From bruno at wolff.to  Thu Jan  1 00:33:57 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 31 Dec 2008 18:33:57 -0600
Subject: Getting started with Rawhide
In-Reply-To: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
Message-ID: <20090101003357.GA24966@wolff.to>

On Wed, Dec 31, 2008 at 15:37:47 -0700,
  Jerry James <loganjerry at gmail.com> wrote:
> 
> First, I couldn't get the Rawhide CD image to finish an installation.

There were warnings about rawhide not being installable for a bit.

> Weirdly, it failed in different ways every time I tried to use it.  So
> I tried to use the F10 -> Rawhide update method with yum documented
> here [1].  I installed from my F10 DVD, then *without updating F10*,
> changed repositories and did an update from the Rawhide repository.

That's what I did.

> It appears that glibc in Rawhide (2.8.90) is older than the glibc in
> the initial F10 release (2.9).  Am I seeing that correctly?  If so,
> should I downgrade, or wait for Rawhide to catch up?

There are a few other things that have higher versions in F10. That caused
me a bit of grief. The dejavu fonts change also caused some problems.
Something that couldn't be updated pinned some other package that was
needed for another package and skip broken couldn't figure out how to
fix things. (It would be nice if it could at least tell it couldn't
succeed rather than going on in an endless loop.) There are also a few
kde-i18 and kde-i10 packages that have conflicting files.

For some things I uninstalled them in F10 to get the upgrade to succeed and
then the other stuff I cleaned up later using rpm to do a downgrade.
I used package-cleanup to find things that needed looking at.

> Can anybody tell me how to get a screen resolution higher than 800x600
> in the virtual machine?

That I can't help you with.

> Incidentally, the yum upgrade spit out somewhere around a million [2]
> warnings that /usr/lib64/libxcb-xlib.so.0 is not a symbolic link,
> apparently every time that ldconfig ran.  Since "rpm -V libxcb"
> produces no output, this appears to be intentional.  F10 gets this
> right (/usr/lib64/libxcb-xlib.so.0 is a symbolic link to
> /usr/lib64/libxcb-xlib.so.0.0.0).

There's been a bug filed on that from about 4 months ago. The problem
seems relatively harmless, so you don't need to do anything about it.



From bpepple at fedoraproject.org  Thu Jan  1 01:47:49 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 31 Dec 2008 20:47:49 -0500
Subject: [Fwd: XO Camp Anouncement e-mail]
Message-ID: <1230774469.28268.3.camel@localhost.localdomain>

Forwarding this to the devel list:
-------- Forwarded Message --------
Hi All,

One Laptop per Child is holding a technical conference called XO Camp 2 
at our Headquarters in Cambridge, MA, January 12 - 16 2009. Its right 
after Fudcon so we hope people can make it.

The conference will focus on the technical work needed to get our XO 
Software Release 9.1.0 shipped.

Conference agenda, address and sign up are here:
http://wiki.laptop.org/go/XOcamp_2

Sign up or join the conference anytime. Questions and comments welcome 
to our engineering list at: http://lists.laptop.org/listinfo/devel
or to greg at laptop.org.

Thanks,

Greg Smith OLPC
Product Manager
---

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081231/c4a03a08/attachment.sig>

From rawhide at fedoraproject.org  Thu Jan  1 07:51:07 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu,  1 Jan 2009 07:51:07 +0000 (UTC)
Subject: rawhide report: 20090101 changes
Message-ID: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>

Compose started at Thu Jan  1 06:01:03 UTC 2009

New package bkchem
        Chemical drawing program
New package ethstatus
        Console-based ethernet statistics monitor
New package farsight2
        Libraries for videoconferencing
New package ircp-tray
        Infrared file transfer applet for GNOME panel
New package python-oasa
        Python library for manipulation of chemical formats
New package tryton
        Client for the Tryton application framework
Updated Packages:

apt-0.5.15lorg3.95-0.git416.3.fc11
----------------------------------
* Wed Dec 31 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 0.5.15lorg3.95-0.git416.3
- trim down ancient cruft in rpmpriorities (#444287)
- depend on system-release instead of fedora-release (#474911)
- look into provides when looking for DistroVerPkg

* Wed Dec 31 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 0.5.15lorg3.95-0.git416.2
- dont enable update "service" by default (#445096)


awstats-6.9-1.fc11
------------------
* Wed Dec 31 17:00:00 2008 Aurelien Bompard <abompard at fedoraproject.org> 6.9-1
- version 6.9
- use Debian's version of the CVE-2008-3714 fix


bigboard-0.6.4-4.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.6.4-4
- Rebuild for Python 2.6


bzr-gtk-0.95.0-3.fc11
---------------------
* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.95.0-3
- Rebuild for Python 2.6


cherokee-0.11.6-1.fc11
----------------------

elfutils-0.138-1.fc11
---------------------
* Wed Dec 31 17:00:00 2008 Roland McGrath <roland at redhat.com> - 0.138-1
- Update to 0.138
  - Install <elfutils/version.h> header file for applications to use in
    source version compatibility checks.
  - libebl: backend fixes for i386 TLS relocs; backend support for NT_386_IOPERM
  - libcpu: disassembler fixes (#469739)
  - libdwfl: bug fixes (#465878)
  - libelf: bug fixes
  - eu-nm: bug fixes for handling corrupt input files (#476136)


fedora-business-cards-0.2.4-2.fc11
----------------------------------
* Wed Dec 31 17:00:00 2008 Ian Weller <ianweller at gmail.com> 0.2.4-2
- Fix F11 dependency on the MgOpen fonts


gnome-compiz-manager-0.10.4-7.fc11
----------------------------------
* Wed Dec 31 17:00:00 2008 Caol??n McNamara <caolanm at redhat.com> 0.10.4-7
- rebuild for dependencies


gnubg-0.9.0.1-4.fc11
--------------------
* Tue Dec 30 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 1:0.9.0.1-4
- Drop and symlink to system fonts, BZ 477391.


gwave-2-13.20080626snap.fc11
----------------------------
* Wed Dec 31 17:00:00 2008 Lubomir Rintel <lkundrak at v3.sk> - 2-13.20080626snap
- New upstream snapshot

* Sun Dec 28 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 2-12.20070514snap
- rebuild for rawhide


hyphen-sk-0.20031227-2.fc11
---------------------------
* Wed Dec 31 17:00:00 2008 Caolan McNamara <caolanm at redhat.com> - 0.20031227-2
- Slobak -> Slovak typo


kernel-2.6.29-0.7.rc0.git3.fc11
-------------------------------
* Wed Dec 31 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
- Linux 2.6.28-git3


koffice-1.9.98.4-1.fc11
-----------------------
* Wed Dec 31 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.4-1
- koffice-1.9.98.4 (koffice2 beta5)

* Sun Dec 21 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.3-2
- respin (omit broken eviv2 support, for now)


koffice-langpack-1.9.98.4-1.fc11
--------------------------------

liboggz-0.9.8-2.fc11
--------------------
* Tue Dec 30 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.9.8-2
- Multilib fixes (bugs #342291, #477291)


lilypond-2.12.0-3.fc11
----------------------
* Tue Dec 30 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.12.0-3
- Split out fonts subpackage, BZ 477416.

* Tue Dec 30 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> - 2.12.0-2
- Re-fix Source0 URL.


liveusb-creator-3.0-5.fc11
--------------------------
* Wed Dec 31 17:00:00 2008 Luke Macken <lmacken at redhat.com> 3.0-5
- Rebuild


maxima-5.17.1-2.fc11
--------------------
* Wed Dec 31 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 5.17.1-2
- respin (sbcl)


mono-2.2-15.RC1.20081231svn122288.fc11
--------------------------------------
* Wed Dec 31 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-15.RC1.20081231svn122288
- Important updates from svn


mono-basic-2.2-9.RC1.20081231svn122295.fc11
-------------------------------------------
* Wed Dec 31 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-9.RC1.20081231svn122295
- Hack to build under ppc. Will revert next build

* Wed Dec 31 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-8.RC1.200812131svn122295
- Large update from svn
- Retag for RC1 release

* Fri Dec 19 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-7.pre3.20081217svn121665
- Reenable ppc


ochusha-0.6.0.1-0.2.cvs20090101T0130.fc11
-----------------------------------------
* Thu Jan  1 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- A Happy New Year


purple-facebookchat-1.47-1.fc11
-------------------------------
* Wed Dec 31 17:00:00 2008 Ismael Olea <ismael at olea.org> 1.47-1
- updating to 1.47


sbcl-1.0.24-1.fc11
------------------
* Wed Dec 31 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 1.0.24-1
- sbcl-1.0.24


sqlite-3.6.7-1.fc11
-------------------
* Wed Dec 31 17:00:00 2008 Panu Matilainen <pmatilai at redhat.com> - 3.6.7-1
- update to 3.6.7
- avoid lemon ending up in main sqlite package too


transmission-1.42-1.fc11
------------------------
* Wed Dec 31 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 1.42-1
- Update to 1.42.
- Update event patch to 1.42.


xmoto-0.5.0-3.fc11
------------------
* Tue Dec 30 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 0.5.0-3
- Symlink to system font, BZ 477485.
- Dropped extension from icon in .desktop.

* Wed Dec 10 17:00:00 2008 Jon Ciesla <limb at jcomserv.net> 0.5.0-2
- No remaining fuzzy patches, dropping patch fuzz workaround.


Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 26
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.i386 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	neverball-1.4.0-12.fc11.i386 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.i386 requires dejavu-fonts



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.x86_64 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.x86_64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.x86_64 requires dejavu-fonts



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.ppc requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5
	wormux-0.8.2-2.fc11.ppc requires dejavu-fonts



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.ppc64 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-cdda-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-audio-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	neverball-1.4.0-12.fc11.ppc64 requires bitstream-vera-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	wormux-0.8.2-2.fc11.ppc64 requires dejavu-fonts





From valent.turkovic at gmail.com  Thu Jan  1 10:19:45 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 1 Jan 2009 11:19:45 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <200812301714.24094.konrad@tylerc.org>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
Message-ID: <64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>

On Wed, Dec 31, 2008 at 2:14 AM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
>> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
>> > *Please* stop posting the particular bugs that affect you to the mailing
>> > list as if they are higher priority than any other bugs.
>> >
>> > Regards,
>> > --
>> > Conrad Meyer <konrad at tylerc.org>
>>
>> I'm not saying that this bug has some too high importance but to say
>> that all bugs are created equal is not true.
>
> That's why there is a priority setting for each bug on bugzilla.
>

Are you being intentionally ignorant or are you new to this list? I
have heard numerous times that priority setting is being ignored and
it doesn't matter what you set it to.

>> Also I heard a lot of positive feedback when some specific bugs got
>> mentioned on this list, if you believe it is now important you can
>> choose to ignore that thread.
>
> (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
> work. Ignoring spam that is sent to onesself regularly doesn't stop it from
> being sent. Please don't contribute to the internet's spam problem. I don't
> believe there is any added value in your regular mailings of the list with
> your own bugs.
>
> Regards,
> --
> Conrad Meyer <konrad at tylerc.org>
>

I believe that this issue should be discussed also here, and there are
people who aren't ware of it or maybe I'm wrong and this isn't a bug
but some error on my part so others can show me that.

Anyway I would like to help fix this issue with my feedback and
testing and that is one more reason why I wrote to this list.

If you have some helpful suggestions or comments please join the
discussion or feel free to ignore it.

Cheers and happy New Year!

-- 
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  Thu Jan  1 10:22:17 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Thu, 1 Jan 2009 11:22:17 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <20081230210941.02be930e@gmx.net>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
	<64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>
	<20081230210941.02be930e@gmx.net>
Message-ID: <64b14b300901010222y55d526begbffee96dd2b3401c@mail.gmail.com>

On Tue, Dec 30, 2008 at 9:09 PM, Stefan Grosse <singularitaet at gmx.net> wrote:
> On Tue, 30 Dec 2008 18:18:04 +0100 "Valent Turkovic"
>
> VT> >> this bug [1] makes Fedora 10 unusable on Asus eee 701 because
> VT> >> onboard 4GB drive is too small for default set of apps and after
> VT> >> updates drive keeps shrinking to 0MB free :(((
>
> VT> I'm using standard Fedora desktop spin (CD Gnome spin). I removed
> VT> some locals after install and installed some additiona apps that are
> VT> essential but are missing from desktop spin - like OpenOffice.
>
> Dear Ikea, I cannot fit the Billy shelves that I bought into my VW
> beetle. Please consider this as a major failure in
> the construction of billy shelves.
>
> Happy New Year! ;-)
>
> Stefan
>
> PS I suppose you haven't been successfull installing XP including OO?

Nope, do you have some tips regarding that? ;)

Cheers and Happy New Year!

-- 
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 cdahlin at redhat.com  Thu Jan  1 10:27:11 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Thu, 01 Jan 2009 05:27:11 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495B0362.6030906@gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>	<49588D9D.5020303@gmail.com>	<495A18D5.3030602@nobugconsulting.ro>
	<495B0362.6030906@gmail.com>
Message-ID: <495C9A7F.9080300@redhat.com>

Lyos Gemini Norezel wrote:
> Manuel Wolfshant wrote:
>> On 12/29/2008 10:43 AM, Lyos Gemini Norezel wrote:
>>> Casey Dahlin wrote:
>>>> Lyos Gemini Norezel wrote:
>>>> I don't see why either of those should exist entirely in /boot. You 
>>>> are allowed further partitions. 
>>>
>>> Where else would they be better placed?
>> in /dev/sda2, also known as "hidden rescue partition".
>>
>>> I have no desire to clutter my disk with endless numbers of partitions, 
>> indeed. only one additional partition is enough. and guess what ? 
>> that's what numberless laptop manufacturers do in order to store a 
>> ghost-ed backup of the main partition
>
> Most laptops (ie., Win$hit boxen) don't need a /boot or even a swap 
> partition.
>
> If you have /dev/sda1 as a /boot partition, /dev/sda2 as a /rescue 
> partition, /dev/sda3 as a swap partition, /dev/sda4 becomes an 
> extended partition... and /dev/sda5 winds up as your /root partition.
>

And? The numbers are free. I can see not wanting to have lots of 
partitions to distinguish from, but this use case doesn't strike me as 
killer.

--CJD



From kevin.kofler at chello.at  Thu Jan  1 11:02:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 01 Jan 2009 12:02:47 +0100
Subject: Fedora unusable on Asus eee 701
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
Message-ID: <gji7sn$497$1@ger.gmane.org>

Valent Turkovic wrote:
> Are you being intentionally ignorant or are you new to this list? I
> have heard numerous times that priority setting is being ignored and
> it doesn't matter what you set it to.

The priority setting is often (not always) ignored because it is getting set
by users like you.

The developers fix the bugs according to THEIR priorities (often based on
how many users are affected and how badly), it is not your business to
decide that your bug is more important than somebody else's. Posting "my
bug is important" to a mailing list is just as impolite and arrogant as
bumping its priority, and in addition it will also annoy people who don't
care about your bug at all (if they did, they'd be CCed on it).

        Kevin Kofler



From bashton at brennanashton.com  Thu Jan  1 16:03:16 2009
From: bashton at brennanashton.com (Brennan Ashton)
Date: Thu, 1 Jan 2009 10:03:16 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495B0362.6030906@gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com> <495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com> <495A18D5.3030602@nobugconsulting.ro>
	<495B0362.6030906@gmail.com>
Message-ID: <981da310901010803r2608c24eyd94f3067ee6b64f7@mail.gmail.com>

On Tue, Dec 30, 2008 at 11:30 PM, Lyos Gemini Norezel
<lyos.gemininorezel at gmail.com> wrote:
> Manuel Wolfshant wrote:
>>
>> On 12/29/2008 10:43 AM, Lyos Gemini Norezel wrote:
>>>
>>> Casey Dahlin wrote:
>>>>
>>>> Lyos Gemini Norezel wrote:
>>>> I don't see why either of those should exist entirely in /boot. You are
>>>> allowed further partitions.
>>>
>>> Where else would they be better placed?
>>
>> in /dev/sda2, also known as "hidden rescue partition".
>>
>>> I have no desire to clutter my disk with endless numbers of partitions,
>>
>> indeed. only one additional partition is enough. and guess what ? that's
>> what numberless laptop manufacturers do in order to store a ghost-ed backup
>> of the main partition
>
> Most laptops (ie., Win$hit boxen) don't need a /boot or even a swap
> partition.
>
> If you have /dev/sda1 as a /boot partition, /dev/sda2 as a /rescue
> partition, /dev/sda3 as a swap partition, /dev/sda4 becomes an extended
> partition... and /dev/sda5 winds up as your /root partition.
<SNIP>
> Lyos Gemini Norezel

You can avoid some of that with LVM.   And while I DO NOT recommend
it, with some tweaking you could get all of this on one partition, but
I guess I dont get your point. I tend to just ignore my physical
partition lay out (various dual boots over time have left it in
shambles MS will only look in certain places), and just let LVM do its
magic. With just three partitions I have XP, F8, F9, F10.

If anything I would like to see some lvm love from grub... But that's
a whole nother can of worms.

--Brennan Ashton



From cra at WPI.EDU  Thu Jan  1 16:33:11 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 1 Jan 2009 11:33:11 -0500
Subject: rawhide report: 20090101 changes
In-Reply-To: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
References: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
Message-ID: <20090101163311.GA9611@angus.ind.WPI.EDU>

On Thu, Jan 01, 2009 at 07:51:07AM +0000, Rawhide Report wrote:
> kernel-2.6.29-0.7.rc0.git3.fc11
> -------------------------------
> * Wed Dec 31 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
> - Linux 2.6.28-git3

Shouldn't this be 2.6.29-git3?



From kevin.kofler at chello.at  Thu Jan  1 16:50:58 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 01 Jan 2009 17:50:58 +0100
Subject: rawhide report: 20090101 changes
References: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
	<20090101163311.GA9611@angus.ind.WPI.EDU>
Message-ID: <gjis9i$kk1$1@ger.gmane.org>

Chuck Anderson wrote:
> Shouldn't this be 2.6.29-git3?

No, Linus's numbering uses 2.6.28-gitN for the first snapshots after 2.6.28.
(It's post-release numbering, not pre-release numbering.)

        Kevin Kofler



From nikolay at vladimiroff.com  Thu Jan  1 16:56:45 2009
From: nikolay at vladimiroff.com (Nikolay Vladimirov)
Date: Thu, 1 Jan 2009 18:56:45 +0200
Subject: vim syntax file packaging
Message-ID: <20090101165645.GA3821@voltron>

Hi!

I was wondering if there is a proper way of packaging vim syntax
files. 
When I did ' yum whatprovides \*.vim ' I saw 4 ways of doing this:

1) Add the files to /usr/share/vim/vim71/ftdetect/ and
/usr/share/vim/vim71/ftplugin/. One package even provides a 
subpackage only for the vim syntax. I think this is done because the
subpackage can require vim. which is reasonable if you install a vim
syntax file.  
2) Add them in /usr/share/doc/packagename
3) Add them in /usr/share/packagename
4) Distributed with vim-common

So is there a guideline I missed? 
Is it for the packager to decide?
It's good to have at least some 'best practice' note about this. 

Best Regards,
Nikolay Vladimirov
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090101/76941bad/attachment.sig>

From bpepple at fedoraproject.org  Thu Jan  1 18:26:39 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 01 Jan 2009 13:26:39 -0500
Subject: Package Review Stats for 2008
Message-ID: <1230834399.13150.11.camel@localhost.localdomain>

Hi all,

The top ten FAS account holders who have completed reviewing "Package
review" components on bugzilla for the year ending December 31st, 2008
were Parag AN(????), Jason Tibbitts, Mamoru Tasaka, Manuel Wolfshant,
Kevin Fenzi, Jon Ciesla, Brian Pepple, Dan Hor?k, Patrice Dumas, and
Marek Mahut.  Below is the number of completed package reviews done
during 2008.

Parag AN(????) - 319
Jason Tibbitts - 264
Mamoru Tasaka - 158
manuel wolfshant - 95
Kevin Fenzi - 47
Jon Ciesla - 45
Brian Pepple - 42
Dan Hor?k - 40
Patrice Dumas - 36
Marek Mahut - 31
Jeroen van Meeuwen - 28
Orcan 'oget' Ogetbil - 25
Tom "spot" Callaway - 24
Lubomir Rintel - 23
Rex Dieter - 23
Peter Lemenkov - 22
Hans de Goede - 21
Marcela Maslanova - 20
Matthias Clasen - 19
Richard W.M. Jones - 19
Lubomir Kundrak - 18
Rakesh Pandit - 17
Michel Alexandre Salim - 16
Rahul Sundaram - 16
Debarshi Ray - 15
Michael Schwendt - 15
Till Maas - 15
Dennis Gilmore - 14
Ed Hill - 13
Ville Skytt? - 13
S.A. Hartsuiker - 12
Chris Weyl - 11
Ruben Kerkhof - 11
Xavier Bachelot - 11
Nicolas Chauvet (kwizart) - 10
Nicolas Mailhot - 10
Christoph Wickert - 9
Colin Walters - 9
David Nielsen - 9
Jens Petersen - 9
Jesse Keating - 9
Peter Robinson - 9
David Woodhouse - 8
Fabian Affolter - 8
Kevin Kofler - 8
Alex Lancaster - 7
Conrad Meyer - 7
David Lutterkort - 7
Matej Cepl - 7
Nigel Jones - 7
Adam Tkac - 6
Adel Gadllah - 6
Dominik 'Rathann' Mierzejewski - 6
Lillian Angel - 6
Lucian Langa - 6
Matt Domsch - 6
Nuno Santos - 6
Rob Crittenden - 6
Xavier Lamien - 6
Andrew Overholt - 5
Bastien Nocera - 5
Jerry James - 5
Remi Collet - 5
Simon Schampijer - 5
Sven Lankes - 5
Thomas Moschny - 5
Tim Lauridsen - 5
Bill Nottingham - 4
Chris Feist - 4
Daniel Berrange - 4
Denis Leroy - 4
Jan ONDREJ - 4
Jarod Wilson - 4
Johan Cwiklinski - 4
John Mahowald - 4
Jon Stanley - 4
Miroslav Lichvar - 4
Robert Scheck - 4
Terje R??sten - 4
Tyler Owen - 4
Alexander Kahl - 3
Brennan Ashton - 3
Bryan Kearney - 3
Caolan McNamara - 3
Chitlesh GOORAH - 3
David A. Wheeler - 3
Erik van Pienbroek - 3
Hans Ulrich Niedermann - 3
Ian Weller - 3
Jos? Matos - 3
Jussi Lehtola - 3
Levente Farkas - 3
Marco Pesenti Gritti - 3
Michal Marciniszyn - 3
Miroslav Suchy - 3
Owen Taylor - 3
Paul F. Johnson - 3
Peter Vrabec - 3
Pierre-YvesChibon - 3
Rafa? Psota - 3
Ralf Corsepius - 3
Ricky Zhou - 3
Robin Norwood - 3
Stepan Kasal - 3
Thomas Fitzsimmons - 3
Tomas Mraz - 3
Toshio Ernie Kuratomi - 3
Beno?t Marcelin - 2
Chris Lalancette - 2
Christopher Aillon - 2
Christopher Stone - 2
Dan Hor??k - 2
Dan Smith - 2
Darryl L. Pierce - 2
Ignacio Vazquez-Abrams - 2
Jeremy Katz - 2
Jonathan Roberts - 2
Josh Boyer - 2
Julian Sikorski - 2
Lorenzo Villani - 2
Michal Nowak - 2
Neil Horman - 2
Nils Philippsen - 2
Orion Poplawski - 2
Paul Howarth - 2
Paulo Roma Cavalcanti - 2
Permaine Cheung - 2
Rahul Bhalerao - 2
Randall Berry - 2
Sergio Pascual - 2
Simon Wesp - 2
Steven Pritchard - 2
Todd Zullinger - 2
Wart - 2
Adam Jackson - 1
Adrian Reber - 1
Alan Dunn - 1
Alexey Torkhov - 1
Allisson Azevedo - 1
Andreas Thienemann - 1
Anthony Green - 1
Axel Thimm - 1
Benjamin Krill - 1
Benjamin Lewis - 1
Bernie Innocenti - 1
Casey Dahlin - 1
Charles R. Anderson - 1
Chris Lumens - 1
Christophe GRENIER - 1
Clint Savage - 1
David Cantrell - 1
David Timms - 1
Deepak Bhole - 1
Deji Akingunola - 1
Felix Kaechele - 1
Gianluca Sforna - 1
Harald Hoyer - 1
Hemant Goyal - 1
Ian Chapman - 1
Jaroslav Reznik - 1
Jef Spaleta - 1
Jochen Schmitt - 1
Jonathan Dieter - 1
Karol Trzcionka - 1
Karsten Hopp - 1
Luke Macken - 1
Luya Tshimbalanga - 1
Mads Villadsen - 1
Marc Wiriadisastra - 1
Martin Sourada - 1
Matt Wringe - 1
Matthias Saou - 1
Michal Schmidt - 1
Micha? Bentkowski - 1
Milos Jakubicek - 1
Miloslav Trmac - 1
Patrick Monnerat - 1
Paul Nasrat - 1
Paul Wouters - 1
Pavel Lis? - 1
Pierre-Yves - 1
Robert M.Albrecht - 1
Roland McGrath - 1
Roy Rankin - 1
Sebastian Vahl - 1
Seth Vidal - 1
Shawn Starr - 1
Stefan Posdzich - 1
Stephen Warren - 1
Steve Grubb - 1
Steven M. Parrish - 1
Terje R???sten - 1
Thibault North - 1
Thorsten Leemhuis - 1
Tomas Heinrich - 1
Tomeu Vizoso - 1
Ville Skytt? - 1
Ville-Pekka Vainio - 1
Warren Togami - 1
_pjp_ - 1

Review Requests: 1813
Merge Reviews: 116
Total Reviews Completed: 1978

Thanks to everyone that spent time working on package reviews during
2008.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090101/ccd301e1/attachment.sig>

From davej at redhat.com  Thu Jan  1 18:35:12 2009
From: davej at redhat.com (Dave Jones)
Date: Thu, 1 Jan 2009 13:35:12 -0500
Subject: rawhide report: 20090101 changes
In-Reply-To: <20090101163311.GA9611@angus.ind.WPI.EDU>
References: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
	<20090101163311.GA9611@angus.ind.WPI.EDU>
Message-ID: <20090101183512.GA7661@redhat.com>

On Thu, Jan 01, 2009 at 11:33:11AM -0500, Chuck Anderson wrote:
 > On Thu, Jan 01, 2009 at 07:51:07AM +0000, Rawhide Report wrote:
 > > kernel-2.6.29-0.7.rc0.git3.fc11
 > > -------------------------------
 > > * Wed Dec 31 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
 > > - Linux 2.6.28-git3
 > 
 > Shouldn't this be 2.6.29-git3?

No. Upstream doesn't use the same 'rc0' numbering style as us,
they just imply it instead.  29-git3 will be the third patch
that comes out after .29 is released.

	Dave

-- 
http://www.codemonkey.org.uk



From bcrl at kvack.org  Fri Jan  2 00:45:01 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 1 Jan 2009 19:45:01 -0500
Subject: new quagga rpms?
Message-ID: <20090102004501.GA15498@kvack.org>

Hi folks,

Are there any plans to update the version of quagga in testing?  It fixes 
at least one bug that a couple of my routers have been hitting pertaining 
to missed routing table updates.

		-ben



From loganjerry at gmail.com  Fri Jan  2 04:27:28 2009
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 1 Jan 2009 21:27:28 -0700
Subject: Getting started with Rawhide
In-Reply-To: <20090101003357.GA24966@wolff.to>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
Message-ID: <870180fe0901012027i63334de4i2bbac61d1602b56d@mail.gmail.com>

On Wed, Dec 31, 2008 at 5:33 PM, Bruno Wolff III <bruno at wolff.to> wrote:
> There are a few other things that have higher versions in F10. That caused
> me a bit of grief. The dejavu fonts change also caused some problems.
> Something that couldn't be updated pinned some other package that was
> needed for another package and skip broken couldn't figure out how to
> fix things. (It would be nice if it could at least tell it couldn't
> succeed rather than going on in an endless loop.) There are also a few
> kde-i18 and kde-i10 packages that have conflicting files.
>
> For some things I uninstalled them in F10 to get the upgrade to succeed and
> then the other stuff I cleaned up later using rpm to do a downgrade.
> I used package-cleanup to find things that needed looking at.

Ah, yes, I forgot about package-cleanup.  So, skipping the F-10
kernel, here is what "package-cleanup --orphans" reports on my virtual
Rawhide machine:

glibc-2.9-2.x86_64
glibc-common-2.9-2.x86_64
glibc-devel-2.9-2.x86_64
glibc-headers-2.9-2.x86_64
libdhcp-1.99.8-1.fc10.x86_64
libdhcp4client-4.0.0-30.fc10.x86_64
libdhcp6client-1.0.22-1.fc10.x86_64
nscd-2.9-2.x86_64
xorg-x11-drv-mga-1.4.9-1.fc9.x86_64
xorg-x11-drv-mouse-1.3.0-2.fc9.x86_64

I admit that having glibc on that list really surprises me.  It's such
a fundamental piece of the system...

Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From kevin.kofler at chello.at  Fri Jan  2 06:01:24 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 02 Jan 2009 07:01:24 +0100
Subject: Getting started with Rawhide
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
	<870180fe0901012027i63334de4i2bbac61d1602b56d@mail.gmail.com>
Message-ID: <gjkajk$ioe$1@ger.gmane.org>

Jerry James wrote:
> I admit that having glibc on that list really surprises me.  It's such
> a fundamental piece of the system...

Obviously you can't remove it...

What you're seeing is an upgrade path bug, i.e. the EVR in Rawhide is lower
than in F10.

        Kevin Kofler



From rawhide at fedoraproject.org  Fri Jan  2 08:23:33 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri,  2 Jan 2009 08:23:33 +0000 (UTC)
Subject: rawhide report: 20090102 changes
Message-ID: <20090102082333.DDCFE1F825D@releng2.fedora.phx.redhat.com>

Compose started at Fri Jan  2 06:01:02 UTC 2009

New package python-twisted-web2
        Experimental Twisted Web Server Framework
Updated Packages:

PyOpenGL-3.0.0-0.11.b8.fc11
---------------------------
* Fri Jan  2 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> - 3.0.0-0.11.b8
- New upstream 3.0.0b8 (b7 was skipped by upstream)
- performance, bug-fix and packaging release. 
- Use macro for "python"
- remove "--single-version-externally-managed" option for setup.py
- *.egg-info is no longer a folder, it's a file now 
- Tests are no longer installed by setup.py
- Obsolete 'doc' subpackage (no longer distributed "documentation" folder)
- license.txt is also no longer provided by upstream. Using one from b6
- Removed Requires for libGL and libGLU ( should be pulled for freeglut)


cairo-dock-2.0.0-0.3.svn1458_trunk.fc11
---------------------------------------
* Fri Jan  2 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1458


elfutils-0.138-2.fc11
---------------------
* Thu Jan  1 17:00:00 2009 Roland McGrath <roland at redhat.com> - 0.138-2
- Fix libelf regression.


emerald-0.7.8-1.fc11
--------------------
* Thu Jan  1 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> - 0.7.8-1
- Minor bugfixes
- L10N updates
- Droping .desktop file patch ( now upsteam )


gimp-2.6.4-1.fc11
-----------------
* Thu Jan  1 17:00:00 2009 Nils Philippsen <nils at redhat.com> - 2:2.6.4-1
- version 2.6.4

  Overview of Changes from GIMP 2.6.3 to GIMP 2.6.4
  =================================================
  
  * Bugs fixed:
  
   565223 ??? Perspective transformation jagged edges / comb effect
   563985 ??? jpg save dialog: "cancel" is treated like "commit"
            for settings
   564087 ??? Using clone tool on a layer with a part out of canvas
            causes crashes
   564593 ??? crash when the drawable is changed while a color tool
            is active
   564869 ??? GIMP crashes on selecting Tools->GEGL operation
   565138 ??? python-fu-foggify does not check if image is in rgb mode
   563130 ??? Hue selection mode does not cross the 0-360 degrees line
   563179 ??? Scrollbars not resized when we extend the canvas size
   562459 ??? PF_PALETTE: 'TypeError' when used in a plugin that is
            registered in <Image>
   562427 ??? Compilation with --as-needed
   562386 ??? PF_SLIDER and PF_SPINNER 'Step' values do not change
            consistently...
   562366 ??? Default image dimensions are not correctly
            transferred in the file/new dialog box
   561899 ??? GIMP can't save to mounted filesystem if file exists
  
  * Updated translations:
  
   Greek (el)
   Hindi (hi)
   Hungarian (hu)
   Italian (it)
   Japanese (ja)
   Korean (ko)
   Slovenian (sl)
   Swedish (sv)
   Tamil (ta)
   Simplified Chinese (zh_CN)
- add BuildRequires: aalib-devel


gstreamer-plugins-base-0.10.21-3.fc11
-------------------------------------
* Thu Jan  1 17:00:00 2009 - Rex Dieter <rdieter at fedoraproject.org> - 0.10.2-3
- rebuild for pkgconfig deps (#478577)


gtk2-2.15.0-1.fc11
------------------
* Thu Jan  1 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.0-1
- Update to 2.15.0


libgsasl-0.2.29-1.fc11
----------------------
* Thu Jan  1 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> - 0.2.29-1
- Rewrite to use poll instead of select.
- Don't use poll with POLLOUT to avoid busy-waiting.


liveusb-creator-3.1-1.fc11
--------------------------
* Thu Jan  1 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.1-1
- Latest upstream release, containing some windows-specific
  optimizations and fixes.


mercurial-1.1.2-2.fc11
----------------------
* Thu Jan  1 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 1.1.2-2
- Rename mergetools.rc -> mergetools.rc.sample

* Thu Jan  1 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 1.1.2-1
- Update to 1.1.2

* Wed Dec 24 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.1.1-3
- Install mergetools.rc as mergetools.rc.sample


msmtp-1.4.17-1.fc11
-------------------
* Thu Jan  1 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> - 1.4.17-1
- Msmtp now also reads SYSCONFDIR/netrc if the password wasn't found in ~/.netrc.
- Support for the GNOME keyring was added by Satoru SATOH.
- Added BuildRequires for gnome-keyring-devel due to the new feature.
- Added PDF version of the manual.


neverball-1.4.0-13.fc11
-----------------------
* Thu Jan  1 17:00:00 2009 Wart <wart at kobold.org> - 1.4.0-13
- Fix font package name for F11


papyrus-0.7.1-6.fc11
--------------------
* Thu Jan  1 17:00:00 2009 Tim Niemueller <tim at niemueller.de> - 0.7.1-6
- Make all dtors virtual to fix compile warnings (errors with -Wall -Werror)


perl-PDL-2.4.4-2.fc11
---------------------
* Thu Jan  1 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> - 2.4.4-2
- Use PDL-Graphics-PLplot-0.47 to support latest plplot


poker-engine-1.3.2-1.fc11
-------------------------
* Thu Jan  1 17:00:00 2009 Christopher Stone <chris.stone at gmail.com> 1.3.2-1
- Upstream sync
- Add new BR procps for make check


poker-eval-135.0-1.fc11
-----------------------
* Thu Jan  1 17:00:00 2009 Christopher Stone <chris.stone at gmail.com> 135.0-1
- Upstream sync
- Add patch to remove exit calls from library


pypoker-eval-136.0-1.fc11
-------------------------
* Thu Jan  1 17:00:00 2009 Christopher Stone <chris.stone at gmail.com> 136.0-1
- Upstream sync
- Remove no longer needed python26 patch


python-libgmail-0.1.11-1.fc11
-----------------------------
* Fri Jan  2 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> - 0.1.11-1
- New upstream 0.1.11
- Fixed bug that broke attachment support (SF bug #2034927) 
- added .author_fullname field for messages 
- Don't crash on threads with google chat log


rdiff-backup-1.2.4-1.fc11
-------------------------
* Thu Jan  1 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.4-1
- Update to 1.2.4


rsync-3.0.5-0.fc11
------------------
* Thu Jan  1 17:00:00 2009 Simo Sorce <ssorce at redhat.com> 3.0.5-0.fc11
- New upstream bugfix release


rubyripper-0.5.4-1.fc11
-----------------------
* Thu Jan  1 17:00:00 2009 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.5.4-1
- New upstream release


wormux-0.8.2-3.fc11
-------------------
* Thu Jan  1 17:00:00 2009 Wart <wart at kobold.org> 0.8.2-3
- Fix font package name for F11


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 22
Broken deps for i386
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.i386 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	olpc-utils-0.89-7.fc11.i386 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.x86_64 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	olpc-utils-0.89-7.fc11.x86_64 requires /usr/bin/python2.5
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.ppc requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	olpc-utils-0.89-7.fc11.ppc requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	1:gnubg-0.9.0.1-4.fc11.ppc64 requires bitstream-vera-fonts
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	olpc-utils-0.89-7.fc11.ppc64 requires /usr/bin/python2.5
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From iarnell at gmail.com  Fri Jan  2 08:34:11 2009
From: iarnell at gmail.com (iarnell)
Date: Fri, 2 Jan 2009 09:34:11 +0100
Subject: vim syntax file packaging
In-Reply-To: <20090101165645.GA3821@voltron>
References: <20090101165645.GA3821@voltron>
Message-ID: <81487f820901020034v4f31449ev28b7851f829f3363@mail.gmail.com>

2009/1/1 Nikolay Vladimirov <nikolay at vladimiroff.com>
>
> Hi!
>
> I was wondering if there is a proper way of packaging vim syntax
> files.
> When I did ' yum whatprovides \*.vim ' I saw 4 ways of doing this:
>
> 1) Add the files to /usr/share/vim/vim71/ftdetect/ and
> /usr/share/vim/vim71/ftplugin/. One package even provides a
> subpackage only for the vim syntax. I think this is done because the
> subpackage can require vim. which is reasonable if you install a vim
> syntax file.
> 2) Add them in /usr/share/doc/packagename
> 3) Add them in /usr/share/packagename
> 4) Distributed with vim-common
>
> So is there a guideline I missed?
> Is it for the packager to decide?
> It's good to have at least some 'best practice' note about this.

When I recently packaged vim-perl-support, the closest I could find to
a 'best practice' was to follow what was done for vim-vimoutliner
package.  Basically, just put any syntax/plugin/detect/whatever files
into the appropriate subdirectories of /usr/share/vim/vimfiles -
definitely not into /usr/share/vim/vim71, though as this would create
an unnecessary dependency on a particular vim version.

For a syntax file supplied as part of a larger package, I certainly
like the idea of making it a subpackage. And requiring vim when
installing something under /usr/share/vim would be necessary to get
correct directory ownership.

Anything installed under /usr/share{/doc,}/packagename won't be
automatically picked up by vim, so unless you happen to spot that it
got installed, you'd never take advantage of it.

--
Iain.



From debarshi.ray at gmail.com  Fri Jan  2 08:52:49 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 2 Jan 2009 14:22:49 +0530
Subject: rawhide report: 20090102 changes
In-Reply-To: <20090102082333.DDCFE1F825D@releng2.fedora.phx.redhat.com>
References: <20090102082333.DDCFE1F825D@releng2.fedora.phx.redhat.com>
Message-ID: <3170f42f0901020052m73b0267bj89e581b74002b267@mail.gmail.com>

>        1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
>        1:anjuta-2.24.1-2.fc11.i386 requires libgladeui-1.so.7
>        1:anjuta-2.24.1-2.fc11.x86_64 requires libgladeui-1.so.7()(64bit)
>        1:anjuta-2.24.1-2.fc11.ppc requires libgladeui-1.so.7
>        1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)
>        1:anjuta-2.24.1-2.fc11.ppc64 requires libgladeui-1.so.7()(64bit)

Sorry for not having solved this before. But thanks to Caolan McNamara
[1], this will happen sooner rather than later.

Cheers,
Debarshi

[1] https://bugzilla.redhat.com/478578



From snecklifter at gmail.com  Fri Jan  2 09:33:56 2009
From: snecklifter at gmail.com (Christopher Brown)
Date: Fri, 2 Jan 2009 09:33:56 +0000
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <20081230210941.02be930e@gmx.net>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
	<64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>
	<20081230210941.02be930e@gmx.net>
Message-ID: <364d303b0901020133i6c413f66xcffd4b4a2243e937@mail.gmail.com>

2008/12/30 Stefan Grosse <singularitaet at gmx.net>:
> On Tue, 30 Dec 2008 18:18:04 +0100 "Valent Turkovic"
>
> VT> >> this bug [1] makes Fedora 10 unusable on Asus eee 701 because
> VT> >> onboard 4GB drive is too small for default set of apps and after
> VT> >> updates drive keeps shrinking to 0MB free :(((
>
> VT> I'm using standard Fedora desktop spin (CD Gnome spin). I removed
> VT> some locals after install and installed some additiona apps that are
> VT> essential but are missing from desktop spin - like OpenOffice.
>
> Dear Ikea, I cannot fit the Billy shelves that I bought into my VW
> beetle. Please consider this as a major failure in
> the construction of billy shelves.
>
> Happy New Year! ;-)
>
> Stefan
>
> PS I suppose you haven't been successfull installing XP including OO?

Please take that attitude somewhere else. This list is for the
development of Fedora. The latest release does not install for Valent
on a hardware platform that is hugely popular. This should be a cause
for concern, not ridicule.

-- 
Christopher Brown



From kmaraas at broadpark.no  Fri Jan  2 13:07:47 2009
From: kmaraas at broadpark.no (Kjartan Maraas)
Date: Fri, 02 Jan 2009 14:07:47 +0100
Subject: rawhide report: 20090101 changes
In-Reply-To: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
References: <20090101075107.AC64B1F825D@releng2.fedora.phx.redhat.com>
Message-ID: <1230901667.12904.3.camel@laptop126.lan>

to., 01.01.2009 kl. 07.51 +0000, skrev Rawhide Report:
> Compose started at Thu Jan  1 06:01:03 UTC 2009
> 
> kernel-2.6.29-0.7.rc0.git3.fc11
> -------------------------------
> * Wed Dec 31 17:00:00 2008 Kyle McMartin <kyle at redhat.com>
> - Linux 2.6.28-git3

This broke X here it seeems. GDM went insane and just flickered for a
long time before giving up. Going back to the previous kernel from
rawhide fixes it.

Attaching some logs.

Cheers
Kjartan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.0.log.old
Type: application/x-trash
Size: 12241 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/df6409ab/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: :0-greeter.log.1
Type: text/x-emacs-lisp
Size: 19087 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/df6409ab/attachment-0001.bin>
-------------- next part --------------

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.5.99.3
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.18.el5 i686 
Current Operating System: Linux localhost.localdomain 2.6.29-0.7.rc0.git3.fc11.i686 #1 SMP Wed Dec 31 11:35:46 EST 2008 i686
Build Date: 28 December 2008  08:42:29PM
Build ID: xorg-x11-server 1.5.99.3-5.fc11 
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan  1 23:24:01 2009
(==) Using config file: "/etc/X11/xorg.conf"
(==) ServerLayout "single head configuration"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor "Monitor0"
(**) |   |-->Device "Videocard0"
(**) |-->Input Device "Keyboard0"
(==) Automatically adding devices
(==) Automatically enabling devices
(==) No FontPath specified.  Using compiled-in default.
(==) FontPath set to:
	built-ins
(==) ModulePath set to "/usr/lib/xorg/modules"
(II) Cannot locate a core pointer device.
(II) The server relies on HAL to provide the list of input devices.
	If no devices become available, reconfigure HAL or disable AllowEmptyInput.
(WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
(WW) Disabling Keyboard0
(--) using VT number 7

(--) PCI:*(0 at 0:2:0) Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xf4600000/0, 0xe0000000/0, 0xf4680000/0, I/O @ 0x00004000/0
(--) PCI: (0 at 0:2:1) Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller rev 3, Mem @ 0xf4700000/0
(II) Loading /usr/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/extensions//libglx.so
(II) Module glx: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 1.0.0
(==) AIGLX enabled
(==) Exporting typical set of GLX visuals
(II) Loading /usr/lib/xorg/modules/extensions//libdri.so
(II) Module dri: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/extensions//libdri2.so
(II) Module dri2: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 1.0.0
(II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 2.6.99
(II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
	i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G,
	E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ,
	965GM, 965GME/GLE, G33, Q35, Q33,
	Mobile Intel? GM45 Express Chipset,
	Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41
(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
	compiled for 1.5.99.3, module version = 0.1.0
(**) intel(0): Depth 24, (--) framebuffer bpp 32
(==) intel(0): RGB weight 888
(==) intel(0): Default visual is TrueColor
(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GM
(--) intel(0): Chipset: "945GM"
(--) intel(0): Linear framebuffer at 0xE0000000
(--) intel(0): IO registers at addr 0xF4600000
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(==) intel(0): Using EXA for acceleration
(II) intel(0): 2 display pipes available.
(II) intel(0): Output VGA using monitor section Monitor0
(II) intel(0): Output LVDS has no monitor section
(II) intel(0): I2C bus "LVDSDDC_C" initialized.
(II) intel(0): Attempting to determine panel fixed mode.
(II) intel(0): I2C device "LVDSDDC_C:E-EDID segment register" registered at address 0x60.
(II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0.
(II) intel(0): EDID vendor "AUO", prod id 8516
(II) intel(0): found backlight control method /sys/class/backlight/acpi_video0
(II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" initialized.
(II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" registered at address 0x70.
(II) intel(0): I2C bus "SDVOB DDC Bus" initialized.
(II) intel(0): Output TMDS-1 has no monitor section
(II) intel(0): SDVOB: device VID/DID: 02:3C.06, clock range 25.0MHz - 200.0MHz
(II) intel(0): SDVOB: 1 input channel
(II) intel(0): SDVOB: TMDS0 output reported
(II) intel(0): Output TV has no monitor section
(II) intel(0): Current clock rate multiplier: 1
(II) intel(0): EDID for output VGA
(II) intel(0): EDID for output LVDS
(II) intel(0): EDID for output TMDS-1
(II) intel(0): EDID for output TV
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(II) intel(0): Output TMDS-1 disconnected
(II) intel(0): Output TV disconnected
(WW) intel(0): No outputs definitely connected, trying again...
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(II) intel(0): Output TMDS-1 disconnected
(II) intel(0): Output TV disconnected
(WW) intel(0): Unable to find initial modes
(EE) intel(0): No valid modes.
(II) Unloading /usr/lib/xorg/modules//libvgahw.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

-------------- next part --------------
gdm-simple-slave[9304]: DEBUG(+): Enabling debugging
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 1: signum=15 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 15 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 2: signum=2 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 2 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 3: signum=4 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 4 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 4: signum=7 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 7 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 5: signum=8 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 8 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 6: signum=1 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 1 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 7: signum=11 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 11 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 8: signum=6 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 6 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 9: signum=10 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 10 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 10: signum=12 0x804cc00
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Registering for 12 signals
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Registering /org/gnome/DisplayManager/Slave1
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: starting slave
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Starting slave
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Creating proxy for /org/gnome/DisplayManager/Display1
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Got display id: /org/gnome/DisplayManager/Display1
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Adding handler 11: signum=10 0x8053af0
gdm-simple-slave[9304]: DEBUG(+): GdmServer: Starting X server process: /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-JlKXAz/database -nolisten tcp
gdm-simple-slave[9305]: DEBUG(+): GdmServer: Opening logfile for server /var/log/gdm/:0.log
gdm-simple-slave[9304]: DEBUG(+): GdmServer: Started X server process 9305 - waiting for READY
gdm-simple-slave[9304]: DEBUG(+): GdmSimpleSlave: Started X server
gdm-simple-slave[9304]: DEBUG(+): GdmServer: child (pid:9305) done (status:1)
gdm-simple-slave[9304]: DEBUG(+): GdmSimpleSlave: server exited with code 1

gdm-simple-slave[9304]: DEBUG(+): slave finished
gdm-simple-slave[9304]: DEBUG(+): GdmSimpleSlave: Stopping simple_slave
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Stopping slave
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Disconnected from display
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Removing handler 10: signum=11 0x8053af0
gdm-simple-slave[9304]: DEBUG(+): GdmSlave: Stopping slave
gdm-simple-slave[9304]: DEBUG(+): GdmSignalHandler: Finalizing signal handler
gdm-simple-slave[9304]: DEBUG(+): Slave finished

From stickster at gmail.com  Fri Jan  2 16:09:56 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 2 Jan 2009 11:09:56 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <1230834399.13150.11.camel@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
Message-ID: <20090102160956.GA6883@localhost.localdomain>

On Thu, Jan 01, 2009 at 01:26:39PM -0500, Brian Pepple wrote:
> Hi all,
> 
> The top ten FAS account holders who have completed reviewing "Package
> review" components on bugzilla for the year ending December 31st, 2008
> were Parag AN(????), Jason Tibbitts, Mamoru Tasaka, Manuel Wolfshant,
> Kevin Fenzi, Jon Ciesla, Brian Pepple, Dan Hor?k, Patrice Dumas, and
> Marek Mahut.  Below is the number of completed package reviews done
> during 2008.

I'd like to arrange for some sort of reward for the top 10 reviewers.
We could turn that into an annual event.

There was a previous attempt at a "Fedora Award," but it was based on
completely subjective measures whereas this reward would be (1) less
hoopla involved, and (2) based on the completely objective measure of
package reviews, which are both sorely needed in the project and
obviously well-connected to our mission of advancing free software --
in this case, by getting more of it included in the distribution.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/d7720965/attachment.sig>

From kanarip at kanarip.com  Fri Jan  2 16:32:43 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 02 Jan 2009 17:32:43 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102160956.GA6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
Message-ID: <495E41AB.6050606@kanarip.com>

Paul W. Frields wrote:
> On Thu, Jan 01, 2009 at 01:26:39PM -0500, Brian Pepple wrote:
>> Hi all,
>>
>> The top ten FAS account holders who have completed reviewing "Package
>> review" components on bugzilla for the year ending December 31st, 2008
>> were Parag AN(????????????), Jason Tibbitts, Mamoru Tasaka, Manuel Wolfshant,
>> Kevin Fenzi, Jon Ciesla, Brian Pepple, Dan Hor??k, Patrice Dumas, and
>> Marek Mahut.  Below is the number of completed package reviews done
>> during 2008.
> 
> I'd like to arrange for some sort of reward for the top 10 reviewers.

Good idea! I'm #11 ;-)

> We could turn that into an annual event.
> 
> There was a previous attempt at a "Fedora Award," but it was based on
> completely subjective measures whereas this reward would be (1) less
> hoopla involved, and (2) based on the completely objective measure of
> package reviews, which are both sorely needed in the project and
> obviously well-connected to our mission of advancing free software --
> in this case, by getting more of it included in the distribution.
> 

Given the overall sentiment the last time; How are you going to award 
whomever is doing whatever in whichever area doesn't have this kind of 
statistics? I'm afraid the ones that had something to complain about 
with the Fedora Award will find something to complain about this time.

Why not combine whatever statistics we can pull from wherever, have 
these people put their ranking on their personal Wiki page -if they even 
want to-, and elect who's getting the Fedora Award? We could arrange for 
the winners in YearN to not be eligible for YearN+1, too.

Just a thought ;-)

-Jeroen



From mschwendt at gmail.com  Fri Jan  2 16:33:43 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 2 Jan 2009 17:33:43 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102160956.GA6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
Message-ID: <20090102173343.6e2c77c3.mschwendt@gmail.com>

On Fri, 2 Jan 2009 11:09:56 -0500, Paul wrote:

> I'd like to arrange for some sort of reward for the top 10 reviewers.
> We could turn that into an annual event.

What are your plans on avoiding "quantity instead of quality" effects?



From stickster at gmail.com  Fri Jan  2 16:45:50 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 2 Jan 2009 11:45:50 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <495E41AB.6050606@kanarip.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<495E41AB.6050606@kanarip.com>
Message-ID: <20090102164550.GH6883@localhost.localdomain>

On Fri, Jan 02, 2009 at 05:32:43PM +0100, Jeroen van Meeuwen wrote:
> Paul W. Frields wrote:
>> On Thu, Jan 01, 2009 at 01:26:39PM -0500, Brian Pepple wrote:
>>> Hi all,
>>>
>>> The top ten FAS account holders who have completed reviewing "Package
>>> review" components on bugzilla for the year ending December 31st, 2008
>>> were Parag AN(????????????), Jason Tibbitts, Mamoru Tasaka, Manuel Wolfshant,
>>> Kevin Fenzi, Jon Ciesla, Brian Pepple, Dan Hor??k, Patrice Dumas, and
>>> Marek Mahut.  Below is the number of completed package reviews done
>>> during 2008.
>>
>> I'd like to arrange for some sort of reward for the top 10 reviewers.
>
> Good idea! I'm #11 ;-)

We could just as easily make this 5, or 15.  The number isn't that
important to me personally, and the community can help decide the
cutoff point.

>> We could turn that into an annual event.
>>
>> There was a previous attempt at a "Fedora Award," but it was based on
>> completely subjective measures whereas this reward would be (1) less
>> hoopla involved, and (2) based on the completely objective measure of
>> package reviews, which are both sorely needed in the project and
>> obviously well-connected to our mission of advancing free software --
>> in this case, by getting more of it included in the distribution.
>>
>
> Given the overall sentiment the last time; How are you going to award  
> whomever is doing whatever in whichever area doesn't have this kind of  
> statistics? I'm afraid the ones that had something to complain about  
> with the Fedora Award will find something to complain about this time.

There was a lot more to complain about with that award being (1)
decided out of public view, (2) not based on objective criteria, and
(3) publicly trumpeted as an "award" and not a "reward."  I see this
as more of a bounty or a thank-you, not an award that promotes
specific people as somehow having more value to the project than
others.

Any team in Fedora is free to find objective metrics and show
achievement based on those metrics.  And I'd be open to finding a way
to thank people based on their objective achievements.

> Why not combine whatever statistics we can pull from wherever, have  
> these people put their ranking on their personal Wiki page -if they even  
> want to-, and elect who's getting the Fedora Award? We could arrange for  
> the winners in YearN to not be eligible for YearN+1, too.

Elections devalue the point of the reward -- that it's based on an
objective measure and not biased by popularity, group awareness, or
any number of other social considerations.  Those latter
considerations were some of the biggest complaints about having awards
bestowed on specific people -- as opposed to a reward for measurable
work completed.  I think it's worthwhile to recognize people who are
measurably contributing to the fulfillment of our mission, in this
case by getting more software included in Fedora with a token reward.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/19a700f1/attachment.sig>

From stickster at gmail.com  Fri Jan  2 16:47:04 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 2 Jan 2009 11:47:04 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <20090102173343.6e2c77c3.mschwendt@gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
Message-ID: <20090102164704.GI6883@localhost.localdomain>

On Fri, Jan 02, 2009 at 05:33:43PM +0100, Michael Schwendt wrote:
> On Fri, 2 Jan 2009 11:09:56 -0500, Paul wrote:
> 
> > I'd like to arrange for some sort of reward for the top 10 reviewers.
> > We could turn that into an annual event.
> 
> What are your plans on avoiding "quantity instead of quality" effects?

How does the packaging community currently ensure that packages
reviewed are of sufficient quality?

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/d19d5e44/attachment.sig>

From bashton at brennanashton.com  Fri Jan  2 16:51:29 2009
From: bashton at brennanashton.com (Brennan Ashton)
Date: Fri, 2 Jan 2009 10:51:29 -0600
Subject: Package Review Stats for 2008
In-Reply-To: <20090102160956.GA6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
Message-ID: <981da310901020851l17b5fd8dtc8f3de568a70cbb6@mail.gmail.com>

2009/1/2 Paul W. Frields <stickster at gmail.com>:
> On Thu, Jan 01, 2009 at 01:26:39PM -0500, Brian Pepple wrote:
>> Hi all,
>>
>> The top ten FAS account holders who have completed reviewing "Package
>> review" components on bugzilla for the year ending December 31st, 2008
>> were Parag AN(????), Jason Tibbitts, Mamoru Tasaka, Manuel Wolfshant,
>> Kevin Fenzi, Jon Ciesla, Brian Pepple, Dan Hor?k, Patrice Dumas, and
>> Marek Mahut.  Below is the number of completed package reviews done
>> during 2008.
>
> I'd like to arrange for some sort of reward for the top 10 reviewers.
> We could turn that into an annual event.
>
> There was a previous attempt at a "Fedora Award," but it was based on
> completely subjective measures whereas this reward would be (1) less
> hoopla involved, and (2) based on the completely objective measure of
> package reviews, which are both sorely needed in the project and
> obviously well-connected to our mission of advancing free software --
> in this case, by getting more of it included in the distribution.
>
> --
> 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

Right now I have been working on writing a service that monitors
package reviews and triage stats in an attempt to automate these types
of reports with a very customizable TG interface.  I have the back end
running on my server for the last few weeks, and it seems to be
running just fine.  Right now I am working on designing the front end
for this.  Please fill me in on the types of reports people would
like, I hope to have the web interface up up some time in the next
month and a half.

--Brennan Ashton



From bashton at brennanashton.com  Fri Jan  2 16:56:57 2009
From: bashton at brennanashton.com (Brennan Ashton)
Date: Fri, 2 Jan 2009 10:56:57 -0600
Subject: Package Review Stats for 2008
In-Reply-To: <20090102164704.GI6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
Message-ID: <981da310901020856q3ab22f6ah26d03de2322f2872@mail.gmail.com>

2009/1/2 Paul W. Frields <stickster at gmail.com>:
> On Fri, Jan 02, 2009 at 05:33:43PM +0100, Michael Schwendt wrote:
>> On Fri, 2 Jan 2009 11:09:56 -0500, Paul wrote:
>>
>> > I'd like to arrange for some sort of reward for the top 10 reviewers.
>> > We could turn that into an annual event.
>>
>> What are your plans on avoiding "quantity instead of quality" effects?
>
> How does the packaging community currently ensure that packages
> reviewed are of sufficient quality?
>
> --
> 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

My thoughts on this is that as we progress further down the food chain
the reviews are more likely to be in a quantity vs quality battle.  In
fact with these stats when someone all of a sudden jumps up they might
then get a few looks at there reviews.  Another thought would be to
each month or two have the sponsor verify at least one of the bugs of
each of there minions.  As a packager myself I would actually
appreciate this, keeps everyone in the loop on little changes by
packaging committee.

--Brennan Ashton



From bpepple at fedoraproject.org  Fri Jan  2 17:14:57 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Fri, 02 Jan 2009 12:14:57 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <20090102160956.GA6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
Message-ID: <1230916497.5175.19.camel@localhost.localdomain>

On Fri, 2009-01-02 at 11:09 -0500, Paul W. Frields wrote:
> 
> I'd like to arrange for some sort of reward for the top 10 reviewers.
> We could turn that into an annual event.

I think that would be a great idea.

Looking at the stats the top 5 reviewers did something like 44% of all
package reviews.  One of the things I'd like to work on improving in
2009 is to increase the number of reviews done by the folks that did 10
or fewer reviews in 2008, since this is where the bulk of our package
reviewers lie.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/95c2bfb5/attachment.sig>

From pertusus at free.fr  Fri Jan  2 17:31:26 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 2 Jan 2009 18:31:26 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102164704.GI6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
Message-ID: <20090102173126.GF2458@free.fr>

On Fri, Jan 02, 2009 at 11:47:04AM -0500, Paul W. Frields wrote:
> On Fri, Jan 02, 2009 at 05:33:43PM +0100, Michael Schwendt wrote:
> > On Fri, 2 Jan 2009 11:09:56 -0500, Paul wrote:
> > 
> > > I'd like to arrange for some sort of reward for the top 10 reviewers.
> > > We could turn that into an annual event.
> > 
> > What are your plans on avoiding "quantity instead of quality" effects?
> 
> How does the packaging community currently ensure that packages
> reviewed are of sufficient quality?

I don't know if it was what Michael wanted to say, but there are reviews
that are very easy and reviews that are quite hard, counting these the
same may be misleading. However taking that into account requires a 
rating of the submission which is not obvious. 

Another issue is that in some cases commentators may do more work
in the review than the one approving the review request. This is also
not something that is easily measured, though...

In any case, as long as those numbers are not misrepresented as 
the amount of work done through reviews or the like, but only plainly 
as review requests accepted, everything is fine.

--
Pat



From stickster at gmail.com  Fri Jan  2 17:32:34 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 2 Jan 2009 12:32:34 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <1230916497.5175.19.camel@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
Message-ID: <20090102173234.GN6883@localhost.localdomain>

On Fri, Jan 02, 2009 at 12:14:57PM -0500, Brian Pepple wrote:
> On Fri, 2009-01-02 at 11:09 -0500, Paul W. Frields wrote:
> > 
> > I'd like to arrange for some sort of reward for the top 10 reviewers.
> > We could turn that into an annual event.
> 
> I think that would be a great idea.
> 
> Looking at the stats the top 5 reviewers did something like 44% of all
> package reviews.  One of the things I'd like to work on improving in
> 2009 is to increase the number of reviews done by the folks that did 10
> or fewer reviews in 2008, since this is where the bulk of our package
> reviewers lie.

I don't want to short the "long tail" of reviewers, so perhaps we
could arrange for a smaller but still significant reward for people
who did more than "N" reviews.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/b49dd419/attachment.sig>

From mschwendt at gmail.com  Fri Jan  2 17:36:40 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 2 Jan 2009 18:36:40 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102164704.GI6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
Message-ID: <20090102183640.b4557430.mschwendt@gmail.com>

On Fri, 2 Jan 2009 11:47:04 -0500, Paul wrote:

> On Fri, Jan 02, 2009 at 05:33:43PM +0100, Michael Schwendt wrote:
> > On Fri, 2 Jan 2009 11:09:56 -0500, Paul wrote:
> > 
> > > I'd like to arrange for some sort of reward for the top 10 reviewers.
> > > We could turn that into an annual event.
> > 
> > What are your plans on avoiding "quantity instead of quality" effects?
> 
> How does the packaging community currently ensure that packages
> reviewed are of sufficient quality?

Are you aware of any efforts to do re-reviews? ;)

I'm not. With the current system, a single reviewer is enough to approve a
package. That's all. One could argue that the packager (who submits the
review request) is a second reviewer, but often (at least that is my
experience) this is not the case. And afterall, once a package is
approved, the packager can modify it and even violate the review
guidelines as long as nobody notices it. It happens regularly. We've
even had duplicate packages in the collection (using different names).

Once packaging bugs are found, hardly anyone looks up old review tickets
to (1) find out whether an issue was missed during review and to (2)
inform the reviewer about an issue.

Twenty reviews of small packages, which are trivial to review (or even
flawless to begin with because the packager is experienced!), or reviews
of package rename requests, may be less of an achievement than one review
of a big beast with dependencies, which has been waiting in the review
queue for many months and needed lots of work.

-- 
Disclaimer: Comments in my messages in this thread don't refer to any
particular person listed in the "Package Review Stats for 2008".



From stickster at gmail.com  Fri Jan  2 17:49:36 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 2 Jan 2009 12:49:36 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <20090102173126.GF2458@free.fr>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
	<20090102173126.GF2458@free.fr>
Message-ID: <20090102174936.GQ6883@localhost.localdomain>

On Fri, Jan 02, 2009 at 06:31:26PM +0100, Patrice Dumas wrote:
> I don't know if it was what Michael wanted to say, but there are reviews
> that are very easy and reviews that are quite hard, counting these the
> same may be misleading. However taking that into account requires a 
> rating of the submission which is not obvious. 
> 
> Another issue is that in some cases commentators may do more work
> in the review than the one approving the review request. This is also
> not something that is easily measured, though...
> 
> In any case, as long as those numbers are not misrepresented as 
> the amount of work done through reviews or the like, but only plainly 
> as review requests accepted, everything is fine.

Precisely.  This is not about rewarding people for the most work done,
simply for a number of package reviews.  One very detailed package
review might be a lot of work for an experienced package reviewer.
Similarly, one simple package review might just as easily be a lot of
work for an enthusiastic but inexperienced package reviewer.  Both may
be completed equally successfully.

I don't see a way of equitably treating the amount of work done, and
therefore this reward is not based on that measurement.  And the fact
that amounts of work may differ should not stop us from saying thank
you to contributors doing work.

I think concerns of people gaming the system are completely out of
proportion on a risk vs. reward basis.  And if anyone's involved in
Fedora processes purely out of an interest in being materially
rewarded, I would say that person's priorities are somewhat askew!

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/f8e777d9/attachment.sig>

From mschwendt at gmail.com  Fri Jan  2 17:49:41 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 2 Jan 2009 18:49:41 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <1230916497.5175.19.camel@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
Message-ID: <20090102184941.24ea2296.mschwendt@gmail.com>

On Fri, 02 Jan 2009 12:14:57 -0500, Brian wrote:

> One of the things I'd like to work on improving in
> 2009 is to increase the number of reviews done by the folks that did 10
> or fewer reviews in 2008, since this is where the bulk of our package
> reviewers lie.

Better: increase the number of people, who've done 10 or fewer reviews
in 2008.

There are first-time revievers and people, who are afraid of doing
mistakes in reviews and who therefore don't review anything to stay on
the safe side. Encourage them to ask for a review of their review
prior to approval. Reward active contributors with becoming a
"sponsor", with access to the "provenpackagers" group, and with
removing the mandatory review requests of package renaming.



From bpepple at fedoraproject.org  Fri Jan  2 18:02:39 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Fri, 02 Jan 2009 13:02:39 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <20090102173234.GN6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
	<20090102173234.GN6883@localhost.localdomain>
Message-ID: <1230919359.5653.2.camel@localhost.localdomain>

On Fri, 2009-01-02 at 12:32 -0500, Paul W. Frields wrote:
> On Fri, Jan 02, 2009 at 12:14:57PM -0500, Brian Pepple wrote:
> > 
> > Looking at the stats the top 5 reviewers did something like 44% of all
> > package reviews.  One of the things I'd like to work on improving in
> > 2009 is to increase the number of reviews done by the folks that did 10
> > or fewer reviews in 2008, since this is where the bulk of our package
> > reviewers lie.
> 
> I don't want to short the "long tail" of reviewers, so perhaps we
> could arrange for a smaller but still significant reward for people
> who did more than "N" reviews.

Yeah, we briefly discussed in the Package Review sig perhaps having a
random drawing of folks that completed x-number of reviews for a period
of time (something like 3 months), and sending them some form of Fedora
swag.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/82fc4ce2/attachment.sig>

From bpepple at fedoraproject.org  Fri Jan  2 18:09:53 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Fri, 02 Jan 2009 13:09:53 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <20090102183640.b4557430.mschwendt@gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
	<20090102183640.b4557430.mschwendt@gmail.com>
Message-ID: <1230919794.5653.9.camel@localhost.localdomain>

On Fri, 2009-01-02 at 18:36 +0100, Michael Schwendt wrote:

> Twenty reviews of small packages, which are trivial to review (or even
> flawless to begin with because the packager is experienced!), or reviews
> of package rename requests, may be less of an achievement than one review
> of a big beast with dependencies, which has been waiting in the review
> queue for many months and needed lots of work.

Totally agree with you, but I don't think we have any way currently to
differentiate the difficulty between reviews that we could extract into
a report.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/248fad7b/attachment.sig>

From mschwendt at gmail.com  Fri Jan  2 18:14:42 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 2 Jan 2009 19:14:42 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102174936.GQ6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
	<20090102173126.GF2458@free.fr>
	<20090102174936.GQ6883@localhost.localdomain>
Message-ID: <20090102191442.0bd64801.mschwendt@gmail.com>

On Fri, 2 Jan 2009 12:49:36 -0500, Paul wrote:

> On Fri, Jan 02, 2009 at 06:31:26PM +0100, Patrice Dumas wrote:
> > I don't know if it was what Michael wanted to say, but there are reviews
> > that are very easy and reviews that are quite hard, counting these the
> > same may be misleading. However taking that into account requires a 
> > rating of the submission which is not obvious. 
> > 
> > Another issue is that in some cases commentators may do more work
> > in the review than the one approving the review request. This is also
> > not something that is easily measured, though...
> > 
> > In any case, as long as those numbers are not misrepresented as 
> > the amount of work done through reviews or the like, but only plainly 
> > as review requests accepted, everything is fine.
> 
> Precisely.  This is not about rewarding people for the most work done,
> simply for a number of package reviews.  One very detailed package
> review might be a lot of work for an experienced package reviewer.
> Similarly, one simple package review might just as easily be a lot of
> work for an enthusiastic but inexperienced package reviewer.  Both may
> be completed equally successfully.
> 
> I don't see a way of equitably treating the amount of work done, and
> therefore this reward is not based on that measurement.  And the fact
> that amounts of work may differ should not stop us from saying thank
> you to contributors doing work.

Which is what Brian's OP has done. It has listed _all_ the people who've
contributed package reviews in 2008, sorted by number of reviews. Why is
that not enough? Why do you want to apply a system where the two reviewers
from your example above won't see any official "thank you"?

> I think concerns of people gaming the system are completely out of
> proportion on a risk vs. reward basis.

Still: somebody, who [unintentionally] hunts down dozens of tiny Perl
module packages, would enter the Top 10 more likely [and possibly
unintentionally] than somebody who fights a 20K spec file for a pkg
that requires lots of work.



From thomas.moschny at gmail.com  Fri Jan  2 18:34:37 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 2 Jan 2009 19:34:37 +0100
Subject: Package Review Stats for 2008
In-Reply-To: <1230919794.5653.9.camel@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
	<20090102183640.b4557430.mschwendt@gmail.com>
	<1230919794.5653.9.camel@localhost.localdomain>
Message-ID: <a9d183c80901021034o53ff7655qa265eceb349e1146@mail.gmail.com>

2009/1/2 Brian Pepple <bpepple at fedoraproject.org>:
> On Fri, 2009-01-02 at 18:36 +0100, Michael Schwendt wrote:
>
>> Twenty reviews of small packages, which are trivial to review (or even
>> flawless to begin with because the packager is experienced!), or reviews
>> of package rename requests, may be less of an achievement than one review
>> of a big beast with dependencies, which has been waiting in the review
>> queue for many months and needed lots of work.
>
> Totally agree with you, but I don't think we have any way currently to
> differentiate the difficulty between reviews that we could extract into
> a report.

The number of comments the reviewer himself added to the review ticket
could give a hint on how to complicated the review was.

- Thomas



From itamar at ispbrasil.com.br  Fri Jan  2 18:37:46 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Fri, 2 Jan 2009 16:37:46 -0200
Subject: apache dist tag
Message-ID: <d3ceea380901021037t283c7492y56c423034d464ee2@mail.gmail.com>

anyone can explain for me why apache doesn't have the %{?dist} tag ?

Summary: Apache HTTP Server
Name: httpd
Version: 2.2.11
Release: 4

something like this

Release: 4%{?dist}


-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From rdieter at math.unl.edu  Fri Jan  2 19:34:42 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 02 Jan 2009 13:34:42 -0600
Subject: apache dist tag
References: <d3ceea380901021037t283c7492y56c423034d464ee2@mail.gmail.com>
Message-ID: <gjlq68$nkn$1@ger.gmane.org>

Itamar Reis Peixoto wrote:

> anyone can explain for me why apache doesn't have the %{?dist} tag ?

Shot in the dark: because it's maintainer(s) didn't want to use one? 

-- Rex




From valent.turkovic at gmail.com  Fri Jan  2 19:35:12 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 2 Jan 2009 20:35:12 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <20081231023722.GE11236@duckland.org>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>
	<20081231023722.GE11236@duckland.org>
Message-ID: <64b14b300901021135x250b8432o450e06c52c5a5f3a@mail.gmail.com>

2008/12/31 Don Harper <duck at duckland.org>:
> On Tue, Dec 30, 2008 at 07:49:07PM -0600, Jerry Amundson wrote to To Development discussions related to Fedora:
>> On 12/30/08, Conrad Meyer <konrad at tylerc.org> wrote:
>> > On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
>> >> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
>> >> > *Please* stop posting the particular bugs that affect you to the mailing
>> >> > list as if they are higher priority than any other bugs.
>> >> Also I heard a lot of positive feedback when some specific bugs got
>> >> mentioned on this list, if you believe it is now important you can
>> >> choose to ignore that thread.
>> > (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
>> > work. Ignoring spam that is sent to onesself regularly doesn't stop it from
>> > being sent. Please don't contribute to the internet's spam problem. I don't
>> > believe there is any added value in your regular mailings of the list with
>> > your own bugs.
>> Don't be so hasty to judge. They should not become frequent list
>> postings, true, but sometimes they can be a handy "heads up" that can
>> apply to others.
>
> For example, I have started to comment on the bug since I saw it
> mentioned here (my 701 works).
>
> Don

It's is interesing how yours and some other work and some don't work
with SD card reader.

I bought mine over six months ago and has SD card for similar time so
I thought that it could be a hardware error on my part but after I
talked with a friend of mine who bought his eee and 8BG sd card few
weeks ago and has issues with installing Fedora 10 on it (same issues
as described before) I concluded that it probably isn't a hardware bug
on my eee.

That friend has since installed Ubuntu (netbook remix edition) on SD
card and it is working for him. Ununtu-Fedora 1:0 :(

I'm not sure which kernel is ubuntu running and if there are some
custom kernel partches... but if you are interested I can look into
that.

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  Fri Jan  2 19:37:13 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Fri, 2 Jan 2009 20:37:13 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <364d303b0901020133i6c413f66xcffd4b4a2243e937@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<35586fc00812300419g6070f807p5491bfe7e053a947@mail.gmail.com>
	<64b14b300812300918q36810121l32974b8fef9c871a@mail.gmail.com>
	<20081230210941.02be930e@gmx.net>
	<364d303b0901020133i6c413f66xcffd4b4a2243e937@mail.gmail.com>
Message-ID: <64b14b300901021137x667975b5o9e4dd83980e55820@mail.gmail.com>

On Fri, Jan 2, 2009 at 10:33 AM, Christopher Brown
<snecklifter at gmail.com> wrote:
> 2008/12/30 Stefan Grosse <singularitaet at gmx.net>:
>> On Tue, 30 Dec 2008 18:18:04 +0100 "Valent Turkovic"
>>
>> VT> >> this bug [1] makes Fedora 10 unusable on Asus eee 701 because
>> VT> >> onboard 4GB drive is too small for default set of apps and after
>> VT> >> updates drive keeps shrinking to 0MB free :(((
>>
>> VT> I'm using standard Fedora desktop spin (CD Gnome spin). I removed
>> VT> some locals after install and installed some additiona apps that are
>> VT> essential but are missing from desktop spin - like OpenOffice.
>>
>> Dear Ikea, I cannot fit the Billy shelves that I bought into my VW
>> beetle. Please consider this as a major failure in
>> the construction of billy shelves.
>>
>> Happy New Year! ;-)
>>
>> Stefan
>>
>> PS I suppose you haven't been successfull installing XP including OO?
>
> Please take that attitude somewhere else. This list is for the
> development of Fedora. The latest release does not install for Valent
> on a hardware platform that is hugely popular. This should be a cause
> for concern, not ridicule.
>
> --
> Christopher Brown

I'm sorry that I didn't test rawhide on eee and raised this issue before...

ps. I do rest rawhide on my 3 other laptops and report bugs regularly.

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 rakesh.pandit at gmail.com  Fri Jan  2 20:15:56 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sat, 3 Jan 2009 01:45:56 +0530
Subject: Package Review Stats for 2008
In-Reply-To: <a9d183c80901021034o53ff7655qa265eceb349e1146@mail.gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<20090102173343.6e2c77c3.mschwendt@gmail.com>
	<20090102164704.GI6883@localhost.localdomain>
	<20090102183640.b4557430.mschwendt@gmail.com>
	<1230919794.5653.9.camel@localhost.localdomain>
	<a9d183c80901021034o53ff7655qa265eceb349e1146@mail.gmail.com>
Message-ID: <b401d2530901021215r1ab9ef7aicc389a4c3e94d968@mail.gmail.com>

2009/1/3 Thomas Moschny <thomas.moschny at gmail.com>:
> 2009/1/2 Brian Pepple <bpepple at fedoraproject.org>:
>> On Fri, 2009-01-02 at 18:36 +0100, Michael Schwendt wrote:
>>
>>> Twenty reviews of small packages, which are trivial to review (or even
>>> flawless to begin with because the packager is experienced!), or reviews
>>> of package rename requests, may be less of an achievement than one review
>>> of a big beast with dependencies, which has been waiting in the review
>>> queue for many months and needed lots of work.
>>
>> Totally agree with you, but I don't think we have any way currently to
>> differentiate the difficulty between reviews that we could extract into
>> a report.
>
> The number of comments the reviewer himself added to the review ticket
> could give a hint on how to complicated the review was.
>

Sometime reviewer does not take a note of what he has tested [assuming
reporter has already done clever job] unless package fails that test.
So, number of comments are also not a good hint.

-- 
rakesh



From sundaram at fedoraproject.org  Fri Jan  2 20:24:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 03 Jan 2009 01:54:41 +0530
Subject: apache dist tag
In-Reply-To: <gjlq68$nkn$1@ger.gmane.org>
References: <d3ceea380901021037t283c7492y56c423034d464ee2@mail.gmail.com>
	<gjlq68$nkn$1@ger.gmane.org>
Message-ID: <495E7809.1000807@fedoraproject.org>

Rex Dieter wrote:
> Itamar Reis Peixoto wrote:
> 
>> anyone can explain for me why apache doesn't have the %{?dist} tag ?
> 
> Shot in the dark: because it's maintainer(s) didn't want to use one? 

Some additional info: dist tag doesn't make sense for a lot of packages. 
In other cases, maintainers prefer not to use one. Since dist tag is 
completely optional, they have that freedom and they don't have to 
justify their reasons. So other than asking specific maintainers why, 
there is no quick way to find out.

Rahul



From dtimms at iinet.net.au  Fri Jan  2 21:19:58 2009
From: dtimms at iinet.net.au (David Timms)
Date: Sat, 03 Jan 2009 08:19:58 +1100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102184941.24ea2296.mschwendt@gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>	<20090102160956.GA6883@localhost.localdomain>	<1230916497.5175.19.camel@localhost.localdomain>
	<20090102184941.24ea2296.mschwendt@gmail.com>
Message-ID: <495E84FE.6030005@iinet.net.au>

Michael Schwendt wrote:
> There are first-time revievers and people, who are afraid of doing
> mistakes in reviews and who therefore don't review anything to stay on
> the safe side. 
Perhaps we could ask that people with little package activity after 
having there package accepted need to perform at least one review per 
year. This sort of says "I'm keeping up with the guidelines".

> Encourage them to ask for a review of their review
> prior to approval. Reward active contributors with becoming a
I like this bit, even though not really related to the reward process. 
In eg mozilla, changes on the source code require the developer put 
patches on a bug, requests review, reviewer makes comments, to help 
improve patch, developer updates patch. Eventually reviewer may sign 
off, then a superreviewer needs to be found who oversees a major area of 
the source. Only once both r+ and sr+ have provided signoff, are commits 
to cvs allowed.

In Fedora packaging, I'm sure there are people who are experts in 
general areas like java packaging, gnome desktop, multimedia etc, who 
could be called on to check over a package where the main reviewer sees 
is otherwise ready to be accepted.

DaveT.



From dtimms at iinet.net.au  Fri Jan  2 21:21:26 2009
From: dtimms at iinet.net.au (David Timms)
Date: Sat, 03 Jan 2009 08:21:26 +1100
Subject: Package Review Stats for 2008
In-Reply-To: <20090102164550.GH6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>	<20090102160956.GA6883@localhost.localdomain>	<495E41AB.6050606@kanarip.com>
	<20090102164550.GH6883@localhost.localdomain>
Message-ID: <495E8556.2000304@iinet.net.au>

Paul W. Frields wrote:
>>> I'd like to arrange for some sort of reward for the top 10 reviewers.

Since giving away a free copy of Fedora DVD wouldn't probably cut it 
(unless it's nicely labelled packaged or something unique), I was 
thinking - how about access to a paid redhat person for a day to move 
forward the reviewers favourite (most annoying, etc) Fedora bug or RFE ?

DaveT.



From sgrubb at redhat.com  Fri Jan  2 21:22:41 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Fri, 2 Jan 2009 16:22:41 -0500
Subject: Why is X and IPv6 required for autoreconf?
Message-ID: <200901021622.42289.sgrubb@redhat.com>

Hi,

I ran across something weird over the holidays. I wanted to do some work on 
the audit package and put its srpm on a rawhide machine. The changes I made 
required regenerating the configure script by running autoreconf. My rawhide 
machine is a laptop which I have hardened since I travel with it. One of the 
precautions was disabling IPv6. When I rebuild my package, it dies like this:

make  all-recursive
make[1]: Entering directory `/home/sgrubb/working/BUILD/audit-1.7.11'
Making all in lib
make[2]: Entering directory `/home/sgrubb/working/BUILD/audit-1.7.11/lib'
gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../auparse   -fPIC -DPIC -D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT 
gen_actiontabs_h-gen_tables.o -MD -MP -MF .deps/gen_actiontabs_h-gen_tables.Tpo -c -o 
gen_actiontabs_h-gen_tables.o `test -f 'gen_tables.c' || 
echo './'`gen_tables.c
mv -f .deps/gen_actiontabs_h-gen_tables.Tpo .deps/gen_actiontabs_h-gen_tables.Po
/bin/sh ../libtool --tag=CC   --mode=link 
gcc -fPIC -DPIC -D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic   -o 
gen_actiontabs_h gen_actiontabs_h-gen_tables.o  
../libtool: line 821: X--tag=CC: command not found
../libtool: line 854: libtool: ignoring unknown tag : command not found
../libtool: line 821: X--mode=link: command not found
../libtool: line 988: *** Warning: inferring the mode of operation is 
deprecated.: command not found
../libtool: line 989: *** Future versions of Libtool will require --mode=MODE 
be specified.: command not found
../libtool: line 2226: X-fPIC: command not found
../libtool: line 2226: X-DPIC: command not found
../libtool: line 2226: X-D_GNU_SOURCE: command not found
../libtool: line 2226: X-DTABLE_H="actiontab.h": command not found
../libtool: line 2226: X-O2: command not found
../libtool: line 2226: X-g: command not found
../libtool: line 2226: X-pipe: command not found
../libtool: line 2226: X-Wall: command not found
../libtool: line 2226: X-Wp,-D_FORTIFY_SOURCE=2: command not found
../libtool: line 2226: X-fexceptions: command not found
../libtool: line 2226: X-fstack-protector: command not found
../libtool: line 2226: X--param=ssp-buffer-size=4: command not found
../libtool: line 2061: X-m64: command not found
../libtool: line 2061: X-mtune=generic: command not found
../libtool: line 2395: Xgen_actiontabs_h: command not found

Fatal server error:
Server is already active for display 0
	If this server is no longer running, remove /tmp/.X0-lock
	and start again.

../libtool: line 2407: Xgen_actiontabs_h: command not found
../libtool: line 2415: mkdir /.libs: No such file or directory
mkdir: cannot create directory `/.libs': Permission denied
make[2]: *** [gen_actiontabs_h] Error 1


Next I delete the lock like it asks and it now dies like this:


../libtool: line 2226: X-Wp,-D_FORTIFY_SOURCE=2: command not found
../libtool: line 2226: X-fexceptions: command not found
../libtool: line 2226: X-fstack-protector: command not found
../libtool: line 2226: X--param=ssp-buffer-size=4: command not found
../libtool: line 2061: X-m64: command not found
../libtool: line 2061: X-mtune=generic: command not found
../libtool: line 2395: Xgen_actiontabs_h: command not found
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/livestrong:0
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running

Fatal server error:
Cannot establish any listening sockets - Make sure an X server isn't already 
running
../libtool: line 2407: Xgen_actiontabs_h: command not found
../libtool: line 2415: mkdir /.libs: No such file or directory
mkdir: cannot create directory `/.libs': Permission denied


Then I decide, this should not require X at all and reboot to run level 3. 
When I compile now, it tries to start the X server when it gets to this 
point - of course it fails.

-Steve



From ivazqueznet at gmail.com  Sat Jan  3 00:38:41 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Fri, 02 Jan 2009 19:38:41 -0500
Subject: Why is X and IPv6 required for autoreconf?
In-Reply-To: <200901021622.42289.sgrubb@redhat.com>
References: <200901021622.42289.sgrubb@redhat.com>
Message-ID: <1230943121.3590.32.camel@ignacio.lan>

On Fri, 2009-01-02 at 16:22 -0500, Steve Grubb wrote:
> Hi,
> 
> I ran across something weird over the holidays. I wanted to do some work on 
> the audit package and put its srpm on a rawhide machine. The changes I made 
> required regenerating the configure script by running autoreconf. My rawhide 
> machine is a laptop which I have hardened since I travel with it. One of the 
> precautions was disabling IPv6. When I rebuild my package, it dies like this:

> ../libtool: line 821: X--tag=CC: command not found
> ../libtool: line 854: libtool: ignoring unknown tag : command not found
> ../libtool: line 821: X--mode=link: command not found
> ../libtool: line 988: *** Warning: inferring the mode of operation is 
> deprecated.: command not found

I'm not sure about the rest of your issues, but running autoreconf -i -f
should fix these.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/bb15d754/attachment.sig>

From duck at duckland.org  Sat Jan  3 00:43:50 2009
From: duck at duckland.org (Don Harper)
Date: Fri, 2 Jan 2009 18:43:50 -0600
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300901021135x250b8432o450e06c52c5a5f3a@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>
	<20081231023722.GE11236@duckland.org>
	<64b14b300901021135x250b8432o450e06c52c5a5f3a@mail.gmail.com>
Message-ID: <20090103004350.GK11236@duckland.org>

On Fri, Jan 02, 2009 at 08:35:12PM +0100, Valent Turkovic wrote to To Development discussions related to Fedora:
> It's is interesing how yours and some other work and some don't work
> with SD card reader.

I understand that there was a change to the 701 somewhere along the
line.  My serial number starts with 7C.  My model is eeePc4G-W011.

There appears to be some slight differences between the sub-releases.

http://forum.eeeuser.com/viewtopic.php?id=11180
http://forum.eeeuser.com/viewtopic.php?id=13560

Don


> I bought mine over six months ago and has SD card for similar time so
> I thought that it could be a hardware error on my part but after I
> talked with a friend of mine who bought his eee and 8BG sd card few
> weeks ago and has issues with installing Fedora 10 on it (same issues
> as described before) I concluded that it probably isn't a hardware bug
> on my eee.

> That friend has since installed Ubuntu (netbook remix edition) on SD
> card and it is working for him. Ununtu-Fedora 1:0 :(

> I'm not sure which kernel is ubuntu running and if there are some
> custom kernel partches... but if you are interested I can look into
> that.

> Cheers,
> Valent.
-- 
Don Harper, RHCE                                email: duck at duckland.org
Just a systems kinda guy...                      http://www.duckland.org
        OK, the joke is over. Bring back the Constitution.
We may be very busy, we may be very efficient, but we will also be truly
      effective only when we begin with the end in mind. - Stephen Covey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090102/a189fb38/attachment.sig>

From email.ahmedkamal at googlemail.com  Sat Jan  3 01:28:24 2009
From: email.ahmedkamal at googlemail.com (Ahmed Kamal)
Date: Sat, 3 Jan 2009 03:28:24 +0200
Subject: kernel 2.6.27.9-159.fc10.i686 Rescheduling interrupts all the time
Message-ID: <3da3b5b40901021728jb284b87h608face22e904b5d@mail.gmail.com>

Hi,
powertop displays kernel IPI as the top CPU waker.
35.8% (198.7)      <kernel IPI> : Rescheduling interrupts
This does not look right to me. Any idea what might be wrong ?

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/190a5b17/attachment.htm>

From pbrobinson at gmail.com  Sat Jan  3 02:29:36 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 3 Jan 2009 03:29:36 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300901021135x250b8432o450e06c52c5a5f3a@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<6d06ce20812301749m429564c5ja36fd07f250dff6@mail.gmail.com>
	<20081231023722.GE11236@duckland.org>
	<64b14b300901021135x250b8432o450e06c52c5a5f3a@mail.gmail.com>
Message-ID: <5256d0b0901021829r45ed8232oa51376e1c1d75bdf@mail.gmail.com>

>>> >> > *Please* stop posting the particular bugs that affect you to the mailing
>>> >> > list as if they are higher priority than any other bugs.
>>> >> Also I heard a lot of positive feedback when some specific bugs got
>>> >> mentioned on this list, if you believe it is now important you can
>>> >> choose to ignore that thread.
>>> > (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
>>> > work. Ignoring spam that is sent to onesself regularly doesn't stop it from
>>> > being sent. Please don't contribute to the internet's spam problem. I don't
>>> > believe there is any added value in your regular mailings of the list with
>>> > your own bugs.
>>> Don't be so hasty to judge. They should not become frequent list
>>> postings, true, but sometimes they can be a handy "heads up" that can
>>> apply to others.
>>
>> For example, I have started to comment on the bug since I saw it
>> mentioned here (my 701 works).
>>
>> Don
>
> It's is interesing how yours and some other work and some don't work
> with SD card reader.
>
> I bought mine over six months ago and has SD card for similar time so
> I thought that it could be a hardware error on my part but after I
> talked with a friend of mine who bought his eee and 8BG sd card few
> weeks ago and has issues with installing Fedora 10 on it (same issues
> as described before) I concluded that it probably isn't a hardware bug
> on my eee.
>
> That friend has since installed Ubuntu (netbook remix edition) on SD
> card and it is working for him. Ununtu-Fedora 1:0 :(
>
> I'm not sure which kernel is ubuntu running and if there are some
> custom kernel partches... but if you are interested I can look into
> that.

There's a couple of linux-kernel mailing list threads that I posted to
the bug report (see around comments 12-15) that details the issue.
There was a specific patch to fix the issue that was made more generic
but I haven't see it go into a mainline kernel yet but the author of
the patch is there, I was going to ping an email to him but haven't
had time to do so.

Peter



From mmcgrath at redhat.com  Sat Jan  3 05:29:38 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 2 Jan 2009 23:29:38 -0600 (CST)
Subject: Outage Notification - 2009-01-03 04:16 UTC
Message-ID: <alpine.LFD.2.00.0901022323330.12222@laptop.mmcgrath.net>

There is a current unscheduled outage starting at 2009-01-03 UTC, which
will last for an unknown amount of time.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2009-01-03 04:16 UTC'

Affected Services:

Fedora Hosted (Auth)
Mail
Websites (FAS, PackageDB and other applications that use PostgreSQL)
Any services that require authentication that are not shell based or cert
based

Unaffected Services:

Buildsystem
Database (Partial)
CVS / Source Control
DNS
Mirror System
Torrent
Translation Services

Reason for Outage:

The server that hosts db2 is currently down.  The biggest impact of this
is authenticated services are offline.

A technician has been called and services will be restored as soon as
possible.  ETA for tech on site is around 3-4 hours.

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 rawhide at fedoraproject.org  Sat Jan  3 08:46:12 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat,  3 Jan 2009 08:46:12 +0000 (UTC)
Subject: rawhide report: 20090103 changes
Message-ID: <20090103084612.AF3121F8285@releng2.fedora.phx.redhat.com>

Compose started at Sat Jan  3 06:01:03 UTC 2009

New package k12linux-quick-start-guide
        Quick Start Guide for K12Linux Live LTSP Server
Updated Packages:

abcm2ps-5.9.3-1.fc11
--------------------
* Fri Jan  2 17:00:00 2009 Gerard Milmeister <gemi at bluewin.ch> - 5.9.3-1
- new release 5.9.3


anjuta-2.24.1-3.fc11
--------------------
* Sat Jan  3 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 1:2.24.1-3
- Added patch against the Devhelp plugin from GNOME to make it work with the
  new WebKit-based Devhelp >= 0.22. Closes GNOME Bugzilla bug #560311, and Red
  Hat Bugzilla bug #478578.


boinc-client-6.4.5-1.20081217svn.fc11
-------------------------------------
* Wed Dec 17 17:00:00 2008 Milos Jakubicek <xjakub at fi.muni.cz> - 6.4.5-1.20081217svn
- Update to 6.4.5
- Updated boinc-gccflags.patch and boinc-locales.patch
- Not trimming doc/ subdirectory
- Bash completion now provided by the source tarball,
  not packaged as separate sources anymore.
- Supplied example /etc/sysconfig configuration file
- Added BR: docbook2X for autogenerating manpages, not packaged as separate
  sources anymore.


drupal-6.8-1.fc11
-----------------
* Fri Jan  2 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 6.8-1
- Upgrade to 6.8.
- Move files directories from sites to /var/lib/drupal/files/N for selinux reasons, 472642.
- Included script to move files outside of default, use at your own risk, patches welcome.


gnubg-0.9.0.1-4.1.fc11
----------------------
* Fri Jan  2 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 1:0.9.0.1-4.1
- Requires fix.


hunspell-da-1.7.27-1.fc11
-------------------------
* Fri Jan  2 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 1.7.27-1
- latest version


ikiwiki-2.72-1.fc11
-------------------
* Fri Jan  2 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 2.72-1
- Update to 2.72.
- Patch for mtn plugin has been applied upstream.
- Encoding of ikiwiki.vim has been changed to utf-8 upstream.
- Use new W3M_CGI_BIN option in %install.


kde-plasma-runcommand-0.9-1.fc11
--------------------------------
* Fri Jan  2 17:00:00 2009 Jaroslav Reznik <jreznik at redhat.com> 0.9-1
- update to 0.9


kernel-2.6.29-0.9.rc0.git4.fc11
-------------------------------
* Thu Jan  1 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.28-git4


latex2html-2008-1.fc11
----------------------
* Fri Jan  2 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 2008
- update to latex2html-2008
- license changed to GPL
- update japanese support to l2h-2K8-jp20081220
- update cfgcache.pm
- fix BR


libidn-0.6.14-9
---------------
* Mon Dec 29 17:00:00 2008 Kedar Sovani <kedars at marvell.com> 0.6.14-9
- fix the problem with #include_next


liveusb-creator-3.2-1.fc11
--------------------------
* Fri Jan  2 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.2-1
- Fixed some syslinux-related issues (#167)
- Fixed some windows-related logging problems (#337)
- Mitigate a DBus/HAL-related segfault by unmounting upon termination


lm_sensors-3.0.3-1.fc11
-----------------------
* Thu Jan  1 17:00:00 2009 Hans de Goede <j.w.r.degoede at hhs.nl> 3.0.3-1
- New upstream release 3.0.3
- Add a patch to support drivers with an ACPI "bus" (new Asus atk0110 drv)


lpsolve-5.5.0.13-2.fc11
-----------------------
* Fri Jan  2 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 5.5.0.13-2
- use -fPIC on sparc and s390 arches


monotone-0.42-2.fc11
--------------------
* Fri Jan  2 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 0.42-2
- Pack Monotone.pm (in a subpackage). (#450267)

* Fri Jan  2 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 0.42-1
- Updated for 0.42 release.


olpc-utils-0.89-8.fc11
----------------------
* Fri Jan  2 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.89-8
- Add patch to fix spurious python2.5 Requires (#478661)


perl-Locale-Maketext-Lexicon-0.77-1.fc11
----------------------------------------
* Fri Jan  2 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.77-1
- Upstream update.


php-ZendFramework-1.7.2-2.fc11
------------------------------
* Fri Jan  2 17:00:00 2009 Alexander Kahl <akahl at iconmobile.com> - 1.7.2-2
- Bug 477440: Use Vera fonts from Fedora's package

* Fri Jan  2 17:00:00 2009 Alexander Kahl <akahl at iconmobile.com> - 1.7.2-1
- update to 1.7.2
- ZendX documentation doesn't need regeneration anymore, removed deps


proftpd-1.3.2-0.2.rc3.fc11
--------------------------
* Fri Jan  2 17:00:00 2009 Matthias Saou <http://freshrpms.net/> 1.3.2-0.2.rc3
- Update default configuration to have a lit of available modules and more
  example configuration for them.

* Mon Dec 22 17:00:00 2008 Matthias Saou <http://freshrpms.net/> 1.3.2-0.1.rc3
- Update to 1.3.2rc3 (fixes security issue #464127)
- Exclude new pkgconfig file, as we already exclude header files (if someone
  ever needs to rebuild something against this proftpd, just ask and I'll split
  out a devel package... but it seems pretty useless currently).
- Remove no longer needed find-umode_t patch.


psad-2.1.3-1.fc11
-----------------

python-Coherence-0.6.0-1.fc11
-----------------------------
* Fri Jan  2 17:00:00 2009 Matthias Saou <http://freshrpms.net/> 0.6.0-1
- Update to 0.6.0.
- Remove bundled internal louie and require external + trivial sed to use it.


python-libgmail-docs-0.3-7.fc11
-------------------------------
* Fri Jan  2 17:00:00 2009 Nikolay Vladimirov <nikolay at vladimiroff.com> 0.3-7
- Completely restructure the package
- Now using package's own dir instead of python-libmail's
- Fixes BZ#474616


python-sphinx-0.5.1-1.fc11
--------------------------
* Fri Jan  2 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1


qlandkartegt-0.9.3-1.fc11
-------------------------
* Fri Jan  2 17:00:00 2009 Dan Horak <dan[at]danny.cz> 0.9.3-1
- update to 0.9.3


rkhunter-1.3.4-1.fc11
---------------------
* Fri Jan  2 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.3.4-1
- Update to 1.3.4
- Use libdir as tmp dir - bug #456340


vim-perl-support-4.0.1-1.fc11
-----------------------------
* Fri Jan  2 17:00:00 2009 Iain Arnell <iarnell at gmail.com> 4.0.1-1
- Bugfix: Error message in some functions that issue a prompt.

* Fri Jan  2 17:00:00 2009 Iain Arnell <iarnell at gmail.com> 4.0-1
- update to 4.0:
 + Completely new template system. Most menu items now user definable.
 + Plugin split into autoloadable modules (makes Vim startup faster).
 + Submenus for perlcritic severity and verbosity.
 In consequence there are some obsolete files and global variables, and some
 new files and hotkeys.
- fix bug in Perl_Input function


Summary:
Added Packages: 1
Removed Packages: 0
Modified Packages: 26
Broken deps for i386
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	mapnik-0.5.2-0.9.svn738.fc11.i386 requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.x86_64 requires dejavu-fonts
	olpcsound-5.08.92-12.fc11.i386 requires python(abi) = 0:2.5
	olpcsound-5.08.92-12.fc11.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	mapnik-0.5.2-0.9.svn738.fc11.ppc requires dejavu-fonts
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gpodder-0.14.0-1.fc11.noarch requires python-bluez
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapnik-0.5.2-0.9.svn738.fc11.ppc64 requires dejavu-fonts
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From huzaifas at redhat.com  Sat Jan  3 11:38:17 2009
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Sat, 03 Jan 2009 17:08:17 +0530
Subject: Dia does not work without .la files - BZ 475992 
Message-ID: <495F4E29.3050806@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Some time ago there was a long thread regarding libtool files which
started with why dia has .la files.

I was unable to respond to that thread since i was travelling at that
time. In the mean time it seems that someone removed the .la files from
dia according to the fedora packaging policy.

However now dia crashes with an error message, i have done some
preliminary investigation ( Ref BZ 475992  ) and it seems that the
source is looking at the la files to determine the libs.

I am going to talk to upstream to see if this behaviour can be changed.
However my question is in case they dis-agree what are the options do we
have?

Do we bring the .la files back so that dia works ?
- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklfTikACgkQzHDc8tpb2uW5RQCeKCE6UwL9S+UAHSKUi4AvrHBd
QawAoJkU5iAZnqlKs6H1qUrgmpd3eQjz
=+/R4
-----END PGP SIGNATURE-----



From wolfy at nobugconsulting.ro  Sat Jan  3 14:39:38 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 03 Jan 2009 16:39:38 +0200
Subject: Dia does not work without .la files - BZ 475992
In-Reply-To: <495F4E29.3050806@redhat.com>
References: <495F4E29.3050806@redhat.com>
Message-ID: <495F78AA.5040308@nobugconsulting.ro>

Huzaifa Sidhpurwala wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Some time ago there was a long thread regarding libtool files which
> started with why dia has .la files.
>
> I was unable to respond to that thread since i was travelling at that
> time. In the mean time it seems that someone removed the .la files from
> dia according to the fedora packaging policy.
>
> However now dia crashes with an error message, i have done some
> preliminary investigation ( Ref BZ 475992  ) and it seems that the
> source is looking at the la files to determine the libs.
>
> I am going to talk to upstream to see if this behaviour can be changed.
> However my question is in case they dis-agree what are the options do we
> have?
>
> Do we bring the .la files back so that dia works ?
tough choice... what should we select, a working application with .la 
files included, or a nicely-packaged-but-crashing  app ?



From fedora at camperquake.de  Sat Jan  3 14:52:17 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 3 Jan 2009 15:52:17 +0100
Subject: Handling of bitmap fonts in rawhide
Message-ID: <20090103155217.64cd85ee@lain.camperquake.de>

Hi.

Has there been a change regarding bitmap fonts in rawhide lately? I'm
asking because almost all of them seem to have disappeared (although
the packages are still there, of course). xlsfonts just shows a handful
of fixed fonts, but the mincho fonts I used to use in xterm are gone.

Is this intentional or a bug?



From dan at danny.cz  Sat Jan  3 15:07:15 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sat, 03 Jan 2009 16:07:15 +0100
Subject: Dia does not work without .la files - BZ 475992
In-Reply-To: <495F78AA.5040308@nobugconsulting.ro>
References: <495F4E29.3050806@redhat.com> <495F78AA.5040308@nobugconsulting.ro>
Message-ID: <1230995235.3673.10.camel@eagle.danny.cz>

Manuel Wolfshant p??e v So 03. 01. 2009 v 16:39 +0200:
> Huzaifa Sidhpurwala wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Some time ago there was a long thread regarding libtool files which
> > started with why dia has .la files.
> >
> > I was unable to respond to that thread since i was travelling at that
> > time. In the mean time it seems that someone removed the .la files from
> > dia according to the fedora packaging policy.
> >
> > However now dia crashes with an error message, i have done some
> > preliminary investigation ( Ref BZ 475992  ) and it seems that the
> > source is looking at the la files to determine the libs.
> >
> > I am going to talk to upstream to see if this behaviour can be changed.
> > However my question is in case they dis-agree what are the options do we
> > have?
> >
> > Do we bring the .la files back so that dia works ?
> tough choice... what should we select, a working application with .la 
> files included, or a nicely-packaged-but-crashing  app ?
> 

IMHO a working application is always preferred :-) But the plugin
loading mechanism can be checked why it requires the *.la files.


		Dan




From fasteliteprogrammer at yahoo.com  Sat Jan  3 15:07:42 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 07:07:42 -0800 (PST)
Subject: revisor help
Message-ID: <424744.49106.qm@web36504.mail.mud.yahoo.com>

I been try to get revisor to boot and make a live cd can and one show me what step i need to take?


      



From SteveD at redhat.com  Sat Jan  3 15:32:54 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Sat, 03 Jan 2009 10:32:54 -0500
Subject: /etc/hosts re-ordered f10?
Message-ID: <495F8526.4030901@RedHat.com>

Hello,

It seems in F10 the hostname and DNS domain name are now being added
as alias at the end of 127.0.0.1 definition, ala

     127.0.0.1   localhost.localdomain localhost f10.domainname.com f10

which unfortunately breaks kerberos in its keytab lookups.

Here what's happening in kerberos libkrb5.so.3.3 library (which
probably has not changed in while):

First the local hostname is looked up:
    gethostname(localname, MAXHOSTNAMELEN) returns 'f10.domainname.com'
[which is correct]

Next the IP address is looked up:
    hints.ai_family = AF_INET;
    getaddrinfo(localname, 0, &hints, &ai); returns 'ai->ai_addr == 127.0.0.1'
[which is kinda correct since 127.0.0.1 is _a_ local address]

Finally a reverse DNS lookup is done on the ai_addr (127.0.0.1):
    getnameinfo(ai->ai_addr, ai->ai_addrlen, ...) returns 'localhost.localdomain'

[which is not exactly wrong, but the DNS address of f10.domainname.com is
 not 127.0.0.1 its a 192.168.x.x address ]

Now if I simply remove the 'f10.domainname.com' and 'f10' from the line
everything works.

If I convert it back to how it was down in F9:
    127.0.0.1  f10  localhost.localdomain localhost localhost

everything works as well since the DNS lookup will return actual 
hostname 'f10'.

So may questions are:

    - What was the reasoning behind the re-order? Was it needed to fix something
      else?

    - Has anything else been effect this change? If so what was done about it?

    - Who owns /etc/hosts? rpm -qf /etc/hosts returns "is not owned by any package"

tia,

steved.



From bkearney at redhat.com  Sat Jan  3 15:33:19 2009
From: bkearney at redhat.com (Bryan Kearney)
Date: Sat, 03 Jan 2009 10:33:19 -0500
Subject: revisor help
In-Reply-To: <424744.49106.qm@web36504.mail.mud.yahoo.com>
References: <424744.49106.qm@web36504.mail.mud.yahoo.com>
Message-ID: <495F853F.9030703@redhat.com>

Craig wrote:
> I been try to get revisor to boot and make a live cd can and one show me what step i need to take?
I assume you have installed revisor? If so, onto what operating system? 
 From there, can you launch it from Applications -> System Tools?

-- bk



From fasteliteprogrammer at yahoo.com  Sat Jan  3 15:44:19 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 07:44:19 -0800 (PST)
Subject: revisor help
Message-ID: <631325.77935.qm@web36508.mail.mud.yahoo.com>

i use fedora 10

--- On Sat, 1/3/09, Bryan Kearney <bkearney at redhat.com> wrote:

From: Bryan Kearney <bkearney at redhat.com>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Saturday, January 3, 2009, 9:33 AM

Craig wrote:
> I been try to get revisor to boot and make a live cd can and one show me what step i need to take?
I assume you have installed revisor? If so, onto what operating system? From there, can you launch it from Applications -> System Tools?

-- bk

-- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/b08b6877/attachment.htm>

From fasteliteprogrammer at yahoo.com  Sat Jan  3 15:45:37 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 07:45:37 -0800 (PST)
Subject: revisor help
Message-ID: <993426.75723.qm@web36504.mail.mud.yahoo.com>

But how do i make a iso so it will boot up.

--- On Sat, 1/3/09, Bryan Kearney <bkearney at redhat.com> wrote:

From: Bryan Kearney <bkearney at redhat.com>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Saturday, January 3, 2009, 9:33 AM

Craig wrote:
> I been try to get revisor to boot and make a live cd can and one show me what step i need to take?
I assume you have installed revisor? If so, onto what operating system? From there, can you launch it from Applications -> System Tools?

-- bk

-- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/dabfea3f/attachment.htm>

From stickster at gmail.com  Sat Jan  3 15:49:09 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 3 Jan 2009 10:49:09 -0500
Subject: Package Review Stats for 2008
In-Reply-To: <1230919359.5653.2.camel@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
	<20090102173234.GN6883@localhost.localdomain>
	<1230919359.5653.2.camel@localhost.localdomain>
Message-ID: <20090103154909.GA27057@localhost.localdomain>

On Fri, Jan 02, 2009 at 01:02:39PM -0500, Brian Pepple wrote:
> On Fri, 2009-01-02 at 12:32 -0500, Paul W. Frields wrote:
> > On Fri, Jan 02, 2009 at 12:14:57PM -0500, Brian Pepple wrote:
> > > 
> > > Looking at the stats the top 5 reviewers did something like 44% of all
> > > package reviews.  One of the things I'd like to work on improving in
> > > 2009 is to increase the number of reviews done by the folks that did 10
> > > or fewer reviews in 2008, since this is where the bulk of our package
> > > reviewers lie.
> > 
> > I don't want to short the "long tail" of reviewers, so perhaps we
> > could arrange for a smaller but still significant reward for people
> > who did more than "N" reviews.
> 
> Yeah, we briefly discussed in the Package Review sig perhaps having a
> random drawing of folks that completed x-number of reviews for a period
> of time (something like 3 months), and sending them some form of Fedora
> swag.

Perhaps this would be a good compromise -- using randomization to
eliminate bias that favors quantity of simpler reviews.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/7de8b87e/attachment.sig>

From rdieter at math.unl.edu  Sat Jan  3 16:05:51 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 03 Jan 2009 10:05:51 -0600
Subject: Dia does not work without .la files - BZ 475992
References: <495F4E29.3050806@redhat.com> <495F78AA.5040308@nobugconsulting.ro>
	<1230995235.3673.10.camel@eagle.danny.cz>
Message-ID: <gjo2ak$2k0$1@ger.gmane.org>

Dan Hor?k wrote:
 
> IMHO a working application is always preferred :-) But the plugin
> loading mechanism can be checked why it requires the *.la files.

+1.  The problematic .la files that should be avoided are those associated with (linkable) shlibs.  Plugin .la files are mostly harmless.

-- Rex




From mclasen at redhat.com  Sat Jan  3 16:10:07 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 03 Jan 2009 11:10:07 -0500
Subject: Dia does not work without .la files - BZ 475992
In-Reply-To: <1230995235.3673.10.camel@eagle.danny.cz>
References: <495F4E29.3050806@redhat.com> <495F78AA.5040308@nobugconsulting.ro>
	<1230995235.3673.10.camel@eagle.danny.cz>
Message-ID: <1230999007.3425.0.camel@localhost.localdomain>

On Sat, 2009-01-03 at 16:07 +0100, Dan Hor?k wrote:
> Manuel Wolfshant p??e v So 03. 01. 2009 v 16:39 +0200:
> > Huzaifa Sidhpurwala wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Some time ago there was a long thread regarding libtool files which
> > > started with why dia has .la files.
> > >
> > > I was unable to respond to that thread since i was travelling at that
> > > time. In the mean time it seems that someone removed the .la files from
> > > dia according to the fedora packaging policy.
> > >
> > > However now dia crashes with an error message, i have done some
> > > preliminary investigation ( Ref BZ 475992  ) and it seems that the
> > > source is looking at the la files to determine the libs.
> > >
> > > I am going to talk to upstream to see if this behaviour can be changed.
> > > However my question is in case they dis-agree what are the options do we
> > > have?
> > >
> > > Do we bring the .la files back so that dia works ?
> > tough choice... what should we select, a working application with .la 
> > files included, or a nicely-packaged-but-crashing  app ?
> > 
> 
> IMHO a working application is always preferred :-) But the plugin
> loading mechanism can be checked why it requires the *.la files.
> 

There is no deep reason why dias plugin support looks for .la files. It
would be a 3 line patch to make it look for .so instead.



From huzaifas at redhat.com  Sat Jan  3 16:14:43 2009
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Sat, 03 Jan 2009 21:44:43 +0530
Subject: Dia does not work without .la files - BZ 475992
In-Reply-To: <1230999007.3425.0.camel@localhost.localdomain>
References: <495F4E29.3050806@redhat.com>
	<495F78AA.5040308@nobugconsulting.ro>	<1230995235.3673.10.camel@eagle.danny.cz>
	<1230999007.3425.0.camel@localhost.localdomain>
Message-ID: <495F8EF3.2050101@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthias Clasen wrote:
> On Sat, 2009-01-03 at 16:07 +0100, Dan Hor?k wrote:
>> Manuel Wolfshant p??e v So 03. 01. 2009 v 16:39 +0200:
>>> Huzaifa Sidhpurwala wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Some time ago there was a long thread regarding libtool files which
>>>> started with why dia has .la files.
>>>>
>>>> I was unable to respond to that thread since i was travelling at that
>>>> time. In the mean time it seems that someone removed the .la files from
>>>> dia according to the fedora packaging policy.
>>>>
>>>> However now dia crashes with an error message, i have done some
>>>> preliminary investigation ( Ref BZ 475992  ) and it seems that the
>>>> source is looking at the la files to determine the libs.
>>>>
>>>> I am going to talk to upstream to see if this behaviour can be changed.
>>>> However my question is in case they dis-agree what are the options do we
>>>> have?
>>>>
>>>> Do we bring the .la files back so that dia works ?
>>> tough choice... what should we select, a working application with .la 
>>> files included, or a nicely-packaged-but-crashing  app ?
>>>
>> IMHO a working application is always preferred :-) But the plugin
>> loading mechanism can be checked why it requires the *.la files.
>>
> 
> There is no deep reason why dias plugin support looks for .la files. It
> would be a 3 line patch to make it look for .so instead.
> 
Matthias,
I saw your comment on the bugzilla, I am going to apply that patch and
see if that works, Thanks a lot.

- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklfjvMACgkQzHDc8tpb2uX4+QCfbAhy5uzT1E03UxuwE+FL+oHB
xPkAoIhlX6rZVP3MaDxPBJ+SFdDcTo0Z
=eIRJ
-----END PGP SIGNATURE-----



From bruno at wolff.to  Sat Jan  3 16:33:18 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Jan 2009 10:33:18 -0600
Subject: revisor help
In-Reply-To: <424744.49106.qm@web36504.mail.mud.yahoo.com>
References: <424744.49106.qm@web36504.mail.mud.yahoo.com>
Message-ID: <20090103163318.GB1071@wolff.to>

On Sat, Jan 03, 2009 at 07:07:42 -0800,
  Craig <fasteliteprogrammer at yahoo.com> wrote:
> I been try to get revisor to boot and make a live cd can and one show me what step i need to take?

If you want livecd's use livecd-creator instead of revisor. livecd-creator
is included in the livecd-tools package. You probably also want to
install the spin-kickstarts package to get sample kickstart files
to work from.



From frankly3d at fedoraproject.org  Sat Jan  3 16:49:30 2009
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Sat, 03 Jan 2009 16:49:30 +0000
Subject: revisor help
In-Reply-To: <993426.75723.qm@web36504.mail.mud.yahoo.com>
References: <993426.75723.qm@web36504.mail.mud.yahoo.com>
Message-ID: <495F971A.6090100@fedoraproject.org>

Craig wrote:
> But how do i make a iso so it will boot up.
> 

revisor (when installed), should have pulled in livecd-tools,
that is how it will allow livecd creation.

"rpm -q livecd-tools" to check if it is installed.
If not try unistalling, the re-installing revisor.

Frank



From fasteliteprogrammer at yahoo.com  Sat Jan  3 16:55:51 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 08:55:51 -0800 (PST)
Subject: revisor help
Message-ID: <6615.43830.qm@web36507.mail.mud.yahoo.com>

I get this error




[perlsyntax at localhost ~]$ livecd-creator -c ks.cfg
You must run livecd-creator as root
[perlsyntax at localhost ~]$ su
Password: 
[root at localhost perlsyntax]# livecd-creator -c ks.cfg
Traceback (most recent call last):
? File "/usr/bin/livecd-creator", line 136, in <module>
??? sys.exit(main())
? File "/usr/bin/livecd-creator", line 112, in main
??? creator = imgcreate.LiveImageCreator(ks, name, fs_label)
? File "/usr/lib/python2.5/site-packages/imgcreate/live.py", line 47, in __init__
??? LoopImageCreator.__init__(self, *args)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 788, in __init__
??? ImageCreator.__init__(self, ks, name)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 76, in __init__
??? self.__sanity_check()
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 400, in __sanity_check
??? raise CreatorError("No repositories specified")
imgcreate.errors.CreatorError: No repositories specified









--- On Sat, 1/3/09, Frank Murphy <frankly3d at fedoraproject.org> wrote:

From: Frank Murphy <frankly3d at fedoraproject.org>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Saturday, January 3, 2009, 10:49 AM

Craig wrote:
> But how do i make a iso so it will boot up.
> 

revisor (when installed), should have pulled in livecd-tools,
that is how it will allow livecd creation.

"rpm -q livecd-tools" to check if it is installed.
If not try unistalling, the re-installing revisor.

Frank

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/15813150/attachment.htm>

From fasteliteprogrammer at yahoo.com  Sat Jan  3 16:55:56 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 08:55:56 -0800 (PST)
Subject: revisor help
Message-ID: <686262.28332.qm@web36504.mail.mud.yahoo.com>

I get this error




[perlsyntax at localhost ~]$ livecd-creator -c ks.cfg
You must run livecd-creator as root
[perlsyntax at localhost ~]$ su
Password: 
[root at localhost perlsyntax]# livecd-creator -c ks.cfg
Traceback (most recent call last):
? File "/usr/bin/livecd-creator", line 136, in <module>
??? sys.exit(main())
? File "/usr/bin/livecd-creator", line 112, in main
??? creator = imgcreate.LiveImageCreator(ks, name, fs_label)
? File "/usr/lib/python2.5/site-packages/imgcreate/live.py", line 47, in __init__
??? LoopImageCreator.__init__(self, *args)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 788, in __init__
??? ImageCreator.__init__(self, ks, name)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 76, in __init__
??? self.__sanity_check()
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 400, in __sanity_check
??? raise CreatorError("No repositories specified")
imgcreate.errors.CreatorError: No repositories specified









--- On Sat, 1/3/09, Frank Murphy <frankly3d at fedoraproject.org> wrote:

From: Frank Murphy <frankly3d at fedoraproject.org>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Saturday, January 3, 2009, 10:49 AM

Craig wrote:
> But how do i make a iso so it will boot up.
> 

revisor (when installed), should have pulled in livecd-tools,
that is how it will allow livecd creation.

"rpm -q livecd-tools" to check if it is installed.
If not try unistalling, the re-installing revisor.

Frank

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/eab92a72/attachment.htm>

From mdehaan at redhat.com  Sat Jan  3 17:14:37 2009
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sat, 03 Jan 2009 12:14:37 -0500
Subject: revisor help
In-Reply-To: <686262.28332.qm@web36504.mail.mud.yahoo.com>
References: <686262.28332.qm@web36504.mail.mud.yahoo.com>
Message-ID: <495F9CFD.5050302@redhat.com>

Craig wrote:
> I get this error ...
>

Craig,

Revisor has a mailing list at 
http://lists.fedorahosted.org/mailman/listinfo/revisor-users -- I'd 
suggest you ask that question there instead.

--Michael




From tmz at pobox.com  Sat Jan  3 17:19:59 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 3 Jan 2009 12:19:59 -0500
Subject: Heads up: git-1.6.1-1.fc11 moves most git-* commands out of PATH
Message-ID: <20090103171959.GA12325@inocybe.teonanacatl.org>

Greetings,

Git-1.6.1 is headed to rawhide and among the changes is that we now
follow upstream defaults and install the majority of git-* commands in
%{_libexecdir}/git-core/ instead of %{_bindir}.  If you have scripts
that call git-* binaries, you should either change them to use the
"git foo" style or add %{_libexecdir}/git-core to PATH.  Git provides
a convenient method to do this:

    PATH=$(git --exec-path):$PATH

This update and path change is only going to rawhide.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't mind arguing with myself. It's when I lose that it bothers me.
    -- Richard Powers

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/44641407/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Jan  3 17:25:48 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 03 Jan 2009 18:25:48 +0100
Subject: Handling of bitmap fonts in rawhide
In-Reply-To: <20090103155217.64cd85ee@lain.camperquake.de>
References: <20090103155217.64cd85ee@lain.camperquake.de>
Message-ID: <1231003548.3539.4.camel@arekh.okg>

Le samedi 03 janvier 2009 ? 15:52 +0100, Ralf Ertzinger a ?crit :

> Has there been a change regarding bitmap fonts in rawhide lately?

Not that I know of. No one cares enough about them to write bitmap font
packaging guidelines, and fewer and fewer of them are installed by
default, but there's no specific drive to remove them either.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/3216d164/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Jan  3 17:35:52 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 03 Jan 2009 18:35:52 +0100
Subject: Getting started with Rawhide
In-Reply-To: <20090101003357.GA24966@wolff.to>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
Message-ID: <1231004152.3539.6.camel@arekh.okg>

Le mercredi 31 d?cembre 2008 ? 18:33 -0600, Bruno Wolff III a ?crit :
> On Wed, Dec 31, 2008 at 15:37:47 -0700,

> > It appears that glibc in Rawhide (2.8.90) is older than the glibc in
> > the initial F10 release (2.9).  Am I seeing that correctly?  If so,
> > should I downgrade, or wait for Rawhide to catch up?
> 
> There are a few other things that have higher versions in F10. That caused
> me a bit of grief. The dejavu fonts change also caused some problems.

Could you please expand? The update path is supposed to work, and I
notified every single packager that needed to change its deps when the
packages were re-organised.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/4e6774f9/attachment.sig>

From bruno at wolff.to  Sat Jan  3 17:45:49 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Jan 2009 11:45:49 -0600
Subject: Getting started with Rawhide
In-Reply-To: <1231004152.3539.6.camel@arekh.okg>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
	<1231004152.3539.6.camel@arekh.okg>
Message-ID: <20090103174549.GB6656@wolff.to>

On Sat, Jan 03, 2009 at 18:35:52 +0100,
  Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> Le mercredi 31 d?cembre 2008 ? 18:33 -0600, Bruno Wolff III a ?crit :
> > On Wed, Dec 31, 2008 at 15:37:47 -0700,
> 
> > > It appears that glibc in Rawhide (2.8.90) is older than the glibc in
> > > the initial F10 release (2.9).  Am I seeing that correctly?  If so,
> > > should I downgrade, or wait for Rawhide to catch up?
> > 
> > There are a few other things that have higher versions in F10. That caused
> > me a bit of grief. The dejavu fonts change also caused some problems.
> 
> Could you please expand? The update path is supposed to work, and I
> notified every single packager that needed to change its deps when the
> packages were re-organised.

Well it doesn't. Updates have been pushed for a few packages in F10 updates
and/or updates testing that have high NVRs than the corresponding rawhide
NVRs. Yum won't update those packages. Normally that wouldn't be a big deal
as skip broken would skip these and they would show up as orphans after the
update and you could manually downgrade them. But because so much stuff
depends on python the failure is complicated enough that skip broken
can't deal with it effectively. (In my case there was an infinite loop
where it tried to remove something, but that something was brought back
in by a dependency, resulting in the same failing package set continually
being retried.) If you uninstall a few key packages, you can get the update
to work. Once the vast majority of packages have been updated, you can
use package-cleanup --orphans to find problem packages and deal with them.
And then you can probably also reinstall some or all of what you have to
remove to get the update to work.



From nicolas.mailhot at laposte.net  Sat Jan  3 17:59:49 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 03 Jan 2009 18:59:49 +0100
Subject: Getting started with Rawhide
In-Reply-To: <20090103174549.GB6656@wolff.to>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to> <1231004152.3539.6.camel@arekh.okg>
	<20090103174549.GB6656@wolff.to>
Message-ID: <1231005589.21702.2.camel@arekh.okg>

Le samedi 03 janvier 2009 ? 11:45 -0600, Bruno Wolff III a ?crit :
> On Sat, Jan 03, 2009 at 18:35:52 +0100,
>   Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> > Le mercredi 31 d?cembre 2008 ? 18:33 -0600, Bruno Wolff III a ?crit :
> > > On Wed, Dec 31, 2008 at 15:37:47 -0700,
> > 
> > > > It appears that glibc in Rawhide (2.8.90) is older than the glibc in
> > > > the initial F10 release (2.9).  Am I seeing that correctly?  If so,
> > > > should I downgrade, or wait for Rawhide to catch up?
> > > 
> > > There are a few other things that have higher versions in F10. That caused
> > > me a bit of grief. The dejavu fonts change also caused some problems.
> > 
> > Could you please expand? The update path is supposed to work, and I
> > notified every single packager that needed to change its deps when the
> > packages were re-organised.
> 
> Well it doesn't. Updates have been pushed for a few packages in F10 updates
> and/or updates testing that have high NVRs than the corresponding rawhide
> NVRs.

Well, I should have been clearer: which dejavu fonts problems did you
encounter?

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/c05e6d6b/attachment.sig>

From bruno at wolff.to  Sat Jan  3 18:02:04 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Jan 2009 12:02:04 -0600
Subject: Getting started with Rawhide
In-Reply-To: <20090103174549.GB6656@wolff.to>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
	<1231004152.3539.6.camel@arekh.okg>
	<20090103174549.GB6656@wolff.to>
Message-ID: <20090103180204.GC6656@wolff.to>

On Sat, Jan 03, 2009 at 11:45:49 -0600,
  Bruno Wolff III <bruno at wolff.to> wrote:
> being retried.) If you uninstall a few key packages, you can get the update
> to work. Once the vast majority of packages have been updated, you can
> use package-cleanup --orphans to find problem packages and deal with them.
> And then you can probably also reinstall some or all of what you have to
> remove to get the update to work.

I submitted an RFE (478697) to yum-utils to provide a way to find those
packages ahead of an update.



From bruno at wolff.to  Sat Jan  3 18:04:55 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 3 Jan 2009 12:04:55 -0600
Subject: Getting started with Rawhide
In-Reply-To: <1231005589.21702.2.camel@arekh.okg>
References: <870180fe0812311437y72912f08p9ab6b939abcdbb95@mail.gmail.com>
	<20090101003357.GA24966@wolff.to>
	<1231004152.3539.6.camel@arekh.okg>
	<20090103174549.GB6656@wolff.to>
	<1231005589.21702.2.camel@arekh.okg>
Message-ID: <20090103180455.GD6656@wolff.to>

On Sat, Jan 03, 2009 at 18:59:49 +0100,
  Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> Well, I should have been clearer: which dejavu fonts problems did you
> encounter?

Mostly games. I think today's update covers the last of the games I was
interested in for the games spin. (I am still working on getting the
update though.) So you probably won't have install problems due to that.
However, I was using those fonts for Firefox, so there was some extra grief.
(Especially since I am sharing /home between my F10 and F11 installs.)



From bkearney at redhat.com  Sat Jan  3 19:17:01 2009
From: bkearney at redhat.com (Bryan Kearney)
Date: Sat, 03 Jan 2009 14:17:01 -0500
Subject: revisor help
In-Reply-To: <686262.28332.qm@web36504.mail.mud.yahoo.com>
References: <686262.28332.qm@web36504.mail.mud.yahoo.com>
Message-ID: <495FB9AD.9040906@redhat.com>

Craig wrote:
> I get this error
What is the contents of your kickstart file?

-- bk



From fasteliteprogrammer at yahoo.com  Sat Jan  3 20:08:51 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 12:08:51 -0800 (PST)
Subject: revisor help
Message-ID: <570559.70840.qm@web36501.mail.mud.yahoo.com>

What you mean and where can i get that?

--- On Sat, 1/3/09, Bryan Kearney <bkearney at redhat.com> wrote:

From: Bryan Kearney <bkearney at redhat.com>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Saturday, January 3, 2009, 1:17 PM

Craig wrote:
> I get this error
What is the contents of your kickstart file?

-- bk

-- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/bcf53b38/attachment.htm>

From fedora at camperquake.de  Sat Jan  3 22:00:09 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 3 Jan 2009 23:00:09 +0100
Subject: Handling of bitmap fonts in rawhide
In-Reply-To: <1231003548.3539.4.camel@arekh.okg>
References: <20090103155217.64cd85ee@lain.camperquake.de>
	<1231003548.3539.4.camel@arekh.okg>
Message-ID: <20090103230009.2b486c55@lain.camperquake.de>

Hi.

On Sat, 03 Jan 2009 18:25:48 +0100, Nicolas Mailhot wrote

> Not that I know of. No one cares enough about them to write bitmap
> font packaging guidelines, and fewer and fewer of them are installed
> by default, but there's no specific drive to remove them either.

That's good to hear. Where should I file a bug about this?



From kevin.kofler at chello.at  Sat Jan  3 23:16:28 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Jan 2009 00:16:28 +0100
Subject: Package Review Stats for 2008
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
	<20090102173234.GN6883@localhost.localdomain>
	<1230919359.5653.2.camel@localhost.localdomain>
	<20090103154909.GA27057@localhost.localdomain>
Message-ID: <gjorkc$l77$2@ger.gmane.org>

Paul W. Frields wrote:
> Perhaps this would be a good compromise -- using randomization to
> eliminate bias that favors quantity of simpler reviews.

But it also eliminates the incentive to continue doing reviews in that year
once you hit the magical threshold 'N'.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan  3 23:21:22 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Jan 2009 00:21:22 +0100
Subject: revisor help
References: <570559.70840.qm@web36501.mail.mud.yahoo.com>
Message-ID: <gjorti$l77$3@ger.gmane.org>

Craig wrote:
> What you mean and where can i get that?

Please read the documentation of the tools you want to use instead of
pestering the mailing list with stupid questions.

Or try using Revisor instead of using livecd-creator directly. What you're
trying to use is not Revisor, it's the command-line livecd-creator tool
(which definitely expects you to know what you're doing). Revisor can be
found in your menu, it's a graphical application. But even when using
Revisor, reading the documentation is definitely a good idea!

        Kevin Kofler



From fasteliteprogrammer at yahoo.com  Sun Jan  4 00:57:02 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sat, 3 Jan 2009 16:57:02 -0800 (PST)
Subject: revisor help
Message-ID: <84811.85040.qm@web36506.mail.mud.yahoo.com>

That what i did was read the doc



--- On Sat, 1/3/09, Kevin Kofler <kevin.kofler at chello.at> wrote:

From: Kevin Kofler <kevin.kofler at chello.at>
Subject: Re: revisor help
To: fedora-devel-list at redhat.com
Date: Saturday, January 3, 2009, 5:21 PM

Craig wrote:
> What you mean and where can i get that?

Please read the documentation of the tools you want to use instead of
pestering the mailing list with stupid questions.

Or try using Revisor instead of using livecd-creator directly. What you're
trying to use is not Revisor, it's the command-line livecd-creator tool
(which definitely expects you to know what you're doing). Revisor can be
found in your menu, it's a graphical application. But even when using
Revisor, reading the documentation is definitely a good idea!

? ? ? ? Kevin Kofler

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/531fdfb8/attachment.htm>

From erikina at gmail.com  Sun Jan  4 01:24:50 2009
From: erikina at gmail.com (Eric Springer)
Date: Sun, 4 Jan 2009 11:24:50 +1000
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
Message-ID: <ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>

On Thu, Jan 1, 2009 at 8:19 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> On Wed, Dec 31, 2008 at 2:14 AM, Conrad Meyer <konrad at tylerc.org> wrote:
>
> Are you being intentionally ignorant or are you new to this list?

Oh screw you. You come to the *development* list and say crap like
this to contributing and active member?

Beside repeatably avoiding taking the proper channels to get issues
fixed, you can't even be polite.

Let me take a quick look at your contributions:

08-12-30 -- Posting about a bug that affects you (on devel)
08-12-29 -- Asking for tips on using your eee (on devel)
08-11-30 -- Asking a wiki question (on devel)
08-11-17 -- Asking about WEP keys and network manager (on devel)
08-07-14 -- Asking people to look at a sound issue for you (on devel)
08-06-14 -- Posting about 4 feature requests bugs you want (on devel)
08-06-12 -- Posting about a selinux bug that affects you (on devel)
08-03-30 -- Posting about a networkmanager bug that affects you (on devel)
08-06-09 -- Asking if Red Hat is dropping support for fedora (on devel)
08-05-27 -- Asking about fedoratv (on devel)
08-05-27 -- Reporting flash doesn't work (on devel)
08-05-27 -- Asking about webcam support (on devel)
08-05-27 -- Asking how to disable a feature in swfdec (on devel)


The development mailing list isn't for:
* The bugs that affect you
* Asking developers for help
* Being a jerk

If you don't understand that, you shouldn't be here. Thanks.




> have heard numerous times that priority setting is being ignored and
> it doesn't matter what you set it to.

Considering every issue you have ends up on the development mailing
list, I doubt *you* understand priority.


> Also I heard a lot of positive feedback when some specific bugs got
> mentioned on this list, if you believe it is now important you can
> choose to ignore that thread.

Look carefully. They generally are in the format "Watch out for this
bug, we're fixing it" or "Anyone knows how to help me fix.." or
something similarly constructive. However if Flash 10 isn't working
for you, use bugzilla or a help forum.



From wolfy at nobugconsulting.ro  Sun Jan  4 01:52:46 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 04 Jan 2009 03:52:46 +0200
Subject: Package Review Stats for 2008
In-Reply-To: <gjorkc$l77$2@ger.gmane.org>
References: <1230834399.13150.11.camel@localhost.localdomain>	<20090102160956.GA6883@localhost.localdomain>	<1230916497.5175.19.camel@localhost.localdomain>	<20090102173234.GN6883@localhost.localdomain>	<1230919359.5653.2.camel@localhost.localdomain>	<20090103154909.GA27057@localhost.localdomain>
	<gjorkc$l77$2@ger.gmane.org>
Message-ID: <4960166E.2090205@nobugconsulting.ro>

On 01/04/2009 01:16 AM, Kevin Kofler wrote:
> Paul W. Frields wrote:
>   
>> Perhaps this would be a good compromise -- using randomization to
>> eliminate bias that favors quantity of simpler reviews.
>>     
>
> But it also eliminates the incentive to continue doing reviews in that year
> once you hit the magical threshold 'N'.
>   
Come on, Kevin, if someone does reviews just for the 
"award"/"reward"/"prize"/whatever-else-we-call-it, [s]he should not be 
here in the first place. We do it for the community, not for a personal 
pride. You've reached the threshold ? Fine. The community thanks you. 
Now, go on.




From vonbrand at inf.utfsm.cl  Sun Jan  4 01:55:03 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 03 Jan 2009 22:55:03 -0300
Subject: Package Review Stats for 2008
In-Reply-To: <gjorkc$l77$2@ger.gmane.org>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<1230916497.5175.19.camel@localhost.localdomain>
	<20090102173234.GN6883@localhost.localdomain>
	<1230919359.5653.2.camel@localhost.localdomain>
	<20090103154909.GA27057@localhost.localdomain>
	<gjorkc$l77$2@ger.gmane.org>
Message-ID: <200901040155.n041t35w013045@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Paul W. Frields wrote:
> > Perhaps this would be a good compromise -- using randomization to
> > eliminate bias that favors quantity of simpler reviews.
> 
> But it also eliminates the incentive to continue doing reviews in that year
> once you hit the magical threshold 'N'.

Don't use a threshold then, just give each reviewer one ticket in the
lottery for each package reviewed (but make sure nobody gets more than one
prize). Or only give out tickets as above to anybody who did more than
N. Or give out max(0, reviews - N + 1) tickets.

There are many variations possible (give an extra ticket in the lottery to
new reviewers, give extra tickets for reviewing a package that person
hasn't reviewed before, give extra tickets for packages for which that
person is the lone reviewer, ...)
-- 
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 jspaleta at gmail.com  Sun Jan  4 01:58:20 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 3 Jan 2009 16:58:20 -0900
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
	<ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
Message-ID: <604aa7910901031758n78cdc79bp6d9b2bf24e761826@mail.gmail.com>

On Sat, Jan 3, 2009 at 4:24 PM, Eric Springer <erikina at gmail.com> wrote:
> Oh screw you. You come to the *development* list and say crap like
> this to contributing and active member?

Please, let's not ratchet up the emotion over Valent's abuse of this
list further.  I realize he's being condescending. I've a whole gmail
label category for all the unsent draft responses to all sorts of
people I've written which start with "screw you" penned in anger to
exactly what you are finding irritating. I completely understand, it
feels really good to write that sort of thing..i think the word is
cathartic . But actually sending emotive posts doesn't necessarily
help solve the problem in the long run.

-jef"Has learned to always eat something before writing an email. Low
blood sugar induced rage does not mix with communication."spaleta



From jspaleta at gmail.com  Sun Jan  4 02:12:20 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 3 Jan 2009 17:12:20 -0900
Subject: Package Review Stats for 2008
In-Reply-To: <20090102164550.GH6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<495E41AB.6050606@kanarip.com>
	<20090102164550.GH6883@localhost.localdomain>
Message-ID: <604aa7910901031812h13fe02afoa9bf2d9a766e59e3@mail.gmail.com>

2009/1/2 Paul W. Frields <stickster at gmail.com>:
> We could just as easily make this 5, or 15.  The number isn't that
> important to me personally, and the community can help decide the
> cutoff point.

Do a histogram, fit a exponential distribution to the histogram, maybe
a Poisson distribution... the distribution of "rare events".  Define
the number of awards on the variance,mean,median, or some complication
combination there of.

This however will not solve the qauntity over quality problem.


-jef"You know what would be fun? A histogram of number of reviews
weighted by the number of non-whitespace characters in the specfile or
weighted by the total size of the sources associated with the
package"spaleta



From robert at fedoraproject.org  Sun Jan  4 02:20:56 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 4 Jan 2009 03:20:56 +0100
Subject: Why is X and IPv6 required for autoreconf?
In-Reply-To: <200901021622.42289.sgrubb@redhat.com>
References: <200901021622.42289.sgrubb@redhat.com>
Message-ID: <20090104022056.GA5011@hurricane.linuxnetz.de>

Hello Steve,

On Fri, 02 Jan 2009, Steve Grubb wrote:
> /bin/sh ../libtool --tag=CC   --mode=link 
> gcc -fPIC -DPIC -D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic   -o 
> gen_actiontabs_h gen_actiontabs_h-gen_tables.o  
> ../libtool: line 821: X--tag=CC: command not found

you need to run "libtoolize" in e.g. %prep because of the bigger libtool
bump vom 1.5 to 2.x some time ago. That will solve your issue completely.
Ask yourself, why you've written/done insane libtool stuff in the past ;)


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/489c0a2b/attachment.sig>

From erikina at gmail.com  Sun Jan  4 03:05:32 2009
From: erikina at gmail.com (Eric Springer)
Date: Sun, 4 Jan 2009 13:05:32 +1000
Subject: Package Review Stats for 2008
In-Reply-To: <20090102160956.GA6883@localhost.localdomain>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
Message-ID: <ce9c609e0901031905s60393f6fh82cfa942e228c6b5@mail.gmail.com>

2009/1/3 Paul W. Frields <stickster at gmail.com>:
> I'd like to arrange for some sort of reward for the top 10 reviewers.
> We could turn that into an annual event.


Perhaps a silly idea, but how about a lottery? One ticket per package
(or unit of work, if you can figure that out) and randomly give X
prizes. I think it'll be more accessible for everyone, a bit more fun
and a little less competitive.



From lyos.gemininorezel at gmail.com  Sun Jan  4 03:16:50 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Sat, 03 Jan 2009 22:16:50 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <981da310901010803r2608c24eyd94f3067ee6b64f7@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>
	<495884BC.7040800@redhat.com>	<49588D9D.5020303@gmail.com>
	<495A18D5.3030602@nobugconsulting.ro>	<495B0362.6030906@gmail.com>
	<981da310901010803r2608c24eyd94f3067ee6b64f7@mail.gmail.com>
Message-ID: <49602A22.9020602@gmail.com>

Brennan Ashton wrote:
>
> You can avoid some of that with LVM.   And while I DO NOT recommend
> it, with some tweaking you could get all of this on one partition, but
> I guess I dont get your point. 

Sure you can... theoretically you can get all of them on one physical 
partition.

Theoretically you can put swap on a file in the root partition and put 
/boot on the /root partition.

That theory doesn't make it a good idea... in fact... you'd have to be a 
moron to do such a thing.

> I tend to just ignore my physical partition lay out (various dual boots over time have left it in
> shambles MS will only look in certain places), and just let LVM do its
> magic. With just three partitions I have XP, F8, F9, F10.
>
>   

Yowza... hope you don't keep any valuable data on those partitions.

Lyos Gemini Norezel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090103/9f967874/attachment.htm>

From lyos.gemininorezel at gmail.com  Sun Jan  4 03:19:42 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Sat, 03 Jan 2009 22:19:42 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495C9A7F.9080300@redhat.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>	<49588D9D.5020303@gmail.com>	<495A18D5.3030602@nobugconsulting.ro>	<495B0362.6030906@gmail.com>
	<495C9A7F.9080300@redhat.com>
Message-ID: <49602ACE.6050506@gmail.com>

Casey Dahlin wrote:
> And? The numbers are free. I can see not wanting to have lots of 
> partitions to distinguish from, but this use case doesn't strike me as 
> killer.
> --CJD

Sure... until you have to remember, under stress, which partition your 
data's on.
Lyos Gemini Norezel



From rakesh.pandit at gmail.com  Sun Jan  4 04:00:47 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 4 Jan 2009 09:30:47 +0530
Subject: Package Review Stats for 2008
In-Reply-To: <ce9c609e0901031905s60393f6fh82cfa942e228c6b5@mail.gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<ce9c609e0901031905s60393f6fh82cfa942e228c6b5@mail.gmail.com>
Message-ID: <b401d2530901032000qca8c90fxdc5423d6549789cb@mail.gmail.com>

With so many ideas coming up, I would have rather liked a program
taking dictionary (Key: <Reviewer Name>, Value:
<number_of_reviews_done>) and number of awards as input  and selected
candidates as output based on different algorithms proposed. I am very
bad at probability, in case someone can take up the problem and
suggest even a pseudo code , it would help.

Report generating script is already providing a dictionary.

-- 
rakesh



From jspaleta at gmail.com  Sun Jan  4 04:13:40 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 3 Jan 2009 19:13:40 -0900
Subject: Package Review Stats for 2008
In-Reply-To: <ce9c609e0901031905s60393f6fh82cfa942e228c6b5@mail.gmail.com>
References: <1230834399.13150.11.camel@localhost.localdomain>
	<20090102160956.GA6883@localhost.localdomain>
	<ce9c609e0901031905s60393f6fh82cfa942e228c6b5@mail.gmail.com>
Message-ID: <604aa7910901032013g12c396fah35675ecbdc032202@mail.gmail.com>

On Sat, Jan 3, 2009 at 6:05 PM, Eric Springer <erikina at gmail.com> wrote:
> Perhaps a silly idea, but how about a lottery? One ticket per package
> (or unit of work, if you can figure that out) and randomly give X
> prizes. I think it'll be more accessible for everyone, a bit more fun
> and a little less competitive.


I think your right.  Anyway we cut it, awards are somewhat arbitrary
since we aren't going to get the perfect metric of what the workload
really looks like. I love plotting things, just because I love data,
but I don't necessarily like personalizing the data.  A lottery
encodes the arbitrariness into the "award" process to some extent.

Taken this idea further, we could invest in one of those big air
chambers like you see on cheesy gameshows and fill it with little
scraps of paper with a reviewers name, one scrap of paper is a ticket
in the lottery. Paul walks into the chamber, the air turns on and he
randomly grabs X number of flying scraps of paper. All of this on
video of course.

-jef"Is it wrong that I think of the packaging process as akin to the
old Double Dare obstacle course, 'the messiest minute on television'
?"spaleta



From abu_hurayrah at hidayahonline.org  Sun Jan  4 04:44:55 2009
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Sun, 04 Jan 2009 06:44:55 +0200
Subject: Ekiga dependencies
Message-ID: <1231044296.10626.82.camel@localhost.localdomain>

After installing Fedora 10 from the LiveCD, I wanted to install Ekiga as
well.  I discovered that the dependencies for Ekiga were:

      * libopal.so.3.4.2
              * provided by opal
      * libpt.so.2.4.2
              * provided by ptlib
                
Being file dependencies, yum had to pull in the the files information
from the repositories which took much longer on my slower connection
(512k right now - sympathy cards welcome).

I recall reading before (where, I do not remember) that package
dependencies are better than file ones because fewer repo files are
needed to provide an update.

So, can someone with more knowledge on the issue explain this to me?
Either way, I thought I'd mention it here, hopefully someone with more
knowledge can clarify it to me.



From jspaleta at gmail.com  Sun Jan  4 05:08:09 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 3 Jan 2009 20:08:09 -0900
Subject: Ekiga dependencies
In-Reply-To: <1231044296.10626.82.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
Message-ID: <604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>

On Sat, Jan 3, 2009 at 7:44 PM, Basil Mohamed Gohar
> Being file dependencies, yum had to pull in the the files information
> from the repositories which took much longer on my slower connection
> (512k right now - sympathy cards welcome).


I think you are a little mistaken.  Those are library dependencies not
file dependancies... file dependencies should have a fully qualified
path associated with them.

And when i do  yum install ekiga  after doing a yum clean metadata  on
my f10 system I do not have the filelist metadata pulled.  I just pull
the primary_db no filelist information is required.

-jef



From abu_hurayrah at hidayahonline.org  Sun Jan  4 05:13:27 2009
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Sun, 04 Jan 2009 07:13:27 +0200
Subject: Ekiga dependencies
In-Reply-To: <604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
Message-ID: <1231046007.10626.84.camel@localhost.localdomain>

On Sat, 2009-01-03 at 20:08 -0900, Jeff Spaleta wrote:

> I think you are a little mistaken.  Those are library dependencies not
> file dependancies... file dependencies should have a fully qualified
> path associated with them.
> 
> And when i do  yum install ekiga  after doing a yum clean metadata  on
> my f10 system I do not have the filelist metadata pulled.  I just pull
> the primary_db no filelist information is required.
> 
> -jef
> 
Jef,

Thanks.  I ran it on December 23rd but for whatever reason I didn't
report it until now,  So, either it's fixed now or my config with borked
at the time.  I appreciate your clarifying the issue for me & checking
it out.



From jspaleta at gmail.com  Sun Jan  4 05:18:05 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 3 Jan 2009 20:18:05 -0900
Subject: Ekiga dependencies
In-Reply-To: <1231046007.10626.84.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
	<1231046007.10626.84.camel@localhost.localdomain>
Message-ID: <604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>

On Sat, Jan 3, 2009 at 8:13 PM, Basil Mohamed Gohar
> Thanks.  I ran it on December 23rd but for whatever reason I didn't
> report it until now,  So, either it's fixed now or my config with borked
> at the time.  I appreciate your clarifying the issue for me & checking
> it out.

Or it could be you have an additional yum plugin enabled that is
pulling filelists as part of its operation.  I've no idea why you are
seeing filelist pulled.

-jef



From abu_hurayrah at hidayahonline.org  Sun Jan  4 06:05:55 2009
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Sun, 04 Jan 2009 08:05:55 +0200
Subject: Ekiga dependencies
In-Reply-To: <604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
	<1231046007.10626.84.camel@localhost.localdomain>
	<604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
Message-ID: <1231049155.10626.105.camel@localhost.localdomain>

On Sat, 2009-01-03 at 20:18 -0900, Jeff Spaleta wrote:
> Or it could be you have an additional yum plugin enabled that is
> pulling filelists as part of its operation.  I've no idea why you are
> seeing filelist pulled.
> 
> -jef

The only plugin I have installed is refresh-packagekit.  However, I just
erased Ekiga & the two dependencies, did a yum clean all, and when I
reinstalled Ekiga, no filelists were pulled, so whatever was happening
is no longer, so I guess that's a good thing.

For future reference, would it be better (this is my ignorance asking)
for a dependency to be on a library (x.so.n) or on a package
name/version combination (x.version)?



From konrad at tylerc.org  Sun Jan  4 06:12:51 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 3 Jan 2009 22:12:51 -0800
Subject: Ekiga dependencies
In-Reply-To: <1231049155.10626.105.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
	<1231049155.10626.105.camel@localhost.localdomain>
Message-ID: <200901032212.52079.konrad@tylerc.org>

On Saturday 03 January 2009 10:05:55 pm Basil Mohamed Gohar wrote:
> On Sat, 2009-01-03 at 20:18 -0900, Jeff Spaleta wrote:
> > Or it could be you have an additional yum plugin enabled that is
> > pulling filelists as part of its operation.  I've no idea why you are
> > seeing filelist pulled.
> >
> > -jef
>
> The only plugin I have installed is refresh-packagekit.  However, I just
> erased Ekiga & the two dependencies, did a yum clean all, and when I
> reinstalled Ekiga, no filelists were pulled, so whatever was happening
> is no longer, so I guess that's a good thing.
>
> For future reference, would it be better (this is my ignorance asking)
> for a dependency to be on a library (x.so.n) or on a package
> name/version combination (x.version)?

Library dependencies are generated automatically so it is considered poor 
style to Require: the package explicitly.

-- 
Conrad Meyer <konrad at tylerc.org>




From pbrobinson at gmail.com  Sun Jan  4 06:17:01 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sun, 4 Jan 2009 07:17:01 +0100
Subject: Ekiga dependencies
In-Reply-To: <1231049155.10626.105.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
	<1231046007.10626.84.camel@localhost.localdomain>
	<604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
	<1231049155.10626.105.camel@localhost.localdomain>
Message-ID: <5256d0b0901032217q7a07f525r1c7b6d7a77106a55@mail.gmail.com>

>> Or it could be you have an additional yum plugin enabled that is
>> pulling filelists as part of its operation.  I've no idea why you are
>> seeing filelist pulled.
>>
>> -jef
>
> The only plugin I have installed is refresh-packagekit.  However, I just
> erased Ekiga & the two dependencies, did a yum clean all, and when I
> reinstalled Ekiga, no filelists were pulled, so whatever was happening
> is no longer, so I guess that's a good thing.

There's been no new packages for ekiga for quite some time. I was
hoping for a new version of ekiga with the last gnome stable 2.24.2
release but there wasn't one released so nothing has changed since mid
November

> For future reference, would it be better (this is my ignorance asking)
> for a dependency to be on a library (x.so.n) or on a package
> name/version combination (x.version)?

The rpm build process works out all the library deps as part of the
build process so its all basically done automatically.

Peter



From abu_hurayrah at hidayahonline.org  Sun Jan  4 06:24:05 2009
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Sun, 04 Jan 2009 08:24:05 +0200
Subject: Ekiga dependencies
In-Reply-To: <1231049155.10626.105.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
	<1231046007.10626.84.camel@localhost.localdomain>
	<604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
	<1231049155.10626.105.camel@localhost.localdomain>
Message-ID: <1231050245.10626.114.camel@localhost.localdomain>

On Sun, 2009-01-04 at 08:05 +0200, Basil Mohamed Gohar wrote:
> 
> The only plugin I have installed is refresh-packagekit.  However, I just
> erased Ekiga & the two dependencies, did a yum clean all, and when I
> reinstalled Ekiga, no filelists were pulled, so whatever was happening
> is no longer, so I guess that's a good thing.
> 
> For future reference, would it be better (this is my ignorance asking)
> for a dependency to be on a library (x.so.n) or on a package
> name/version combination (x.version)?
> 

Thanks, Conrad & Peter, for replying and explaining to me how it works.
I guess I was still in the mindset that if it's a "file" (i.e., library)
being required, it is less efficient than a package, but I think Jef
already addressed that issue, and you guys covered the aspect that it's
done automatically anyway.

________________________________________________________________________

Basil Mohamed Gohar
abu_hurayrah at hidayahonline.org
www.basilgohar.com



From rawhide at fedoraproject.org  Sun Jan  4 08:49:14 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun,  4 Jan 2009 08:49:14 +0000 (UTC)
Subject: rawhide report: 20090104 changes
Message-ID: <20090104084914.E5E331F825E@releng2.fedora.phx.redhat.com>

Compose started at Sun Jan  4 06:01:03 UTC 2009

New package hello
        Prints a Familiar, Friendly Greeting
New package python-cvxopt
        A Python Package for Convex Optimization
Updated Packages:

NetworkManager-0.7.0-1.git20090102.fc11
---------------------------------------
* Fri Jan  2 17:00:00 2009 Dan Williams <dcbw at redhat.com> - 1:0.7.0-1.git20090102
- Update to 0.7.1 pre-release
- Allow connections to be ignored when determining the default route (rh #476089)
- Own /usr/share/gnome-vpn-properties (rh #477155)
- Fix log flooding due to netlink errors (rh #459205)
- Pass connection UUID to dispatcher scripts via the environment
- Fix possible crash after deactivating a VPN connection
- Fix issues with editing wired 802.1x connections
- Fix issues when using PKCS#12 certificates with 802.1x connections


NetworkManager-openvpn-0.7.0-18.svn11.fc11
------------------------------------------
* Sat Jan  3 17:00:00 2009 Dan Williams <dcbw at redhat.com> 1:0.7.0-18.svn11
- Rebuild for updated NetworkManager
- Fix some specfile issues (rh #477149)

* Sat Dec 20 17:00:00 2008 Christoph H??ger <choeger at cs.tu-berlin.de> 0.7.0-17.svn4326
- removed libpng-devel from BuildRequires, added /usr/share/gnome-vpn-properties/openvpn/ (rh #477149)


NetworkManager-pptp-0.7.0-1.svn16.fc11
--------------------------------------
* Sat Jan  3 17:00:00 2009 Dan Williams <dcbw at redhat.com> 1:0.7.0-1.svn16
- Rebuild for updated NetworkManager
- Fix some specfile issues (rh #477153)
- Allow the EAP authentication method


NetworkManager-vpnc-0.7.0-1.svn13.fc11
--------------------------------------
* Sat Jan  3 17:00:00 2009 Dan Williams <dcbw at redhat.com> 1:0.7.0-1
- Rebuild for updated NetworkManager
- Better handling of passwords that shouldn't be saved
- Fix some specfile issues (rh #477151)


TurboGears-1.0.8-1.fc11
-----------------------
* Sat Jan  3 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.0.8-1
- Latest upstream release.


cairo-dock-2.0.0-0.3.svn1462_trunk.fc11
---------------------------------------
* Sun Jan  4 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1462


comix-4.0.2-1.fc11
------------------
* Sun Jan  4 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 4.0.2-1
- 4.0.2


dia-0.96.1-10.fc11
------------------
* Sat Jan  3 17:00:00 2009 Huzaifa Sidhpurwala <huzaifas at redhat.com> 1:0.96.1-10
- Patch so that plugins dont look for .la files


escape-200704130-10.fc11
------------------------
* Sun Jan  4 17:00:00 2009 Adam Goode <adam at spicenitz.org> - 200704130-10
- Correct post and postun scripts for icon cache


fet-5.7.7-1.fc11
----------------
* Sat Jan  3 17:00:00 2009 Balint Cristian <rezso at rdsor.ro> - 5.7.7-1
- new upstream release


git-1.6.1-1.fc11
----------------
* Sat Jan  3 17:00:00 2009 Todd Zullinger <tmz at pobox.com> 1.6.1-1
- Install git-* commands in %{_libexecdir}/git-core, the upstream default
- Remove libcurl from Requires, rpm will pick this up automatically
- Consolidate build/install options in %make_git (Roland McGrath)
- Include DirectoryIndex in gitweb httpd-config (bug 471692)
- Define DOCBOOK_XSL_172 to fix minor manpage issues
- Rename %{_var}/lib/git-daemon to %{_var}/lib/git
- Preserve timestamps on installed files
- Quiet some rpmlint complaints
- Use macros more consistently


gnome-commander-1.2.8-0.3.svn2379_trunk.fc11
--------------------------------------------
* Sun Jan  4 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2379


gnuradio-3.1.3-3.fc11
---------------------
* Wed Dec 31 17:00:00 2008 Marek Mahut <mmahut at fedoraproject.org> - 3.1.3-3
- Adding udev rule for USRP device
- Adding usrp system group


gpodder-0.14.0-2.fc11
---------------------
* Sat Jan  3 17:00:00 2009 Jef Spaleta <jspaleta AT fedoraproject DOT org> - 0.14.0-2
- pybluez dep fix


gyachi-1.1.61-1.fc11
--------------------
* Sat Jan  3 17:00:00 2009 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.61.1
- Add fix for segfault in file transfer.


ikiwiki-3.00-1.fc11
-------------------

libiphone-0.1.0-9.20090103git5cde554.fc11
-----------------------------------------
* Sat Jan  3 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> 0.1.0-9.git5cde554
- Add back gnutls version patch

* Sat Jan  3 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> 0.1.0-8.git5cde554
- Upload bzipped source file

* Sat Jan  3 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> 0.1.0-7.git5cde554
- New git snapshot


mapnik-0.5.2-0.10.svn780.fc11
-----------------------------
* Sat Jan  3 17:00:00 2009 Balint Cristian <rezso at rdsor.ro> - 0.5.2-0.10.svn780
- fix > fc11 fonts requirement
- new CVS


mapserver-5.2.1-3.fc11
----------------------
* Sat Jan  3 17:00:00 2009 Balint Cristian <rezso at rdsor.ro> 5.2.1-3
- require external fonts
- get rid of internal fonts


olpcsound-5.08.92-15.fc11
-------------------------
* Sat Jan  3 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 5.08.92-15
- Add patch for python 2.6 versions

* Sat Jan  3 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 5.08.92-14
- Hopefully fix versioned python dir locations

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 5.08.92-13
- Rebuild for Python 2.6


poker-network-1.7.3-1.fc11
--------------------------
* Thu Jan  1 17:00:00 2009 Christopher Stone <chris.stone at gmail.com> 1.7.3-1
- Upstream sync


safekeep-1.0.5-1.fc11
---------------------
* Sat Jan  3 17:00:00 2009 Jef Spaleta <jspaleta AT fedoraproject DOT org> 1.0.5-1
- Latest upstream release


Summary:
Added Packages: 2
Removed Packages: 0
Modified Packages: 22
Broken deps for i386
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.i386 requires libnm-util.so.0
	anaconda-11.5.0.3-1.i386 requires libnm-util.so.0
	asterisk-1.6.1-0.5beta2.fc11.i386 requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.i386 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.x86_64 requires libnm-util.so.0()(64bit)
	anaconda-11.5.0.3-1.x86_64 requires libnm-util.so.0()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.x86_64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.x86_64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.ppc requires libnm-util.so.0
	anaconda-11.5.0.3-1.ppc requires libnm-util.so.0
	asterisk-1.6.1-0.5beta2.fc11.ppc requires libgmime-2.0.so.2
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.ppc64 requires libnm-util.so.0()(64bit)
	anaconda-11.5.0.3-1.ppc64 requires libnm-util.so.0()(64bit)
	asterisk-1.6.1-0.5beta2.fc11.ppc64 requires libgmime-2.0.so.2()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From mschwendt at gmail.com  Sun Jan  4 09:13:40 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 4 Jan 2009 10:13:40 +0100
Subject: Ekiga dependencies
In-Reply-To: <200901032212.52079.konrad@tylerc.org>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032118v1fbb1edfx6820d3f80460b8a1@mail.gmail.com>
	<1231049155.10626.105.camel@localhost.localdomain>
	<200901032212.52079.konrad@tylerc.org>
Message-ID: <20090104101340.941f90d6.mschwendt@gmail.com>

On Sat, 3 Jan 2009 22:12:51 -0800, Conrad wrote:

> On Saturday 03 January 2009 10:05:55 pm Basil Mohamed Gohar wrote:
> >
> > For future reference, would it be better (this is my ignorance asking)
> > for a dependency to be on a library (x.so.n) or on a package
> > name/version combination (x.version)?
> 
> Library dependencies are generated automatically so it is considered poor 
> style to Require: the package explicitly.

"Poor style" is not the reason, however.

Package name dependencies are weak. Much weaker than the automatic
dependencies on a specific library SONAME -- in particular everytime the
library SONAME is changed.

Dependencies on minimum package version ranges are weak, too. Less weak,
but often they get out-of-date.

Strict dependencies on specific package versions are fragile.

All of them make it harder to rename a package or move the library
elsewhere. And a superfluous explicit dependency on a package name
adds confusion. It suggests that package "foo" is sufficient, but the
depsolver fails to resolve the stricter, automatically added library
dependency nevertheless.



From debarshi.ray at gmail.com  Sun Jan  4 09:38:36 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 4 Jan 2009 15:08:36 +0530
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <ufar669flro.fsf@epithumia.math.uh.edu>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901040138v66618793t60de76d685061afb@mail.gmail.com>

> Issues pending FESCo ratification:
>
> [...]
>
> * Desktop File guideline modification
> ** https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor
> ** This removes language which many interpreted as requiring most
>   desktop files to be installed with --vendor=fedora.

What is the current status of this? Should new packages use
--vendor=fedora or not?

Cheers,
Debarshi



From mtasaka at ioa.s.u-tokyo.ac.jp  Sun Jan  4 10:14:30 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sun, 04 Jan 2009 19:14:30 +0900
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <3170f42f0901040138v66618793t60de76d685061afb@mail.gmail.com>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
	<3170f42f0901040138v66618793t60de76d685061afb@mail.gmail.com>
Message-ID: <49608C06.5050204@ioa.s.u-tokyo.ac.jp>

Debarshi Ray wrote, at 01/04/2009 06:38 PM +9:00:
>> Issues pending FESCo ratification:
>>
>> [...]
>>
>> * Desktop File guideline modification
>> ** https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor
>> ** This removes language which many interpreted as requiring most
>>   desktop files to be installed with --vendor=fedora.
> 
> What is the current status of this? Should new packages use
> --vendor=fedora or not?
> 
> Cheers,
> Debarshi
> 

From:
https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02273.html

=== Fedora Packaging Committee Guideline Proposals ===
* FESCo had no objections to the guideline proposals approved by the
FPC. http://fedoraproject.org/wiki/Packaging/Minutes/20081021

Regards,
Mamoru



From debarshi.ray at gmail.com  Sun Jan  4 10:17:38 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 4 Jan 2009 15:47:38 +0530
Subject: Summary of the 2008-10-21 Packaging Committee meeting
In-Reply-To: <49608C06.5050204@ioa.s.u-tokyo.ac.jp>
References: <ufar669flro.fsf@epithumia.math.uh.edu>
	<3170f42f0901040138v66618793t60de76d685061afb@mail.gmail.com>
	<49608C06.5050204@ioa.s.u-tokyo.ac.jp>
Message-ID: <3170f42f0901040217y495011e4ue4b14584dd4f8da4@mail.gmail.com>

> === Fedora Packaging Committee Guideline Proposals ===
> * FESCo had no objections to the guideline proposals approved by the
> FPC. http://fedoraproject.org/wiki/Packaging/Minutes/20081021

Thank you. https://fedoraproject.org/wiki/Packaging/Guidelines#desktop-file-install_usage
needs to be updated.

Cheers,
Debarshi



From frank-buettner at gmx.net  Sun Jan  4 11:23:14 2009
From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=)
Date: Sun, 04 Jan 2009 12:23:14 +0100
Subject: make build will fail
In-Reply-To: <da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>
References: <49590988.3030709@gmx.net>
	<20081229201028.GB18035@ozlabs.org>	<4959320E.7000602@gmx.net>	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>	<495A086D.30703@gmx.net>
	<da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>
Message-ID: <49609C22.9080605@gmx.net>

Jon Stanley schrieb:
> 2008/12/30 Frank B?ttner <frank-buettner at gmx.net>:
> 
>> Hello,
>> can you tell me ,where must I put this certificates?
>> And where can I get it, because an fedora-packager will not be presented
>> at EPEL.
> 
> The fedora-packager package is indeed in EPEL.
> 
Now I have run fedora-packager-setup, this have build an new cerificate
for koji. I can login into it.
But when I try to run make build I get the same error like before:
/usr/bin/plague-client build ctapi-cyberjack ctapi-cyberjack-3_3_0-2_el5 el5
Traceback (most recent call last):
  File "/usr/bin/plague-client", line 423, in ?
    cli = PlagueClient(os.path.expanduser(cfg_file))
  File "/usr/bin/plague-client", line 85, in __init__
    self._check_api_version(self._server)
  File "/usr/bin/plague-client", line 90, in _check_api_version
    server_ver = server.api_version()
  File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.4/xmlrpclib.py", line 1129, in request
    self.send_content(h, request_body)
  File "/usr/lib/python2.4/xmlrpclib.py", line 1243, in send_content
    connection.endheaders()
  File "/usr/lib/python2.4/httplib.py", line 804, in endheaders
    self._send_output()
  File "/usr/lib/python2.4/httplib.py", line 685, in _send_output
    self.send(msg)
  File "/usr/lib/python2.4/httplib.py", line 664, in send
    self.sock.sendall(str)
  File "/usr/lib/python2.4/site-packages/plague/SSLConnection.py", line
110, in sendall
    sent = con.send(data, flags)
OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE',
'certificate verify failed')]
make: *** [plague] Fehler 1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/3e3a5335/attachment.bin>

From rjones at redhat.com  Sun Jan  4 13:06:36 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 4 Jan 2009 13:06:36 +0000
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <495F8526.4030901@RedHat.com>
References: <495F8526.4030901@RedHat.com>
Message-ID: <20090104130636.GA25798@amd.home.annexia.org>

On Sat, Jan 03, 2009 at 10:32:54AM -0500, Steve Dickson wrote:
> It seems in F10 the hostname and DNS domain name are now being added
> as alias at the end of 127.0.0.1 definition, ala
> 
>      127.0.0.1   localhost.localdomain localhost f10.domainname.com f10
> 
> which unfortunately breaks kerberos in its keytab lookups.

I had a similar problem with dnsmasq, which was apparently caused by
dnsdomainname returning the wrong name (IIRC 'localdomain' rather than
the real domain name).  Copying lines from a working F-8 /etc/hosts
fixed it for me.  Sorry, I didn't make any detailed notes :-(

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From dan at danny.cz  Sun Jan  4 13:11:54 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 04 Jan 2009 14:11:54 +0100
Subject: firewire devices permissions and ownership
Message-ID: <1231074714.3708.49.camel@eagle.danny.cz>

After plugging in a firewire MiniDV camera a new device (/dev/fw1) is
correctly created. But they (/dev/fw*) have 0660 as the permission and
root:root as owner, so it is impossible to control the camera or grab
the videos as a regular user (eg. from Kino). What should be responsible
for allowing the user access for firewire devices?


		Dan




From mschwendt at gmail.com  Sun Jan  4 13:12:07 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 4 Jan 2009 14:12:07 +0100
Subject: make build will fail
In-Reply-To: <49609C22.9080605@gmx.net>
References: <49590988.3030709@gmx.net> <20081229201028.GB18035@ozlabs.org>
	<4959320E.7000602@gmx.net>
	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
	<495A086D.30703@gmx.net>
	<da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>
	<49609C22.9080605@gmx.net>
Message-ID: <20090104141207.d7abe829.mschwendt@gmail.com>

On Sun, 04 Jan 2009 12:23:14 +0100, Frank wrote:

> Jon Stanley schrieb:
> > 2008/12/30 Frank B?ttner <frank-buettner at gmx.net>:
> > 
> >> Hello,
> >> can you tell me ,where must I put this certificates?
> >> And where can I get it, because an fedora-packager will not be presented
> >> at EPEL.
> > 
> > The fedora-packager package is indeed in EPEL.
> > 
> Now I have run fedora-packager-setup, this have build an new cerificate
> for koji. I can login into it.
> But when I try to run make build I get the same error like before:
> /usr/bin/plague-client build ctapi-cyberjack ctapi-cyberjack-3_3_0-2_el5 el5

Koji is for Fedora, EPEL uses Plague.
What does your $HOME/.plague-client.cfg contain?



From bkearney at redhat.com  Sun Jan  4 13:17:42 2009
From: bkearney at redhat.com (Bryan Kearney)
Date: Sun, 04 Jan 2009 08:17:42 -0500
Subject: revisor help
In-Reply-To: <84811.85040.qm@web36506.mail.mud.yahoo.com>
References: <84811.85040.qm@web36506.mail.mud.yahoo.com>
Message-ID: <4960B6F6.7030103@redhat.com>

Craig wrote:
> That what i did was read the doc
> 

You invoked livecd creator with --config ks.cfg. The ks.cfg is a 
kickstart file. It controls how livecd or revisor will build the iso.

-- bk



From frank-buettner at gmx.net  Sun Jan  4 13:38:45 2009
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 04 Jan 2009 14:38:45 +0100
Subject: make build will fail
In-Reply-To: <20090104141207.d7abe829.mschwendt@gmail.com>
References: <49590988.3030709@gmx.net>
	<20081229201028.GB18035@ozlabs.org>	<4959320E.7000602@gmx.net>	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>	<495A086D.30703@gmx.net>	<da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>	<49609C22.9080605@gmx.net>
	<20090104141207.d7abe829.mschwendt@gmail.com>
Message-ID: <4960BBE5.1070603@gmx.net>

Michael Schwendt schrieb:
> On Sun, 04 Jan 2009 12:23:14 +0100, Frank wrote:
> 
>> Jon Stanley schrieb:
>>> 2008/12/30 Frank B?ttner <frank-buettner at gmx.net>:
>>>
>>>> Hello,
>>>> can you tell me ,where must I put this certificates?
>>>> And where can I get it, because an fedora-packager will not be presented
>>>> at EPEL.
>>> The fedora-packager package is indeed in EPEL.
>>>
>> Now I have run fedora-packager-setup, this have build an new cerificate
>> for koji. I can login into it.
>> But when I try to run make build I get the same error like before:
>> /usr/bin/plague-client build ctapi-cyberjack ctapi-cyberjack-3_3_0-2_el5 el5
> 
> Koji is for Fedora, EPEL uses Plague.
> What does your $HOME/.plague-client.cfg contain?
> 
This is the containt of the file

[Certs]
user-ca-cert = ~/X509/Fedora/fedora-upload-ca.cert
server-ca-cert =  ~/X509/Fedora/fedora-server-ca.cert
user-cert = ~/X509/Fedora/fedora.cert

[User]
email = frank-buettner at gmx.net

[Server]
use_ssl = True
address = https://buildsys.fedoraproject.org:8887
allow_uploads = False

Thanks for help.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/4adae2c6/attachment.bin>

From frank-buettner at gmx.net  Sun Jan  4 13:45:44 2009
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 04 Jan 2009 14:45:44 +0100
Subject: make build will fail
In-Reply-To: <4960BBE5.1070603@gmx.net>
References: <49590988.3030709@gmx.net>	<20081229201028.GB18035@ozlabs.org>	<4959320E.7000602@gmx.net>	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>	<495A086D.30703@gmx.net>	<da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>	<49609C22.9080605@gmx.net>	<20090104141207.d7abe829.mschwendt@gmail.com>
	<4960BBE5.1070603@gmx.net>
Message-ID: <4960BD88.1050809@gmx.net>

Frank B?ttner schrieb:
> Michael Schwendt schrieb:
>> On Sun, 04 Jan 2009 12:23:14 +0100, Frank wrote:
>>
>>> Jon Stanley schrieb:
>>>> 2008/12/30 Frank B?ttner <frank-buettner at gmx.net>:
>>>>
>>>>> Hello,
>>>>> can you tell me ,where must I put this certificates?
>>>>> And where can I get it, because an fedora-packager will not be presented
>>>>> at EPEL.
>>>> The fedora-packager package is indeed in EPEL.
>>>>
>>> Now I have run fedora-packager-setup, this have build an new cerificate
>>> for koji. I can login into it.
>>> But when I try to run make build I get the same error like before:
>>> /usr/bin/plague-client build ctapi-cyberjack ctapi-cyberjack-3_3_0-2_el5 el5
>> Koji is for Fedora, EPEL uses Plague.
>> What does your $HOME/.plague-client.cfg contain?
>>

Nice hint, after copy the files from $HOME/.xxx to /X509/Fedora/.xxx
it will work.
Thanks very much for help.

Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/6b47c20b/attachment.bin>

From mschwendt at gmail.com  Sun Jan  4 13:46:08 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 4 Jan 2009 14:46:08 +0100
Subject: make build will fail
In-Reply-To: <4960BBE5.1070603@gmx.net>
References: <49590988.3030709@gmx.net> <20081229201028.GB18035@ozlabs.org>
	<4959320E.7000602@gmx.net>
	<da159fda0812291319m60e49e70n5b1c4ab9080ee42@mail.gmail.com>
	<495A086D.30703@gmx.net>
	<da159fda0812300658g38c7ca61r1803bc1c10beff1c@mail.gmail.com>
	<49609C22.9080605@gmx.net>
	<20090104141207.d7abe829.mschwendt@gmail.com>
	<4960BBE5.1070603@gmx.net>
Message-ID: <20090104144608.b460106e.mschwendt@gmail.com>

On Sun, 04 Jan 2009 14:38:45 +0100, Frank wrote:

> > What does your $HOME/.plague-client.cfg contain?
> > 
> This is the containt of the file
> 
> [Certs]
> user-ca-cert = ~/X509/Fedora/fedora-upload-ca.cert
> server-ca-cert =  ~/X509/Fedora/fedora-server-ca.cert
> user-cert = ~/X509/Fedora/fedora.cert

And are these symlinks which point to the new certs as created
by fedora-packager-setup? 

  -> ~/.fedora-upload-ca.cert
  -> ~/.fedora-server-ca.cert
  -> ~/.fedora.cert

If not, create links or copy the new cert files.



From jkeating at redhat.com  Sun Jan  4 14:11:30 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 04 Jan 2009 06:11:30 -0800
Subject: Ekiga dependencies
In-Reply-To: <1231046007.10626.84.camel@localhost.localdomain>
References: <1231044296.10626.82.camel@localhost.localdomain>
	<604aa7910901032108p168bf809qf6663122275ef24@mail.gmail.com>
	<1231046007.10626.84.camel@localhost.localdomain>
Message-ID: <1231078290.4566.19.camel@localhost.localdomain>

On Sun, 2009-01-04 at 07:13 +0200, Basil Mohamed Gohar wrote:
> Thanks.  I ran it on December 23rd but for whatever reason I didn't
> report it until now,  So, either it's fixed now or my config with borked
> at the time.  I appreciate your clarifying the issue for me & checking
> it out.

It's also possible that one of the things ekiga needed and you didn't
have installed had file deps, and thus brought in the filelists.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/b4189912/attachment.sig>

From andy at smile.org.ua  Sun Jan  4 14:11:24 2009
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sun, 4 Jan 2009 16:11:24 +0200
Subject: New font packaging guidelines
In-Reply-To: <1229789615.16655.28.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
Message-ID: <20090104141124.GA29978@work.smile.org.ua>

On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:
> As some of you may know, after more than a month of consultation,
> feedback and tweaking new font packaging guidelines have been approved
> by FESCO.

As I said before in [1] the new guidelines has at least bad explanation about
fonts which are used to create internal documentation like *.pdf from *.tex.
In my case [1] the *.ttf has been shipped under %{_docdir}. 

And actually this font file is attached to package during generation
documentation via doxygen [2]. 

I consider is not a bug at all in case of jack-audio-connection-kit-devel. The
way to follow by rules is to patch doxygen.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=477402
[2] 
...
\anchor cfg_dot_fontname
<dt>\c DOT_FONTNAME <dd>
 \addindex DOT_FONTNAME
 By default doxygen will write a font called \c FreeSans.ttf to the output
 directory and reference it in all dot files that doxygen generates. This
...

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From dledford at redhat.com  Sun Jan  4 14:13:05 2009
From: dledford at redhat.com (Doug Ledford)
Date: Sun, 04 Jan 2009 09:13:05 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <4957E650.6010809@redhat.com>
References: <494930CD.70709@herr-schmitt.de>  <4957E650.6010809@redhat.com>
Message-ID: <1231078385.32405.737.camel@firewall.xsintricity.com>

On Sun, 2008-12-28 at 15:49 -0500, Casey Dahlin wrote:
> Jochen Schmitt wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hallo,
> >
> > nowaday I have read in the german fedora forum, that grub is not able
> > to handle
> > ext4 file systems. In opposite grub2 should be able to support ext4.
> >
> >   
> I haven't looked at the code for grub2 myself, but most of the people I 
> talk to that have cringe when they mention it. The people I talk to tend 
> to be heavily involved in the boot process. As a piece of software 
> engineering, it hasn't earned many fans among those most concerned with 
> the change as far as I can tell.

Last I knew, grub2 was a dead project.  At least it was when I looked at
it about 2 or 3 years ago.  It hadn't had a single code update in over 2
years when I looked at it.  Has that changed?

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/04258e5c/attachment.sig>

From fasteliteprogrammer at yahoo.com  Sun Jan  4 14:15:13 2009
From: fasteliteprogrammer at yahoo.com (Craig)
Date: Sun, 4 Jan 2009 06:15:13 -0800 (PST)
Subject: revisor help
Message-ID: <434964.88993.qm@web36501.mail.mud.yahoo.com>



When i do that i get this error


livecd-creator --config ks.cfg
Traceback (most recent call last):
? File "/usr/bin/livecd-creator", line 136, in <module>
??? sys.exit(main())
? File "/usr/bin/livecd-creator", line 112, in main
??? creator = imgcreate.LiveImageCreator(ks, name, fs_label)
? File "/usr/lib/python2.5/site-packages/imgcreate/live.py", line 47, in __init__
??? LoopImageCreator.__init__(self, *args)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 788, in __init__
??? ImageCreator.__init__(self, ks, name)
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 76, in __init__
??? self.__sanity_check()
? File "/usr/lib/python2.5/site-packages/imgcreate/creator.py", line 400, in __sanity_check
??? raise CreatorError("No repositories specified")
imgcreate.errors.CreatorError: No repositories specified







--- On Sun, 1/4/09, Bryan Kearney <bkearney at redhat.com> wrote:

From: Bryan Kearney <bkearney at redhat.com>
Subject: Re: revisor help
To: "Development discussions related to Fedora" <fedora-devel-list at redhat.com>
Date: Sunday, January 4, 2009, 7:17 AM

Craig wrote:
> That what i did was read the doc
> 

You invoked livecd creator with --config ks.cfg. The ks.cfg is a kickstart file. It controls how livecd or revisor will build the iso.

-- bk

-- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/1913a23b/attachment.htm>

From dledford at redhat.com  Sun Jan  4 14:18:24 2009
From: dledford at redhat.com (Doug Ledford)
Date: Sun, 04 Jan 2009 09:18:24 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495884BC.7040800@redhat.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com>  <495884BC.7040800@redhat.com>
Message-ID: <1231078704.32405.744.camel@firewall.xsintricity.com>

On Mon, 2008-12-29 at 03:05 -0500, Casey Dahlin wrote:
> Lyos Gemini Norezel wrote:
> > Yaakov Nemoy wrote:
> >> 2008/12/17 Jochen Schmitt <Jochen at herr-schmitt.de>:
> >>   
> >> /boot is a 100-200 MB partition on many machines. 
> >
> >> ...there's just no sense supporting /boot on anything
> >> other than a 100-200 MB ext2 or ext3 volume.
> >>   
> > Sorry... but that's just plain wrong.
> >
> > Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 
> > 5GB on all of my computers.
> >
> > Why?
> >
> > 1.) I have a rescue image setup to boot if I need it...
> > and
> > 2.) I have a ghost image I made right after installing this version of 
> > fedora.
> >
> 
> I don't see why either of those should exist entirely in /boot. You are 
> allowed further partitions. Nothing in /boot should remain relevant 
> after we get a proper kernel in memory and enough modules to read the 
> rest of the disk.

You only need a separate /boot partition for a few reasons:

1) BIOS can't read the entire disk so you need to ensure that your boot
loader and kernel fall in the readable section
2) The boot loader can't read your / filesystem type (because of LVM or
ext4 or whatever) so you need a separate space for the boot files

The whole argument that you need /boot separate from / in case your /
filesystem gets hosed is bogus.  If your / filesystem is so hosed you
can't boot the kernel into a usable OS, or even into a bash shell, then
being able to boot buys you nothing, you still need a rescue environment
to get anything fixed.

Lyos' method of putting a rescue image in /boot actually solves that
conundrum nicely.  And no, you don't need a separate partition for it,
using /boot is perfectly good enough.  After all, if /boot gets hosed
due to a kernel bug, and it takes out the boot loader or the initrd or
the kernel image itself, then having the rescue tools on a hidden
partition buys you nothing since you won't have a boot loader and kernel
to boot into the rescue tools.  As long as you remember that the rescue
environment is useless without the boot loader, kernel, and initrd, then
it becomes clear that grouping those things together is perfectly
acceptable because either they all work, or they none work.

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/590823e2/attachment.sig>

From surenkarapetyan at gmail.com  Sun Jan  4 14:58:50 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Sun, 04 Jan 2009 18:58:50 +0400
Subject: sound problems
Message-ID: <4960CEAA.4070507@gmail.com>

Yeah.. I know. fedora-devel is not a place for discussing bugs but I'll 
risk.

As (I hope) many of You already know kernel-2.6.27.9-159 which was 
pushed as a security update has broken sound on many systems (mostly 
notebooks) - https://bugzilla.redhat.com/show_bug.cgi?id=477954. The 
reason for this is the new ALSA (1.0.18a).

There are a lot of "+1"s and "me too"s in bugzilla and if we consider 
the amount of people who don't know how to report bugs, add those who 
are on New Year holidays it becomes clear that this affects a lot of our 
users.

So users have two choices now:
1. Have no sound.
2. Stick with 2.6.27.9-134 (this is not as easy as it seems cause the 
new update will be downloaded and installed automatically).

I do understand that many developers are on holidays themselves, but I'm 
also sure this is a REAL problem which should be resolved ASAP.
So I just wanted to know what are we going to do about this.

Regards,
Suren



From frank-buettner at gmx.net  Sun Jan  4 15:00:15 2009
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 04 Jan 2009 16:00:15 +0100
Subject: Missing target in the cvs tree
Message-ID: <4960CEFF.1060900@gmx.net>

Hello,
in the CVS tree of my packages ate the F-9 and F-10 trees missing.
What must I to to create this trees.?
I have the follow ones:
common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/83a43888/attachment.bin>

From rakesh.pandit at gmail.com  Sun Jan  4 15:11:22 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 4 Jan 2009 20:41:22 +0530
Subject: Missing target in the cvs tree
In-Reply-To: <4960CEFF.1060900@gmx.net>
References: <4960CEFF.1060900@gmx.net>
Message-ID: <b401d2530901040711wd81fd89n667f9d76efdecb02@mail.gmail.com>

2009/1/4 Frank B?ttner <frank-buettner at gmx.net>:
> Hello,
> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
> What must I to to create this trees.?
> I have the follow ones:
> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6
>

>From the packages at
https://admin.fedoraproject.org/pkgdb/users/packages/frankb I don't
see anyone which does not have both F9 and F10 branch missing.

Which package ?

-- 
rakesh



From lists at sapience.com  Sun Jan  4 15:13:02 2009
From: lists at sapience.com (Mail Lists)
Date: Sun, 04 Jan 2009 10:13:02 -0500
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <495F8526.4030901@RedHat.com>
References: <495F8526.4030901@RedHat.com>
Message-ID: <4960D1FE.20303@sapience.com>

On 01/03/2009 10:32 AM, Steve Dickson wrote:
> Hello,
> 
> It seems in F10 the hostname and DNS domain name are now being added
> as alias at the end of 127.0.0.1 definition, ala
> 
>      127.0.0.1   localhost.localdomain localhost f10.domainname.com f10
> 
> which unfortunately breaks kerberos in its keytab lookups.
> 

  Every F10 install I did had a bad /etc/hosts file in  the way you
describe. Easy enough to fix but not for Aunt Tilly - tho she may not
care and desktop impact is probably lowish.

 However this does impact other services as well (squid/apache and
others). I had terrible problems with some daemons inappropriately
listening on 127.0.0.1 and not on the real IP until I fixed the hosts file.




From pingou at pingoured.fr  Sun Jan  4 15:13:07 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Sun, 04 Jan 2009 16:13:07 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <4960CEFF.1060900@gmx.net>
References: <4960CEFF.1060900@gmx.net>
Message-ID: <4960D203.4070301@pingoured.fr>

Frank B?ttner wrote:
> Hello,
> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
> What must I to to create this trees.?
> I have the follow ones:
> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6

Tried the cvs update before ?

(Just in case  ^^)

Regards,

Pierre



From frank-buettner at gmx.net  Sun Jan  4 15:20:52 2009
From: frank-buettner at gmx.net (=?UTF-8?B?RnJhbmsgQsO8dHRuZXI=?=)
Date: Sun, 04 Jan 2009 16:20:52 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <4960D203.4070301@pingoured.fr>
References: <4960CEFF.1060900@gmx.net> <4960D203.4070301@pingoured.fr>
Message-ID: <4960D3D4.6050601@gmx.net>

Pierre-Yves schrieb:
> Frank B?ttner wrote:
>> Hello,
>> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
>> What must I to to create this trees.?
>> I have the follow ones:
>> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6
> 
> Tried the cvs update before ?
> 
> (Just in case  ^^)
> 
> Regards,
> 
> Pierre
> 
Yes, but the F-9 and F-10 tree is missing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/eba91e00/attachment.bin>

From frank-buettner at gmx.net  Sun Jan  4 15:23:18 2009
From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=)
Date: Sun, 04 Jan 2009 16:23:18 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <b401d2530901040711wd81fd89n667f9d76efdecb02@mail.gmail.com>
References: <4960CEFF.1060900@gmx.net>
	<b401d2530901040711wd81fd89n667f9d76efdecb02@mail.gmail.com>
Message-ID: <4960D466.6020104@gmx.net>

Rakesh Pandit schrieb:
> 2009/1/4 Frank B?ttner <frank-buettner at gmx.net>:
>> Hello,
>> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
>> What must I to to create this trees.?
>> I have the follow ones:
>> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6
>>
> 
>> >From the packages at
> https://admin.fedoraproject.org/pkgdb/users/packages/frankb I don't
> see anyone which does not have both F9 and F10 branch missing.
> 
> Which package ?
> 
In all of my packages.
qwt-doc,qwt,qtiplot,nas,muParser,ctapi-cyberjack,ctapi-common

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/b82fdba3/attachment.bin>

From musuruan at gmail.com  Sun Jan  4 15:25:51 2009
From: musuruan at gmail.com (Andrea Musuruane)
Date: Sun, 4 Jan 2009 16:25:51 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <4960D466.6020104@gmx.net>
References: <4960CEFF.1060900@gmx.net>
	<b401d2530901040711wd81fd89n667f9d76efdecb02@mail.gmail.com>
	<4960D466.6020104@gmx.net>
Message-ID: <29fee02b0901040725r6856d292u9e412c2ce0e7ee2a@mail.gmail.com>

2009/1/4 Frank B?ttner <frank-buettner at gmx.net>:
> In all of my packages.
> qwt-doc,qwt,qtiplot,nas,muParser,ctapi-cyberjack,ctapi-common

It seems a problem on your side.

If you use the viewvc web interface, you can see that the branches are there:
http://cvs.fedoraproject.org/viewvc/rpms/ctapi-cyberjack/
http://cvs.fedoraproject.org/viewvc/rpms/nas/

Regards,

Andrea.



From mschwendt at gmail.com  Sun Jan  4 15:25:54 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 4 Jan 2009 16:25:54 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <4960CEFF.1060900@gmx.net>
References: <4960CEFF.1060900@gmx.net>
Message-ID: <20090104162554.e7751d66.mschwendt@gmail.com>

On Sun, 04 Jan 2009 16:00:15 +0100, Frank wrote:

> Hello,
> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
> What must I to to create this trees.?
> I have the follow ones:
> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6

cvs up -d



From frank-buettner at gmx.net  Sun Jan  4 15:33:43 2009
From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=)
Date: Sun, 04 Jan 2009 16:33:43 +0100
Subject: Missing target in the cvs tree
In-Reply-To: <20090104162554.e7751d66.mschwendt@gmail.com>
References: <4960CEFF.1060900@gmx.net>
	<20090104162554.e7751d66.mschwendt@gmail.com>
Message-ID: <4960D6D7.4060600@gmx.net>

Michael Schwendt schrieb:
> On Sun, 04 Jan 2009 16:00:15 +0100, Frank wrote:
> 
>> Hello,
>> in the CVS tree of my packages ate the F-9 and F-10 trees missing.
>> What must I to to create this trees.?
>> I have the follow ones:
>> common  CVS  devel  EL-4  EL-5  F-7  F-8  FC-4  FC-5  FC-6
> 
> cvs up -d
> 
yes this was it. thanks for the fast help
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/bb26dd74/attachment.bin>

From fedora at matbooth.co.uk  Sun Jan  4 15:45:36 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Sun, 4 Jan 2009 15:45:36 +0000
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
Message-ID: <9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>

Hi

I want to configure my Asus laptop's Fn volume keys as they do not
currently work in Fedora.

Looking in the 30-keymap-module-asus-laptop.fdi file I can see it
expects there to be an "Asus Extra Buttons" device, however when I do
a:

#  lshal | grep Asus

I see no such device. The asus_laptop kernel seems to be loaded
however, because I can see the following two lines in dmesg:

asus-laptop: Asus Laptop Support version 0.42
asus-laptop:   F3Sr model detected

I am new to HAL. How do I debug this?

Regards,
Mat

-- 
Mat Booth
www.matbooth.co.uk



From rakesh.pandit at gmail.com  Sun Jan  4 15:52:59 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 4 Jan 2009 21:22:59 +0530
Subject: proposal for fedora11 feature ReviewOMatic
Message-ID: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>

I am going to propose review-o-matic as fedora 11 infrastructure feature.

Regarding review-o-matic

 * Home Page https://fedorahosted.org/review-o-matic/wiki
 * Browse Source Code https://fedorahosted.org/review-o-matic/browser
 * Mailing List https://fedorahosted.org/mailman/listinfo/review-o-matic

Proposal(still incomplete):
https://fedoraproject.org/wiki/Features/ReviewOMatic

Snippet from proposal:
"""
  Benefit to Fedora

    * Automatically building srpms once they are submitted for package
review and responding depending upon the result of build.
    * Running rpmlint and other automated guideline checks provided by
review-o-matic and providing a report.
    * Periodically checking already existing packages in repository
for their consistency with guidelines and proving reports to
maintainers. There by doing a periodic maintenance for ever increasing
fedora packages.

"""

I request everyone to check the project and read proposal.

Comments, suggestions, improvements are all welcome ?

-- 
rakesh



From bruno at wolff.to  Sun Jan  4 15:55:28 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sun, 4 Jan 2009 09:55:28 -0600
Subject: revisor help
In-Reply-To: <434964.88993.qm@web36501.mail.mud.yahoo.com>
References: <434964.88993.qm@web36501.mail.mud.yahoo.com>
Message-ID: <20090104155528.GA13183@wolff.to>

On Sun, Jan 04, 2009 at 06:15:13 -0800,
  Craig <fasteliteprogrammer at yahoo.com> wrote:
> 
> 
> When i do that i get this error

The kickstart file either needs to have at least one repo command in it or
it needs to use an include command to include another kickstart file that
does include a repo command. Otherwise livecd-creator doesn't know where
to find the packages needed to build the image.



From nicolas.mailhot at laposte.net  Sun Jan  4 16:00:10 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 04 Jan 2009 17:00:10 +0100
Subject: New font packaging guidelines
In-Reply-To: <20090104141124.GA29978@work.smile.org.ua>
References: <1229789615.16655.28.camel@arekh.okg>
	<20090104141124.GA29978@work.smile.org.ua>
Message-ID: <1231084810.28717.58.camel@arekh.okg>

Le dimanche 04 janvier 2009 ? 16:11 +0200, Andy Shevchenko a ?crit :
> On Sat, Dec 20, 2008 at 05:13:35PM +0100, Nicolas Mailhot wrote:
> > As some of you may know, after more than a month of consultation,
> > feedback and tweaking new font packaging guidelines have been approved
> > by FESCO.
> 
> As I said before in [1]

[For people who didn't follow, after FPC and FESCO approved the new
rules, when Andy Shevchenko was notified via bugzilla to apply them]

>  the new guidelines has at least bad explanation about
> fonts which are used to create internal documentation like *.pdf from *.tex.

There is no bad explanation at all because they are not intended to be
special-cased at all, so they don't need special explanations.

There are many tools that may misbehave and install stuff like fonts
they should not, but this is not a reason to let it pass in packages.

> In my case [1] the *.ttf has been shipped under %{_docdir}. 
> 
> And actually this font file is attached to package during generation
> documentation via doxygen [2]. 
> 
> I consider is not a bug at all in case of jack-audio-connection-kit-devel. The
> way to follow by rules is to patch doxygen.

When you ship material you should not ship it's a bug in your package.
Otherwise one could do pretty much anything he wanted and claim it was
the fault of the tools he used.

I've filled a bug on doxygen if that makes you feel better, but really,
it's an easy fix in your package and there's no reason to postpone the
fix till the tools you use are eventually fixed upstream

http://bugzilla.redhat.com/show_bug.cgi?id=478747

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/4198847e/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Jan  4 16:02:00 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 04 Jan 2009 17:02:00 +0100
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
Message-ID: <1231084920.28717.59.camel@arekh.okg>

Le dimanche 04 janvier 2009 ? 21:22 +0530, Rakesh Pandit a ?crit :

> Comments, suggestions, improvements are all welcome ?

Is there some check wishlist people can add to somewhere? (preferably
not in trac)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/35db3f23/attachment.sig>

From chitlesh.goorah at gmail.com  Sun Jan  4 16:15:46 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sun, 4 Jan 2009 17:15:46 +0100
Subject: emacs fan help with packaging .el
Message-ID: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>

Hello there,

I have never used emacs before.

I'm packaging a few items which includes *.el for emacs.

after following https://fedoraproject.org/wiki/Packaging/Emacs,
I've prepared the spec file:
http://chitlesh.fedorapeople.org/RPMS/dinotrace.spec
http://chitlesh.fedorapeople.org/RPMS/dinotrace-9.3f-1.fc10.src.rpm

Nevertheless, the  emacs-dinotrace requires dinotrace-doc for
installing. But dinotrace.spec doesn't ship dinotrace-doc. I don't
know how this dependency is being pulled up.

[root at cgoorah ~]# rpm -ivh
/home/chitlesh/rpmbuild/RPMS/i386/emacs-dinotrace-9.3f-1.fc10.i386.rpm
error: Failed dependencies:
        dinotrace-doc = 9.3f-1.fc10 is needed by
emacs-dinotrace-9.3f-1.fc10.i386

Can you also verify how I'm getting the *.el installed please ? I'll
use that as a template for my other packages.

thanks,
Chitlesh



From debarshi.ray at gmail.com  Sun Jan  4 16:16:55 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 4 Jan 2009 21:46:55 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <1231084920.28717.59.camel@arekh.okg>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<1231084920.28717.59.camel@arekh.okg>
Message-ID: <3170f42f0901040816s77e5998cw29363ffb62ee44ba@mail.gmail.com>

>> Comments, suggestions, improvements are all welcome ?

> Is there some check wishlist people can add to somewhere? (preferably
> not in trac)

We can either create a wiki page on Fedorahosted, or use the ticket
system. Or did you mean "not in fedorahosted.org" by "not in trac"?

Cheers,
Debarshi



From fedora at matbooth.co.uk  Sun Jan  4 16:18:39 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Sun, 4 Jan 2009 16:18:39 +0000
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
	<9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
Message-ID: <9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>

On Sun, Jan 4, 2009 at 3:45 PM, Mat Booth <fedora at matbooth.co.uk> wrote:
> Hi
>
> I want to configure my Asus laptop's Fn volume keys as they do not
> currently work in Fedora.
>
> Looking in the 30-keymap-module-asus-laptop.fdi file I can see it
> expects there to be an "Asus Extra Buttons" device, however when I do
> a:
>
> #  lshal | grep Asus
>
> I see no such device. The asus_laptop kernel seems to be loaded
> however, because I can see the following two lines in dmesg:
>
> asus-laptop: Asus Laptop Support version 0.42
> asus-laptop:   F3Sr model detected
>
> I am new to HAL. How do I debug this?
>

Sorry to reply to myself.

I was just looking at the config for other brands of laptop. The FDI
for sony machines expects a device called "Sony Vaio Keys" and looking
in the source for the sony-laptop driver shows that this device is
indeed provided. (The same goes for Thinkpads.)

However, it does not look like the asus-laptop driver provides any
device called "Asus Extra Buttons".

I'd be amazed if the config that exists in
30-keymap-module-asus-laptop.fdi works at all!

Is this an omission in the asus-laptop driver? Would I need to
implement an input device driver to get it working?

-- 
Mat Booth
www.matbooth.co.uk



From frank-buettner at gmx.net  Sun Jan  4 16:21:17 2009
From: frank-buettner at gmx.net (=?ISO-8859-1?Q?Frank_B=FCttner?=)
Date: Sun, 04 Jan 2009 17:21:17 +0100
Subject: [reopen]Re: mock 0.9.11 will not build anything
In-Reply-To: <47F48C7D.8000904@gmx.net>
References: <479399FA.9040709@gmx.net>	<1200899414.6945.39.camel@localhost.localdomain>	<47945451.4040606@gmx.net>	<1200904582.6945.41.camel@localhost.localdomain>	<47945C3F.7040109@gmx.net>	<1200914012.6945.58.camel@localhost.localdomain>	<47949FD6.7070300@gmx.net>	<4794C518.1010307@gmx.net>	<20080121175047.GA28272@humbolt.us.dell.com>	<47E11484.5000408@gmx.net>	<20080319144819.GA28719@humbolt.us.dell.com>
	<47F48C7D.8000904@gmx.net>
Message-ID: <4960E1FD.8060504@gmx.net>

Frank B?ttner schrieb:
> Michael E Brown schrieb:
>> On Wed, Mar 19, 2008 at 02:26:28PM +0100, Frank B?ttner wrote:
>>> Michael E Brown schrieb:
>>>> We intend to upgrade mock in EPEL5 to 0.9.x come Feb. The dependencies
>>>> are now all mostly available. Python-ctypes is in the -testing
>>>> repository for EPEL-5.
>>>>
>>>> The fedora builders are all running RHEL5 with this version, so it is
>>>> well-tested. If you want to use it, grab the mock 0.9.x SRPM from
>>>> fedora
>>>> rawhide and rebuild it and grab the python-ctypes RPM from epel testing
>>>> repo.
>>>>
>>>> All of the configs in 0.9.x have been tested. ccache is disabled in all
>>>> of the configs where it is not available in the upstream repos.
>>> Now we have March, but I can't see any new version. Can you tell me
>>> the status??
>>
>> I built 0.9.7 for EPEL5 either earlier this week or late last week. It
>> takes a while before it goes from EPEL testing repo to the prod repo.
>> -- 
>> Michael

Hello again,
the last version mock-0.9.11-1.el5, will also don't build anything.:(



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5766 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/32188c2e/attachment.bin>

From andy at smile.org.ua  Sun Jan  4 16:30:41 2009
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sun, 4 Jan 2009 18:30:41 +0200
Subject: New font packaging guidelines
In-Reply-To: <1231084810.28717.58.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
	<20090104141124.GA29978@work.smile.org.ua>
	<1231084810.28717.58.camel@arekh.okg>
Message-ID: <20090104163041.GB29978@work.smile.org.ua>

On Sun, Jan 04, 2009 at 05:00:10PM +0100, Nicolas Mailhot wrote:
> I've filled a bug on doxygen if that makes you feel better, but really,
> it's an easy fix in your package and there's no reason to postpone the
> fix till the tools you use are eventually fixed upstream
> 
> http://bugzilla.redhat.com/show_bug.cgi?id=478747
Ok, I see the temporary solution is to exclude latex documentation from jack
until doxygen has fixed the issue.

Thanks.

P.S. Hoewver, it was not so desirable to fill bug against hundreds of packages
instead of fix one of them.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From jonathan.underwood at gmail.com  Sun Jan  4 16:30:49 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 16:30:49 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
Message-ID: <645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>

2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
> Nevertheless, the  emacs-dinotrace requires dinotrace-doc for
> installing. But dinotrace.spec doesn't ship dinotrace-doc. I don't
> know how this dependency is being pulled up.
>

In your spec file you have:

Requires:          %{name}-doc = %{version}-%{release}

for the emacs-dino-trace package. That's why emacs-dinotrace is
wanting to install dinotrace-doc. Remove that and your problem will go
away. Question is, why did you add it in the first place, and is
removing it the right thing to do?

Other things I noticed:

You should Require emacs(bin) rather than emacs-common
You should BuildRequire: emacs-el to pull in the pkgconfig file.

Also, you should set some sensible defaults in the case that the
pkg-config file is not available to aid portability and also stops the
SRPM building fail in the build system - see the templates in the
Emacs packaging guidelines.

Aside: The Emacs packaging guidelines use of pkg-config is actually
pretty horrible (I'm allowed to say that, it's my fault). I'm drafting
some updated guidelines (and accompanying patches to the emacs and
xemacs spec) which instead use macros (to be defined in
/etc/macros.[x]emacs).

Another aside: Other the past few months I've noticed that many
packages don't create a separate emacs-foo subpackage but rather use a
trick with %triggerin to drop elisp files into place when emacs is
installed. I also think this should be discussed and documented in the
packaging guidelines as an alternative when a package only has 1 or 2
elisp files.

A further aside: I think the emacs guidelines should only insist on
separate emacs-foo-el sub-packages when there are a large number of
.el files. Perhaps. Maybe.

HTH,
J.



From rakesh.pandit at gmail.com  Sun Jan  4 16:36:28 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 4 Jan 2009 22:06:28 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901040816s77e5998cw29363ffb62ee44ba@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<1231084920.28717.59.camel@arekh.okg>
	<3170f42f0901040816s77e5998cw29363ffb62ee44ba@mail.gmail.com>
Message-ID: <b401d2530901040836n26e637d3t210d1bd88cf25a94@mail.gmail.com>

2009/1/4 Debarshi Ray <debarshi.ray at gmail.com>:
>>> Comments, suggestions, improvements are all welcome ?
>
>> Is there some check wishlist people can add to somewhere? (preferably
>> not in trac)
>
> We can either create a wiki page on Fedorahosted, or use the ticket
> system. Or did you mean "not in fedorahosted.org" by "not in trac"?
>

We started making a table of all checks and investigating them on
wiki. Time did not permitted us to get started on them as first
priority was to get bare minimum workflow implemented.

Here is the wiki link https://fedorahosted.org/review-o-matic/wiki/Check_Table

You may add to this list or create a new page in wiki.

-- 
rakesh



From nicolas.mailhot at laposte.net  Sun Jan  4 16:39:08 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 04 Jan 2009 17:39:08 +0100
Subject: New font packaging guidelines
In-Reply-To: <20090104163041.GB29978@work.smile.org.ua>
References: <1229789615.16655.28.camel@arekh.okg>
	<20090104141124.GA29978@work.smile.org.ua>
	<1231084810.28717.58.camel@arekh.okg>
	<20090104163041.GB29978@work.smile.org.ua>
Message-ID: <1231087148.28717.61.camel@arekh.okg>

Le dimanche 04 janvier 2009 ? 18:30 +0200, Andy Shevchenko a ?crit :

> P.S. Hoewver, it was not so desirable to fill bug against hundreds of packages
> instead of fix one of them.

I can assure you the reasons that made packages include fonts when they
should not vary wildly and actually you're the first packager in the
~130 bug set that hit that particular docygen quirk.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/71e9ac98/attachment.sig>

From chitlesh.goorah at gmail.com  Sun Jan  4 16:39:26 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sun, 4 Jan 2009 17:39:26 +0100
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
Message-ID: <50baabb30901040839p31122c5di18a97ca10f82a7f2@mail.gmail.com>

On Sun, Jan 4, 2009 at 5:30 PM, Jonathan Underwood
<jonathan.underwood at gmail.com> wrote:

> In your spec file you have:
>
> Requires:          %{name}-doc = %{version}-%{release}
>
> for the emacs-dino-trace package. That's why emacs-dinotrace is
> wanting to install dinotrace-doc. Remove that and your problem will go
> away. Question is, why did you add it in the first place, and is
> removing it the right thing to do?

Oh dear, I feel stupid !

Chitlesh



From jonathan.underwood at gmail.com  Sun Jan  4 16:43:06 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 16:43:06 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <50baabb30901040839p31122c5di18a97ca10f82a7f2@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<50baabb30901040839p31122c5di18a97ca10f82a7f2@mail.gmail.com>
Message-ID: <645d17210901040843g2c2e2972g683476399ff5d2cc@mail.gmail.com>

2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
> On Sun, Jan 4, 2009 at 5:30 PM, Jonathan Underwood
> <jonathan.underwood at gmail.com> wrote:
>
>> In your spec file you have:
>>
>> Requires:          %{name}-doc = %{version}-%{release}
>>
>> for the emacs-dino-trace package. That's why emacs-dinotrace is
>> wanting to install dinotrace-doc. Remove that and your problem will go
>> away. Question is, why did you add it in the first place, and is
>> removing it the right thing to do?
>
> Oh dear, I feel stupid !

No need, it's Sunday. Have a coffee.



From pingou at pingoured.fr  Sun Jan  4 16:44:42 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Sun, 04 Jan 2009 17:44:42 +0100
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901040843g2c2e2972g683476399ff5d2cc@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>	<50baabb30901040839p31122c5di18a97ca10f82a7f2@mail.gmail.com>
	<645d17210901040843g2c2e2972g683476399ff5d2cc@mail.gmail.com>
Message-ID: <4960E77A.3040502@pingoured.fr>

Jonathan Underwood wrote:
> 2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
>> On Sun, Jan 4, 2009 at 5:30 PM, Jonathan Underwood
>> <jonathan.underwood at gmail.com> wrote:
>>
>>> In your spec file you have:
>>>
>>> Requires:          %{name}-doc = %{version}-%{release}
>>>
>>> for the emacs-dino-trace package. That's why emacs-dinotrace is
>>> wanting to install dinotrace-doc. Remove that and your problem will go
>>> away. Question is, why did you add it in the first place, and is
>>> removing it the right thing to do?
>> Oh dear, I feel stupid !
> 
> No need, it's Sunday. Have a coffee.
> 
Knowing Chitlesh I would say a break and a beer :p

I bet he did not taste them all yet !

Cheers,

Pierre



From andy at smile.org.ua  Sun Jan  4 16:52:47 2009
From: andy at smile.org.ua (Andy Shevchenko)
Date: Sun, 4 Jan 2009 18:52:47 +0200
Subject: New font packaging guidelines
In-Reply-To: <1231087148.28717.61.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
	<20090104141124.GA29978@work.smile.org.ua>
	<1231084810.28717.58.camel@arekh.okg>
	<20090104163041.GB29978@work.smile.org.ua>
	<1231087148.28717.61.camel@arekh.okg>
Message-ID: <20090104165247.GC29978@work.smile.org.ua>

On Sun, Jan 04, 2009 at 05:39:08PM +0100, Nicolas Mailhot wrote:
> > P.S. Hoewver, it was not so desirable to fill bug against hundreds of packages
> > instead of fix one of them.
> 
> I can assure you the reasons that made packages include fonts when they
> should not vary wildly and actually you're the first packager in the
> ~130 bug set that hit that particular docygen quirk.
Apparently others are excluded LaTeX generation :-)

It looks like a bomb with delaying activation, you know. And nice to fix it
before any worse case has been come.

Anyway, I'm working now with workaround and I'll push today new package which
satisfies both you and me.

-- 
With best regards,
Andy Shevchenko.      mailto: andy at smile.org.ua




From thomas.moschny at gmail.com  Sun Jan  4 17:23:57 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sun, 4 Jan 2009 18:23:57 +0100
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
Message-ID: <a9d183c80901040923s3515da88s9a041ed698c54dbe@mail.gmail.com>

2009/1/4 Jonathan Underwood <jonathan.underwood at gmail.com>:
> Another aside: Other the past few months I've noticed that many
> packages don't create a separate emacs-foo subpackage but rather use a
> trick with %triggerin to drop elisp files into place when emacs is
> installed. I also think this should be discussed and documented in the
> packaging guidelines as an alternative when a package only has 1 or 2
> elisp files.

Couldn't this be a general mechanism to be used also for vim
syntaxfiles, shell completion rules, etc, etc... ?

- Thomas



From a.badger at gmail.com  Sun Jan  4 17:21:24 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sun, 04 Jan 2009 09:21:24 -0800
Subject: Dia does not work without .la files - BZ 475992
In-Reply-To: <gjo2ak$2k0$1@ger.gmane.org>
References: <495F4E29.3050806@redhat.com>
	<495F78AA.5040308@nobugconsulting.ro>	<1230995235.3673.10.camel@eagle.danny.cz>
	<gjo2ak$2k0$1@ger.gmane.org>
Message-ID: <4960F014.8090707@gmail.com>

Rex Dieter wrote:
> Dan Hor?k wrote:
>  
>> IMHO a working application is always preferred :-) But the plugin
>> loading mechanism can be checked why it requires the *.la files.
> 
The only time I've seen .la files really being needed was with KDE-3.
And that wasn't so much an issue that couldn't be solved as the KDE sig
wanting to put effort into KDE-4 rather than working on the deficincies
in KDE-3.

> +1.  The problematic .la files that should be avoided are those associated with (linkable) shlibs.  Plugin .la files are mostly harmless.
> 
I thought Michael Schwendt pointed out times when plugin .la's would
cause issues as well.  Is this chain of reasoning correct:  Plugin .la
encodes need for library foo's .la.  foo .la is packaged in the -devel
subpackage.  Plugins now drag in the -devel package and its dep chain.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/dc9942c0/attachment.sig>

From jonathan.underwood at gmail.com  Sun Jan  4 17:44:54 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 17:44:54 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <a9d183c80901040923s3515da88s9a041ed698c54dbe@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<a9d183c80901040923s3515da88s9a041ed698c54dbe@mail.gmail.com>
Message-ID: <645d17210901040944k6162bee4xaaac6dcdf2121219@mail.gmail.com>

2009/1/4 Thomas Moschny <thomas.moschny at gmail.com>:
> 2009/1/4 Jonathan Underwood <jonathan.underwood at gmail.com>:
>> Another aside: Other the past few months I've noticed that many
>> packages don't create a separate emacs-foo subpackage but rather use a
>> trick with %triggerin to drop elisp files into place when emacs is
>> installed. I also think this should be discussed and documented in the
>> packaging guidelines as an alternative when a package only has 1 or 2
>> elisp files.
>
> Couldn't this be a general mechanism to be used also for vim
> syntaxfiles, shell completion rules, etc, etc... ?

yup... there's already examples of this. What I'm not too clear on is
whether triggers are really a good idea. I have vague memories that
the use of triggers was discouraged in fedora, but I don't recall why
- perhaps because using triggers makes things a bit less
deterministic. Perhaps I missremember.



From ngompa13 at gmail.com  Sun Jan  4 18:35:49 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Sun, 4 Jan 2009 12:35:49 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <1231078385.32405.737.camel@firewall.xsintricity.com>
References: <494930CD.70709@herr-schmitt.de> <4957E650.6010809@redhat.com>
	<1231078385.32405.737.camel@firewall.xsintricity.com>
Message-ID: <8278b1b0901041035v76592249l4838f08eed32204e@mail.gmail.com>

2009/1/4 Doug Ledford <dledford at redhat.com>

> On Sun, 2008-12-28 at 15:49 -0500, Casey Dahlin wrote:
> > Jochen Schmitt wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Hallo,
> > >
> > > nowaday I have read in the german fedora forum, that grub is not able
> > > to handle
> > > ext4 file systems. In opposite grub2 should be able to support ext4.
> > >
> > >
> > I haven't looked at the code for grub2 myself, but most of the people I
> > talk to that have cringe when they mention it. The people I talk to tend
> > to be heavily involved in the boot process. As a piece of software
> > engineering, it hasn't earned many fans among those most concerned with
> > the change as far as I can tell.
>
> Last I knew, grub2 was a dead project.  At least it was when I looked at
> it about 2 or 3 years ago.  It hadn't had a single code update in over 2
> years when I looked at it.  Has that changed?
>
> --
> Doug Ledford <dledford at redhat.com>
>              GPG KeyID: CFBFF194
>              http://people.redhat.com/dledford
>
> Infiniband specific RPMs available at
>              http://people.redhat.com/dledford/Infiniband
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


According to the SVN repo for grub2, its just the opposite!

SVN repo: http://svn.savannah.gnu.org/viewvc/trunk/grub2/?root=grub

In the repo, the latest change was 42hrs ago. It is far from dead. A video
subsystem has been implemented from the GSoC 2008 as well as some usb
support I believe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/c819466b/attachment.htm>

From ngompa13 at gmail.com  Sun Jan  4 18:36:53 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Sun, 4 Jan 2009 12:36:53 -0600
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <8278b1b0901041035v76592249l4838f08eed32204e@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de> <4957E650.6010809@redhat.com>
	<1231078385.32405.737.camel@firewall.xsintricity.com>
	<8278b1b0901041035v76592249l4838f08eed32204e@mail.gmail.com>
Message-ID: <8278b1b0901041036x2bf66a9dla896596654934f73@mail.gmail.com>

On Sun, Jan 4, 2009 at 12:35 PM, King InuYasha <ngompa13 at gmail.com> wrote:

> 2009/1/4 Doug Ledford <dledford at redhat.com>
>
>> On Sun, 2008-12-28 at 15:49 -0500, Casey Dahlin wrote:
>> > Jochen Schmitt wrote:
>> > > -----BEGIN PGP SIGNED MESSAGE-----
>> > > Hash: SHA1
>> > >
>> > > Hallo,
>> > >
>> > > nowaday I have read in the german fedora forum, that grub is not able
>> > > to handle
>> > > ext4 file systems. In opposite grub2 should be able to support ext4.
>> > >
>> > >
>> > I haven't looked at the code for grub2 myself, but most of the people I
>> > talk to that have cringe when they mention it. The people I talk to tend
>> > to be heavily involved in the boot process. As a piece of software
>> > engineering, it hasn't earned many fans among those most concerned with
>> > the change as far as I can tell.
>>
>> Last I knew, grub2 was a dead project.  At least it was when I looked at
>> it about 2 or 3 years ago.  It hadn't had a single code update in over 2
>> years when I looked at it.  Has that changed?
>>
>> --
>> Doug Ledford <dledford at redhat.com>
>>              GPG KeyID: CFBFF194
>>              http://people.redhat.com/dledford
>>
>> Infiniband specific RPMs available at
>>              http://people.redhat.com/dledford/Infiniband
>>
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> According to the SVN repo for grub2, its just the opposite!
>
> SVN repo: http://svn.savannah.gnu.org/viewvc/trunk/grub2/?root=grub
>
> In the repo, the latest change was 42hrs ago. It is far from dead. A video
> subsystem has been implemented from the GSoC 2008 as well as some usb
> support I believe.
>

Well, it was a "fancy menu" thing implemented using the video subsystem...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/d991472f/attachment.htm>

From nicoleau.fabien at gmail.com  Sun Jan  4 18:41:07 2009
From: nicoleau.fabien at gmail.com (Nicoleau Fabien)
Date: Sun, 04 Jan 2009 19:41:07 +0100
Subject: Orphaning printoxx and fotoxx
Message-ID: <496102C3.7040403@gmail.com>

Hello,
As I'm no more using these 2 packages and can't continue maintain them, 
I'm orphaning printoxx and fotoxx for devel, F10 and F9 branches.
(printoxx is used as a dependancy for fotoxx).


Regards,

Fabien



From tromey at redhat.com  Sun Jan  4 18:45:54 2009
From: tromey at redhat.com (Tom Tromey)
Date: Sun, 04 Jan 2009 11:45:54 -0700
Subject: emacs fan help with packaging .el
In-Reply-To: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	(Chitlesh GOORAH's message of "Sun\, 4 Jan 2009 17\:15\:46 +0100")
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
Message-ID: <m3mye6rjtp.fsf@fleche.redhat.com>

>>>>> "Chitlesh" == Chitlesh GOORAH <chitlesh.goorah at gmail.com> writes:

Chitlesh> I have never used emacs before.

It is never too late :-)

Chitlesh> http://chitlesh.fedorapeople.org/RPMS/dinotrace.spec

I'm curious about the byte-compilation step in this spec file.  Emacs
.elc files are not portable across Emacs versions; so won't this do
the wrong thing depending on the emacs alternatives setting?  It seems
to me that either Emacs or XEmacs users will be left out.

Also, from dinotrace.el:

;;	---INSTALLER-SITE-START---
[...]
;;	(global-set-key "\C-x\C-aa" 'dinotrace-update)
;;	(global-set-key "\C-x\C-ad" 'dinotrace-mode)
;;	---INSTALLER-SITE-END---

And then later:

(global-set-key "\C-x\C-aa" 'dinotrace-update)

IMO, unconditionally installing new global key bindings is unfriendly,
particularly for something relatively obscure like this.


sim-log.el has this:

;;	(setq auto-mode-alist (append (list '("\\.log$" . sim-log-mode)) auto-mode-alist))

I would be very surprised if a .log file showed up in sim-log-mode,
just because dinotrace was installed.

Now, from what I can tell, that the .spec does not extract the install
stuff from sim-log.el.  Maybe this was the reason?  The problem is
that I think you really do want to extract the autoload of
sim-log-mode -- just not the auto-mode-alist change.

Both of these are nits to pick with upstream, I suppose.

Tom



From lsof at nodata.co.uk  Sun Jan  4 18:52:55 2009
From: lsof at nodata.co.uk (nodata)
Date: Sun, 04 Jan 2009 19:52:55 +0100
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <495F8526.4030901@RedHat.com>
References: <495F8526.4030901@RedHat.com>
Message-ID: <1231095175.6905.2.camel@sb-home>

Am Samstag, den 03.01.2009, 10:32 -0500 schrieb Steve Dickson:
> Hello,
> 
> It seems in F10 the hostname and DNS domain name are now being added
> as alias at the end of 127.0.0.1 definition, ala
> 
>      127.0.0.1   localhost.localdomain localhost f10.domainname.com f10
> 
> which unfortunately breaks kerberos in its keytab lookups.


It would be nice to fix this once and for all :)

http://www.faqs.org/docs/securing/chap9sec95.html recommends:

127.0.0.1 localhost.localdomain localhost myhostname
1.2.3.4 myhostname





From lists at sapience.com  Sun Jan  4 18:56:56 2009
From: lists at sapience.com (Mail Lists)
Date: Sun, 04 Jan 2009 13:56:56 -0500
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <1231095175.6905.2.camel@sb-home>
References: <495F8526.4030901@RedHat.com> <1231095175.6905.2.camel@sb-home>
Message-ID: <49610678.6030401@sapience.com>

On 01/04/2009 01:52 PM, nodata wrote:
t would be nice to fix this once and for all :)
> 
> http://www.faqs.org/docs/securing/chap9sec95.html recommends:
> 
> 127.0.0.1 localhost.localdomain localhost myhostname
> 1.2.3.4 myhostname
> 

  I would definitely not do that .. i  would recommend

  127.0.0.1 localhost.localdomain localhost
  1.2.3.4   foo at my.dom  foo



From dan at danny.cz  Sun Jan  4 19:05:34 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Sun, 04 Jan 2009 20:05:34 +0100
Subject: firewire devices permissions and ownership
In-Reply-To: <1231074714.3708.49.camel@eagle.danny.cz>
References: <1231074714.3708.49.camel@eagle.danny.cz>
Message-ID: <1231095935.3708.58.camel@eagle.danny.cz>

Dan Hor?k p??e v Ne 04. 01. 2009 v 14:11 +0100:
> After plugging in a firewire MiniDV camera a new device (/dev/fw1) is
> correctly created. But they (/dev/fw*) have 0660 as the permission and
> root:root as owner, so it is impossible to control the camera or grab
> the videos as a regular user (eg. from Kino). What should be responsible
> for allowing the user access for firewire devices?

https://bugzilla.redhat.com/show_bug.cgi?id=441073


		Dan




From jonathan.underwood at gmail.com  Sun Jan  4 19:12:18 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 19:12:18 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <m3mye6rjtp.fsf@fleche.redhat.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<m3mye6rjtp.fsf@fleche.redhat.com>
Message-ID: <645d17210901041112n1e9c0a39k41dc8de12df3d34b@mail.gmail.com>

2009/1/4 Tom Tromey <tromey at redhat.com>:
>>>>>> "Chitlesh" == Chitlesh GOORAH <chitlesh.goorah at gmail.com> writes:
>
> Chitlesh> I have never used emacs before.
>
> It is never too late :-)
>
> Chitlesh> http://chitlesh.fedorapeople.org/RPMS/dinotrace.spec
>
> I'm curious about the byte-compilation step in this spec file.  Emacs
> .elc files are not portable across Emacs versions; so won't this do
> the wrong thing depending on the emacs alternatives setting?  It seems
> to me that either Emacs or XEmacs users will be left out.

An emacs-foo subpackages target GNU Emacs specifically, so that's ok.
Chitlesh could also create an xemacs subpackage if he chooses to.



From chitlesh.goorah at gmail.com  Sun Jan  4 19:44:09 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sun, 4 Jan 2009 20:44:09 +0100
Subject: dotted rectangles on all gui
Message-ID: <50baabb30901041144k4c4a1316v75252cc1819aab52@mail.gmail.com>

Hello there,

I'm encountering a weird bug with alliance. From the same fedora rpm,
I've installed alliance into different hardware configurations:
- i386, x86_64
- ati, nvidia

https://bugzilla.redhat.com/show_bug.cgi?id=451209

In the layout editor, viewer or schemtatic editor from alliance, the text in the
menus is missing. Instead, dotted rectangles appear where characters should be.

However it only appears to be a random bug since not on every hardware
configurations it is working.

http://chitlesh.fedorapeople.org/images/alliance.png

Version-Release number of selected component
alliance-5.0-16.20070718

I have gathered a list of all the rpms installed on 2 boxes (working
and not_working)

http://chitlesh.fedorapeople.org/images/not_working.txt

http://chitlesh.fedorapeople.org/images/working.txt

Can you please help me troubleshoot this bug ?
dinotrace which appears to be developed the same way as alliance
doesn't suffer from this weird bug

Chitlesh



From lsof at nodata.co.uk  Sun Jan  4 19:58:50 2009
From: lsof at nodata.co.uk (nodata)
Date: Sun, 04 Jan 2009 20:58:50 +0100
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <49610678.6030401@sapience.com>
References: <495F8526.4030901@RedHat.com> <1231095175.6905.2.camel@sb-home>
	<49610678.6030401@sapience.com>
Message-ID: <1231099130.6905.4.camel@sb-home>

Am Sonntag, den 04.01.2009, 13:56 -0500 schrieb Mail Lists:
> On 01/04/2009 01:52 PM, nodata wrote:
> t would be nice to fix this once and for all :)
> > 
> > http://www.faqs.org/docs/securing/chap9sec95.html recommends:
> > 
> > 127.0.0.1 localhost.localdomain localhost myhostname
> > 1.2.3.4 myhostname
> > 
> 
>   I would definitely not do that .. i  would recommend
> 
>   127.0.0.1 localhost.localdomain localhost
>   1.2.3.4   foo at my.dom  foo
> 

What if 1.2.3.4 is a floating service address, and 1.2.3.1 and 1.2.3.2
are the active and passive hosts?



From rdieter at math.unl.edu  Sun Jan  4 20:06:36 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 04 Jan 2009 14:06:36 -0600
Subject: Dia does not work without .la files - BZ 475992
References: <495F4E29.3050806@redhat.com> <495F78AA.5040308@nobugconsulting.ro>
	<1230995235.3673.10.camel@eagle.danny.cz>
	<gjo2ak$2k0$1@ger.gmane.org> <4960F014.8090707@gmail.com>
Message-ID: <gjr4pv$7g8$1@ger.gmane.org>

Toshio Kuratomi wrote:

> I thought Michael Schwendt pointed out times when plugin .la's would
> cause issues as well.  Is this chain of reasoning correct:  Plugin .la
> encodes need for library foo's .la.  foo .la is packaged in the -devel
> subpackage.  Plugins now drag in the -devel package and its dep chain.

Could be, but afaik missing .la items haven't caused runtime problems afaik (as long as symbols are otherwise resolvable), but that would change when/if rpm's automatic .la file dependencies were ever used.

So, yeah, still a good general idea (per guidelines) to avoid the hassle whenever possible.

-- Rex




From lists at sapience.com  Sun Jan  4 21:22:47 2009
From: lists at sapience.com (Mail Lists)
Date: Sun, 04 Jan 2009 16:22:47 -0500
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <1231099130.6905.4.camel@sb-home>
References: <495F8526.4030901@RedHat.com>
	<1231095175.6905.2.camel@sb-home>	<49610678.6030401@sapience.com>
	<1231099130.6905.4.camel@sb-home>
Message-ID: <496128A7.6060800@sapience.com>

On 01/04/2009 02:58 PM, nodata wrote:

> 
> What if 1.2.3.4 is a floating service address, and 1.2.3.1 and 1.2.3.2
> are the active and passive hosts?
> 


  I am no expert in clustering, or hot stand by machines - so in the
config you have in mind - is the floating IP not associated with a fixed
name so the consumers dont know that the machine is being switched over?

If so both active and passive could have as their /etc/hosts files:

  127.0.0.1 	localhost.localdomain	localhost
  1.2.3.1	m1.my.dom	m1
  1.2.3.2	m2.my.dom	m2
  1.2.3.4	float.my.dom	float


 Then I assume you need to weewee on arp a little and do something like
  ip address add xxx ..
 and delete it off the failing one etc etc ... ?

On the other hand - you probably dont need any of this as DNS is
probably doing it all no ?

  I'll leave this to the failover, clusterer experts ..

gene



From mjs at clemson.edu  Sun Jan  4 21:42:18 2009
From: mjs at clemson.edu (Matthew Saltzman)
Date: Sun, 04 Jan 2009 16:42:18 -0500
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
Message-ID: <1231105338.5617.58.camel@valkyrie.localdomain>

On Sun, 2009-01-04 at 16:30 +0000, Jonathan Underwood wrote:
> 2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
> 
> Another aside: Other the past few months I've noticed that many
> packages don't create a separate emacs-foo subpackage but rather use a
> trick with %triggerin to drop elisp files into place when emacs is
> installed. I also think this should be discussed and documented in the
> packaging guidelines as an alternative when a package only has 1 or 2
> elisp files.
> 
> A further aside: I think the emacs guidelines should only insist on
> separate emacs-foo-el sub-packages when there are a large number of
> .el files. Perhaps. Maybe.

What happens when one installs a package with .el files and installs
emacs later?  How would one go about getting the .el files for your
package in that case? 

In the case of subpackages, I'd be able to just yum list \*emacs\* to
see what I need to add after the fact.

> 
> HTH,
> J.
> 
> 
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs



From jspaleta at gmail.com  Sun Jan  4 22:08:03 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 4 Jan 2009 13:08:03 -0900
Subject: Atlas and lapack provide the same library..compiled differently...
	is that a problem?
Message-ID: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>

Okay I ran across an interesting issue trying to get scipy compiled
with atlas support.

lapack and atlas both provide liblapack.so.3, in different locations,
but accessible to the linker.

scipy builds against atlas just fine, and runs on systems just
fine...unless lapack is installed on the system. Once lapack is
installed the link prefers the lapack package's version of the same
library and runtime errors occur.

I think I can work around this in scipy packaging... but the question
is, is it a general problem that lapack and atlas are providing link
incompatible versions of the same library?  The packages which
reqoquery --alldeps  lists for atlas   and lapack have a significant
overlap.  Are all those overlapping applications affected by this
runtime linking problem?

-jef



From kevin.kofler at chello.at  Sun Jan  4 22:36:03 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Jan 2009 23:36:03 +0100
Subject: dotted rectangles on all gui
References: <50baabb30901041144k4c4a1316v75252cc1819aab52@mail.gmail.com>
Message-ID: <gjrdkj$unf$1@ger.gmane.org>

Chitlesh GOORAH wrote:
> I have gathered a list of all the rpms installed on 2 boxes (working
> and not_working)
> 
> http://chitlesh.fedorapeople.org/images/not_working.txt
> 
> http://chitlesh.fedorapeople.org/images/working.txt
> 
> Can you please help me troubleshoot this bug ?

not_working.txt has some additional font packages:
larabie-fonts-deco-0-0.2.20011216.fc10.noarch
texlive-texmf-errata-fonts-2007-4.fc9.noarch
texlive-texmf-fonts-2007-26.fc10.noarch
xorg-x11-fonts-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-75dpi-7.2-6.fc9.noarch
xorg-x11-fonts-ISO8859-1-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-ISO8859-9-100dpi-7.2-6.fc9.noarch
xorg-x11-fonts-Type1-7.2-6.fc9.noarch

Maybe one of those is broken?

        Kevin Kofler



From jonathan.underwood at gmail.com  Sun Jan  4 22:36:26 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 22:36:26 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <1231105338.5617.58.camel@valkyrie.localdomain>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<1231105338.5617.58.camel@valkyrie.localdomain>
Message-ID: <645d17210901041436p4f1d3e77i607eaedd441b7c74@mail.gmail.com>

2009/1/4 Matthew Saltzman <mjs at clemson.edu>:
> On Sun, 2009-01-04 at 16:30 +0000, Jonathan Underwood wrote:
>> 2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
>>
>> Another aside: Other the past few months I've noticed that many
>> packages don't create a separate emacs-foo subpackage but rather use a
>> trick with %triggerin to drop elisp files into place when emacs is
>> installed. I also think this should be discussed and documented in the
>> packaging guidelines as an alternative when a package only has 1 or 2
>> elisp files.
>>
>> A further aside: I think the emacs guidelines should only insist on
>> separate emacs-foo-el sub-packages when there are a large number of
>> .el files. Perhaps. Maybe.
>
> What happens when one installs a package with .el files and installs
> emacs later?  How would one go about getting the .el files for your
> package in that case?
>

See the triggerin scriptlet in eg. rpmdevtools - on emacs installation
symlinks aer created in the /usr/share/emacs/site-lisp tree to the
.el(c) files as needed.


> In the case of subpackages, I'd be able to just yum list \*emacs\* to
> see what I need to add after the fact.

Yep, agreed, and that's one of the reasons why, when i drafted the
emacs packaging guidelines I detailed creating a separate
emacs-fool-[el] subpackage. However, the ubiquity of the triggerin
approach in current packages suggests there is some merit. Personally,
I think it needs further discussion, and was planning to take it to
the packaging list when I have a free moment.



From kevin.kofler at chello.at  Sun Jan  4 22:38:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Jan 2009 23:38:17 +0100
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
Message-ID: <gjrdop$unf$2@ger.gmane.org>

Jeff Spaleta wrote:
> scipy builds against atlas just fine, and runs on systems just
> fine...unless lapack is installed on the system. Once lapack is
> installed the link prefers the lapack package's version of the same
> library and runtime errors occur.

Weird, normally ATLAS should be preferred and it's also supposed to be
binary-compatible with LAPACK.

But I wonder if we can't just make ATLAS the default and retire the slow
reference LAPACK (and BLAS) implementation entirely, except possibly on
architectures not supported by ATLAS.

        Kevin Kofler



From jonathan.underwood at gmail.com  Sun Jan  4 22:44:34 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 22:44:34 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <gjrdop$unf$2@ger.gmane.org>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
Message-ID: <645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>

2009/1/4 Kevin Kofler <kevin.kofler at chello.at>:
> Jeff Spaleta wrote:
>> scipy builds against atlas just fine, and runs on systems just
>> fine...unless lapack is installed on the system. Once lapack is
>> installed the link prefers the lapack package's version of the same
>> library and runtime errors occur.
>
> Weird, normally ATLAS should be preferred and it's also supposed to be
> binary-compatible with LAPACK.
>

The Atlas webpage suggests that the atlas lapack library does not have
complete coverage of all functions in the original Lapack - is that
not the case?

J



From kevin.kofler at chello.at  Sun Jan  4 22:53:06 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 04 Jan 2009 23:53:06 +0100
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
Message-ID: <gjreki$unf$6@ger.gmane.org>

Jonathan Underwood wrote:
> The Atlas webpage suggests that the atlas lapack library does not have
> complete coverage of all functions in the original Lapack - is that
> not the case?

To be honest, I don't know for sure.

What I do know is that some stuff I built against the original Lapack picked
up ATLAS automatically when I installed it and worked fine against it.

But this is in no way a complete regression test.

        Kevin Kofler



From jspaleta at gmail.com  Sun Jan  4 22:51:02 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 4 Jan 2009 13:51:02 -0900
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <gjrdop$unf$2@ger.gmane.org>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
Message-ID: <604aa7910901041451k51c98938rca8793a1a2931157@mail.gmail.com>

On Sun, Jan 4, 2009 at 1:38 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Weird, normally ATLAS should be preferred and it's also supposed to be
> binary-compatible with LAPACK.


Honestly I don't know what is going on. I can't reproduce the problem
being reported.
https://bugzilla.redhat.com/show_bug.cgi?id=478435#c12

Attempting to reproduce on my systems, and even with lapack and atlas
installed, atlas library is preferred.  This could still be a strange
local customization to linker configuration.

-jef



From jspaleta at gmail.com  Sun Jan  4 23:13:16 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 4 Jan 2009 14:13:16 -0900
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <gjreki$unf$6@ger.gmane.org>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
Message-ID: <604aa7910901041513p30b69ae8pc67e83952adafcfc@mail.gmail.com>

On Sun, Jan 4, 2009 at 1:53 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> But this is in no way a complete regression test.


I'm quite frankly not as competent as I would like to be with regard
to runtime linker logic.
So the issue may not be as dire as it could be...if the affected
system in the bugreport is suffering due to local linker logic
reconfiguration. Jury is out on that.

But I do think its somewhat problematic in our packaging that lapack
and atlas expose the same provides.
F10: repoquery --whatprovides liblapack.so.3
atlas-0:3.6.0-15.fc10.i386
atlas-3dnow-0:3.6.0-15.fc10.i386
atlas-sse-0:3.6.0-15.fc10.i386
atlas-sse2-0:3.6.0-15.fc10.i386
lapack-0:3.1.1-4.fc10.i386

Does yum prefer to install atlas over lapack when looking to fill
liblapack.so.3 deps?
Is that a problem for applications which are compiled against lapack
but not atlas at build time?  This is the more general problem that
worries me, Its probably a corner case in the dependency resolution
space that you can only get to if you start from a pathologically
broken starting point..like forcibly removing lapack and atlas from
your system, then attempting to install something qhich requires that
library.

-jef



From nicolas.mailhot at laposte.net  Sun Jan  4 23:47:03 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 05 Jan 2009 00:47:03 +0100
Subject: emacs fan help with packaging .el
In-Reply-To: <1231105338.5617.58.camel@valkyrie.localdomain>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<1231105338.5617.58.camel@valkyrie.localdomain>
Message-ID: <1231112823.3880.2.camel@arekh.okg>

Le dimanche 04 janvier 2009 ? 16:42 -0500, Matthew Saltzman a ?crit :
> On Sun, 2009-01-04 at 16:30 +0000, Jonathan Underwood wrote:
> > 2009/1/4 Chitlesh GOORAH <chitlesh.goorah at gmail.com>:
> > 
> > Another aside: Other the past few months I've noticed that many
> > packages don't create a separate emacs-foo subpackage but rather use a
> > trick with %triggerin to drop elisp files into place when emacs is
> > installed. I also think this should be discussed and documented in the
> > packaging guidelines as an alternative when a package only has 1 or 2
> > elisp files.
> > 
> > A further aside: I think the emacs guidelines should only insist on
> > separate emacs-foo-el sub-packages when there are a large number of
> > .el files. Perhaps. Maybe.
> 
> What happens when one installs a package with .el files and installs
> emacs later?  How would one go about getting the .el files for your
> package in that case? 

The way we handle this for fonts and fontconfig is that the fontconfig
package runs its magic command on stuff available in special dirs on
install, and individual packages run the same magic command on
themselves in post if fontconfig is available.

It's simpler and more robust than triggers.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/a72c7adc/attachment.sig>

From jonathan.underwood at gmail.com  Sun Jan  4 23:56:36 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Sun, 4 Jan 2009 23:56:36 +0000
Subject: emacs fan help with packaging .el
In-Reply-To: <1231112823.3880.2.camel@arekh.okg>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<1231105338.5617.58.camel@valkyrie.localdomain>
	<1231112823.3880.2.camel@arekh.okg>
Message-ID: <645d17210901041556u429a764as2ebdf5107032ecaa@mail.gmail.com>

2009/1/4 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> The way we handle this for fonts and fontconfig is that the fontconfig
> package runs its magic command on stuff available in special dirs on
> install, and individual packages run the same magic command on
> themselves in post if fontconfig is available.
>
> It's simpler and more robust than triggers.

I am sure you're right, but I'd like to understand why it's more
robust, and more robust against what?

Cheers,
Jonathan.



From jonathan.underwood at gmail.com  Mon Jan  5 00:02:29 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 00:02:29 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <604aa7910901041513p30b69ae8pc67e83952adafcfc@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<604aa7910901041513p30b69ae8pc67e83952adafcfc@mail.gmail.com>
Message-ID: <645d17210901041602x2a005292t97515e8438abe025@mail.gmail.com>

2009/1/4 Jeff Spaleta <jspaleta at gmail.com>:
> On Sun, Jan 4, 2009 at 1:53 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>> But this is in no way a complete regression test.
>
>
> I'm quite frankly not as competent as I would like to be with regard
> to runtime linker logic.
> So the issue may not be as dire as it could be...if the affected
> system in the bugreport is suffering due to local linker logic
> reconfiguration. Jury is out on that.
>
> But I do think its somewhat problematic in our packaging that lapack
> and atlas expose the same provides.
> F10: repoquery --whatprovides liblapack.so.3
> atlas-0:3.6.0-15.fc10.i386
> atlas-3dnow-0:3.6.0-15.fc10.i386
> atlas-sse-0:3.6.0-15.fc10.i386
> atlas-sse2-0:3.6.0-15.fc10.i386
> lapack-0:3.1.1-4.fc10.i386
>

FWIW the same situation is true for libblas:

$ repoquery --whatprovides libblas.so.3
atlas-sse-0:3.6.0-15.fc10.i386
atlas-3dnow-0:3.6.0-15.fc10.i386
blas-0:3.1.1-4.fc10.i386
atlas-sse2-0:3.6.0-15.fc10.i386
atlas-0:3.6.0-15.fc10.i386

(where blas is a subpackage of lapack).

Fortunately the blas interface is defined and so these should be abi
compatible. A knowledgeable user writing her own programs would ensure
that the atlas subdirectory is seen first by the linker when she wants
the optimised libraries, I suppose.



From jonathan.underwood at gmail.com  Mon Jan  5 00:04:09 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 00:04:09 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <604aa7910901041513p30b69ae8pc67e83952adafcfc@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<604aa7910901041513p30b69ae8pc67e83952adafcfc@mail.gmail.com>
Message-ID: <645d17210901041604v6a69f3abof2e0de0167117ca6@mail.gmail.com>

2009/1/4 Jeff Spaleta <jspaleta at gmail.com>:
> Does yum prefer to install atlas over lapack when looking to fill
> liblapack.so.3 deps?
> Is that a problem for applications which are compiled against lapack
> but not atlas at build time?  This is the more general problem that
> worries me, Its probably a corner case in the dependency resolution
> space that you can only get to if you start from a pathologically
> broken starting point..like forcibly removing lapack and atlas from
> your system, then attempting to install something qhich requires that
> library.


lapack requires libblas which will means yum will pull in either the
atlas or blas package if neither are installed. Not sure which :)



From jonathan.underwood at gmail.com  Mon Jan  5 00:15:36 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 00:15:36 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <gjreki$unf$6@ger.gmane.org>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
Message-ID: <645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>

2009/1/4 Kevin Kofler <kevin.kofler at chello.at>:
> Jonathan Underwood wrote:
>> The Atlas webpage suggests that the atlas lapack library does not have
>> complete coverage of all functions in the original Lapack - is that
>> not the case?
>
> To be honest, I don't know for sure.
>
> What I do know is that some stuff I built against the original Lapack picked
> up ATLAS automatically when I installed it and worked fine against it.
>
> But this is in no way a complete regression test.

Poking about with nm on the two different liblapack.so.3 files shows
they contain substantially different symbols, so I'd be surprised if
they were abi compatible.

Note also that building against lapack means that you package
installation may pull in atlas to satisfy the blas requirement of
lapack. Or it may pull in the blas package (a subpackage of lapack
which has a different blas implementation).



From promac at gmail.com  Mon Jan  5 00:21:02 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sun, 4 Jan 2009 22:21:02 -0200
Subject: sound problems
In-Reply-To: <4960CEAA.4070507@gmail.com>
References: <4960CEAA.4070507@gmail.com>
Message-ID: <68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>

On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan <surenkarapetyan at gmail.com
> wrote:

> Yeah.. I know. fedora-devel is not a place for discussing bugs but I'll
> risk.
>
> As (I hope) many of You already know kernel-2.6.27.9-159 which was pushed
> as a security update has broken sound on many systems (mostly notebooks) -
> https://bugzilla.redhat.com/show_bug.cgi?id=477954. The reason for this is
> the new ALSA (1.0.18a).
>
> There are a lot of "+1"s and "me too"s in bugzilla and if we consider the
> amount of people who don't know how to report bugs, add those who are on New
> Year holidays it becomes clear that this affects a lot of our users.
>
> So users have two choices now:
> 1. Have no sound.
> 2. Stick with 2.6.27.9-134 (this is not as easy as it seems cause the new
> update will be downloaded and installed automatically).
>
> I do understand that many developers are on holidays themselves, but I'm
> also sure this is a REAL problem which should be resolved ASAP.
> So I just wanted to know what are we going to do about this.
>



You can try the latest alsa snapshot available in ATrpms:

http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm

http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm

It has a lot of recent fixes and it is working just fine for me and for
others. I also had no sound with kernel 159, before installing this new
alsa.

If you remove the rpm later, you go back to the original sound modules
(nothing is overwritten).

Good luck.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/a545f34f/attachment.htm>

From jspaleta at gmail.com  Mon Jan  5 00:38:19 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 4 Jan 2009 15:38:19 -0900
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
Message-ID: <604aa7910901041638i70f26662l658bbe4965375c99@mail.gmail.com>

On Sun, Jan 4, 2009 at 3:15 PM, Jonathan Underwood
<jonathan.underwood at gmail.com> wrote:
> Note also that building against lapack means that you package
> installation may pull in atlas to satisfy the blas requirement of
> lapack. Or it may pull in the blas package (a subpackage of lapack
> which has a different blas implementation).


This is the sort of thing that concerns me.  But I can't reproduce the
reported problem and that unnerves me even more.  If this were a
fragile dep resolution  and linker logic interaction, that just
happens to work in the default install situations.. i should be able
to break it  by doing weird things like forcing nodep package erases
by hand and then asking yum to resolve deps.   But I can't.

-jef



From vonbrand at inf.utfsm.cl  Mon Jan  5 02:10:06 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 04 Jan 2009 23:10:06 -0300
Subject: dotted rectangles on all gui
In-Reply-To: <50baabb30901041144k4c4a1316v75252cc1819aab52@mail.gmail.com>
References: <50baabb30901041144k4c4a1316v75252cc1819aab52@mail.gmail.com>
Message-ID: <200901050210.n052A6Lb011069@laptop14.inf.utfsm.cl>

Chitlesh GOORAH <chitlesh.goorah at gmail.com> wrote:
> I'm encountering a weird bug with alliance. From the same fedora rpm,
> I've installed alliance into different hardware configurations:
> - i386, x86_64
> - ati, nvidia
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=451209

> In the layout editor, viewer or schemtatic editor from alliance, the text
> in the menus is missing. Instead, dotted rectangles appear where
> characters should be.

That is what I see when characters/fonts are missing.
-- 
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 Jan  5 02:21:39 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 04 Jan 2009 23:21:39 -0300
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
Message-ID: <200901050221.n052LdYd011151@laptop14.inf.utfsm.cl>

Jonathan Underwood <jonathan.underwood at gmail.com> wrote:

[...]

> Another aside: Other the past few months I've noticed that many
> packages don't create a separate emacs-foo subpackage but rather use a
> trick with %triggerin to drop elisp files into place when emacs is
> installed. I also think this should be discussed and documented in the
> packaging guidelines as an alternative when a package only has 1 or 2
> elisp files.

So the behaviour depends on whether {,x}emacs was installed before the
package or not? If the *.el files are borken, "rpm -V" won't notice?
Grates me the wrong way.
-- 
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 dbn.lists at gmail.com  Mon Jan  5 02:26:22 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sun, 4 Jan 2009 18:26:22 -0800
Subject: Why is X and IPv6 required for autoreconf?
In-Reply-To: <20090104022056.GA5011@hurricane.linuxnetz.de>
References: <200901021622.42289.sgrubb@redhat.com>
	<20090104022056.GA5011@hurricane.linuxnetz.de>
Message-ID: <91705d080901041826g7ae72bdew7d15f1f5c517efdf@mail.gmail.com>

2009/1/3 Robert Scheck <robert at fedoraproject.org>:
> Hello Steve,
>
> On Fri, 02 Jan 2009, Steve Grubb wrote:
>> /bin/sh ../libtool --tag=CC   --mode=link
>> gcc -fPIC -DPIC -D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic   -o
>> gen_actiontabs_h gen_actiontabs_h-gen_tables.o
>> ../libtool: line 821: X--tag=CC: command not found
>
> you need to run "libtoolize" in e.g. %prep because of the bigger libtool
> bump vom 1.5 to 2.x some time ago. That will solve your issue completely.
> Ask yourself, why you've written/done insane libtool stuff in the past ;)

If you just run "autoreconf -i", it will take care of this for you.
There is a silly issue with autoreconf where it doesn't run libtoolize
unless you pass the --install parameter to autoreconf. The reason has
something to do with libtoolize "installing" new files when it runs,
so autoreconf refuses to run it unless you pass -i. If you run
autoreconf with the --verbose/-v parameter (always a good idea), it
will tell you that it's skipping libtoolize.

--
Dan



From vonbrand at inf.utfsm.cl  Mon Jan  5 02:36:34 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sun, 04 Jan 2009 23:36:34 -0300
Subject: rawhide report: 20090104 changes
In-Reply-To: <20090104084914.E5E331F825E@releng2.fedora.phx.redhat.com>
References: <20090104084914.E5E331F825E@releng2.fedora.phx.redhat.com>
Message-ID: <200901050236.n052aYp9013141@laptop14.inf.utfsm.cl>

Rawhide Report <rawhide at fedoraproject.org> wrote:

[...]

> safekeep-1.0.5-1.fc11
> ---------------------
> * Sat Jan  3 17:00:00 2009 Jef Spaleta <jspaleta AT fedoraproject DOT org> 1.0.5-1
> - Latest upstream release

"yum info safekeep" doesn't find it here (x86_64).
-- 
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 rdieter at math.unl.edu  Mon Jan  5 02:51:12 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sun, 04 Jan 2009 20:51:12 -0600
Subject: emacs fan help with packaging .el
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<200901050221.n052LdYd011151@laptop14.inf.utfsm.cl>
Message-ID: <gjrsgj$5m5$1@ger.gmane.org>

Horst H. von Brand wrote:

> Jonathan Underwood <jonathan.underwood at gmail.com> wrote:
> 
> [...]
> 
>> Another aside: Other the past few months I've noticed that many
>> packages don't create a separate emacs-foo subpackage but rather use a
>> trick with %triggerin to drop elisp files into place when emacs is
>> installed. I also think this should be discussed and documented in the
>> packaging guidelines as an alternative when a package only has 1 or 2
>> elisp files.
> 
> So the behaviour depends on whether {,x}emacs was installed before the
> package or not? 

%triggers fire on when (x)emacs is installed/removed/upgraded, ie, order doesn't matter.

-- Rex



From jkeating at redhat.com  Mon Jan  5 02:51:39 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 04 Jan 2009 18:51:39 -0800
Subject: Missing target in the cvs tree
In-Reply-To: <4960D466.6020104@gmx.net>
References: <4960CEFF.1060900@gmx.net>
	<b401d2530901040711wd81fd89n667f9d76efdecb02@mail.gmail.com>
	<4960D466.6020104@gmx.net>
Message-ID: <1231123899.4566.20.camel@localhost.localdomain>

On Sun, 2009-01-04 at 16:23 +0100, Frank B?ttner wrote:
> In all of my packages.
> qwt-doc,qwt,qtiplot,nas,muParser,ctapi-cyberjack,ctapi-common

cvs update -d from the top level of each package module.  The -d is
important as it will bring in new directories (yay CVS?)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090104/5ff1c054/attachment.sig>

From katzj at redhat.com  Mon Jan  5 04:29:30 2009
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 04 Jan 2009 23:29:30 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <1230623299.6985.247.camel@localhost.localdomain>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com>  <4958B05F.3060006@redhat.com>
	<1230623299.6985.247.camel@localhost.localdomain>
Message-ID: <1231129770.19227.2.camel@aglarond.local>

On Tue, 2008-12-30 at 01:48 -0600, Callum Lerwick wrote:
> 2) Rebuilding the initrd when moving a system to a differing
> motherboard, which often results in a non-bootable system due to
> (apparently) not having the right ATA driver built into the initrd.
> Unfortunately, the new IDE drivers no longer seem to fall back on
> oldsk00l PIO IDE like the old ones did, even on non-SATA systems.

This is one of the cases that dracut[1] is intended to handle nicer,
fwiw

Jeremy

[1] http://katzj.livejournal.com/443807.html



From nicolas.mailhot at laposte.net  Mon Jan  5 07:05:10 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 05 Jan 2009 08:05:10 +0100
Subject: emacs fan help with packaging .el
In-Reply-To: <645d17210901041556u429a764as2ebdf5107032ecaa@mail.gmail.com>
References: <50baabb30901040815g70d18113o4f38686fbf1ee201@mail.gmail.com>
	<645d17210901040830m79c5f907h860936ee2bbc2958@mail.gmail.com>
	<1231105338.5617.58.camel@valkyrie.localdomain>
	<1231112823.3880.2.camel@arekh.okg>
	<645d17210901041556u429a764as2ebdf5107032ecaa@mail.gmail.com>
Message-ID: <1231139110.7036.1.camel@arekh.okg>

Le dimanche 04 janvier 2009 ? 23:56 +0000, Jonathan Underwood a ?crit :
> 2009/1/4 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> > The way we handle this for fonts and fontconfig is that the fontconfig
> > package runs its magic command on stuff available in special dirs on
> > install, and individual packages run the same magic command on
> > themselves in post if fontconfig is available.
> >
> > It's simpler and more robust than triggers.
> 
> I am sure you're right, but I'd like to understand why it's more
> robust, and more robust against what?
 
triggers are very difficult to maintain and master long term since it's
code from one package that fires when another package is installed with
not warning, making install logs useless to understand problems.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/612f018d/attachment.sig>

From rawhide at fedoraproject.org  Mon Jan  5 08:54:43 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon,  5 Jan 2009 08:54:43 +0000 (UTC)
Subject: rawhide report: 20090105 changes
Message-ID: <20090105085443.41F1C1F8258@releng2.fedora.phx.redhat.com>

Compose started at Mon Jan  5 06:01:03 UTC 2009

New package conspy
        Remote control for text mode virtual consoles
New package dhcping
        DHCP daemon ping program
New package fspy
        Filesystem activity monitoring utility
New package gnaural
        A multi-platform programmable binaural-beat generator
New package mr
        A multiple repository management tool
New package perl-Directory-Scratch-Structured
        Creates temporary files and directories from a structured description
New package pnglite
        A lightweight C library for loading PNG images
New package python-transitfeed
        Google Transit Feed Specification library and tools
New package screenie
        A small and lightweight screen wrapper
New package sion
        GIO/GVFS management application
New package srm
        Secure file deletion
New package virtaal
        Localization and translation editor
New package xfce4-screenshooter
        Screenshot utility for the Xfce desktop
Updated Packages:

akonadi-1.1.0-1.fc11
--------------------
* Sun Jan  4 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1.1.0-1
- 1.1.0


asterisk-1.6.1-0.12.beta4.fc11
------------------------------
* Sun Jan  4 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.12.beta4
- Fedora Directory Server compatibility patch/subpackage.

* Sun Jan  4 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.10.beta4
- Fix up paths. BZ#477238

* Sat Jan  3 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.9.beta4
- Update patches

* Sat Jan  3 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.8.beta4
- Update to 1.6.1-beta4

* Tue Dec  9 17:00:00 2008 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.1-0.7.beta3
- Update to 1.6.1-beta3

* Tue Dec  9 17:00:00 2008 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.6.1-0.6.beta2
- Rebuild for new gmime


cmake-2.6.3-0.2.rc5.fc11
------------------------
* Sun Jan  4 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 2.6.3-0.2.rc5
- macros.cmake: add -DCMAKE_SKIP_RPATH:BOOL=ON
- fix Release tag


ctapi-cyberjack-3.3.0-4.fc11
----------------------------
* Sun Jan  4 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net> - 3.3.0-4
- fix missing dependency (libsysfs-devel) for EPEL4

* Sun Jan  4 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net> - 3.3.0-3
- fix missing dependency (libsysfs-devel)

* Mon Dec 29 17:00:00 2008 Frank B??ttner <frank-buettner at gmx.net> - 3.3.0-2
- no changes

* Mon Dec 29 17:00:00 2008 Frank B??ttner <frank-buettner at gmx.net> - 3.3.0-1
- update to 3.3.0


dahdi-tools-2.1.0.2-4.fc11
--------------------------
* Sun Jan  4 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.1.0.2-4
- Update to latest.


eigen2-2.0-0.6.beta4.fc11
-------------------------
* Sun Jan  4 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.6.beta4
- eigen-2.0-beta4


expendable-0.0.8-1.fc11
-----------------------
* Sun Jan  4 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 0.0.8-1
- 0.0.8.


fbterm-1.3-0.fc11
-----------------
* Mon Jan  5 17:00:00 2009 Ding-Yi Chen <dchen at redhat dot com> - 1.3-0
- Upstream update:
  1. added command line arguments to change option values 
  2. added client-server based input method framework 
  3. added screen rotation support 
  4. added support for visual type DIRECTCOLOR used by ATI cards 
     (thanks for Witek's patch) 
  5. fixed a bug that user can't input some unicode characters 
  6. fixed a bug of maybe not restore original console state after 
     FbTerm exited 
  7. fixed several trivial bugs 
  8. added using filesystem capability attributes offered by kernel 
     2.6.27, instead of setting set-user-ID bit on FbTerm 
  9. decreased memory usage of every shell instance by changing size 
      of the struct saving every charater's attribute from 4 to 2 bytes


fotoxx-5.8-1.fc11
-----------------
* Sun Jan  4 17:00:00 2009 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 5.8-1
- Rebuild for 5.8


gimp-2.6.4-2.fc11
-----------------
* Sun Jan  4 17:00:00 2009 Nils Philippsen <nils at redhat.com> - 2:2.6.4-2
- enable building with aalib


gnome-applet-timer-2.0.1-8.fc11
-------------------------------
* Sun Jan  4 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.0.2-8
- Use Paul's patch instead of Michael's suggestion (#471465)

* Sun Jan  4 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.0.2-7
- Apply libnotify patch, thanks to Michael Schwendt and Paul Frields (#471465)


jack-audio-connection-kit-0.116.1-3.fc11
----------------------------------------
* Sun Jan  4 17:00:00 2009 Andy Shevchenko <andy at smile.org.ua> - 0.116.1-3
- avoid creation of the LaTeX documentation (temporary fix for #477402)


k12linux-quick-start-guide-0.0.10-1.fc11
----------------------------------------
* Sun Jan  4 17:00:00 2009 Peter Scheie <peter at scheie.homedns.org> - 0.0.10-1
- Moved 'version 5' phrase describing version of LTSP to bottom of html
  document.
- Changed wording of WARNING about the dhcp server to CAUTION and emphasized
  that the bridge should only be connected to an isolated switch with the TCs.


libgdiplus-2.2-4.RC1.20090104svn122354.fc11
-------------------------------------------
* Sun Jan  4 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.RC1.20090104svn122354
- Update to svn


maatkit-2725-1.fc11
-------------------
* Sun Jan  4 17:00:00 2009 Sven Lankes <sven at lank.es> - 2725-1
- new upstream release


mono-2.2-15.RC1.20090401svn122388.fc11
--------------------------------------
* Sun Jan  4 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-15.RC1.20090401svn122388
- Updates from svn


mono-tools-2.2-9.RC1.20090104svn122377.fc11
-------------------------------------------
* Sun Jan  4 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> -.2.2-9.RC1.20090104svn122377
- update from svn


monodevelop-1.9.2-pre1.20090104svn122336.fc11
---------------------------------------------
* Sun Jan  4 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.2-pre1.200900104svn122336
- Update from svn
- Reversioned as 1.9.1 is out there already


munin-1.2.6-4.fc11
------------------
* Sun Jan  4 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.6-4
- Require bitstream-vera-fonts-sans-mono for Font (fixes #477428)


perl-Class-MOP-0.75-1.fc11
--------------------------
* Sun Jan  4 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.75-1
- update to 0.75


perl-Config-General-2.42-1.fc11
-------------------------------
* Sun Jan  4 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 2.42-1
- 2.42.
- Patch test suite to use system installed Tie::IxHash.
- Fix some spelling errors in %description.
- Use Source0: instead of Source:.


perl-Moose-0.64-1.fc11
----------------------
* Sun Jan  4 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.64-1
- update to 0.64


perl-TAP-Harness-JUnit-0.26-1.fc11
----------------------------------
* Sun Jan  4 17:00:00 2009 Lubomir Rintel (Good Data) <lubo.rintel at gooddata.com> 0.26-1
- New upstream release
- Re-enable regression tests


policycoreutils-2.0.60-6.fc11
-----------------------------
* Mon Dec 15 17:00:00 2008 Dan Walsh <dwalsh at redhat.com> 2.0.60-6
- fix audit2allow man page


printoxx-1.8-1.fc11
-------------------
* Sun Jan  4 17:00:00 2009 Nicoleau Fabien <nicoleau.fabien at gmail.com> - 1.8-1
- Rebuild for 1.8


pygobject2-2.16.0-1.fc11
------------------------
* Sun Jan  4 17:00:00 2009 - Matthew Barnes <mbarnes at redhat.com> - 2.16.0-1.fc11
- Update to 2.16.0
- Remove patch for RH bug #457502 (fixed upstream).
- Remove patch for GNOME bug #551059 and #551212 (fixed upstream).


qwt-5.1.1-2.fc11
----------------
* Sun Jan  4 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net> - 5.1.1-2
- modify path patch

* Sun Jan  4 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net> - 5.1.1-1
-update to 5.1.1


selinux-policy-3.6.1-15.fc11
----------------------------
* Sun Jan  4 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.1-15
- Allow hal_acl_t to getattr/setattr fixed_disk


stellarium-0.10.0-2.fc11
------------------------
* Sun Jan  4 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 0.10.0-2
- Create symlinks to DejaVu fonts (#477460)


sugar-0.83.4-2.fc11
-------------------
* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at laptop.org> - 0.83.4-2
- add intltool build require

* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at laptop.org> - 0.83.4-1
- New download url
- Fix language parsing on Gentoo and ALTLinux #81 (alsroot)
- Change the FRAME_POSITION_RELATIVE to follow eben's spec
- exec sugar-session
- Add wired device icon for the frame
- Only show wireless device in the frame when connecting/connected
- Use jabber.sugarlabs.org by default
- Only create a keydialog for the activating connection
- CanvasPulsingIcon: Don't begin pulse loop on resume if not pulsing
- Use g_timeout_add_seconds() for power efficiency
- Add the journal button to the volumes toolbar in the journal
- Remove jarabe/model/volume.py and use gio instead
- First try at restoring removable devices support in the journal
- make the image viewer activity the default one for iamges


sugar-artwork-0.83.2-1.fc11
---------------------------
* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at laptop.org> - 0.83.2-1
- New icon for the wired network


sugar-base-0.83.2-1.fc11
------------------------
* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 0.83.2-1
- add intltool as build dep
- new download url
- Adding language he, bi, hu, sw, cs, sv, sk, wa
- Updated translations


sugar-datastore-0.83.1-1.fc11
-----------------------------
* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at laptop.org> - 0.83.1-1
- contains a bunch of stability and robustness improvements


sugar-toolkit-0.83.3-1.fc11
---------------------------
* Sun Jan  4 17:00:00 2009 Simon Schampijer <simon at laptop.org> - 0.83.3-1
- remove session shutdown patch
- add intltool as build requires
- new download url
- Fix palette highlighting on tray icons. Patch by benzea, style tweaks by marcopg
- Rework palette state logic. Fix #42
- Use g_timeout_add_seconds() for power efficiency
- Add colors to icons in menu items
- Add accelerator support to menu items
- Simplify activity bundle installation
- Dont pop down the palette when a submenu opens


supybot-fedora-0.2.1-1.fc11
---------------------------
* Sun Jan  4 17:00:00 2009 Jon Stanley <jonstanley at gmail.com> - 0.2.1-1
- New upstream 0.2.1


xkeyboard-config-1.4-8.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> - 1.4-8
- xkeyboard-config-1.4-abnt2.patch: fix , and . mixup in abnt2 (#470153)


xorg-x11-drv-synaptics-0.99.3-3.fc11
------------------------------------
* Mon Jan  5 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 0.99.3-3
- Require xorg-x11-server-sdk 1.6 to build
- Update fdi file with comments on how to merge your own keys.


Summary:
Added Packages: 13
Removed Packages: 0
Modified Packages: 37
Broken deps for i386
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.i386 requires libnm-util.so.0
	anaconda-11.5.0.3-1.i386 requires libnm-util.so.0
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.i386 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qwt-doc-5.0.2-4.fc8.noarch requires qwt = 0:5.0.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.x86_64 requires libnm-util.so.0()(64bit)
	anaconda-11.5.0.3-1.x86_64 requires libnm-util.so.0()(64bit)
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.i386 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.x86_64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.x86_64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qwt-doc-5.0.2-4.fc8.noarch requires qwt = 0:5.0.2
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.ppc requires libnm-util.so.0
	anaconda-11.5.0.3-1.ppc requires libnm-util.so.0
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qwt-doc-5.0.2-4.fc8.noarch requires qwt = 0:5.0.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	NetworkManager-openconnect-0.7.0-3.svn9.fc11.ppc64 requires libnm-util.so.0()(64bit)
	anaconda-11.5.0.3-1.ppc64 requires libnm-util.so.0()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	farsight2-devel-0.0.6-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	firstaidkit-plugin-grub-0.2.2-5.fc11.noarch requires grub
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	gstreamer-plugins-base-devel-0.10.21-3.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	gstreamermm-devel-0.9.8-2.fc11.ppc64 requires pkgconfig(gstreamer-base-0.10)
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qwt-doc-5.0.2-4.fc8.noarch requires qwt = 0:5.0.2
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From cdahlin at redhat.com  Mon Jan  5 09:38:07 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 05 Jan 2009 04:38:07 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49602ACE.6050506@gmail.com>
References: <494930CD.70709@herr-schmitt.de>	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>	<49588231.2070800@gmail.com>	<495884BC.7040800@redhat.com>	<49588D9D.5020303@gmail.com>	<495A18D5.3030602@nobugconsulting.ro>	<495B0362.6030906@gmail.com>	<495C9A7F.9080300@redhat.com>
	<49602ACE.6050506@gmail.com>
Message-ID: <4961D4FF.5090306@redhat.com>

Lyos Gemini Norezel wrote:
> Casey Dahlin wrote:
>> And? The numbers are free. I can see not wanting to have lots of 
>> partitions to distinguish from, but this use case doesn't strike me 
>> as killer.
>> --CJD
>
> Sure... until you have to remember, under stress, which partition your 
> data's on.
> Lyos Gemini Norezel
>
/dev/disk/by-label/...

--CJD



From thomas.moschny at gmail.com  Mon Jan  5 10:15:33 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Mon, 5 Jan 2009 11:15:33 +0100
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
Message-ID: <a9d183c80901050215ia9b7ebucd5c315111644f12@mail.gmail.com>

2009/1/5 Jonathan Underwood <jonathan.underwood at gmail.com>:
> Note also that building against lapack means that you package
> installation may pull in atlas to satisfy the blas requirement of
> lapack. Or it may pull in the blas package (a subpackage of lapack
> which has a different blas implementation).

Vaguely remember that the package with the shortest wins in yum's
depsolving algorithm.

- Thomas



From mschwendt at gmail.com  Mon Jan  5 10:23:53 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 5 Jan 2009 11:23:53 +0100
Subject: rawhide report: 20090105 changes
In-Reply-To: <20090105085443.41F1C1F8258@releng2.fedora.phx.redhat.com>
References: <20090105085443.41F1C1F8258@releng2.fedora.phx.redhat.com>
Message-ID: <20090105112353.8e772304.mschwendt@gmail.com>

On Mon,  5 Jan 2009 08:54:43 +0000 (UTC), Rawhide wrote:

> gnome-applet-timer-2.0.1-8.fc11
> -------------------------------
> * Sun Jan  4 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.0.2-8
> - Use Paul's patch instead of Michael's suggestion (#471465)
> 
> * Sun Jan  4 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.0.2-7
> - Apply libnotify patch, thanks to Michael Schwendt and Paul Frields (#471465)

You could have asked. This changelog comment is based on a misunderstanding.
It should read:
 - Use Paul's patch instead of Christoph's patch



From surenkarapetyan at gmail.com  Mon Jan  5 10:37:56 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Mon, 05 Jan 2009 14:37:56 +0400
Subject: sound problems
In-Reply-To: <68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
Message-ID: <4961E304.7090202@gmail.com>

Paulo Cavalcanti wrote:
>
>
> On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan 
> <surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>> wrote:
>
>     Yeah.. I know. fedora-devel is not a place for discussing bugs but
>     I'll risk.
>
>     As (I hope) many of You already know kernel-2.6.27.9-159 which was
>     pushed as a security update has broken sound on many systems
>     (mostly notebooks) -
>     https://bugzilla.redhat.com/show_bug.cgi?id=477954. The reason for
>     this is the new ALSA (1.0.18a).
>
>     There are a lot of "+1"s and "me too"s in bugzilla and if we
>     consider the amount of people who don't know how to report bugs,
>     add those who are on New Year holidays it becomes clear that this
>     affects a lot of our users.
>
>     So users have two choices now:
>     1. Have no sound.
>     2. Stick with 2.6.27.9-134 (this is not as easy as it seems cause
>     the new update will be downloaded and installed automatically).
>
>     I do understand that many developers are on holidays themselves,
>     but I'm also sure this is a REAL problem which should be resolved
>     ASAP.
>     So I just wanted to know what are we going to do about this.
>
>
>  
>
> You can try the latest alsa snapshot available in ATrpms:
>
> http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm
>
> http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm
>
> It has a lot of recent fixes and it is working just fine for me and 
> for others. I also had no sound with kernel 159, before installing 
> this new alsa.
>
> If you remove the rpm later, you go back to the original sound modules 
> (nothing is overwritten).
>
> Good luck.
>
>
> -- 
> Paulo Roma Cavalcanti
> LCG - UFRJ
Still doesn't work.



From promac at gmail.com  Mon Jan  5 10:59:17 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Mon, 5 Jan 2009 08:59:17 -0200
Subject: sound problems
In-Reply-To: <4961E304.7090202@gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<4961E304.7090202@gmail.com>
Message-ID: <68720af30901050259w1f118c75mbbb94d29a3f7d144@mail.gmail.com>

On Mon, Jan 5, 2009 at 8:37 AM, Suren Karapetyan
<surenkarapetyan at gmail.com>wrote:

> Paulo Cavalcanti wrote:
>
>
>>
>> On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan <
>> surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>> wrote:
>>
>>    Yeah.. I know. fedora-devel is not a place for discussing bugs but
>>    I'll risk.
>>
>>    As (I hope) many of You already know kernel-2.6.27.9-159 which was
>>    pushed as a security update has broken sound on many systems
>>    (mostly notebooks) -
>>    https://bugzilla.redhat.com/show_bug.cgi?id=477954. The reason for
>>    this is the new ALSA (1.0.18a).
>>
>>    There are a lot of "+1"s and "me too"s in bugzilla and if we
>>    consider the amount of people who don't know how to report bugs,
>>    add those who are on New Year holidays it becomes clear that this
>>    affects a lot of our users.
>>
>>    So users have two choices now:
>>    1. Have no sound.
>>    2. Stick with 2.6.27.9-134 (this is not as easy as it seems cause
>>    the new update will be downloaded and installed automatically).
>>
>>    I do understand that many developers are on holidays themselves,
>>    but I'm also sure this is a REAL problem which should be resolved
>>    ASAP.
>>    So I just wanted to know what are we going to do about this.
>>
>>
>>
>> You can try the latest alsa snapshot available in ATrpms:
>>
>>
>> http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm
>>
>>
>> http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm
>>
>> It has a lot of recent fixes and it is working just fine for me and for
>> others. I also had no sound with kernel 159, before installing this new
>> alsa.
>>
>> If you remove the rpm later, you go back to the original sound modules
>> (nothing is overwritten).
>>
>> Good luck.
>>
>>
>> --
>> Paulo Roma Cavalcanti
>> LCG - UFRJ
>>
> Still doesn't work.
>
>
>
Have you rebooted?


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/9eb50b6e/attachment.htm>

From mcepl at redhat.com  Mon Jan  5 10:51:40 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 05 Jan 2009 11:51:40 +0100
Subject: vim syntax file packaging
References: <20090101165645.GA3821@voltron>
Message-ID: <sa5936xdk5.ln2@ppp1053.in.ipex.cz>

On 2009-01-01, 16:56 GMT, Nikolay Vladimirov wrote:
> So is there a guideline I missed?=20
> Is it for the packager to decide?
> It's good to have at least some 'best practice' note about this.=20

There is no official policy for this, but currently if I am not 
mistaken, the biggest vim plugin distributed in fedora is my 
vim-vimoutliner. I think the best way how to do it, is to use 
/usr/share/vim/vimfiles (which is owned by vim-common just for 
this purpose).

Mat?j



From surenkarapetyan at gmail.com  Mon Jan  5 11:04:44 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Mon, 05 Jan 2009 15:04:44 +0400
Subject: sound problems
In-Reply-To: <68720af30901050259w1f118c75mbbb94d29a3f7d144@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<4961E304.7090202@gmail.com>
	<68720af30901050259w1f118c75mbbb94d29a3f7d144@mail.gmail.com>
Message-ID: <4961E94C.6010204@gmail.com>

Paulo Cavalcanti wrote:
>
>
> On Mon, Jan 5, 2009 at 8:37 AM, Suren Karapetyan 
> <surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>> wrote:
>
>     Paulo Cavalcanti wrote:
>
>
>
>         On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan
>         <surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>
>         <mailto:surenkarapetyan at gmail.com
>         <mailto:surenkarapetyan at gmail.com>>> wrote:
>
>            Yeah.. I know. fedora-devel is not a place for discussing
>         bugs but
>            I'll risk.
>
>            As (I hope) many of You already know kernel-2.6.27.9-159
>         which was
>            pushed as a security update has broken sound on many systems
>            (mostly notebooks) -
>            https://bugzilla.redhat.com/show_bug.cgi?id=477954. The
>         reason for
>            this is the new ALSA (1.0.18a).
>
>            There are a lot of "+1"s and "me too"s in bugzilla and if we
>            consider the amount of people who don't know how to report
>         bugs,
>            add those who are on New Year holidays it becomes clear
>         that this
>            affects a lot of our users.
>
>            So users have two choices now:
>            1. Have no sound.
>            2. Stick with 2.6.27.9-134 (this is not as easy as it seems
>         cause
>            the new update will be downloaded and installed automatically).
>
>            I do understand that many developers are on holidays
>         themselves,
>            but I'm also sure this is a REAL problem which should be
>         resolved
>            ASAP.
>            So I just wanted to know what are we going to do about this.
>
>
>          
>         You can try the latest alsa snapshot available in ATrpms:
>
>         http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm
>
>         http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm
>
>         It has a lot of recent fixes and it is working just fine for
>         me and for others. I also had no sound with kernel 159, before
>         installing this new alsa.
>
>         If you remove the rpm later, you go back to the original sound
>         modules (nothing is overwritten).
>
>         Good luck.
>
>
>         -- 
>         Paulo Roma Cavalcanti
>         LCG - UFRJ
>
>     Still doesn't work.
>
>
>
> Have you rebooted?
>
>
> -- 
> Paulo Roma Cavalcanti
> LCG - UFRJ
Yes I have.
And I forgot that I've tried the exact same RPM yesterday with same results.
If you look at bugzilla I've reported that version as not working yesterday.



From valent.turkovic at gmail.com  Mon Jan  5 11:17:44 2009
From: valent.turkovic at gmail.com (Valent Turkovic)
Date: Mon, 5 Jan 2009 12:17:44 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
	<ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
Message-ID: <64b14b300901050317g71f49a8dme9ab1289062510f5@mail.gmail.com>

On Sun, Jan 4, 2009 at 2:24 AM, Eric Springer <erikina at gmail.com> wrote:
> On Thu, Jan 1, 2009 at 8:19 PM, Valent Turkovic
> <valent.turkovic at gmail.com> wrote:
>> On Wed, Dec 31, 2008 at 2:14 AM, Conrad Meyer <konrad at tylerc.org> wrote:
>>
>> Are you being intentionally ignorant or are you new to this list?
>
> Oh screw you. You come to the *development* list and say crap like
> this to contributing and active member?

I'm sorry if I offended you, I don't know you personaly and I just
judge from what you wrote. Because I know that that is ignored most of
the time I concluded that you were being intentionally a prick or are
new to this list and don't know that this is ignored.

My primary language isn't english so words that I use don't have the
finesse of english speaking people and come out much stronger than
intended, sorry again for that.

> Beside repeatably avoiding taking the proper channels to get issues
> fixed, you can't even be polite.
>
> Let me take a quick look at your contributions:
>
> 08-12-30 -- Posting about a bug that affects you (on devel)
> 08-12-29 -- Asking for tips on using your eee (on devel)
> 08-11-30 -- Asking a wiki question (on devel)
> 08-11-17 -- Asking about WEP keys and network manager (on devel)
> 08-07-14 -- Asking people to look at a sound issue for you (on devel)
> 08-06-14 -- Posting about 4 feature requests bugs you want (on devel)
> 08-06-12 -- Posting about a selinux bug that affects you (on devel)
> 08-03-30 -- Posting about a networkmanager bug that affects you (on devel)
> 08-06-09 -- Asking if Red Hat is dropping support for fedora (on devel)
> 08-05-27 -- Asking about fedoratv (on devel)
> 08-05-27 -- Reporting flash doesn't work (on devel)
> 08-05-27 -- Asking about webcam support (on devel)
> 08-05-27 -- Asking how to disable a feature in swfdec (on devel)
>

I don't "abuse" this mailing list that much if you read my mails you
would see that they are intended for devels and not only as issues
that I have! Why are spreading this FUD? Are you so mad? Sorry once
more if I have offended you.

You have too much time on your hand if you have time to invest in my
mail history. I don't have to see yours but I guess it is interesting
:)

> The development mailing list isn't for:
> * The bugs that affect you
I don't. As with this email I just higlighted an issue that affects
ALL eee users, and I know how much fedora devels have done to make
fedora work on that device so it is a shame that this issue ruins it
all.

> * Asking developers for help
> * Being a jerk

then please go of this list ;) I couldn't resist :) If I'm being a
jerk it is not intentional... sorry.

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 promac at gmail.com  Mon Jan  5 11:24:38 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Mon, 5 Jan 2009 09:24:38 -0200
Subject: sound problems
In-Reply-To: <4961E94C.6010204@gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<4961E304.7090202@gmail.com>
	<68720af30901050259w1f118c75mbbb94d29a3f7d144@mail.gmail.com>
	<4961E94C.6010204@gmail.com>
Message-ID: <68720af30901050324m49355e2fm460d525d77bf2905@mail.gmail.com>

On Mon, Jan 5, 2009 at 9:04 AM, Suren Karapetyan
<surenkarapetyan at gmail.com>wrote:

> Paulo Cavalcanti wrote:
>
>>
>>
>> On Mon, Jan 5, 2009 at 8:37 AM, Suren Karapetyan <
>> surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>> wrote:
>>
>>    Paulo Cavalcanti wrote:
>>
>>
>>
>>        On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan
>>        <surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>
>>        <mailto:surenkarapetyan at gmail.com
>>
>>        <mailto:surenkarapetyan at gmail.com>>> wrote:
>>
>>           Yeah.. I know. fedora-devel is not a place for discussing
>>        bugs but
>>           I'll risk.
>>
>>           As (I hope) many of You already know kernel-2.6.27.9-159
>>        which was
>>           pushed as a security update has broken sound on many systems
>>           (mostly notebooks) -
>>           https://bugzilla.redhat.com/show_bug.cgi?id=477954. The
>>        reason for
>>           this is the new ALSA (1.0.18a).
>>
>>           There are a lot of "+1"s and "me too"s in bugzilla and if we
>>           consider the amount of people who don't know how to report
>>        bugs,
>>           add those who are on New Year holidays it becomes clear
>>        that this
>>           affects a lot of our users.
>>
>>           So users have two choices now:
>>           1. Have no sound.
>>           2. Stick with 2.6.27.9-134 (this is not as easy as it seems
>>        cause
>>           the new update will be downloaded and installed automatically).
>>
>>           I do understand that many developers are on holidays
>>        themselves,
>>           but I'm also sure this is a REAL problem which should be
>>        resolved
>>           ASAP.
>>           So I just wanted to know what are we going to do about this.
>>
>>
>>                You can try the latest alsa snapshot available in ATrpms:
>>
>>
>> http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm
>>
>>
>> http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm
>>
>>        It has a lot of recent fixes and it is working just fine for
>>        me and for others. I also had no sound with kernel 159, before
>>        installing this new alsa.
>>
>>        If you remove the rpm later, you go back to the original sound
>>        modules (nothing is overwritten).
>>
>>        Good luck.
>>
>>
>>        --        Paulo Roma Cavalcanti
>>        LCG - UFRJ
>>
>>    Still doesn't work.
>>
>>
>>
>> Have you rebooted?
>>
>>
>>
I have a dell vostro 1400, which uses the sigmatel codec (STAC9200)

It is working just fine with the snapshot, but I have to specify the model
in /etc/modprobe.conf. These are the results I got for all possible models:


# the position_fix parameter seems to end xruns in jack
# model=ref           - sound in headphone only, analog mic work. No digital
mic.
# model=3stack,5stack - no sound at all.
# model=dell-3stack   - sound works for headphones and speakers, no analog
mic. Digital mic is really too low (unusable for practical purposes).

Therefore, the one which works for me, is:

options snd-hda-intel position_fix=1 model=dell-3stack




-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/5200c3a3/attachment.htm>

From mail at michaelmondragon.net  Mon Jan  5 11:33:08 2009
From: mail at michaelmondragon.net (Michael Mondragon)
Date: Mon, 5 Jan 2009 19:33:08 +0800
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
Message-ID: <cd8747700901050333q29bdf3d8h6d55b3646a9d2f4e@mail.gmail.com>

Hey Guys,

As I read Valent's mail, I do understand his ways one way or another.
At the end of the day, let's help together and to have more leaner
team.

To all dev, kudos!  Actually I'm newbie here in Fedora devel, but
reading those emails, I understand the feelings/emotions and sometimes
language is the barrier that even myself is having a hard time to make
people understand me. :)  Anyway, Valant for me, I think we need to
think twice as hard as we could.  Happy New Year to all!

Just a cent worth from me!


Thanks,
-- 
Michael F. Mondragon | MCSA, Linux+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hear and I forget.
I see and I remember.
I do and I understand.
       ?Confucius
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



On Thu, Jan 1, 2009 at 6:19 PM, Valent Turkovic
<valent.turkovic at gmail.com> wrote:
> On Wed, Dec 31, 2008 at 2:14 AM, Conrad Meyer <konrad at tylerc.org> wrote:
>> On Tuesday 30 December 2008 09:13:56 am Valent Turkovic wrote:
>>> On Mon, Dec 29, 2008 at 10:40 PM, Conrad Meyer <konrad at tylerc.org> wrote:
>>> > *Please* stop posting the particular bugs that affect you to the mailing
>>> > list as if they are higher priority than any other bugs.
>>> >
>>> > Regards,
>>> > --
>>> > Conrad Meyer <konrad at tylerc.org>
>>>
>>> I'm not saying that this bug has some too high importance but to say
>>> that all bugs are created equal is not true.
>>
>> That's why there is a priority setting for each bug on bugzilla.
>>
>
> Are you being intentionally ignorant or are you new to this list? I
> have heard numerous times that priority setting is being ignored and
> it doesn't matter what you set it to.
>
>>> Also I heard a lot of positive feedback when some specific bugs got
>>> mentioned on this list, if you believe it is now important you can
>>> choose to ignore that thread.
>>
>> (I believe you meant 'not' instead of 'now'.) That strategy doesn't really
>> work. Ignoring spam that is sent to onesself regularly doesn't stop it from
>> being sent. Please don't contribute to the internet's spam problem. I don't
>> believe there is any added value in your regular mailings of the list with
>> your own bugs.
>>
>> Regards,
>> --
>> Conrad Meyer <konrad at tylerc.org>
>>
>
> I believe that this issue should be discussed also here, and there are
> people who aren't ware of it or maybe I'm wrong and this isn't a bug
> but some error on my part so others can show me that.
>
> Anyway I would like to help fix this issue with my feedback and
> testing and that is one more reason why I wrote to this list.
>
> If you have some helpful suggestions or comments please join the
> discussion or feel free to ignore it.
>
> Cheers and happy New Year!
>
> --
> 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
>



From kevin.kofler at chello.at  Mon Jan  5 11:33:05 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 05 Jan 2009 12:33:05 +0100
Subject: Fedora unusable on Asus eee 701
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
	<ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
	<64b14b300901050317g71f49a8dme9ab1289062510f5@mail.gmail.com>
Message-ID: <gjsr5h$el2$1@ger.gmane.org>

Valent Turkovic wrote:
> I don't "abuse" this mailing list that much if you read my mails you
> would see that they are intended for devels and not only as issues
> that I have! Why are spreading this FUD? Are you so mad? Sorry once
> more if I have offended you.

I think you're misunderstanding the purpose of this list. It is for
discussion ABOUT development of Fedora, NOT for asking user questions TO
the Fedora developers. Your posts are the latter, and thus they are off
topic.

https://fedoraproject.org/wiki/PostIsOffTopic
> If you are not a Fedora developer, you probably have no business posting
> here. This is not for end-user questions.

        Kevin Kofler



From mjg at redhat.com  Mon Jan  5 12:05:13 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 5 Jan 2009 12:05:13 +0000
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
	<9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
	<9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>
Message-ID: <20090105120513.GA29438@srcf.ucam.org>

On Sun, Jan 04, 2009 at 04:18:39PM +0000, Mat Booth wrote:

> Is this an omission in the asus-laptop driver? 

Yes.

> Would I need to implement an input device driver to get it working?

I believe that one's been implemented, but not merged.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From promac at gmail.com  Mon Jan  5 12:08:16 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Mon, 5 Jan 2009 10:08:16 -0200
Subject: sound problems
In-Reply-To: <68720af30901050324m49355e2fm460d525d77bf2905@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<4961E304.7090202@gmail.com>
	<68720af30901050259w1f118c75mbbb94d29a3f7d144@mail.gmail.com>
	<4961E94C.6010204@gmail.com>
	<68720af30901050324m49355e2fm460d525d77bf2905@mail.gmail.com>
Message-ID: <68720af30901050408w2620319ob8809d768f54444b@mail.gmail.com>

On Mon, Jan 5, 2009 at 9:24 AM, Paulo Cavalcanti <promac at gmail.com> wrote:

>
>
> On Mon, Jan 5, 2009 at 9:04 AM, Suren Karapetyan <
> surenkarapetyan at gmail.com> wrote:
>
>> Paulo Cavalcanti wrote:
>>
>>>
>>>
>>> On Mon, Jan 5, 2009 at 8:37 AM, Suren Karapetyan <
>>> surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>> wrote:
>>>
>>>    Paulo Cavalcanti wrote:
>>>
>>>
>>>
>>>        On Sun, Jan 4, 2009 at 12:58 PM, Suren Karapetyan
>>>        <surenkarapetyan at gmail.com <mailto:surenkarapetyan at gmail.com>
>>>        <mailto:surenkarapetyan at gmail.com
>>>
>>>        <mailto:surenkarapetyan at gmail.com>>> wrote:
>>>
>>>           Yeah.. I know. fedora-devel is not a place for discussing
>>>        bugs but
>>>           I'll risk.
>>>
>>>           As (I hope) many of You already know kernel-2.6.27.9-159
>>>        which was
>>>           pushed as a security update has broken sound on many systems
>>>           (mostly notebooks) -
>>>           https://bugzilla.redhat.com/show_bug.cgi?id=477954. The
>>>        reason for
>>>           this is the new ALSA (1.0.18a).
>>>
>>>           There are a lot of "+1"s and "me too"s in bugzilla and if we
>>>           consider the amount of people who don't know how to report
>>>        bugs,
>>>           add those who are on New Year holidays it becomes clear
>>>        that this
>>>           affects a lot of our users.
>>>
>>>           So users have two choices now:
>>>           1. Have no sound.
>>>           2. Stick with 2.6.27.9-134 (this is not as easy as it seems
>>>        cause
>>>           the new update will be downloaded and installed automatically).
>>>
>>>           I do understand that many developers are on holidays
>>>        themselves,
>>>           but I'm also sure this is a REAL problem which should be
>>>        resolved
>>>           ASAP.
>>>           So I just wanted to know what are we going to do about this.
>>>
>>>
>>>                You can try the latest alsa snapshot available in ATrpms:
>>>
>>>
>>> http://dl.atrpms.net/f10-x86_64/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.x86_64.rpm
>>>
>>>
>>> http://dl.atrpms.net/f10-i386/atrpms/bleeding/alsa-kmdl-2.6.27.9-159.fc10-1.0.18a.snap-74.fc10.i686.rpm
>>>
>>>        It has a lot of recent fixes and it is working just fine for
>>>        me and for others. I also had no sound with kernel 159, before
>>>        installing this new alsa.
>>>
>>>        If you remove the rpm later, you go back to the original sound
>>>        modules (nothing is overwritten).
>>>
>>>        Good luck.
>>>
>>>
>>>        --        Paulo Roma Cavalcanti
>>>        LCG - UFRJ
>>>
>>>    Still doesn't work.
>>>
>>>
>>>
>>> Have you rebooted?
>>>
>>>
>>>
> I have a dell vostro 1400, which uses the sigmatel codec (STAC9200)
>
> It is working just fine with the snapshot, but I have to specify the model
> in /etc/modprobe.conf. These are the results I got for all possible models:
>
>
> # the position_fix parameter seems to end xruns in jack
> # model=ref           - sound in headphone only, analog mic work. No
> digital mic.
> # model=3stack,5stack - no sound at all.
> # model=dell-3stack   - sound works for headphones and speakers, no analog
> mic. Digital mic is really too low (unusable for practical purposes).
>
> Therefore, the one which works for me, is:
>
> options snd-hda-intel position_fix=1 model=dell-3stack
>
>
>
In fact, my codec is Sigmatel STAC9228.



-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/473852f0/attachment.htm>

From jonathan.underwood at gmail.com  Mon Jan  5 12:18:40 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 12:18:40 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <604aa7910901041638i70f26662l658bbe4965375c99@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
	<604aa7910901041638i70f26662l658bbe4965375c99@mail.gmail.com>
Message-ID: <645d17210901050418k8135662ib267cf8a20e1be8c@mail.gmail.com>

2009/1/5 Jeff Spaleta <jspaleta at gmail.com>:
> On Sun, Jan 4, 2009 at 3:15 PM, Jonathan Underwood
> <jonathan.underwood at gmail.com> wrote:
>> Note also that building against lapack means that you package
>> installation may pull in atlas to satisfy the blas requirement of
>> lapack. Or it may pull in the blas package (a subpackage of lapack
>> which has a different blas implementation).
>
>
> This is the sort of thing that concerns me.  But I can't reproduce the
> reported problem and that unnerves me even more.  If this were a
> fragile dep resolution  and linker logic interaction, that just
> happens to work in the default install situations.. i should be able
> to break it  by doing weird things like forcing nodep package erases
> by hand and then asking yum to resolve deps.   But I can't.

You can see what is happening if you do

export LD_DEBUG=libs

then run python and import scipy

On a system with only atlas installed (no lapack or blas):
[snip]
     30261:	find library=liblapack.so.3 [0]; searching
     30261:	 search cache=/etc/ld.so.cache
     30261:	  trying file=/usr/lib64/atlas/liblapack.so.3
[snip]

On installing the lapack package:
[snip]
     30373:	find library=liblapack.so.3 [0]; searching
     30373:	 search cache=/etc/ld.so.cache
     30373:	  trying file=/usr/lib64/atlas/liblapack.so.3
[snip]

Now installing blas and removing atlas does allow the "proper"
liblapack to be used:
[snip]
     30408:	find library=liblapack.so.3 [0]; searching
     30408:	 search cache=/etc/ld.so.cache
     30408:	  trying file=/usr/lib64/liblapack.so.3
[snip]

This is basically the situation as forced by the file
/etc/ld.so.conf.d/atlas-x86_64.conf which places the atlas libraries
at the front of the linker search path. It's a tough call as to
whether this is a useful default.

Personally I think that the liblapack provided by atlas should be renamed.

[Or liblapack should be set up using alternatives. Not sure if
alternatives works for libraries? Actually, what's really needed as
some sort of simple way for the user to select which library is used
when two or more have the same name.]

HTH,
J.



From ml at bendler-net.de  Mon Jan  5 12:24:02 2009
From: ml at bendler-net.de (Thomas Bendler)
Date: Mon, 5 Jan 2009 13:24:02 +0100
Subject: Fedora unusable on Asus eee 701
In-Reply-To: <gjsr5h$el2$1@ger.gmane.org>
References: <64b14b300812291336w4d2fe21cq7782fb6c58f71c79@mail.gmail.com>
	<200812291340.25845.konrad@tylerc.org>
	<64b14b300812300913k3bf79716s306081bc10712d2e@mail.gmail.com>
	<200812301714.24094.konrad@tylerc.org>
	<64b14b300901010219q515d02eeu8caa8d6dd411f2e0@mail.gmail.com>
	<ce9c609e0901031724x28f2702dpb636d6d550cdfe95@mail.gmail.com>
	<64b14b300901050317g71f49a8dme9ab1289062510f5@mail.gmail.com>
	<gjsr5h$el2$1@ger.gmane.org>
Message-ID: <e5f36bc70901050424v5ad1357br3f7216f8bb8432c2@mail.gmail.com>

On Mon, Jan 5, 2009 at 12:33 PM, Kevin Kofler <kevin.kofler at chello.at>wrote:

> [...]
> I think you're misunderstanding the purpose of this list. It is for
> discussion ABOUT development of Fedora, NOT for asking user questions TO
> the Fedora developers. Your posts are the latter, and thus they are off
> topic.
>
> https://fedoraproject.org/wiki/PostIsOffTopic
> > If you are not a Fedora developer, you probably have no business posting
> > here. This is not for end-user questions.


What is so complicated to tell him, questions like this should be placed on
fedora-list at redhat.com??? There are tons of mails telling him this is the
wrong list, why not simply tell him: "Ask this question on list XYZ"? This
is less emotional and reduce the amount of useless mails on this list.

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/0a83efd4/attachment.htm>

From mschwendt at gmail.com  Mon Jan  5 12:26:55 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 5 Jan 2009 13:26:55 +0100
Subject: Atlas and lapack provide the same library..compiled
 differently... is that a problem?
In-Reply-To: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
Message-ID: <20090105132655.c948585c.mschwendt@gmail.com>

On Sun, 4 Jan 2009 13:08:03 -0900, Jeff wrote:

> Okay I ran across an interesting issue trying to get scipy compiled
> with atlas support.
> 
> lapack and atlas both provide liblapack.so.3, in different locations,
> but accessible to the linker.

This has been reported before in bugzilla, but according to the package
maintainer the libraries are compatible.

(The list of pkgs which require liblapack.so.3 is quite long nowadays.)



From jonathan.underwood at gmail.com  Mon Jan  5 12:47:02 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 12:47:02 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <20090105132655.c948585c.mschwendt@gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<20090105132655.c948585c.mschwendt@gmail.com>
Message-ID: <645d17210901050447s468958e9p82e472968de0f475@mail.gmail.com>

2009/1/5 Michael Schwendt <mschwendt at gmail.com>:
> On Sun, 4 Jan 2009 13:08:03 -0900, Jeff wrote:
>
>> Okay I ran across an interesting issue trying to get scipy compiled
>> with atlas support.
>>
>> lapack and atlas both provide liblapack.so.3, in different locations,
>> but accessible to the linker.
>
> This has been reported before in bugzilla, but according to the package
> maintainer the libraries are compatible.
>

Ah, yes, looking at the atlas spec, it looks like the atlas package is
doing a variant of this:

http://math-atlas.sourceforge.net/errata.html#completelp



From fedora at matbooth.co.uk  Mon Jan  5 12:50:42 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Mon, 5 Jan 2009 12:50:42 +0000
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <20090105120513.GA29438@srcf.ucam.org>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
	<9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
	<9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>
	<20090105120513.GA29438@srcf.ucam.org>
Message-ID: <9497e9990901050450j2838e013ub29cec3702dfbb04@mail.gmail.com>

On Mon, Jan 5, 2009 at 12:05 PM, Matthew Garrett wrote:
> On Sun, Jan 04, 2009 at 04:18:39PM +0000, Mat Booth wrote:
>> Would I need to implement an input device driver to get it working?
>
> I believe that one's been implemented, but not merged.
>

Aha, you are right. A quick search for "asus laptop" input patch
yields this from our own Mr Wickert:

http://cwickert.fedorapeople.org/asus-laptop-add-input-events.patch

What is the prospect of getting this patch into the kernel? If it is
need of some love, I am willing to help develop and test it.


-- 
Mat Booth
www.matbooth.co.uk



From dledford at redhat.com  Mon Jan  5 15:49:35 2009
From: dledford at redhat.com (Doug Ledford)
Date: Mon, 05 Jan 2009 10:49:35 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <8278b1b0901041035v76592249l4838f08eed32204e@mail.gmail.com>
References: <494930CD.70709@herr-schmitt.de> <4957E650.6010809@redhat.com>
	<1231078385.32405.737.camel@firewall.xsintricity.com>
	<8278b1b0901041035v76592249l4838f08eed32204e@mail.gmail.com>
Message-ID: <1231170575.32405.778.camel@firewall.xsintricity.com>

On Sun, 2009-01-04 at 12:35 -0600, King InuYasha wrote:

> According to the SVN repo for grub2, its just the opposite!
> 
> 
> SVN repo: http://svn.savannah.gnu.org/viewvc/trunk/grub2/?root=grub
> 
> 
> In the repo, the latest change was 42hrs ago. It is far from dead. A
> video subsystem has been implemented from the GSoC 2008 as well as
> some usb support I believe.

Hmmm...I may have looked at an old source repository or something.  Or
maybe it went dormant for a period of time.  However, what I find
interesting is that the md software raid support is largely unchanged
since I last looked at it.  No better, no worse.  So whether it is alive
or not, it isn't making any progress in that area and still can't
support md raid partitions any better than grub1 (well, a *little*
better maybe, but no version 1 superblocks, and certainly no superblocks
at the beginning of the partition which is what I would like to see
supported the most).

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/e0126d68/attachment.sig>

From chris.stone at gmail.com  Mon Jan  5 16:16:06 2009
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 5 Jan 2009 08:16:06 -0800
Subject: sound problems
In-Reply-To: <68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
Message-ID: <d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>

2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
> You can try the latest alsa snapshot available in ATrpms:

Whoa, bad advice...anyone with half a brain knows to stay well clear
of anything coming from ATrpms.  Axel Thimm is one of the the worst
packagers in the Fedora community, and installing his packages is
*extremely* dangerous.

Anyway, I have this sound problem too, thanks atleast for pointing me
to the bug number...



From sundaram at fedoraproject.org  Mon Jan  5 16:24:19 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 05 Jan 2009 21:54:19 +0530
Subject: sound problems
In-Reply-To: <d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
Message-ID: <49623433.9020800@fedoraproject.org>

Christopher Stone wrote:
> 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
>> You can try the latest alsa snapshot available in ATrpms:
> 
> Whoa, bad advice...anyone with half a brain knows to stay well clear
> of anything coming from ATrpms.  Axel Thimm is one of the the worst
> packagers in the Fedora community, and installing his packages is
> *extremely* dangerous.

Oh come on. We don't need to rehash the friendly discussion you had in 
fedora-maintainers list before. Yes, conflicting packages in 
repositories has been a problem in many occasions but attacking Axel 
isn't the right solution to that problem. Please refrain from doing so.

Rahul



From jspaleta at gmail.com  Mon Jan  5 16:17:08 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 5 Jan 2009 07:17:08 -0900
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <20090105132655.c948585c.mschwendt@gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<20090105132655.c948585c.mschwendt@gmail.com>
Message-ID: <604aa7910901050817g517fca6bvd5f3113a45a0a33e@mail.gmail.com>

On Mon, Jan 5, 2009 at 3:26 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> This has been reported before in bugzilla, but according to the package
> maintainer the libraries are compatible.

And yet, I have a user reporting missing symbols errors when the
linker attempts to use the lapack package libraries instead of the
atlas libraries. If they were compatible before, something has
changed.

-jef



From promac at gmail.com  Mon Jan  5 16:48:17 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Mon, 5 Jan 2009 14:48:17 -0200
Subject: sound problems
In-Reply-To: <d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
Message-ID: <68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>

On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone <chris.stone at gmail.com>wrote:

> 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
> > You can try the latest alsa snapshot available in ATrpms:
>
> Whoa, bad advice...anyone with half a brain knows to stay well clear
> of anything coming from ATrpms.  Axel Thimm is one of the the worst
> packagers in the Fedora community, and installing his packages is
> *extremely* dangerous.
>
> Anyway, I have this sound problem too, thanks atleast for pointing me
> to the bug number...
>
>
Well, a lot of packages in ATrpms are mine. Including this alsa snapshot.
I am the person who spent almost two weeks with Takashi trying to debug
the sigmatel codec. Therefore, I think your comment is directed to me.

Your parents should have told you a long time ago that when someone does
not have anything nice to say, it is much better to keep the mouth shut.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/862efcb7/attachment.htm>

From konrad at tylerc.org  Mon Jan  5 16:54:18 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 5 Jan 2009 08:54:18 -0800
Subject: sound problems
In-Reply-To: <68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
Message-ID: <200901050854.18189.konrad@tylerc.org>

On Monday 05 January 2009 08:48:17 am Paulo Cavalcanti wrote:
> On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone 
<chris.stone at gmail.com>wrote:
> > 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
> > > You can try the latest alsa snapshot available in ATrpms:
> >
> > Whoa, bad advice...anyone with half a brain knows to stay well clear
> > of anything coming from ATrpms.  Axel Thimm is one of the the worst
> > packagers in the Fedora community, and installing his packages is
> > *extremely* dangerous.
> >
> > Anyway, I have this sound problem too, thanks atleast for pointing me
> > to the bug number...
>
> Well, a lot of packages in ATrpms are mine.

Why not put that work into Fedora / RPM Fusion? Seems a waste to contribute to 
an incompatible 3rd-party repo.

> Including this alsa snapshot. 
> I am the person who spent almost two weeks with Takashi trying to debug
> the sigmatel codec.

Thanks.

-- 
Conrad Meyer <konrad at tylerc.org>




From jonathan.underwood at gmail.com  Mon Jan  5 16:59:35 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 16:59:35 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <604aa7910901050817g517fca6bvd5f3113a45a0a33e@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<20090105132655.c948585c.mschwendt@gmail.com>
	<604aa7910901050817g517fca6bvd5f3113a45a0a33e@mail.gmail.com>
Message-ID: <645d17210901050859m5999b1c5i94e3224dc04bcd95@mail.gmail.com>

2009/1/5 Jeff Spaleta <jspaleta at gmail.com>:
> On Mon, Jan 5, 2009 at 3:26 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
>> This has been reported before in bugzilla, but according to the package
>> maintainer the libraries are compatible.
>
> And yet, I have a user reporting missing symbols errors when the
> linker attempts to use the lapack package libraries instead of the
> atlas libraries. If they were compatible before, something has
> changed.

Yes - the problem is that that Atlas implemented versions of lapack
symbols get prefixed with clapack_ so these two liblapack libraries
are not ABI compatible.

This is an ugly situation - I think the Atlas liblapack should be
renamed to something else, personally.

However, to fix your scipy problem, wouldn't a Requires: atlas "fix"
the issue? (And associated BuildRequires, I guess). That's an obscene
hack tho :).



From SteveD at redhat.com  Mon Jan  5 17:13:13 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 05 Jan 2009 12:13:13 -0500
Subject: /etc/hosts re-ordered f10?
In-Reply-To: <4960D1FE.20303@sapience.com>
References: <495F8526.4030901@RedHat.com> <4960D1FE.20303@sapience.com>
Message-ID: <49623FA9.6000906@RedHat.com>



Mail Lists wrote:
> On 01/03/2009 10:32 AM, Steve Dickson wrote:
>> Hello,
>>
>> It seems in F10 the hostname and DNS domain name are now being added
>> as alias at the end of 127.0.0.1 definition, ala
>>
>>      127.0.0.1   localhost.localdomain localhost f10.domainname.com f10
>>
>> which unfortunately breaks kerberos in its keytab lookups.
>>
> 
>   Every F10 install I did had a bad /etc/hosts file in  the way you
> describe. Easy enough to fix but not for Aunt Tilly - tho she may not
> care and desktop impact is probably lowish.
> 
>  However this does impact other services as well (squid/apache and
> others). I had terrible problems with some daemons inappropriately
> listening on 127.0.0.1 and not on the real IP until I fixed the hosts file.
It appears this was a know problem, https://bugzilla.redhat.com/show_bug.cgi?id=474086,
and was resolved by adding the non-FQDN hostname to the end of the 127.0.0.1 line.

This resolution does indeed fix the problem I was seeing with the kerberos libraries.

steved.



From jspaleta at gmail.com  Mon Jan  5 17:23:52 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 5 Jan 2009 08:23:52 -0900
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <645d17210901050859m5999b1c5i94e3224dc04bcd95@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<20090105132655.c948585c.mschwendt@gmail.com>
	<604aa7910901050817g517fca6bvd5f3113a45a0a33e@mail.gmail.com>
	<645d17210901050859m5999b1c5i94e3224dc04bcd95@mail.gmail.com>
Message-ID: <604aa7910901050923i157356fbr6816254c67601c51@mail.gmail.com>

On Mon, Jan 5, 2009 at 7:59 AM, Jonathan Underwood
<jonathan.underwood at gmail.com> wrote:
> Yes - the problem is that that Atlas implemented versions of lapack
> symbols get prefixed with clapack_ so these two liblapack libraries
> are not ABI compatible.

>
> This is an ugly situation - I think the Atlas liblapack should be
> renamed to something else, personally.

I'd rather not make it personal :->
>
> However, to fix your scipy problem, wouldn't a Requires: atlas "fix"
> the issue? (And associated BuildRequires, I guess). That's an obscene
> hack tho :).

Yes explicitly requiring atlas would solve the corner case you
discovered where blas and lapack were installed but atlas was not.
But that cornercase does not affect scipy as scipy package requires
libatlas.so.3.  This may be true for anything build against the atlas
provided lapack libraries. So the cornercase maybe vanishingly small
for Fedora packages which use atlas at build time.  I can poke with
reqoquery and see if libatlas.so.3 is always in the dep chain.

What Michael said could be true as far as fedora packaging processes
are concerned...this is compatible...assuming no local linker path
customizations are employed.  But from the linker standpoint and more
importantly for locally compiled code, I would think you are correct,
the ABI incompatibility is a very good reason to change the library
names to prevent cornercase runtime linking problems.

Here's the weird part... the user reporting the problem with scipy had
atlas installed!  I can't confirm the one legit user reported problem
with incorrect linking, That report has to be a client side linker
path configuration customization on the affected machines.  But that's
going to be difficult for me to prove to my satisfaction.

https://bugzilla.redhat.com/show_bug.cgi?id=478435#c12

His home machine links as expected, multiple work machines don't even
with atlas installed.  Dollars to doughnuts he's using
LD_LIBRARAY_PATH or has a custom ld.so.conf.d script in place which
changes if the atlas library is linked.


-jef



From bpepple at fedoraproject.org  Mon Jan  5 17:36:06 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 05 Jan 2009 12:36:06 -0500
Subject: Package Review Stats for the week ending January 4th, 2009
Message-ID: <1231176966.13091.7.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending January 4th, 2009
were Lubomir Rintel, Parag AN(????), and Manuel Wolfshant.  Below is the
number of completed package reviews done.  Thanks to everyone that spent
time working on package reviews over the holidays.

Lubomir Rintel - 4
Parag AN(????) - 4
manuel wolfshant - 4
Jussi Lehtola - 3
Christoph Wickert - 2
Dan Hor?k - 1
Debarshi Ray - 1
Erik van Pienbroek - 1
Jon Stanley - 1
Kevin Fenzi - 1
Marek Mahut - 1
Michael Schwendt - 1
Michal Schmidt - 1
Robert Scheck - 1
Sven Lankes - 1

Review Requests: 25
Merge Reviews: 1
Total reviews modified: 27

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/09c0c6ca/attachment.sig>

From forum at ru.bir.ru  Mon Jan  5 17:29:48 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 05 Jan 2009 20:29:48 +0300
Subject: /*MerryChristmas.c*/
In-Reply-To: <1230586315.4566.2.camel@localhost.localdomain>
References: <4952A587.5000400@projetofedora.org>	<16de708d0812241616p45e4fab2xc1817c507d0020ec@mail.gmail.com>	<49583AFB.5090903@redhat.com>
	<1230586315.4566.2.camel@localhost.localdomain>
Message-ID: <gjtg2c$rt8$1@ger.gmane.org>

G?rard Milmeister ?????:
> On Sun, 2008-12-28 at 21:50 -0500, Casey Dahlin wrote:
>> Arthur Pemberton wrote:
>>> On Wed, Dec 24, 2008 at 3:11 PM, Rodrigo Padula de Oliveira
>>> <rodrigopadula at projetofedora.org> wrote:
>>>   
>>>> /*MerryChristmas.c*/
>>>> void main (int argc, char* argv[])
>>>> {
>>>>    printf("\n Merry Christmas! \n");
>>>>    if (strcmp(argv[1],"girl") == 0)    /*general idea*/
>>>>        printf("Kisses! \n");
>>>>    else
>>>>        printf("Hugs! \n");
>>>> }
>>>>     
>>>
>>> #i!/bin/env python
>>> import sys
>>> print 'Kisses!' if len(sys.argv) == 2 and sys.argv[1].lower() ==
>>> 'girl' else 'Hugs!'
>>>
>>>   
>> #! /usr/bin/env ruby
>>
>> class Object
>>   def response
>>     "Hugs!"
>>   end
>> end
>>
>> class String
>>   def response
>>     return "Kisses!" if self.downcase == "girl"
>>     super
>>   end
>> end
>>
>> puts "Merry Christmas!\n#{ARGV[0].response}"
> 
> #!/usr/bin/sbcl --script
> (princ #\newline)
> (princ "Merry Christmas!")
> (princ #\newline)
> 
> (let ((argv sb-ext:*posix-argv*))
>   (if (> (length argv) 1)
>       (let ((type (string-downcase (cadr argv))))
>         (if (equal type "girl")
>             (princ "Kisses!")
>             (princ "Hugs!")))))
> 
> (princ #\newline)
> 
> 
#!/usr/bin/php
<?
	if (strtolower(@$argv[1]) == 'girl') /*general idea*/
		echo "Kisses! \n";
	else
		echo "Hugs! \n";
?>



From eric.tanguy at univ-nantes.fr  Mon Jan  5 17:43:50 2009
From: eric.tanguy at univ-nantes.fr (Eric Tanguy)
Date: Mon, 05 Jan 2009 18:43:50 +0100
Subject: Build failed help
Message-ID: <496246D6.8050006@univ-nantes.fr>

I build a package in April for fedora10 
http://koji.fedoraproject.org/koji/buildinfo?buildID=47407 and now i try 
to rebuild the same package 
http://koji.fedoraproject.org/koji/taskinfo?taskID=1033422 and it 
failed. Since i change nothing to this package between the 2 build i 
think something change in fedora10. What i have to do to to build the 
package ?
Thanks
Eric



From jonathan.underwood at gmail.com  Mon Jan  5 17:45:09 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Mon, 5 Jan 2009 17:45:09 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <604aa7910901050923i157356fbr6816254c67601c51@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<20090105132655.c948585c.mschwendt@gmail.com>
	<604aa7910901050817g517fca6bvd5f3113a45a0a33e@mail.gmail.com>
	<645d17210901050859m5999b1c5i94e3224dc04bcd95@mail.gmail.com>
	<604aa7910901050923i157356fbr6816254c67601c51@mail.gmail.com>
Message-ID: <645d17210901050945x31555ec9l67d6a0a99052de52@mail.gmail.com>

2009/1/5 Jeff Spaleta <jspaleta at gmail.com>:
> His home machine links as expected, multiple work machines don't even
> with atlas installed.  Dollars to doughnuts he's using
> LD_LIBRARAY_PATH or has a custom ld.so.conf.d script in place which
> changes if the atlas library is linked.
>

Yes, exactly, the way in which atlas is trying to force the linker to
load its liblapack by a script in /etc/ld..so.conf.d is fragile.

I've filed a bug against atlas:

https://bugzilla.redhat.com/show_bug.cgi?id=478856

J.



From jkeating at redhat.com  Mon Jan  5 17:49:57 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 05 Jan 2009 09:49:57 -0800
Subject: Build failed help
In-Reply-To: <496246D6.8050006@univ-nantes.fr>
References: <496246D6.8050006@univ-nantes.fr>
Message-ID: <1231177797.4566.30.camel@localhost.localdomain>

On Mon, 2009-01-05 at 18:43 +0100, Eric Tanguy wrote:
> I build a package in April for fedora10 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=47407 and now i try 
> to rebuild the same package 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1033422 and it 
> failed. Since i change nothing to this package between the 2 build i 
> think something change in fedora10. What i have to do to to build the 
> package ?
> Thanks
> Eric

error: 
sipAPIscidavis.h: No such file or directory

That error leads to a cascading list of undefined things.  What package
provides that file, perhaps it changed.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/f383b386/attachment.sig>

From mschwendt at gmail.com  Mon Jan  5 18:09:50 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 5 Jan 2009 19:09:50 +0100
Subject: Build failed help
In-Reply-To: <1231177797.4566.30.camel@localhost.localdomain>
References: <496246D6.8050006@univ-nantes.fr>
	<1231177797.4566.30.camel@localhost.localdomain>
Message-ID: <20090105190950.ea81e112.mschwendt@gmail.com>

On Mon, 05 Jan 2009 09:49:57 -0800, Jesse wrote:

> On Mon, 2009-01-05 at 18:43 +0100, Eric Tanguy wrote:
> > I build a package in April for fedora10 
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=47407 and now i try 
> > to rebuild the same package 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=1033422 and it 
> > failed. Since i change nothing to this package between the 2 build i 
> > think something change in fedora10. What i have to do to to build the 
> > package ?
> > Thanks
> > Eric
> 
> error: 
> sipAPIscidavis.h: No such file or directory
> 
> That error leads to a cascading list of undefined things.  What package
> provides that file, perhaps it changed.

Have you tried to remove the SMP make flags from your spec file?



From notting at redhat.com  Mon Jan  5 18:15:35 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 5 Jan 2009 13:15:35 -0500
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
Message-ID: <20090105181535.GB11824@nostromo.devel.redhat.com>

Rakesh Pandit (rakesh.pandit at gmail.com) said: 
>     * Automatically building srpms once they are submitted for package
> review and responding depending upon the result of build.

This allows uncredentialed users to DoS (or worse) the build system,
does it not?

Bill



From nicolas.mailhot at laposte.net  Mon Jan  5 18:20:43 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 05 Jan 2009 19:20:43 +0100
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <20090105181535.GB11824@nostromo.devel.redhat.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
Message-ID: <1231179643.12948.1.camel@arekh.okg>

Le lundi 05 janvier 2009 ? 13:15 -0500, Bill Nottingham a ?crit :
> Rakesh Pandit (rakesh.pandit at gmail.com) said: 
> >     * Automatically building srpms once they are submitted for package
> > review and responding depending upon the result of build.
> 
> This allows uncredentialed users to DoS (or worse) the build system,
> does it not?

Conversely, since guidelines change with time, and packagers have been
known to add stuff later that would never have passed review, some sort
of regular auditing of existing packages would be great.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/a0011c53/attachment.sig>

From tibbs at math.uh.edu  Mon Jan  5 18:25:44 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Jan 2009 12:25:44 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <20090105181535.GB11824@nostromo.devel.redhat.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
Message-ID: <ufaocylvcd3.fsf@epithumia.math.uh.edu>

>>>>> "BN" == Bill Nottingham <notting at redhat.com> writes:

BN> This allows uncredentialed users to DoS (or worse) the build
BN> system, does it not?

It does.  But then, nobody was concerned about this when I indicated
that I would be building many untrusted packages in koji and surely
any automated system would issue its builds at low priority anyway.

 - J<



From eric.tanguy at univ-nantes.fr  Mon Jan  5 18:29:42 2009
From: eric.tanguy at univ-nantes.fr (Eric Tanguy)
Date: Mon, 05 Jan 2009 19:29:42 +0100
Subject: Build failed help
In-Reply-To: <20090105190950.ea81e112.mschwendt@gmail.com>
References: <496246D6.8050006@univ-nantes.fr>	<1231177797.4566.30.camel@localhost.localdomain>
	<20090105190950.ea81e112.mschwendt@gmail.com>
Message-ID: <49625196.9020409@univ-nantes.fr>

Michael Schwendt a ?crit :
> On Mon, 05 Jan 2009 09:49:57 -0800, Jesse wrote:
>
>   
>> On Mon, 2009-01-05 at 18:43 +0100, Eric Tanguy wrote:
>>     
>>> I build a package in April for fedora10 
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=47407 and now i try 
>>> to rebuild the same package 
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=1033422 and it 
>>> failed. Since i change nothing to this package between the 2 build i 
>>> think something change in fedora10. What i have to do to to build the 
>>> package ?
>>> Thanks
>>> Eric
>>>       
>> error: 
>> sipAPIscidavis.h: No such file or directory
>>
>> That error leads to a cascading list of undefined things.  What package
>> provides that file, perhaps it changed.
>>     
>
> Have you tried to remove the SMP make flags from your spec file?
>
>   
The sipAPIscidavis.h never exists so maybe the gcc version changed 
between the 2 builds ?
Removing the SMP flag change nothing.
Eric



From forum at ru.bir.ru  Mon Jan  5 18:33:34 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 05 Jan 2009 21:33:34 +0300
Subject: when update mysql to 5.1.x?
In-Reply-To: <gjfl04$s9k$1@ger.gmane.org>
References: <1230690814.8810.3.camel@localhost.localdomain>
	<gjfl04$s9k$1@ger.gmane.org>
Message-ID: <gjtjpu$9oq$1@ger.gmane.org>

Kevin Kofler ?????:
> ??? wrote:
>> when update mysql to 5.1.x?
> 
> If you can't wait, you can try this:
> http://blog.famillecollet.com/post/2008/11/29/mysql-5.1.30-1
> Not an official Fedora package though.
> 
>         Kevin Kofler
> 
I also use MySQL 5.1 for very long time ago, from few rc-versions on 
production servers this is pretty stable for use on my opinion.

You can try it from my rpm-repository 
http://hubbitus.net.ru/rpm/Fedora9/mysql/



From tibbs at math.uh.edu  Mon Jan  5 18:34:33 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Jan 2009 12:34:33 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <1231179643.12948.1.camel@arekh.okg>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
Message-ID: <ufak599vbye.fsf@epithumia.math.uh.edu>

>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

NM> Conversely, since guidelines change with time, and packagers have
NM> been known to add stuff later that would never have passed review,
NM> some sort of regular auditing of existing packages would be great.

Infinite manpower would be great, too.  Unfortunately at this point I
think the limited amount of reviewer time is better spent dealing
with the incoming queue, which has grown over the holidays.  I also
don't see the situation improving much as long as it is deemed
acceptable to drop large numbers of packages in the queue without
doing something close to a proportional number of reviews.  Several of
us are willing to soak up the extras but it simply isn't enough.

 - J<



From limb at jcomserv.net  Mon Jan  5 18:40:45 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 5 Jan 2009 12:40:45 -0600 (CST)
Subject: gallery2 outstanding security bugs -- Abondoned by Berninger?
In-Reply-To: <20090105180740.GF23775@yellowpig>
References: <baebf0ad794495b06d54b400982d859f.squirrel@mail.jcomserv.net>
	<5269cdd125e01b5cbc512b3bebd964ad.squirrel@mail.jcomserv.net>
	<7892.1228943483@sss.pgh.pa.us>
	<a0f39aee4eadfff273b7151907203906.squirrel@mail.jcomserv.net>
	<13600.1229038307@sss.pgh.pa.us>
	<b9d0db631c0c0ca90cbce9c2675c1c45.squirrel@mail.jcomserv.net>
	<49428284.7050903@pobox.com>
	<eed4e813c2aa264a2127ffb8e73e97a2.squirrel@mail.jcomserv.net>
	<91705d080812181053k526e7da5ydf194633fb0bd245@mail.gmail.com>
	<c36581a7b59348d68dbdecd9d018da71.squirrel@mail.jcomserv.net>
	<20090105180740.GF23775@yellowpig>
Message-ID: <9b2887e24c4ce74ff1356b89428d602b.squirrel@mail.jcomserv.net>


> On Thu, Dec 18, 2008 at 01:21:16PM -0600, Jon Ciesla wrote:
>> access to the project there?  I have a SF account currently.
>>
>> As far as bringing libjpeg current, I'm not sure the task would be as
>> herculean as it sounds, activities at fd.o hotwithstanding, not sure
>> what
>> that's about.
>>
>> State of things as I see them:
>>
>> 1 libjpeg bug in RH/Fedora land.
>>
>> 1 libjpeg bug in Debian. CCing debian libjpeg62 maintainer.
>
> Which bug you are pointing to ?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446821

>> None in Gentoo.  Not sure where OpenSUSE bugs live.  Not sure what other
>> distros to loop into this.
>>
>> What it looks like needs to be done is an examination of the patches
>> used
>> in the above distros, and a discussion over these among the distro
>> maintainers and $_libjpeg_upstream_designee, leading to integration of
>> those most commonly used in the distros.
>>
>> Does this sound sane?
>
> The most important thing is that everybody standardize on the same
> API and ABI for the successor of libjpeg6b. This means not only the same
> source tarball, but also the same set of optionnal features activated
> for /usr/lib/libjpeg.so in all distros.
>
> Cheers,
> --
> Bill. <ballombe at debian.org>
>
> Imagine a large red swirl here.
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From notting at redhat.com  Mon Jan  5 18:58:27 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 5 Jan 2009 13:58:27 -0500
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaocylvcd3.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
Message-ID: <20090105185827.GD11824@nostromo.devel.redhat.com>

Jason L Tibbitts III (tibbs at math.uh.edu) said: 
> BN> This allows uncredentialed users to DoS (or worse) the build
> BN> system, does it not?
> 
> It does.  But then, nobody was concerned about this when I indicated
> that I would be building many untrusted packages in koji and surely
> any automated system would issue its builds at low priority anyway.

Right, but you're an authorized user who (may) do some sort of rudimentary
check for '100 GB source tarball' or 'is an obvious trojan', etc. before
submitting the build. Would this automated system do that?

Bill



From Matt_Domsch at dell.com  Mon Jan  5 19:08:04 2009
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Mon, 5 Jan 2009 13:08:04 -0600
Subject: GPG Keysigning at FUDConF11
Message-ID: <20090105190804.GA2732@auslistsprd01.us.dell.com>

I'll be running a GPG Keysigning session at the FUDConF11 this coming
Saturday in Cambridge, MA.  If you would like to participate, see

  http://domsch.com/blog/?p=23

for instructions.  You'll want to send your keys (as noted) ahead of
time (now would be just fine...)

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From forum at ru.bir.ru  Mon Jan  5 19:14:02 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Mon, 05 Jan 2009 22:14:02 +0300
Subject: Orphaning printoxx and fotoxx
In-Reply-To: <496102C3.7040403@gmail.com>
References: <496102C3.7040403@gmail.com>
Message-ID: <gjtm5q$ka8$1@ger.gmane.org>

Nicoleau Fabien ?????:
> Hello,
> As I'm no more using these 2 packages and can't continue maintain them, 
> I'm orphaning printoxx and fotoxx for devel, F10 and F9 branches.
> (printoxx is used as a dependancy for fotoxx).
> 
> 
> Regards,
> 
> Fabien
> 
I'm also not using this packages, but take it to maintain, if any more 
do not want.



From debarshi.ray at gmail.com  Mon Jan  5 18:46:46 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 00:16:46 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaocylvcd3.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901051046k71d7ecf7p7ef03e41dc3d4662@mail.gmail.com>

> surely
> any automated system would issue its builds at low priority anyway.

https://fedorahosted.org/review-o-matic/ticket/2

Cheers,
Debarshi



From tibbs at math.uh.edu  Mon Jan  5 19:35:26 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 05 Jan 2009 13:35:26 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <20090105185827.GD11824@nostromo.devel.redhat.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
Message-ID: <ufafxjxv94x.fsf@epithumia.math.uh.edu>

>>>>> "BN" == Bill Nottingham <notting at redhat.com> writes:

BN> Right, but you're an authorized user who (may) do some sort of
BN> rudimentary check for '100 GB source tarball' or 'is an obvious
BN> trojan', etc. before submitting the build. Would this automated
BN> system do that?

Well, that's a fair question, and do note that I have no involvement
with the currently proposed system.  (I don't even agree with the name
that's been chosen for it.)  But when I initially talked about
scraping the last src.rpm posted in every open package review ticket
and dumping it on koji, people didn't raise any issues.  I was
specifically asking about where there were any security or DOS issues
involved in that.  It is entirely possible that folks behind the
current proposal saw that discussion.

 - J<



From mjg at redhat.com  Mon Jan  5 19:56:39 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Mon, 5 Jan 2009 19:56:39 +0000
Subject: Atlas and lapack provide the same library..compiled
	differently... is that a problem?
In-Reply-To: <645d17210901050418k8135662ib267cf8a20e1be8c@mail.gmail.com>
References: <604aa7910901041408y534f3ccaye0838c23f2385b0e@mail.gmail.com>
	<gjrdop$unf$2@ger.gmane.org>
	<645d17210901041444p53418ca7j1b821b33a3522bfd@mail.gmail.com>
	<gjreki$unf$6@ger.gmane.org>
	<645d17210901041615x31372b94gca8c40d23e94e06d@mail.gmail.com>
	<604aa7910901041638i70f26662l658bbe4965375c99@mail.gmail.com>
	<645d17210901050418k8135662ib267cf8a20e1be8c@mail.gmail.com>
Message-ID: <20090105195639.GA9055@srcf.ucam.org>

On Mon, Jan 05, 2009 at 12:18:40PM +0000, Jonathan Underwood wrote:

> [Or liblapack should be set up using alternatives. Not sure if
> alternatives works for libraries? Actually, what's really needed as
> some sort of simple way for the user to select which library is used
> when two or more have the same name.]

What's needed is for us not to be distributing two libraries with the 
same SONAME and differing ABIs, I think. It's pretty inevitably going to 
lead to failure.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From surenkarapetyan at gmail.com  Mon Jan  5 20:01:59 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Tue, 06 Jan 2009 00:01:59 +0400
Subject: sound problems
In-Reply-To: <68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
Message-ID: <49626737.7020109@gmail.com>

Paulo Cavalcanti wrote:
>
>
> On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone 
> <chris.stone at gmail.com <mailto:chris.stone at gmail.com>> wrote:
>
>     2009/1/4 Paulo Cavalcanti <promac at gmail.com
>     <mailto:promac at gmail.com>>:
>     > You can try the latest alsa snapshot available in ATrpms:
>
>     Whoa, bad advice...anyone with half a brain knows to stay well clear
>     of anything coming from ATrpms.  Axel Thimm is one of the the worst
>     packagers in the Fedora community, and installing his packages is
>     *extremely* dangerous.
>
>     Anyway, I have this sound problem too, thanks atleast for pointing me
>     to the bug number...
>
>
> Well, a lot of packages in ATrpms are mine. Including this alsa snapshot.
> I am the person who spent almost two weeks with Takashi trying to debug
> the sigmatel codec. Therefore, I think your comment is directed to me.
>
Thanks for Your hard work!
But the problem is not just with sigmatel.
It looks like many people with different configurations have problems 
with the new alsa.
I'm sure trying to fix them one by one in F10 is WRONG.
It's already ~10 days sound is broken for many users.
Most of them are not on this list/bugzilla. They just try to play a song 
and hear no sound and say "This fedora thing is bad. I should switch to 
RHEL/CentOS/Ubuntu/MAC/Windows."
Fixing the problems one by one may last for days or weeks or even months.
What guaranties to bring sound back to everyone for whom it worked 10 
days ago is reverting ALSA to previews version.
Then we can switch to ALSA 1.0.18a in rawhide where none will be upset 
to not have sound for a month or two.



From itamar at ispbrasil.com.br  Mon Jan  5 20:09:14 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Mon, 5 Jan 2009 18:09:14 -0200
Subject: co-maintaing ss5
Message-ID: <d3ceea380901051209w615b90e6i8ba0d46ee5b1c67b@mail.gmail.com>

ss5 have 5 bugs, all easy to fix, but current maintaner seems too busy

https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5

Can I co-maintain it ?



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From jspaleta at gmail.com  Mon Jan  5 20:37:18 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 5 Jan 2009 11:37:18 -0900
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <20090105185827.GD11824@nostromo.devel.redhat.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
Message-ID: <604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>

On Mon, Jan 5, 2009 at 9:58 AM, Bill Nottingham <notting at redhat.com> wrote:
> Right, but you're an authorized user who (may) do some sort of rudimentary
> check for '100 GB source tarball' or 'is an obvious trojan', etc. before
> submitting the build. Would this automated system do that?

Limiting the number of requested queued builds in koji from this
system(or any user) might help limit DoS risk exposure. Putting some
limits on the srpm size which is allowed to be submitted would also
help.  This system could implement these sort of limit checks as part
of the service if there was no desire to put the limits in koji
itself.

This automation does however bring up issues with koji resources. How
long do we make automated builds available for download before they
are garbage collected to make room for more? How much of koji's
diskspace cache should be allocated to support automated review
builds?

Is koji garbage collecting binary builds currently?

The obvious trojan question is another issue entirely and would
require deep musing on what it means for anything to be obviously
malicious versus desired functionality.  As long as we can adequately
keep these packages from being candidates for repository inclusion
this issue is less problematic.

And then there is the related question... what about things which have
legal issues that would otherwise prevent us from normally
distributing. By automating the builds of such submissions are we
opening ourselves to enhanced legal risk?

I think if we limit this service to packages only from people who have
signed the appropriate CLA and are a sponsored contributor I think
both the obvious trojan risk and the legal liability of distribution
risk fall within already acceptable levels comparable to the review
process we have.  I would not offer this service to package from any
new contributor who has not gone through the sponsorship
process..unless a sponsored contributor signs off and lets the
autobuilds go forward.

-jef



From nicolas.mailhot at laposte.net  Mon Jan  5 20:46:16 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 05 Jan 2009 21:46:16 +0100
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufak599vbye.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
Message-ID: <1231188376.17459.0.camel@arekh.okg>

Le lundi 05 janvier 2009 ? 12:34 -0600, Jason L Tibbitts III a ?crit :
> >>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:
> 
> NM> Conversely, since guidelines change with time, and packagers have
> NM> been known to add stuff later that would never have passed review,
> NM> some sort of regular auditing of existing packages would be great.
> 
> Infinite manpower would be great, too.  Unfortunately at this point I
> think the limited amount of reviewer time is better spent dealing
> with the incoming queue, which has grown over the holidays.

Which is why a bot like ReviewOMatic would be better suited for this
kind of continuous testing than human reviewers

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/cda2587f/attachment.sig>

From jkeating at redhat.com  Mon Jan  5 20:53:47 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 05 Jan 2009 12:53:47 -0800
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
Message-ID: <1231188827.4566.36.camel@localhost.localdomain>

On Mon, 2009-01-05 at 11:37 -0900, Jeff Spaleta wrote:
> Is koji garbage collecting binary builds currently?

Yes, and these would be scratch builds which are cleaned up more
aggressively anyway.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/9ae38e3a/attachment.sig>

From notting at redhat.com  Mon Jan  5 21:02:22 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 5 Jan 2009 16:02:22 -0500
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
Message-ID: <20090105210222.GA20265@nostromo.devel.redhat.com>

Jeff Spaleta (jspaleta at gmail.com) said: 
> I think if we limit this service to packages only from people who have
> signed the appropriate CLA and are a sponsored contributor I think
> both the obvious trojan risk and the legal liability of distribution
> risk fall within already acceptable levels comparable to the review
> process we have.

That's not bad; it's simple, should be easy to implement, and should get rid
of most of the direct risks.

Bill



From konrad at tylerc.org  Mon Jan  5 21:04:49 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 5 Jan 2009 13:04:49 -0800
Subject: co-maintaing ss5
In-Reply-To: <d3ceea380901051209w615b90e6i8ba0d46ee5b1c67b@mail.gmail.com>
References: <d3ceea380901051209w615b90e6i8ba0d46ee5b1c67b@mail.gmail.com>
Message-ID: <200901051304.49921.konrad@tylerc.org>

On Monday 05 January 2009 12:09:14 pm Itamar Reis Peixoto wrote:
> ss5 have 5 bugs, all easy to fix, but current maintaner seems too busy
>
> https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5
>
> Can I co-maintain it ?
>
>
>
> --
> ------------
>
> Itamar Reis Peixoto
>
> e-mail/msn: itamar at ispbrasil.com.br
> sip: itamar at ispbrasil.com.br
> skype: itamarjp
> icq: 81053601
> +55 11 4063 5033
> +55 34 3221 8599

Ask him (or her).

-- 
Conrad Meyer <konrad at tylerc.org>




From limb at jcomserv.net  Mon Jan  5 21:09:58 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Mon, 5 Jan 2009 15:09:58 -0600 (CST)
Subject: co-maintaing ss5
In-Reply-To: <200901051304.49921.konrad@tylerc.org>
References: <d3ceea380901051209w615b90e6i8ba0d46ee5b1c67b@mail.gmail.com>
	<200901051304.49921.konrad@tylerc.org>
Message-ID: <956641217ad5306f85ec9e9863b08992.squirrel@mail.jcomserv.net>


> On Monday 05 January 2009 12:09:14 pm Itamar Reis Peixoto wrote:
>> ss5 have 5 bugs, all easy to fix, but current maintaner seems too busy
>>
>> https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5
>>
>> Can I co-maintain it ?
>>
>>
>>
>> --
>> ------------
>>
>> Itamar Reis Peixoto
>>
>> e-mail/msn: itamar at ispbrasil.com.br
>> sip: itamar at ispbrasil.com.br
>> skype: itamarjp
>> icq: 81053601
>> +55 11 4063 5033
>> +55 34 3221 8599
>
> Ask him (or her).

He (or she) has.

https://admin.fedoraproject.org/pkgdb/packages/name/ss5

> --
> Conrad Meyer <konrad at tylerc.org>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From Fedora at FamilleCollet.com  Mon Jan  5 21:15:33 2009
From: Fedora at FamilleCollet.com (Remi Collet)
Date: Mon, 05 Jan 2009 22:15:33 +0100
Subject: PHP 5.2.8 available in updates-testing and in buildroot
Message-ID: <49627875.4050001@FamilleCollet.com>

Hi,

If you maintain a package requiring php-embedded (libphp5-5.2.6.so),
it's time to rebuild it against the new version (php 5.2.8 is tagged as
dist-f9-override and dist-f10-override).

Please contact me (direct email) to add it (if possible) to the existing
update.

Happy new year all !
Remi.

P.S. php-pecl extension must not be affected as ABI is stable.



From debarshi.ray at gmail.com  Mon Jan  5 21:16:09 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 02:46:09 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaocylvcd3.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901051316h3e0806d5p11e4762489af22f5@mail.gmail.com>

> BN> This allows uncredentialed users to DoS (or worse) the build
> BN> system, does it not?
>
> It does.  But then, nobody was concerned about this when I indicated
> that I would be building many untrusted packages in koji and surely
> any automated system would issue its builds at low priority anyway.

These issues arise when we get to the point of running Review-O-Matic
or RoM over the entire review queue, or over the entire repository to
check for deviations from the guidelines. If we just look at the
usecase of a reviewer using RoM to take care of the monotonous parts
of a review, or a packager using it to sanity check his submission,
most of these issues don't arise and it is still useful.

Cheers,
Debarshi



From mike at cchtml.com  Mon Jan  5 21:28:54 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 05 Jan 2009 15:28:54 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901051316h3e0806d5p11e4762489af22f5@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>	<20090105181535.GB11824@nostromo.devel.redhat.com>	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<3170f42f0901051316h3e0806d5p11e4762489af22f5@mail.gmail.com>
Message-ID: <49627B96.1080408@cchtml.com>

-------- Original Message --------
Subject: Re: proposal for fedora11 feature ReviewOMatic
From: Debarshi Ray <debarshi.ray at gmail.com>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 01/05/2009 03:16 PM

> 
> These issues arise when we get to the point of running Review-O-Matic
> or RoM over the entire review queue, or over the entire repository to
> check for deviations from the guidelines. If we just look at the
> usecase of a reviewer using RoM to take care of the monotonous parts
> of a review, or a packager using it to sanity check his submission,
> most of these issues don't arise and it is still useful.


Since these are not "official" packages yet, do they need to be built on 
koji?

Yes, a new system involves additional hardware (even if in a VM), and 
replication to insure the build environment matches koji, but it would 
alleviate a lot of the issues brought up.



From debarshi.ray at gmail.com  Mon Jan  5 21:33:10 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 03:03:10 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901051316h3e0806d5p11e4762489af22f5@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<3170f42f0901051316h3e0806d5p11e4762489af22f5@mail.gmail.com>
Message-ID: <3170f42f0901051333h31a4ba27n19900822c6d9b3b4@mail.gmail.com>

>> BN> This allows uncredentialed users to DoS (or worse) the build
>> BN> system, does it not?
>>
>> It does.  But then, nobody was concerned about this when I indicated
>> that I would be building many untrusted packages in koji and surely
>> any automated system would issue its builds at low priority anyway.

By the way, we plan to have a RomMockBuilder similar to RomKojiBuilder too.

Cheers,
Debarshi



From Fedora at FamilleCollet.com  Mon Jan  5 21:34:44 2009
From: Fedora at FamilleCollet.com (Remi Collet)
Date: Mon, 05 Jan 2009 22:34:44 +0100
Subject: PHP 5.2.8 available in updates-testing and in buildroot
In-Reply-To: <49627875.4050001@FamilleCollet.com>
References: <49627875.4050001@FamilleCollet.com>
Message-ID: <49627CF4.5090303@FamilleCollet.com>

$ repoquery --whatrequires 'libphp5-5.2.6.so()(64bit)'
php-embedded-0:5.2.6-6.fc10.remi.x86_64
maniadrive-track-editor-0:1.2-10.fc10.x86_64
raydium-0:1.2-10.fc10.x86_64
php-embedded-0:5.2.6-5.x86_64
maniadrive-0:1.2-10.fc10.x86_64

:)



From chris.stone at gmail.com  Mon Jan  5 21:40:52 2009
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 5 Jan 2009 13:40:52 -0800
Subject: sound problems
In-Reply-To: <49623433.9020800@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
Message-ID: <d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>

On Mon, Jan 5, 2009 at 8:24 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Christopher Stone wrote:
>>
>> 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
>>>
>>> You can try the latest alsa snapshot available in ATrpms:
>>
>> Whoa, bad advice...anyone with half a brain knows to stay well clear
>> of anything coming from ATrpms.  Axel Thimm is one of the the worst
>> packagers in the Fedora community, and installing his packages is
>> *extremely* dangerous.
>
> Oh come on. We don't need to rehash the friendly discussion you had in
> fedora-maintainers list before. Yes, conflicting packages in repositories
> has been a problem in many occasions but attacking Axel isn't the right
> solution to that problem. Please refrain from doing so.

Rahul, you should know that my post to the Maintainers list was
basically an exact version of a post Axel made on the developers list.
 I was simply showing the maintainers how Axel acts.

The only solution to the Axel problem is to avoid Axel and his
packages at all cost.  This is simply the advice I am giving here.

I will not refrain from telling the truth about Axel, I'm sorry if the
truth bothers you...



From itamar at ispbrasil.com.br  Mon Jan  5 21:56:35 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Mon, 5 Jan 2009 19:56:35 -0200
Subject: co-maintaing ss5
In-Reply-To: <956641217ad5306f85ec9e9863b08992.squirrel@mail.jcomserv.net>
References: <d3ceea380901051209w615b90e6i8ba0d46ee5b1c67b@mail.gmail.com>
	<200901051304.49921.konrad@tylerc.org>
	<956641217ad5306f85ec9e9863b08992.squirrel@mail.jcomserv.net>
Message-ID: <d3ceea380901051356h6a40facbpabefe08808b2faf2@mail.gmail.com>

L@@k

someone is asking since 2007

Bug 229141 Reported: 2007-02-18 06:37

and He (or she) has only one package.




On Mon, Jan 5, 2009 at 7:09 PM, Jon Ciesla <limb at jcomserv.net> wrote:
>
>> On Monday 05 January 2009 12:09:14 pm Itamar Reis Peixoto wrote:
>>> ss5 have 5 bugs, all easy to fix, but current maintaner seems too busy
>>>
>>> https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5
>>>
>>> Can I co-maintain it ?
>>>

>> Ask him (or her).
>
> He (or she) has.
>
> https://admin.fedoraproject.org/pkgdb/packages/name/ss5
>
>> --
>> Conrad Meyer <konrad at tylerc.org>
>>



From chris.stone at gmail.com  Mon Jan  5 21:44:00 2009
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 5 Jan 2009 13:44:00 -0800
Subject: sound problems
In-Reply-To: <68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
Message-ID: <d9c612bf0901051344pb12bfc2ldb5f79eea382c9b2@mail.gmail.com>

2009/1/5 Paulo Cavalcanti <promac at gmail.com>:
>
>
> On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone <chris.stone at gmail.com>
> wrote:
>>
>> 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
>> > You can try the latest alsa snapshot available in ATrpms:
>>
>> Whoa, bad advice...anyone with half a brain knows to stay well clear
>> of anything coming from ATrpms.  Axel Thimm is one of the the worst
>> packagers in the Fedora community, and installing his packages is
>> *extremely* dangerous.
>>
>> Anyway, I have this sound problem too, thanks atleast for pointing me
>> to the bug number...
>>
>
> Well, a lot of packages in ATrpms are mine. Including this alsa snapshot.
> I am the person who spent almost two weeks with Takashi trying to debug
> the sigmatel codec. Therefore, I think your comment is directed to me.

No it was not directed towards you.  Although why you would contribute
to ATrpms and not to Fedora directly is way beyond my capability of
understanding...people should be avoiding ATrpms like the plague.



From pronix.service at gmail.com  Mon Jan  5 22:18:26 2009
From: pronix.service at gmail.com (pronix pronix)
Date: Tue, 6 Jan 2009 01:18:26 +0300
Subject: sound problems
In-Reply-To: <d9c612bf0901051344pb12bfc2ldb5f79eea382c9b2@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<d9c612bf0901051344pb12bfc2ldb5f79eea382c9b2@mail.gmail.com>
Message-ID: <639ce0480901051418tc75080clbd7c8d3a21ab97c6@mail.gmail.com>

i resolve this problem - build kernel 2.6.28

2009/1/6 Christopher Stone <chris.stone at gmail.com>:
> 2009/1/5 Paulo Cavalcanti <promac at gmail.com>:
>>
>>
>> On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone <chris.stone at gmail.com>
>> wrote:
>>>
>>> 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
>>> > You can try the latest alsa snapshot available in ATrpms:
>>>
>>> Whoa, bad advice...anyone with half a brain knows to stay well clear
>>> of anything coming from ATrpms.  Axel Thimm is one of the the worst
>>> packagers in the Fedora community, and installing his packages is
>>> *extremely* dangerous.
>>>
>>> Anyway, I have this sound problem too, thanks atleast for pointing me
>>> to the bug number...
>>>
>>
>> Well, a lot of packages in ATrpms are mine. Including this alsa snapshot.
>> I am the person who spent almost two weeks with Takashi trying to debug
>> the sigmatel codec. Therefore, I think your comment is directed to me.
>
> No it was not directed towards you.  Although why you would contribute
> to ATrpms and not to Fedora directly is way beyond my capability of
> understanding...people should be avoiding ATrpms like the plague.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From sundaram at fedoraproject.org  Mon Jan  5 22:20:10 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 03:50:10 +0530
Subject: sound problems
In-Reply-To: <d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
Message-ID: <4962879A.9020603@fedoraproject.org>

Christopher Stone wrote:
> Rahul, you should know that my post to the Maintainers list was
> basically an exact version of a post Axel made on the developers list.
>  I was simply showing the maintainers how Axel acts.
> 
> The only solution to the Axel problem is to avoid Axel and his
> packages at all cost.  This is simply the advice I am giving here.
> 
> I will not refrain from telling the truth about Axel, I'm sorry if the
> truth bothers you...

What bothers me is the way you choose to express your opinions towards a 
fellow contributor. You can disagree without being so rude.

Rahul



From roland at redhat.com  Mon Jan  5 22:37:36 2009
From: roland at redhat.com (Roland McGrath)
Date: Mon,  5 Jan 2009 14:37:36 -0800 (PST)
Subject: debuginfo audit
Message-ID: <20090105223736.2BEC5FC299@magilla.sf.frob.com>

I've been setting up to do mass tests on all the debuginfo files,
and I've generated some data along the way.

http://roland.fedorapeople.org/tmp/rawhide-debuginfo-summary.bz2

See https://fedorahosted.org/pipermail/elfutils-devel/2009-January/000065.html
for how to generate the data and how to grok the file.

An industrious volunteer could grep that for "missing", collate the results,
and look into the cases.  For each hit, filter out any old rpms superceded
by new builds in the summary, and categorize the case.

"src missing" means the debuginfo package appeared to contain no
/usr/src/debug files, but may have had some ELF .debug files.

"debug missing" means the package appeared to contain no ELF
files in /usr/lib/debug.

If both are missing, the debuginfo rpm might be entirely empty.  Look
into why the particular package produced nothing.  That might suggest
a package with non-compiled code or something that probably should
suppress making a debuginfo rpm.  It might also be a package whose
%install stripped everything, which should be fixed.

If just "src missing", that might be in an rpm all of whose ELF files
actually have no DWARF.  (I'm generating a list of all such files too.)
That can have several possible causes, some that should be fixed and
some that are just acceptable reality.  Should categorize each
affected package/file as to which.  I'll post more details about that
when I've got the file-by-file data (chugging now).


Thanks,
Roland



From Axel.Thimm at ATrpms.net  Mon Jan  5 22:38:43 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 00:38:43 +0200
Subject: Make love not war (was: sound problems)
In-Reply-To: <4962879A.9020603@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
Message-ID: <20090105223843.GC17823@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 03:50:10AM +0530, Rahul Sundaram wrote:
> Christopher Stone wrote:
>> Rahul, you should know that my post to the Maintainers list was
>> basically an exact version of a post Axel made on the developers
>> list.  I was simply showing the maintainers how Axel acts.

I'm sorry, did I miss something? What mails to maintainers and devel
lists? I hope, Christopher, you are not referring to the old mail I
had to write a year or two ago about you harassing me in lists and
bugzillas. I hoped that you would have grown up by now.

>> The only solution to the Axel problem is to avoid Axel and his
>> packages at all cost.  This is simply the advice I am giving here.

Well, the solution to Axel implies that Axel is a problem, which I
disagree. Call me biased, egoist, whatever. I see the problem in
completely unrelated and misplaced "hate you" posts.

>> I will not refrain from telling the truth about Axel, I'm sorry if
>> the truth bothers you...
>
> What bothers me is the way you choose to express your opinions
> towards a fellow contributor. You can disagree without being so
> rude.

Anyway, it's sad to see Christopher's hate parade tuning in
again. Yes, I get it by now, Christopher, you hate me, no need to
restate that again and again. Merry Xmas to you as well. ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/96614cfc/attachment.sig>

From roland at redhat.com  Mon Jan  5 23:38:53 2009
From: roland at redhat.com (Roland McGrath)
Date: Mon,  5 Jan 2009 15:38:53 -0800 (PST)
Subject: debuginfo audit: missing DWARF
Message-ID: <20090105233853.48E9CFC299@magilla.sf.frob.com>


http://roland.fedorapeople.org/tmp/rawhide-debuginfo-missing-dwarf.bz2

This is a big list (small file) of all the ELF files in rawhide debuginfo
rpms that have no DWARF information.  Each line looks like e.g.:

zenon-debuginfo-0.5.0-3.fc10.i386:usr:lib:debug:usr:bin:zenon.debug

meaning that in zenon-debuginfo-0.5.0-3.fc10.i386 the file
/usr/lib/debug/usr/bin/zenon.debug exists and is an ELF file,
but has no DWARF in it.

I have not looked at any of the cases.  An industrious volunteer could
collate all these along with the "missing" cases from the summary, filter
out superceded rpms, and categorize the cases.

DWARFless ELF files in debuginfo packages are most likely .debug files that
contain a symbol table but no DWARF.  This might be because the binary was
built without -g, which may indicate the package didn't use $RPM_OPT_FLAGS
correctly.  It's also possibly had 'strip -g' run on it, which would be
unusual and presumably happening somewhere inside the upstream makefiles
when the package maintainer didn't realize it was happening.

It might also be a legitimate case of some other kind of executable
generation for some language that never produces DWARF.

Other cases might be something odd that should be looked into it.

There is probably a lot of overlap with the "src missing" cases,
e.g. from whole packages built without -g.  There are many individual
cases flagged, but I suspect that almost all boil down to the same two or
three common issues.  We can categorize all the cases and then for each
issue either fix the packages, or document the categories that raise red
flags in this kind of audit but aren't build problems that can be fixed.


Thanks,
Roland



From peter at thecodergeek.com  Tue Jan  6 01:35:44 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 05 Jan 2009 17:35:44 -0800
Subject: Heads-Up: rb_libtorrent 0.14.1 Bump (API/ABI changes from 0.13.x,
 Python egg-info data renamed)
Message-ID: <1231205744.5570.67.camel@localhost.localdomain>

Hi, all. 

I just pushed a bump of rb_libtorrent-0.14.1 to Rawhide, which should
hit tomorrow's compose. 

This update contains many API changes and updates as well as a soname
change (libtorrent-rasterbar.so.0 --> libtorrent-rasterbar.so.1).

According to repoquery, the only package that depends on rb_libtorrent
is linkage, which requires significant changes to build properly against
this new version. I have filed bug #478924 [1] with the beginnings of a
patch for it, but it still requires a lot of TLC in terms of the code
logic that I cannot fix, since I am not familiar with the details of its
codebase.

The name of the egg-info data has also been changed from 'libtorrent' to
'python-libtorrent'.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=478924

Please don't hesitate me if any related issues arise from this update.

Thanks.
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.com>
???????????
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/f75306fb/attachment.sig>

From chris.stone at gmail.com  Tue Jan  6 02:30:36 2009
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 5 Jan 2009 18:30:36 -0800
Subject: sound problems
In-Reply-To: <4962879A.9020603@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
Message-ID: <d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>

On Mon, Jan 5, 2009 at 2:20 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Christopher Stone wrote:
>>
>> Rahul, you should know that my post to the Maintainers list was
>> basically an exact version of a post Axel made on the developers list.
>>  I was simply showing the maintainers how Axel acts.
>>
>> The only solution to the Axel problem is to avoid Axel and his
>> packages at all cost.  This is simply the advice I am giving here.
>>
>> I will not refrain from telling the truth about Axel, I'm sorry if the
>> truth bothers you...
>
> What bothers me is the way you choose to express your opinions towards a
> fellow contributor. You can disagree without being so rude.

Yea, I could, but in the case of Axel Thimm he has caused me, and
countless others, many headaches so I wont be tactful.  In addition,
it is a stretch to call Axel Thimm a "contributor", unless you want to
count bugs, headaches, forked code and broken systems a contribution.



From stickster at gmail.com  Tue Jan  6 03:02:55 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 5 Jan 2009 22:02:55 -0500
Subject: sound problems
In-Reply-To: <d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
Message-ID: <20090106030255.GJ21964@localhost.localdomain>

On Mon, Jan 05, 2009 at 06:30:36PM -0800, Christopher Stone wrote:
> On Mon, Jan 5, 2009 at 2:20 PM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
> > Christopher Stone wrote:
> >>
> >> Rahul, you should know that my post to the Maintainers list was
> >> basically an exact version of a post Axel made on the developers list.
> >>  I was simply showing the maintainers how Axel acts.
> >>
> >> The only solution to the Axel problem is to avoid Axel and his
> >> packages at all cost.  This is simply the advice I am giving here.
> >>
> >> I will not refrain from telling the truth about Axel, I'm sorry if the
> >> truth bothers you...
> >
> > What bothers me is the way you choose to express your opinions towards a
> > fellow contributor. You can disagree without being so rude.
> 
> Yea, I could, but in the case of Axel Thimm he has caused me, and
> countless others, many headaches so I wont be tactful.  In addition,
> it is a stretch to call Axel Thimm a "contributor", unless you want to
> count bugs, headaches, forked code and broken systems a contribution.

Please stop this unproductive and pointless thread.  You've made your
point, albeit rudely, and you're simply baiting now.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/886aea3a/attachment.sig>

From jspaleta at gmail.com  Tue Jan  6 03:04:17 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 5 Jan 2009 18:04:17 -0900
Subject: sound problems
In-Reply-To: <d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
Message-ID: <604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>

On Mon, Jan 5, 2009 at 5:30 PM, Christopher Stone <chris.stone at gmail.com> wrote:
> Yea, I could, but in the case of Axel Thimm he has caused me, and
> countless others, many headaches so I wont be tactful.  In addition,
> it is a stretch to call Axel Thimm a "contributor", unless you want to
> count bugs, headaches, forked code and broken systems a contribution.

I can't let this stand.  This public character assassination
absolutely must stop.  As an outgoing Board member I am appalled by
this sort of deliberate attempt to go out of your way to besmirk a
fellow contributor's direct contributions to this project.  The
accusation that Axel does not constructively contribute to the
packaging process is easily contradicted by looking at the package
database.

Here a subset of Axel's direct contributions to Fedora:
https://admin.fedoraproject.org/pkgdb/users/packages/athimm

And more to the point, there are many public 3rd party repositories
out there which conflict to varying degrees with the official Fedora
repositories.   Do you plan to ridicule each and every contributor who
runs a 3rd party repo on the side which conflicts? Any Fedora
contributor which chooses to run a repository on the side is their
choice and its a users choice to mix and match repositories or not.

I may disagree with Axel's choice to spend as much energy as he does
maintaining Atrpms and supporting the userbase...but I'm not going to
single him out and ridicule him publicly for making that choice when
others continue to make that choice as well.

Axel if you are still reading this, for what its worth, I'm extremely
sorry that the disagreements over Atrpms are being publicly discussed
on this fedora mailinglist in the form of a personal attack.  There is
a very long history here, and I thought we had for the most part moved
past most of the personal demonizing at least in the fedora
mailinglists proper.   if I have in any way done anything to foster
this level of personal animosity in any discussion concerning the
technical issues around 3rd party repos and package conflicts I
sincerely apologize.

-jef



From konrad at tylerc.org  Tue Jan  6 03:16:25 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Mon, 5 Jan 2009 19:16:25 -0800
Subject: sound problems
In-Reply-To: <604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
Message-ID: <200901051916.25386.konrad@tylerc.org>

On Monday 05 January 2009 07:04:17 pm Jeff Spaleta wrote:
> Here a subset of Axel's direct contributions to Fedora:
> https://admin.fedoraproject.org/pkgdb/users/packages/athimm

And here's a subset of his directly destructive behavior towards Fedora:
http://atrpms.net/dist/f10/

> And more to the point, there are many public 3rd party repositories
> out there which conflict to varying degrees with the official Fedora
> repositories.   Do you plan to ridicule each and every contributor who
> runs a 3rd party repo on the side which conflicts?

Yes.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From chris.stone at gmail.com  Tue Jan  6 03:39:55 2009
From: chris.stone at gmail.com (Christopher Stone)
Date: Mon, 5 Jan 2009 19:39:55 -0800
Subject: sound problems
In-Reply-To: <604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
Message-ID: <d9c612bf0901051939n3fec7301oe5d25e7128cbaab4@mail.gmail.com>

On Mon, Jan 5, 2009 at 7:04 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> And more to the point, there are many public 3rd party repositories
> out there which conflict to varying degrees with the official Fedora
> repositories.   Do you plan to ridicule each and every contributor who
> runs a 3rd party repo on the side which conflicts? Any Fedora
> contributor which chooses to run a repository on the side is their
> choice and its a users choice to mix and match repositories or not.

Amazingly, ATrpms is so bad, that it is the only repository I recall
hearing people constantly complain about on IRC.  I only plan to
ridicule those 3rd party repositories which actually cause problems
for Fedora users and do more harm than good, and no effort is made to
fix problems in the repository.  ATrpms is the only 3rd party repo I
am aware of which meet all of these criteria.

As a board member or ambassador or whatever you are, you should do
everything in your power to make sure that Fedora users are well aware
of the dangers of using ATrpms, and are well aware that Axel Thimm has
no intentions of fixing any bugs which may cause a broken Fedora
system.  As I recall, I posted over one hundred bugs over a year ago
and not a single one has been touched by Axel.



From kevin.kofler at chello.at  Tue Jan  6 04:12:27 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 05:12:27 +0100
Subject: Build failed help
References: <496246D6.8050006@univ-nantes.fr>	<1231177797.4566.30.camel@localhost.localdomain>
	<20090105190950.ea81e112.mschwendt@gmail.com>
	<49625196.9020409@univ-nantes.fr>
Message-ID: <gjulnb$h9q$1@ger.gmane.org>

Eric Tanguy wrote:
> The sipAPIscidavis.h never exists so maybe the gcc version changed
> between the 2 builds ?

sip was recently upgraded.

        Kevin Kofler



From rakesh.pandit at gmail.com  Tue Jan  6 04:17:48 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 6 Jan 2009 09:47:48 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <20090105210222.GA20265@nostromo.devel.redhat.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
	<20090105210222.GA20265@nostromo.devel.redhat.com>
Message-ID: <b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>

2009/1/6 Bill Nottingham <notting at redhat.com>:
> Jeff Spaleta (jspaleta at gmail.com) said:
>> I think if we limit this service to packages only from people who have
>> signed the appropriate CLA and are a sponsored contributor I think
>> both the obvious trojan risk and the legal liability of distribution
>> risk fall within already acceptable levels comparable to the review
>> process we have.
>
> That's not bad; it's simple, should be easy to implement, and should get rid
> of most of the direct risks.
>

+1
Noted down.

https://fedorahosted.org/review-o-matic/ticket/3

-- 
rakesh



From mail at michaelmondragon.net  Tue Jan  6 04:21:59 2009
From: mail at michaelmondragon.net (Michael Mondragon)
Date: Tue, 6 Jan 2009 12:21:59 +0800
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
	<20090105210222.GA20265@nostromo.devel.redhat.com>
	<b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>
Message-ID: <cd8747700901052021t1be4e6c0jb4203bec4e8579d6@mail.gmail.com>

+5 Stars from me

-- 
Michael F. Mondragon
http://www.michaelmondragon.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I hear and I forget.
I see and I remember.
I do and I understand.
       ?Confucius
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Tue, Jan 6, 2009 at 12:17 PM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2009/1/6 Bill Nottingham <notting at redhat.com>:
>> Jeff Spaleta (jspaleta at gmail.com) said:
>>> I think if we limit this service to packages only from people who have
>>> signed the appropriate CLA and are a sponsored contributor I think
>>> both the obvious trojan risk and the legal liability of distribution
>>> risk fall within already acceptable levels comparable to the review
>>> process we have.
>>
>> That's not bad; it's simple, should be easy to implement, and should get rid
>> of most of the direct risks.
>>
>
> +1
> Noted down.
>
> https://fedorahosted.org/review-o-matic/ticket/3
>
> --
> rakesh
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From Axel.Thimm at ATrpms.net  Tue Jan  6 04:29:48 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 06:29:48 +0200
Subject: sound problems
In-Reply-To: <68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
Message-ID: <20090106042948.GE24592@victor.nirvana>

On Mon, Jan 05, 2009 at 02:48:17PM -0200, Paulo Cavalcanti wrote:
> On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone <chris.stone at gmail.com>wrote:
> 
> > 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
> > > You can try the latest alsa snapshot available in ATrpms:
> >
> > Whoa, bad advice...anyone with half a brain knows to stay well clear
> > of anything coming from ATrpms.  Axel Thimm is one of the the worst
> > packagers in the Fedora community, and installing his packages is
> > *extremely* dangerous.
> >
> > Anyway, I have this sound problem too, thanks atleast for pointing me
> > to the bug number...
> >
> >
> Well, a lot of packages in ATrpms are mine. Including this alsa snapshot.
> I am the person who spent almost two weeks with Takashi trying to debug
> the sigmatel codec.

Actually, credit where credit is due: Not only a lot of packages are
Paulo's, but as well as most maintenance and new package creation is
his as well. One of these days ATrpms will be renamed to PCrpms ;)

Also Paulo does a lot of upstream communication and bug fixing, not
only with alsa, but anything that comes along, be that v4l, nvidia
bits etc.

> Therefore, I think your comment is directed to me. Your parents
> should have told you a long time ago that when someone does not have
> anything nice to say, it is much better to keep the mouth shut.

Christopher certainly didn't check out any of the packages or work
mentioned in this thread to start shouting. He is just hate-triggered
by the mention of ATrpms and starts kicking in any direction not even
bothering to check out whether his accusations have any basis.

It's of course quite easy to make noise, but your work is certainly
highly appreciated!
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/89fe4e80/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 04:13:12 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 06:13:12 +0200
Subject: sound problems
In-Reply-To: <604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
Message-ID: <20090106041312.GC24592@victor.nirvana>

On Mon, Jan 05, 2009 at 06:04:17PM -0900, Jeff Spaleta wrote:
> Axel if you are still reading this, for what its worth, I'm extremely
> sorry that the disagreements over Atrpms are being publicly discussed
> on this fedora mailinglist in the form of a personal attack.  There is
> a very long history here, and I thought we had for the most part moved
> past most of the personal demonizing at least in the fedora
> mailinglists proper.   if I have in any way done anything to foster
> this level of personal animosity in any discussion concerning the
> technical issues around 3rd party repos and package conflicts I
> sincerely apologize.

I don't think you have done so, your criticism was and is always well
received.

There is a difference between civilized people having a different
opinion and savages that need to kill people with an opinion that
differs from theirs.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/262fda47/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 04:19:39 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 06:19:39 +0200
Subject: sound problems
In-Reply-To: <d9c612bf0901051939n3fec7301oe5d25e7128cbaab4@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
	<d9c612bf0901051939n3fec7301oe5d25e7128cbaab4@mail.gmail.com>
Message-ID: <20090106041939.GD24592@victor.nirvana>

On Mon, Jan 05, 2009 at 07:39:55PM -0800, Christopher Stone wrote:
> On Mon, Jan 5, 2009 at 7:04 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> > And more to the point, there are many public 3rd party repositories
> > out there which conflict to varying degrees with the official Fedora
> > repositories.   Do you plan to ridicule each and every contributor who
> > runs a 3rd party repo on the side which conflicts? Any Fedora
> > contributor which chooses to run a repository on the side is their
> > choice and its a users choice to mix and match repositories or not.
> 
> Amazingly, ATrpms is so bad, that it is the only repository I recall
> hearing people constantly complain about on IRC.

Indeed, I never heard anyone compaining about your repo.

> I only plan to ridicule those 3rd party repositories which actually
> cause problems for Fedora users and do more harm than good, and no
> effort is made to fix problems in the repository.  ATrpms is the
> only 3rd party repo I am aware of which meet all of these criteria.

Yes, that's my charter and hidden agenda: Create packages that cause
harm. Actually all I wanted is for someone to finally step up and
uncover the truth, so I can publicly enjoy the fruits of my labour.

> As a board member or ambassador or whatever you are, you should do
> everything in your power to make sure that Fedora users are well aware
> of the dangers of using ATrpms, and are well aware that Axel Thimm has
> no intentions of fixing any bugs which may cause a broken Fedora
> system.  As I recall, I posted over one hundred bugs over a year ago
> and not a single one has been touched by Axel.

As I recall 99 of these bugs were semi-automatically filled with "move
this package to Fedora or livna". You really still think that
repeating a request as many packages as there are in a repo will shut
it down? It will annoy people, yes, suddenly bugzilla.atrpms.net was
unusable. Thanks for the sabotage again.

Love and Peace.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/8707da7d/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 04:10:37 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 06:10:37 +0200
Subject: sound problems
In-Reply-To: <200901051916.25386.konrad@tylerc.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
	<200901051916.25386.konrad@tylerc.org>
Message-ID: <20090106041037.GB24592@victor.nirvana>

On Mon, Jan 05, 2009 at 07:16:25PM -0800, Conrad Meyer wrote:
> On Monday 05 January 2009 07:04:17 pm Jeff Spaleta wrote:
> > Here a subset of Axel's direct contributions to Fedora:
> > https://admin.fedoraproject.org/pkgdb/users/packages/athimm
> 
> And here's a subset of his directly destructive behavior towards Fedora:
> http://atrpms.net/dist/f10/

so extending Fedora and RHEL to support more multimedia/drivers
etc. is a destructive behaviour? Offering choice for more is bad?

> > And more to the point, there are many public 3rd party repositories
> > out there which conflict to varying degrees with the official Fedora
> > repositories.   Do you plan to ridicule each and every contributor who
> > runs a 3rd party repo on the side which conflicts?
> 
> Yes.
> 
> Regards,

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/de19e496/attachment.sig>

From jspaleta at gmail.com  Tue Jan  6 04:33:42 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 5 Jan 2009 19:33:42 -0900
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
	<20090105210222.GA20265@nostromo.devel.redhat.com>
	<b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>
Message-ID: <604aa7910901052033y4f921b51sa0dd28ad614845d9@mail.gmail.com>

On Mon, Jan 5, 2009 at 7:17 PM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> +1
> Noted down.
>
> https://fedorahosted.org/review-o-matic/ticket/3


I don't know how you would do it in a submission request ticket, but
if an existing contributor signed off on the submission from a new
contributor, that sign off should be enough to get the build going.
Such a signoff mechanism would hold that existing contributor
accountable if it was a problematic build.

That way, existing contributors could work on the submission review
proactively with a new contributor to get things in shape for an a
binding sponsorship review without blocking on a sponsor to do all the
interaction with the new contributor in getting the the packaging
cleaned up.

-jef



From kevin.kofler at chello.at  Tue Jan  6 05:06:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 06:06:23 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<49626737.7020109@gmail.com>
Message-ID: <gjuosf$oic$1@ger.gmane.org>

Suren Karapetyan wrote:
> I'm sure trying to fix them one by one in F10 is WRONG.

Downgrading is what is wrong. The ALSA update fixes bugs for some people and
even adds support for some hardware. Moving back is not the solution,
fixing the update is.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan  6 05:10:32 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 06:10:32 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
Message-ID: <gjup48$oic$2@ger.gmane.org>

Conrad Meyer wrote:
> Why not put that work into Fedora / RPM Fusion? Seems a waste to
> contribute to an incompatible 3rd-party repo.

Fedora does not allow kernel modules, and I think RPM Fusion is also the
wrong place for experimental upgrades to modules which are included in
Fedora kernels. ALSA snapshots are something for an unstable repository,
which neither Fedora nor RPM Fusion have. (Kinda like the stuff in
kde-redhat unstable.) So in this case, putting them into
ATrpms's "bleeding" repo makes a lot of sense.

        Kevin Kofler



From rakesh.pandit at gmail.com  Tue Jan  6 05:41:34 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 6 Jan 2009 11:11:34 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <604aa7910901052033y4f921b51sa0dd28ad614845d9@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<ufaocylvcd3.fsf@epithumia.math.uh.edu>
	<20090105185827.GD11824@nostromo.devel.redhat.com>
	<604aa7910901051237u3bf26bb1q98b49b2a63ba5879@mail.gmail.com>
	<20090105210222.GA20265@nostromo.devel.redhat.com>
	<b401d2530901052017n1c38d3d3mc840dd22aeb0b6c8@mail.gmail.com>
	<604aa7910901052033y4f921b51sa0dd28ad614845d9@mail.gmail.com>
Message-ID: <b401d2530901052141g30591bb1qf869217bf9339ea0@mail.gmail.com>

2009/1/6 Jeff Spaleta <jspaleta at gmail.com>:
> On Mon, Jan 5, 2009 at 7:17 PM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
>> +1
>> Noted down.
>>
>> https://fedorahosted.org/review-o-matic/ticket/3
>
>
> I don't know how you would do it in a submission request ticket, but
> if an existing contributor signed off on the submission from a new
> contributor, that sign off should be enough to get the build going.
> Such a signoff mechanism would hold that existing contributor
> accountable if it was a problematic build.
>
> That way, existing contributors could work on the submission review
> proactively with a new contributor to get things in shape for an a
> binding sponsorship review without blocking on a sponsor to do all the
> interaction with the new contributor in getting the the packaging
> cleaned up.
>

Yeah, very much right. We will discuss and check how this aspect can
be implemented.

-- 
rakesh



From eric.tanguy at univ-nantes.fr  Tue Jan  6 06:56:21 2009
From: eric.tanguy at univ-nantes.fr (Eric Tanguy)
Date: Tue, 06 Jan 2009 07:56:21 +0100
Subject: Build failed help
In-Reply-To: <gjulnb$h9q$1@ger.gmane.org>
References: <496246D6.8050006@univ-nantes.fr>	<1231177797.4566.30.camel@localhost.localdomain>	<20090105190950.ea81e112.mschwendt@gmail.com>	<49625196.9020409@univ-nantes.fr>
	<gjulnb$h9q$1@ger.gmane.org>
Message-ID: <49630095.7060605@univ-nantes.fr>

Kevin Kofler a ?crit :
> Eric Tanguy wrote:
>   
>> The sipAPIscidavis.h never exists so maybe the gcc version changed
>> between the 2 builds ?
>>     
>
> sip was recently upgraded.
>
>         Kevin Kofler
>
>   
But when i built it locally (fully updated F-10) using make i386 it 
builds fine but if i run make build it fails. So there is somewhere a 
difference between my config and the koji one.
Eric



From fedora at leemhuis.info  Tue Jan  6 07:28:11 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 06 Jan 2009 08:28:11 +0100
Subject: sound problems
In-Reply-To: <gjup48$oic$2@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>
	<gjup48$oic$2@ger.gmane.org>
Message-ID: <4963080B.9040105@leemhuis.info>

On 06.01.2009 06:10, Kevin Kofler wrote:
> Conrad Meyer wrote:
>> Why not put that work into Fedora / RPM Fusion? Seems a waste to
>> contribute to an incompatible 3rd-party repo.
> Fedora does not allow kernel modules, and I think RPM Fusion is also the
> wrong place for experimental upgrades to modules which are included in
> Fedora kernels.

Tend to agree here. Getting the fixes into the Fedora-Kernel is the way 
forward. As that's what cebbert did with the latest F10 kernels afaics:

$ rpm -q kernel-2.6.27.9-159.fc10.x86_64 --changelog | grep -B 1 -A 5 -i 
1.0.18
* Mo Dez 08 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.27.7-139
- ALSA 1.0.18a
   Dropped patches:
     linux-2.6-alsa-ac97-whitelist.patch
     linux-2.6-alsa-ac97-whitelist-AD1981B.patch
     linux-2.6-alsa-revo51-headphone.patch
     linux-2.6-olpc-speaker-out.patch

thx for that cebbert!

> ALSA snapshots are something for an unstable repository,
> which neither Fedora nor RPM Fusion have. (Kinda like the stuff in
> kde-redhat unstable.)

*Hint, hint:* A lot of people requested a RPM Fusion unstable repo (and 
I think it would be good to have one), but nobody stepped forwarded yet 
to lay the groundwork for it -- e.g. discuss layout, rules, infra, and 
all those other details that need to be sorted out before it such a repo 
is started.

> So in this case, putting them into
> ATrpms's "bleeding" repo makes a lot of sense.

Normally yes, but not if the latest Fedora kernel already includes the 
same Alsa, then providing (nearly) the same in a different place is just 
wasting time and leads to confusion among users.

CU
knurd



From kevin.kofler at chello.at  Tue Jan  6 07:37:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 08:37:36 +0100
Subject: Build failed help
References: <496246D6.8050006@univ-nantes.fr>	<1231177797.4566.30.camel@localhost.localdomain>	<20090105190950.ea81e112.mschwendt@gmail.com>	<49625196.9020409@univ-nantes.fr>
	<gjulnb$h9q$1@ger.gmane.org> <49630095.7060605@univ-nantes.fr>
Message-ID: <gjv1o0$ang$1@ger.gmane.org>

Eric Tanguy wrote:
> But when i built it locally (fully updated F-10) using make i386 it
> builds fine but if i run make build it fails. So there is somewhere a
> difference between my config and the koji one.

The sip update is still in updates-testing, but it's already in the
buildroot (it's tagged dist-f10-override) because other stuff needed to be
rebuilt against it.

Please talk to Rex Dieter, he did the sip upgrade.

        Kevin Kofler



From Axel.Thimm at ATrpms.net  Tue Jan  6 08:14:18 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 10:14:18 +0200
Subject: sound problems
In-Reply-To: <4963080B.9040105@leemhuis.info>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<gjup48$oic$2@ger.gmane.org> <4963080B.9040105@leemhuis.info>
Message-ID: <20090106081418.GA4061@victor.nirvana>

On Tue, Jan 06, 2009 at 08:28:11AM +0100, Thorsten Leemhuis wrote:
>> So in this case, putting them into ATrpms's "bleeding" repo makes a
>> lot of sense.
>
> Normally yes, but not if the latest Fedora kernel already includes
> the same Alsa, then providing (nearly) the same in a different place
> is just wasting time and leads to confusion among users.

Please check the thread - this is about alsa 1.0.18a failing on some
hardware which the packages at ATrpms fix. So it's neither a waste,
nor confusion, but supporting the userbase (this thread has become
waste and confusion).

Actually a lot of the current snapshot from alsa has been driven by
Paulo who also packaged it up for immediate consuming. And yes, it's
all in upstream already, but until 1.0.18b/1.0.19 is released and that
pushed to the kernel or the Fedora kernel maintainer backporting the
bits it to the next packaged kernel, some people with a nice sound
system will only listen to the Sound of Silence.

All that Paulo was trying to do here is help users with a problem at
hand, be that with a package we created or other advice to get the
sound codec going. I really doubt that he will be that enthousiastic
to help people out on this list when the side reactions are like that.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/18e296fb/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 08:20:24 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 10:20:24 +0200
Subject: sound problems
In-Reply-To: <200901050854.18189.konrad@tylerc.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
Message-ID: <20090106082024.GB4061@victor.nirvana>

On Mon, Jan 05, 2009 at 08:54:18AM -0800, Conrad Meyer wrote:
> On Monday 05 January 2009 08:48:17 am Paulo Cavalcanti wrote:
> > On Mon, Jan 5, 2009 at 2:16 PM, Christopher Stone 
> <chris.stone at gmail.com>wrote:
> > > 2009/1/4 Paulo Cavalcanti <promac at gmail.com>:
> > > > You can try the latest alsa snapshot available in ATrpms:
> > >
> > > Whoa, bad advice...anyone with half a brain knows to stay well clear
> > > of anything coming from ATrpms.  Axel Thimm is one of the the worst
> > > packagers in the Fedora community, and installing his packages is
> > > *extremely* dangerous.
> > >
> > > Anyway, I have this sound problem too, thanks atleast for pointing me
> > > to the bug number...
> >
> > Well, a lot of packages in ATrpms are mine.
> 
> Why not put that work into Fedora / RPM Fusion? Seems a waste to contribute to 
> an incompatible 3rd-party repo.

Incompatible to what? If there are conflicts between ATrpms' packages
and others from the N thousand official packages, please report
them and we'll fix them.

Incompatibility between RPM Fusion and the rest of the world was RPM
Fusion's decision which after months of struggling I couldn't
influence anymore.

> > Including this alsa snapshot. 
> > I am the person who spent almost two weeks with Takashi trying to debug
> > the sigmatel codec.
> 
> Thanks.
> 

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/e8ac92ab/attachment.sig>

From sundaram at fedoraproject.org  Tue Jan  6 08:24:57 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 13:54:57 +0530
Subject: sound problems
In-Reply-To: <20090106082024.GB4061@victor.nirvana>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
Message-ID: <49631559.8060003@fedoraproject.org>

Axel Thimm wrote:
> 
> Incompatible to what? If there are conflicts between ATrpms' packages
> and others from the N thousand official packages, please report
> them and we'll fix them.

You could simply run a script and just not duplicate packages already in 
the official repo. In a quick glance, I can spot pdfmerge, xine-lib and 
several others, some of which are not deps of anything else. So it is 
just unnecessary extra work.

Rahul










From rawhide at fedoraproject.org  Tue Jan  6 09:01:46 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue,  6 Jan 2009 09:01:46 +0000 (UTC)
Subject: rawhide report: 20090106 changes
Message-ID: <20090106090146.247E81F8258@releng2.fedora.phx.redhat.com>

Compose started at Tue Jan  6 06:01:02 UTC 2009

New package eg
        Git for mere mortals
New package hyphen-fr
        French hyphenation rules
New package libnice
        GLib ICE implementation
New package linsmith
        A Smith charting program
New package mapbender
        Geospatial portal for OGC OWS architectures
New package pfstools
        Programs for handling high-dynamic range images
New package tinyows
        WFS-T and FE implementation server
Updated Packages:

NetworkManager-openconnect-0.7.0-4.svn14.fc11
---------------------------------------------
* Mon Jan  5 17:00:00 2009 David Woodhouse <David.woodhouse at intel.com> 0.7.0-4.svn14
- Rebuild for updated NetworkManager
- Update translations from GNOME SVN


R-2.8.1-2.fc11
--------------
* Mon Jan  5 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 2.8.1-2
- add pango-devel to BuildRequires (thanks to Martyn Plummer and Peter Dalgaard)
- fix libRmath requires to need V-R (thanks to Martyn Plummer)


anaconda-11.5.0.4-1
-------------------
* Mon Jan  5 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 11.5.0.4-1
- Workaround compile error due to (# 478663) (hdegoede)
- Various packaging fixed from review (#225246) (hdegoede)
- Show the header in certain non-lowres cases (#478765, alsadi AT
  ojuba.org). (clumens)
- Remove doMultiMount. (clumens)
- Use mount -t auto instead of passing a list of valid fstypes (#477328).
  (clumens)
- Fix case sensitivity when searching for headers (kanarip)
- Fix a traceback in checking for network install (ricky AT
  fedoraproject.org). (clumens)


anjuta-2.24.2-1.fc11
--------------------
* Sun Jan  4 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 1:2.24.2-1
- Version bump to 2.24.2. Closes Red Hat Bugzilla bug #478684.


batik-1.7-1.fc11
----------------
* Mon Jan  5 17:00:00 2009 Nicolas Chauvet <kwizart at gmail.com> - 1.7-1
- Fix release field
- Repack the source (without included jar files)
- Fix dual listed files in the demo subpackage
- Fix BR subversion used in determine-svn-revision-svn-info
- Fix BR that was previously bundled within the source archive
- Resolves: rhbz#472736

* Mon Jan  5 17:00:00 2009 Lillian Angel  <langel at redhat.com> - 1.7-1
- Updated batik-repack.sh to remove font files from test resources.
- Resolves: rhbz#477369


bind-9.6.0-1.fc11
-----------------
* Mon Jan  5 17:00:00 2009 Adam Tkac <atkac redhat com> 32:9.6.0-1
- Happy new year
- 9.6.0 release


bluez-4.25-1.fc11
-----------------
* Sat Jan  3 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 4.25-1
- Update to 4.25


bodhi-0.5.16-1.fc11
-------------------
* Mon Jan  5 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.5.16-1
- Latest upstream bugfix release.

* Mon Dec 22 17:00:00 2008 Luke Macken <lmacken at redhat.com> - 0.5.15-1
- Latest release, with more masher improvements.


bpython-0.7.1-2.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Terje Rosten <terje.rosten at ntnu.no> - 0.7.1-2
- Add setuptools to buildreq

* Mon Jan  5 17:00:00 2009 Terje Rosten <terje.rosten at ntnu.no> - 0.7.1-1
- 0.7.1


crypto-utils-2.4.1-6
--------------------
* Mon Jan  5 17:00:00 2009 Elio Maldonado <emaldona at redhat.com> - 2.4.1-6
- genkey: fix ca key name extension


dhcp-4.0.0-34.fc11
------------------

digikam-0.10.0-0.12.beta8.fc11
------------------------------
* Mon Jan  5 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.10.0-0.12.beta8
- digikam-0.10.0-beta8


eclipse-pydev-1.4.0-1.fc11
--------------------------
* Thu Dec 25 17:00:00 2008 Alexander Kurtakov <akurtako at redhat.com> 1:1.4.0-1
- Update to 1.4.0 - adds support for Python 2.6/3.0.
- Use system jakarta-commons-logging and xmlrpc3.
- Drop arch checks for mylyn - it is noarch now.


farsight2-0.0.6-4.fc11
----------------------
* Mon Jan  5 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.0.6-4
- Add BR on libnice-devel and build libnice transmitter.
- Set gstreamer package name & origin.

* Fri Jan  2 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.0.6-3
- Rebuild.

* Wed Dec 31 17:00:00 2008 Brian Pepple <bpepple at fedoraproject.org> - 0.0.6-2
- Preserve time stamps.


fbterm-1.3-1.fc11
-----------------
* Tue Jan  6 17:00:00 2009 Ding-Yi Chen <dchen at redhat dot com> - 1.3-1
- SUID fbterm for el5, as it does not have libcap.


firstaidkit-0.2.2-6.fc11
------------------------
* Mon Jan  5 17:00:00 2009 Joel Granados <jgranado at redhat.com> - 0.2.2-6
- The ppc and ppc64 arch do not handle grub as their bootloader.


fwknop-1.9.9-2
--------------
* Mon Jan  5 17:00:00 2009 Peter Vrabec <pvrabec at redhat.com> 1.9.9-2
- add /var/log/fwknop/errs directory (#469395)


gamin-0.1.10-3.fc11
-------------------
* Mon Jan  5 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 0.1.10-3
- Fix build on gnueabi (patch by Kedar Sovani)


gedit-2.25.2-3.fc11
-------------------
* Mon Jan  5 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 1:2.25.2-3
- Remove some unneeded dependencies


glib2-2.19.4-1.fc11
-------------------
* Mon Jan  5 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.19.4-1
- Update to 2.19.4


gnome-applet-timer-2.0.1-9.fc11
-------------------------------
* Mon Jan  5 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.0.2-9
- Update patch as suggested by Michael Schwendt


gnome-keyring-2.25.4-1.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 2.25.4-1
- Update to 2.25.4


gnome-media-2.25.1-2.fc11
-------------------------
* Mon Jan  5 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.1-2
- Split applications and the media profiles library
- Remove some unneeded BuildRequires


gstreamer-0.10.21-4.fc11
------------------------
* Mon Jan  5 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.21-4
- Fix build with newer version of bison

* Thu Jan  1 17:00:00 2009 Rex Dieter <rdieter at fedoraprojet.org> - 0.10.21-3
- rebuild for pkgconfig deps (#478576)


gtkhtml3-3.25.4-1.fc11
----------------------
* Mon Jan  5 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 3.25.4-1.fc11
- Update to 3.25.4


iso-codes-3.5.1-1.fc11
----------------------
* Mon Jan  5 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 3.5.1-1
- Update to 3.5.1


kernel-2.6.29-0.12.rc0.git7.fc11
--------------------------------
* Mon Jan  5 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.28-git7

* Sat Jan  3 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.28-git6

* Fri Jan  2 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.28-git5


kipi-plugins-0.2.0-0.11.beta6.fc11
----------------------------------
* Mon Jan  5 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.2.0-0.11.beta6
- kipi-plugins-0.2.0-beta6


konq-plugins-4.1.3-4.fc11
-------------------------
* Mon Jan  5 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.3-4
- make install/fast
- jpegorient is not installed (#478736, kdebug#178612)


libcgroup-0.32.2-3.fc11
-----------------------
* Mon Jan  5 17:00:00 2009 Dhaval Giani <dhaval at linux.vnet.ibm.com> 0.32.2-3
- Fix redhat-lsb dependency


libgweather-2.25.4-1.fc11
-------------------------
* Mon Jan  5 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> 2.25.4-1
- Update to 2.25.4


libicns-0.6.1-1.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Andrea Musuruane <musuruan at gmail.com> - 0.6.1-1
- Updated to upstream 0.6.1


libmcrypt-2.5.8-7.fc11
----------------------
* Mon Jan  5 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 2.5.8-7
- fix multilib conflict (bz 478879)


libsoup-2.25.4-1.fc11
---------------------
* Mon Jan  5 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.4-1
- Update to 2.25.4

* Tue Dec 16 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.3-1
- Update to 2.25.3


linuxwacom-0.8.0.3-7.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 0.8.0.3-7
- linuxwacom-0.8.0.3-nocrash-removal.patch: don't free the device's private,
  it causes a SIGABRT on device removal and the server does it anyway.


mathomatic-14.2.8-1.fc11
------------------------
* Mon Jan  5 17:00:00 2009 Terje Rosten <terje.rosten at ntnu.no> - 14.2.8-1
- 14.2.8


metacity-2.25.89-1.fc11
-----------------------
* Mon Jan  5 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.89-1
- Update to 2.25.89


mythes-sk-0.20090102-1.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20090102-1
- latest version


nautilus-sound-converter-1.0.0-1.fc11
-------------------------------------
* Sat Jan  3 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 1.0.0-1
- Update to 1.0.0.
- Drop oga patch.  Fixed upstream.


ochusha-0.6.0.1-0.2.cvs20090106T1430.fc11
-----------------------------------------
* Tue Jan  6 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Use latest CVS


octave-forge-20080831-4.fc11
----------------------------
* Mon Jan  5 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 20080831-4
- Patch to temporarily get image subpackage to build (#477577)

* Sun Jan  4 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 20080831-3
- Fixed unowned directories (BZ 474675)


pssh-1.4.3-1.fc11
-----------------
* Mon Jan  5 17:00:00 2009 Terje Rosten <terje.rosten at ntnu.no> - 1.4.3-1
- 1.4.3


python-telepathy-0.15.4-1.fc11
------------------------------
* Mon Jan  5 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.15.4-1
- Update to 0.15.4.


python-vobject-0.8.0-1.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 James Bowes <jbowes at redhat.com> - 0.8.0-1
- Update to 0.8.0


qwt-doc-5.1.1-2.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net - 5.1.1-2
- fix wrong file name

* Mon Jan  5 17:00:00 2009 Frank B??ttner <frank-buettner at gmx.net - 5.1.1-1
- update to 5.1.1

* Sun Oct  7 18:00:00 2007 Frank B??ttner <frank-buettner at gmx.net - 5.0.2-5
- fix for bug #322191
 - use tab for all seperators


rb_libtorrent-0.14.1-1.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 0.14.1-1
- Update to new upstream release (0.14.1)
- Add asio-devel as runtime dependency for the devel subpackage (#478589)
- Add patch to build with Python 2.6:
  + python26.patch
- Add patch to make the configure script use the proper python include
  directory instead of calling locate, as that can cause failures in a chroot
  with no db file (and is a bit silly in the first place):
  + configure-dont-use-locate.patch
- Drop manual setup.py for building the python module (fixed upstream):
  - setup.py
- Update Source0 URL back to SourceForge's hosting.
- Reenable the examples, since the Makefiles are fixed.


selinux-policy-3.6.2-1.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.2-1
- Update to upstream


shadow-utils-4.1.2-10.fc11
--------------------------
* Mon Jan  5 17:00:00 2009 Peter Vrabec <pvrabec at redhat.com> 2:4.1.2-10
- Add policycoreutils as Requires, because of restorecon (#478494)


snake-0.11-0.12.fc11
--------------------
* Mon Jan  5 17:00:00 2009 James Laska <jlaska at redhat.com> 0.11-0.12
- Minor fix to cobbler template and move %doc into base package (jlaska)


tar-1.21-1.fc11
---------------
* Mon Jan  5 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2:1.21-1
- New upstream release 1.21, removed applied patches
- add support for -I option, fix testsuite failure


telepathy-salut-0.3.7-1.fc11
----------------------------
* Mon Jan  5 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.3.7-1
- Update to 0.3.7.
- Change BR to libsoup-devel, since they support it now.


unbound-1.1.1-7.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Paul Wouters <paul at xelerance.com> - 1.1.1-7
- Modified scandir patch to silently fail when wildcard matches nothing
- Patch to allow unbound-checkconf to find empty wildcard matches

* Mon Jan  5 17:00:00 2009 Paul Wouters <paul at xelerance.com> - 1.1.1-6
- Added scandir patch for trusted-keys-file: option, which
  is used to load multiple dnssec keys in bind file format


xmlto-0.0.21-5.fc11
-------------------
* Mon Jan  5 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 0.0.21-5
- fix stringparam option functionality

* Tue Dec 16 17:00:00 2008 Ondrej Vasik <ovasik at redhat.com> - 0.0.21-4
- merge review(#226568)
  correct doc filelist attributes, add License GPL+ for xmlif


xorg-x11-drv-openchrome-0.2.903-5.fc11
--------------------------------------
* Mon Jan  5 17:00:00 2009 Xavier Bachelot <xavier at bachelot.org> - 0.2.903-5
- Update to latest snapshot (svn 711), fix hardware cursor and add VX800 Xv.


ypbind-1.20.4-12.fc11
---------------------
* Mon Jan  5 17:00:00 2009 Vitezslav Crhonek <vcrhonek at redhat.com> - 3:1.20.4-12
- Ship helper script for dhclient


Summary:
Added Packages: 7
Removed Packages: 0
Modified Packages: 55
Broken deps for i386
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	batik-1.7-1.fc11.noarch requires java >= 1:1.6.0.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.i386 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.i386 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.i386 requires libgnome-desktop-2.so.10
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	icewm-gnome-1.2.35-4.fc10.i386 requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.i386 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.i386 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.i386 requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.i386 requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	batik-1.7-1.fc11.noarch requires java >= 1:1.6.0.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.x86_64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.i386 requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.x86_64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.x86_64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	icewm-gnome-1.2.35-4.fc10.x86_64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.x86_64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc requires libgnome-desktop-2.so.7
	awn-extras-applets-0.2.6-6.fc10.ppc requires libpython2.5.so.1.0
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	batik-1.7-1.fc11.noarch requires java >= 1:1.6.0.0
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc requires gecko-devel = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.ppc requires libgnome-desktop-2.so.10
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	icewm-gnome-1.2.35-4.fc10.ppc requires libgnome-desktop-2.so.7
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires python(abi) = 0:2.5
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	awn-extras-applets-0.2.6-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	batik-1.7-1.fc11.noarch requires java >= 1:1.6.0.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	epiphany-2.24.2.1-2.fc11.ppc64 requires gecko-libs = 0:1.9.0.4
	epiphany-devel-2.24.2.1-2.fc11.ppc64 requires gecko-devel = 0:1.9.0.4
	epiphany-extensions-2.24.0-3.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	galeon-2.0.7-3.fc11.ppc64 requires libgnome-desktop-2.so.10()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	icewm-gnome-1.2.35-4.fc10.ppc64 requires libgnome-desktop-2.so.7()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From Axel.Thimm at ATrpms.net  Tue Jan  6 09:00:45 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 11:00:45 +0200
Subject: sound problems
In-Reply-To: <49631559.8060003@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
Message-ID: <20090106090045.GC4061@victor.nirvana>

On Tue, Jan 06, 2009 at 01:54:57PM +0530, Rahul Sundaram wrote:
> Axel Thimm wrote:
>>
>> Incompatible to what? If there are conflicts between ATrpms' packages
>> and others from the N thousand official packages, please report
>> them and we'll fix them.
>
> You could simply run a script

Which one? If there are conflicts they are at file level which is
(was?) always a problem for the main Fedora repos within themselves,
too. I know Jesse was one using one (in mesh?) but it was horribly
stalling rawhide composes, so it was deactivated. But this was half a
year ago, perhaps the current koji/mesh/etc toolchain does that for
you now.

> and just not duplicate packages already in the official repo. In a
> quick glance, I can spot pdfmerge, xine-lib and several others, some
> of which are not deps of anything else. So it is just unnecessary
> extra work.

According to logs and dates I packaged pdfmerge on Nov 9 2003 and by
happenstance Fedora's first release ever was a week later.

Now I see that you imported pdfmerge into Fedora about half a year
ago. It would probably not take much to ping me and ask whether we can
either comaintain, or work together on providing an upgrade path to
users of this package (which hasn't changed EVR since 5 years!).

So when talking about duplication of work/efforts one needs to check
what was really the duplicate, just blaming ATrpms for carring
duplicates, when these are actually ancient packages is wrong.

And when discussing about incompatibilities/package upgrades etc. one
also needs to admit that it is a two way *co*operation. I can't hunt
the Fedora package database to see whether XYZ packaged foo and bar
and to review his/her package to see whether it properly steps up from
the pervious package and then ensure package upgrade paths etc. I
wasn't aware of pdfmerge being in Fedora as your import didn't
actually create any user issues for them to report.

We had a discussion with Max and Mike at LinuxTag about this last year
and the common approach was that Fedora packagers would be kindly
asked to check and cooperate with (major) 3rd party repos instead of
blindly packaging creating the incompatibilities (actually this was
more in the loght of EPEL than Fedora proper). Unfortunately this was
never really followed up after the meeting.

And to xine: This is also a package by Paulo, so I can say less about
it, but AFAIK he needed to undo some of the multimedia codec removal
bits to reenable some functionality. I'm not a xine user (maybe I
should become one, but I'm an mplayer guy), so I don't know what was
fixed, but the changelogs are your friend.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/c650b07e/attachment.sig>

From surenkarapetyan at gmail.com  Tue Jan  6 09:29:55 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Tue, 06 Jan 2009 13:29:55 +0400
Subject: sound problems
In-Reply-To: <gjuosf$oic$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<49626737.7020109@gmail.com>
	<gjuosf$oic$1@ger.gmane.org>
Message-ID: <49632493.9030001@gmail.com>

Kevin Kofler wrote:
> Suren Karapetyan wrote:
>   
>> I'm sure trying to fix them one by one in F10 is WRONG.
>>     
>
> Downgrading is what is wrong. The ALSA update fixes bugs for some people and
> even adds support for some hardware. Moving back is not the solution,
> fixing the update is.
>
>         Kevin Kofler
>
>   
As You see I'm on the other side.
I'm one of many for whom ALSA upgrade introduced the worst bug it could 
i.e. it destroyed sound!
Breaking something which works to fix something which doesn't work is 
not the right way to go.
Let's take an example.
I have friends Bob and Jane.
He downloaded F10 second day of the release burned it on a DVD and 
installed it.
Everything was fine, BUT there was no sound.
He plays with it a few days and switches to something which has sound.
Jane installs F10 and is quite satisfied until the day security update 
breaks sound (the same update fixes sound for Bob, but he'll not know it 
until F11,  cause he is sure F10 is broken).
She has good education and is computer-literate, so she goes to 
bugzilla, reports her problems.
Waits for a few days and gets nothing.
Then she calls Bob and asks what he did to fix his problem.
Bob tells her to switch to X.

And now to Your point.
I agree: downgrading is wrong.
But upgrading was even wrongER.
Just look at https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11593
The new kernel spent ~30 hours in updates-testing.
While it's quite normal for a security fix it's unacceptable for such a 
huge change as ALSA upgrade.

And a question to You.
If I become a fedora maintainer and (in some way manage to) upgrade F10 
to kernel-2.6.29 are we going to revert my update or try to fix all the 
regressions which will take ~2 months.

P.S. 2.6.28 fixes suspend-wakeup issues for my notebook, but I'm not 
asking anyone to upgrade F10 to it.



From kevin.kofler at chello.at  Tue Jan  6 10:12:01 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 11:12:01 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
Message-ID: <gjvapj$5sf$1@ger.gmane.org>

Axel Thimm wrote:
> And to xine: This is also a package by Paulo, so I can say less about
> it, but AFAIK he needed to undo some of the multimedia codec removal
> bits to reenable some functionality.

That's what xine-lib-extras-freeworld in RPM Fusion is for.

xine-lib has a plugin architecture, so adding features should be done by
adding the plugins, not replacing the whole package.

As for the conflicts with RPM Fusion, I don't think it is fair to blame it
all on RPM Fusion. There's a lot you could do to avoid both
incompatibilities and duplication of effort. Upgrade paths are not really a
convincing argument: it was no problem to ensure proper upgrade paths from
both Livna and FreshRPMs, I'm sure RPM Fusion maintainers will be willing
to fix the upgrade paths from ATrpms for the relevant packages if you
accept that RPM Fusion will be the authority for those packages. In fact
many of them will also have no problems with letting you and/or Paolo
comaintain those packages. The root of the problem is that you're shipping
some packages which are also in RPM Fusion. There would be no
incompatibility if you didn't do that.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan  6 10:24:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 11:24:07 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
Message-ID: <gjvbg8$81h$1@ger.gmane.org>

Axel Thimm wrote:
> Incompatible to what? If there are conflicts between ATrpms' packages
> and others from the N thousand official packages, please report
> them and we'll fix them.

One concrete source of incompatibility is that you use Debian-style
versioning (e.g. libquicktime0) for some library packages, which is against
Fedora guidelines (in fact, IIRC a guideline change you proposed to that
effect was rejected) and which can confuse yum in some cases.

        Kevin Kofler



From promac at gmail.com  Tue Jan  6 10:49:45 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 6 Jan 2009 08:49:45 -0200
Subject: sound problems
In-Reply-To: <49631559.8060003@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
Message-ID: <68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>

On Tue, Jan 6, 2009 at 6:24 AM, Rahul Sundaram
<sundaram at fedoraproject.org>wrote:

> Axel Thimm wrote:
>
>>
>> Incompatible to what? If there are conflicts between ATrpms' packages
>> and others from the N thousand official packages, please report
>> them and we'll fix them.
>>
>
> You could simply run a script and just not duplicate packages already in
> the official repo. In a quick glance, I can spot pdfmerge, xine-lib and
> several others, some of which are not deps of anything else. So it is just
> unnecessary extra work.
>
>
Rahul,

if my memory is not failing, some packages appeared first in ATrpms
than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc. I am not
discussing
if these packages are useful or not. The fedora version of xzgv was never
able
to display the thumbnails correctly, for instance. Why? Because it has to be
compiled with
gcc3.

But the only reason for the existence of a 3rd party repo is a multimedia
package.
Almost all of them are based on ffmpeg, which is obtained from svn.
Therefore,
it is very difficult to have compatible packages, since ffmpeg API changes
very often.

Because of that, packages like, vlc, mplayer and xine, must get all of their
dependencies from the same repo. As a matter of fact, Fedora supplies a
chopped version of xine, and the other repos try to "fill the gaps".  They
accomplish this by creating packages, such as,
xine-lib-moles, xine-lib-extras-nonfree, xine-lib-extras-freeworld, etc.

In xine particular case,  it is much easier to compile it as a whole, than
wasting hours
trying to see what is missing. Again, I understand the license issue, but it
would be much more
appropriate if Fedora did not supply it at all (I think a gstreamer solution
only would be preferable).
But this is my opinion only.

Returning to the sound problem, the snapshots come from here:

ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/


As you can see, there is also an alsa-driver-unstable-snapshot. The stable
snapshot
have already been committed to the kernel tree. As a consequence, it should
not bring
any headache. I am running it on several computers that stay on 24/7. Of
course,
they work for my codecs (basically, snd-hda-intel/sigmatel), wich are the
ones I can test.
I have learned enough to remap the connections, and fix a few misplaced pins
I still have,
but this is not the case.

The only thing I cannot put up with is discrimination. For several years I
have seen
some people, in Fedora lists, execrating Axel. However, the thing came to a
point
that I can not stand anymore. When the subject changes from technical to
personal,
there is nothing else to be said.

This type of behavior, when tolerated,  works as "low (level) pass filter",
and implies,
 by omission, in a consent of the community. As a writer (Nelson Rodrigues),
I like much,
used to say, "all unanimity is stupid".

I do not think I am on the dark side of the force, but, from this day on, I
will avoid posting to any Fedora list.

Finally, I have met in this list some very nice people: my sponsor, Jon
Ciesla,
Jarrod Wilson, Rex Dieter, and many others. To all of them, many thanks.

A good day for all.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/f7f46aee/attachment.htm>

From kevin.kofler at chello.at  Tue Jan  6 10:48:39 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 11:48:39 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<49626737.7020109@gmail.com>
	<gjuosf$oic$1@ger.gmane.org> <49632493.9030001@gmail.com>
Message-ID: <gjvcui$cij$1@ger.gmane.org>

Suren Karapetyan wrote:
> Everything was fine, BUT there was no sound.
> He plays with it a few days and switches to something which has sound.

If he is knowledgeable about Fedora, he doesn't do that, because he knows
Fedora gets version updates and thus a fix should be forthcoming fairly
quickly.

> Jane installs F10 and is quite satisfied until the day security update
> breaks sound (the same update fixes sound for Bob, but he'll not know it
> until F11,  cause he is sure F10 is broken).
> She has good education and is computer-literate, so she goes to
> bugzilla, reports her problems.
> Waits for a few days and gets nothing.
> Then she calls Bob and asks what he did to fix his problem.

No, she just uses the old working kernel as long as no new working one comes
out. Kernels can be installed in parallel (and you can set how many kernels
should be kept at a time in yum.conf, I recommend just setting
installonly=0, i.e. no limit, and cleaning up by hand once you're sure you
don't need the old kernels anymore). For example, I skipped all the 2.6.26
kernels on my laptop because iwl4965 wireless was broken, the 2.6.27
updates fixed that, I just stayed on 2.6.25 until those came out.

Regressions are definitely an annoyance, but they're not the unsolvable
problem you make them out to be. They're better than unfixed bugs, because
with regressions, at least you have the option to revert to the old
version, with unfixed bugs, there's no working version to revert to.

> And now to Your point.
> I agree: downgrading is wrong.
> But upgrading was even wrongER.
> Just look at https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11593
> The new kernel spent ~30 hours in updates-testing.
> While it's quite normal for a security fix it's unacceptable for such a
> huge change as ALSA upgrade.

I agree that the mixing of this upgrade with the security fixes was
unfortunate from a testing standpoint and that unfortunately this is not an
isolated incident with kernel updates (it's pretty much unavoidable though:
there are lots of changes to the kernel, some of which are security fixes,
some which aren't, so the security update will always also include
non-security stuff), but reverting the ALSA upgrade is still not the proper
way to fix this, fixing the regressions is.

Now if you think ALSA shouldn't get upgraded at all during a stable release,
you're using the wrong distribution.

> And a question to You.
> If I become a fedora maintainer and (in some way manage to) upgrade F10
> to kernel-2.6.29 are we going to revert my update or try to fix all the
> regressions which will take ~2 months.

Nobody is going to upgrade F10 to 2.6.29 now. The kernel has locked ACLs to
prevent you from doing that. ;-) Those people on the ACL know very well
that 2.6.29 is not ready for production use at all yet. But if you mean
2.6.28:

> P.S. 2.6.28 fixes suspend-wakeup issues for my notebook, but I'm not
> asking anyone to upgrade F10 to it.

F10 _will_ be upgraded to 2.6.28, and in fact this is likely to happen very
soon. (And 2.6.29 will be pushed too, when it's ready, which is of course
not now.) Fedora does push out new versions of some packages as updates,
and the kernel is one of those packages. If that's not OK for you, then
Fedora is not for you.

And once this upgrade is out, you can be fairly sure it will *not* be
reverted. Reverting it would be highly impractical for several reasons, in
particular it would require introducing an Epoch in the kernel package and
it would reintroduce all the bugs fixed by the update (which would also be
a nightmare from a bug triaging standpoint). The "try to fix all the
regressions" method is how *all* kernel updates in the past have been
handled.

        Kevin Kofler



From pertusus at free.fr  Tue Jan  6 11:00:26 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Tue, 6 Jan 2009 12:00:26 +0100
Subject: sound problems
In-Reply-To: <49632493.9030001@gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<49626737.7020109@gmail.com> <gjuosf$oic$1@ger.gmane.org>
	<49632493.9030001@gmail.com>
Message-ID: <20090106110025.GA2478@free.fr>

On Tue, Jan 06, 2009 at 01:29:55PM +0400, Suren Karapetyan wrote:

> Breaking something which works to fix something which doesn't work is  
> not the right way to go.

It is how things are done in fedora for many packages, and I don't think 
it is gonna change soon: fixing regressions has a cost. If you don't 
like regressions, maybe Fedora is not the right distro for you.

--
Pat



From sundaram at fedoraproject.org  Tue Jan  6 11:10:42 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 16:40:42 +0530
Subject: sound problems
In-Reply-To: <20090106090045.GC4061@victor.nirvana>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
Message-ID: <49633C32.6050805@fedoraproject.org>

Axel Thimm wrote:
> On Tue, Jan 06, 2009 at 01:54:57PM +0530, Rahul Sundaram wrote:
>> Axel Thimm wrote:
>>> Incompatible to what? If there are conflicts between ATrpms' packages
>>> and others from the N thousand official packages, please report
>>> them and we'll fix them.
>> You could simply run a script
> 
> Which one? If there are conflicts they are at file level which is
> (was?) always a problem for the main Fedora repos within themselves,
> too. 

Check a list of package names. That will catch the many obvious 
duplicates in your repo now. It is not that hard to look over the whole 
list manually either. We will worry about filenames later.

> So when talking about duplication of work/efforts one needs to check
> what was really the duplicate, just blaming ATrpms for carring
> duplicates, when these are actually ancient packages is wrong.

The point is not about finding blame. It is just that you evidently have 
a lot of packages in your repo, you don't need to anymore. Just drop 
them in your repo and we can avoid conflicts for those.

Otherwise, you are free to import and maintain the packages directly in 
the Fedora repository instead of your own which will work just fine as 
well.

There are dozens of third party repositories and asking every 
maintainers to cross check the entire list isn't that feasible. When it 
is, I am all for it.

Rahul



From sundaram at fedoraproject.org  Tue Jan  6 11:21:07 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 16:51:07 +0530
Subject: sound problems
In-Reply-To: <68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
Message-ID: <49633EA3.6030207@fedoraproject.org>

Paulo Cavalcanti wrote:

> Rahul,
> 
> if my memory is not failing, some packages appeared first in ATrpms
> than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc. I am not 
> discussing
> if these packages are useful or not. The fedora version of xzgv was 
> never able
> to display the thumbnails correctly, for instance. Why? Because it has 
> to be compiled with
> gcc3.

Was there a bug report filed on this? Again, when problems are in a 
repository, working together to fix the problem is more of a benefit, 
compared to have alternative fixed versions in a place, where majority 
of end users won't benefit from it. If maintainers don't have time, 
step-in and become co-maintainers and fix the problems instead.

> But the only reason for the existence of a 3rd party repo is a 
> multimedia package.
> Almost all of them are based on ffmpeg, which is obtained from svn. 
> Therefore,
> it is very difficult to have compatible packages, since ffmpeg API 
> changes very often.

You just one single repository for patent encumbered multimedia and 
other things Fedora won't carry. You don't many many conflicting 
repositories for this.

Again, I understand the license issue,
> but it would be much more
> appropriate if Fedora did not supply it at all (I think a gstreamer 
> solution only would be preferable).
> But this is my opinion only.

Your opinion doesn't take into consideration why xine-lib is in the 
repository in the first place. Xine as a multimedia framework is a 
dependency on many many packages in the repository including KDE and 
Miro. Excluding xine-lib means, you have to exclude a whole lot of 
others from the repository as well. Try running repoquery on xine-lib 
for a entire list.

Besides, the xine-lib package in Fedora is carefully coordinated, often 
by the same maintainer to work with a single third party repository. 
Others when they have conflicting packages, create problems for end 
users which is reflected in the current discussions.

> The only thing I cannot put up with is discrimination. For several years 
> I have seen
> some people, in Fedora lists, execrating Axel. However, the thing came 
> to a point
> that I can not stand anymore. When the subject changes from technical to 
> personal,
> there is nothing else to be said.
> 
> This type of behavior, when tolerated,  works as "low (level) pass 
> filter", and implies,
>  by omission, in a consent of the community.

You would note that, many people including myself did oppose personal 
attacks and will continue to do so. Generalizations are not appropriate.

Rahul



From ville.skytta at iki.fi  Tue Jan  6 11:31:58 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 6 Jan 2009 13:31:58 +0200
Subject: debuginfo audit
In-Reply-To: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
References: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
Message-ID: <200901061331.59622.ville.skytta@iki.fi>

On Tuesday 06 January 2009, Roland McGrath wrote:
> I've been setting up to do mass tests on all the debuginfo files,
> and I've generated some data along the way.

Would you be interested in including this script I wrote some time ago in your 
script set in git?  http://scop.fedorapeople.org/scripts/debuginfocheck.py

It's feeble in features compared to your script set, but also so much more 
lightweight and requires no setup on Fedora boxes that I suppose more people 
could be interested in running it more often.

Example output from current rawhide follows.  Many of the reported things are 
due to rpmbuild's inability to extract debuginfo packages in certain 
scenarios (static libs only, some mono related packages - perhaps these would 
be fixable in rpmbuild?), and some are genuine packaging bugs, all of which 
should already have bugs reported against them unless new ones have appeared 
since I last ran this and filed bugs for my findings.

I haven't seen any "without sources" entries included in the in quite a while 
so it's possible that something has changed and the script no longer detects 
these issues correctly, or of course it could be that there simply hasn't 
been such packages in the repo.

$ time debuginfocheck.py rawhide-debuginfo
Importing additional filelist information

Empty debuginfo packages:
    bibus-debuginfo-1.4.3.1-1.fc11.x86_64
    boo-debuginfo-0.8.1.2865-4.fc9.x86_64
    cowbell-debuginfo-0.3-0.svn34.4.fc10.x86_64
    dbus-sharp-debuginfo-0.63-10.fc10.x86_64
    eclipse-pydev-debuginfo-1.3.24-4.fc11.x86_64
    eclipse-rpm-editor-debuginfo-0.4.0-5.fc10.x86_64
    etherboot-debuginfo-5.4.4-7.fc11.x86_64
    fedora-idm-console-debuginfo-1.1.1-2.fc9.x86_64
    fpc-debuginfo-2.2.2-3.fc10.x86_64
    g2clib-debuginfo-1.1.7-1.fc10.x86_64
    gecko-sharp2-debuginfo-0.13-3.fc10.x86_64
    gnu-efi-debuginfo-3.0e-2.fc10.x86_64
    gnustep-make-debuginfo-2.0.6-14.fc11.x86_64
    iml-debuginfo-1.0.2-4.fc11.x86_64
    incollector-debuginfo-1.0-6.fc9.1.x86_64
    ipod-sharp-debuginfo-0.8.1-1.fc10.x86_64
    libglfw-debuginfo-2.6-2.fc11.x86_64
    libmimedir-debuginfo-0.4-4.fc9.x86_64
    libnet-debuginfo-1.1.2.1-12.fc9.x86_64
    libnet10-debuginfo-1.0.2a-15.fc10.x86_64
    mboxgrep-debuginfo-0.7.9-6.fc10.x86_64
    mpfi-debuginfo-1.3.4-0.4.RC3.fc11.x86_64
    muine-scrobbler-debuginfo-0.1.8-7.fc10.x86_64
    sublib-debuginfo-0.9-2.fc10.x86_64
    sugar-debuginfo-0.83.4-2.fc11.x86_64

4198 debuginfo packages, 25 empty, 0 with no sources.


real    0m10.676s
user    0m8.659s
sys     0m0.547s



From kevin.kofler at chello.at  Tue Jan  6 11:44:21 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 12:44:21 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
Message-ID: <gjvg74$me4$1@ger.gmane.org>

Paulo Cavalcanti wrote:
> if my memory is not failing, some packages appeared first in ATrpms
> than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc.

But that is pretty much irrelevant. The point is that now those packages are
duplicates and there's no reason to continue providing them in ATrpms, even
if you were first.

> The fedora version of xzgv was never able to display the thumbnails
> correctly, for instance. Why? Because it has to be compiled with gcc3.

Ugh... This is really not a solution, the software should be fixed to work
properly when built with GCC 4 instead.

> But the only reason for the existence of a 3rd party repo is a multimedia
> package. Almost all of them are based on ffmpeg, which is obtained from
> svn. Therefore, it is very difficult to have compatible packages, since
> ffmpeg API changes very often.

And that's why you should let RPM Fusion handle those packages and not waste
your time duplicating them. Again, this is not a matter of who was first,
but practical pragmatism: it makes much more sense to let a big repo like
RPM Fusion with many maintainers do the work (and if you want to help out,
ask for comaintainership within RPM Fusion) than a 2-man show.

I think everyone would benefit from that:
* users, because the repos are no longer incompatible,
* you (both yourself and Axel), because you have less work and get no more
complaints about conflicts,
* RPM Fusion, because they get fewer complaints about conflicts as well, and
if you decide to become comaintainers there, also less work.

And if you want to package something which is not in RPM Fusion, you can
still build it against RPM Fusion's ffmpeg (but it would be better to just
submit it for review in RPM Fusion).

> Because of that, packages like, vlc, mplayer and xine, must get all of
> their dependencies from the same repo.

Kinda my point. ;-) See above.

> As a matter of fact, Fedora supplies a chopped version of xine, and the
> other repos try to "fill the gaps".  They accomplish this by creating
> packages, such as, xine-lib-moles, xine-lib-extras-nonfree,
> xine-lib-extras-freeworld, etc.

Which is the right way to do this. (And FYI, I'm a comaintainer of xine-lib
and xine-lib-extras-freeworld.) Xine-lib has a plugin architecture for a
reason. And FYI, xine-lib-moles and xine-lib-extras-nonfree are obsolete
names (one from FreshRPMs, one from Livna), they're both replaced (with RPM
Obsoletes tags in place) by xine-lib-extras-freeworld from RPM Fusion.

> In xine particular case,  it is much easier to compile it as a whole

It may be easier for you, but it means you're replacing the Fedora package,
potentially causing incompatibilites (and definitely causing file conflicts
with xine-lib-extras-freeworld, which doesn't expect you to ship a xine-lib
which includes this stuff), and also causing repository race conditions
when a new xine-lib comes out (which we may be pushing out very quickly as
a security fix - xine-lib updates are often security-sensitive). (Users
will get the Fedora update and end up without the extra codecs with no
warning.)

> than wasting hours trying to see what is missing.

Then why waste your time when we xine-lib maintainers in Fedora, who are
also the ones maintaining xine-lib-extras-freeworld in RPM Fusion, already
did the work for you?

If you hate RPM Fusion that much, you could just rebuild the
xine-lib-extras-freeworld SRPM from there and ship it. No work for you, and
instant repo compatibility. But I think it would be more helpful for
everyone if you worked with RPM Fusion rather than against it.

> Again, I understand the license issue, but it would be much more
> appropriate if Fedora did not supply it at all (I think a gstreamer
> solution only would be preferable).

No, because many useful apps use xine-lib, especially in KDE:
* The recommended backend for Phonon, which is used for all multimedia in
KDE 4, is the xine-lib backend. There is a GStreamer backend, but it has
many known bugs, especially when used with Amarok 2 (so the Amarok
developers strongly recommend against its use), and its way to handle
output device selection makes it not work with PulseAudio out of the box.
* Several older KDE apps don't support GStreamer at all, for example
Kaffeine (which is still the most powerful KDE video player) and Amarok 1
(which was the app xine-lib was initially introduced for in Fedora).
* Dragon Player (the default video player in KDE 4) requires xine-lib for
some of its functionality (and xine-lib has to be found at build time for
that functionality to be enabled).

> I do not think I am on the dark side of the force, but, from this day on,
> I will avoid posting to any Fedora list.

I think you're overreacting. Please ignore the rudeness some people are
showing and think of cooperating more. While it doesn't really excuse their
rudeness, you have to understand those people are frustrated by the lack of
cooperation from Axel and you over some issues (such as the ones I
highlighted above). I'm sure it is possible to achieve a healthy atmosphere
without you running away.

        Kevin Kofler



From fedora at leemhuis.info  Tue Jan  6 11:56:34 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 06 Jan 2009 12:56:34 +0100
Subject: Moving xine to Fedora (Was: Re: sound problems)
In-Reply-To: <gjvg74$me4$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<gjvg74$me4$1@ger.gmane.org>
Message-ID: <496346F2.3010001@leemhuis.info>

On 06.01.2009 12:44, Kevin Kofler wrote:
> Paulo Cavalcanti wrote:
>> if my memory is not failing, some packages appeared first in ATrpms
>> than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc.
> But that is pretty much irrelevant.

Strong +1

Which reminds me: RPM Fusion (just as ATrpms now and Livna and freshrpms 
in the past) ships xine, but that afaics should have been moved to 
Fedora ages ago after xine-lib had been imported to Fedora. But the xine 
maintainers from Livna/RPM Fusion afaics never found time for that :-/ . 
Hence I'm asking here:

Does anybody have a few spare cycles and is willig to submitt xine to 
Fedora? Dan Hor?k recently even offered to do the review (see
http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2009-January/003279.html
), as he has a package which depends on it (hence it could go to Fedora 
is xine makes it into Fedora).


CU
knurd



From mschwendt at gmail.com  Tue Jan  6 12:12:52 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 13:12:52 +0100
Subject: Conflicts with 3rd party repos (was: Re: sound problems)
In-Reply-To: <20090106090045.GC4061@victor.nirvana>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
Message-ID: <20090106131252.3a52d53e.mschwendt@gmail.com>

On Tue, 6 Jan 2009 11:00:45 +0200, Axel wrote:

> We had a discussion with Max and Mike at LinuxTag about this last year
> and the common approach was that Fedora packagers would be kindly
> asked to check and cooperate with (major) 3rd party repos instead of
> blindly packaging creating the incompatibilities (actually this was
> more in the loght of EPEL than Fedora proper). Unfortunately this was
> never really followed up after the meeting.

Interesting. Why do Max [Spevack] and Mike [McGrath?] assume this is
feasible? This is different from the results of previous discussions
within old FESCO, FESCo and another major 3rd party repo. The participants
of previous discussions [to my knowledge] have all found that it is not
feasible (or requires too much effort). What has changed? Do the members
of the current committees have a different opinion?

One could establish a list of "big players" in the 3rd party repo scene,
specific repo URLs, and corresponding guidelines, and make it a MUST item
on the list of things to do during package review. That would increase the
hurdle quite a bit for the packagers and reviewers. And there are no tools
available that check for conflicts with arbitrary repositories. Some
existing [unofficial] scripts either need local access to all packages or
run for quite a long time. There have been conflicting duplicates in the
review queue as well as within the Fedora package collection.



From mschwendt at gmail.com  Tue Jan  6 12:13:15 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 13:13:15 +0100
Subject: Checking repos for conflicting duplicates (was: Re: sound problems)
In-Reply-To: <49633C32.6050805@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
	<49633C32.6050805@fedoraproject.org>
Message-ID: <20090106131315.719c28e4.mschwendt@gmail.com>

On Tue, 06 Jan 2009 16:40:42 +0530, Rahul wrote:

> Axel Thimm wrote:
> > On Tue, Jan 06, 2009 at 01:54:57PM +0530, Rahul Sundaram wrote:
> >> Axel Thimm wrote:
> >>> Incompatible to what? If there are conflicts between ATrpms' packages
> >>> and others from the N thousand official packages, please report
> >>> them and we'll fix them.
> >> You could simply run a script
> > 
> > Which one? If there are conflicts they are at file level which is
> > (was?) always a problem for the main Fedora repos within themselves,
> > too. 
> 
> Check a list of package names. That will catch the many obvious 
> duplicates in your repo now. It is not that hard to look over the whole 
> list manually either. We will worry about filenames later.

Not too hard? And still we've had conflicting duplicates in the
Fedora review queue as well as within the Fedora package collection.
Sometimes it's just the package names that differ (despite
the existing package naming guidelines). Other times the files
within the packages are stored in different locations.



From sundaram at fedoraproject.org  Tue Jan  6 12:17:22 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 17:47:22 +0530
Subject: Checking repos for conflicting duplicates
In-Reply-To: <20090106131315.719c28e4.mschwendt@gmail.com>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<20090106090045.GC4061@victor.nirvana>	<49633C32.6050805@fedoraproject.org>
	<20090106131315.719c28e4.mschwendt@gmail.com>
Message-ID: <49634BD2.3040907@fedoraproject.org>

Michael Schwendt wrote:
> On Tue, 06 Jan 2009 16:40:42 +0530, Rahul wrote:
> 
>> Axel Thimm wrote:
>>> On Tue, Jan 06, 2009 at 01:54:57PM +0530, Rahul Sundaram wrote:
>>>> Axel Thimm wrote:
>>>>> Incompatible to what? If there are conflicts between ATrpms' packages
>>>>> and others from the N thousand official packages, please report
>>>>> them and we'll fix them.
>>>> You could simply run a script
>>> Which one? If there are conflicts they are at file level which is
>>> (was?) always a problem for the main Fedora repos within themselves,
>>> too. 
>> Check a list of package names. That will catch the many obvious 
>> duplicates in your repo now. It is not that hard to look over the whole 
>> list manually either. We will worry about filenames later.
> 
> Not too hard? And still we've had conflicting duplicates in the
> Fedora review queue as well as within the Fedora package collection.

Not comparable. Axel has a relatively small repo and packages can be 
verified much more easily.

Rahul



From mschwendt at gmail.com  Tue Jan  6 12:25:47 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 13:25:47 +0100
Subject: xzgv in Fedora broken? (was: Re: sound problems)
In-Reply-To: <49633EA3.6030207@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org>
Message-ID: <20090106132547.eac4b1b5.mschwendt@gmail.com>

On Tue, 06 Jan 2009 16:51:07 +0530, Rahul wrote:

> Paulo Cavalcanti wrote:
> 
> > Rahul,
> > 
> > if my memory is not failing, some packages appeared first in ATrpms
> > than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc. I am not 
> > discussing
> > if these packages are useful or not. The fedora version of xzgv was 
> > never able
> > to display the thumbnails correctly, for instance. Why? Because it has 
> > to be compiled with
> > gcc3.
> 
> Was there a bug report filed on this? Again, when problems are in a 
> repository, working together to fix the problem is more of a benefit, 
> compared to have alternative fixed versions in a place, where majority 
> of end users won't benefit from it. If maintainers don't have time, 
> step-in and become co-maintainers and fix the problems instead.

Exactly. Although above bug sounds as if the packager should have noticed
it during one of the Fedora development cycles, it can be most
disappointing for Fedora packagers to learn after a long time, that there
are problems which have not been reported to Fedora and neither to
upstream. I'm aware of several cases like that. Sometimes you meet users,
who claim that simply rebuilding a Fedora package would fix something.
They point their fingers at Fedora and blame Fedora for "lame bugs", but
when finally a problem is examined, it turns out they have been mistaken
as the problem is completely elsewhere. Trying to work around problems
with private builds or upgrades in unofficial repos may be a temporary
solution, but it doesn't help to improve Fedora [or the packaged
software].



From ville.skytta at iki.fi  Tue Jan  6 12:31:52 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 6 Jan 2009 14:31:52 +0200
Subject: Tracking new review requests?
Message-ID: <200901061431.53501.ville.skytta@iki.fi>

Hello,

I'd like to be notified about new Fedora package review requests by mail, only 
once.  I'm currently subscribed to fedora-package-review which is otherwise 
fine, except that I receive all of the review mail and not only the first 
mail sent when a new review request is submitted.

I suppose I could set up a filter that gets the mails I'm not usually 
interested out of the way, but I'd rather not receive anything but the first 
one in the first place (unless I'm submitter/reviewer/cc'd of course, but 
that's handled by direct mails).

Would it be possible to add a mailman topic to fedora-package-review that 
receives only new submissions?  I don't know how mailman topics are 
configured, but I suppose these can be detected by matching "New: " at the 
beginning of the subject.  Any other solutions?



From Axel.Thimm at ATrpms.net  Tue Jan  6 12:32:40 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 14:32:40 +0200
Subject: sound problems
In-Reply-To: <gjvbg8$81h$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
Message-ID: <20090106123240.GA15179@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 11:24:07AM +0100, Kevin Kofler wrote:
> Axel Thimm wrote:
> > Incompatible to what? If there are conflicts between ATrpms' packages
> > and others from the N thousand official packages, please report
> > them and we'll fix them.
> 
> One concrete source of incompatibility is that you use Debian-style
> versioning (e.g. libquicktime0) for some library packages, which is against
> Fedora guidelines (in fact, IIRC a guideline change you proposed to that
> effect was rejected) and which can confuse yum in some cases.

I think it was rather forgotten and withdrawn, but that's rejected
nonetheless.

The reson I use these conventions is because they actually increase
compatibility: When repo X, repo Y and repo Z (one of them may be
Fedora, the others two 3rd party ones) have built foo, baz and wuz
against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
packages make sure that they can all coexist w/o one repo enforcing a
full rebuild on the other.

This will even help Fedora, as the reason Debian/Mandriva introduced
them was for being able to cope with tons of packages when a
dependency does an sobump.

Currently in Fedora whenever a package with many dependent other
packages changes soname, we need to go yelling around to other
packagers and are only able to do an upgrade of this kind in rawhide.

So for Fedora I suggested it w/o looking at 3rd parties, but I'm using
it at ATrpms for better 3rd party support.

See for example the x264 libs. Any 3rd party repo using them is doomed
to be incompatible to the other one. Unless we would all use
libfoo<so> style packaging.

In a nutshell: This is done for better compatibility, not worse.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/32bbe65f/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 12:45:49 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 14:45:49 +0200
Subject: sound problems
In-Reply-To: <gjvapj$5sf$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana> <gjvapj$5sf$1@ger.gmane.org>
Message-ID: <20090106124549.GB15179@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 11:12:01AM +0100, Kevin Kofler wrote:
> Axel Thimm wrote:
> > And to xine: This is also a package by Paulo, so I can say less about
> > it, but AFAIK he needed to undo some of the multimedia codec removal
> > bits to reenable some functionality.
> 
> That's what xine-lib-extras-freeworld in RPM Fusion is for.
> 
> xine-lib has a plugin architecture, so adding features should be done by
> adding the plugins, not replacing the whole package.
> 
> As for the conflicts with RPM Fusion, I don't think it is fair to blame it
> all on RPM Fusion. There's a lot you could do to avoid both
> incompatibilities and duplication of effort. Upgrade paths are not really a
> convincing argument:
> Nobody is trying to argue, rpmfusion it was no problem to ensure
> proper upgrade paths from both Livna and FreshRPMs, I'm sure RPM
> Fusion maintainers will be willing to fix the upgrade paths from
> ATrpms for the relevant packages if you accept that RPM Fusion will
> be the authority for those packages. In fact many of them will also
> have no problems with letting you and/or Paolo comaintain those
> packages. The root of the problem is that you're shipping some
> packages which are also in RPM Fusion. There would be no
> incompatibility if you didn't do that.

Please check

http://lists.fedoraunity.org/pipermail/repo-merge-discussion/2007-May/000137.html

for my reasons to step down from rpmfusion/epel. In both projects I
was a coinitiator and was burned down.

I don't want to rehash the discussion there, but I'm under the
impression that you don't know the history of it and that you think
this is just for personal pride or whatever.

FWIW rpmfusion is a 3rd party repo, very much like Dag, Dries,
PlanetCCRMA, CentOS Extras, KB, ATrpms etc. I'm not placing any
authority hierarchy upon any of these, and I'm expecting similar from
the other repo maintainers, of course.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/8886e61a/attachment.sig>

From sundaram at fedoraproject.org  Tue Jan  6 12:48:42 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 18:18:42 +0530
Subject: sound problems
In-Reply-To: <20090106124549.GB15179@victor.dsathen.edu.gr>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<20090106090045.GC4061@victor.nirvana>
	<gjvapj$5sf$1@ger.gmane.org>
	<20090106124549.GB15179@victor.dsathen.edu.gr>
Message-ID: <4963532A.3040408@fedoraproject.org>

Axel Thimm wrote:

> 
> FWIW rpmfusion is a 3rd party repo, very much like Dag, Dries,
> PlanetCCRMA, CentOS Extras, KB, ATrpms etc. I'm not placing any
> authority hierarchy upon any of these, and I'm expecting similar from
> the other repo maintainers, of course.

It is not a matter of authority but compatibility. As far as 
compatibility is concerned, they aren't in the same level.  More 
coordination would help.

Rahul



From choeger at cs.tu-berlin.de  Tue Jan  6 12:49:50 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Tue, 06 Jan 2009 13:49:50 +0100
Subject: security update for xterm needed
Message-ID: <1231246190.7606.4.camel@choeger5.umpa.netz>

Hi folks,

I will file a bug becasue of this, but you should be sure to update
xterm asap, if you use it:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030

I testet on fedora 10 accordign to
http://www.heise.de/newsticker/Terminal-Emulator-xterm-fuehrt-untergeschobene-Befehle-aus--/meldung/121196
(sorry, german)

I tried:

[choeger at choeger5 ~]$ perl -e 'print "\eP\$q\nwhoami\n\e\\"' > bla.log

and in xterm:

[choeger at choeger5 ~]$ cat bla.log 
^[P0$r

whoami

^[\[choeger at choeger5 ~]$ 
[choeger at choeger5 ~]$ whoami
choeger
[choeger at choeger5 ~]$ 
[choeger at choeger5 ~]$ 

As you can see, its valid.



-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/eb426585/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 12:54:20 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 14:54:20 +0200
Subject: sound problems
In-Reply-To: <49633C32.6050805@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
	<49633C32.6050805@fedoraproject.org>
Message-ID: <20090106125420.GC15179@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 04:40:42PM +0530, Rahul Sundaram wrote:
> Axel Thimm wrote:
>> On Tue, Jan 06, 2009 at 01:54:57PM +0530, Rahul Sundaram wrote:
>>> Axel Thimm wrote:
>>>> Incompatible to what? If there are conflicts between ATrpms' packages
>>>> and others from the N thousand official packages, please report
>>>> them and we'll fix them.
>>> You could simply run a script
>>
>> Which one? If there are conflicts they are at file level which is
>> (was?) always a problem for the main Fedora repos within themselves,
>> too. 
>
> Check a list of package names. That will catch the many obvious  
> duplicates in your repo now. It is not that hard to look over the whole  
> list manually either. We will worry about filenames later.

I've done that a lot of times and withdrawn a lot, these are not the
package to worry about. And if there is a package in ATrpms that's in
a higher version than in Fedora it will be for a reason, and if not
bugzilla me.

> Otherwise, you are free to import and maintain the packages directly in  
> the Fedora repository instead of your own which will work just fine as  
> well.

I've done that with several packages. And the result is that it takes
months to even a year to get it through. It is far from "just
fine". Still I'm doing just that at a.

> There are dozens of third party repositories and asking every  
> maintainers to cross check the entire list isn't that feasible. When it  
> is, I am all for it.

And there are tons of Fedora packages submitted, it isn't feasible for
the dozen repos to check against every package submission in Fedora.

(And actually I would call major repos only a handful, some with
rather well defined niches, e.g. if I want to package a sound
application I will check against planetccrma, if a kde app against KDE
Redhat etc.)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/eb91cc5c/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Jan  6 13:03:54 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 10:03:54 -0300
Subject: kernel-2.6.29-0.9.rc0.git4.fc11.x86_64 hang (?),
 yum-complete-transaction weirdness
Message-ID: <200901061303.n06D3sES007430@laptop14.inf.utfsm.cl>

I started the machine today, it booted the kernel stated. After futzing
around a bit (and starting yum update) the CPU usage went to the maximum
(as shown by CPU Frequency Scaling Monitor), the mouse did move but the
spinner on Firefox (opening a page) went very slowly and on starts and
fits. I could go to the System menu, but that was it. No reaction to "Shut
down..." No reaction to ctrl-alt-DEL, had to shut down by force.

BTW, yum-complete-transaction (the yum transaction did not finish) wanted 
to delete 1105 packages (!) while updating a handful. Killed that one... 

Ran "yum update", which finished normally; and then
"yum-complete-transaction" again. Now it wants to delete only 1102
packages, including yum itself.

After "package-cleanup --cleandupes" (which deleted some 20 leftovers) now
it's down to 1082 to go. Reassuring...
-- 
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 sundaram at fedoraproject.org  Tue Jan  6 13:04:11 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 18:34:11 +0530
Subject: sound problems
In-Reply-To: <20090106125420.GC15179@victor.dsathen.edu.gr>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<20090106090045.GC4061@victor.nirvana>	<49633C32.6050805@fedoraproject.org>
	<20090106125420.GC15179@victor.dsathen.edu.gr>
Message-ID: <496356CB.7020104@fedoraproject.org>

Axel Thimm wrote:

> I've done that a lot of times and withdrawn a lot, these are not the
> package to worry about. And if there is a package in ATrpms that's in
> a higher version than in Fedora it will be for a reason, and if not
> bugzilla me.

No wild goose chases. I named specific examples and to the best of my 
knowledge, they are just there due to the history which isn't relevant 
anymore. Now that those packages are in Fedora repository, just drop 
them please. It's a very simple way to gain better compatibility.

For xine-lib and other similar packages, instead of conflicting, either 
drop packages or copy the Fedora (and rpmfusion one)

> I've done that with several packages. And the result is that it takes
> months to even a year to get it through. It is far from "just
> fine". 

It works fine for many people. The difference is that, they are willing 
to swap reviews inorder to get their own packages moving.  If not 
getting reviews is your only problem, let me offer to do that or arrange 
to do that for all packages you agree to move from your own repo to Fedora.

>> There are dozens of third party repositories and asking every  
>> maintainers to cross check the entire list isn't that feasible. When it  
>> is, I am all for it.
> 
> And there are tons of Fedora packages submitted, it isn't feasible for
> the dozen repos to check against every package submission in Fedora.

It is feasible for you to check your own repository packages pretty 
easily. It is not a huge list. If you are willing to coordinate, others, 
can and will help you out as well.

Rahul



From kevin.kofler at chello.at  Tue Jan  6 13:05:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 14:05:17 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
Message-ID: <gjvkue$64j$1@ger.gmane.org>

Axel Thimm wrote:
> The reson I use these conventions is because they actually increase
> compatibility: When repo X, repo Y and repo Z (one of them may be
> Fedora, the others two 3rd party ones) have built foo, baz and wuz
> against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
> packages make sure that they can all coexist w/o one repo enforcing a
> full rebuild on the other.

Repos building against different versions of libbar are the actual problem
there. Your solution is a bad attempt at working around it (bad because it
can cause file conflicts between the differently-versioned packages -
library packages are not just a single .so.n file - and is also known to
confuse yum in other situations) which has not been considered useful by
Fedora (as the lack of success of your attempted guideline change shows).

> This will even help Fedora, as the reason Debian/Mandriva introduced
> them was for being able to cope with tons of packages when a
> dependency does an sobump.

In Fedora we already have a solution for that, it's called a mass rebuild.

> Currently in Fedora whenever a package with many dependent other
> packages changes soname, we need to go yelling around to other
> packagers

Which is the right solution. Otherwise the packages will not benefit from
bugfixes and improvements in the new version of the library.

> and are only able to do an upgrade of this kind in rawhide. 

No, we can do a grouped update with a library and all dependent packages.
(Buildroot overrides can be requested from rel-eng to build such grouped
updates.) Of course this doesn't make sense for something which almost
everything links, such as OpenSSL, but trying to upgrade such a library in
a release is just insane, it makes much more sense to settle on a single
version. Having packages require different versions of OpenSSL just because
they happened to be built at different times is not helpful, one version is
enough.

> So for Fedora I suggested it w/o looking at 3rd parties, but I'm using
> it at ATrpms for better 3rd party support.

IMHO you should follow the Fedora guidelines on this issue, which means that
you should only add version suffixes for non-default versions of the
library, and only add such non-default (compat or forward-compat) packages
where really needed (and no, "package X in repo Y was not rebuilt against
the new version" is not a real need, it should just get rebuilt; only if
this is not easily possible a compat package makes sense). In addition, the
common practice in Fedora is to use the user-visible version as the suffix,
not the soname version. Otherwise you end up with confusing nonsense such
as KDE 3 libraries in a package called kdelibs4. Sonames are what soname
autoprovs/autoreqs are for, not package names.

> See for example the x264 libs. Any 3rd party repo using them is doomed
> to be incompatible to the other one. Unless we would all use
> libfoo<so> style packaging.

Or unless the smaller repositories (e.g. ATrpms) just accept one large
repository (i.e. RPM Fusion) as the authority for x264 (and again: who was
first is really irrelevant here) and stop shipping incompatible x264
packages. Just build against the version in RPM Fusion. If you don't want
your repository to depend on RPM Fusion (which is IMHO a bad decision),
just re-sign or rebuild the package from RPM Fusion.

> In a nutshell: This is done for better compatibility, not worse.

I know this is the intention, but in practice it is rather unhelpful and
counterproductive. IMHO you should follow the Fedora guidelines closer,
even where you believe them to be technically inferior.

        Kevin Kofler



From mschwendt at gmail.com  Tue Jan  6 13:11:35 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 14:11:35 +0100
Subject: Package naming conflicts (was: Re: sound problems)
In-Reply-To: <20090106123240.GA15179@victor.dsathen.edu.gr>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
Message-ID: <20090106141135.05670460.mschwendt@gmail.com>

On Tue, 6 Jan 2009 14:32:40 +0200, Axel wrote:

> On Tue, Jan 06, 2009 at 11:24:07AM +0100, Kevin Kofler wrote:
> > Axel Thimm wrote:
> > > Incompatible to what? If there are conflicts between ATrpms' packages
> > > and others from the N thousand official packages, please report
> > > them and we'll fix them.
> > 
> > One concrete source of incompatibility is that you use Debian-style
> > versioning (e.g. libquicktime0) for some library packages, which is against
> > Fedora guidelines (in fact, IIRC a guideline change you proposed to that
> > effect was rejected) and which can confuse yum in some cases.
> 
> I think it was rather forgotten and withdrawn, but that's rejected
> nonetheless.
> 
> The reson I use these conventions is because they actually increase
> compatibility: When repo X, repo Y and repo Z (one of them may be
> Fedora, the others two 3rd party ones) have built foo, baz and wuz
> against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
> packages make sure that they can all coexist w/o one repo enforcing a
> full rebuild on the other.

Without proper Obsoletes/Provides in both directions (i.e. Fedora <-> 3rd
party repo), it doesn't work flawlessly. libbar3-3.0.1 will conflict
with libbar-3.0.2. AFAIK, this has happened several times before.
Additionally, you need to take precautions and relocate files in
several packages for them to become parallel-installable.

> This will even help Fedora, as the reason Debian/Mandriva introduced
> them was for being able to cope with tons of packages when a
> dependency does an sobump.

Without a doubt. If done properly, it would fix the poor broken deps
caused by sudden/unexpected soname bumps.

> Currently in Fedora whenever a package with many dependent other
> packages changes soname, we need to go yelling around to other
> packagers and are only able to do an upgrade of this kind in rawhide.

This is also due to koji buildroot protection and overrides.
Some packagers believe they must push a soname bump to stable before
they can rebuild dependencies. They feel embarrassed when they learn
that they can request releng to set an override-tag and then prepare
a group update for bodhi. Features and procedures are not known enough
and are hard to find in the Wiki.



From vonbrand at inf.utfsm.cl  Tue Jan  6 13:13:06 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 10:13:06 -0300
Subject: sound problems
In-Reply-To: <200901051916.25386.konrad@tylerc.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
	<200901051916.25386.konrad@tylerc.org>
Message-ID: <200901061313.n06DD6nb007531@laptop14.inf.utfsm.cl>

Conrad Meyer <konrad at tylerc.org> wrote:
> On Monday 05 January 2009 07:04:17 pm Jeff Spaleta wrote:
> > Here a subset of Axel's direct contributions to Fedora:
> > https://admin.fedoraproject.org/pkgdb/users/packages/athimm
> 
> And here's a subset of his directly destructive behavior towards Fedora:
> http://atrpms.net/dist/f10/

How does something independent, meant to be used _with_ Fedora (at your own
risk!)  "destroy Fedora"?

> > And more to the point, there are many public 3rd party repositories
> > out there which conflict to varying degrees with the official Fedora
> > repositories.   Do you plan to ridicule each and every contributor who
> > runs a 3rd party repo on the side which conflicts?

> Yes.

Third party repositories are exactly that. Discussing them here is
completely off-topic, and way beside the point.
-- 
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 kevin.kofler at chello.at  Tue Jan  6 13:14:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 14:14:50 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana> <gjvapj$5sf$1@ger.gmane.org>
	<20090106124549.GB15179@victor.dsathen.edu.gr>
Message-ID: <gjvlgb$80i$1@ger.gmane.org>

Axel Thimm wrote:
> I don't want to rehash the discussion there, but I'm under the
> impression that you don't know the history of it

Oh I do. That doesn't mean it wasn't a mistake. ;-) Nor that it's a good
idea to continue on that path.

> and that you think this is just for personal pride or whatever.

... yet ...

> FWIW rpmfusion is a 3rd party repo, very much like Dag, Dries,
> PlanetCCRMA, CentOS Extras, KB, ATrpms etc. I'm not placing any
> authority hierarchy upon any of these, and I'm expecting similar from
> the other repo maintainers, of course.

Sense the contradiction there? You're expecting the RPM Fusion community
which includes dozens of packagers to treat your 2-person repository as an
equal and you claim it's not personal pride?

See, I maintain a small repository myself
(http://repo.calcforge.org/fedora/ - mainly because those packages haven't
been cleaned up for review in Fedora or RPM Fusion yet), but I would never
expect that repository to be equivalent in importance to RPM Fusion.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan  6 13:19:38 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 14:19:38 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
	<49633C32.6050805@fedoraproject.org>
	<20090106125420.GC15179@victor.dsathen.edu.gr>
Message-ID: <gjvlpa$80i$2@ger.gmane.org>

Axel Thimm wrote:
> (And actually I would call major repos only a handful, some with
> rather well defined niches, e.g. if I want to package a sound
> application I will check against planetccrma, if a kde app against KDE
> Redhat etc.)

FYI, the kde-redhat packages are almost all stuff backported from Rawhide,
or from a Fedora release to RHEL. There's almost nothing in there which is
not in Fedora (at least Rawhide) already (or in some cases, undergoing
review).

        Kevin Kofler



From promac at gmail.com  Tue Jan  6 13:21:12 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 6 Jan 2009 11:21:12 -0200
Subject: xzgv in Fedora broken? (was: Re: sound problems)
In-Reply-To: <20090106132547.eac4b1b5.mschwendt@gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org>
	<20090106132547.eac4b1b5.mschwendt@gmail.com>
Message-ID: <68720af30901060521x72f1814m2acc1aff7d08611c@mail.gmail.com>

On Tue, Jan 6, 2009 at 10:25 AM, Michael Schwendt <mschwendt at gmail.com>wrote:

> On Tue, 06 Jan 2009 16:51:07 +0530, Rahul wrote:
>
> > Paulo Cavalcanti wrote:
> >
> > > Rahul,
> > >
> > > if my memory is not failing, some packages appeared first in ATrpms
> > > than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc. I am not
> > > discussing
> > > if these packages are useful or not. The fedora version of xzgv was
> > > never able
> > > to display the thumbnails correctly, for instance. Why? Because it has
> > > to be compiled with
> > > gcc3.
> >
> > Was there a bug report filed on this? Again, when problems are in a
> > repository, working together to fix the problem is more of a benefit,
> > compared to have alternative fixed versions in a place, where majority
> > of end users won't benefit from it. If maintainers don't have time,
> > step-in and become co-maintainers and fix the problems instead.
>
> Exactly. Although above bug sounds as if the packager should have noticed
> it during one of the Fedora development cycles, it can be most
> disappointing for Fedora packagers to learn after a long time, that there
> are problems which have not been reported to Fedora and neither to
> upstream. I'm aware of several cases like that. Sometimes you meet users,
> who claim that simply rebuilding a Fedora package would fix something.
> They point their fingers at Fedora and blame Fedora for "lame bugs", but
> when finally a problem is examined, it turns out they have been mistaken
> as the problem is completely elsewhere. Trying to work around problems
> with private builds or upgrades in unofficial repos may be a temporary
> solution, but it doesn't help to improve Fedora [or the packaged
> software].
>

I really tried sometimes, with other packages (memtest86+, in this case):

https://bugzilla.redhat.com/show_bug.cgi?id=237279

Never received an answer in one year and half. I also gave a solution, that
worked for me
with several different computers (Intel and AMD).
The bug was closed, and re-opened now, by another person:

https://bugzilla.redhat.com/show_bug.cgi?id=472981

By the way, the same problem persists in F10. But really, this bug affects
much more people than xzgv, and old image viewer, I thought only me was
using.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/55605f2d/attachment.htm>

From debarshi.ray at gmail.com  Tue Jan  6 13:38:56 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 19:08:56 +0530
Subject: Moving xine to Fedora (Was: Re: sound problems)
In-Reply-To: <496346F2.3010001@leemhuis.info>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<gjvg74$me4$1@ger.gmane.org> <496346F2.3010001@leemhuis.info>
Message-ID: <3170f42f0901060538i394b90e1l35275e8b59696a60@mail.gmail.com>

> Which reminds me: RPM Fusion (just as ATrpms now and Livna and freshrpms in
> the past) ships xine, but that afaics should have been moved to Fedora ages
> ago after xine-lib had been imported to Fedora. But the xine maintainers
> from Livna/RPM Fusion afaics never found time for that :-/ . Hence I'm
> asking here:
>
> Does anybody have a few spare cycles and is willig to submitt xine to
> Fedora?

Isn't the Fedora xine-lib packager (CC'ed) interested?

Cheers,
Debarshi



From cra at WPI.EDU  Tue Jan  6 13:39:36 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 6 Jan 2009 08:39:36 -0500
Subject: xzgv in Fedora broken? (was: Re: sound problems)
In-Reply-To: <68720af30901060521x72f1814m2acc1aff7d08611c@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org>
	<20090106132547.eac4b1b5.mschwendt@gmail.com>
	<68720af30901060521x72f1814m2acc1aff7d08611c@mail.gmail.com>
Message-ID: <20090106133936.GA19432@angus.ind.WPI.EDU>

On Tue, Jan 06, 2009 at 11:21:12AM -0200, Paulo Cavalcanti wrote:
> I really tried sometimes, with other packages (memtest86+, in this case):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=237279
> 
> Never received an answer in one year and half. I also gave a solution, that
> worked for me
> with several different computers (Intel and AMD).
> The bug was closed, and re-opened now, by another person:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=472981
> 
> By the way, the same problem persists in F10. But really, this bug affects
> much more people than xzgv, and old image viewer, I thought only me was
> using.

Have you asked to become a co-maintainer of memtest86+?  Then you 
could just fix the bug yourself.



From mschwendt at gmail.com  Tue Jan  6 13:43:05 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 14:43:05 +0100
Subject: xzgv in Fedora broken? (was: Re: sound problems)
In-Reply-To: <68720af30901060521x72f1814m2acc1aff7d08611c@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org>
	<20090106132547.eac4b1b5.mschwendt@gmail.com>
	<68720af30901060521x72f1814m2acc1aff7d08611c@mail.gmail.com>
Message-ID: <20090106144305.d53382ea.mschwendt@gmail.com>

On Tue, 6 Jan 2009 11:21:12 -0200, Paulo wrote:

> I really tried sometimes, with other packages (memtest86+, in this case):
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=237279
> 
> Never received an answer in one year and half.

So, you punish the xzgv package maintainer because the maintainer
of memtest86+ has ignored you?

Instead, you could have made some noise much earlier. On this list
and also by trying to contact memtest86+ upstream. I know it sucks,
that tickets are closed automatically, hiding them under the carpet
even if the package owner has not posted a single comment. And it's
not nice either to get no answer on problem reports in bugzilla,
but the only way to fix that is to increase the number of maintainers
per package. Even if it's just for a single patch per year, step forward
and help with keeping a package in better shape.

> https://bugzilla.redhat.com/show_bug.cgi?id=472981
> 
> By the way, the same problem persists in F10. But really, this bug affects
> much more people than xzgv, and old image viewer, I thought only me was
> using.

There's activity in that new ticket. 



From vonbrand at inf.utfsm.cl  Tue Jan  6 13:44:22 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 10:44:22 -0300
Subject: debuginfo audit
In-Reply-To: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
References: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
Message-ID: <200901061344.n06DiNGX009617@laptop14.inf.utfsm.cl>

Roland McGrath <roland at redhat.com> wrote:
> I've been setting up to do mass tests on all the debuginfo files,
> and I've generated some data along the way.

Does this include e.g. latest glibc not having debuginfo? (BZ 478426)
-- 
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 Axel.Thimm at ATrpms.net  Tue Jan  6 13:56:43 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 15:56:43 +0200
Subject: sound problems
In-Reply-To: <gjvkue$64j$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<gjvkue$64j$1@ger.gmane.org>
Message-ID: <20090106135643.GC16190@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 02:05:17PM +0100, Kevin Kofler wrote:
> > This will even help Fedora, as the reason Debian/Mandriva introduced
> > them was for being able to cope with tons of packages when a
> > dependency does an sobump.
> 
> In Fedora we already have a solution for that, it's called a mass rebuild.

Oh, my middle name is mass rebuild. This is yet another feature I was
driving for in Fedora, to have scheduled mass rebuilds to do away with
issues like this and others, but mass rebuilds were consdiered only to
be done for really big changes (gcc for example). You can try to bring
it up though. Currently there are just no mass rebuilds.

> > Currently in Fedora whenever a package with many dependent other
> > packages changes soname, we need to go yelling around to other
> > packagers
> 
> Which is the right solution. Otherwise the packages will not benefit from
> bugfixes and improvements in the new version of the library.

A bumbed soname usually implies an API change. Some libs can be deep
in the depdency hierarchy. The issues have been recognized by now also
in Fedora due to the sheer size of it and we do have the first
incarnation libfoo-compat. This is just the first step to an versioned
libfoo<somark>.

> > and are only able to do an upgrade of this kind in rawhide. 
> 
> No, we can do a grouped update with a library and all dependent packages.
> (Buildroot overrides can be requested from rel-eng to build such grouped
> updates.) Of course this doesn't make sense for something which almost
> everything links, such as OpenSSL, but trying to upgrade such a library in
> a release is just insane, it makes much more sense to settle on a single
> version. Having packages require different versions of OpenSSL just because
> they happened to be built at different times is not helpful, one version is
> enough.

So, only rawhide. I'm talking about packages with many dependencies,
not libgphoto and gphoto (no issues against these two packages, just
the first that cam to my mind with little dependencies).

For example ffmpeg or similar packages would require almost a third of
ATrpms' package to be rebuilt.

> > See for example the x264 libs. Any 3rd party repo using them is doomed
> > to be incompatible to the other one. Unless we would all use
> > libfoo<so> style packaging.
> 
> Or unless the smaller repositories (e.g. ATrpms) just accept one large
> repository (i.e. RPM Fusion) as the authority

Yes, the authority question again. Please accept that not everybody
weighs the repos the same way you do. As packagers of these repos we
are doomed to be biased, but I'm trying to keep hierarchies out of the
game, can't you?

> > In a nutshell: This is done for better compatibility, not worse.
> 
> I know this is the intention, but in practice it is rather unhelpful and
> counterproductive. IMHO you should follow the Fedora guidelines closer,
> even where you believe them to be technically inferior.

Either way the issue is about say conflicting libx264 packages, the
libfoo<somark> is not causing any harm otherwise, there needs to be an
overlap to begin with. And in a monolithic build you have no chance at
all, with libfoo<somark> you can use foo-rpmfusion (including
libfoo.so.1001) and libfoo1002-atrpms for different consumers.

Of course when some people read foo-rpmfusion conflicts with
libfoo1001-atrpms they assume that the latter is wrong due to the
non-conventional name. If I dropped this packaging style you would
just have foo-rpmfusion conflicting to foo-atrpms and the bug reports
would level again. Actually it would be in my favour, I guess ;)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/d4fb8d5f/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 13:40:27 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 15:40:27 +0200
Subject: sound problems
In-Reply-To: <gjvlgb$80i$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana> <gjvapj$5sf$1@ger.gmane.org>
	<20090106124549.GB15179@victor.dsathen.edu.gr>
	<gjvlgb$80i$1@ger.gmane.org>
Message-ID: <20090106134027.GB16190@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 02:14:50PM +0100, Kevin Kofler wrote:
> Axel Thimm wrote:
> > I don't want to rehash the discussion there, but I'm under the
> > impression that you don't know the history of it
> 
> Oh I do. That doesn't mean it wasn't a mistake. ;-) Nor that it's a good
> idea to continue on that path.
> 
> > and that you think this is just for personal pride or whatever.
> 
> ... yet ...
> 
> > FWIW rpmfusion is a 3rd party repo, very much like Dag, Dries,
> > PlanetCCRMA, CentOS Extras, KB, ATrpms etc. I'm not placing any
> > authority hierarchy upon any of these, and I'm expecting similar from
> > the other repo maintainers, of course.
> 
> Sense the contradiction there? You're expecting the RPM Fusion community
> which includes dozens of packagers to treat your 2-person repository as an
> equal and you claim it's not personal pride?
> 
> See, I maintain a small repository myself
> (http://repo.calcforge.org/fedora/ - mainly because those packages haven't
> been cleaned up for review in Fedora or RPM Fusion yet), but I would never
> expect that repository to be equivalent in importance to RPM Fusion.

Please stop placing hierarchies. The begining of rpmfusion was when
Ville asked me for livna and atrpms to merge at a time when livna had
lost almost all packagers.

The end result is a stronger livna renamed, but it stil shouldn't
allow anyone to become arrogant and place itself over others, pride or
non-pride.

And ATrpms is not just two packagers. Paulo is a excellent packager,
but there are others packaging other stuff, be that afs,
suspend/tuxonice, voip apps etc. All in all there are 16 people with
write access to the build server. Personally I doubt that rpmfusion is
any bigger than ATrpms in consumer space. I think both repos play in
the same league.

Anyway, this is not about mine-is-bigger-than-yours. Actually ATrpms
is known for trying to help small repos as well to level up to the
other ones. See for example the common bugzilla I had setup.

Please stop placing yourself above the others and dropping the burden
of compatibility on them. If you want comaptibility between 3rd party
repos, then please acknowledge that it is a two-way street.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/c4044e6f/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Jan  6 14:00:28 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 6 Jan 2009 16:00:28 +0200
Subject: sound problems
In-Reply-To: <496356CB.7020104@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<20090106090045.GC4061@victor.nirvana>
	<49633C32.6050805@fedoraproject.org>
	<20090106125420.GC15179@victor.dsathen.edu.gr>
	<496356CB.7020104@fedoraproject.org>
Message-ID: <20090106140028.GD16190@victor.dsathen.edu.gr>

On Tue, Jan 06, 2009 at 06:34:11PM +0530, Rahul Sundaram wrote:
> Axel Thimm wrote:
>
>> I've done that a lot of times and withdrawn a lot, these are not the
>> package to worry about. And if there is a package in ATrpms that's in
>> a higher version than in Fedora it will be for a reason, and if not
>> bugzilla me.
>
> No wild goose chases. I named specific examples

But I answered to all of them? I'm not after wild goose chases either,
and asking to periodically check whether Packager Joe Random decided to
import a package of mine w/o pinging me is just that.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/d9f6d31e/attachment.sig>

From debarshi.ray at gmail.com  Tue Jan  6 14:05:04 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 19:35:04 +0530
Subject: [bug 478331]: Attention libical users
Message-ID: <3170f42f0901060605p209e4352t5b37dd2dd0e5a4d2@mail.gmail.com>

I would like to draw the attention of those who are maintaining
packages depending on libical to a bug [1] that causes applications to
crash if invalid input is fed to libical. This includes Sunbird, KDE
PIM, Osmo, probably Evolution and maybe some more (no access to
repoquery for me now).

Cheers,
Debarshi

----
[1] https://bugzilla.redhat.com/478331 -  Insane libical defaults



From denis at poolshark.org  Tue Jan  6 14:11:34 2009
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 06 Jan 2009 15:11:34 +0100
Subject: sound problems
In-Reply-To: <gjvlgb$80i$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<20090106090045.GC4061@victor.nirvana>
	<gjvapj$5sf$1@ger.gmane.org>	<20090106124549.GB15179@victor.dsathen.edu.gr>
	<gjvlgb$80i$1@ger.gmane.org>
Message-ID: <49636696.5020703@poolshark.org>

Kevin Kofler wrote:
> Sense the contradiction there? You're expecting the RPM Fusion community
> which includes dozens of packagers to treat your 2-person repository as an
> equal and you claim it's not personal pride?

I think you've found the real problem here.

(my first and last post on this topic)
-denis



From fedora at matbooth.co.uk  Tue Jan  6 14:30:27 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 6 Jan 2009 14:30:27 +0000
Subject: Tracking new review requests?
In-Reply-To: <200901061431.53501.ville.skytta@iki.fi>
References: <200901061431.53501.ville.skytta@iki.fi>
Message-ID: <9497e9990901060630m52e07213nd36fcca115cf5fe8@mail.gmail.com>

On Tue, Jan 6, 2009 at 12:31 PM, Ville Skytt? <ville.skytta at iki.fi> wrote:
> Hello,
>
> I'd like to be notified about new Fedora package review requests by mail, only
> once.  I'm currently subscribed to fedora-package-review which is otherwise
> fine, except that I receive all of the review mail and not only the first
> mail sent when a new review request is submitted.
>
> I suppose I could set up a filter that gets the mails I'm not usually
> interested out of the way, but I'd rather not receive anything but the first
> one in the first place (unless I'm submitter/reviewer/cc'd of course, but
> that's handled by direct mails).
>
> Would it be possible to add a mailman topic to fedora-package-review that
> receives only new submissions?  I don't know how mailman topics are
> configured, but I suppose these can be detected by matching "New: " at the
> beginning of the subject.  Any other solutions?
>

Not sure how well this works, but maybe you could subscribe to the
search results page as a feed:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=Package%20Review&field-1-0-0=classification&field-1-1-0=product&field-1-2-0=component&field-1-3-0=bug_status&product=Fedora&query_format=advanced&remaction=&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type-1-3-0=anyexact&value-1-0-0=Fedora&value-1-1-0=Fedora&value-1-2-0=Package%20Review&value-1-3-0=NEW%2CASSIGNED&title=Bug%20List&ctype=atom


-- 
Mat Booth
www.matbooth.co.uk



From vonbrand at inf.utfsm.cl  Tue Jan  6 14:33:57 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 11:33:57 -0300
Subject: Package naming conflicts (was: Re: sound problems)
In-Reply-To: <20090106141135.05670460.mschwendt@gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<20090106141135.05670460.mschwendt@gmail.com>
Message-ID: <200901061433.n06EXvpI025741@laptop14.inf.utfsm.cl>

Michael Schwendt <mschwendt at gmail.com> wrote:
> On Tue, 6 Jan 2009 14:32:40 +0200, Axel wrote:
> > On Tue, Jan 06, 2009 at 11:24:07AM +0100, Kevin Kofler wrote:
> > > Axel Thimm wrote:

> > > > Incompatible to what? If there are conflicts between ATrpms' packages
> > > > and others from the N thousand official packages, please report
> > > > them and we'll fix them.

> > > One concrete source of incompatibility is that you use Debian-style
> > > versioning (e.g. libquicktime0) for some library packages, which is
> > > against Fedora guidelines (in fact, IIRC a guideline change you
> > > proposed to that effect was rejected) and which can confuse yum in
> > > some cases.

> > I think it was rather forgotten and withdrawn, but that's rejected
> > nonetheless.

> > The reson I use these conventions is because they actually increase
> > compatibility: When repo X, repo Y and repo Z (one of them may be
> > Fedora, the others two 3rd party ones) have built foo, baz and wuz
> > against libbar.so.1, libbar.so.2 and libbar.so.3 these runtime
> > packages make sure that they can all coexist w/o one repo enforcing a
> > full rebuild on the other.

But using one convention here and a different one there /creates/
confusion.

> Without proper Obsoletes/Provides in both directions (i.e. Fedora <-> 3rd
> party repo), it doesn't work flawlessly. libbar3-3.0.1 will conflict
> with libbar-3.0.2. AFAIK, this has happened several times before.
> Additionally, you need to take precautions and relocate files in
> several packages for them to become parallel-installable.

Right. And that is a distribution-wide decision.  BTW, I do agree with the
Fedora folks here: Making sure everything works with /one/ set of libraries
(or other assorted packages) is hard enough as it is. It means there is
system-wide breakage if something like Python is updated, sure. But that
can be inflicted upon rawhide users, and the result of shaking out the bugs
shows up at most some 6 months later. It is not that regular users have to
wait for untold years until random updates are in mainstream Fedora.

> > This will even help Fedora, as the reason Debian/Mandriva introduced
> > them was for being able to cope with tons of packages when a
> > dependency does an sobump.

> Without a doubt. If done properly, it would fix the poor broken deps
> caused by sudden/unexpected soname bumps.

No, it doesn't. It just forces carrying outdated junk around forever, stuff
that needs the same care as new packages (and tending for old code is more
work, and unexciting work at that). Better do a clean cut with the past; if
some dependencies can't be updated for now, so be it. yum is currently able
to handle this scenario just fine.

> > Currently in Fedora whenever a package with many dependent other
> > packages changes soname, we need to go yelling around to other
> > packagers and are only able to do an upgrade of this kind in rawhide.

So?

> This is also due to koji buildroot protection and overrides.
> Some packagers believe they must push a soname bump to stable before
> they can rebuild dependencies. They feel embarrassed when they learn
> that they can request releng to set an override-tag and then prepare
> a group update for bodhi. Features and procedures are not known enough
> and are hard to find in the Wiki.

Suggest updated guidelines then.
-- 
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 ajax at redhat.com  Tue Jan  6 14:38:55 2009
From: ajax at redhat.com (Adam Jackson)
Date: Tue, 06 Jan 2009 09:38:55 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <20090105233853.48E9CFC299@magilla.sf.frob.com>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
Message-ID: <1231252735.28012.3.camel@atropine.boston.devel.redhat.com>

On Mon, 2009-01-05 at 15:38 -0800, Roland McGrath wrote:
> http://roland.fedorapeople.org/tmp/rawhide-debuginfo-missing-dwarf.bz2
> 
> This is a big list (small file) of all the ELF files in rawhide debuginfo
> rpms that have no DWARF information.  Each line looks like e.g.:
> 
> zenon-debuginfo-0.5.0-3.fc10.i386:usr:lib:debug:usr:bin:zenon.debug
> 
> meaning that in zenon-debuginfo-0.5.0-3.fc10.i386 the file
> /usr/lib/debug/usr/bin/zenon.debug exists and is an ELF file,
> but has no DWARF in it.
> 
> I have not looked at any of the cases.  An industrious volunteer could
> collate all these along with the "missing" cases from the summary, filter
> out superceded rpms, and categorize the cases.

As a first pass, here's the list of packages mentioned.  Only 139, which
isn't that bad all things considered.

abiword
allegro
ann
apt
ardour
astromenace
atlas
ax25-apps
b43-fwcutter
bacula
balance
blitz
byaccj
cairo-java
claws-mail-plugins
colrdx
compat-gcc-296
corrida
crossvc
csound
csstidy
cups
curry
ddrescue
denemo
eclipse
elftoaout
email2trac
erlang
esc
fish
fpc
freeipmi
freenx-server
frysk
gammu
gcc
giflib
gle
glib-java
gmpc
GMT
gmyth
gnumeric
gpart
gperiodic
grass
groff
grub2
gtk2
GtkAda
gutenprint
hevea
homestead
i8kutils
icu
java-1.6.0-openjdk
kdelibs3
kernel
kernel-PAE
kita
kmid
LabPlot
lam
lazarus
libAfterImage
libflaim
libgconf-java
libglade-java
libgnome-java
libgtk-java
libhocr
libsvm
libtrash
libvte-java
libxcb
licq
ltsp
mediawiki
Miro
mod_auth_shadow
mod_security
moe
mono
mono-debugger
mtd-utils
nekovm
nessus-core
nightfall
nled
nvclock
nx
olpc-utils
OpenIPMI
openmpi
openoffice.org
openvpn
osmo
perl-PDL
phasex
pinot
planets
plt-scheme
postgresql-odbcng
psad
pvm
qps
qt3
quassel
rhm
ricci
rpc2
samba
ScientificPython
sectool
ser
shed
simdock
skychart
splat
star
taginfo
TeXmacs
tomoe-gtk
transfig
tuxcmd
uuid
vodovod
wesnoth
wgrib2
why
wings
wmx
wormux
WritRecogn
yap
zaptel
zenon
zynaddsubfx

- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/2def0244/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Jan  6 14:36:17 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 11:36:17 -0300
Subject: security update for xterm needed
In-Reply-To: <1231246190.7606.4.camel@choeger5.umpa.netz>
References: <1231246190.7606.4.camel@choeger5.umpa.netz>
Message-ID: <200901061436.n06EaHAr029381@laptop14.inf.utfsm.cl>

Christoph H??ger <choeger at cs.tu-berlin.de> wrote:
> I will file a bug becasue of this, but you should be sure to update
> xterm asap, if you use it:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030
> 
> I testet on fedora 10 accordign to
> http://www.heise.de/newsticker/Terminal-Emulator-xterm-fuehrt-untergeschobene-Befehle-aus--/meldung/121196
> (sorry, german)
> 
> I tried:
> 
> [choeger at choeger5 ~]$ perl -e 'print "\eP\$q\nwhoami\n\e\\"' > bla.log
> 
> and in xterm:
> 
> [choeger at choeger5 ~]$ cat bla.log 
> ^[P0$r
> 
> whoami
> 
> ^[\[choeger at choeger5 ~]$ 
> [choeger at choeger5 ~]$ whoami
> choeger
> [choeger at choeger5 ~]$ 
> [choeger at choeger5 ~]$ 
> 
> As you can see, its valid.

This is bog-standard VT100 behaviour, AFAIKS.
-- 
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 mclasen at redhat.com  Tue Jan  6 14:41:24 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Jan 2009 09:41:24 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
	<1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
Message-ID: <1231252884.3519.1.camel@localhost.localdomain>

On Tue, 2009-01-06 at 09:38 -0500, Adam Jackson wrote:

> As a first pass, here's the list of packages mentioned.  Only 139, which
> isn't that bad all things considered.

[...]

> gtk2

The one file mentioned in the gtk2 package is a fake elf file that gets
put into an otherwise empty directory to work around deficiencies in
rpms directory handling, so thats not a concern.



From stickster at gmail.com  Mon Jan  5 12:57:25 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 5 Jan 2009 07:57:25 -0500
Subject: Fedora 11 release name voting open
Message-ID: <20090105125703.GA22179@localhost.localdomain>

Voting is now opened for the Fedora 11 release name.  There are eight
names on the ballot from which to choose.  To cast your vote, point
your web browser to this URL:

https://admin.fedoraproject.org/voting/about/relnamef11

Log in with your Fedora Account name and password.  As long as you
have signed the CLA and belong to one additional group in the Fedora
Account System, you can cast your vote.

Voting will end and be tallied at 23:59:59 January 9, 2009 UTC.

Background information on the release naming process is available here
on the wiki:

https://fedoraproject.org/wiki/Name_suggestions_for_Fedora_11
https://fedoraproject.org/wiki/Guidelines_for_release_names

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/cfa048ef/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From stickster at gmail.com  Tue Jan  6 02:18:30 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Mon, 5 Jan 2009 21:18:30 -0500
Subject: Reminder: Fedora Board IRC meeting 1900 UTC 2009-01-06
Message-ID: <20090106021830.GE21964@localhost.localdomain>

The Board is holding its monthly public meeting on Tuesday, 6 January
2009, at 1900 UTC on IRC Freenode.  The Board has settled on a
schedule that puts these public IRC meetings on the first Tuesday of
each month.  Therefore, the next following public meeting will be on 3
February 2009.  For these meetings, the public is invited to do the
following:

* Join #fedora-board-meeting to see the Board's conversation.  This
  channel is read-only for non-Board members.

* Join #fedora-board-public to discuss topics and post questions. This
  channel is read/write for everyone.

The moderator will direct questions from the #fedora-board-public
channel to the Board members at #fedora-board-meeting.  This should
limit confusion and ensure our logs are useful to everyone.

We look forward to seeing you at the meeting.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090105/ddf02ba4/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From mlichvar at redhat.com  Tue Jan  6 14:47:51 2009
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Tue, 6 Jan 2009 15:47:51 +0100
Subject: security update for xterm needed
In-Reply-To: <1231246190.7606.4.camel@choeger5.umpa.netz>
References: <1231246190.7606.4.camel@choeger5.umpa.netz>
Message-ID: <20090106144751.GA6207@localhost>

On Tue, Jan 06, 2009 at 01:49:50PM +0100, Christoph H?ger wrote:
> Hi folks,
> 
> I will file a bug becasue of this, but you should be sure to update
> xterm asap, if you use it:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510030

Security updates created:
https://admin.fedoraproject.org/updates/xterm-238-1.fc8
https://admin.fedoraproject.org/updates/xterm-238-1.fc9
https://admin.fedoraproject.org/updates/xterm-238-1.fc10

-- 
Miroslav Lichvar



From jkeating at redhat.com  Tue Jan  6 14:52:58 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 09:52:58 -0500
Subject: sound problems
In-Reply-To: <604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<49623433.9020800@fedoraproject.org>
	<d9c612bf0901051340r590ffc9enf840f0077e8ae0cb@mail.gmail.com>
	<4962879A.9020603@fedoraproject.org>
	<d9c612bf0901051830p4304f8feybdeb1c05231bbe36@mail.gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
Message-ID: <1231253578.4036.3.camel@localhost.localdomain>

On Mon, 2009-01-05 at 18:04 -0900, Jeff Spaleta wrote:
> I can't let this stand.  This public character assassination
> absolutely must stop.  As an outgoing Board member I am appalled by
> this sort of deliberate attempt to go out of your way to besmirk a
> fellow contributor's direct contributions to this project.

I have to agree with Jeff here.  Axel and I don't always agree, but he
has been a valued contributor to the project both in packages but also
in the packaging committee helping us to define good packaging practice.

Your (Conrad) behavior on this list is completely unacceptable.  Find
somewhere else (like your own room) to grind your axe.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/4fc80cb2/attachment.sig>

From tibbs at math.uh.edu  Tue Jan  6 15:11:31 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 06 Jan 2009 09:11:31 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <1231188376.17459.0.camel@arekh.okg>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
Message-ID: <ufaljtopizg.fsf@epithumia.math.uh.edu>

>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:

NM> Which is why a bot like ReviewOMatic would be better suited for
NM> this kind of continuous testing than human reviewers

As if a bot can actually review anything.

Look, it isn't hard to make sure things build and to run rpmlint.  We
already have other automated checks, like Kevin's source URL checks.
The problem is that the terribly named "ReviewOMatic" can't actually
automatically review anything; a human is still required.  rpmlint
output specifically is useless without piles of human interpretation.

Surely you don't want to be automatically mailbombed with the rpmlint
output from all of your packages.  That would only lead to bogus
changes just to shut up equally bogus complaints, or some random
syntax in comments within a specfile indicating what rpmlint
complaints are expected.  Does anyone actually want that?

 - J<



From j.w.r.degoede at hhs.nl  Tue Jan  6 15:06:17 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Tue, 06 Jan 2009 16:06:17 +0100
Subject: xzgv in Fedora broken? (was: Re: sound problems)
In-Reply-To: <49633EA3.6030207@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
Message-ID: <49637369.1010302@hhs.nl>

On Tue, 06 Jan 2009 16:51:07 +0530, Rahul wrote:

> Paulo Cavalcanti wrote:
> 
> > Rahul,
> > 
> > if my memory is not failing, some packages appeared first in ATrpms
> > than if Fedora (livna/rpmfusion): xvidcap, xzgv, xv, etc. I am not 
> > discussing
> > if these packages are useful or not. The fedora version of xzgv was 
> > never able
> > to display the thumbnails correctly, for instance. Why? Because it has 
> > to be compiled with
> > gcc3.
> 
> Was there a bug report filed on this? Again, when problems are in a 
> repository, working together to fix the problem is more of a benefit, 
> compared to have alternative fixed versions in a place, where majority 
> of end users won't benefit from it. If maintainers don't have time, 
> step-in and become co-maintainers and fix the problems instead.

Note I'm looking in to fixing the xzgv thumbnails issue. Why? To show that 
actually reporting problems helps I guess.

Regards,

Hans



From debarshi.ray at gmail.com  Tue Jan  6 15:20:05 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 20:50:05 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaljtopizg.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>

> Look, it isn't hard to make sure things build and to run rpmlint.  We
> already have other automated checks, like Kevin's source URL checks.

The plan is to pull all such "other automated checks" in place.

> The problem is that the terribly named "ReviewOMatic" can't actually
> automatically review anything; a human is still required.

What is in a name? It can be changed.

Cheers,
Debarshi



From mschwendt at gmail.com  Tue Jan  6 15:19:57 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 6 Jan 2009 16:19:57 +0100
Subject: Package naming conflicts (was: Re: sound problems)
In-Reply-To: <200901061433.n06EXvpI025741@laptop14.inf.utfsm.cl>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<20090106141135.05670460.mschwendt@gmail.com>
	<200901061433.n06EXvpI025741@laptop14.inf.utfsm.cl>
Message-ID: <20090106161957.865c7e47.mschwendt@gmail.com>

Could you please reply only to the list instead of sending a copy
via Cc?

On Tue, 06 Jan 2009 11:33:57 -0300, Horst wrote:

> > > This will even help Fedora, as the reason Debian/Mandriva introduced
> > > them was for being able to cope with tons of packages when a
> > > dependency does an sobump.
> 
> > Without a doubt. If done properly, it would fix the poor broken deps
> > caused by sudden/unexpected soname bumps.
> 
> No, it doesn't. It just forces carrying outdated junk around forever,

It doesn't do that. It's similar to our compat-* packages. Once all
dependencies build'n'work fine with the latest library, the old
parallel installable releases can be obsoleted (= removed).

On the contrary, an ABI/API-incompatible library upgrade in the middle
of a stable Fedora release forces packagers (and upstream maintainers)
to spend extra time on [often unnecessary] maintenance tasks just to
move closer to the bleeding edge.

> stuff
> that needs the same care as new packages (and tending for old code is more
> work, and unexciting work at that). Better do a clean cut with the past;

This can be done prior to the next release of Fedora. This is what
Rawhide is for.

> if
> some dependencies can't be updated for now, so be it. yum is currently able
> to handle this scenario just fine.

So? Here, by default, it runs into a fatal error condition and throws
an error message, which confuses many (many!) users. And --skip-broken
(even if enabled by default) is no cure either.



From sundaram at fedoraproject.org  Tue Jan  6 15:21:40 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 20:51:40 +0530
Subject: sound problems
In-Reply-To: <20090106140028.GD16190@victor.dsathen.edu.gr>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<20090106090045.GC4061@victor.nirvana>	<49633C32.6050805@fedoraproject.org>	<20090106125420.GC15179@victor.dsathen.edu.gr>	<496356CB.7020104@fedoraproject.org>
	<20090106140028.GD16190@victor.dsathen.edu.gr>
Message-ID: <49637704.8000901@fedoraproject.org>

Axel Thimm wrote:
> On Tue, Jan 06, 2009 at 06:34:11PM +0530, Rahul Sundaram wrote:
>> Axel Thimm wrote:
>>
>>> I've done that a lot of times and withdrawn a lot, these are not the
>>> package to worry about. And if there is a package in ATrpms that's in
>>> a higher version than in Fedora it will be for a reason, and if not
>>> bugzilla me.
>> No wild goose chases. I named specific examples
> 
> But I answered to all of them? 

I don't think so. You went on to talk about history and which package 
came first which is rather unimportant to end users. A simple question. 
Why is say dovecot, asterisk, ocaml, pdfmerge and mutt in your repo still?

Rahul



From rakesh.pandit at gmail.com  Tue Jan  6 15:23:00 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 6 Jan 2009 20:53:00 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
Message-ID: <b401d2530901060723n33157702s3d4a64b93df999e3@mail.gmail.com>

2009/1/6 Debarshi Ray <debarshi.ray at gmail.com>:
>> Look, it isn't hard to make sure things build and to run rpmlint.  We
>> already have other automated checks, like Kevin's source URL checks.
>
> The plan is to pull all such "other automated checks" in place.
>

And add as many as *possible* or doable.

-- 
rakesh



From debarshi.ray at gmail.com  Tue Jan  6 15:17:11 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Tue, 6 Jan 2009 20:47:11 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaljtopizg.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901060717x476f843br7642547319451492@mail.gmail.com>

> Surely you don't want to be automatically mailbombed with the rpmlint
> output from all of your packages.  That would only lead to bogus
> changes just to shut up equally bogus complaints, or some random
> syntax in comments within a specfile indicating what rpmlint
> complaints are expected.  Does anyone actually want that?

Quite true, but I was suprised to see what 'rpmlint
gstreamer-plugins-base' gave me recently. :-)

Cheers,
Debarshi



From sundaram at fedoraproject.org  Tue Jan  6 15:23:36 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 06 Jan 2009 20:53:36 +0530
Subject: xzgv in Fedora broken?
In-Reply-To: <49637369.1010302@hhs.nl>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
	<49637369.1010302@hhs.nl>
Message-ID: <49637778.3@fedoraproject.org>

Hans de Goede wrote:

> Note I'm looking in to fixing the xzgv thumbnails issue. Why? To show 
> that actually reporting problems helps I guess.

Thanks Hans. It is amazing, people who knew about the issue would be not 
reporting the bug but be willing to build conflicting packages in 
another repository.

Rahul



From jkeating at redhat.com  Tue Jan  6 15:31:07 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 10:31:07 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <1231252884.3519.1.camel@localhost.localdomain>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
	<1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
	<1231252884.3519.1.camel@localhost.localdomain>
Message-ID: <1231255867.4036.4.camel@localhost.localdomain>

On Tue, 2009-01-06 at 09:41 -0500, Matthias Clasen wrote:
> The one file mentioned in the gtk2 package is a fake elf file that gets
> put into an otherwise empty directory to work around deficiencies in
> rpms directory handling, so thats not a concern.

Are those current deficiencies with the current rpm?  What is the
problem exactly?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/c5bd2e10/attachment.sig>

From rakesh.pandit at gmail.com  Tue Jan  6 15:32:31 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 6 Jan 2009 21:02:31 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaljtopizg.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
Message-ID: <b401d2530901060732o84df0f7hb2e3df04beeede4e@mail.gmail.com>

2009/1/6 Jason L Tibbitts III <tibbs at math.uh.edu>:
>>>>>> "NM" == Nicolas Mailhot <nicolas.mailhot at laposte.net> writes:
[..]
>
> Surely you don't want to be automatically mailbombed with the rpmlint
> output from all of your packages.  That would only lead to bogus
> changes just to shut up equally bogus complaints, or some random
> syntax in comments within a specfile indicating what rpmlint
> complaints are expected.  Does anyone actually want that?
>


Most of I guess wants rpmlint output(my assumption). What they decide
based on that output is upto them.

It is not in plans to replace reviewer or even rpmlint or change the
workflow. Decision will always be with reviewer. And reviewer will
decide what is bogus or not.

-- 
rakesh



From mclasen at redhat.com  Tue Jan  6 15:50:28 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 06 Jan 2009 10:50:28 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <1231255867.4036.4.camel@localhost.localdomain>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
	<1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
	<1231252884.3519.1.camel@localhost.localdomain>
	<1231255867.4036.4.camel@localhost.localdomain>
Message-ID: <1231257028.3519.15.camel@localhost.localdomain>

On Tue, 2009-01-06 at 10:31 -0500, Jesse Keating wrote:
> On Tue, 2009-01-06 at 09:41 -0500, Matthias Clasen wrote:
> > The one file mentioned in the gtk2 package is a fake elf file that gets
> > put into an otherwise empty directory to work around deficiencies in
> > rpms directory handling, so thats not a concern.
> 
> Are those current deficiencies with the current rpm?  What is the
> problem exactly?

>From the spec:

# create a dummy binary for /usr/lib/gtk-2.0/immodules to work around
# problems in our ia64 multilib infrastructure
# See https://bugzilla.redhat.com/show_bug.cgi?id=253726 for more
details
echo 'int main (void) { return 0; }' > relocation-tag.c
gcc -Os relocation-tag.c -o relocation-tag


So not very relevant for Fedora.
Lets just hope that ia64 multilib dies a well-deserved death,
sometime...



From jkeating at redhat.com  Tue Jan  6 16:00:56 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 11:00:56 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <1231257028.3519.15.camel@localhost.localdomain>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
	<1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
	<1231252884.3519.1.camel@localhost.localdomain>
	<1231255867.4036.4.camel@localhost.localdomain>
	<1231257028.3519.15.camel@localhost.localdomain>
Message-ID: <1231257656.4036.10.camel@localhost.localdomain>

On Tue, 2009-01-06 at 10:50 -0500, Matthias Clasen wrote:
> On Tue, 2009-01-06 at 10:31 -0500, Jesse Keating wrote:
> > On Tue, 2009-01-06 at 09:41 -0500, Matthias Clasen wrote:
> > > The one file mentioned in the gtk2 package is a fake elf file that gets
> > > put into an otherwise empty directory to work around deficiencies in
> > > rpms directory handling, so thats not a concern.
> > 
> > Are those current deficiencies with the current rpm?  What is the
> > problem exactly?
> 
> >From the spec:
> 
> # create a dummy binary for /usr/lib/gtk-2.0/immodules to work around
> # problems in our ia64 multilib infrastructure
> # See https://bugzilla.redhat.com/show_bug.cgi?id=253726 for more
> details
> echo 'int main (void) { return 0; }' > relocation-tag.c
> gcc -Os relocation-tag.c -o relocation-tag
> 
> 
> So not very relevant for Fedora.
> Lets just hope that ia64 multilib dies a well-deserved death,
> sometime...

ia64 multilib is dead, it's dead in upstream and our rpm, so this can go
away.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/0b600f75/attachment.sig>

From cra at WPI.EDU  Tue Jan  6 16:03:22 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Tue, 6 Jan 2009 11:03:22 -0500
Subject: debuginfo audit: missing DWARF
In-Reply-To: <1231257028.3519.15.camel@localhost.localdomain>
References: <20090105233853.48E9CFC299@magilla.sf.frob.com>
	<1231252735.28012.3.camel@atropine.boston.devel.redhat.com>
	<1231252884.3519.1.camel@localhost.localdomain>
	<1231255867.4036.4.camel@localhost.localdomain>
	<1231257028.3519.15.camel@localhost.localdomain>
Message-ID: <20090106160322.GA12183@angus.ind.WPI.EDU>

On Tue, Jan 06, 2009 at 10:50:28AM -0500, Matthias Clasen wrote:
> On Tue, 2009-01-06 at 10:31 -0500, Jesse Keating wrote:
> > On Tue, 2009-01-06 at 09:41 -0500, Matthias Clasen wrote:
> > > The one file mentioned in the gtk2 package is a fake elf file that gets
> > > put into an otherwise empty directory to work around deficiencies in
> > > rpms directory handling, so thats not a concern.
> > 
> > Are those current deficiencies with the current rpm?  What is the
> > problem exactly?
> 
> >From the spec:
> 
> # create a dummy binary for /usr/lib/gtk-2.0/immodules to work around
> # problems in our ia64 multilib infrastructure
> # See https://bugzilla.redhat.com/show_bug.cgi?id=253726 for more

You are not authorized to access bug #253726. 



From ndbecker2 at gmail.com  Tue Jan  6 16:05:23 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 06 Jan 2009 11:05:23 -0500
Subject: desktop-file-install question
Message-ID: <gjvvg4$ceo$1@ger.gmane.org>

What should be done with a kde4 app that already installs desktop files in the correct location?

e.g.:
-- Installing: /home/nbecker/RPM/BUILDROOT/kdiff3-0.9.93-1.fc11.x86_64/usr/share/kde4/services/kdiff3part.desktop

I understand desktop-file-install must be run, but with what args?



From musuruan at gmail.com  Tue Jan  6 16:38:44 2009
From: musuruan at gmail.com (Andrea Musuruane)
Date: Tue, 6 Jan 2009 17:38:44 +0100
Subject: desktop-file-install question
In-Reply-To: <gjvvg4$ceo$1@ger.gmane.org>
References: <gjvvg4$ceo$1@ger.gmane.org>
Message-ID: <29fee02b0901060838o57310995td102962ee583394@mail.gmail.com>

On Tue, Jan 6, 2009 at 5:05 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> What should be done with a kde4 app that already installs desktop files in the correct location?
>
> e.g.:
> -- Installing: /home/nbecker/RPM/BUILDROOT/kdiff3-0.9.93-1.fc11.x86_64/usr/share/kde4/services/kdiff3part.desktop
>
> I understand desktop-file-install must be run, but with what args?

You may use desktop-file-validate:
https://fedoraproject.org/wiki/TomCallaway/DesktopFileVendor

Bye,

Andrea.



From fedora at camperquake.de  Tue Jan  6 16:54:35 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 6 Jan 2009 17:54:35 +0100
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <495B0362.6030906@gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com> <495884BC.7040800@redhat.com>
	<49588D9D.5020303@gmail.com> <495A18D5.3030602@nobugconsulting.ro>
	<495B0362.6030906@gmail.com>
Message-ID: <20090106175435.0d441942@dhcp03.addix.net>

Hi.

On Wed, 31 Dec 2008 00:30:10 -0500, Lyos Gemini Norezel wrote:

> Most laptops (ie., Win$hit boxen) don't need a /boot or even a swap 
> partition.

Right. Instead you get a bootloader which encodes some magic values in the
first sectors of the hard drive which fails spectacularily once the
underlying disk geometry changes just a little bit.

I spent a handful of minutes last week moving a Fedora from one machine
into a quite different one (dd-copying the hard disks over), and
the system booted immediately.

I then spent one and a half days getting a Windows 2000 image (from
a running system) to work under qemu, because qemu assumed a slightly
different disk geometry and the windows bootloader exploded.

I'll take the boot partition.



From tibbs at math.uh.edu  Tue Jan  6 17:16:13 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 06 Jan 2009 11:16:13 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
Message-ID: <ufa7i58pd7m.fsf@epithumia.math.uh.edu>

>>>>> "DR" == Debarshi Ray <debarshi.ray at gmail.com> writes:

DR> The plan is to pull all such "other automated checks" in place.

Certainly, that's a good idea; I don't know how it works out
in practise, but that's no reason not to try.  However, my point was
that the mere existence of this software won't magically eliminate the
need for humans to do package reviews, and we're still not going to be
able to do significant numbers of package re-reviews given our current
manpower and the current rate of new package submissions unless the
community attitude towards the acceptable ratio of submissions to
reviews changes (or we magically acquire significant additional
manpower).

>> The problem is that the terribly named "ReviewOMatic" can't
>> actually automatically review anything; a human is still required.

DR> What is in a name? It can be changed.

Well, I wasn't exactly silent about my objection when the project was
first proposed and I was ignored then.  I still wish that the name
didn't somehow imply that the software actually reviews anything
(because it doesn't); I've spent a lot of time actually reviewing
packages and find the implication that software can do it instead to
be more than a bit presumptive.  But in any case it's just a name, and
while it will continue to annoy me I'm not going to do anything
foolish such as demand that it be changed.

 - J<



From jspaleta at gmail.com  Tue Jan  6 17:32:50 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 08:32:50 -0900
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufa7i58pd7m.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
	<ufa7i58pd7m.fsf@epithumia.math.uh.edu>
Message-ID: <604aa7910901060932y7e700e80o8043b2a5884be85@mail.gmail.com>

On Tue, Jan 6, 2009 at 8:16 AM, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
> DR> What is in a name? It can be changed.
>
> Well, I wasn't exactly silent about my objection when the project was
> first proposed and I was ignored then.  I still wish that the name
> didn't somehow imply that the software actually reviews anything
> (because it doesn't); I've spent a lot of time actually reviewing
> packages and find the implication that software can do it instead to
> be more than a bit presumptive.  But in any case it's just a name, and
> while it will continue to annoy me I'm not going to do anything
> foolish such as demand that it be changed.

Automated Review Clerk?
Like a law clerk in a law office doing filing and research tasks
preparing documents and what not.

Automated Review Assistant? Like a dental assistant...does routine
packaging..cleaning/maiming.


-jef"Automated Review and Submission Examiner (ARSE)"spaleta



From mw_triad at users.sourceforge.net  Tue Jan  6 17:33:57 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 06 Jan 2009 11:33:57 -0600
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
Message-ID: <gk04m5$1qt$1@ger.gmane.org>

Ricardo Arg?ello wrote:
> Why was the improve-relatime.patch dropped from F10's kernel? F9 had
> relatime on by default using this patch.
> I first thought the upstream kernel had the patch now, but
> /proc/mounts does not show relatime in F10.
> 
> I found this bug, looks related:
> 
>   mkinitrd can't deal with the "relatime" mount option
>   https://bugzilla.redhat.com/show_bug.cgi?id=430280

Speaking of, this looks to be... how old? Any chance of getting it 
fixed? (Especially with SSD's becoming more popular, for which it makes 
particular sense to request relatime?)

I mean... if you don't know about this bug and add relatime to fstab, 
you've just made it impossible to upgrade the kernel. And the 
work-around (edit fstab to remove relatime, 'yum update kernel', edit 
fstab to put back relatime) isn't very friendly.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ethics? We've heard of it" -- Microsoft



From rjones at redhat.com  Tue Jan  6 17:40:07 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 6 Jan 2009 17:40:07 +0000
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <49588231.2070800@gmail.com>
References: <494930CD.70709@herr-schmitt.de>
	<7f692fec0812171239k2d7fe6a3w4b3e69da2f21c045@mail.gmail.com>
	<49588231.2070800@gmail.com>
Message-ID: <20090106174007.GA21573@amd.home.annexia.org>

On Mon, Dec 29, 2008 at 02:54:25AM -0500, Lyos Gemini Norezel wrote:
> Maybe my use case is odd... but my /boot partition is a *MINIMUM* of 5GB  
> on all of my computers.

Even on your virtual machines?

The presence of virtualization changes all these assumptions.  I now
WANT my operating system to run in 32 MB of RAM[*] with 128 MB of swap
and a 4 GB disk, because I want to run dozens of copies.

Rich.

[*] Numbers not chosen at random - I have Debian VMs running in 32 MB
of RAM just fine.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From vonbrand at inf.utfsm.cl  Tue Jan  6 17:56:13 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 06 Jan 2009 14:56:13 -0300
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <604aa7910901060932y7e700e80o8043b2a5884be85@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
	<ufa7i58pd7m.fsf@epithumia.math.uh.edu>
	<604aa7910901060932y7e700e80o8043b2a5884be85@mail.gmail.com>
Message-ID: <200901061756.n06HuDMa032670@laptop14.inf.utfsm.cl>

Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 8:16 AM, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
> > DR> What is in a name? It can be changed.

[...]

> Automated Review Assistant? Like a dental assistant...does routine
> packaging..cleaning/maiming.

I like this one.
-- 
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 seg at haxxed.com  Tue Jan  6 18:07:47 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 06 Jan 2009 12:07:47 -0600
Subject: [bug 478331]: Attention libical users
In-Reply-To: <3170f42f0901060605p209e4352t5b37dd2dd0e5a4d2@mail.gmail.com>
References: <3170f42f0901060605p209e4352t5b37dd2dd0e5a4d2@mail.gmail.com>
Message-ID: <1231265267.5754.7.camel@localhost.localdomain>

On Tue, 2009-01-06 at 19:35 +0530, Debarshi Ray wrote:
> I would like to draw the attention of those who are maintaining
> packages depending on libical to a bug [1] that causes applications to
> crash if invalid input is fed to libical. This includes Sunbird, KDE
> PIM, Osmo, probably Evolution and maybe some more (no access to
> repoquery for me now).

That sounds like the definition of denial of service vulnerability. I
put further comments on the bug. :)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/3acadab3/attachment.sig>

From bpepple at fedoraproject.org  Tue Jan  6 18:13:31 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Tue, 06 Jan 2009 13:13:31 -0500
Subject: Plan for tomorrows (20090107) FESCO meeting
Message-ID: <1231265611.20019.5.camel@localhost.localdomain>

Hi,

Please find below the list of topics that are likely to come up in the
next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00
UTC (13:00 EST) in #fedora-meeting on irc.freenode.org:

/topic FESCo-Meeting -- Elect new FESCo chair (Thunderdome Edition) -
all

/topic FESCo-Meeting -- New FESCo meeting time (Friday's @ ?) - all

/topic FESCo-Meeting -- Adding provenpackagers to experienced maintainer
definition -
http://www.redhat.com/archives/fedora-devel-list/2008-December/msg02338.html - nirik

/topic FESCo-Meeting --
https://fedoraproject.org/wiki/PackagingDrafts/RenamingPackages - nirik

/topic FESCO-Meeting -- Features --
https://fedoraproject.org/wiki/Features/KDE42

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 <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/f3c59fe8/attachment.sig>

From kevin.kofler at chello.at  Tue Jan  6 18:37:37 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 19:37:37 +0100
Subject: xzgv in Fedora broken?
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
	<49637369.1010302@hhs.nl> <49637778.3@fedoraproject.org>
Message-ID: <gk08dh$dtg$1@ger.gmane.org>

Rahul Sundaram wrote:
> Thanks Hans. It is amazing, people who knew about the issue would be not
> reporting the bug but be willing to build conflicting packages in
> another repository.

Not to mention the "fix" only papers around the real issue (by building the
package with an old compiler).

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan  6 18:42:54 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 19:42:54 +0100
Subject: Moving xine to Fedora (Was: Re: sound problems)
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<gjvg74$me4$1@ger.gmane.org> <496346F2.3010001@leemhuis.info>
	<3170f42f0901060538i394b90e1l35275e8b59696a60@mail.gmail.com>
Message-ID: <gk08ne$dtg$2@ger.gmane.org>

Debarshi Ray wrote:
> Isn't the Fedora xine-lib packager (CC'ed) interested?

There's more than one, but AFAIK we're all coming from the KDE camp, so we
aren't all that interested in the X11-only xine with its nonstandard UI. I
use Kaffeine (video) and Amarok (audio) as my xine-lib frontends.

        Kevin Kofler



From gauret at free.fr  Tue Jan  6 18:51:21 2009
From: gauret at free.fr (Aurelien Bompard)
Date: Tue, 6 Jan 2009 19:51:21 +0100
Subject: Moving xine to Fedora (Was: Re: sound problems)
In-Reply-To: <3170f42f0901060538i394b90e1l35275e8b59696a60@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com> <496346F2.3010001@leemhuis.info>
	<3170f42f0901060538i394b90e1l35275e8b59696a60@mail.gmail.com>
Message-ID: <200901061951.21721.gauret@free.fr>

> > Does anybody have a few spare cycles and is willig to submitt xine to
> > Fedora?
>
> Isn't the Fedora xine-lib packager (CC'ed) interested?

Sorry, no. I don't use xine, and I already maintain too many packages I 
don't use regularly.

Aur?lien
-- 
http://aurelien.bompard.org  ~~~~  Jabber : abompard at jabber.fr
"You do not really understand something unless you can
explain it to your grandmother." -- Albert Einstein

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/dd52c205/attachment.htm>

From ricardo at fedoraproject.org  Tue Jan  6 18:53:21 2009
From: ricardo at fedoraproject.org (=?UTF-8?Q?Ricardo_Arg=C3=BCello?=)
Date: Tue, 6 Jan 2009 13:53:21 -0500
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <gk04m5$1qt$1@ger.gmane.org>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
	<gk04m5$1qt$1@ger.gmane.org>
Message-ID: <500f0ca00901061053k757667c4r282ff7ae74658c7d@mail.gmail.com>

Should I report the dropped improve-relatime.patch as a bug? The
mkinitrd is a whole different thing.

What I wanted was the improve-relatime.patch to be included in F10, as
it is included in F9 by default:
http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch

-- 
Ricardo Arguello

On Tue, Jan 6, 2009 at 12:33 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Ricardo Arg?ello wrote:
>>
>> Why was the improve-relatime.patch dropped from F10's kernel? F9 had
>> relatime on by default using this patch.
>> I first thought the upstream kernel had the patch now, but
>> /proc/mounts does not show relatime in F10.
>>
>> I found this bug, looks related:
>>
>>  mkinitrd can't deal with the "relatime" mount option
>>  https://bugzilla.redhat.com/show_bug.cgi?id=430280
>
> Speaking of, this looks to be... how old? Any chance of getting it fixed?
> (Especially with SSD's becoming more popular, for which it makes particular
> sense to request relatime?)
>
> I mean... if you don't know about this bug and add relatime to fstab, you've
> just made it impossible to upgrade the kernel. And the work-around (edit
> fstab to remove relatime, 'yum update kernel', edit fstab to put back
> relatime) isn't very friendly.
>
> --
> Matthew
> Please do not quote my e-mail address unobfuscated in message bodies.
> --
> "Ethics? We've heard of it" -- Microsoft
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jkeating at redhat.com  Tue Jan  6 18:53:36 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 13:53:36 -0500
Subject: xzgv in Fedora broken?
In-Reply-To: <gk08dh$dtg$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org> <49637369.1010302@hhs.nl>
	<49637778.3@fedoraproject.org>  <gk08dh$dtg$1@ger.gmane.org>
Message-ID: <1231268016.4036.16.camel@localhost.localdomain>

On Tue, 2009-01-06 at 19:37 +0100, Kevin Kofler wrote:
> Rahul Sundaram wrote:
> > Thanks Hans. It is amazing, people who knew about the issue would be not
> > reporting the bug but be willing to build conflicting packages in
> > another repository.
> 
> Not to mention the "fix" only papers around the real issue (by building the
> package with an old compiler).
> 
>         Kevin Kofler

That's the "work around to function now" fix whilst the "work with
upstream to port to new gcc" work continues.  The latter part is hardly
ever instant.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/c84a60ff/attachment.sig>

From kevin.kofler at chello.at  Tue Jan  6 18:59:42 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 06 Jan 2009 19:59:42 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<gjvkue$64j$1@ger.gmane.org>
	<20090106135643.GC16190@victor.dsathen.edu.gr>
Message-ID: <gk09mu$lmp$1@ger.gmane.org>

Axel Thimm wrote:
> Oh, my middle name is mass rebuild. This is yet another feature I was
> driving for in Fedora, to have scheduled mass rebuilds to do away with
> issues like this and others, but mass rebuilds were consdiered only to
> be done for really big changes (gcc for example). You can try to bring
> it up though. Currently there are just no mass rebuilds.

IMHO it only makes sense to rebuild packages if there is a good reason to.
Mass-rebuilding packages which have broken dependencies due to a soname
bump is a no-brainer, mass-rebuilding packages for a new GCC also makes
sense, mass-rebuilding packages just to mass-rebuild them is a rather
pointless exercise.

> A bumbed soname usually implies an API change. Some libs can be deep
> in the depdency hierarchy. The issues have been recognized by now also
> in Fedora due to the sheer size of it and we do have the first
> incarnation libfoo-compat. This is just the first step to an versioned
> libfoo<somark>.

Compat packages are the exception rather than the rule and should be done
only where they're really needed (i.e. the API changed and packages cannot
be easily ported to the current API). They have drawbacks which make them a
bad idea when avoidable:
* symbol clashes if a program somehow ends up with both versions linked
indirectly. Especially with things like plugins, this can happen more
easily than you think. (For example, a GTK+ program which links KDE 3
libraries for desktop integration will crash when used with the Qt 4
gtk-qt-engine. I've seen that happen with packages in the CalcForge repo.
Of course qt3/kdelibs3 is an example of an unavoidable compat package set,
but it does show that symbol clashes are a real issue.)
* risk of file conflicts, especially for the -devel packages (the .so
symlink is almost guaranteed to clash, we have scary hacks to work around
that for the KDE libs).

> For example ffmpeg or similar packages would require almost a third of
> ATrpms' package to be rebuilt.

Yeah, ffmpeg is a particularly annoying library due to its notorious
ABI-unstability and its heavy use in the multimedia world (because it has
really no equals when it comes to support for patent-encumbered formats).
I'll grant you that point.

But that doesn't explain why e.g. libquicktime which has been at .so.0 since
forever is using soname-based naming.

        Kevin Kofler



From debarshi.ray at gmail.com  Tue Jan  6 19:01:40 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 7 Jan 2009 00:31:40 +0530
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufa7i58pd7m.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
	<ufa7i58pd7m.fsf@epithumia.math.uh.edu>
Message-ID: <3170f42f0901061101x6bab50x7f5ebf075f73b72d@mail.gmail.com>

>  However, my point was
> that the mere existence of this software won't magically eliminate the
> need for humans to do package reviews,

Sure. After it is just a tool, but the idea is to reduce the number of
manual steps to a review. Manually carrying out mundane things like
verifying whether the package builds in Koji/Mock, the Source0 tag is
sane, md5sum of upstream and packaged tarballs match, rpmlint output,
etc. should not burden a person every time he/she does a review.

> and we're still not going to be
> able to do significant numbers of package re-reviews given our current
> manpower

Matt Domsch already does his periodic rebuilds of the entire tree to
uncover FTBFS packages. Kevin does his SourceX URL checks. Think of
all those combined into a single application. Ofcourse the priority of
a FTBFS package is going to be way higher than one that is not rpmlint
clean, but looking at some of the recent merge reviews I am trying to
do, I think it would be good to have them noted somewhere atleast.

>>> The problem is that the terribly named "ReviewOMatic" can't
>>> actually automatically review anything; a human is still required.
>
> DR> What is in a name? It can be changed.
>
> Well, I wasn't exactly silent about my objection when the project was
> first proposed and I was ignored then.

In that case I did not notice it. To be honest, I did not select this
name in the first place and I don't like it very much either. Neither
did Rakesh. There was a project by this name created on
Fedorahosted.org which we joined and started working on. The name, as
you say, was an annoyance but we were too lazy to do something about
it.

>  But in any case it's just a name, and
> while it will continue to annoy me I'm not going to do anything
> foolish such as demand that it be changed.

Foolish? Not really. I was just asking Rakesh whether we could have a
name change somewhere along the line or not. Suggestions welcome.

Cheers,
Debarshi



From Jochen at herr-schmitt.de  Tue Jan  6 19:06:18 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Tue, 06 Jan 2009 20:06:18 +0100
Subject: Issue on creating noarch subpackage in a ach depending package on
 koji
Message-ID: <4963ABAA.2030005@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

I have try to create a noarch subpackage in a arch depending package.

The build works fine on my local system, but on koji the build fails.

The build log you may find at:

http://koji.fedoraproject.org/koji/getfile?taskID=1035612&name=build.log


I may be happy for any hint to solve this issue.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkljq58ACgkQT2AHK6txfgyDswCeMVwsRnG4KN6p1leEDZLpb7Pn
5CMAn1JBhI1J49NN2xmm1YE8PJlSG5Yo
=atyW
-----END PGP SIGNATURE-----



From mjg at redhat.com  Tue Jan  6 19:10:22 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Tue, 6 Jan 2009 19:10:22 +0000
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <gk04m5$1qt$1@ger.gmane.org>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
	<gk04m5$1qt$1@ger.gmane.org>
Message-ID: <20090106191022.GA32590@srcf.ucam.org>

On Tue, Jan 06, 2009 at 11:33:57AM -0600, Matthew Woehlke wrote:

> I mean... if you don't know about this bug and add relatime to fstab, 
> you've just made it impossible to upgrade the kernel. And the 
> work-around (edit fstab to remove relatime, 'yum update kernel', edit 
> fstab to put back relatime) isn't very friendly.

relatime is supported in the stock kernel, but without the heuristic 
that avoids tmpreaper deleting your files at inappropriate times. It 
should cause failure.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From ricardo at fedoraproject.org  Tue Jan  6 19:11:57 2009
From: ricardo at fedoraproject.org (=?UTF-8?Q?Ricardo_Arg=C3=BCello?=)
Date: Tue, 6 Jan 2009 14:11:57 -0500
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <500f0ca00901061053k757667c4r282ff7ae74658c7d@mail.gmail.com>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
	<gk04m5$1qt$1@ger.gmane.org>
	<500f0ca00901061053k757667c4r282ff7ae74658c7d@mail.gmail.com>
Message-ID: <500f0ca00901061111q2e2788d8m4ba9b2aada683a9e@mail.gmail.com>

I reported it as a bug:

Add improve-relatime.patch to F10 and rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=479052

-- 
Ricardo Arguello

On Tue, Jan 6, 2009 at 1:53 PM, Ricardo Arg?ello
<ricardo at fedoraproject.org> wrote:
> Should I report the dropped improve-relatime.patch as a bug? The
> mkinitrd is a whole different thing.
>
> What I wanted was the improve-relatime.patch to be included in F10, as
> it is included in F9 by default:
> http://people.redhat.com/mingo/relatime-patches/improve-relatime.patch
>
> --
> Ricardo Arguello
>
> On Tue, Jan 6, 2009 at 12:33 PM, Matthew Woehlke
> <mw_triad at users.sourceforge.net> wrote:
>> Ricardo Arg?ello wrote:
>>>
>>> Why was the improve-relatime.patch dropped from F10's kernel? F9 had
>>> relatime on by default using this patch.
>>> I first thought the upstream kernel had the patch now, but
>>> /proc/mounts does not show relatime in F10.
>>>
>>> I found this bug, looks related:
>>>
>>>  mkinitrd can't deal with the "relatime" mount option
>>>  https://bugzilla.redhat.com/show_bug.cgi?id=430280
>>
>> Speaking of, this looks to be... how old? Any chance of getting it fixed?
>> (Especially with SSD's becoming more popular, for which it makes particular
>> sense to request relatime?)
>>
>> I mean... if you don't know about this bug and add relatime to fstab, you've
>> just made it impossible to upgrade the kernel. And the work-around (edit
>> fstab to remove relatime, 'yum update kernel', edit fstab to put back
>> relatime) isn't very friendly.
>>
>> --
>> Matthew
>> Please do not quote my e-mail address unobfuscated in message bodies.
>> --
>> "Ethics? We've heard of it" -- Microsoft
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>



From tibbs at math.uh.edu  Tue Jan  6 19:12:47 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 06 Jan 2009 13:12:47 -0600
Subject: Issue on creating noarch subpackage in a ach depending package
	on koji
In-Reply-To: <4963ABAA.2030005@herr-schmitt.de>
References: <4963ABAA.2030005@herr-schmitt.de>
Message-ID: <ufa1vvgp7tc.fsf@epithumia.math.uh.edu>

>>>>> "JS" == Jochen Schmitt <Jochen at herr-schmitt.de> writes:

JS> Hallo, I have try to create a noarch subpackage in a arch
JS> depending package.

Bad idea.

JS> The build works fine on my local system, but on koji the build
JS> fails.

This is as expected; rpm may support it, but the build system does
not.

JS> I may be happy for any hint to solve this issue.

There is no hint; you simply cannot do this at this time.

 - J<



From ricardo at fedoraproject.org  Tue Jan  6 19:16:40 2009
From: ricardo at fedoraproject.org (=?UTF-8?Q?Ricardo_Arg=C3=BCello?=)
Date: Tue, 6 Jan 2009 14:16:40 -0500
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <20090106191022.GA32590@srcf.ucam.org>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
	<gk04m5$1qt$1@ger.gmane.org> <20090106191022.GA32590@srcf.ucam.org>
Message-ID: <500f0ca00901061116k5aee1e2fl38bc51fe369e9e6d@mail.gmail.com>

> On Tue, Jan 06, 2009 at 11:33:57AM -0600, Matthew Woehlke wrote:
>
> relatime is supported in the stock kernel, but without the heuristic
> that avoids tmpreaper deleting your files at inappropriate times. It
> should cause failure.

Would the "improved relatime" patch solve that problem?



From tibbs at math.uh.edu  Tue Jan  6 19:16:59 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 06 Jan 2009 13:16:59 -0600
Subject: Summary of the 2009-01-06 Packaging Committee meeting
Message-ID: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the 2009-01-06 FPC meeting are
online:

http://fedoraproject.org/wiki/Packaging:Minutes
http://fedoraproject.org/wiki/Packaging:Minutes/20090106

Summary:

The following drafts are now official guidelines, having been accepted
by FESCO last week:

* RubyGems with C code -
  https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code
* Font packaging automation -
  https://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
* Updates to the Eclipse plugin guidelines
* Make adherence to the FHS a MUST, with the added exception of
  /usr/<target> for cross toolchains.

These should be written into the guidelines soon if this hasn't
already been done by the time you read this.

Issues pending FESCO ratification:

*  Font package splitting rules
   http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29

Misc business:

*  Font package naming -
   http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282008-12-22%29
 o Passed back to the submitter with comments and questions. 

* Use of absolute symlinks in packages -
  http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29
 o Turns out that rpm can be made to convert all symlinks to relative
   ones transparently, so that's being experimented with first.

 - J<



From ville.skytta at iki.fi  Tue Jan  6 19:28:47 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 6 Jan 2009 21:28:47 +0200
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <ufaljtopizg.fsf@epithumia.math.uh.edu>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
Message-ID: <200901062128.47695.ville.skytta@iki.fi>

On Tuesday 06 January 2009, Jason L Tibbitts III wrote:

> rpmlint
> output specifically is useless without piles of human interpretation.
>
> Surely you don't want to be automatically mailbombed with the rpmlint
> output from all of your packages.  That would only lead to bogus
> changes just to shut up equally bogus complaints, or some random
> syntax in comments within a specfile indicating what rpmlint
> complaints are expected.  Does anyone actually want that?

Probably not.  But what I'd want is people to file specific bugs if they have 
ideas how to improve rpmlint by eliminating bogosity or to make its messages 
clearer or any other way, Bugzilla or upstream.  Not everything can be fixed, 
but that doesn't mean everything should be accepted either.  I suppose 
prolific Fedora package reviewers are The People who run into issues with it 
most often and are in the best position to help out by pointing those out - 
most certainly *much* better than current rpmlint developers.



From a.badger at gmail.com  Tue Jan  6 19:33:19 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 06 Jan 2009 11:33:19 -0800
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <3170f42f0901061101x6bab50x7f5ebf075f73b72d@mail.gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>	<20090105181535.GB11824@nostromo.devel.redhat.com>	<1231179643.12948.1.camel@arekh.okg>	<ufak599vbye.fsf@epithumia.math.uh.edu>	<1231188376.17459.0.camel@arekh.okg>	<ufaljtopizg.fsf@epithumia.math.uh.edu>	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>	<ufa7i58pd7m.fsf@epithumia.math.uh.edu>
	<3170f42f0901061101x6bab50x7f5ebf075f73b72d@mail.gmail.com>
Message-ID: <4963B1FF.9000001@gmail.com>

Debarshi Ray wrote:
>>  However, my point was
>> that the mere existence of this software won't magically eliminate the
>> need for humans to do package reviews,
> 
> Sure. After it is just a tool, but the idea is to reduce the number of
> manual steps to a review. Manually carrying out mundane things like
> verifying whether the package builds in Koji/Mock, the Source0 tag is
> sane, md5sum of upstream and packaged tarballs match, rpmlint output,
> etc. should not burden a person every time he/she does a review.
> 
Note that the software needs to be clear on what is still required of
the human reviewer.  for instance, Source tag has several automatable
steps but also must have a human review that the Source URL is canonical
in the first place.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/d669e9dd/attachment.sig>

From ville.skytta at iki.fi  Tue Jan  6 19:44:00 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 6 Jan 2009 21:44:00 +0200
Subject: Tracking new review requests?
In-Reply-To: <9497e9990901060630m52e07213nd36fcca115cf5fe8@mail.gmail.com>
References: <200901061431.53501.ville.skytta@iki.fi>
	<9497e9990901060630m52e07213nd36fcca115cf5fe8@mail.gmail.com>
Message-ID: <200901062144.01583.ville.skytta@iki.fi>

On Tuesday 06 January 2009, Mat Booth wrote:
> On Tue, Jan 6, 2009 at 12:31 PM, Ville Skytt? <ville.skytta at iki.fi> wrote:
>
> > Would it be possible to add a mailman topic to fedora-package-review that
> > receives only new submissions?  I don't know how mailman topics are
> > configured, but I suppose these can be detected by matching "New: " at
> > the beginning of the subject.  Any other solutions?
>
> Not sure how well this works, but maybe you could subscribe to the
> search results page as a feed:

Thanks, I'll try something like this out.  But I'd still prefer a mail 
solution...



From ville.skytta at iki.fi  Tue Jan  6 19:47:04 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Tue, 6 Jan 2009 21:47:04 +0200
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
Message-ID: <200901062147.04828.ville.skytta@iki.fi>

On Tuesday 06 January 2009, Jason L Tibbitts III wrote:

> * Make adherence to the FHS a MUST, with the added exception of
>   /usr/<target> for cross toolchains.

Does this mean that /usr/libexec is still ok?



From jkeating at redhat.com  Tue Jan  6 19:54:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 14:54:13 -0500
Subject: Issue on creating noarch subpackage in a ach depending package
 on koji
In-Reply-To: <ufa1vvgp7tc.fsf@epithumia.math.uh.edu>
References: <4963ABAA.2030005@herr-schmitt.de>
	<ufa1vvgp7tc.fsf@epithumia.math.uh.edu>
Message-ID: <1231271653.4036.18.camel@localhost.localdomain>

On Tue, 2009-01-06 at 13:12 -0600, Jason L Tibbitts III wrote:
> There is no hint; you simply cannot do this at this time.

This is one of the topics that will be discussed during FUDCon, likely
at a hackfest or in a hallway or whatever given the high percentage of
koji hackers in the area.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/346a4652/attachment.sig>

From tibbs at math.uh.edu  Tue Jan  6 20:04:25 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 06 Jan 2009 14:04:25 -0600
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <200901062147.04828.ville.skytta@iki.fi>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<200901062147.04828.ville.skytta@iki.fi>
Message-ID: <ufaprj0nquu.fsf@epithumia.math.uh.edu>

>>>>> "VS" == Ville Skytt? <ville.skytta at iki.fi> writes:

VS> Does this mean that /usr/libexec is still ok?

Yes.  Unfortunately my summary is very short, and I would urge anyone
with questions to read the discussion or wait until the guidelines
have been updated.

 - J<



From konrad at tylerc.org  Tue Jan  6 20:04:27 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Tue, 6 Jan 2009 12:04:27 -0800
Subject: sound problems
In-Reply-To: <1231253578.4036.3.camel@localhost.localdomain>
References: <4960CEAA.4070507@gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
	<1231253578.4036.3.camel@localhost.localdomain>
Message-ID: <200901061204.27188.konrad@tylerc.org>

On Tuesday 06 January 2009 06:52:58 am Jesse Keating wrote:
> On Mon, 2009-01-05 at 18:04 -0900, Jeff Spaleta wrote:
> > I can't let this stand.  This public character assassination
> > absolutely must stop.  As an outgoing Board member I am appalled by
> > this sort of deliberate attempt to go out of your way to besmirk a
> > fellow contributor's direct contributions to this project.
>
> I have to agree with Jeff here.  Axel and I don't always agree, but he
> has been a valued contributor to the project both in packages but also
> in the packaging committee helping us to define good packaging practice.
>
> Your (Conrad) behavior on this list is completely unacceptable.  Find
> somewhere else (like your own room) to grind your axe.

Jeff's reply was to Christopher.

-- 
Conrad Meyer <konrad at tylerc.org>




From dominik at greysector.net  Tue Jan  6 20:14:06 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 6 Jan 2009 21:14:06 +0100
Subject: sound problems
In-Reply-To: <68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
Message-ID: <20090106201406.GB5797@mokona.greysector.net>

On Tuesday, 06 January 2009 at 11:49, Paulo Cavalcanti wrote:
[...]
> But the only reason for the existence of a 3rd party repo is a multimedia
> package.
> Almost all of them are based on ffmpeg, which is obtained from svn.
> Therefore,
> it is very difficult to have compatible packages, since ffmpeg API changes
> very often.

That is a lie. There was one incompatible ABI/API change in the last three
years and one move of headers.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Tue Jan  6 20:16:02 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 15:16:02 -0500
Subject: sound problems
In-Reply-To: <200901061204.27188.konrad@tylerc.org>
References: <4960CEAA.4070507@gmail.com>
	<604aa7910901051904v21345ee7h6c67512a006992e5@mail.gmail.com>
	<1231253578.4036.3.camel@localhost.localdomain>
	<200901061204.27188.konrad@tylerc.org>
Message-ID: <1231272962.4036.20.camel@localhost.localdomain>

> On Tue, 2009-01-06 at 12:04 -0800, Conrad Meyer wrote:
> > Your (Conrad) behavior on this list is completely unacceptable.  Find
> > somewhere else (like your own room) to grind your axe.
> 
> Jeff's reply was to Christopher.

GAH!  Mea Culpa!!!  You are correct, the admonition goes to Christopher.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/5b130800/attachment.sig>

From jspaleta at gmail.com  Tue Jan  6 20:41:29 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 11:41:29 -0900
Subject: sound problems
In-Reply-To: <20090106201406.GB5797@mokona.greysector.net>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<20090106201406.GB5797@mokona.greysector.net>
Message-ID: <604aa7910901061241s60658810s304d21b4bd497@mail.gmail.com>

On Tue, Jan 6, 2009 at 11:14 AM, Dominik 'Rathann' Mierzejewski
> That is a lie. There was one incompatible ABI/API change in the last three
> years and one move of headers.

So ffmpeg doesn't recommend using a static copy of ffmpeg libraries in
projects any more?

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/002999.html

Yes I know its an old post, but that's the sort of thing that people
bring up as a reference on how ffmpeg upstream works.

The header location change is certainly minor, but the impression
among application developers is that a common shared version of the
ffmpeg libs is still not the preferred way that upstream ffmpeg wants
application developers to use the libraries.  Just look at this recent
blog post:

http://blogs.gnome.org/bolsh/2008/12/05/ffmpeg-strikes-again/
Yes he got bit by the header location change...which is minor. But
look at all the responses from other application developers.  Multiple
people chiming in there complaining about how difficult it is to rely
consistently on ffmpeg svn checkouts.  Even a Moonlight developer,
which is a rather recent development effort in comparison to other
things, so the frustration with ffmpeg isn't completely a historical
artifact.

If there is a misconception about ffmpeg's relative instability
compared to other shared libraries...then ffmpeg developers need to
clarify this and actively encourage people to use a single shared
library across applications instead of continuing to let application
developers think that ffmpeg upstream encourages them to shove a
different static ffmpeg revision checkout into each and every
application.

It's the same blasted problem that is plaguing xulrunner applications
right now.  We can't have upstreams encouraging people to cart around
static copies of slightly different revision of the same library. We
need application developers to be targeting the use of shared
libraries and if ffmpeg developers are willing to help make that
possible, then please, please get them to put a public statement out
about that on the ffmpeg website with instructions for application
developers on how to file and fix issues with regard to using a single
shared system library instead of a per-application ffmpeg revision.

-jef



From peter at thecodergeek.com  Tue Jan  6 21:07:44 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 06 Jan 2009 13:07:44 -0800
Subject: Heads-Up: Deluge Update - Now noarch, using system rb_libtorrent
Message-ID: <1231276064.31156.29.camel@localhost.localdomain>

Hi, all.

I just committed an update to Deluge in rawhide (1.1.0-0.2.rc3) which,
along with the minor fixes from the bump to 1.1.0 RC3, contains a couple
of dramatic changes due to the rb_libtorrent update that I pushed
yesterday.

Firstly, the rb_libtorrent version is now more-or-less in sync with what
the upstream in-tarball copy is pulling, and so this allows us to skip
that in-tarball copy entirely and build against the system copy of
rb_libtorrent (and rb_libtorrent-python). Aside from the security and
bug-squashing benefits of using a system instead of a local copy, this
decreases the size of the built package by more than one-third (from 3.6
to 2.3MB).

Because of this change, the package now contains no arch-specific files
(just Python scripts, translations, and other data). Thus, it is now a
noarch package.

Please point and laugh^W^W^W yell at me if this causes any issues. :)

Thanks; and Regards.
--
Peter Gordon (codergeek42) <peter at thecodergeek.com>
???????????
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/7bb1fbcb/attachment.sig>

From list at pceet030.cern.ch  Tue Jan  6 21:09:27 2009
From: list at pceet030.cern.ch (Alfredo Ferrari)
Date: Tue, 6 Jan 2009 22:09:27 +0100
Subject: sound problems
In-Reply-To: <gjuosf$oic$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<49626737.7020109@gmail.com> <gjuosf$oic$1@ger.gmane.org>
Message-ID: <alpine.LFD.2.00.0901062207230.24562@pceet030.cern.ch>

I don't agree.

Fixing some problems and casuing many more is not progress it is a 
regression full stop.

By the way, a lot of people contribute to this thread with various degrees 
of flame wars, except that nobody (particularly from Fedora) is spending 
one word on how they are going to fix this big regression.

        Any news about the REAL problem (the broken audio)?

                  Alfredo Ferrari



+----------------------------------------------------------------------------+
|  Alfredo Ferrari                         ||  Tel.: +41.22.767.6119         |
|  C.E.R.N.                                ||  Fax.: +41.22.767.7555         |
|  European Laboratory for Particle Physics||                                |
|  AB Division / ATB Group                 ||  e-mail:                       |
|  1211 Geneva 23                          ||     Alfredo.Ferrari at cern.ch    |
|  Switzerland                             ||     Alfredo.Ferrari at mi.infn.it |
+----------------------------------------------------------------------------+

On Tue, 6 Jan 2009, Kevin Kofler wrote:

> Suren Karapetyan wrote:
>> I'm sure trying to fix them one by one in F10 is WRONG.
>
> Downgrading is what is wrong. The ALSA update fixes bugs for some people and
> even adds support for some hardware. Moving back is not the solution,
> fixing the update is.
>
>        Kevin Kofler
>
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From greno at verizon.net  Tue Jan  6 21:17:44 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 06 Jan 2009 16:17:44 -0500
Subject: Python, distutils, rpmbuild, issues
Message-ID: <4963CA78.4020408@verizon.net>

I wasn't sure exactly where to start with all this so here goes:

I've been working with some python projects and running into problems 
with RedHat-based distros when it comes to rpm generation, versioning, 
and updating.

Specifically, many projects like to put out release candidates for 
packages.  In python, there is a module, "distutils", that will permit 
you to create packaging for both apt and rpm like so:
$ python ./setup.py bdist_rpm  # this generates SRPMS and RPMS for this 
python app

One of the problems is versioning and occurred when the project created 
release candidates and we ended up with versions like:
5.0.0-rc1
Well, rpmbuild does not recognize hyphen as a legal character although 
it worked fine for apt.  So I opened a bug on the project and then devs 
then changed it to:
5.0.0_rc2
Ok, rpmbuild went along with this and apparently apt didn't care.  But 
will this work with the final release, 5.0.0?  Can the 5.0.0 rpm 
actually upgrade a 5.0.0_rc2 release?  Remember, the python module 
"distutils" causes the spec file to be generated on the fly.  So does it 
just assume the version will occur in lexical order?

The next problem was with trying to use the python setuy.py target, 
"bdist_rpm".  The bdist_rpm worked fine when you run it on ubuntu or 
debian (with rpmbuild installed) but failed when it was run on any of 
the RedHat-based distros.  The error that was occurring on the 
RedHat-based distros is the "Installed (but unpackages) file(s) found".  
Apparently on RedHat-based distros, rpmbuild creates .pyo files which 
never get added back into the INSTALLED_FILES from distutils and then of 
course it causes this error.  Has anyone solved this problem?  I see 
lots of references to this problem when I google it, but no solutions.


Regards,
Gerry





From jspaleta at gmail.com  Tue Jan  6 21:20:52 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 12:20:52 -0900
Subject: Heads-Up: Deluge Update - Now noarch, using system rb_libtorrent
In-Reply-To: <1231276064.31156.29.camel@localhost.localdomain>
References: <1231276064.31156.29.camel@localhost.localdomain>
Message-ID: <604aa7910901061320g2776b32bi3b48f15d1aa380c1@mail.gmail.com>

2009/1/6 Peter Gordon <peter at thecodergeek.com>:
> Because of this change, the package now contains no arch-specific files
> (just Python scripts, translations, and other data). Thus, it is now a
> noarch package.
>
> Please point and laugh^W^W^W yell at me if this causes any issues. :)

Hmm the switch to noarch will be interesting.  Does yum with exactarch
enabled keep this from being seen as an update?

-jef



From fedora at camperquake.de  Tue Jan  6 21:24:41 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 6 Jan 2009 22:24:41 +0100
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <4957E650.6010809@redhat.com>
References: <494930CD.70709@herr-schmitt.de>
	<4957E650.6010809@redhat.com>
Message-ID: <20090106222441.3cbe6860@lain.camperquake.de>

Hi.

On Sun, 28 Dec 2008 15:49:20 -0500, Casey Dahlin wrote

> I haven't looked at the code for grub2 myself, but most of the people
> I talk to that have cringe when they mention it. The people I talk to
> tend to be heavily involved in the boot process. As a piece of
> software engineering, it hasn't earned many fans among those most
> concerned with the change as far as I can tell.

Having looked at the code for GRUB(1) in order to figure out how to
properly boot Solaris I can't say that it makes me happy, either.

Is there such a thing as a bootloader that has nice and easy
to read code?



From dominik at greysector.net  Tue Jan  6 21:26:30 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 6 Jan 2009 22:26:30 +0100
Subject: sound problems
In-Reply-To: <604aa7910901061241s60658810s304d21b4bd497@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<20090106201406.GB5797@mokona.greysector.net>
	<604aa7910901061241s60658810s304d21b4bd497@mail.gmail.com>
Message-ID: <20090106212627.GC5797@mokona.greysector.net>

On Tuesday, 06 January 2009 at 21:41, Jeff Spaleta wrote:
> On Tue, Jan 6, 2009 at 11:14 AM, Dominik 'Rathann' Mierzejewski
> > That is a lie. There was one incompatible ABI/API change in the last three
> > years and one move of headers.
> 
> So ffmpeg doesn't recommend using a static copy of ffmpeg libraries in
> projects any more?

I haven't seen any such statements from the developers for a long time now.
ABI and API changes are watched carefully and breakage is postponed for
next major version bump as far as I can tell.

> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2005-August/002999.html
> 
> Yes I know its an old post, but that's the sort of thing that people
> bring up as a reference on how ffmpeg upstream works.
> 
> The header location change is certainly minor, but the impression
> among application developers is that a common shared version of the
> ffmpeg libs is still not the preferred way that upstream ffmpeg wants
> application developers to use the libraries.  Just look at this recent
> blog post:
> 
> http://blogs.gnome.org/bolsh/2008/12/05/ffmpeg-strikes-again/
> Yes he got bit by the header location change...which is minor. But
> look at all the responses from other application developers.  Multiple
> people chiming in there complaining about how difficult it is to rely
> consistently on ffmpeg svn checkouts.  Even a Moonlight developer,
> which is a rather recent development effort in comparison to other
> things, so the frustration with ffmpeg isn't completely a historical
> artifact.

Let me reply with a link to a blog post by one of FFmpeg's developers
then: http://multimedia.cx/eggs/we-dont-care-we-dont-have-to/

> If there is a misconception about ffmpeg's relative instability
> compared to other shared libraries...then ffmpeg developers need to
> clarify this and actively encourage people to use a single shared
> library across applications instead of continuing to let application
> developers think that ffmpeg upstream encourages them to shove a
> different static ffmpeg revision checkout into each and every
> application.

Well, given the rapid development rate of FFmpeg, a statically linked
snapshot is not a bad solution. FFmpeg developers don't really care
if you use a static or shared version, as long as you don't report
problems with an old version to them. 

I think this is where the distribution packagers have to come in. I try
to keep up with FFmpeg's latest version in RPMFusion/devel, but both
F-10 and F-9 branches carry an older snapshot, from before the ABI change.

> It's the same blasted problem that is plaguing xulrunner applications
> right now.  We can't have upstreams encouraging people to cart around
> static copies of slightly different revision of the same library. We
> need application developers to be targeting the use of shared
> libraries and if ffmpeg developers are willing to help make that
> possible, then please, please get them to put a public statement out
> about that on the ffmpeg website with instructions for application
> developers on how to file and fix issues with regard to using a single
> shared system library instead of a per-application ffmpeg revision.

I think the current snapshots are well-suited to be built as shared
libraries and I haven't seen any issues related to using them other than
applications (ab)using FFmpeg's private API. This is the reason why
e.g. MPlayer is still built using a static copy of FFmpeg's libraries.

I'm not really sure what you're expecting with regard to "a public statement
about that on the FFmpeg website" etc, though.

Regards,
R.

PS. Please use the correct capitalization of the name FFmpeg in the future.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Tue Jan  6 21:26:06 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 06 Jan 2009 16:26:06 -0500
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CA78.4020408@verizon.net>
References: <4963CA78.4020408@verizon.net>
Message-ID: <1231277166.4036.24.camel@localhost.localdomain>

On Tue, 2009-01-06 at 16:17 -0500, Gerry Reno wrote:
> Ok, rpmbuild went along with this and apparently apt didn't care.  But 
> will this work with the final release, 5.0.0?  Can the 5.0.0 rpm 
> actually upgrade a 5.0.0_rc2 release?  Remember, the python module 
> "distutils" causes the spec file to be generated on the fly.  So does it 
> just assume the version will occur in lexical order?

No, this won't work.  5.0.0_rc2 is in fact rpm newer than 5.0.0.

As to your other problem, I haven't even attempted it as the distutils
generated spec file isn't acceptable to Fedora packaging standards,
therefor I just maintain a spec file in my upstream source and have a
'make srpm' target in my makefile to turn the sources into an srpm.  I
also have other makefile targets to call various distutils things and
git things too.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/1981d173/attachment.sig>

From james at fedoraproject.org  Tue Jan  6 21:31:15 2009
From: james at fedoraproject.org (James Antill)
Date: Tue, 06 Jan 2009 16:31:15 -0500
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CA78.4020408@verizon.net>
References: <4963CA78.4020408@verizon.net>
Message-ID: <1231277475.11717.229.camel@code.and.org>

On Tue, 2009-01-06 at 16:17 -0500, Gerry Reno wrote:
[...]
> Ok, rpmbuild went along with this and apparently apt didn't care.  But 
> will this work with the final release, 5.0.0?  Can the 5.0.0 rpm 
> actually upgrade a 5.0.0_rc2 release?  Remember, the python module 
> "distutils" causes the spec file to be generated on the fly.  So does it 
> just assume the version will occur in lexical order?

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease

> The next problem was with trying to use the python setuy.py target, 
> "bdist_rpm".  The bdist_rpm worked fine when you run it on ubuntu or 
> debian (with rpmbuild installed) but failed when it was run on any of 
> the RedHat-based distros.  The error that was occurring on the 
> RedHat-based distros is the "Installed (but unpackages) file(s) found".  

bug#236535, co-incidentally I committed the fix to rawhide earlier today
(I didn't build though, as 2.6.1 is coming).

-- 
James Antill <james at fedoraproject.org>
Fedora



From cmadams at hiwaay.net  Tue Jan  6 21:31:46 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 6 Jan 2009 15:31:46 -0600
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CA78.4020408@verizon.net>
References: <4963CA78.4020408@verizon.net>
Message-ID: <20090106213146.GJ1310766@hiwaay.net>

Once upon a time, Gerry Reno <greno at verizon.net> said:
> One of the problems is versioning and occurred when the project created 
> release candidates and we ended up with versions like:
> 5.0.0-rc1

I believe the typical way to package an rc, pre, etc. type release is
5.0.0-0.rc1.  Then when it goes final, you can package 5.0.0-1 and be
newer.

> Well, rpmbuild does not recognize hyphen as a legal character although 
> it worked fine for apt.  So I opened a bug on the project and then devs 
> then changed it to:
> 5.0.0_rc2

That is newer than 5.0.0, so you'll have upgrade problems.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From skvidal at fedoraproject.org  Tue Jan  6 21:33:48 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 06 Jan 2009 16:33:48 -0500
Subject: Heads-Up: Deluge Update - Now noarch, using system rb_libtorrent
In-Reply-To: <604aa7910901061320g2776b32bi3b48f15d1aa380c1@mail.gmail.com>
References: <1231276064.31156.29.camel@localhost.localdomain>
	<604aa7910901061320g2776b32bi3b48f15d1aa380c1@mail.gmail.com>
Message-ID: <1231277628.26455.120.camel@rosebud>

On Tue, 2009-01-06 at 12:20 -0900, Jeff Spaleta wrote:
> 2009/1/6 Peter Gordon <peter at thecodergeek.com>:
> > Because of this change, the package now contains no arch-specific files
> > (just Python scripts, translations, and other data). Thus, it is now a
> > noarch package.
> >
> > Please point and laugh^W^W^W yell at me if this causes any issues. :)
> 
> Hmm the switch to noarch will be interesting.  Does yum with exactarch
> enabled keep this from being seen as an update?

exactarch only impacts certain pkgs.


-sv




From dominik at greysector.net  Tue Jan  6 21:34:28 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 6 Jan 2009 22:34:28 +0100
Subject: sound problems
In-Reply-To: <gk09mu$lmp$1@ger.gmane.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<gjvkue$64j$1@ger.gmane.org>
	<20090106135643.GC16190@victor.dsathen.edu.gr>
	<gk09mu$lmp$1@ger.gmane.org>
Message-ID: <20090106213428.GD5797@mokona.greysector.net>

On Tuesday, 06 January 2009 at 19:59, Kevin Kofler wrote:
> Axel Thimm wrote:

> > For example ffmpeg or similar packages would require almost a third of
> > ATrpms' package to be rebuilt.
> 
> Yeah, ffmpeg is a particularly annoying library due to its notorious
> ABI-unstability

Please, stop spreading FUD. As I said in another post in this thread,
there was one API/ABI change in the last three years and one move of headers.
If that's not stable, then I dare you to find another project that is
developed at a similar pace and has a more stable API and ABI.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From greno at verizon.net  Tue Jan  6 21:38:08 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 06 Jan 2009 16:38:08 -0500
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <1231277166.4036.24.camel@localhost.localdomain>
References: <4963CA78.4020408@verizon.net>
	<1231277166.4036.24.camel@localhost.localdomain>
Message-ID: <4963CF40.4090207@verizon.net>

Jesse Keating wrote:
> No, this won't work.  5.0.0_rc2 is in fact rpm newer than 5.0.0.
>   
Is there some way to force rpm to recognize 5.0.0 as newer than 
5.0.0_rc2?  How else are you supposed to handle the release candidate 
packaging?

> As to your other problem, I haven't even attempted it as the distutils
> generated spec file isn't acceptable to Fedora packaging standards,
>   
Why is this?  I've built RPMS using bdist_rpm and they work just fine.  
You can configure things in setup.cfg.  Of course I had to force an 
ignore of the "Installed but not packaged files" error which is not a 
permanent solution to the problem.  I would prefer to use 'bdist_rpm' 
and not develop a whole new way of building python packages when 
distutils can already do this.  If something cannot be configured then I 
think distutils should be enhanced.

Regards,
Gerry



From jspaleta at gmail.com  Tue Jan  6 21:39:53 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 12:39:53 -0900
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CA78.4020408@verizon.net>
References: <4963CA78.4020408@verizon.net>
Message-ID: <604aa7910901061339o53c80925oe64d7ff01b14e08f@mail.gmail.com>

On Tue, Jan 6, 2009 at 12:17 PM, Gerry Reno <greno at verizon.net> wrote:
> Ok, rpmbuild went along with this and apparently apt didn't care.  But will
> this work with the final release, 5.0.0?  Can the 5.0.0 rpm actually upgrade
> a 5.0.0_rc2 release?  Remember, the python module "distutils" causes the
> spec file to be generated on the fly.  So does it just assume the version
> will occur in lexical order?

We have packaging policies aimed at pre-release versions, which throw
the pre-release naming scheme into the release.  I have a scipy
package right now in rawhide and in f10 updates-testing which uses our
project policy to ensure upgrade paths work.  Python's distutil spec
file generation needs to grow the ability to put the pre-release
information into the "release" field and not in the "version" field.


>
> The next problem was with trying to use the python setuy.py target,
> "bdist_rpm".  The bdist_rpm worked fine when you run it on ubuntu or debian
> (with rpmbuild installed) but failed when it was run on any of the
> RedHat-based distros.  The error that was occurring on the RedHat-based
> distros is the "Installed (but unpackages) file(s) found".  Apparently on
> RedHat-based distros, rpmbuild creates .pyo files which never get added back
> into the INSTALLED_FILES from distutils and then of course it causes this
> error.  Has anyone solved this problem?  I see lots of references to this
> problem when I google it, but no solutions.


The solution is to fix upstream python's specfile generation so that
its robust against the sort of failures your are finding.  It just
needs to include *.pyo files Fedora packagers are not relying on this
auto-generation by distutils.


-jef



From loganjerry at gmail.com  Tue Jan  6 21:44:52 2009
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 6 Jan 2009 14:44:52 -0700
Subject: MAVEN_OPTS and mvn-jpp
Message-ID: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>

I'm having a build failure, on rawhide only, of a Java package that is
built with maven.  When I run maven from the command line, if I give
it more than one -DXXX option, it always complains that the second one
is not a valid target.  I took a tip from a web site that mentions
this problem and tried this (where the first 3 -DXXX options are from
/usr/bin/mvn-jpp, and the 4th is the recommended way of using mvn-jpp
in a spec file):

$ export MAVEN_OPTS="-Dmaven2.offline.mode -Dmaven2.ignore.versions
-Dmaven2.usejppjars -Dmaven.repo.local=$MAVEN_REPO_LOCAL"
$ mvn install

That worked.  Is this an expected change?  If so, both the
/usr/bin/mvn-jpp script and the wiki description of how to use maven
will have to be changed.  If not, does anyone have any idea why
multiple -DXXX options aren't working for me?  Again, this is on
Rawhide only.  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From dledford at redhat.com  Tue Jan  6 21:54:48 2009
From: dledford at redhat.com (Doug Ledford)
Date: Tue, 06 Jan 2009 16:54:48 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
Message-ID: <1231278888.32405.845.camel@firewall.xsintricity.com>

On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
> Meeting minutes and full logs of the 2009-01-06 FPC meeting are
> online:
> 
> http://fedoraproject.org/wiki/Packaging:Minutes
> http://fedoraproject.org/wiki/Packaging:Minutes/20090106
> 
> Summary:
> 
> The following drafts are now official guidelines, having been accepted
> by FESCO last week:
> 
> * RubyGems with C code -
>   https://fedoraproject.org/wiki/PackagingDrafts/RubyGem_with_C_code
> * Font packaging automation -
>   https://fedoraproject.org/wiki/PackagingDrafts/Fonts_packaging_automation
> * Updates to the Eclipse plugin guidelines
> * Make adherence to the FHS a MUST, with the added exception of
>   /usr/<target> for cross toolchains.

I happen to have a few packages that just *can't* follow FHS (unless we
opt to ignore FHS and allow a package to install to /opt, but that's
always been just as verbotten by the FHS for the initial software
distributor versus an ISV as failing to follow any other FHS specified
layout).

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/119f4f96/attachment.sig>

From forum at ru.bir.ru  Tue Jan  6 22:17:40 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Wed, 07 Jan 2009 01:17:40 +0300
Subject: Tracking new review requests?
In-Reply-To: <200901061431.53501.ville.skytta@iki.fi>
References: <200901061431.53501.ville.skytta@iki.fi>
Message-ID: <gk0la5$1ve$1@ger.gmane.org>

Ville Skytt? ?????:
> Hello,
> 
> I'd like to be notified about new Fedora package review requests by mail, only 
> once.  I'm currently subscribed to fedora-package-review which is otherwise 
> fine, except that I receive all of the review mail and not only the first 
> mail sent when a new review request is submitted.
> 
> I suppose I could set up a filter that gets the mails I'm not usually 
> interested out of the way, but I'd rather not receive anything but the first 
> one in the first place (unless I'm submitter/reviewer/cc'd of course, but 
> that's handled by direct mails).
> 
May be this is more easy make on user side? I read fedora-package-review 
in Thunderbird through nntp protocol (over gmane) and free set up any 
filters with all power of a filters what thunderbird does (and/or logic, 
any part of message and few actions like skip thread etc.)



From thomas.moschny at gmail.com  Tue Jan  6 22:19:17 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Tue, 6 Jan 2009 23:19:17 +0100
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CA78.4020408@verizon.net>
References: <4963CA78.4020408@verizon.net>
Message-ID: <a9d183c80901061419y57da717dy4c7aa28750ef76ba@mail.gmail.com>

2009/1/6 Gerry Reno <greno at verizon.net>:
> The next problem was with trying to use the python setuy.py target,
> "bdist_rpm".  The bdist_rpm worked fine when you run it on ubuntu or debian
> (with rpmbuild installed) but failed when it was run on any of the
> RedHat-based distros.  The error that was occurring on the RedHat-based
> distros is the "Installed (but unpackages) file(s) found".  Apparently on
> RedHat-based distros, rpmbuild creates .pyo files which never get added back
> into the INSTALLED_FILES from distutils and then of course it causes this
> error.  Has anyone solved this problem?  I see lots of references to this
> problem when I google it, but no solutions.

Here's how it worked for me some time ago:

$ echo 'python setup.py install --optimize 1 --root=$RPM_BUILD_ROOT
--record=INSTALLED_FILES' > install.spec
$ python setup.py bdist_rpm --install-script=install.spec

- Thomas



From peter at thecodergeek.com  Tue Jan  6 22:19:58 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 06 Jan 2009 14:19:58 -0800
Subject: Heads-Up: Deluge Update - Now noarch, using system rb_libtorrent
In-Reply-To: <604aa7910901061320g2776b32bi3b48f15d1aa380c1@mail.gmail.com>
References: <1231276064.31156.29.camel@localhost.localdomain>
	<604aa7910901061320g2776b32bi3b48f15d1aa380c1@mail.gmail.com>
Message-ID: <1231280398.31156.40.camel@localhost.localdomain>

On Tue, 2009-01-06 at 12:20 -0900, Jeff Spaleta wrote:
> Hmm the switch to noarch will be interesting.  Does yum with exactarch
> enabled keep this from being seen as an update?
> 

On my updated F10/x86_64 desktop, exactarch is set to on (1) by default,
and a `yum localupgrade' worked just fine from the arch-specific 1.0.7
(in F10 updates-testing) to the noarch mock-built package. :)
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.com>
???????????
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/58bc0454/attachment.sig>

From jspaleta at gmail.com  Tue Jan  6 22:28:19 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 13:28:19 -0900
Subject: sound problems
In-Reply-To: <20090106212627.GC5797@mokona.greysector.net>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<20090106201406.GB5797@mokona.greysector.net>
	<604aa7910901061241s60658810s304d21b4bd497@mail.gmail.com>
	<20090106212627.GC5797@mokona.greysector.net>
Message-ID: <604aa7910901061428r1904fd82qb3e63fb08aec3379@mail.gmail.com>

On Tue, Jan 6, 2009 at 12:26 PM, Dominik 'Rathann' Mierzejewski
> Well, given the rapid development rate of FFmpeg, a statically linked
> snapshot is not a bad solution. FFmpeg developers don't really care
> if you use a static or shared version, as long as you don't report
> problems with an old version to them.

wrong. staticly linked libraries on a per application basis are a very
very bad solution.

What if every gtk or qt application used its own static version of
those libraries.... madness.

If library developers need to care about the shared library case.

-jef



From cmadams at hiwaay.net  Tue Jan  6 22:30:45 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 6 Jan 2009 16:30:45 -0600
Subject: sound problems
In-Reply-To: <604aa7910901061428r1904fd82qb3e63fb08aec3379@mail.gmail.com>
References: <d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<20090106201406.GB5797@mokona.greysector.net>
	<604aa7910901061241s60658810s304d21b4bd497@mail.gmail.com>
	<20090106212627.GC5797@mokona.greysector.net>
	<604aa7910901061428r1904fd82qb3e63fb08aec3379@mail.gmail.com>
Message-ID: <20090106223045.GL1310766@hiwaay.net>

Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> wrong. staticly linked libraries on a per application basis are a very
> very bad solution.
> 
> What if every gtk or qt application used its own static version of
> those libraries.... madness.

One word: BerkeleyDB

AFAIK db4 still recommends a static local copy for apps that use it.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From a.badger at gmail.com  Tue Jan  6 22:37:04 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 06 Jan 2009 14:37:04 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <1231278888.32405.845.camel@firewall.xsintricity.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
Message-ID: <4963DD10.1060002@gmail.com>

Doug Ledford wrote:
> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:

>> * Make adherence to the FHS a MUST, with the added exception of
>>   /usr/<target> for cross toolchains.
> 
> I happen to have a few packages that just *can't* follow FHS (unless we
> opt to ignore FHS and allow a package to install to /opt, but that's
> always been just as verbotten by the FHS for the initial software
> distributor versus an ISV as failing to follow any other FHS specified
> layout).
> 
Example SRPMS?  (Or the package name if it's already in cvs).

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/c955bbc1/attachment.sig>

From a.badger at gmail.com  Tue Jan  6 22:47:41 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 06 Jan 2009 14:47:41 -0800
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963CF40.4090207@verizon.net>
References: <4963CA78.4020408@verizon.net>	<1231277166.4036.24.camel@localhost.localdomain>
	<4963CF40.4090207@verizon.net>
Message-ID: <4963DF8D.9060102@gmail.com>

Gerry Reno wrote:
> Jesse Keating wrote:
>> No, this won't work.  5.0.0_rc2 is in fact rpm newer than 5.0.0.
>>   
> Is there some way to force rpm to recognize 5.0.0 as newer than
> 5.0.0_rc2?  How else are you supposed to handle the release candidate
> packaging?
> 
No.  This needs to be fixed in distutils/setuptools.  I don't think that
distutils currently knows anything about versions and ordering.
setuptools does its own ordering which is incompatible with rpm but I
don't believe that impacts the bdist_rpm target.

To work, bdist_rpm would need to understand the ordering of the package
and map that to an ordering for rpm.  In Fedora we do the mapping
manually by placing the prerelease information into the rpm release field:

Upstream: foo-5.0.0_rc2
Rpm Version: 5.0.0
Rpm Release: 0.1.rc2

Upstream: foo-5.0.0_rc3
Rpm Version: 5.0.0
Rpm Release: 0.2.rc3

Upstream: foo-5.0.0
Rpm Version: 5.0.0
Rpm Release: 1

>> As to your other problem, I haven't even attempted it as the distutils
>> generated spec file isn't acceptable to Fedora packaging standards,
>>   
> Why is this?  I've built RPMS using bdist_rpm and they work just fine. 
> You can configure things in setup.cfg.  Of course I had to force an
> ignore of the "Installed but not packaged files" error which is not a
> permanent solution to the problem.  I would prefer to use 'bdist_rpm'
> and not develop a whole new way of building python packages when
> distutils can already do this.  If something cannot be configured then I
> think distutils should be enhanced.
> 
bdist_rpm can create a valid rpm.  But it doesn't meet our standards.
For instance, as you've found it doesn't account for the *.pyo files.
These need to be included in the package otherwise they can be created
later at runtime (if python optimize is on and root runs a python
program, for instance) and then leave the unowned *.pyo's on the system.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/27b07868/attachment.sig>

From surenkarapetyan at gmail.com  Tue Jan  6 23:12:30 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Wed, 07 Jan 2009 03:12:30 +0400
Subject: sound problems
In-Reply-To: <alpine.LFD.2.00.0901062207230.24562@pceet030.cern.ch>
References: <4960CEAA.4070507@gmail.com>	<68720af30901041621g3d3927d0ta1b24cf6b76f8375@mail.gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<49626737.7020109@gmail.com>
	<gjuosf$oic$1@ger.gmane.org>
	<alpine.LFD.2.00.0901062207230.24562@pceet030.cern.ch>
Message-ID: <4963E55E.5030409@gmail.com>

Alfredo Ferrari wrote:
> I don't agree.
>
> Fixing some problems and casuing many more is not progress it is a 
> regression full stop.
>
> By the way, a lot of people contribute to this thread with various 
> degrees of flame wars, except that nobody (particularly from Fedora) 
> is spending one word on how they are going to fix this big regression.
>
>        Any news about the REAL problem (the broken audio)?
>
>                  Alfredo Ferrari
>
>
>
> +----------------------------------------------------------------------------+ 
>
> |  Alfredo Ferrari                         ||  Tel.: 
> +41.22.767.6119         |
> |  C.E.R.N.                                ||  Fax.: 
> +41.22.767.7555         |
> |  European Laboratory for Particle 
> Physics||                                |
> |  AB Division / ATB Group                 ||  
> e-mail:                       |
> |  1211 Geneva 23                          ||     
> Alfredo.Ferrari at cern.ch    |
> |  Switzerland                             ||     
> Alfredo.Ferrari at mi.infn.it |
> +----------------------------------------------------------------------------+ 
>
>
> On Tue, 6 Jan 2009, Kevin Kofler wrote:
>
>> Suren Karapetyan wrote:
>>> I'm sure trying to fix them one by one in F10 is WRONG.
>>
>> Downgrading is what is wrong. The ALSA update fixes bugs for some 
>> people and
>> even adds support for some hardware. Moving back is not the solution,
>> fixing the update is.
>>
>>        Kevin Kofler
>>
>> -- 
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
I knew I'll be sorry when I created the thread (maybe I'll be sorry for 
this post even more).
It was completely of no use.
And bugzilla report (https://bugzilla.redhat.com/show_bug.cgi?id=477911) 
was quite pointless too.
As statistics shows 
(https://bugzilla.redhat.com/buglist.cgi?component=kernel&product=Fedora), 
opening a report against kernel is no more useful than sending it to 
/dev/null.
And so is bodhi 
(https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11593).
2008-12-21 08:31:27 This update has been pushed to testing
2008-12-21 14:45:43 On my dell 640m, mic does not have sound output. But 
the built-in speaker works.
2008-12-21 16:07:36 Sorry, it's not mic, but the earphone does not have 
sound output. [dell 640m, all configurations are default ]
2008-12-22 15:45:37 This update has been submitted for stable
2008-12-24 18:45:34 This update has been pushed to stable

31 hours in testing (add mirror sync and it will be much less) 2 
comments from 1 person telling that it breaks sound. And it's pushed to 
stable.
The next morning it breaks sound on my notebook and I report it at: 
https://bugzilla.redhat.com/show_bug.cgi?id=477911.
A lot of "me too"s. 27 comments from different people trying 
with/without pulseaudio, next kernel update from koji, rawhide...
Then the bug is marked as a duplicate of 
https://bugzilla.redhat.com/show_bug.cgi?id=477954.
The same discussions go here and H.J. Lu (hongjiu.lu at intel.com) points 
us to 
http://n2.nabble.com/F10:-new-kernel-breaks-audio-(snd-hda-intel)-td1923470.html
Here people are advised to download and try the alsa snapshot builds 
from atrpms which fixes sound at least for a few people (not for me).

Then I create this thread hoping to get some developers look at the 
problem and provide patches which I can test.
In no time this thread becomes a flamewar where people tell how bad 
atrpms (yeah.. the one which fixed sound for some people) and everyone 
who contributes to it is.
And then I'm told that if I consider breaking sound for 13 (for now) 
days with a security update wrong, then maybe I shouldn't use Fedora.

This brings to an interesting question: Who should use Fedora.
In 95% of this list/wiki we consider Fedora's users to be newbies and 
very often even clueless, silly, dumb.
We say: "Let's stop doing X and start doing Y, cause clueless users will 
want Y and if someone wants X back he can do it himself".

Do we expect regular user to stay with Fedora while he can't play any 
music on his entertainment notebook for 13 days?

"You can boot with older kernel!" - "An older what?"
<irony>We don't show grub menu(to eliminate flicker) until user presses 
CTRL or whatever it was (I don't remember).</irony>



From greno at verizon.net  Wed Jan  7 00:03:37 2009
From: greno at verizon.net (Gerry Reno)
Date: Tue, 06 Jan 2009 19:03:37 -0500
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963DF8D.9060102@gmail.com>
References: <4963CA78.4020408@verizon.net>
	<1231277166.4036.24.camel@localhost.localdomain>
	<4963CF40.4090207@verizon.net> <4963DF8D.9060102@gmail.com>
Message-ID: <4963F159.1050901@verizon.net>

Toshio Kuratomi wrote:
> Gerry Reno wrote:
>   
>> Jesse Keating wrote:
>>     
>>> No, this won't work.  5.0.0_rc2 is in fact rpm newer than 5.0.0.
>>>   
>>>       
>> Is there some way to force rpm to recognize 5.0.0 as newer than
>> 5.0.0_rc2?  How else are you supposed to handle the release candidate
>> packaging?
>>
>>     
> No.  This needs to be fixed in distutils/setuptools.  I don't think that
> distutils currently knows anything about versions and ordering.
> setuptools does its own ordering which is incompatible with rpm but I
> don't believe that impacts the bdist_rpm target.
>
> To work, bdist_rpm would need to understand the ordering of the package
> and map that to an ordering for rpm.  In Fedora we do the mapping
> manually by placing the prerelease information into the rpm release field:
>
> Upstream: foo-5.0.0_rc2
> Rpm Version: 5.0.0
> Rpm Release: 0.1.rc2
>
> Upstream: foo-5.0.0_rc3
> Rpm Version: 5.0.0
> Rpm Release: 0.2.rc3
>
> Upstream: foo-5.0.0
> Rpm Version: 5.0.0
> Rpm Release: 1
>   
Ok, I need to work on this a little to see what is going to be necessary 
to get something that will work for both apt and rpm as far as release 
candidate versioning, ordering and updating.

>   
>>> As to your other problem, I haven't even attempted it as the distutils
>>> generated spec file isn't acceptable to Fedora packaging standards,
>>>   
>>>       
>> Why is this?  I've built RPMS using bdist_rpm and they work just fine. 
>> You can configure things in setup.cfg.  Of course I had to force an
>> ignore of the "Installed but not packaged files" error which is not a
>> permanent solution to the problem.  I would prefer to use 'bdist_rpm'
>> and not develop a whole new way of building python packages when
>> distutils can already do this.  If something cannot be configured then I
>> think distutils should be enhanced.
>>
>>     
> bdist_rpm can create a valid rpm.  But it doesn't meet our standards.
> For instance, as you've found it doesn't account for the *.pyo files.
> These need to be included in the package otherwise they can be created
> later at runtime (if python optimize is on and root runs a python
> program, for instance) and then leave the unowned *.pyo's on the system.
>
> -Toshio
>   
Thomas just had a good suggestion and I tried it and it seems to work 
and it generates the .pyo files.
My goal is to only use 'bdist' and 'bdist_rpm' configured using 
setup.cfg to generate apt and rpm files for various distros.  This sure 
simplifies things.  Are you saying that this is not going to be possible 
with Fedora/RedHat?

Regards,
Gerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/168c9881/attachment.htm>

From cdahlin at redhat.com  Wed Jan  7 00:29:55 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Tue, 06 Jan 2009 19:29:55 -0500
Subject: Futuer of grub/grub2 to F11
In-Reply-To: <20090106222441.3cbe6860@lain.camperquake.de>
References: <494930CD.70709@herr-schmitt.de>	<4957E650.6010809@redhat.com>
	<20090106222441.3cbe6860@lain.camperquake.de>
Message-ID: <4963F783.7000300@redhat.com>

Ralf Ertzinger wrote:
> Hi.
>
> On Sun, 28 Dec 2008 15:49:20 -0500, Casey Dahlin wrote
>
>   
>> I haven't looked at the code for grub2 myself, but most of the people
>> I talk to that have cringe when they mention it. The people I talk to
>> tend to be heavily involved in the boot process. As a piece of
>> software engineering, it hasn't earned many fans among those most
>> concerned with the change as far as I can tell.
>>     
>
> Having looked at the code for GRUB(1) in order to figure out how to
> properly boot Solaris I can't say that it makes me happy, either.
>
> Is there such a thing as a bootloader that has nice and easy
> to read code?
>
>   
Probably not. Hacks are pretty much part of the job (this is where we 
keep our chickens and eggs).

--CJD



From a.badger at gmail.com  Wed Jan  7 00:36:38 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 06 Jan 2009 16:36:38 -0800
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963F159.1050901@verizon.net>
References: <4963CA78.4020408@verizon.net>	<1231277166.4036.24.camel@localhost.localdomain>	<4963CF40.4090207@verizon.net>
	<4963DF8D.9060102@gmail.com> <4963F159.1050901@verizon.net>
Message-ID: <4963F916.8060309@gmail.com>

Gerry Reno wrote:

> Thomas just had a good suggestion and I tried it and it seems to work
> and it generates the .pyo files.
> My goal is to only use 'bdist' and 'bdist_rpm' configured using
> setup.cfg to generate apt and rpm files for various distros.  This sure
> simplifies things.  Are you saying that this is not going to be possible
> with Fedora/RedHat?
> 
It depends.  bdist_rpm certainly doesn't generate packages that we would
include verbatim into Fedora.  However, it might be able to generate
rpms that are servicable for an upstream to distribute.  We do lean
heavily on distutils in our spec files for python modules so it's not
something that's impossible.  I'd watch out for gotchas like file
placement for data files, man pages, locale files, though.  And if
you're packaging an application rather than a module, things won't be
very nice.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090106/54d1e89c/attachment.sig>

From jspaleta at gmail.com  Wed Jan  7 00:46:04 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 6 Jan 2009 15:46:04 -0900
Subject: Python, distutils, rpmbuild, issues
In-Reply-To: <4963F159.1050901@verizon.net>
References: <4963CA78.4020408@verizon.net>
	<1231277166.4036.24.camel@localhost.localdomain>
	<4963CF40.4090207@verizon.net> <4963DF8D.9060102@gmail.com>
	<4963F159.1050901@verizon.net>
Message-ID: <604aa7910901061646q391ef548k3369df0f0b23f05@mail.gmail.com>

2009/1/6 Gerry Reno <greno at verizon.net>:
> My goal is to only use 'bdist' and 'bdist_rpm' configured using setup.cfg to
> generate apt and rpm files for various distros.  This sure simplifies
> things.  Are you saying that this is not going to be possible with
> Fedora/RedHat?

Whether or not you can get bdist to comply with our python packaging
policies or not is an open question.  The pre-release versioning is
just one potential problem..general to any packaging effort.  We also
have language specific best practises which apply to python
applications.  Those best practices evolve over time.

We have human reviewers who check submissions to make sure submissions
meet the current packaging guidance.  If you can get bdist generated
specfiles to comply with those best practises, then reviewers won't
know its a generated spec unless you tell them.  But how much effort
it will take for you to get bdist to conform to our guidance is
something we can't tell you.  The fact that it has problems with
version numbering for pre-releases which do not work for standard rpm
alphanumeric parsing rules isn't encouraging and that's not even a
Fedora specific policy statement..that's an rpm-ism which reaches
across rpm based distributions.

-jef



From roland at redhat.com  Wed Jan  7 00:52:45 2009
From: roland at redhat.com (Roland McGrath)
Date: Tue,  6 Jan 2009 16:52:45 -0800 (PST)
Subject: debuginfo audit
In-Reply-To: Horst H. von Brand's message of  Tuesday,
	6 January 2009 10:44:22 -0300
	<200901061344.n06DiNGX009617@laptop14.inf.utfsm.cl>
References: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
	<200901061344.n06DiNGX009617@laptop14.inf.utfsm.cl>
Message-ID: <20090107005245.155DAFC305@magilla.sf.frob.com>

> Roland McGrath <roland at redhat.com> wrote:
> > I've been setting up to do mass tests on all the debuginfo files,
> > and I've generated some data along the way.
> 
> Does this include e.g. latest glibc not having debuginfo? (BZ 478426)

The data are the data.  You can answer a question about a particular
rpm by looking in the files I posted about.



From mjg at redhat.com  Wed Jan  7 00:54:52 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Wed, 7 Jan 2009 00:54:52 +0000
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <500f0ca00901061116k5aee1e2fl38bc51fe369e9e6d@mail.gmail.com>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>
	<gk04m5$1qt$1@ger.gmane.org> <20090106191022.GA32590@srcf.ucam.org>
	<500f0ca00901061116k5aee1e2fl38bc51fe369e9e6d@mail.gmail.com>
Message-ID: <20090107005452.GA8500@srcf.ucam.org>

On Tue, Jan 06, 2009 at 02:16:40PM -0500, Ricardo Arg?ello wrote:
> > On Tue, Jan 06, 2009 at 11:33:57AM -0600, Matthew Woehlke wrote:
> >
> > relatime is supported in the stock kernel, but without the heuristic
> > that avoids tmpreaper deleting your files at inappropriate times. It
> > should cause failure.
> 
> Would the "improved relatime" patch solve that problem?

Huh. I actually meant "shouldn't cause failure" there, in terms of it 
still being a valid mount option. The improved relatime code adds that 
heuristic, which avoids the tmpreaper failure. I'm trying to get it 
upstream, at which point I'll backport it - I'm not enthusiastic about 
carrying it around as a custom modification forever.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From roland at redhat.com  Wed Jan  7 01:06:20 2009
From: roland at redhat.com (Roland McGrath)
Date: Tue,  6 Jan 2009 17:06:20 -0800 (PST)
Subject: debuginfo audit
In-Reply-To: Ville Skyttä's message of  Tuesday, 6 January 2009 13:31:58 +0200 <200901061331.59622.ville.skytta@iki.fi>
References: <20090105223736.2BEC5FC299@magilla.sf.frob.com>
	<200901061331.59622.ville.skytta@iki.fi>
Message-ID: <20090107010620.10540FC305@magilla.sf.frob.com>

> Would you be interested in including this script I wrote some time ago in
> your script set in git?
> http://scop.fedorapeople.org/scripts/debuginfocheck.py

Um, sure.  If you fork my tiny git repo, I'd be glad to pull from yours.
I'm not really trying to get into looking for individual package problems
myself.  I just happen to have the data on hand, so I thought I'd share.
(My focus is on new tools to improve things across the board, and I think
my time is best spent trying to make some of that happen and giving
technical pointers to folks who investigate particular Fedora packages.)


Thanks,
Roland



From mw_triad at users.sourceforge.net  Wed Jan  7 01:37:41 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Tue, 06 Jan 2009 19:37:41 -0600
Subject: improve-relatime.patch dropped from F10
In-Reply-To: <20090106191022.GA32590@srcf.ucam.org>
References: <500f0ca00812272308w2b6d0f39q5868b9ce06d032@mail.gmail.com>	<gk04m5$1qt$1@ger.gmane.org>
	<20090106191022.GA32590@srcf.ucam.org>
Message-ID: <gk1115$5ek$1@ger.gmane.org>

Matthew Garrett wrote:
> On Tue, Jan 06, 2009 at 11:33:57AM -0600, Matthew Woehlke wrote:
>> I mean... if you don't know about this bug and add relatime to fstab, 
>> you've just made it impossible to upgrade the kernel. And the 
>> work-around (edit fstab to remove relatime, 'yum update kernel', edit 
>> fstab to put back relatime) isn't very friendly.
> 
> relatime is supported in the stock kernel, but without the heuristic 
> that avoids tmpreaper deleting your files at inappropriate times. It 
> shouldn't cause failure.

As per the bug mentioned in the OP, it may be coming from around initrd 
and not the kernel per-se. I intend to check next time a kernel update 
is available.

What does tmpreaper normally reap? If it is only /tmp, then I don't care 
about the missing heuristic ;-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ethics? We've heard of it" -- Microsoft



From atkac at redhat.com  Wed Jan  7 08:43:00 2009
From: atkac at redhat.com (Adam Tkac)
Date: Wed, 7 Jan 2009 09:43:00 +0100
Subject: git-* commands in /usr/libexec/git-core/
Message-ID: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>

Hi all,

git-* binaries have been moved to /usr/libexec/git-core directory in
the latest git build in F11 branch. Changelog says "Install git-*
commands in %{_libexecdir}/git-core, the upstream default".

Unfortunately this change break many scripts which are using git-*
commands. In my opinion binaries should be moved back to /usr/bin or
/usr/libexec/git-core should be added to PATH by default, shouldn't it?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.



From rawhide at fedoraproject.org  Wed Jan  7 08:52:50 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed,  7 Jan 2009 08:52:50 +0000 (UTC)
Subject: rawhide report: 20090107 changes
Message-ID: <20090107085250.EF0EA1F8260@releng2.fedora.phx.redhat.com>

Compose started at Wed Jan  7 06:01:03 UTC 2009

New package cudd
        CU Decision Diagram Package
New package ghc-HTTP
        HTTP library for Haskell
New package mumbles
        A plugin driven DBus based notification system for the Gnome desktop
New package python-weberror
        Web Error handling and exception catching middleware
Updated Packages:

amarok-2.0.1-1.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 2.0.1-1
- amarok-2.0.1


amtterm-1.2-1.fc11
------------------
* Tue Jan  6 17:00:00 2009 Gerd Hoffmann <kraxel at redhat.com> - 1.2-1
- update to version 1.2
  * support special reboot commands (pxe, bios. ...).
  * gamt: gui tweaks, logging support.

* Thu Oct 30 18:00:00 2008 Gerd Hoffmann <kraxel at redhat.com> - 1.1-3
- update to version 1.1
  * handle BIOS-over-SOL.
  * some minor doc tweaks.


at-spi-1.25.4-2.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1.25.4-2
- Update to 1.25.4


automaton-1.11r1-1.fc11
-----------------------
* Tue Jan  6 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 1.11r1-1
- Upgrade to 1.11-1


awn-extras-applets-0.2.6-8.fc11
-------------------------------
* Tue Jan  6 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.2.6-8
- Resolves: rhbz#478696 make build again

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.6-7
- Rebuild for Python 2.6


bacula-2.4.4-1.fc11
-------------------
* Mon Jan  5 17:00:00 2009 Jon Ciesla <limb at jcomserv.net - 2.4.4-1
- Update to new upstream, 2.4.4.
- Dropped orphaned jobs patch, python 2.6 patch, applied upstream.


bash-completion-20080705-1
--------------------------
* Tue Jan  6 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 20080705-1
- 20080705; new upstream at http://bash-completion.alioth.debian.org/
- Perl, Debian, and scp patches applied upstream.
- Patch to improve man completion: more sections, better filename handling.
- Patch to speed up yum install/deplist completion (#478784).
- Patch to fix and speed up rpm installed packages completion.
- Update mock completion.

* Thu Sep 25 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi>
- More Matroska associations (#463829, based on patch from Yanko Kaneti).


batik-1.7-2.fc11
----------------
* Tue Jan  6 17:00:00 2009 Lillian Angel  <langel at redhat.com> - 1.7-2
- Fixed java dependencies to check for java-1.6.0-openjdk instead.


bit-0.4.90-3.fc11
-----------------
* Tue Jan  6 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.4.90-3
- Updated summaries


blender-2.48a-9.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-9
- Create fonts sub-package (#477370)


brasero-0.8.4-1.fc10
--------------------
* Tue Dec 16 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 0.8.3-1
- Update to upstream 0.8.4
- Enabled nautilus extension


cairo-1.8.6-1.fc11
------------------
* Wed Jan  7 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> 1.8.6-1
- Update to 1.8.6


cairo-dock-2.0.0-0.3.svn1470_trunk.fc11
---------------------------------------
* Tue Jan  6 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1470


check-0.9.6-1.fc11
------------------
* Tue Jan  6 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 0.9.6-1
- update to 0.9.6


cheese-2.25.4-1.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> 2.25.4-1
- Update to 2.25.4


conexusmm-0.5.0-6.fc8
---------------------
* Thu Jan  1 17:00:00 2009 Tim Niemueller <tim at niemueller.de> - 0.5.0-6
- Rebuild for new papyrus 0.7.1-6
- Sync to F-10 version/release

* Tue Jul 15 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 0.5.0-5
- fix license tag

* Tue Feb 19 17:00:00 2008 Fedora Release Engineering <rel-eng at fedoraproject.org> - 0.5.0-4
- Autorebuild for GCC 4.3


deluge-1.1.0-0.2.rc3.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 1.1.0-0.2.rc3
- Update to new upstream release candidate (1.1.0 RC3)
- Build against the system rb_libtorrent instead of using the in-tarball copy
  (requires rb_libtorrent 0.14+), and adjust dependencies accordingly. Drop
  the hacked setup.py script formerly used to enable this (fixed upstream):
  - fixed-setup.py
- Make it a noarch package now that it's just python scripts and related
  data files (translations, images, etc.)


dhcp-4.1.0-1.fc11
-----------------
* Tue Jan  6 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 12:4.1.0-1
- Upgraded to ISC dhcp-4.1.0
- Had to rename the -T option to -timeout as ISC is now using -T
- Allow package rebuilders to easily enable DHCPv6 support with:
      rpmbuild --with DHCPv6 dhcp.spec
  Note that Fedora is still using the 'dhcpv6' package, but some
  users may want to experiment with the ISC DHCPv6 implementation
  locally.


eclipse-changelog-2.6.4-1.fc10
------------------------------
* Wed Dec 10 17:00:00 2008 Jeff Johnston <jjohnstn at redhat.com> 2.6.4-1
- 2.6.4.
- Add javacSource and javacTarget parameters to pdebuild call.
- Fixes #253016


eclipse-rpm-editor-0.4.1-1.fc11
-------------------------------
* Tue Jan  6 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 0.4.1-1
- New version 0.4.1.
- Fix URL and fetch script to use tags.


eigen2-2.0-0.7.beta5.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.7.beta5
- eigen-2.0-beta5


emotion-0.1.0.042-3.fc11
------------------------
* Sat Nov 29 17:00:00 2008 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.1.0.042-3
- Fixed unowned directory


empathy-2.25.4-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 2.25.4-1
- Update to 2.25.4.
- Add BR on libcanberra-devel.


eog-2.25.4-1.fc11
-----------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


epiphany-2.24.2.1-4.fc11
------------------------
* Tue Jan  6 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 2.24.2.1-4
- Rebuild against newer gecko

* Tue Dec 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.2.1-3
- Rebuild against newer gecko


epiphany-extensions-2.24.0-3.fc11
---------------------------------
* Tue Jan  6 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 2.24.0-3
- Rebuild against newer gecko


evince-2.25.4-1.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4
- Temporarily drop the duplex patch, it needs updating


evolution-2.25.4-1.fc11
-----------------------
* Mon Jan  5 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.4-1.fc11
- Update to 2.25.4
- Bump eds_version to 2.25.4.
- Bump libgweather_version to 2.25.4.


evolution-data-server-2.25.4-1.fc11
-----------------------------------
* Mon Jan  5 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.4-1.fc11
- Update to 2.25.4


evolution-exchange-2.25.4-1.fc11
--------------------------------
* Tue Jan  6 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.4-1.fc11
- Update to 2.25.4

* Mon Dec 15 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.3-1.fc11
- Update to 2.25.3

* Mon Dec  1 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.25.2-1.fc11
- Update to 2.25.2


exempi-2.1.0-1.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Deji Akingunola <dakingun at gmail.com> - 2.1.0-1
- Update to 2.1.0


file-roller-2.25.1-5.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.1-5
- Update to 2.25.1
- Clean up BRs


galeon-2.0.7-5.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 2.0.7-5
- Apply modified patch for epiphany for building against xulrunner
  1.9.1 from Christopher Aillon (#478666)

* Fri Dec 26 17:00:00 2008 Denis Leroy <denis at poolshark.org> - 2.0.7-4
- Rebuild for newer gnome desktop library


gcalctool-5.25.4-1.fc11
-----------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 5.25.4-1
- Update to 5.25.4


gd-2.0.35-7.fc11
----------------
* Tue Jan  6 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 2.0.35-7
- do minor spec file cleanup


gedit-2.25.4-2.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.4-2
- Update to 2.25.4


glade3-3.5.5-1.fc11
-------------------
* Wed Jan  7 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 3.5.5-1
- Version bump to 3.5.5.
- Removed 'Provides: glade'.
- Addressed warnings generated by rpmlint.


gnome-applets-2.25.3-2.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.3-2
- Update to 2.25.3


gnome-desktop-2.25.4-1.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 2.25.3-3
- Stop cross fade before freeing pixmaps in finalize instead
  of after.

* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


gnome-games-2.25.4-1.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.4-1
- Update to 2.25.4


gnome-keyring-2.25.4.1-1.fc11
-----------------------------
* Tue Jan  6 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 2.25.4.1-1
- Update to 2.25.4.1


gpm-1.20.5-2.fc11
-----------------
* Tue Dec  2 17:00:00 2008 Zdenek Prikryl <zprikryl at redhat.com> - 1.20.5-2
- Fixed debug mode (#473422)
- Fixed description in init script (#474337)


gsoap-2.7.12-1.fc11
-------------------
* Wed Dec 24 17:00:00 2008 <matt at redhat> - 2.7.12-1
- Updated to gsoap 2.7.12:
-  Numerous bug fixes - xml:lang, maxOccurs="unbounded", SSL, xmlns="", ...
-  New features, maintaining backward compatibility - MinGW, wsseapi, multi-endpoint connect, ...
- Patches removed (incorporated upstream):
-  datadir_importpath-2.7.10.patch
-  install_soapcpp2_wsdl2h_aux-2.7.10.patch
-  no_locale.patch as default off, enable by defining WITH_C_LOCALE
- Patches added (sent upstream):
-  unused_args.patch - eliminate many unused param warnings


gtksourceview2-2.5.2-1.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.5.2-1
- Update to 2.5.2


gtkspell-2.0.15-1.fc10
----------------------
* Fri Dec 12 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.0.15-1.fc10
- Update to 2.0.15
- Add patch for a language comparison bug reported by Zden??k Jurka.

* Thu Nov 27 17:00:00 2008 Matthew Barnes <mbarnes at redhat.com> - 2.0.14-1.fc10
- Update to 2.0.14


gvfs-1.1.3-1.fc11
-----------------
* Tue Jan  6 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 1.1.3-1
- Update to 1.1.3


icewm-1.2.36-3.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1.2.36-3
- pkg-config --cflags gnome-desktop-2.0 doesn't implicitly include
  libgnomeui-2.0 anymore, so add it in explicitly

* Mon Jan  5 17:00:00 2009 Gilboa Davara <gilboad[AT]gmail.com> - 1.2.36-2
- Missing BR libgnomeui-devel. (devel)
- Missing BR gnome-vfs2-devel. (devel)


jetty-5.1.14-1.7.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Jeff Johnston <jjohnstn at redhat.com> 5.1.14-1.7
- Resolves #473585
- Patch init.d script to add status operation
- Patch unix djetty script so it doesn't issue error messages about /dev/tty
  and fix various inconsistencies with the init.d script


kdiff3-0.9.93-1.2.fc11
----------------------
* Tue Jan  6 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.9.93-6
- use kde4 macros
- add scriptlets for locolor icons
- update d-f-i usage
- include khelpcenter handbook
- update Source0 URL

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-5
- Fix HTML_DIR and use kde4_ versions of datadir, libdir, bindir

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-4
- Remove /etc/profile.d/qt.sh, remove configure

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-3
- Change BR, no longer kde3

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-2-1
- Update to 0.9.93-2

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-2
- Add br cmake

* Tue Jan  6 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-1
- Update to 0.9.93


ksplice-0.9.5-1.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 0.9.5-1
- New upstream release


latexmk-4.03-1.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 4.03-1
- Update to 4.03 to fix log file parsing


libselinux-2.0.77-2.fc11
------------------------
* Tue Jan  6 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.0.77-2
- Fix restorecon python code

* Tue Jan  6 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.0.77-1
- Update to upstream


libwpd-0.8.14-2.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.8.14-2
- Rebuild for provides


lilypond-doc-2.12.1-1.fc11
--------------------------
* Tue Jan  6 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> 2.12.1-1
- Update to 2.12.1.


logwatch-7.3.6-39.fc11
----------------------
* Tue Jan  6 17:00:00 2009 Ivana Varekova <varekova at redhat.com> 7.3.6-39
- fix smartd script


magic-7.5.169-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 7.5.169-1
- new upstream release

* Mon Dec 15 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 7.5.168-1
- new upstream release


mousetweaks-2.25.4-1.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


newscache-1.2-0.8.rc6.fc11
--------------------------
* Tue Jan  6 17:00:00 2009 Dmitry Butskoy <Dmitry at Butskoy.name> - 1.2-0.8.rc6
- Fix autotools stuff in socket++ for libtool >= 2

* Mon Jan  5 17:00:00 2009 Dmitry Butskoy <Dmitry at Butskoy.name> - 1.2-0.7.rc6
- Add news user and group (#478785) since Fedora 10


nfs-utils-1.1.4-11.fc11
-----------------------
* Sat Jan  3 17:00:00 2009 Steve Dickson <steved at redhat.com> 1.1.4-11
- Added warnings to tcp wrapper code when mounts are 
  denied due to misconfigured DNS configurations.
- gssd: By default, don't spam syslog when users' credentials expire
- mount: revert recent fix for build problems on old systems
- mount: use gethostbyname(3) when building on old systems
- mount: getport: don't use getaddrinfo(3) on old systems
- mount: Random clean up
- configure: use "--disable-uuid" instead of	"--without-uuid"


openoffice.org-3.0.1-14.3.fc11
------------------------------
* Tue Jan  6 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-14.3
- Resolves: rhbz#476959 openoffice.org-3.0.1.ooo97488.sw.ww8toc.patch


orca-2.25.4-1.fc11
------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


perl-HTML-Parser-3.59-1.fc10
----------------------------
* Tue Dec 16 17:00:00 2008 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 3.59-1
- update to the latest version for Padre editor


perl-Image-ExifTool-7.60-1.fc11
-------------------------------
* Tue Jan  6 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 7.60-1
- update to 7.60


policycoreutils-2.0.60-7.fc11
-----------------------------
* Tue Jan  6 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.60-7
- Don't error out when removing a non existing module


postr-0.12.3-1.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Tim Lauridsen <timlau at fedoraproject.org> - 0.12.3-1
- New upstream version 0.12.3


powertop-1.11-1.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Adam Jackson <ajax at redhat.com> 1.11-1
- powertop 1.11

* Thu Nov 20 17:00:00 2008 Adam Jackson <ajax at redhat.com>
- Spec only change, fix URL.


ptlib-2.5.2-1.fc11
------------------
* Tue Jan  6 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 2.5.2-1
- New release for ekiga 3.1.0 beta


pyke-0.6-1.fc11
---------------
* Tue Jan  6 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 0.6-1
- update to 0.6


python-beaker-1.1.3-1.fc11
--------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.1.3-1
- Update to 1.1.3

* Sat Dec 20 17:00:00 2008 Felix Schwarz <felix.schwarz at oss.schwarz.eu> - 1.1.2-1
- Update to 1.1.2


python-formencode-1.2-1.fc11
----------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.2-1
- Update to 1.2
- Run the test suite
- Remove formencode-translations-system.patch


python-mako-0.2.4-1.fc11
------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.2.4-1
- Update to 0.2.4


python-paste-1.7.2-1.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.7.2-1
- Update to 1.7.2


python-paste-script-1.7.3-1.fc11
--------------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.7.3-1
- Update to 1.7.3
- Remove copydir_re_fix.patch


python-routes-1.10.1-1.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.10.1-2
- Update to 1.10.1
- Run the test suite


python-simplejson-2.0.7-1.fc11
------------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> 2.0.7-1
- Update to 2.0.7


python-telepathy-0.15.5-1.fc11
------------------------------
* Tue Jan  6 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.15.5-1
- Update to 0.15.5.


python-toscawidgets-0.9.4-1.fc11
--------------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.9.4-1
- Update to 0.9.4


python-webob-0.9.5-1.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> 0.9.5-1
- Update to 0.9.5


quagga-0.99.11-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Jiri Skala <jskala at redhat.com> - 0.99.11-1
- bump to latest upstream version 0.99.11


rhm-0.4.3030-2.fc10
-------------------

rss2email-2.65-1.1
------------------
* Tue Jan  6 17:00:00 2009 Thorsten Leemhuis <fedora [AT] leemhuis [DOT] info> - 2.65-1
- update to 2.65
- recreate rss2email-use-configpy-from-homedir.patch


rubygem-rubyforge-1.0.2-2.fc11
------------------------------
* Tue Jan  6 17:00:00 2009 Darryl Pierce <dpierce at redhat.com> - 1.0.2-2
- Provided the wrong gem as source.

* Tue Jan  6 17:00:00 2009 Darryl Pierce <dpierce at redhat.com> - 1.0.2-1
- Release 1.0.2 of Rubyforge.


seahorse-plugins-2.25.3-1.fc11
------------------------------
* Mon Dec 22 17:00:00 2008 Tomas Bzatek <tbzatek at redhat.com> 2.25.3-1
- Update to 2.25.3


selinux-policy-3.6.2-2.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.2-2
- Remove audio_entropy policy


smc-fonts-04.1-2.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Pravin Satpute <psatpute at redhat.com> 04.1-2
- bugfix 477458
- updated spec


solar-kde-theme-0.1.17-1.fc11
-----------------------------
* Tue Jan  6 17:00:00 2009 Jaroslav Reznik <jreznik at redhat.com> 0.1.17-1
- screenshot resized to 200x150 px
- kdm theme authors are more compact


sooperlooper-1.6.13-1.fc11
--------------------------
* Tue Jan  6 17:00:00 2009 Anthony Green <green at redhat.com> 1.6.13-1
- New upstream release 1.6.13


tailor-0.9.35-4.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Dan Hor??k <dan[at]danny.cz> 0.9.35-4
- add patch for compatibility with mercurial 1.1.2 by Daniel P. Berrange (Resolves: #478841)


telepathy-butterfly-0.3.3-1.fc11
--------------------------------
* Tue Jan  6 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.3.3-1
- Update to 0.3.3.
- Add NEWS.


telepathy-gabble-0.7.18-1.fc11
------------------------------
* Tue Jan  6 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.18-1
- Update to 0.7.18.


texi2html-1.80-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 1.80-1
- update to 1.80


thunderbird-2.0.0.19-1.fc10
---------------------------
* Mon Jan  5 17:00:00 2009 Christopher Aillon <caillon at redhat.com> 2.0.0.19-1
- Update to 2.0.0.19


totem-2.25.3-6.fc11
-------------------
* Mon Jan  5 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-6
- Remove compiled bits for the bug report scripts (#478889)


vdr-ttxtsubs-0.0.8-1.fc11
-------------------------
* Tue Jan  6 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 0.0.8-1
- 0.0.8.
- License: GPLv2+ (already since 0.0.6).


vdradmin-am-3.6.4-1.fc10
------------------------
* Sun Dec 21 17:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 3.6.4-1
- 3.6.4, proctitle patch applied upstream.


vinagre-2.25.4-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


vino-2.25.4-1.fc11
------------------
* Tue Jan  6 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4-1
- Update to 2.25.4


xorg-x11-drv-ati-6.10.0-1.fc11
------------------------------
* Wed Jan  7 17:00:00 2009 Dave Airlie <airlied at redhat.com> 6.10.0-1
- rebase to latest upstream release


xterm-238-1.fc11
----------------
* Tue Jan  6 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 238-1
- update to 238 (#479000, CVE-2008-2383)
- set default values of allowWindowOps and allowFontOps resources to false


Summary:
Added Packages: 4
Removed Packages: 0
Modified Packages: 99
Broken deps for i386
----------------------------------------------------------
	bigboard-0.6.4-4.fc11.i386 requires libempathy.so.17
	desktop-data-model-1.2.5-3.fc11.i386 requires libempathy.so.17
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mumbles-0.4-8.fc10.noarch requires python(abi) = 0:2.5
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.i386 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.i386 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.i386 requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.i386 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.i386 requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.i386 requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.i386 requires python(abi) = 0:2.5



Broken deps for x86_64
----------------------------------------------------------
	bigboard-0.6.4-4.fc11.x86_64 requires libempathy.so.17()(64bit)
	desktop-data-model-1.2.5-3.fc11.i386 requires libempathy.so.17
	desktop-data-model-1.2.5-3.fc11.x86_64 requires libempathy.so.17()(64bit)
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mumbles-0.4-8.fc10.noarch requires python(abi) = 0:2.5
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.x86_64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.x86_64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.x86_64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.x86_64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	syck-python-0.61-6.fc10.x86_64 requires python(abi) = 0:2.5



Broken deps for ppc
----------------------------------------------------------
	bigboard-0.6.4-4.fc11.ppc requires libempathy.so.17
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	desktop-data-model-1.2.5-3.fc11.ppc requires libempathy.so.17
	desktop-data-model-1.2.5-3.fc11.ppc64 requires libempathy.so.17()(64bit)
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mumbles-0.4-8.fc10.noarch requires python(abi) = 0:2.5
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	python-gtkextra-1.1.0-3.fc10.ppc requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc requires libpython2.5.so.1.0
	python-rra-0.11.1-1.fc9.ppc requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	pyzzub-0.2.3-12.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	scidavis-0.1.3-2.fc10.ppc requires libpython2.5.so.1.0
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc requires libpython2.5.so.1.0
	syck-python-0.61-6.fc10.ppc requires python(abi) = 0:2.5



Broken deps for ppc64
----------------------------------------------------------
	bigboard-0.6.4-4.fc11.ppc64 requires libempathy.so.17()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	desktop-data-model-1.2.5-3.fc11.ppc64 requires libempathy.so.17()(64bit)
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mumbles-0.4-8.fc10.noarch requires python(abi) = 0:2.5
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	poker2d-common-1.6.0-3.fc11.1.ppc64 requires poker-client-lib = 0:1.6.0
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	python-gtkextra-1.1.0-3.fc10.ppc64 requires python(abi) = 0:2.5
	python-rra-0.11.1-1.fc9.ppc64 requires libpython2.5.so.1.0()(64bit)
	python-rra-0.11.1-1.fc9.ppc64 requires python(abi) = 0:2.5
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	scidavis-0.1.3-2.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk
	syck-python-0.61-6.fc10.ppc64 requires python(abi) = 0:2.5
	syck-python-0.61-6.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)





From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Jan  7 09:02:42 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 07 Jan 2009 18:02:42 +0900
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
Message-ID: <49646FB2.4050908@ioa.s.u-tokyo.ac.jp>

Adam Tkac wrote, at 01/07/2009 05:43 PM +9:00:
> Hi all,
> 
> git-* binaries have been moved to /usr/libexec/git-core directory in
> the latest git build in F11 branch. Changelog says "Install git-*
> commands in %{_libexecdir}/git-core, the upstream default".
> 
> Unfortunately this change break many scripts which are using git-*
> commands. In my opinion binaries should be moved back to /usr/bin or
> /usr/libexec/git-core should be added to PATH by default, shouldn't it?
> 
> Regards, Adam

I don't know if %_libexec/git-core should be added to the default
PATH or not, however FYI this was announced:

https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00071.html

Regards,
Mamoru



From promac at gmail.com  Wed Jan  7 09:48:47 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 7 Jan 2009 07:48:47 -0200
Subject: xzgv in Fedora broken?
In-Reply-To: <49637778.3@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org> <49637369.1010302@hhs.nl>
	<49637778.3@fedoraproject.org>
Message-ID: <68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>

On Tue, Jan 6, 2009 at 1:23 PM, Rahul Sundaram
<sundaram at fedoraproject.org>wrote:

> Hans de Goede wrote:
>
>  Note I'm looking in to fixing the xzgv thumbnails issue. Why? To show that
>> actually reporting problems helps I guess.
>>
>
> Thanks Hans. It is amazing, people who knew about the issue would be not
> reporting the bug but be willing to build conflicting packages in another
> repository.
>
>

Please, Rahul

xzgv does not impact anything.

Once more, here is the fixed memtest86+ for F10.
It works just fine (for me) even on new Intel G45.

http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm

I would appreciate if someone could take a look at it.

Thanks.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/b67f3cbb/attachment.htm>

From kzak at redhat.com  Wed Jan  7 09:55:10 2009
From: kzak at redhat.com (Karel Zak)
Date: Wed, 7 Jan 2009 10:55:10 +0100
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
Message-ID: <20090107095510.GA2960@nb.net.home>

On Wed, Jan 07, 2009 at 09:43:00AM +0100, Adam Tkac wrote:
> Hi all,
> 
> git-* binaries have been moved to /usr/libexec/git-core directory in
> the latest git build in F11 branch. Changelog says "Install git-*
> commands in %{_libexecdir}/git-core, the upstream default".

Git 1.6.0 ReleaseNotes:

   Invoking a git subcommand as "git-xyzzy" from the command line has
   been deprecated since early 2006 (and officially announced in 1.5.4
                         ^^^^^^^^^^
   release notes);

now we have 2009...

> Unfortunately this change break many scripts which are using git-*

Fix your scripts. (I did it one year ago;-)

> commands. In my opinion binaries should be moved back to /usr/bin or
> /usr/libexec/git-core should be added to PATH by default, shouldn't it?

I don't think so, because:

  http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

and because it's better when you fix your scripts today than
tomorrow... because you might have more scripts tomorrow.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From sundaram at fedoraproject.org  Wed Jan  7 10:17:10 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 07 Jan 2009 15:47:10 +0530
Subject: xzgv in Fedora broken?
In-Reply-To: <68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
	<49637369.1010302@hhs.nl>	<49637778.3@fedoraproject.org>
	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
Message-ID: <49648126.9000904@fedoraproject.org>

Paulo Cavalcanti wrote:

> Please, Rahul
> 
> xzgv does not impact anything. 

Maybe it doesn't but someone has went through the effort of a workaround 
in a different repository while being aware of the issue. That effort 
could have been made to make this work well with gcc4 and helping 
resolve the issue in the long term for upstream as well.
> 
> Once more, here is the fixed memtest86+ for F10. 
> It works just fine (for me) even on new Intel G45.
> 
> http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm
> 
> I would appreciate if someone could take a look at it.

Apply to be a co-maintainer and you will be able to fix it directly.

Rahul



From bmr at redhat.com  Wed Jan  7 10:21:20 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Wed, 07 Jan 2009 10:21:20 +0000
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
Message-ID: <49648220.7050209@redhat.com>

Adam Tkac wrote:
> Hi all,
> 
> git-* binaries have been moved to /usr/libexec/git-core directory in
> the latest git build in F11 branch. Changelog says "Install git-*
> commands in %{_libexecdir}/git-core, the upstream default".
> 
> Unfortunately this change break many scripts which are using git-*
> commands. In my opinion binaries should be moved back to /usr/bin or
> /usr/libexec/git-core should be added to PATH by default, shouldn't it?

I guess it depends how much we care about being close to upstream for 
this. If it's worth the effort to move these to libexec, then perhaps 
putting compatibility symlinks in place for a couple of releases (with a 
clear relnote that they will be removed in a future release and scripts 
need updating) could be a way to handle the transition?

I think putting /usr/libexec/git-core in PATH would be a bad idea.

Regards,
Bryn.



From rjones at redhat.com  Wed Jan  7 10:35:11 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 7 Jan 2009 10:35:11 +0000
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
Message-ID: <20090107103511.GA27484@amd.home.annexia.org>

On Tue, Jan 06, 2009 at 01:16:59PM -0600, Jason L Tibbitts III wrote:
> * Make adherence to the FHS a MUST, [...]

Is there a recognized process for getting changes into upstream FHS?

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 promac at gmail.com  Wed Jan  7 11:01:48 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 7 Jan 2009 09:01:48 -0200
Subject: xzgv in Fedora broken?
In-Reply-To: <49648126.9000904@fedoraproject.org>
References: <4960CEAA.4070507@gmail.com> <200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org> <49637369.1010302@hhs.nl>
	<49637778.3@fedoraproject.org>
	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
	<49648126.9000904@fedoraproject.org>
Message-ID: <68720af30901070301j2df3434dha5205183261fcbc7@mail.gmail.com>

On Wed, Jan 7, 2009 at 8:17 AM, Rahul Sundaram
<sundaram at fedoraproject.org>wrote:

> Paulo Cavalcanti wrote:
>
>  Please, Rahul
>>
>> xzgv does not impact anything.
>>
>
> Maybe it doesn't but someone has went through the effort of a workaround in
> a different repository while being aware of the issue. That effort could
> have been made to make this work well with gcc4 and helping resolve the
> issue in the long term for upstream as well.
>
>>
>> Once more, here is the fixed memtest86+ for F10. It works just fine (for
>> me) even on new Intel G45.
>>
>> http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm>
>>
>> I would appreciate if someone could take a look at it.
>>
>
> Apply to be a co-maintainer and you will be able to fix it directly.
>
>
OK. Should I send a message to the maintainer first, or just "add myself to
package"
is enough (and wait for a reply)?

Also, I looked at the bugs and I the only one I do not know how to solve
is how to add the grub entry at the end of the file. I tried that in the
past
and never managed to write it other than as the first entry.

Do you know if this is possible at all?

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/e3004fa4/attachment.htm>

From rakesh.pandit at gmail.com  Wed Jan  7 12:07:30 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 7 Jan 2009 17:37:30 +0530
Subject: Plan for tomorrows (20090107) FESCO meeting
In-Reply-To: <1231265611.20019.5.camel@localhost.localdomain>
References: <1231265611.20019.5.camel@localhost.localdomain>
Message-ID: <b401d2530901070407x6dd60512t3636dec41f5f296d@mail.gmail.com>

2009/1/6 Brian Pepple <bpepple at fedoraproject.org>:
> Hi,
>
[..]
>
> /topic FESCO-Meeting -- Features --
> https://fedoraproject.org/wiki/Features/KDE42
>
> 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.
>

https://fedoraproject.org/wiki/Features/ReviewOMatic

I would like this to be considered for feature vote this meet if
possible. It is still in FeatureReadyForWrangler state. It was pushed
back to FeaturePageIncomplete because of lack for "Release Notes"
section. As this is a feature which wouldn't impact directly the end
users, this section seemed irrelevant. Is this essential for every
feature ? If yes, we can think of it later (depending upon decision
though :) and write down.

May this feature be considered for voting this meet?

-- 
rakesh



From j.w.r.degoede at hhs.nl  Wed Jan  7 12:32:05 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 07 Jan 2009 13:32:05 +0100
Subject: xzgv in Fedora broken?
In-Reply-To: <68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
	<49637369.1010302@hhs.nl>	<49637778.3@fedoraproject.org>
	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
Message-ID: <4964A0C5.6050708@hhs.nl>

Paulo Cavalcanti wrote:
> 
> 
> On Tue, Jan 6, 2009 at 1:23 PM, Rahul Sundaram 
> <sundaram at fedoraproject.org <mailto:sundaram at fedoraproject.org>> wrote:
> 
>     Hans de Goede wrote:
> 
>         Note I'm looking in to fixing the xzgv thumbnails issue. Why? To
>         show that actually reporting problems helps I guess.
> 
> 
>     Thanks Hans. It is amazing, people who knew about the issue would be
>     not reporting the bug but be willing to build conflicting packages
>     in another repository.
> 
> 
> 
> Please, Rahul
> 
> xzgv does not impact anything. 
> 

True, never the less I've fixed it: a gtk callback functions return value was 
declared void while it should be gboolean and it should return TRUE, that this 
worked with gcc3 is just plain luck.

A patch is forth coming, I'm still looking into some of the thumbnails being 
wrong for images whose width is not a multiple of 4. Its a pitch/stride != 
width issue, and I've already located it, but it needs some surgery to fix cleanly.

> Once more, here is the fixed memtest86+ for F10. 
> It works just fine (for me) even on new Intel G45.
> 
> http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm
> 

Yes this is a more important issue, thanks for bringing it to our attention. 
First of all it would help if you could post a patch with your prepared fix, 
that is less cumbersome to take a quick peek then an srpm. This is important 
because, for example yesterday I clicked at the bug report you linked and when 
only seeing srpm's went on with other stuff. If there would have been a patch 
attached I would have clicked it, and if it is cleanly I would have tried to 
get it in to Fedora asap. But the srpm was just too big of a hurdle (given that 
memtest is not a package I maintain, nor is xzgv btw).

Thanks & Regards,

Hans



From j.w.r.degoede at hhs.nl  Wed Jan  7 12:34:36 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 07 Jan 2009 13:34:36 +0100
Subject: xzgv in Fedora broken?
In-Reply-To: <68720af30901070301j2df3434dha5205183261fcbc7@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com>
	<200901050854.18189.konrad@tylerc.org>	<20090106082024.GB4061@victor.nirvana>	<49631559.8060003@fedoraproject.org>	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>	<49633EA3.6030207@fedoraproject.org>
	<49637369.1010302@hhs.nl>	<49637778.3@fedoraproject.org>	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>	<49648126.9000904@fedoraproject.org>
	<68720af30901070301j2df3434dha5205183261fcbc7@mail.gmail.com>
Message-ID: <4964A15C.1090008@hhs.nl>

Paulo Cavalcanti wrote:
> 
> 
> On Wed, Jan 7, 2009 at 8:17 AM, Rahul Sundaram 
> <sundaram at fedoraproject.org <mailto:sundaram at fedoraproject.org>> wrote:
> 
>     Paulo Cavalcanti wrote:
> 
>         Please, Rahul
> 
>         xzgv does not impact anything.
> 
> 
>     Maybe it doesn't but someone has went through the effort of a
>     workaround in a different repository while being aware of the issue.
>     That effort could have been made to make this work well with gcc4
>     and helping resolve the issue in the long term for upstream as well.
> 
> 
>         Once more, here is the fixed memtest86+ for F10. It works just
>         fine (for me) even on new Intel G45.
> 
>         http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm
>         <http://people.atrpms.net/%7Epcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm>
> 
>         I would appreciate if someone could take a look at it.
> 
> 
>     Apply to be a co-maintainer and you will be able to fix it directly.
> 
> 
> OK. Should I send a message to the maintainer first, or just "add myself 
> to package"
> is enough (and wait for a reply)?
> 

There are no written rules, personally I would write a mail saying you want to 
become a co-maintainer, and then when he says ok, apply for the necessary 
rights in pkgdb.

If he does not respond in a few days (which I do not say he will do, but that 
happens some time). Send a mail to this list complaining about it, then I'm 
sore someone (me for example) will try to get things sorted out.

> Also, I looked at the bugs and I the only one I do not know how to solve
> is how to add the grub entry at the end of the file. I tried that in the 
> past
> and never managed to write it other than as the first entry.
> 

That is great news (not about the grub bug, but that you know how to solve all 
others)!

Keep up the good work.

Regards,

Hans



From jeff at ocjtech.us  Wed Jan  7 13:35:07 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Wed, 7 Jan 2009 07:35:07 -0600
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <49648220.7050209@redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
Message-ID: <935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>

On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>
> I guess it depends how much we care about being close to upstream for this.
> If it's worth the effort to move these to libexec, then perhaps putting
> compatibility symlinks in place for a couple of releases (with a clear
> relnote that they will be removed in a future release and scripts need
> updating) could be a way to handle the transition?

Adding symlinks does nothing to help, it just delays the pain because
people won't read the release notes or won't bother to fix their
scripts until the symlinks disappear.  Fixing the scripts is trivial,
and backwards compatible to boot.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From ntroncos at gmail.com  Wed Jan  7 13:41:38 2009
From: ntroncos at gmail.com (Nicolas Troncoso)
Date: Wed, 7 Jan 2009 10:41:38 -0300
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
Message-ID: <a8b1764d0901070541s2ce70942kcc71705b8511cf11@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:35 AM, Jeffrey Ollie <jeff at ocjtech.us> wrote:
> On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>>
>> I guess it depends how much we care about being close to upstream for this.
>> If it's worth the effort to move these to libexec, then perhaps putting
>> compatibility symlinks in place for a couple of releases (with a clear
>> relnote that they will be removed in a future release and scripts need
>> updating) could be a way to handle the transition?
>
> Adding symlinks does nothing to help, it just delays the pain because
> people won't read the release notes or won't bother to fix their
> scripts until the symlinks disappear.  Fixing the scripts is trivial,
> and backwards compatible to boot.

I fully agree with jeff in this topic. In my expirience when you get
"temporal" basis fixes in they turn out to be permanent. Rawhide
users should feel the pain and get them fixed, the sooner the better.

cheers

-- 
Nicol?s Troncoso Carr?re



From bmr at redhat.com  Wed Jan  7 13:43:28 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Wed, 07 Jan 2009 13:43:28 +0000
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
Message-ID: <4964B180.8020009@redhat.com>

Jeffrey Ollie wrote:
> On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>> I guess it depends how much we care about being close to upstream for this.
>> If it's worth the effort to move these to libexec, then perhaps putting
>> compatibility symlinks in place for a couple of releases (with a clear
>> relnote that they will be removed in a future release and scripts need
>> updating) could be a way to handle the transition?
> 
> Adding symlinks does nothing to help, it just delays the pain because
> people won't read the release notes or won't bother to fix their
> scripts until the symlinks disappear.  Fixing the scripts is trivial,
> and backwards compatible to boot.
> 

No, but having an entry in the release notes for a release or two gives 
something more concrete to point at and say "I told you so" than an 
announcement on the fedora-devel lists which are not read by most users 
(yes, I know that this was announced three years ago upstream, but the 
same comment regarding users not reading things applies).

Since we carried the package with non-upstream default paths for these 
files for some time, I think we (Fedora) have some responsibility to 
clearly tell our users that we are now bringing things back into line 
with upstream.

I don't have any issue either way, my scripts have long used the new 
conventions but I think this would be helpful to at least some.

Regards,
Bryn.



From promac at gmail.com  Wed Jan  7 14:00:37 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 7 Jan 2009 12:00:37 -0200
Subject: xzgv in Fedora broken?
In-Reply-To: <4964A0C5.6050708@hhs.nl>
References: <4960CEAA.4070507@gmail.com> <200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org> <49637369.1010302@hhs.nl>
	<49637778.3@fedoraproject.org>
	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
	<4964A0C5.6050708@hhs.nl>
Message-ID: <68720af30901070600y72aa4863u9c2794d0a8a16558@mail.gmail.com>

On Wed, Jan 7, 2009 at 10:32 AM, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:

> Paulo Cavalcanti wrote:
>
>>
>>
>> On Tue, Jan 6, 2009 at 1:23 PM, Rahul Sundaram <
>> sundaram at fedoraproject.org <mailto:sundaram at fedoraproject.org>> wrote:
>>
>>    Hans de Goede wrote:
>>
>>        Note I'm looking in to fixing the xzgv thumbnails issue. Why? To
>>        show that actually reporting problems helps I guess.
>>
>>
>>    Thanks Hans. It is amazing, people who knew about the issue would be
>>    not reporting the bug but be willing to build conflicting packages
>>    in another repository.
>>
>>
>>
>> Please, Rahul
>>
>> xzgv does not impact anything.
>>
>
> True, never the less I've fixed it: a gtk callback functions return value
> was declared void while it should be gboolean and it should return TRUE,
> that this worked with gcc3 is just plain luck.
>
> A patch is forth coming, I'm still looking into some of the thumbnails
> being wrong for images whose width is not a multiple of 4. Its a
> pitch/stride != width issue, and I've already located it, but it needs some
> surgery to fix cleanly.
>

You are good. I thought it would take longer.



>
>
>  Once more, here is the fixed memtest86+ for F10. It works just fine (for
>> me) even on new Intel G45.
>>
>> http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm>
>>
>>
> Yes this is a more important issue, thanks for bringing it to our
> attention. First of all it would help if you could post a patch with your
> prepared fix, that is less cumbersome to take a quick peek then an srpm.
> This is important because, for example yesterday I clicked at the bug report
> you linked and when only seeing srpm's went on with other stuff. If there
> would have been a patch attached I would have clicked it, and if it is
> cleanly I would have tried to get it in to Fedora asap. But the srpm was
> just too big of a hurdle (given that memtest is not a package I maintain,
> nor is xzgv btw).
>
>
Here are the differences using Fedora original spec (although the .src.rpm
is slightly different):

http://people.atrpms.net/~pcavalcanti/patches/spec.patch

http://people.atrpms.net/~pcavalcanti/patches/setup.patch

The fix is simple, and the grub entry is going to be this way:


title Memtest86+ v2.11
        kernel --type=netbsd /memtest86+-2.11


It has been working fine for me, with a lot of different computers,
for about two years.

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/7c19ba34/attachment.htm>

From promac at gmail.com  Wed Jan  7 14:14:15 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 7 Jan 2009 12:14:15 -0200
Subject: xzgv in Fedora broken?
In-Reply-To: <68720af30901070600y72aa4863u9c2794d0a8a16558@mail.gmail.com>
References: <4960CEAA.4070507@gmail.com> <20090106082024.GB4061@victor.nirvana>
	<49631559.8060003@fedoraproject.org>
	<68720af30901060249k1a200a9fw43e9672f6884b9a5@mail.gmail.com>
	<49633EA3.6030207@fedoraproject.org> <49637369.1010302@hhs.nl>
	<49637778.3@fedoraproject.org>
	<68720af30901070148r246e6b10p3195311c13375379@mail.gmail.com>
	<4964A0C5.6050708@hhs.nl>
	<68720af30901070600y72aa4863u9c2794d0a8a16558@mail.gmail.com>
Message-ID: <68720af30901070614v71bcbe78id7b8bf02cd0bc945@mail.gmail.com>

On Wed, Jan 7, 2009 at 12:00 PM, Paulo Cavalcanti <promac at gmail.com> wrote:

>
>
> On Wed, Jan 7, 2009 at 10:32 AM, Hans de Goede <j.w.r.degoede at hhs.nl>wrote:
>
>> Paulo Cavalcanti wrote:
>>
>>>
>>>
>>> On Tue, Jan 6, 2009 at 1:23 PM, Rahul Sundaram <
>>> sundaram at fedoraproject.org <mailto:sundaram at fedoraproject.org>> wrote:
>>>
>>>    Hans de Goede wrote:
>>>
>>>        Note I'm looking in to fixing the xzgv thumbnails issue. Why? To
>>>        show that actually reporting problems helps I guess.
>>>
>>>
>>>    Thanks Hans. It is amazing, people who knew about the issue would be
>>>    not reporting the bug but be willing to build conflicting packages
>>>    in another repository.
>>>
>>>
>>>
>>> Please, Rahul
>>>
>>> xzgv does not impact anything.
>>>
>>
>> True, never the less I've fixed it: a gtk callback functions return value
>> was declared void while it should be gboolean and it should return TRUE,
>> that this worked with gcc3 is just plain luck.
>>
>> A patch is forth coming, I'm still looking into some of the thumbnails
>> being wrong for images whose width is not a multiple of 4. Its a
>> pitch/stride != width issue, and I've already located it, but it needs some
>> surgery to fix cleanly.
>>
>
> You are good. I thought it would take longer.
>
>
>
>>
>>
>>  Once more, here is the fixed memtest86+ for F10. It works just fine (for
>>> me) even on new Intel G45.
>>>
>>>
>>> http://people.atrpms.net/~pcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm<http://people.atrpms.net/%7Epcavalcanti/srpms/memtest86+-2.11-3.fc10.src.rpm>
>>>
>>>
>> Yes this is a more important issue, thanks for bringing it to our
>> attention. First of all it would help if you could post a patch with your
>> prepared fix, that is less cumbersome to take a quick peek then an srpm.
>> This is important because, for example yesterday I clicked at the bug report
>> you linked and when only seeing srpm's went on with other stuff. If there
>> would have been a patch attached I would have clicked it, and if it is
>> cleanly I would have tried to get it in to Fedora asap. But the srpm was
>> just too big of a hurdle (given that memtest is not a package I maintain,
>> nor is xzgv btw).
>>
>>
> Here are the differences using Fedora original spec (although the .src.rpm
> is slightly different):
>
> http://people.atrpms.net/~pcavalcanti/patches/spec.patch<http://people.atrpms.net/%7Epcavalcanti/patches/spec.patch>
>
> http://people.atrpms.net/~pcavalcanti/patches/setup.patch<http://people.atrpms.net/%7Epcavalcanti/patches/setup.patch>
>
> The fix is simple, and the grub entry is going to be this way:
>
>
> title Memtest86+ v2.11
>         kernel --type=netbsd /memtest86+-2.11
>
>
> It has been working fine for me, with a lot of different computers,
> for about two years.
>
>
>

I would like to add that I always have a /boot partition.

I never tested it with a different configuration (without /boot, for
instance) or
using lvm. Maybe nothing does change, but this is why I always avoided to
to get involved, because I do not have how to test all of the
configurations.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/0847e78a/attachment.htm>

From jorton at redhat.com  Wed Jan  7 15:18:12 2009
From: jorton at redhat.com (Joe Orton)
Date: Wed, 7 Jan 2009 15:18:12 +0000
Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
Message-ID: <20090107151812.GA12074@redhat.com>

The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by 
default.  Apache httpd uses one epoll fd ("instance") per child process, 
so this sets a hard limit on 128 children (i.e. 100 concurrent clients) 
out of the box.

1) shouldn't this be an rlimit so that we can bump it appropriately in 
the parent as root?

2) can we get it tweaked in the default sysctl.conf to be something more 
sane, e.g. 1024?

Regards, Joe



From tmz at pobox.com  Wed Jan  7 15:32:52 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 7 Jan 2009 10:32:52 -0500
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <4964B180.8020009@redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
Message-ID: <20090107153251.GA21007@inocybe.teonanacatl.org>

Bryn M. Reeves wrote:
> Since we carried the package with non-upstream default paths for
> these files for some time, I think we (Fedora) have some
> responsibility to clearly tell our users that we are now bringing
> things back into line with upstream.

This change isn't planned to go to any of the stable branches, so it
only affects rawhide users.  And for that, I think announcing it here
as well as clearly in the in package %changelog is pretty reasonable.
This can be added to the F-11 release notes too if folks think it's
important enough.

FWIW, We really didn't carry git with non-upstream paths for long.
The change upstream was made with the 1.6.0 release (August 17, 2008).
We discussed changing the path then (on this list), but it was decided
to wait.  Now, we've made the change in the devel branch rather early
in the cycle, so there's plenty of time for rawhide users to adapt and
have some release notes added to let those users who read them take
notice (though the cynic in me says that number is dreadfully low ;).

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The average woman would rather be beautiful than smart because the
average man can see better than he can think.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/edc8b76b/attachment.sig>

From bmr at redhat.com  Wed Jan  7 15:37:28 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Wed, 07 Jan 2009 15:37:28 +0000
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090107153251.GA21007@inocybe.teonanacatl.org>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>	<49648220.7050209@redhat.com>	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>	<4964B180.8020009@redhat.com>
	<20090107153251.GA21007@inocybe.teonanacatl.org>
Message-ID: <4964CC38.7010303@redhat.com>

Todd Zullinger wrote:
> Bryn M. Reeves wrote:
>> Since we carried the package with non-upstream default paths for
>> these files for some time, I think we (Fedora) have some
>> responsibility to clearly tell our users that we are now bringing
>> things back into line with upstream.
> 
> This change isn't planned to go to any of the stable branches, so it
> only affects rawhide users.  And for that, I think announcing it here
> as well as clearly in the in package %changelog is pretty reasonable.
> This can be added to the F-11 release notes too if folks think it's
> important enough.
> 
> FWIW, We really didn't carry git with non-upstream paths for long.
> The change upstream was made with the 1.6.0 release (August 17, 2008).

I'm sorry - I'd mistaken the deprecation announcement for the change 
itself. My bad.

> We discussed changing the path then (on this list), but it was decided
> to wait.  Now, we've made the change in the devel branch rather early
> in the cycle, so there's plenty of time for rawhide users to adapt and
> have some release notes added to let those users who read them take
> notice (though the cynic in me says that number is dreadfully low ;).

It is :) And the cynic in me says that the main point in release-noting 
things is to have something to point at when users start complaining 
about changes they don't like..

I don't have strong feelings on this though, and I know my own scripts 
will carry on working fine. ;)

Bryn.



From dledford at redhat.com  Wed Jan  7 15:50:14 2009
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 07 Jan 2009 10:50:14 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <4963DD10.1060002@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
	<4963DD10.1060002@gmail.com>
Message-ID: <1231343414.32405.888.camel@firewall.xsintricity.com>

On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
> Doug Ledford wrote:
> > On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
> 
> >> * Make adherence to the FHS a MUST, with the added exception of
> >>   /usr/<target> for cross toolchains.
> > 
> > I happen to have a few packages that just *can't* follow FHS (unless we
> > opt to ignore FHS and allow a package to install to /opt, but that's
> > always been just as verbotten by the FHS for the initial software
> > distributor versus an ISV as failing to follow any other FHS specified
> > layout).
> > 
> Example SRPMS?  (Or the package name if it's already in cvs).

The main ones are all MPI implementations.  They need per arch and per
version libraries and runtimes.  OpenMPI is in cvs, but hasn't been
updated to my current layout as used in RHEL.  I tried, for about 5
consecutive releases, to adhere to the FHS with that package.  It just
ended up being more problems than could be solved.  The current version
of the package as shipped in RHEL (and there is an example of it in the
Infiniband link in my sig) puts the entire tree under
%{_libdir}/%{name}/%{version}-%{opt_cc}.  While you can *attempt* to get
OpenMPI to work with a FHS standard layout, the two other main MPIs,
mvapich and mvapich2, flat will not work with a FHS layout at all.  They
*must* be installed under a single directory prefix that doesn't
conflict with any other installations.

It's worth noting here that trying to comply with user's requirements
for MPI packages has resulted in exposing short comings of rpm, yum,
repos, etc. relative to MPI user's needs (this isn't to say yum or the
current repo setup is wrong, simply that it doesn't fit their needs
properly).  Users of MPI packages often times need multiple versions of
the same MPI installed (for example, OpenMPI-1.1 and OpenMPI-1.2, I
recently had to create an openmpi11 compat package for this very reason
since the update mechanism won't allow me to simply stuff openmpi-1.1
and openmpi-1.2 into the channel at the same time, but that's exactly
what I needed).  They also sometimes need MPIs compiled with compilers
other than gcc in order to link/run with their various apps.  Hence the
naming of the directory hierarchy for OpenMPI.

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/0d505632/attachment.sig>

From silfreed at silfreed.net  Wed Jan  7 16:34:41 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Wed, 07 Jan 2009 11:34:41 -0500
Subject: vim syntax file packaging
In-Reply-To: <20090101165645.GA3821@voltron>
References: <20090101165645.GA3821@voltron>
Message-ID: <4964D9A1.6010408@silfreed.net>

Nikolay Vladimirov wrote:
> Hi!
> 
> I was wondering if there is a proper way of packaging vim syntax
> files. 
> When I did ' yum whatprovides \*.vim ' I saw 4 ways of doing this:
> 
> 1) Add the files to /usr/share/vim/vim71/ftdetect/ and
> /usr/share/vim/vim71/ftplugin/. One package even provides a 
> subpackage only for the vim syntax. I think this is done because the
> subpackage can require vim. which is reasonable if you install a vim
> syntax file.  
> 2) Add them in /usr/share/doc/packagename
> 3) Add them in /usr/share/packagename
> 4) Distributed with vim-common
> 
> So is there a guideline I missed? 
> Is it for the packager to decide?
> It's good to have at least some 'best practice' note about this. 
> 

Checkout how the syslog-ng package installs it's plugin; it's a big 
kludgy, but works pretty well.

-Doug



From poelstra at redhat.com  Wed Jan  7 16:54:58 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 07 Jan 2009 08:54:58 -0800
Subject: Fedora Release Engineering Meeting Recap 2009-01-05
Message-ID: <4964DE62.3000802@redhat.com>

Full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-jan-05



From poelstra at redhat.com  Wed Jan  7 16:58:18 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 07 Jan 2009 08:58:18 -0800
Subject: [Fwd: bugzilla.redhat.com, hardware.redhat.com Planned Outage | Jan
 09 2009 - 9:00 PM EST]
Message-ID: <4964DF2A.7010800@redhat.com>



-------- Original Message --------
Subject: bugzilla.redhat.com,	hardware.redhat.com Planned Outage | Jan 
09 2009 - 9:00 PM EST
Date: Wed, 7 Jan 2009 11:18:46 -0500
From: Meethune Bhowmick


O U T A G E   R E Q U E S T   F O R M
=====================================

Severity:
Severity Four (Low)/CSR

Scheduled Date:
Jan 09 2009

Scheduled Time:
9:00 PM EST

Estimated Time Required:
1 hour

Performed By:
Engineering Operations

People/Groups Impacted:
Bugzilla Users

Site/Services Affected:
bugzilla.redhat.com, hardware.redhat.com

Impact:
Bugzilla will be temporarily offline while we run updates.

Description:
Running package updates. Hosts will be rebooted.

Signoff:
mschick at redhat.com

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From opensource at till.name  Wed Jan  7 17:18:21 2009
From: opensource at till.name (Till Maas)
Date: Wed, 07 Jan 2009 18:18:21 +0100
Subject: Tracking new review requests?
In-Reply-To: <200901062144.01583.ville.skytta@iki.fi>
References: <200901061431.53501.ville.skytta@iki.fi>
	<9497e9990901060630m52e07213nd36fcca115cf5fe8@mail.gmail.com>
	<200901062144.01583.ville.skytta@iki.fi>
Message-ID: <200901071818.29012.opensource@till.name>

On Tue January 6 2009, Ville Skytt? wrote:
> On Tuesday 06 January 2009, Mat Booth wrote:

> > Not sure how well this works, but maybe you could subscribe to the
> > search results page as a feed:
>
> Thanks, I'll try something like this out.  But I'd still prefer a mail
> solution...

You can get mail for RSS Feeds with rss2email[0], which is  packaged in 
Fedora. But I do not know how readable the RSS feed from Bugzilla is.

Regards,
Till

[0] http://rss2email.infogami.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/54436986/attachment.sig>

From a.badger at gmail.com  Wed Jan  7 17:20:16 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Jan 2009 09:20:16 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <1231343414.32405.888.camel@firewall.xsintricity.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>	<1231278888.32405.845.camel@firewall.xsintricity.com>	<4963DD10.1060002@gmail.com>
	<1231343414.32405.888.camel@firewall.xsintricity.com>
Message-ID: <4964E450.6010909@gmail.com>

Doug Ledford wrote:
> On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
>> Doug Ledford wrote:
>>> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
>>>> * Make adherence to the FHS a MUST, with the added exception of
>>>>   /usr/<target> for cross toolchains.
>>> I happen to have a few packages that just *can't* follow FHS (unless we
>>> opt to ignore FHS and allow a package to install to /opt, but that's
>>> always been just as verbotten by the FHS for the initial software
>>> distributor versus an ISV as failing to follow any other FHS specified
>>> layout).
>>>
>> Example SRPMS?  (Or the package name if it's already in cvs).
> 
> The main ones are all MPI implementations.  They need per arch and per
> version libraries and runtimes.  OpenMPI is in cvs, but hasn't been
> updated to my current layout as used in RHEL.  I tried, for about 5
> consecutive releases, to adhere to the FHS with that package.  It just
> ended up being more problems than could be solved.  The current version
> of the package as shipped in RHEL (and there is an example of it in the
> Infiniband link in my sig) puts the entire tree under
> %{_libdir}/%{name}/%{version}-%{opt_cc}.  While you can *attempt* to get
> OpenMPI to work with a FHS standard layout, the two other main MPIs,
> mvapich and mvapich2, flat will not work with a FHS layout at all.  They
> *must* be installed under a single directory prefix that doesn't
> conflict with any other installations.
> 

openmpi doesn't look too bad.  If this was being reviewed with the FHS
Guideline in mind, these are the questions I'd ask:

/usr/share/openmpi/1.2.4-gcc/help32/openmpi/doc -- Are the files located
here used by the programs at run time?  If so, this is fine.  If not,
they should be in /usr/share/doc (marked as %doc) instead.

/usr/share/openmpi/1.2.4-gcc/man -- Why are these man pages placed here?
 Is it because of conflicts with other mpi implementations?  If so, this
is fine but see my question about environment-modules.  (Note, I think
you have to manually mark these as %doc since they don't live in the
system %{_mandir})

/usr/share/openmpi/1.2.4-gcc/bin32
/usr/share/openmpi/1.2.4-gcc/help32 -- Are these files arch specific?
If so (even if they are text files but arch specific), they cannot go in
/usr/share.  Somewhere under %{_libdir}/openmpi would be better.

%{mode} in directories like /usr/share/openmpi/1.2.4-gcc/bin32 -- if we
place these files in %{_libdir}, can we get rid of the %{mode} for them
since the information will be present in the %{libdir} path?

/usr/share/openmpi/1.2.4-gcc/bin32/*
/usr/lib/openmpi/1.2.4-gcc/openmpi/* -- Do these directories exist
because of file Conflicts with other MPI implementations?  If so, this
seems basically okay but how are users supposed to access these
programs?  How are programs supposed to find the libraries?  Would it be
proper to package an enviroment-modules configuration for switching
between the implementations?

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/20f5abd6/attachment.sig>

From ville.skytta at iki.fi  Wed Jan  7 18:13:22 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 7 Jan 2009 20:13:22 +0200
Subject: Tracking new review requests?
In-Reply-To: <200901071818.29012.opensource@till.name>
References: <200901061431.53501.ville.skytta@iki.fi>
	<200901062144.01583.ville.skytta@iki.fi>
	<200901071818.29012.opensource@till.name>
Message-ID: <200901072013.23018.ville.skytta@iki.fi>

On Wednesday 07 January 2009, Till Maas wrote:
> On Tue January 6 2009, Ville Skytt? wrote:
> > On Tuesday 06 January 2009, Mat Booth wrote:
> > > Not sure how well this works, but maybe you could subscribe to the
> > > search results page as a feed:
> >
> > Thanks, I'll try something like this out.  But I'd still prefer a mail
> > solution...
>
> You can get mail for RSS Feeds with rss2email[0], which is  packaged in
> Fedora.

Hm, could be useful in some scenarios, but sounds too clumsy to me for this 
purpose.

> But I do not know how readable the RSS feed from Bugzilla is. 

Don't know about readability, but after one day of testing it, the feed from 
the query seems useless for my purposes - I got 4 new RSS entries today, none 
of which were new package submissions (I don't know why they were included in 
the first place).  There were at least 3 new package submissions today, none 
of which ended up in the feed as new items.

The gmane topics with excerpts feed looks more promising.
http://rss.gmane.org/topics/complete/gmane.linux.redhat.fedora.reviews



From ville.skytta at iki.fi  Wed Jan  7 18:26:02 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Wed, 7 Jan 2009 20:26:02 +0200
Subject: Tracking new review requests?
In-Reply-To: <gk0la5$1ve$1@ger.gmane.org>
References: <200901061431.53501.ville.skytta@iki.fi>
	<gk0la5$1ve$1@ger.gmane.org>
Message-ID: <200901072026.02756.ville.skytta@iki.fi>

On Wednesday 07 January 2009, Pavel Alexeev (aka Pahan-Hubbitus) wrote:

> May be this is more easy make on user side? I read fedora-package-review 
> in Thunderbird through nntp protocol

Thanks for the suggestion, but I use kmail which unfortunately does not have 
support for NNTP (or RSS) as far as I know, so this is not an option.  Nor is 
using a different mail client or a dedicated NNTP reader only for this 
purpose, and I'm not planning to switch completely away from kmail either...



From dledford at redhat.com  Wed Jan  7 18:44:20 2009
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 07 Jan 2009 13:44:20 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <4964E450.6010909@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
	<4963DD10.1060002@gmail.com>
	<1231343414.32405.888.camel@firewall.xsintricity.com>
	<4964E450.6010909@gmail.com>
Message-ID: <1231353860.32405.916.camel@firewall.xsintricity.com>

On Wed, 2009-01-07 at 09:20 -0800, Toshio Kuratomi wrote:
> Doug Ledford wrote:
> > On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
> >> Doug Ledford wrote:
> >>> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
> >>>> * Make adherence to the FHS a MUST, with the added exception of
> >>>>   /usr/<target> for cross toolchains.
> >>> I happen to have a few packages that just *can't* follow FHS (unless we
> >>> opt to ignore FHS and allow a package to install to /opt, but that's
> >>> always been just as verbotten by the FHS for the initial software
> >>> distributor versus an ISV as failing to follow any other FHS specified
> >>> layout).
> >>>
> >> Example SRPMS?  (Or the package name if it's already in cvs).
> > 
> > The main ones are all MPI implementations.  They need per arch and per
> > version libraries and runtimes.  OpenMPI is in cvs, but hasn't been
> > updated to my current layout as used in RHEL.  I tried, for about 5
> > consecutive releases, to adhere to the FHS with that package.  It just
> > ended up being more problems than could be solved.  The current version
> > of the package as shipped in RHEL (and there is an example of it in the
> > Infiniband link in my sig) puts the entire tree under
> > %{_libdir}/%{name}/%{version}-%{opt_cc}.  While you can *attempt* to get
> > OpenMPI to work with a FHS standard layout, the two other main MPIs,
> > mvapich and mvapich2, flat will not work with a FHS layout at all.  They
> > *must* be installed under a single directory prefix that doesn't
> > conflict with any other installations.
> > 
> 
> openmpi doesn't look too bad.  If this was being reviewed with the FHS
> Guideline in mind, these are the questions I'd ask:

As mentioned in my original mail, you are looking at the older version
of OpenMPI in Fedora CVS, where as the version on my people.redhat.com
page for RHEL is both A) significantly newer and B) has a vastly
different file layout because the file layout you are seeing in the
Fedora CVS version of the package proved to be impossible to get
completely right.

However, even though you are referencing a layout that proved not to be
effective, I'll address your questions because I think the answers might
point out why it's so hard to get OpenMPI right:


> /usr/share/openmpi/1.2.4-gcc/help32/openmpi/doc -- Are the files
> located
> here used by the programs at run time?  If so, this is fine.  If not,
> they should be in /usr/share/doc (marked as %doc) instead.

Yes, they are used by the runtime.  In particular, ompi_info --all will
read all the available options for the different modules that OpenMPI
actually has built.  As the modules that a person builds is build time
configured, the OpenMPI architecture was set up so that each module
could just stick its relevant help info in these files, and the run time
help system will read the files as installed by the various modules.


> /usr/share/openmpi/1.2.4-gcc/man -- Why are these man pages placed
> here?
>  Is it because of conflicts with other mpi implementations?  If so,
> this
> is fine but see my question about environment-modules.  (Note, I think
> you have to manually mark these as %doc since they don't live in the
> system %{_mandir})

Yes, they conflict with other MPI installations.  In my current spec
file I don't mark them as %doc (you can't as far as I know, because the
%doc macro includes a step to copy the files into /usr/share/doc and as
such can't be used on anything *but* doc files), but I did have to
manually compress them in the %install section because they aren't in
the system mandir.


> /usr/share/openmpi/1.2.4-gcc/bin32
> /usr/share/openmpi/1.2.4-gcc/help32 -- Are these files arch specific?
> If so (even if they are text files but arch specific), they cannot go
> in
> /usr/share.  Somewhere under %{_libdir}/openmpi would be better.

Yes.  But more than just arch specific, they are openmpi version
specific and as I pointed out in my original explanation, users often
need multiple versions of openmpi installed.  So, if I were to put the
binaries in /usr/bin, not only would I have to encode the arch, but also
the version into the binary name.  This would then need to be aliased
via something like the alternatives system.  I tried that.  It was a
*horrible* mess to try and maintain and resulted in several broken
updates.  So, putting the binaries for a specific arch/version into a
unique path and then using path manipulation to control use was much
cleaner.  In addition, the help32/*-wrapper-data.txt files are used by
the devel environment to pull the default gcc compile/link flags for a
given arch.

> %{mode} in directories like /usr/share/openmpi/1.2.4-gcc/bin32 -- if
> we
> place these files in %{_libdir}, can we get rid of the %{mode} for
> them
> since the information will be present in the %{libdir} path?

Yes.  This has been done in the latest spec file.

> /usr/share/openmpi/1.2.4-gcc/bin32/*
> /usr/lib/openmpi/1.2.4-gcc/openmpi/* -- Do these directories exist
> because of file Conflicts with other MPI implementations?  If so, this
> seems basically okay but how are users supposed to access these
> programs?  How are programs supposed to find the libraries?  Would it
> be
> proper to package an enviroment-modules configuration for switching
> between the implementations?

Yes, there are file conflicts not only with other MPI implementations,
but different versions of the same MPI, and also the same MPI compiled
with different compilers.

In the current setup, access if via either mpi-selector (a glorified
alternatives setup that uses paths instead of links to solve the
problem) as well as environment-modules.  When I bring the current stuff
over to Fedora, the mpi-selector setup will get dropped and only
environment-modules selection will be supported.

The libraries are found via an LD_LIBRARY_PATH setup created by either
the mpi-selector or environment-modules usage.  The man pages are found
by placing the mandir and the bindir in the same top level directory.
In the case that <prefix>/bin/<command-name> has a matching
<prefix>/man/man?/<command-name>* man page, man automatically finds it
without having to manipulate the manpath or other settings.

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/f895bd8f/attachment.sig>

From a.badger at gmail.com  Wed Jan  7 19:30:36 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Jan 2009 11:30:36 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <1231353860.32405.916.camel@firewall.xsintricity.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>	<1231278888.32405.845.camel@firewall.xsintricity.com>	<4963DD10.1060002@gmail.com>	<1231343414.32405.888.camel@firewall.xsintricity.com>	<4964E450.6010909@gmail.com>
	<1231353860.32405.916.camel@firewall.xsintricity.com>
Message-ID: <496502DC.4070603@gmail.com>

Doug Ledford wrote:
> On Wed, 2009-01-07 at 09:20 -0800, Toshio Kuratomi wrote:
>> Doug Ledford wrote:
>>> On Tue, 2009-01-06 at 14:37 -0800, Toshio Kuratomi wrote:
>>>> Doug Ledford wrote:
>>>>> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote:
>>>>>> * Make adherence to the FHS a MUST, with the added exception of
>>>>>>   /usr/<target> for cross toolchains.
>>>>> I happen to have a few packages that just *can't* follow FHS (unless we
>>>>> opt to ignore FHS and allow a package to install to /opt, but that's
>>>>> always been just as verbotten by the FHS for the initial software
>>>>> distributor versus an ISV as failing to follow any other FHS specified
>>>>> layout).
>>>>>
>>>> Example SRPMS?  (Or the package name if it's already in cvs).
>>> The main ones are all MPI implementations.  They need per arch and per
>>> version libraries and runtimes.  OpenMPI is in cvs, but hasn't been
>>> updated to my current layout as used in RHEL.  I tried, for about 5
>>> consecutive releases, to adhere to the FHS with that package.  It just
>>> ended up being more problems than could be solved.  The current version
>>> of the package as shipped in RHEL (and there is an example of it in the
>>> Infiniband link in my sig) puts the entire tree under
>>> %{_libdir}/%{name}/%{version}-%{opt_cc}.  While you can *attempt* to get
>>> OpenMPI to work with a FHS standard layout, the two other main MPIs,
>>> mvapich and mvapich2, flat will not work with a FHS layout at all.  They
>>> *must* be installed under a single directory prefix that doesn't
>>> conflict with any other installations.
>>>
>> openmpi doesn't look too bad.  If this was being reviewed with the FHS
>> Guideline in mind, these are the questions I'd ask:
> 
> As mentioned in my original mail, you are looking at the older version
> of OpenMPI in Fedora CVS, where as the version on my people.redhat.com
> page for RHEL is both A) significantly newer and B) has a vastly
> different file layout because the file layout you are seeing in the
> Fedora CVS version of the package proved to be impossible to get
> completely right.
> 
If it's on your people.redhat.com account, could you post a link?  The
index.html you have up doesn't have a link to this package.

> However, even though you are referencing a layout that proved not to be
> effective, I'll address your questions because I think the answers might
> point out why it's so hard to get OpenMPI right:
> 
> 
>> /usr/share/openmpi/1.2.4-gcc/help32/openmpi/doc -- Are the files
>> located
>> here used by the programs at run time?  If so, this is fine.  If not,
>> they should be in /usr/share/doc (marked as %doc) instead.
> 
> Yes, they are used by the runtime.  In particular, ompi_info --all will
> read all the available options for the different modules that OpenMPI
> actually has built.  As the modules that a person builds is build time
> configured, the OpenMPI architecture was set up so that each module
> could just stick its relevant help info in these files, and the run time
> help system will read the files as installed by the various modules.
> 
Cool.  So that's fine.
> 
>> /usr/share/openmpi/1.2.4-gcc/man -- Why are these man pages placed
>> here?
>>  Is it because of conflicts with other mpi implementations?  If so,
>> this
>> is fine but see my question about environment-modules.  (Note, I think
>> you have to manually mark these as %doc since they don't live in the
>> system %{_mandir})
> 
> Yes, they conflict with other MPI installations.

So with environment-modules, this is fine too.

  In my current spec
> file I don't mark them as %doc (you can't as far as I know, because the
> %doc macro includes a step to copy the files into /usr/share/doc and as
> such can't be used on anything *but* doc files), but I did have to
> manually compress them in the %install section because they aren't in
> the system mandir.
> 
This was untrue when I first learned to package but I haven't tested
recently.  If you give a relative path to %doc it copies as you say.  If
you give an absolute path to %doc, it just marks the file as being a doc
file.

> 
>> /usr/share/openmpi/1.2.4-gcc/bin32
>> /usr/share/openmpi/1.2.4-gcc/help32 -- Are these files arch specific?
>> If so (even if they are text files but arch specific), they cannot go
>> in
>> /usr/share.  Somewhere under %{_libdir}/openmpi would be better.
> 
> Yes.  But more than just arch specific, they are openmpi version
> specific and as I pointed out in my original explanation, users often
> need multiple versions of openmpi installed.

Yep, agreed.

>  So, if I were to put the
> binaries in /usr/bin, not only would I have to encode the arch, but also
> the version into the binary name.  This would then need to be aliased
> via something like the alternatives system.

As you found, alternatives is the wrong solution for this.  These are
being used by users who might not be the system admin.

>> %{mode} in directories like /usr/share/openmpi/1.2.4-gcc/bin32 -- if
>> we
>> place these files in %{_libdir}, can we get rid of the %{mode} for
>> them
>> since the information will be present in the %{libdir} path?
> 
> Yes.  This has been done in the latest spec file.
> 
>> /usr/share/openmpi/1.2.4-gcc/bin32/*
>> /usr/lib/openmpi/1.2.4-gcc/openmpi/* -- Do these directories exist
>> because of file Conflicts with other MPI implementations?  If so, this
>> seems basically okay but how are users supposed to access these
>> programs?  How are programs supposed to find the libraries?  Would it
>> be
>> proper to package an enviroment-modules configuration for switching
>> between the implementations?
> 
> Yes, there are file conflicts not only with other MPI implementations,
> but different versions of the same MPI, and also the same MPI compiled
> with different compilers.
> 
> In the current setup, access if via either mpi-selector (a glorified
> alternatives setup that uses paths instead of links to solve the
> problem) as well as environment-modules.  When I bring the current stuff
> over to Fedora, the mpi-selector setup will get dropped and only
> environment-modules selection will be supported.
> 
> The libraries are found via an LD_LIBRARY_PATH setup created by either
> the mpi-selector or environment-modules usage.  The man pages are found
> by placing the mandir and the bindir in the same top level directory.
> In the case that <prefix>/bin/<command-name> has a matching
> <prefix>/man/man?/<command-name>* man page, man automatically finds it
> without having to manipulate the manpath or other settings.
> 

So, with the exception of the arch-specific files in %{_datadir} which
has changed for the new release, this seems to be FHS-kosher to me.  If
you can get me a link to the new package I can take a look and see if
the situation there is worse.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/ca63c12a/attachment.sig>

From dledford at redhat.com  Wed Jan  7 21:25:39 2009
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 07 Jan 2009 16:25:39 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <496502DC.4070603@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
	<4963DD10.1060002@gmail.com>
	<1231343414.32405.888.camel@firewall.xsintricity.com>
	<4964E450.6010909@gmail.com>
	<1231353860.32405.916.camel@firewall.xsintricity.com>
	<496502DC.4070603@gmail.com>
Message-ID: <1231363539.32405.962.camel@firewall.xsintricity.com>

On Wed, 2009-01-07 at 11:30 -0800, Toshio Kuratomi wrote:
> If it's on your people.redhat.com account, could you post a link?  The
> index.html you have up doesn't have a link to this package.

It's found by going to the second link in my sig, the one about
Infiniband specific rpms.  Under there, the rhel5.3 rpms are present,
and you can find the openmpi src rpm at this location:

http://people.redhat.com/dledford/Infiniband/rhel5.3/src/

Ignore the bits in the spec file that deal with cleaning up all the
previous, busted usage of alternatives.  Or not if you want to see just
how much of a mess it made :-/

> So, with the exception of the arch-specific files in %{_datadir} which
> has changed for the new release, this seems to be FHS-kosher to me.  If
> you can get me a link to the new package I can take a look and see if
> the situation there is worse.

Well, not really (unless the FHS changed since I last read it).  The
solution was to create an %{mpidir} macro that was
%{name}/%{version}-%{opt_cc} and use %{_libdir}/%{mpidir} as a prefix
for the entire install.  So, libraries, binaries, man pages, etc config
files, they all reside under %{_lidbir}/%{mpidir}.  That's an acceptable
layout for things in /opt according to the FHS, but not for distribution
provided files in %{_libdir}, and distribution provided files are
prohibited from being placed in /opt.  Hence the conundrum.

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/c7d8d087/attachment.sig>

From mike.cloaked at gmail.com  Wed Jan  7 21:28:22 2009
From: mike.cloaked at gmail.com (Mike)
Date: Wed, 7 Jan 2009 21:28:22 +0000 (UTC)
Subject: F10/11 and Intel Integrated Graphics?
Message-ID: <loom.20090107T211629-323@post.gmane.org>

I have installed F10 on 8 machines - on 6 of them it was fine and there were no
major issues during install. On those machines Fedora running with a gnome
desktop is excellent (apart from one or two issues with upstream gnome
regressions such as no ability to save desktop sessions!)

However on two machines, one of which is only 3 years old and is a Dell 5150
with 82945G integrated graphics, it was a mess when it came to graphics - and
the other machine was a Dell Dimension 2400 a little older with 82845G graphics
which was also non-trivial to get installed.

I now have them working with quite a lot of effort using the vesa driver rather
than the intel driver. However, despite the fact that I am an experienced Fedora
user/admin, this taxed me a considerable amount and I was ready to throw the
boxes in the bin at one or two points in time. I know there are outstanding bz
reports concerning both these chipsets, and they go back some way before F9
without a proper resolution.

An inexperienced new user to Linux trying an install of F10 to a machine with
either of these chipsets would likely get a very bad impression of Fedora, since
it is easy to end up with a non-functioning screen and keyboard, and the "intel"
driver issue needs to be properly fixed since there must be a non-trivial number
of users who have machines with those graphics chips.

Can someone tell me what the state of development, if any, there is concerning
getting a fixed intel graphics driver (xorg-x11-drv-i810) either as an update
for F10 or fixed in time for F11 release.

I believe that having a new user install an up-to-date version of Fedora from a
DVD or CD set or LiveCD and end up with a blank screen and unresponsive
keyboard/mouse would be very disheartening at best and give a very bad press to
Fedora at worst.

I'd be interested to hear what the general view about this is? F10 is really
excellent when it works but this kind of problem is really serious and should
not be ignored. 



From tomek at pipebreaker.pl  Wed Jan  7 21:48:23 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Wed, 7 Jan 2009 22:48:23 +0100
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T211629-323@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
Message-ID: <20090107214822.GA16228@mother.fordon.pl.eu.org>

On Wed, Jan 07, 2009 at 09:28:22PM +0000, Mike wrote:
> An inexperienced new user to Linux trying an install of F10 to a machine with
> either of these chipsets would likely get a very bad impression of Fedora, since
> it is easy to end up with a non-functioning screen and keyboard, and the "intel"
> driver issue needs to be properly fixed since there must be a non-trivial number
> of users who have machines with those graphics chips.


 Do you mean https://bugzilla.redhat.com/show_bug.cgi?id=464866
[Bug 464866] Xorg lockup with i945: "EQ overflowing. The server is
probably stuck in an infinite loop."
or some other bug? Above happens to me on X4500MHD, so it's not i945
specific.

-- 
Tomasz Torcz                                                       72->|   80->|
xmpp: zdzichubg at chrome.pl                                          72->|   80->|

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/1916bf83/attachment.sig>

From darrellpf at gmail.com  Wed Jan  7 21:50:17 2009
From: darrellpf at gmail.com (darrell pfeifer)
Date: Wed, 7 Jan 2009 13:50:17 -0800
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T211629-323@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
Message-ID: <f6e5806f0901071350y5e0c88c4n7c8218bc84a9a029@mail.gmail.com>

On Wed, Jan 7, 2009 at 13:28, Mike <mike.cloaked at gmail.com> wrote:

>
> I'd be interested to hear what the general view about this is? F10 is
> really
> excellent when it works but this kind of problem is really serious and
> should
> not be ignored.
>

I have 3 different machines with intel graphics on them. The last i810
driver that worked for me was 2.4.2-1.fc10, circa 2008-08-26. I've tried
pretty much every new version in rawhide since then, in combination with
various kernels. without success. I've also added bugzilla entries, which
for the most part seem to be ignored. I regularly scan through the bug
reports to try to pick up hints on how to fix things. There are lots of
reports (far more than usual I think) about the intel driver.

kernel 2.6.29-0.12.rc0.git7.fc11 doesn't work with compiz, so one of my
suggestions would be to turn off compiz for a while.

It used to be relatively easy to restore just the old i810 driver in case of
a failure. Recent changes in rawhide make it tougher to test because you'll
probably need back out more dependencies.

There are very large changes being introduced both the the driver code and
in the kernel. The bottom line is that the intel driver has been unstable
for quite some time, and you should expect to be patient.

darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/3c00f4cf/attachment.htm>

From mike.cloaked at gmail.com  Wed Jan  7 21:54:36 2009
From: mike.cloaked at gmail.com (Mike)
Date: Wed, 7 Jan 2009 21:54:36 +0000 (UTC)
Subject: F10/11 and Intel Integrated Graphics?
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
Message-ID: <loom.20090107T215239-554@post.gmane.org>

Tomasz Torcz <tomek <at> pipebreaker.pl> writes:

>  Do you mean https://bugzilla.redhat.com/show_bug.cgi?id=464866

or
https://bugzilla.redhat.com/show_bug.cgi?id=473427
or
https://bugzilla.redhat.com/show_bug.cgi?id=429500
or
https://bugzilla.redhat.com/show_bug.cgi?id=473427

and a slew of others so yes it seems to cover a range of 
Intel Integrated graphics.




From davej at redhat.com  Wed Jan  7 22:01:22 2009
From: davej at redhat.com (Dave Jones)
Date: Wed, 7 Jan 2009 17:01:22 -0500
Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
In-Reply-To: <20090107151812.GA12074@redhat.com>
References: <20090107151812.GA12074@redhat.com>
Message-ID: <20090107220122.GB17904@redhat.com>

On Wed, Jan 07, 2009 at 03:18:12PM +0000, Joe Orton wrote:
 > The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by 
 > default.  Apache httpd uses one epoll fd ("instance") per child process, 
 > so this sets a hard limit on 128 children (i.e. 100 concurrent clients) 
 > out of the box.
 > 
 > 1) shouldn't this be an rlimit so that we can bump it appropriately in 
 > the parent as root?

possibly.  It's a question better asked on linux-kernel really. 

This does sound like a better change to me than forcing the sysctl change
on everyone.

	Dave

-- 
http://www.codemonkey.org.uk



From rda at rincon.com  Wed Jan  7 22:03:23 2009
From: rda at rincon.com (Robert Arendt)
Date: Wed, 07 Jan 2009 15:03:23 -0700
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T211629-323@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
Message-ID: <496526AB.1070407@rincon.com>

Mike wrote:
> However on two machines, one of which is only 3 years old and is a Dell 5150
> with 82945G integrated graphics, it was a mess when it came to graphics - and
> the other machine was a Dell Dimension 2400 a little older with 82845G graphics
> which was also non-trivial to get installed.
> 
>    .... snip .... 
> 
> Can someone tell me what the state of development, if any, there is concerning
> getting a fixed intel graphics driver (xorg-x11-drv-i810) either as an update
> for F10 or fixed in time for F11 release.
> 
> I believe that having a new user install an up-to-date version of Fedora from a
> DVD or CD set or LiveCD and end up with a blank screen and unresponsive
> keyboard/mouse would be very disheartening at best and give a very bad press to
> Fedora at worst.
> 
> I'd be interested to hear what the general view about this is? F10 is really
> excellent when it works but this kind of problem is really serious and should
> not be ignored.
> 

Intel 82845G issues still aren't resolved.  This has been broken since
10/31/2008 on Rawhide, and is still broken.  I re-test whenever a new
F10 kernel, mesa, libdrm, or relevant xorg component comes out.

See:  https://bugzilla.redhat.com/show_bug.cgi?id=469292
  "Xorg drv-i810 locks up unless NoAccel True"

I'd also like to find out when this is going to come together.



From mike.cloaked at gmail.com  Wed Jan  7 22:03:42 2009
From: mike.cloaked at gmail.com (Mike)
Date: Wed, 7 Jan 2009 22:03:42 +0000 (UTC)
Subject: F10/11 and Intel Integrated Graphics?
References: <loom.20090107T211629-323@post.gmane.org>
	<f6e5806f0901071350y5e0c88c4n7c8218bc84a9a029@mail.gmail.com>
Message-ID: <loom.20090107T215800-427@post.gmane.org>

darrell pfeifer <darrellpf <at> gmail.com> writes:

> Recent changes in rawhide make it tougher to test because you'll probably
> need back out more dependencies.There are very large changes being
> introduced both the the driver code and in the kernel. 
> The bottom line is that the intel driver has been unstable for quite 
> some time, and you should expect to be patient
> .darrell

You and I can mostly be patient but consider the enthusiastic newcomer 
who reads about this wonderful new Fedora distro in some magazine or on a 
website like distrowatch, and either downloads the iso or gets the free DVD
with his magazine - and then installs to find it fails abysmally.

He talks to some other guys at the local Linux User Group who tell him that 
he will get better success with Ubuntu - so he tries that and it works - 

Now imagine the chatter over a drink the next time he joins the local Linux
group social....

I have been using Fedora since its inception - and I can usually be patient
but how many people will be turned off permanently by issues like this,
both old hands as well as newcomers?

I think this is an issue that is ignored at our peril.




From a.badger at gmail.com  Wed Jan  7 22:01:47 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Jan 2009 14:01:47 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <20090107103511.GA27484@amd.home.annexia.org>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<20090107103511.GA27484@amd.home.annexia.org>
Message-ID: <4965264B.3020705@gmail.com>

Richard W.M. Jones wrote:
> On Tue, Jan 06, 2009 at 01:16:59PM -0600, Jason L Tibbitts III wrote:
>> * Make adherence to the FHS a MUST, [...]
> 
> Is there a recognized process for getting changes into upstream FHS?

Changes to the FHS are discussed on their mailing list hosted on
Sourceforge::

http://sourceforge.net/projects/freestandards/

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/3c488bdc/attachment.sig>

From m.a.young at durham.ac.uk  Wed Jan  7 22:08:12 2009
From: m.a.young at durham.ac.uk (M A Young)
Date: Wed, 7 Jan 2009 22:08:12 +0000 (GMT)
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T211629-323@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
Message-ID: <alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>

On Wed, 7 Jan 2009, Mike wrote:

> I have installed F10 on 8 machines - on 6 of them it was fine and there were no
> major issues during install. On those machines Fedora running with a gnome
> desktop is excellent (apart from one or two issues with upstream gnome
> regressions such as no ability to save desktop sessions!)
>
> However on two machines, one of which is only 3 years old and is a Dell 5150
> with 82945G integrated graphics, it was a mess when it came to graphics - and
> the other machine was a Dell Dimension 2400 a little older with 82845G graphics
> which was also non-trivial to get installed.

Yes, intel graphics are highly flaky on Fedora 10. You might be able to 
get it working by adding
option "NoAccel" true
into the right clause of the /etc/X11/xorg.conf file (if you have one).

 	Michael Young



From craftjml at gmail.com  Wed Jan  7 22:19:34 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 7 Jan 2009 16:19:34 -0600
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>
References: <loom.20090107T211629-323@post.gmane.org>
	<alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>
Message-ID: <20d6441a0901071419k1dc50f82s65e6619f0247bc9e@mail.gmail.com>

Isn't there a simple check for those cards that can either A) fall
back to VESA or B) switch NoAccel to true automatically?

Even if they can't accelerate, an unaccelerated desktop would still
have pleasant functionality.  Ubuntu obviously wouldn't get
acceleration working either on these cards.

Since they glitch up and it hasn't been resolved in some time, a
graceful fallback should be done, that will protect the user from the
most unpleasant parts of the experience.



From rda at rincon.com  Wed Jan  7 22:19:57 2009
From: rda at rincon.com (Robert Arendt)
Date: Wed, 07 Jan 2009 15:19:57 -0700
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T215800-427@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>	<f6e5806f0901071350y5e0c88c4n7c8218bc84a9a029@mail.gmail.com>
	<loom.20090107T215800-427@post.gmane.org>
Message-ID: <49652A8D.1070300@rincon.com>

Mike wrote:
> You and I can mostly be patient but consider the enthusiastic newcomer
> who reads about this wonderful new Fedora distro in some magazine or on a
> website like distrowatch, and either downloads the iso or gets the free DVD
> with his magazine - and then installs to find it fails abysmally.
> 
> He talks to some other guys at the local Linux User Group who tell him that
> he will get better success with Ubuntu - so he tries that and it works -

.. except that Intel 82845G is broken on Ubuntu 810 also.  Upstream
Xorg/Mesa/kernel (shifting GEM / DRM into the kernel?) seems to be
the moving target.




From seg at haxxed.com  Wed Jan  7 22:27:05 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 07 Jan 2009 16:27:05 -0600
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090107T215239-554@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
	<loom.20090107T215239-554@post.gmane.org>
Message-ID: <1231367225.5754.11.camel@localhost.localdomain>

On Wed, 2009-01-07 at 21:54 +0000, Mike wrote:
> Tomasz Torcz <tomek <at> pipebreaker.pl> writes:
> 
> >  Do you mean https://bugzilla.redhat.com/show_bug.cgi?id=464866
> 
> or
> https://bugzilla.redhat.com/show_bug.cgi?id=473427
> or
> https://bugzilla.redhat.com/show_bug.cgi?id=429500
> or
> https://bugzilla.redhat.com/show_bug.cgi?id=473427
> 
> and a slew of others so yes it seems to cover a range of 
> Intel Integrated graphics.

While we're complaining, Intel 830M has been broken since F9:

https://bugzilla.redhat.com/show_bug.cgi?id=441665

And for that matter, F10 broke on my Radeon 9600XT too:

https://bugzilla.redhat.com/show_bug.cgi?id=474977

Blech. Is there something more I can do to help fix this? I have some C
skills.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/a3a95009/attachment.sig>

From mike.cloaked at gmail.com  Wed Jan  7 22:26:28 2009
From: mike.cloaked at gmail.com (Mike)
Date: Wed, 7 Jan 2009 22:26:28 +0000 (UTC)
Subject: F10/11 and Intel Integrated Graphics?
References: <loom.20090107T211629-323@post.gmane.org>	<f6e5806f0901071350y5e0c88c4n7c8218bc84a9a029@mail.gmail.com>
	<loom.20090107T215800-427@post.gmane.org>
	<49652A8D.1070300@rincon.com>
Message-ID: <loom.20090107T222321-674@post.gmane.org>

Robert Arendt <rda <at> rincon.com> writes:

> .. except that Intel 82845G is broken on Ubuntu 810 also.  Upstream
> Xorg/Mesa/kernel (shifting GEM / DRM into the kernel?) seems to be
> the moving target.

In that case I guess it is likely to be a problem with other distributions 
also?

Is there any way to nail the target and find where to concentrate the effort
needed?

Sometimes in the past on matters not related to this one, there has been
active passing of bucks from pillar to post with all potentially involved
parties insisting the the problem lies elsewhere - or is that not the case
here?






From a.badger at gmail.com  Wed Jan  7 22:48:10 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Jan 2009 14:48:10 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <1231363539.32405.962.camel@firewall.xsintricity.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>	<1231278888.32405.845.camel@firewall.xsintricity.com>	<4963DD10.1060002@gmail.com>	<1231343414.32405.888.camel@firewall.xsintricity.com>	<4964E450.6010909@gmail.com>	<1231353860.32405.916.camel@firewall.xsintricity.com>	<496502DC.4070603@gmail.com>
	<1231363539.32405.962.camel@firewall.xsintricity.com>
Message-ID: <4965312A.4020909@gmail.com>

Doug Ledford wrote:
> On Wed, 2009-01-07 at 11:30 -0800, Toshio Kuratomi wrote:
> 
>> So, with the exception of the arch-specific files in %{_datadir} which
>> has changed for the new release, this seems to be FHS-kosher to me.  If
>> you can get me a link to the new package I can take a look and see if
>> the situation there is worse.
> 
> Well, not really (unless the FHS changed since I last read it).  The
> solution was to create an %{mpidir} macro that was
> %{name}/%{version}-%{opt_cc} and use %{_libdir}/%{mpidir} as a prefix
> for the entire install.  So, libraries, binaries, man pages, etc config
> files, they all reside under %{_lidbir}/%{mpidir}.  That's an acceptable
> layout for things in /opt according to the FHS, but not for distribution
> provided files in %{_libdir}, and distribution provided files are
> prohibited from being placed in /opt.  Hence the conundrum.
> 
> 
It depends on how you interpret the FHS, I suppose.  In the old
packages, the config files are in /etc, the arch independent data (help
files) are in a subdir or /usr/share/openmpi/, and most of the
arch-specific files are under /usr/lib/openmpi/.  This satisfies the
overarching goal of the FHS, separation of sharable and unsharable data.
 it also satisfies the goal of separating arch specific and arch
independent files.

The question is whether the binaries can go there or have to go in
/usr/bin and whether the libraries can go there or must go directly in
/usr/lib.  For the libraries, we often put private libraries in a
subdirectory of /usr/lib.  These differ in that they're public
libraries.  I lean towards this being okay.  The binaries being in the
subdirectory of %{_libdir} doesn't have as much precedent.  Perhaps we
need to make that usage explicit in the Guidelines just like %{_libexecdir}?

Looking at the new package I see that there's config files under
%{_libdir}/openmpi.  I think these need to go in %{_sysconfdir} instead.
 This is more important than binaries and libraries for several reasons:

1) Having them in %{_libdir} breaks the sharable/unsharable boundary
2) They are files edited by system admins and looked at by the user.
They should be in a predictable place for this reason.

As you noted, there's also some FHS regressions compared to the current
package:

- include files are under %{_libdir} instead of under %{_includedir} --
If these are arch specific include files then this makes sense.  If not,
they belong in %{_includedir}.  What things were broken by doing that?

- man dirs are now under %{_libdir} instead of under %{_datadir}.  What
broke by having these under %{_datadir}?

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/ac753800/attachment.sig>

From mrmazda at ij.net  Wed Jan  7 23:11:30 2009
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 07 Jan 2009 18:11:30 -0500
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <20d6441a0901071419k1dc50f82s65e6619f0247bc9e@mail.gmail.com>
References: <loom.20090107T211629-323@post.gmane.org>	<alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>
	<20d6441a0901071419k1dc50f82s65e6619f0247bc9e@mail.gmail.com>
Message-ID: <496536A2.3070406@ij.net>

Anyone tried the solution in https://bugzilla.novell.com/show_bug.cgi?id=463288 ?
-- 
"Train a child in the way he should go, and when he
is old he will not turn from it." Proverbs 22:6 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From dledford at redhat.com  Wed Jan  7 23:37:56 2009
From: dledford at redhat.com (Doug Ledford)
Date: Wed, 07 Jan 2009 18:37:56 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <4965312A.4020909@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
	<4963DD10.1060002@gmail.com>
	<1231343414.32405.888.camel@firewall.xsintricity.com>
	<4964E450.6010909@gmail.com>
	<1231353860.32405.916.camel@firewall.xsintricity.com>
	<496502DC.4070603@gmail.com>
	<1231363539.32405.962.camel@firewall.xsintricity.com>
	<4965312A.4020909@gmail.com>
Message-ID: <1231371476.32405.994.camel@firewall.xsintricity.com>

On Wed, 2009-01-07 at 14:48 -0800, Toshio Kuratomi wrote:
> Doug Ledford wrote:
> > On Wed, 2009-01-07 at 11:30 -0800, Toshio Kuratomi wrote:
> > 
> >> So, with the exception of the arch-specific files in %{_datadir} which
> >> has changed for the new release, this seems to be FHS-kosher to me.  If
> >> you can get me a link to the new package I can take a look and see if
> >> the situation there is worse.
> > 
> > Well, not really (unless the FHS changed since I last read it).  The
> > solution was to create an %{mpidir} macro that was
> > %{name}/%{version}-%{opt_cc} and use %{_libdir}/%{mpidir} as a prefix
> > for the entire install.  So, libraries, binaries, man pages, etc config
> > files, they all reside under %{_lidbir}/%{mpidir}.  That's an acceptable
> > layout for things in /opt according to the FHS, but not for distribution
> > provided files in %{_libdir}, and distribution provided files are
> > prohibited from being placed in /opt.  Hence the conundrum.
> > 
> > 
> It depends on how you interpret the FHS, I suppose.  In the old
> packages, the config files are in /etc, the arch independent data (help
> files) are in a subdir or /usr/share/openmpi/, and most of the
> arch-specific files are under /usr/lib/openmpi/.  This satisfies the
> overarching goal of the FHS, separation of sharable and unsharable data.
>  it also satisfies the goal of separating arch specific and arch
> independent files.
> 
> The question is whether the binaries can go there or have to go in
> /usr/bin and whether the libraries can go there or must go directly in
> /usr/lib.  For the libraries, we often put private libraries in a
> subdirectory of /usr/lib.  These differ in that they're public
> libraries.  I lean towards this being okay.  The binaries being in the
> subdirectory of %{_libdir} doesn't have as much precedent.  Perhaps we
> need to make that usage explicit in the Guidelines just like %{_libexecdir}?
> 
> Looking at the new package I see that there's config files under
> %{_libdir}/openmpi.  I think these need to go in %{_sysconfdir} instead.
>  This is more important than binaries and libraries for several reasons:
> 
> 1) Having them in %{_libdir} breaks the sharable/unsharable boundary

Not really, but that's due to typical usage of these specific files.  I
would tend to agree that files normally in /etc are something that are
intended to be edited on a per machine basis.  These files, even though
they are in %{_libdir}/%{mpidir}/etc, are not something that you would
edit on a per machine basis.  If anything, things like the
openmpi-default-hostfile would be edited on a per version basis (and
with this layout they have a per version etc directory to be contained
in).  This is because on a large cluster, you are likely to either allow
all the machines in the cluster to participate and would put all the
machines in the cluster in this config file, or you would have a segment
of the cluster that is dedicated to running this version of openmpi and
only those machines would be in this file.  Either way, for all the
machines you want running this version of openmpi by default, the file
would be the same (this assumes that a person might start the openmpi
job from any machine in the cluster that's part of the appropriate
group, you may have a control machine doing things instead, in which
case you really only have to edit the file on that one machine and all
the others will be passive clients and not care about the contents of
this file).

Now, the even more common scenario is that you have multiple different
MPI apps.  The admins typically would do a login per app so that the
default login environment for a given app is already pre-configured.
Amongst that would be things like selection of the right mpi, and host
files specific to what machines that app is allowed to run on.  Those
would all be in the home directory for the login and wouldn't require
editing the system wide etc files in here.

> 2) They are files edited by system admins and looked at by the user.
> They should be in a predictable place for this reason.

In truth, they aren't edited much at all, and relying upon them is
frowned upon.  But, as I noted above, even if they are edited, they are
still generally shareable due to the nature of MPI clusters.

> As you noted, there's also some FHS regressions compared to the current
> package:
> 
> - include files are under %{_libdir} instead of under %{_includedir} --
> If these are arch specific include files then this makes sense.  If not,
> they belong in %{_includedir}.  What things were broken by doing that?

Two things here.  Remember that we allow simultaneous installs of
different versions of OpenMPI (you can't get it out of the yum channel
this way, and you can't do upgrades of OpenMPI or it wipes older
versions out, but you can download anything after the openmpi-1.2.5 I
think and install different copies of different versions, although that
does not include multiple releases of the same version, I only use n-v
in the naming, not full n-v-r, so for instance you couldn't have 1.2.7-5
and 1.2.7-6 installed, but you can have 1.1.8 and 1.2.7 installed at the
same time) in order to meet user requirements.  Differing versions can
have differing header files, so we can't just use %{_includedir}/%{name}
or they might conflict.  Putting the includes alongside the libs works
for just about any devel package that needs to use it because you can
just use --prefix to configure it to the right place.  Of course, the
gcc wrappers also know about where the right include files are, so it
works with mpicc without doing anything.  The second reason is that for
fortran use in particular, the header file produced during build is
different for different arches.  So aside from the multi-install issue,
there is an arch specific component to the headers that can't be worked
around due to limitations in the fortran language (or that's my
understanding, I haven't touched fortran since 1991 or so).

> - man dirs are now under %{_libdir} instead of under %{_datadir}.  What
> broke by having these under %{_datadir}?

Multiple installs and also if we put it under datadir, then we have to
fiddle with manpath when we set up the environment.  With them where
they are, the presence of %{_libdir}/%{mpidir}/bin in the exec path is
enough for man to track down the right man page automatically.

> -Toshio
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/4d6f4f0a/attachment.sig>

From vonbrand at inf.utfsm.cl  Wed Jan  7 23:52:13 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 07 Jan 2009 20:52:13 -0300
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <4964B180.8020009@redhat.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
Message-ID: <200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>

Bryn M. Reeves <bmr at redhat.com> wrote:
> Jeffrey Ollie wrote:
> > On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
> >> I guess it depends how much we care about being close to upstream for this.
> >> If it's worth the effort to move these to libexec, then perhaps putting
> >> compatibility symlinks in place for a couple of releases (with a clear
> >> relnote that they will be removed in a future release and scripts need
> >> updating) could be a way to handle the transition?
> > Adding symlinks does nothing to help, it just delays the pain because
> > people won't read the release notes or won't bother to fix their
> > scripts until the symlinks disappear.  Fixing the scripts is trivial,
> > and backwards compatible to boot.

> No, but having an entry in the release notes for a release or two
> gives something more concrete to point at and say "I told you so" than
> an announcement on the fedora-devel lists which are not read by most
> users (yes, I know that this was announced three years ago upstream,
> but the same comment regarding users not reading things applies).

It has been announced in git's release notes for more than two years now!

> Since we carried the package with non-upstream default paths for these
> files for some time,

I don't think so.

>                      I think we (Fedora) have some responsibility to
> clearly tell our users that we are now bringing things back into line
> with upstream.

This is bringing stuff in line with upstream.
-- 
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 kevin.kofler at chello.at  Thu Jan  8 00:01:29 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 08 Jan 2009 01:01:29 +0100
Subject: sound problems
References: <4960CEAA.4070507@gmail.com>
	<d9c612bf0901050816q52e9c8c0wef8dab8ca2390f76@mail.gmail.com>
	<68720af30901050848v6728796cndf58347605f74fce@mail.gmail.com>
	<200901050854.18189.konrad@tylerc.org>
	<20090106082024.GB4061@victor.nirvana> <gjvbg8$81h$1@ger.gmane.org>
	<20090106123240.GA15179@victor.dsathen.edu.gr>
	<gjvkue$64j$1@ger.gmane.org>
	<20090106135643.GC16190@victor.dsathen.edu.gr>
	<gk09mu$lmp$1@ger.gmane.org>
	<20090106213428.GD5797@mokona.greysector.net>
Message-ID: <gk3fop$6t7$2@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:
> Please, stop spreading FUD. As I said in another post in this thread,
> there was one API/ABI change in the last three years and one move of
> headers. If that's not stable, then I dare you to find another project
> that is developed at a similar pace and has a more stable API and ABI.

Sorry, I stand corrected. I thought there were more such changes, but my
memory must be dating back from ancient times.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Jan  8 00:07:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 08 Jan 2009 01:07:10 +0100
Subject: Tracking new review requests?
References: <200901061431.53501.ville.skytta@iki.fi>
	<gk0la5$1ve$1@ger.gmane.org>
	<200901072026.02756.ville.skytta@iki.fi>
Message-ID: <gk3g3e$6t7$3@ger.gmane.org>

Ville Skytt? wrote:
> Thanks for the suggestion, but I use kmail which unfortunately does not
> have
> support for NNTP (or RSS) as far as I know, so this is not an option.  Nor
> is using a different mail client or a dedicated NNTP reader only for this
> purpose, and I'm not planning to switch completely away from kmail
> either...

Well, there's KNode for this purpose. I use it for all the mailing lists, it
works great. :-)

You can also use Kontact which gives you KMail and KNode in the same window.

        Kevin Kofler



From stickster at gmail.com  Thu Jan  8 00:38:03 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 7 Jan 2009 19:38:03 -0500
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
	<200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>
Message-ID: <20090108003803.GC17592@localhost.localdomain>

On Wed, Jan 07, 2009 at 08:52:13PM -0300, Horst H. von Brand wrote:
> Bryn M. Reeves <bmr at redhat.com> wrote:
> > Jeffrey Ollie wrote:
> > > On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
> > >> I guess it depends how much we care about being close to upstream for this.
> > >> If it's worth the effort to move these to libexec, then perhaps putting
> > >> compatibility symlinks in place for a couple of releases (with a clear
> > >> relnote that they will be removed in a future release and scripts need
> > >> updating) could be a way to handle the transition?
> > > Adding symlinks does nothing to help, it just delays the pain because
> > > people won't read the release notes or won't bother to fix their
> > > scripts until the symlinks disappear.  Fixing the scripts is trivial,
> > > and backwards compatible to boot.
> 
> > No, but having an entry in the release notes for a release or two
> > gives something more concrete to point at and say "I told you so" than
> > an announcement on the fedora-devel lists which are not read by most
> > users (yes, I know that this was announced three years ago upstream,
> > but the same comment regarding users not reading things applies).
> 
> It has been announced in git's release notes for more than two years now!

I would expect a good number of git users on Fedora don't watch the
git upstream.  Putting a note in the F11 release notes is perfectly
valid, reasonable, and laudable.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/62e7d6ad/attachment.sig>

From bpepple at fedoraproject.org  Thu Jan  8 00:54:52 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 07 Jan 2009 19:54:52 -0500
Subject: FESCo Meeting Summary for 2009-01-07
Message-ID: <1231376092.3115.28.camel@localhost.localdomain>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Bill Nottingham       (notting)
* David Woodhouse       (dwmw2)
* Dennis Gilmore        (dgilmore)
* Jon Stanley           (jds2001)
* Dan Hor?k             (sharkcz) 

== Summary ==
=== New FESCo Chair ===
      * jds2001 was chosen to be the new chair for FESCo.

=== FESCo Meeting Time ===
      * FESCo will meet on Friday's at 17:00GMT (Noon EST) beginning on
        January 16th, 2009.

=== ProvenPackagers ===
      * FESCo approved a proposal for packages that wish to prevent
        provenpackager commits to require FESCo approval.
              * For: jds2001, sharkcz, dwmw2, j-rod, nirik, bpepple, jwb
              * Against: notting
              * Abstain: dgilmore
      * Discussed the initial seeding of the provenpackager group, and
        there will be a session at FUDCon to see if a reasonable
        solution can be worked out.

=== Features ===
      * FESCo approved the KDE-4.2 feature for F11.
        https://fedoraproject.org/wiki/Features/KDE42

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2009-01-07.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/d9073384/attachment.sig>

From a.badger at gmail.com  Thu Jan  8 00:51:36 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 07 Jan 2009 16:51:36 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <1231371476.32405.994.camel@firewall.xsintricity.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>	<1231278888.32405.845.camel@firewall.xsintricity.com>	<4963DD10.1060002@gmail.com>	<1231343414.32405.888.camel@firewall.xsintricity.com>	<4964E450.6010909@gmail.com>	<1231353860.32405.916.camel@firewall.xsintricity.com>	<496502DC.4070603@gmail.com>	<1231363539.32405.962.camel@firewall.xsintricity.com>	<4965312A.4020909@gmail.com>
	<1231371476.32405.994.camel@firewall.xsintricity.com>
Message-ID: <49654E18.6040709@gmail.com>

Doug Ledford wrote:
> On Wed, 2009-01-07 at 14:48 -0800, Toshio Kuratomi wrote:
>> It depends on how you interpret the FHS, I suppose.  In the old
>> packages, the config files are in /etc, the arch independent data (help
>> files) are in a subdir or /usr/share/openmpi/, and most of the
>> arch-specific files are under /usr/lib/openmpi/.  This satisfies the
>> overarching goal of the FHS, separation of sharable and unsharable data.
>>  it also satisfies the goal of separating arch specific and arch
>> independent files.
>>
>> The question is whether the binaries can go there or have to go in
>> /usr/bin and whether the libraries can go there or must go directly in
>> /usr/lib.  For the libraries, we often put private libraries in a
>> subdirectory of /usr/lib.  These differ in that they're public
>> libraries.  I lean towards this being okay.  The binaries being in the
>> subdirectory of %{_libdir} doesn't have as much precedent.  Perhaps we
>> need to make that usage explicit in the Guidelines just like %{_libexecdir}?
>>
>> Looking at the new package I see that there's config files under
>> %{_libdir}/openmpi.  I think these need to go in %{_sysconfdir} instead.
>>  This is more important than binaries and libraries for several reasons:
>>
>> 1) Having them in %{_libdir} breaks the sharable/unsharable boundary
> 
> Not really, but that's due to typical usage of these specific files.  I
> would tend to agree that files normally in /etc are something that are
> intended to be edited on a per machine basis.  These files, even though
> they are in %{_libdir}/%{mpidir}/etc, are not something that you would
> edit on a per machine basis.  If anything, things like the
> openmpi-default-hostfile would be edited on a per version basis (and
> with this layout they have a per version etc directory to be contained
> in).  This is because on a large cluster, you are likely to either allow
> all the machines in the cluster to participate and would put all the
> machines in the cluster in this config file, or you would have a segment
> of the cluster that is dedicated to running this version of openmpi and
> only those machines would be in this file.  Either way, for all the
> machines you want running this version of openmpi by default, the file
> would be the same (this assumes that a person might start the openmpi
> job from any machine in the cluster that's part of the appropriate
> group, you may have a control machine doing things instead, in which
> case you really only have to edit the file on that one machine and all
> the others will be passive clients and not care about the contents of
> this file).
> 
Okay.. but then you preclude the possibility of running multiple
instances of one mpi version within a cluster.  It sounds like that's
not typical in your experience but it doesn't sound like a necessary
limitation.

> Now, the even more common scenario is that you have multiple different
> MPI apps.  The admins typically would do a login per app so that the
> default login environment for a given app is already pre-configured.
> Amongst that would be things like selection of the right mpi, and host
> files specific to what machines that app is allowed to run on.  Those
> would all be in the home directory for the login and wouldn't require
> editing the system wide etc files in here.
> 
Despite the environment being somewhat different than normal this kind
of configuration is normal for any apps.

>> 2) They are files edited by system admins and looked at by the user.
>> They should be in a predictable place for this reason.
> 
> In truth, they aren't edited much at all, and relying upon them is
> frowned upon.  But, as I noted above, even if they are edited, they are
> still generally shareable due to the nature of MPI clusters.
> 

This is true of other applications as well, though....

So even if we don't care about people having multiple different openmpi
instances within their cluster, this still doesn't answer what breaks by
putting the config files in /etc.  Which is important because deviating
breaks other sysadmin assumptions.  For instance, if I was backing up
all configuration files on these machines by backing up /etc, this would
miss the openmpi configs.  If I was mounting the /usr filesystem
read-only, this would prevent me from updating the config file on-the-fly.

>> As you noted, there's also some FHS regressions compared to the current
>> package:
>>
>> - include files are under %{_libdir} instead of under %{_includedir} --
>> If these are arch specific include files then this makes sense.  If not,
>> they belong in %{_includedir}.  What things were broken by doing that?
> 
> Two things here.  Remember that we allow simultaneous installs of
> different versions of OpenMPI (you can't get it out of the yum channel
> this way, and you can't do upgrades of OpenMPI or it wipes older
> versions out, but you can download anything after the openmpi-1.2.5 I
> think and install different copies of different versions, although that
> does not include multiple releases of the same version, I only use n-v
> in the naming, not full n-v-r, so for instance you couldn't have 1.2.7-5
> and 1.2.7-6 installed, but you can have 1.1.8 and 1.2.7 installed at the
> same time) in order to meet user requirements.  Differing versions can
> have differing header files, so we can't just use %{_includedir}/%{name}
> or they might conflict.  Putting the includes alongside the libs works
> for just about any devel package that needs to use it because you can
> just use --prefix to configure it to the right place.  Of course, the
> gcc wrappers also know about where the right include files are, so it
> works with mpicc without doing anything.  The second reason is that for
> fortran use in particular, the header file produced during build is
> different for different arches.

The correct way to do this is by having the version in the includedir:
  %{_includedir}/openmpi-1.2.7/*.h

>  So aside from the multi-install issue,
> there is an arch specific component to the headers that can't be worked
> around due to limitations in the fortran language (or that's my
> understanding, I haven't touched fortran since 1991 or so).
> 
So is it only the fortran headers that are arch specific or all all of
them arch specific and only fortran doesn't have a way to workaround that?

arch specific headers do belong in a subdir of %{_libdir}.  But most of
the times just that file goes into %{_libdir}.  If you take a look at
glib-devel, for instance, you have:
  /usr/lib/glib/include/glibconfig.h
  /usr/include/glib-1.2
  /usr/include/glib-1.2/glib.h
  /usr/include/glib-1.2/gmodule.h

>> - man dirs are now under %{_libdir} instead of under %{_datadir}.  What
>> broke by having these under %{_datadir}?
> 
> Multiple installs

This shouldn't be the case.  Once again, the correct solution to this
problem is including the version in the directory name.

> and also if we put it under datadir, then we have to
> fiddle with manpath when we set up the environment.  With them where
> they are, the presence of %{_libdir}/%{mpidir}/bin in the exec path is
> enough for man to track down the right man page automatically.
> 
And this should be something that environment modules takes care of.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/8ccb8fa1/attachment.sig>

From jwboyer at gmail.com  Fri Jan  9 02:14:55 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 8 Jan 2009 21:14:55 -0500
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090108003803.GC17592@localhost.localdomain>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
	<200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>
	<20090108003803.GC17592@localhost.localdomain>
Message-ID: <20090109021455.GA11775@yoda.jdub.homelinux.org>

On Wed, Jan 07, 2009 at 07:38:03PM -0500, Paul W. Frields wrote:
>On Wed, Jan 07, 2009 at 08:52:13PM -0300, Horst H. von Brand wrote:
>> Bryn M. Reeves <bmr at redhat.com> wrote:
>> > Jeffrey Ollie wrote:
>> > > On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>> > >> I guess it depends how much we care about being close to upstream for this.
>> > >> If it's worth the effort to move these to libexec, then perhaps putting
>> > >> compatibility symlinks in place for a couple of releases (with a clear
>> > >> relnote that they will be removed in a future release and scripts need
>> > >> updating) could be a way to handle the transition?
>> > > Adding symlinks does nothing to help, it just delays the pain because
>> > > people won't read the release notes or won't bother to fix their
>> > > scripts until the symlinks disappear.  Fixing the scripts is trivial,
>> > > and backwards compatible to boot.
>> 
>> > No, but having an entry in the release notes for a release or two
>> > gives something more concrete to point at and say "I told you so" than
>> > an announcement on the fedora-devel lists which are not read by most
>> > users (yes, I know that this was announced three years ago upstream,
>> > but the same comment regarding users not reading things applies).
>> 
>> It has been announced in git's release notes for more than two years now!
>
>I would expect a good number of git users on Fedora don't watch the
>git upstream.  Putting a note in the F11 release notes is perfectly
>valid, reasonable, and laudable.

We (the git maintainers) can certainly do that.

josh



From stickster at gmail.com  Thu Jan  8 02:39:38 2009
From: stickster at gmail.com (Paul Frields)
Date: Wed, 7 Jan 2009 21:39:38 -0500
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <20090109021455.GA11775@yoda.jdub.homelinux.org>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
	<200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>
	<20090108003803.GC17592@localhost.localdomain>
	<20090109021455.GA11775@yoda.jdub.homelinux.org>
Message-ID: <ef93afcf0901071839o6bbe3732q6b375730778e11a8@mail.gmail.com>

On Thu, Jan 8, 2009 at 9:14 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Wed, Jan 07, 2009 at 07:38:03PM -0500, Paul W. Frields wrote:
>>On Wed, Jan 07, 2009 at 08:52:13PM -0300, Horst H. von Brand wrote:
>>> Bryn M. Reeves <bmr at redhat.com> wrote:
>>> > Jeffrey Ollie wrote:
>>> > > On Wed, Jan 7, 2009 at 4:21 AM, Bryn M. Reeves <bmr at redhat.com> wrote:
>>> > >> I guess it depends how much we care about being close to upstream for this.
>>> > >> If it's worth the effort to move these to libexec, then perhaps putting
>>> > >> compatibility symlinks in place for a couple of releases (with a clear
>>> > >> relnote that they will be removed in a future release and scripts need
>>> > >> updating) could be a way to handle the transition?
>>> > > Adding symlinks does nothing to help, it just delays the pain because
>>> > > people won't read the release notes or won't bother to fix their
>>> > > scripts until the symlinks disappear.  Fixing the scripts is trivial,
>>> > > and backwards compatible to boot.
>>>
>>> > No, but having an entry in the release notes for a release or two
>>> > gives something more concrete to point at and say "I told you so" than
>>> > an announcement on the fedora-devel lists which are not read by most
>>> > users (yes, I know that this was announced three years ago upstream,
>>> > but the same comment regarding users not reading things applies).
>>>
>>> It has been announced in git's release notes for more than two years now!
>>
>>I would expect a good number of git users on Fedora don't watch the
>>git upstream.  Putting a note in the F11 release notes is perfectly
>>valid, reasonable, and laudable.
>
> We (the git maintainers) can certainly do that.

Excellent. The Release Notes holding area ("beats"), where the Docs
team drafts content for the next release, haven't been scrubbed yet
but should be shortly. In the meantime, a BZ against Fedora
Documentation, release-notes is a good way to make sure someone sees
this before we're too far down the road.

Paul



From sundaram at fedoraproject.org  Thu Jan  8 02:49:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 08 Jan 2009 08:19:26 +0530
Subject: Enabling drivers in staging tree in rawhide
Message-ID: <496569B6.1090204@fedoraproject.org>

Hi

Quite a bit of new drivers in

http://lwn.net/Articles/313730/

The ralink wireless drivers for example would hopefully make the newer 
EEE PC model would out of the box.  Does it make sense to enable the 
drivers in staging tree by default and bring more exposure to them 
atleast via rawhide if not in general releases?

Rahul



From tmz at pobox.com  Thu Jan  8 02:51:30 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 7 Jan 2009 21:51:30 -0500
Subject: git-* commands in /usr/libexec/git-core/
In-Reply-To: <ef93afcf0901071839o6bbe3732q6b375730778e11a8@mail.gmail.com>
References: <20090107084300.GA20651@evileye.atkac.englab.brq.redhat.com>
	<49648220.7050209@redhat.com>
	<935ead450901070535p1bfd312eja75cb2a9ee5afeca@mail.gmail.com>
	<4964B180.8020009@redhat.com>
	<200901072352.n07NqDor008636@laptop14.inf.utfsm.cl>
	<20090108003803.GC17592@localhost.localdomain>
	<20090109021455.GA11775@yoda.jdub.homelinux.org>
	<ef93afcf0901071839o6bbe3732q6b375730778e11a8@mail.gmail.com>
Message-ID: <20090108025130.GM21007@inocybe.teonanacatl.org>

Paul W. Frields wrote:
> Excellent. The Release Notes holding area ("beats"), where the Docs
> team drafts content for the next release, haven't been scrubbed yet
> but should be shortly. In the meantime, a BZ against Fedora
> Documentation, release-notes is a good way to make sure someone sees
> this before we're too far down the road.

Done: https://bugzilla.redhat.com/479216

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Don't look for me in daylight where robots all assemble.  You'll find
me in my dark world, in my smoke-filled temple.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/73a7278f/attachment.sig>

From ioplex at gmail.com  Thu Jan  8 03:16:30 2009
From: ioplex at gmail.com (Michael B Allen)
Date: Wed, 7 Jan 2009 22:16:30 -0500
Subject: Automatic update ran despite being disabled (which is bad)
Message-ID: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>

About 15 minutes ago a dialog popped up that claimed "Your system has
been updated" (or something to that effect). The problem is, I didn't
initiate an update and my system is not configured to automatically
update.

Can anyone explain how this could happen?

How do I *completely disable* automatic updating? And I mean
completely with no exceptions. I don't care if there's a bug in
something that has a good chance of erasing my motherboard firmware. I
do not want automatic updates.

Hopefully I accidentally clicked on something to trigger the update.
Hopefully, with automatic updates disabled, the update daemon is
carefully coded so that there is no possibility that the system could
update unless explicitly instructed.

Mike



From mjg at redhat.com  Thu Jan  8 03:36:50 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Thu, 8 Jan 2009 03:36:50 +0000
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <496569B6.1090204@fedoraproject.org>
References: <496569B6.1090204@fedoraproject.org>
Message-ID: <20090108033650.GB2550@srcf.ucam.org>

On Thu, Jan 08, 2009 at 08:19:26AM +0530, Rahul Sundaram wrote:

> The ralink wireless drivers for example would hopefully make the newer 
> EEE PC model would out of the box.  Does it make sense to enable the 
> drivers in staging tree by default and bring more exposure to them 
> atleast via rawhide if not in general releases?

I think providing hardware support in rawhide and then removing it 
before release would be somewhat user-hostile. The ralink drivers that 
have landed in staging are a dead end - they're never going to be 
in-kernel proper. They don't need testing or bugs filing against them. 
What's needed is more manpower to help work on the native mac80211 
drivers.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From sundaram at fedoraproject.org  Thu Jan  8 04:20:13 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 08 Jan 2009 09:50:13 +0530
Subject: Automatic update ran despite being disabled (which is bad)
In-Reply-To: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>
Message-ID: <49657EFD.6060900@fedoraproject.org>

Michael B Allen wrote:
> About 15 minutes ago a dialog popped up that claimed "Your system has
> been updated" (or something to that effect). The problem is, I didn't
> initiate an update and my system is not configured to automatically
> update.
> 
> Can anyone explain how this could happen?

Essentially a bug in PackageKit that was fixed in a update.

Rahul



From ianweller at gmail.com  Thu Jan  8 05:53:44 2009
From: ianweller at gmail.com (Ian Weller)
Date: Wed, 7 Jan 2009 23:53:44 -0600
Subject: One-on-one wiki gardening at FUDConF11
Message-ID: <20090108055344.GA21260@gmail.com>

Hey,

The Docs Project will be providing one-on-one help with developers and
other writers on the wiki for help with cleaning up and gardening their
pages at FUDConF11.

Ask around for ianweller (me) or quaid (Karsten Wade) in #fudcon to get
our location.

This is a great opportunity to become part of the great wiki
reorganization effort taken on by Docs -- and we could use your help!

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090107/93221fe4/attachment.sig>

From fedora at leemhuis.info  Thu Jan  8 06:17:30 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 08 Jan 2009 07:17:30 +0100
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <496569B6.1090204@fedoraproject.org>
References: <496569B6.1090204@fedoraproject.org>
Message-ID: <49659A7A.8020804@leemhuis.info>

CCing fedora-kernel

On 08.01.2009 03:49, Rahul Sundaram wrote:
> Quite a bit of new drivers in
> http://lwn.net/Articles/313730/

Related: I raised the staging problem already in
https://bugzilla.redhat.com/show_bug.cgi?id=477927
as rawhide contained the at76 driver as separate patch
http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
-- but the same driver (with two small changes) also was part of the 
upstream kernel since October/2.6.28-rc as one of the staging drivers:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
(for more details see bug).

That sounds wrong to me, as

- it's duplicated work

- the at76 staging driver from upstream taints the kernel; the driver 
from our patch doesn't.

> The ralink wireless drivers for example would hopefully make the newer 
> EEE PC model would out of the box.  Does it make sense to enable the 
> drivers in staging tree by default and bring more exposure to them 
> atleast via rawhide if not in general releases?

+1 to the "I think providing hardware support in rawhide and then 
removing it  before release would be somewhat user-hostile." comment 
from mjg59.

IOW: Either enable or disable them. I'm unsure myself what to do but I 
tend to say that disabling the whole staging drivers might be the best 
for Fedora (Greg calls himself as "maintainer of crap" for a good reason).

@Davej, Cebbert and Kylem: What's your position on this?

If they are disabled completely in Fedora then I'll nevertheless 
consider to create a "kmod-staging" package for RPM Fusion.

CU
knurd



From rawhide at fedoraproject.org  Thu Jan  8 09:05:21 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu,  8 Jan 2009 09:05:21 +0000 (UTC)
Subject: rawhide report: 20090108 changes
Message-ID: <20090108090522.0A9FA1F8260@releng2.fedora.phx.redhat.com>

Compose started at Thu Jan  8 06:01:04 UTC 2009

New package FlightGear-Atlas
        Flightgear map tools
New package FlightGear-data
        FlightGear base scenery and data files
New package dustin-dustismo-fonts
        General purpose sans-serif font with bold, italic and bold-italic variations
New package hyphen-el
        Greek hyphenation rules
New package hyphen-es
        Spanish hyphenation rules
New package moon-buggy
        Drive and jump with some kind of car across the moon
New package nightview
        A general astronomical software package to control of a CCD camera
New package perl-Hardware-Vhdl-Tidy
        VHDL code prettifier
New package perl-Verilog
        Verilog parsing routines
New package rfdump
        RFID tags detector
New package unhide
        Tool to find hidden processes and TCP/UDP ports from rootkits
Updated Packages:

FlightGear-1.9.0-1.fc11
-----------------------
* Tue Jan  6 17:00:00 2009 Fabrice Bellet <fabrice at bellet.info> 1.9.0-1
- new upstream release


SimGear-1.9.0-1.fc11
--------------------
* Tue Jan  6 17:00:00 2009 Fabrice Bellet <fabrice at bellet.info> 1.9.0-1
- New upstream release


ace-0.0.5-1.fc11
----------------
* Wed Jan  7 17:00:00 2009 Bryan Kearney <bkearney at redhat.com> 0.0.5-1
- Status of puppet script is reflected in command line and init script
- Executingn 'ace --verbose' now provides real time view of puppet output
- Will work with new puppet which includes the augas plugin

* Tue Dec 16 17:00:00 2008 Bryan Kearney <bkearney at redhat.com> 0.0.4-1
- Postgres packages did not enforfce dependencies correctly
- init script can handle many appliances


aplus-fsf-4.22.4-8.fc11
-----------------------
* Wed Jan  7 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 4.22.4-8
- Reorganization of apl fonts


bigboard-0.6.4-5.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.6.4-5
- rebuild for dependancies


centerim-4.22.6-1
-----------------
* Fri Jan  9 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 1:4.22.6-1
- New upstream release
- Disable openssl due to licensing trouble
- Fix dependencies


classads-1.0.1-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 <matt at redhat> - 1.0.1-1
- Upgraded to 1.0.1 release:
-  New functions: ifThenElse, regexps, interval
-  Source files renamed from .C to .cpp
- Fixed unowned /usr/include/classad directory (BZ473636)
- Updated summaries


comedilib-0.8.1-3.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Marek Mahut <mmahut at fedoraproject.org> - 0.8.1-3
- RHBZ#473642 Unowned directories


condor-7.2.0-1.fc11
-------------------
* Wed Jan  7 17:00:00 2009 <matt at redhat> - 7.2.0-1
- Upgraded to 7.2.0 release
- Removed -static package
- Added Fedora specific buildid
- Enabled KBDD, daemon to monitor X usage on systems with only USB devs
- Updated install process


dbus-1.2.4.4permissive-1.fc11
-----------------------------
* Tue Jan  6 17:00:00 2009 Colin Walters <walters at redhat.com> - 1:1.2.4.4.permissive-1
- New upstream

* Thu Dec 18 17:00:00 2008 Colin Walters <walters at redhat.com> - 1:1.2.4.2.permissive-1
- New upstream


dbus-glib-0.78-2.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Colin Walters <walters at verbum.org> - 0.78-2
- Add patch to avoid sending reply to noreply messages; this avoids
  some spurious dbus denial logs during system startup from NM


deluge-1.1.0-0.3.rc3.fc11
-------------------------
* Wed Jan  7 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 1.1.0-0.3.rc3
- Add patch from upstream SVN to fix an error where torrents are not shown (or
  possibly shown in "Error" states) due to a bad inet_aton call:
  + fix-get_tracker-host-if-no-tracker.patch
- Resolves: #479097 (No torrent shown in menu); thanks to Mamoru Tasaka for
  the bug report.
- Fix day of previous %changelog entry.


denemo-0.8.0-1.fc11
-------------------
* Sun Nov 30 17:00:00 2008 Roy Rankin <rrankin at ihug.com.au> - 0.8.0-1
-Update for Denemo release 0.8.0


desktop-data-model-1.2.5-4.fc11
-------------------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1.2.5-4
- rebuild for dependancies


gimp-2.6.4-3.fc11
-----------------
* Wed Jan  7 17:00:00 2009 Nils Philippsen <nils at redhat.com> - 2:2.6.4-3
- split off gimptool into new gimp-devel-tools subpackage to avoid multilib
  conflicts (#477789)
- require poppler-glib-devel for building from F9 on (#478691)
- fix gimp-devel package group


glabels-2.2.4-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 2.2.4-1
- Update to new upstream bug-fix release (2.2.4):
  * Corrected button order in "Open" and "Save as" dialogs.
  * Fixed performance problem when large number of fonts are installed.
  * Corrected several i18n problems.
  * Fixed "paste" bug that created phantom object views.
  * Fixed performance problem when many objects are selected.
  * New templates.


gnome-applet-music-2.5.0-1.fc11
-------------------------------
* Wed Jan  7 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 2.5.0-1
- Update to new upstream release (2.5.0), which adds support for Amarok 2,
  fixes uncontrolled growth in applet with long metadata strings (#452420),
  improved loading of album art from Rhythmbox, fixes for the rating scale
  change in Exaile 0.2.14 (from 8-star to 5-star), fixes improper entity
  encodings of song titles in notification popups, and replaces the deprecated
  mpdclient2 library with python-mpd in the MPD plugin.


gnome-media-2.25.1-3.fc11
-------------------------
* Wed Jan  7 17:00:00 2009 - Rex Dieter <rdieter at fedoraproject.org> - 2.25.1-3
- gnome-media should not depend on -devel packages (#479181)


gnome-power-manager-2.25.2-1.fc11
---------------------------------
* Wed Jan  7 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2


gnonlin-0.10.10-2.fc10
----------------------

grc-0.70-3.fc11
---------------
* Wed Jan  7 17:00:00 2009 Marek Mahut <mmahut at fedoraproject.org> - 0.70-3
- RHBZ#473924 Unowned directories


kdelibs-4.1.96-1.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.18.rc0.git9.fc11
--------------------------------
* Wed Jan  7 17:00:00 2009 Jarod Wilson <jarod at redhat.com>
- 2.6.28-git9
- Should resolve broken byteorder.h issues (#478663)

* Wed Jan  7 17:00:00 2009 Dave Jones <davej at redhat.com>
- Fix up broken rebase.

* Wed Jan  7 17:00:00 2009 Dave Jones <davej at redhat.com>
- Build ACPI_BATTERY in on x86-64, as we do on x86-32

* Wed Jan  7 17:00:00 2009 Dave Jones <davej at redhat.com>
- Build ACPI_AC in on x86-64/ia64, as we do on x86-32

* Tue Jan  6 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- 2.6.28-git8


ldm-2.0.27-1.fc10
-----------------
* Wed Dec 24 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.27-1
- More bug fixes

* Fri Dec 12 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.25-1
- More bug fixes

* Fri Dec 12 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.24-1
- Minor bug fixes

* Fri Dec 12 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.23-1
- LDM_DIRECTX=true was broken, now fixed

* Thu Dec 11 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 2.0.22-1
- Show good names in Session menu
- Use and write to user .dmrc
  It is now possible to set a default session that is not GNOME.
  Set LDM_GLOBAL_DMRC=/etc/ltsp/ldm-global-dmrc in lts.conf
    and specify your choice in /etc/ltsp/ldm-global-dmrc on the server.


libapreq2-2.10-0.rc1.3.fc11
---------------------------
* Wed Jan  7 17:00:00 2009 Bojan Smojver <bojan at rexursive.com> - 2.10-0.rc1.3
- better fix for apreq2-config

* Wed Jan  7 17:00:00 2009 Bojan Smojver <bojan at rexursive.com> - 2.10-0.rc1.2
- delay changing apreq2-config, so we don't pick up wrong libs


libev-3.52-1.fc11
-----------------
* Wed Jan  7 17:00:00 2009 Michal Nowak <mnowak at redhat.com> - 3.52-1
- 3.52


libgsf-1.14.11-1.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 1.14.11-1
- latest version


libical-0.41-2.fc11
-------------------
* Thu Jan  8 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 0.41-2
- Switched off ICAL_ERRORS_ARE_FATAL for all distributions, except Fedora 11.
  Closes Red Hat Bugzilla bug #478331.


librra-0.11.1-3.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.11.1-3
- Resolves: rhbz#465100 backport upstream pyrra.pyx fix to make build

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.11.1-2
- Rebuild for Python 2.6


libzzub-0.2.3-14.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.2.3-14
- defuzz patches and extend buildfix to get building again

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.2.3-13
- Rebuild for Python 2.6


lilypond-2.12.1-1.fc11
----------------------
* Tue Jan  6 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.12.1-1
- Update to 2.12.1.
- Droppedn parse-scm patch, applied upstream.


linsmith-0.99.11-4.fc11
-----------------------
* Wed Jan  7 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.99.11-4
- fixed vendor

* Wed Jan  7 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 0.99.11-3
- added vendor to skip build failure on EL-5


ltsp-5.1.44-1.fc10
------------------
* Mon Dec 29 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.44-1
- More bug fixes

* Wed Dec 24 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.42-1
- More bug fixes

* Fri Dec 19 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.41-1
- PPC chroot creation and automatic netboot, needs testing
- More bug fixes

* Tue Dec 16 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.39-1
- More bug fixes

* Fri Dec 12 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.38-1
- Fix a few bugs in X_* option handling
- Added LOCAL_APPS_WHITELIST, disabled by default
  If set, only defined commands are allowed to be run as local apps.

* Thu Dec 11 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.37-1
- Now possible to set default session that is not GNOME
  See /etc/ltsp/ldm-global-dmrc
- X_* lts.conf options are now supported
- AMD Geode GX2 should automatically be forced to the geode driver now

* Mon Dec  8 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 5.1.36-1
- jetpipe in ltsp-client requires pyserial
- /etc/cups/client.conf writable for local apps printing to to local
  printers directly (not common, requires cups installed in chroot)


ltspfs-0.5.8-1.fc10
-------------------
* Thu Dec 11 17:00:00 2008 Warren Togami <wtogami at redhat.com> - 0.5.8-1
- LOCALDEV_DENY stuff


mumbles-0.4-8.fc11
------------------

mutt-1.5.19-1.fc11
------------------
* Wed Jan  7 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 5:1.5.19-1
- update to 1.5.19
- switch hcache backend to tokyocabinet
- drop intr patch


nautilus-2.25.2-6.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 2.25.2-6
- Don't crash when closing spatial window very quickly after
  opening it (gnome bug 552859)


nfs-utils-1.1.4-12.fc11
-----------------------
* Wed Jan  7 17:00:00 2009 Steve Dickson <steved at redhat.com> 1.1.4-12
- configure: Remove inet_ntop(3) check from configure.ac
- configure: Add new build option "--enable-tirpc"
- showmount command: Quiesce warning when TI-RPC is disabled


nvclock-0.8-0.7.b4.fc11
-----------------------
* Wed Jan  7 17:00:00 2009 Adel Gadllah <adel.gadllah at gmail.com> 0.8-0.7.b4
- Update to new beta release
- New smartdimmer utility to control backlight on some NBs


openssl-0.9.8g-12.fc10
----------------------
* Wed Jan  7 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8g-12
- fix CVE-2008-5077 - incorrect checks for malformed signatures (#476671)
- add -no_ign_eof option (#462393)


perl-BDB-1.82-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 kwizart < kwizart at gmail.com > - 1.82-1
- Update to 1.82


perl-Hardware-Verilog-Parser-0.13-1.fc11
----------------------------------------

poker2d-1.7.3-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Christopher Stone <chris.stone at gmail.com> 1.7.3-1
- Upstream sync
- Remove no longer needed patches
- Remove new files in poker-network package


procps-3.2.7-23.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Adam Jackson <ajax at redhat.com> 3.2.7-23
- procps-3.2.7-vmstat-header.patch: Fix vmstat header to fit on a single line.


ptlib-2.5.2-2.fc11
------------------

python-gtkextra-1.1.0-5.fc11
----------------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1.1.0-5
- codegen moved from pygtk to pygobject, fix to rebuild

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 1.1.0-4
- Rebuild for Python 2.6


python-telepathy-0.15.6-1.fc11
------------------------------
* Wed Jan  7 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.15.6-1
- Update to 0.15.6.


python-webhelpers-0.6.4-2.fc11
------------------------------
* Wed Jan  7 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.6.4-2
- Remove some non-existent files.

* Tue Jan  6 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.6.4-1
- Update to 0.6.4
- Run the test suite


roundcubemail-0.2-6.stable.fc11
-------------------------------
* Mon Jan  5 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> = 0.2-6.stable
- New upstream.
- Dropped two most recent patches, applied upstream.


rsyslog-3.21.9-2.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Tomas Heinrich <theinric at redhat.com> 3.21.9-2
- fix several legacy options handling
- fix internal message output (#478612)


ruby-marc-0.2.2-1.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.2.2-1
- 0.2.2


scidavis-0.1.3-5.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.1.3-4
- sip patch (#479118)

* Wed Jan  7 17:00:00 2009 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 0.1.3-5
- Rebuild

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.1.3-3
- Rebuild for Python 2.6


seahorse-2.25.4-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> 2.25.4-1
- Update to 2.25.4


seamonkey-1.1.14-2.fc11
-----------------------
* Wed Jan  7 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 1.1.14-2
- Disable the crash dialog


setup-2.7.5-4.fc11
------------------
* Tue Jan  6 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2.7.5-4
- use lua language in post to prevent additional
  dependencies


syck-0.61-7.2.fc11
------------------
* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.61-7.2
- build isn't parallel-make safe


thunderbird-2.0.0.18-2.fc11
---------------------------
* Wed Jan  7 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 2.0.0.18-2
- Disable the crash dialog


tryton-1.0.2-1.fc11
-------------------
* Wed Jan  7 17:00:00 2009 Dan Hor??k <dan[at]danny.cz> 1.0.2-1
- update to upstream version 1.0.2


vdr-femon-1.6.6-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.6-1
- 1.6.6.


xfsprogs-2.10.2-2.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 2.10.2-2
- Fix perms of libhandle.so so that it's properly stripped


xorg-x11-drv-keyboard-1.3.2-1.fc11
----------------------------------
* Thu Jan  8 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 1.3.2-1
- keyboard 1.3.2


xorg-x11-drv-openchrome-0.2.903-6.fc11
--------------------------------------
* Wed Jan  7 17:00:00 2009 Xavier Bachelot <xavier at bachelot.org> - 0.2.903-6
- Fix crash with xserver 1.6 (changeset 712).


xqilla-2.1.3-0.4.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Milan Zazrivec <mzazrivec at redhat.com> 2.1.3-0.4
- fixed requirements for xqilla-devel package


xtide-2.10-3.fc11
-----------------
* Thu Jan  8 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.10-3
- Update harmonics data to 20081228
- Update xtide-get_harmonics-data.sh following harmonics tarball 
  format change


xulrunner-1.9.1-0.6.beta2.fc11
------------------------------
* Wed Jan  7 17:00:00 2009 Martin Stransky <stransky at redhat.com> 1.9.1-0.6
- Copied mozilla-config.h to stable include dir (#478445)


yum-3.2.21-2.fc11
-----------------
* Wed Jan  7 17:00:00 2009 Seth Vidal <skvidal at fedoraproject.org> - 3.2.21-1
- bump to 3.2.21


Summary:
Added Packages: 11
Removed Packages: 0
Modified Packages: 66
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	gnome-web-photo-0.3-13.fc10.i386 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-5.fc11.i386 requires libkformula.so.4
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.i386 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	python-gammu-0.27-3.fc11.i386 requires libGammu.so.4
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	screenie-1.30.0-2.fc11.noarch requires awk



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	gnome-web-photo-0.3-13.fc10.x86_64 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-5.fc11.x86_64 requires libkformula.so.4()(64bit)
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.x86_64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.x86_64 requires libGammu.so.4()(64bit)
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnome-web-photo-0.3-13.fc10.ppc requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-5.fc11.ppc requires libkformula.so.4
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	python-gammu-0.27-3.fc11.ppc requires libGammu.so.4
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	screenie-1.30.0-2.fc11.noarch requires awk



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	gnome-web-photo-0.3-13.fc10.ppc64 requires gecko-libs = 0:1.9.0.5
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	kdeedu-math-4.1.85-5.fc11.ppc64 requires libkformula.so.4()(64bit)
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pcmanx-gtk2-xulrunner-plugin-0.3.8-4.fc10.ppc64 requires xulrunner = 0:1.9.0.5
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	python-gammu-0.27-3.fc11.ppc64 requires libGammu.so.4()(64bit)
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	screenie-1.30.0-2.fc11.noarch requires awk





From mike.cloaked at gmail.com  Thu Jan  8 09:35:58 2009
From: mike.cloaked at gmail.com (Mike)
Date: Thu, 8 Jan 2009 09:35:58 +0000 (UTC)
Subject: F10/11 and Intel Integrated Graphics?
References: <loom.20090107T211629-323@post.gmane.org>	<alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>
	<20d6441a0901071419k1dc50f82s65e6619f0247bc9e@mail.gmail.com>
	<496536A2.3070406@ij.net>
Message-ID: <loom.20090108T093202-621@post.gmane.org>

Felix Miata <mrmazda <at> ij.net> writes:

> 
> Anyone tried the solution in 
https://bugzilla.novell.com/show_bug.cgi?id=463288 ?

Seems that the problem is in fact a serious upstream driver issue
There are a lot of reports:
See for example -
http://bugs.freedesktop.org/show_bug.cgi?id=17713
http://bugs.freedesktop.org/show_bug.cgi?id=19090
http://bugs.freedesktop.org/show_bug.cgi?id=17291
http://bugs.freedesktop.org/show_bug.cgi?id=18270
http://bugs.freedesktop.org/show_bug.cgi?id=17756
http://bugs.freedesktop.org/show_bug.cgi?id=19319
http://bugs.freedesktop.org/show_bug.cgi?id=14464
http://bugs.freedesktop.org/show_bug.cgi?id=17638

and the lists at
https://bugzilla.redhat.com/buglist.cgi?component=xorg-x11-drv-
i810&product=Fedora

or

https://admin.fedoraproject.org/pkgdb/packages/bugs/xorg-x11-drv-i810

It would be nice if Intel would help to get this fixed, and there are indeed
problems with Suse, Ubuntu and Mandriva also with newer drivers and Intel
graphics chipsets of various flavours - this is really bad!



From jorton at redhat.com  Thu Jan  8 10:47:21 2009
From: jorton at redhat.com (Joe Orton)
Date: Thu, 8 Jan 2009 10:47:21 +0000
Subject: /proc/sys/fs/epoll/max_user_instances=128 considered harmful
In-Reply-To: <20090107220122.GB17904@redhat.com>
References: <20090107151812.GA12074@redhat.com>
	<20090107220122.GB17904@redhat.com>
Message-ID: <20090108104721.GA5804@redhat.com>

On Wed, Jan 07, 2009 at 05:01:22PM -0500, Dave Jones wrote:
> On Wed, Jan 07, 2009 at 03:18:12PM +0000, Joe Orton wrote:
>  > The F10 kernel has /proc/sys/fs/epoll/max_user_instances set to 128 by 
>  > default.  Apache httpd uses one epoll fd ("instance") per child process, 
>  > so this sets a hard limit on 128 children (i.e. 100 concurrent clients) 
>  > out of the box.
>  > 
>  > 1) shouldn't this be an rlimit so that we can bump it appropriately in 
>  > the parent as root?
> 
> possibly.  It's a question better asked on linux-kernel really. 
> 
> This does sound like a better change to me than forcing the sysctl change
> on everyone.

Well, it's effectively a regression as-is.  Any chance someone from the 
kernel team can chase this upstream?

Regards, Joe



From rjones at redhat.com  Thu Jan  8 11:47:59 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 8 Jan 2009 11:47:59 +0000
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <4965264B.3020705@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<20090107103511.GA27484@amd.home.annexia.org>
	<4965264B.3020705@gmail.com>
Message-ID: <20090108114759.GA5982@amd.home.annexia.org>

On Wed, Jan 07, 2009 at 02:01:47PM -0800, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> > On Tue, Jan 06, 2009 at 01:16:59PM -0600, Jason L Tibbitts III wrote:
> >> * Make adherence to the FHS a MUST, [...]
> > 
> > Is there a recognized process for getting changes into upstream FHS?
> 
> Changes to the FHS are discussed on their mailing list hosted on
> Sourceforge::
> 
> http://sourceforge.net/projects/freestandards/

The discussion there seems mainly to revolve around the topics of
enlarging members and picking penny stocks:

http://sourceforge.net/mailarchive/forum.php?forum_name=freestandards-fhs-discuss
http://sourceforge.net/mailarchive/forum.php?forum_name=freestandards-ldps

I saw precisely 1 non-spam posting in the last 2 months (and that was
just a question).

This really matters.  If we're going to block projects because they
cannot fulfil FHS requirements (eg. as might have happened to MinGW
because of the /usr/<target> path) then there must be a way to get
changes into the FHS.

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 craftjml at gmail.com  Thu Jan  8 15:23:59 2009
From: craftjml at gmail.com (Jud Craft)
Date: Thu, 8 Jan 2009 09:23:59 -0600
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <loom.20090108T093202-621@post.gmane.org>
References: <loom.20090107T211629-323@post.gmane.org>
	<alpine.LFD.2.00.0901072205290.29137@vega1.dur.ac.uk>
	<20d6441a0901071419k1dc50f82s65e6619f0247bc9e@mail.gmail.com>
	<496536A2.3070406@ij.net> <loom.20090108T093202-621@post.gmane.org>
Message-ID: <20d6441a0901080723x19120796jdbd5e5dd66dff670@mail.gmail.com>

It'd be nice if Intel fixed it (and I find the irony delicious that in
the new XOrg, in addition to NVidia, not even the open source drivers
themselves can keep up stability), but failing gracefully with
acceleration switched off seems to be an excellent and preferable
compromise in the short term.  (Unless I misread, which is possible).

17638 seems like a separate issue (not related to the unstartable
X-server), but just general instability with the i945.  Looks like
they fixed that one.

17756 also sounds separate, referring to Xrandr problems and not the
inability to even launch the X-server, and that one looks resolved
too.

Apparently the intel driver has tons of issues, but then again, so do
all the drivers nowadays.



From kyle at mcmartin.ca  Thu Jan  8 15:31:54 2009
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Thu, 8 Jan 2009 10:31:54 -0500
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <49659A7A.8020804@leemhuis.info>
References: <496569B6.1090204@fedoraproject.org>
	<49659A7A.8020804@leemhuis.info>
Message-ID: <20090108153154.GB15684@bombadil.infradead.org>

On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
> IOW: Either enable or disable them. I'm unsure myself what to do but I  
> tend to say that disabling the whole staging drivers might be the best  
> for Fedora (Greg calls himself as "maintainer of crap" for a good 
> reason).
>
> @Davej, Cebbert and Kylem: What's your position on this?
>

I was largely ignoring staging/ for maintainability reasons, but if
there's sufficient demand I can take a look at enabling some of it on a
case by case basis, as long as it won't cause a tragic amount of grief
for everyone.

regards, Kyle



From davej at redhat.com  Thu Jan  8 15:35:42 2009
From: davej at redhat.com (Dave Jones)
Date: Thu, 8 Jan 2009 10:35:42 -0500
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <49659A7A.8020804@leemhuis.info>
References: <496569B6.1090204@fedoraproject.org>
	<49659A7A.8020804@leemhuis.info>
Message-ID: <20090108153542.GA14702@redhat.com>

On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:

 > Related: I raised the staging problem already in
 > https://bugzilla.redhat.com/show_bug.cgi?id=477927
 > as rawhide contained the at76 driver as separate patch
 > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
 > -- but the same driver (with two small changes) also was part of the 
 > upstream kernel since October/2.6.28-rc as one of the staging drivers:
 > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
 > (for more details see bug).
 > 
 > That sounds wrong to me, as
 > 
 > - it's duplicated work
 > 
 > - the at76 staging driver from upstream taints the kernel; the driver 
 > from our patch doesn't.

The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville.
I don't know the backstory behind at76, but it's been lingering for
quite a while, and it would be nice to see it go away yes.
I'm not clear on why this is going through -staging instead of wireless-dev either.
 
 > > The ralink wireless drivers for example would hopefully make the newer 
 > > EEE PC model would out of the box.  Does it make sense to enable the 
 > > drivers in staging tree by default and bring more exposure to them 
 > > atleast via rawhide if not in general releases?
 > 
 > +1 to the "I think providing hardware support in rawhide and then 
 > removing it  before release would be somewhat user-hostile." comment 
 > from mjg59.
 > 
 > IOW: Either enable or disable them. I'm unsure myself what to do but I 
 > tend to say that disabling the whole staging drivers might be the best 
 > for Fedora (Greg calls himself as "maintainer of crap" for a good reason).
 > @Davej, Cebbert and Kylem: What's your position on this?

I don't think we can make a carte-blanche statement to say "no we won't do this ever".
The quality of the drivers that end up there are going to vary, and for some,
if it's for a piece of hardware that's really popular, it may make sense
to enable it.  As long as doing so doesn't cause us headaches down the line.

I'm not overly against the idea of enabling something with the caveat
that we have someone responsible for working on it, with the goal of
getting it out of staging, and dealing with bugs etc.
Not unlike the same reasoning for us adding various not-yet-upstream drivers
to the Fedora kernel really.

But it's really going to be a case-by-case thing I think. 

	Dave

-- 
http://www.codemonkey.org.uk



From dcbw at redhat.com  Thu Jan  8 16:14:04 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 08 Jan 2009 11:14:04 -0500
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <20090108153542.GA14702@redhat.com>
References: <496569B6.1090204@fedoraproject.org>
	<49659A7A.8020804@leemhuis.info>  <20090108153542.GA14702@redhat.com>
Message-ID: <1231431244.21643.18.camel@localhost.localdomain>

On Thu, 2009-01-08 at 10:35 -0500, Dave Jones wrote:
> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
> 
>  > Related: I raised the staging problem already in
>  > https://bugzilla.redhat.com/show_bug.cgi?id=477927
>  > as rawhide contained the at76 driver as separate patch
>  > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
>  > -- but the same driver (with two small changes) also was part of the 
>  > upstream kernel since October/2.6.28-rc as one of the staging drivers:
>  > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
>  > (for more details see bug).
>  > 
>  > That sounds wrong to me, as
>  > 
>  > - it's duplicated work
>  > 
>  > - the at76 staging driver from upstream taints the kernel; the driver 
>  > from our patch doesn't.
> 
> The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville.
> I don't know the backstory behind at76, but it's been lingering for
> quite a while, and it would be nice to see it go away yes.
> I'm not clear on why this is going through -staging instead of wireless-dev either.

I would *not* recommend adding RTL staging driver at this time.  There's
a reason it wasn't imported into the actual kernel in the first place.
-staging is a bad idea for precisely the reason we're talking about this
now: it gives legitimacy to drivers of questionable quality.  While it
may make peoples hardware somewhat work, it certainly doesn't help make
the system as a whole work *better*, because the drivers don't
necessarily implement everything that, for example, wpa_supplicant or
NetworkManager expect, or v4l2, or whatever.

Does it use the in-kernel rfkill layer?  Does it have correct locking
and everything?  Does it use the *standard kernel wireless stack*?  The
answer to at least two of these is "no", which is why it's not approved
by the wireless developers yet, and never will be.

Just because a driver makes hardware work, doesn't mean it makes
hardware work *well* or play well with everything else.

Dan

>  > > The ralink wireless drivers for example would hopefully make the newer 
>  > > EEE PC model would out of the box.  Does it make sense to enable the 
>  > > drivers in staging tree by default and bring more exposure to them 
>  > > atleast via rawhide if not in general releases?
>  > 
>  > +1 to the "I think providing hardware support in rawhide and then 
>  > removing it  before release would be somewhat user-hostile." comment 
>  > from mjg59.
>  > 
>  > IOW: Either enable or disable them. I'm unsure myself what to do but I 
>  > tend to say that disabling the whole staging drivers might be the best 
>  > for Fedora (Greg calls himself as "maintainer of crap" for a good reason).
>  > @Davej, Cebbert and Kylem: What's your position on this?
> 
> I don't think we can make a carte-blanche statement to say "no we won't do this ever".
> The quality of the drivers that end up there are going to vary, and for some,
> if it's for a piece of hardware that's really popular, it may make sense
> to enable it.  As long as doing so doesn't cause us headaches down the line.
> 
> I'm not overly against the idea of enabling something with the caveat
> that we have someone responsible for working on it, with the goal of
> getting it out of staging, and dealing with bugs etc.
> Not unlike the same reasoning for us adding various not-yet-upstream drivers
> to the Fedora kernel really.
> 
> But it's really going to be a case-by-case thing I think. 
> 
> 	Dave
> 
> -- 
> http://www.codemonkey.org.uk
> 



From dcbw at redhat.com  Thu Jan  8 16:17:09 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 08 Jan 2009 11:17:09 -0500
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <20090108153154.GB15684@bombadil.infradead.org>
References: <496569B6.1090204@fedoraproject.org>
	<49659A7A.8020804@leemhuis.info>
	<20090108153154.GB15684@bombadil.infradead.org>
Message-ID: <1231431429.21643.22.camel@localhost.localdomain>

On Thu, 2009-01-08 at 10:31 -0500, Kyle McMartin wrote:
> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
> > IOW: Either enable or disable them. I'm unsure myself what to do but I  
> > tend to say that disabling the whole staging drivers might be the best  
> > for Fedora (Greg calls himself as "maintainer of crap" for a good 
> > reason).
> >
> > @Davej, Cebbert and Kylem: What's your position on this?
> >
> 
> I was largely ignoring staging/ for maintainability reasons, but if
> there's sufficient demand I can take a look at enabling some of it on a
> case by case basis, as long as it won't cause a tragic amount of grief
> for everyone.

The rtl driver has it's own 802.11 stack, just like linux-wlan-usb does
(p80211), which is also in staging.  I don't think we really want to be
maintaining twice as many wireless stacks going forward, do we?
Basically, I'm going to ignore any issues that come in from these
drivers because they aren't accepted upstream wireless drivers, despite
what gregkh (who's not a wireless developer) tries to make them.

The upstream wireless people have made it clear that these drivers
aren't acceptable in their current form, and it's unlikely either of
these will be, given that they will essentially need a complete rewrite
to use mac80211 (for rtl2860) and hostap (for linux-wlan-ng).

Dan




From dcbw at redhat.com  Thu Jan  8 16:21:18 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 08 Jan 2009 11:21:18 -0500
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <1231367225.5754.11.camel@localhost.localdomain>
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
	<loom.20090107T215239-554@post.gmane.org>
	<1231367225.5754.11.camel@localhost.localdomain>
Message-ID: <1231431678.21643.26.camel@localhost.localdomain>

On Wed, 2009-01-07 at 16:27 -0600, Callum Lerwick wrote:
> On Wed, 2009-01-07 at 21:54 +0000, Mike wrote:
> > Tomasz Torcz <tomek <at> pipebreaker.pl> writes:
> > 
> > >  Do you mean https://bugzilla.redhat.com/show_bug.cgi?id=464866
> > 
> > or
> > https://bugzilla.redhat.com/show_bug.cgi?id=473427
> > or
> > https://bugzilla.redhat.com/show_bug.cgi?id=429500
> > or
> > https://bugzilla.redhat.com/show_bug.cgi?id=473427
> > 
> > and a slew of others so yes it seems to cover a range of 
> > Intel Integrated graphics.
> 
> While we're complaining, Intel 830M has been broken since F9:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=441665

As a workaround, try adding a minimal xorg.conf with:

Option "EXANoComposite" "true"

I just ran into this updating a Dell Latitude C400 (i830) to F10, and
I'm interesting in fixing it.

Dan

> 
> And for that matter, F10 broke on my Radeon 9600XT too:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=474977
> 
> Blech. Is there something more I can do to help fix this? I have some C
> skills.
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From linville at redhat.com  Thu Jan  8 16:45:22 2009
From: linville at redhat.com (John W. Linville)
Date: Thu, 8 Jan 2009 11:45:22 -0500
Subject: Enabling drivers in staging tree in rawhide
In-Reply-To: <20090108153542.GA14702@redhat.com>
References: <496569B6.1090204@fedoraproject.org>
	<49659A7A.8020804@leemhuis.info>
	<20090108153542.GA14702@redhat.com>
Message-ID: <20090108164522.GA6069@redhat.com>

On Thu, Jan 08, 2009 at 10:35:42AM -0500, Dave Jones wrote:
> On Thu, Jan 08, 2009 at 07:17:30AM +0100, Thorsten Leemhuis wrote:
> 
>  > Related: I raised the staging problem already in
>  > https://bugzilla.redhat.com/show_bug.cgi?id=477927
>  > as rawhide contained the at76 driver as separate patch
>  > http://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/linux-2.6-at76.patch?view=markup
>  > -- but the same driver (with two small changes) also was part of the 
>  > upstream kernel since October/2.6.28-rc as one of the staging drivers:
>  > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99e06e372378c5833a0c60274b645dfb2e4a4b08
>  > (for more details see bug).
>  > 
>  > That sounds wrong to me, as
>  > 
>  > - it's duplicated work
>  > 
>  > - the at76 staging driver from upstream taints the kernel; the driver 
>  > from our patch doesn't.
> 
> The wireless stuff, I've pretty much deferred to the wireless maintainer, John Linville.
> I don't know the backstory behind at76, but it's been lingering for
> quite a while, and it would be nice to see it go away yes.
> I'm not clear on why this is going through -staging instead of wireless-dev either.

at76 looked like it was going to have a working mac80211-based
version some time ago.  The mac80211 port happened, but it broke the
driver... :-(

The version in -staging actually came from the Fedora kernel, so
enabling it and dropping our patch isn't such a bad idea.  I was
concerned that the busted mac80211 port of it might come back (and it
seem to have done so for now in 2.6.29), so I was leaning against it.
(I'm still mostly against that unless we can get the mac80211 port
backed-out of 2.6.29...)

Now Kalle Valo says he is working on a new mac80211 port of
that driver, and that he intends to rename it to avoid confusion.
I presume that will get to Linus through my trees when it becomes
available and hopefully at76_usb will disappear from -staging then.

Does that clear-up anything? :-)

John
-- 
John W. Linville
linville at redhat.com



From ville.skytta at iki.fi  Thu Jan  8 16:54:05 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 8 Jan 2009 18:54:05 +0200
Subject: Tracking new review requests?
In-Reply-To: <gk3g3e$6t7$3@ger.gmane.org>
References: <200901061431.53501.ville.skytta@iki.fi>
	<200901072026.02756.ville.skytta@iki.fi>
	<gk3g3e$6t7$3@ger.gmane.org>
Message-ID: <200901081854.06842.ville.skytta@iki.fi>

On Thursday 08 January 2009, Kevin Kofler wrote:
> Ville Skytt? wrote:
> > Thanks for the suggestion, but I use kmail which unfortunately does not
> > have
> > support for NNTP (or RSS) as far as I know, so this is not an option. 
> > Nor is using a different mail client or a dedicated NNTP reader only for
> > this purpose, and I'm not planning to switch completely away from kmail
> > either...
>
> Well, there's KNode for this purpose. I use it for all the mailing lists,
> it works great. :-)
>
> You can also use Kontact which gives you KMail and KNode in the same
> window.

Thanks for the suggestions, but both knode and kontact are apps I don't 
already use and I really want to avoid starting using any new ones for this 
purpose.



From bruno at wolff.to  Thu Jan  8 17:01:51 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 8 Jan 2009 11:01:51 -0600
Subject: Maintainer unavailable for a couple of months
Message-ID: <20090108170151.GA30119@wolff.to>

I have a bug (475919) against nethack-vultures that should be easy for any
maintainer to fix (two requires(pre) commands need to be added to the spec
file). The maintainer is having problems with their Fedora key and doesn't
have time now to deal with fixing it and hence can't commit any changes.
They estimate they won't have a chance to fix this for a couple of months.

This bug potentially impacts the game spin (I haven't tested if the install of
that game actually fails yet, though there is a message stating that the
package was skipped because the preinstall script failed) which I am hoping
can be made for the alpha release.

I am not a maintainer myself, so i can't go in and make the change. I would
appreciate it if someone could take a look at this in the next couple of
days.

Thanks.



From s-t-rhbugzilla at wwwdotorg.org  Thu Jan  8 17:18:35 2009
From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren)
Date: Thu, 8 Jan 2009 10:18:35 -0700 (MST)
Subject: font-schumacher-misc removed from xorg-x11-fonts-misc package? 
	(bug 478489)
Message-ID: <1231435115.1469.TMDA@tmda.severn.wwwdotorg.org>

https://bugzilla.redhat.com/show_bug.cgi?id=478489 says that package
xorg-x11-fonts-misc contains the Schumacher font under F9, but does not
under F10.

It looks like unison blows up if this font isn't installed.

Why was the font removed; is there some other replacement that
applications should use?



From m.a.young at durham.ac.uk  Thu Jan  8 17:23:07 2009
From: m.a.young at durham.ac.uk (M A Young)
Date: Thu, 8 Jan 2009 17:23:07 +0000 (GMT)
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <1231431678.21643.26.camel@localhost.localdomain>
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
	<loom.20090107T215239-554@post.gmane.org>
	<1231367225.5754.11.camel@localhost.localdomain>
	<1231431678.21643.26.camel@localhost.localdomain>
Message-ID: <alpine.GSO.2.00.0901081719320.3825@algedi.dur.ac.uk>

On Thu, 8 Jan 2009, Dan Williams wrote:

>> While we're complaining, Intel 830M has been broken since F9:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=441665
>
> As a workaround, try adding a minimal xorg.conf with:
>
> Option "EXANoComposite" "true"
>
> I just ran into this updating a Dell Latitude C400 (i830) to F10, and
> I'm interesting in fixing it.

It doesn't help with Bug 473809
https://bugzilla.redhat.com/show_bug.cgi?id=473809
style crashes.

The Option "AccelMethod" "XAA" suggestion from Bug 441665 does work and 
seems faster than Option "NoAccel" "true" which is what I was previously using.

 	Michael Young



From nicolas.mailhot at laposte.net  Thu Jan  8 18:53:52 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 08 Jan 2009 19:53:52 +0100
Subject: font-schumacher-misc removed from xorg-x11-fonts-misc package?
 (bug 478489)
In-Reply-To: <1231435115.1469.TMDA@tmda.severn.wwwdotorg.org>
References: <1231435115.1469.TMDA@tmda.severn.wwwdotorg.org>
Message-ID: <1231440832.9373.7.camel@arekh.okg>

Le jeudi 08 janvier 2009 ? 10:18 -0700, Stephen Warren a ?crit :
> https://bugzilla.redhat.com/show_bug.cgi?id=478489 says that package
> xorg-x11-fonts-misc contains the Schumacher font under F9, but does not
> under F10.

The usual reason for fonts being removed from existing packages like
xorg is licensing audit failure.

> It looks like unison blows up if this font isn't installed.

Which is why unison developpers should use fontconfig (via pango, cairo
or something higher-level) if they need text/font support.

Using the legacy core font system results in applications blowing up
sooner or later.

> Why was the font removed; is there some other replacement that
> applications should use?

You can use 'fixed'. It will probably be the last one to go. However as
long as unison depends on core fonts it may fail every other release.
Core font apps are highly susceptible to any font environment change,
and change happens.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/3a6ac532/attachment.sig>

From dledford at redhat.com  Thu Jan  8 19:15:21 2009
From: dledford at redhat.com (Doug Ledford)
Date: Thu, 08 Jan 2009 14:15:21 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <49654E18.6040709@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<1231278888.32405.845.camel@firewall.xsintricity.com>
	<4963DD10.1060002@gmail.com>
	<1231343414.32405.888.camel@firewall.xsintricity.com>
	<4964E450.6010909@gmail.com>
	<1231353860.32405.916.camel@firewall.xsintricity.com>
	<496502DC.4070603@gmail.com>
	<1231363539.32405.962.camel@firewall.xsintricity.com>
	<4965312A.4020909@gmail.com>
	<1231371476.32405.994.camel@firewall.xsintricity.com>
	<49654E18.6040709@gmail.com>
Message-ID: <1231442121.32405.1046.camel@firewall.xsintricity.com>

On Wed, 2009-01-07 at 16:51 -0800, Toshio Kuratomi wrote:
> Doug Ledford wrote:
> > On Wed, 2009-01-07 at 14:48 -0800, Toshio Kuratomi wrote:
> >> It depends on how you interpret the FHS, I suppose.  In the old
> >> packages, the config files are in /etc, the arch independent data (help
> >> files) are in a subdir or /usr/share/openmpi/, and most of the
> >> arch-specific files are under /usr/lib/openmpi/.  This satisfies the
> >> overarching goal of the FHS, separation of sharable and unsharable data.
> >>  it also satisfies the goal of separating arch specific and arch
> >> independent files.
> >>
> >> The question is whether the binaries can go there or have to go in
> >> /usr/bin and whether the libraries can go there or must go directly in
> >> /usr/lib.  For the libraries, we often put private libraries in a
> >> subdirectory of /usr/lib.  These differ in that they're public
> >> libraries.  I lean towards this being okay.  The binaries being in the
> >> subdirectory of %{_libdir} doesn't have as much precedent.  Perhaps we
> >> need to make that usage explicit in the Guidelines just like %{_libexecdir}?
> >>
> >> Looking at the new package I see that there's config files under
> >> %{_libdir}/openmpi.  I think these need to go in %{_sysconfdir} instead.
> >>  This is more important than binaries and libraries for several reasons:
> >>
> >> 1) Having them in %{_libdir} breaks the sharable/unsharable boundary
> > 
> > Not really, but that's due to typical usage of these specific files.  I
> > would tend to agree that files normally in /etc are something that are
> > intended to be edited on a per machine basis.  These files, even though
> > they are in %{_libdir}/%{mpidir}/etc, are not something that you would
> > edit on a per machine basis.  If anything, things like the
> > openmpi-default-hostfile would be edited on a per version basis (and
> > with this layout they have a per version etc directory to be contained
> > in).  This is because on a large cluster, you are likely to either allow
> > all the machines in the cluster to participate and would put all the
> > machines in the cluster in this config file, or you would have a segment
> > of the cluster that is dedicated to running this version of openmpi and
> > only those machines would be in this file.  Either way, for all the
> > machines you want running this version of openmpi by default, the file
> > would be the same (this assumes that a person might start the openmpi
> > job from any machine in the cluster that's part of the appropriate
> > group, you may have a control machine doing things instead, in which
> > case you really only have to edit the file on that one machine and all
> > the others will be passive clients and not care about the contents of
> > this file).
> > 
> Okay.. but then you preclude the possibility of running multiple
> instances of one mpi version within a cluster.  It sounds like that's
> not typical in your experience but it doesn't sound like a necessary
> limitation.

No, nothing's precluded.  None of these files are essential to the
openmpi operation (well, the mpivars.* files are essential to
mpi-selector operation, but they are files that should never be edited
by admins, they are created during the build process and are static, I
just stuck them there) and every single one of them has the option to be
overridden by an instance specific version of the file.

> > Now, the even more common scenario is that you have multiple different
> > MPI apps.  The admins typically would do a login per app so that the
> > default login environment for a given app is already pre-configured.
> > Amongst that would be things like selection of the right mpi, and host
> > files specific to what machines that app is allowed to run on.  Those
> > would all be in the home directory for the login and wouldn't require
> > editing the system wide etc files in here.
> > 
> Despite the environment being somewhat different than normal this kind
> of configuration is normal for any apps.
> 
> >> 2) They are files edited by system admins and looked at by the user.
> >> They should be in a predictable place for this reason.
> > 
> > In truth, they aren't edited much at all, and relying upon them is
> > frowned upon.  But, as I noted above, even if they are edited, they are
> > still generally shareable due to the nature of MPI clusters.
> > 
> 
> This is true of other applications as well, though....
> 
> So even if we don't care about people having multiple different openmpi
> instances within their cluster, this still doesn't answer what breaks by
> putting the config files in /etc.  Which is important because deviating
> breaks other sysadmin assumptions.

No, putting the files in /etc would actually break more sysadmin
assumptions that anything else.  OpenMPI and the mvapich stacks have
been installed under static prefix installations for far longer than
we've been interested in shipping them.  People totally new to the
openmpi realm/usage might have some assumptions broken, but people who
have been using openmpi and similar packages for years would have theirs
broken by our changes.

And it's not just the users.  The package itself has a configure option
to enable --prefix behavior by default, and if you read the man page
you'll see that there is a specific option for passing in the --prefix
to the run time environment, and in fact if you even just start the run
time environment using a full path such as /usr/local/bin/mpirun, it
automatically enables --prefix mode and sets the prefix to one directory
up from the one the binary is in, and then it passes %{prefix}/bin in
the path and %{prefix}/lib in the ld library path to the remote nodes.

>   For instance, if I was backing up
> all configuration files on these machines by backing up /etc, this would
> miss the openmpi configs.  If I was mounting the /usr filesystem
> read-only, this would prevent me from updating the config file on-the-fly.

True on both counts.  Of course, given clusters, totally irrelevant
points.  They don't back up individual /etc directories on any of the
cluster nodes.  All the nodes are set up so that they can be installed
by the cluster manager, and they can be reinstalled as needed.  Nodes
are disposable.  Also, they *do* mount /usr read-only in lots of
clusters, and they couldn't care less that default files are in there.
If they need to edit them, they go to the cluster disk controller node
and edit it where it isn't read-only and then all the nodes see the
changes.  More commonly, the batch scheduler they use has its own
private data directory on the controlling node and it writes the
necessary files on the fly (or passes the options entirely on the
command line) based upon what nodes it intends to start the job on.  My
point is that these "we care about single node issues" simply do not
exist in clusters, and *can't* exist or they make the cluster
unmaintainable.

> >> As you noted, there's also some FHS regressions compared to the current
> >> package:
> >>
> >> - include files are under %{_libdir} instead of under %{_includedir} --
> >> If these are arch specific include files then this makes sense.  If not,
> >> they belong in %{_includedir}.  What things were broken by doing that?
> > 
> > Two things here.  Remember that we allow simultaneous installs of
> > different versions of OpenMPI (you can't get it out of the yum channel
> > this way, and you can't do upgrades of OpenMPI or it wipes older
> > versions out, but you can download anything after the openmpi-1.2.5 I
> > think and install different copies of different versions, although that
> > does not include multiple releases of the same version, I only use n-v
> > in the naming, not full n-v-r, so for instance you couldn't have 1.2.7-5
> > and 1.2.7-6 installed, but you can have 1.1.8 and 1.2.7 installed at the
> > same time) in order to meet user requirements.  Differing versions can
> > have differing header files, so we can't just use %{_includedir}/%{name}
> > or they might conflict.  Putting the includes alongside the libs works
> > for just about any devel package that needs to use it because you can
> > just use --prefix to configure it to the right place.  Of course, the
> > gcc wrappers also know about where the right include files are, so it
> > works with mpicc without doing anything.  The second reason is that for
> > fortran use in particular, the header file produced during build is
> > different for different arches.
> 
> The correct way to do this is by having the version in the includedir:
>   %{_includedir}/openmpi-1.2.7/*.h
> 
> >  So aside from the multi-install issue,
> > there is an arch specific component to the headers that can't be worked
> > around due to limitations in the fortran language (or that's my
> > understanding, I haven't touched fortran since 1991 or so).
> > 
> So is it only the fortran headers that are arch specific or all all of
> them arch specific and only fortran doesn't have a way to workaround that?

All the headers except fortran have the ability to do things like #ifdef
__i386__ so that a single header works on all arches.  The fortan header
can't and must be specific to the arch it's referencing.  In the past,
what I tried to do was put the headers under %{_includedir}/openmpi and
then I created an arch specific dir and moved the arch specific header
into that.  Because of how openmpi's mpicc works, this then meant that I
had to run a sed script during the install on the files in
%{_datadir}/%{name}/help/*-wrapper.txt to edit in the additional include
directory into the default include search list (I also had to edit in -m
%{mode} on multilib capable arches).  This is why the datadir help files
had to be placed in an arch specific location.

> arch specific headers do belong in a subdir of %{_libdir}.  But most of
> the times just that file goes into %{_libdir}.  If you take a look at
> glib-devel, for instance, you have:
>   /usr/lib/glib/include/glibconfig.h
>   /usr/include/glib-1.2
>   /usr/include/glib-1.2/glib.h
>   /usr/include/glib-1.2/gmodule.h

I actually think that doing the above is worse than what I'm doing with
all of the openmpi include files in one place.  And when I *did* have
the openmpi includes inside %{_includedir}, I *still* kept all the
includes there and just created bit size specific include dirs under the
main openmpi include dir.  I find either of those alternatives superior
to the junk above.

> >> - man dirs are now under %{_libdir} instead of under %{_datadir}.  What
> >> broke by having these under %{_datadir}?
> > 
> > Multiple installs
> 
> This shouldn't be the case.  Once again, the correct solution to this
> problem is including the version in the directory name.
> 
> > and also if we put it under datadir, then we have to
> > fiddle with manpath when we set up the environment.  With them where
> > they are, the presence of %{_libdir}/%{mpidir}/bin in the exec path is
> > enough for man to track down the right man page automatically.
> > 
> And this should be something that environment modules takes care of.

Sorry, not convincing.  The openmpi package has unique requirements.  It
has assumptions about being in its own prefix coded into its actual
runtime operation.  And although openmpi might be able to do these
things, neither mvapich or mvapich2 even allow installing their files in
anything other than their own private prefix.  So making all these
changes to openmpi wouldn't solve the issue on the other two and would
simply serve to fragment how people handle the various MPI
implementations, taking us from one standard to two.  And this all
because the people that put out the FHS decided that if you are an ISV
then you can put code into /opt under a private prefix, but if you are
the OS vendor, then even if the code really *is* highly optional and not
shipped by default and really *should* be in /opt with its own prefix,
you can't do it.  My response to that is that the FHS people were being
dumbasses and should have left us with a bit more flexibility to do the
right thing depending on circumstances.  In fact, if I were to do
*anything* with the openmpi package, it would be to go ahead and move it
under /opt in defiance of FHS because that's where it really needs to
be.

-- 
Doug Ledford <dledford at redhat.com>
              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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/691311b8/attachment.sig>

From a.badger at gmail.com  Thu Jan  8 19:13:04 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 08 Jan 2009 11:13:04 -0800
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <20090108114759.GA5982@amd.home.annexia.org>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>	<20090107103511.GA27484@amd.home.annexia.org>	<4965264B.3020705@gmail.com>
	<20090108114759.GA5982@amd.home.annexia.org>
Message-ID: <49665040.9030903@gmail.com>

Richard W.M. Jones wrote:
> On Wed, Jan 07, 2009 at 02:01:47PM -0800, Toshio Kuratomi wrote:
>> Richard W.M. Jones wrote:
>>> On Tue, Jan 06, 2009 at 01:16:59PM -0600, Jason L Tibbitts III wrote:
>>>> * Make adherence to the FHS a MUST, [...]
>>> Is there a recognized process for getting changes into upstream FHS?
>> Changes to the FHS are discussed on their mailing list hosted on
>> Sourceforge::
>>
>> http://sourceforge.net/projects/freestandards/
> 
> The discussion there seems mainly to revolve around the topics of
> enlarging members and picking penny stocks:
> 
> http://sourceforge.net/mailarchive/forum.php?forum_name=freestandards-fhs-discuss
> http://sourceforge.net/mailarchive/forum.php?forum_name=freestandards-ldps
> 
> I saw precisely 1 non-spam posting in the last 2 months (and that was
> just a question).
> 
> This really matters.  If we're going to block projects because they
> cannot fulfil FHS requirements (eg. as might have happened to MinGW
> because of the /usr/<target> path) then there must be a way to get
> changes into the FHS.
> 
This particular case (cross-compilers) was addressed in the meeting::

(09:59:54 AM) abadger1999: "with exceptions for libexecdir (specified in
the GNU Coding Standards [LINK]) and /usr/target for crosscompilers"
(09:59:58 AM) abadger1999:
http://www.gnu.org/prep/standards/standards.html#Directory-Variables
(10:00:01 AM) hansg: spot, +1
(10:00:16 AM) ubertibbs: I'm sure there are other problems, but we
should simply address them when they come up.

We also are acknowledging here that we may not be able to get our
changes applied to the FHS (athimm tried to get libexecdir into FHS, for
instance, but was stymied by their current lack of interest in problems)
and we'll list more exceptions in the Guideline if necessary.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/c048253d/attachment.sig>

From andrea at andreafrancia.it  Thu Jan  8 20:20:47 2009
From: andrea at andreafrancia.it (Andrea Francia)
Date: Thu, 8 Jan 2009 21:20:47 +0100
Subject: Package trash-cli is ready for the review (#448122)
Message-ID: <e12fead70901081220o218672f9hd7f296063836bfe1@mail.gmail.com>

The trash-cli software provides command line interface to FreeDesktop
Trashcan.

A review bug was opened time ago but the package didn't pass the QA checks
because it had a generic name issue.
Now a new version which solve the generic name issue was released and this
was reported in the tracker comments.

The fixing release is came out two month later, and nobody is assigned to
this bug, so I think that nobody is currently reviewing it.

How can I get a review?

Bug entry: https://bugzilla.redhat.com/show_bug.cgi?id=448122
-- 
Andrea Francia
http://andreafrancia.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/798c2b88/attachment.htm>

From bruno at wolff.to  Thu Jan  8 20:57:52 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 8 Jan 2009 14:57:52 -0600
Subject: Maintainer unavailable for a couple of months
In-Reply-To: <20090108170151.GA30119@wolff.to>
References: <20090108170151.GA30119@wolff.to>
Message-ID: <20090108205752.GA2109@wolff.to>

On Thu, Jan 08, 2009 at 11:01:51 -0600,
  Bruno Wolff III <bruno at wolff.to> wrote:
> 
> I am not a maintainer myself, so i can't go in and make the change. I would
> appreciate it if someone could take a look at this in the next couple of
> days.

Jon Ciesla has stepped in to help out here.

Thanks Jon!



From lsof at nodata.co.uk  Thu Jan  8 21:26:33 2009
From: lsof at nodata.co.uk (nodata)
Date: Thu, 08 Jan 2009 22:26:33 +0100
Subject: ssh private key password
Message-ID: <1231449993.2181.2.camel@localhost.localdomain>

When I run ssh-add, a gnome dialog pops up asking me for the password to
my private ssh key.

I find this a little odd, since I am not running ssh to connect
anywhere.

I also find this a little disconcerting: I don't like giving my private
key's to programs that ask for it.

Is anyone else experiencing this?



From jkeating at redhat.com  Thu Jan  8 21:29:47 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 08 Jan 2009 16:29:47 -0500
Subject: ssh private key password
In-Reply-To: <1231449993.2181.2.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
Message-ID: <1231450187.4755.71.camel@localhost.localdomain>

On Thu, 2009-01-08 at 22:26 +0100, nodata wrote:
> When I run ssh-add, a gnome dialog pops up asking me for the password to
> my private ssh key.
> 
> I find this a little odd, since I am not running ssh to connect
> anywhere.
> 
> I also find this a little disconcerting: I don't like giving my private
> key's to programs that ask for it.
> 
> Is anyone else experiencing this?
> 

It's asking to store the passphrase in your gnome-keyring as
gnome-keyring is acting as an ssh-agent for you.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/ddad9b9e/attachment.sig>

From vonbrand at inf.utfsm.cl  Thu Jan  8 21:31:16 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 08 Jan 2009 18:31:16 -0300
Subject: ssh private key password
In-Reply-To: <1231449993.2181.2.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
Message-ID: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>

nodata <lsof at nodata.co.uk> wrote:
> When I run ssh-add, a gnome dialog pops up asking me for the password to
> my private ssh key.

That is the idea... it keeps the password for you, so you don't need to
enter it each time you connect to a site.

> I find this a little odd, since I am not running ssh to connect
> anywhere.

Then why using ssh-add(1)?!

> I also find this a little disconcerting: I don't like giving my private
> key's to programs that ask for it.

Neither do I, but this one is _meant_ to do so.

> Is anyone else experiencing this?

Everyday 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 lsof at nodata.co.uk  Thu Jan  8 21:42:28 2009
From: lsof at nodata.co.uk (nodata)
Date: Thu, 08 Jan 2009 22:42:28 +0100
Subject: ssh private key password
In-Reply-To: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
Message-ID: <1231450948.2181.5.camel@localhost.localdomain>

Am Donnerstag, den 08.01.2009, 18:31 -0300 schrieb Horst H. von Brand:
> nodata <lsof at nodata.co.uk> wrote:
> > When I run ssh-add, a gnome dialog pops up asking me for the password to
> > my private ssh key.
> 
> That is the idea... it keeps the password for you, so you don't need to
> enter it each time you connect to a site.

But I am already using ssh-agent to do this.

> 
> > I find this a little odd, since I am not running ssh to connect
> > anywhere.
> 
> Then why using ssh-add(1)?!

To add my key to ssh-agent.

> 
> > I also find this a little disconcerting: I don't like giving my private
> > key's to programs that ask for it.
> 
> Neither do I, but this one is _meant_ to do so.

But can't I chose which program stores my key? I'd rather something with
less code stores it.

> 
> > Is anyone else experiencing this?
> 
> Everyday here.



From jonathan.underwood at gmail.com  Thu Jan  8 21:48:49 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 8 Jan 2009 21:48:49 +0000
Subject: ssh private key password
In-Reply-To: <1231450948.2181.5.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
Message-ID: <645d17210901081348k6ec5dae1h57f200affe20c673@mail.gmail.com>

2009/1/8 nodata <lsof at nodata.co.uk>:
> Am Donnerstag, den 08.01.2009, 18:31 -0300 schrieb Horst H. von Brand:
> But can't I chose which program stores my key? I'd rather something with
> less code stores it.

By default this is set:

SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

so

unset SSH_ASKPASS

will get you what you want, I think.

HTH.
J.

ps. these sorts of questions should really be posted to the
fedora-list, not here.



From ricky at fedoraproject.org  Thu Jan  8 21:54:16 2009
From: ricky at fedoraproject.org (Ricky Zhou)
Date: Thu, 8 Jan 2009 16:54:16 -0500
Subject: ssh private key password
In-Reply-To: <1231450948.2181.5.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
Message-ID: <20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>

On 2009-01-08 10:42:28 PM, nodata wrote:
> > Then why using ssh-add(1)?!
> 
> To add my key to ssh-agent.
> 
> > 
> > > I also find this a little disconcerting: I don't like giving my private
> > > key's to programs that ask for it.
> > 
> > Neither do I, but this one is _meant_ to do so.
> 
> But can't I chose which program stores my key? I'd rather something with
> less code stores it.
From the ssh-add manpage:

     DISPLAY and SSH_ASKPASS
             If ssh-add needs a passphrase, it will read the passphrase from
             the current terminal if it was run from a terminal.  If ssh-add
             does not have a terminal associated with it but DISPLAY and
             SSH_ASKPASS are set, it will execute the program specified by
             SSH_ASKPASS and open an X11 window to read the passphrase.  This
             is particularly useful when calling ssh-add from a .xsession or
             related script.  (Note that on some machines it may be necessary
             to redirect the input from /dev/null to make this work.)

Perhaps the dialog that pops up is the program specified by your
SSH_ASKPASS environmental variable?  I'm pretty sure that this is only
for prompting, and the passphrase still only gets stored by ssh-agent.

Thanks,
Ricky

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/1e394dd3/attachment.sig>

From lsof at nodata.co.uk  Thu Jan  8 22:02:14 2009
From: lsof at nodata.co.uk (nodata)
Date: Thu, 08 Jan 2009 23:02:14 +0100
Subject: ssh private key password
In-Reply-To: <20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
Message-ID: <1231452134.2181.9.camel@localhost.localdomain>

Am Donnerstag, den 08.01.2009, 16:54 -0500 schrieb Ricky Zhou:
> On 2009-01-08 10:42:28 PM, nodata wrote:
> > > Then why using ssh-add(1)?!
> > 
> > To add my key to ssh-agent.
> > 
> > > 
> > > > I also find this a little disconcerting: I don't like giving my private
> > > > key's to programs that ask for it.
> > > 
> > > Neither do I, but this one is _meant_ to do so.
> > 
> > But can't I chose which program stores my key? I'd rather something with
> > less code stores it.
> From the ssh-add manpage:
> 
>      DISPLAY and SSH_ASKPASS
>              If ssh-add needs a passphrase, it will read the passphrase from
>              the current terminal if it was run from a terminal.  If ssh-add
>              does not have a terminal associated with it but DISPLAY and
>              SSH_ASKPASS are set, it will execute the program specified by
>              SSH_ASKPASS and open an X11 window to read the passphrase.  This
>              is particularly useful when calling ssh-add from a .xsession or
>              related script.  (Note that on some machines it may be necessary
>              to redirect the input from /dev/null to make this work.)
> 
> Perhaps the dialog that pops up is the program specified by your
> SSH_ASKPASS environmental variable?  I'm pretty sure that this is only
> for prompting, and the passphrase still only gets stored by ssh-agent.
> 
> Thanks,
> Ricky

I'm wondering when this changed (F10)? I'm sure it didn't act like this
in F9.

In F9, I would only be prompted to enter my passphrase if I sshed to a
box that accepted pubkey authentication and a ssh-agent did not already
have the key.
In F10 it asks earlier: when ssh-add is run.

But oh well, it does.




From ricky at fedoraproject.org  Thu Jan  8 22:21:43 2009
From: ricky at fedoraproject.org (Ricky Zhou)
Date: Thu, 8 Jan 2009 17:21:43 -0500
Subject: ssh private key password
In-Reply-To: <1231452134.2181.9.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
Message-ID: <20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>

On 2009-01-08 11:02:14 PM, nodata wrote:
> I'm wondering when this changed (F10)? I'm sure it didn't act like this
> in F9.
> 
> In F9, I would only be prompted to enter my passphrase if I sshed to a
> box that accepted pubkey authentication and a ssh-agent did not already
> have the key.
> In F10 it asks earlier: when ssh-add is run.
When you run ssh-add, you are *asking* for the passphrase to be stored
with ssh-agent, so of course, it has to ask for your passphrase.  This
is the very purpose of ssh-add.  Could you be confusing ssh-add with
something else?

Thanks,
Ricky
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/5736dbab/attachment.sig>

From lsof at nodata.co.uk  Thu Jan  8 22:42:26 2009
From: lsof at nodata.co.uk (nodata)
Date: Thu, 08 Jan 2009 23:42:26 +0100
Subject: ssh private key password
In-Reply-To: <20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
Message-ID: <1231454546.2181.10.camel@localhost.localdomain>

Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
> On 2009-01-08 11:02:14 PM, nodata wrote:
> > I'm wondering when this changed (F10)? I'm sure it didn't act like this
> > in F9.
> > 
> > In F9, I would only be prompted to enter my passphrase if I sshed to a
> > box that accepted pubkey authentication and a ssh-agent did not already
> > have the key.
> > In F10 it asks earlier: when ssh-add is run.
> When you run ssh-add, you are *asking* for the passphrase to be stored
> with ssh-agent, so of course, it has to ask for your passphrase.  This
> is the very purpose of ssh-add.  Could you be confusing ssh-add with
> something else?

No, I'm just getting annoyed that a GUI is popping up when I am using a
command line app. Not sure of the point of it, it seems counter
intuitive.



From jkeating at redhat.com  Thu Jan  8 22:59:57 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 08 Jan 2009 17:59:57 -0500
Subject: ssh private key password
In-Reply-To: <1231454546.2181.10.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
Message-ID: <1231455597.4755.74.camel@localhost.localdomain>

On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> 
> No, I'm just getting annoyed that a GUI is popping up when I am using a
> command line app. Not sure of the point of it, it seems counter
> intuitive.

You're using a command line app from a graphical terminal.

Also, cli apps aren't the only use for ssh and ssh keys.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/ac168f01/attachment.sig>

From pertusus at free.fr  Thu Jan  8 23:42:59 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 9 Jan 2009 00:42:59 +0100
Subject: ssh private key password
In-Reply-To: <1231455597.4755.74.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
Message-ID: <20090108234258.GE2447@free.fr>

On Thu, Jan 08, 2009 at 05:59:57PM -0500, Jesse Keating wrote:
> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > 
> > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > command line app. Not sure of the point of it, it seems counter
> > intuitive.
> 
> You're using a command line app from a graphical terminal.

Not a very appealing argument... The 'graphical terminal' is a 
terminal emulator, not something fancy, just a console with a 
shell in it...

> Also, cli apps aren't the only use for ssh and ssh keys.

But can't graphical applications simply ask the ssh-agent? Is the 
graphical ssh-add frontend doing more than the cli ssh-add?


I was also quite freakened out by ssh-add popping a box of an unknown
application when I did a ssh-add in a terminal of a liveCD.

--
Pat



From mw_triad at users.sourceforge.net  Thu Jan  8 23:46:15 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 08 Jan 2009 17:46:15 -0600
Subject: ssh private key password
In-Reply-To: <1231455597.4755.74.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>	<1231450948.2181.5.camel@localhost.localdomain>	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>	<1231452134.2181.9.camel@localhost.localdomain>	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
Message-ID: <gk6389$hkt$1@ger.gmane.org>

Jesse Keating wrote:
> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
>> No, I'm just getting annoyed that a GUI is popping up when I am using a
>> command line app. Not sure of the point of it, it seems counter
>> intuitive.
> 
> You're using a command line app from a graphical terminal.

...but according to Ricky Zhou:
> From the ssh-add manpage:
> 
>      DISPLAY and SSH_ASKPASS
>              If ssh-add needs a passphrase, it will read the passphrase from
>              the current terminal if it was run from a terminal.

...so shouldn't it use the terminal in this case? (isatty() thinks 
Konsole and xterm are terminals, at any rate.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
We apologize for the inconvenience. -- God's Last Message to Creation 
(as reported by Douglas Adams in the Hitchhiker's Guide series)



From mclasen at redhat.com  Fri Jan  9 00:43:15 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 08 Jan 2009 19:43:15 -0500
Subject: ssh private key password
In-Reply-To: <1231454546.2181.10.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
Message-ID: <1231461795.3174.2.camel@matthiasc>

On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
> > On 2009-01-08 11:02:14 PM, nodata wrote:
> > > I'm wondering when this changed (F10)? I'm sure it didn't act like this
> > > in F9.
> > > 
> > > In F9, I would only be prompted to enter my passphrase if I sshed to a
> > > box that accepted pubkey authentication and a ssh-agent did not already
> > > have the key.
> > > In F10 it asks earlier: when ssh-add is run.
> > When you run ssh-add, you are *asking* for the passphrase to be stored
> > with ssh-agent, so of course, it has to ask for your passphrase.  This
> > is the very purpose of ssh-add.  Could you be confusing ssh-add with
> > something else?
> 
> No, I'm just getting annoyed that a GUI is popping up when I am using a
> command line app. Not sure of the point of it, it seems counter
> intuitive.

If you don't want this, you can turn it off with
gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false



From aa.lucelio at gmail.com  Fri Jan  9 01:12:41 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Thu, 8 Jan 2009 23:12:41 -0200
Subject: skype in F10-x86_64
Message-ID: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>

Hello,
Does anybody use skype in F10-x86_64?  Does it work with F10?
I cannot get any sound with Skype for Linux. What's
happening?<http://support.skype.com/en_US/faq/FA197/I-cannot-get-any-sound-with-Skype-for-Linux-What-s-happening?frompage=category>
I would like to have sound and image on it.
Thanks,
Luc?lio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/615c542e/attachment.htm>

From seg at haxxed.com  Fri Jan  9 01:43:49 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 08 Jan 2009 19:43:49 -0600
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <1231431678.21643.26.camel@localhost.localdomain>
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
	<loom.20090107T215239-554@post.gmane.org>
	<1231367225.5754.11.camel@localhost.localdomain>
	<1231431678.21643.26.camel@localhost.localdomain>
Message-ID: <1231465429.18388.4.camel@localhost.localdomain>

On Thu, 2009-01-08 at 11:21 -0500, Dan Williams wrote:
> On Wed, 2009-01-07 at 16:27 -0600, Callum Lerwick wrote:
> > While we're complaining, Intel 830M has been broken since F9:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=441665
> 
> As a workaround, try adding a minimal xorg.conf with:
> 
> Option "EXANoComposite" "true"
> 
> I just ran into this updating a Dell Latitude C400 (i830) to F10, and
> I'm interesting in fixing it.

Works for me.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/899e734a/attachment.sig>

From bmaly at redhat.com  Fri Jan  9 02:32:13 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 08 Jan 2009 21:32:13 -0500
Subject: skype in F10-x86_64
In-Reply-To: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
Message-ID: <4966B72D.7040000@redhat.com>

Luc?lio Gomes de Freitas wrote:
> Hello,
> Does anybody use skype in F10-x86_64?  Does it work with F10?
> I cannot get any sound with Skype for Linux. What's happening? 
> <http://support.skype.com/en_US/faq/FA197/I-cannot-get-any-sound-with-Skype-for-Linux-What-s-happening?frompage=category>
> I would like to have sound and image on it.
> Thanks,
> Luc?lio.
I have not tried F10 yet but Ive installed on a bunch of x86_64 machines 
and there is a lot of fiddling involved with ALSA.
First check (with ALSA) that you can record from mic and playback (with 
arecord/aplay). Try recording a .wav file, etc. Ive found that most of 
the time the mute options and levels are wrong, try opening 
gnome-volume-control and look at capture settings. Also, skype tries to 
readjust mic levels in ALSA and this almost never works right, so you 
may want to go into skype config and disable that too.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090108/10629b75/attachment.htm>

From jamundso at gmail.com  Fri Jan  9 02:35:27 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Thu, 8 Jan 2009 20:35:27 -0600
Subject: ssh private key password
In-Reply-To: <1231461795.3174.2.camel@matthiasc>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
Message-ID: <6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>

On 1/8/09, Matthias Clasen <mclasen at redhat.com> wrote:
> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
>> No, I'm just getting annoyed that a GUI is popping up when I am using a
>> command line app. Not sure of the point of it, it seems counter
>> intuitive.
>
> If you don't want this, you can turn it off with
> gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false

Users, naturally, would not "want this" - it's intrusive and
completely unnecessary. In the Windows world, IT staff would be be
bombarded with virus warnings.

Please, make "false" the default.

jerry



From kevin.kofler at chello.at  Fri Jan  9 02:47:57 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 09 Jan 2009 03:47:57 +0100
Subject: Automatic update ran despite being disabled (which is bad)
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>
	<49657EFD.6060900@fedoraproject.org>
Message-ID: <gk6dst$94u$1@ger.gmane.org>

Rahul Sundaram wrote:
> Essentially a bug in PackageKit that was fixed in a update.

Unfortunately, even though we have changed the default both in kde-settings
and in the code itself, KPackageKit still sometimes decides it wants to
auto-install updates:
https://bugzilla.redhat.com/show_bug.cgi?id=475303

I have no idea why this happens, nor does the upstream KPackageKit author.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan  9 02:49:15 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 09 Jan 2009 03:49:15 +0100
Subject: Automatic update ran despite being disabled (which is bad)
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>
Message-ID: <gk6dvb$94u$2@ger.gmane.org>

Michael B Allen wrote:
> About 15 minutes ago a dialog popped up that claimed "Your system has
> been updated" (or something to that effect). The problem is, I didn't
> initiate an update and my system is not configured to automatically
> update.
> 
> Can anyone explain how this could happen?

Are you using KPackageKit?
https://bugzilla.redhat.com/show_bug.cgi?id=475303

Yes, I hate that bug too. But I looked at the code and didn't find the
slightest clue as to how it may happen, nor did the KPackageKit upstream
author.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan  9 03:11:24 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 09 Jan 2009 04:11:24 +0100
Subject: ssh private key password
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
Message-ID: <gk6f8s$cgs$1@ger.gmane.org>

Jerry Amundson wrote:
> Users, naturally, would not "want this" - it's intrusive and
> completely unnecessary. In the Windows world, IT staff would be be
> bombarded with virus warnings.
> 
> Please, make "false" the default.

Uh, a GUI prompt for the passphrase is a feature. It also gets used when you
use SSH from a GUI app, such as a client for a version control system. I
don't see how this is a problem.

        Kevin Kofler



From rda at rincon.com  Fri Jan  9 03:37:00 2009
From: rda at rincon.com (Bob Arendt)
Date: Thu, 08 Jan 2009 20:37:00 -0700
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <alpine.GSO.2.00.0901081719320.3825@algedi.dur.ac.uk>
References: <loom.20090107T211629-323@post.gmane.org>	<20090107214822.GA16228@mother.fordon.pl.eu.org>	<loom.20090107T215239-554@post.gmane.org>	<1231367225.5754.11.camel@localhost.localdomain>	<1231431678.21643.26.camel@localhost.localdomain>
	<alpine.GSO.2.00.0901081719320.3825@algedi.dur.ac.uk>
Message-ID: <4966C65C.20700@rincon.com>

M A Young wrote:
> On Thu, 8 Jan 2009, Dan Williams wrote:
> 
>>> While we're complaining, Intel 830M has been broken since F9:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=441665
>> As a workaround, try adding a minimal xorg.conf with:
>>
>> Option "EXANoComposite" "true"
>>
>> I just ran into this updating a Dell Latitude C400 (i830) to F10, and
>> I'm interesting in fixing it.
> 
> It doesn't help with Bug 473809
> https://bugzilla.redhat.com/show_bug.cgi?id=473809
> style crashes.
> 
> The Option "AccelMethod" "XAA" suggestion from Bug 441665 does work and
> seems faster than Option "NoAccel" "true" which is what I was previously using.
> 
And neither currently helps with  Bug 469292 (82845G/GL[Brookdale-G]/GE)
https://bugzilla.redhat.com/show_bug.cgi?id=469292
But the "XAA" did work for a short period.  Now it doesn't (details in bug).

I remember reading that there are several different generations
of intel graphics chips supported under this one xorg driver.
In the attempt to make a unified intel xorg driver, it appears
that some chipsets have been short-changed / overlooked.



From sundaram at fedoraproject.org  Fri Jan  9 06:08:52 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 09 Jan 2009 11:38:52 +0530
Subject: ssh private key password
In-Reply-To: <6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>	<1231450948.2181.5.camel@localhost.localdomain>	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>	<1231452134.2181.9.camel@localhost.localdomain>	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>	<1231454546.2181.10.camel@localhost.localdomain>	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
Message-ID: <4966E9F4.4050200@fedoraproject.org>

Jerry Amundson wrote:
> On 1/8/09, Matthias Clasen <mclasen at redhat.com> wrote:
>> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
>>> No, I'm just getting annoyed that a GUI is popping up when I am using a
>>> command line app. Not sure of the point of it, it seems counter
>>> intuitive.
>> If you don't want this, you can turn it off with
>> gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false
> 
> Users, naturally, would not "want this" - it's intrusive and
> completely unnecessary. In the Windows world, IT staff would be be
> bombarded with virus warnings.
> 
> Please, make "false" the default.

You don't speak on my behalf, please. I do prefer this as a user.

Rahul



From sundaram at fedoraproject.org  Fri Jan  9 06:17:17 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 09 Jan 2009 11:47:17 +0530
Subject: Automatic update ran despite being disabled (which is bad)
In-Reply-To: <gk6dst$94u$1@ger.gmane.org>
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>	<49657EFD.6060900@fedoraproject.org>
	<gk6dst$94u$1@ger.gmane.org>
Message-ID: <4966EBED.4050208@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> Essentially a bug in PackageKit that was fixed in a update.
> 
> Unfortunately, even though we have changed the default both in kde-settings
> and in the code itself, KPackageKit still sometimes decides it wants to
> auto-install updates:
> https://bugzilla.redhat.com/show_bug.cgi?id=475303
> 
> I have no idea why this happens, nor does the upstream KPackageKit author.

Ouch. I saw a bug report earlier being closed and heard from someone 
(you?), that this problem was fixed. It is a pretty bad bug to ignore 
someone's settings and auto-install updates like this. People are going 
to assume, we are doing something sneaky behind their back.

There was an issue earlier with PackageKit or gpk-application as well 
where it would install some packages (preupgrade and new version of 
PackageKit iirc) and that to my knowledge is indeed fixed now.

Rahul



From jamundso at gmail.com  Fri Jan  9 06:28:43 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 00:28:43 -0600
Subject: ssh private key password
In-Reply-To: <4966E9F4.4050200@fedoraproject.org>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<4966E9F4.4050200@fedoraproject.org>
Message-ID: <6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>

On 1/9/09, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Jerry Amundson wrote:
>> On 1/8/09, Matthias Clasen <mclasen at redhat.com> wrote:
>>> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
>>>> No, I'm just getting annoyed that a GUI is popping up when I am using a
>>>> command line app. Not sure of the point of it, it seems counter
>>>> intuitive.
>>> If you don't want this, you can turn it off with
>>> gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false
>>
>> Users, naturally, would not "want this" - it's intrusive and
>> completely unnecessary. In the Windows world, IT staff would be be
>> bombarded with virus warnings.
>>
>> Please, make "false" the default.
>
> You don't speak on my behalf, please. I do prefer this as a user.

I stand corrected. I hope, no matter what, that the process stands
exactly the way it is.
In fact, I hope more and more command line tools add this GUI pop-up
feature. It's awesome.

jerry



From kevin.kofler at chello.at  Fri Jan  9 08:21:43 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 09 Jan 2009 09:21:43 +0100
Subject: Automatic update ran despite being disabled (which is bad)
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>	<49657EFD.6060900@fedoraproject.org>
	<gk6dst$94u$1@ger.gmane.org> <4966EBED.4050208@fedoraproject.org>
Message-ID: <gk71eo$m4o$1@ger.gmane.org>

Rahul Sundaram wrote:
> Ouch. I saw a bug report earlier being closed and heard from someone
> (you?), that this problem was fixed. It is a pretty bad bug to ignore
> someone's settings and auto-install updates like this. People are going
> to assume, we are doing something sneaky behind their back.

Well, it was supposed to be fixed, but the setting still magically resets
even though this is no longer the default anywhere, we changed the default
everywhere in the code! I don't understand why and how it happens at all.
Maybe an array overflow or something truly nasty like that? Or a mixup of
variables?

And yes, IMHO this is an absolute showstopper and it sucks that we have been
unable to fix this for over a month now.

Any help welcome! (Experience with KDE code is likely to be required
though.)

        Kevin Kofler



From pavel.lisy at gmail.com  Fri Jan  9 08:28:19 2009
From: pavel.lisy at gmail.com (Pavel Lisy)
Date: Fri, 09 Jan 2009 09:28:19 +0100
Subject: ssh private key password
In-Reply-To: <gk6f8s$cgs$1@ger.gmane.org>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<gk6f8s$cgs$1@ger.gmane.org>
Message-ID: <1231489699.26060.7.camel@pali-pc.hk.tmapy.cz>

Kevin Kofler p??e v P? 09. 01. 2009 v 04:11 +0100:
> Jerry Amundson wrote:
> > Users, naturally, would not "want this" - it's intrusive and
> > completely unnecessary. In the Windows world, IT staff would be be
> > bombarded with virus warnings.
> > 
> > Please, make "false" the default.
> 
> Uh, a GUI prompt for the passphrase is a feature. It also gets used when you
> use SSH from a GUI app, such as a client for a version control system. I
> don't see how this is a problem.

But it is annoying when it asks for password-phrase even if I use ssh
keys without password. It changed between F9 and F10 and I didn't now
since this mail thread why it started open new window when I use command
line. 

I am voting for default false too or to put it to FAQ or Release Notes
to F10.

Pavel

-- 
Pavel Lisy <pavel.lisy at gmail.com>



From rawhide at fedoraproject.org  Fri Jan  9 08:30:31 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri,  9 Jan 2009 08:30:31 +0000 (UTC)
Subject: rawhide report: 20090109 changes
Message-ID: <20090109083031.4241D1F8260@releng2.fedora.phx.redhat.com>

Compose started at Fri Jan  9 06:01:03 UTC 2009

New package cdk
        Curses Development Kit
New package eboard
        Chess board interface for ICS
New package mod_scgi
        Python implementation of the SCGI protocol
New package nachocalendar
        Provides a flexible Calendar component to the Java Platform
New package teeworlds
        Online multi-player platform 2D shooter
Updated Packages:

anaconda-11.5.0.6-1
-------------------
* Thu Jan  8 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 11.5.0.6-1
- Collect DSO deps for NetworkManager plugins. (dcantrell)

* Thu Jan  8 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 11.5.0.5-1
- NetworkManager system settings plugins were renamed, change mk-images.
  (dcantrell)
- Add a message to install.log when package installation is done (#476953).
  (clumens)
- Add support for specifying which partition to upgrade (atodorov, #471232).
  (clumens)
- pykickstart has a new version of the upgrade command. (clumens)
- Log all calls to mount to /tmp/program.log as well. (clumens)
- Log everything from execWithRedirect or execWithCapture (#467690).
  (clumens)
- Update partedUtils.py:findExistingRootPartitions to return UUID
  (atodorov). (clumens)
- Don't skip the method screen when going back and forth (#477991). (clumens)
- Die on errors from upd-instroot/mk-images rather than continuing on (katzj)
- The FTP USER command does not need to be followed by a PASS (#477536).
  (clumens)


baekmuk-ttf-fonts-2.2-10.fc11
-----------------------------
* Fri Jan  9 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-10.fc11
- Resolves: rhbz#477332 (Convert to new font packaging guidelines.)


bind-9.6.0-2.P1.fc11
--------------------
* Thu Jan  8 17:00:00 2009 Adam Tkac <atkac redhat com> 32:9.6.0-2.P1
- 9.6.0-P1 release (CVE-2009-0025)


cairo-dock-2.0.0-0.3.svn1476_trunk.fc11
---------------------------------------
* Fri Jan  9 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1476


cjkunifonts-0.2.20080216.1-12.fc11
----------------------------------
* Tue Jan  6 17:00:00 2009 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-12.fc11
- Resolves: rhbz#477373 (Converted to new font packaging guidelines.)


condor-7.2.0-2.fc11
-------------------
* Thu Jan  8 17:00:00 2009 <matt at redhat> - 7.2.0-2
- (Re)added CONDOR_DEVELOPERS=NONE to the default condor_config.local
- Added missing Obsoletes for condor-static (thanks Michael Schwendt)


dovecot-1.1.8-1.fc11
--------------------
* Thu Jan  8 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.8-1
- dovecot updated to 1.1.8
- sieve-plugin updated to 1.1.6


e16-0.16.8.15-1.fc11
--------------------
* Thu Jan  8 17:00:00 2009 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.15-1
- 0.16.8.15


e16-docs-0.16.8.0.2-1.fc11
--------------------------
* Thu Jan  8 17:00:00 2009 Terje Rosten <terjeros at phys.ntnu.no> - 0.16.8.0.2-1
- 0.16.8.0.2


e16-epplets-0.12-1.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Terje Rosten <terjeros at phys.ntnu.no> - 0.12-1
- 0.12


eclipse-shelled-1.0.4-1.fc11
----------------------------
* Thu Jan  8 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 1.0.4-1
- Update to version 1.0.4.


eric-4.2.5-1.fc11
-----------------
* Thu Jan  8 17:00:00 2009 Johan Cwiklinski <johan AT x-tnd DOT be> 4.2.5-1
* 4.2.5


filezilla-3.2.0-1.fc11
----------------------
* Thu Jan  8 17:00:00 2009 kwizart < kwizart at gmail.com > - 3.2.0-1
- Update to 3.2.0 stable

* Tue Jan  6 17:00:00 2009 kwizart < kwizart at gmail.com > - 3.2.0-0.1_rc2
- Update to 3.2.0-rc2
- Add BR dbus-devel - Needs a fix for gnome-session
  see http://bugzilla.gnome.org/show_bug.cgi?id=559469


flashrom-0-0.15.20090112svn3852.fc11
------------------------------------
* Thu Jan  8 17:00:00 2009 Peter Lemenkov <lemenkov at gmail.com> 0-0.15.20090112svn3852
- Changed license to GPLv2
- SST49LF020 support
- AMD-768 chipset support
- i631x LPC support
- Support the MX29LV040C
- AMD SB700 flash enable
- Support for the AMD/ATI SB600 southbridge SPI
- SST25VF080B flash chip support
- Support for 32Mbit SPI flash SST25VF032B
- Support for bunch of Fujitsu and Macronix chips

* Mon Nov  3 17:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 0-0.14.20081103svn3723
- Dump ICH8/ICH9/ICH10 SPI registers
- Add additional SPI sector erase and chip erase command
- Add support for the ST M50FW002 chip
- Support for some Numonyx parts (M25PE)
- SPI boot flash support on EP80579
- Support for the Intel 82371MX (MPIIX) southbridge
- Support for the Intel 82371FB PIIX and 82371SB (PIIX3) southbridges
- Support for the VIA VT82C586A/B chipset
- ICH10 support to flashrom
- Support for AM29F002(N)B[BT]

* Mon Oct  6 18:00:00 2008 Peter Lemenkov <lemenkov at gmail.com> 0-0.13.20080928svn3602
- More ExcludeArch


glibc-2.9.90-2
--------------
* Thu Jan  8 17:00:00 2009 Jakub Jelinek <jakub at redhat.com> 2.9.90-2
- update from trunk

* Fri Jan  2 17:00:00 2009 Jakub Jelinek <jakub at redhat.com> 2.9.90-1
- update from trunk (#478314)

* Mon Dec  8 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.9-3
- temporarily disable _nss_dns_gethostbyname4_r (#459756)
- NIS hostname lookup fixes (#473073, #474800, BZ#7058)
- fix unsetenv (#472941)

* Thu Nov 13 17:00:00 2008 Jakub Jelinek <jakub at redhat.com> 2.9-2
- glibc 2.9 release
- fix CPU_ALLOC_SIZE on 32-bit arches (BZ#7029)


gnome-keyring-2.25.4.2-1.fc11
-----------------------------
* Thu Jan  8 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.4.2-1
- Update to 2.25.4.2


gnome-pilot-2.0.17-1.fc11
-------------------------
* Thu Jan  8 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.0.17-1
- Update to 2.0.17

* Wed Jul 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0.16-3
- fix license tag


gnome-pilot-conduits-2.0.17-1.fc11
----------------------------------
* Thu Jan  8 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.0.17-1
- Update to 2.0.17
- Bump gnome_pilot_version to 2.0.17.

* Wed Jul 23 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.0.16-2
- fix license tag


gnome-screensaver-2.25.2-2.fc11
-------------------------------
* Thu Jan  8 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.2-2
- Use better invisible char


gnome-web-photo-0.3-13.fc11
---------------------------
* Tue Jan  6 17:00:00 2009 Christopher Aillon <caillon at redhat.com> - 0.3-13
- Rebuild against newer gecko


gnonlin-0.10.10-2.fc11
----------------------

gnubversion-0.5-5.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.5-5
- Fix BRs.

* Thu Jan  8 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.5-4
- Place the library to libdir


grep-2.5.3-2.fc11
-----------------
* Thu Jan  8 17:00:00 2009 Stepan Kasal <skasal at redhat.com> 2.5.3-2
- fix bug #460641 (a.k.a. 479152)


guile-1.8.6-2.fc11
------------------
* Thu Jan  8 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> - 5:1.8.6-2
- include Emacs support (#478468)


gutenprint-5.2.3-2.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 5.2.3-2
- Only run the foomatic PPD update script on update, and make sure the
  script can deal with major version upgrades (bug #478328).


isomd5sum-1.0.5-1.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Jeremy Katz <katzj at redhat.com> - 1:1.0.5-1
- Don't install the unused python module (#479005)


kbd-1.15-1.fc11
---------------
* Thu Jan  8 17:00:00 2009 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.15-1
- Update to kbd-1.15

* Mon Sep  8 18:00:00 2008 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.12-32
- Rediff all patches to work with patch --fuzz=0
- Add static loadkeys
  Related: #451672


kde-filesystem-4-23.fc11
------------------------
* Thu Jan  8 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4-23
- macros.kde4: use %_cmake_lib_suffix64, %_cmake_lib_suffix64


kdebase-runtime-4.1.96-1.fc11
-----------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdeedu-4.1.96-2.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-2
- drop upstreamed cfitsio patch
- package manpages

* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> 4.1.96-1
- 4.2rc1


kdelibs-4.1.96-2.fc11
---------------------
* Thu Jan  8 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-2
- kdepim cmake files in correct place


kdepimlibs-4.1.96-1.fc11
------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.19.rc0.git9.fc11
--------------------------------

kvm-81-2.fc11
-------------
* Tue Jan  6 17:00:00 2009 Daniel P. Berrange <berrange at redhat.com> - 81-2
- Explicitly install newly built BIOS blobs (rhbz #478855)
- List all files explicitly so they don't silently go missing
- Don't claim ownership of the shared man page directories


libarchive-2.6.0-1.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> 2.6.0-1
- Update to 2.6.0


libburn-0.6.0-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Adel Gadllah <adel.gadllah at gmail.com> - 0.6.0-1
- New upstream version


liberation-fonts-1.04.93-3.fc11
-------------------------------
* Fri Jan  9 17:00:00 2009 Caius Chance <cchance at redhat.com> - 1.04.93-3.fc11
- Resolves: rhbz#477410 (Convert to new font packaging guidelines.)


libgeda-20081231-1.fc11
-----------------------
* Wed Dec 31 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


libglfw-2.6-3.fc11
------------------
* Thu Jan  8 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> 2.6-3
- Major refactor, since this was not properly reviewed
- Get rid of ugly sedding
- Install a DSO properly
- Use SONAME
- Fix Source URL
- Rename SPEC file to match the package name
- Nuke -doc subpackage, move development documentation into -devel
- Include all documentation
- Use macros consistently
- Indent consistently


libsyncml-0.5.0-1.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Felix Kaechele <felix at fetzig dot org> - 0.5.0-1
- upstream 0.5.0
- buildsystem changed to cmake


libwvstreams-4.5.1-1.fc11
-------------------------
* Thu Jan  8 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 4.5.1-1
- new upstream release 4.5.1 , removed applied patches
- activate --with-dbus(#479144)


mash-0.4.9-1.fc11
-----------------
* Thu Jan  8 17:00:00 2009 Bill Nottingham <notting at redhat.com> 0.4.9-1
- error out if strict_keys is set and we can't download the signed package


nethack-vultures-2.1.0-15.fc11
------------------------------
* Thu Jan  8 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.1.0-15
- Fix Requires(pre), BZ 475919.


netlabel_tools-0.19-1.fc11
--------------------------
* Thu Jan  8 17:00:00 2009 Peter Vrabec <pvrabec at redhat.com> - 0.19-1
- upgrade (#478903)


nspluginwrapper-1.3.0-1.fc11
----------------------------
* Thu Jan  8 17:00:00 2009 Martin Stransky <stransky at redhat.com> 1.1.8-3
- Updated to 1.3.0 and removed some fedora build patches


ntfs-3g-1.5222-0.2.RC.fc11
--------------------------
* Thu Jan  8 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 2:1.5222-0.2.RC
- move pkgconfig Requires to -devel package where it belongs


pcmanx-gtk2-0.3.8-3.fc11
------------------------
* Wed Jan  7 17:00:00 2009 Martin Stransky <stransky at redhat.com> - 0.3.8-3
- updated for xulrunner 1.9.1


perl-Data-TreeDumper-0.35-3.fc11
--------------------------------
* Thu Jan  8 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.35-3
- manually require Term::Size


perl-bioperl-1.5.9-0.3.2.fc11
-----------------------------
* Wed Jan  7 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.5.9-0.3.2
- Update to 1.6.0 release candidate 2
- Remove filter for Bio::Graphics*, upstream removed them from the
  tarball


phonon-4.2.96-3.fc11
--------------------
* Thu Jan  8 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.2.96-3
- new tarball
- put icons/scriptlets into main pkg
- Requires: phonon-backend

* Thu Jan  8 17:00:00 2009 Lorenzo Villani <lvillani at binaryhelix.net> - 4.2.96-2
- add gstreaer-logo.svg

* Thu Jan  8 17:00:00 2009 Lorenzo Villani <lvillani at binaryhelix.net> - 4.2.96-1
- 4.2.96
- rebase phonon-4.2.0-pulseaudio.patch (-> phonon-4.2.96-pulseaudio.patch)
- rebase phonon-4.2.70-xine-pulseaudio.patch 
  (-> phonon-4.2.96-xine-pulseaudio.patch)

* Fri Dec 12 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> 4.2.80-3
- rebuild for pkgconfig deps


php-xmpphp-0.1-0.4.rc1_r70.fc11
-------------------------------
* Thu Jan  8 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 0.1-0.4.rc1_r70
- Updated to 0.1rc1-r70


pykickstart-1.49-1.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 1.49-1
- Add upgrade --root-device (atodorov, #471232).
- Use python's builtin set rather than the Sets module (#477836, dcantrell).


python-gammu-0.28-1.fc11
------------------------
* Thu Jan  8 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.28-1
- devel n-v-r < F-10, syncing to rebuild against libGammu


python-kaa-metadata-0.7.5-1.fc11
--------------------------------
* Mon Jan  5 17:00:00 2009 kwizart < kwizart at gmail.com > - 0.7.5-1
- Update to 0.7.5


python-qpid-0.4.728142-3.fc11
-----------------------------
* Thu Jan  8 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.728142-3
- BZ 479212: add qmf dirs


screenie-1.30.0-3.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Fabian Affolter <fabian at bernewireless.net> - 1.30.0-3
- Fixed requires


system-config-printer-1.1.1-2.fc11
----------------------------------
* Thu Jan  8 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 1.1.1-2
- Updated pycups to 1.9.45.


unison213-2.13.16-13.fc11
-------------------------
* Thu Jan  8 17:00:00 2009 Stephen Warren <s-t-rhbugzilla at wwwdotorg.org> - 2.13.16-13
- Add Requires: xorg-x11-fonts-misc


unison227-2.27.57-11.fc11
-------------------------
* Thu Jan  8 17:00:00 2009 Stephen Warren <s-t-rhbugzilla at wwwdotorg.org> - 2.27.57-11
- Add Requires: xorg-x11-fonts-misc


unuran-1.3-1.devel.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 1.3-1.devel.fc11
- Update to 1.3.devel

* Thu Dec 18 17:00:00 2008 Neal Becker <ndbecker2 at gmail.com> - 1.3.0-1
- Update to 1.3.0


vim-7.2.079-2.fc11
------------------
* Thu Jan  8 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 7.2.079-2
- patchlevel 79


wine-1.1.12-1.fc11
------------------
* Mon Jan  5 17:00:00 2009 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 1.1.12-1
- version upgrade


xen-3.3.1-1.fc11
----------------
* Thu Jan  8 17:00:00 2009 Gerd Hoffmann <kraxel at redhat.com> - 3.3.1-1
- update to xen 3.3.1 release.


xfsprogs-2.10.2-3.fc11
----------------------
* Thu Jan  8 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 2.10.2-3
- Fix perms of libhandle.so in specfile, not makefile


xine-lib-1.1.16-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1.1.16-1
- xine-lib-1.1.16, plugin ABI 1.25
- --with-external-libdvdnav, include mpeg demuxers (#213597)


xorg-x11-server-1.5.99.3-8.fc11
-------------------------------
* Thu Jan  8 17:00:00 2009 Adam Jackson <ajax at redhat.com> 1.5.99.3-8
- xserver-1.5.99.3-broken-mtrr-header.patch: Unbreak broken mtrr.h.

* Wed Jan  7 17:00:00 2009 Adam Tkac <atkac redhat com> 1.5.99.3-6
- use "git am" instead of "git-am"
- added more sources into xorg-x11-server-source to make source compilable

* Wed Jan  7 17:00:00 2009 Adam Jackson <ajax at redhat.com> 1.5.99.3-7
- xserver-1.5.99.3-offscreen-pixmaps.patch: Turn off offscreen pixmaps in XAA.
  Again.  Sigh.


Summary:
Added Packages: 5
Removed Packages: 0
Modified Packages: 66
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.i386 requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.i386 requires libboost_python.so.3
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.x86_64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.x86_64 requires libexiv2.so.4()(64bit)
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc requires libexiv2.so.4
	pyexiv2-0.1.2-5.fc11.ppc requires libboost_python.so.3
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pyexiv2-0.1.2-5.fc11.ppc64 requires libboost_python.so.3()(64bit)
	pyexiv2-0.1.2-5.fc11.ppc64 requires libexiv2.so.4()(64bit)
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From fedora at camperquake.de  Fri Jan  9 08:32:26 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 9 Jan 2009 09:32:26 +0100
Subject: ssh private key password
In-Reply-To: <645d17210901081348k6ec5dae1h57f200affe20c673@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<645d17210901081348k6ec5dae1h57f200affe20c673@mail.gmail.com>
Message-ID: <20090109093226.44f50676@dhcp03.addix.net>

Hi.

On Thu, 8 Jan 2009 21:48:49 +0000, Jonathan Underwood wrote:

> By default this is set:
> 
> SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

For the record: /usr/libexec/openssh/gnome-ssh-askpass is _not_ the program
popping up when ssh-add is run from an xterm. It seems like the ssh-agent
program (which is not the classical ssh-agent anymore, but a part of gnome)
is doing this on it's own, which explains why it does not care about being
called from a terminal or not.



From rjones at redhat.com  Fri Jan  9 09:13:30 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 9 Jan 2009 09:13:30 +0000
Subject: Summary of the 2009-01-06 Packaging Committee meeting
In-Reply-To: <49665040.9030903@gmail.com>
References: <ufawsd8nt1w.fsf@epithumia.math.uh.edu>
	<20090107103511.GA27484@amd.home.annexia.org>
	<4965264B.3020705@gmail.com>
	<20090108114759.GA5982@amd.home.annexia.org>
	<49665040.9030903@gmail.com>
Message-ID: <20090109091330.GA13168@amd.home.annexia.org>

On Thu, Jan 08, 2009 at 11:13:04AM -0800, Toshio Kuratomi wrote:
[...]
> We also are acknowledging here that we may not be able to get our
> changes applied to the FHS (athimm tried to get libexecdir into FHS, for
> instance, but was stymied by their current lack of interest in problems)
> and we'll list more exceptions in the Guideline if necessary.

What's the purpose of this statement then?

> >>>> * Make adherence to the FHS a MUST, [...]

Sounds like we're continuing business as usual - we'll continue to use
FHS from 2004, and will make ad-hoc decisions as required about
exceptions, because as we've seen there is no hope of getting any
changes into FHS itself, since FHS is a dead project.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From stlwrt at gmail.com  Fri Jan  9 09:13:36 2009
From: stlwrt at gmail.com (Pavel Shevchuk)
Date: Fri, 9 Jan 2009 11:13:36 +0200
Subject: skype in F10-x86_64
In-Reply-To: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
Message-ID: <d25f375f0901090113o40a0d404jd6e3f18c67cbb445@mail.gmail.com>

I use skype on F10 x86_64. Works fine except sound capture which is
buggy with my emu10k1 (skype bug)

2009/1/9 Luc?lio Gomes de Freitas <aa.lucelio at gmail.com>:
> Hello,
> Does anybody use skype in F10-x86_64?  Does it work with F10?
> I cannot get any sound with Skype for Linux. What's happening?
> I would like to have sound and image on it.
> Thanks,
> Luc?lio.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
http://scwlab.com



From rmy at tigress.co.uk  Fri Jan  9 09:23:30 2009
From: rmy at tigress.co.uk (Ron Yorston)
Date: Fri, 09 Jan 2009 09:23:30 +0000
Subject: ssh private key password
In-Reply-To: <gk6f8s$cgs$1@ger.gmane.org>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<gk6f8s$cgs$1@ger.gmane.org>
Message-ID: <200901090923.n099NVSd018356@tiffany.internal.tigress.co.uk>

Kevin Kofler <kevin.kofler at chello.at> wrote:
>Jerry Amundson wrote:
>> Users, naturally, would not "want this" - it's intrusive and
>> completely unnecessary. In the Windows world, IT staff would be be
>> bombarded with virus warnings.
>> 
>> Please, make "false" the default.
>
>Uh, a GUI prompt for the passphrase is a feature. It also gets used when you
>use SSH from a GUI app, such as a client for a version control system. I
>don't see how this is a problem.

My ssh passphrase is a private matter between me and the ssh client.  I
don't even trust ssh-agent, why would I trust some unexpected GUI that
pops up and demands my passphrase?

I was annoyed when the dialog appeared the first time I used ssh in F10
and made a point of turning it off before making an ssh connection.  I'd
prefer it to be off by default.

Ron



From aph at redhat.com  Fri Jan  9 09:45:09 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 09 Jan 2009 09:45:09 +0000
Subject: ssh private key password
In-Reply-To: <200901090923.n099NVSd018356@tiffany.internal.tigress.co.uk>
References: <1231449993.2181.2.camel@localhost.localdomain>	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>	<1231450948.2181.5.camel@localhost.localdomain>	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>	<1231452134.2181.9.camel@localhost.localdomain>	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>	<1231454546.2181.10.camel@localhost.localdomain>	<1231461795.3174.2.camel@matthiasc>	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>	<gk6f8s$cgs$1@ger.gmane.org>
	<200901090923.n099NVSd018356@tiffany.internal.tigress.co.uk>
Message-ID: <49671CA5.2080602@redhat.com>

Ron Yorston wrote:
> Kevin Kofler <kevin.kofler at chello.at> wrote:
>> Jerry Amundson wrote:
>>> Users, naturally, would not "want this" - it's intrusive and
>>> completely unnecessary. In the Windows world, IT staff would be be
>>> bombarded with virus warnings.
>>>
>>> Please, make "false" the default.
>> Uh, a GUI prompt for the passphrase is a feature. It also gets used when you
>> use SSH from a GUI app, such as a client for a version control system. I
>> don't see how this is a problem.
> 
> My ssh passphrase is a private matter between me and the ssh client.  I
> don't even trust ssh-agent, why would I trust some unexpected GUI that
> pops up and demands my passphrase?

That's right.  The key argument against a pop-up dialog box that asks
for the passphrase is that we're training people to type secrets into
pop-up dialog boxes.  Bad psychology, bad security.

Andrew.



From tim at niemueller.de  Fri Jan  9 11:04:07 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Fri, 09 Jan 2009 12:04:07 +0100
Subject: skype in F10-x86_64
In-Reply-To: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
Message-ID: <49672F27.1060302@niemueller.de>

Luc?lio Gomes de Freitas schrieb:
> Hello,
> Does anybody use skype in F10-x86_64?  Does it work with F10?
> I cannot get any sound with Skype for Linux. What's happening?
> <http://support.skype.com/en_US/faq/FA197/I-cannot-get-any-sound-with-Skype-for-Linux-What-s-happening?frompage=category>
> I would like to have sound and image on it.

I had to change the input device to not use pulseaudio but the ALSA
device directly. With PA it wouldn't work.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From jonathan.underwood at gmail.com  Fri Jan  9 11:12:34 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Fri, 9 Jan 2009 11:12:34 +0000
Subject: ssh private key password
In-Reply-To: <20090109093226.44f50676@dhcp03.addix.net>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<645d17210901081348k6ec5dae1h57f200affe20c673@mail.gmail.com>
	<20090109093226.44f50676@dhcp03.addix.net>
Message-ID: <645d17210901090312u79314f21v323697d8d8a79d26@mail.gmail.com>

2009/1/9 Ralf Ertzinger <fedora at camperquake.de>:
> Hi.
>
> On Thu, 8 Jan 2009 21:48:49 +0000, Jonathan Underwood wrote:
>
>> By default this is set:
>>
>> SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
>
> For the record: /usr/libexec/openssh/gnome-ssh-askpass is _not_ the program
> popping up when ssh-add is run from an xterm. It seems like the ssh-agent
> program (which is not the classical ssh-agent anymore, but a part of gnome)
> is doing this on it's own, which explains why it does not care about being
> called from a terminal or not.

I never said it was :) I just said unset it, and the behaviour reverts.



From jonathan.underwood at gmail.com  Fri Jan  9 14:06:32 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Fri, 9 Jan 2009 14:06:32 +0000
Subject: skype in F10-x86_64
In-Reply-To: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
Message-ID: <645d17210901090606x5653d4e1g4426a65b938a2972@mail.gmail.com>

2009/1/9 Luc?lio Gomes de Freitas <aa.lucelio at gmail.com>:
> Hello,
> Does anybody use skype in F10-x86_64?  Does it work with F10?
> I cannot get any sound with Skype for Linux. What's happening?
> I would like to have sound and image on it.
> Thanks,
> Luc?lio.

This question is more appropriate for the fedora-list, not
fedora-devel-list which si for discussion related to the development
of Fedora.



From linville at redhat.com  Fri Jan  9 14:11:39 2009
From: linville at redhat.com (John W. Linville)
Date: Fri, 9 Jan 2009 09:11:39 -0500
Subject: ssh private key password
In-Reply-To: <6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<4966E9F4.4050200@fedoraproject.org>
	<6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>
Message-ID: <20090109141139.GB17648@redhat.com>

On Fri, Jan 09, 2009 at 12:28:43AM -0600, Jerry Amundson wrote:

> In fact, I hope more and more command line tools add this GUI pop-up
> feature. It's awesome.

I'm curious, why is this awesome?  It seems to me that if one has
chosen to type commands into a terminal emulator that changing focus
to a different window for further input violates the 'rule of least
suprise'?  Or is this some form of "GUI = good, CLI = bad" religion?

John
-- 
John W. Linville
linville at redhat.com



From linville at redhat.com  Fri Jan  9 14:12:47 2009
From: linville at redhat.com (John W. Linville)
Date: Fri, 9 Jan 2009 09:12:47 -0500
Subject: ssh private key password
In-Reply-To: <1231461795.3174.2.camel@matthiasc>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
Message-ID: <20090109141247.GC17648@redhat.com>

On Thu, Jan 08, 2009 at 07:43:15PM -0500, Matthias Clasen wrote:
> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
> > > On 2009-01-08 11:02:14 PM, nodata wrote:
> > > > I'm wondering when this changed (F10)? I'm sure it didn't act like this
> > > > in F9.
> > > > 
> > > > In F9, I would only be prompted to enter my passphrase if I sshed to a
> > > > box that accepted pubkey authentication and a ssh-agent did not already
> > > > have the key.
> > > > In F10 it asks earlier: when ssh-add is run.
> > > When you run ssh-add, you are *asking* for the passphrase to be stored
> > > with ssh-agent, so of course, it has to ask for your passphrase.  This
> > > is the very purpose of ssh-add.  Could you be confusing ssh-add with
> > > something else?
> > 
> > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > command line app. Not sure of the point of it, it seems counter
> > intuitive.
> 
> If you don't want this, you can turn it off with
> gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false

Sorry for the troll, but I just had to admire this.  One has to love
the easy discoverability of GNOME configuration methods... :-)

John
-- 
John W. Linville
linville at redhat.com



From linville at redhat.com  Fri Jan  9 14:16:24 2009
From: linville at redhat.com (John W. Linville)
Date: Fri, 9 Jan 2009 09:16:24 -0500
Subject: ssh private key password
In-Reply-To: <1231455597.4755.74.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
Message-ID: <20090109141623.GD17648@redhat.com>

On Thu, Jan 08, 2009 at 05:59:57PM -0500, Jesse Keating wrote:
> On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > 
> > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > command line app. Not sure of the point of it, it seems counter
> > intuitive.
> 
> You're using a command line app from a graphical terminal.

I'm not sure I see your point.  Changing focus to another window just
to type a passphrase seems at best to add zero benefit and at worst
to provide surprise and distraction.  What is the benefit?
 
> Also, cli apps aren't the only use for ssh and ssh keys.

Is this an either/or situation?  The cited man page would seem to
indicate that GUI apps can use this feature while CLI invocations
should not.  FWIW, that would seem to me to be the "least surprise"
behavior.

John
-- 
John W. Linville
linville at redhat.com



From jamundso at gmail.com  Fri Jan  9 14:22:50 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 08:22:50 -0600
Subject: ssh private key password
In-Reply-To: <20090109141139.GB17648@redhat.com>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<4966E9F4.4050200@fedoraproject.org>
	<6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>
	<20090109141139.GB17648@redhat.com>
Message-ID: <6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>

On 1/9/09, John W. Linville <linville at redhat.com> wrote:
> On Fri, Jan 09, 2009 at 12:28:43AM -0600, Jerry Amundson wrote:
>> In fact, I hope more and more command line tools add this GUI pop-up
>> feature. It's awesome.
>
> I'm curious, why is this awesome?  It seems to me that if one has
> chosen to type commands into a terminal emulator that changing focus
> to a different window for further input violates the 'rule of least
> surprise'?  Or is this some form of "GUI = good, CLI = bad" religion?

I agree with you.
I was being sarcastic to the person who preferred the current behavior.

jerry



From mcepl at redhat.com  Fri Jan  9 14:15:26 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 09 Jan 2009 15:15:26 +0100
Subject: F10/11 and Intel Integrated Graphics?
References: <loom.20090107T211629-323@post.gmane.org>
Message-ID: <uo2k36x32m.ln2@ppp1053.in.ipex.cz>

On 2009-01-07, 21:28 GMT, Mike wrote:
> However on two machines, one of which is only 3 years old and 
> is a Dell 5150 with 82945G integrated graphics, it was a mess 
> when it came to graphics - and the other machine was a Dell 
> Dimension 2400 a little older with 82845G graphics which was 
> also non-trivial to get installed.

Problem with intel driver is that we are waiting on mighty 
rewrite of intel driver for Rawhide, which would include KMS 
support and other stuff, and so nobody is willing to spend much 
time on something, which will get rewritten anyway.

Mat?j



From veillard at redhat.com  Fri Jan  9 14:50:50 2009
From: veillard at redhat.com (Daniel Veillard)
Date: Fri, 9 Jan 2009 15:50:50 +0100
Subject: New Fedora virtualization list: fedora-virt
Message-ID: <20090109145050.GC9484@redhat.com>

 Considering the size of virtualization in Fedora it makes sense
to have a dedicated mailing-list, and at the moment the existing
list Fedora-xen at redhat.com doesn't really fit the current state
of Fedora virtualization, so I created a new list:
   https://www.redhat.com/mailman/listinfo/fedora-virt
maybe this will avoid getting posts about KVM problems or setup
on a list with a Xen centric focus :-)
The new list would be the correct place for anything related to
virtualization in fedora, both user and development issues,
and all hypervisors. The old list sounds the right place for
people still using Fedora <= 8 with Xen,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/



From jkeating at redhat.com  Fri Jan  9 15:19:35 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 09 Jan 2009 10:19:35 -0500
Subject: ssh private key password
In-Reply-To: <20090109141247.GC17648@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc> <20090109141247.GC17648@redhat.com>
Message-ID: <1231514375.4755.88.camel@localhost.localdomain>

On Fri, 2009-01-09 at 09:12 -0500, John W. Linville wrote:
> 
> Sorry for the troll, but I just had to admire this.  One has to love
> the easy discoverability of GNOME configuration methods... :-)

Because discovering how to configure wireless from the command line is
oh so easy?  (;

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/ff58b7b8/attachment.sig>

From jkeating at redhat.com  Fri Jan  9 15:22:56 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 09 Jan 2009 10:22:56 -0500
Subject: ssh private key password
In-Reply-To: <20090109141623.GD17648@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
Message-ID: <1231514576.4755.91.camel@localhost.localdomain>

On Fri, 2009-01-09 at 09:16 -0500, John W. Linville wrote:
> Is this an either/or situation?  The cited man page would seem to
> indicate that GUI apps can use this feature while CLI invocations
> should not.  FWIW, that would seem to me to be the "least surprise"
> behavior.

*shrug*  I'm not claiming that there isn't a bug, I just didn't
investigate much.  It seemed to work just like calling a
system-config-foo app from a graphical terminal, it'll launch the gui
version.  It didn't exactly strike me as odd that the ssh passphrase
came up as a gui.  I just like that it works automatically, I don't have
to manually call ssh-add.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/3cbc875a/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Jan  9 15:32:52 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 10 Jan 2009 00:32:52 +0900
Subject: New maintainer request for ruby-gnome2
Message-ID: <49676E24.9070309@ioa.s.u-tokyo.ac.jp>

Hello, all:

Now I am looking for a new (primary) maintainer for ruby-gnome2 [1].
Previously ruby-gnome2 was maintained by my sponsornee, however 
the ownership was released on all branches two weeks ago and currently
no one owns this package.

I maintain some packages which depend on ruby-gnome2 (or its
subpackages) and one package heavily depends on ruby-gnome2, so I will
try to co-maintain ruby-gnome2. However as I already maintain many
packages I would appreciate it if someone else would take the prime
ownership on ruby-gnome2.

As this package is already orphaned, please visit pkgdb webpage
and take the ownership freely.

[1] https://admin.fedoraproject.org/pkgdb/packages/name/ruby-gnome2

Regards,
Mamoru



From dan at danny.cz  Fri Jan  9 15:39:42 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Fri, 09 Jan 2009 16:39:42 +0100
Subject: search for BuildRequires using repoquery
In-Reply-To: <1229594337.3612.68.camel@eagle.danny.cz>
References: <1229594337.3612.68.camel@eagle.danny.cz>
Message-ID: <1231515582.27804.7.camel@eagle.danny.cz>

Dan Hor?k p??e v ?t 18. 12. 2008 v 10:58 +0100:
> Hi,
> 
> the manpage for repoquery says that is is possible to search for
> BuildRequires using this command:
> 
> repoquery --archlist=src --whatrequires gail-devel
> 
> But it gives me a traceback. Is it still supposed to work? There was
> also a thread on yum-devel about searching BuildRequires -
> http://lists.baseurl.org/pipermail/yum-devel/2006-May/002187.html

So the proper syntax (to get the results and to avoid the crash) is

repoquery --repoid=rawhide-source --archlist=src --whatrequires
wxGTK-devel


		Dan



From vonbrand at inf.utfsm.cl  Fri Jan  9 15:48:59 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 09 Jan 2009 12:48:59 -0300
Subject: New Fedora virtualization list: fedora-virt
In-Reply-To: <20090109145050.GC9484@redhat.com>
References: <20090109145050.GC9484@redhat.com>
Message-ID: <200901091548.n09Fmx8a011699@laptop14.inf.utfsm.cl>

Daniel Veillard <veillard at redhat.com> wrote:

[...]

> The new list would be the correct place for anything related to
> virtualization in fedora, both user and development issues,
> and all hypervisors. The old list sounds the right place for
> people still using Fedora <= 8 with Xen,

I.e., officially nobody?
-- 
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 seg at haxxed.com  Fri Jan  9 16:00:22 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 09 Jan 2009 10:00:22 -0600
Subject: ssh private key password
In-Reply-To: <49671CA5.2080602@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<gk6f8s$cgs$1@ger.gmane.org>
	<200901090923.n099NVSd018356@tiffany.internal.tigress.co.uk>
	<49671CA5.2080602@redhat.com>
Message-ID: <1231516822.16049.10.camel@localhost.localdomain>

On Fri, 2009-01-09 at 09:45 +0000, Andrew Haley wrote:
> That's right.  The key argument against a pop-up dialog box that asks
> for the passphrase is that we're training people to type secrets into
> pop-up dialog boxes.  Bad psychology, bad security.

And how do you suggest GUI applications ask for passwords on a GUI
system?
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/552d254f/attachment.sig>

From seg at haxxed.com  Fri Jan  9 16:19:12 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 09 Jan 2009 10:19:12 -0600
Subject: ssh private key password
In-Reply-To: <20090109141623.GD17648@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
Message-ID: <1231517952.16049.29.camel@localhost.localdomain>

On Fri, 2009-01-09 at 09:16 -0500, John W. Linville wrote:
> On Thu, Jan 08, 2009 at 05:59:57PM -0500, Jesse Keating wrote:
> > On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > > 
> > > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > > command line app. Not sure of the point of it, it seems counter
> > > intuitive.
> > 
> > You're using a command line app from a graphical terminal.
> 
> I'm not sure I see your point.  Changing focus to another window just
> to type a passphrase seems at best to add zero benefit and at worst
> to provide surprise and distraction.  What is the benefit?

http://man.root.cz/1/gnome-ssh-askpass/

gnome-ssh-askpass will lock keyboard focus to its window, preventing
focus stealing and key logging attacks from other X clients. It also
aborts if it fails to gain a lock on the keyboard. Try starting two
copies of gnome-ssh-askpass at the same time, and see what happens:

$ /usr/libexec/openssh/gnome-ssh-askpass&/usr/libexec/openssh/gnome-ssh-askpass

Seems to me it's much preferable to use gnome-ssh-askpass if you're in
X, even in xterms.

(Getting real sick of these "I vote to change default functionality
because I find it aesthetically displeasing and clearly I know better
than the people who designed and implemented the functionality"
threads.)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/491168a7/attachment.sig>

From dcbw at redhat.com  Fri Jan  9 16:23:38 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 09 Jan 2009 11:23:38 -0500
Subject: F10/11 and Intel Integrated Graphics?
In-Reply-To: <1231465429.18388.4.camel@localhost.localdomain>
References: <loom.20090107T211629-323@post.gmane.org>
	<20090107214822.GA16228@mother.fordon.pl.eu.org>
	<loom.20090107T215239-554@post.gmane.org>
	<1231367225.5754.11.camel@localhost.localdomain>
	<1231431678.21643.26.camel@localhost.localdomain>
	<1231465429.18388.4.camel@localhost.localdomain>
Message-ID: <1231518218.30057.4.camel@dhcp-18-190-61-35.dyn.mit.edu>

On Thu, 2009-01-08 at 19:43 -0600, Callum Lerwick wrote:
> On Thu, 2009-01-08 at 11:21 -0500, Dan Williams wrote:
> > On Wed, 2009-01-07 at 16:27 -0600, Callum Lerwick wrote:
> > > While we're complaining, Intel 830M has been broken since F9:
> > > 
> > > https://bugzilla.redhat.com/show_bug.cgi?id=441665
> > 
> > As a workaround, try adding a minimal xorg.conf with:
> > 
> > Option "EXANoComposite" "true"
> > 
> > I just ran into this updating a Dell Latitude C400 (i830) to F10, and
> > I'm interesting in fixing it.
> 
> Works for me.

Ok, looks like there are quite a few issues, and this fixes one of them
for both of us on i830.  I'm gradually trying to track down the specific
change upstream that caused this issue, my C400 last had F-8 on it where
it was working fine.

Dan




From linville at redhat.com  Fri Jan  9 16:26:14 2009
From: linville at redhat.com (John W. Linville)
Date: Fri, 9 Jan 2009 11:26:14 -0500
Subject: ssh private key password
In-Reply-To: <1231517952.16049.29.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<1231517952.16049.29.camel@localhost.localdomain>
Message-ID: <20090109162613.GE17648@redhat.com>

On Fri, Jan 09, 2009 at 10:19:12AM -0600, Callum Lerwick wrote:
> On Fri, 2009-01-09 at 09:16 -0500, John W. Linville wrote:
> > On Thu, Jan 08, 2009 at 05:59:57PM -0500, Jesse Keating wrote:
> > > On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > > > 
> > > > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > > > command line app. Not sure of the point of it, it seems counter
> > > > intuitive.
> > > 
> > > You're using a command line app from a graphical terminal.
> > 
> > I'm not sure I see your point.  Changing focus to another window just
> > to type a passphrase seems at best to add zero benefit and at worst
> > to provide surprise and distraction.  What is the benefit?
> 
> http://man.root.cz/1/gnome-ssh-askpass/
> 
> gnome-ssh-askpass will lock keyboard focus to its window, preventing
> focus stealing and key logging attacks from other X clients. It also
> aborts if it fails to gain a lock on the keyboard. Try starting two
> copies of gnome-ssh-askpass at the same time, and see what happens:
> 
> $ /usr/libexec/openssh/gnome-ssh-askpass&/usr/libexec/openssh/gnome-ssh-askpass
> 
> Seems to me it's much preferable to use gnome-ssh-askpass if you're in
> X, even in xterms.

That could be -- the key logging point seems worthwhile.  Thanks for
the explanation.
 
> (Getting real sick of these "I vote to change default functionality
> because I find it aesthetically displeasing and clearly I know better
> than the people who designed and implemented the functionality"
> threads.)

I suspect some of us are a bit sick of the indignation we get from
others who don't think we should bother asking questions of them
because clearly they know best...just sayin'...

John
-- 
John W. Linville
linville at redhat.com



From nalin at redhat.com  Fri Jan  9 16:27:02 2009
From: nalin at redhat.com (Nalin Dahyabhai)
Date: Fri, 9 Jan 2009 11:27:02 -0500
Subject: ssh private key password
In-Reply-To: <1231517952.16049.29.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<1231517952.16049.29.camel@localhost.localdomain>
Message-ID: <20090109162702.GA7038@redhat.com>

On Fri, Jan 09, 2009 at 10:19:12AM -0600, Callum Lerwick wrote:
> http://man.root.cz/1/gnome-ssh-askpass/
> 
> gnome-ssh-askpass will lock keyboard focus to its window, preventing
> focus stealing and key logging attacks from other X clients. It also
> aborts if it fails to gain a lock on the keyboard. Try starting two
> copies of gnome-ssh-askpass at the same time, and see what happens:
> 
> $ /usr/libexec/openssh/gnome-ssh-askpass&/usr/libexec/openssh/gnome-ssh-askpass
> 
> Seems to me it's much preferable to use gnome-ssh-askpass if you're in
> X, even in xterms.

Note that the dialog in this case comes from gnome-keyring, and is not
actually gnome-ssh-askpass.  You can tell because gnome-ssh-askpass
doesn't offer to store things in your keyring, and it isn't used when
the process has access to a terminal device which it can use to prompt
the user.

Nalin



From jamundso at gmail.com  Fri Jan  9 16:29:13 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 10:29:13 -0600
Subject: ssh private key password
In-Reply-To: <1231516822.16049.10.camel@localhost.localdomain>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<gk6f8s$cgs$1@ger.gmane.org>
	<200901090923.n099NVSd018356@tiffany.internal.tigress.co.uk>
	<49671CA5.2080602@redhat.com>
	<1231516822.16049.10.camel@localhost.localdomain>
Message-ID: <6d06ce20901090829h6b93de0u1b4673ae51c59956@mail.gmail.com>

2009/1/9 Callum Lerwick <seg at haxxed.com>:
> On Fri, 2009-01-09 at 09:45 +0000, Andrew Haley wrote:
>> That's right.  The key argument against a pop-up dialog box that asks
>> for the passphrase is that we're training people to type secrets into
>> pop-up dialog boxes.  Bad psychology, bad security.
>
> And how do you suggest GUI applications ask for passwords on a GUI
> system?

We're talking about a command-line tool, *not* a GUI application. See OP.



From mclasen at redhat.com  Fri Jan  9 16:39:39 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 09 Jan 2009 11:39:39 -0500
Subject: ssh private key password
In-Reply-To: <20090109141247.GC17648@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc> <20090109141247.GC17648@redhat.com>
Message-ID: <1231519180.3563.0.camel@matthiasc>

On Fri, 2009-01-09 at 09:12 -0500, John W. Linville wrote:
> On Thu, Jan 08, 2009 at 07:43:15PM -0500, Matthias Clasen wrote:
> > On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> > > Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
> > > > On 2009-01-08 11:02:14 PM, nodata wrote:
> > > > > I'm wondering when this changed (F10)? I'm sure it didn't act like this
> > > > > in F9.
> > > > > 
> > > > > In F9, I would only be prompted to enter my passphrase if I sshed to a
> > > > > box that accepted pubkey authentication and a ssh-agent did not already
> > > > > have the key.
> > > > > In F10 it asks earlier: when ssh-add is run.
> > > > When you run ssh-add, you are *asking* for the passphrase to be stored
> > > > with ssh-agent, so of course, it has to ask for your passphrase.  This
> > > > is the very purpose of ssh-add.  Could you be confusing ssh-add with
> > > > something else?
> > > 
> > > No, I'm just getting annoyed that a GUI is popping up when I am using a
> > > command line app. Not sure of the point of it, it seems counter
> > > intuitive.
> > 
> > If you don't want this, you can turn it off with
> > gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false
> 
> Sorry for the troll, but I just had to admire this.  One has to love
> the easy discoverability of GNOME configuration methods... :-)

If you prefer, setting

SSH_AUTH_SOCK=

in your shell works just as well. How is that for discoverability ?



From jamundso at gmail.com  Fri Jan  9 16:47:35 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 10:47:35 -0600
Subject: ssh private key password
In-Reply-To: <1231519180.3563.0.camel@matthiasc>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<20090109141247.GC17648@redhat.com>
	<1231519180.3563.0.camel@matthiasc>
Message-ID: <6d06ce20901090847k46116546y7ad049a93560b241@mail.gmail.com>

On Fri, Jan 9, 2009 at 10:39 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Fri, 2009-01-09 at 09:12 -0500, John W. Linville wrote:
>> On Thu, Jan 08, 2009 at 07:43:15PM -0500, Matthias Clasen wrote:
>> > On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
>> > > Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
>> > > > On 2009-01-08 11:02:14 PM, nodata wrote:
>> > > > > I'm wondering when this changed (F10)? I'm sure it didn't act like this
>> > > > > in F9.
>> > > > >
>> > > > > In F9, I would only be prompted to enter my passphrase if I sshed to a
>> > > > > box that accepted pubkey authentication and a ssh-agent did not already
>> > > > > have the key.
>> > > > > In F10 it asks earlier: when ssh-add is run.
>> > > > When you run ssh-add, you are *asking* for the passphrase to be stored
>> > > > with ssh-agent, so of course, it has to ask for your passphrase.  This
>> > > > is the very purpose of ssh-add.  Could you be confusing ssh-add with
>> > > > something else?
>> > >
>> > > No, I'm just getting annoyed that a GUI is popping up when I am using a
>> > > command line app. Not sure of the point of it, it seems counter
>> > > intuitive.
>> >
>> > If you don't want this, you can turn it off with
>> > gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false
>>
>> Sorry for the troll, but I just had to admire this.  One has to love
>> the easy discoverability of GNOME configuration methods... :-)
>
> If you prefer, setting
>
> SSH_AUTH_SOCK=
>
> in your shell works just as well. How is that for discoverability ?

Now my system (new F10 from KDE Live) is *not* popping up the GUI window.
[jerry at jerry-opti755 ~]$ gconftool-2 -g
/apps/gnome-keyring/daemon-components/ssh
true
[jerry at jerry-opti755 ~]$ env | grep SSH
SSH_AGENT_PID=2320
SSH_AUTH_SOCK=/tmp/ssh-bfNSeF2292/agent.2292
SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass

Is this a bug? :-)

wishing I hadn't stated my thoughts in the first place,
jerry



From tmraz at redhat.com  Fri Jan  9 16:51:57 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 09 Jan 2009 17:51:57 +0100
Subject: ssh private key password
In-Reply-To: <6d06ce20901090847k46116546y7ad049a93560b241@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc> <20090109141247.GC17648@redhat.com>
	<1231519180.3563.0.camel@matthiasc>
	<6d06ce20901090847k46116546y7ad049a93560b241@mail.gmail.com>
Message-ID: <1231519917.3391.49.camel@vespa.frost.loc>

On Fri, 2009-01-09 at 10:47 -0600, Jerry Amundson wrote:
> On Fri, Jan 9, 2009 at 10:39 AM, Matthias Clasen <mclasen at redhat.com> wrote:
> > On Fri, 2009-01-09 at 09:12 -0500, John W. Linville wrote:
> >> On Thu, Jan 08, 2009 at 07:43:15PM -0500, Matthias Clasen wrote:
> >> > On Thu, 2009-01-08 at 23:42 +0100, nodata wrote:
> >> > > Am Donnerstag, den 08.01.2009, 17:21 -0500 schrieb Ricky Zhou:
> >> > > > On 2009-01-08 11:02:14 PM, nodata wrote:
> >> > > > > I'm wondering when this changed (F10)? I'm sure it didn't act like this
> >> > > > > in F9.
> >> > > > >
> >> > > > > In F9, I would only be prompted to enter my passphrase if I sshed to a
> >> > > > > box that accepted pubkey authentication and a ssh-agent did not already
> >> > > > > have the key.
> >> > > > > In F10 it asks earlier: when ssh-add is run.
> >> > > > When you run ssh-add, you are *asking* for the passphrase to be stored
> >> > > > with ssh-agent, so of course, it has to ask for your passphrase.  This
> >> > > > is the very purpose of ssh-add.  Could you be confusing ssh-add with
> >> > > > something else?
> >> > >
> >> > > No, I'm just getting annoyed that a GUI is popping up when I am using a
> >> > > command line app. Not sure of the point of it, it seems counter
> >> > > intuitive.
> >> >
> >> > If you don't want this, you can turn it off with
> >> > gconftool-2 -s -t bool /apps/gnome-keyting/daemon-components/ssh false
> >>
> >> Sorry for the troll, but I just had to admire this.  One has to love
> >> the easy discoverability of GNOME configuration methods... :-)
> >
> > If you prefer, setting
> >
> > SSH_AUTH_SOCK=
> >
> > in your shell works just as well. How is that for discoverability ?
> 
> Now my system (new F10 from KDE Live) is *not* popping up the GUI window.
> [jerry at jerry-opti755 ~]$ gconftool-2 -g
> /apps/gnome-keyring/daemon-components/ssh
> true
> [jerry at jerry-opti755 ~]$ env | grep SSH
> SSH_AGENT_PID=2320
> SSH_AUTH_SOCK=/tmp/ssh-bfNSeF2292/agent.2292
> SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
> 
> Is this a bug? :-)
No, this means you are running the regular openssh ssh-agent and not a
gnome-keyring as replacement for ssh-agent.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From seg at haxxed.com  Fri Jan  9 16:58:48 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 09 Jan 2009 10:58:48 -0600
Subject: ssh private key password
In-Reply-To: <20090109162702.GA7038@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<1231517952.16049.29.camel@localhost.localdomain>
	<20090109162702.GA7038@redhat.com>
Message-ID: <1231520329.16049.50.camel@localhost.localdomain>

On Fri, 2009-01-09 at 11:27 -0500, Nalin Dahyabhai wrote:
> On Fri, Jan 09, 2009 at 10:19:12AM -0600, Callum Lerwick wrote:
> > http://man.root.cz/1/gnome-ssh-askpass/
> > 
> > gnome-ssh-askpass will lock keyboard focus to its window, preventing
> > focus stealing and key logging attacks from other X clients. It also
> > aborts if it fails to gain a lock on the keyboard. Try starting two
> > copies of gnome-ssh-askpass at the same time, and see what happens:
> > 
> > $ /usr/libexec/openssh/gnome-ssh-askpass&/usr/libexec/openssh/gnome-ssh-askpass
> > 
> > Seems to me it's much preferable to use gnome-ssh-askpass if you're in
> > X, even in xterms.
> 
> Note that the dialog in this case comes from gnome-keyring, and is not
> actually gnome-ssh-askpass.  You can tell because gnome-ssh-askpass
> doesn't offer to store things in your keyring, and it isn't used when
> the process has access to a terminal device which it can use to prompt
> the user.

Any GUI password dialog really ought to be taking the same precautions.

... gnome-keyring's SSH agent doesn't seem to be working right on my
system. I've been using "keychain" but it should be disabled at the
moment.

Does it really implement its own ssh agent? That would be really
annoying as that would break interoperability with non-GUI logins. I ssh
in and use screen on this box as well. "keychain" was handling all cases
seamlessly, with this small fix:

ln -s /etc/profile.d/keychain.sh /etc/X11/xinit/xinitrc.d/keychain.sh

( https://bugzilla.redhat.com/show_bug.cgi?id=180776 )
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/0f081bed/attachment.sig>

From mdehaan at redhat.com  Fri Jan  9 19:43:42 2009
From: mdehaan at redhat.com (Michael DeHaan)
Date: Fri, 09 Jan 2009 14:43:42 -0500
Subject: New Fedora virtualization list: fedora-virt
In-Reply-To: <20090109145050.GC9484@redhat.com>
References: <20090109145050.GC9484@redhat.com>
Message-ID: <4967A8EE.5090702@redhat.com>

Daniel Veillard wrote:
>  Considering the size of virtualization in Fedora it makes sense
> to have a dedicated mailing-list, and at the moment the existing
> list Fedora-xen at redhat.com doesn't really fit the current state
> of Fedora virtualization, so I created a new list:
>    https://www.redhat.com/mailman/listinfo/fedora-virt
> maybe this will avoid getting posts about KVM problems or setup
> on a list with a Xen centric focus :-)
> The new list would be the correct place for anything related to
> virtualization in fedora, both user and development issues,
> and all hypervisors. The old list sounds the right place for
> people still using Fedora <= 8 with Xen,
>
> Daniel
>
>   

Woohoo, I was wondering where my KVM questions went. Excellent.

For those wondering, I think here are most of the Fedora mailing lists 
that are virt related:

libvir-list at redhat.com -- libvirt, libvirtd, and underlying libraries
ovirt-devel at redhat.com -- a management application and a minimal OS for 
managing virt
fedora-virt at redhat.com -- the new list
fedora-xen at redhat.com -- the old list
et-mgmt-tools at redhat.com -- virt-manager, virt-install, virsh, and 
related tools, also appliance build tools (thincrust) that target virt
cobbler at lists.fedorahosted.org -- for automated lab/datacenter/etc 
installs of physical and virtual machines
spacewalk-list at redhat.com -- has a virt installation and management 
component (xenpv only now)

Let me know if I've forgotten any.

I am going to have to start collecting virt mailing list trading cards 
now...

--Michael









From dbhole at redhat.com  Fri Jan  9 20:00:22 2009
From: dbhole at redhat.com (Deepak Bhole)
Date: Fri, 9 Jan 2009 15:00:22 -0500
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
Message-ID: <20090109200022.GA4271@redhat.com>

* Jerry James <loganjerry at gmail.com> [2009-01-06 16:46]:
> I'm having a build failure, on rawhide only, of a Java package that is
> built with maven.  When I run maven from the command line, if I give
> it more than one -DXXX option, it always complains that the second one
> is not a valid target.  I took a tip from a web site that mentions
> this problem and tried this (where the first 3 -DXXX options are from
> /usr/bin/mvn-jpp, and the 4th is the recommended way of using mvn-jpp
> in a spec file):
> 

Can you post the exact command that you are running (when it fails) and
what the resulting log is?

Deepak


> $ export MAVEN_OPTS="-Dmaven2.offline.mode -Dmaven2.ignore.versions
> -Dmaven2.usejppjars -Dmaven.repo.local=$MAVEN_REPO_LOCAL"
> $ mvn install
> 
> That worked.  Is this an expected change?  If so, both the
> /usr/bin/mvn-jpp script and the wiki description of how to use maven
> will have to be changed.  If not, does anyone have any idea why
> multiple -DXXX options aren't working for me?  Again, this is on
> Rawhide only.  Thanks,
> -- 
> Jerry James
> http://loganjerry.googlepages.com/
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From mike at cchtml.com  Fri Jan  9 20:07:54 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Fri, 09 Jan 2009 14:07:54 -0600
Subject: skype in F10-x86_64
In-Reply-To: <49672F27.1060302@niemueller.de>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
	<49672F27.1060302@niemueller.de>
Message-ID: <4967AE9A.8090200@cchtml.com>

-------- Original Message --------
Subject: Re: skype in F10-x86_64
From: Tim Niemueller <tim at niemueller.de>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 01/09/2009 05:04 AM

> 
> I had to change the input device to not use pulseaudio but the ALSA
> device directly. With PA it wouldn't work.
> 

Fixed in the latest alsa-plugins-pulseaudio package released yesterday.



From joshuacov at googlemail.com  Fri Jan  9 21:14:29 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Fri, 9 Jan 2009 22:14:29 +0100
Subject: AMD Video BIOS Disassembler and ATi RS485
Message-ID: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>

I (and maybe others) still have problems with kernel modesetting and
my ATi RS482 (RS485). Dave Airlie fixed it but then it broke again.
Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=472310.This is
the reason I still stick with f9. Maybe I can help if I manage to dump
the video bios of my card. According to this
http://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&num=1
it should be possible but rhd_conntest works only for R500 and R600.
Any Idea how to use this with my RS485?



From zaitcev at redhat.com  Fri Jan  9 21:20:31 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 9 Jan 2009 14:20:31 -0700
Subject: gnome keyring and Rawhide
Message-ID: <20090109142031.cdf44ecd.zaitcev@redhat.com>

Hi, All:

I run "yum update" every day and about two days ago something happened
in Rawhide that resulted in two things on my laptop:

#1: The long-deleted login.keyring was regenerated:

[zaitcev at niphredil ~]$ ls -la .gnome2/keyrings/
total 20
drwx------  2 zaitcev zaitcev 4096 2008-12-07 20:39 .
drwx------ 13 zaitcev zaitcev 4096 2009-01-05 08:33 ..
-rw-------  1 zaitcev zaitcev 2015 2008-12-07 20:39 login.keyring
[zaitcev at niphredil ~]$ 

#2: The "keyring" preferences disappeared. I swear to whatever $DEITY
that it used to exist, because I managed to add it explicitly before
by installing everything with "keyring" (except Brutus) and seahorse.
You know what I'm talking about? Well, it's gone now.

Here's the list of packages:

[zaitcev at niphredil ~]$ rpm -qa '*seahorse*' '*keyring*' | sort
gnome-keyring-2.25.2-3.fc11.i386
gnome-keyring-2.25.2-3.fc11.x86_64
gnome-keyring-devel-2.25.2-3.fc11.x86_64
gnome-keyring-pam-2.25.2-3.fc11.x86_64
gnome-python2-gnomekeyring-2.24.1-2.fc11.x86_64
pam_keyring-0.0.9-2.fc9.x86_64
seahorse-2.25.3-1.fc11.x86_64
[zaitcev at niphredil ~]$ 

What do I miss? Why did it disappear -- someone is playing with
Obsoletes: in a random package?

Greetings,
-- Pete



From zaitcev at redhat.com  Fri Jan  9 21:28:58 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 9 Jan 2009 14:28:58 -0700
Subject: ssh private key password
In-Reply-To: <6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<4966E9F4.4050200@fedoraproject.org>
	<6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>
	<20090109141139.GB17648@redhat.com>
	<6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
Message-ID: <20090109142858.1c1c50ef.zaitcev@redhat.com>

On Fri, 9 Jan 2009 08:22:50 -0600, "Jerry Amundson" <jamundso at gmail.com> wrote:

> >> In fact, I hope more and more command line tools add this GUI pop-up
> >> feature. It's awesome.
> >
> > I'm curious, why is this awesome?  It seems to me that if one has
> > chosen to type commands into a terminal emulator that changing focus
> > to a different window for further input violates the 'rule of least
> > surprise'?  Or is this some form of "GUI = good, CLI = bad" religion?
> 
> I agree with you.
> I was being sarcastic to the person who preferred the current behavior.

Having a session-wide store for keys is awesome, which is why the
old ssh-agent existed in the first place! Logically if you log
through gdm, GNOME desktop is your session, and it ought to keep
your keys now. The old ssh-agent remains in the play only if you
continue using getty-initiated sessions and startx, in which case
the GNOME should defer to pre-existing session. If it doesn't then
file bugs.

As for the religion, I edit everything with gvim, because I want
something that a) support normal clipboard instead of middle-buttoning,
and b) would not destroy my files like gedit. It's launched from
the command line, of course. I guess it makes me spiritually
promiscuous.

-- Pete



From aa.lucelio at gmail.com  Fri Jan  9 22:19:59 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Fri, 9 Jan 2009 20:19:59 -0200
Subject: skype in F10-x86_64
In-Reply-To: <4967AE9A.8090200@cchtml.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
	<49672F27.1060302@niemueller.de> <4967AE9A.8090200@cchtml.com>
Message-ID: <f4a59ea0901091419j3a5c4564gc0dab3cf7c4e35f1@mail.gmail.com>

*Michael Cronenworth*,

OK.   I have updated.    You was right, and it is working now, I knew, I was
feeling that something related to skype in this package(ALSA) was not
working well, thank you very much.   Now I have to get the video part
working.   I hope I get it.

Wen sie(*Tim Niemueller*) keine h?tslage habe?    Geben sie mir.   Danke.
Very sorry (*Jonathan Underwood*) for the wrong place to ask about a bug in
alsa-plugins-pulseaudio package released yesterday.

Thanks,
Luc?lio.       (Pv 14:12)

2009/1/9 Michael Cronenworth <mike at cchtml.com>

> -------- Original Message --------
> Subject: Re: skype in F10-x86_64
> From: Tim Niemueller <tim at niemueller.de>
> To: Development discussions related to Fedora <
> fedora-devel-list at redhat.com>
> Date: 01/09/2009 05:04 AM
>
>
>> I had to change the input device to not use pulseaudio but the ALSA
>> device directly. With PA it wouldn't work.
>>
>>
> Fixed in the latest alsa-plugins-pulseaudio package released yesterday.
>
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090109/d04b8e4f/attachment.htm>

From airlied at redhat.com  Sat Jan 10 00:35:23 2009
From: airlied at redhat.com (Dave Airlie)
Date: Sat, 10 Jan 2009 10:35:23 +1000
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
Message-ID: <1231547723.4259.34.camel@optimus>

On Fri, 2009-01-09 at 22:14 +0100, Joshua C. wrote:
> I (and maybe others) still have problems with kernel modesetting and
> my ATi RS482 (RS485). Dave Airlie fixed it but then it broke again.
> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=472310.This is
> the reason I still stick with f9. Maybe I can help if I manage to dump
> the video bios of my card. According to this
> http://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&num=1
> it should be possible but rhd_conntest works only for R500 and R600.
> Any Idea how to use this with my RS485?

Its not useful at all for older chipsets, we have all the functionality
in open source radeontool for ages, not sure why the release is a big
deal.

I'm not working at the moment, but I was going to suggest rs485 people
try booting with radeon.gartsize=32 to see if it helps.

Dave..

> 



From kevin.kofler at chello.at  Sat Jan 10 00:56:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Jan 2009 01:56:17 +0100
Subject: ssh private key password
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<1231517952.16049.29.camel@localhost.localdomain>
Message-ID: <gk8rnh$k5h$1@ger.gmane.org>

Callum Lerwick wrote:
> gnome-ssh-askpass will lock keyboard focus to its window, preventing
> focus stealing and key logging attacks from other X clients. It also
> aborts if it fails to gain a lock on the keyboard. Try starting two
> copies of gnome-ssh-askpass at the same time, and see what happens:

Interesting... ksshaskpass doesn't do anything like that. Not that I think
focus stealing is really a good solution for this problem anyway.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 10 01:10:00 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Jan 2009 02:10:00 +0100
Subject: AMD Video BIOS Disassembler and ATi RS485
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
Message-ID: <gk8sh8$nq6$1@ger.gmane.org>

Joshua C. wrote:
> I (and maybe others) still have problems with kernel modesetting and
> my ATi RS482 (RS485). Dave Airlie fixed it but then it broke again.
> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=472310.This is
> the reason I still stick with f9.

Are you aware of the fact that kernel modesetting can be disabled? (Use
the "nomodeset" kernel parameter.) You don't have to go as far as using an
old Fedora release to avoid it.

        Kevin Kofler



From gmaxwell at gmail.com  Sat Jan 10 01:27:47 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Fri, 9 Jan 2009 20:27:47 -0500
Subject: ssh private key password
In-Reply-To: <20090109141623.GD17648@redhat.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
Message-ID: <e692861c0901091727p562c3b6cq3fa1226041d56f21@mail.gmail.com>

On Fri, Jan 9, 2009 at 9:16 AM, John W. Linville <linville at redhat.com> wrote:
> I'm not sure I see your point.  Changing focus to another window just
> to type a passphrase seems at best to add zero benefit and at worst
> to provide surprise and distraction.  What is the benefit?
[snip]

Presumably the GUI password dialog can XGrabKeyboard to prevent
keyboard sniffing. Your terminal can probably do it to, but you
probably have to tell it to and you probably do not.

A central unspoofable password dialog does make sense for improving
security, Fedora isn't there yet? but CLI apps kicking you to some
external dialog for passwords is a necessary step to that end.



From jamundso at gmail.com  Sat Jan 10 03:33:24 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 21:33:24 -0600
Subject: ssh private key password
In-Reply-To: <e692861c0901091727p562c3b6cq3fa1226041d56f21@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<e692861c0901091727p562c3b6cq3fa1226041d56f21@mail.gmail.com>
Message-ID: <6d06ce20901091933i210a85e8s416e9969cc9077f5@mail.gmail.com>

On 1/9/09, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> A central unspoofable password dialog does make sense for improving
> security, Fedora isn't there yet? but CLI apps kicking you to some
> external dialog for passwords is a necessary step to that end.

And that's been proven by whom?

jerry



From jamundso at gmail.com  Sat Jan 10 04:02:41 2009
From: jamundso at gmail.com (Jerry Amundson)
Date: Fri, 9 Jan 2009 22:02:41 -0600
Subject: ssh private key password
In-Reply-To: <gk8rnh$k5h$1@ger.gmane.org>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<1231517952.16049.29.camel@localhost.localdomain>
	<gk8rnh$k5h$1@ger.gmane.org>
Message-ID: <6d06ce20901092002y37dda579kdf697283eccbe537@mail.gmail.com>

On Fri, Jan 9, 2009 at 6:56 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Callum Lerwick wrote:
>> gnome-ssh-askpass will lock keyboard focus to its window, preventing
>> focus stealing and key logging attacks from other X clients. It also
>> aborts if it fails to gain a lock on the keyboard. Try starting two
>> copies of gnome-ssh-askpass at the same time, and see what happens:
>
> Interesting... ksshaskpass doesn't do anything like that. Not that I think
> focus stealing is really a good solution for this problem anyway.
>
>        Kevin Kofler

You're against focus stealing, but for the GUI prompt "feature"?

On Thu, Jan 8, 2009 at 9:11 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Uh, a GUI prompt for the passphrase is a feature. It also gets used when you
> use SSH from a GUI app, such as a client for a version control system. I
> don't see how this is a problem.
>
>        Kevin Kofler

/me confused.

done with this now,
jerry



From rawhide at fedoraproject.org  Sat Jan 10 08:50:43 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 10 Jan 2009 08:50:43 +0000 (UTC)
Subject: rawhide report: 20090110 changes
Message-ID: <20090110085044.1F9D31F8260@releng2.fedora.phx.redhat.com>

Compose started at Sat Jan 10 06:01:03 UTC 2009

New package PolicyKit-kde
        PolicyKit integration for the KDE desktop
New package clamtk
        Easy to use front-end for ClamAV
New package cwirc
        X-Chat Morse plugin
New package gdata-java
        Client libraries to write Google Data API client applications in Java
New package hyphen-id
        Indonesian hyphenation rules
New package hyphen-is
        Icelandic hyphenation rules
New package jakarta-commons-compress
        Java API for working with tar, zip and bzip2 files
New package javassist
        The Java Programming Assistant provides simple Java bytecode manipulation
New package jcalendar
        A Java date chooser bean for graphically picking a date
New package libwpg
        Library for reading WordPerfect Graphics images
New package nufw
        Authentication Firewall Suite for Linux
New package perl-MooseX-Traits-Attribute-CascadeClear
        Attribute trait to cascade clearer actions
New package perl-SVG-Parser
        XML Parser for SVG documents
New package pfscalibration
        Scripts and programs for photometric calibration
New package pfstmo
        PFS tone mapping operators
Updated Packages:

GConf2-2.25.0-1.fc11
--------------------
* Sat Jan 10 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.0-1
- Update to 2.25.0


amarok-2.0.1.1-1.fc11
---------------------
* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 2.0.1.1-1
- amarok-2.0.1.1


antlr-2.7.7-3.fc11
------------------
* Fri Jan  9 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> 2.7.7-3
- exlcude using mono on sparc64


aterm-1.0.1-4.fc11
------------------
* Fri Jan  9 17:00:00 2009 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de> - 1.0.1-4
- fix #454936


bluez-4.26-1.fc11
-----------------
* Fri Jan  9 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 4.26-1
- Update to 4.26


cobbler-1.4.1-1.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Michael DeHaan <mdehaan at redhat.com> - 1.4.1-1
- Upstream changes (see CHANGELOG)


ddd-3.3.12-1.rc1.fc11
---------------------
* Thu Jan  8 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 3.3.12-1.rc1
- New upstream.
- Updated htmlview patch.
- Dropped xprint patch, applied upstream.


deluge-1.1.0-0.4.rc3.fc11
-------------------------
* Fri Jan  9 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 1.1.0-0.4.rc3
- Do not package the country flags data.
- Resolves: #479265 (country flags should not be used in Deluge)


eigen2-2.0-0.8.20090109svn.fc11
-------------------------------
* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.8.20090109svn
- eigen2-20090109svn snapshot


farsight2-0.0.7-1.fc11
----------------------
* Fri Jan  9 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.0.7-1
- Update to 0.0.7.


freedink-1.08.20090109-2.fc11
-----------------------------
* Fri Jan  9 17:00:00 2009 Sylvain Beucler <beuc at beuc.net> - 1.08.20090109-2
- Bump version to fix build tag issue

* Fri Jan  9 17:00:00 2009 Sylvain Beucler <beuc at beuc.net> - 1.08.20090109-1
- New upstream release
- Declare .mo translation catalogs


gnubg-0.9.0.1-5.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 1:0.9.0.1-5
- Switch to dejavu fonts.


gvfs-1.1.3-2.fc11
-----------------
* Fri Jan  9 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 1.1.3-2
- Support moving files in the burn backend


kde-l10n-4.1.96-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdeaccessibility-4.1.96-2.fc11
------------------------------
* Fri Jan  9 17:00:00 2009 Lorenzo Villani <lvillani at binaryhelix.net> - 1:4.1.96-2
- rebuilt
- fix file list

* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdeadmin-4.1.96-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdebase-4.1.96-1.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdebase-workspace-4.1.96-2.fc11
-------------------------------
* Fri Jan  9 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-2
- remove Provides: plasma-devel

* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdebindings-4.1.96-1.fc11
-------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdegraphics-4.1.96-1.fc11
-------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdelibs-4.1.96-4.fc11
---------------------
* Fri Jan  9 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-3
- BR soprano >= 2.1.64

* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.1.96-4
- bump min deps (cmake, kde-filesystem, phonon)
- kde.(sh|csh): cleanup QT_PLUGIN_PATH handling
- Requires: coreutils grep


kdemultimedia-4.1.96-1.fc11
---------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdenetwork-4.1.96-1.fc11
------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdepim-4.1.96-1.fc11
--------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdetoys-4.1.96-1.fc11
---------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdeutils-4.1.96-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.24.rc0.git13.fc11
---------------------------------
* Thu Jan  8 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- Fixup build failures due to warn/info macro removal.
- Revert patch which caused modules to bloat to 1GB of
  (mostly) zeroes.

* Thu Jan  8 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- 2.6.28-git12
- Revert ihex2fb moving patch, causes noarch target to
  epicly fail.

* Thu Jan  8 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.28-git11


koan-1.4.1-1.fc11
-----------------
* Fri Jan  9 17:00:00 2009 Michael DeHaan <mdehaan at redhat.com> - 1.4.1-1
- Upstream changes (see CHANGELOG)


koffice-1.9.98.5-1.fc11
-----------------------
* Thu Jan  8 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.5-1
- koffice-1.9.98.5, koffice2 beta 5 (take 2)


koffice-langpack-1.9.98.5-1.fc11
--------------------------------
* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 1.9.98.5
- koffice-l10n-1.9.98.5


libksba-1.0.5-1.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 1.0.5-1
- libksba-1.0.5


libmsn-4.0-0.6.beta2.fc11
-------------------------
* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.0-0.6.beta2
- pkgconfig patch to workaround bug #479493

* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.0-0.5.beta2
- -devel: Requires: openssl-devel

* Fri Jan  9 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.0-0.4.beta2
- libmsn-4.0-beta2


libpng-1.2.34-1.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Tom Lane <tgl at redhat.com> 2:1.2.34-1
- Update to libpng 1.2.34


libprojectM-1.2.0-7.fc11
------------------------
* Thu Jan  1 17:00:00 2009 Jameson Pugh (imntreal at gmail.com) - 1.2.0-7
- Per recommendation, switched font packages from bitstream to dejavu


libwvstreams-4.5.1-2.fc11
-------------------------
* Fri Jan  9 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 4.5.1-2
- do not remove libwvdbus.pc (#479144)


moomps-5.8-5.fc11
-----------------
* Fri Jan  9 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 5.8-5
- make /usr/share/moomps the homedir instead of /srv


ncmpc-0.13-1.fc11
-----------------
* Fri Jan  9 17:00:00 2009 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.13-1
- version upgrade (#479240)

* Sat Nov 22 17:00:00 2008 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 0.12-0.1.beta1
- version upgrade


nspluginwrapper-1.3.0-2.fc11
----------------------------
* Fri Jan  9 17:00:00 2009 Martin Stransky <stransky at redhat.com> 1.3.0-2
- Fixed multilib conflicts


oggvideotools-0.6-1.fc11
------------------------
* Fri Jan  9 17:00:00 2009 Matt Domsch <mdomsch at fedoraproject.org> - 0.6-1
- update to 0.6
  added oggSlideshow, oggThumb
  handling for huge files > 4GB implemented
  packet order with oggCut has been fixed and cleaned up
  ogg type in BOS packet is completely analysed
  added support for kate-streams (done by ogg.k.ogg.k)


pyexiv2-0.1.2-8.1.20090109bzr107.fc11
-------------------------------------
* Fri Jan  9 17:00:00 2009 Matej Cepl <mcepl at redhat.com> 0.1.2-8.1.20090109bzr107
- New snapshot from upstream pyexiv2-0.2 branch in order to be compatible
  with the current package of exiv2.

* Thu Dec 18 17:00:00 2008 Rex Dieter <rdieter at fedoraproject.org> - 0.1.2-6
- respin (eviv2)


python-gtkextra-1.1.0-6
-----------------------
* Fri Jan  9 17:00:00 2009 Miloslav Trma?? <mitr at redhat.com> - 1.1.0-6
- More general fix for the codegen move


rpmrebuild-2.3-1.fc11
---------------------
* Fri Jan  9 17:00:00 2009 Anderson Silva <ansilva at redhat.com> 2.3-1
- Introduces some fixes for compatibility with rpm 4.6.0


soprano-2.1.64-1.fc11
---------------------
* Fri Jan  9 17:00:00 2009 Than Ngo <than at redhat.com> - 2.1.64-1
- update to 2.1.64


strigi-0.6.2-1.fc11
-------------------
* Tue Jan  6 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.6.2-1
- strigi-0.6.2
- use %cmake macro


texi2html-1.82-1.fc11
---------------------
* Fri Jan  9 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 1.82-1
- update to 1.82


trytond-1.0.2-1.fc11
--------------------
* Thu Jan  8 17:00:00 2009 Dan Hor??k <dan[at]danny.cz> 1.0.2-1
- modularize the openoffice.org support
- update to upstream version 1.0.2


unuran-1.3.1-1.fc11
-------------------
* Fri Jan  9 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 1.3.1-1
- Update to 1.3.1 final


Summary:
Added Packages: 15
Removed Packages: 0
Modified Packages: 47
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.i386 requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.x86_64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc requires python(abi) = 0:2.5
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	libopensync-0.36-3.fc10.ppc64 requires python(abi) = 0:2.5
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From rmy at tigress.co.uk  Sat Jan 10 09:33:40 2009
From: rmy at tigress.co.uk (Ron Yorston)
Date: Sat, 10 Jan 2009 09:33:40 +0000
Subject: ssh private key password
In-Reply-To: <20090109142858.1c1c50ef.zaitcev@redhat.com>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231461795.3174.2.camel@matthiasc>
	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>
	<4966E9F4.4050200@fedoraproject.org>
	<6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>
	<20090109141139.GB17648@redhat.com>
	<6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
	<20090109142858.1c1c50ef.zaitcev@redhat.com>
Message-ID: <200901100933.n0A9XgNJ019107@tiffany.internal.tigress.co.uk>

Pete Zaitcev <zaitcev at redhat.com> wrote:
>Having a session-wide store for keys is awesome, which is why the
>old ssh-agent existed in the first place!

Then it's awesomeness I can do without.  I want to keep control of my
ssh credentials and *always* be prompted when something wants to use
them.

My opinion:  gnome-keyring should not act as an ssh agent by default.

Ron



From joshuacov at googlemail.com  Sat Jan 10 09:55:18 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 10 Jan 2009 10:55:18 +0100
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <gk8sh8$nq6$1@ger.gmane.org>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<gk8sh8$nq6$1@ger.gmane.org>
Message-ID: <5f6f8c5f0901100155u43ddc2bby87dadeeb0694ead8@mail.gmail.com>

2009/1/10 Kevin Kofler <kevin.kofler at chello.at>:
> Joshua C. wrote:
>> I (and maybe others) still have problems with kernel modesetting and
>> my ATi RS482 (RS485). Dave Airlie fixed it but then it broke again.
>> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=472310.This is
>> the reason I still stick with f9.
>
> Are you aware of the fact that kernel modesetting can be disabled? (Use
> the "nomodeset" kernel parameter.) You don't have to go as far as using an
> old Fedora release to avoid it.
>
>        Kevin Kofler
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I know about it. Actually it is the only way to boot the f10. What is
really strange is that I have 2 boards (from the same vendor) and on
paper they are fully identical. Modeset works with one of them but not
with the other. I saw that the non working board is a newer revision
but this didn't help me much. Therefore I thought that if I manage to
dump the video bios of the board I can shed some light on the problem.
I saw people that don't experience this problem with this card but
there is still something worng with my RS485. I'll try booting with
radeon.gartsize=32 and see what happens.



From joshuacov at googlemail.com  Sat Jan 10 10:04:35 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 10 Jan 2009 05:04:35 -0500
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <1231547723.4259.34.camel@optimus>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<1231547723.4259.34.camel@optimus>
Message-ID: <5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>

2009/1/9 Dave Airlie <airlied at redhat.com>:
> On Fri, 2009-01-09 at 22:14 +0100, Joshua C. wrote:
>> I (and maybe others) still have problems with kernel modesetting and
>> my ATi RS482 (RS485). Dave Airlie fixed it but then it broke again.
>> Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=472310.This is
>> the reason I still stick with f9. Maybe I can help if I manage to dump
>> the video bios of my card. According to this
>> http://www.phoronix.com/scan.php?page=article&item=amd_atombios_dumper&num=1
>> it should be possible but rhd_conntest works only for R500 and R600.
>> Any Idea how to use this with my RS485?
>
> Its not useful at all for older chipsets, we have all the functionality
> in open source radeontool for ages, not sure why the release is a big
> deal.
>
> I'm not working at the moment, but I was going to suggest rs485 people
> try booting with radeon.gartsize=32 to see if it helps.
>
> Dave..

With 2.6.27.10-167.fc10.x86_64 I got `Unknown boot option
`radeon.gartsize=32': ignoring`. Did I miss something?



From joshuacov at googlemail.com  Sat Jan 10 10:25:16 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 10 Jan 2009 05:25:16 -0500
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<1231547723.4259.34.camel@optimus>
	<5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>
Message-ID: <5f6f8c5f0901100225p771e5851ta34bc7b7f0b00db@mail.gmail.com>

2009/1/10 Joshua C. <joshuacov at googlemail.com>:
> 2009/1/9 Dave Airlie <airlied at redhat.com>:
>> On Fri, 2009-01-09 at 22:14 +0100, Joshua C. wrote:
>>> Any Idea how to use this with my RS485?
>> I'm not working at the moment, but I was going to suggest rs485 people
>> try booting with radeon.gartsize=32 to see if it helps.
>>
>> Dave..
>
> With 2.6.27.10-167.fc10.x86_64 I got `Unknown boot option
> `radeon.gartsize=32': ignoring`. Did I miss something?
>

OK I tried it. I still got the message "Unknow boot option", but it
works fine. Without radeon.gartsize=32 everything is fine until the
xserver starts. Modesetting works fine but when the Xserver start I
get two-color-strips on my monitor. This doesn't happen when I set
radeon.gartsize=32 and the Xserver starts right.
This is a laptop and the video card can use from 32 up to 256 mb from
the main memory.I've set it to 128mb. Maybe this can also help.

@Dave
Thanx for the tip. It works once again. Does this gart table has
something to do with the memory used by card? As I said, my other
mashine with the same  radeon RS485 works fine without this option.
The only difference is that I have 4GB memory (an a memory hole) with
the non working card and 2GB with the working one.



From ich at frank-schmitt.net  Fri Jan  9 08:32:26 2009
From: ich at frank-schmitt.net (Frank Schmitt)
Date: Fri, 09 Jan 2009 09:32:26 +0100
Subject: Automatic update ran despite being disabled (which is bad)
References: <78c6bd860901071916j686ac317o1828a04da89efcab@mail.gmail.com>
	<gk6dvb$94u$2@ger.gmane.org>
Message-ID: <m38wpkanhh.fsf@mid.gehheimdienst.de>

Kevin Kofler <kevin.kofler at chello.at> writes:

> Michael B Allen wrote:
>> About 15 minutes ago a dialog popped up that claimed "Your system has
>> been updated" (or something to that effect). The problem is, I didn't
>> initiate an update and my system is not configured to automatically
>> update.
>> 
>> Can anyone explain how this could happen?
>
> Are you using KPackageKit?
> https://bugzilla.redhat.com/show_bug.cgi?id=475303
>
> Yes, I hate that bug too. But I looked at the code and didn't find the
> slightest clue as to how it may happen, nor did the KPackageKit upstream
> author.

Isn't this a sure sign that the underlying mechanism is to complicated?

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.



From airlied at redhat.com  Sat Jan 10 12:53:21 2009
From: airlied at redhat.com (Dave Airlie)
Date: Sat, 10 Jan 2009 22:53:21 +1000
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <5f6f8c5f0901100225p771e5851ta34bc7b7f0b00db@mail.gmail.com>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<1231547723.4259.34.camel@optimus>
	<5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>
	<5f6f8c5f0901100225p771e5851ta34bc7b7f0b00db@mail.gmail.com>
Message-ID: <1231592001.6763.0.camel@localhost>

On Sat, 2009-01-10 at 05:25 -0500, Joshua C. wrote:
> 2009/1/10 Joshua C. <joshuacov at googlemail.com>:
> > 2009/1/9 Dave Airlie <airlied at redhat.com>:
> >> On Fri, 2009-01-09 at 22:14 +0100, Joshua C. wrote:
> >>> Any Idea how to use this with my RS485?
> >> I'm not working at the moment, but I was going to suggest rs485 people
> >> try booting with radeon.gartsize=32 to see if it helps.
> >>
> >> Dave..
> >
> > With 2.6.27.10-167.fc10.x86_64 I got `Unknown boot option
> > `radeon.gartsize=32': ignoring`. Did I miss something?
> >
> 
> OK I tried it. I still got the message "Unknow boot option", but it
> works fine. Without radeon.gartsize=32 everything is fine until the
> xserver starts. Modesetting works fine but when the Xserver start I
> get two-color-strips on my monitor. This doesn't happen when I set
> radeon.gartsize=32 and the Xserver starts right.
> This is a laptop and the video card can use from 32 up to 256 mb from
> the main memory.I've set it to 128mb. Maybe this can also help.
> 
> @Dave
> Thanx for the tip. It works once again. Does this gart table has
> something to do with the memory used by card? As I said, my other
> mashine with the same  radeon RS485 works fine without this option.
> The only difference is that I have 4GB memory (an a memory hole) with
> the non working card and 2GB with the working one.

It controls what parts of main RAM the card uses, however the hint about
having 4GB vs 2GB is probably useful, can you update the bug with that
info, and I'll try and think about it a bit more when I get back to the
office.

Dave.

> 



From sundaram at fedoraproject.org  Sat Jan 10 13:14:06 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 10 Jan 2009 18:44:06 +0530
Subject: ssh private key password
In-Reply-To: <6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>	<1231452134.2181.9.camel@localhost.localdomain>	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>	<1231454546.2181.10.camel@localhost.localdomain>	<1231461795.3174.2.camel@matthiasc>	<6d06ce20901081835h73b9cd40h2d79a9e6ca93de94@mail.gmail.com>	<4966E9F4.4050200@fedoraproject.org>	<6d06ce20901082228v6c983fefgcf0de6ca837dc724@mail.gmail.com>	<20090109141139.GB17648@redhat.com>
	<6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
Message-ID: <49689F1E.6030405@fedoraproject.org>

Jerry Amundson wrote:
> On 1/9/09, John W. Linville <linville at redhat.com> wrote:
>> On Fri, Jan 09, 2009 at 12:28:43AM -0600, Jerry Amundson wrote:
>>> In fact, I hope more and more command line tools add this GUI pop-up
>>> feature. It's awesome.
>> I'm curious, why is this awesome?  It seems to me that if one has
>> chosen to type commands into a terminal emulator that changing focus
>> to a different window for further input violates the 'rule of least
>> surprise'?  Or is this some form of "GUI = good, CLI = bad" religion?
> 
> I agree with you.
> I was being sarcastic to the person who preferred the current behavior.

You seem to be sarcastic way too often in this list. It is not so 
difficult to accept that there are others with different criteria to yours.

Rahul



From joshuacov at googlemail.com  Sat Jan 10 15:56:47 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 10 Jan 2009 16:56:47 +0100
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <1231592001.6763.0.camel@localhost>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<1231547723.4259.34.camel@optimus>
	<5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>
	<5f6f8c5f0901100225p771e5851ta34bc7b7f0b00db@mail.gmail.com>
	<1231592001.6763.0.camel@localhost>
Message-ID: <5f6f8c5f0901100756l374756a7l94bb0f5b7d2f92f5@mail.gmail.com>

2009/1/10 Dave Airlie <airlied at redhat.com>:
> On Sat, 2009-01-10 at 05:25 -0500, Joshua C. wrote:
>> 2009/1/10 Joshua C. <joshuacov at googlemail.com>:
>> > 2009/1/9 Dave Airlie <airlied at redhat.com>:
>> >> On Fri, 2009-01-09 at 22:14 +0100, Joshua C. wrote:
>> >>> Any Idea how to use this with my RS485?
>> >> I'm not working at the moment, but I was going to suggest rs485 people
>> >> try booting with radeon.gartsize=32 to see if it helps.
>> >>
>> >> Dave..
>> >
>> > With 2.6.27.10-167.fc10.x86_64 I got `Unknown boot option
>> > `radeon.gartsize=32': ignoring`. Did I miss something?
>> >
>>
>> OK I tried it. I still got the message "Unknow boot option", but it
>> works fine. Without radeon.gartsize=32 everything is fine until the
>> xserver starts. Modesetting works fine but when the Xserver start I
>> get two-color-strips on my monitor. This doesn't happen when I set
>> radeon.gartsize=32 and the Xserver starts right.
>> This is a laptop and the video card can use from 32 up to 256 mb from
>> the main memory.I've set it to 128mb. Maybe this can also help.
>>
>> @Dave
>> Thanx for the tip. It works once again. Does this gart table has
>> something to do with the memory used by card? As I said, my other
>> mashine with the same  radeon RS485 works fine without this option.
>> The only difference is that I have 4GB memory (an a memory hole) with
>> the non working card and 2GB with the working one.
>
> It controls what parts of main RAM the card uses, however the hint about
> having 4GB vs 2GB is probably useful, can you update the bug with that
> info, and I'll try and think about it a bit more when I get back to the
> office.
>
> Dave.
>
I've done it. Thank you for the help.
>>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From jonstanley at gmail.com  Sat Jan 10 17:29:03 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Sat, 10 Jan 2009 12:29:03 -0500
Subject: Summary of 20090110 FESCo meeting at FUDCon
Message-ID: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>

=== Members Present ===

Jon Stanley
Dennis Gilmore
Jarod Wilson
Bill Nottingham
Josh Boyer
Kevin Fenzi

== Summary ==
=== provenpacakger ===

* All members present approved a proposal to reseed provenpackager
with current sponsors, who will be granted administrator status.
* Sponsorship guidelines for packager will be revised. (Kevin Fenzi)
* Guidelines will be drafted (discretionary) for what type of
qualifications to apply to provenpackager. (Jesse Keating)
* Announcement to fedora-devel-announce (Jon Stanley)

=== Squeak ===

* gdk mentioned the need to get squeak into Fedora, which is a binary
that builds it's own source. FESCo is OK with the concept of this, the
implementation will need to be reviewed.



From kevin.kofler at chello.at  Sat Jan 10 17:57:38 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Jan 2009 18:57:38 +0100
Subject: Summary of 20090110 FESCo meeting at FUDCon
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
Message-ID: <gkanii$665$1@ger.gmane.org>

Jon Stanley wrote:
> * gdk mentioned the need to get squeak into Fedora, which is a binary
> that builds it's own source. FESCo is OK with the concept of this, the
> implementation will need to be reviewed.

Isn't squeak still non-Free and involved in a lengthy process of tracking
down all contributors for a relicensing?

        Kevin Kofler



From jwboyer at gmail.com  Sat Jan 10 18:04:15 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 10 Jan 2009 13:04:15 -0500
Subject: Summary of 20090110 FESCo meeting at FUDCon
In-Reply-To: <gkanii$665$1@ger.gmane.org>
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
	<gkanii$665$1@ger.gmane.org>
Message-ID: <20090110180415.GC18018@zod.rchland.ibm.com>

On Sat, Jan 10, 2009 at 06:57:38PM +0100, Kevin Kofler wrote:
>Jon Stanley wrote:
>> * gdk mentioned the need to get squeak into Fedora, which is a binary
>> that builds it's own source. FESCo is OK with the concept of this, the
>> implementation will need to be reviewed.
>
>Isn't squeak still non-Free and involved in a lengthy process of tracking
>down all contributors for a relicensing?

Spot decreed that the legal issues were cleared.

josh



From kevin.kofler at chello.at  Sat Jan 10 18:16:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 10 Jan 2009 19:16:52 +0100
Subject: Summary of 20090110 FESCo meeting at FUDCon
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
	<gkanii$665$1@ger.gmane.org>
	<20090110180415.GC18018@zod.rchland.ibm.com>
Message-ID: <gkaomk$665$6@ger.gmane.org>

Josh Boyer wrote:
> Spot decreed that the legal issues were cleared.

Based on what?

http://www.squeak.org/SqueakLicense/ still describes the license change
as "upcoming".

        Kevin Kofler



From loganjerry at gmail.com  Sat Jan 10 18:30:32 2009
From: loganjerry at gmail.com (Jerry James)
Date: Sat, 10 Jan 2009 11:30:32 -0700
Subject: PPC64 virtual machine
Message-ID: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>

I've gotten GCL to build successfully in Rawhide on i386 and x86_64
platforms.  However, it segfaulted on PPC64.

http://koji.fedoraproject.org/koji/taskinfo?taskID=1043890

Before I ExcludeArch the ppc platforms, I would like to try to
diagnose the problem.  My first thought was to create a virtual PPC64
machine.  So I downloaded the latest Rawhide boot.iso and fired up
virt-manager.  After configuring the machine, attempting to boot
produces this output on the console:

  PPC Open Hack'Ware BIOS for qemu version 0.4.1
  Build 2007-10-01 06:42:47
  Copyright 2003-2005 Jocelyn Mayer

  Memory size: 1024 MB.
  Booting from device d
  PPC Open Hack'Ware BIOS for qemu version 0.4.1
  Build 2007-10-01 06:42:47
  Copyright 2003-2005 Jocelyn Mayer

  ide0: drive 0: Hard Disk
  ERROR: OF_property_copy cannot get property 'hd' for aliases
  ide0: drive 1: CD-ROM
  ERROR: OF_property_copy cannot get property 'cd' for aliases
  ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40
  ide1: drive 0: none
  ide1: drive 1: none
  ERROR: Found no boot partition!

Google shows a lot of people complaining about the same problem, but
no solutions; e.g.:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502418
http://www.archivum.info/qemu-devel at nongnu.org/2008-09/msg01672.html

So does anybody know how to create a virtual PPC64 machine?  Failing
that, does anybody have any suggestions for me on how to diagnose the
GCL segfault?  Failing that, I'll have to ExcludeArch, I guess.
Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From jwboyer at gmail.com  Sat Jan 10 18:35:03 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 10 Jan 2009 13:35:03 -0500
Subject: PPC64 virtual machine
In-Reply-To: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
References: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
Message-ID: <20090110183451.GA18569@zod.rchland.ibm.com>

On Sat, Jan 10, 2009 at 11:30:32AM -0700, Jerry James wrote:
>I've gotten GCL to build successfully in Rawhide on i386 and x86_64
>platforms.  However, it segfaulted on PPC64.
>
>http://koji.fedoraproject.org/koji/taskinfo?taskID=1043890
>
>Before I ExcludeArch the ppc platforms, I would like to try to
>diagnose the problem.  My first thought was to create a virtual PPC64
>machine.  So I downloaded the latest Rawhide boot.iso and fired up
>virt-manager.  After configuring the machine, attempting to boot
>produces this output on the console:
>
>  PPC Open Hack'Ware BIOS for qemu version 0.4.1
>  Build 2007-10-01 06:42:47
>  Copyright 2003-2005 Jocelyn Mayer
>
>  Memory size: 1024 MB.
>  Booting from device d
>  PPC Open Hack'Ware BIOS for qemu version 0.4.1
>  Build 2007-10-01 06:42:47
>  Copyright 2003-2005 Jocelyn Mayer
>
>  ide0: drive 0: Hard Disk
>  ERROR: OF_property_copy cannot get property 'hd' for aliases
>  ide0: drive 1: CD-ROM
>  ERROR: OF_property_copy cannot get property 'cd' for aliases
>  ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40
>  ide1: drive 0: none
>  ide1: drive 1: none
>  ERROR: Found no boot partition!
>
>Google shows a lot of people complaining about the same problem, but
>no solutions; e.g.:

ppc and qemu in general don't get along at the moment.  Also, if you were
looking for hardware assisted virt, you'd need an LPAR which is only available
on the big server boxes.  (Or want to be running on a PPC 440 embedded board,
but that is a tangent).

You can get access to a machine though.  There are those in the community that
have Fedora PPC64 machines you can ssh into if you give them an ssh public
key.  David Woodhouse, Kevin Fenzi, and myself are among them.

josh



From gmaxwell at gmail.com  Sat Jan 10 19:36:49 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sat, 10 Jan 2009 14:36:49 -0500
Subject: ssh private key password
In-Reply-To: <6d06ce20901091933i210a85e8s416e9969cc9077f5@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<e692861c0901091727p562c3b6cq3fa1226041d56f21@mail.gmail.com>
	<6d06ce20901091933i210a85e8s416e9969cc9077f5@mail.gmail.com>
Message-ID: <e692861c0901101136l4e57709aqe263655bff47c189@mail.gmail.com>

On Fri, Jan 9, 2009 at 10:33 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> On 1/9/09, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>> A central unspoofable password dialog does make sense for improving
>> security, Fedora isn't there yet? but CLI apps kicking you to some
>> external dialog for passwords is a necessary step to that end.
>
> And that's been proven by whom?

?

Perhaps you didn't understand what I was saying.

It is considered a reasonable goal by many that there ought to be a
way for joe-average-user to be confident that when he is entering a
password it isn't being entered into some spoof/trojan program.

There are a number of ways to accomplish this, for example: There
could be a secure system level password entry box that requires a
magic keypress to activate, and the keypress can't be intercepted by
anything 'user level'. (The windows NT press ctrl-alt-delete login box
is an example of this). Or, for example, the entry could be
accomplished via a secure hardware device (such as a smartcard or
external keypad) which communicates with a protected system level
service.  I'm sure you can imagine a few more possibilities.

Individual apps (be they CLI or GUI) prompting the user for their
password inline is simply incompatible with that goal. If every little
application has it's own password prompts and password entry
facilities the user can't be confident that the one he's talking to is
the one he wants and isn't just some trojan.

This isn't to say that the one-password-dialog-to-rule-them-all must
be obnoxious, focus stealing, etc. ... only that a particular security
goal which you may or many not share requires the consistency of
singular password entry point.



From konrad at tylerc.org  Sat Jan 10 20:14:09 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 10 Jan 2009 12:14:09 -0800
Subject: ssh private key password
In-Reply-To: <49689F1E.6030405@fedoraproject.org>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<6d06ce20901090622l7d6d5985y756dcfbbeb401e16@mail.gmail.com>
	<49689F1E.6030405@fedoraproject.org>
Message-ID: <200901101214.09412.konrad@tylerc.org>

On Saturday 10 January 2009 05:14:06 am Rahul Sundaram wrote:
> Jerry Amundson wrote:
> > On 1/9/09, John W. Linville <linville at redhat.com> wrote:
> >> On Fri, Jan 09, 2009 at 12:28:43AM -0600, Jerry Amundson wrote:
> >>> In fact, I hope more and more command line tools add this GUI pop-up
> >>> feature. It's awesome.
> >>
> >> I'm curious, why is this awesome?  It seems to me that if one has
> >> chosen to type commands into a terminal emulator that changing focus
> >> to a different window for further input violates the 'rule of least
> >> surprise'?  Or is this some form of "GUI = good, CLI = bad" religion?
> >
> > I agree with you.
> > I was being sarcastic to the person who preferred the current behavior.
>
> You seem to be sarcastic way too often in this list. It is not so
> difficult to accept that there are others with different criteria to yours.
>
> Rahul

Let's not start a flame war with personal attacks, please...

-- 
Conrad Meyer <konrad at tylerc.org>




From loganjerry at gmail.com  Sat Jan 10 20:17:55 2009
From: loganjerry at gmail.com (Jerry James)
Date: Sat, 10 Jan 2009 13:17:55 -0700
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <20090109200022.GA4271@redhat.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
	<20090109200022.GA4271@redhat.com>
Message-ID: <870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>

On Fri, Jan 9, 2009 at 1:00 PM, Deepak Bhole <dbhole at redhat.com> wrote:
> Can you post the exact command that you are running (when it fails) and
> what the resulting log is?

This is an attempted rebuild of the jsr-305 package.  It's a pretty
small download, if anybody wants to try it.  The spec file contains
this:

export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
mkdir -p $MAVEN_REPO_LOCAL
mvn-jpp -Dmaven.repo.local=$MAVEN_REPO_LOCAL install

The mvn-jpp invocation produces this output:

/usr/lib/jvm/java
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   JSR 305: Annotations for Software Defect Detection in Java
[INFO]   JSR 305 Implementation
[INFO]   JSR 305 Test Cases
[INFO]   JSR 305 Sample Use Cases
[INFO]   JSR 305 Proposed Annotations
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Invalid task 'maven2.ignore.versions': you must specify a valid
lifecycle phase, or a goal in the format plugin:goal or
pluginGroupId:pluginArtifactId:pluginVersion:goal
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Sat Jan 10 13:02:47 MST 2009
[INFO] Final Memory: 2M/7M
[INFO] ------------------------------------------------------------------------

I have tried extracting out the bits of the mvn-jpp script and running
them directly in the shell, culminating in a line like this:

$ mvn -Dmaven2.offline.mode -Dmaven2.ignore.versions
-Dmaven2.usejppjars -Dmaven.repo.local=$MAVEN_REPO_LOCAL install

This produces the same output.  If I change the order of the -D
arguments, maven always complains about the second one.  Is anybody
else seeing this?

Again, this is only on Rawhide.  F-9 and F-10 build with no problems.
I just updated my Rawhide installation and tried again with the same
result.
-- 
Jerry James
http://loganjerry.googlepages.com/



From ihok at hotmail.com  Sat Jan 10 20:19:54 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 10 Jan 2009 15:19:54 -0500
Subject: RFE: reopening auto-closed bugs
Message-ID: <BLU129-W40BB0807E0FCAC5424B72ECADA0@phx.gbl>


There was recently an automated sweep through Bugzilla to close F8 bugs since F8 has reached EOL. Some (most?) bugs were closed appropriately, but I was CC'ed on at least 3 that still seem to be present in F10.

https://bugzilla.redhat.com/show_bug.cgi?id=227537
https://bugzilla.redhat.com/show_bug.cgi?id=445209
https://bugzilla.redhat.com/show_bug.cgi?id=443104

Since I did not file those bugs, and since I don't have any special Bugzilla privs, I cannot reopen them. I made comments in the bugs that they still seem valid, but neither the original reporters nor the assignees reopened them.

Here's a request: for those bugs that are closed by an automated end-of-life sweep, let them be re-openable by anyone with a Bugzilla account.

_________________________________________________________________
Windows Live?: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009



From opensource at till.name  Sat Jan 10 20:21:07 2009
From: opensource at till.name (Till Maas)
Date: Sat, 10 Jan 2009 21:21:07 +0100
Subject: Summary of 20090110 FESCo meeting at FUDCon
In-Reply-To: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
Message-ID: <200901102121.14123.opensource@till.name>

On Sat January 10 2009, Jon Stanley wrote:

> * All members present approved a proposal to reseed provenpackager
> with current sponsors, who will be granted administrator status.

What does this mean?
Will everyone except the sponsors be removed from provenpackager and the 
sponsers lifted from provenpackager-sponsors to administrators?
Will new members for provenpackagers become sponsors or regular members?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090110/c67d0a78/attachment.sig>

From notting at redhat.com  Sat Jan 10 20:24:08 2009
From: notting at redhat.com (Bill Nottingham)
Date: Sat, 10 Jan 2009 15:24:08 -0500
Subject: Summary of 20090110 FESCo meeting at FUDCon
In-Reply-To: <200901102121.14123.opensource@till.name>
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
	<200901102121.14123.opensource@till.name>
Message-ID: <20090110202408.GA5369@nostromo.devel.redhat.com>

Till Maas (opensource at till.name) said: 
> > * All members present approved a proposal to reseed provenpackager
> > with current sponsors, who will be granted administrator status.
> 
> What does this mean?
> Will everyone except the sponsors be removed from provenpackager and the 
> sponsers lifted from provenpackager-sponsors to administrators?

Yes.

> Will new members for provenpackagers become sponsors or regular members?

Regular members. (There are 70+ sponsors, so finding a sponsor to elevate
new provenpackager members should not be an issue.)

Bill



From opensource at till.name  Sat Jan 10 20:34:30 2009
From: opensource at till.name (Till Maas)
Date: Sat, 10 Jan 2009 21:34:30 +0100
Subject: RFE: reopening auto-closed bugs
In-Reply-To: <BLU129-W40BB0807E0FCAC5424B72ECADA0@phx.gbl>
References: <BLU129-W40BB0807E0FCAC5424B72ECADA0@phx.gbl>
Message-ID: <200901102134.41885.opensource@till.name>

On Sat January 10 2009, Jack Tanner wrote:

> https://bugzilla.redhat.com/show_bug.cgi?id=227537
> https://bugzilla.redhat.com/show_bug.cgi?id=445209
> https://bugzilla.redhat.com/show_bug.cgi?id=443104
>
> Since I did not file those bugs, and since I don't have any special
> Bugzilla privs, I cannot reopen them. I made comments in the bugs that they
> still seem valid, but neither the original reporters nor the assignees
> reopened them.

I found only in the last bug a comment from you about it still being present 
in Fedora 10, except that two bugs were about the same issue.

> Here's a request: for those bugs that are closed by an automated
> end-of-life sweep, let them be re-openable by anyone with a Bugzilla
> account.

I guess this is not possible with Bugzilla. A probably better (because 
possble) approach would be to review or not auto close any bug report that was 
changed after the EOL reminder, but I am not sure how doable wrt. manpower 
this is.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090110/f08ec272/attachment.sig>

From opensource at till.name  Sat Jan 10 20:35:43 2009
From: opensource at till.name (Till Maas)
Date: Sat, 10 Jan 2009 21:35:43 +0100
Subject: ssh private key password
In-Reply-To: <200901100933.n0A9XgNJ019107@tiffany.internal.tigress.co.uk>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<20090109142858.1c1c50ef.zaitcev@redhat.com>
	<200901100933.n0A9XgNJ019107@tiffany.internal.tigress.co.uk>
Message-ID: <200901102135.44548.opensource@till.name>

On Sat January 10 2009, Ron Yorston wrote:
> Pete Zaitcev <zaitcev at redhat.com> wrote:
> >Having a session-wide store for keys is awesome, which is why the
> >old ssh-agent existed in the first place!
>
> Then it's awesomeness I can do without.  I want to keep control of my
> ssh credentials and *always* be prompted when something wants to use
> them.
>
> My opinion:  gnome-keyring should not act as an ssh agent by default.

At least the old ssh-add accepts the option "-c", which makes the ssh-agent to 
require a confirmation before it uses the loaded key to authenticate. But this 
seems to be maily interesting  (imho) in case a ssh agent is forwarded.

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090110/0ef86c36/attachment.sig>

From opensource at till.name  Sat Jan 10 20:43:29 2009
From: opensource at till.name (Till Maas)
Date: Sat, 10 Jan 2009 21:43:29 +0100
Subject: Summary of 20090110 FESCo meeting at FUDCon
In-Reply-To: <20090110202408.GA5369@nostromo.devel.redhat.com>
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
	<200901102121.14123.opensource@till.name>
	<20090110202408.GA5369@nostromo.devel.redhat.com>
Message-ID: <200901102143.30782.opensource@till.name>

On Sat January 10 2009, Bill Nottingham wrote:

> > Will new members for provenpackagers become sponsors or regular members?
>
> Regular members. (There are 70+ sponsors, so finding a sponsor to elevate
> new provenpackager members should not be an issue.)

What are the new criteria to become provenpackager member?

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090110/a717e61b/attachment.sig>

From tibbs at math.uh.edu  Sat Jan 10 20:48:21 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 10 Jan 2009 14:48:21 -0600
Subject: Summary of 20090110 FESCo meeting at FUDCon
In-Reply-To: <200901102143.30782.opensource@till.name>
References: <da159fda0901100929m495f64ccs55d5c92846132587@mail.gmail.com>
	<200901102121.14123.opensource@till.name>
	<20090110202408.GA5369@nostromo.devel.redhat.com>
	<200901102143.30782.opensource@till.name>
Message-ID: <ufafxjq7uqy.fsf@epithumia.math.uh.edu>

>>>>> "TM" == Till Maas <opensource at till.name> writes:

TM> What are the new criteria to become provenpackager member?

You may note in the original announcement the following:

* Guidelines will be drafted (discretionary) for what type of
qualifications to apply to provenpackager. (Jesse Keating)

 - J<



From camilo at mesias.co.uk  Sat Jan 10 21:52:25 2009
From: camilo at mesias.co.uk (Camilo Mesias)
Date: Sat, 10 Jan 2009 21:52:25 +0000
Subject: ssh private key password
In-Reply-To: <200901102135.44548.opensource@till.name>
References: <200901082131.n08LVGY3015571@laptop14.inf.utfsm.cl>
	<20090109142858.1c1c50ef.zaitcev@redhat.com>
	<200901100933.n0A9XgNJ019107@tiffany.internal.tigress.co.uk>
	<200901102135.44548.opensource@till.name>
Message-ID: <d551e0e20901101352m2ce0ed94y28d46dbfd8c59209@mail.gmail.com>

I sense a bit of dogma creeping in to the discussion.

Is there a way a GUI solution can be made to suit everyone? How about:

* Fedora includes a GUI ssh-agent by default, but
* the traditional ssh-agent is available and easily configurable
* the GUI popup includes a 'turn this heresy off' check box which when
activated tells the user how to turn it back on again, and WHY it's a
good idea to do so.

You don't have to give your passphrase to any agent, you could cancel
/ escape and just use ssh directly.



From adrian at lisas.de  Sat Jan 10 22:04:20 2009
From: adrian at lisas.de (Adrian Reber)
Date: Sat, 10 Jan 2009 23:04:20 +0100
Subject: libcdio update (rawhide)
In-Reply-To: <20081230202412.GA15976@lisas.de>
References: <20081230202412.GA15976@lisas.de>
Message-ID: <20090110220420.GA3272@lisas.de>

On Tue, Dec 30, 2008 at 09:24:12PM +0100, Adrian Reber wrote:
> I want to update libcdio to 0.81. libcdio 0.81 requires a rebuild of all
> application linking against it. If I used repoquery correctly following
> packages in fedora and rpmfusion need a rebuild:
> 
> vlc: GPLv2+
> libcddb: LGPLv2+
> gvfs: LGPLv2+
> kover: GPLv2+
> oxine: GPLv2+
> vcdimager: GPLv2+
> bmpx: GPLv2
> xine-lib-extras-freeworld: GPLv2+
> gstreamer-plugins-ugly: LGPLv2+
> xmms2: LGPLv2+ and GPLv2+ and BSD
> mednafen: GPLv2+
> 
> libcdio also changes the license to GPLv3+ which is a problem only for
> bmpx which, according to RPM, is GPLv2.

I will commit the update to libcdio 0.81 in the next days. This means,
however, that bmpx needs to be removed from rawhide as it as GPLv2 only.

What are the necessary steps to get it removed from the repositories?

> I tried to rebuild all packages against the new libcdio 0.81 and the
> following rebuilds where successful:
> 
> libcddb
> gvfs
> kover
> vcdimager
> bmpx
> gstreamer-plugins-ugly
> xmms2
> mednafen
> 
> I was not able to rebuild the following packages, but all of them are
> right now not rebuildable at all. Even with the current libcdio.
> 
> vlc
> oxine
> xine-lib-extras-freeworld
> 
> I can do all the necessary rebuilds of the rebuildable packages.
> 
> I will commit libcdio 0.81 in the next few days to rawhide.

		Adrian



From lsof at nodata.co.uk  Sat Jan 10 22:42:51 2009
From: lsof at nodata.co.uk (nodata)
Date: Sat, 10 Jan 2009 23:42:51 +0100
Subject: ssh private key password
In-Reply-To: <e692861c0901101136l4e57709aqe263655bff47c189@mail.gmail.com>
References: <1231449993.2181.2.camel@localhost.localdomain>
	<1231450948.2181.5.camel@localhost.localdomain>
	<20090108215224.GA23072@Wolfgang.fedora.phx.redhat.com>
	<1231452134.2181.9.camel@localhost.localdomain>
	<20090108222143.GB23072@Wolfgang.fedora.phx.redhat.com>
	<1231454546.2181.10.camel@localhost.localdomain>
	<1231455597.4755.74.camel@localhost.localdomain>
	<20090109141623.GD17648@redhat.com>
	<e692861c0901091727p562c3b6cq3fa1226041d56f21@mail.gmail.com>
	<6d06ce20901091933i210a85e8s416e9969cc9077f5@mail.gmail.com>
	<e692861c0901101136l4e57709aqe263655bff47c189@mail.gmail.com>
Message-ID: <1231627371.6692.2.camel@localhost.localdomain>

Am Samstag, den 10.01.2009, 14:36 -0500 schrieb Gregory Maxwell:
> On Fri, Jan 9, 2009 at 10:33 PM, Jerry Amundson <jamundso at gmail.com> wrote:
> > On 1/9/09, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> >> A central unspoofable password dialog does make sense for improving
> >> security, Fedora isn't there yet? but CLI apps kicking you to some
> >> external dialog for passwords is a necessary step to that end.
> >
> > And that's been proven by whom?
> 
> ?
> 
> Perhaps you didn't understand what I was saying.
> 
> It is considered a reasonable goal by many that there ought to be a
> way for joe-average-user to be confident that when he is entering a
> password it isn't being entered into some spoof/trojan program.
> 
> There are a number of ways to accomplish this, for example: There
> could be a secure system level password entry box that requires a
> magic keypress to activate, and the keypress can't be intercepted by
> anything 'user level'. (The windows NT press ctrl-alt-delete login box
> is an example of this). Or, for example, the entry could be
> accomplished via a secure hardware device (such as a smartcard or
> external keypad) which communicates with a protected system level
> service.  I'm sure you can imagine a few more possibilities.
> 
> Individual apps (be they CLI or GUI) prompting the user for their
> password inline is simply incompatible with that goal. If every little
> application has it's own password prompts and password entry
> facilities the user can't be confident that the one he's talking to is
> the one he wants and isn't just some trojan.
> 
> This isn't to say that the one-password-dialog-to-rule-them-all must
> be obnoxious, focus stealing, etc. ... only that a particular security
> goal which you may or many not share requires the consistency of
> singular password entry point.
> 

Perhpas slightly off-topic - but related - bug:
 https://bugzilla.redhat.com/show_bug.cgi?id=136341

>From five years ago.




From mschwendt at gmail.com  Sat Jan 10 23:35:59 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 11 Jan 2009 00:35:59 +0100
Subject: libcdio update (rawhide)
In-Reply-To: <20081230202412.GA15976@lisas.de>
References: <20081230202412.GA15976@lisas.de>
Message-ID: <20090111003559.f69cb8f6.mschwendt@gmail.com>

On Tue, 30 Dec 2008 21:24:12 +0100, Adrian wrote:

> 
> I want to update libcdio to 0.81. libcdio 0.81 requires a rebuild of all
> application linking against it. If I used repoquery correctly following
> packages in fedora and rpmfusion need a rebuild:
> 
> vlc: GPLv2+
> libcddb: LGPLv2+
> gvfs: LGPLv2+
> kover: GPLv2+
> oxine: GPLv2+
> vcdimager: GPLv2+
> bmpx: GPLv2
> xine-lib-extras-freeworld: GPLv2+
> gstreamer-plugins-ugly: LGPLv2+
> xmms2: LGPLv2+ and GPLv2+ and BSD
> mednafen: GPLv2+
> 
> libcdio also changes the license to GPLv3+ which is a problem only for
> bmpx which, according to RPM, is GPLv2.

Also "audacious-plugins" - it just doesn't BR libcdio-devel yet:
https://bugzilla.redhat.com/442921



From paul at all-the-johnsons.co.uk  Sun Jan 11 00:47:05 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 11 Jan 2009 00:47:05 +0000
Subject: Has koji gone tits up?
Message-ID: <1231634825.6159.15.camel@PB3.Linux>

Hi,

I've tried to build mono on koji twice in the last 10 minutes with the
same error showing both times. Neither help...

http://koji.fedoraproject.org/koji/getfile?taskID=1044571 

Is this a problem at my end or kojis?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/0bbdb3e5/attachment.sig>

From john5342 at googlemail.com  Sun Jan 11 01:09:22 2009
From: john5342 at googlemail.com (John5342)
Date: Sun, 11 Jan 2009 01:09:22 +0000
Subject: Has koji gone tits up?
In-Reply-To: <1231634825.6159.15.camel@PB3.Linux>
References: <1231634825.6159.15.camel@PB3.Linux>
Message-ID: <6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>

Looking at the last mono build build.log (
http://koji.fedoraproject.org/koji/getfile?taskID=1044571&name=build.log)
shows:

configure: error: msgfmt not found. You need to install the 'gettext'
package, or pass --enable-nls=no to configure.

Probably missing a BuildRequire?

2009/1/11 Paul <paul at all-the-johnsons.co.uk>

> Hi,
>
> I've tried to build mono on koji twice in the last 10 minutes with the
> same error showing both times. Neither help...
>
> http://koji.fedoraproject.org/koji/getfile?taskID=1044571
>
> Is this a problem at my end or kojis?
>
> TTFN
>
> Paul
> --
> ?Sie k?nnen mich aufreizen und wirklich hei? machen!
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
There are 10 kinds of people in the world: Those who understand binary and
those who don't...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/36937d5e/attachment.htm>

From roland at redhat.com  Sun Jan 11 01:11:51 2009
From: roland at redhat.com (Roland McGrath)
Date: Sat, 10 Jan 2009 17:11:51 -0800 (PST)
Subject: Has koji gone tits up?
In-Reply-To: Paul's message of  Sunday, 11 January 2009 00:47:05 +0000
	<1231634825.6159.15.camel@PB3.Linux>
References: <1231634825.6159.15.camel@PB3.Linux>
Message-ID: <20090111011151.B4D44FC305@magilla.sf.frob.com>

> Hi,
> 
> I've tried to build mono on koji twice in the last 10 minutes with the
> same error showing both times. Neither help...
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1044571 

That's a bad link.  Maybe a cut/paste error?

The "build.log" link on
	http://koji.fedoraproject.org/koji/taskinfo?taskID=1044571
points to:
	http://koji.fedoraproject.org/koji/getfile?taskID=1044571&name=build.log

The log file shows a normal looking package build error (some missing
buildrequires, looks like).



From rakesh.pandit at gmail.com  Sun Jan 11 04:25:27 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 11 Jan 2009 09:55:27 +0530
Subject: request for maintaining EPECL5 branches
Message-ID: <b401d2530901102025w10c87fa2q6f47494575de6abc@mail.gmail.com>

Hello,

I had few pending requests for EPEL5. Anyone interested in maintaining
EPEL5  branches for ntop and uriparser?

https://bugzilla.redhat.com/show_bug.cgi?id=476561 ntop (already
branched needs an update)
https://bugzilla.redhat.com/show_bug.cgi?id=479545 uriparser (need to
create branch and do initial import)

-- 
Cheers,
rakesh



From rawhide at fedoraproject.org  Sun Jan 11 08:49:22 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 11 Jan 2009 08:49:22 +0000 (UTC)
Subject: rawhide report: 20090111 changes
Message-ID: <20090111084922.D08BE1F8260@releng2.fedora.phx.redhat.com>

Compose started at Sun Jan 11 06:01:02 UTC 2009

Updated Packages:

abiword-2.6.6-9.fc11
--------------------
* Sat Jan 10 17:00:00 2009 Marc Maurer <uwog at abisource.com> - 1:2.6.6-1
- New upstream release


audit-1.7.11-1.fc11
-------------------
* Sat Jan 10 17:00:00 2009 Steve Grubb <sgrubb at redhat.com> 1.7.11-1
- New upstream release


btrfs-progs-0.16.git1-1.fc11
----------------------------
* Sat Jan 10 17:00:00 2009 Marek Mahut <mmahut at fedoraproject.org> 0.16-1
- Upstream release 0.16

* Sat Jan 10 17:00:00 2009 Kyle McMartin <kyle at redhat.com> 0.16.git1-1
- Upstream git sync from -g72359e8 (needed for kernel...)


dhcp-4.1.0-2.fc11
-----------------
* Sat Jan 10 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 12:4.1.0-2
- Make sure all /etc/dhcp config files are marked in the manifest
- Include new config file directies in the dhcp and dhclient packages
- Do not overwrite new config files if they already exist


e2fsprogs-1.41.3-3.fc11
-----------------------
* Sat Jan 10 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 1.41.3-3
- Remove conservative "don't change journal location" patch for F11
- Add btrfs recognition to blkid


foomatic-3.0.2-69.fc11
----------------------
* Sat Jan 10 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 3.0.2-69
- Updated db-hpijs to 20090110.
- Updated db to 20090110.
- Updated filters to 3.0-20090110.
- Updated db-engine to 3.0-20090110.


gambas2-2.10.2-1.fc11
---------------------
* Mon Jan  5 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 2.10.2-1
- update to 2.10.2


gstreamer-python-0.10.13-1.fc11
-------------------------------
* Sat Jan 10 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.10.13-1
- Update to upstraem 0.10.13
- Forked devel package with pkgconfig file (#477310)


gutenprint-5.2.3-3.fc11
-----------------------
* Sat Jan 10 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 5.2.3-3
- Don't use popen2 in the foomatic PPD update script.


ice-3.3.0-10.fc11
-----------------
* Sat Jan 10 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 3.3.0-10
- ExcludeArch sparc64 no mono there


ikiwiki-3.01-1.fc11
-------------------
* Sat Jan 10 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 3.01-1
- Update to 3.01.


iw-0.9.7-1.fc11
---------------
* Sat Jan 10 17:00:00 2009 Adel Gadllah <adel.gadllah at gmail.com> 0.9.7-1
- Update to 0.9.7


kde-i18n-3.5.10-2.fc11
----------------------
* Sun Jan 11 17:00:00 2009 Than Ngo <than at redhat.com> - 3.5.10-2
- remove kdgantt.mo that conflict with kde-l10n


kdeartwork-4.1.96-2.fc11
------------------------
* Sat Jan 10 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-2
- fix file list

* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kdelibs-4.1.96-5.fc11
---------------------
* Sat Jan 10 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-5
- kdeworkspace cmake files in correct place


kdeplasma-addons-4.1.96-1.fc11
------------------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.25.rc0.git14.fc11
---------------------------------

libopensync-0.36-6.fc11
-----------------------
* Sat Jan 10 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.36-6
- Add patch from upstream changeset for Python 2.6
  (http://www.opensync.org/changeset/4383)

* Fri Jan  9 17:00:00 2009 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de> - 0.36-5
- fix swig version

* Sat Nov 29 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.36-4
- Rebuild for Python 2.6


museek+-0.2-0.1.20090110svn1063.fc11
------------------------------------
* Sat Jan 10 17:00:00 2009 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.2-0.1.20090110svn1063
- Updated to SVN revision 1063
- Added libevent-devel to BuildRequires


nautilus-sendto-1.1.1-1.fc11
----------------------------
* Sat Jan 10 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 1.1.1
- Update to 1.1.1
- Add UPNP and Empathy plugins


nntpgrab-0.4.2-1.fc11
---------------------
* Sat Jan 10 17:00:00 2009 Erik van Pienbroek <info at nntpgrab.nl> - 0.4.2-1
- Update to 0.4.2


ogre-1.6.0-4.fc11
-----------------
* Sat Jan 10 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.6.0-4
- use regular (full) instead of lgc dejavu fonts for the demos (rh 477434)


perl-MooseX-Object-Pluggable-0.0009-2.fc11
------------------------------------------
* Sat Jan 10 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.0009-2
- rebuild against new Moose level


perl-MooseX-Params-Validate-0.07-2.fc11
---------------------------------------
* Sat Jan 10 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.07-2
- rebuild against new Moose


perl-MooseX-StrictConstructor-0.07-3.fc11
-----------------------------------------
* Sat Jan 10 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.07-3
- rebuild under new Moose level


perl-Net-CUPS-0.59-2.fc11
-------------------------
* Sat Jan 10 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.59-2
- ...and finish cleaning up

* Sat Jan 10 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.59-1
- update to 0.59
- drop some fixes that have been applied upstream (RHBZ#455190, RHBZ#455192,
  RT#35966)


pykickstart-1.50-1.fc11
-----------------------
* Sat Jan 10 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 1.50-1
- Add a script to diff two versions of kickstart syntax.
- Add an option to ksvalidator to list all available syntax versions.
- Remove a couple extra newlines in output formatting.
- Add documentation for the new %include representation.
- Add support %include to the pykickstart data objects.


python-jinja2-2.1.1-1.fc11
--------------------------
* Sat Jan 10 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 2.1.1-1
- Update to 2.1.1 (bugfix release).


vdr-skins-20081124-3.fc11
-------------------------
* Sat Jan 10 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 20081124-3
- Use full DejaVu fonts instead of LGC (#477478).


xzgv-0.9-5.fc11
---------------
* Sat Jan 10 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> - 0.9-5
- Update to latest upstream svn (r41) fixing several crashes
- Add a patch fixing thumbnail loading
- Add a patch fixing thumbnail generation for pictures where
  the width is not a multiple of 4
- Add a patch fixing thumbnail generation for pictures which have an alpha
  channel
- Fix scriptlet error on uninstall (make it preun instead of postun)


Summary:
Added Packages: 0
Removed Packages: 0
Modified Packages: 30
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(wv-1.0) >= 0:1.2.0
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(wv-1.0) >= 0:1.2.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From joshuacov at googlemail.com  Sun Jan 11 12:06:17 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sun, 11 Jan 2009 07:06:17 -0500
Subject: AMD Video BIOS Disassembler and ATi RS485
In-Reply-To: <5f6f8c5f0901100756l374756a7l94bb0f5b7d2f92f5@mail.gmail.com>
References: <5f6f8c5f0901091314q579718b6ua6143304aadbb030@mail.gmail.com>
	<1231547723.4259.34.camel@optimus>
	<5f6f8c5f0901100204i38384ca4p42545dd2049d5ce0@mail.gmail.com>
	<5f6f8c5f0901100225p771e5851ta34bc7b7f0b00db@mail.gmail.com>
	<1231592001.6763.0.camel@localhost>
	<5f6f8c5f0901100756l374756a7l94bb0f5b7d2f92f5@mail.gmail.com>
Message-ID: <5f6f8c5f0901110406h6e1cf6dai390e2d982012c1da@mail.gmail.com>

2009/1/10 Joshua C. <joshuacov at googlemail.com>:
>>
> I've done it. Thank you for the help.
>>>

I did some more test with the machine with 4GB memory. When I remove 2Gb then
it works fine. No problems at all, but with 4GB the problem occurs again. I
tried setting radeon.gartsize=32/64/128/256 (in bios it is set to 128MB) and
the computer boots without problems. Even with gartsize=256.

This makes me think that the xserver cannot determine the gartsize when
starting up, because the kms works in all the cases, until the moment the
xserver should be started. In my case the xserver needs to see any value set to
gartsize in order to start properly.



From rjones at redhat.com  Sun Jan 11 12:47:19 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sun, 11 Jan 2009 12:47:19 +0000
Subject: New Fedora virtualization list: fedora-virt
In-Reply-To: <4967A8EE.5090702@redhat.com>
References: <20090109145050.GC9484@redhat.com> <4967A8EE.5090702@redhat.com>
Message-ID: <20090111124719.GA27926@amd.home.annexia.org>

On Fri, Jan 09, 2009 at 02:43:42PM -0500, Michael DeHaan wrote:
> fedora-virt at redhat.com -- the new list
[...]
> et-mgmt-tools at redhat.com -- virt-manager, virt-install, virsh, and  
> related tools, also appliance build tools (thincrust) that target virt

I think we should fold et-mgmt-tools into fedora-virt too.  The list
has < 10 messages / day, and has a confusing name that superficially
has nothing to do with virtualization unless you happen to know the
history behind some Red Hat internal department.

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 stickster at gmail.com  Sun Jan 11 03:21:35 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Sat, 10 Jan 2009 22:21:35 -0500
Subject: Fedora 11 release name
Message-ID: <20090111032135.GA32025@localhost.localdomain>

The Fedora 11 release name is:

  Leonidas

The full GPG-signed message from our election coordinator, Nigel
Jones, is attached.  Thank you to the community for their suggestions,
Josh Boyer and the Board for their work on additional diligence
searches, and Nigel Jones for setting up the voting.

-- 
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 --------------
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Election Results for Fedora 11 Release Name

Voting Period: 05 January 2009 08:00:00 UTC to 09 January 2009 23:59:59 UTC

Nominations:

* Blarney
* Bras?lia
* Claypool
* Duchess
* Euryalus
* Indomitable
* Leonidas
* Zampone

Outcomes:

As defined in the election text, the one (1) candidate with the greatest number
 of votes will be chosen as the Fedora 11 Release Name.

Information:

At close of voting there were:
310 valid ballots

Using the Fedora Range Voting method, each candidate could attain a maximum of
2480 votes (310*2480).

Results:

1. Leonidas	1108
*****
2. Indomitable	1054
3. Claypool	 944
4. Bras?lia	 890
5. Blarney	 890
6. Duchess	 838
7. Zampone	 716
8. Euryalus	 713

As such, Leonidas has been selected as the release name for Fedora 11.

Signed,

Nigel Jones <nigjones at redhat.com>
Elections Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFJaDQYZLzpFltXFOsRAtNWAKCsJHlC6G31S2MAfcmxmyjKnNi8PgCg1JTj
LQd1lBHJaBmRgzFbCZoF/mM=
=UrdZ
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090110/7d3ed80f/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From nicolas.mailhot at laposte.net  Sun Jan 11 15:12:42 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 11 Jan 2009 16:12:42 +0100
Subject: New font packaging guidelines
In-Reply-To: <1229789615.16655.28.camel@arekh.okg>
References: <1229789615.16655.28.camel@arekh.okg>
Message-ID: <1231686762.16307.2.camel@arekh.okg>

Dear all,

To help people deal with the new fonts guidelines, I've added the
following FAQ to the wiki:

http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ)

Feel free to complete it (or request additions)

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/36d39634/attachment.sig>

From dbhole at redhat.com  Sun Jan 11 15:28:00 2009
From: dbhole at redhat.com (Deepak Bhole)
Date: Sun, 11 Jan 2009 10:28:00 -0500
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
	<20090109200022.GA4271@redhat.com>
	<870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>
Message-ID: <20090111152759.GA8635@redhat.com>

* Jerry James <loganjerry at gmail.com> [2009-01-10 15:19]:
> On Fri, Jan 9, 2009 at 1:00 PM, Deepak Bhole <dbhole at redhat.com> wrote:
> > Can you post the exact command that you are running (when it fails) and
> > what the resulting log is?
> 
> This is an attempted rebuild of the jsr-305 package.  It's a pretty
> small download, if anybody wants to try it.  The spec file contains
> this:
> 
> export MAVEN_REPO_LOCAL=$(pwd)/.m2/repository
> mkdir -p $MAVEN_REPO_LOCAL
> mvn-jpp -Dmaven.repo.local=$MAVEN_REPO_LOCAL install
> 
> The mvn-jpp invocation produces this output:
> 
> /usr/lib/jvm/java
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO]   JSR 305: Annotations for Software Defect Detection in Java
> [INFO]   JSR 305 Implementation
> [INFO]   JSR 305 Test Cases
> [INFO]   JSR 305 Sample Use Cases
> [INFO]   JSR 305 Proposed Annotations
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Invalid task 'maven2.ignore.versions': you must specify a valid
> lifecycle phase, or a goal in the format plugin:goal or
> pluginGroupId:pluginArtifactId:pluginVersion:goal
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: < 1 second
> [INFO] Finished at: Sat Jan 10 13:02:47 MST 2009
> [INFO] Final Memory: 2M/7M
> [INFO] ------------------------------------------------------------------------
> 
> I have tried extracting out the bits of the mvn-jpp script and running
> them directly in the shell, culminating in a line like this:
> 
> $ mvn -Dmaven2.offline.mode -Dmaven2.ignore.versions
> -Dmaven2.usejppjars -Dmaven.repo.local=$MAVEN_REPO_LOCAL install
> 
> This produces the same output.  If I change the order of the -D
> arguments, maven always complains about the second one.  Is anybody
> else seeing this?
> 
> Again, this is only on Rawhide.  F-9 and F-10 build with no problems.
> I just updated my Rawhide installation and tried again with the same
> result.

Hmm, I don't have a rawhide machine around atm, but I have never seen
that before. Do you have another copy of (non-rpm) maven on the system?

Deepak

> -- 
> Jerry James
> http://loganjerry.googlepages.com/



From debarshi.ray at gmail.com  Sun Jan 11 15:40:14 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 11 Jan 2009 21:10:14 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
Message-ID: <3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>

> I would like to initiate the non-responsive maintainer policy [1]
> against Damien Durand (CC'ed).

Some more bugs assigned to him that need attention:
https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10
https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6

Cheers,
Debarshi



From kevin at scrye.com  Sun Jan 11 16:09:27 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Sun, 11 Jan 2009 09:09:27 -0700
Subject: PPC64 virtual machine
In-Reply-To: <20090110183451.GA18569@zod.rchland.ibm.com>
References: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
	<20090110183451.GA18569@zod.rchland.ibm.com>
Message-ID: <20090111090927.22b24cb8@ohm.scrye.com>

On Sat, 10 Jan 2009 13:35:03 -0500
Josh Boyer <jwboyer at gmail.com> wrote:

> On Sat, Jan 10, 2009 at 11:30:32AM -0700, Jerry James wrote:
> >I've gotten GCL to build successfully in Rawhide on i386 and x86_64
> >platforms.  However, it segfaulted on PPC64.
> >
> >http://koji.fedoraproject.org/koji/taskinfo?taskID=1043890
> >
> >Before I ExcludeArch the ppc platforms, I would like to try to
> >diagnose the problem.  My first thought was to create a virtual PPC64
> >machine.  So I downloaded the latest Rawhide boot.iso and fired up
> >virt-manager.  After configuring the machine, attempting to boot
> >produces this output on the console:
> >
> >  PPC Open Hack'Ware BIOS for qemu version 0.4.1
> >  Build 2007-10-01 06:42:47
> >  Copyright 2003-2005 Jocelyn Mayer
> >
> >  Memory size: 1024 MB.
> >  Booting from device d
> >  PPC Open Hack'Ware BIOS for qemu version 0.4.1
> >  Build 2007-10-01 06:42:47
> >  Copyright 2003-2005 Jocelyn Mayer
> >
> >  ide0: drive 0: Hard Disk
> >  ERROR: OF_property_copy cannot get property 'hd' for aliases
> >  ide0: drive 1: CD-ROM
> >  ERROR: OF_property_copy cannot get property 'cd' for aliases
> >  ERROR: ATAPI TEST_UNIT_READY : status 41 != 0x40
> >  ide1: drive 0: none
> >  ide1: drive 1: none
> >  ERROR: Found no boot partition!
> >
> >Google shows a lot of people complaining about the same problem, but
> >no solutions; e.g.:
> 
> ppc and qemu in general don't get along at the moment.  Also, if you
> were looking for hardware assisted virt, you'd need an LPAR which is
> only available on the big server boxes.  (Or want to be running on a
> PPC 440 embedded board, but that is a tangent).
> 
> You can get access to a machine though.  There are those in the
> community that have Fedora PPC64 machines you can ssh into if you
> give them an ssh public key.  David Woodhouse, Kevin Fenzi, and
> myself are among them.

Yeah, happy to provide access.

I only have a ppc32 box however. 

> 
> josh
> 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/3c359c45/attachment.sig>

From sundaram at fedoraproject.org  Sun Jan 11 16:21:43 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 11 Jan 2009 21:51:43 +0530
Subject: New Fedora virtualization list: fedora-virt
In-Reply-To: <20090111124719.GA27926@amd.home.annexia.org>
References: <20090109145050.GC9484@redhat.com> <4967A8EE.5090702@redhat.com>
	<20090111124719.GA27926@amd.home.annexia.org>
Message-ID: <496A1C97.9060508@fedoraproject.org>

Richard W.M. Jones wrote:
> On Fri, Jan 09, 2009 at 02:43:42PM -0500, Michael DeHaan wrote:
>> fedora-virt at redhat.com -- the new list
> [...]
>> et-mgmt-tools at redhat.com -- virt-manager, virt-install, virsh, and  
>> related tools, also appliance build tools (thincrust) that target virt
> 
> I think we should fold et-mgmt-tools into fedora-virt too.  The list
> has < 10 messages / day, and has a confusing name that superficially
> has nothing to do with virtualization unless you happen to know the
> history behind some Red Hat internal department.

Perhaps you can move the projects under development to fedorahosted.org 
and get some added benefits such as a tracker.

Rahul



From rakesh.pandit at gmail.com  Sun Jan 11 16:37:48 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sun, 11 Jan 2009 22:07:48 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
Message-ID: <b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>

2009/1/11 Debarshi Ray <debarshi.ray at gmail.com>:
>> I would like to initiate the non-responsive maintainer policy [1]
>> against Damien Durand (CC'ed).
>
> Some more bugs assigned to him that need attention:
> https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10

I checked this one and it is probably fixed already, though F9 build
is absent but I checked that F9 build also.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1044981

And it is fine.

> https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6

Will look into this, it needs some love I guess.

-- 
rakesh



From paul at all-the-johnsons.co.uk  Sun Jan 11 17:34:48 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 11 Jan 2009 17:34:48 +0000
Subject: Has koji gone tits up?
In-Reply-To: <6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
References: <1231634825.6159.15.camel@PB3.Linux>
	<6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
Message-ID: <1231695288.18610.1.camel@PB3.Linux>

Hi,

> Looking at the last mono build build.log
> (http://koji.fedoraproject.org/koji/getfile?taskID=1044571&name=build.log) shows:
> 
> configure: error: msgfmt not found. You need to install the 'gettext' package, or pass --enable-nls=no to configure.
> 
> Probably missing a BuildRequire?

Okay, I've added it in. The URL I emailed for the build is the one koji
sent and on my box it gave a pile of python errors rather than something
useful.

Thanks to everyone who replied though :-)

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/b36da3a4/attachment.sig>

From lsof at nodata.co.uk  Sun Jan 11 18:12:34 2009
From: lsof at nodata.co.uk (nodata)
Date: Sun, 11 Jan 2009 19:12:34 +0100
Subject: skype in F10-x86_64
In-Reply-To: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
References: <f4a59ea0901081712h4840868cm85efe929cd64acf2@mail.gmail.com>
Message-ID: <1231697554.5238.1.camel@localhost.localdomain>

Am Donnerstag, den 08.01.2009, 23:12 -0200 schrieb Luc?lio Gomes de
Freitas:
> Hello,
> Does anybody use skype in F10-x86_64?  Does it work with F10?
> I cannot get any sound with Skype for Linux. What's happening?
> I would like to have sound and image on it.
> Thanks,
> Luc?lio.
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Is there an selinux policy for skype?




From mschwendt at gmail.com  Sun Jan 11 18:20:29 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sun, 11 Jan 2009 19:20:29 +0100
Subject: Has koji gone tits up?
In-Reply-To: <1231695288.18610.1.camel@PB3.Linux>
References: <1231634825.6159.15.camel@PB3.Linux>
	<6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
	<1231695288.18610.1.camel@PB3.Linux>
Message-ID: <20090111192029.e29154d6.mschwendt@gmail.com>

On Sun, 11 Jan 2009 17:34:48 +0000, Paul wrote:

> http://koji.fedoraproject.org/koji/getfile?taskID=1044571 

> Okay, I've added it in. The URL I emailed for the build is the one koji
> sent 

Are you sure?

The second parameter is missing: &name=build.log
Looks very much like a cut'n'paste mistake.

In build failure reports, koji sends many links to log files.
And at the bottom, two links to the Task Info and Build Info pages.



From rakesh.pandit at gmail.com  Sun Jan 11 19:23:37 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 12 Jan 2009 00:53:37 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
Message-ID: <b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>

2009/1/11 Rakesh Pandit <rakesh.pandit at gmail.com>:
> 2009/1/11 Debarshi Ray <debarshi.ray at gmail.com>:
>>> I would like to initiate the non-responsive maintainer policy [1]
>>> against Damien Durand (CC'ed).
>>
>> Some more bugs assigned to him that need attention:
>> https://bugzilla.redhat.com/465114: FTBFS gnome-specimen-0.3-2.fc10
>
> I checked this one and it is probably fixed already, though F9 build
> is absent but I checked that F9 build also.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1044981
>
> And it is fine.
>

Wello this one is already fixed and I have build for F-9 and closed.

>> https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
>

While fixing this one I encountered a problem of 2 more folks fixing
it simultaneously. Which resulted in unnecessary commits and bump.

The basic problem is without assigning bug why we committing the fix ?
This has resulted in confusion. Lets assign bugs at least before
acting on them and that will help in collaboration.

-- 
rakesh



From Axel.Thimm at ATrpms.net  Sun Jan 11 19:47:14 2009
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 11 Jan 2009 21:47:14 +0200
Subject: ffmpeg stable API/ABI or not? (was: sound problems)
Message-ID: <20090111194714.GB14847@victor.nirvana>

On Tue, Jan 06, 2009 at 10:34:28PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 06 January 2009 at 19:59, Kevin Kofler wrote:
> > Axel Thimm wrote:
> 
> > > For example ffmpeg or similar packages would require almost a third of
> > > ATrpms' package to be rebuilt.
> > 
> > Yeah, ffmpeg is a particularly annoying library due to its notorious
> > ABI-unstability
> 
> Please, stop spreading FUD. As I said in another post in this thread,
> there was one API/ABI change in the last three years and one move of headers.
> If that's not stable, then I dare you to find another project that is
> developed at a similar pace and has a more stable API and ABI.

Well, just to present some facts, ffmpeg's libavcodec just recently in
2008 bumped soname again. And 2008 saw the move of the headers, so
there are actually rather fresh changes in ABI/API, and the three
years before didn't look much different (Note: libpostproc and
libswscale). Note that the sonames are in the range 49-52, which
indicates many bumps in ffmpeg's history.

Also about a year or two ago I tried to get an upstream release
blessed, there were many folks on ffmpeg-devel that were interested,
unsurprisingly mainly distribution packagers. One of the main reasons
stated from the core developers was that they don't want to commit to
an API/ABI due to a release. So if there is FUD it is being fueled
from upstream.

Anyway if ffmpeg has really stabilized in terms of API/ABI then we
will never again read anything about repo foo's ffmpeg not carrying
the sonames as needed by repo bar, so any "bad" reputation ffmpeg may
have in terms of API/ABI will automatically fade away, and maybe there
will be an ffmpeg release again someday.

FWIW I'm not criticising ffmpeg's development quality, this is a great
project and very vivid upstream. It only lacks in the downstream
channels, e.g. offering releases for the various downstreams to base
their projects upon leading to every second project to fork off a
snapshot from ffmpeg.

So actually my plead to anyone dissatisfied with the API/ABI stability
or bad rumor of it and with enough knowledge on the matter: Please try
to get onto ffmpeg-devel and become a release manager. Release early,
release often is what ffmpeg lacks.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/20959cb7/attachment.sig>

From seg at haxxed.com  Mon Jan 12 04:07:31 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 11 Jan 2009 22:07:31 -0600
Subject: proposal for fedora11 feature ReviewOMatic
In-Reply-To: <4963B1FF.9000001@gmail.com>
References: <b401d2530901040752k4c1426acm6227e0830d327897@mail.gmail.com>
	<20090105181535.GB11824@nostromo.devel.redhat.com>
	<1231179643.12948.1.camel@arekh.okg>
	<ufak599vbye.fsf@epithumia.math.uh.edu>
	<1231188376.17459.0.camel@arekh.okg>
	<ufaljtopizg.fsf@epithumia.math.uh.edu>
	<3170f42f0901060720q6c5767f6xf11a816402f8b2c7@mail.gmail.com>
	<ufa7i58pd7m.fsf@epithumia.math.uh.edu>
	<3170f42f0901061101x6bab50x7f5ebf075f73b72d@mail.gmail.com>
	<4963B1FF.9000001@gmail.com>
Message-ID: <1231733251.26000.1.camel@localhost.localdomain>

On Tue, 2009-01-06 at 11:33 -0800, Toshio Kuratomi wrote:
> Debarshi Ray wrote:
> >>  However, my point was
> >> that the mere existence of this software won't magically eliminate the
> >> need for humans to do package reviews,
> > 
> > Sure. After it is just a tool, but the idea is to reduce the number of
> > manual steps to a review. Manually carrying out mundane things like
> > verifying whether the package builds in Koji/Mock, the Source0 tag is
> > sane, md5sum of upstream and packaged tarballs match, rpmlint output,
> > etc. should not burden a person every time he/she does a review.
> > 
> Note that the software needs to be clear on what is still required of
> the human reviewer.  for instance, Source tag has several automatable
> steps but also must have a human review that the Source URL is canonical
> in the first place.

"Fedora Review Wizard" (or "Druid" as GNOME apparently calls them...)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/d051a29a/attachment.sig>

From rawhide at fedoraproject.org  Mon Jan 12 07:56:35 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 12 Jan 2009 07:56:35 +0000 (UTC)
Subject: rawhide report: 20090112 changes
Message-ID: <20090112075635.41EFB1F825D@releng2.fedora.phx.redhat.com>

Compose started at Mon Jan 12 06:01:03 UTC 2009

New package HamFax
        HamFax is an application for sending and receiving facsimiles in amateur radio
New package cpm
        Console Password Manager
New package mpop
        POP3 client for recieving mail from POP3 mailboxes
New package perl-DateTime-Format-DateParse
        Parse Date::Parse compatible formats
New package perl-DateTime-Format-Flexible
        Flexibly parse strings and turn them into DateTime objects
New package procinfo-ng
        Console-based system monitoring utility
Updated Packages:

alexandria-0.6.3-6.fc11
-----------------------
* Sun Jan 11 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.6.3-6
- Rebuild to restore ARCHIVESIZE


anyremote-4.14-1.fc11
---------------------
* Sat Jan 10 17:00:00 2009 Mikhail Fedotov <anyremote at mail.ru> - 4.14-1
- Small corrections in configuration files. Configuration file for AlsaPlayer, 
  Digikam (thanks to Marcus Hardt) and GPicView were added. 
  Syntax of Emulate() command was extended.


blender-2.48a-10.fc11
---------------------
* Sun Jan 11 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-10
- Create symlink to DajaVu-Sans


cairo-dock-2.0.0-0.3.svn1481_trunk.fc11
---------------------------------------
* Mon Jan 12 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1481


cdargs-1.35-3.fc11
------------------
* Sun Jan 11 17:00:00 2009 Milos Jakubicek <xjakub at fi.muni.cz> - 1.35-3
- Fixed usage in other shells than bash: minor compatibility code changes and 
  no complains because completion doesn't work (fix BZ#479398).


darkgarden-fonts-1.1-5.fc11
---------------------------
* Sun Jan 11 17:00:00 2009 Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com> 1.1-5
- Modified spec file to comply with recent policy changes.


dhcp-4.1.0-3.fc11
-----------------
* Sun Jan 11 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 12:4.1.0-3
- Correct syntax errors in %post script (#479012)


gdmap-0.8.1-3.fc11
------------------
* Mon Jan 12 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-3
- Bump

* Mon Jan 12 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-2
- Bump + some cleaning.

* Sun Jan 11 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-1
- Updated to 0.8.1, fixed .desktop file and license tag.
- Fixed Unowned directories.


geda-docs-20081231-1.fc11
-------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-examples-20081231-1.fc11
-----------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-gattrib-20081231-1.fc11
----------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-gnetlist-20081231-1.fc11
-----------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-gschem-20081231-1.fc11
---------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-gsymcheck-20081231-1.fc11
------------------------------
* Sun Jan 11 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-symbols-20081231-1.fc11
----------------------------
* Wed Dec 31 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


geda-utils-20081231-1.fc11
--------------------------
* Wed Dec 31 17:00:00 2008 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> - 20081231-1
- new upstream release


gnome-applets-2.25.3-3.fc11
---------------------------
* Sun Jan 11 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.3-3
- Fix the nullappletification of the mixer applet


gnome-doc-utils-0.14.2-1.fc11
-----------------------------
* Sun Jan 11 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 0.14.2-1
- Update to 0.14.2


gnome-media-2.25.1-4.fc11
-------------------------
* Sun Jan 11 17:00:00 2009 Matthias Clasen <mclasen at redhat.com>  2.25.1-4
- Silence %pre and %preun


gnome-utils-2.25.2-1.fc11
-------------------------
* Sun Jan 11 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.2-1
- Update to 2.25.2


grub-0.97-37.fc11
-----------------
* Sun Jan 11 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.97-37
- Get rid of /usr/bin/cmp dependency (Ville Skytt??, #431351)
- Support multiple initrds (Jeff Layton, #179127)
- Obey 2.06 boot protocol's cmdline_size (Lubomir Rintel, #327541)


hedgewars-0.9.8-1.fc11
----------------------
* Sat Jan 10 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.9.8-1
- New upstream release 0.9.8


hfsutils-3.2.6-15.fc11
----------------------
* Sun Jan 11 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 3.2.6-15
- Updated large file patch. Closes Red Hat Bugzilla bug #465060.
- Added 'BuildRequires: libXft-devel'.


hunspell-en-0.20090110-1.fc11
-----------------------------
* Sun Jan 11 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20090110-1
- latest version


hunspell-sk-0.20090106-1.fc11
-----------------------------
* Sun Jan 11 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 1:0.20090106-1
- latest version


kdegames-4.1.96-1.fc11
----------------------
* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.28.rc1.fc11
---------------------------
* Fri Jan  9 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- Disable CONFIG_MAXSMP on x86_64.
- Fixup build failure in powerpc due to cpumask changes.

* Fri Jan  9 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- 2.6.29-rc1


libmatheval-1.1.5-4.fc11
------------------------
* Sun Jan 11 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 1.1.5-4
- Info page fixed by upstream. Closes Red Hat Bugzilla bug #465112.

* Fri May 23 18:00:00 2008 Jon Stanley <jonstanley at gmail.com> - 1.1.5-3
- Fix license tag


libtranslate-0.99-18.fc11
-------------------------
* Sun Jan 11 17:00:00 2009 Dmitry Butskoy <Dmitry at Butskoy.name> - 0.99-18
- update services.xml (google, babelfish, add apertium and opentrad) (#478626)
  (by Dwayne Bailey <dwayne at translate.org.za>)


libv4l-0.5.8-1.fc11
-------------------
* Sun Jan 11 17:00:00 2009 Hans de Goede <j.w.r.degoede at hhs.nl> 0.5.8-1
- New upstream release 0.5.8


liferea-1.4.23-1.fc11
---------------------
* Sun Jan 11 17:00:00 2009 Steven M. Parrish <tuxbrewr at fedoraproject.org> 1.4.23
- New upstream release


mod_mono-2.2-4.RC2.20090901svn122806.fc11
-----------------------------------------
* Fri Jan  9 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-4.RC2.20090901svn122806
- Bump to RC2
- Big update from svn

* Wed Dec 17 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.pre3.20081217svn117989
- Bump to preview 3
- Move to svn for bug fixes

* Sat Dec  6 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre2
- Bump to preview 2


mono-2.2-17.RC2.20091101svn122994.fc11
--------------------------------------
* Sun Jan 11 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-17.RC2.20091101svn122991
- Updates from svn
- Change to RC2
- Removed mono-api-diff.exe and transform.exe from spec
- Fixes some problems with winforms on some boxes
- Added gettext-devel


mono-tools-2.2-10.RC2.20090111svn122993.fc11
--------------------------------------------
* Sun Jan 11 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> -.2.2-10.RC2.20090111svn122974
- update from svn
- bump to RC2


monodevelop-1.9.2-pre1.20090110svn122940.fc11
---------------------------------------------
* Sat Jan 10 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.2-pre1.200900109svn122940
- Update from svn


munin-1.2.6-5.fc11
------------------
* Sun Jan 11 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.6-5
- Switch to using dejavu-fonts instead of bitstream-vera


ngspice-18-1.fc11
-----------------
* Sat Jan 10 17:00:00 2009 Chitlesh Goorah <chitlesh [AT] fedoraproject DOT org> 18-1
- new upstream release


ocsinventory-1.02-0.10.rc3.fc11
-------------------------------
* Sun Jan 11 17:00:00 2009 Remi Collet <Fedora at famillecollet.com> 1.02-0.10.rc3
- add r1447 and r1462 patch
- change log selinux context (httpd_log_t)


pachi-1.0-6.fc11
----------------
* Sun Jan 11 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.0-6
- Add 2 patches with small fixes from altlinux


perl-Apache2-SOAP-0.73-1.fc11
-----------------------------

qemu-0.9.1-12.fc11
------------------
* Sun Jan 11 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 0.9.1-12
- Updated build patch. Closes Red Hat Bugzilla bug #465041.

* Wed Dec 31 17:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.9.1-11
- add sparcv9 and sparc64 support

* Fri Jul 25 18:00:00 2008 Bill Nottingham <notting at redhat.com>
- Fix qemu-img summary (#456344)


scidavis-0.1.3-7.fc11
---------------------
* Sun Jan 11 17:00:00 2009 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 0.1.3-7
- Replace the sip patch by a better one from upstream

* Sun Jan 11 17:00:00 2009 Eric Tanguy <eric.tanguy at univ-nantes.fr> - 0.1.3-6
- Replace the sip patch by the one from upstream


shorewall-4.2.4-1.fc11
----------------------
* Sun Jan 11 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.4-1
- Update to version 4.2.4 which adds IPV6 support and two new sub-packages
  (shorewall6 and shorewall6-lite) 
- Add proper versioning to sub-packages
- Remove patch patch-perl-4.2.3.1


supybot-fedora-0.2.2-1.fc11
---------------------------
* Sun Jan 11 17:00:00 2009 Jon Stanley <jonstanley at gmail.com> - 0.2.2-1
- New upstream 0.2.2


thibault-fonts-0.1-3.fc11
-------------------------
* Sun Jan 11 17:00:00 2009 Lyos Gemini Norezel <Lyos.GeminiNorezel at gmail.com> 0.1-3
- Modified spec file to comply with new policy changes.


usb_modeswitch-0.9.6-1.fc11
---------------------------
* Sun Jan 11 17:00:00 2009 Robert M. Albrecht <fedora at romal.de> 0.9.6-1
* new upstream release

* Sat Dec 13 17:00:00 2008 Robert M. Albrecht <fedora at romal.de> 0.9.5-1
* new upstream release


vdr-osdteletext-0.8.1-1.fc11
----------------------------
* Sun Jan 11 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 0.8.1-1
- 0.8.1.
- Trim pre-Fedora %changelog entries.


xorg-x11-drv-mouse-1.4.0-1.fc11
-------------------------------
* Mon Jan 12 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 1.4.0-1
- mouse 1.4.0


xorg-x11-server-1.5.99.3-9.fc11
-------------------------------
* Mon Jan 12 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 1.5.99.3-5
- rebase to today's server-1.6-enterleave branch, current 1.6 plus enterleave
  patches.
- drop xserver-1.5.99.3-offscreen-pixmaps.patch - merged upstream
- fix up git checkout in make-git-snapshot.sh to allow a remote branch to be
  specified as $1.


xosview-1.8.3-14.20080301cvs.fc11
---------------------------------
* Sun Jan 11 17:00:00 2009 Terje Rosten <terje.rosten at ntnu.no> - 1.8.3-14.20080301cvs
- Add xorg-x11-fonts-misc to req, fixing #479456.


xsp-2.2-7.RC2.20090901svn122761.fc11
------------------------------------
* Fri Jan  9 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-7.RC2.20090901svn122761
- rename to RC2
- update from svn


Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 51
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	1:kawa-javadoc-1.9.1-6.fc11.i386 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.i386 requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	munin-1.2.6-5.fc11.noarch requires dejavu-fonts
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.x86_64 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.i386 requires pkgconfig(wv-1.0) >= 0:1.2.0
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.x86_64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.x86_64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	munin-1.2.6-5.fc11.noarch requires dejavu-fonts
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:kawa-javadoc-1.9.1-6.fc11.ppc requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc requires pkgconfig(wv-1.0) >= 0:1.2.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.ppc requires libpython2.5.so.1.0
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	munin-1.2.6-5.fc11.noarch requires dejavu-fonts
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	1:kawa-javadoc-1.9.1-6.fc11.ppc64 requires kawa = 0:1.9.1-6.fc11
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(libgoffice-0.4) >= 0:0.4.0
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(fribidi) >= 0:0.10.4
	1:libabiword-devel-2.6.6-9.fc11.ppc64 requires pkgconfig(wv-1.0) >= 0:1.2.0
	libopensync-plugin-python-0.36-1.fc10.ppc64 requires libpython2.5.so.1.0()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	munin-1.2.6-5.fc11.noarch requires dejavu-fonts
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	php-ZendFramework-tests-1.7.2-2.fc11.noarch requires bitstream-vera-fonts
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11





From mschwendt at gmail.com  Mon Jan 12 10:37:24 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 12 Jan 2009 11:37:24 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
Message-ID: <20090112113724.73cf2bae.mschwendt@gmail.com>

On Mon, 12 Jan 2009 00:53:37 +0530, Rakesh wrote:

> >> https://bugzilla.redhat.com/465075: FTBFS gdmap-0.7.5-6.fc6
> >
> 
> While fixing this one I encountered a problem of 2 more folks fixing
> it simultaneously. Which resulted in unnecessary commits and bump.
> 
> The basic problem is without assigning bug why we committing the fix ?
> This has resulted in confusion. Lets assign bugs at least before
> acting on them and that will help in collaboration.

The problem is you. Nobody else has committed anything at the same
time. In gdmap/devel, take a look at

  cvs diff -r1.9 -r1.10 gdmap.spec | less

which shows that you've reverted several old commits dating
back to Feb 2008. You've also decreased %release which resulted
in tag conflicts. To avoid all this, you ought to have started
with a fresh working-copy.



From rakesh.pandit at gmail.com  Mon Jan 12 11:04:45 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 12 Jan 2009 16:34:45 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20090112113724.73cf2bae.mschwendt@gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
Message-ID: <b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>

2009/1/12 Michael Schwendt <mschwendt at gmail.com>:
[..]
>
> The problem is you. Nobody else has committed anything at the same
> time. In gdmap/devel, take a look at
>
>  cvs diff -r1.9 -r1.10 gdmap.spec | less
>
> which shows that you've reverted several old commits dating
> back to Feb 2008. You've also decreased %release which resulted
> in tag conflicts. To avoid all this, you ought to have started
> with a fresh working-copy.
>

Yeah my mistake

But what prevents one to assigning bugs to himself before fixing it
and doing the build after commits? Not even importing the source for
which fix was done ? why half work ?

-- 
rakesh



From rakesh.pandit at gmail.com  Mon Jan 12 11:26:34 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 12 Jan 2009 16:56:34 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
Message-ID: <b401d2530901120326w671480dat10010f12309b3136@mail.gmail.com>

2009/1/12 Rakesh Pandit <rakesh.pandit at gmail.com>:
[..]
> and doing the build after commits? Not even importing the source for
> which fix was done ? why half work ?
>

Check cvs log sources file if interested.

-- 
rakesh



From christoph.wickert at googlemail.com  Mon Jan 12 11:33:32 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 12 Jan 2009 12:33:32 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
Message-ID: <1231760012.3571.3.camel@wicktop.localdomain>

Am Sonntag, den 09.11.2008, 02:44 +0530 schrieb Debarshi Ray:
> I would like to initiate the non-responsive maintainer policy [1]
> against Damien Durand (CC'ed). 
...
> 
> Here is another bug pending response for a long time:
> https://bugzilla.redhat.com/257721

And yet another one:
https://bugzilla.redhat.com/show_bug.cgi?id=449890
I have asked Damien for a reaction on December 19th 2008, but nothing
happened.

Christoph



From mschwendt at gmail.com  Mon Jan 12 11:39:53 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 12 Jan 2009 12:39:53 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
Message-ID: <20090112123953.d01ea744.mschwendt@gmail.com>

On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:

> But what prevents one to assigning bugs to himself before fixing it
> and doing the build after commits? Not even importing the source for
> which fix was done ? why half work ?

Can't answer that and don't want to guess. ;)


Let me point out the following, though:

This would be less of an issue, if the package had a maintainer instead of
a non-responsive one.

The FTBFS issue was reported on 2008-02-22 for a package with a Fedora 6
tag. The incomplete commit to fix it was done seven months later. The
ticket - https://bugzilla.redhat.com/434529 - was closed prior to 
waiting for the build results. Nobody has verified this, nobody
has reopened it. Yes, one can see the source tarball was missing.

The FTBFS issue was reported _another_ time for the same package id
on 2008-10-01 in a _new_ ticket: https://bugzilla.redhat.com/465075
That's the one you refer to.


Still, cvs commits can be completely unrelated to any open bugzilla
tickets. That's why it is important to be careful when committing changes
and not to ignore cvs' warnings about working-copies of files being older
than files in the cvs repository. It is really bad to not examine the
diffs painstakingly, but simply force changes into the repository.



From paul at all-the-johnsons.co.uk  Sun Jan 11 21:01:27 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 11 Jan 2009 21:01:27 +0000
Subject: Has koji gone tits up?
In-Reply-To: <20090111192029.e29154d6.mschwendt@gmail.com>
References: <1231634825.6159.15.camel@PB3.Linux>
	<6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
	<1231695288.18610.1.camel@PB3.Linux>
	<20090111192029.e29154d6.mschwendt@gmail.com>
Message-ID: <1231707687.18610.2.camel@PB3.Linux>

Hi,

> In build failure reports, koji sends many links to log files.
> And at the bottom, two links to the Task Info and Build Info pages.

mono-addins failed and koji sent this back...

mono-addins-0.4-3.fc11 (78071) failed on x86-2.fedora.phx.redhat.com
(i386), xenbuilder4.fedora.phx.redhat.com (noarch):
  BuildrootError: error building package (arch i386), mock exited with
status 1
SRPMS:
  mono-addins-0.4-3.fc11.src.rpm

Failed tasks:
-------------

Task 1045506 on x86-2.fedora.phx.redhat.com
Task Type: buildArch (mono-addins-0.4-3.fc11.src.rpm, i386)
logs:

http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=1045506 
http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=state.log

it looks like the & is not being added.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090111/e17c4762/attachment.sig>

From mschwendt at gmail.com  Mon Jan 12 12:10:12 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 12 Jan 2009 13:10:12 +0100
Subject: Has koji gone tits up?
In-Reply-To: <1231707687.18610.2.camel@PB3.Linux>
References: <1231634825.6159.15.camel@PB3.Linux>
	<6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
	<1231695288.18610.1.camel@PB3.Linux>
	<20090111192029.e29154d6.mschwendt@gmail.com>
	<1231707687.18610.2.camel@PB3.Linux>
Message-ID: <20090112131012.6e545433.mschwendt@gmail.com>

On Sun, 11 Jan 2009 21:01:27 +0000, Paul wrote:

> Hi,
> 
> > In build failure reports, koji sends many links to log files.
> > And at the bottom, two links to the Task Info and Build Info pages.
> 
> mono-addins failed and koji sent this back...

> Failed tasks:
> -------------
> 
> Task 1045506 on x86-2.fedora.phx.redhat.com
> Task Type: buildArch (mono-addins-0.4-3.fc11.src.rpm, i386)
> logs:
> 
> http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=build.log
> http://koji.fedoraproject.org/koji/getfile?taskID=1045506 
> http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=state.log
> 
> it looks like the & is not being added.

I doubt that. Unless it is a very recently introduced bug (i.e.  newer
than Dec 2008). All three URLs are wrong, because the 1st and 3rd is
missing the &. Some bad mail filter in your environment?

Normally, it gives links to the three logs:

  http://koji.fedoraproject.org/koji/getfile?taskID=1045506&name=build.log
  http://koji.fedoraproject.org/koji/getfile?taskID=1045506&name=root.log
  http://koji.fedoraproject.org/koji/getfile?taskID=1045506&name=state.log



From rakesh.pandit at gmail.com  Mon Jan 12 12:19:14 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 12 Jan 2009 17:49:14 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20090112123953.d01ea744.mschwendt@gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
Message-ID: <b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>

2009/1/12 Michael Schwendt <mschwendt at gmail.com>:
> On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:
>
>> But what prevents one to assigning bugs to himself before fixing it
>> and doing the build after commits? Not even importing the source for
>> which fix was done ? why half work ?
>
> Can't answer that and don't want to guess. ;)
>
>
> Let me point out the following, though:
>
> This would be less of an issue, if the package had a maintainer instead of
> a non-responsive one.
>

I request FISco member attention here.  The non-responsive maintainer
policy was initiated long ago here.

-- 
rakesh



From ghosler at redhat.com  Mon Jan 12 13:16:15 2009
From: ghosler at redhat.com (Gregory Hosler)
Date: Mon, 12 Jan 2009 21:16:15 +0800
Subject: how to make use of bug-buddy bugreport files ?
Message-ID: <496B429F.4050902@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

How do I, as a package developer/maintainer, make use of a bug-buddy bugreport.txt file ?

I'm old school, and can deal w/ core files just fine. I'm looking for some way to get
symbolic stack trace backs from bugreport.txt files.

Any documentation as to how the bugreport.txt file is intended to help developers?

urls/pointer to info/etc welcome.

All the best,

- -Greg

- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
		(from /var/log/Xorg.setup.log)

| Greg Hosler					ghosler at redhat.com    |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFJa0Kd404fl/0CV/QRAig5AJsHN0GkwWHiuFXUgJpBM/Q/loSyhwCeLt+a
I+vlSGWaEfRZvBHpoBl5gWU=
=cg0h
-----END PGP SIGNATURE-----



From paul at all-the-johnsons.co.uk  Mon Jan 12 13:59:11 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Mon, 12 Jan 2009 13:59:11 +0000
Subject: Has koji gone tits up?
In-Reply-To: <20090112131012.6e545433.mschwendt@gmail.com>
References: <1231634825.6159.15.camel@PB3.Linux>
	<6dc6523c0901101709j32325e24o107865d81995d3c1@mail.gmail.com>
	<1231695288.18610.1.camel@PB3.Linux>
	<20090111192029.e29154d6.mschwendt@gmail.com>
	<1231707687.18610.2.camel@PB3.Linux>
	<20090112131012.6e545433.mschwendt@gmail.com>
Message-ID: <1231768751.18610.3.camel@PB3.Linux>

Hi,

> > http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=build.log
> > http://koji.fedoraproject.org/koji/getfile?taskID=1045506 
> > http://koji.fedoraproject.org/koji/getfile?taskID=1045506name=state.log
> > 
> > it looks like the & is not being added.
> 
> I doubt that. Unless it is a very recently introduced bug (i.e.  newer
> than Dec 2008). All three URLs are wrong, because the 1st and 3rd is
> missing the &. Some bad mail filter in your environment?

Only filters I have are spam ones and that was a direct copy and paste
from the email koji emailed to me.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090112/0a2f660d/attachment.sig>

From mdehaan at redhat.com  Mon Jan 12 14:25:14 2009
From: mdehaan at redhat.com (Michael DeHaan)
Date: Mon, 12 Jan 2009 09:25:14 -0500
Subject: [et-mgmt-tools] Re: New Fedora virtualization list: fedora-virt
In-Reply-To: <20090111124719.GA27926@amd.home.annexia.org>
References: <20090109145050.GC9484@redhat.com> <4967A8EE.5090702@redhat.com>
	<20090111124719.GA27926@amd.home.annexia.org>
Message-ID: <496B52CA.1080007@redhat.com>

Richard W.M. Jones wrote:
> On Fri, Jan 09, 2009 at 02:43:42PM -0500, Michael DeHaan wrote:
>   
>> fedora-virt at redhat.com -- the new list
>>     
> [...]
>   
>> et-mgmt-tools at redhat.com -- virt-manager, virt-install, virsh, and  
>> related tools, also appliance build tools (thincrust) that target virt
>>     
>
> I think we should fold et-mgmt-tools into fedora-virt too.  The list
> has < 10 messages / day, and has a confusing name that superficially
> has nothing to do with virtualization unless you happen to know the
> history behind some Red Hat internal department.
>
> Rich.
>
>   
Yeah, I agree with moving this around (virt-tools sounds good).

Originally this list was started back when we just wanted a list for 
various systems management projects that our (Red Hat) group created, 
not really even being sure which ones would be ones we'd be spending 
time on (hence not wanting to pick a more specific name).  Then it 
became largely cobbler+virt-manager, then lots of other virt tools came 
along, and cobbler migrated to it's own list because it wasn't all virt 
related, so we're left with pretty much the assorted virt tools here.

This list becoming the hub for discussions around virt tooling seems to 
be good, and folks can come there with new virt ideas as well.

Make it so, #1?

--Michael






From loganjerry at gmail.com  Mon Jan 12 15:23:09 2009
From: loganjerry at gmail.com (Jerry James)
Date: Mon, 12 Jan 2009 08:23:09 -0700
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <20090111152759.GA8635@redhat.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
	<20090109200022.GA4271@redhat.com>
	<870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>
	<20090111152759.GA8635@redhat.com>
Message-ID: <870180fe0901120723q5a6a312cg89576180895b1d78@mail.gmail.com>

On Sun, Jan 11, 2009 at 8:28 AM, Deepak Bhole <dbhole at redhat.com> wrote:
> Hmm, I don't have a rawhide machine around atm, but I have never seen
> that before. Do you have another copy of (non-rpm) maven on the system?

No.  I did update with yum from F-10 instead of installing Rawhide
directly, because I was unable to get the installer to complete (see
https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00014.html).
 But I have not installed anything but Fedora packages on this
machine.  It looks to me like maven's command-line processing is
busted.
-- 
Jerry James
http://loganjerry.googlepages.com/



From sstarr at platform.com  Mon Jan 12 15:27:18 2009
From: sstarr at platform.com (Shawn Starr)
Date: Mon, 12 Jan 2009 10:27:18 -0500
Subject: Summary of the 2009-01-06 Packaging Committee meeting
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B06@catoexm05.noam.corp.platform.com>

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Doug Ledford
> Sent: Thursday, January 08, 2009 2:15 PM
> To: Development discussions related to Fedora
> Subject: Re: Summary of the 2009-01-06 Packaging Committee meeting
> 

< big snip > ...

> 
> True on both counts.  Of course, given clusters, totally irrelevant
> points.  They don't back up individual /etc directories on any of the
> cluster nodes.  All the nodes are set up so that they can be installed
> by the cluster manager, and they can be reinstalled as needed.  Nodes
> are disposable.  Also, they *do* mount /usr read-only in lots of
> clusters, and they couldn't care less that default files are in there.
> If they need to edit them, they go to the cluster disk controller node
> and edit it where it isn't read-only and then all the nodes see the
> changes.  More commonly, the batch scheduler they use has its own
> private data directory on the controlling node and it writes the
> necessary files on the fly (or passes the options entirely on the
> command line) based upon what nodes it intends to start the 
> job on.  My
> point is that these "we care about single node issues" simply do not
> exist in clusters, and *can't* exist or they make the cluster
> unmaintainable.
> 

This should be something the Fedora HPC SIG should be deciding. 
You and I both know installing multiple MPIs and other apps can make things a mess in a big hurry.

Shawn.

> -- 
> Doug Ledford <dledford at redhat.com>
>               GPG KeyID: CFBFF194
>               http://people.redhat.com/dledford
> 
> Infiniband specific RPMs available at
>               http://people.redhat.com/dledford/Infiniband
> 
> 



From itamar at ispbrasil.com.br  Mon Jan 12 18:32:18 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Mon, 12 Jan 2009 16:32:18 -0200
Subject: Becoming a Fedora Package Collection Sponsor
Message-ID: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>

Hello guy's

sometimes is very hard to find a sponsor,  and currently I don't know
if there are  some sponsor's  from Brazil

the Fedora Brazilian community is growing and will be good to have a
Brazilian sponsor.

I like to become a "Fedora Package Collection Sponsor" .

someone can point the right direction ?


------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From jamatos at fc.up.pt  Mon Jan 12 18:39:05 2009
From: jamatos at fc.up.pt (=?iso-8859-1?q?Jos=E9_Matos?=)
Date: Mon, 12 Jan 2009 18:39:05 +0000
Subject: Becoming a Fedora Package Collection Sponsor
In-Reply-To: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>
References: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>
Message-ID: <200901121839.06583.jamatos@fc.up.pt>

On Monday 12 January 2009 18:32:18 Itamar Reis Peixoto wrote:
> Hello guy's
>
> sometimes is very hard to find a sponsor,  and currently I don't know
> if there are  some sponsor's  from Brazil

Assuming that the language could be a barrier I think that being a sponsor I 
can help dealing with those issues.

> the Fedora Brazilian community is growing and will be good to have a
> Brazilian sponsor.
>
> I like to become a "Fedora Package Collection Sponsor" .
>
> someone can point the right direction ?
>
>
> ------------
>
> Itamar Reis Peixoto
>
> e-mail/msn: itamar at ispbrasil.com.br
> sip: itamar at ispbrasil.com.br
> skype: itamarjp
> icq: 81053601
> +55 11 4063 5033
> +55 34 3221 8599

-- 
Jos? Ab?lio



From bpepple at fedoraproject.org  Mon Jan 12 18:42:53 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 12 Jan 2009 13:42:53 -0500
Subject: Package Review Stats for the week ending January 11th, 2009
Message-ID: <1231785774.4953.18.camel@localhost.localdomain>

Top four  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending January 11th, 2009
were Manuel Wolfshant, Lubomir Rintel, Mamoru Tasaka, and Parag
AN(????).  Below is the number of package reviews completed.

manuel wolfshant - 15
Lubomir Rintel - 4
Mamoru Tasaka - 3
Parag AN(????) - 3
Fabian Affolter - 2
Marek Mahut - 2
Conrad Meyer - 1
Dan Hor?k - 1
Levente Farkas - 1
Lucian Langa - 1
Marcela Maslanova - 1
Michael Schwendt - 1
Nicolas Mailhot - 1
Orcan 'oget' Ogetbil - 1
Remi Collet - 1
Tim Lauridsen - 1
Tom "spot" Callaway - 1

Review Requests: 39
Merge Reviews: 1
Total Reviews Completed: 40

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090112/6ffdde52/attachment.sig>

From vonbrand at inf.utfsm.cl  Mon Jan 12 20:17:46 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 12 Jan 2009 17:17:46 -0300
Subject: Problems with X font handling
Message-ID: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>

Lots of X programs (xemacs, xlogo, xfig) complain of missing fonts (and end
up using some cheesy default font). I reported this originally against
xemacs (at 478999), and now changed it to xorg-x11 as I believe this is a
better match. xfontsel has only 4 fonts to exhibit now in all. This is
probably due to the ongoing font handling overhaul in rawhide.

In any case, could somebody knowledgeable on this point me (OK, make that
"handhold me") in the direction to fix this?
-- 
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 sgallagh at redhat.com  Mon Jan 12 20:28:50 2009
From: sgallagh at redhat.com (Stephen Gallagher)
Date: Mon, 12 Jan 2009 15:28:50 -0500
Subject: Problems with X font handling
In-Reply-To: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
Message-ID: <496BA802.2040607@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Horst H. von Brand wrote:
> Lots of X programs (xemacs, xlogo, xfig) complain of missing fonts (and end
> up using some cheesy default font). I reported this originally against
> xemacs (at 478999), and now changed it to xorg-x11 as I believe this is a
> better match. xfontsel has only 4 fonts to exhibit now in all. This is
> probably due to the ongoing font handling overhaul in rawhide.
> 
> In any case, could somebody knowledgeable on this point me (OK, make that
> "handhold me") in the direction to fix this?

I opened a similar bug:
https://bugzilla.redhat.com/show_bug.cgi?id=476531

It was fixed by adding xorg-x11-fonts-ISO8859-1-75dpi and
xorg-x11-fonts-ISO8859-1-100dpi to the "Requires:" list of the package
(in my case DDD).

I don't know the history on it, but I suspect that one or the other of
these two packages was once a part of the core Xorg packages and was
later broken out. Individual packages relying on these fonts were not
updated to be aware of the change.
- --

- --------------------
Stephen Gallagher
RHCE 804006346421761
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklrqAIACgkQeiVVYja6o6PPNQCdEb2rcT2BJKF9GZorDt7oxMTN
u8cAn3mHdgw2IxFzopT9qBMoL3xcjkzW
=GhAm
-----END PGP SIGNATURE-----



From nicolas.mailhot at laposte.net  Mon Jan 12 20:33:29 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Jan 2009 21:33:29 +0100
Subject: Problems with X font handling
In-Reply-To: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
Message-ID: <1231792409.9194.1.camel@arekh.okg>

Le lundi 12 janvier 2009 ? 17:17 -0300, Horst H. von Brand a ?crit :
> Lots of X programs (xemacs, xlogo, xfig) complain of missing fonts (and end
> up using some cheesy default font). I reported this originally against
> xemacs (at 478999), and now changed it to xorg-x11 as I believe this is a
> better match. xfontsel has only 4 fonts to exhibit now in all. This is
> probably due to the ongoing font handling overhaul in rawhide.

Not really, this is older and due to removal of all the legacy font
packages from the default install set. Apps that still need them need to
grow the associated deps.

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29#Fedora_fonts_are_broken_anyway.2C_my_application_crashes.21


-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090112/0c51f1cf/attachment.sig>

From fedora at camperquake.de  Mon Jan 12 20:40:36 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 12 Jan 2009 21:40:36 +0100
Subject: Problems with X font handling
In-Reply-To: <1231792409.9194.1.camel@arekh.okg>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<1231792409.9194.1.camel@arekh.okg>
Message-ID: <20090112214036.0c31e029@lain.camperquake.de>

Hi.

On Mon, 12 Jan 2009 21:33:29 +0100, Nicolas Mailhot wrote

> Not really, this is older and due to removal of all the legacy font
> packages from the default install set. Apps that still need them need
> to grow the associated deps.

No, the fonts themselves are still there, the applications don't see
them anymore, tough. This has happened during some update after F10 GA.



From nicolas.mailhot at laposte.net  Mon Jan 12 20:59:31 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 12 Jan 2009 21:59:31 +0100
Subject: Problems with X font handling
In-Reply-To: <20090112214036.0c31e029@lain.camperquake.de>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<1231792409.9194.1.camel@arekh.okg>
	<20090112214036.0c31e029@lain.camperquake.de>
Message-ID: <1231793971.10746.1.camel@arekh.okg>

Le lundi 12 janvier 2009 ? 21:40 +0100, Ralf Ertzinger a ?crit :
> Hi.
> 
> On Mon, 12 Jan 2009 21:33:29 +0100, Nicolas Mailhot wrote
> 
> > Not really, this is older and due to removal of all the legacy font
> > packages from the default install set. Apps that still need them need
> > to grow the associated deps.
> 
> No, the fonts themselves are still there, the applications don't see
> them anymore, tough. This has happened during some update after F10 GA.

Ah, then it's the usual core fonts brokeness which has existed for as
long as we used core fonts

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090112/f71db546/attachment.sig>

From roozbeh at gmail.com  Mon Jan 12 21:03:09 2009
From: roozbeh at gmail.com (Roozbeh Pournader)
Date: Mon, 12 Jan 2009 13:03:09 -0800
Subject: Orphaning gpsbabel
Message-ID: <e117404e0901121303j119d4936k666d16fe986c2df8@mail.gmail.com>

Hi all,

I am orphaning gpsbabel. silfreed has already accepted to take over.

roozbeh

PS: Sorry for being AWOL for so long. Some explanation here:

http://advogato.org/person/roozbeh/diary/152.html

I showed at FUDcon to get a handle on what's going on, and I'm going
over the list of my fedora/epel responsibilities and free whatever I
can't really do any more. Thanks a lot to everybody who took over
those when I could not do them.



From josef at toxicpanda.com  Mon Jan 12 21:16:56 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Mon, 12 Jan 2009 16:16:56 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
Message-ID: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>

Hello,

I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
the same for F-10 and F-9 shortly.  If you are using the rawhide
kernel then you will be able to test with the newly merged btrfs
filesystem.  All testing is greatly appreciated.  Here is a wiki page
which outlines some of the basic commands you can use with btrfs

http://btrfs.wiki.kernel.org/index.php/Getting_started

Btrfs has built in snapshotting, subvolumes and RAID support, so lots
of fun new things to tinker with.  A few disclaimers

1) Goes without saying, but this is a brand new filesystem that is not
finished yet, so treat it as if it would rather eat your hand than
keep your data
2) SELinux support is not quite there yet.  It does have xattr
support, and there is a patch available for support, but its not
upstream yet, so not in rawhide yet.
3) The disk format is not _supposed_ to change, but if there is some
major flaw found then it will change, so plan for the worst.
4) You cannot fill the disk about 85%.  This is not a bug, its a hard
limit, and on the TODO list to fix, do not be alarmed if it cuts out.

Please feel free to file a bugzilla if something goes horribly wrong,
stability and finishing out the remaining features is what our main
focus is now.  Thanks,

Josef



From zaitcev at redhat.com  Mon Jan 12 21:37:45 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Mon, 12 Jan 2009 14:37:45 -0700
Subject: Problems with X font handling
In-Reply-To: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
Message-ID: <20090112143745.853acd38.zaitcev@redhat.com>

On Mon, 12 Jan 2009 17:17:46 -0300, "Horst H. von Brand" <vonbrand at inf.utfsm.cl> wrote:

> Lots of X programs (xemacs, xlogo, xfig) complain of missing fonts (and end
> up using some cheesy default font). I reported this originally against
> xemacs (at 478999), and now changed it to xorg-x11 as I believe this is a
> better match. xfontsel has only 4 fonts to exhibit now in all. This is
> probably due to the ongoing font handling overhaul in rawhide.

Assuming you already verified that fonts are actually installed
please run the following test for me:

1. Log in
2. Open gnome-terminal
3. run xemacs and verify that it fails like you described
4. su, "service xfs restart"
5. run xemacs again

If it still fails on step 5, it's not bug 430416. If it starts working,
then the problem is that we fixed it in libraries somewhere (with
X server remaining broken), and perhaps your apps use old libraries.

Please let me know how it goes.

-- Pete



From christoph.wickert at googlemail.com  Tue Jan 13 00:16:16 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 13 Jan 2009 01:16:16 +0100
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <9497e9990901050450j2838e013ub29cec3702dfbb04@mail.gmail.com>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
	<9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
	<9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>
	<20090105120513.GA29438@srcf.ucam.org>
	<9497e9990901050450j2838e013ub29cec3702dfbb04@mail.gmail.com>
Message-ID: <1231805776.14501.20.camel@wicktop.localdomain>

Am Montag, den 05.01.2009, 12:50 +0000 schrieb Mat Booth:
> On Mon, Jan 5, 2009 at 12:05 PM, Matthew Garrett wrote:
> > On Sun, Jan 04, 2009 at 04:18:39PM +0000, Mat Booth wrote:
> >> Would I need to implement an input device driver to get it working?
> >
> > I believe that one's been implemented, but not merged.
> >
> 
> Aha, you are right. A quick search for "asus laptop" input patch
> yields this from our own Mr Wickert:
> 
> http://cwickert.fedorapeople.org/asus-laptop-add-input-events.patch

Just for the record: I didn't do the patch, it was Richard Hughes who
send it to me. Just want to make sure that he gets the credits!

> What is the prospect of getting this patch into the kernel? If it is
> need of some love, I am willing to help develop and test it.

Please contact Richard, he sent it to several kernel people as well as
to me, so he might know what their reaction was.

Regards,
Christoph




From christoph.wickert at googlemail.com  Tue Jan 13 00:21:22 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Tue, 13 Jan 2009 01:21:22 +0100
Subject: Asus Laptop Fn-Keys and HAL
In-Reply-To: <1231805776.14501.20.camel@wicktop.localdomain>
References: <9497e9990901040742m655a5774g27d2dbe35460401@mail.gmail.com>
	<9497e9990901040745j79656ad1s3675970ee069ad35@mail.gmail.com>
	<9497e9990901040818y561e6bb5l260815ec6e2c4d04@mail.gmail.com>
	<20090105120513.GA29438@srcf.ucam.org>
	<9497e9990901050450j2838e013ub29cec3702dfbb04@mail.gmail.com>
	<1231805776.14501.20.camel@wicktop.localdomain>
Message-ID: <1231806082.14501.23.camel@wicktop.localdomain>

Am Dienstag, den 13.01.2009, 01:16 +0100 schrieb Christoph Wickert:
> 
> Please contact Richard, he sent it to several kernel people as well as
> to me, so he might know what their reaction was.

As a follow-up to my previous message please read
http://blog.eikke.com/index.php/ikke/2007/08/15/asus_laptops_multimedia_keys_and_input

> Regards,
> Christoph




From silfreed at silfreed.net  Tue Jan 13 02:38:09 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Mon, 12 Jan 2009 21:38:09 -0500
Subject: Orphaning gpsbabel
In-Reply-To: <e117404e0901121303j119d4936k666d16fe986c2df8@mail.gmail.com>
References: <e117404e0901121303j119d4936k666d16fe986c2df8@mail.gmail.com>
Message-ID: <496BFE91.1060206@silfreed.net>

Roozbeh Pournader wrote:
> Hi all,
> 
> I am orphaning gpsbabel. silfreed has already accepted to take over.
> 

As Roozbeh stated, I've taken over gpsbabel.  Any co-maintainers are welcome.

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090112/5bce131f/attachment.sig>

From huzaifas at redhat.com  Tue Jan 13 03:02:33 2009
From: huzaifas at redhat.com (Huzaifa Sidhpurwala)
Date: Tue, 13 Jan 2009 08:32:33 +0530
Subject: request for maintaining EPECL5 branches
In-Reply-To: <b401d2530901102025w10c87fa2q6f47494575de6abc@mail.gmail.com>
References: <b401d2530901102025w10c87fa2q6f47494575de6abc@mail.gmail.com>
Message-ID: <496C0449.9050205@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rakesh Pandit wrote:
> Hello,
> 
> I had few pending requests for EPEL5. Anyone interested in maintaining
> EPEL5  branches for ntop and uriparser?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=476561 ntop (already
> branched needs an update)
> https://bugzilla.redhat.com/show_bug.cgi?id=479545 uriparser (need to
> create branch and do initial import)
> 
Will take both of them.



- --
Regards,
Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)


GnuPG Fingerprint:
3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFJbARJzHDc8tpb2uURAv6WAJ9vGWeFfNLkvvZilNAdiSH/Sti5PgCeL8nO
EZwD1xifS0xe6pDXRkpnmLI=
=t5Cx
-----END PGP SIGNATURE-----



From loganjerry at gmail.com  Tue Jan 13 04:19:35 2009
From: loganjerry at gmail.com (Jerry James)
Date: Mon, 12 Jan 2009 21:19:35 -0700
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <870180fe0901120723q5a6a312cg89576180895b1d78@mail.gmail.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
	<20090109200022.GA4271@redhat.com>
	<870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>
	<20090111152759.GA8635@redhat.com>
	<870180fe0901120723q5a6a312cg89576180895b1d78@mail.gmail.com>
Message-ID: <870180fe0901122019t1f41b71bw927ca2519f639e42@mail.gmail.com>

On Mon, Jan 12, 2009 at 8:23 AM, Jerry James <loganjerry at gmail.com> wrote:
> No.  I did update with yum from F-10 instead of installing Rawhide
> directly, because I was unable to get the installer to complete (see
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00014.html).
>  But I have not installed anything but Fedora packages on this
> machine.  It looks to me like maven's command-line processing is
> busted.

And I neglected to point out that I'm investigating this in the first
place because maven threw this error on the koji builders.  I believe
that rules out any strangeness on my machine being the cause.
-- 
Jerry James
http://loganjerry.googlepages.com/



From petersen at redhat.com  Tue Jan 13 04:55:57 2009
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 12 Jan 2009 23:55:57 -0500 (EST)
Subject: Fedora I18n project meeting
In-Reply-To: <564345480.455581231822058162.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1657069858.455861231822557540.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Hi,

We are going to do a fedora-i18n meeting next week. We haven't done one for a long time so a meeting around the F11 Alpha freeze seems like a good time.

2009-01-20 0500 UTC on #fedora-meeting at Freenode

More details and current agenda at https://fedoraproject.org/wiki/I18N/Meetings

Please add more items you have you would like to discuss.

Jens



From roozbeh at gmail.com  Tue Jan 13 06:50:17 2009
From: roozbeh at gmail.com (Roozbeh Pournader)
Date: Mon, 12 Jan 2009 22:50:17 -0800
Subject: orphaning perl-Math-Vec
Message-ID: <e117404e0901122250l4b539eafye8aa1eb8ca3929c8@mail.gmail.com>

Hi all,

I just orphaned perl-Math-Vec too. I used that as a part of
requirements for OpenStreetMap tools in Fedora, which I don't think I
would be using for quite a while. Feel free to take over.

I think that's all for now, I will try to take care of the rest of my
old packages.

Roozbeh



From sundaram at fedoraproject.org  Tue Jan 13 07:23:06 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 13 Jan 2009 12:53:06 +0530
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
Message-ID: <496C415A.1020100@fedoraproject.org>

Josef Bacik wrote:
> Hello,
> 
> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
> the same for F-10 and F-9 shortly.  If you are using the rawhide
> kernel then you will be able to test with the newly merged btrfs
> filesystem.  All testing is greatly appreciated.  Here is a wiki page
> which outlines some of the basic commands you can use with btrfs
> 
> http://btrfs.wiki.kernel.org/index.php/Getting_started
> 
> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
> of fun new things to tinker with.  

I know this is very early but just to get an idea of the status, has 
anyone looked into:

  * Anaconda support for Fedora 11
  * Simple home user backup that takes advantage of snapshots
  * RPM/Yum integration for rollbacks

Rahul



From roozbeh at gmail.com  Tue Jan 13 08:10:13 2009
From: roozbeh at gmail.com (Roozbeh Pournader)
Date: Tue, 13 Jan 2009 00:10:13 -0800
Subject: Looking for Fedora bugmasters
Message-ID: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>

I have been in an awkward situation for quite a while now: I created
the tracker bug for FE-NEEDSPONSOR three years ago (which made me its
reporter). Since then, I've been CC-ed on all the changes. I was
wondering who should I contact to change the "reporter" of the bug:

https://bugzilla.redhat.com/show_bug.cgi?id=177841

Or should I open a bug for that? If yes, in product/component?

roozbeh



From rawhide at fedoraproject.org  Tue Jan 13 08:15:06 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 13 Jan 2009 08:15:06 +0000 (UTC)
Subject: rawhide report: 20090113 changes
Message-ID: <20090113081506.781B11F825D@releng2.fedora.phx.redhat.com>

Compose started at Tue Jan 13 06:01:03 UTC 2009

New package SolarModel
        Real-time 3D Solar System simulation
New package chipmunk
        Physics engine for 2D games
New package guiloader-c++
        C++ Binding to GuiLoader Library
New package irrlicht
        A high performance realtime 3D engine
New package perl-Catalyst-Authentication-Store-DBIx-Class
        A storage class for Catalyst Authentication using DBIx::Class
New package perl-Catalyst-Plugin-Authorization-ACL
        ACL Support for Catalyst Applications
New package perl-Class-Throwable
        A minimal lightweight exception class
New package perl-Test-NeedsDisplay
        Ensure that tests needing a display have one
New package python-progressbar
        Text progressbar library for python
New package tcl-zlib
        Tcl extension for zlib support
Updated Packages:

audio-convert-mod-3.45.5-1.fc11
-------------------------------
* Mon Jan 12 17:00:00 2009 Stewart Adam <s.adam at diffingo.com> - 3.45.5-1
- Update to 3.45.5 (see ChangeLog for details on version changes)
- Add BR on autoconf
- Require libmp4v2 for AAC tagging, id3lib for MP3 tagging and notify-python
- Add %check section


barry-0.15-0.3.20090109git.fc11
-------------------------------
* Mon Jan 12 17:00:00 2009 Christopher D. Stover <quantumburnz at hotmail.com> 0.15-0.3.20090109git
- version bump for proper patch name

* Mon Jan 12 17:00:00 2009 Christopher D. Stover <quantumburnz at hotmail.com> 0.15-0.2.20090109git
- enable fuse module during build
- include ip_modem password patch for the Blackberry Bold 9000

* Mon Jan 12 17:00:00 2009 Christopher D. Stover <quantumburnz at hotmail.com> 0.15-0.1.20090109git
- version/git bump


bibus-1.4.3.1-2.fc11
--------------------
* Mon Jan 12 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.4.3.1-2
- Fix paths to openoffice (#479099)


boost-1.37.0-3.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Petr Machata <pmachata at redhat.com> - 1.37.0-3
- Apply a unneccessary_iostreams patch from Caolan McNamara
- Fix soname patch so that it applies with fuzz=0.  Use fuzz=0 option
  in spec file just like ordinary patches do.
- Resolves: #479409


btrfs-progs-0.17-2.fc11
-----------------------
* Mon Jan 12 17:00:00 2009 Josef Bacik <josef at toxicpanda.com> 0.17-2
- fixed wrong sources upload

* Mon Jan 12 17:00:00 2009 Josef Bacik <josef at toxicpanda.com> 0.17
- Upstream release 0.17


cluster-3.0.0-2.alpha2.fc11
---------------------------
* Mon Jan 12 17:00:00 2009 Fabio M. Di Nitto <fdinitto at redhat.com> - 3.0.0-2.alpha2
- New upstream release (retag cvs package)

* Mon Jan 12 17:00:00 2009 Fabio M. Di Nitto <fdinitto at redhat.com> - 3.0.0-1.alpha2
- New upstream release


cpan2rpm-2.028-4.fc11
---------------------
* Mon Jan 12 17:00:00 2009 Stepan Kasal <skasal at redhat.com> - 2.028-4
- ... and fix patch0 so that it applies with no fuzz.

* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.028-3
- Fix Patch0:/%patch mismatch.


deluge-1.1.0-1.fc11
-------------------
* Sun Jan 11 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 1.1.0-1
- Update to new upstream release (1.1.0 Final - yay!)
- Drop the get_tracker_host patch (fixed upstream):
  - fix-get_tracker-host-if-no-tracker.patch


digikam-0.10.0-0.13.beta8.fc11
------------------------------
* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.10-0.13.beta8
- re-enable marble integration, kde42+ (bug #470578)


ecryptfs-utils-68-0.fc11
------------------------
* Mon Jan 12 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> 68-0
- updated to 68
- fix #478464 - /usr/bin/ecryptfs-setup-private errors out


file-4.26-8.fc11
----------------
* Mon Jan 12 17:00:00 2009 Daniel Novotny <dnovotny at redhat.com> 4.26-8
- fix #479300 - add btrfs filesystem magic


foomatic-3.0.2-70.fc11
----------------------
* Mon Jan 12 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 3.0.2-70
- Major gutenprint version is 5.2.


fribidi-0.19.1-3.fc11
---------------------
* Mon Jan 12 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.19.1-3
- rebuild to get provides pkgconfig(fribidi)


gegl-0.0.22-1.fc11
------------------
* Tue Jan 13 17:00:00 2009 Deji Akingunola <dakingun at gmail.com> - 0.0.22-1
- Update to version 0.0.22


gnome-scan-0.6.1-1.fc11
-----------------------
* Tue Jan 13 17:00:00 2009 Deji Akingunola <dakingun at gmail.com> - 0.6.1-1
- Update to version 0.6.1


goffice-0.6.5-2.fc11
--------------------
* Mon Jan 12 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.6.5-2
- rebuild to get provides pkgconfig(libgoffice-0.4) >= 0:0.4.0


goffice04-0.4.3-3.fc11
----------------------

gvfs-1.1.3-3.fc11
-----------------
* Mon Jan 12 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 1.1.3-3
- Fix dav+sd.mount


hplip-2.8.12-2.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 2.8.12-2
- Don't write to system-wide configuration file (bug #479178).


iproute-2.6.27-2.fc11
---------------------
* Mon Jan 12 17:00:00 2009 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 2.6.27-2
- 475130 - Negative preferred lifetimes of IPv6 prefixes/addresses
  displayed incorrectly
- 472878 - ???ip maddr show??? in IB interface causes a stack corruption
- both patches will be probably in iproute v2.6.28


jfsutils-1.1.13-1
-----------------
* Tue Jan 13 17:00:00 2009 Josh Boyer <jwboyer at gmail.com> - 1.1.13-1
- Update to latest release (bug 479565)


kawa-1.9.1-7.fc11
-----------------
* Mon Jan 12 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1:1.9.1-7
- Requires in -javadoc subpackage needs epoch


kbd-1.15-2.fc11
---------------
* Mon Jan 12 17:00:00 2009 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.15-2
- Move loadkeys to /bin


kdeedu-4.1.96-4.fc11
--------------------
* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-4
- drop extraneous giflib pcre deps

* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-3
- sane marble packaging (#470577)
- use system dustismo-roman font (#477406)


kdelibs-4.1.96-7.fc11
---------------------
* Mon Jan 12 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-6
- fix a crash (appearing in KSMServer)

* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.1.96-7
- Slight speedup to profile.d/kde.sh (#465370)
- (Build)Req: strigi(-devel) >= 0.6.3


kdenetwork-4.1.96-2.fc11
------------------------
* Mon Jan 12 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-2
- build against system libgadu (trivial patch backported from 4.3)


kernel-2.6.29-0.31.rc1.git2.fc11
--------------------------------
* Mon Jan 12 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc1-git2

* Mon Jan 12 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc1-git1

* Mon Jan 12 17:00:00 2009 Adam Jackson <ajax at redhat.com>
- Define %fedora_build a different (faster) way.


kscope-1.9.0-1.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.9.0-1
- update to 1.9.0, no longer depends on kde
- license change to GPLv2+


libical-0.43-1.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 0.43-1
- Version bump to 0.43.
- Added patch to fix implicit pointer conversion from Debian. Fixes Debian BTS
  bug #511598.
- Upstream has switched off ICAL_ERRORS_ARE_FATAL by default. This behaviour
  is being retained across all distributions, including Fedora 11.
- Added 'Requires: tzdata'.
- Enabled backtrace dumps in the syslog.


libnasl-2.2.11-3.fc11
---------------------
* Mon Jan 12 17:00:00 2009 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de>
- 2.2.11-3
- fix #479655


libnetfilter_conntrack-0.0.99-1.fc11
------------------------------------
* Tue Jan 13 17:00:00 2009 Paul P. Komkoff Jr <i at stingr.net> - 0.0.99-1
- new upstream version


libopensync-plugin-python-0.36-3.fc11
-------------------------------------
* Mon Jan 12 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.36-3
- Copy patch from libopensync, which is the same as upstream changeset
  for Python 2.6 (http://www.opensync.org/changeset/4383)

* Sun Nov 30 17:00:00 2008 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> - 0.36-2
- Rebuild for Python 2.6


libsemanage-2.0.30-3.fc11
-------------------------
* Mon Jan 12 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.0.30-3
- Fix up patch to get it upstreamed


lincity-ng-1.97-0.2.beta.fc11
-----------------------------
* Mon Jan 12 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.97-0.2.beta
- do not bundle font in data subpackage, use symlink and Requires: dejavu-fonts-sans


mlocate-0.21.1-3
----------------
* Mon Jan 12 17:00:00 2009 Miloslav Trma?? <mitr at redhat.com> - 0.21.1-3
- Merge review fixes, based on a patch by Parag AN:
  - Use %{_localstatedir}/lib instead of hard-coding /var/lib
  - Use %{?_smp_mflags}
  - Preserve file time stamps
  - Only create the group if it doesn't exist, hide errors from rpm


mtools-4.0.0-2.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Adam Tkac <atkac redhat com> 4.0.0-2
- don't ship infodir/dir.gz (#478322)


munin-1.2.6-6.fc11
------------------
* Mon Jan 12 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.6-6
- Fix to require the correct font


nted-1.4.17-2.fc11
------------------
* Sun Jan 11 17:00:00 2009 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.17-2
- remove unneeded fontconfig hooks from spec

* Sun Jan 11 17:00:00 2009 Hans Ulrich Niedermann <hun at n-dimensional.de> - 1.4.17-1.1
- remove wrongly encoded german description
- use new font packaging rules
- split ntedfont.pfa into nted-fonts subpackage


openoffice.org-3.0.1-15.1.fc11
------------------------------
* Mon Jan 12 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-15.1
- next milestone
- rename openoffice.org-3.0.0.ooo90072.sw.undo-longtext.patch to 
  upstream workspace.sw31bf02.patch
- Resolves: rhbz#477880 add openoffice.org-3.0.1.ooo97975.bridges.mainalreadyexited.patch

* Wed Jan  7 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-14.4
- add hyphen-el, hyphen-es


perl-AnyEvent-4.331-1.fc11
--------------------------
* Mon Jan 12 17:00:00 2009 kwizart < kwizart at gmail.com > - 4.331-1
- Update to 4.331   (rpm version : same )


perl-BSD-Resource-1.28-7.fc11
-----------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.28-7
- Fix Patch0:/%patch mismatch.


perl-JSON-Any-1.16-4.fc11
-------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.16-4
- Fix Patch:/%patch0 mismatch.


perl-ORLite-1.17-1.fc11
-----------------------
* Mon Jan 12 17:00:00 2009 Marcela Ma??l????ov?? <mmaslano at redhat.com> 1.17-1
- update to 1.17


php-ZendFramework-1.7.2-4.fc11
------------------------------
* Mon Jan 12 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.7.2-4
- Fix Requires, BuildRequires: bitstream-vera-fonts-{sans,sans-mono,serif}
  fixes broken deps


pidgin-2.5.4-1.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Stu Tomlinson <stu at nosnilmot.com> 2.5.4-1
- 2.5.4


poppler-0.10.3-1.fc11
---------------------
* Tue Jan 13 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 0.10.3-1
- Update to 0.10.3


python-BeautifulSoup-3.1.0.1-2.fc11
-----------------------------------
* Mon Jan 12 17:00:00 2009 kwizart < kwizart at gmail.com > - 3.1.0.1-2
- Fix installed files.

* Mon Jan 12 17:00:00 2009 kwizart < kwizart at gmail.com > - 3.1.0.1-1
- Update to 3.1.0.1


python-twyt-0.9.0-1.fc11
------------------------
* Sun Jan 11 17:00:00 2009 Andy Price <andy at andrewprice.me.uk> - 0.9.0-1
- Updated to 0.9.0
- Install HOWTO doc file instead of GUIHOWTO


qt-4.4.3-10.fc11
----------------
* Mon Jan 12 17:00:00 2009 Than Ngo <than at redhat.com> - 4.4.3-9
- qt-copy-patches-20090112

* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.4.3-10
- drop qt-x11-opensource-src-4.3.4-no-hardcoded-font-aliases.patch (#447298),
  in favor of qt-copy's 0263-fix-fontconfig-handling.diff


quilt-0.47-2.fc11
-----------------
* Tue Jan 13 17:00:00 2009 - jwboyer at gmail.com - 0.47-2
- Fix 'quilt setup' for rpm 4.6 (bug 473557)


samyak-fonts-1.2.1-2.fc11
-------------------------
* Mon Jan 12 17:00:00 2009 Pravin Satpute <psatpute at redhat.com> 1.2.1-2
- bugzilla 477451
- updated spec


selinux-policy-3.6.2-3.fc11
---------------------------
* Thu Jan  8 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.2-3
- Allow cups_pdf_t write to nfs_t


sos-1.8-6.fc11
--------------
* Mon Jan 12 17:00:00 2009 Adam Stokes <ajs at redhat dot com> - 1.8-6
- updated spec to include setuptools/egg file

* Mon Dec 29 17:00:00 2008 Adam Stokes <ajs at redhat dot com> - 1.8-5
- removed source defines as python manifest handles this

* Fri Dec 19 17:00:00 2008 Adam Stokes <ajs at redhat dot com> - 1.8-4
- spec cleanup, fixed license, source
- reworked Makefile to build properly


squashfs-tools-4.0-0.20090112
-----------------------------
* Mon Jan 12 17:00:00 2009 <katzj at redhat.com> - 4.0-0.20090112
- update to cvs snap that generates v4.0 images


strigi-0.6.3-1.fc11
-------------------
* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.6.3-1
- strigi-0.6.3


telepathy-glib-0.7.21-1.fc11
----------------------------
* Mon Jan 12 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.21-1
- Update to 0.7.21.


tetex-font-cm-lgc-0.5-11.fc11
-----------------------------
* Mon Jan 12 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.5-11
- Restructure spec file according to
  https://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes
  (bug #477461)
- Split package to cm-lgc-fonts (.pfb and .afm) and tetex-font-cm-lgc 
  (TeX stuff)
- Include .afm files (forgotten in the previous versions)


tetex-font-kerkis-2.0-16.fc11
-----------------------------
* Mon Jan 12 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 2.0-16
- Restructure spec file according to
  https://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes
  (bug #477462)
- Split package to cm-lgc-fonts (.pfb and .afm) and tetex-font-cm-lgc
  (TeX stuff)
- Include .afm files (forgotten in the previous versions)


tqsllib-2.0-5.fc11
------------------
* Mon Jan 12 17:00:00 2009 Lucian Langa <cooly at gnome.eu.org> - 2.0-5
- modify patch0 to include fix for #479650 (CVE-2008-5077 related)


uw-imap-2007e-3.fc11
--------------------
* Mon Jan 12 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2007e-3
- main/-utils: +Req: %imap_libs = %version-%release


wmx-7-1.fc11
------------
* Sat Jan 10 17:00:00 2009 Gabriel Somlo <somlo at cmu.edu> 7-1
- update to 7


words-3.0-14.fc11
-----------------
* Mon Jan 12 17:00:00 2009 Karel Zak <kzak at redhat.com> - 3.0-14
- fix #457309 - contains both 'unnecessary' and 'unneccesary'
- fix #470921 -"Barack" and "Obama" are not in /usr/share/dict/words
- update spec file (#226542 - Merge Review)


wv-1.2.4-5.fc11
---------------
* Mon Jan 12 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1.2.4-5
- rebuild to get provides pkgconfig(wv-1.0) >= 0:1.2.0


xorg-x11-drv-evdev-2.1.1-1.fc11
-------------------------------
* Tue Jan 13 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 2.1.1-1
- evdev 2.1.1
- update Requires to 1.5.99.1 to make sure the ABI is right.


xorg-x11-server-1.5.99.901-1.fc11
---------------------------------
* Tue Jan 13 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 1.5.99.901-1
- xserver 1.6 RC 1
- fix "git-xyz" to "git xyz"
- revert yesterdays changes to make-git-snapshot.sh, that was a bad idea.


Summary:
Added Packages: 10
Removed Packages: 0
Modified Packages: 65
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.i386 requires libsgdebug-1.0.0.so
	goffice-devel-0.6.5-2.fc11.i386 requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.i386 requires pkgconfig(libart-2.0)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.i386 requires pkgconfig(libnfnetlink)
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pywbxml-0.1-3.fc9.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.x86_64 requires libsgdebug-1.0.0.so()(64bit)
	goffice-devel-0.6.5-2.fc11.i386 requires pkgconfig(libart-2.0)
	goffice-devel-0.6.5-2.fc11.x86_64 requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.i386 requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.x86_64 requires pkgconfig(libart-2.0)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.i386 requires pkgconfig(libnfnetlink)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.x86_64 requires pkgconfig(libnfnetlink)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.i386 requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pywbxml-0.1-3.fc9.x86_64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.i386 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.x86_64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.i386 requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.i386 requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.x86_64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgserial-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgscreen-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmisc-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgmagvar-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgio-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgtiming-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgbucket-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgxml-1.0.0.so
	fgfs-Atlas-0.3.1-9.fc10.ppc requires libsgdebug-1.0.0.so
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	goffice-devel-0.6.5-2.fc11.ppc requires pkgconfig(libart-2.0)
	goffice-devel-0.6.5-2.fc11.ppc64 requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.ppc requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.ppc64 requires pkgconfig(libart-2.0)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.ppc requires pkgconfig(libnfnetlink)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.ppc64 requires pkgconfig(libnfnetlink)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	opal-3.4.2-2.fc11.ppc requires libpt.so.2.4.2
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pywbxml-0.1-3.fc9.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidc-perftest-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_program_options.so.3
	qpidd-0.4.728142-1.fc10.ppc requires libboost_filesystem.so.3
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgbucket-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmisc-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgtiming-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgxml-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgmagvar-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgscreen-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgserial-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgio-1.0.0.so()(64bit)
	fgfs-Atlas-0.3.1-9.fc10.ppc64 requires libsgdebug-1.0.0.so()(64bit)
	goffice-devel-0.6.5-2.fc11.ppc64 requires pkgconfig(libart-2.0)
	goffice04-devel-0.4.3-3.fc11.ppc64 requires pkgconfig(libart-2.0)
	libnetfilter_conntrack-devel-0.0.99-1.fc11.ppc64 requires pkgconfig(libnfnetlink)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	opal-3.4.2-2.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pywbxml-0.1-3.fc9.ppc64 requires python(abi) = 0:2.5
	qmf-devel-0.4.728142-1.fc10.ppc64 requires python(abi) = 0:2.5
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidc-perftest-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_program_options.so.3()(64bit)
	qpidd-0.4.728142-1.fc10.ppc64 requires libboost_filesystem.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From mschwendt at gmail.com  Tue Jan 13 08:37:50 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 13 Jan 2009 09:37:50 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
Message-ID: <20090113093750.192007a4.mschwendt@gmail.com>

On Mon, 12 Jan 2009 17:49:14 +0530, Rakesh wrote:

> > On Mon, 12 Jan 2009 16:34:45 +0530, Rakesh wrote:
> >
> >> But what prevents one to assigning bugs to himself before fixing it
> >> and doing the build after commits? Not even importing the source for
> >> which fix was done ? why half work ?
> >
> > Can't answer that and don't want to guess. ;)
> >
> >
> > Let me point out the following, though:
> >
> > This would be less of an issue, if the package had a maintainer instead of
> > a non-responsive one.
> >
> 
> I request FISco member attention here.  The non-responsive maintainer
> policy was initiated long ago here.
 
It might be that the Wiki explains how to contact FESCo.

Meanwhile it would be nice if you reverted the changes in cvs.
Some of them are confusing, such as the GPL+ -> GPLv2 change,
which is not explained in the spec/changelog, or the duplicate
directory inclusion.



From pbrobinson at gmail.com  Tue Jan 13 08:54:04 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 13 Jan 2009 09:54:04 +0100
Subject: chain build for Fedora 10 (ie non rawhide)
Message-ID: <5256d0b0901130054r1c1613a3kd241b1ba2f18b04a@mail.gmail.com>

What is the equivalent way of doing a chain build for a non rawhide
build. I have a couple (well 3 actually) of packages that have a
bugfix release that are dependant on the build so I wanted to build
them all together so I can push them to updates-testing all together
so as no dep issues occur. What's the best way to do that?

Packages in destination tag dist-f10-updates-candidate are not
inherited by build tag dist-f10-build
Target dist-f10-updates-candidate is not usable for a chain-build
make: *** [chain-build] Error 1

Regards,
Peter



From rakesh.pandit at gmail.com  Tue Jan 13 08:59:17 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 13 Jan 2009 14:29:17 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20090113093750.192007a4.mschwendt@gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
Message-ID: <b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>

2009/1/13 Michael Schwendt <mschwendt at gmail.com>:
[..]
>>
>> I request FISco member attention here.  The non-responsive maintainer
>> policy was initiated long ago here.
>
> It might be that the Wiki explains how to contact FESCo.
>

Well this thread already is part of process.

> Meanwhile it would be nice if you reverted the changes in cvs.
> Some of them are confusing, such as the GPL+ -> GPLv2 change,
> which is not explained in the spec/changelog, or the duplicate
> directory inclusion.
>

* Sun Jan 11 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-1
- Updated to 0.8.1, fixed .desktop file and license tag.
- Fixed Unowned directories.

It is mentioned. I don't see a point in reverting, but feel free to
revert if you think it is worth.

-- 
rakesh



From mschwendt at gmail.com  Tue Jan 13 09:21:14 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 13 Jan 2009 10:21:14 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
Message-ID: <20090113102114.ac8f643c.mschwendt@gmail.com>

On Tue, 13 Jan 2009 14:29:17 +0530, Rakesh wrote:

> [..]
> >>
> >> I request FISco member attention here.  The non-responsive maintainer
> >> policy was initiated long ago here.
> >
> > It might be that the Wiki explains how to contact FESCo.
> >
> 
> Well this thread already is part of process.
> 
> > Meanwhile it would be nice if you reverted the changes in cvs.
> > Some of them are confusing, such as the GPL+ -> GPLv2 change,
> > which is not explained in the spec/changelog, or the duplicate
> > directory inclusion.
> >
> 
> * Sun Jan 11 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-1
> - Updated to 0.8.1, fixed .desktop file and license tag.
> - Fixed Unowned directories.
> 
> It is mentioned. I don't see a point in reverting, but feel free to
> revert if you think it is worth.

I won't touch spec files which are overwritten randomly.

The changelog entry is poor, because it's incomplete. It says "fixed
license tag" without giving a rationale. It doesn't explain what was wrong
about the previous license tag. And it doesn't mention what the tag was
changed to. You simply discarded (= overwrote) the old comment that
explained the previous license tag.

According to https://fedoraproject.org/wiki/Licensing#Good_Licenses
the previous tag was correct.

> %dir %{_datadir}/%{name}
> %{_datadir}/%{name}/

The %dir entry is superfluous.



From drago01 at gmail.com  Tue Jan 13 09:23:32 2009
From: drago01 at gmail.com (drago01)
Date: Tue, 13 Jan 2009 10:23:32 +0100
Subject: chain build for Fedora 10 (ie non rawhide)
In-Reply-To: <5256d0b0901130054r1c1613a3kd241b1ba2f18b04a@mail.gmail.com>
References: <5256d0b0901130054r1c1613a3kd241b1ba2f18b04a@mail.gmail.com>
Message-ID: <f6ca9fed0901130123yd7313d5jefa11b90fcbd8866@mail.gmail.com>

On Tue, Jan 13, 2009 at 9:54 AM, Peter Robinson <pbrobinson at gmail.com> wrote:
> What is the equivalent way of doing a chain build for a non rawhide
> build. I have a couple (well 3 actually) of packages that have a
> bugfix release that are dependant on the build so I wanted to build
> them all together so I can push them to updates-testing all together
> so as no dep issues occur. What's the best way to do that?
>
> Packages in destination tag dist-f10-updates-candidate are not
> inherited by build tag dist-f10-build
> Target dist-f10-updates-candidate is not usable for a chain-build
> make: *** [chain-build] Error 1

You have to build one package, request rel-eng to tag it [1] into the
buildroot, build the next package and so on.
When you are done push them as a single update in bodhi.

1: https://fedorahosted.org/rel-eng/newticket
(make sure to include the full n-v-r of the package you want to be tagged)



From rakesh.pandit at gmail.com  Tue Jan 13 09:43:17 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 13 Jan 2009 15:13:17 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20090113102114.ac8f643c.mschwendt@gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<20090113102114.ac8f643c.mschwendt@gmail.com>
Message-ID: <b401d2530901130143r647c1335n7157972e3ba9d8ec@mail.gmail.com>

"""
> But what prevents one to assigning bugs to himself before fixing it
> and doing the build after commits? Not even importing the source for
> which fix was done ? why half work ?

Can't answer that and don't want to guess. ;)
""""

This was shit which made me slip.

Well when one (here me) slips on someone's shit, s/he is bound to be a
culprit of making the place bad and making more mistakes.

Reverting.

-- 
rakesh



From mschwendt at gmail.com  Tue Jan 13 11:18:22 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 13 Jan 2009 12:18:22 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901130143r647c1335n7157972e3ba9d8ec@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<20090113102114.ac8f643c.mschwendt@gmail.com>
	<b401d2530901130143r647c1335n7157972e3ba9d8ec@mail.gmail.com>
Message-ID: <20090113121822.e226354e.mschwendt@gmail.com>

On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:

> """
> > But what prevents one to assigning bugs to himself before fixing it
> > and doing the build after commits? Not even importing the source for
> > which fix was done ? why half work ?
> """"
> 
> This was shit which made me slip.

Well, at least the files in cvs were tagged properly.
You somehow managed to ignore that and started with a lower %release:

symbolic names:
        gdmap-0_8_1-3_fc11: 1.12
        gdmap-0_8_1-1_fc11: 1.10

      ^-- these are your tags

        gdmap-0_8_1-2_fc11: 1.9
        F-10-split: 1.8
        gdmap-0_8_1-1_fc10: 1.8
        gdmap-0_7_5-8_fc10: 1.7
        F-9-split: 1.5
        gdmap-0_7_5-7_fc9: 1.5

 
> Well when one (here me) slips on someone's shit, s/he is bound to be a
> culprit of making the place bad and making more mistakes.
> 
> Reverting.

The thing that bugs me is that you try to blame other people in
justification of your own mistakes. In the original post, and also in the
private messages. Okay, Matt forgot to commit the source, most likely
while committing fixes for other build failures. So what? If the package
had a maintainer, he would notice the build failure and fix this small
mistake. The pkg is orphaned, however.

Current status of gdmap in cvs now is that on three branches, %version and
%release values in the spec have been decreased and are lower than latest
tag. Whoever will touch the pkg next will probably run into this trap and
then need to examine the tags. And the desktop file patch is missing, too.

I mean, if you want to take over maintainership of gdmap, just apply
for ownership in pkgdb and fix the package finally. If you don't want
ownership, changes ought to be only minor.



From rakesh.pandit at gmail.com  Tue Jan 13 12:06:59 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 13 Jan 2009 17:36:59 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <20090113121822.e226354e.mschwendt@gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<20090113102114.ac8f643c.mschwendt@gmail.com>
	<b401d2530901130143r647c1335n7157972e3ba9d8ec@mail.gmail.com>
	<20090113121822.e226354e.mschwendt@gmail.com>
Message-ID: <b401d2530901130406u64373053n5c2dedbab493d5bd@mail.gmail.com>

2009/1/13 Michael Schwendt <mschwendt at gmail.com>:
> On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:
>
[..]
>
> The thing that bugs me is that you try to blame other people in
> justification of your own mistakes. In the original post, and also in the
> private messages. Okay, Matt forgot to commit the source, most likely
> while committing fixes for other build failures. So what? If the package
> had a maintainer, he would notice the build failure and fix this small
> mistake. The pkg is orphaned, however.
>

Well I have already agreed of using old working copy and not checking
diffs painstakingly. Between your commit in devel also ignored source
import and build. You had updated to new version and didn't bothered
to update the source and support your statement with a false argument
that "if it had a maintainer". Package should not be left it that
state.

> Current status of gdmap in cvs now is that on three branches, %version and
> %release values in the spec have been decreased and are lower than latest
> tag. Whoever will touch the pkg next will probably run into this trap and
> then need to examine the tags. And the desktop file patch is missing, too.
>

I am getting back the dead file and doing the fix. Give me some breath.

-- 
rakesh



From jwboyer at gmail.com  Tue Jan 13 12:31:59 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 13 Jan 2009 07:31:59 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <496C415A.1020100@fedoraproject.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<496C415A.1020100@fedoraproject.org>
Message-ID: <20090113123159.GA2456@yoda.jdub.homelinux.org>

On Tue, Jan 13, 2009 at 12:53:06PM +0530, Rahul Sundaram wrote:
> Josef Bacik wrote:
>> Hello,
>>
>> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
>> the same for F-10 and F-9 shortly.  If you are using the rawhide
>> kernel then you will be able to test with the newly merged btrfs
>> filesystem.  All testing is greatly appreciated.  Here is a wiki page
>> which outlines some of the basic commands you can use with btrfs
>>
>> http://btrfs.wiki.kernel.org/index.php/Getting_started
>>
>> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
>> of fun new things to tinker with.  
>
> I know this is very early but just to get an idea of the status, has  
> anyone looked into:
>
>  * Anaconda support for Fedora 11

There was an Anaconda session at FUDCon.  This wasn't mentioned at all.
I think there are enough things to do for F11 at the moment, and given
that btrfs isn't even in a stable release yet it's probably premature
to talk about supporting it for installs.

>  * Simple home user backup that takes advantage of snapshots
>  * RPM/Yum integration for rollbacks

All of these seem like F12 topics to me.

josh



From josef at toxicpanda.com  Tue Jan 13 12:46:06 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Tue, 13 Jan 2009 07:46:06 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <20090113123159.GA2456@yoda.jdub.homelinux.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<496C415A.1020100@fedoraproject.org>
	<20090113123159.GA2456@yoda.jdub.homelinux.org>
Message-ID: <1b7401870901130446w32706564ta935b7ded19f3596@mail.gmail.com>

On Tue, Jan 13, 2009 at 7:31 AM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Tue, Jan 13, 2009 at 12:53:06PM +0530, Rahul Sundaram wrote:
>> Josef Bacik wrote:
>>> Hello,
>>>
>>> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
>>> the same for F-10 and F-9 shortly.  If you are using the rawhide
>>> kernel then you will be able to test with the newly merged btrfs
>>> filesystem.  All testing is greatly appreciated.  Here is a wiki page
>>> which outlines some of the basic commands you can use with btrfs
>>>
>>> http://btrfs.wiki.kernel.org/index.php/Getting_started
>>>
>>> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
>>> of fun new things to tinker with.
>>
>> I know this is very early but just to get an idea of the status, has
>> anyone looked into:
>>
>>  * Anaconda support for Fedora 11
>
> There was an Anaconda session at FUDCon.  This wasn't mentioned at all.
> I think there are enough things to do for F11 at the moment, and given
> that btrfs isn't even in a stable release yet it's probably premature
> to talk about supporting it for installs.
>

Eric has sent along an anaconda patch.  The thinking is that there
will be some magic incantation to turn it on for F11, kind of like
linux iamanext4developer when ext4 wasn't quite ready.  Thanks,

Josef



From mschwendt at gmail.com  Tue Jan 13 12:50:18 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 13 Jan 2009 13:50:18 +0100
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901130406u64373053n5c2dedbab493d5bd@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<20090113102114.ac8f643c.mschwendt@gmail.com>
	<b401d2530901130143r647c1335n7157972e3ba9d8ec@mail.gmail.com>
	<20090113121822.e226354e.mschwendt@gmail.com>
	<b401d2530901130406u64373053n5c2dedbab493d5bd@mail.gmail.com>
Message-ID: <20090113135018.458d057a.mschwendt@gmail.com>

On Tue, 13 Jan 2009 17:36:59 +0530, Rakesh wrote:

> > On Tue, 13 Jan 2009 15:13:17 +0530, Rakesh wrote:
> >
> [..]
> >
> > The thing that bugs me is that you try to blame other people in
> > justification of your own mistakes. In the original post, and also in the
> > private messages. Okay, Matt forgot to commit the source, most likely
> > while committing fixes for other build failures. So what? If the package
> > had a maintainer, he would notice the build failure and fix this small
> > mistake. The pkg is orphaned, however.
> >
> 
> Well I have already agreed of using old working copy and not checking
> diffs painstakingly. Between your commit in devel also ignored source
> import and build. You had updated to new version and didn't bothered
> to update the source and support your statement with a false argument
> that "if it had a maintainer". Package should not be left it that
> state.

You are mistaken. I am completely innocent here.

It was not me who did the version upgrade. Check your facts, please.

The only thing I did was to commit a spec file fix in devel for an
unowned directory and leave it to the old or new package maintainer to
decide whether and when to rebuild in Rawhide. Typically, maintainers
[even some who have been non-responsive for a few weeks] take the
chance and apply other updates [such as new version upgrades - hint;) ].

And even if I had noticed the missing tarball upload, it would not have
been my obligation to fix it. Rather I would have tried to find out the
reason for it.



From fedora at leemhuis.info  Tue Jan 13 12:57:22 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 13 Jan 2009 13:57:22 +0100
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <20090113123159.GA2456@yoda.jdub.homelinux.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>	<496C415A.1020100@fedoraproject.org>
	<20090113123159.GA2456@yoda.jdub.homelinux.org>
Message-ID: <496C8FB2.9040401@leemhuis.info>

On 13.01.2009 13:31, Josh Boyer wrote:
> On Tue, Jan 13, 2009 at 12:53:06PM +0530, Rahul Sundaram wrote:
>> Josef Bacik wrote:
>>> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
>>> of fun new things to tinker with.  
>> I know this is very early but just to get an idea of the status, has  
>> anyone looked into:
>>  * Anaconda support for Fedora 11
> There was an Anaconda session at FUDCon.  This wasn't mentioned at all.
> I think there are enough things to do for F11 at the moment,

FYI, patches from Sandeen seems to be in the works:

https://www.redhat.com/archives/anaconda-devel-list/2009-January/msg00077.html
https://www.redhat.com/archives/anaconda-devel-list/2009-January/msg00091.html

 > [...]

CU
knurd



From vonbrand at inf.utfsm.cl  Tue Jan 13 13:20:36 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 13 Jan 2009 10:20:36 -0300
Subject: Problems with X font handling
In-Reply-To: <20090112143745.853acd38.zaitcev@redhat.com>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
Message-ID: <200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>

Pete Zaitcev <zaitcev at redhat.com> wrote:
> On Mon, 12 Jan 2009 17:17:46 -0300, "Horst H. von Brand" <vonbrand at inf.utfsm.cl> wrote:
> 
> > Lots of X programs (xemacs, xlogo, xfig) complain of missing fonts (and end
> > up using some cheesy default font). I reported this originally against
> > xemacs (at 478999), and now changed it to xorg-x11 as I believe this is a
> > better match. xfontsel has only 4 fonts to exhibit now in all. This is

> Assuming you already verified that fonts are actually installed

$ yum list installed "xorg-x11-fonts-*"
Loaded plugins: fastestmirror, refresh-packagekit
Installed Packages
xorg-x11-fonts-100dpi.noarch               7.2-6.fc9
xorg-x11-fonts-75dpi.noarch                7.2-6.fc9
xorg-x11-fonts-ISO8859-1-100dpi.noarch     7.2-6.fc9
xorg-x11-fonts-ISO8859-1-75dpi.noarch      7.2-6.fc9
xorg-x11-fonts-Type1.noarch                7.2-6.fc9
xorg-x11-fonts-misc.noarch                 7.2-6.fc9

> please run the following test for me:
> 
> 1. Log in
> 2. Open gnome-terminal
> 3. run xemacs and verify that it fails like you described

Fails.

> 4. su, "service xfs restart"

xfs: unrecognized service

(No, I did not do anything here except religiously updating X and axing
xorg.conf when told so. And particularly, I did nothing specially X-related
during the great font handling overhaul.)

There is no xorg-x11-xfs installed here (and that used to work fine). On
another machine (a bit carelessly handled, sorry) what I have is
xorg-x11-xfs-1.0.5-3.fc10.x86_64, installed in July (legacy
leftover?). There I get:

  Warning: Cannot convert string "-*-helvetica-bold-r-*-*-*-120-*-*-*-*-*-*" to type FontStruct
  Warning: Missing charsets in String to FontSet conversion

> 5. run xemacs again

On the other machine with xfs I restarted that one, and starting xemacs
again gives me the message stated. There I have

xorg-x11-fonts-100dpi.noarch             7.2-6.fc9
xorg-x11-fonts-75dpi.noarch              7.2-6.fc9
xorg-x11-fonts-ISO8859-1-100dpi.noarch   7.2-6.fc9
xorg-x11-fonts-ISO8859-1-75dpi.noarch    7.2-6.fc9
xorg-x11-fonts-Type1.noarch              7.2-6.fc9
xorg-x11-fonts-misc.noarch               7.2-6.fc9
xorg-x11-fonts-truetype.noarch           7.2-4.fc9

> If it still fails on step 5, it's not bug 430416. If it starts working,
> then the problem is that we fixed it in libraries somewhere (with
> X server remaining broken), and perhaps your apps use old libraries.
> 
> Please let me know how it goes.
-- 
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 tomek at pipebreaker.pl  Tue Jan 13 13:22:09 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Tue, 13 Jan 2009 14:22:09 +0100
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <20090113123159.GA2456@yoda.jdub.homelinux.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<496C415A.1020100@fedoraproject.org>
	<20090113123159.GA2456@yoda.jdub.homelinux.org>
Message-ID: <20090113132209.GA6027@mother.fordon.pl.eu.org>

On Tue, Jan 13, 2009 at 07:31:59AM -0500, Josh Boyer wrote:
> >> http://btrfs.wiki.kernel.org/index.php/Getting_started
> >>
> >> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
> >> of fun new things to tinker with.  

> >  * Simple home user backup that takes advantage of snapshots
> >  * RPM/Yum integration for rollbacks
> 
> All of these seem like F12 topics to me.

  As for backup, the code is already written (cron job snapshotting and
nautilus extension for GUI). It's here:
http://src.opensolaris.org/source/xref/jds/time-slider/

  It may need adjustment to uset btrfs snapshotting mechanism, but
apart from this logic and UI is implemented.


-- 
Tomasz Torcz                                                       72->|   80->|
xmpp: zdzichubg at chrome.pl                                          72->|   80->|

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090113/800c1e3d/attachment.sig>

From skvidal at fedoraproject.org  Tue Jan 13 13:25:20 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 13 Jan 2009 08:25:20 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <496C415A.1020100@fedoraproject.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<496C415A.1020100@fedoraproject.org>
Message-ID: <1231853120.14403.1331.camel@rosebud>

On Tue, 2009-01-13 at 12:53 +0530, Rahul Sundaram wrote:
> Josef Bacik wrote:
> > Hello,
> > 
> > I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
> > the same for F-10 and F-9 shortly.  If you are using the rawhide
> > kernel then you will be able to test with the newly merged btrfs
> > filesystem.  All testing is greatly appreciated.  Here is a wiki page
> > which outlines some of the basic commands you can use with btrfs
> > 
> > http://btrfs.wiki.kernel.org/index.php/Getting_started
> > 
> > Btrfs has built in snapshotting, subvolumes and RAID support, so lots
> > of fun new things to tinker with.  
> 
> I know this is very early but just to get an idea of the status, has 
> anyone looked into:
> 
>   * RPM/Yum integration for rollbacks

the last one would be implemented in exactly the same way lvm snapshots
would - via a yum plugin running before a transaction.

-sv




From veillard at redhat.com  Tue Jan 13 13:59:12 2009
From: veillard at redhat.com (Daniel Veillard)
Date: Tue, 13 Jan 2009 14:59:12 +0100
Subject: New Fedora virtualization list: fedora-virt
In-Reply-To: <200901091548.n09Fmx8a011699@laptop14.inf.utfsm.cl>
References: <20090109145050.GC9484@redhat.com>
	<200901091548.n09Fmx8a011699@laptop14.inf.utfsm.cl>
Message-ID: <20090113135912.GA4669@redhat.com>

On Fri, Jan 09, 2009 at 12:48:59PM -0300, Horst H. von Brand wrote:
> Daniel Veillard <veillard at redhat.com> wrote:
> 
> [...]
> 
> > The new list would be the correct place for anything related to
> > virtualization in fedora, both user and development issues,
> > and all hypervisors. The old list sounds the right place for
> > people still using Fedora <= 8 with Xen,
> 
> I.e., officially nobody?

  Well, we know some users just can't switch, our hope is for Xen
in upstream kernel to improve until they are able to be back on the
normal Fedora supported distros.
  But right now the status-quo is that some people still need to
run Fedora 8,

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/



From rakesh.pandit at gmail.com  Tue Jan 13 14:20:45 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 13 Jan 2009 19:50:45 +0530
Subject: Straw comaintainer needed
In-Reply-To: <4925C3DA.5000800@herr-schmitt.de>
References: <539333cb0811200910j180badb9wce4188c7d93cb4f8@mail.gmail.com>
	<4925C3DA.5000800@herr-schmitt.de>
Message-ID: <b401d2530901130620y96a553ema87c36ca82fc4fc@mail.gmail.com>

2008/11/21 Jochen Schmitt <Jochen at herr-schmitt.de>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> subhodip biswas schrieb:
>> hi !
>>
>> A FTBFS bug is assigned against straw for quite a amount of time . I
>> really didnt able to dedicate the time necessary to fix it .
>> I will be grateful , if someone co maintains straw and help in fixing
> the bug .
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=465038
>>
> Should be fixed on straw-0.27-14
>
> The issues was:
>
> * Add the egg-info files into the package
> * Add gnome-python2-gnome as BR and Req.
>

May you or owner close the bug as fix is done. This will help
consistency. Others not wasting time to recheck in cvs whether fix is
already there or not.

Thanks,

-- 
rakesh



From notting at redhat.com  Tue Jan 13 16:29:57 2009
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 13 Jan 2009 11:29:57 -0500
Subject: Looking for Fedora bugmasters
In-Reply-To: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
References: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
Message-ID: <20090113162957.GB24319@nostromo.devel.redhat.com>

Roozbeh Pournader (roozbeh at gmail.com) said: 
> I have been in an awkward situation for quite a while now: I created
> the tracker bug for FE-NEEDSPONSOR three years ago (which made me its
> reporter). Since then, I've been CC-ed on all the changes. I was
> wondering who should I contact to change the "reporter" of the bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=177841
> 
> Or should I open a bug for that? If yes, in product/component?

bugzilla-owner at redhat.com, or open a bug against bugzilla. Changing
the reporter (IIRC) requires admin access to the raw database.

Bill



From zaitcev at redhat.com  Tue Jan 13 16:29:54 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Tue, 13 Jan 2009 09:29:54 -0700
Subject: Problems with X font handling
In-Reply-To: <200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
Message-ID: <20090113092954.04bfc620.zaitcev@redhat.com>

On Tue, 13 Jan 2009 10:20:36 -0300, "Horst H. von Brand" <vonbrand at inf.utfsm.cl> wrote:

> > 5. run xemacs again
> 
> On the other machine with xfs I restarted that one, and starting xemacs
> again gives me the message stated.

Sorry for leading you astray with this.

I see it myself now too. If I have the following in xorg.conf:

Section "Files"
        FontPath     "/usr/share/X11/fonts/75dpi"
        FontPath     "unix/:7100"
EndSection

Then the following is seen in Xorg.0.log:

(==) Including the default font path built-ins.
(**) FontPath set to:
        /usr/share/X11/fonts/75dpi,
        unix/:7100,
        built-ins
.... so far so good, but then:
[dix] Could not init font path element /usr/share/X11/fonts/75dpi, removing from list!
[dix] Could not init font path element unix/:7100, removing from list!

Of course the fontdir is set up correctly with mkfontdir.
It happens on:
xorg-x11-server-Xorg-1.5.99.3-8.fc11.x86_64

So, looks like the X server is bust pretty badly. Time to file a bug.
I don't use legacy X applications, so the problem does not bother me.
Horst, do you want to confirm and file?

-- Pete



From mike at miketc.net  Tue Jan 13 16:34:23 2009
From: mike at miketc.net (Mike Chambers)
Date: Tue, 13 Jan 2009 10:34:23 -0600
Subject: Rawhide status 1/13
Message-ID: <1231864463.8582.7.camel@scrappy.miketc.net>

How does rawhide seem to be running in the last week/days or so?  When I
messed with it few days ago, it seems slow and not as responsive (yes I
am aware at some point, debug type services are turned on and make it a
little slower during testing).  It seemed firefox was not showing pages
correctly, as in some of the blocks/frames within the page would be a
bunch of them, like tiled or something?  Thought I saw few others
mention this before.

In other words, it running same, better, no idea what I am referring to,
it picking up steam and working pretty decent for being rawhide?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From bruno at wolff.to  Tue Jan 13 16:44:08 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 13 Jan 2009 10:44:08 -0600
Subject: Rawhide status 1/13
In-Reply-To: <1231864463.8582.7.camel@scrappy.miketc.net>
References: <1231864463.8582.7.camel@scrappy.miketc.net>
Message-ID: <20090113164408.GA21619@wolff.to>

On Tue, Jan 13, 2009 at 10:34:23 -0600,
  Mike Chambers <mike at miketc.net> wrote:
> How does rawhide seem to be running in the last week/days or so?  When I
> messed with it few days ago, it seems slow and not as responsive (yes I
> am aware at some point, debug type services are turned on and make it a
> little slower during testing).  It seemed firefox was not showing pages
> correctly, as in some of the blocks/frames within the page would be a
> bunch of them, like tiled or something?  Thought I saw few others
> mention this before.
> 
> In other words, it running same, better, no idea what I am referring to,
> it picking up steam and working pretty decent for being rawhide?

X doesn't work for me (ATI rv280).

There was a kernel bug (479553) a couple of days ago that was generating
a lot of log messages that might have slowed a system down. If you were
using kernel-2.6.29-0.24.rc0.git13.fc11 that might have been your problem.

I used rawhide to test livecd-creator last night and it didn't seem any
slower than F10.



From kevin.kofler at chello.at  Tue Jan 13 16:57:03 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 13 Jan 2009 17:57:03 +0100
Subject: Looking for Fedora bugmasters
References: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
Message-ID: <gkih4v$ebq$1@ger.gmane.org>

Roozbeh Pournader wrote:
> I have been in an awkward situation for quite a while now: I created
> the tracker bug for FE-NEEDSPONSOR three years ago (which made me its
> reporter). Since then, I've been CC-ed on all the changes. I was
> wondering who should I contact to change the "reporter" of the bug:

I think only the RH folks who admin the Bugzilla can change it, Fedora bug
masters don't have direct database access and Bugzilla doesn't allow
changing the reporter.

        Kevin Kofler



From darrellpf at gmail.com  Tue Jan 13 17:48:08 2009
From: darrellpf at gmail.com (darrell pfeifer)
Date: Tue, 13 Jan 2009 09:48:08 -0800
Subject: Rawhide status 1/13
In-Reply-To: <1231864463.8582.7.camel@scrappy.miketc.net>
References: <1231864463.8582.7.camel@scrappy.miketc.net>
Message-ID: <f6e5806f0901130948ke181783x479a2f09fbd801c@mail.gmail.com>

On Tue, Jan 13, 2009 at 08:34, Mike Chambers <mike at miketc.net> wrote:

> How does rawhide seem to be running in the last week/days or so?  When I
> messed with it few days ago, it seems slow and not as responsive (yes I
> am aware at some point, debug type services are turned on and make it a
> little slower during testing).  It seemed firefox was not showing pages
> correctly, as in some of the blocks/frames within the page would be a
> bunch of them, like tiled or something?  Thought I saw few others
> mention this before.
>
> In other words, it running same, better, no idea what I am referring to,
> it picking up steam and working pretty decent for being rawhide?
>

There was some serious oopsing in recent kernels which caused some slowness
and rather large /var/log/messages. Today's kernel is much better.

I had the same X problem. The intel driver has been flaky for lots of folks
since November-ish. If your intel card is misbehaving, I had success with
the latest drivers by

a)Turn off compiz
b) In your xorg.conf, add
   Option "EXANoComposite" "true"

My network seems quite slow. I think the problem is that dns queries are
seeing A rather than AAAA (or vice versa) responses and there appears to be
a timeout associated with that. The slowdown comes and goes with updates to
bind.

For the most part, today's rawhide is usable for me.

darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090113/26ac639f/attachment.htm>

From tmz at pobox.com  Tue Jan 13 19:38:29 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Tue, 13 Jan 2009 14:38:29 -0500
Subject: rpms/sudo/devel sudo.spec,1.70,1.71
In-Reply-To: <20090113170932.822CF70129@cvs1.fedora.phx.redhat.com>
References: <20090113170932.822CF70129@cvs1.fedora.phx.redhat.com>
Message-ID: <20090113193829.GY18365@inocybe.teonanacatl.org>

Daniel Kope?ek wrote:
> @@ -74,7 +75,7 @@
>         --with-ldap \
> 	--with-selinux \
> 	--with-passprompt="[sudo] password for %p: " \
> -	--with-secure-path="/sbin:/bin:/usr/sbin:/usr/bin"
> +	--with-secure-path="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin"
> #	--without-kerb5 \
> #	--without-kerb4
> make

I'm curious, why add /usr/local/bin and not /usr/local/sbin?  I would
think admins using /usr/local would be at least as likely to use sbin
as bin.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All of us could take a lesson from the weather.  It pays no attention
to criticism.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090113/3fd28f29/attachment.sig>

From fedora at camperquake.de  Tue Jan 13 20:42:53 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 13 Jan 2009 21:42:53 +0100
Subject: Problems with X font handling
In-Reply-To: <20090113092954.04bfc620.zaitcev@redhat.com>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
Message-ID: <20090113214253.73df662a@lain.camperquake.de>

Hi.

On Tue, 13 Jan 2009 09:29:54 -0700, Pete Zaitcev wrote

> Of course the fontdir is set up correctly with mkfontdir.
> It happens on:
> xorg-x11-server-Xorg-1.5.99.3-8.fc11.x86_64

I can confirm that
xorg-x11-server-Xorg-1.5.3-6.fc10.i386

works, and
xorg-x11-server-Xorg-1.5.99.901-1.fc11.i386

does not.



From jkeating at redhat.com  Tue Jan 13 18:55:28 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Jan 2009 10:55:28 -0800
Subject: Fedora 11 Alpha Freeze one week away
Message-ID: <1231872928.5086.5.camel@localhost.localdomain>

Next Tuesday we will be doing a non-blocking freeze of rawhide to be the
basis of Fedora 11 Alpha.  Only targeted fixes will be pulled into the
Alpha tag after the freeze.  Rawhide itself will continue on as to not
disrupt development.  The freeze tag will be used to create something
that is installable in most situations and the alpha release will serve
as a known good starting point for users wishing to start Fedora 11
testing and development.

Please try to keep your changes conservative over the next week as to
avoid massively breaking rawhide while we try to snapshot.  Thanks!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090113/60ee4939/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From dbn.lists at gmail.com  Tue Jan 13 22:39:31 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 13 Jan 2009 14:39:31 -0800
Subject: Problems with X font handling
In-Reply-To: <20090113214253.73df662a@lain.camperquake.de>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<20090113214253.73df662a@lain.camperquake.de>
Message-ID: <91705d080901131439h554a96d3w1082b9b48b92ebce@mail.gmail.com>

On Tue, Jan 13, 2009 at 12:42 PM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
>
> On Tue, 13 Jan 2009 09:29:54 -0700, Pete Zaitcev wrote
>
>> Of course the fontdir is set up correctly with mkfontdir.
>> It happens on:
>> xorg-x11-server-Xorg-1.5.99.3-8.fc11.x86_64
>
> I can confirm that
> xorg-x11-server-Xorg-1.5.3-6.fc10.i386
>
> works, and
> xorg-x11-server-Xorg-1.5.99.901-1.fc11.i386
>
> does not.

I think this is because the xserver now defaults to using builtin fonts.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=385943e0e9

This is nice since most people don't care about server-side fonts.
However, I think it means that you don't get to use them at all. So, I
think to fix this, you either need to build the server with
--disable-builtin-fonts or apply this patch:

http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.4.99-builtin-fonts.patch?view=markup

which gets you both builtin and loadable fonts. FWIW, the xserver in
master does this now more cleanly:

http://cgit.freedesktop.org/xorg/xserver/commit/?id=49b93df8

--
Dan



From christoph.wickert at googlemail.com  Wed Jan 14 01:59:44 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 14 Jan 2009 02:59:44 +0100
Subject: Becoming a Fedora Package Collection Sponsor
In-Reply-To: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>
References: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>
Message-ID: <1231898384.29665.40.camel@wicktop.localdomain>

Am Montag, den 12.01.2009, 16:32 -0200 schrieb Itamar Reis Peixoto:
> 
> I like to become a "Fedora Package Collection Sponsor" .
> 
> someone can point the right direction ?

http://fedoraproject.org/wiki/PackageMaintainers/SponsorProcess#Becoming_a_Fedora_Package_Collection_Sponsor

Regards,
Christoph



From jonstanley at gmail.com  Wed Jan 14 04:57:49 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Tue, 13 Jan 2009 23:57:49 -0500
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<3170f42f0901110740w590c19c5t85a52cd4e811a24b@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
Message-ID: <da159fda0901132057p3e2de847wa4d5334f216c64d7@mail.gmail.com>

On Tue, Jan 13, 2009 at 3:59 AM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2009/1/13 Michael Schwendt <mschwendt at gmail.com>:
> [..]
>>>
>>> I request FISco member attention here.  The non-responsive maintainer
>>> policy was initiated long ago here.
>>
>> It might be that the Wiki explains how to contact FESCo.

As the new FESCo chair, my preferred form of contact in the trac
instance at https://fedorahosted.org/fesco, but any method works
(though if it need follow-up, it will ultimately end up there even if
I file it myself).

> Well this thread already is part of process.

That's true. Looking at the two FTBFS bugs, I don't see the required
pings in there.  Debarshi, did your mails bounce? If so, that's enough
to short-circuit the process. If not, I'd like to give him awhile to
respond as outlined in the policy (yes, I realize that the bugs are
very old and a response is unlikely).



From loganjerry at gmail.com  Wed Jan 14 05:08:25 2009
From: loganjerry at gmail.com (Jerry James)
Date: Tue, 13 Jan 2009 22:08:25 -0700
Subject: SELinux in mock
Message-ID: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>

Josh Boyer was kind enough to give me a login on a ppc64 machine so I
can try to debug the issue I'm having with GCL.  Unfortunately, I
cannot even get off the ground.  I'm using a 'mock -r
fedora-rawhide-ppc64' command to try things out.  Inside the chroot, I
see this:

$ mock -r fedora-rawhide-ppc64 --shell
INFO: mock.py version 0.9.13 starting...
State Changed: init plugins
State Changed: start
State Changed: lock buildroot
mock-chroot> selinuxenabled
mock-chroot> echo $?
0
mock-chroot> /usr/sbin/semodule -i /tmp/gcl.pp
/usr/sbin/semodule: SELinux policy is not managed or store cannot be accessed.


How is that supposed to work?  This is blocking the GCL build, which
has to change dumped images to type gcl_exec_t when SELinux is active
(checked with selinuxenabled).  If the policy is not managed or the
store cannot be accessed, then selinuxenabled should be setting its
exit code to 1, should it not?  As it is, the GCL build fails when
trying to invoke chcon because selinuxenabled is apparently lying.
-- 
Jerry James
http://loganjerry.googlepages.com/



From jkeating at redhat.com  Wed Jan 14 05:26:33 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 13 Jan 2009 21:26:33 -0800
Subject: SELinux in mock
In-Reply-To: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
Message-ID: <1231910793.5086.47.camel@localhost.localdomain>

On Tue, 2009-01-13 at 22:08 -0700, Jerry James wrote:
> 
> 
> How is that supposed to work?  This is blocking the GCL build, which
> has to change dumped images to type gcl_exec_t when SELinux is active
> (checked with selinuxenabled).  If the policy is not managed or the
> store cannot be accessed, then selinuxenabled should be setting its
> exit code to 1, should it not?  As it is, the GCL build fails when
> trying to invoke chcon because selinuxenabled is apparently lying.

selinuxenabled I do believe likely just checks the kernel, which on the
host may indeed be running.  However within the chroot the policy may be
mismatching or completely non-existent.  There is very early support for
allowing in chroot policy to work, but it's certainly not in play on our
builders in Koji, which are a el5 base.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090113/5f5408cf/attachment.sig>

From jonstanley at gmail.com  Wed Jan 14 05:29:38 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 14 Jan 2009 00:29:38 -0500
Subject: Becoming a Fedora Package Collection Sponsor
In-Reply-To: <1231898384.29665.40.camel@wicktop.localdomain>
References: <d3ceea380901121032w6f6a4d00q186631e415934762@mail.gmail.com>
	<1231898384.29665.40.camel@wicktop.localdomain>
Message-ID: <da159fda0901132129u4a5f9c2cqfc5f395ee9f3cf6f@mail.gmail.com>

On Tue, Jan 13, 2009 at 8:59 PM, Christoph Wickert
<christoph.wickert at googlemail.com> wrote:

> http://fedoraproject.org/wiki/PackageMaintainers/SponsorProcess#Becoming_a_Fedora_Package_Collection_Sponsor

Note that this is already on the schedule for Friday's FESCo meeting.



From jonstanley at gmail.com  Wed Jan 14 05:41:36 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 14 Jan 2009 00:41:36 -0500
Subject: FESCo meeting reminder + new chair
Message-ID: <da159fda0901132141o3252f6bfw66d835fdc379b133@mail.gmail.com>

Just a few friendly FESCo reminders:

First off, I was selected as the new chair of FESCo at the last
meeting. Anything that you may have formerly sent to Brian Pepple in
that role (sponsor nominations, requests for advice, etc) you can now
send to me. Brian is obviously still around, though :). I strongly
prefer trac tickets so that I don't lose track of anything (no pun
intended :) ), however any method of contact (IRC, private email,
public list, Fedora Talk ext 5102788) all work.

I'd like to thank Brian for his many years of service as the chair of FESCo.

Secondly, the meeting time for FESCo has changed as well,  We are now
meeting on Friday's, at 1700UTC in #fedora-meeting. I'll send the
agenda out the day before, or you can view the current agenda for the
next meeting at any time at https://fedorahosted.org/fesco/report/9

Thanks!
-Jon



From debarshi.ray at gmail.com  Wed Jan 14 06:45:17 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 14 Jan 2009 12:15:17 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <da159fda0901132057p3e2de847wa4d5334f216c64d7@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<da159fda0901132057p3e2de847wa4d5334f216c64d7@mail.gmail.com>
Message-ID: <3170f42f0901132245v79c2cd11ub380f9a5f047af2b@mail.gmail.com>

>  Debarshi, did your mails bounce? If so, that's enough
> to short-circuit the process. If not, I'd like to give him awhile to
> respond as outlined in the policy (yes, I realize that the bugs are
> very old and a response is unlikely).

Actually I do not remember whether they bounced or not. I have CC'ed
him again in this email so lets see what happens. I also find that
Michael Schwendt had emailed him regarding gdmap on an independent
thread without any response.

Cheers,
Debarshi



From debarshi.ray at gmail.com  Wed Jan 14 06:55:46 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 14 Jan 2009 12:25:46 +0530
Subject: Non-responsive maintainer process for Damien Durand
In-Reply-To: <da159fda0901132057p3e2de847wa4d5334f216c64d7@mail.gmail.com>
References: <3170f42f0811081314q17ddeeb7pa44123ee488d7d75@mail.gmail.com>
	<b401d2530901110837r4379249bwd013e2c650743244@mail.gmail.com>
	<b401d2530901111123g629166bfoc9ab08cc4b0fafd2@mail.gmail.com>
	<20090112113724.73cf2bae.mschwendt@gmail.com>
	<b401d2530901120304u61763632m48f40984d64a8b56@mail.gmail.com>
	<20090112123953.d01ea744.mschwendt@gmail.com>
	<b401d2530901120419t23b02bf3ob383e38b0031c6b6@mail.gmail.com>
	<20090113093750.192007a4.mschwendt@gmail.com>
	<b401d2530901130059w1ef23330s7eae2c73a9d17010@mail.gmail.com>
	<da159fda0901132057p3e2de847wa4d5334f216c64d7@mail.gmail.com>
Message-ID: <3170f42f0901132255q219ac885sa79c407582bbd1ea@mail.gmail.com>

> As the new FESCo chair, my preferred form of contact in the trac
> instance at https://fedorahosted.org/fesco,

https://fedorahosted.org/fesco/ticket/17

Cheers,
Debarshi



From tim at niemueller.de  Wed Jan 14 07:25:13 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Wed, 14 Jan 2009 08:25:13 +0100
Subject: Lua module packages are not multi-lib, how to do?
Message-ID: <496D9359.5090000@niemueller.de>

Hello Fedora.

I've just realized that the Lua module packages that I maintain, which
include a Lua module in form of a .so shared object, are not available
as multi-lib. I can only ever install the x86_64 version on my machine,
yum and packagekit do not provide the i386 version.

As an example take lua-posix, it provides /usr/lib64/lua/5.1/posix.so.
Probably this does not match some pattern to make it understood as
multi-lib. Is there a way I can force this package to be pushed as
multi-lib package? Or is it a bug in my spec files and it should already
have been recognized as multi-lib?

Regards from Aachen,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From alexl at users.sourceforge.net  Wed Jan 14 07:53:14 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Wed, 14 Jan 2009 00:53:14 -0700
Subject: PPC64 virtual machine
In-Reply-To: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
	(Jerry James's message of "Sat\, 10 Jan 2009 11\:30\:32 -0700")
References: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
Message-ID: <iyeiz6jpcl.fsf@allele2.eebweb.arizona.edu>

>>>>> "JJ" == Jerry James  writes:

JJ> I've gotten GCL to build successfully in Rawhide on i386 and
JJ> x86_64 platforms.  However, it segfaulted on PPC64.

JJ> http://koji.fedoraproject.org/koji/taskinfo?taskID=1043890

If it currently works on x86_64, you might want to take ownership of
of, close or otherwise comment on this open bug:

http://bugzilla.redhat.com/show_bug.cgi?id=428539

Alex



From ivazqueznet at gmail.com  Wed Jan 14 07:58:39 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 14 Jan 2009 02:58:39 -0500
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <496D9359.5090000@niemueller.de>
References: <496D9359.5090000@niemueller.de>
Message-ID: <1231919919.12251.141.camel@ignacio.lan>

On Wed, 2009-01-14 at 08:25 +0100, Tim Niemueller wrote:
> Hello Fedora.
> 
> I've just realized that the Lua module packages that I maintain, which
> include a Lua module in form of a .so shared object, are not available
> as multi-lib. I can only ever install the x86_64 version on my machine,
> yum and packagekit do not provide the i386 version.
> 
> As an example take lua-posix, it provides /usr/lib64/lua/5.1/posix.so.
> Probably this does not match some pattern to make it understood as
> multi-lib. Is there a way I can force this package to be pushed as
> multi-lib package? Or is it a bug in my spec files and it should already
> have been recognized as multi-lib?

All multilib means is that the 64-bit repo contains 32-bit packages as
well as the normal 64-bit packages. By default only packages with a
-devel subpackage are considered multilib; I think you need to log a
request with releng to make other packages multilib. And even then
you'll need a good reason for them to make it so.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/ec8afe2f/attachment.sig>

From rawhide at fedoraproject.org  Wed Jan 14 08:08:59 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 14 Jan 2009 08:08:59 +0000 (UTC)
Subject: rawhide report: 20090114 changes
Message-ID: <20090114080859.EA7051F825D@releng2.fedora.phx.redhat.com>

Compose started at Wed Jan 14 06:01:03 UTC 2009

New package cgit
        A fast webinterface for git
New package serafettin-cartoon-fonts
        Sans-serif Cartoon Fonts
New package system-autodeath
        Automatically disable system default route on a specific date
Removed package fgfs-Atlas
Removed package fgfs-base
Removed package pywbxml
Updated Packages:

ConsoleKit-0.3.0-3.fc11
-----------------------
* Wed Jan 14 17:00:00 2009 Colin Walters <walters at verbum.org> - 0.3.0-4
- Add patch to fix up dbus permissions

* Fri Nov 21 17:00:00 2008 Matthias Clasen  <mclasen at redhat.com> - 0.3.0-3
- Tweak descriptions


anaconda-11.5.0.7-1
-------------------
* Wed Jan 14 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 11.5.0.7-1
- How to get raw pages from the wiki has changed again. (clumens)
- Make sure the 'anaconda' file gets the right detected type (alsadi,
  - Include the missing import. (clumens)


audit-1.7.11-2.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Steve Grubb <sgrubb at redhat.com> 1.7.11-2
- Add crypto event definitions


cairo-dock-2.0.0-0.3.svn1483_trunk.fc11
---------------------------------------
* Wed Jan 14 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1483


cjkunifonts-0.2.20080216.1-13.fc11
----------------------------------
* Wed Jan 14 17:00:00 2009 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-13.fc11
- Resolves: rhbz#477373
- Included _font_pkg macro to conform new font packaging guidelines.
- Tidy up .spec file.


cmake-2.6.3-0.3.rc8.fc11
------------------------
* Tue Jan 13 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> - 2.6.3-0.3.rc8
- Update to 2.6.3-RC-8


conntrack-tools-0.9.9-1.fc11
----------------------------
* Tue Jan 13 17:00:00 2009 Paul P. Komkoff Jr <i at stingr.net> - 0.9.9-1
- new upstream version


cyrus-imapd-2.3.13-1.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> - 2.3.13-1
- updated to 2.3.13


dhcp-4.1.0-4.fc11
-----------------
* Tue Jan 13 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 12:4.1.0-4
- Updated LSB init script header to reference /etc/dhcp/dhcpd.conf (#479012)


doulos-fonts-4.104-1.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Roozbeh Pournader <roozbeh at gmail.com> - 4.104-1
- Update main font to 4.104 (with Unicode 5.1 support)
- Remove Doulos Literacy (not maintained anymore)
- Last update before conversion to new fonts policy


dovecot-1.1.8-2.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> - 1:1.1.8-2
- added managesieve support (thanks Helmut K. C. Tessarek)


ftnchek-3.3.1-8.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> 3.3.1-9
- Add upstream varfmt patch
- Add BR bison to handle change to yacc file


gdmap-0.8.1-4.fc11
------------------
* Tue Jan 13 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-4
- Bumped

* Tue Jan 13 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.8.1-3
- Escaped macros in changelog to make rpmlint silent.
- Removed mixed space and tab.


gnome-commander-1.2.8-0.3.svn2426_trunk.fc11
--------------------------------------------
* Wed Jan 14 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2426


gnome-media-2.25.1-5.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.1-5
- Another try at fixing the scriplets


gnupg2-2.0.10-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0.10-1
- gnupg-2.0.10


gnuplot-4.2.4-2.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 4.2.4-2
- add minimal package for server SIG purposes


gstreamer-plugins-base-0.10.21-4.fc11
-------------------------------------
* Tue Jan 13 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.2-4
- Avoid deadlocks when PulseAudio disappears


gstreamer-plugins-good-0.10.11-2.fc11
-------------------------------------
* Tue Jan 13 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.11-2
- Avoid pulsesink hang when PulseAudio disappears


gupnp-0.12.5-1.fc11
-------------------
* Wed Jan 14 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> 0.12.5-1
- New upstream release


gupnp-av-0.3-1.fc11
-------------------

gvfs-1.1.3-4.fc11
-----------------
* Tue Jan 13 17:00:00 2009 Adrian Reber <adrian at lisas.de> - 1.1.3-4
- Rebuild for libcdio-0.81


hal-cups-utils-0.6.19-1.fc11
----------------------------
* Tue Jan 13 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 0.6.19-1
- 0.6.19.


hplip-2.8.12-5.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 2.8.12-5
- Fixed Quit menu item in device manager (bug #479751).

* Tue Jan 13 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 2.8.12-4
- Prevent crash when DEVICE_URI/PRINTER environment variables are not
  set (bug #479808 comment 6).

* Tue Jan 13 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 2.8.12-3
- Make --qt4 the default for the systray applet, so that it appears
  in the right place, again (bug #479751).
- Removed hal preprobe rules as they were causing breakage
  (bug #479648).


icon-naming-utils-0.8.7-2.fc11
------------------------------
* Wed Jan 14 17:00:00 2009 Parag <pnemade at redhat.com> - 0.8.7-2
- spec file cleanup as suggested in merge-review rh#225894


inkscape-0.46-9.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.46-9
- Fix crash with bitmap font (#477158)


inksmoto-0.5.0-3.rc2.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 0.5.0-3.rc2
- New upstream.


inn-2.4.5-7.fc11
----------------
* Tue Jan 13 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 2.4.5-7
- fix upstream url


iok-1.1.0-1.fc11
----------------
* Tue Jan 13 17:00:00 2009 Parag Nemade <panemade at gmail.com>- 1.1.0-1
- Update to Next release 1.1.0


kdebase-runtime-4.1.96-2.fc11
-----------------------------
* Tue Jan 13 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-2
- tarball respin
- drop extraneous deps (that are in kdelibs)


kdesdk-4.1.96-3.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-3
- F11+: add workaround to fix build against Boost 1.37.0

* Fri Jan  9 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-2
- don't ship krazy-licensecheck, should be in krazy2

* Wed Jan  7 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-1
- 4.2rc1


kernel-2.6.29-0.35.rc1.git4.fc11
--------------------------------
* Tue Jan 13 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- Enable CONFIG_DMAR (and GFX_WA and FLOPPY_WA) requested by Gerd.

* Tue Jan 13 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- 2.6.29-rc1-git4
- CONFIG_MFD_PCF50633 fails. disable it for now.

* Tue Jan 13 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc1-git3


kover-4-2.fc11
--------------
* Tue Jan 13 17:00:00 2009 Adrian Reber <adrian at lisas.de> - 4-2
- rebuilt for new libcdio


krazy2-2.8-5.20090111svn909634.fc11
-----------------------------------
* Tue Jan 13 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-5.20090111svn909634
- Typo with sources

* Tue Jan 13 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-4.20090111svn909634
- Forgot to commit krazy-licensecheck

* Tue Jan 13 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-3.20090111svn909634
- Missed the patch

* Tue Jan 13 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-2.20090111svn909634
- Moved krazy-licensecheck from kdesdk to here

* Tue Jan  6 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-1.20090105svn906738
- New plugins and extra checks
- Updated plugins


krb5-auth-dialog-0.8-2.fc11
---------------------------
* Wed Jan 14 17:00:00 2009 Colin Walters <walters at verbum.org> - 0.8-2
- BR notify, pointed out by Bojan Smojver <bojan at rexursive.com>

* Tue Jan 13 17:00:00 2009 Colin Walters <walters at verbum.org> - 0.8-1
- New upstream release
- Remove both patches; they are upstreamed
- Add gconf spec goo
- Add new stuff to files list


libart_lgpl-2.3.20-3.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 2.3.20-3
- rebuild to get provides pkgconfig(libart-2.0)

* Mon May 26 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.3.20-2
- add sparc64 for multilib


libcddb-1.3.0-6.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Adrian Reber <adrian at lisas.de> 1.3.0-6
- Rebuild for new libcdio


libcdio-0.81-1.fc11
-------------------

libgxim-0.3.2-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Akira TAGOH <tagoh at redhat.com> - 0.3.2-1
- New upstream release.


libnfnetlink-0.0.39-4.fc11
--------------------------
* Tue Jan 13 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.0.39-4
- rebuild to get provides pkgconfig(libnfnetlink)


libraw1394-2.0.0-6.fc11
-----------------------
* Tue Jan 13 17:00:00 2009 Jarod Wilson <jarod at redhat.com> - 2.0.0-6
- Set errno = ENOSYS for all unimplemented functions
- Make dvgrab and friends work w/o requiring r/w on the local fw node (#441073)


libsemanage-2.0.31-1.fc11
-------------------------

opal-3.5.2-3.fc11
-----------------
* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.5.2-3
- Yet another dep that configure doesn't check and it just fails on

* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.5.2-2
- Add a build dep

* Tue Jan  6 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.5.2-1
- New release for ekiga 3.1.0 beta
- Some updates from merge review


oxine-0.7.1-2.fc11
------------------
* Tue Jan 13 17:00:00 2009 Adrian Reber <adrian at lisas.de> 0.7.1-2
- Rebuild for libcdio-0.81


pbzip2-1.0.5-1.fc11
-------------------
* Thu Jan  8 17:00:00 2009 Jeff Gilchrist <pbzip2 at compression.ca> - 1.0.5-1
- Release 1.0.5

* Sun Dec 21 17:00:00 2008 Jeff Gilchrist <pbzip2 at compression.ca> - 1.0.4-1
- Release 1.0.4

* Fri Oct 31 18:00:00 2008 Jeff Gilchrist <pbzip2 at compression.ca> - 1.0.3-1
- Release 1.0.3
- Added support for SUSE RPM build
- Added symlink for pbzcat


php-pecl-memcache-3.0.3-1.fc11
------------------------------
* Tue Jan 13 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> 3.0.3-1
- new version 3.0.3


policycoreutils-2.0.61-1.fc11
-----------------------------
* Tue Jan 13 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-1
- Update to upstream
	* chcat: cut categories at arbitrary point (25) from Dan Walsh
	* semodule: use new interfaces in libsemanage for compressed files
	  from Dan Walsh
	* audit2allow: string changes for usage


ptlib-2.5.2-3.fc11
------------------
* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 2.5.2-3
- Add an extra build dep


pulseaudio-0.9.14-2.fc11
------------------------
* Tue Jan 13 17:00:00 2009 Lennart Poettering <lpoetter at redhat.com> 0.9.14-1
- New release

* Tue Jan 13 17:00:00 2009 Adel Gadllah <adel.gadllah at gmail.com> 0.9.14-2
- Prefer mixer controls with volumes over switches


pyicq-t-0.8.1-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Michael Fleming <mfleming+rpm at enlartenment.com> - 0.8.1-1
- New upstream release


qpidc-0.4.728142-1.fc11
-----------------------

quota-3.17-1.fc11
-----------------
* Tue Jan 13 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 1:3.17-1
- new upstream release, remove already applied patches


rhm-0.4.3030-2.fc11
-------------------

rhythmbox-0.11.6-21.r6096.fc11
------------------------------
* Tue Jan 13 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-21.r6096
- Add more Python deps for the UPNP plugin (#474372)
- Require gstreamer-python-devel, as it's been split from gstreamer-python

* Mon Jan  5 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-20.r6096
- Don't ship our own iradio playlist, the changes are already upstream


selinux-policy-3.6.2-4.fc11
---------------------------
* Mon Jan 12 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.2-4
- Fixes for reading xserver_tmp_t


srecord-1.46-1.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.46-1
- update to 1.46


telepathy-glib-0.7.22-1.fc11
----------------------------
* Tue Jan 13 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.22-1
- Update to 0.7.22.


telepathy-sofiasip-0.5.14-1.fc11
--------------------------------
* Tue Jan 13 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.5.14-1
- Update to 0.5.14.


tokyocabinet-1.3.27-1.fc11
--------------------------
* Tue Jan 13 17:00:00 2009 Deji Akingunola <dakingun at gmail.com> - 1.3.27-1
- Update to version 1.3.27


wmx-7-2.fc11
------------
* Tue Jan 13 17:00:00 2009 Gabriel Somlo <somlo at cmu.edu> 7-2
- re-enabled scroll-wheel-cycles-channels feature


xmms2-0.5-4.fc11
----------------
* Tue Jan 13 17:00:00 2009 Adrian Reber <adrian at lisas.de> - 0.5-4
- Rebuild for libcdio-0.81


Summary:
Added Packages: 3
Removed Packages: 3
Modified Packages: 61
Broken deps for i386
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.i386 requires libopal.so.3.4.2
	ekiga-3.0.1-4.fc11.i386 requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnuplot-common-4.2.4-2.fc11.i386 requires /usr/sbin/install-info
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	5:mutt-1.5.19-1.fc11.i386 requires libtokyocabinet.so.4
	osmo-0.2.4-2.fc11.i386 requires libsyncml.so.0
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	ekiga-3.0.1-4.fc11.x86_64 requires libopal.so.3.4.2()(64bit)
	ekiga-3.0.1-4.fc11.x86_64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnuplot-common-4.2.4-2.fc11.x86_64 requires /usr/sbin/install-info
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	5:mutt-1.5.19-1.fc11.x86_64 requires libtokyocabinet.so.4()(64bit)
	osmo-0.2.4-2.fc11.x86_64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	ekiga-3.0.1-4.fc11.ppc requires libopal.so.3.4.2
	ekiga-3.0.1-4.fc11.ppc requires libpt.so.2.4.2
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	gnuplot-common-4.2.4-2.fc11.ppc requires /usr/sbin/install-info
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	5:mutt-1.5.19-1.fc11.ppc requires libtokyocabinet.so.4
	osmo-0.2.4-2.fc11.ppc requires libsyncml.so.0
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	ekiga-3.0.1-4.fc11.ppc64 requires libopal.so.3.4.2()(64bit)
	ekiga-3.0.1-4.fc11.ppc64 requires libpt.so.2.4.2()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnuplot-common-4.2.4-2.fc11.ppc64 requires /usr/sbin/install-info
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	5:mutt-1.5.19-1.fc11.ppc64 requires libtokyocabinet.so.4()(64bit)
	osmo-0.2.4-2.fc11.ppc64 requires libsyncml.so.0()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	shorewall-perl-4.2.4.5-1.fc11.noarch requires shorewall-common = 0:4.2.4.5-1.fc11
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From mcepl at redhat.com  Wed Jan 14 10:28:14 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 14 Jan 2009 11:28:14 +0100
Subject: Problems with X font handling
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
Message-ID: <uar046x62l.ln2@ppp1053.in.ipex.cz>

On 2009-01-13, 16:29 GMT, Pete Zaitcev wrote:
> Section "Files"
>         FontPath     "/usr/share/X11/fonts/75dpi"
>         FontPath     "unix/:7100"
> EndSection

Try to just eliminate "Files" section altogether. You then get in 
/var/log/Xorg.0.log something like this:

    (==) No FontPath specified.  Using compiled-in default.
    (==) FontPath set to:
            catalogue:/etc/X11/fontpath.d,
            built-ins

Pete, xfs is not manadatory anymore and it is not installed per 
default since somewhere in F9. All configuration files for 
individual font packages should go to /etc/X11/fontpath.d. If you 
eliminate "Files" section, stop xfs, restart Xorg, and something 
doesn't work, THEN file a bug about it. Or if you have xfs 
running and set up like above (I don't think you should have the 
first line in xorg.conf, it should go to /etc/X11/fs/config 
instead) then it should work as wel, of course -- we don't ban 
xfs, just don't use it per default anymore.

Best,

Mat?j



From mcepl at redhat.com  Wed Jan 14 10:29:12 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 14 Jan 2009 11:29:12 +0100
Subject: Problems with X font handling
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<20090113214253.73df662a@lain.camperquake.de>
	<91705d080901131439h554a96d3w1082b9b48b92ebce@mail.gmail.com>
Message-ID: <ocr046x62l.ln2@ppp1053.in.ipex.cz>

On 2009-01-13, 22:39 GMT, Dan Nicholson wrote:
> I think this is because the xserver now defaults to using 
> builtin fonts.

s/builtin fonts/builtin font rasterization/

Mat?j



From z.kota at gmx.net  Wed Jan 14 10:55:48 2009
From: z.kota at gmx.net (Zoltan Kota)
Date: Wed, 14 Jan 2009 11:55:48 +0100 (CET)
Subject: font problem in rawhide
Message-ID: <Pine.LNX.4.58.0901141147490.8405@venus.brc>

Hi,

pybliographer has a font problem in Rawhide. It is ok with f10.
The error message in the terminal:
...
  File "/usr/share/pybliographer/Pyblio/ConfDir/GnomeUI.py", line 49, in 
<module>
    gtk.gdk.Font ('-*-*-*-r-normal-*-*-*-*-*-c-*-iso8859-1'))
RuntimeError: could not create GdkFont object


Is it related to the rawhide fonts issue discussed in an other thread? Or 
where should I look around? 


Zoltan



From paskalis at di.uoa.gr  Wed Jan 14 11:09:57 2009
From: paskalis at di.uoa.gr (Sarantis Paskalis)
Date: Wed, 14 Jan 2009 13:09:57 +0200
Subject: TeX font package naming guidelines
Message-ID: <20090114110957.GA10071@gallagher.di.uoa.gr>

Hello,

Recently an effort has begun to the system infrastructure in fedora 
aware of each font shipped, and this shipment explicit mostly through 
subpackages 
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)

Two of my packages are fonts primarily intended for LaTeX 
(tetex-font-kerkis and tetex-font-cm-lgc).  The guidelines suggest 
splitting the package in the Type 1 font files and TeX-support files.

The font-related part is mostly sorted out (see 
https://bugzilla.redhat.com/show_bug.cgi?id=477461 )

The TeX-related part consists of files (.sty, .tfm, .ovf, etc) to 
support the use of these fonts in LaTeX.  

Now, the draft for font naming guidelines suggests the srpm name to 
changed from tetex-font-cm-lgc to ctan-cm-lgc-fonts (to which I agree).

The reason for this email is the last line in the proposed table, where 
the TeX related subpackage is to be named ctan-cm-lgc-tex.  I think this 
is inconsistent with the rest of the TeX world in fedora and would like 
some feedback as to what name would be preferable.

My preference would be to put tex as a prefix and drop ctan as in 
tex-cm-lgc as it is rather obvious for TeX-related stuff; afterall we 
don't have many perl-cpan-perlmodule packages) 

What do other TeX packagers prefer?

P.S. The only hint I found at existing guidelines is that the prefix 
tex- is preferable 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28TeX.29

-- Sarantis



From itamar at ispbrasil.com.br  Wed Jan 14 11:20:32 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Jan 2009 09:20:32 -0200
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
Message-ID: <d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>

hello guys

forwarding a very sweet mail

will be very cool to have qt compiled by fedora mingw, allowing
development of window$ apps without window$, but the buildsystem of qt
need some fix's


On Wed, Jan 14, 2009 at 7:31 AM, Nokia, Qt Software
<Nokia_Qt_Software at mail.vresp.com> wrote:
> Dear Qt User:
>
> Nokia is pleased to announce that with the release of Qt 4.5 you will
> be able to use Qt under the Lesser General Public License (LGPL)
> version 2.1 terms. When released in March 2009, Qt will be made
> available under three licensing options: Commercial, LGPL and GPL.
> Prior versions of Qt are not impacted by this announcement.
>
> Nokia is committed to Qt and its continued development. By offering Qt
> under LGPL version 2.1 license terms alongside today's licensing
> options Nokia hopes to:
>
> - facilitate wider adoption of Qt across industries, desktop, web and
> embedded platforms.
> - establish Qt as a de facto standard for application development.
> - receive more valuable feedback and increased user contributions to
> ensure that Qt remains the best-in-class, cross-platform framework.
> - extend Nokia's existing platform commitment to the open source
> community.
>
> By offering a cost-free LGPL license as well as commercial and GPL
> licenses to Qt, you can choose the license model that best fits your
> development requirements.
>
> Irrespective of which license model you choose:
>
> - Qt Software is committed to continuing to provide our customers with
> the same level of professional support, services and regular releases
> you have come to expect of Qt Software.
> - We will continue to actively develop Qt, and with a greater degree
> of cooperation with the community through a new contribution model, we
> hope to make Qt even more valuable to our users.
>
> For more information on the introduction of the LGPL license and what
> this means for you, please consult the Frequently Asked Questions
> section on www.qtsoftware.com.
>
> Best regards
>
> Tom Miller
> Director of Sales
> Nokia, Qt Software
>
>
> ______________________________________________________________________
> If you no longer wish to receive these emails, please reply to this
> message with "Unsubscribe" in the subject line or simply click on the
> following link:
> http://cts.vresp.com/u?24e30d3804/490e3d1ebc/48eacdb
>
> ______________________________________________________________________
> This message was sent by Nokia, Qt Software using VerticalResponse
>
> Nokia, Qt Software
> Sandakervn 116
> (P.O. Box 4332 Nydalen, NO-0402 Oslo)
> Oslo, Oslo  NO-0484
>
> Read the VerticalResponse marketing policy:
> http://www.verticalresponse.com/content/pm_policy.html
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From nicolas.mailhot at laposte.net  Wed Jan 14 11:21:27 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Jan 2009 12:21:27 +0100 (CET)
Subject: TeX font package naming guidelines
In-Reply-To: <20090114110957.GA10071@gallagher.di.uoa.gr>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
Message-ID: <71c8744e8aba3edaf18fd1f6678389a1.squirrel@arekh.dyndns.org>



CC-ing a few more TEX folks

Le Mer 14 janvier 2009 12:09, Sarantis Paskalis a ?crit :
>
> Hello,
>
> Recently an effort has begun to the system infrastructure in fedora
> aware of each font shipped, and this shipment explicit mostly through
> subpackages
> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)
>
> Two of my packages are fonts primarily intended for LaTeX
> (tetex-font-kerkis and tetex-font-cm-lgc).  The guidelines suggest
> splitting the package in the Type 1 font files and TeX-support files.
>
> The font-related part is mostly sorted out (see
> https://bugzilla.redhat.com/show_bug.cgi?id=477461 )
>
> The TeX-related part consists of files (.sty, .tfm, .ovf, etc) to
> support the use of these fonts in LaTeX.
>
> Now, the draft for font naming guidelines suggests the srpm name to
> changed from tetex-font-cm-lgc to ctan-cm-lgc-fonts (to which I
> agree).
>
> The reason for this email is the last line in the proposed table,
> where
> the TeX related subpackage is to be named ctan-cm-lgc-tex.  I think
> this
> is inconsistent with the rest of the TeX world in fedora and would
> like
> some feedback as to what name would be preferable.
>
> My preference would be to put tex as a prefix and drop ctan as in
> tex-cm-lgc as it is rather obvious for TeX-related stuff; afterall we
> don't have many perl-cpan-perlmodule packages)
>
> What do other TeX packagers prefer?
>
> P.S. The only hint I found at existing guidelines is that the prefix
> tex- is preferable
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28TeX.29
>
> -- Sarantis

-- 
Nicolas Mailhot



From berrange at redhat.com  Wed Jan 14 11:25:48 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Wed, 14 Jan 2009 11:25:48 +0000
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
Message-ID: <20090114112547.GE24995@redhat.com>

On Wed, Jan 14, 2009 at 09:20:32AM -0200, Itamar Reis Peixoto wrote:
> hello guys
> 
> forwarding a very sweet mail
> 
> will be very cool to have qt compiled by fedora mingw, allowing
> development of window$ apps without window$, but the buildsystem of qt
> need some fix's

I'd encourage anyone interested in this to submit a mingw package for
review. Happy to advise / review the package, but we really do need
to get a broader base of maintainers for the MinGW packages rather
than 3 of us maintaining everything in MinGW.

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 nicolas.mailhot at laposte.net  Wed Jan 14 11:26:29 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Jan 2009 12:26:29 +0100 (CET)
Subject: TeX font package naming guidelines
In-Reply-To: <71c8744e8aba3edaf18fd1f6678389a1.squirrel@arekh.dyndns.org>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
	<71c8744e8aba3edaf18fd1f6678389a1.squirrel@arekh.dyndns.org>
Message-ID: <c032552364edb3c7e7f436f7c9e57ba1.squirrel@arekh.dyndns.org>



Le Mer 14 janvier 2009 12:21, Nicolas Mailhot a ?crit :
>
> CC-ing a few more TEX folks
>
> Le Mer 14 janvier 2009 12:09, Sarantis Paskalis a ?crit :
>>
>> Now, the draft for font naming guidelines suggests the srpm name to
>> changed from tetex-font-cm-lgc to ctan-cm-lgc-fonts (to which I
>> agree).

Just to be clear, the current draft after changes requested by FPC is
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2009-01-13)

-- 
Nicolas Mailhot



From rjones at redhat.com  Wed Jan 14 11:31:18 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Jan 2009 11:31:18 +0000
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
Message-ID: <20090114113118.GB11242@amd.home.annexia.org>

On Wed, Jan 14, 2009 at 09:20:32AM -0200, Itamar Reis Peixoto wrote:
> forwarding a very sweet mail
> 
> will be very cool to have qt compiled by fedora mingw, allowing
> development of window$ apps without window$, but the buildsystem of qt
> need some fix's

Was there a restriction before?

Anyway, yes we welcome someone porting Qt to Fedora MinGW ...

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From pertusus at free.fr  Wed Jan 14 11:37:16 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Jan 2009 12:37:16 +0100
Subject: TeX font package naming guidelines
In-Reply-To: <20090114110957.GA10071@gallagher.di.uoa.gr>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
Message-ID: <20090114113716.GE2860@free.fr>

On Wed, Jan 14, 2009 at 01:09:57PM +0200, Sarantis Paskalis wrote:
> Hello,
> 
> Now, the draft for font naming guidelines suggests the srpm name to 
> changed from tetex-font-cm-lgc to ctan-cm-lgc-fonts (to which I agree).

Looks good to me too.

> The reason for this email is the last line in the proposed table, where 
> the TeX related subpackage is to be named ctan-cm-lgc-tex.  I think this 
> is inconsistent with the rest of the TeX world in fedora and would like 
> some feedback as to what name would be preferable.

I would personally prefer

tex-cm-lgc

for the TeX specific stuff. It is not consistent with the srpm name
but it is consistent with the upstream (CTAN) package name, and it seems 
to me that it would be more consistent with non font tex pacakge names, 
and easier for user if it is called that way instead of ctan-cm-lgc-tex,
or ctan-cm-lgc-fonts-tex. tex-cm-lgc-fonts would also be possible, but
I would prefer using simply the CTAN package name. Unfortunatly, in 
that case, the .sty is called cmlgc.sty and not cm-lgc.sty, but it is
still closer to the package name.

Also there may be TeX packages that also have fonts, but consist mainly 
in tex stuff, in that case, I think that the srpm could be called 
tex-some-package
though the font parts should still be called
ctan-some-package-fonts-common
ctan-some-package-fonts-roman
...

--
Pat



From itamar at ispbrasil.com.br  Wed Jan 14 11:38:51 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Jan 2009 09:38:51 -0200
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <20090114113118.GB11242@amd.home.annexia.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
	<20090114113118.GB11242@amd.home.annexia.org>
Message-ID: <d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>

before it was gpl/commercial


On Wed, Jan 14, 2009 at 9:31 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
> On Wed, Jan 14, 2009 at 09:20:32AM -0200, Itamar Reis Peixoto wrote:
>> forwarding a very sweet mail
>>
>> will be very cool to have qt compiled by fedora mingw, allowing
>> development of window$ apps without window$, but the buildsystem of qt
>> need some fix's
>
> Was there a restriction before?
>
> Anyway, yes we welcome someone porting Qt to Fedora MinGW ...
>
> Rich.
>
> --
> Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
> Read my OCaml programming blog: http://camltastic.blogspot.com/
> Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
> http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From jonathan.underwood at gmail.com  Wed Jan 14 11:45:33 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 14 Jan 2009 11:45:33 +0000
Subject: TeX font package naming guidelines
In-Reply-To: <20090114113716.GE2860@free.fr>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
	<20090114113716.GE2860@free.fr>
Message-ID: <645d17210901140345n19472010ic834be7ef5136ec2@mail.gmail.com>

2009/1/14 Patrice Dumas <pertusus at free.fr>:
> On Wed, Jan 14, 2009 at 01:09:57PM +0200, Sarantis Paskalis wrote:
>> Hello,
>>
>> Now, the draft for font naming guidelines suggests the srpm name to
>> changed from tetex-font-cm-lgc to ctan-cm-lgc-fonts (to which I agree).
>
> Looks good to me too.
>
>> The reason for this email is the last line in the proposed table, where
>> the TeX related subpackage is to be named ctan-cm-lgc-tex.  I think this
>> is inconsistent with the rest of the TeX world in fedora and would like
>> some feedback as to what name would be preferable.
>
> I would personally prefer
>
> tex-cm-lgc
>
> for the TeX specific stuff. It is not consistent with the srpm name
> but it is consistent with the upstream (CTAN) package name, and it seems
> to me that it would be more consistent with non font tex pacakge names,
> and easier for user if it is called that way instead of ctan-cm-lgc-tex,
> or ctan-cm-lgc-fonts-tex. tex-cm-lgc-fonts would also be possible, but
> I would prefer using simply the CTAN package name. Unfortunatly, in
> that case, the .sty is called cmlgc.sty and not cm-lgc.sty, but it is
> still closer to the package name.
>
> Also there may be TeX packages that also have fonts, but consist mainly
> in tex stuff, in that case, I think that the srpm could be called
> tex-some-package
> though the font parts should still be called
> ctan-some-package-fonts-common
> ctan-some-package-fonts-roman

Yes, I whole heartedly agree with Pat.



From giallu at gmail.com  Wed Jan 14 12:00:27 2009
From: giallu at gmail.com (Gianluca Sforna)
Date: Wed, 14 Jan 2009 13:00:27 +0100
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <20090114113118.GB11242@amd.home.annexia.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
	<20090114113118.GB11242@amd.home.annexia.org>
Message-ID: <d5ad21470901140400x21e7f4bvb67df540221ca1af@mail.gmail.com>

On Wed, Jan 14, 2009 at 12:31 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
>
> Was there a restriction before?
>
> Anyway, yes we welcome someone porting Qt to Fedora MinGW ...
>

Do you know if there are enough mingw-* packages in rawhide to give it a try?

-- 
Gianluca Sforna

http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna



From yersinia.spiros at gmail.com  Wed Jan 14 12:00:35 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Wed, 14 Jan 2009 13:00:35 +0100
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <1231919919.12251.141.camel@ignacio.lan>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
Message-ID: <b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>

2009/1/14 Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

> On Wed, 2009-01-14 at 08:25 +0100, Tim Niemueller wrote:
> > Hello Fedora.
> >
> > I've just realized that the Lua module packages that I maintain, which
> > include a Lua module in form of a .so shared object, are not available
> > as multi-lib. I can only ever install the x86_64 version on my machine,
> > yum and packagekit do not provide the i386 version.
> >
> > As an example take lua-posix, it provides /usr/lib64/lua/5.1/posix.so.
> > Probably this does not match some pattern to make it understood as
> > multi-lib. Is there a way I can force this package to be pushed as
> > multi-lib package? Or is it a bug in my spec files and it should already
> > have been recognized as multi-lib?
>
> All multilib means is that the 64-bit repo contains 32-bit packages as
> well as the normal 64-bit packages. By default only packages with a
> -devel subpackage are considered multilib; I think you need to log a
> request with releng to make other packages multilib. And even then
> you'll need a good reason for them to make it so.


Sure ? httpd-devel exists but in the x86_64 branch does not exist httpd
i386. Or it is  an exception ? And if so why ?




>
> --
> Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
>
> PLEASE don't CC me; I'm already subscribed
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/e4ff20ae/attachment.htm>

From rjones at redhat.com  Wed Jan 14 12:09:23 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Jan 2009 12:09:23 +0000
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d5ad21470901140400x21e7f4bvb67df540221ca1af@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
	<20090114113118.GB11242@amd.home.annexia.org>
	<d5ad21470901140400x21e7f4bvb67df540221ca1af@mail.gmail.com>
Message-ID: <20090114120923.GA11850@amd.home.annexia.org>

On Wed, Jan 14, 2009 at 01:00:27PM +0100, Gianluca Sforna wrote:
> On Wed, Jan 14, 2009 at 12:31 PM, Richard W.M. Jones <rjones at redhat.com> wrote:
> >
> > Was there a restriction before?
> >
> > Anyway, yes we welcome someone porting Qt to Fedora MinGW ...
> >
> 
> Do you know if there are enough mingw-* packages in rawhide to give it a try?

As of about 1 hour ago there are approx. 10 mingw32 packages in Rawhide.

You can also add the temporary repository to your yum setup, which
will give you access to the full set of packages:

  [mingw]
  name=MinGW
  baseurl=http://www.annexia.org/tmp/mingw/fedora-10/
  enabled=1
  gpgcheck=0

Many programs can be cross compiled simply by doing:

  # yum install mingw32-{any dependencies it needs}
  $ mingw32-configure
  $ make

More details here:

  http://fedoraproject.org/wiki/MinGW
  http://camltastic.blogspot.com/2008/10/mingw-compile-software-for-windows.html
  http://camltastic.blogspot.com/2008/11/common-mistakes-cross-compiling-mingw.html

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 fedora at camperquake.de  Wed Jan 14 12:18:11 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 14 Jan 2009 13:18:11 +0100
Subject: Problems with X font handling
In-Reply-To: <uar046x62l.ln2@ppp1053.in.ipex.cz>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<uar046x62l.ln2@ppp1053.in.ipex.cz>
Message-ID: <20090114131811.2e24163a@dhcp03.addix.net>

Hi.

On Wed, 14 Jan 2009 11:28:14 +0100, Matej Cepl wrote:

> individual font packages should go to /etc/X11/fontpath.d. If you 
> eliminate "Files" section, stop xfs, restart Xorg, and something 
> doesn't work, THEN file a bug about it.

No xorg.conf, no xfs, Xorg.0.log says:

(==) No FontPath specified. Using compiled-in default.
(==) FontPath set to:
        built-ins



From nicolas.mailhot at laposte.net  Wed Jan 14 12:25:17 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Jan 2009 13:25:17 +0100 (CET)
Subject: TeX font package naming guidelines
In-Reply-To: <20090114113716.GE2860@free.fr>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
	<20090114113716.GE2860@free.fr>
Message-ID: <7d8c6bdfeb8472faea9d4f0d315576ab.squirrel@arekh.dyndns.org>



Le Mer 14 janvier 2009 12:37, Patrice Dumas a ?crit :

> Also there may be TeX packages that also have fonts, but consist
> mainly
> in tex stuff, in that case, I think that the srpm could be called
> tex-some-package
> though the font parts should still be called
> ctan-some-package-fonts-common
> ctan-some-package-fonts-roman

ctan-some-package-fonts-common
ctan-some-package-roman-fonts

according to the draft for the fonts part.

Anyway I don't want to be involved in the TEX parts (that's one reason
I pushed for a clean fonts/other stuff split) so I'll be ok with
whatever TEX subpackage name TEX people agree on (please update this
line of the table accordingly, I don't want to be involved more least
people start expecting me to write TEX guidelines)

-- 
Nicolas Mailhot



From kanarip at kanarip.com  Wed Jan 14 12:26:14 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 14 Jan 2009 13:26:14 +0100
Subject: Spins SIG Meeting(s) / Agenda!
Message-ID: <496DD9E6.2050800@kanarip.com>

The Spins SIG is going to have regular, bi-weekly meetings. I've chosen 
Mondays at 18:00 UTC, on even weeks, and it will not take more then one 
hour.

Obviously, we can pre-discuss most of the items on the agenda on our 
mailing list fedora-spins -at- lists.fedoraproject.org.

With help of several key people in the current Spins process, including 
Process-Guru and current Feature Wrangler John Poelstra, we've come up 
with a real Spins Process during this last FUDCon.

If you are a member of Release Engineering, Quality Assurance, FESCo or 
Infrastructure, I would like you to attend.

Our first meeting (in the series of regular meetings) would be January 
19th, 18:00 UTC, for which I'm going to set the Agenda now:

== Agenda ==

# Finalizing Spins Process[1], vote
#* Writing up details on the Wiki, where necessary
#* Writing our Spins_SIG_Review_Checklist, and what to do if something 
isn't covered
#* Maintainer responsiveness and responsibilities for current releases
#* Checklist of DOs and DONTs, SHOULDs and SHOULD NOTs[2]
#* Defining permanent vs. non-permanent spins, the procedure to change 
status, and the consequences for the Spins Process.
# Set our final meeting time and schedule, vote
# Determine our workflow (using the spin-kickstarts Trac instance?)
#* Branching and tagging (based on milestones to be determined)
#* Creating daily spins for compose tests and reporting results
#* Having maintainers (re-)create spins regularly for tests and 
collecting results
# Determine our process for recurring releases and reviewing current 
spins for the upcoming release
# Current Spins Requests:
#* Games Spin
#** Has been previously approved
#** Failed during Fedora 10
#** Revamped for Fedora 11 by Bruno Wolff III
#* A dozen or so localized spins
#** http://sundaram.fedorapeople.org/spins/
# Review of all current spins
#* Who's the maintainer of each spin, and where can we reach them?
#* Fedora AOS
#* Fedora BrOffice.org
#* Fedora Developer
#* Fedora Education Math
#* Fedora Electronic Lab
#* Fedora Games
#* Fedora Sugar
#* Fedora XFCE

This agenda is also available (in a more readable format) on:

https://fedoraproject.org/wiki/Spins_SIG_Meeting_2009-01-19

Additional Agenda items you may have can go to that Wiki page as well.

Again, if you are a member of Release Engineering, Quality Assurance, 
FESCo or Infrastructure, I would like you to attend also. In the new 
process, the Spins SIG meetings are where you can say "no" or "yes" to a 
spin, or raise concerns. I would like to know if you agree with that. 
Also, I'd like to know if you (or a delegate of your team) wants to 
attend our meetings, or settles with being notified by the Spins SIG 
every step of the way.

Now, in my Agenda, the time for our first meeting would already conflict 
with a very important appointment I have with Max next week -which I'm 
not going to reschedule, it includes dinner :P I'll make it work one way 
or the other, though, so there'll definitely be a meeting at January 
19th, 18:00 UTC. Be there or forever hold your peace ;-)

Thank you,

Kind regards,

Jeroen van Meeuwen
-kanarip

[1] http://fedoraproject.org/wiki/Spins_Process
[2] http://fedoraproject.org/wiki/Spins_Guidelines



From sds at tycho.nsa.gov  Wed Jan 14 14:02:32 2009
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 14 Jan 2009 09:02:32 -0500
Subject: SELinux in mock
In-Reply-To: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
Message-ID: <1231941752.31192.4.camel@localhost.localdomain>

On Tue, 2009-01-13 at 22:08 -0700, Jerry James wrote:
> Josh Boyer was kind enough to give me a login on a ppc64 machine so I
> can try to debug the issue I'm having with GCL.  Unfortunately, I
> cannot even get off the ground.  I'm using a 'mock -r
> fedora-rawhide-ppc64' command to try things out.  Inside the chroot, I
> see this:
> 
> $ mock -r fedora-rawhide-ppc64 --shell
> INFO: mock.py version 0.9.13 starting...
> State Changed: init plugins
> State Changed: start
> State Changed: lock buildroot
> mock-chroot> selinuxenabled
> mock-chroot> echo $?
> 0
> mock-chroot> /usr/sbin/semodule -i /tmp/gcl.pp
> /usr/sbin/semodule: SELinux policy is not managed or store cannot be accessed.
> 
> 
> How is that supposed to work?  This is blocking the GCL build, which
> has to change dumped images to type gcl_exec_t when SELinux is active
> (checked with selinuxenabled).  If the policy is not managed or the
> store cannot be accessed, then selinuxenabled should be setting its
> exit code to 1, should it not?  As it is, the GCL build fails when
> trying to invoke chcon because selinuxenabled is apparently lying.

selinuxenabled just tests for the presence of SELinux in the kernel by
probing for the selinuxfs filesystem (typically mounted on /selinux).

semodule is testing whether the policy store
(under /etc/selinux/$SELINUXTYPE/modules/active) exists and can be
accessed by the current process before proceeding to try to install your
module.  strace semodule -i /tmp/gcl.pp would show the precise point of
failure, but offhand I'd guess that /etc/selinux/targeted/modules/active
either does not exist or is not readable by the process.

-- 
Stephen Smalley
National Security Agency



From jkeating at redhat.com  Wed Jan 14 14:28:46 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Jan 2009 06:28:46 -0800
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
Message-ID: <1231943326.5086.49.camel@localhost.localdomain>

On Wed, 2009-01-14 at 13:00 +0100, yersinia wrote:
> Sure ? httpd-devel exists but in the x86_64 branch does not exist httpd
> i386. Or it is  an exception ? And if so why ?

That would only happen if the httpd-devel.i386 package had no arch
specific requires upon the httpd.i386 package.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/ff294bad/attachment.sig>

From jreznik at redhat.com  Wed Jan 14 14:39:16 2009
From: jreznik at redhat.com (Jaroslav Reznik)
Date: Wed, 14 Jan 2009 15:39:16 +0100
Subject: KDE-SIG weekly report (3/2009)
Message-ID: <200901141539.24542.jreznik@redhat.com>

This is a report of the weekly KDE-SIG-Meeting with a summary of the 
topics that were discussed. If you want to add a comment please reply
?to this email or add it to the related meeting page.

----------------------------------------------------------------------------------

= Weekly KDE Summary =

Week: 3/2009

Time: 2009-01-13 16:00 UTC

Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-01-13

Meeting log: https://fedoraproject.org/w/uploads/c/c2/KDE-SIG-2009-01-13.txt

----------------------------------------------------------------------------------

= Participants = 

- Than Ngo 
- Rex Dieter 
- Jaroslav Reznik 
- Kevin Kofler 
- Mathstuf 
- Steven Parrish 
- Lukas Tinkl

----------------------------------------------------------------------------------

= Agenda =
 
* KDE 4.1.4 - anything to add before it goes stable? 
* kde42 blocker, comments/additions [1] 
* kdesdk (Umbrello) build failure in Rawhide due to boost 
* mysql-server requires for akonadi 

= Summary =
* kudos to SMParrish for recent bug triage 

* KDE 4.1.4 
 - respin of kdebase (kdebase-4.1.4-2.fc{9,10}) due to upstream changes to 
release (regression) 
 - current status: testing 

*kde42 blocker [1]
 - jreznik is working on libv4l2 support for Kopete, but it's not considered 
as "the must be done" blocker (rhbz#475623) 
 -- xine-lib needs libv4l patch too 
 - the indi support in kdeedu isn't strictly a blocker but it's a regression 
(rhbz#478539) 
 - desktop effects defaults bug should be filled 

* desktop effects defaults 
 - considering defaults for F9 & F10 to be off and on for F11+ or just on by 
default everywhere their "self-test" passes? 
 - but test crashes X server sometimes (worst case) 
 - ltinkl discuss it with seli 
 - decision postponed until ltinkl gets Seli's opinion 
 
* mysql-server requires for akonadi 
 - akonadi does not work without mysql server and there is no alternative 
 -- splitting packages which requires akonadi? 
 - kdepim requires akonadi 
 - gnome user use case - they don't need everything from KDE 
 -- leads to discussion about splitting of System Settings - KCM modules all 
around KDE's sources 
 
* (Umbrello) build failure in Rawhide due to boost 
 - Rawhide got a new boost - Umbrello uses Boost (at compile time only, it 
uses some templated headers from it) and fails 
 - it's not clear if it is Umbrello, Boost, gcc bug 
 - problem with STATIC_ASSERTION_FAILURE<false> template [2]

----------------------------------------------------------------------------------

= Next Meeting =

http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2009-01-20

----------------------------------------------------------------------------------

= Links =

[1] https://bugzilla.redhat.com/showdependencytree.cgi?id=kde42
[2] 
http://websvn.kde.org/trunk/KDE/kdesdk/umbrello/umbrello/codeimport/kdevcppparser/preprocesslexer.h?r1=887978&r2=902899 



From rdieter at math.unl.edu  Wed Jan 14 15:17:19 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 14 Jan 2009 09:17:19 -0600
Subject: Lua module packages are not multi-lib, how to do?
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
Message-ID: <gkkvm7$6ta$1@ger.gmane.org>

Ignacio Vazquez-Abrams wrote:


> All multilib means is that the 64-bit repo contains 32-bit packages as
> well as the normal 64-bit packages. By default only packages with a
> -devel subpackage are considered multilib

I used to think that too, but it seems the rules have changed (recently?) to
also include any package that includes shlibs.

-- Rex



From skasal at redhat.com  Wed Jan 14 15:36:01 2009
From: skasal at redhat.com (Stepan Kasal)
Date: Wed, 14 Jan 2009 16:36:01 +0100
Subject: orphaning perl-Math-Vec
In-Reply-To: <e117404e0901122250l4b539eafye8aa1eb8ca3929c8@mail.gmail.com>
References: <e117404e0901122250l4b539eafye8aa1eb8ca3929c8@mail.gmail.com>
Message-ID: <20090114153601.GA32357@camelia.ucw.cz>

Hello,

> I just orphaned perl-Math-Vec too.

I'm taking this.

Stepan



From mcepl at redhat.com  Wed Jan 14 15:34:14 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Wed, 14 Jan 2009 16:34:14 +0100
Subject: Problems with X font handling
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<uar046x62l.ln2@ppp1053.in.ipex.cz>
	<20090114131811.2e24163a@dhcp03.addix.net>
Message-ID: <m8d146xvto.ln2@ppp1053.in.ipex.cz>

On 2009-01-14, 12:18 GMT, Ralf Ertzinger wrote:
> No xorg.conf, no xfs, Xorg.0.log says:
>
> (==) No FontPath specified. Using compiled-in default.
> (==) FontPath set to:
>         built-ins

And? What's the error (if there is one) from xemacs (or what was 
your problematic application)?

Mat?j



From skasal at redhat.com  Wed Jan 14 16:06:13 2009
From: skasal at redhat.com (Stepan Kasal)
Date: Wed, 14 Jan 2009 17:06:13 +0100
Subject: orphaning all my packages
In-Reply-To: <20081216094739.GA3877@free.fr>
References: <20081216094739.GA3877@free.fr>
Message-ID: <20090114160613.GA523@camelia.ucw.cz>


Hallo,

  I'm taking these (in devel):

pmount
perl-Text-Unidecode
perl-Parse-Yapp
perl-Math-Symbolic
perl-Math-MatrixReal
perl-HTML-FormatText-WithLinks
perl-Heap
perl-File-NFSLock
perl-File-MimeInfo
perl-File-DesktopEntry
perl-File-BaseDir
perl-Feed-Find
perl-Algorithm-CurveFit
ooo2txt
libsx
intuitively
html2ps
halevt
fcron
debootstrap
bitmap
bibexport
asa

That does not imply that I support the statement that
> [...] fcron [...] strategic for fedora.

Have a nice day,
	Stepan Kasal



From loganjerry at gmail.com  Wed Jan 14 16:10:21 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 09:10:21 -0700
Subject: PPC64 virtual machine
In-Reply-To: <iyeiz6jpcl.fsf@allele2.eebweb.arizona.edu>
References: <870180fe0901101030u3f876aa7vf3b0b48d10a2a46e@mail.gmail.com>
	<iyeiz6jpcl.fsf@allele2.eebweb.arizona.edu>
Message-ID: <870180fe0901140810x351e938ag5d48b90ba3a5ccb6@mail.gmail.com>

On Wed, Jan 14, 2009 at 12:53 AM, Alex Lancaster
<alexl at users.sourceforge.net> wrote:
> If it currently works on x86_64, you might want to take ownership of
> of, close or otherwise comment on this open bug:
>
> http://bugzilla.redhat.com/show_bug.cgi?id=428539
>
> Alex
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

Sorry, I thought I had taken ownership of all GCL bugs.  I've got that
one now.  Give me another day or two to try to get a successful build
on the ppc64 platform.  If I don't succeed by then, I'll do the
necessary ExcludeArch and push the Intel builds.
-- 
Jerry James
http://loganjerry.googlepages.com/



From zaitcev at redhat.com  Wed Jan 14 16:19:16 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 14 Jan 2009 09:19:16 -0700
Subject: Problems with X font handling
In-Reply-To: <uar046x62l.ln2@ppp1053.in.ipex.cz>
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<uar046x62l.ln2@ppp1053.in.ipex.cz>
Message-ID: <20090114091916.795328bb.zaitcev@redhat.com>

On Wed, 14 Jan 2009 11:28:14 +0100, Matej Cepl <mcepl at redhat.com> wrote:
> On 2009-01-13, 16:29 GMT, Pete Zaitcev wrote:

> > Section "Files"
> >         FontPath     "/usr/share/X11/fonts/75dpi"
> >         FontPath     "unix/:7100"
> > EndSection
> 
> Try to just eliminate "Files" section altogether. You then get in 
> /var/log/Xorg.0.log something like this:
> 
>     (==) No FontPath specified.  Using compiled-in default.
>     (==) FontPath set to:
>             catalogue:/etc/X11/fontpath.d,
>             built-ins

This is completely beside the point. The problem occures in the
part of the log that you skipped and I'm going to re-insert:

> > [dix] Could not init font path element /usr/share/X11/fonts/75dpi, removing from list!
> > [dix] Could not init font path element unix/:7100, removing from list!

I'm sorry to repeat it for you, but X server is badly broken
(or was broken, for the documented version).

> Pete, xfs is not manadatory anymore and it is not installed per 
> default since somewhere in F9. All configuration files for 
> individual font packages should go to /etc/X11/fontpath.d. If you 
> eliminate "Files" section, stop xfs, restart Xorg, and something 
> doesn't work, THEN file a bug about it.

Not that I care about it, since I don't use legacy applications,
but you're dead wrong here as long as the capability to use Files
and FontPath is documented. Ditto xfs.

-- Pete



From konrad at tylerc.org  Wed Jan 14 16:37:43 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 14 Jan 2009 08:37:43 -0800
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<20090114113118.GB11242@amd.home.annexia.org>
	<d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
Message-ID: <200901140837.43622.konrad@tylerc.org>

On Wednesday 14 January 2009 03:38:51 am Itamar Reis Peixoto wrote:
> before it was gpl/commercial

How is that a problem?

-- 
Conrad Meyer <konrad at tylerc.org>




From itamar at ispbrasil.com.br  Wed Jan 14 16:41:25 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Jan 2009 14:41:25 -0200
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <200901140837.43622.konrad@tylerc.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<20090114113118.GB11242@amd.home.annexia.org>
	<d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
	<200901140837.43622.konrad@tylerc.org>
Message-ID: <d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>

if you want to develop  a commercial program the you can't use the gpl version

with lgpl you you can develop comercial program's without need to
release the source code.


On Wed, Jan 14, 2009 at 2:37 PM, Conrad Meyer <konrad at tylerc.org> wrote:
> On Wednesday 14 January 2009 03:38:51 am Itamar Reis Peixoto wrote:
>> before it was gpl/commercial
>
> How is that a problem?
>
> --
> Conrad Meyer <konrad at tylerc.org>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From pemboa at gmail.com  Wed Jan 14 16:44:06 2009
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 14 Jan 2009 10:44:06 -0600
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<20090114113118.GB11242@amd.home.annexia.org>
	<d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
	<200901140837.43622.konrad@tylerc.org>
	<d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>
Message-ID: <16de708d0901140844k1f102cata0a87e71597715da@mail.gmail.com>

On Wed, Jan 14, 2009 at 10:41 AM, Itamar Reis Peixoto
<itamar at ispbrasil.com.br> wrote:
> if you want to develop  a commercial program the you can't use the gpl version
>
> with lgpl you you can develop comercial program's without need to
> release the source code.

GPL is not the opposite of commercial.

-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pemboa at gmail.com  Wed Jan 14 16:43:17 2009
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 14 Jan 2009 10:43:17 -0600
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140320w6b9183bfo36a1b7468efcacba@mail.gmail.com>
	<20090114113118.GB11242@amd.home.annexia.org>
	<d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
Message-ID: <16de708d0901140843x53386e51na7b4e1db6b71c61e@mail.gmail.com>

On Wed, Jan 14, 2009 at 5:38 AM, Itamar Reis Peixoto
<itamar at ispbrasil.com.br> wrote:
> before it was gpl/commercial

It was GPL (v3 I think) and closed source. There was never a
restriction on doing commercial OSS as far as I am aware.


-- 
Fedora 9 : sulphur is good for the skin
( www.pembo13.com )



From pertusus at free.fr  Wed Jan 14 16:49:18 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Jan 2009 17:49:18 +0100
Subject: orphaning all my packages
In-Reply-To: <20090114160613.GA523@camelia.ucw.cz>
References: <20081216094739.GA3877@free.fr>
	<20090114160613.GA523@camelia.ucw.cz>
Message-ID: <20090114164918.GA2834@free.fr>

On Wed, Jan 14, 2009 at 05:06:13PM +0100, Stepan Kasal wrote:
> 
> Hallo,
> 
>   I'm taking these (in devel):
> 
> pmount
> perl-Text-Unidecode

Additionally, this one is a texi2html dependency, and therefore, 
hopefully, soon a makeinfo dependency.

> perl-Parse-Yapp
> perl-Math-Symbolic
> perl-Math-MatrixReal
> perl-HTML-FormatText-WithLinks
> perl-Heap
> perl-File-NFSLock
> perl-File-MimeInfo
> perl-File-DesktopEntry
> perl-File-BaseDir
> perl-Feed-Find
> perl-Algorithm-CurveFit
> ooo2txt
> libsx
> intuitively
> html2ps
> halevt
> fcron
> debootstrap
> bitmap
> bibexport
> asa

Nice, and thanks. Most of my packages are owned now.

> That does not imply that I support the statement that
> > [...] fcron [...] strategic for fedora.

;-)

--
Pat



From konrad at tylerc.org  Wed Jan 14 16:53:58 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 14 Jan 2009 08:53:58 -0800
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <16de708d0901140843x53386e51na7b4e1db6b71c61e@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<d3ceea380901140338m133e5d78s266550e64efe0078@mail.gmail.com>
	<16de708d0901140843x53386e51na7b4e1db6b71c61e@mail.gmail.com>
Message-ID: <200901140853.58987.konrad@tylerc.org>

On Wednesday 14 January 2009 08:43:17 am Arthur Pemberton wrote:
> On Wed, Jan 14, 2009 at 5:38 AM, Itamar Reis Peixoto
>
> <itamar at ispbrasil.com.br> wrote:
> > before it was gpl/commercial
>
> It was GPL (v3 I think) and closed source. There was never a
> restriction on doing commercial OSS as far as I am aware.

Nor does the GPL prevent it from being compiled for windows, as far as I can 
see.

-- 
Conrad Meyer <konrad at tylerc.org>




From konrad at tylerc.org  Wed Jan 14 16:53:33 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 14 Jan 2009 08:53:33 -0800
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<200901140837.43622.konrad@tylerc.org>
	<d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>
Message-ID: <200901140853.33577.konrad@tylerc.org>

On Wednesday 14 January 2009 08:41:25 am Itamar Reis Peixoto wrote:
> if you want to develop  a commercial program the you can't use the gpl
> version
>
> with lgpl you you can develop comercial program's without need to
> release the source code.

How is that a problem w.r.t. to it being packaged for mingw, though?

-- 
Conrad Meyer <konrad at tylerc.org>




From mike at miketc.net  Wed Jan 14 16:56:36 2009
From: mike at miketc.net (Mike Chambers)
Date: Wed, 14 Jan 2009 10:56:36 -0600
Subject: Keyboard shortcut buttons logs out of Gnome/X
Message-ID: <1231952196.4947.6.camel@scrappy.miketc.net>

I have a Microsoft Wireless Desktop keyboard/mouse 2000.  And in F10 the
keyboard shortcuts (buttons to start email, browser, volume adjustments,
etc..) work just fine.

In Rawhide, if I hit one of them, it logs me out of Gnome/X and back to
the login screen.  I tried setting the keyboard to the MS Wireless
Multimedia keyboard 1A but that doesn't help.  Not sure it matters what
I select.  Any ideas  and what component would I file a bug against if I
need to?

-- 
Mike Chambers
Fedora Project - Ambassador, Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From itamar at ispbrasil.com.br  Wed Jan 14 16:58:58 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 14 Jan 2009 14:58:58 -0200
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <200901140853.33577.konrad@tylerc.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<200901140837.43622.konrad@tylerc.org>
	<d3ceea380901140841u44c533e5q776a90c1a7c7ddc1@mail.gmail.com>
	<200901140853.33577.konrad@tylerc.org>
Message-ID: <d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>

> How is that a problem w.r.t. to it being packaged for mingw, though?

the build system used by qt (windows version) is not compatible with linux

it compile fine under windows, but doesn't work under linux.




------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From vonbrand at inf.utfsm.cl  Wed Jan 14 17:02:28 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 14 Jan 2009 14:02:28 -0300
Subject: TeX font package naming guidelines
In-Reply-To: <7d8c6bdfeb8472faea9d4f0d315576ab.squirrel@arekh.dyndns.org>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
	<20090114113716.GE2860@free.fr>
	<7d8c6bdfeb8472faea9d4f0d315576ab.squirrel@arekh.dyndns.org>
Message-ID: <200901141702.n0EH2Six031570@laptop14.inf.utfsm.cl>

Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

[...]

> ctan-some-package-fonts-common
> ctan-some-package-roman-fonts
> 
> according to the draft for the fonts part.

Sounds wrong... either all fonts-foo or all bar-fonts, not mix and
match. Please?
-- 
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 konrad at tylerc.org  Wed Jan 14 17:05:54 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Wed, 14 Jan 2009 09:05:54 -0800
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<200901140853.33577.konrad@tylerc.org>
	<d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>
Message-ID: <200901140905.54967.konrad@tylerc.org>

On Wednesday 14 January 2009 08:58:58 am Itamar Reis Peixoto wrote:
> > How is that a problem w.r.t. to it being packaged for mingw, though?
>
> the build system used by qt (windows version) is not compatible with linux
>
> it compile fine under windows, but doesn't work under linux.

Ah, interesting. I wonder why the linux version doesn't work with mingw.

-- 
Conrad Meyer <konrad at tylerc.org>




From rjones at redhat.com  Wed Jan 14 17:12:40 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 14 Jan 2009 17:12:40 +0000
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <200901140905.54967.konrad@tylerc.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<200901140853.33577.konrad@tylerc.org>
	<d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>
	<200901140905.54967.konrad@tylerc.org>
Message-ID: <20090114171240.GA15391@amd.home.annexia.org>

On Wed, Jan 14, 2009 at 09:05:54AM -0800, Conrad Meyer wrote:
> On Wednesday 14 January 2009 08:58:58 am Itamar Reis Peixoto wrote:
> > > How is that a problem w.r.t. to it being packaged for mingw, though?
> >
> > the build system used by qt (windows version) is not compatible with linux
> >
> > it compile fine under windows, but doesn't work under linux.
> 
> Ah, interesting. I wonder why the linux version doesn't work with mingw.

Likely because the Linux version of Qt makes POSIX & X11 calls which
don't exist under Windows.  So we need to start with the Windows
version of Qt which uses the Win32 APIs, but that will have a build
system that is only applicable to Windows.

Actually the above is mostly speculation, but is typically the case
for such things, and is the reason why cross-compiling is a non-
trivial exercise.

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 dbn.lists at gmail.com  Wed Jan 14 17:20:03 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Wed, 14 Jan 2009 09:20:03 -0800
Subject: font problem in rawhide
In-Reply-To: <Pine.LNX.4.58.0901141147490.8405@venus.brc>
References: <Pine.LNX.4.58.0901141147490.8405@venus.brc>
Message-ID: <91705d080901140920k19a3bb59ydc6ea9c3577c5354@mail.gmail.com>

On Wed, Jan 14, 2009 at 2:55 AM, Zoltan Kota <z.kota at gmx.net> wrote:
> Hi,
>
> pybliographer has a font problem in Rawhide. It is ok with f10.
> The error message in the terminal:
> ...
>  File "/usr/share/pybliographer/Pyblio/ConfDir/GnomeUI.py", line 49, in
> <module>
>    gtk.gdk.Font ('-*-*-*-r-normal-*-*-*-*-*-c-*-iso8859-1'))
> RuntimeError: could not create GdkFont object
>
>
> Is it related to the rawhide fonts issue discussed in an other thread? Or
> where should I look around?

I would wager that this has to do with the other xserver thread. Since
it's not initializing the font file registration, I doubt that any
client can use anything besides the fixed builtins.

--
Dan



From notting at redhat.com  Wed Jan 14 17:26:08 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Jan 2009 12:26:08 -0500
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <gkkvm7$6ta$1@ger.gmane.org>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<gkkvm7$6ta$1@ger.gmane.org>
Message-ID: <20090114172608.GF19783@nostromo.devel.redhat.com>

Rex Dieter (rdieter at math.unl.edu) said: 
> > All multilib means is that the 64-bit repo contains 32-bit packages as
> > well as the normal 64-bit packages. By default only packages with a
> > -devel subpackage are considered multilib
> 
> I used to think that too, but it seems the rules have changed (recently?) to
> also include any package that includes shlibs.

What packages are selected as multilib is determined by:
  http://git.fedorahosted.org/git/?p=mash;a=blob_plain;f=mash/multilib.py;hb=HEAD

Fedora uses the 'devel' method (which also does all the checks in the
'runtime' method.)

Bill



From loganjerry at gmail.com  Wed Jan 14 17:30:04 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 10:30:04 -0700
Subject: SELinux in mock
In-Reply-To: <1231941752.31192.4.camel@localhost.localdomain>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
	<1231941752.31192.4.camel@localhost.localdomain>
Message-ID: <870180fe0901140930je234b81j6e0b1fc457ddf35@mail.gmail.com>

On Wed, Jan 14, 2009 at 7:02 AM, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> selinuxenabled just tests for the presence of SELinux in the kernel by
> probing for the selinuxfs filesystem (typically mounted on /selinux).
>
> semodule is testing whether the policy store
> (under /etc/selinux/$SELINUXTYPE/modules/active) exists and can be
> accessed by the current process before proceeding to try to install your
> module.  strace semodule -i /tmp/gcl.pp would show the precise point of
> failure, but offhand I'd guess that /etc/selinux/targeted/modules/active
> either does not exist or is not readable by the process.

Thanks, Stephen and Jesse.  This is helpful information.  So here's
the problem I'm having.  I have defined a policy that creates process
type gcl_t and file type gcl_exec_t.  This policy allows GCL to do a
number of strange things to memory (execheap, for example).  GCL
creates multiple dump files as it builds, each leading up to the final
dump file to be packaged.  Each dump file has to be labeled gcl_exec_t
if the build is happening on an SELinux-enabled system.  I patched the
GCL makefiles to include lines like this:

       if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then \
               chcon -t gcl_exec_t $@; \
       fi

This works fine when I do a normal build on my home (SELinux-enabled)
machine.  It also works on the koji builders, where SELinux is not
enabled.  However, it is failing in mock on an SELinux-enabled
machine.  How should I change the test so that chcon isn't run if it
is going to fail?  Or should I just ignore chcon failures?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From notting at redhat.com  Wed Jan 14 17:36:35 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Jan 2009 12:36:35 -0500
Subject: Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496DD9E6.2050800@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
Message-ID: <20090114173635.GG19783@nostromo.devel.redhat.com>

Jeroen van Meeuwen (kanarip at kanarip.com) said: 
> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen  
> Mondays at 18:00 UTC, on even weeks, and it will not take more then one  
> hour.

...

> If you are a member of Release Engineering, Quality Assurance, FESCo or  
> Infrastructure, I would like you to attend.

releng meetings are Mondays, 18:00 UTC already. See
  http://fedoraproject.org/wiki/ReleaseEngineering

Bill



From tgl at redhat.com  Wed Jan 14 17:39:30 2009
From: tgl at redhat.com (Tom Lane)
Date: Wed, 14 Jan 2009 12:39:30 -0500
Subject: Heads up: MySQL 5.1 coming soon to rawhide
Message-ID: <17597.1231954770@sss.pgh.pa.us>

I intend to push mysql 5.1.30 into rawhide next week, as soon as the
alpha freeze has lifted.  This involves an ABI break: libmysqlclient.so
has increased its major version number from 15 to 16.  According to
pkgdb the packages listed below will require rebuilds.  (Hopefully just
a rebuild and not source-code changes...)  I'm willing to launch
rebuilds for anyone who can't do it themselves in a timely fashion;
let me know if you want me to.

Upstream documentation about changes since 5.0.x can be found here:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html

If you want to do some early testing, there are provisional scratch
builds for rawhide here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1051162
or you can pull mysql/devel from CVS (changes are committed, but
not tagged yet).

			regards, tom lane


Io-language-mysql	salimma
MySQL-python	tgl
amarok	abompard
apr-util-mysql	jorton
bacula-director-mysql	ixs
bacula-storage-mysql	ixs
bind-sdb	atkac
callweaver-mysql	dwmw2
cherokee	pali
collectd-mysql	rjones
cyrus-sasl-sql	tmraz
dbmail-mysql	bjohnson
dovecot-mysql	sharkcz
exim	dwmw2
flow-tools	stingray
freeradius-mysql	jdennis
gambas2	spot
gammu	laxathom
gdal	rezso
gmyth	hadess
gnokii-smsd-mysql	snirkel
grass	rezso
jabberd	adrian
koffice-kexi-driver-mysql	awjb
libdbi-dbd-mysql	tgl
libgda-mysql	denis
libnss-mysql	ondrejj
libpreludedb-mysql	sgrubb
lighttpd-mod_mysql_vhost	thias
lua-sql-mysql	timn
mapserver	rezso
mediatomb	mwiriadi
mod_auth_mysql	jorton
mysql++	remi
mysql-connector-odbc	tgl
nagios-plugins-mysql	mmcgrath
ntop	rakesh
openser-mysql	peter
pam_mysql	stingray
pdns-backend-mysql	ruben
perl-DBD-MySQL	kasal
php-mapserver	jorton
php-mysql	jorton
postfix	mlichvar
proftpd-mysql	thias
pure-ftpd	abompard
qt-mysql	than
qt3-MySQL	than
redland	thomasvs
rekall-mysql	spot
rsyslog-mysql	theinric
ruby-mysql	orion
ser-mysql	ixs
showimg-mysql	abompard
snort-bloat	ausil
snort-mysql	ausil
snort-mysql+flexresp	ausil
totem-mythtv	hadess
ulogd-mysql	abompard
zabbix	sharkcz
zoneminder	mebourne



From dr.diesel at gmail.com  Wed Jan 14 17:43:34 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Wed, 14 Jan 2009 12:43:34 -0500
Subject: Heads up: MySQL 5.1 coming soon to rawhide
In-Reply-To: <17597.1231954770@sss.pgh.pa.us>
References: <17597.1231954770@sss.pgh.pa.us>
Message-ID: <2a28d2ab0901140943uede01a9mb2375c4b83b11f27@mail.gmail.com>

On Wed, Jan 14, 2009 at 12:39 PM, Tom Lane <tgl at redhat.com> wrote:

> I intend to push mysql 5.1.30 into rawhide next week, as soon as the
> alpha freeze has lifted.  This involves an ABI break: libmysqlclient.so
> has increased its major version number from 15 to 16.  According to
> pkgdb the packages listed below will require rebuilds.  (Hopefully just
> a rebuild and not source-code changes...)  I'm willing to launch
> rebuilds for anyone who can't do it themselves in a timely fashion;
> let me know if you want me to.
>
>
Any plans to push it to F10 at some point?

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/7a301923/attachment.htm>

From blc at redhat.com  Wed Jan 14 17:43:51 2009
From: blc at redhat.com (Brendan Conoboy)
Date: Wed, 14 Jan 2009 10:43:51 -0700
Subject: Nokia to License Qt Under LGPL
In-Reply-To: <20090114171240.GA15391@amd.home.annexia.org>
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>	<200901140853.33577.konrad@tylerc.org>	<d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>	<200901140905.54967.konrad@tylerc.org>
	<20090114171240.GA15391@amd.home.annexia.org>
Message-ID: <496E2457.4050109@redhat.com>

Richard W.M. Jones wrote:
> Likely because the Linux version of Qt makes POSIX & X11 calls which
> don't exist under Windows.  So we need to start with the Windows
> version of Qt which uses the Win32 APIs, but that will have a build
> system that is only applicable to Windows.

If it's POISX/X11 assumptions, Cygwin could be used.  GPL only, of course.

-- 
Brendan Conoboy / Red Hat, Inc. / blc at redhat.com



From limb at jcomserv.net  Wed Jan 14 17:47:23 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Wed, 14 Jan 2009 11:47:23 -0600 (CST)
Subject: Heads up: MySQL 5.1 coming soon to rawhide
In-Reply-To: <17597.1231954770@sss.pgh.pa.us>
References: <17597.1231954770@sss.pgh.pa.us>
Message-ID: <d0c4ab73fbf661e5662789bbc2dbb204.squirrel@mail.jcomserv.net>

Will you give us a shout here right after yuo do it?


> I intend to push mysql 5.1.30 into rawhide next week, as soon as the
> alpha freeze has lifted.  This involves an ABI break: libmysqlclient.so
> has increased its major version number from 15 to 16.  According to
> pkgdb the packages listed below will require rebuilds.  (Hopefully just
> a rebuild and not source-code changes...)  I'm willing to launch
> rebuilds for anyone who can't do it themselves in a timely fashion;
> let me know if you want me to.
>
> Upstream documentation about changes since 5.0.x can be found here:
> http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html
>
> If you want to do some early testing, there are provisional scratch
> builds for rawhide here:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1051162
> or you can pull mysql/devel from CVS (changes are committed, but
> not tagged yet).
>
> 			regards, tom lane
>
>
> Io-language-mysql	salimma
> MySQL-python	tgl
> amarok	abompard
> apr-util-mysql	jorton
> bacula-director-mysql	ixs
> bacula-storage-mysql	ixs
> bind-sdb	atkac
> callweaver-mysql	dwmw2
> cherokee	pali
> collectd-mysql	rjones
> cyrus-sasl-sql	tmraz
> dbmail-mysql	bjohnson
> dovecot-mysql	sharkcz
> exim	dwmw2
> flow-tools	stingray
> freeradius-mysql	jdennis
> gambas2	spot
> gammu	laxathom
> gdal	rezso
> gmyth	hadess
> gnokii-smsd-mysql	snirkel
> grass	rezso
> jabberd	adrian
> koffice-kexi-driver-mysql	awjb
> libdbi-dbd-mysql	tgl
> libgda-mysql	denis
> libnss-mysql	ondrejj
> libpreludedb-mysql	sgrubb
> lighttpd-mod_mysql_vhost	thias
> lua-sql-mysql	timn
> mapserver	rezso
> mediatomb	mwiriadi
> mod_auth_mysql	jorton
> mysql++	remi
> mysql-connector-odbc	tgl
> nagios-plugins-mysql	mmcgrath
> ntop	rakesh
> openser-mysql	peter
> pam_mysql	stingray
> pdns-backend-mysql	ruben
> perl-DBD-MySQL	kasal
> php-mapserver	jorton
> php-mysql	jorton
> postfix	mlichvar
> proftpd-mysql	thias
> pure-ftpd	abompard
> qt-mysql	than
> qt3-MySQL	than
> redland	thomasvs
> rekall-mysql	spot
> rsyslog-mysql	theinric
> ruby-mysql	orion
> ser-mysql	ixs
> showimg-mysql	abompard
> snort-bloat	ausil
> snort-mysql	ausil
> snort-mysql+flexresp	ausil
> totem-mythtv	hadess
> ulogd-mysql	abompard
> zabbix	sharkcz
> zoneminder	mebourne
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From rvinyard at cs.nmsu.edu  Wed Jan 14 17:00:46 2009
From: rvinyard at cs.nmsu.edu (rvinyard at cs.nmsu.edu)
Date: Wed, 14 Jan 2009 10:00:46 -0700 (MST)
Subject: Papyrus and Conexus License Change
Message-ID: <39170.155.148.81.31.1231952446.squirrel@intranet.cs.nmsu.edu>

Just the FYI notice that the latest releases of papyrus and conexus have
changed licenses from LGPLv2 to GPLv3.

Conexus is the only dependency of papyrus and has no dependencies of its own.



From tgl at redhat.com  Wed Jan 14 17:51:23 2009
From: tgl at redhat.com (Tom Lane)
Date: Wed, 14 Jan 2009 12:51:23 -0500
Subject: Heads up: MySQL 5.1 coming soon to rawhide 
In-Reply-To: <2a28d2ab0901140943uede01a9mb2375c4b83b11f27@mail.gmail.com> 
References: <17597.1231954770@sss.pgh.pa.us>
	<2a28d2ab0901140943uede01a9mb2375c4b83b11f27@mail.gmail.com>
Message-ID: <17817.1231955483@sss.pgh.pa.us>

"Dr. Diesel" <dr.diesel at gmail.com> writes:
> On Wed, Jan 14, 2009 at 12:39 PM, Tom Lane <tgl at redhat.com> wrote:
>> I intend to push mysql 5.1.30 into rawhide next week, as soon as the
>> alpha freeze has lifted.

> Any plans to push it to F10 at some point?

No.  ABI breakage is not material for a released branch, IMHO;
not to mention that there are still serious questions about 5.1's
stability.  (I'm trusting that there will be a 5.1.31 or later
before F11 ships...)

			regards, tom lane



From tgl at redhat.com  Wed Jan 14 17:52:32 2009
From: tgl at redhat.com (Tom Lane)
Date: Wed, 14 Jan 2009 12:52:32 -0500
Subject: Heads up: MySQL 5.1 coming soon to rawhide 
In-Reply-To: <d0c4ab73fbf661e5662789bbc2dbb204.squirrel@mail.jcomserv.net> 
References: <17597.1231954770@sss.pgh.pa.us>
	<d0c4ab73fbf661e5662789bbc2dbb204.squirrel@mail.jcomserv.net>
Message-ID: <17843.1231955552@sss.pgh.pa.us>

"Jon Ciesla" <limb at jcomserv.net> writes:
> Will you give us a shout here right after yuo do it?

Sure, will do.

>> I intend to push mysql 5.1.30 into rawhide next week, as soon as the
>> alpha freeze has lifted.

			regards, tom lane



From nicolas.mailhot at laposte.net  Wed Jan 14 18:06:09 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Jan 2009 19:06:09 +0100
Subject: TeX font package naming guidelines
In-Reply-To: <200901141702.n0EH2Six031570@laptop14.inf.utfsm.cl>
References: <20090114110957.GA10071@gallagher.di.uoa.gr>
	<20090114113716.GE2860@free.fr>
	<7d8c6bdfeb8472faea9d4f0d315576ab.squirrel@arekh.dyndns.org>
	<200901141702.n0EH2Six031570@laptop14.inf.utfsm.cl>
Message-ID: <1231956369.16909.3.camel@arekh.okg>

Le mercredi 14 janvier 2009 ? 14:02 -0300, Horst H. von Brand a ?crit :
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> [...]
> 
> > ctan-some-package-fonts-common
> > ctan-some-package-roman-fonts
> > 
> > according to the draft for the fonts part.
> 
> Sounds wrong... either all fonts-foo or all bar-fonts, not mix and
> match. Please?

The -fonts packages are real font packages
The srpm-common is an utility package with no fonts inside (common stuff
like directory ownership, documentation, etc), so it's actually good it
has a different naming than packages with fonts in them.

http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29
-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/5e13969c/attachment.sig>

From sds at tycho.nsa.gov  Wed Jan 14 18:04:53 2009
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 14 Jan 2009 13:04:53 -0500
Subject: SELinux in mock
In-Reply-To: <870180fe0901140930je234b81j6e0b1fc457ddf35@mail.gmail.com>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
	<1231941752.31192.4.camel@localhost.localdomain>
	<870180fe0901140930je234b81j6e0b1fc457ddf35@mail.gmail.com>
Message-ID: <1231956293.31192.53.camel@localhost.localdomain>

On Wed, 2009-01-14 at 10:30 -0700, Jerry James wrote:
> On Wed, Jan 14, 2009 at 7:02 AM, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> > selinuxenabled just tests for the presence of SELinux in the kernel by
> > probing for the selinuxfs filesystem (typically mounted on /selinux).
> >
> > semodule is testing whether the policy store
> > (under /etc/selinux/$SELINUXTYPE/modules/active) exists and can be
> > accessed by the current process before proceeding to try to install your
> > module.  strace semodule -i /tmp/gcl.pp would show the precise point of
> > failure, but offhand I'd guess that /etc/selinux/targeted/modules/active
> > either does not exist or is not readable by the process.
> 
> Thanks, Stephen and Jesse.  This is helpful information.  So here's
> the problem I'm having.  I have defined a policy that creates process
> type gcl_t and file type gcl_exec_t.  This policy allows GCL to do a
> number of strange things to memory (execheap, for example).  GCL
> creates multiple dump files as it builds, each leading up to the final
> dump file to be packaged.  Each dump file has to be labeled gcl_exec_t
> if the build is happening on an SELinux-enabled system.  I patched the
> GCL makefiles to include lines like this:
> 
>        if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then \
>                chcon -t gcl_exec_t $@; \
>        fi
> 
> This works fine when I do a normal build on my home (SELinux-enabled)
> machine.  It also works on the koji builders, where SELinux is not
> enabled.  However, it is failing in mock on an SELinux-enabled
> machine.  How should I change the test so that chcon isn't run if it
> is going to fail?  Or should I just ignore chcon failures?  Thanks,

If the chcon fails, won't the subsequent attempt to execute the dump
file also fail due to lack of permissions?

Ideally you'd get your domain (or perhaps just a more generic
unconfined_execheap_t domain) added to the base policy and included in
the policy on the build servers so that you could use an already defined
file type.

Alternatively, you might be able to workaround via setting the existing
allow_execheap boolean if that exists on those machines:
	setsebool allow_execheap = 1
	<run your build>
	setsebool allow_execheap = 0

That unfortunately will affect more than just your particular process,
but may be a temporary fix.

-- 
Stephen Smalley
National Security Agency



From kevin.kofler at chello.at  Wed Jan 14 18:14:40 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Jan 2009 19:14:40 +0100
Subject: Nokia to License Qt Under LGPL
References: <24e30d3804-itamar=ispbrasil.com.br@mail.vresp.com>
	<200901140853.33577.konrad@tylerc.org>
	<d3ceea380901140858s647b1d82mb386d377395c0d7c@mail.gmail.com>
	<200901140905.54967.konrad@tylerc.org>
	<20090114171240.GA15391@amd.home.annexia.org>
Message-ID: <gkla2h$hrk$1@ger.gmane.org>

Richard W.M. Jones wrote:
> Likely because the Linux version of Qt makes POSIX & X11 calls which
> don't exist under Windows.  So we need to start with the Windows
> version of Qt which uses the Win32 APIs, but that will have a build
> system that is only applicable to Windows.

You may be interested in my mkspecs. But they may not be good enough to
build Qt itself with no changes. (I haven't tried building Qt itself, I
just unzipped the binaries from the kdewin project into my sysroot.)

http://tigcc-linux.cvs.sourceforge.net/viewvc/tigcc-linux/ktigcc/mingw/mkspecs/win32-cross-g++/

        Kevin Kofler



From loganjerry at gmail.com  Wed Jan 14 18:15:44 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 11:15:44 -0700
Subject: SELinux in mock
In-Reply-To: <1231956293.31192.53.camel@localhost.localdomain>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
	<1231941752.31192.4.camel@localhost.localdomain>
	<870180fe0901140930je234b81j6e0b1fc457ddf35@mail.gmail.com>
	<1231956293.31192.53.camel@localhost.localdomain>
Message-ID: <870180fe0901141015i557a4862p471866f2ed2e3001@mail.gmail.com>

On Wed, Jan 14, 2009 at 11:04 AM, Stephen Smalley <sds at tycho.nsa.gov> wrote:
> If the chcon fails, won't the subsequent attempt to execute the dump
> file also fail due to lack of permissions?

It doesn't fail on SELinux-enabled hosts where the GCL policy is
already in place.  On the koji builders, since selinuxenabled exits
with code 1, we don't try the chcon in the first place.  The only
place where I'm having a problem is in a mock build on an
SELinux-enabled host.  I don't know what to do there.

> Ideally you'd get your domain (or perhaps just a more generic
> unconfined_execheap_t domain) added to the base policy and included in
> the policy on the build servers so that you could use an already defined
> file type.

GCL needs more than just execheap permission, which is why I wrote an
app-specific policy.  Since it is still undergoing a certain amount of
flux, I think that adding it to the base policy might be premature at
this time.

> Alternatively, you might be able to workaround via setting the existing
> allow_execheap boolean if that exists on those machines:
>        setsebool allow_execheap = 1
>        <run your build>
>        setsebool allow_execheap = 0
>
> That unfortunately will affect more than just your particular process,
> but may be a temporary fix.

I'd like to avoid this solution if at all possible.

Thanks for the help.
-- 
Jerry James
http://loganjerry.googlepages.com/



From loganjerry at gmail.com  Wed Jan 14 18:16:45 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 11:16:45 -0700
Subject: SELinux in mock
In-Reply-To: <870180fe0901141015i557a4862p471866f2ed2e3001@mail.gmail.com>
References: <870180fe0901132108m5e552fc0pd49f7a0c968365e9@mail.gmail.com>
	<1231941752.31192.4.camel@localhost.localdomain>
	<870180fe0901140930je234b81j6e0b1fc457ddf35@mail.gmail.com>
	<1231956293.31192.53.camel@localhost.localdomain>
	<870180fe0901141015i557a4862p471866f2ed2e3001@mail.gmail.com>
Message-ID: <870180fe0901141016p30e964cide0f3f8b98fde384@mail.gmail.com>

On Wed, Jan 14, 2009 at 11:15 AM, Jerry James <loganjerry at gmail.com> wrote:
> GCL needs more than just execheap permission, which is why I wrote an
> app-specific policy.  Since it is still undergoing a certain amount of
> flux, I think that adding it to the base policy might be premature at
> this time.

"I wrote"!  In the credit where credit is due department: I made an
initial fumbling attempt to write a policy, and Dan Walsh cleaned up
my mess.  Thanks, Dan!
-- 
Jerry James
http://loganjerry.googlepages.com/



From skvidal at fedoraproject.org  Wed Jan 14 19:51:52 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 14:51:52 -0500
Subject: comps discussion at fudcon and the future
Message-ID: <1231962712.14403.1559.camel@rosebud>


On saturday at fudcon we had a small talk (meaning there were only 4 of
us there: Jeroen, Jeremy, James, and Me) about the future of comps and
what we need.

We came up with a fairly radical departure that will take some work to
implement and probably won't land for F11 but it is worth discussing a
bit now. Please read through the whole thing before jumping all over it.


Problems we see:
- browsing packages is a difficult problem when you have 10000+ pkgs.
- comps has a lot of meanings and it is not obvious what they all are/do
- conditional pkgs (which provide a way of saying "install pkgX only 
  if pkgY is installed) are several colors of doom b/c they aren't a 
  dependency relationship and creates clutter on systems.
- users expect groups to be more persistent on their systems and to act
  more like pkgs (ie: yum update should update groups, too)
- optional/default/mandatory pkgs are confusing and not useful to most
  people - the types are only useful when browsing, not when installing.


We're still going to have a comps/groups file in the metadata but we'll
be removing package types. If a package is a member of a group then
that's it. It's in the group.

When someone goes to install the group: 'yum groupinstall
mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
comps/groups file from each repo, look if the group you're requesting is
there. If so it will create a metapkg rpm (a package containing only
requirements) on the packages that exist in the repositories that are
listed in that group. Then it will depsolve and install that pkg. The
package name will be @mygroup-of-fun. The package version will be a hash
of the contents of the package along with a timestamp. It needs to be
timestamp-based so the version is increasing so we can 'update' these
pkgs.

We'll make sure that yum knows about @pkgs to be looked up against the
comps file (which should be  significantly smaller now).

A yum update @mygroup-of-fun (or just a yum update) will grab the
comps/groups file. Check to see if the hash has changed. If it has then
it will create a new rpm and update it accordingly, pulling in the
necessary deps as it goes.

An additional feature return that this gets us is being able to have
groups w/i groups.

The reason we're building the packages on-demand instead of like any
other pkg is that this allows us to merge comps/groups content from
multiple repositories easily.


We do suggest adding some new metadata (probably originating at the
pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
tag-cloud browse them, if necessary. It will also afford us additional
terms to search against for better search results.

Fun, huh?

There's a fair number more things to iron out and constructive and
helpful remarks are welcome. :)

-sv




From Matt_Domsch at dell.com  Wed Jan 14 19:58:48 2009
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 14 Jan 2009 13:58:48 -0600
Subject: [PATCH] man 1.6f - add bin/../share/man to manpath
Message-ID: <20090114195848.GC23561@auslistsprd01.us.dell.com>

Forwarding for additional feedback.

----- Forwarded message from Matt Domsch <Matt_Domsch at dell.com> -----

Date: Wed, 14 Jan 2009 13:54:32 -0600
From: Matt Domsch <Matt_Domsch at dell.com>
To: flucifredi at acm.org, freestandards-fhs-discuss at lists.sourceforge.net
Cc: Ivana Varekova <varekova at redhat.com>, werner at suse.de,
	Colin Watson <cjwatson at debian.org>
Subject: [PATCH] man 1.6f - add bin/../share/man to manpath
Status: RO

man searches for package/bin/ directories on $PATH, and then looks for
package/man/ directories to exist as well.  When trying to place
packages into /opt/<provider>/<package> per FHS 2.3 [1], it expects
manpages to be found under this point, in share/man, not in man/.
/opt/<provider>/<package>/bin will get placed on $PATH, but share/man
won't be found without somehow editing $MANPATH, /etc/man.config, or
making share/man get automatically found by man.

Patch below adds ../share/man/ to the search path, after ../man/, for
bin/ directories on $PATH.  This adds one extra stat() call per bin/
directory listed in $PATH for each invocation of man.

Feedback requested.

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html

Thanks,
Matt

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

diff -urNp --exclude-from=/home/mdomsch/excludes --minimal man-1.6f.orig/src/manpath.c man-1.6f/src/manpath.c
--- man-1.6f.orig/src/manpath.c	2009-01-14 12:54:25.000000000 -0600
+++ man-1.6f/src/manpath.c	2009-01-14 13:17:14.000000000 -0600
@@ -106,7 +106,8 @@ is_directory (char *path) {
 
 /*
  * Check to see if the current directory has man or MAN
- * or ../man or ../man1 or ../man8 subdirectories. 
+ * or ../man or ../man1 or ../man8  or ../share/man
+ * subdirectories.
  */
 static char *
 find_man_subdir (char *p) {
@@ -144,6 +145,12 @@ find_man_subdir (char *p) {
      if (is_directory (t) == 1)
 	  return t;
 
+     /* look for the situation with packagedir/bin and packagedir/share/man */
+     strcpy (t + len, "/share/man");
+
+     if (is_directory (t) == 1)
+	  return t;
+
      /* look for the situation with pkg/bin and pkg/man1 or pkg/man8 */
      /* (looking for all man[1-9] would probably be a waste of stats) */
      strcpy (t + len, "/man1");

----- End forwarded message -----

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From mw_triad at users.sourceforge.net  Wed Jan 14 20:15:53 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 14 Jan 2009 14:15:53 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <gklh5p$crj$1@ger.gmane.org>

seth vidal wrote:
> - users expect groups to be more persistent on their systems and to act
>   more like pkgs (ie: yum update should update groups, too)

Um... Finding out about new packages is fine, but having it only work as 
long as you have everything in a particular group IMO isn't useful.

I'd rather see "interests", i.e. "subscribe" to certain groups to get 
notification of new packages in that group. And there needs to be a way 
to run updates without pulling new packages (and once I've declined a 
new package from a group I am subscribed to, I should never be prompted 
about it again).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane



From jspaleta at gmail.com  Wed Jan 14 20:18:06 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 14 Jan 2009 11:18:06 -0900
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>

On Wed, Jan 14, 2009 at 10:51 AM, seth vidal <skvidal at fedoraproject.org> wrote:
> We do suggest adding some new metadata (probably originating at the
> pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
> tag-cloud browse them, if necessary. It will also afford us additional
> terms to search against for better search results.
>
> Fun, huh?

I think the tag cloud idea is probably one of the best organizational
ideas worth experimenting with right now as an aid to end user usage
needs which focus primarily on application installation.

I think a more heretical categorization and classification of the
software package may have merit as a reference service for developers
looking for the 'right' development library for their project. But I
think that sort of thing would really requiring developing informed
opinions about  mature library classification concepts as a guide.  We
could spend years debating traditional brick and mortar library
cataloguing system and still not come to agreement over adapting Bliss
or Library of Congress style classification.

Just a couple of questions. As a percentage of our current packaging catalog...

How many packages provide an executable in the standard paths (and libexec ) ?

How many packages provide a .desktop file and appear in the menus?

These are the subset of package I would expect crowd tagging to be
most popular for.

-jef



From orion at cora.nwra.com  Wed Jan 14 20:18:33 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 14 Jan 2009 13:18:33 -0700
Subject: Help needed with latex/R doc font issue
Message-ID: <496E4899.80600@cora.nwra.com>

I'm trying to update R-lmtest to the latest release, but am having 
trouble during the documentation build step:

* checking PDF version of manual ... 

  ERROR 

LaTeX errors when creating PDF version. 

This typically indicates Rd problems. 

LaTeX errors found: 

! Package textcomp Error: Symbol \textcurrency not provided by 

(textcomp)                font family ptm in TS1 encoding. 

(textcomp)                Default family used instead. 

See the textcomp package documentation for explanation. 


Now, the shipped docs are in ISO-8599 encoding, so I convert the to 
UTF-8 with:

for x in lmtest/man/*.Rd
do
    iconv -f iso-8859-1 -t utf-8 < ${x} | tr -d '\r' > ${x}.utf-8
    touch -r ${x} ${x}.utf-8
    mv ${x}.utf-8 ${x}
done

This worked fine the last time I built the package (2008-06-25 for F-10).

If I take out the iconv step, the documentation builds fine.  Seems like 
a tex font is not getting installed that needs to be?

BuildRequires:    R-devel, tetex-latex, R-zoo

Mock root contains:

DEBUG util.py:250:   fontconfig              x86_64     2.6.0-3.fc10 
  fedora            183 k 

DEBUG util.py:250:   fontconfig-devel        x86_64     2.6.0-3.fc10 
  fedora            216 k 

DEBUG util.py:250:   ghostscript-fonts       noarch     5.50-19.fc10 
  fedora            812 k 

DEBUG util.py:250:   libXfont                x86_64     1.3.3-1.fc10 
  fedora            232 k 

DEBUG util.py:250:   libfontenc              x86_64     1.0.4-6.fc10 
  fedora             24 k 

DEBUG util.py:250:   texlive-texmf-errata-fonts  noarch     2007-5.fc11 
      fedora            3.7 k 

DEBUG util.py:250:   texlive-texmf-fonts     noarch     2007-26.fc10 
  fedora             56 M 

DEBUG util.py:250:   urw-fonts               noarch     2.4-6.fc10 
  fedora            3.2 M 

DEBUG util.py:250:   xorg-x11-font-utils     x86_64     1:7.2-6.fc10 
  fedora             79 k


DEBUG util.py:250:   tex-preview             noarch     11.85-7.fc9 
  fedora             52 k 

DEBUG util.py:250:   texinfo                 x86_64     4.13a-1.fc11 
  fedora            885 k 

DEBUG util.py:250:   texlive                 x86_64     2007-39.fc11 
  fedora            2.2 M 

DEBUG util.py:250:   texlive-dvips           x86_64     2007-39.fc11 
  fedora            197 k 

DEBUG util.py:250:   texlive-latex           x86_64     2007-39.fc11 
  fedora             82 k 

DEBUG util.py:250:   texlive-texmf           noarch     2007-26.fc10 
  fedora            3.5 M 

DEBUG util.py:250:   texlive-texmf-dvips     noarch     2007-26.fc10 
  fedora            378 k 

DEBUG util.py:250:   texlive-texmf-errata    noarch     2007-5.fc11 
  fedora            3.6 k 

DEBUG util.py:250:   texlive-texmf-errata-dvips  noarch     2007-5.fc11 
      fedora            3.6 k 

DEBUG util.py:250:   texlive-texmf-errata-fonts  noarch     2007-5.fc11 
      fedora            3.7 k 

DEBUG util.py:250:   texlive-texmf-errata-latex  noarch     2007-5.fc11 
      fedora            3.7 k 

DEBUG util.py:250:   texlive-texmf-fonts     noarch     2007-26.fc10 
  fedora             56 M 

DEBUG util.py:250:   texlive-texmf-latex     noarch     2007-26.fc10 
  fedora            6.0 M 

DEBUG util.py:250:   texlive-utils           x86_64     2007-39.fc11 
  fedora            236 k 


-- 
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 bkearney at redhat.com  Wed Jan 14 20:30:04 2009
From: bkearney at redhat.com (Bryan Kearney)
Date: Wed, 14 Jan 2009 15:30:04 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496DD9E6.2050800@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
Message-ID: <496E4B4C.6050103@redhat.com>

Jeroen van Meeuwen wrote:
> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen 
> Mondays at 18:00 UTC, on even weeks, and it will not take more then one 
> hour.
> 
> Obviously, we can pre-discuss most of the items on the agenda on our 
> mailing list fedora-spins -at- lists.fedoraproject.org.
> 
> With help of several key people in the current Spins process, including 
> Process-Guru and current Feature Wrangler John Poelstra, we've come up 
> with a real Spins Process during this last FUDCon.
> 
> If you are a member of Release Engineering, Quality Assurance, FESCo or 
> Infrastructure, I would like you to attend.
> 
> Our first meeting (in the series of regular meetings) would be January 
> 19th, 18:00 UTC, for which I'm going to set the Agenda now:
> 
> == Agenda ==
> 
> # Finalizing Spins Process[1], vote

May I suggest part of this discussion is spin versus feature. I ask 
becuase the process (for me) got hairy when combined with the feature 
process.

-- bk



From skvidal at fedoraproject.org  Wed Jan 14 20:45:46 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 15:45:46 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklh5p$crj$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud> <gklh5p$crj$1@ger.gmane.org>
Message-ID: <1231965946.14403.1566.camel@rosebud>

On Wed, 2009-01-14 at 14:15 -0600, Matthew Woehlke wrote:
> seth vidal wrote:
> > - users expect groups to be more persistent on their systems and to act
> >   more like pkgs (ie: yum update should update groups, too)
> 
> Um... Finding out about new packages is fine, but having it only work as 
> long as you have everything in a particular group IMO isn't useful.


> 
> I'd rather see "interests", i.e. "subscribe" to certain groups to get 
> notification of new packages in that group. And there needs to be a way 
> to run updates without pulling new packages (and once I've declined a 
> new package from a group I am subscribed to, I should never be prompted 
> about it again).

you want to update your system w/o pulling down the pkgs? That's, umm,
very difficult. One might even say impossible.

I think what you want out of groups is beyond the scope of what we're
trying to do. Or maybe I'm not understanding what it is you want.

-sv




From notting at redhat.com  Wed Jan 14 20:46:38 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Jan 2009 15:46:38 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <20090114204638.GD32395@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> We do suggest adding some new metadata (probably originating at the
> pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
> tag-cloud browse them, if necessary. It will also afford us additional
> terms to search against for better search results.
> 
> Fun, huh?
> 
> There's a fair number more things to iron out and constructive and
> helpful remarks are welcome. :)

I'm still not seeing how, in this model, you implement our current
language support groups sanely at all. "We'll just take that feature out"
isn't really a viable answer.

Bill



From pertusus at free.fr  Wed Jan 14 20:46:35 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 14 Jan 2009 21:46:35 +0100
Subject: Help needed with latex/R doc font issue
In-Reply-To: <496E4899.80600@cora.nwra.com>
References: <496E4899.80600@cora.nwra.com>
Message-ID: <20090114204635.GB2489@free.fr>

On Wed, Jan 14, 2009 at 01:18:33PM -0700, Orion Poplawski wrote:
> I'm trying to update R-lmtest to the latest release, but am having  
> trouble during the documentation build step:
>
> Now, the shipped docs are in ISO-8599 encoding, so I convert the to  
> UTF-8 with:
>
> for x in lmtest/man/*.Rd
> do
>    iconv -f iso-8859-1 -t utf-8 < ${x} | tr -d '\r' > ${x}.utf-8
>    touch -r ${x} ${x}.utf-8
>    mv ${x}.utf-8 ${x}
> done
>
> This worked fine the last time I built the package (2008-06-25 for F-10).

I think that you should not do that. The encoding is specified in the 
file when needed, so you should not change the encoding. You can change
the encoding and also the command that sets it, but I think this is 
not needed, and complicates matter for no gain.

--
Pat



From bruno at wolff.to  Wed Jan 14 21:00:48 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 14 Jan 2009 15:00:48 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>
References: <1231962712.14403.1559.camel@rosebud>
	<604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>
Message-ID: <20090114210048.GA24348@wolff.to>

On Wed, Jan 14, 2009 at 11:18:06 -0900,
  Jeff Spaleta <jspaleta at gmail.com> wrote:
> 
> I think a more heretical categorization and classification of the
> software package may have merit as a reference service for developers
> looking for the 'right' development library for their project. But I

I didn't think Fedora communtity was very tolerant of heretics.



From skvidal at fedoraproject.org  Wed Jan 14 20:59:15 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 15:59:15 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114204638.GD32395@nostromo.devel.redhat.com>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
Message-ID: <1231966755.14403.1570.camel@rosebud>

On Wed, 2009-01-14 at 15:46 -0500, Bill Nottingham wrote:
> seth vidal (skvidal at fedoraproject.org) said: 
> > We do suggest adding some new metadata (probably originating at the
> > pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
> > tag-cloud browse them, if necessary. It will also afford us additional
> > terms to search against for better search results.
> > 
> > Fun, huh?
> > 
> > There's a fair number more things to iron out and constructive and
> > helpful remarks are welcome. :)
> 
> I'm still not seeing how, in this model, you implement our current
> language support groups sanely at all. "We'll just take that feature out"
> isn't really a viable answer.

So, currently we have magical hooks in anaconda which grabs the
languages you want when you select a certain language. How is that not
possible with this groups mechanism?

-sv




From stickster at gmail.com  Wed Jan 14 21:08:33 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 14 Jan 2009 16:08:33 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114210048.GA24348@wolff.to>
References: <1231962712.14403.1559.camel@rosebud>
	<604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>
	<20090114210048.GA24348@wolff.to>
Message-ID: <20090114210833.GK5170@localhost.localdomain>

On Wed, Jan 14, 2009 at 03:00:48PM -0600, Bruno Wolff III wrote:
> On Wed, Jan 14, 2009 at 11:18:06 -0900,
>   Jeff Spaleta <jspaleta at gmail.com> wrote:
> > 
> > I think a more heretical categorization and classification of the
> > software package may have merit as a reference service for developers
> > looking for the 'right' development library for their project. But I
> 
> I didn't think Fedora communtity was very tolerant of heretics.

There's a beer called "Old Heretic" which I like a lot.  Maybe we need
to be more tolerant of young heretics?

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/fe3ea7d4/attachment.sig>

From jwboyer at gmail.com  Wed Jan 14 21:08:46 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Jan 2009 16:08:46 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <20090114210846.GB18581@yoda.jdub.homelinux.org>

On Wed, Jan 14, 2009 at 02:51:52PM -0500, seth vidal wrote:
>
>On saturday at fudcon we had a small talk (meaning there were only 4 of
>us there: Jeroen, Jeremy, James, and Me) about the future of comps and
>what we need.
>
>We came up with a fairly radical departure that will take some work to
>implement and probably won't land for F11 but it is worth discussing a
>bit now. Please read through the whole thing before jumping all over it.
>
>
>Problems we see:
>- browsing packages is a difficult problem when you have 10000+ pkgs.
>- comps has a lot of meanings and it is not obvious what they all are/do
>- conditional pkgs (which provide a way of saying "install pkgX only 
>  if pkgY is installed) are several colors of doom b/c they aren't a 
>  dependency relationship and creates clutter on systems.
>- users expect groups to be more persistent on their systems and to act
>  more like pkgs (ie: yum update should update groups, too)
>- optional/default/mandatory pkgs are confusing and not useful to most
>  people - the types are only useful when browsing, not when installing.
>
>
>We're still going to have a comps/groups file in the metadata but we'll
>be removing package types. If a package is a member of a group then
>that's it. It's in the group.
>
>When someone goes to install the group: 'yum groupinstall
>mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
>comps/groups file from each repo, look if the group you're requesting is
>there. If so it will create a metapkg rpm (a package containing only
>requirements) on the packages that exist in the repositories that are
>listed in that group. Then it will depsolve and install that pkg. The
>package name will be @mygroup-of-fun. The package version will be a hash
>of the contents of the package along with a timestamp. It needs to be
>timestamp-based so the version is increasing so we can 'update' these
>pkgs.
>
>We'll make sure that yum knows about @pkgs to be looked up against the
>comps file (which should be  significantly smaller now).

Bear with this question, but...

I often find myself doing "yum install <some group>" and messing around
with that a bit.  Then I typically find that I only really want 1/2 the
group or something.

With the metapkg installed, won't I have to yum remove that in order to
remove any individual packages from in that group?  If so, will yum go
into a depsolving erasure spree and try to remove the whole group
instead of just the package or two I listed?

josh



From notting at redhat.com  Wed Jan 14 21:12:32 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 14 Jan 2009 16:12:32 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231966755.14403.1570.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
Message-ID: <20090114211232.GA1188@nostromo.devel.redhat.com>

seth vidal (skvidal at fedoraproject.org) said: 
> > I'm still not seeing how, in this model, you implement our current
> > language support groups sanely at all. "We'll just take that feature out"
> > isn't really a viable answer.
> 
> So, currently we have magical hooks in anaconda which grabs the
> languages you want when you select a certain language. How is that not
> possible with this groups mechanism?

A large portion of the language support is built around conditional
packages.

Bill



From skvidal at fedoraproject.org  Wed Jan 14 21:12:30 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 16:12:30 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114210846.GB18581@yoda.jdub.homelinux.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
Message-ID: <1231967550.14403.1571.camel@rosebud>

On Wed, 2009-01-14 at 16:08 -0500, Josh Boyer wrote:
> On Wed, Jan 14, 2009 at 02:51:52PM -0500, seth vidal wrote:
> >
> >On saturday at fudcon we had a small talk (meaning there were only 4 of
> >us there: Jeroen, Jeremy, James, and Me) about the future of comps and
> >what we need.
> >
> >We came up with a fairly radical departure that will take some work to
> >implement and probably won't land for F11 but it is worth discussing a
> >bit now. Please read through the whole thing before jumping all over it.
> >
> >
> >Problems we see:
> >- browsing packages is a difficult problem when you have 10000+ pkgs.
> >- comps has a lot of meanings and it is not obvious what they all are/do
> >- conditional pkgs (which provide a way of saying "install pkgX only 
> >  if pkgY is installed) are several colors of doom b/c they aren't a 
> >  dependency relationship and creates clutter on systems.
> >- users expect groups to be more persistent on their systems and to act
> >  more like pkgs (ie: yum update should update groups, too)
> >- optional/default/mandatory pkgs are confusing and not useful to most
> >  people - the types are only useful when browsing, not when installing.
> >
> >
> >We're still going to have a comps/groups file in the metadata but we'll
> >be removing package types. If a package is a member of a group then
> >that's it. It's in the group.
> >
> >When someone goes to install the group: 'yum groupinstall
> >mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> >comps/groups file from each repo, look if the group you're requesting is
> >there. If so it will create a metapkg rpm (a package containing only
> >requirements) on the packages that exist in the repositories that are
> >listed in that group. Then it will depsolve and install that pkg. The
> >package name will be @mygroup-of-fun. The package version will be a hash
> >of the contents of the package along with a timestamp. It needs to be
> >timestamp-based so the version is increasing so we can 'update' these
> >pkgs.
> >
> >We'll make sure that yum knows about @pkgs to be looked up against the
> >comps file (which should be  significantly smaller now).
> 
> Bear with this question, but...
> 
> I often find myself doing "yum install <some group>" and messing around
> with that a bit.  Then I typically find that I only really want 1/2 the
> group or something.
> 
> With the metapkg installed, won't I have to yum remove that in order to
> remove any individual packages from in that group?  If so, will yum go
> into a depsolving erasure spree and try to remove the whole group
> instead of just the package or two I listed?

No, not if the remove-with-leaves plugin is not installed.

Remember:

yum install foo

foo requires bar
so bar is installed.

yum remove foo

only foo is removed. bar stays, unless you have remove-with-leaves
installed.


-sv




From skvidal at fedoraproject.org  Wed Jan 14 21:14:11 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 16:14:11 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114211232.GA1188@nostromo.devel.redhat.com>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
Message-ID: <1231967651.14403.1572.camel@rosebud>

On Wed, 2009-01-14 at 16:12 -0500, Bill Nottingham wrote:
> seth vidal (skvidal at fedoraproject.org) said: 
> > > I'm still not seeing how, in this model, you implement our current
> > > language support groups sanely at all. "We'll just take that feature out"
> > > isn't really a viable answer.
> > 
> > So, currently we have magical hooks in anaconda which grabs the
> > languages you want when you select a certain language. How is that not
> > possible with this groups mechanism?
> 
> A large portion of the language support is built around conditional
> packages.

Conditional packages were viewed, from the outset, as something that had
to go. One way or the other conditional pkgs were going to get beaten
up.

Jeremy, would you care to expand on this? You seem to hold a special
kind of hate in your heart for conditionals.

-sv



From mw_triad at users.sourceforge.net  Wed Jan 14 21:22:56 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 14 Jan 2009 15:22:56 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231965946.14403.1566.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud> <gklh5p$crj$1@ger.gmane.org>
	<1231965946.14403.1566.camel@rosebud>
Message-ID: <gkll3g$tvv$1@ger.gmane.org>

seth vidal wrote:
> On Wed, 2009-01-14 at 14:15 -0600, Matthew Woehlke wrote:
>> seth vidal wrote:
>>> - users expect groups to be more persistent on their systems and to act
>>>   more like pkgs (ie: yum update should update groups, too)
>> Um... Finding out about new packages is fine, but having it only work as 
>> long as you have everything in a particular group IMO isn't useful.
> 
> 
>> I'd rather see "interests", i.e. "subscribe" to certain groups to get 
>> notification of new packages in that group. And there needs to be a way 
>> to run updates without pulling new packages (and once I've declined a 
>> new package from a group I am subscribed to, I should never be prompted 
>> about it again).
> 
> you want to update your system w/o pulling down the pkgs? That's, umm,
> very difficult. One might even say impossible.

No. I want to update everything currently installed, and be /offered/ 
anything new. By "new packages" I mean "packages that didn't exist last 
time I ran updates" (as opposed to "updates of already installed 
packages"). Sorry for the confusion.

> I think what you want out of groups is beyond the scope of what we're
> trying to do.

That may be. In which case, I guess the point is just that what you're 
doing is not something that will be useful to me, as I don't typically 
install entire groups (ever). (On my Asus, I even wrote a script to find 
all packages that are not on, or dependencies of, a "whitelist" and 
remove them.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane



From skvidal at fedoraproject.org  Wed Jan 14 21:26:46 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 16:26:46 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkll3g$tvv$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<gklh5p$crj$1@ger.gmane.org> <1231965946.14403.1566.camel@rosebud>
	<gkll3g$tvv$1@ger.gmane.org>
Message-ID: <1231968406.14403.1574.camel@rosebud>

On Wed, 2009-01-14 at 15:22 -0600, Matthew Woehlke wrote:

> No. I want to update everything currently installed, and be /offered/ 
> anything new. By "new packages" I mean "packages that didn't exist last 
> time I ran updates" (as opposed to "updates of already installed 
> packages"). Sorry for the confusion.

Well having them 'offered' implies interactivity in a way that I very
much doubt we'll have. If the group has new pkgs in it then those are
requirements, not recommendations.



> > I think what you want out of groups is beyond the scope of what we're
> > trying to do.
> 
> That may be. In which case, I guess the point is just that what you're 
> doing is not something that will be useful to me, as I don't typically 
> install entire groups (ever). (On my Asus, I even wrote a script to find 
> all packages that are not on, or dependencies of, a "whitelist" and 
> remove them.)

Right, It sounds like what you want is a better way of searching out
packages and installing the specific ones you want.
-sv




From jwboyer at gmail.com  Wed Jan 14 21:32:57 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Jan 2009 16:32:57 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231967550.14403.1571.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
	<1231967550.14403.1571.camel@rosebud>
Message-ID: <20090114213257.GC18581@yoda.jdub.homelinux.org>

On Wed, Jan 14, 2009 at 04:12:30PM -0500, seth vidal wrote:
>On Wed, 2009-01-14 at 16:08 -0500, Josh Boyer wrote:
>> On Wed, Jan 14, 2009 at 02:51:52PM -0500, seth vidal wrote:
>> >
>> >On saturday at fudcon we had a small talk (meaning there were only 4 of
>> >us there: Jeroen, Jeremy, James, and Me) about the future of comps and
>> >what we need.
>> >
>> >We came up with a fairly radical departure that will take some work to
>> >implement and probably won't land for F11 but it is worth discussing a
>> >bit now. Please read through the whole thing before jumping all over it.
>> >
>> >
>> >Problems we see:
>> >- browsing packages is a difficult problem when you have 10000+ pkgs.
>> >- comps has a lot of meanings and it is not obvious what they all are/do
>> >- conditional pkgs (which provide a way of saying "install pkgX only 
>> >  if pkgY is installed) are several colors of doom b/c they aren't a 
>> >  dependency relationship and creates clutter on systems.
>> >- users expect groups to be more persistent on their systems and to act
>> >  more like pkgs (ie: yum update should update groups, too)
>> >- optional/default/mandatory pkgs are confusing and not useful to most
>> >  people - the types are only useful when browsing, not when installing.
>> >
>> >
>> >We're still going to have a comps/groups file in the metadata but we'll
>> >be removing package types. If a package is a member of a group then
>> >that's it. It's in the group.
>> >
>> >When someone goes to install the group: 'yum groupinstall
>> >mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
>> >comps/groups file from each repo, look if the group you're requesting is
>> >there. If so it will create a metapkg rpm (a package containing only
>> >requirements) on the packages that exist in the repositories that are
>> >listed in that group. Then it will depsolve and install that pkg. The
>> >package name will be @mygroup-of-fun. The package version will be a hash
>> >of the contents of the package along with a timestamp. It needs to be
>> >timestamp-based so the version is increasing so we can 'update' these
>> >pkgs.
>> >
>> >We'll make sure that yum knows about @pkgs to be looked up against the
>> >comps file (which should be  significantly smaller now).
>> 
>> Bear with this question, but...
>> 
>> I often find myself doing "yum install <some group>" and messing around
>> with that a bit.  Then I typically find that I only really want 1/2 the
>> group or something.
>> 
>> With the metapkg installed, won't I have to yum remove that in order to
>> remove any individual packages from in that group?  If so, will yum go
>> into a depsolving erasure spree and try to remove the whole group
>> instead of just the package or two I listed?
>
>No, not if the remove-with-leaves plugin is not installed.
>
>Remember:
>
>yum install foo
>
>foo requires bar
>so bar is installed.
>
>yum remove foo
>
>only foo is removed. bar stays, unless you have remove-with-leaves
>installed.

Ok, but if group-metapkg has Requires on all the packages in the
group, then won't:

yum remove foo-is-part-of-group

hit the Requires on group-metapkg and have yum try to remove it,
along with everything else?

I'm very dense, so maybe I'm misunderstanding how the metapkgs
are built.

josh



From nicolas.mailhot at laposte.net  Wed Jan 14 21:34:51 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 14 Jan 2009 22:34:51 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231968406.14403.1574.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
	<gklh5p$crj$1@ger.gmane.org> <1231965946.14403.1566.camel@rosebud>
	<gkll3g$tvv$1@ger.gmane.org>  <1231968406.14403.1574.camel@rosebud>
Message-ID: <1231968891.24058.3.camel@arekh.okg>

Le mercredi 14 janvier 2009 ? 16:26 -0500, seth vidal a ?crit :
> On Wed, 2009-01-14 at 15:22 -0600, Matthew Woehlke wrote:
> 
> > No. I want to update everything currently installed, and be /offered/ 
> > anything new. By "new packages" I mean "packages that didn't exist last 
> > time I ran updates" (as opposed to "updates of already installed 
> > packages"). Sorry for the confusion.
> 
> Well having them 'offered' implies interactivity in a way that I very
> much doubt we'll have. If the group has new pkgs in it then those are
> requirements, not recommendations.

You can probably implement this by making the magic auto metapackage be
"@name-timestamp" instead of "@name" with no auto-update of its content.
And then add a yum command that shows the diff between installed
"@name-timestamp" and "@name-currenttimestamp", and proposes switching
from one to the other.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/c18439aa/attachment.sig>

From skvidal at fedoraproject.org  Wed Jan 14 21:35:28 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 16:35:28 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114213257.GC18581@yoda.jdub.homelinux.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
	<1231967550.14403.1571.camel@rosebud>
	<20090114213257.GC18581@yoda.jdub.homelinux.org>
Message-ID: <1231968928.14403.1575.camel@rosebud>

On Wed, 2009-01-14 at 16:32 -0500, Josh Boyer wrote:
> Ok, but if group-metapkg has Requires on all the packages in the
> group, then won't:
> 
> yum remove foo-is-part-of-group
> 
> hit the Requires on group-metapkg and have yum try to remove it,
> along with everything else?
> 
> I'm very dense, so maybe I'm misunderstanding how the metapkgs
> are built.


As instructed on IRC ignoring this question b/c you said you understood
what I meant before.

-sv




From skvidal at fedoraproject.org  Wed Jan 14 21:36:56 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 16:36:56 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231968891.24058.3.camel@arekh.okg>
References: <1231962712.14403.1559.camel@rosebud>
	<gklh5p$crj$1@ger.gmane.org> <1231965946.14403.1566.camel@rosebud>
	<gkll3g$tvv$1@ger.gmane.org>  <1231968406.14403.1574.camel@rosebud>
	<1231968891.24058.3.camel@arekh.okg>
Message-ID: <1231969016.14403.1576.camel@rosebud>

On Wed, 2009-01-14 at 22:34 +0100, Nicolas Mailhot wrote:
> Le mercredi 14 janvier 2009 ? 16:26 -0500, seth vidal a ?crit :
> > On Wed, 2009-01-14 at 15:22 -0600, Matthew Woehlke wrote:
> > 
> > > No. I want to update everything currently installed, and be /offered/ 
> > > anything new. By "new packages" I mean "packages that didn't exist last 
> > > time I ran updates" (as opposed to "updates of already installed 
> > > packages"). Sorry for the confusion.
> > 
> > Well having them 'offered' implies interactivity in a way that I very
> > much doubt we'll have. If the group has new pkgs in it then those are
> > requirements, not recommendations.
> 
> You can probably implement this by making the magic auto metapackage be
> "@name-timestamp" instead of "@name" with no auto-update of its content.
> And then add a yum command that shows the diff between installed
> "@name-timestamp" and "@name-currenttimestamp", and proposes switching
> from one to the other.

That seems like more of a special case than I'd like and it means 'yum
update' doesn't do what I would expect it to do.

-sv




From mw_triad at users.sourceforge.net  Wed Jan 14 21:40:23 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 14 Jan 2009 15:40:23 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231968406.14403.1574.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>	<gklh5p$crj$1@ger.gmane.org>
	<1231965946.14403.1566.camel@rosebud>	<gkll3g$tvv$1@ger.gmane.org>
	<1231968406.14403.1574.camel@rosebud>
Message-ID: <gklm48$28g$1@ger.gmane.org>

seth vidal wrote:
> On Wed, 2009-01-14 at 15:22 -0600, Matthew Woehlke wrote:
>> No. I want to update everything currently installed, and be /offered/ 
>> anything new. By "new packages" I mean "packages that didn't exist last 
>> time I ran updates" (as opposed to "updates of already installed 
>> packages"). Sorry for the confusion.
> 
> Well having them 'offered' implies interactivity in a way that I very
> much doubt we'll have. If the group has new pkgs in it then those are
> requirements, not recommendations.
> 
> It sounds like what you want is a better way of searching out
> packages and installing the specific ones you want.

They are only dependencies if I have a metapackage installed. Hence why 
I suggested something like a "subscription". IOW, not a metapackage, but 
something that would tell me about new (i.e. didn't exist before) 
packages. I'm not sure that qualifies as "searching" per se; the idea 
was for such new packages to be reported along with update reports.

This would be easy* in PK; just list new stuff as "new" when listing 
what updates are available. Either the user installs them or not, and PK 
keeps track of what the user chose not to install and doesn't offer them 
again as "new" (they'd still be there if you went through the normal 
"install something I don't have already" process, of course).

For yum it would be harder. I think I would want them to show up in 
'update' and 'check-update' until the user issues some new command, say 
'yum clear-optional-updates', which would make yum stop offering any 
packages that are "new" as of when the command is run.

(* by "easy" I mean to come up with a design that is sensible to the 
user, not that the code would necessarily be easy)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane



From mw_triad at users.sourceforge.net  Wed Jan 14 21:46:20 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 14 Jan 2009 15:46:20 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114213257.GC18581@yoda.jdub.homelinux.org>
References: <1231962712.14403.1559.camel@rosebud>	<20090114210846.GB18581@yoda.jdub.homelinux.org>	<1231967550.14403.1571.camel@rosebud>
	<20090114213257.GC18581@yoda.jdub.homelinux.org>
Message-ID: <gklmfd$1ru$1@ger.gmane.org>

Josh Boyer wrote:
> Ok, but if group-metapkg has Requires on all the packages in the
> group, then won't:
> 
> yum remove foo-is-part-of-group
> 
> hit the Requires on group-metapkg and have yum try to remove it,
> along with everything else?

For the benefit of the list, the answer is "yes". This is why I don't 
like using metapackages this way; you can't selectively install them.

In fact, this reminds me... on my Asus cleanup project, one of the 
things I did NOT remove was the xorg-drivers package, for exactly this 
reason. This is one case where I want 'yum update' to know about new 
xorg drivers. But this means I can't remove drivers I don't need, 
because it will remove the metapackage, which means I won't 
automagically find out about new drivers.

This is actually a great example of why I would like a "group 
subscription" model; I could "subscribe" to xorg-drivers, and yum would 
tell me about new drivers, and I could decide if I want to install them, 
without being forced to install a bunch of drivers I don't need.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane



From kevin.kofler at chello.at  Wed Jan 14 22:00:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Jan 2009 23:00:55 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud>
Message-ID: <gklnan$5fb$1@ger.gmane.org>

seth vidal wrote:
> Conditional packages were viewed, from the outset, as something that had
> to go. One way or the other conditional pkgs were going to get beaten
> up.

But it can't go because there's no working alternative.

        Kevin Kofler



From tmraz at redhat.com  Wed Jan 14 22:03:34 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 14 Jan 2009 23:03:34 +0100
Subject: Heads up openssl-0.9.8j in rawhide
Message-ID: <1231970614.5215.58.camel@vespa.frost.loc>

I am going to build new openssl into rawhide really soon. As the new
version contains some minor ABI breaks it will require SONAME bump of
the openssl libraries. That also means all the 288 dependent packages
will have to be rebuilt. Not counting that some of the dependent
packages have circular dependencies.

But do not be scared. As the ABI break is pretty minimal and as it
should not affect a large majority of applications I am going to
temporarily provide symlinks to the old library soname and appropriate
provides in the rpm package. Of course this will be dropped as soon as
all (or majority of) the dependencies are rebuilt.

As the library should not break any major application I'd like to not
wait for the alpha unfreeze as the rebuild of all the deps will surely
take some time.

Here is the list of all the dependent packages:

afflib
aimage
alpine
amanda
amarok
apcupsd
apr-util
asterisk
authd
bacula
balsa
bes
bigloo
bind
bip
boinc-client
bro
bunny
callweaver
cfengine
cherokee
chntpw
clustermon
collectd
compat-erlang-R10B
condor
cone
conserver
cpqarrayd
ctorrent
cyrus-imapd
cyrus-sasl
dar
dclib
dhcp
dillo
distcache
dkim-milter
dnsperf
dnssec-tools
dovecot
drivel
dsniff
echoping
ecore
ecryptfs-utils
edje
efreet
ejabberd
ekg
ekg2
ekiga
elinks
engine_pkcs11
enlightenment
epic
epsilon
erlang-R12B
esmtp
ettercap
evolution-data-server
evolution-exchange
exim
fedora-ds-base
fetchmail
flow-tools
fontmatrix
freeradius
freetds
fuse-encfs
g2ipmsg
gammu
gdal
gftp
gg2
ghasher
git
gkrellm
globalplatform
gmyth
gnokii
gnome-vfs2
gnubiff
gq
grass
gridengine
gsoap
gyachi
heartbeat
hedgewars
hfsplus-tools
hplip
htdig
htmldoc
httpd
httperf
http_ping
ice
ifstat
ike-scan
inkscape
ipa
ipmitool
ipsec-tools
ircd-hybrid
ircd-ratbox
irssi
isns-utils
isync
jabberd
jabbin
jpilot
kadu
kannel
kasablanca
kdebase3
kdelibs
kdenetwork
keepalived
kftpgrabber
krb5
ldapvi
ldns
libesmtp
libewf
libfprint
libgadu
libgda
libjingle
libmsn
libnasl
libp11
libpreludedb
libssh2
libtorrent
libwvstreams
licq
lighttpd
linkage
linuxdcpp
lynx
m2crypto
mail-notification
mapserver
mcabber
mediatomb
Miro
mod_authz_ldap
monit
mysql
mysql-connector-odbc
mysql-gui-tools
MySQL-python
nagios-plugins
nagios-plugins-snmp-disk-proc
nekovm
nessus-core
netatalk
net-snmp
nginx
nmap
nrpe
nsd
ntop
ntp
nufw
nut
nx
ocaml-ssl
ochusha
ocspd
opal
openconnect
openhpi
openhpi-subagent
OpenIPMI
openldap
openoffice.org
opensc
openser
openslp
openssh
openssl
openvpn
osslsigncode
pam_mount
pam_mysql
pam_ssh
paraview
pdns
perl-Crypt-OpenSSL-AES
perl-Crypt-OpenSSL-Bignum
perl-Crypt-OpenSSL-DSA
perl-Crypt-OpenSSL-PKCS10
perl-Crypt-OpenSSL-Random
perl-Crypt-OpenSSL-RSA
perl-Crypt-OpenSSL-X509
perl-Crypt-SSLeay
perl-DBD-MySQL
perl-Net-SSLeay
php
pinot
pl
player
postfix
postgresql
Pound
proftpd
ptlib
pure-ftpd
pwlib
pwsafe
pyOpenSSL
pysvn
python
python-ldap
qca-ossl
qca-tls
qmmp
qt
rb_libtorrent
rdesktop
redland
ricci
rsyslog
ruby
ruby-ldap
ruby-mysql
rudesocket
scribus
scsi-target-utils
sendmail
sepostgresql
showimg
siege
sim
sipp
sipsak
snmp++
socat
sofia-sip
spamassassin
squid
ssmtp
stunnel
suck
sylpheed
tcltls
tcpdump
telepathy-idle
telepathy-salut
tightvnc
tinyfugue
tn5250
tog-pegasus
tomcat-native
tor
totem
tpm-tools
tqsllib
transmission
tripwire
trousers
ulogd
unbound
up-imapproxy
uw-imap
valknut
vnc
vsftpd
vtun
w3c-libwww
w3m
wget
wireshark
wmweather+
wpa_supplicant
x3270
xar
xca
xchat
xchat-gnome
xen
xmlsec1
xmms2
xorg-x11-server
xsupplicant
zabbix

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From kevin.kofler at chello.at  Wed Jan 14 22:15:11 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 14 Jan 2009 23:15:11 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <gklo5h$9gm$1@ger.gmane.org>

seth vidal wrote:
> - conditional pkgs (which provide a way of saying "install pkgX only
>   if pkgY is installed) are several colors of doom b/c they aren't a
>   dependency relationship and creates clutter on systems.

But they're actually needed. We wouldn't have them if they weren't.

> - users expect groups to be more persistent on their systems and to act
>   more like pkgs (ie: yum update should update groups, too)

What users? Surely not me. I don't want packages to be magically added just
because they're in some group.

What I do want is be told of any new packages showing up in the repository.
All of them. No matter what groups, if any, they're in. Then I can decide
if I want them (by default none should be selected, of course). And viewing
that list is probably something which should have to be requested
explicitly, as I think most users will want to only install additional
stuff when they actually need it. (Installing a package to try it out
because it's new is something I do, but not something I'd expect somebody
who only uses the computer as a tool to do their job to do.)

I can't believe I'm alone with that expectation. I actually think there will
be lots of complaints about unwanted packages getting automatically added
(for a reason most users won't understand - metapackages are black magic as
far as they're concerned).

> - optional/default/mandatory pkgs are confusing and not useful to most
>   people - the types are only useful when browsing, not when installing.

They're actually extremely useful when installing, as you can decide what to
install. People may often want, say, KDE or GNOME, but not every single
application (or application pack) which is part of KDE or GNOME. (That's
why there's a distinction between "mandatory" (e.g. if you want KDE, you
definitely want kdelibs) and "default" (i.e. you probably want this, but
maybe not).) In addition, there are many KDE or GNOME applications which
are not directly part of KDE or GNOME. "Optional" provides a nice place to
list those.

While admittedly I haven't done any user research, I'd expect most users to
go through the comps list at least once, either while installing from the
DVD or after installing from a live CD (and noticing missing applications,
which are unavoidable for CD-sized spins).

In addition, there are plans to add soft dependencies even at package level,
which shows there is a demand for them, so IMHO dropping them from comps is
a step backwards.

        Kevin Kofler



From kanarip at kanarip.com  Wed Jan 14 22:19:16 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 14 Jan 2009 23:19:16 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114210833.GK5170@localhost.localdomain>
References: <1231962712.14403.1559.camel@rosebud>	<604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>	<20090114210048.GA24348@wolff.to>
	<20090114210833.GK5170@localhost.localdomain>
Message-ID: <496E64E4.1080001@kanarip.com>

Paul W. Frields wrote:
> There's a beer called "Old Heretic" which I like a lot.  Maybe we need
> to be more tolerant of young heretics?
> 

Yes.



From jkeating at redhat.com  Wed Jan 14 22:18:23 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Jan 2009 14:18:23 -0800
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <1231971503.5086.66.camel@localhost.localdomain>

On Wed, 2009-01-14 at 23:03 +0100, Tomas Mraz wrote:
> As the library should not break any major application I'd like to not
> wait for the alpha unfreeze as the rebuild of all the deps will surely
> take some time.

Isn't this precisely a reason /not/ to do it before the alpha freeze?  A
change like this is likely to break buildroots, break anaconda composes,
break installs, break users.  This isn't the kind of crap we want to
land in rawhide just before a freeze, and just before an effort to turn
that freeze into something usable.  PLEASE wait until after Alpha has
been cut to do this.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/2e09f795/attachment.sig>

From kwade at redhat.com  Wed Jan 14 22:20:22 2009
From: kwade at redhat.com (Karsten Wade)
Date: Wed, 14 Jan 2009 14:20:22 -0800
Subject: Your favorite CMS running docs.fedoraproject.org?
Message-ID: <20090114222022.GF7770@calliope.phig.org>

We are looking for a team of people who want to deploy and maintain a
new CMS for Fedora Docs.  It may become the CMS that runs all of
fedoraproject.org that is not a wiki.[0]

Which CMS?  There's the fun part.  You pick your favorite.

Best is if you are already passionate about a particular CMS solution.
You need to be willing to:

  * Deploy the installation to Fedora Infrastructure

  * Maintain it as part of the Infrastructure and Websites teams[1]

  * Have experience with the CMS to be able to expand it to meet
    Fedora's needs[2], preferably as part of the upstream

  * Be willing to package whatever is needed for Doc's CMS instance
    that isn't already in Fedora

  * Work as part of a team of three or more fellow Fedorans[3]

Skills include web systems administration, design (graphics, CSS)
and/or coding (PHP, Python, Java, etc.) in the particular CMS
solution, and perhaps some understanding of content management.

For more information:

https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites
http://www.redhat.com/archives/fedora-docs-list/2009-January/msg00077.html
https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites#Team_requirements_for_deployment_and_maintenance

(Separate copies sent to fedora-art-list, fedora-devel-list, and
fedora-list; separate discussion threads for each location is
preferred.)

Thanks - Karsten

[0] We are not replacing the wiki.  The wiki serves a different
    purpose than a full CMS.  The CMS would cover <10% of Fedora
    content, such as:

https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites#Target_.28sub-.29domains_and_paths

[1] http://fedoraproject.org/wiki/Infrastructure
    http://fedoraproject.org/wiki/Websites

[2] https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites#Solution_requirements
    https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites#Team_requirements_for_deployment_and_maintenance

[3] We don't want to overburden one individual; we need to avoid
    having one person be a single point of failure.  In addition, it
    would be good if no more than one of the people on the team is
    already busy with work from Infrastructure.  The goal is to
    increase the pool of people, not divide it further.

-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/af191ec7/attachment.sig>

From jkeating at redhat.com  Wed Jan 14 22:21:19 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Jan 2009 14:21:19 -0800
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231971503.5086.66.camel@localhost.localdomain>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<1231971503.5086.66.camel@localhost.localdomain>
Message-ID: <1231971679.5086.67.camel@localhost.localdomain>

On Wed, 2009-01-14 at 14:18 -0800, Jesse Keating wrote:
> On Wed, 2009-01-14 at 23:03 +0100, Tomas Mraz wrote:
> > As the library should not break any major application I'd like to not
> > wait for the alpha unfreeze as the rebuild of all the deps will surely
> > take some time.
> 
> Isn't this precisely a reason /not/ to do it before the alpha freeze?  A
> change like this is likely to break buildroots, break anaconda composes,
> break installs, break users.  This isn't the kind of crap we want to
> land in rawhide just before a freeze, and just before an effort to turn
> that freeze into something usable.  PLEASE wait until after Alpha has
> been cut to do this.

If you can do this in such a way that rpmdeps don't break, that's fine.
I re-read your message again and noticed the part about a compat symlink
and rpm provides.  Please ensure that works before doing the builds in
koji.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/ea5e6bd6/attachment.sig>

From tmraz at redhat.com  Wed Jan 14 22:25:35 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 14 Jan 2009 23:25:35 +0100
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231971679.5086.67.camel@localhost.localdomain>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<1231971503.5086.66.camel@localhost.localdomain>
	<1231971679.5086.67.camel@localhost.localdomain>
Message-ID: <1231971935.5215.61.camel@vespa.frost.loc>

On Wed, 2009-01-14 at 14:21 -0800, Jesse Keating wrote:
> On Wed, 2009-01-14 at 14:18 -0800, Jesse Keating wrote:
> > On Wed, 2009-01-14 at 23:03 +0100, Tomas Mraz wrote:
> > > As the library should not break any major application I'd like to not
> > > wait for the alpha unfreeze as the rebuild of all the deps will surely
> > > take some time.
> > 
> > Isn't this precisely a reason /not/ to do it before the alpha freeze?  A
> > change like this is likely to break buildroots, break anaconda composes,
> > break installs, break users.  This isn't the kind of crap we want to
> > land in rawhide just before a freeze, and just before an effort to turn
> > that freeze into something usable.  PLEASE wait until after Alpha has
> > been cut to do this.
> 
> If you can do this in such a way that rpmdeps don't break, that's fine.
> I re-read your message again and noticed the part about a compat symlink
> and rpm provides.  Please ensure that works before doing the builds in
> koji.

Surely, I am not that stupid to break all the deps a week before freeze.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From kanarip at kanarip.com  Wed Jan 14 22:26:02 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 14 Jan 2009 23:26:02 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklmfd$1ru$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>	<20090114210846.GB18581@yoda.jdub.homelinux.org>	<1231967550.14403.1571.camel@rosebud>	<20090114213257.GC18581@yoda.jdub.homelinux.org>
	<gklmfd$1ru$1@ger.gmane.org>
Message-ID: <496E667A.1040803@kanarip.com>

Matthew Woehlke wrote:
> Josh Boyer wrote:
>> Ok, but if group-metapkg has Requires on all the packages in the
>> group, then won't:
>>
>> yum remove foo-is-part-of-group
>>
>> hit the Requires on group-metapkg and have yum try to remove it,
>> along with everything else?
> 
> For the benefit of the list, the answer is "yes". This is why I don't 
> like using metapackages this way; you can't selectively install them.
> 
> In fact, this reminds me... on my Asus cleanup project, one of the 
> things I did NOT remove was the xorg-drivers package, for exactly this 
> reason. This is one case where I want 'yum update' to know about new 
> xorg drivers. But this means I can't remove drivers I don't need, 
> because it will remove the metapackage, which means I won't 
> automagically find out about new drivers.
> 

Euhm, I can remove xorg-drivers without any dependencies, but not a 
xorg-x11-drv-* package. I'm not sure why these other packages depend on 
xorg-drivers, but that's not how a meta package would be used:

yum install @foo would install bar and baz

yum remove baz would remove baz

yum update @foo would pull in baz again, and maybe newpkg1.

In the last command, the packages baz and newpkg1 would be listed as 
"Installing for dependencies" (rather then "Updating").

> This is actually a great example of why I would like a "group 
> subscription" model; I could "subscribe" to xorg-drivers, and yum would 
> tell me about new drivers, and I could decide if I want to install them, 
> without being forced to install a bunch of drivers I don't need.
> 

The above example does exactly what you want it to do, just not how you 
would like it to do so, I presume.

Kind regards,

Jeroen van Meeuwen
-kanarip



From stickster at gmail.com  Wed Jan 14 22:28:33 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 14 Jan 2009 17:28:33 -0500
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <20090114222022.GF7770@calliope.phig.org>
References: <20090114222022.GF7770@calliope.phig.org>
Message-ID: <20090114222833.GF14350@localhost.localdomain>

On Wed, Jan 14, 2009 at 02:20:22PM -0800, Karsten Wade wrote:
> We are looking for a team of people who want to deploy and maintain a
> new CMS for Fedora Docs.  It may become the CMS that runs all of
> fedoraproject.org that is not a wiki.[0]
> 
[...snip...]
> 
> [0] We are not replacing the wiki.  The wiki serves a different
>     purpose than a full CMS.  The CMS would cover <10% of Fedora
>     content, such as:
> 
> https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites#Target_.28sub-.29domains_and_paths

One way of looking at this, although maybe it's a slightly canted
viewpoint, is that the wiki has 80-90%+ of the content but serves <10%
of the total Fedora audience, and that the CMS would have 10% or so of
the content, but serve a much larger proportion of the total Fedora
audience.

When you include all our users in the total Fedora audience, many of
them are looking for the content that is currently served on the
general web and documentation sites.  For instance, huge numbers of
people visit monthly to find out how to download, join, install, and
translate Fedora, so a CMS would help quite a bit.  I imagine this
would be a fairly prestigious and interesting place to get involved in
Fedora since you'd end up touching a lot of other project areas.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/847a6d86/attachment.sig>

From kanarip at kanarip.com  Wed Jan 14 22:29:30 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 14 Jan 2009 23:29:30 +0100
Subject: Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090114173635.GG19783@nostromo.devel.redhat.com>
References: <496DD9E6.2050800@kanarip.com>
	<20090114173635.GG19783@nostromo.devel.redhat.com>
Message-ID: <496E674A.6030701@kanarip.com>

Bill Nottingham wrote:
> Jeroen van Meeuwen (kanarip at kanarip.com) said: 
>> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen  
>> Mondays at 18:00 UTC, on even weeks, and it will not take more then one  
>> hour.
> 
> ...
> 
>> If you are a member of Release Engineering, Quality Assurance, FESCo or  
>> Infrastructure, I would like you to attend.
> 
> releng meetings are Mondays, 18:00 UTC already. See
>   http://fedoraproject.org/wiki/ReleaseEngineering
> 

https://fedoraproject.org/wiki/Meeting_channel#Time_table has the 
Release Engineering meetings listed at 17:00 UTC.

Kind regards,

Jeroen van Meeuwen
-kanarip



From kanarip at kanarip.com  Wed Jan 14 22:31:28 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 14 Jan 2009 23:31:28 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496E4B4C.6050103@redhat.com>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
Message-ID: <496E67C0.20609@kanarip.com>

Bryan Kearney wrote:
> Jeroen van Meeuwen wrote:
>> The Spins SIG is going to have regular, bi-weekly meetings. I've 
>> chosen Mondays at 18:00 UTC, on even weeks, and it will not take more 
>> then one hour.
>>
>> Obviously, we can pre-discuss most of the items on the agenda on our 
>> mailing list fedora-spins -at- lists.fedoraproject.org.
>>
>> With help of several key people in the current Spins process, 
>> including Process-Guru and current Feature Wrangler John Poelstra, 
>> we've come up with a real Spins Process during this last FUDCon.
>>
>> If you are a member of Release Engineering, Quality Assurance, FESCo 
>> or Infrastructure, I would like you to attend.
>>
>> Our first meeting (in the series of regular meetings) would be January 
>> 19th, 18:00 UTC, for which I'm going to set the Agenda now:
>>
>> == Agenda ==
>>
>> # Finalizing Spins Process[1], vote
> 
> May I suggest part of this discussion is spin versus feature. I ask 
> becuase the process (for me) got hairy when combined with the feature 
> process.
> 

We've beaten that horse during FUDCon and the Spins Process is now 
separate from the Feature Process, although with the primary features of 
the Feature Process such as Freezes and Wrangling.

Kind regards,

Jeroen van Meeuwen
-kanarip



From jonathan.underwood at gmail.com  Wed Jan 14 22:37:42 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 14 Jan 2009 22:37:42 +0000
Subject: Help needed with latex/R doc font issue
In-Reply-To: <496E4899.80600@cora.nwra.com>
References: <496E4899.80600@cora.nwra.com>
Message-ID: <645d17210901141437m6bb34260x2464b96b1c6d001a@mail.gmail.com>

2009/1/14 Orion Poplawski <orion at cora.nwra.com>:
> BuildRequires:    R-devel, tetex-latex, R-zoo

Aside: that should be a BR for tex(latex) rather than tetex-latex.

J



From wolfy at nobugconsulting.ro  Wed Jan 14 22:49:45 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Thu, 15 Jan 2009 00:49:45 +0200
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <496E6C09.9050002@nobugconsulting.ro>

On 01/15/2009 12:03 AM, Tomas Mraz wrote:
> I am going to build new openssl into rawhide really soon. As the new
> version contains some minor ABI breaks it will require SONAME bump of
> the openssl libraries. That also means all the 288 dependent packages
> will have to be rebuilt. Not counting that some of the dependent
> packages have circular dependencies.
>
> But do not be scared. As the ABI break is pretty minimal and as it
> should not affect a large majority of applications I am going to
> temporarily provide symlinks to the old library soname and appropriate
> provides in the rpm package. Of course this will be dropped as soon as
> all (or majority of) the dependencies are rebuilt.
>
> As the library should not break any major application I'd like to not
> wait for the alpha unfreeze as the rebuild of all the deps will surely
> take some time.
>   
Shout loud over here after your builds have been started, please. Bonus 
points for providing  the  link to the koji task#, so that we can track it.
TIA

    wolfy



From jkeating at redhat.com  Wed Jan 14 22:48:26 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Jan 2009 14:48:26 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496E674A.6030701@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
	<20090114173635.GG19783@nostromo.devel.redhat.com>
	<496E674A.6030701@kanarip.com>
Message-ID: <1231973306.5086.73.camel@localhost.localdomain>

On Wed, 2009-01-14 at 23:29 +0100, Jeroen van Meeuwen wrote:
> Bill Nottingham wrote:
> > Jeroen van Meeuwen (kanarip at kanarip.com) said: 
> >> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen  
> >> Mondays at 18:00 UTC, on even weeks, and it will not take more then one  
> >> hour.
> > 
> > ...
> > 
> >> If you are a member of Release Engineering, Quality Assurance, FESCo or  
> >> Infrastructure, I would like you to attend.
> > 
> > releng meetings are Mondays, 18:00 UTC already. See
> >   http://fedoraproject.org/wiki/ReleaseEngineering
> > 
> 
> https://fedoraproject.org/wiki/Meeting_channel#Time_table has the 
> Release Engineering meetings listed at 17:00 UTC.
> 


Probably because one of us forgot to edit the table for the DST change
recently.  Can the spins trade us, or move an hour after us?  We float
back and forth between 1800 and 1700 depending on DST, keeping with 1pm
Eastern US time.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/6174c09e/attachment.sig>

From chitlesh.goorah at gmail.com  Wed Jan 14 23:05:14 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Thu, 15 Jan 2009 00:05:14 +0100
Subject: Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496DD9E6.2050800@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
Message-ID: <50baabb30901141505r60c64319v98604e40ae3ffffd@mail.gmail.com>

On Wed, Jan 14, 2009 at 1:26 PM, Jeroen van Meeuwen wrote:
> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen
> Mondays at 18:00 UTC, on even weeks, and it will not take more then one
> hour.

> #* Who's the maintainer of each spin, and where can we reach them?
> #* Fedora Electronic Lab


Hello,

I won't be able to attend the meeting, so about FEL, I still maintain
it and will continue to do so.
How to contact me ? chitlesh [AT] fedoraproject org

Chitlesh



From jwboyer at gmail.com  Wed Jan 14 23:14:07 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Jan 2009 18:14:07 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklmfd$1ru$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
	<1231967550.14403.1571.camel@rosebud>
	<20090114213257.GC18581@yoda.jdub.homelinux.org>
	<gklmfd$1ru$1@ger.gmane.org>
Message-ID: <20090114231407.GD18581@yoda.jdub.homelinux.org>

On Wed, Jan 14, 2009 at 03:46:20PM -0600, Matthew Woehlke wrote:
> Josh Boyer wrote:
>> Ok, but if group-metapkg has Requires on all the packages in the
>> group, then won't:
>>
>> yum remove foo-is-part-of-group
>>
>> hit the Requires on group-metapkg and have yum try to remove it,
>> along with everything else?
>
> For the benefit of the list, the answer is "yes". This is why I don't  
> like using metapackages this way; you can't selectively install them.

Actually, the answer is no.

The reason being that the metapkg has Requires on the individual packages,
but the individual packages don't have Requires on the metapkg.  So you
can still remove individual packages, the "group" will just be broken.  And
that's fine, since you just decided you don't want the whole group anyway.

josh



From jkeating at redhat.com  Wed Jan 14 23:55:06 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 14 Jan 2009 15:55:06 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114231407.GD18581@yoda.jdub.homelinux.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
	<1231967550.14403.1571.camel@rosebud>
	<20090114213257.GC18581@yoda.jdub.homelinux.org>
	<gklmfd$1ru$1@ger.gmane.org>
	<20090114231407.GD18581@yoda.jdub.homelinux.org>
Message-ID: <1231977306.5086.81.camel@localhost.localdomain>

On Wed, 2009-01-14 at 18:14 -0500, Josh Boyer wrote:
> Actually, the answer is no.
> 
> The reason being that the metapkg has Requires on the individual packages,
> but the individual packages don't have Requires on the metapkg.  So you
> can still remove individual packages, the "group" will just be broken.  And
> that's fine, since you just decided you don't want the whole group anyway.

erm, except that the group is a package within your rpmdb, so if you
tried to remove the individual package, yum/rpm would bark that you're
breaking your deps.  You'd have to --nodeps it, and then have an
inconsistent rpmdb.  Or you'd do both.  You'd remove only the group
metapackage, and the individual package you wish to rid yourself of.
Then you wouldn't have broken deps, but you also wouldn't gain any
"group" advantages for that group in the future.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090114/4e13c95a/attachment.sig>

From loganjerry at gmail.com  Wed Jan 14 23:57:24 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 16:57:24 -0700
Subject: MAVEN_OPTS and mvn-jpp
In-Reply-To: <870180fe0901122019t1f41b71bw927ca2519f639e42@mail.gmail.com>
References: <870180fe0901061344j1fb7c065w53504c8e54485780@mail.gmail.com>
	<20090109200022.GA4271@redhat.com>
	<870180fe0901101217q7c0f82adha84dc85eb0ff462f@mail.gmail.com>
	<20090111152759.GA8635@redhat.com>
	<870180fe0901120723q5a6a312cg89576180895b1d78@mail.gmail.com>
	<870180fe0901122019t1f41b71bw927ca2519f639e42@mail.gmail.com>
Message-ID: <870180fe0901141557x4155d848x8e4997a60c7049c0@mail.gmail.com>

On Mon, Jan 12, 2009 at 9:19 PM, Jerry James <loganjerry at gmail.com> wrote:
> And I neglected to point out that I'm investigating this in the first
> place because maven threw this error on the koji builders.  I believe
> that rules out any strangeness on my machine being the cause.

A little testing shows that this is clearly a bug.  Note that it
prevents any package that builds with mvn-jpp from building
successfully in Rawhide.  See:

https://bugzilla.redhat.com/show_bug.cgi?id=480093
-- 
Jerry James
http://loganjerry.googlepages.com/



From Arnaud.Gomes at ircam.fr  Thu Jan 15 00:59:38 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Thu, 15 Jan 2009 01:59:38 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud> (seth vidal's message of
	"Wed\, 14 Jan 2009 14\:51\:52 -0500")
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <y9hhc4175ad.fsf@libation.ircam.fr>

Hi folks,

I guess most of you don't know me as this is my first post on this
list. Just to make things clear, I am not a Fedora contributor (yet?)
but a packager for Planet CCRMA.

seth vidal <skvidal at fedoraproject.org> writes:

> When someone goes to install the group: 'yum groupinstall
> mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> comps/groups file from each repo, look if the group you're requesting is
> there. If so it will create a metapkg rpm (a package containing only
> requirements) on the packages that exist in the repositories that are
> listed in that group. Then it will depsolve and install that pkg.

>From the point of view of a third-party repo, this means I have one
less option. At the moment, I can provide metapkgs (install this set
of packages and follow future changes) *or* groups (install this set
of packages as a starting point and let the admin decide what to do
with them).

We discussed the options for Planet CCRMA a few months back and AFAIR
we ended with someting along the lines of "let's keep metapkgs for the
time being and let's add groups when we have some free time, both can
have their use".

Actually I'm not sure there is anything in your proposal that can't be
implemented by creating a few metapkgs and making the front-end tools
metapkg-aware. Or am I missing anything obvious?

-- 
Arnaud



From jwboyer at gmail.com  Thu Jan 15 01:00:16 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 14 Jan 2009 20:00:16 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231977306.5086.81.camel@localhost.localdomain>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114210846.GB18581@yoda.jdub.homelinux.org>
	<1231967550.14403.1571.camel@rosebud>
	<20090114213257.GC18581@yoda.jdub.homelinux.org>
	<gklmfd$1ru$1@ger.gmane.org>
	<20090114231407.GD18581@yoda.jdub.homelinux.org>
	<1231977306.5086.81.camel@localhost.localdomain>
Message-ID: <20090115010016.GE18581@yoda.jdub.homelinux.org>

On Wed, Jan 14, 2009 at 03:55:06PM -0800, Jesse Keating wrote:
>On Wed, 2009-01-14 at 18:14 -0500, Josh Boyer wrote:
>> Actually, the answer is no.
>> 
>> The reason being that the metapkg has Requires on the individual packages,
>> but the individual packages don't have Requires on the metapkg.  So you
>> can still remove individual packages, the "group" will just be broken.  And
>> that's fine, since you just decided you don't want the whole group anyway.
>
>erm, except that the group is a package within your rpmdb, so if you
>tried to remove the individual package, yum/rpm would bark that you're
>breaking your deps.  You'd have to --nodeps it, and then have an
>inconsistent rpmdb.  Or you'd do both.  You'd remove only the group
>metapackage, and the individual package you wish to rid yourself of.
>Then you wouldn't have broken deps, but you also wouldn't gain any
>"group" advantages for that group in the future.

Right.

	yum group-install foo-bar-baz

nets foo, bar, baz, and foo-bar-baz-meta being installed.

	yum remove foo

nets foo, and foo-bar-baz-meta being removed.

The mere fact that you want to remove foo after installing the
foo-bar-baz group means that you no longer want the whole group
installed.  Otherwise yum updates in the future would continue
to insist that you need to have foo installed.

Look, people traditionally suck at grouping packages.  Either
the group is huge (like Gnome), or different people have
different interpretations of what should be in a group.  That
doesn't look like it's going to be magically solved by this
proposed mechanism.

The one thing this has going for it is the thing Seth alluded to
with sub-groups being possible.  That way one could install the
"gnome-core" group and maybe not have to deal with the umpteen
other packages it brings in.

josh



From Arnaud.Gomes at ircam.fr  Thu Jan 15 01:02:07 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Thu, 15 Jan 2009 02:02:07 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9hhc4175ad.fsf@libation.ircam.fr> (Arnaud Gomes-do-Vale's
	message of "Thu\, 15 Jan 2009 01\:59\:38 +0100")
References: <1231962712.14403.1559.camel@rosebud>
	<y9hhc4175ad.fsf@libation.ircam.fr>
Message-ID: <y9hd4ep7568.fsf@libation.ircam.fr>

Arnaud Gomes-do-Vale <Arnaud.Gomes at ircam.fr> writes:

> Actually I'm not sure there is anything in your proposal that can't be
> implemented by creating a few metapkgs and making the front-end tools
> metapkg-aware. Or am I missing anything obvious?

Forget about this last part, I should have re-read my post before
hitting send.

-- 
Arnaud



From jonstanley at gmail.com  Thu Jan 15 01:40:17 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 14 Jan 2009 20:40:17 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496DD9E6.2050800@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
Message-ID: <da159fda0901141740t6836b6e3u8c8f27d777f10e6c@mail.gmail.com>

On Wed, Jan 14, 2009 at 7:26 AM, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:

> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen
> Mondays at 18:00 UTC, on even weeks, and it will not take more then one
> hour.

This time will be bad for me over the next several weeks since I have
physical therapy for my busted shoulder. However, as that ends towards
the middle of February, then I should be good for this time.



From loganjerry at gmail.com  Thu Jan 15 02:40:11 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 14 Jan 2009 19:40:11 -0700
Subject: Rawhide PPC64
Message-ID: <870180fe0901141840m6bb88713gc11d27805e6000bf@mail.gmail.com>

I'm still trying to debug my PPC64 problem with GCL on Rawhide.  I
figured out how to get around the SELinux problem, built the software
up to the point where it segfaults on the koji builder, installed gdb
in the mock root, ran mock --shell, and did this:

-------------------------------------------------------------------------------
mock-chroot> gdb raw_pre_gcl
GNU gdb (GDB) Fedora (6.8.50.20081214-1.fc11)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "ppc64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(no debugging symbols found)
(gdb) run /builddir/build/BUILD/gcl-2.6.8/unixport/ -libdir
/builddir/build/BUILD/gcl-2.6.8/ < foo
Starting program: /builddir/build/BUILD/gcl-2.6.8/unixport/raw_pre_gcl
/builddir/build/BUILD/gcl-2.6.8/unixport/ -libdir
/builddir/build/BUILD/gcl-2.6.8/ < foo
rpmdb: munmap: Invalid argument
GCL (GNU Common Lisp)  April 1994  262144 pages
Building symbol table for
/builddir/build/BUILD/gcl-2.6.8/unixport/raw_pre_gcl ..

Unrecoverable error: Segmentation violation..
Segmentation fault
mock-chroot>
-------------------------------------------------------------------------------

So I see a couple of things that concern me.  First, I don't know why
rpmdb is involved at all [1], but what's up with the "rpmdb: munmap:
Invalid argument" line?  Second, gdb segfaulted!  I can't diagnose a
GCL segfault with a segfaulting gdb.  Does anyone have a Rawhide PPC64
machine running (i.e., not just mock)?  If so, does gdb work there?

Footnotes:
[1] Is this so gdb can find the debuginfo?
-- 
Jerry James
http://loganjerry.googlepages.com/



From skvidal at fedoraproject.org  Thu Jan 15 04:28:07 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Wed, 14 Jan 2009 23:28:07 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9hhc4175ad.fsf@libation.ircam.fr>
References: <1231962712.14403.1559.camel@rosebud>
	<y9hhc4175ad.fsf@libation.ircam.fr>
Message-ID: <1231993687.14403.1596.camel@rosebud>

On Thu, 2009-01-15 at 01:59 +0100, Arnaud Gomes-do-Vale wrote:
> Hi folks,
> 
> I guess most of you don't know me as this is my first post on this
> list. Just to make things clear, I am not a Fedora contributor (yet?)
> but a packager for Planet CCRMA.
> 
> seth vidal <skvidal at fedoraproject.org> writes:
> 
> > When someone goes to install the group: 'yum groupinstall
> > mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> > comps/groups file from each repo, look if the group you're requesting is
> > there. If so it will create a metapkg rpm (a package containing only
> > requirements) on the packages that exist in the repositories that are
> > listed in that group. Then it will depsolve and install that pkg.
> 
> >From the point of view of a third-party repo, this means I have one
> less option. At the moment, I can provide metapkgs (install this set
> of packages and follow future changes) *or* groups (install this set
> of packages as a starting point and let the admin decide what to do
> with them).
> 
> We discussed the options for Planet CCRMA a few months back and AFAIR
> we ended with someting along the lines of "let's keep metapkgs for the
> time being and let's add groups when we have some free time, both can
> have their use".
> 
> Actually I'm not sure there is anything in your proposal that can't be
> implemented by creating a few metapkgs and making the front-end tools
> metapkg-aware. Or am I missing anything obvious?

 - you can't merge metapkgs across multiple repos

that's the benefit of doing it this way.

-sv




From kanarip at kanarip.com  Thu Jan 15 07:21:06 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 08:21:06 +0100
Subject: Spins SIG Meeting(s) / Agenda! (Meeting Reschedule)
In-Reply-To: <1231973306.5086.73.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>	<20090114173635.GG19783@nostromo.devel.redhat.com>	<496E674A.6030701@kanarip.com>
	<1231973306.5086.73.camel@localhost.localdomain>
Message-ID: <496EE3E2.1030808@kanarip.com>

Due to a conflict with the Release Engineering Meeting, we'll move the 
meetings to 17:00 UTC, instead of 18:00 UTC.

Sorry for the inconvenience.

Kind regards,

Jeroen van Meeuwen

Jesse Keating wrote:
> On Wed, 2009-01-14 at 23:29 +0100, Jeroen van Meeuwen wrote:
>> Bill Nottingham wrote:
>>> Jeroen van Meeuwen (kanarip at kanarip.com) said: 
>>>> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen  
>>>> Mondays at 18:00 UTC, on even weeks, and it will not take more then one  
>>>> hour.
>>> ...
>>>
>>>> If you are a member of Release Engineering, Quality Assurance, FESCo or  
>>>> Infrastructure, I would like you to attend.
>>> releng meetings are Mondays, 18:00 UTC already. See
>>>   http://fedoraproject.org/wiki/ReleaseEngineering
>>>
>> https://fedoraproject.org/wiki/Meeting_channel#Time_table has the 
>> Release Engineering meetings listed at 17:00 UTC.
>>
> Probably because one of us forgot to edit the table for the DST change
> recently.  Can the spins trade us, or move an hour after us?  We float
> back and forth between 1800 and 1700 depending on DST, keeping with 1pm
> Eastern US time.
> 



From kanarip at kanarip.com  Thu Jan 15 07:23:07 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 08:23:07 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <da159fda0901141740t6836b6e3u8c8f27d777f10e6c@mail.gmail.com>
References: <496DD9E6.2050800@kanarip.com>
	<da159fda0901141740t6836b6e3u8c8f27d777f10e6c@mail.gmail.com>
Message-ID: <496EE45B.5050200@kanarip.com>

Jon Stanley wrote:
> On Wed, Jan 14, 2009 at 7:26 AM, Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> 
>> The Spins SIG is going to have regular, bi-weekly meetings. I've chosen
>> Mondays at 18:00 UTC, on even weeks, and it will not take more then one
>> hour.
> 
> This time will be bad for me over the next several weeks since I have
> physical therapy for my busted shoulder. However, as that ends towards
> the middle of February, then I should be good for this time.
> 

We've rescheduled due to a conflict with the Release Engineering 
meeting, on the same time as the EPEL meeting, but different alternating 
weeks, does that help?

Kind regards,

Jeroen van Meeuwen
-kanarip



From rawhide at fedoraproject.org  Thu Jan 15 07:56:51 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 15 Jan 2009 07:56:51 +0000 (UTC)
Subject: rawhide report: 20090115 changes
Message-ID: <20090115075651.EFFF61F825D@releng2.fedora.phx.redhat.com>

Compose started at Thu Jan 15 06:01:03 UTC 2009

New package docbook5-schemas
        Norman Walsh's schemas (DTD, Relax NG, W3C schema) for Docbook 5.X
New package docbook5-style-xsl
        Norman Walsh's XSL stylesheets for DocBook 5.X
New package hyphen-mi
        Maori hyphenation rules
New package hyphen-pt
        Portuguese hyphenation rules
New package hyphen-ro
        Romanian hyphenation rules
New package hyphen-uk
        Ukrainian hyphenation rules
New package kopete-bonjour
        Bonjour Plugin For Kopete
New package latexdiff
        Determine and mark up significant differences between latex files
New package libnotifymm
        C++ interface for libnotify
New package mingw32-libpng
        MinGW Windows Libpng library
New package mingw32-pthreads
        MinGW pthread library
New package netbeans-platform
        NetBeans Platform 9
New package perl-DateTimeX-Easy
        Parse a date/time string using the best method available
New package perl-Devel-Dumpvar
        Pure-OO reimplementation of dumpvar.pl
New package perl-Eval-Context
        Evalute perl code in context wraper
New package perl-File-pushd
        Change directory temporarily for a limited scope
New package perl-MooseX-Role-Parameterized
        Make your roles flexible through parameterization
New package perl-Parse-ErrorString-Perl
        Module for parsing error messages
New package perl-Test-HTTP-Server-Simple-StashWarnings
        Catch your forked server's warnings
New package perl-Time-Duration-Parse
        Parse string that represents time duration
New package podcatcher
        Armangil's podcatcher
Updated Packages:

DevIL-1.7.5-1.fc11
------------------
* Tue Jan 13 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.7.5-1
- Update to latest upstream: 1.7.5
- Add patch to fix CVE-2008-5262


R-car-1.2-4.fc11
----------------
* Wed Jan 14 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> 1.2-5
- Update to 1.2-11


R-multcomp-1.0-3.fc11
---------------------
* Wed Jan 14 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> - 1.0-3
- Update to 1.0-5


anaconda-11.5.0.8-1
-------------------

autofs-5.0.4-5
--------------
* Thu Jan 15 17:00:00 2009 Ian Kent <kent at redhat.com> - 5.0.4-5
- fix negative caching of non-existent keys.
- fix ldap library detection in configure.
- use CLOEXEC flag functionality if present.
- fix select(2) fd limit.
- make hash table scale to thousands of entries.


automake-1.10.2-1
-----------------
* Wed Jan 14 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 1.10.2-1
- version 1.10.2


boinc-client-6.4.5-2.20081217svn.fc11
-------------------------------------
* Thu Jan 15 17:00:00 2009 Milos Jakubicek <xjakub at fi.muni.cz> - 6.4.5-2.20081217svn
- Fix security bug BZ#479664


cduce-0.5.2.1-12.fc11
---------------------
* Wed Jan 14 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 0.5.2.1-12
- Improve the OCaml 3.11.0 patch (suggested by Kim Nguyen).


condor-7.2.0-3.fc11
-------------------
* Wed Jan 14 17:00:00 2009 <matt at redhat> - 7.2.0-3
- Fixed regression: initscript was on by default, now off again


dictd-1.11.0-1
--------------
* Wed Jan 14 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 1.11.0-1
- update


eclipse-pydev-1.4.2-1.fc11
--------------------------
* Wed Jan 14 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 1:1.4.2-1
- Update to 1.4.2.


ekiga-3.1.0-7.fc11
------------------
* Wed Jan 14 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-7
- Another fix

* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-6
- And SDL too

* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-5
- Add expat-devel, why not everything else wants it

* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-4
- Disable gstreamer support until there's a new gst-plugins-base

* Tue Jan 13 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-3
- Proper fix from upstream for desktop file

* Wed Jan  7 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-2
- Fix issues with the desktop file

* Mon Jan  5 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-1
- Upgrade to the 3.1.0 devel release, enable gstreamer and xcap, remove libgnome


elinks-0.12-0.7.pre2.fc11
-------------------------
* Wed Jan 14 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 0.12.0.7.pre2
- versioned obsoletes and provides for links


epiphany-2.24.2.1-5.fc11
------------------------
* Wed Jan 14 17:00:00 2009 Mat??j Cepl <mcepl at redhat.com> 2.24.2.1-5
- Make epiphany own directories for plugins and extensions
  (#479921).


fbreader-0.10.0-1.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 0.10.0-1
- Update to 0.10.0


fedora-logos-10.0.1-4.fc11
--------------------------
* Wed Jan 14 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 10.0.1-4
- actually, no. I won't make a grub subpackage. No real benefit aside from saving 1MB on disk.

* Wed Jan 14 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 10.0.1-3
- make grub subpackage (bz 479949)


file-4.26-9.fc11
----------------
* Wed Jan 14 17:00:00 2009 Daniel Novotny <dnovotny at redhat.com> 4.26-9
- fix #476655 detect JPEG-2000 Code Stream Bitmap


fontpackages-1.14-1.fc11
------------------------
* Wed Jan 14 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.13-1
??? Update for subpackage naming changes requested by FPC


ganglia-3.1.1-3.fc11
--------------------
* Wed Jan 14 17:00:00 2009 Kostas Georgiou <k.georgiou at imperial.ac.uk> - 3.1.1-3
- Fix for gmetad server buffer overflow
- The private_clusters file should not be readable by everyone


glibmm24-2.19.1-1.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 2.19.1-1
- Update to upstream 2.19.1


gnome-subtitles-0.8-6.fc10.1
----------------------------
* Fri Jan  9 17:00:00 2009 Julian Sikorski <belegdol[at]gmail[dot]com> - 0.8-6.fc10.1
- Rebuilt


gnuplot-4.2.4-3.fc11
--------------------
* Wed Jan 14 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 4.2.4-3
- fix sbin path


google-gadgets-0.10.5-1.fc11
----------------------------
* Wed Jan 14 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.10.5-1
- 0.10.5, req'd by kde

* Tue Dec 30 17:00:00 2008 Michel Salim <salimma at fedoraproject.org> - 0.10.4-2
- BR: Network-Manager-devel, startup-notification-devel
- Pass the browser plugin directory to ./configure
- Move designer desktop entry to -gtk subpackage


gromacs-4.0.2-7.fc11
--------------------
* Wed Jan 14 17:00:00 2009 Jussi Lehtola <jussi.lehtola at iki.fi> - 4.0.2-7
- Update manual to latest version.
- Removed Requires: blas and lapack.


gstreamer-plugins-good-0.10.11-4.fc11
-------------------------------------
* Wed Jan 14 17:00:00 2009 Warren Togami <wtogami at redhat.com> 0.10.11-4
- Bug #477877 Fix multilib conflict in -devel
- Bug #478449 Fix ladspa on lib64

* Wed Jan 14 17:00:00 2009 Lennart Poettering <lpoetter at redhat.com> 0.10.11-3
- Bug #470000 Fix thread/memleak due to ref-loop


gtkmm24-2.15.0-1.fc11
---------------------
* Wed Jan 14 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 2.15.0-1
- Update to upstream 2.15.0


gwibber-0.7.2-4.165bzr.fc11
---------------------------
* Wed Jan 14 17:00:00 2009 Ian Weller <ianweller at gmail.com> 0.7.2-4.165bzr
- Add python-imaging to Requires


hdparm-9.8-1.fc11
-----------------
* Wed Jan 14 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 9.8-1
- update


hunspell-en-0.20090114-1.fc11
-----------------------------
* Wed Jan 14 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20090114-1
- latest version


hunspell-pl-0.20090114-1.fc11
-----------------------------
* Wed Jan 14 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20090114-1
- latest version


kdeadmin-4.1.96-2.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.1.96-2
- include system-config-printer-kde


kdebase-workspace-4.1.96-3.fc11
-------------------------------
* Wed Jan 14 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.1.96-3
- BR: google-gadgets-devel > 0.10.5


kdepim-4.1.96-3.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-3
- move libkpilot_*.so -devel -> main pkg

* Thu Jan 15 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-2
- reenable BR pilot-link-devel, add missing BR libmal-devel (for KPilot)


kdeutils-4.1.96-2.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-2
- (Build)Req: system-config-printer-libs


libchewing-0.3.2-3.fc11
-----------------------
* Wed Jan 14 17:00:00 2009 Ding-Yi Chen <dchen at redhat dot com> - 0.3.2-3
- Add python binding by copy python/chewing.py to 
  <python_dir>/site_packages/libchewing


libgpod-0.6.0-10.fc11
---------------------
* Wed Jan 14 17:00:00 2009 Todd Zullinger <tmz at pobox.com> - 0.6.0-10
- Fix path to hal callout (this should help setup the SysInfoExtended
  file automagically)
- Use /var/run/hald as mount dir for hal callout
- Require hal
- Require main package for the -doc subpackage


libhugetlbfs-2.1.2-1.fc11
-------------------------

liblqr-1-0.1.0-6.fc11
---------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.1.0-6
- Fix Patch0:/%patch mismatch.


libmal-0.44-1.fc11
------------------
* Thu Jan 15 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.44-1
- update to 0.44 (for kdepim 4.2)
- drop libmal-0.31-pi12.patch (fixed upstream)
- rebase 64bit patch
- package new file %{_bindir}/malsync


mboxgrep-0.7.9-7.fc11
---------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 0.7.9-7
- Fix Patch0:/%patch mismatch.


mingw32-filesystem-42-1.fc11
----------------------------
* Wed Jan 14 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 42-1
- Add pseudo-provides secur32.dll


mkinitrd-6.0.74-1.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Jeremy Katz <katzj at redhat.com> - 6.0.74-1
- modesetting for live images


mutt-1.5.19-2.fc11
------------------
* Wed Jan 14 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 5:1.5.19-2
- Rebuild for deps


netbeans-javaparser-6.5-1.fc11
------------------------------
* Wed Dec 24 17:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.5-1
- New vesion of sources
- Call of the brp-java-repack-jars script is disabled


netbeans-svnclientadapter-6.5-1.fc11
------------------------------------
* Tue Dec 23 17:00:00 2008 Victor G. Vasilyev <victor.vasilyev at sun.com> 6.5-1
- Adapt to NetBeans 6.5
- Change URL tag
- Use the original upstream's vcs (version 1.4.0)


ntp-4.2.4p6-1.fc11
------------------
* Wed Jan 14 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 4.2.4p6-1
- update to 4.2.4p6 (CVE-2009-0021)
- include dhclient script (David Cantrell)
- convert COPYRIGHT to UTF-8


osiv-2.0.0-0.6.beta.fc11
------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.0.0-0.6.beta
- Fix Patch0:/%patch mismatch.

* Fri May 23 18:00:00 2008 Jon Stanley <jonstanley at gmail.com> - 2.0.0-0.5.beta
- Fix license tag


osmo-0.2.4-3.fc11
-----------------
* Wed Jan 14 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.2.4-3
- Disable libsyncml until version with support for new syncml 0.5.0 is
  released (#479954)


papyrus-0.8.0-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.8.0-1
- New release

* Mon Jan  5 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.7.91-1
- New release

* Fri Jan  2 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.7.90-1
- New release


pards-0.4-7.fc11
----------------

pdsh-2.17-1.fc11
----------------
* Wed Jan 14 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 2.17-1
- update to 2.17
- fix netgroup


perl-GDTextUtil-0.86-12.fc11
----------------------------
* Wed Jan 14 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 0.86-12
- no need to package this font, only used for buildtime tests


perl-XML-Smart-1.6.9-2.fc11
---------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.6.9-2
- Fix Patch0:/%patch mismatch.


pmd-4.2.4-1.fc11
----------------
* Wed Jan 14 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 0:4.2.4-1
- Upgrade to 4.2.4
- Drop unnecessary scripts/files in etc
- Add more documentation files
- Drop useless manual subpackage; it's really small, and contains files that
  should be docs for the main package


po4a-0.34-1.fc11
----------------
* Tue Jan 13 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 0.34-1
- Reset %release.
- Add BuildRequires: perl(Test::More), BuildRequires: docbook-dtds.
- Activate tests.
- Fix Source0:-URL.
- Spec file cosmetics.

* Sun Aug 24 18:00:00 2008 Axel Thimm <Axel.Thimm at ATrpms.net>
- Update to 0.34.


policycoreutils-2.0.61-2.fc11
-----------------------------
* Wed Jan 14 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-2
- Split python into a separate package


qemu-launcher-1.7.4-5.fc11
--------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.7.4-5
- Fix Patch0:/%patch mismatch.


rocksndiamonds-3.2.6.0-1.fc11
-----------------------------
* Wed Feb 20 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> 3.2.4-1
- update to 3.2.4
- keep music in their own tarball


shorewall-4.2.4-4.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.4-4
- Really update shorewall-perl to 4.2.4.6

* Thu Jan 15 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.4-3
- Update shorewall-perl to 4.2.4.6

* Thu Jan 15 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.4-2
- Fix up dependencies between sub-packages
- No longer attempt to own all files in /var/lib/shorewall* but rather clean
  them up on package removal


subtitleeditor-0.30.0-3.fc10
----------------------------
* Thu Dec 11 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.30.0-3
- Apply patch to upstream bug 12649 (lubek)
- Various changes to spec file (lubek)

* Sat Dec  6 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.30.0-2
- Add intltool to BuildRequires

* Sat Dec  6 17:00:00 2008 Martin Sourada <mso at fedoraproject.org> - 0.30.0-1
- Drop rhbz #459792 workaround
- New upstream release
 - Each function work around extension system (enable/disable/configure)
 - Add 'Generate Wavefrom From Video'
 - Add line break policy option: soft, hard, intelligent (ASS/SSA)
 - Add 'Wavefrom & Media' filter in the wavefrom dialog
 - The subtitle format system was completely rewritten
 - Update the UI when files are open.
 - Add option --enable-profiling
 - New Error Checking tool.
 - New options to set default document values.
 - Add "Edit Cell" and "Edit Next Cell".
 - Another characters coding can be selected if it fails.
 - Waveform Renderer use now Pango to draw subtitle text.

* Mon Aug 25 18:00:00 2008 Martin Sourada <martin.sourada at gmail.com> - 0.22.3-1
- New upstream release
- Don't build with cppunit testing (rhbz #458607)
- Workaround rhbz #459792


sundials-2.3.0-7.fc11
---------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 2.3.0-7
- Fix Patch0:/%patch mismatch (#463065).


sysklogd-1.5-7.fc11
-------------------
* Wed Jan 14 17:00:00 2009 Jeroen van Meeuwen <kanarip at kanarip.com> - 1.5-7
Fix chkconfig line (#478794)


system-autodeath-0.2-2.fc11
---------------------------
* Tue Jan 13 17:00:00 2009 Seth Vidal <skvidal at fedoraproject.org>
- specific system-autodeath.conf


system-config-users-1.2.84-1.fc11
---------------------------------

tcpreplay-3.4.0-2.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Bojan Smojver <bojan at rexursive com> - 3.4.0-2
- correct libdnet BR logic

* Thu Jan 15 17:00:00 2009 Bojan Smojver <bojan at rexursive com> - 3.4.0-1
- bump up to 3.4.0
- add libdnet-devel to BR


tremulous-1.1.0-7.fc11
----------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 1.1.0-7
- Fix Patch0:/%patch mismatch.


unbound-1.2.0-1.fc11
--------------------
* Wed Jan 14 17:00:00 2009 Paul Wouters <paul at xelerance.com - 1.2.0-1
- Updated to 1.2.0
- Added dependancy on minimum SSL for CVE-2008-5077
- Added dependancy on bc for unbound-munin
- Added minimum requirement of libevent 1.4.5. Crashes with older versions
  (note: libevent is stale in EL-4 and not in EL-5, needs fixing there)
- Removed dependancy on selinux-policy (will get used when available)
- Enable options as per draft-wijngaards-dnsext-resolver-side-mitigation-00.txt
- Enable unwanted-reply-threshold to mitigate against a Kaminsky attack
- Enable val-clean-additional to drop addition unsigned data from signed
  response.
- Removed patches (got merged into upstream)


usermode-1.99-2
---------------
* Wed Jan 14 17:00:00 2009 Miloslav Trma?? <mitr at redhat.com> - 1.99-2
- Fix problems pointed out in merge review:
  - Drop Conflicts: SysVinit < very-old
  - Remove very old version requirements from Requires and BuildRequires
  - Make /etc/security/console.apps/* %config(noreplace)
  - Update BuildRoot


vbetool-1.1-2.fc11
------------------
* Wed Jan 14 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 1.1-2
- exclude sparc arches missing sys/io.h


worminator-3.0R2.1-9.fc11
-------------------------
* Sun Sep 21 18:00:00 2008 Ville Skytt?? <ville.skytta at iki.fi> - 3.0R2.1-9
- Fix Patch0:/%patch mismatch.


Summary:
Added Packages: 21
Removed Packages: 0
Modified Packages: 70
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From nicolas.mailhot at laposte.net  Thu Jan 15 08:44:05 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Jan 2009 09:44:05 +0100 (CET)
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <20090114222022.GF7770@calliope.phig.org>
References: <20090114222022.GF7770@calliope.phig.org>
Message-ID: <92dd59b94e93f2e808f01d086eace860.squirrel@arekh.dyndns.org>


Hi

I suspect you'll find moving of packaging guidelines outside the wiki
harder than you think.

Some guideline pages are much more complex under the hood than it may
seem at first sight, with cross-references, transclusion and other
wiki magic.

Also that does not address the gray area of "almost official
guidelines" help pages which are not strict enough of complete enough
yet to be officialised, and need to stay in the wiki while they slowly
mature so people can easily contribute polishing fixes.

Those absolutely need to integrate well with official guidelines and
be able to reference sub-parts of them.

PS
I'll personally object strongly to making guidelines writers shoulder
the burden of converting to CMS syntax. Writing good guidelines is
hard enough without having to take care of the quirks of multiple
document systems.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Thu Jan 15 09:09:01 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Jan 2009 10:09:01 +0100 (CET)
Subject: [Fedora-packaging] Draft vote on Font Package Naming
In-Reply-To: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.
	phx2.redhat.com>
References: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <b35c5e3fd1075200e42a2f53b9b9d72b.squirrel@arekh.dyndns.org>



Le Jeu 15 janvier 2009 00:53, Jens Petersen a ?crit :
>
> ----- "Tom \"spot\" Callaway" <tcallawa at redhat.com> wrote:
>> The draft is available here:
>> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%
>> 282009-01-13%29
>
> Sorry but this is not a good idea IMO.

BTW I think Jens objects strongly because he did not see some of the
horrific naming changes FPC proposed first, which would have resulted
in mass srpm renames and totally un-obvious srpm name -> rpm name
mappings.
(and we use srpm names to reference packages in all our infra tools)

The current FPC-approved draft is a lot saner and does not require too
much implementing work I think:

1. it does not change existing font srpm names at all, except for
 - the handful of packages that didn't respect strictly the previous
semi-official naming guidelines (I write semi-official because even
though no explicit font naming guideline was written down a naming
style was suggested in official font spec templates)
 - the handfuls of packages which didn't use foundryname prefixes when
they could (and we'd planned to make them change them anyway since
having some packages with this prefix and others without was
confusing to users and packagers)

2. does change font subpackage names slightly for font subpackages of
font srpms. I've pushed a new fontpackages-* rpm set (templates and
macros) to rawhide that minimizes the changes needed to existing font
specs to adapt to FPC naming (only %package and %description lines)

Of course packagers will still have to add Obsoletes manually, plus
some sort of Provides transition for the few font packages that other
packages depend on

Actual subpackage content and internal file layout didn't change.

3. Clarifies the font subpackage naming for font subpackages of
non-font srpms. Well since there was no clear convention before, and
inconsistent naming practices, any clear naming guideline was going to
require changes in most packages. I've adapted the macros to force the
FPC naming rules in that case.

WARNING 2. and 3. mean that trying to rebuild a srpm with font
subpackages in rawhide without doing the small spec changes entailed
by the new naming rules adopted by

As a test I've rebuilt a few font packages on my system, and changed
bitstream vera in rawhide, to verify it works in koji (it does), and
to provide people an example of what the renaming entails in practice
for a non-trivial font package.

Sincerely,

-- 
Nicolas Mailhot



From hughsient at gmail.com  Thu Jan 15 09:14:37 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 15 Jan 2009 09:14:37 +0000
Subject: rawhide report: 20090115 changes
In-Reply-To: <20090115075651.EFFF61F825D@releng2.fedora.phx.redhat.com>
References: <20090115075651.EFFF61F825D@releng2.fedora.phx.redhat.com>
Message-ID: <1232010877.6463.0.camel@hughsie-work.lan>

On Thu, 2009-01-15 at 07:56 +0000, Rawhide Report wrote:
> fontpackages-1.14-1.fc11
> ------------------------
> * Wed Jan 14 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot
> org>
> - 1.13-1
> ? Update for subpackage naming changes requested by FPC

Less redundant UTF8 please.

Richard.




From rjones at redhat.com  Thu Jan 15 09:48:20 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 15 Jan 2009 09:48:20 +0000
Subject: Heads up: MySQL 5.1 coming soon to rawhide
In-Reply-To: <17597.1231954770@sss.pgh.pa.us>
References: <17597.1231954770@sss.pgh.pa.us>
Message-ID: <20090115094820.GA30562@amd.home.annexia.org>


Also ocaml-mysql{,-devel}.  For some reason this is lacking a
dependency on the library, but it certainly needs one.  In any case
I'll rebuild it once you've made an announcement that the new mysql
client has been built.

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 sundaram at fedoraproject.org  Thu Jan 15 10:04:59 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 15:34:59 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496E67C0.20609@kanarip.com>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>
Message-ID: <496F0A4B.5090504@fedoraproject.org>

Jeroen van Meeuwen wrote:

> 
> We've beaten that horse during FUDCon and the Spins Process is now 
> separate from the Feature Process, although with the primary features of 
> the Feature Process such as Freezes and Wrangling.

Such decisions shouldn't be taken at FUDCon because it automatically 
excludes people who cannot be present at the event. You should use the 
events only to discuss the issues and make the decisions over mailing 
lists or irc where others can participate as well.

The problem with this whole process is not FESCo didn't want the spins 
to be considered features but how it has been not been delegated 
properly and who is responsible for the final decisions is still 
unclear. Ideally, FESCo would have still considered spins as features so 
that spin maintainers have a procedure to follow up until the time, 
alternative procedure and a owner/team responsible for the final 
decision is outlined somewhere.

I am not sure what to do for the Xfce spin or the local language spins 
now.  Anyone want to clarify this?

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 10:14:29 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 15:44:29 +0530
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>
Message-ID: <496F0C85.3000307@fedoraproject.org>

Jon Stanley wrote:

> We'll work with each individual list owner in order to determine a
> date for the migration. 

Can you also make sure that the list descriptions are updated, has valid 
links etc as part of the migration process? I was trying to do this 
already but if you are already working with owners, we can do this 
together.

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 10:16:40 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 15:46:40 +0530
Subject: rawhide report: 20090115 changes
In-Reply-To: <1232010877.6463.0.camel@hughsie-work.lan>
References: <20090115075651.EFFF61F825D@releng2.fedora.phx.redhat.com>
	<1232010877.6463.0.camel@hughsie-work.lan>
Message-ID: <496F0D08.9080103@fedoraproject.org>

Richard Hughes wrote:
> On Thu, 2009-01-15 at 07:56 +0000, Rawhide Report wrote:
>> fontpackages-1.14-1.fc11
>> ------------------------
>> * Wed Jan 14 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot
>> org>
>> - 1.13-1
>> ? Update for subpackage naming changes requested by FPC
> 
> Less redundant UTF8 please.

We really can't be having this discussion everytime he does this. Just 
invest the time in getting the packaging guidelines updated instead.

Rahul



From tmraz at redhat.com  Thu Jan 15 09:14:34 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 15 Jan 2009 10:14:34 +0100
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <496E6C09.9050002@nobugconsulting.ro>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<496E6C09.9050002@nobugconsulting.ro>
Message-ID: <1232010875.5215.66.camel@vespa.frost.loc>

On Thu, 2009-01-15 at 00:49 +0200, Manuel Wolfshant wrote:
> On 01/15/2009 12:03 AM, Tomas Mraz wrote:
> > I am going to build new openssl into rawhide really soon. As the new
> > version contains some minor ABI breaks it will require SONAME bump of
> > the openssl libraries. That also means all the 288 dependent packages
> > will have to be rebuilt. Not counting that some of the dependent
> > packages have circular dependencies.
> >
> > But do not be scared. As the ABI break is pretty minimal and as it
> > should not affect a large majority of applications I am going to
> > temporarily provide symlinks to the old library soname and appropriate
> > provides in the rpm package. Of course this will be dropped as soon as
> > all (or majority of) the dependencies are rebuilt.
> >
> > As the library should not break any major application I'd like to not
> > wait for the alpha unfreeze as the rebuild of all the deps will surely
> > take some time.
> >   
> Shout loud over here after your builds have been started, please. Bonus 
> points for providing  the  link to the koji task#, so that we can track it.
> TIA

It's building just now.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1054795

I will be rebuilding the dependent packages in the next days. If you own
a package from the list which you don't want me to rebuild please send
me an e-mail. I will not be rebuilding the packages which also depend on
mysql because they will have to be rebuilt after the planned update to
MySQL-5.1 anyway.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From rjones at redhat.com  Thu Jan 15 10:20:55 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 15 Jan 2009 10:20:55 +0000
Subject: Fedora MinGW status, reviews and F11 feature freeze
Message-ID: <20090115102055.GA30871@amd.home.annexia.org>

[Originally sent to the Fedora-MinGW mailing list, but CC'd to
fedora-devel-list for wider distribution]

It only seems like last week that Fedora 10 was released, and now
Fedora 11 Alpha Freeze is on us, next week.

  https://fedoraproject.org/wiki/Releases/11/Schedule

There's no immediate danger of us missing out on the Windows cross-
compiler feature for Fedora 11, because the deadline is the middle of
April, BUT it would be better to get as many packages in sooner rather
than later, say by the Beta freeze (in about 6 weeks).

So here are some stats as to how we're doing ...

                    Packages added: 11
           Packages being reviewed:  5
        Packages waiting in review: 23
Packages not yet added to bugzilla: 30

                             Total: 69

If we discount the packages which are not yet in Bugzilla (mainly
these are C++ and OCaml libraries), and include the 4 packages which
are likely to get into Fedora with relative ease this week, then our
percentage progress is:

                      -->   38%   <--

(We are well under 20% progress if you include a reasonable range of
C++ libraries in the total).

Any effort that people can make to take and review packages on the
list is always helpful.  I am willing to swap reviews of non-MinGW
packages with anyone who wants to do a MinGW review.

  https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32

Some easy reviews (small packages, no/very few dependencies):

  https://bugzilla.redhat.com/show_bug.cgi?id=467388  mingw32-pdcurses
  https://bugzilla.redhat.com/show_bug.cgi?id=467399  mingw32-readline
  https://bugzilla.redhat.com/show_bug.cgi?id=467391  mingw32-gdbm
  https://bugzilla.redhat.com/show_bug.cgi?id=467396  mingw32-freetype
  https://bugzilla.redhat.com/show_bug.cgi?id=467403  mingw32-libgpg-error
  https://bugzilla.redhat.com/show_bug.cgi?id=467410  mingw32-libgcrypt

Some slightly harder ones, but still not too difficult:

  https://bugzilla.redhat.com/show_bug.cgi?id=467414  mingw32-gnutls
  https://bugzilla.redhat.com/show_bug.cgi?id=467402  mingw32-glib2
  https://bugzilla.redhat.com/show_bug.cgi?id=467398  mingw32-gettext

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 fedora at leemhuis.info  Thu Jan 15 10:28:59 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Jan 2009 11:28:59 +0100
Subject: IRC in Fedora (was: Re: [Fedora-spins] Spins SIG Meeting(s) /
	Agenda!)
In-Reply-To: <496F0A4B.5090504@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>
Message-ID: <496F0FEB.9000406@leemhuis.info>

(removing the spins list)

On 15.01.2009 11:04, Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
> 
>> We've beaten that horse during FUDCon and the Spins Process is now 
>> separate from the Feature Process, although with the primary features of 
>> the Feature Process such as Freezes and Wrangling.
> 
> Such decisions shouldn't be taken at FUDCon because it automatically 
> excludes people who cannot be present at the event.  You should use the
> events only to discuss the issues and make the decisions over mailing 
> lists or irc where others can participate as well.

Your first sentence IMHO holds true for IRC as well -- there are a lot 
of people that don't want to go on IRC or simply can't, as meetings 
might happen in the middle of the night in their timezone or while they 
are on work without access to IRC.

IMHO IRC has become a really big problem for Fedora -- we should use it 
a whole lot less for working out decisions, not more(?).

CU
knurd

(?) I'm well aware that meeting on IRC often help a lot to bring things 
forward and make a decisions; I don't want to stop that -- that's 
actually why I wrote "working our decisions" and not "making decisions" 
above; but things should be discussed in public on a different, a bit 
more time-independent medium as well, to make sure that those people 
that can't or don't want to join IRC meetings can share their view and 
know what and why something happens



From pingou at pingoured.fr  Thu Jan 15 10:32:08 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 15 Jan 2009 11:32:08 +0100
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <496F0C85.3000307@fedoraproject.org>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>
	<496F0C85.3000307@fedoraproject.org>
Message-ID: <496F10A8.9040800@pingoured.fr>

Rahul Sundaram wrote:
> Jon Stanley wrote:
> 
>> We'll work with each individual list owner in order to determine a
>> date for the migration. 
> 
> Can you also make sure that the list descriptions are updated, has valid 
> links etc as part of the migration process? I was trying to do this 
> already but if you are already working with owners, we can do this 
> together.

I have probably missed something, but the Mailing Lists will be migrated 
to what ?

Thanks,

Pierre



From jan.kratochvil at redhat.com  Thu Jan 15 10:34:57 2009
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Thu, 15 Jan 2009 11:34:57 +0100
Subject: Rawhide PPC64
In-Reply-To: <870180fe0901141840m6bb88713gc11d27805e6000bf@mail.gmail.com>
References: <870180fe0901141840m6bb88713gc11d27805e6000bf@mail.gmail.com>
Message-ID: <20090115103457.GA17689@host0.dyn.jankratochvil.net>

Hi,

On Thu, 15 Jan 2009 03:40:11 +0100, Jerry James wrote:
> mock-chroot> gdb raw_pre_gcl
> GNU gdb (GDB) Fedora (6.8.50.20081214-1.fc11)
...
> Segmentation fault

confirming current Rawhide GDB segfaults on ppc64, going to fix it; you could
file a normal Bug for it.

> I don't know why rpmdb is involved at all [1]
> [1] Is this so gdb can find the debuginfo?

Yes.


Thanks,
Jan



From sundaram at fedoraproject.org  Thu Jan 15 10:35:20 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 16:05:20 +0530
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <496F1168.3080504@fedoraproject.org>

seth vidal wrote:

> There's a fair number more things to iron out and constructive and
> helpful remarks are welcome. :)
> 

Have you considered taking this to distributions at freedesktop.org and 
discussion about having a single format between distributions for 
defining groups? SUSE shares repomd format but has defined their own 
group structure at

http://en.opensuse.org/Patterns

Debian and Ubuntu seems to rely on metapackages and task selects. Some 
coordination would be helpful.

Rahul



From laxathom at fedoraproject.org  Thu Jan 15 10:38:28 2009
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Thu, 15 Jan 2009 11:38:28 +0100
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <496F10A8.9040800@pingoured.fr>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>
	<496F0C85.3000307@fedoraproject.org> <496F10A8.9040800@pingoured.fr>
Message-ID: <62bc09df0901150238o55ed0bc1ybdbeb9596ea2fc20@mail.gmail.com>

On Thu, Jan 15, 2009 at 11:32 AM, Pierre-Yves <pingou at pingoured.fr> wrote:
> Rahul Sundaram wrote:
>>
>> Jon Stanley wrote:
>>
>>> We'll work with each individual list owner in order to determine a
>>> date for the migration.
>>
>> Can you also make sure that the list descriptions are updated, has valid
>> links etc as part of the migration process? I was trying to do this already
>> but if you are already working with owners, we can do this together.
>
> I have probably missed something, but the Mailing Lists will be migrated to
> what ?

The domain name will change.
e.g you will have <fedora-development-list at lists.fedoraproject.org> instead


Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From bnocera at redhat.com  Thu Jan 15 11:02:18 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 15 Jan 2009 11:02:18 +0000
Subject: Keyboard shortcut buttons logs out of Gnome/X
In-Reply-To: <1231952196.4947.6.camel@scrappy.miketc.net>
References: <1231952196.4947.6.camel@scrappy.miketc.net>
Message-ID: <1232017338.13084.0.camel@snoogens.fab.redhat.com>

On Wed, 2009-01-14 at 10:56 -0600, Mike Chambers wrote:
> I have a Microsoft Wireless Desktop keyboard/mouse 2000.  And in F10 the
> keyboard shortcuts (buttons to start email, browser, volume adjustments,
> etc..) work just fine.
> 
> In Rawhide, if I hit one of them, it logs me out of Gnome/X and back to
> the login screen.  I tried setting the keyboard to the MS Wireless
> Multimedia keyboard 1A but that doesn't help.  Not sure it matters what
> I select.  Any ideas  and what component would I file a bug against if I
> need to?

How do you know it logs you out, and it's not actually X crashing?



From kanarip at kanarip.com  Thu Jan 15 11:58:44 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 12:58:44 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F0A4B.5090504@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>
Message-ID: <496F24F4.7090009@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
> 
>> We've beaten that horse during FUDCon and the Spins Process is now 
>> separate from the Feature Process, although with the primary features of 
>> the Feature Process such as Freezes and Wrangling.
> 
> Such decisions shouldn't be taken at FUDCon because it automatically 
> excludes people who cannot be present at the event. You should use the 
> events only to discuss the issues and make the decisions over mailing 
> lists or irc where others can participate as well.
> 

I'm sorry if I hurt your feelings by abusing FUDCon like this (in your 
opinion), but let me tell you I'll do it again whenever I feel like it.

Everyone involved was there, everyone agreed. This process is set. 
Arguments go to the list. Voting happens next week during the SIG meeting.

If you have a problem with that, please state it. Please be precise in 
what you think we've done so tremendously wrong, that our ability to 
make a decision, gather input and then have a vote on the result 
deserves to be questioned, by you no less.

because although I do understand your argument against deciding stuff at 
FUDCon, I do not understand what is your problem with how things are 
moving forward right now.

> The problem with this whole process is not FESCo didn't want the spins 
> to be considered features but how it has been not been delegated 
> properly and who is responsible for the final decisions is still 
> unclear. Ideally, FESCo would have still considered spins as features so 
> that spin maintainers have a procedure to follow up until the time, 
> alternative procedure and a owner/team responsible for the final 
> decision is outlined somewhere.
> 

- Define "this" in "The problem with this whole process", because I 
don't understand which process you are referring to.

- Explain to me how "The Spin SIG for technical approval and the Board 
for a rubber trademark stamp" leaves you inconclusive about who has the 
final verdict on whether a Spin can be a Spin or not.

- Explain to me what you mean by "Ideally, FESCo would have still 
considered spins as features" because Spins being Features yet not being 
Features was one of the hurdles we needed to overcome by setting up a 
new process.

> I am not sure what to do for the Xfce spin or the local language spins 
> now.  Anyone want to clarify this?
> 

In case you haven't noticed, they are on the agenda. I can already say 
that a Spin Page will need to be created (but not for the Localized 
Spins), or a current page needs to be relocated or possibly 
re-categorized. In any way, this is why these items are on the agenda; 
to establish what needs to happen (to what spin), and to determine who's 
going to take care of that (spin maintainers? SIG?).

Kind regards,

Jeroen van Meeuwen
-kanarip



From withoutreboot at gmail.com  Thu Jan 15 12:00:10 2009
From: withoutreboot at gmail.com (CQC)
Date: Thu, 15 Jan 2009 10:00:10 -0200
Subject: linux-gate.so.1
Message-ID: <58968c1e0901150400u65fb7530hf0b0d0533a0be35f@mail.gmail.com>

Hello, everyone,


I have a saprouter program that is not connect.
When I try to connect it returns a message. Please, see below:

# ./conexao_saprouter

trcfile  dev_rout

*****************************************************************************
*
*  ERROR       SNC processing failed:
*              SncInit
*
*  TIME        Thu Jan 15 09:57:31 2009
*  RELEASE     700
*  COMPONENT   NI (network interface)
*  VERSION     38
*  RC          -17
*  MODULE      nisnc.c
*  LINE        646
*  DETAIL      NiSncInit: sncrc=-1
*  COUNTER     3
*
*****************************************************************************


I checked the libraries necessary.


# ldd saprouter
    linux-gate.so.1 =>  (0x00302000)
    libdl.so.2 => /lib/libdl.so.2 (0x00b23000)
    librt.so.1 => /lib/librt.so.1 (0x00bfa000)
    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x001a7000)
    libm.so.6 => /lib/libm.so.6 (0x00b29000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00de2000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00b52000)
    libc.so.6 => /lib/libc.so.6 (0x009e1000)
    /lib/ld-linux.so.2 (0x009c4000)


Meeting all libraries, except one:

# locate linux-gate.so.1
#

I look for package in rpm.pbone.net to install this library but not found.

Any suggestions?

Thanks

CQC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/0ee16499/attachment.htm>

From promac at gmail.com  Thu Jan 15 12:10:40 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Thu, 15 Jan 2009 10:10:40 -0200
Subject: Lazarus/fpc
Message-ID: <68720af30901150410o499208b6mbe47981c5aa9621a@mail.gmail.com>

Hi,

I would like to ask that the Lazarus package were updated to
version 0.9.26, which has a lot of improvements. It is running
just fine for me in F8 and F10, although some previous application
code had to be adapted slightly.

Also, for being able to access mysql, it would be nice
if the file /etc/fpc.cfg (from fpc) contained the appropriate
Fedora path by default.
Is there anything that precludes this change, or can
I just open a bug report?

Thanks.


-----------------------------------

# searchpath for libraries
#ifdef cpux86_64
-Fl/usr/lib/gcc/x86_64-redhat-linux/4.1.2
# roma
-Fl/usr/lib64/mysql
#endif


#ifdef cpui386
-Fl/usr/lib/gcc/x86_64-redhat-linux/4.1.2/32
# roma
-Fl/usr/lib/mysql
#endif

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/6850efaf/attachment.htm>

From jwboyer at gmail.com  Thu Jan 15 12:44:17 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Jan 2009 07:44:17 -0500
Subject: linux-gate.so.1
In-Reply-To: <58968c1e0901150400u65fb7530hf0b0d0533a0be35f@mail.gmail.com>
References: <58968c1e0901150400u65fb7530hf0b0d0533a0be35f@mail.gmail.com>
Message-ID: <20090115124417.GA2582@yoda.jdub.homelinux.org>

On Thu, Jan 15, 2009 at 10:00:10AM -0200, CQC wrote:
>Hello, everyone,
>
>
>I have a saprouter program that is not connect.
>When I try to connect it returns a message. Please, see below:
>
># ./conexao_saprouter
>
>trcfile  dev_rout
>
>*****************************************************************************
>*
>*  ERROR       SNC processing failed:
>*              SncInit
>*
>*  TIME        Thu Jan 15 09:57:31 2009
>*  RELEASE     700
>*  COMPONENT   NI (network interface)
>*  VERSION     38
>*  RC          -17
>*  MODULE      nisnc.c
>*  LINE        646
>*  DETAIL      NiSncInit: sncrc=-1
>*  COUNTER     3
>*
>*****************************************************************************
>
>
>I checked the libraries necessary.
>
>
># ldd saprouter
>    linux-gate.so.1 =>  (0x00302000)
>    libdl.so.2 => /lib/libdl.so.2 (0x00b23000)
>    librt.so.1 => /lib/librt.so.1 (0x00bfa000)
>    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x001a7000)
>    libm.so.6 => /lib/libm.so.6 (0x00b29000)
>    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00de2000)
>    libpthread.so.0 => /lib/libpthread.so.0 (0x00b52000)
>    libc.so.6 => /lib/libc.so.6 (0x009e1000)
>    /lib/ld-linux.so.2 (0x009c4000)
>
>
>Meeting all libraries, except one:
>
># locate linux-gate.so.1
>#
>
>I look for package in rpm.pbone.net to install this library but not found.
>
>Any suggestions?

This is off-topic for this list.

linux-gate is the vDSO.  You won't find an RPM for it.

josh



From sundaram at fedoraproject.org  Thu Jan 15 12:46:39 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 18:16:39 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F24F4.7090009@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com>
Message-ID: <496F302F.6030905@fedoraproject.org>

Jeroen van Meeuwen wrote:
> Rahul Sundaram wrote:
>> Jeroen van Meeuwen wrote:
>>
>>> We've beaten that horse during FUDCon and the Spins Process is now 
>>> separate from the Feature Process, although with the primary features of 
>>> the Feature Process such as Freezes and Wrangling.
>> Such decisions shouldn't be taken at FUDCon because it automatically 
>> excludes people who cannot be present at the event. You should use the 
>> events only to discuss the issues and make the decisions over mailing 
>> lists or irc where others can participate as well.
>>
> 
> I'm sorry if I hurt your feelings by abusing FUDCon like this (in your 
> opinion), but let me tell you I'll do it again whenever I feel like it.

Please don't put words in my mouth. I never said you were abusing 
FUDCon.  It is a general principle to be inclusive of everyone in the 
community as much as possible. That means, not making decisions in a 
place where many people just cannot attend to state their arguments or 
present alternative view points.

> Everyone involved was there, everyone agreed. This process is set. 

Sorry. no. Not everyone involved was there and unlikely to ever be. 
There are many spin maintainers and spin SIG members not present at FUDCon.

> Arguments go to the list. Voting happens next week during the SIG meeting.
> 
> If you have a problem with that, please state it. Please be precise in 
> what you think we've done so tremendously wrong, that our ability to 
> make a decision, gather input and then have a vote on the result 
> deserves to be questioned, by you no less.
>
> because although I do understand your argument against deciding stuff at 
> FUDCon, I do not understand what is your problem with how things are 
> moving forward right now.

A bunch of people went ahead and made some decisions in FUDCon and when 
others raises their concern over that decision and decision making 
process, you are being unnecessarily abrasive and dismissive about it.

I don't want decisions being made without being communicated at all in 
some random location in the world. If you make a decision, do it over 
mailing lists or on  less preferably on irc ( after announcing ahead of 
time) where people involved or concerned can present their opinions. 
FUDCon should be just for discussions.

>> The problem with this whole process is not FESCo didn't want the spins 
>> to be considered features but how it has been not been delegated 
>> properly and who is responsible for the final decisions is still 
>> unclear. Ideally, FESCo would have still considered spins as features so 
>> that spin maintainers have a procedure to follow up until the time, 
>> alternative procedure and a owner/team responsible for the final 
>> decision is outlined somewhere.
>>
> 
> - Define "this" in "The problem with this whole process", because I 
> don't understand which process you are referring to.

The spins process or lack of clarity in one.

> - Explain to me how "The Spin SIG for technical approval and the Board 
> for a rubber trademark stamp" leaves you inconclusive about who has the 
> final verdict on whether a Spin can be a Spin or not.

I am sure, you are aware of the prior discussions on this topic. How 
many spin SIG meetings have there been and which spins have been 
approved there? In the last release, Xfce and Games spin was approved in 
a rel-eng meeting, fyi. I have explained another problem I ran into at

https://www.redhat.com/archives/fedora-advisory-board/2008-December/msg00054.html

> - Explain to me what you mean by "Ideally, FESCo would have still 
> considered spins as features" because Spins being Features yet not being 
> Features was one of the hurdles we needed to overcome by setting up a 
> new process.

You are forgetting a bit of history here. Spins were considered as 
features before FESCo voted against it.

http://fedoraproject.org/wiki/Releases/8/FeatureList

See the electronics lab as a feature in there?

Rahul



From kanarip at kanarip.com  Thu Jan 15 12:59:19 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 13:59:19 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F302F.6030905@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>
Message-ID: <496F3327.40903@kanarip.com>

Rahul Sundaram wrote:
> 

I'm done arguing with you. Either comment on the process before the vote 
on Monday or forever hold your peace.

Kind regards,

Jeroen van Meeuwen
-kanarip



From sundaram at fedoraproject.org  Thu Jan 15 13:23:48 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 18:53:48 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F3327.40903@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com>
Message-ID: <496F38E4.1060108@fedoraproject.org>

Jeroen van Meeuwen wrote:
> Rahul Sundaram wrote:
>>
> 
> I'm done arguing with you. Either comment on the process before the vote 
> on Monday or forever hold your peace.

Which process are you referring to now? I have commented on the spins 
process extensively in here (I originally outlined a proposal on board's 
request as the person having creating the first official spins) and 
elsewhere as well before but it appears you have already made up your 
mind in FUDCon and don't want any input.

As far as I am concerned, spin = feature worked just fine before FESCo 
decided to vote against that, leaving it in limbo.  For Fedora 9 and 
Fedora 10, there has been a lot of confusion over what should be done.

For Fedora 10, I went to rel-eng just so that some decisions can be 
made. For Fedora 11, the process outlined doesn't have enough details 
(just as an example: what should a report contain? how often would there 
be a spin sig meeting. Can I vote for my own spins as a spin sig member? 
Is everyone who signs up as a spin sig member by merely editing the wiki 
get to vote?). The process has now been made more cumbersome by 
mandating by weekly composes and reports (who decided on that?). Instead 
of helping spin maintainers, this process seems to be making it more 
difficult. It is too soon to be voting on this and time isn't suitable 
for me to attend. Let's discuss it first on mailing list.

Rahul



From pinto.elia at gmail.com  Thu Jan 15 13:29:02 2009
From: pinto.elia at gmail.com (devzero2000)
Date: Thu, 15 Jan 2009 14:29:02 +0100
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <1231943326.5086.49.camel@localhost.localdomain>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
	<1231943326.5086.49.camel@localhost.localdomain>
Message-ID: <b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>

2009/1/14 Jesse Keating <jkeating at redhat.com>

> On Wed, 2009-01-14 at 13:00 +0100, yersinia wrote:
> > Sure ? httpd-devel exists but in the x86_64 branch does not exist httpd
> > i386. Or it is  an exception ? And if so why ?
>
> That would only happen if the httpd-devel.i386 package had no arch
> specific requires upon the httpd.i386 package.
>

it is very boring not also have the 32 - bit version of httpd on 64 bit SO.
Often it is required the installation commercial 32 bit apache modules - i
am speaking of RHEL . But certainly install an 32 bit operating system on
machines with 10 g of RAM - that i have - is not a thing magnificent. Then
it would be useful to install on a 64  bit SO AND an 32 bit Apache  but the
repo (or RHN) default don't have. Sure, i can do anyway on RHEL5.

(Aside) On Fedora 10 64  bit i have also enabled the repo 32 but strangely
enough, i have an error of conflict (on RHEL5 it is ok) . But that is  off
topic, perhaps.

yum install httpd.i386

Transaction Check Error:
  file /etc/httpd/modules from install of httpd-2.2.10-2.i386 conflicts with
file from package httpd-2.2.10-2.x86_64

The same with squid.

It is also true with %_transaction_color     3 in /etc/rpm/macros.color

Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/9e03d61c/attachment.htm>

From yersinia.spiros at gmail.com  Thu Jan 15 13:29:42 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Thu, 15 Jan 2009 14:29:42 +0100
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
	<1231943326.5086.49.camel@localhost.localdomain>
	<b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>
Message-ID: <b086760e0901150529g6b648bdbob6697c8860417ada@mail.gmail.com>

2009/1/14 Jesse Keating <jkeating at redhat.com>
>
>
> On Wed, 2009-01-14 at 13:00 +0100, yersinia wrote:
>> > Sure ? httpd-devel exists but in the x86_64 branch does not exist httpd
>> > i386. Or it is  an exception ? And if so why ?
>>
>> That would only happen if the httpd-devel.i386 package had no arch
>> specific requires upon the httpd.i386 package.
>>
>
> it is very boring not also have the 32 - bit version of httpd on 64 bit SO.
> Often it is required the installation commercial 32 bit apache modules - i
> am speaking of RHEL . But certainly install an 32 bit operating system on
> machines with 10 g of RAM - that i have - is not a thing magnificent. Then
> it would be useful to install on a 64  bit SO AND an 32 bit Apache  but the
> repo (or RHN) default don't have. Sure, i can do anyway on RHEL5.
>
> (Aside) On Fedora 10 64  bit i have also enabled the repo 32 but strangely
> enough, i have an error of conflict (on RHEL5 it is ok) . But that is  off
> topic, perhaps.
>
> yum install httpd.i386
>
> Transaction Check Error:
>   file /etc/httpd/modules from install of httpd-2.2.10-2.i386 conflicts
> with file from package httpd-2.2.10-2.x86_64
>
> The same with squid.
>
> It is also true with %_transaction_color     3 in /etc/rpm/macros.color
>
> Best Regards
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/95d3d581/attachment.htm>

From bkearney at redhat.com  Thu Jan 15 13:44:16 2009
From: bkearney at redhat.com (Bryan Kearney)
Date: Thu, 15 Jan 2009 08:44:16 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496E67C0.20609@kanarip.com>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>
Message-ID: <496F3DB0.7020608@redhat.com>

Jeroen van Meeuwen wrote:
> Bryan Kearney wrote:
>> Jeroen van Meeuwen wrote:
>>> The Spins SIG is going to have regular, bi-weekly meetings. I've 
>>> chosen Mondays at 18:00 UTC, on even weeks, and it will not take more 
>>> then one hour.
>>>
>>> Obviously, we can pre-discuss most of the items on the agenda on our 
>>> mailing list fedora-spins -at- lists.fedoraproject.org.
>>>
>>> With help of several key people in the current Spins process, 
>>> including Process-Guru and current Feature Wrangler John Poelstra, 
>>> we've come up with a real Spins Process during this last FUDCon.
>>>
>>> If you are a member of Release Engineering, Quality Assurance, FESCo 
>>> or Infrastructure, I would like you to attend.
>>>
>>> Our first meeting (in the series of regular meetings) would be 
>>> January 19th, 18:00 UTC, for which I'm going to set the Agenda now:
>>>
>>> == Agenda ==
>>>
>>> # Finalizing Spins Process[1], vote
>>
>> May I suggest part of this discussion is spin versus feature. I ask 
>> becuase the process (for me) got hairy when combined with the feature 
>> process.
>>
> 
> We've beaten that horse during FUDCon and the Spins Process is now 
> separate from the Feature Process, although with the primary features of 
> the Feature Process such as Freezes and Wrangling.

Sorry..I was not at FUDCon and did not see the doco. I am fine with the 
outcome, just wanted to see it written down.

Thanks!

-- bk



From cra at WPI.EDU  Thu Jan 15 13:52:08 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 15 Jan 2009 08:52:08 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <20090115135208.GI19432@angus.ind.WPI.EDU>

On Wed, Jan 14, 2009 at 02:51:52PM -0500, seth vidal wrote:
> When someone goes to install the group: 'yum groupinstall
> mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> comps/groups file from each repo, look if the group you're requesting is
> there. If so it will create a metapkg rpm (a package containing only
> requirements) on the packages that exist in the repositories that are
> listed in that group. Then it will depsolve and install that pkg. The
> package name will be @mygroup-of-fun. The package version will be a hash
> of the contents of the package along with a timestamp. It needs to be
> timestamp-based so the version is increasing so we can 'update' these
> pkgs.

Will the installer install @groups or packages?  What if a user 
installs a @group either with anaconda or yum groupinstall, and they 
later decide they don't want one of the packages in that group?  How 
do they remove just one package member?  What is the behavior of "yum 
remove" on a @group?



From jwboyer at gmail.com  Thu Jan 15 13:56:58 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Jan 2009 08:56:58 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F38E4.1060108@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
Message-ID: <20090115135658.GC2582@yoda.jdub.homelinux.org>

On Thu, Jan 15, 2009 at 06:53:48PM +0530, Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
>> Rahul Sundaram wrote:
>>>
>>
>> I'm done arguing with you. Either comment on the process before the 
>> vote on Monday or forever hold your peace.
>
> Which process are you referring to now? I have commented on the spins  
> process extensively in here (I originally outlined a proposal on board's  
> request as the person having creating the first official spins) and  
> elsewhere as well before but it appears you have already made up your  
> mind in FUDCon and don't want any input.
>
> As far as I am concerned, spin = feature worked just fine before FESCo  
> decided to vote against that, leaving it in limbo.  For Fedora 9 and  
> Fedora 10, there has been a lot of confusion over what should be done.

Here's the deal.  Spins have a process that are treated exactly like
Features.  Just because it's not under the purview of FESCo doesn't
mean that it's not still viable.

> For Fedora 10, I went to rel-eng just so that some decisions can be  
> made.

So you are allowed to make arbitrary decisions in a closed group, but
those that did the exact same thing at FUDCon are somehow evil?  Wtf.

> For Fedora 11, the process outlined doesn't have enough details  

OK, now this is the part where you are actually being helpful.

> (just as an example: what should a report contain?

I'm not entirely clear myself here.

> how often would there  be a spin sig meeting. 

Every other week, in the same time-slot as the EPEL meeting.

> Can I vote for my own spins as a spin sig member?  

Yes.

> Is everyone who signs up as a spin sig member by merely editing the wiki  
> get to vote?).

Dunno.  And sort of inconsiquential, given that "gaming the system" isn't
exactly wrong or right either way.

> The process has now been made more cumbersome by  
> mandating by weekly composes and reports (who decided on that?). 

That one came from me.  Having spins fail to compose during the week
that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the
door is simply an easy way to drop the Spin entirely.

It's not more cumbersome.  It's putting the responsibility for the spin
into the hands of the person that cares about it the most, which is the
spin owner.  So the week before a milestone release is going to be busy
for the SIG and the owners, but that is part of being a Spin owner.

> of helping spin maintainers, this process seems to be making it more  
> difficult. It is too soon to be voting on this and time isn't suitable  
> for me to attend. Let's discuss it first on mailing list.

More difficult in areas, yes.  It does help the owners with the process
itself though, since they don't have to play "who do I ask next for
approval" on getting the spin itself actually accepted.

Look, creating an official Spin is not as simple as "here is my kickstart
file, go build this please."  If the owners really want the Spin to
succeed and be released with the rest of the releases that are done, it
needs to at least have some of the same criteria as those.  If that is too
cumbersome or time consuming for someone to do, then they can use a Remix
and do it on their own schedule.

The bar has been raised, and this is not a bad thing.

josh



From rdieter at math.unl.edu  Thu Jan 15 13:59:57 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 15 Jan 2009 07:59:57 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
Message-ID: <gknfh5$9ss$1@ger.gmane.org>

Operator (postnuke.tv) wrote:

> The Zikula project might be very interested... You could have Zikula
> deployed with the project's help and support?
> Moreover, at some point in the near future, we'd like to be providing
> a Fedora RPM for the FC distrib.

The latter, being packaged and included in fedora, is pretty much a
prerequisite for consideration, so... the sooner the better.

-- Rex



From cra at WPI.EDU  Thu Jan 15 14:09:15 2009
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 15 Jan 2009 09:09:15 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090115135208.GI19432@angus.ind.WPI.EDU>
References: <1231962712.14403.1559.camel@rosebud>
	<20090115135208.GI19432@angus.ind.WPI.EDU>
Message-ID: <20090115140915.GJ19432@angus.ind.WPI.EDU>

On Thu, Jan 15, 2009 at 08:52:08AM -0500, Chuck Anderson wrote:
> On Wed, Jan 14, 2009 at 02:51:52PM -0500, seth vidal wrote:
> > When someone goes to install the group: 'yum groupinstall
> > mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> > comps/groups file from each repo, look if the group you're requesting is
> > there. If so it will create a metapkg rpm (a package containing only
> > requirements) on the packages that exist in the repositories that are
> > listed in that group. Then it will depsolve and install that pkg. The
> > package name will be @mygroup-of-fun. The package version will be a hash
> > of the contents of the package along with a timestamp. It needs to be
> > timestamp-based so the version is increasing so we can 'update' these
> > pkgs.
> 
> Will the installer install @groups or packages?  What if a user 
> installs a @group either with anaconda or yum groupinstall, and they 
> later decide they don't want one of the packages in that group?  How 
> do they remove just one package member?  What is the behavior of "yum 
> remove" on a @group?

Sorry, I missed the 2nd half of this thread where my question above is 
answered:

yum remove @group won't remove any real packages or group members, 
just the metapackage.  You'll also lose the ability to track this 
@group when new group-members appear in the repo(s).

yum remove group-member will remove that group-member and the @group's 
metapackage, leaving all the other group-members there.



From ngompa13 at gmail.com  Thu Jan 15 14:16:31 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 15 Jan 2009 08:16:31 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <gknfh5$9ss$1@ger.gmane.org>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
Message-ID: <8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>

I would like to suggest Enano CMS, which fulfills most of the requirements
without plugins. It would take some work to get FAS2 integration and stuff
though. It uses MediaWiki syntax, so it is portable among other CMSes that
support importing MediaWiki data.

On Thu, Jan 15, 2009 at 7:59 AM, Rex Dieter <rdieter at math.unl.edu> wrote:

> Operator (postnuke.tv) wrote:
>
> > The Zikula project might be very interested... You could have Zikula
> > deployed with the project's help and support?
> > Moreover, at some point in the near future, we'd like to be providing
> > a Fedora RPM for the FC distrib.
>
> The latter, being packaged and included in fedora, is pretty much a
> prerequisite for consideration, so... the sooner the better.
>
> -- Rex
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/10ea10bf/attachment.htm>

From skvidal at fedoraproject.org  Thu Jan 15 14:18:14 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 09:18:14 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090115140915.GJ19432@angus.ind.WPI.EDU>
References: <1231962712.14403.1559.camel@rosebud>
	<20090115135208.GI19432@angus.ind.WPI.EDU>
	<20090115140915.GJ19432@angus.ind.WPI.EDU>
Message-ID: <1232029094.14403.1598.camel@rosebud>

On Thu, 2009-01-15 at 09:09 -0500, Chuck Anderson wrote:

> Sorry, I missed the 2nd half of this thread where my question above is 
> answered:
> 
> yum remove @group won't remove any real packages or group members, 
> just the metapackage.

This is true

>   You'll also lose the ability to track this 
> @group when new group-members appear in the repo(s).

If you remove the metapackage then yes, you can't track what you don't
have. If you have the metapackage installed then when new group members
appear you'll get them added to your system.

> yum remove group-member will remove that group-member and the @group's 
> metapackage, leaving all the other group-members there.

yep.

-sv




From kanarip at kanarip.com  Thu Jan 15 14:18:37 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 15:18:37 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F38E4.1060108@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>
Message-ID: <496F45BD.2040803@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
>> Rahul Sundaram wrote:
>> I'm done arguing with you. Either comment on the process before the vote 
>> on Monday or forever hold your peace.
> 
> Which process are you referring to now?

I think this is a good time for you to start reading the agenda.



From kanarip at kanarip.com  Thu Jan 15 14:20:01 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 15:20:01 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F3DB0.7020608@redhat.com>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F3DB0.7020608@redhat.com>
Message-ID: <496F4611.5020303@kanarip.com>

Bryan Kearney wrote:
> Jeroen van Meeuwen wrote:
>> Bryan Kearney wrote:
>>> Jeroen van Meeuwen wrote:
>>>> == Agenda ==
>>>>
>>>> # Finalizing Spins Process[1], vote
>>> May I suggest part of this discussion is spin versus feature. I ask 
>>> becuase the process (for me) got hairy when combined with the feature 
>>> process.
>>>
>> We've beaten that horse during FUDCon and the Spins Process is now 
>> separate from the Feature Process, although with the primary features of 
>> the Feature Process such as Freezes and Wrangling.
> 
> Sorry..I was not at FUDCon and did not see the doco. I am fine with the 
> outcome, just wanted to see it written down.
> 

Cool, fair enough. fwiw, I did not intend to sound harsh by any means.

Kind regards,

Jeroen van Meeuwen
-kanarip



From fedora at matbooth.co.uk  Thu Jan 15 14:23:07 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Thu, 15 Jan 2009 14:23:07 +0000
Subject: Lazarus/fpc
In-Reply-To: <68720af30901150410o499208b6mbe47981c5aa9621a@mail.gmail.com>
References: <68720af30901150410o499208b6mbe47981c5aa9621a@mail.gmail.com>
Message-ID: <9497e9990901150623x92c7aa8y7091982dc08859b3@mail.gmail.com>

2009/1/15 Paulo Cavalcanti <promac at gmail.com>:
> Hi,
>
> I would like to ask that the Lazarus package were updated to
> version 0.9.26, which has a lot of improvements. It is running
> just fine for me in F8 and F10, although some previous application
> code had to be adapted slightly.
>
> Also, for being able to access mysql, it would be nice
> if the file /etc/fpc.cfg (from fpc) contained the appropriate
> Fedora path by default.
> Is there anything that precludes this change, or can
> I just open a bug report?
>
> Thanks.
>


Opening a bug against the package is a more direct way of bringing it
to the package maintainer's attention.


-- 
Mat Booth
www.matbooth.co.uk



From sundaram at fedoraproject.org  Thu Jan 15 14:26:37 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 19:56:37 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F45BD.2040803@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>
	<496F45BD.2040803@kanarip.com>
Message-ID: <496F479D.5030604@fedoraproject.org>

Jeroen van Meeuwen wrote:
> Rahul Sundaram wrote:
>> Jeroen van Meeuwen wrote:
>>> Rahul Sundaram wrote:
>>> I'm done arguing with you. Either comment on the process before the vote 
>>> on Monday or forever hold your peace.
>> Which process are you referring to now?
> 
> I think this is a good time for you to start reading the agenda.

Please stop being dismissive and read the rest of mails where I gave you 
more input.

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 14:28:59 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 19:58:59 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115135658.GC2582@yoda.jdub.homelinux.org>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
Message-ID: <496F482B.8090802@fedoraproject.org>

Josh Boyer wrote:
> 
> Here's the deal.  Spins have a process that are treated exactly like
> Features.  Just because it's not under the purview of FESCo doesn't
> mean that it's not still viable.

It would be still viable if the process is outlined. The process has to 
be in discussed and in place before FESCo delegates it to somebody else. 
After Fedora 8, FESCo essentially said, we don't want to deal with this 
and it has been a mass confusion ever since.

>> For Fedora 10, I went to rel-eng just so that some decisions can be  
>> made.
> 
> So you are allowed to make arbitrary decisions in a closed group, but
> those that did the exact same thing at FUDCon are somehow evil?  Wtf.

A clearly outlined process and someone or a team needs to be accountable 
for decisions. In the absence of it and confusion over the process,  I 
had to deal with somehow getting the spins I owned published  (there 
weren't enough spin sig meetings and I can't be sitting on much if any 
because of different timezones) and asked for help in #fedora-devel and 
was told that rel-eng would approve spins and I participate in the 
meeting and got it approved. None of this was arbitrary or closed. I 
don't see how it compares at all to making decisions in FUDCon and 
claiming everyone was there.

> That one came from me.  Having spins fail to compose during the week
> that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the
> door is simply an easy way to drop the Spin entirely.
> 
> It's not more cumbersome.  It's putting the responsibility for the spin
> into the hands of the person that cares about it the most, which is the
> spin owner.  So the week before a milestone release is going to be busy
> for the SIG and the owners, but that is part of being a Spin owner.

I don't know what you want from a report and full fledged testing and 
reporting every two weeks is just not feasible for multiple spins for me 
as a spin owner.  If you want just to know if it composes or not or if 
it is the right size and things like that, automated composes already 
give that information. Don't ask me to vote on this incomplete proposal. 
Please hash out the details in this list first and then get to the 
voting part. Premature voting would leave us with just as much confusion 
as before.

> Look, creating an official Spin is not as simple as "here is my kickstart
> file, go build this please." 

No, it is not. I have to spend a lot of time, getting that kickstart 
file in place first. It isn't a simple matter of running some composes 
and calling it a day. There is a heck lot of finicky details to take 
care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. 
You know the amount of work it takes to get alpha,beta and general 
releases out. Are you really asking me to do that work every two weeks 
for multiple spins? You can't be serious.  This feels more like a 
punishment that I have to suffer because other spins broke.

> The bar has been raised, and this is not a bad thing.

Yes, as long as you dont arbitrarily the raise the amount of work 
someone has to do without any justification and not helping them in the 
process. I was once getting blamed for a Xfce spin compose that failed 
because Fedora infrastructure was running a updated (slightly broken) 
version of livecd-tools than the GA version. How about giving me access, 
so that I can do composes in the same environment that you do? Help me 
with this instead of just adding more overhead.

Rahul



From kanarip at kanarip.com  Thu Jan 15 14:56:28 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 15:56:28 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F479D.5030604@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>
	<496F479D.5030604@fedoraproject.org>
Message-ID: <496F4E9C.8090709@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
>> Rahul Sundaram wrote:
>>> Jeroen van Meeuwen wrote:
>>>> Rahul Sundaram wrote:
>>>> I'm done arguing with you. Either comment on the process before the vote 
>>>> on Monday or forever hold your peace.
>>> Which process are you referring to now?
>> I think this is a good time for you to start reading the agenda.
> 
> Please stop being dismissive and read the rest of mails where I gave you 
> more input.
> 

Reviewing what you've written so far;

- not at FUDCon

I've told you I'm sorry, give it a rest already.

- "It's general principle to be inclusive of everyone in the community 
as much as possible"

Wasting my time typing this email is a little more inclusive then I'd 
like to see.

- "I've commented on the spins process extensively"

And how do you think your comments are not in the new process we've come 
up with during FUDCon?

- "what should a report contain?"

I'm not sure yet, have any ideas? This has settled down just under 3 
days, and it hasn't even been voted upon yet. Do you want all the 
details now? You sure? Because that would make it more permanent and 
less flexible then the state it's in now (still open for suggestions).

- you're confused on what process it is we're talking about

Suggested solution: read the Spins_Process page on the Wiki

- you're looking for what the process was and how we streamlined it

Suggested solution: read the Spins_Process page on the Wiki

- you're eager to know what needs to be done for XFCE and other spins 
you submitted

Suggested solution: Await what the Spins SIG comes up with after the 
meeting, since this item is on the agenda

- you have an opinion about Spins being Spins vs. Features

Suggested solution: weight that argument in your vote for the new process

- """It would be still viable if the process is outlined. The process 
has to be in discussed and in place before FESCo delegates it to 
somebody else."""

1) The process is outlined
2) the process has been discussed, with representatives of Rel-eng, our 
dear Feature Wrangler, the Spins SIG leader, a few 
spin-submitting/maintaining users, a FESCo delegate, and reviewed 
afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the 
first place is the party to whom FESCo delegated responsibility.

I could continue but I don't feel like it. I sure hope this email sounds 
dismissive enough for you to finally stop arguing over nothing and 
continue the part of the thread where I think you may have actually said 
something useful.

Kind regards,

Jeroen van Meeuwen
-kanarip



From mcepl at redhat.com  Thu Jan 15 14:50:44 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 15 Jan 2009 15:50:44 +0100
Subject: Problems with X font handling
References: <200901122017.n0CKHkHf014866@laptop14.inf.utfsm.cl>
	<20090112143745.853acd38.zaitcev@redhat.com>
	<200901131320.n0DDKaBb005314@laptop14.inf.utfsm.cl>
	<20090113092954.04bfc620.zaitcev@redhat.com>
	<uar046x62l.ln2@ppp1053.in.ipex.cz>
	<20090114091916.795328bb.zaitcev@redhat.com>
Message-ID: <43v346xeca.ln2@ppp1053.in.ipex.cz>

On 2009-01-14, 16:19 GMT, Pete Zaitcev wrote:
> I'm sorry to repeat it for you, but X server is badly broken
> (or was broken, for the documented version).

Yes, it is -- we went over it yesterday with somebody here, and 
I will try to make the bug moving as fast as possible.

Mat?j



From jwboyer at gmail.com  Thu Jan 15 15:05:38 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Jan 2009 10:05:38 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F482B.8090802@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
Message-ID: <20090115150538.GD2582@yoda.jdub.homelinux.org>

On Thu, Jan 15, 2009 at 07:58:59PM +0530, Rahul Sundaram wrote:
>> That one came from me.  Having spins fail to compose during the week
>> that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the
>> door is simply an easy way to drop the Spin entirely.
>>
>> It's not more cumbersome.  It's putting the responsibility for the spin
>> into the hands of the person that cares about it the most, which is the
>> spin owner.  So the week before a milestone release is going to be busy
>> for the SIG and the owners, but that is part of being a Spin owner.
>
> I don't know what you want from a report and full fledged testing and  
> reporting every two weeks is just not feasible for multiple spins for me  
> as a spin owner.  If you want just to know if it composes or not or if  
> it is the right size and things like that, automated composes already  
> give that information. Don't ask me to vote on this incomplete proposal.  
> Please hash out the details in this list first and then get to the  
> voting part. Premature voting would leave us with just as much confusion  
> as before.
>
>> Look, creating an official Spin is not as simple as "here is my kickstart
>> file, go build this please." 
>
> No, it is not. I have to spend a lot of time, getting that kickstart  
> file in place first. It isn't a simple matter of running some composes  
> and calling it a day. There is a heck lot of finicky details to take  
> care of. Rawhide breaks my compose in subtle ways. You are in rel-eng.  
> You know the amount of work it takes to get alpha,beta and general  
> releases out. Are you really asking me to do that work every two weeks  
> for multiple spins? You can't be serious.  This feels more like a  
> punishment that I have to suffer because other spins broke.

I'm asking that the spins owners don't show up on release day with broken
spins for rel-eng to compose.  I'm asking them to make sure their spin
boots and isn't DOA when users download it.  I'm asking them to make sure
the items (or *gasp* features) that make their spin unique actually work
when you boot the spin.

Rawhide is a moving target.  Everyone knows this.  Everyone also knows that
stuff gets shoved into it at the last minute before a freeze date (which is
a separate problem that needs solving, but is the truth).  So, if you can
accomplish the above requirements without doing composes and testing every
two weeks, then we can discuss that.  The track record thus far has not been
wonderful (and no, that is not a statement about your specific spins).

>> The bar has been raised, and this is not a bad thing.
>
> Yes, as long as you dont arbitrarily the raise the amount of work  
> someone has to do without any justification and not helping them in the  
> process. I was once getting blamed for a Xfce spin compose that failed  
> because Fedora infrastructure was running a updated (slightly broken)  
> version of livecd-tools than the GA version. How about giving me access,  
> so that I can do composes in the same environment that you do? Help me  
> with this instead of just adding more overhead.

We did talk about having compose boxes available for the Spins SIG to
use.  That really has nothing to do with the process itself though, and
is really not a requirement.

There are certainly things that could be done to make this at least more
efficient from a technical standpoint for the spins owners.  But those
things are going to have to show up over time.  And if it's too much
work in the meantime, do a Remix.

josh



From kanarip at kanarip.com  Thu Jan 15 15:08:39 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:08:39 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1232029094.14403.1598.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>	<20090115135208.GI19432@angus.ind.WPI.EDU>	<20090115140915.GJ19432@angus.ind.WPI.EDU>
	<1232029094.14403.1598.camel@rosebud>
Message-ID: <496F5177.6030103@kanarip.com>

seth vidal wrote:
> On Thu, 2009-01-15 at 09:09 -0500, Chuck Anderson wrote:
> 
>> Sorry, I missed the 2nd half of this thread where my question above is 
>> answered:
>>
>> yum remove @group won't remove any real packages or group members, 
>> just the metapackage.
> 
> This is true
> 
>>   You'll also lose the ability to track this 
>> @group when new group-members appear in the repo(s).
> 
> If you remove the metapackage then yes, you can't track what you don't
> have. If you have the metapackage installed then when new group members
> appear you'll get them added to your system.
> 

Just a thought: if we do not eliminate groupinstall/groupremove 
behaviour, then yum could potentially yum groupremove foo and remove all 
package foo "brought in", expect if they are a dependency for another 
@metapkg.

Removing the @metapkg will enable you to install @metapkg and all leafs 
once, yum remove @metapkg without removing the leafs would be possible, 
as well as including the leafs in the removal: yum groupremove @metapkg.

Does this make sense?

-Jeroen



From pertusus at free.fr  Thu Jan 15 15:10:13 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 15 Jan 2009 16:10:13 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F4E9C.8090709@kanarip.com>
References: <496E4B4C.6050103@redhat.com> <496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org> <496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org> <496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org> <496F45BD.2040803@kanarip.com>
	<496F479D.5030604@fedoraproject.org> <496F4E9C.8090709@kanarip.com>
Message-ID: <20090115151013.GF2841@free.fr>

On Thu, Jan 15, 2009 at 03:56:28PM +0100, Jeroen van Meeuwen wrote:
>
> Wasting my time typing this email is a little more inclusive then I'd  
> like to see.
>
> - you're confused on what process it is we're talking about
>
> Suggested solution: read the Spins_Process page on the Wiki
>
> - you're looking for what the process was and how we streamlined it
>
> Suggested solution: read the Spins_Process page on the Wiki

As an external, though contrariant (and out of fedora) reader of
that page, it seems to me that some details are lacking, especially in 
the part:

3. Spins SIG reviews the Spin

    * If the Spin is accepted by the Spins SIG, the page is added to category Spins_Ready_for_Board
    * If the Spin is not accepted by the Spins SIG, the page is removed from the Spins_Ready_for_SIG category, and goes back to category Incomplete_Spins

The process for 'Spins SIG reviews the Spin' is lacking.
Maybe it is just that I am missing some information known by
everybody involved, but it is not on this page. 

--
Pat



From notting at redhat.com  Thu Jan 15 15:12:57 2009
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 15 Jan 2009 10:12:57 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F482B.8090802@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
Message-ID: <20090115151257.GC24937@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
> No, it is not. I have to spend a lot of time, getting that kickstart  
> file in place first. It isn't a simple matter of running some composes  
> and calling it a day. There is a heck lot of finicky details to take  
> care of. Rawhide breaks my compose in subtle ways. You are in rel-eng.  
> You know the amount of work it takes to get alpha,beta and general  
> releases out. Are you really asking me to do that work every two weeks  
> for multiple spins?

In many respects, yes. Because otherwise it falls to the 'base' rel-eng
and QA to constantly do that work, and that doesn't scale. If people
want their own custom spins, they do have to put some skin in the game.

It's not really adding anything to the amount of work that needs to be
done, in total. It's just shifting around who it gets done by and when.

Bill



From sundaram at fedoraproject.org  Thu Jan 15 15:18:56 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 20:48:56 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F4E9C.8090709@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com>
Message-ID: <496F53E0.5070205@fedoraproject.org>

Jeroen van Meeuwen wrote:

> - not at FUDCon
> 
> I've told you I'm sorry, give it a rest already.

The problem is not me or others being in FUDCon or not but decisions 
being made there which will always exclude people. Ours a global 
community and the ability to attend conferences in a particular place 
anywhere in the world is limited. You said you will do it again which 
seemed to be that you didn't understand the issue. It is nothing personal.

> And how do you think your comments are not in the new process we've come 
> up with during FUDCon?

It is not since I wasn't in FUDCon.

> - "what should a report contain?"
> 
> I'm not sure yet, have any ideas? This has settled down just under 3 
> days, and it hasn't even been voted upon yet. Do you want all the 
> details now? You sure? Because that would make it more permanent and 
> less flexible then the state it's in now (still open for suggestions).

Here is what I suggest:

* Postpone the IRC meeting and voting now. It is too early and there has 
not been enough details to warrant a vote yet.

* Post a summary of what was discussed in FUDCon and the new proposal 
discussed in the FUDCon. Communicate as much details as possible so that 
spin owners can understand why the changes were made and ask for input 
in this list and not on a IRC meeting. Wait for a week or two so that we 
can discuss it further and then maybe arrange a IRC meeting.

> - you're confused on what process it is we're talking about
> 
> Suggested solution: read the Spins_Process page on the Wiki
> 
> - you're looking for what the process was and how we streamlined it
> 
> Suggested solution: read the Spins_Process page on the Wiki

I already did. You would know that if you had read my mails since I was 
specific and pointed out a few examples where there aren't enough details.

> - you're eager to know what needs to be done for XFCE and other spins 
> you submitted
> 
> Suggested solution: Await what the Spins SIG comes up with after the 
> meeting, since this item is on the agenda

Since I am part of Spin SIG, I am giving my feedback to try and steer 
the decision in the right direction.

> - you have an opinion about Spins being Spins vs. Features
> 
> Suggested solution: weight that argument in your vote for the new process

I can't be in the IRC meeting and I don't think voting without details 
in the right way to do it. I am explaining it in the list so you can 
consider it while making the decision.

> - """It would be still viable if the process is outlined. The process 
> has to be in discussed and in place before FESCo delegates it to 
> somebody else."""
> 
> 1) The process is outlined
> 2) the process has been discussed, with representatives of Rel-eng, our 
> dear Feature Wrangler, the Spins SIG leader, a few 
> spin-submitting/maintaining users, a FESCo delegate, and reviewed 
> afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the 
> first place is the party to whom FESCo delegated responsibility.

I don't know what was discussed since a summary wasn't posted in this 
list. Filling in the details would be helpful.

> I could continue but I don't feel like it. I sure hope this email sounds 
> dismissive enough for you to finally stop arguing over nothing and 
> continue the part of the thread where I think you may have actually said 
> something useful.

If you don't feel I have said anything useful so far, I am sorry to hear 
that but then, we have nothing more to discuss. Carry on with your 
meeting and I will deal with the result when it comes to that point. 
Thanks.

Rahul



From kanarip at kanarip.com  Thu Jan 15 15:20:43 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:20:43 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115151013.GF2841@free.fr>
References: <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>
	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com> <20090115151013.GF2841@free.fr>
Message-ID: <496F544B.6070206@kanarip.com>

Patrice Dumas wrote:
> On Thu, Jan 15, 2009 at 03:56:28PM +0100, Jeroen van Meeuwen wrote:
>> Wasting my time typing this email is a little more inclusive then I'd  
>> like to see.
>>
>> - you're confused on what process it is we're talking about
>>
>> Suggested solution: read the Spins_Process page on the Wiki
>>
>> - you're looking for what the process was and how we streamlined it
>>
>> Suggested solution: read the Spins_Process page on the Wiki
> 
> As an external, though contrariant (and out of fedora) reader of
> that page, it seems to me that some details are lacking, especially in 
> the part:
> 
> 3. Spins SIG reviews the Spin
> 
>     * If the Spin is accepted by the Spins SIG, the page is added to category Spins_Ready_for_Board
>     * If the Spin is not accepted by the Spins SIG, the page is removed from the Spins_Ready_for_SIG category, and goes back to category Incomplete_Spins
> 
> The process for 'Spins SIG reviews the Spin' is lacking.
> Maybe it is just that I am missing some information known by
> everybody involved, but it is not on this page. 
> 

There's an email in my drafts, that describes how I planned to build our 
Spins_SIG_Review_Checklist. In fact, I saved that draft to the Wiki just 
because I was creating it there and didn't have a local copy. It isn't 
finished though, as obviously all this has to have some time to settle 
in writing, somewhere for others to review and edit.

As you *may* have noticed, that Spins_SIG_Review_Checklist is also on 
the Agenda.

Thank you,

Kind regards,

Jeroen van Meeuwen
-kanarip



From stickster at gmail.com  Thu Jan 15 15:21:05 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 15 Jan 2009 10:21:05 -0500
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
Message-ID: <20090115152044.GC5966@localhost.localdomain>

On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:
> I would like to suggest Enano CMS, which fulfills most of the requirements
> without plugins. It would take some work to get FAS2 integration and stuff
> though. It uses MediaWiki syntax, so it is portable among other CMSes that
> support importing MediaWiki data.

As I understand the post Karsten made earlier, suggestions will be
given credence if they are accompanied by people willing to deploy and
maintain the suggested system.  I couldn't tell from your post if
you're saying you're willing to do that, but you may in fact be saying
just that.  Could you clarify so the Docs team can understand where to
fit this suggestion into the lineup?

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/83e83e7a/attachment.sig>

From bruno at wolff.to  Thu Jan 15 15:24:16 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 15 Jan 2009 09:24:16 -0600
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115135658.GC2582@yoda.jdub.homelinux.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
Message-ID: <20090115152416.GA7579@wolff.to>

On Thu, Jan 15, 2009 at 08:56:58 -0500,
  Josh Boyer <jwboyer at gmail.com> wrote:
> 
> That one came from me.  Having spins fail to compose during the week
> that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the
> door is simply an easy way to drop the Spin entirely.

Note that the spin maintainer can't directly fix this in some cases.
I still have open bugzillas and several packages that don't install
cleanly because of missing requires. I can't fix them myself. I can't prevent
someone from introducing dependency issues (as happened briefly for the
poker2d update) at the wrong time. All I can do is file bugs and in extreme
cases as for help on the devel list for another maintainer to help out.



From bruno at wolff.to  Thu Jan 15 15:27:12 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 15 Jan 2009 09:27:12 -0600
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F482B.8090802@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
Message-ID: <20090115152712.GB7579@wolff.to>

On Thu, Jan 15, 2009 at 19:58:59 +0530,
  Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>
> Yes, as long as you dont arbitrarily the raise the amount of work  
> someone has to do without any justification and not helping them in the  
> process. I was once getting blamed for a Xfce spin compose that failed  
> because Fedora infrastructure was running a updated (slightly broken)  
> version of livecd-tools than the GA version. How about giving me access,  
> so that I can do composes in the same environment that you do? Help me  
> with this instead of just adding more overhead.

The code for the git archive of livecd-tools is public. I have already been
testing the git version of livecd-tools without special access.



From skvidal at fedoraproject.org  Thu Jan 15 15:26:45 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 10:26:45 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5177.6030103@kanarip.com>
References: <1231962712.14403.1559.camel@rosebud>
	<20090115135208.GI19432@angus.ind.WPI.EDU>
	<20090115140915.GJ19432@angus.ind.WPI.EDU>
	<1232029094.14403.1598.camel@rosebud>  <496F5177.6030103@kanarip.com>
Message-ID: <1232033205.14403.1603.camel@rosebud>

On Thu, 2009-01-15 at 16:08 +0100, Jeroen van Meeuwen wrote:
> seth vidal wrote:
> > On Thu, 2009-01-15 at 09:09 -0500, Chuck Anderson wrote:
> > 
> >> Sorry, I missed the 2nd half of this thread where my question above is 
> >> answered:
> >>
> >> yum remove @group won't remove any real packages or group members, 
> >> just the metapackage.
> > 
> > This is true
> > 
> >>   You'll also lose the ability to track this 
> >> @group when new group-members appear in the repo(s).
> > 
> > If you remove the metapackage then yes, you can't track what you don't
> > have. If you have the metapackage installed then when new group members
> > appear you'll get them added to your system.
> > 
> 
> Just a thought: if we do not eliminate groupinstall/groupremove 
> behaviour, then yum could potentially yum groupremove foo and remove all 
> package foo "brought in", expect if they are a dependency for another 
> @metapkg.
> 
> Removing the @metapkg will enable you to install @metapkg and all leafs 
> once, yum remove @metapkg without removing the leafs would be possible, 
> as well as including the leafs in the removal: yum groupremove @metapkg.
> 
> Does this make sense?

It seems like it would make more sense to do:

yum remove @group with remove-with-leaves enabled.

then the group remove behavior is as it was before and maybe a little
better b/c you aren't removing members of other metapkg/groups.

-sv




From sundaram at fedoraproject.org  Thu Jan 15 15:27:18 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 20:57:18 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115150538.GD2582@yoda.jdub.homelinux.org>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>
	<20090115150538.GD2582@yoda.jdub.homelinux.org>
Message-ID: <496F55D6.2030207@fedoraproject.org>

Josh Boyer wrote:

> 
> I'm asking that the spins owners don't show up on release day with broken
> spins for rel-eng to compose.  I'm asking them to make sure their spin
> boots and isn't DOA when users download it.  I'm asking them to make sure
> the items (or *gasp* features) that make their spin unique actually work
> when you boot the spin.

I am already doing all this and I don't see the benefit in mandating 
biweekly composes and reporting when you don't even know what you want 
from the report.

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 15:30:51 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:00:51 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115152712.GB7579@wolff.to>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
	<20090115152712.GB7579@wolff.to>
Message-ID: <496F56AB.4060809@fedoraproject.org>

Bruno Wolff III wrote:
> On Thu, Jan 15, 2009 at 19:58:59 +0530,
>   Rahul Sundaram <sundaram at fedoraproject.org> wrote:
>> Yes, as long as you dont arbitrarily the raise the amount of work  
>> someone has to do without any justification and not helping them in the  
>> process. I was once getting blamed for a Xfce spin compose that failed  
>> because Fedora infrastructure was running a updated (slightly broken)  
>> version of livecd-tools than the GA version. How about giving me access,  
>> so that I can do composes in the same environment that you do? Help me  
>> with this instead of just adding more overhead.
> 
> The code for the git archive of livecd-tools is public. I have already been
> testing the git version of livecd-tools without special access.

Err, I do own livecd-tools in EPEL so I am fully aware of that.
That wasn't what I was talking about however. I think Josh Boyer 
understands the issue better. Essentially, the environment that spin 
maintainers do composes on should be exactly the same as the one the 
final composes are being made. Any minor change can cause issues which 
we cant easily reproduce.

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 15:35:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:05:26 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115151257.GC24937@nostromo.devel.redhat.com>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>
	<20090115151257.GC24937@nostromo.devel.redhat.com>
Message-ID: <496F57BE.3090908@fedoraproject.org>

Bill Nottingham wrote:
> Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> No, it is not. I have to spend a lot of time, getting that kickstart  
>> file in place first. It isn't a simple matter of running some composes  
>> and calling it a day. There is a heck lot of finicky details to take  
>> care of. Rawhide breaks my compose in subtle ways. You are in rel-eng.  
>> You know the amount of work it takes to get alpha,beta and general  
>> releases out. Are you really asking me to do that work every two weeks  
>> for multiple spins?
> 
> In many respects, yes. Because otherwise it falls to the 'base' rel-eng
> and QA to constantly do that work, and that doesn't scale. If people
> want their own custom spins, they do have to put some skin in the game.
> 
> It's not really adding anything to the amount of work that needs to be
> done, in total. It's just shifting around who it gets done by and when.

QA hasn't been involved in custom spins ever to my knowledge. I haven't 
received any input from them ever. So let's leave QA out. In rel-eng, 
the only person involved on a regular interval is Jesse Keating (and 
Josh Boyer has helped as well) has sometimes run into issues and there 
hasn't been any major problem that I haven't responded to on time but 
doing composes and full fledged testing and reports every two weeks for 
all the different spins throughout rawhide development just isn't 
feasible. Automate more of this process via daily composes and automated 
tests and I can fill in the gaps that require manual supervision. I am 
already doing composes on my own and testing to the extend I can. There 
really isn't any room for me to do more.

Rahul



From pertusus at free.fr  Thu Jan 15 15:35:48 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 15 Jan 2009 16:35:48 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F544B.6070206@kanarip.com>
References: <496F0A4B.5090504@fedoraproject.org> <496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org> <496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org> <496F45BD.2040803@kanarip.com>
	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com> <20090115151013.GF2841@free.fr>
	<496F544B.6070206@kanarip.com>
Message-ID: <20090115153548.GG2841@free.fr>

On Thu, Jan 15, 2009 at 04:20:43PM +0100, Jeroen van Meeuwen wrote:
>
> There's an email in my drafts, that describes how I planned to build our  
> Spins_SIG_Review_Checklist. In fact, I saved that draft to the Wiki just  
> because I was creating it there and didn't have a local copy. It isn't  
> finished though, as obviously all this has to have some time to settle  
> in writing, somewhere for others to review and edit.

I am a bit confused because this is more or less the same than
Spins_Guidelines

> As you *may* have noticed, that Spins_SIG_Review_Checklist is also on  
> the Agenda.

You mean
Spins_Guidelines

Anyway, this has no information related with the process itself of 
3. Spins SIG reviews the Spin 

--
Pat



From kanarip at kanarip.com  Thu Jan 15 15:35:31 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:35:31 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F482B.8090802@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
Message-ID: <496F57C3.3000705@kanarip.com>

Rahul Sundaram wrote:
> Josh Boyer wrote:
>> Look, creating an official Spin is not as simple as "here is my kickstart
>> file, go build this please." 
> 
> No, it is not. I have to spend a lot of time, getting that kickstart 
> file in place first. It isn't a simple matter of running some composes 
> and calling it a day. There is a heck lot of finicky details to take 
> care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. 
> You know the amount of work it takes to get alpha,beta and general 
> releases out. Are you really asking me to do that work every two weeks 
> for multiple spins? You can't be serious.  This feels more like a 
> punishment that I have to suffer because other spins broke.
> 

You can't be serious if you're expecting the limited number of Spins SIG 
members or Release Engineering members to do that work for you, and 
numerous other spins as well.

FWIW though, we have not defined what a spins report should look like 
yet. Maybe, just maybe, you have some vague idea of what should be in there?

Kind regards,

Jeroen van Meeuwen
-kanarip



From kanarip at kanarip.com  Thu Jan 15 15:43:14 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:43:14 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F53E0.5070205@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>
	<496F53E0.5070205@fedoraproject.org>
Message-ID: <496F5992.9040801@kanarip.com>

Rahul Sundaram wrote:
> Jeroen van Meeuwen wrote:
>> And how do you think your comments are not in the new process we've 
>> come up with during FUDCon?
> 
> It is not since I wasn't in FUDCon.
> 

You make it sound so logic, I can only agree with you. You're right. I 
hadn't read anything, I can't remember anything, let alone keep in mind 
what everyone's ideas, comments and recommendations were and shape them 
into the skeleton (read: *THE SKELETON*) of a new process. I'm 
definitely a fail.

>> - "what should a report contain?"
>>
>> I'm not sure yet, have any ideas? This has settled down just under 3 
>> days, and it hasn't even been voted upon yet. Do you want all the 
>> details now? You sure? Because that would make it more permanent and 
>> less flexible then the state it's in now (still open for suggestions).
> 
> Here is what I suggest:
> 
> * Postpone the IRC meeting and voting now. It is too early and there has 
> not been enough details to warrant a vote yet.
> 

NO! Period. Exclamation-mark. Fullstop. Why not? Because our next 
meeting would be only ~2 weeks prior to Beta freeze. Don't recall the 
timeline exactly, don't care enough to look it up for you.

> * Post a summary of what was discussed in FUDCon and the new proposal 
> discussed in the FUDCon. Communicate as much details as possible so that 
> spin owners can understand why the changes were made and ask for input 
> in this list and not on a IRC meeting. Wait for a week or two so that we 
> can discuss it further and then maybe arrange a IRC meeting.
> 

I did ask for feedback on the list, so that the IRC meeting would only 
have the vote. So, here's a couple of suggestions for you:

- stop
- step away from the keyboard
- think of a couple of questions to which the answers may be valuable in 
moving us forward.
- post those questions on the list

>> - you're confused on what process it is we're talking about
>>
>> Suggested solution: read the Spins_Process page on the Wiki
>>
>> - you're looking for what the process was and how we streamlined it
>>
>> Suggested solution: read the Spins_Process page on the Wiki
> 
> I already did. You would know that if you had read my mails since I was 
> specific and pointed out a few examples where there aren't enough details.
> 

Obviously, I haven't read the rest of your email, doh! I'm obviously 
responding to things I don't read?

>> - you're eager to know what needs to be done for XFCE and other spins 
>> you submitted
>>
>> Suggested solution: Await what the Spins SIG comes up with after the 
>> meeting, since this item is on the agenda
> 
> Since I am part of Spin SIG, I am giving my feedback to try and steer 
> the decision in the right direction.
> 

I think you're confusing blunt criticism with constructive commentary.

>> - you have an opinion about Spins being Spins vs. Features
>>
>> Suggested solution: weight that argument in your vote for the new process
> 
> I can't be in the IRC meeting and I don't think voting without details 
> in the right way to do it. I am explaining it in the list so you can 
> consider it while making the decision.
> 

You're not explaining anything, you're dismissing everything we did for 
reasons of your absence and <insert-the-other-favorite-here>, almost 
entirely similar to how I'm dismissive towards you.

>> - """It would be still viable if the process is outlined. The process 
>> has to be in discussed and in place before FESCo delegates it to 
>> somebody else."""
>>
>> 1) The process is outlined
>> 2) the process has been discussed, with representatives of Rel-eng, 
>> our dear Feature Wrangler, the Spins SIG leader, a few 
>> spin-submitting/maintaining users, a FESCo delegate, and reviewed 
>> afterwards by QA and the Rel-Eng lead. Remember that Rel-Eng in the 
>> first place is the party to whom FESCo delegated responsibility.
> 
> I don't know what was discussed since a summary wasn't posted in this 
> list. Filling in the details would be helpful.
> 

There were no meeting minutes being kept track of during the meeting, 
regrettably. But, in case you want my 5-minute after best-recollection 
of what happened, that has been on the Wiki:

http://fedoraproject.org/wiki/SIGs/Spins_NewProcess

Note that this is a very quick and dirty list of things as I recalled 
them happening in the meeting, not the meeting minutes.

Other pages needed to complete the details on these pages you have so 
far should be in the making but somehow the person tasked to create 
those pages does not seem to be able to find the time to actually do 
what he's intended to do.

>> I could continue but I don't feel like it. I sure hope this email 
>> sounds dismissive enough for you to finally stop arguing over nothing 
>> and continue the part of the thread where I think you may have 
>> actually said something useful.
> 
> If you don't feel I have said anything useful so far, I am sorry to hear 
> that but then, we have nothing more to discuss. Carry on with your 
> meeting and I will deal with the result when it comes to that point. 
> Thanks.
> 

No, thank you!

Kind regards,

Jeroen van Meeuwen
-kanarip



From jkeating at redhat.com  Thu Jan 15 15:42:16 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 07:42:16 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda! (Meeting
 Reschedule)
In-Reply-To: <496EE3E2.1030808@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>
	<20090114173635.GG19783@nostromo.devel.redhat.com>
	<496E674A.6030701@kanarip.com>
	<1231973306.5086.73.camel@localhost.localdomain>
	<496EE3E2.1030808@kanarip.com>
Message-ID: <1232034136.5086.84.camel@localhost.localdomain>

On Thu, 2009-01-15 at 08:21 +0100, Jeroen van Meeuwen wrote:
> Due to a conflict with the Release Engineering Meeting, we'll move the 
> meetings to 17:00 UTC, instead of 18:00 UTC.

Thanks for being flexible Jeroen.

> 
> Sorry for the inconvenience.

I'm sorry we forgot to edit the schedule page in the first place causing
this mess.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/f59b0f84/attachment.sig>

From sundaram at fedoraproject.org  Thu Jan 15 15:45:38 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:15:38 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F57C3.3000705@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>
	<496F57C3.3000705@kanarip.com>
Message-ID: <496F5A22.7020201@fedoraproject.org>

Jeroen van Meeuwen wrote:
> 
> You can't be serious if you're expecting the limited number of Spins SIG 
> members or Release Engineering members to do that work for you, and 
> numerous other spins as well.

Spin SIG members are already doing it since many of them are spin owners 
as well but leaving that side, to the extend, there is a need for a 
bi-weekly compose, the first thing to be considered, is what parts can 
be automated so that we can make more efficient use of our limited time, 
collectively.

> FWIW though, we have not defined what a spins report should look like 
> yet. Maybe, just maybe, you have some vague idea of what should be in 
> there?

I wasn't the one who came up with the report idea and I am still not 
clear, why one is needed in the first place. Tell me what was discussed 
in FUDCon by posting a meeting summary of who attended and what was 
discussed and I will tell you what the report can contain. Currently, I 
don't have enough information provided to give any further input.

Rahul



From ffesti at redhat.com  Thu Jan 15 15:47:01 2009
From: ffesti at redhat.com (Florian Festi)
Date: Thu, 15 Jan 2009 16:47:01 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <496F5A75.30007@redhat.com>

Hi!

I fully agree that this current package handling situation is less then
perfect. We have all been overrun by the amazing success and growth of
Fedora. A lot of mechanisms that have been put into place years ago do no
longer fit - the comps file being one.

seth vidal wrote:
> Problems we see:
> - browsing packages is a difficult problem when you have 10000+ pkgs.
> - comps has a lot of meanings and it is not obvious what they all are/do
> - conditional pkgs (which provide a way of saying "install pkgX only 
>   if pkgY is installed) are several colors of doom b/c they aren't a 
>   dependency relationship and creates clutter on systems.
> - users expect groups to be more persistent on their systems and to act
>   more like pkgs (ie: yum update should update groups, too)
> - optional/default/mandatory pkgs are confusing and not useful to most
>   people - the types are only useful when browsing, not when installing.

While I agree with the list above I believe it only is a small part of the
problem and the suggested solution does not even cover them completely.

But there are other problems, challenges and developments that came up
within the packaging domain:

Handling of language dependent content:
This is related to the "conditionals" mentioned above. With the increasing
number of languages supported and packages being properly translated we ship
more and more language dependent content the users are not interested in. We
are currently missing both a way to package these contents properly and a
mechanism the control which should be actually installed.

Multilib:
The situation has changed a lot since we introduced multilib. The challenge
who is going to support 64bit processors first has been decided long ago and
the age of 32bit processors is ending. There are several annoying features
of the solution that was chosen at the time (overwriting 32 bit binaries,
install lots of files twice) and we should get rid of them at some point in
the (not too near) future. But this may require some other changes first...

Packaging noarch content:
We have just started
http://fedoraproject.org/wiki/Features/NoarchSubpackages and hope it will
make its way into F11. A long with all it's benefits I also expect it to
increase the number of packages and to change the ration of arch dependent
and noarch packages a lot.

Doing things per packages gets too expensive:
Even a small amount of work or possibility of error gets expensive and
annoying if it has to be done in a lot of packages. The example we are
looking at right now are scripts that are handling special types of files
like: ldconfig, install-info, gtk-update-icon-cache, ... We hope to come up
with a solution soon.
Another idea under that topic is the (semi) automatic creation of sub
packages. This could be used to address several other problems like multilib
or language files. But right now it is only a vague idea...

Poor implementations:
Several part of our tool chain are poorly implemented and though do not
scale linearly. Some parts of RPM already got fixed (I hope the code can hit
rawhide soon) but I am quite sure there are enough places left to keep us
busy (e.g. transferring the repo data of a updates repo takes quadratic
(O(#packages*#repodate_updated) bandwidth over its life time). The larger
the number will get the smaller the visible sins will get.

Ratio between installed and available packages:
We are dealing with an increasing size of meta data that is not actually
used (by the system dealing with them). This is not yet a problem but will
require deep architectural changes if it gets one.


I believe this list (including the issues brought up in the original post)
will require deep changes to the way we package Fedora during the next few
releases. Changes to the comps file should better fit into our overall plan.



Nevertheless I'd like to comment the suggested solution:

Some kind of conditionals will need to stay. As soon as we have a better
solution we can easily drop them but I cannot see yet when this is going to
happen. The solution will surely be part of yum and might even require
changes to rpm (No soft requires discussion now and here!).

The details of the implementation feel very fishy. I am not sure if this
change is really going to ease the pain or make it harder.

I think the discussion of the implementation details misses the point: Who
is going to define and apply the keywords for the packages and who is going
to define the groups in the new comps file. Comps was introduced to take
control, responsibility and burden of the decision what should be installed
and offered to the user by default away from the single packagers (with the
additional benefit of being able to make changes without rebuilding the
packages). And this was a "good idea"(tm). I now have doubt that a central
instance will be capable to keep track of the 15000 or soon may be even
50000 packages. Comming up with a set of keywords and applying them to all
packages will be even much more work and source of much more trouble that
the current comps file. Especially as (more) domain specific knowledge will 
be needed.
So IMHO we need a mechanism that still keeps the single packager out of the
process but allow much more people and groups to participate in it. I could
image that SIGs or may be even Spins get their own comps/groups/keyword
files to deal with a given application domain. May be users could even
decide what comps file to install on their system. So everybody could
package their view of the Fedora world. I am still very undecided how this 
should look like but I don't think we are ready to discuss the 
implementation details yet.

Florian




From kanarip at kanarip.com  Thu Jan 15 15:46:07 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:46:07 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115152416.GA7579@wolff.to>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<20090115152416.GA7579@wolff.to>
Message-ID: <496F5A3F.2070800@kanarip.com>

Bruno Wolff III wrote:
> On Thu, Jan 15, 2009 at 08:56:58 -0500,
>   Josh Boyer <jwboyer at gmail.com> wrote:
>> That one came from me.  Having spins fail to compose during the week
>> that rel-eng is trying to get a milestone (Alpha, Beta, Preview) out the
>> door is simply an easy way to drop the Spin entirely.
> 
> Note that the spin maintainer can't directly fix this in some cases.
> I still have open bugzillas and several packages that don't install
> cleanly because of missing requires. I can't fix them myself. I can't prevent
> someone from introducing dependency issues (as happened briefly for the
> poker2d update) at the wrong time. All I can do is file bugs and in extreme
> cases as for help on the devel list for another maintainer to help out.
> 

In the new spins process, we take those "dependencies" as we call them 
into account -somewhat;

you can list whatever dependencies you have in a separate sort-of topic 
on a Spins page similar to a Feature page, which is then used similar to 
how a Feature page is then used;

whether it be packages that still need to be reviewed, general bugs, 
features that need to be completed, you name it. Anything that stops the 
spin from being all fine can go there so that everyone knows.

Kind regards,

Jeroen van Meeuwen
-kanarip



From dominik at greysector.net  Thu Jan 15 15:57:01 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 15 Jan 2009 16:57:01 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5A75.30007@redhat.com>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
Message-ID: <20090115155700.GF15589@mokona.greysector.net>

On Thursday, 15 January 2009 at 16:47, Florian Festi wrote:
> Hi!
> 
> I fully agree that this current package handling situation is less then
> perfect. We have all been overrun by the amazing success and growth of
> Fedora. A lot of mechanisms that have been put into place years ago do no
> longer fit - the comps file being one.
[...]
> Handling of language dependent content:
> This is related to the "conditionals" mentioned above. With the increasing
> number of languages supported and packages being properly translated we ship
> more and more language dependent content the users are not interested in. We
> are currently missing both a way to package these contents properly and a
> mechanism the control which should be actually installed.

And the ability to add the previously uninstalled language-dependent files
to already installed packages.

> Multilib:
> The situation has changed a lot since we introduced multilib. The challenge
> who is going to support 64bit processors first has been decided long ago and
> the age of 32bit processors is ending. There are several annoying features
> of the solution that was chosen at the time (overwriting 32 bit binaries,
> install lots of files twice) and we should get rid of them at some point in
> the (not too near) future. But this may require some other changes first...

Or we could just drop multilib. ;)

[...]
> Doing things per packages gets too expensive:
> Even a small amount of work or possibility of error gets expensive and
> annoying if it has to be done in a lot of packages. The example we are
> looking at right now are scripts that are handling special types of files
> like: ldconfig, install-info, gtk-update-icon-cache, ... We hope to come up
> with a solution soon.

Just don't break plain rpm -i installs and rpm -e removals while you're at it.
I.e. don't go the SUSE way and require some frontend for pre/post-transaction
actions.

[...]
> I believe this list (including the issues brought up in the original post)
> will require deep changes to the way we package Fedora during the next few
> releases. Changes to the comps file should better fit into our overall plan.
> 
> 
> 
> Nevertheless I'd like to comment the suggested solution:
> 
> Some kind of conditionals will need to stay. As soon as we have a better
> solution we can easily drop them but I cannot see yet when this is going to
> happen. The solution will surely be part of yum and might even require
> changes to rpm (No soft requires discussion now and here!).

+1.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jwboyer at gmail.com  Thu Jan 15 16:01:07 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 15 Jan 2009 11:01:07 -0500
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F55D6.2030207@fedoraproject.org>
References: <496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
	<20090115150538.GD2582@yoda.jdub.homelinux.org>
	<496F55D6.2030207@fedoraproject.org>
Message-ID: <20090115160107.GA7508@yoda.jdub.homelinux.org>

On Thu, Jan 15, 2009 at 08:57:18PM +0530, Rahul Sundaram wrote:
> Josh Boyer wrote:
>
>>
>> I'm asking that the spins owners don't show up on release day with broken
>> spins for rel-eng to compose.  I'm asking them to make sure their spin
>> boots and isn't DOA when users download it.  I'm asking them to make sure
>> the items (or *gasp* features) that make their spin unique actually work
>> when you boot the spin.
>
> I am already doing all this and I don't see the benefit in mandating  
> biweekly composes and reporting when you don't even know what you want  
> from the report.

Hey, here's a hint.  The Spins SIG, Spins process, and the world in
general is not about you.

Glad you're doing it already.  Once we figure out what to report, it
should be easy for you to fill in the template.

I'm pretty much done with this conversation now.

josh



From Arnaud.Gomes at ircam.fr  Thu Jan 15 16:05:52 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Thu, 15 Jan 2009 17:05:52 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud> (seth vidal's message of
	"Wed\, 14 Jan 2009 14\:51\:52 -0500")
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <y9hvdsgv9jz.fsf@libation.ircam.fr>

seth vidal <skvidal at fedoraproject.org> writes:

> When someone goes to install the group: 'yum groupinstall
> mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> comps/groups file from each repo, look if the group you're requesting is
> there. If so it will create a metapkg rpm (a package containing only
> requirements) on the packages that exist in the repositories that are
> listed in that group. Then it will depsolve and install that pkg.

Another issue, from the point of view of a systems administrator this
time: what about anaconda? What if I have the following in my
kickstart packages list:

@mygroup
-mypackage

with mypackage a member of mygroup?

-- 
Arnaud



From sundaram at fedoraproject.org  Thu Jan 15 16:05:56 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:35:56 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F5992.9040801@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>	<496F53E0.5070205@fedoraproject.org>
	<496F5992.9040801@kanarip.com>
Message-ID: <496F5EE4.8020706@fedoraproject.org>

Jeroen van Meeuwen wrote:
> 
> You make it sound so logic, I can only agree with you. You're right. I 
> hadn't read anything, I can't remember anything, let alone keep in mind 
> what everyone's ideas, comments and recommendations were and shape them 
> into the skeleton (read: *THE SKELETON*) of a new process. I'm 
> definitely a fail.

The process is defined and decisions being made where majority of the 
people affected by the process cannot participate. Nobody posts a 
meeting summary.

The spin process wiki page doesn't say draft or skeleton or anything 
like that. It appears on it's own and a vote is being rushed based on 
that in a IRC meeting (which I cannot attend) where a lot of details 
haven't been discussed yet.

A new procedure for reports every week has been added to the process 
where nobody has even a vague idea (according to you) on what it should 
contain.  This all doesn't look like the right thing to do.

>> * Postpone the IRC meeting and voting now. It is too early and there has 
>> not been enough details to warrant a vote yet.
>>
> 
> NO! Period. Exclamation-mark. Fullstop. Why not? Because our next 
> meeting would be only ~2 weeks prior to Beta freeze. Don't recall the 
> timeline exactly, don't care enough to look it up for you.

Regardless of the time period, rushing through a vote with a skeleton 
proposal isn't going to benefit anybody. It would just lead to more 
confusion as has been evident over 3 releases in the past. So give it 
time and work through the details carefully.

> Obviously, I haven't read the rest of your email, doh! I'm obviously 
> responding to things I don't read?

Then I don't see the point of asking me to read a process wiki which has 
very few details. I have already read and commented on it.

> I think you're confusing blunt criticism with constructive commentary.

Perhaps but I am tired of running around and want it to stop. I have 
wasted enough time unnecessarily. I am very frustrated with this 
repeatedly. Let's get it right, this time.

> You're not explaining anything, you're dismissing everything we did for 
> reasons of your absence and <insert-the-other-favorite-here>, almost 
> entirely similar to how I'm dismissive towards you

Since I am not present, I can't know why without you and others who did 
attend post some details. Any of those attended post a summary please?

> Other pages needed to complete the details on these pages you have so 
> far should be in the making but somehow the person tasked to create 
> those pages does not seem to be able to find the time to actually do 
> what he's intended to do.

Who is that? Can he do it before the voting?

Rahul



From sundaram at fedoraproject.org  Thu Jan 15 16:11:10 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:41:10 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <20090115160107.GA7508@yoda.jdub.homelinux.org>
References: <496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>	<20090115150538.GD2582@yoda.jdub.homelinux.org>	<496F55D6.2030207@fedoraproject.org>
	<20090115160107.GA7508@yoda.jdub.homelinux.org>
Message-ID: <496F601E.5030901@fedoraproject.org>

Josh Boyer wrote:

> Hey, here's a hint.  The Spins SIG, Spins process, and the world in
> general is not about you.

No but I am involved and present in all of it. So please consider my 
input instead of side stepping my concerns.

> Glad you're doing it already.  Once we figure out what to report, it
> should be easy for you to fill in the template.

I will wait for that. Please discuss that in this list instead of on IRC.

Rahul



From kanarip at kanarip.com  Thu Jan 15 15:38:20 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 15 Jan 2009 16:38:20 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F482B.8090802@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
Message-ID: <496F586C.6090403@kanarip.com>

Rahul Sundaram wrote:
> Josh Boyer wrote:
>> Look, creating an official Spin is not as simple as "here is my kickstart
>> file, go build this please." 
> 
> No, it is not. I have to spend a lot of time, getting that kickstart 
> file in place first. It isn't a simple matter of running some composes 
> and calling it a day. There is a heck lot of finicky details to take 
> care of. Rawhide breaks my compose in subtle ways. You are in rel-eng. 
> You know the amount of work it takes to get alpha,beta and general 
> releases out. Are you really asking me to do that work every two weeks 
> for multiple spins? You can't be serious.  This feels more like a 
> punishment that I have to suffer because other spins broke.
> 

You can't be serious if you're expecting the limited number of Spins SIG 
members or Release Engineering members to do that work for you, and 
numerous other spins as well.

FWIW though, we have not defined what a spins report should look like 
yet. Maybe, just maybe, you have some vague idea of what should be in there?

Kind regards,

Jeroen van Meeuwen
-kanarip



From sundaram at fedoraproject.org  Thu Jan 15 16:20:47 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 21:50:47 +0530
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5A75.30007@redhat.com>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
Message-ID: <496F625F.7080503@fedoraproject.org>

Florian Festi wrote:
> 
> Doing things per packages gets too expensive:
> Even a small amount of work or possibility of error gets expensive and
> annoying if it has to be done in a lot of packages. The example we are
> looking at right now are scripts that are handling special types of files
> like: ldconfig, install-info, gtk-update-icon-cache, ... We hope to come up
> with a solution soon.
> Another idea under that topic is the (semi) automatic creation of sub
> packages. This could be used to address several other problems like 
> multilib
> or language files. But right now it is only a vague idea...

Have you looked at what Conary does in this space to solve these issues 
in particular? It seems worth looking into.

Rahul



From notting at redhat.com  Thu Jan 15 16:26:25 2009
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 15 Jan 2009 11:26:25 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F625F.7080503@fedoraproject.org>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
	<496F625F.7080503@fedoraproject.org>
Message-ID: <20090115162625.GA26565@nostromo.devel.redhat.com>

Rahul Sundaram (sundaram at fedoraproject.org) said: 
>> Doing things per packages gets too expensive:
>> Even a small amount of work or possibility of error gets expensive and
>> annoying if it has to be done in a lot of packages. The example we are
>> looking at right now are scripts that are handling special types of files
>> like: ldconfig, install-info, gtk-update-icon-cache, ... We hope to come up
>> with a solution soon.
>> Another idea under that topic is the (semi) automatic creation of sub
>> packages. This could be used to address several other problems like  
>> multilib
>> or language files. But right now it is only a vague idea...
>
> Have you looked at what Conary does in this space to solve these issues  
> in particular? It seems worth looking into.

This is all pretty easy to do.... as long as you don't mind downloading
the filelists constantly, and the fact that it won't work when using
'just' RPM.

Moving it to RPM at the lowest level adds a huge level of complication.

Bill



From bruno at wolff.to  Thu Jan 15 16:42:31 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 15 Jan 2009 10:42:31 -0600
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F5A3F.2070800@kanarip.com>
References: <496E4B4C.6050103@redhat.com> <496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org> <496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org> <496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<20090115152416.GA7579@wolff.to> <496F5A3F.2070800@kanarip.com>
Message-ID: <20090115164231.GA17884@wolff.to>

On Thu, Jan 15, 2009 at 16:46:07 +0100,
  Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> 
> you can list whatever dependencies you have in a separate sort-of topic 
> on a Spins page similar to a Feature page, which is then used similar to 
> how a Feature page is then used;

I have been linking to bugs on my revamped games spin feature page. I don't
know that it helps get them taken care of though.



From vonbrand at inf.utfsm.cl  Thu Jan 15 16:43:25 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 15 Jan 2009 13:43:25 -0300
Subject: asciidoc abandoned?
Message-ID: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>

x86_64, rawhide up to date.

I've got an annoying bug in asciidoc (#283351; yes, it is quite old by
now), and I check regularly on that one, there being no movement there
except for automagic assignment to the stable releases. The current package
is still asciidoc-8.2.5-2.fc9.noarch in Fedora, while upstream it is now at
8.3.3. In any case, the homepage warns of possible compatibility issues WRT
8.2.7. They look relatively minor to me, but in any case I believe Fedora
11 should ship the new version.
-- 
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 nicolas.mailhot at laposte.net  Thu Jan 15 16:45:11 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Jan 2009 17:45:11 +0100 (CET)
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5A75.30007@redhat.com>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
Message-ID: <0db71c7e264783f9de59177f0d61bc14.squirrel@arekh.dyndns.org>



Le Jeu 15 janvier 2009 16:47, Florian Festi a ?crit :

> Doing things per packages gets too expensive:
> Even a small amount of work or possibility of error gets expensive and
> annoying if it has to be done in a lot of packages. The example we are
> looking at right now are scripts that are handling special types of
> files
> like: ldconfig, install-info, gtk-update-icon-cache, ... We hope to
> come up
> with a solution soon.
> Another idea under that topic is the (semi) automatic creation of sub
> packages. This could be used to address several other problems like
> multilib
> or language files. But right now it is only a vague idea...

BTW this is effectively what the new F11 fonts packaging guidelines
and framework do for fonts (in a crude way)

http://fedoraproject.org/wiki/Fontpackages
http://koji.fedoraproject.org/koji/buildinfo?buildID=78561

A review by people familiar with rpm internals would be much appreciated

-- 
Nicolas Mailhot



From skvidal at fedoraproject.org  Thu Jan 15 16:45:20 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 11:45:20 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklo5h$9gm$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud> <gklo5h$9gm$1@ger.gmane.org>
Message-ID: <1232037920.14403.1610.camel@rosebud>

On Wed, 2009-01-14 at 23:15 +0100, Kevin Kofler wrote:
> seth vidal wrote:
> > - conditional pkgs (which provide a way of saying "install pkgX only
> >   if pkgY is installed) are several colors of doom b/c they aren't a
> >   dependency relationship and creates clutter on systems.
> 
> But they're actually needed. We wouldn't have them if they weren't.

maybe so, maybe not.

> 
> > - users expect groups to be more persistent on their systems and to act
> >   more like pkgs (ie: yum update should update groups, too)
> 
> What users? Surely not me.

When did you become a yum user? :)


> I don't want packages to be magically added just because they're in some group.

That's the point of the groups - of them being transitioned to metapkgs
- so we no longer have the ambiguity. It's like watching a bad episode
of moonlighting "will they? Won't they?".


> What I do want is be told of any new packages showing up in the repository.
> All of them. No matter what groups, if any, they're in. Then I can decide
> if I want them (by default none should be selected, of course). And viewing
> that list is probably something which should have to be requested
> explicitly, as I think most users will want to only install additional
> stuff when they actually need it. (Installing a package to try it out
> because it's new is something I do, but not something I'd expect somebody
> who only uses the computer as a tool to do their job to do.)

New stuff showing up in the repo is completely unrelated to the groups.

> 
> I can't believe I'm alone with that expectation. I actually think there will
> be lots of complaints about unwanted packages getting automatically added
> (for a reason most users won't understand - metapackages are black magic as
> far as they're concerned).

and groups are worse black magic - if only b/c they have this way of
rebounding on the people who do understand them. :-/


> They're actually extremely useful when installing, as you can decide what to
> install. People may often want, say, KDE or GNOME, but not every single
> application (or application pack) which is part of KDE or GNOME. (That's
> why there's a distinction between "mandatory" (e.g. if you want KDE, you
> definitely want kdelibs) and "default" (i.e. you probably want this, but
> maybe not).) In addition, there are many KDE or GNOME applications which
> are not directly part of KDE or GNOME. "Optional" provides a nice place to
> list those.

Which is why we can do groups of groups and more precisely break them
down into smaller sections. so you install what you need, not the whole
world.

> While admittedly I haven't done any user research, I'd expect most users to
> go through the comps list at least once, either while installing from the
> DVD or after installing from a live CD (and noticing missing applications,
> which are unavoidable for CD-sized spins).
> 

I suspect most users never know what comps is and they do all their
discovery by doing:
yum search someword
or 
yum list somepkgnametheyknow

> In addition, there are plans to add soft dependencies even at package level,
> which shows there is a demand for them, so IMHO dropping them from comps is
> a step backwards.

Really? Who is making the plans for soft deps. Doesn't seem like it at
the rpm layer.

-sv




From skvidal at fedoraproject.org  Thu Jan 15 16:45:48 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 11:45:48 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklnan$5fb$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud>  <gklnan$5fb$1@ger.gmane.org>
Message-ID: <1232037948.14403.1611.camel@rosebud>

On Wed, 2009-01-14 at 23:00 +0100, Kevin Kofler wrote:
> seth vidal wrote:
> > Conditional packages were viewed, from the outset, as something that had
> > to go. One way or the other conditional pkgs were going to get beaten
> > up.
> 
> But it can't go because there's no working alternative.
> 

I'm sure we can sort one out.


-sv




From skvidal at fedoraproject.org  Thu Jan 15 16:46:45 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 11:46:45 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9hvdsgv9jz.fsf@libation.ircam.fr>
References: <1231962712.14403.1559.camel@rosebud>
	<y9hvdsgv9jz.fsf@libation.ircam.fr>
Message-ID: <1232038005.14403.1613.camel@rosebud>

On Thu, 2009-01-15 at 17:05 +0100, Arnaud Gomes-do-Vale wrote:
> seth vidal <skvidal at fedoraproject.org> writes:
> 
> > When someone goes to install the group: 'yum groupinstall
> > mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> > comps/groups file from each repo, look if the group you're requesting is
> > there. If so it will create a metapkg rpm (a package containing only
> > requirements) on the packages that exist in the repositories that are
> > listed in that group. Then it will depsolve and install that pkg.
> 
> Another issue, from the point of view of a systems administrator this
> time: what about anaconda? What if I have the following in my
> kickstart packages list:
> 
> @mygroup
> -mypackage
> 
> with mypackage a member of mygroup?
> 

Well, kickstart doesn't EXCLUDE pkgs when it does a -mypackage - it just
takes them out of the defaults. If they are pulled back in due to a
dependency, then they go in.

I don't see how this would be any different.

-sv




From bruno at wolff.to  Thu Jan 15 16:53:29 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Thu, 15 Jan 2009 10:53:29 -0600
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F586C.6090403@kanarip.com>
References: <496E4B4C.6050103@redhat.com> <496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org> <496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org> <496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org> <496F586C.6090403@kanarip.com>
Message-ID: <20090115165329.GB17884@wolff.to>

On Thu, Jan 15, 2009 at 16:38:20 +0100,
  Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
>
> FWIW though, we have not defined what a spins report should look like  
> yet. Maybe, just maybe, you have some vague idea of what should be in 
> there?

I have found that looking at the install (done as part of the spin build)
process shows up missing requires for pre and post (un)install scripts that
are easy to miss when testing on a system where the base stuff is already
installed. Some of these errors are really just noise, others cause breakage.
It would be nice if the installs were totally clean of error or warning
messages.

I have also found that it is possible for a dependency problem to block
the build entirely.



From limb at jcomserv.net  Thu Jan 15 16:57:47 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 15 Jan 2009 10:57:47 -0600 (CST)
Subject: asciidoc abandoned?
In-Reply-To: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
Message-ID: <4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>


> x86_64, rawhide up to date.
>
> I've got an annoying bug in asciidoc (#283351; yes, it is quite old by
> now), and I check regularly on that one, there being no movement there
> except for automagic assignment to the stable releases. The current
> package
> is still asciidoc-8.2.5-2.fc9.noarch in Fedora, while upstream it is now
> at
> 8.3.3. In any case, the homepage warns of possible compatibility issues
> WRT
> 8.2.7. They look relatively minor to me, but in any case I believe Fedora
> 11 should ship the new version.

Looks like Chris Wright owns it, and Florian La Roche did quite a bit with
it, but nothing since 2007.  Would either care to comment?

> --
> 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
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From skvidal at fedoraproject.org  Thu Jan 15 16:59:12 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 11:59:12 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5A75.30007@redhat.com>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
Message-ID: <1232038752.14403.1621.camel@rosebud>

On Thu, 2009-01-15 at 16:47 +0100, Florian Festi wrote:
> Hi!
> 
> I fully agree that this current package handling situation is less then
> perfect. We have all been overrun by the amazing success and growth of
> Fedora. A lot of mechanisms that have been put into place years ago do no
> longer fit - the comps file being one.
> 

<snip>
My takeaway from your comments is this bit:

"I am still very undecided how this should look like but I don't think
we are ready to discuss the implementation details yet."


I don't think we should stop until we've decided all the details.


Groups/comps will be dealt with as it is now - in cvs.
search/tags can start out in cvs and expand out to being in the pkgdb. I
talked to Toshio about this a bit - the only thing keeping that from
happening is free time.

We can suss out the other details as we go, I think.

-sv




From Arnaud.Gomes at ircam.fr  Thu Jan 15 17:14:17 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Thu, 15 Jan 2009 18:14:17 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <1232038005.14403.1613.camel@rosebud> (seth vidal's message of
	"Thu\, 15 Jan 2009 11\:46\:45 -0500")
References: <1231962712.14403.1559.camel@rosebud>
	<y9hvdsgv9jz.fsf@libation.ircam.fr>
	<1232038005.14403.1613.camel@rosebud>
Message-ID: <y9hr634v6dy.fsf@libation.ircam.fr>

seth vidal <skvidal at fedoraproject.org> writes:

>> Another issue, from the point of view of a systems administrator this
>> time: what about anaconda? What if I have the following in my
>> kickstart packages list:
>> 
>> @mygroup
>> -mypackage
>> 
>> with mypackage a member of mygroup?
>
> Well, kickstart doesn't EXCLUDE pkgs when it does a -mypackage - it just
> takes them out of the defaults. If they are pulled back in due to a
> dependency, then they go in.

Thank you for explaining this, but I'm still not sure I get it. How
would I say, for instance, "install the whole text-internet group
except fetchmail"? At the moment, this is a very useful feature and I
would not like to see it go away.

-- 
Arnaud



From a.badger at gmail.com  Thu Jan 15 17:27:48 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 15 Jan 2009 09:27:48 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9hr634v6dy.fsf@libation.ircam.fr>
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>
	<y9hr634v6dy.fsf@libation.ircam.fr>
Message-ID: <496F7214.7020109@gmail.com>

Arnaud Gomes-do-Vale wrote:
> seth vidal <skvidal at fedoraproject.org> writes:
> 
>>> Another issue, from the point of view of a systems administrator this
>>> time: what about anaconda? What if I have the following in my
>>> kickstart packages list:
>>>
>>> @mygroup
>>> -mypackage
>>>
>>> with mypackage a member of mygroup?
>> Well, kickstart doesn't EXCLUDE pkgs when it does a -mypackage - it just
>> takes them out of the defaults. If they are pulled back in due to a
>> dependency, then they go in.
> 
> Thank you for explaining this, but I'm still not sure I get it. How
> would I say, for instance, "install the whole text-internet group
> except fetchmail"? At the moment, this is a very useful feature and I
> would not like to see it go away.
> 
You'd need to do the removal (yum remove -y mypackage should work) in a
%post script.  This is something I've had to do before when making
minimal livemedia.  It's not too hard although it wasn't obvious to me
at first why -mypackage didn't work in the packages list :-)

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/7b141fa1/attachment.sig>

From fedora at leemhuis.info  Thu Jan 15 17:32:45 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 15 Jan 2009 18:32:45 +0100
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <62bc09df0901150238o55ed0bc1ybdbeb9596ea2fc20@mail.gmail.com>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>	<496F0C85.3000307@fedoraproject.org>
	<496F10A8.9040800@pingoured.fr>
	<62bc09df0901150238o55ed0bc1ybdbeb9596ea2fc20@mail.gmail.com>
Message-ID: <496F733D.7080000@leemhuis.info>



On 15.01.2009 11:38, Xavier Lamien wrote:
> On Thu, Jan 15, 2009 at 11:32 AM, Pierre-Yves <pingou at pingoured.fr> wrote:
>> Rahul Sundaram wrote:
>>> Jon Stanley wrote:
>>>
>>>> We'll work with each individual list owner in order to determine a
>>>> date for the migration.
>>> Can you also make sure that the list descriptions are updated, has valid
>>> links etc as part of the migration process? I was trying to do this already
>>> but if you are already working with owners, we can do this together.
>> I have probably missed something, but the Mailing Lists will be migrated to
>> what ?
> 
> The domain name will change.
> e.g you will have <fedora-development-list at lists.fedoraproject.org> instead

Was "fedora-development-list at lists.fedoraproject.org" a real world 
example? Fedora and list are redundant in it.

I'd prefer to get rid of at least the list *or* have fedora and list in 
all the new list names.

CU
knurd



From mike at cchtml.com  Thu Jan 15 17:45:33 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Thu, 15 Jan 2009 11:45:33 -0600
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <496F733D.7080000@leemhuis.info>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>	<496F0C85.3000307@fedoraproject.org>	<496F10A8.9040800@pingoured.fr>	<62bc09df0901150238o55ed0bc1ybdbeb9596ea2fc20@mail.gmail.com>
	<496F733D.7080000@leemhuis.info>
Message-ID: <496F763D.7050006@cchtml.com>

-------- Original Message --------
Subject: Re: Migration of the Fedora Mailing Lists
From: Thorsten Leemhuis <fedora at leemhuis.info>
To: Development discussions related to Fedora <fedora-devel-list at redhat.com>
Date: 01/15/2009 11:32 AM

> 
> Was "fedora-development-list at lists.fedoraproject.org" a real world 
> example? Fedora and list are redundant in it.
> 
> I'd prefer to get rid of at least the list *or* have fedora and list in 
> all the new list names.
> 
> CU
> knurd
> 

fedora-fonts -> fonts at lists.fedoraproject.org
fedora-kernel-list -> kernel at lists.fedoraproject.org
fedora-list -> support at lists.fedoraproject.org
fedora-devel-list -> development at lists.fedoraproject.org
fedora-virt -> virtualization at lists.fedoraproject.org

Etc., etc., etc.



From jkeating at redhat.com  Thu Jan 15 17:47:40 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 09:47:40 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F53E0.5070205@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>
	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com>  <496F53E0.5070205@fedoraproject.org>
Message-ID: <1232041660.5086.104.camel@localhost.localdomain>

On Thu, 2009-01-15 at 20:48 +0530, Rahul Sundaram wrote:
> The problem is not me or others being in FUDCon or not but decisions 
> being made there which will always exclude people. Ours a global 
> community and the ability to attend conferences in a particular place 
> anywhere in the world is limited. You said you will do it again which 
> seemed to be that you didn't understand the issue. It is nothing
> personal.

Sounds like you'd rather FUDCons never happened at all.  It also seems
you've confused "created a proposal" with "made a set in stone final
decision".  These are two different things.  The fact that many key
players in the game happened to be in the same place, at the same time,
and were able to dedicate some high bandwidth discussion to the matter
led to a pretty good proposal.  It's no different than somebody thinking
up a proposal by themselves, or while talking with somebody on the
phone, or IRC, or even email.  It's a proposal.  It can be modified, it
can be adjusted, it can be rejected, etc..  It's a proposal.

I get the fact that you resent being in a timezone and location that
makes it difficult for you to participate in higher bandwidth forms of
communication (irc, phone, face to face).  I can't help that.  However
I'm not about to force the entire Fedora project slow to a crawl just so
that every thought, comment, discussion, fart, whatever happens via a
public email.  That's just ridiculous.  People will continue to talk on
IRC, will continue to chat via IM, will continue to talk on phones, and
will even *shock* talk in person!  Ideas, proposals, and even a decision
or two, depending on the group, will be made in these ways.  Deal with
it.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/87dd96be/attachment.sig>

From sundaram at fedoraproject.org  Thu Jan 15 17:56:53 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 15 Jan 2009 23:26:53 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <1232041660.5086.104.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>
	<496F53E0.5070205@fedoraproject.org>
	<1232041660.5086.104.camel@localhost.localdomain>
Message-ID: <496F78E5.2080002@fedoraproject.org>

Jesse Keating wrote:
> On Thu, 2009-01-15 at 20:48 +0530, Rahul Sundaram wrote:
>> The problem is not me or others being in FUDCon or not but decisions 
>> being made there which will always exclude people. Ours a global 
>> community and the ability to attend conferences in a particular place 
>> anywhere in the world is limited. You said you will do it again which 
>> seemed to be that you didn't understand the issue. It is nothing
>> personal.
> 
> Sounds like you'd rather FUDCons never happened at all. 

No. I travelled over 20 hours of flight to attend it twice. So I 
certainly understand the value of it. You got to read what I said before 
assuming anything of that sort.

https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00789.html

"Such decisions shouldn't be taken at FUDCon because it automatically 
excludes people who cannot be present at the event. You should use the 
events only to discuss the issues and make the decisions over mailing 
lists or irc where others can participate as well. "

  However
> I'm not about to force the entire Fedora project slow to a crawl just so
> that every thought, comment, discussion, fart, whatever happens via a
> public email.  That's just ridiculous. 

Yes. it is but just made up a completely fictitious situation just to 
demolish it. I know that form of argument. It even has a catchy name but 
I forget it now.  Just read the mail I replied to and what I said was 
much more reasonable than what you are making it out to be.

Rahul



From joe at nall.com  Thu Jan 15 17:59:26 2009
From: joe at nall.com (Joe Nall)
Date: Thu, 15 Jan 2009 11:59:26 -0600
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F5992.9040801@kanarip.com>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>
	<496F53E0.5070205@fedoraproject.org> <496F5992.9040801@kanarip.com>
Message-ID: <50476478-1EE2-4863-9CD0-B0CDC8CCDC96@nall.com>


On Jan 15, 2009, at 9:43 AM, Jeroen van Meeuwen wrote:

> You make it sound so logic, I can only agree with you. You're right.  
> I hadn't read anything, I can't remember anything, let alone keep in  
> mind what everyone's ideas, comments and recommendations were and  
> shape them into the skeleton (read: *THE SKELETON*) of a new  
> process. I'm definitely a fail.

First thing you have said that I can agree with.

joe




From seg at haxxed.com  Thu Jan 15 17:59:37 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Thu, 15 Jan 2009 11:59:37 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>
References: <1231962712.14403.1559.camel@rosebud>
	<604aa7910901141218p5528a781q3a4f92338198b91a@mail.gmail.com>
Message-ID: <1232042377.12133.14.camel@localhost.localdomain>

On Wed, 2009-01-14 at 11:18 -0900, Jeff Spaleta wrote:
> I think a more heretical categorization and classification of the
> software package may have merit as a reference service for developers
> looking for the 'right' development library for their project. But I
> think that sort of thing would really requiring developing informed
> opinions about  mature library classification concepts as a guide.

Or just search the intersection of tags "library" + "python" +
"dowhatimean". Or "library" + "c" + "bubblesort".

> We
> could spend years debating traditional brick and mortar library
> cataloguing system and still not come to agreement over adapting Bliss
> or Library of Congress style classification.

Or just let the crowd have at it with tags.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/6d3acbeb/attachment.sig>

From hedayat at grad.com  Thu Jan 15 18:05:02 2009
From: hedayat at grad.com (Hedayat Vatankhah)
Date: Thu, 15 Jan 2009 21:35:02 +0330
Subject: Package doesn't build in Koji, but can be built locally using mock!
Message-ID: <496F7ACE.8040201@grad.com>

Hi all,
I'm the maintainer of rcssserver3d package. The package has been built 
in rawhide successfully, but recently I just removed a font file from 
the package and tried to build the package again in koji, but it failed. 
The build log says that it is unable to find /usr/lib64/libIL.so, but it 
should be able to find it. I didn't change anything related to it. Also, 
I tried to build the package using mock (make mockbuild) and the package 
was able to find the library! I wonder what's the problem?!

koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=1055760

Thanks,
Hedayat



From jkeating at redhat.com  Thu Jan 15 18:19:58 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 10:19:58 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F78E5.2080002@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>
	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com> <496F53E0.5070205@fedoraproject.org>
	<1232041660.5086.104.camel@localhost.localdomain>
	<496F78E5.2080002@fedoraproject.org>
Message-ID: <1232043598.5086.105.camel@localhost.localdomain>

On Thu, 2009-01-15 at 23:26 +0530, Rahul Sundaram wrote:
> "Such decisions shouldn't be taken at FUDCon because it automatically 
> excludes people who cannot be present at the event. You should use the 
> events only to discuss the issues and make the decisions over mailing 
> lists or irc where others can participate as well. "

I see you're still completely ignoring the fact that what came out of
FUDCon was a /proposal/, and not a decision.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/5e9b83bd/attachment.sig>

From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Jan 15 18:26:37 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 16 Jan 2009 03:26:37 +0900
Subject: Package doesn't build in Koji, but can be built locally using
 mock!
In-Reply-To: <496F7ACE.8040201@grad.com>
References: <496F7ACE.8040201@grad.com>
Message-ID: <496F7FDD.7020304@ioa.s.u-tokyo.ac.jp>

Hedayat Vatankhah wrote, at 01/16/2009 03:05 AM +9:00:
> Hi all,
> I'm the maintainer of rcssserver3d package. The package has been built 
> in rawhide successfully, but recently I just removed a font file from 
> the package and tried to build the package again in koji, but it failed. 
> The build log says that it is unable to find /usr/lib64/libIL.so, but it 
> should be able to find it. I didn't change anything related to it. Also, 
> I tried to build the package using mock (make mockbuild) and the package 
> was able to find the library! I wonder what's the problem?!
> 
> koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=1055760
> 
> Thanks,
> Hedayat

At least DevIL-1.7.5-1.fc11 seems broken as now ldd reports that libIL.so.1 
contains undefined non-weak symbols. config.log shows:

-------------------------------------------------------------------
configure:22286: g++ -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic    -lIL conftest.cpp  >&5
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: undefined reference to `ilLoadVtf'
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: undefined reference to `ilLoadVtfF'
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: undefined reference to `ilLoadVtfL'
collect2: ld returned 1 exit status
configure:22293: $? = 1
configure: failed program was:
| #include <IL/il.h>
| #include <stdarg.h> /* _vsnprintf may be undefined (and it is needed by libIL) */
| extern "C" int _vsnprintf(char *str, size_t size, const char *format, va_list ap) { return 0;}
| int main(int argc, char **argv) { ilInit(); return 0; }
configure:22360: WARNING: The DevIL library (libIL.a or libIL.so) cannot be found.
-------------------------------------------------------------------

I guess this needs bug report against DevIL.

Mamoru



From maillist at diffingo.com  Thu Jan 15 18:52:23 2009
From: maillist at diffingo.com (Stewart Adam)
Date: Thu, 15 Jan 2009 13:52:23 -0500
Subject: Retiring package: wxsvg
Message-ID: <496F85E7.6080004@diffingo.com>

Hi,

I'd like to retire wxsvg from Fedora, as no software uses it without the 
ffmpeg extensions [1] and it's been causing a lot of trouble for 
DVDStyler [2]. I've done a repoquery and no packages require wxsvg, but 
before I started going through the package EOL process I wanted to make 
sure that it was really unused.

btw - I'm not the owner of wxsvg in PackageDB, but I've contacted 
Matthias and he's accepted to remove it so long as there's nothing which 
requires it in Fedora.

Thanks,
Stewart

[1] 
https://sourceforge.net/forum/forum.php?thread_id=2850496&forum_id=424987
[2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=49



From sundaram at fedoraproject.org  Thu Jan 15 18:57:53 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Jan 2009 00:27:53 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <1232043598.5086.105.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>
	<496F53E0.5070205@fedoraproject.org>	<1232041660.5086.104.camel@localhost.localdomain>	<496F78E5.2080002@fedoraproject.org>
	<1232043598.5086.105.camel@localhost.localdomain>
Message-ID: <496F8731.2010003@fedoraproject.org>

Jesse Keating wrote:
> On Thu, 2009-01-15 at 23:26 +0530, Rahul Sundaram wrote:
>> "Such decisions shouldn't be taken at FUDCon because it automatically 
>> excludes people who cannot be present at the event. You should use the 
>> events only to discuss the issues and make the decisions over mailing 
>> lists or irc where others can participate as well. "
> 
> I see you're still completely ignoring the fact that what came out of
> FUDCon was a /proposal/, and not a decision.

There is nothing in the original mail that calls for a meeting indicate 
anything about a proposal. It just declares that the spin sig is going 
have to bi weekly meetings (where was that discussed before?) and says 
we have come up with a spin process.

https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00695.html

Nothing in the wiki either says draft or proposal or anything like that.

https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00768.html 


makes it sound like a final decision as well.

If this is really just a proposal, give it more than 3 days instead of 
voting in such a hurried manner after announcing a spin sig meeting out 
of the blue with no prior discussions of time or date or interval. There 
are lot of basic details we need to discuss about this and we need to 
discuss it on list before moving to a IRC meeting and voting about it. 
Please give it more time and do it right.

Rahul




From jkeating at redhat.com  Thu Jan 15 19:18:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 11:18:13 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496F8731.2010003@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>
	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>
	<496F4E9C.8090709@kanarip.com> <496F53E0.5070205@fedoraproject.org>
	<1232041660.5086.104.camel@localhost.localdomain>
	<496F78E5.2080002@fedoraproject.org>
	<1232043598.5086.105.camel@localhost.localdomain>
	<496F8731.2010003@fedoraproject.org>
Message-ID: <1232047093.5086.108.camel@localhost.localdomain>

On Fri, 2009-01-16 at 00:27 +0530, Rahul Sundaram wrote:
> If this is really just a proposal, give it more than 3 days instead of 
> voting in such a hurried manner after announcing a spin sig meeting out 
> of the blue with no prior discussions of time or date or interval. There 
> are lot of basic details we need to discuss about this and we need to 
> discuss it on list before moving to a IRC meeting and voting about it. 
> Please give it more time and do it right.

Well if we don't want to have any spins for F11 so that we can spend the
time and hash out every single detail over public email, that's fine
with me.  I'll be over here getting actual work done.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/9fe33a57/attachment.sig>

From sundaram at fedoraproject.org  Thu Jan 15 19:28:52 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Jan 2009 00:58:52 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <1232047093.5086.108.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>	<496F38E4.1060108@fedoraproject.org>	<496F45BD.2040803@kanarip.com>	<496F479D.5030604@fedoraproject.org>	<496F4E9C.8090709@kanarip.com>
	<496F53E0.5070205@fedoraproject.org>	<1232041660.5086.104.camel@localhost.localdomain>	<496F78E5.2080002@fedoraproject.org>	<1232043598.5086.105.camel@localhost.localdomain>	<496F8731.2010003@fedoraproject.org>
	<1232047093.5086.108.camel@localhost.localdomain>
Message-ID: <496F8E74.5090308@fedoraproject.org>

Jesse Keating wrote:
> On Fri, 2009-01-16 at 00:27 +0530, Rahul Sundaram wrote:
>> If this is really just a proposal, give it more than 3 days instead of 
>> voting in such a hurried manner after announcing a spin sig meeting out 
>> of the blue with no prior discussions of time or date or interval. There 
>> are lot of basic details we need to discuss about this and we need to 
>> discuss it on list before moving to a IRC meeting and voting about it. 
>> Please give it more time and do it right.
> 
> Well if we don't want to have any spins for F11 so that we can spend the
> time and hash out every single detail over public email, that's fine
> with me.  I'll be over here getting actual work done.

Discussing and coming up with a solid process *is* part of getting 
actual work done. Skipping on this in the name of "actual work" is what 
has caused confusion over the past few releases. However, there is no 
blocker to getting Fedora 11 spins out continuing whatever we had in the 
past as the way to get that done while we continue to improve on doing 
this better for the next release. If it just can't be done let's do 
remixes on our own instead for a release or two till we manage to find 
time and interest to do this correctly. Rushing out a vote in a with 
only a skeleton process is no way to do this.

Rahul



From mw_triad at users.sourceforge.net  Thu Jan 15 20:09:45 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 15 Jan 2009 14:09:45 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <496E667A.1040803@kanarip.com>
References: <1231962712.14403.1559.camel@rosebud>	<20090114210846.GB18581@yoda.jdub.homelinux.org>	<1231967550.14403.1571.camel@rosebud>	<20090114213257.GC18581@yoda.jdub.homelinux.org>	<gklmfd$1ru$1@ger.gmane.org>
	<496E667A.1040803@kanarip.com>
Message-ID: <gko569$gg8$1@ger.gmane.org>

Jeroen van Meeuwen wrote:
> Matthew Woehlke wrote:
>> This reminds me... on my Asus cleanup project, one of the things I
>> did NOT remove was the xorg-drivers package, for exactly this 
>> reason. This is one case where I want 'yum update' to know about
>> new xorg drivers. But this means I can't remove drivers I don't
>> need, because it will remove the metapackage, which means I won't 
>> automagically find out about new drivers.
> 
> Euhm, I can remove xorg-drivers without any dependencies, but not a 
> xorg-x11-drv-* package. I'm not sure why these other packages depend on 
> xorg-drivers, but that's not how a meta package would be used:

Ok, I'm confused. I agree that's how it works. But that's exactly how it 
is meant to work, from my perspective. xorg-drivers is the metapackage, 
so you cannot remove individual drivers without removing the 
metapackage. (But nothing stops you from removing just the metapackage.)

> yum install @foo would install bar and baz
> 
> yum remove baz would remove baz

Um... no, that's not how it works. foo depends on bar and baz; if you 
remove bar and/or baz without removing foo, foo is broken. (If foo is a 
metapackage, then "broken" doesn't really mean anything, but rpm doesn't 
distinguish between metapackages and regular packages.)

For example, you install kde, which installs qt. By your logic, I could 
now remove qt, but of course kde wouldn't work very well if I did, so 
removing qt also removes anything that depends on it, i.e. kde. 
(Obviously I am simplifying; kde is more fine-grained than one package.)

> yum update @foo would pull in baz again, and maybe newpkg1.

Even *if* rpm knew about metapackages and could do that, I wouldn't want 
baz to be pulled in again. Presumably I removed it because I don't 
need/want it.

> The above example does exactly what you want it to do, just not how you 
> would like it to do so, I presume.

Not quite (as per previous paragraph), but it also doesn't work that way 
currently. If it did, it would be an improvement, although a small one 
if it keeps wanting to reinstall things I removed.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)



From mw_triad at users.sourceforge.net  Thu Jan 15 20:11:11 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 15 Jan 2009 14:11:11 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090114231407.GD18581@yoda.jdub.homelinux.org>
References: <1231962712.14403.1559.camel@rosebud>	<20090114210846.GB18581@yoda.jdub.homelinux.org>	<1231967550.14403.1571.camel@rosebud>	<20090114213257.GC18581@yoda.jdub.homelinux.org>	<gklmfd$1ru$1@ger.gmane.org>
	<20090114231407.GD18581@yoda.jdub.homelinux.org>
Message-ID: <gko58v$g08$1@ger.gmane.org>

Josh Boyer wrote:
> On Wed, Jan 14, 2009 at 03:46:20PM -0600, Matthew Woehlke wrote:
>> Josh Boyer wrote:
>>> Ok, but if group-metapkg has Requires on all the packages in the
>>> group, then won't:
>>>
>>> yum remove foo-is-part-of-group
>>>
>>> hit the Requires on group-metapkg and have yum try to remove it,
>>> along with everything else?
>> For the benefit of the list, the answer is "yes". This is why I don't  
>> like using metapackages this way; you can't selectively install them.
> 
> Actually, the answer is no.

Oh, sorry. It will remove the metapackage. I missed the part about 
"everything else".

Let me try again:

Will it remove the metapackage?
Yes.

Will removing the metapackage remove everything else?
No*.

(* assuming remove-with-leaves isn't in use)

Jesse's reply pretty much hits right on what my complaint is.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)



From limb at jcomserv.net  Thu Jan 15 20:17:42 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Thu, 15 Jan 2009 14:17:42 -0600 (CST)
Subject: asciidoc abandoned?
In-Reply-To: <4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
Message-ID: <853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>


>
>> x86_64, rawhide up to date.
>>
>> I've got an annoying bug in asciidoc (#283351; yes, it is quite old by
>> now), and I check regularly on that one, there being no movement there
>> except for automagic assignment to the stable releases. The current
>> package
>> is still asciidoc-8.2.5-2.fc9.noarch in Fedora, while upstream it is now
>> at
>> 8.3.3. In any case, the homepage warns of possible compatibility issues
>> WRT
>> 8.2.7. They look relatively minor to me, but in any case I believe
>> Fedora
>> 11 should ship the new version.
>
> Looks like Chris Wright owns it, and Florian La Roche did quite a bit with
> it, but nothing since 2007.  Would either care to comment?

Horst, I've been playing with this, and 8.2.7 fixes your issue, and
according to the changelog:

http://www.methods.co.nz/asciidoc/CHANGELOG.html

there are not major compatibility issues WRT 8.2.5.  The ACLs allow
provenpackagers to commit, and I am one, so in the event the neither Chris
nor Florian gets back to us I can at least build and push 8.2.7 for F-10
and F-9.  Then we can discuss 8.3.3 for rawhide, including compat issues,
dependencies, etc.

>> --
>> 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
>>
>> --
>> fedora-devel-list mailing list
>> fedora-devel-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>>
>
>
> --
> in your fear, speak only peace
> in your fear, seek only love
>
> -d. bowie
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From benny+usenet at amorsen.dk  Thu Jan 15 20:21:39 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 15 Jan 2009 21:21:39 +0100
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc> (Tomas Mraz's message
	of "Wed\, 14 Jan 2009 23\:03\:34 +0100")
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <m3zlhscobw.fsf@ursa.amorsen.dk>

Not again. Why does openssl make us suffer so?


/Benny



From fedux13 at yahoo.com  Thu Jan 15 20:27:59 2009
From: fedux13 at yahoo.com (Fedora Linux)
Date: Thu, 15 Jan 2009 12:27:59 -0800 (PST)
Subject: Help with C Code in Fedora
Message-ID: <735284.12620.qm@web112215.mail.gq1.yahoo.com>

Hi,
I am new to Linux and just installed Fedora 10 on my Machine. I wanted
to develop graphical libraries using C (not C++). Can anyone please
tell me if there is some place where I can download these graphical
Libraries. For example if I want to display a pixel on the screen can
someone please explain how I could do so using C  


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/22a722cf/attachment.htm>

From tmraz at redhat.com  Thu Jan 15 20:34:49 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 15 Jan 2009 21:34:49 +0100
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <m3zlhscobw.fsf@ursa.amorsen.dk>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<m3zlhscobw.fsf@ursa.amorsen.dk>
Message-ID: <1232051689.5215.79.camel@vespa.frost.loc>

On Thu, 2009-01-15 at 21:21 +0100, Benny Amorsen wrote:
> Not again. Why does openssl make us suffer so?

This is due to bad design of openssl namely declaring some important
structures which have to be changed/extended with new functionality in
the public headers. Unless they move these structures to private headers
this situation is going to happen again.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From Jochen at herr-schmitt.de  Thu Jan 15 20:36:58 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 15 Jan 2009 21:36:58 +0100
Subject: Help with C Code in Fedora
In-Reply-To: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
Message-ID: <496F9E6A.3060102@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fedora Linux schrieb:
> Hi, I am new to Linux and just installed Fedora 10 on my Machine. I
> wanted to develop graphical libraries using C (not C++). Can anyone
> please tell me if there is some place where I can download these
> graphical Libraries. For example if I want to display a pixel on
> the screen can someone please explain how I could do so using C
>
>
>
It's nice, that you are interesting to develop linux applications.
Because you
want to use C as programming language, I would propose, that you may
use the gtk+
toolkit.

Because GNOME is the sttandard desktop of Fedora, you have only to
install the
gtk2-devel package on your system.

Unfortunately, I'm prefering Qt, so I can't give you forther
information, but I think
the documentation of gtk should help you to take your first steps.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklvnmEACgkQT2AHK6txfgzIzQCdHQSKd3jb3L2q4HtdzfUzzy+z
BhoAniRucFlamTWoIzzXPkWg+6na6O5E
=ssKN
-----END PGP SIGNATURE-----



From notting at redhat.com  Thu Jan 15 20:41:57 2009
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 15 Jan 2009 15:41:57 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gklnan$5fb$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
Message-ID: <20090115204156.GA30791@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> seth vidal wrote:
> > Conditional packages were viewed, from the outset, as something that had
> > to go. One way or the other conditional pkgs were going to get beaten
> > up.
> 
> But it can't go because there's no working alternative.

Well... attached is a prototype of a yum plugin to do this sort of stuff.

However:

- KDE would need to be repackaged so their packages are kde-l10n-fr,
  kde-i18n-de, etc. Same for some other packages (scim-lang?)
- The actual list of conditional packages would still need to be
  in the external metadata that's used to define the groups, as it
  shouldn't be hardcoded in the plugin, nor dropped on the filesystem

Bill
-------------- next part --------------
#!/bin/env python
# -*- coding: utf-8 -*-
#
# Conditional language support packages, via a yum plugin
#
# Copyright ? 2009 Red Hat, Inc.
#
# 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; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

from yum.plugins import TYPE_CORE

import fnmatch
import glob
import locale
import rpm

requires_api_version = '2.5'
plugin_type = TYPE_CORE

langs = []

# This needs to be in the metadata somewhere. For a POC, this works.
conditional_pkgs = {
  'aspell' : [ 'aspell-%s', 'hunspell-%s' ],
  'eclipse-platform' : [ 'eclipse-nls-%s' ],
  'gcompris' : [ 'gcompris-sound-%s'],
  'hunspell' : [ 'hunspell-%s' ],
  'hyphen' : [ 'hyphen-%s' ],
  'kdelibs3' : [ 'kde-i18n-%s' ],
  'kdelibs' : [ 'kde-l10n-%s' ],
  'koffice-core' : [ 'koffice-langpack-%s' ],
  'LabPlot-doc' : [ 'LabPlot-doc-%s' ],
  'man-pages' : [ 'man-pages-%s' ],
  'moodle' : [ 'moodle-%s' ],
  'openoffice.org-core' : [ 'openoffice.org-langpack-%s' ],
  'tesseract' : [ 'tesseract-langpack-%s' ],
  'xorg-x11-server-Xorg' : [ 'scim-lang-%s' ]
}

def config_hook(conduit):
    global conditional_pkgs
    
    # Here is where we would read conditional pkgs from some sort of
    # metadata. For now, they're defined above

def init_hook(conduit):
    global langs
    
    (lang, encoding) = locale.getdefaultlocale()
    
    rpm_langs = rpm.expandMacro("%_install_langs")
    # FIXME - what to do here? 'all' seems to be the default
    if rpm_langs == "all":
        #langs.append('*')
        #print "YOU GET TO DRINK FROM THE FIRE HOSE!"
        #return
        pass
    else:
        langlist = rpm_langs.split(':')
        for l in langlist:
            print "Adding %s to language list" % (l,)
            langs.append(l)
    print "Adding %s to language list" % (lang,)
    langs.append(lang)

def add_deps_to_ts(conduit, po):
    conds = conditional_pkgs[po.name]
    sack = conduit.getRepos().getPackageSack()
    tsInfo = conduit.getTsInfo()
    for lang in langs:
        pkgs = sack.returnPackages(patterns = map(lambda x: x % (lang,), conds))
        if not pkgs and lang != '*':
            shortlang = lang.split('_')[0]
            pkgs = sack.returnPackages(patterns = map(lambda x: x % (shortlang,), conds))
        for po in pkgs:
            print "Adding %s to transaction" % (po.name)
            tsInfo.addInstall(po)

def remove_deps_from_ts(conduit, po):
    conds = conditional_pkgs[po.name]
    pkgs = conduit.getRpmDB().returnPackages()
    tsInfo = conduit.getTsInfo()
    for pkg in pkgs:
        for c in conds:
            for lang in langs:
              if fnmatch.fnmatch(pkg.name, c % (lang,)):
                  print "Removing %s from system" % (pkg.name)
                  tsInfo.addErase(pkg)
              shortlang = lang.split('_')[0]
              if fnmatch.fnmatch(pkg.name, c % (shortlang,)):
                  print "Removing %s from system" % (pkg.name)
                  tsInfo.addErase(pkg)

def postresolve_hook(conduit):
    for member in conduit.getTsInfo().getMembers():
        po = member.po
        if conditional_pkgs.has_key(po.name):
            print "AOOOGA AOOOGA %s" % ( po.name )
            if member.ts_state in ('i', 'u'):
                add_deps_to_ts(conduit, po)
            elif member.ts_state in ('e'):
                remove_deps_from_ts(conduit, po)

From james at fedoraproject.org  Thu Jan 15 21:01:09 2009
From: james at fedoraproject.org (James Antill)
Date: Thu, 15 Jan 2009 16:01:09 -0500
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <m3zlhscobw.fsf@ursa.amorsen.dk>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<m3zlhscobw.fsf@ursa.amorsen.dk>
Message-ID: <1232053269.4934.84.camel@code.and.org>

On Thu, 2009-01-15 at 21:21 +0100, Benny Amorsen wrote:
> Not again. Why does openssl make us suffer so?

 The openssl developers not-so-secretly want anyone to use NSS instead.

-- 
James Antill <james at fedoraproject.org>
Fedora



From Jochen at herr-schmitt.de  Thu Jan 15 21:21:47 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 15 Jan 2009 22:21:47 +0100
Subject: Trouble with koji (%_font_pkg macro)
Message-ID: <496FA8EB.6040402@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

I have try to adap aplus-fsf to the new fonts packaging policy.

The local build (F-10) works fine, but the koji build failed as you
can see at:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1056379

The issue is relating to using the _font_pkg for creating a font
subpackage.

It will be nice, if anyone can give me a hint to solve this issue.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklvqOEACgkQT2AHK6txfgzDoACfaFfohPsU+Nytt/oFttW9hcD1
bygAoPznykHfFF81d6Kho9BbK7mDdH5M
=rdHW
-----END PGP SIGNATURE-----



From nicolas.mailhot at laposte.net  Thu Jan 15 21:30:21 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 15 Jan 2009 22:30:21 +0100
Subject: Trouble with koji (%_font_pkg macro)
In-Reply-To: <496FA8EB.6040402@herr-schmitt.de>
References: <496FA8EB.6040402@herr-schmitt.de>
Message-ID: <1232055021.20003.0.camel@arekh.okg>

Le jeudi 15 janvier 2009 ? 22:21 +0100, Jochen Schmitt a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hallo,
> 
> I have try to adap aplus-fsf to the new fonts packaging policy.
> 
> The local build (F-10) works fine, but the koji build failed as you
> can see at:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1056379
> 
> The issue is relating to using the _font_pkg for creating a font
> subpackage.

See
https://www.redhat.com/archives/fedora-packaging/2009-January/msg00090.html

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/b2a19bf6/attachment.sig>

From alsadi at gmail.com  Thu Jan 15 21:40:25 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Thu, 15 Jan 2009 23:40:25 +0200
Subject: Keyboard shortcut buttons logs out of Gnome/X
In-Reply-To: <1232017338.13084.0.camel@snoogens.fab.redhat.com>
References: <1231952196.4947.6.camel@scrappy.miketc.net>
	<1232017338.13084.0.camel@snoogens.fab.redhat.com>
Message-ID: <385866f0901151340q591883d7r826654adc2ef6aff@mail.gmail.com>

> I select.  Any ideas  and what component would I file a bug against
my guess is hal, because my Xlog says

(II) config/hal: Adding input device AT Translated Set 2 keyboard
(II) LoadModule: "evdev"



From rdieter at math.unl.edu  Thu Jan 15 21:39:18 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 15 Jan 2009 15:39:18 -0600
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
	<20090115204156.GA30791@nostromo.devel.redhat.com>
Message-ID: <gkoaee$ojq$1@ger.gmane.org>

Bill Nottingham wrote:

> Kevin Kofler (kevin.kofler at chello.at) said:
>> seth vidal wrote:
>> > Conditional packages were viewed, from the outset, as something that
>> > had to go. One way or the other conditional pkgs were going to get
>> > beaten up.
>> 
>> But it can't go because there's no working alternative.
> 
> Well... attached is a prototype of a yum plugin to do this sort of stuff.

ok for language conditionals... there's a few other use-cases...

but I was just wondering that perhaps this is an area where soft/recommended
dependencies could help address (within or not in the context of the future
of comps).

-- Rex



From mw_triad at users.sourceforge.net  Thu Jan 15 21:42:27 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 15 Jan 2009 15:42:27 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <496F5A75.30007@redhat.com>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
Message-ID: <gkoak3$qhf$1@ger.gmane.org>

Florian Festi wrote:
> Multilib:
> The situation has changed a lot since we introduced multilib. The challenge
> who is going to support 64bit processors first has been decided long ago 
> and the age of 32bit processors is ending.

No it isn't. I doubt very much that use of 32-bit processors is going 
away any time soon. (In "traditional desktops", maybe, but not embedded 
devices. Perhaps even in devices Fedora is interested in supporting, but 
that I'm not so sure about. It will depend heavily on a: if netbooks 
universally switch to 64-bit CPU's, and b: if Fedora decides to support 
other sorts of MID's, e.g. "phones". Yes, I know, at the point Fedora is 
running on such a device it will be "an MID that happens to be able to 
make phone calls", but we're already at that stage.)

And I hear plenty of embedded devices still use *16*-bit CPU's...

> There are several annoying features
> of the solution that was chosen at the time (overwriting 32 bit binaries,
> install lots of files twice) and we should get rid of them at some point in
> the (not too near) future. But this may require some other changes first...

Other than perhaps binutils, why would you ever have a 32-bit binary on 
a 64-bit system? ;-) Or do you include libs in "binaries"?

As for the rest, IMO as long as gcc supports -m32, it should stay. The 
project I work on for my day job would have to completely scrap our 
build system and break what is currently a one-package multilib 
distribution into two separate platforms, if multilib went away.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)



From skvidal at fedoraproject.org  Thu Jan 15 21:43:49 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 15 Jan 2009 16:43:49 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoaee$ojq$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
	<20090115204156.GA30791@nostromo.devel.redhat.com>
	<gkoaee$ojq$1@ger.gmane.org>
Message-ID: <1232055829.14403.1707.camel@rosebud>

On Thu, 2009-01-15 at 15:39 -0600, Rex Dieter wrote:
> Bill Nottingham wrote:
> 
> > Kevin Kofler (kevin.kofler at chello.at) said:
> >> seth vidal wrote:
> >> > Conditional packages were viewed, from the outset, as something that
> >> > had to go. One way or the other conditional pkgs were going to get
> >> > beaten up.
> >> 
> >> But it can't go because there's no working alternative.
> > 
> > Well... attached is a prototype of a yum plugin to do this sort of stuff.
> 
> ok for language conditionals... there's a few other use-cases...
> 
> but I was just wondering that perhaps this is an area where soft/recommended
> dependencies could help address (within or not in the context of the future
> of comps).

they don't help the problem at all, they just introduce a whole other
set of difficulties as to what the default behavior should be when we
hit them.

-sv




From bnocera at redhat.com  Thu Jan 15 22:19:36 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 15 Jan 2009 22:19:36 +0000
Subject: Keyboard shortcut buttons logs out of Gnome/X
In-Reply-To: <385866f0901151340q591883d7r826654adc2ef6aff@mail.gmail.com>
References: <1231952196.4947.6.camel@scrappy.miketc.net>
	<1232017338.13084.0.camel@snoogens.fab.redhat.com>
	<385866f0901151340q591883d7r826654adc2ef6aff@mail.gmail.com>
Message-ID: <1232057976.16333.7.camel@snoogens.fab.redhat.com>

On Thu, 2009-01-15 at 23:40 +0200, Muayyad AlSadi wrote:
> > I select.  Any ideas  and what component would I file a bug against
> my guess is hal, because my Xlog says
> 
> (II) config/hal: Adding input device AT Translated Set 2 keyboard
> (II) LoadModule: "evdev"

What would that have to do with anything? The X server uses HAL to find
the input devices. That's it.



From mw_triad at users.sourceforge.net  Thu Jan 15 23:03:03 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 15 Jan 2009 17:03:03 -0600
Subject: Migration of the Fedora Mailing Lists
In-Reply-To: <496F763D.7050006@cchtml.com>
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>	<496F0C85.3000307@fedoraproject.org>	<496F10A8.9040800@pingoured.fr>	<62bc09df0901150238o55ed0bc1ybdbeb9596ea2fc20@mail.gmail.com>	<496F733D.7080000@leemhuis.info>
	<496F763D.7050006@cchtml.com>
Message-ID: <gkofb7$8rv$1@ger.gmane.org>

Michael Cronenworth wrote:
> fedora-fonts -> fonts at lists.fedoraproject.org
> fedora-kernel-list -> kernel at lists.fedoraproject.org
> fedora-list -> support at lists.fedoraproject.org
> fedora-devel-list -> development at lists.fedoraproject.org
> fedora-virt -> virtualization at lists.fedoraproject.org
> 
> Etc., etc., etc.

Please be sure to update gmane when doing this. It would be preferable 
if you can either coordinate the changeover with them, or else mirror 
the lists via the old address for a few days. (gmane doesn't have the 
beginning of this thread, so I don't know if that was already planned.)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)



From jkeating at redhat.com  Fri Jan 16 00:14:00 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 16:14:00 -0800
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
	<1231943326.5086.49.camel@localhost.localdomain>
	<b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>
Message-ID: <1232064840.5086.136.camel@localhost.localdomain>

On Thu, 2009-01-15 at 14:29 +0100, devzero2000 wrote:
> it is very boring not also have the 32 - bit version of httpd on 64 bit SO.
> Often it is required the installation commercial 32 bit apache modules - i
> am speaking of RHEL . But certainly install an 32 bit operating system on
> machines with 10 g of RAM - that i have - is not a thing magnificent. Then
> it would be useful to install on a 64  bit SO AND an 32 bit Apache  but the
> repo (or RHN) default don't have. Sure, i can do anyway on RHEL5.
> 
> (Aside) On Fedora 10 64  bit i have also enabled the repo 32 but strangely
> enough, i have an error of conflict (on RHEL5 it is ok) . But that is  off
> topic, perhaps.
> 
> yum install httpd.i386
> 
> Transaction Check Error:
>   file /etc/httpd/modules from install of httpd-2.2.10-2.i386 conflicts with
> file from package httpd-2.2.10-2.x86_64
> 
> The same with squid.
> 
> It is also true with %_transaction_color     3 in /etc/rpm/macros.color

The base package can't be multilib, as the paths aren't unique.  You can
only have one /usr/sbin/httpd and which arch wins if you try to install
both?  You won't be able to run both a 64bit httpd instance and a 32bit
httpd instance.

You can do chroots or virt images in order to serve up your 32bit needs
though.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/bdf4b366/attachment.sig>

From kevin.kofler at chello.at  Fri Jan 16 00:59:11 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 01:59:11 +0100
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>
	<20090115152712.GB7579@wolff.to>
	<496F56AB.4060809@fedoraproject.org>
Message-ID: <gkom4v$q8s$1@ger.gmane.org>

Rahul Sundaram wrote:
> That wasn't what I was talking about however. I think Josh Boyer
> understands the issue better. Essentially, the environment that spin
> maintainers do composes on should be exactly the same as the one the
> final composes are being made. Any minor change can cause issues which
> we cant easily reproduce.

But what if fixes are needed to make one of the base spins, or even another
custom spin, work?

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan 16 01:10:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 02:10:55 +0100
Subject: Heads up: MySQL 5.1 coming soon to rawhide
References: <17597.1231954770@sss.pgh.pa.us>
	<20090115094820.GA30562@amd.home.annexia.org>
Message-ID: <gkomqv$q8s$2@ger.gmane.org>

Richard W.M. Jones wrote:
> Also ocaml-mysql{,-devel}.  For some reason this is lacking a
> dependency on the library, but it certainly needs one.

Most likely it's using dlopen, there are no autoreqs on dlopened stuff.

        Kevin Kofler



From jonstanley at gmail.com  Fri Jan 16 01:16:54 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 15 Jan 2009 20:16:54 -0500
Subject: Plan for tommorow's (20090116) FESCo meeting
Message-ID: <da159fda0901151716k7d6bd0eeif262d3a55dda37f1@mail.gmail.com>

So I fail as chair, week 1 :(  I'm out tonight, and before I went out
I neglected to send this out.

The current agenda can be found at https://fedorahosted.org/fesco/report/9

I have not yet added features to the agenda, they are on the wiki in
the category FeaturesReadyForFesco. I will add trac tickets for them
when I get back tonight.

Sincere apologies for the late (and incomplete) notice.

-- 
Sent from my mobile device

Jon Stanley
Fedora Bug Wrangler
jstanley at fedoraproject.org



From kevin.kofler at chello.at  Fri Jan 16 01:15:12 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 02:15:12 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
	<20090115204156.GA30791@nostromo.devel.redhat.com>
	<gkoaee$ojq$1@ger.gmane.org> <1232055829.14403.1707.camel@rosebud>
Message-ID: <gkon30$q8s$3@ger.gmane.org>

seth vidal wrote:
> they don't help the problem at all, they just introduce a whole other
> set of difficulties as to what the default behavior should be when we
> hit them.

Here's how I see things (which I believe is close if not identical to how it
works on Debian):

Recommended = default on.
Suggested = default off.
The user can customize it to have both on or both off.

And in both cases, removing a package with only a soft dep should not remove
the dependent package (except if an option to treat them as hard deps is
set).

        Kevin Kofler



From sundaram at fedoraproject.org  Fri Jan 16 01:21:45 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Jan 2009 06:51:45 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <gkom4v$q8s$1@ger.gmane.org>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>	<496F56AB.4060809@fedoraproject.org>
	<gkom4v$q8s$1@ger.gmane.org>
Message-ID: <496FE129.6060404@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> That wasn't what I was talking about however. I think Josh Boyer
>> understands the issue better. Essentially, the environment that spin
>> maintainers do composes on should be exactly the same as the one the
>> final composes are being made. Any minor change can cause issues which
>> we cant easily reproduce.
> 
> But what if fixes are needed to make one of the base spins, or even another
> custom spin, work?

Then, ideally both the spin owner and Fedora infrastructure folks are 
aware and can coordinate on the changes required. The same concerns 
apply. We should strive to minimize the differences in the environment 
between test composes and the final compose.

Rahul



From jkeating at redhat.com  Fri Jan 16 01:28:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 17:28:13 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496FE129.6060404@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>
	<496F56AB.4060809@fedoraproject.org> <gkom4v$q8s$1@ger.gmane.org>
	<496FE129.6060404@fedoraproject.org>
Message-ID: <1232069293.5086.169.camel@localhost.localdomain>

On Fri, 2009-01-16 at 06:51 +0530, Rahul Sundaram wrote:
> 
> Then, ideally both the spin owner and Fedora infrastructure folks are 
> aware and can coordinate on the changes required. The same concerns 
> apply. We should strive to minimize the differences in the environment 
> between test composes and the final compose.

I'm not all that sure why you think there is a difference.  During the
F10 development, the spins were composed in a guest that was rawhide of
the day.  The configs came from the git tag for spin-kickstarts.  I'm
really not sure how this would be any different from anybody else.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/d9a42808/attachment.sig>

From sundaram at fedoraproject.org  Fri Jan 16 01:36:44 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Jan 2009 07:06:44 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <1232069293.5086.169.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>	<496F56AB.4060809@fedoraproject.org>
	<gkom4v$q8s$1@ger.gmane.org>	<496FE129.6060404@fedoraproject.org>
	<1232069293.5086.169.camel@localhost.localdomain>
Message-ID: <496FE4AC.9060001@fedoraproject.org>

Jesse Keating wrote:
> On Fri, 2009-01-16 at 06:51 +0530, Rahul Sundaram wrote:
>> Then, ideally both the spin owner and Fedora infrastructure folks are 
>> aware and can coordinate on the changes required. The same concerns 
>> apply. We should strive to minimize the differences in the environment 
>> between test composes and the final compose.
> 
> I'm not all that sure why you think there is a difference.  During the
> F10 development, the spins were composed in a guest that was rawhide of
> the day.  The configs came from the git tag for spin-kickstarts.  I'm
> really not sure how this would be any different from anybody else.

As I said already, we did run into a problem in the compose of Xfce live 
cd because the VM had a updated livecd-tools (post GA update IIRC) which 
created a SELinux policy denial or similar issue.

Rahul



From kevin.kofler at chello.at  Fri Jan 16 01:36:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 02:36:55 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud> <gklo5h$9gm$1@ger.gmane.org>
	<1232037920.14403.1610.camel@rosebud>
Message-ID: <gkoobo$2km$1@ger.gmane.org>

seth vidal wrote:
> When did you become a yum user? :)

When apt-rpm broke beyond repair (well, it's finally being fixed now), but
that would be something for another rant. ;-)

>> I don't want packages to be magically added just because they're in some
>> group.
> 
> That's the point of the groups - of them being transitioned to metapkgs
> - so we no longer have the ambiguity. It's like watching a bad episode
> of moonlighting "will they? Won't they?".

But that's sidestepping the question whether the resolution "They will" is a
good idea in the first place.

> New stuff showing up in the repo is completely unrelated to the groups.

... which is exactly why it shouldn't get installed just because it got
added to some group. :-)

>> I can't believe I'm alone with that expectation. I actually think there
>> will be lots of complaints about unwanted packages getting automatically
>> added (for a reason most users won't understand - metapackages are black
>> magic as far as they're concerned).
> 
> and groups are worse black magic - if only b/c they have this way of
> rebounding on the people who do understand them. :-/

Well, I think that with the suggested changes, there will be a lots of
complaints about unwanted packages getting installed.

But what do I care? I can just remove all the metapackages. It's average
users who are going to get hurt (i.e. exactly the people you're trying to
help). :-(

> Which is why we can do groups of groups and more precisely break them
> down into smaller sections. so you install what you need, not the whole
> world.

That sounds reasonable, but I'm not sure it's going to scale. If we end up
with one group per package, we're failing.

> I suspect most users never know what comps is and they do all their
> discovery by doing:
> yum search someword
> or
> yum list somepkgnametheyknow

You think most people don't use the GUIs? I'm not claiming you're wrong
because I don't have any stats, but are you sure?

> Really? Who is making the plans for soft deps. Doesn't seem like it at
> the rpm layer.

Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
would be unfortunate, because I think they could be useful, I've seen
several cases where they would have helped (just one example: Kile (a LaTeX
editor) can call many tools, most users will want them dragged in, but some
don't and Kile will still work, with reduced functionality, without them -
just grep for Requires(hint) in packages (mostly those touched by Rex
Dieter) to see more places where we'd like soft dependencies) and Debian
fans keep making fun of us because we don't have them ;-).

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan 16 01:39:26 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 02:39:26 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>
	<y9hhc4175ad.fsf@libation.ircam.fr>
	<1231993687.14403.1596.camel@rosebud>
Message-ID: <gkooge$2km$2@ger.gmane.org>

seth vidal wrote:
>  - you can't merge metapkgs across multiple repos
> 
> that's the benefit of doing it this way.

Sorry, but how's that a benefit?

RPM Fusion extends the current comps groups with their own stuff. Why do you
want to stop them from doing that? It is what makes multimedia just work if
you add the RPM Fusion Free repository at install time. It also means the
packages will show up in the regular groups in GUIs, not in special "(RPM
Fusion Free)" groups. Banning it would break all this again.

        Kevin Kofler



From jkeating at redhat.com  Fri Jan 16 01:51:07 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 15 Jan 2009 17:51:07 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496FE4AC.9060001@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>
	<496F56AB.4060809@fedoraproject.org> <gkom4v$q8s$1@ger.gmane.org>
	<496FE129.6060404@fedoraproject.org>
	<1232069293.5086.169.camel@localhost.localdomain>
	<496FE4AC.9060001@fedoraproject.org>
Message-ID: <1232070667.5086.170.camel@localhost.localdomain>

On Fri, 2009-01-16 at 07:06 +0530, Rahul Sundaram wrote:
> As I said already, we did run into a problem in the compose of Xfce live 
> cd because the VM had a updated livecd-tools (post GA update IIRC) which 
> created a SELinux policy denial or similar issue.

Right, that was just my fault, and partly the problem was doing the spin
so far after GA.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/fca1f088/attachment.sig>

From ngompa13 at gmail.com  Fri Jan 16 01:59:17 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 15 Jan 2009 19:59:17 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <20090115152044.GC5966@localhost.localdomain>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
	<20090115152044.GC5966@localhost.localdomain>
Message-ID: <8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>

Yes, I would be willing to maintain the system if you guys wanted me to.
Also, I have answers for some of the items on the list just so that I could
expand on my belief that Enano could get the job done.
"""""""""""""""
* Good security record
Enano has a good security record, it had few holes in it during its
development period, and these were quickly spotted and plugged up nicely
* Proactive, security minded developer community that is ...
Enano was designed with security in mind, and the developer absolutely
believes security is top priority
* Highly responsive, especially to security issues
The Developer will react VERY quickly to any security issues and fix them
ASAP
* Flexible enough auth system to attach to FAS
Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and
DiffieHellman + AES192 for password transmission (that is the whole
backend). I'm not sure what FAS2 uses for auth system, but it will be likely
that the auth system backend in Enano would be entirely rewritten for FAS2
unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would
adopt OUR system for authentication :)
* RSS
Enano's FeedMe plugin provides RSS feeds
* L10n that doesn't break the translator workflow
I have no idea what this means.
* Output for Transifex (PO/POT)
Could be done with a helper script according to the Developer.
* Content workflow (write <=> edit => publish)
No idea what this means.
* Internal version control with rollback capability
Definitely. Due to the wiki capabilities in Enano, all documents have the
capability of being rolled back, it supports diffing and revision control
* Content expiration (automatic)
Not sure, but I think this could be done through a plugin
* Multiple roles, e.g. writer, team lead, editor, publisher, managing editor
Defintely. Group support is in Enano and through its ACLs it is possible to
set the exact correct permissions for each group to suit its role
* Categorize/tag content for easy base organization
Definite support for tags
* Search that works
Yes. The Search works very well.
* Integrate with FAS
I'm not sure of the integration points for FAS2 for Enano. It was actually
because our efforts to get the Fedora Project to use Enano last summer that
Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it
could be done through that. A method will have to be investigated.
* Be a CMS as a core function, not an add-on
It definitely is a CMS at the core.
* Handle making certain pages or content areas static/non-database driven,
such as for scaling during times of heavy resource demand
Can be done with adding a plugin
* Must not lock us in. Data should be portable to another CMS.
Any CMS that supports importing MediaWiki and HTML page data from
MySQL/Postgres should be able to import any and all documents from Enano
straight from the database.
"""""""""""

2009/1/15 Paul W. Frields <stickster at gmail.com>

> On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:
> > I would like to suggest Enano CMS, which fulfills most of the
> requirements
> > without plugins. It would take some work to get FAS2 integration and
> stuff
> > though. It uses MediaWiki syntax, so it is portable among other CMSes
> that
> > support importing MediaWiki data.
>
> As I understand the post Karsten made earlier, suggestions will be
> given credence if they are accompanied by people willing to deploy and
> maintain the suggested system.  I couldn't tell from your post if
> you're saying you're willing to do that, but you may in fact be saying
> just that.  Could you clarify so the Docs team can understand where to
> fit this suggestion into the lineup?
>
> --
> 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
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/da67610d/attachment.htm>

From kevin.kofler at chello.at  Fri Jan 16 01:59:25 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 02:59:25 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>
	<y9hr634v6dy.fsf@libation.ircam.fr> <496F7214.7020109@gmail.com>
Message-ID: <gkoplt$43e$1@ger.gmane.org>

Toshio Kuratomi wrote:
> You'd need to do the removal (yum remove -y mypackage should work) in a
> %post script.  This is something I've had to do before when making
> minimal livemedia.

But that means that for classical uses of kickstart (i.e. run the installer
with this kickstart on every machine), the package would get installed,
then removed, on every single machine. :-(

        Kevin Kofler



From sundaram at fedoraproject.org  Fri Jan 16 01:59:29 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 16 Jan 2009 07:29:29 +0530
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <1232070667.5086.170.camel@localhost.localdomain>
References: <496DD9E6.2050800@kanarip.com>
	<496E4B4C.6050103@redhat.com>	<496E67C0.20609@kanarip.com>
	<496F0A4B.5090504@fedoraproject.org>	<496F24F4.7090009@kanarip.com>
	<496F302F.6030905@fedoraproject.org>	<496F3327.40903@kanarip.com>
	<496F38E4.1060108@fedoraproject.org>	<20090115135658.GC2582@yoda.jdub.homelinux.org>	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>	<496F56AB.4060809@fedoraproject.org>
	<gkom4v$q8s$1@ger.gmane.org>	<496FE129.6060404@fedoraproject.org>	<1232069293.5086.169.camel@localhost.localdomain>	<496FE4AC.9060001@fedoraproject.org>
	<1232070667.5086.170.camel@localhost.localdomain>
Message-ID: <496FEA01.1090506@fedoraproject.org>

Jesse Keating wrote:
> On Fri, 2009-01-16 at 07:06 +0530, Rahul Sundaram wrote:
>> As I said already, we did run into a problem in the compose of Xfce live 
>> cd because the VM had a updated livecd-tools (post GA update IIRC) which 
>> created a SELinux policy denial or similar issue.
> 
> Right, that was just my fault, and partly the problem was doing the spin
> so far after GA.

The point wasn't to find out whom to blame. Just saying that is one 
instance which clearly did demonstrate that we need to avoid changes in 
the compose environment.  I have run into issues with other package 
updates in rawhide (GDM broke Xfce session once, yum failed to dep solve 
properly at another time and so on ) breaking the compose in regular 
intervals as well. So not just a livecd-tools specific thing.

Rahul



From ngompa13 at gmail.com  Fri Jan 16 02:01:09 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 15 Jan 2009 20:01:09 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
	<20090115152044.GC5966@localhost.localdomain>
	<8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>
Message-ID: <8278b1b0901151801x2866ccdboa0567be179edfa4a@mail.gmail.com>

And, I forgot to note, that it does have a graphical WYSIWYG editor. HTML is
highly sanitized with strict filters in place, so attack vectors through
HTML shouldn't be a problem.

On Thu, Jan 15, 2009 at 7:59 PM, King InuYasha <ngompa13 at gmail.com> wrote:

> Yes, I would be willing to maintain the system if you guys wanted me to.
> Also, I have answers for some of the items on the list just so that I could
> expand on my belief that Enano could get the job done.
> """""""""""""""
> * Good security record
> Enano has a good security record, it had few holes in it during its
> development period, and these were quickly spotted and plugged up nicely
> * Proactive, security minded developer community that is ...
> Enano was designed with security in mind, and the developer absolutely
> believes security is top priority
> * Highly responsive, especially to security issues
> The Developer will react VERY quickly to any security issues and fix them
> ASAP
> * Flexible enough auth system to attach to FAS
> Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and
> DiffieHellman + AES192 for password transmission (that is the whole
> backend). I'm not sure what FAS2 uses for auth system, but it will be likely
> that the auth system backend in Enano would be entirely rewritten for FAS2
> unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would
> adopt OUR system for authentication :)
> * RSS
> Enano's FeedMe plugin provides RSS feeds
> * L10n that doesn't break the translator workflow
> I have no idea what this means.
> * Output for Transifex (PO/POT)
> Could be done with a helper script according to the Developer.
> * Content workflow (write <=> edit => publish)
> No idea what this means.
> * Internal version control with rollback capability
> Definitely. Due to the wiki capabilities in Enano, all documents have the
> capability of being rolled back, it supports diffing and revision control
> * Content expiration (automatic)
> Not sure, but I think this could be done through a plugin
> * Multiple roles, e.g. writer, team lead, editor, publisher, managing
> editor
> Defintely. Group support is in Enano and through its ACLs it is possible to
> set the exact correct permissions for each group to suit its role
> * Categorize/tag content for easy base organization
> Definite support for tags
> * Search that works
> Yes. The Search works very well.
> * Integrate with FAS
> I'm not sure of the integration points for FAS2 for Enano. It was actually
> because our efforts to get the Fedora Project to use Enano last summer that
> Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it
> could be done through that. A method will have to be investigated.
> * Be a CMS as a core function, not an add-on
> It definitely is a CMS at the core.
> * Handle making certain pages or content areas static/non-database driven,
> such as for scaling during times of heavy resource demand
> Can be done with adding a plugin
> * Must not lock us in. Data should be portable to another CMS.
> Any CMS that supports importing MediaWiki and HTML page data from
> MySQL/Postgres should be able to import any and all documents from Enano
> straight from the database.
> """""""""""
>
> 2009/1/15 Paul W. Frields <stickster at gmail.com>
>
>> On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:
>> > I would like to suggest Enano CMS, which fulfills most of the
>> requirements
>> > without plugins. It would take some work to get FAS2 integration and
>> stuff
>> > though. It uses MediaWiki syntax, so it is portable among other CMSes
>> that
>> > support importing MediaWiki data.
>>
>> As I understand the post Karsten made earlier, suggestions will be
>> given credence if they are accompanied by people willing to deploy and
>> maintain the suggested system.  I couldn't tell from your post if
>> you're saying you're willing to do that, but you may in fact be saying
>> just that.  Could you clarify so the Docs team can understand where to
>> fit this suggestion into the lineup?
>>
>> --
>> 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
>>
>> --
>> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/fa4490ad/attachment.htm>

From kevin.kofler at chello.at  Fri Jan 16 02:16:19 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 03:16:19 +0100
Subject: Migration of the Fedora Mailing Lists
References: <da159fda0901141600h6fb76ea5i9e12d118bce7f71e@mail.gmail.com>
	<496F0C85.3000307@fedoraproject.org>
Message-ID: <gkoqlj$7f7$1@ger.gmane.org>

Rahul Sundaram wrote:
> Can you also make sure that the list descriptions are updated, has valid
> links etc as part of the migration process? I was trying to do this
> already but if you are already working with owners, we can do this
> together.

Indeed, some stuff still refers to Extras.
The fedora-extras-commits list also needs renaming. Badly.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan 16 02:30:46 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 03:30:46 +0100
Subject: Help with C Code in Fedora
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
Message-ID: <gkorgn$9hj$1@ger.gmane.org>

Fedora Linux wrote:
> I am new to Linux and just installed Fedora 10 on my Machine. I wanted
> to develop graphical libraries using C (not C++). Can anyone please
> tell me if there is some place where I can download these graphical
> Libraries. For example if I want to display a pixel on the screen can
> someone please explain how I could do so using C

Do you want to have full control over drawing (e.g. for a game) or do you
want to write an application which looks like common desktop applications
(with "widgets", i.e. controls like menus, buttons and textboxes)?

For the first thing, you'll want something like SDL or Allegro. Those are
the most frequently used ones, but there are some more libraries like that
in Fedora too.

For the second thing, something like GTK+ (which is in C) or Qt (it's C++,
but it replaces most of the C++ standard library with better-designed
classes, so you may end up actually liking it - I used to hate C++ and only
like C before I started coding with Qt and KDE). In both cases, you will
quickly notice that you need to think in a more object-oriented way. There
aren't really any modern GUI toolkits which are strictly procedural. GTK+
uses some convoluted ways to write object-oriented code in C (macros,
structures with function pointers in them etc.), Qt uses C++ for it. IMHO
Qt's solution is better (and yes, I have worked with both), but I'm
biased. :-) So as a plain C programmer, you'll have to get used to the OO
paradigm (and also to event-based programming) to do GUI programming,
objects and events are the main concepts there, whether it's in C++ or in
OO-style C (like GTK+).

        Kevin Kofler



From chrisw at redhat.com  Fri Jan 16 02:43:34 2009
From: chrisw at redhat.com (Chris Wright)
Date: Thu, 15 Jan 2009 18:43:34 -0800
Subject: asciidoc abandoned?
In-Reply-To: <4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
Message-ID: <20090116024334.GB6975@x200.localdomain>

* Jon Ciesla (limb at jcomserv.net) wrote:
> > I've got an annoying bug in asciidoc (#283351; yes, it is quite old by
> > now), and I check regularly on that one, there being no movement there
> > except for automagic assignment to the stable releases. The current
> > package
> > is still asciidoc-8.2.5-2.fc9.noarch in Fedora, while upstream it is now
> > at
> > 8.3.3. In any case, the homepage warns of possible compatibility issues
> > WRT
> > 8.2.7. They look relatively minor to me, but in any case I believe Fedora
> > 11 should ship the new version.
> 
> Looks like Chris Wright owns it, and Florian La Roche did quite a bit with
> it, but nothing since 2007.  Would either care to comment?

Horst, you've done most bug filing, you interested in helping maintain
the package?

thanks,
-chris



From chrisw at redhat.com  Fri Jan 16 02:53:37 2009
From: chrisw at redhat.com (Chris Wright)
Date: Thu, 15 Jan 2009 18:53:37 -0800
Subject: asciidoc abandoned?
In-Reply-To: <853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
Message-ID: <20090116025337.GD6975@x200.localdomain>

* Jon Ciesla (limb at jcomserv.net) wrote:
> Horst, I've been playing with this, and 8.2.7 fixes your issue, and
> according to the changelog:
> 
> http://www.methods.co.nz/asciidoc/CHANGELOG.html
> 
> there are not major compatibility issues WRT 8.2.5.  The ACLs allow
> provenpackagers to commit, and I am one, so in the event the neither Chris
> nor Florian gets back to us I can at least build and push 8.2.7 for F-10
> and F-9.  Then we can discuss 8.3.3 for rawhide, including compat issues,
> dependencies, etc.

Fine by me.  Just need to double check at least git against it.

thanks,
-chris



From katzj at redhat.com  Fri Jan 16 03:04:48 2009
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 15 Jan 2009 22:04:48 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkooge$2km$2@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<y9hhc4175ad.fsf@libation.ircam.fr>
	<1231993687.14403.1596.camel@rosebud> <gkooge$2km$2@ger.gmane.org>
Message-ID: <20090116030446.GA3162@redhat.com>

On Friday, January 16 2009, Kevin Kofler said:
> seth vidal wrote:
> >  - you can't merge metapkgs across multiple repos
> > 
> > that's the benefit of doing it this way.
> 
> Sorry, but how's that a benefit?
> 
> RPM Fusion extends the current comps groups with their own stuff. Why do you
> want to stop them from doing that? It is what makes multimedia just work if
> you add the RPM Fusion Free repository at install time. It also means the
> packages will show up in the regular groups in GUIs, not in special "(RPM
> Fusion Free)" groups. Banning it would break all this again.

No, that's exactly what Seth is saying.  By using the groups file ->
metapackage on the fly conversion, we allow what RPM Fusion is doing
today to be able to continue working.  If we were to use explicit meta
packages, on the other hand, it wouldn't

Jeremy



From tmz at pobox.com  Fri Jan 16 03:07:09 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Thu, 15 Jan 2009 22:07:09 -0500
Subject: asciidoc abandoned?
In-Reply-To: <20090116025337.GD6975@x200.localdomain>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
	<20090116025337.GD6975@x200.localdomain>
Message-ID: <20090116030709.GI18365@inocybe.teonanacatl.org>

Chris Wright wrote:
> Fine by me.  Just need to double check at least git against it.

FWIw, in F-10 and devel, git's manpages already have some oddities
which I believe come from either docbook-style-xsl or xmlto.

I thought that defining DOCBOOK_XSL_172 in the git build had fixed the
issues, but noticed later that it caused another one. :/

I mentioned this on git list the other day, so hopefully someone who
knows the whole ugly doc generation tool-chain can help find a fix.

http://thread.gmane.org/gmane.comp.version-control.git/105583/focus=105589

Who knows, maybe an asciidoc update will magically fix the problems?

...Now, where did I leave my pipe...

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you haven't the strength to impose your own terms upon life, you
must accept the terms it offers you.
    -- T.S. Eliot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/d63688c0/attachment.sig>

From craftjml at gmail.com  Fri Jan 16 03:21:27 2009
From: craftjml at gmail.com (Jud Craft)
Date: Thu, 15 Jan 2009 21:21:27 -0600
Subject: Help with C Code in Fedora
In-Reply-To: <gkorgn$9hj$1@ger.gmane.org>
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
	<gkorgn$9hj$1@ger.gmane.org>
Message-ID: <20d6441a0901151921t34cc7d34g3b0fce2e088e5723@mail.gmail.com>

He sounds like he's just starting out, and is still grasping object
oriented.  GTK+ stopped being an option just yet -- it requires more
than competent knowledge of C (function pointers!) and object-oriented
design.

He sounds like he wants to do pixel manipulation, so that rules out
GUI toolkits.  That sounds like a multimedia library right there.  So
maybe it's time to learn C & SDL, but it will be a little difficult.

In addition, he probably hasn't compiled anything before, or used a
makefile or GCC.  There's a lot of stuff that has to be reigned in for
a newbie linux programmer.

Try starting with the language.  After he gets used to C, then he can
tackle a GUI toolkit like GTK.

Although personally, it would be much better if he was introduced to
GUIs and graphics libraries at a higher level.  Trying to learn C
_and_ program graphics/interface is learning two moderately difficult
tricks at the same time.

I'd recommend starting higher level (use Python, Pygame - that is, SDL
for Python) -- learn how graphics libraries work first, and Python
provides an easy, gentle introduction to objects.  Then, when you're
ready, learn C.  After that, learn SDL & C.

You can google python, and google pygame, for details on how to use
them -- I believe Fedora has them in the
System->Preferences->Add/Remove Software.

You essentially have to learn the C language, also learn the library
(GTK or SDL), and possibly learn object-oriented programming
(mandatory for any GUI work).  He needs to choose one and get
comfortable, and then start tackling the other.  Python itself is a
very easy language to pick up on for a first-time programmer, since it
doesn't have the huge compile/make hurdle that C/C++ do, and once you
understand basic programming concepts, you could jump to something
harder.

Or go straight into it:  learn how to use gcc, learn how to program C,
learn SDL.  That's straight into the hard stuff, but much more direct.
 The choice is yours.



From ngompa13 at gmail.com  Fri Jan 16 03:39:13 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Thu, 15 Jan 2009 21:39:13 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <8278b1b0901151801x2866ccdboa0567be179edfa4a@mail.gmail.com>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
	<20090115152044.GC5966@localhost.localdomain>
	<8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>
	<8278b1b0901151801x2866ccdboa0567be179edfa4a@mail.gmail.com>
Message-ID: <8278b1b0901151939k3262bad1sbb25bb66a0f7a1c3@mail.gmail.com>

I don't know why I keep forgetting these things.... It is also modular, the
core is even made up of modules (just they are labeled "system" and are
basically unable to be disabled or removed).

On Thu, Jan 15, 2009 at 8:01 PM, King InuYasha <ngompa13 at gmail.com> wrote:

> And, I forgot to note, that it does have a graphical WYSIWYG editor. HTML
> is highly sanitized with strict filters in place, so attack vectors through
> HTML shouldn't be a problem.
>
>
> On Thu, Jan 15, 2009 at 7:59 PM, King InuYasha <ngompa13 at gmail.com> wrote:
>
>> Yes, I would be willing to maintain the system if you guys wanted me to.
>> Also, I have answers for some of the items on the list just so that I could
>> expand on my belief that Enano could get the job done.
>> """""""""""""""
>> * Good security record
>> Enano has a good security record, it had few holes in it during its
>> development period, and these were quickly spotted and plugged up nicely
>> * Proactive, security minded developer community that is ...
>> Enano was designed with security in mind, and the developer absolutely
>> believes security is top priority
>> * Highly responsive, especially to security issues
>> The Developer will react VERY quickly to any security issues and fix them
>> ASAP
>> * Flexible enough auth system to attach to FAS
>> Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and
>> DiffieHellman + AES192 for password transmission (that is the whole
>> backend). I'm not sure what FAS2 uses for auth system, but it will be likely
>> that the auth system backend in Enano would be entirely rewritten for FAS2
>> unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would
>> adopt OUR system for authentication :)
>> * RSS
>> Enano's FeedMe plugin provides RSS feeds
>> * L10n that doesn't break the translator workflow
>> I have no idea what this means.
>> * Output for Transifex (PO/POT)
>> Could be done with a helper script according to the Developer.
>> * Content workflow (write <=> edit => publish)
>> No idea what this means.
>> * Internal version control with rollback capability
>> Definitely. Due to the wiki capabilities in Enano, all documents have the
>> capability of being rolled back, it supports diffing and revision control
>> * Content expiration (automatic)
>> Not sure, but I think this could be done through a plugin
>> * Multiple roles, e.g. writer, team lead, editor, publisher, managing
>> editor
>> Defintely. Group support is in Enano and through its ACLs it is possible
>> to set the exact correct permissions for each group to suit its role
>> * Categorize/tag content for easy base organization
>> Definite support for tags
>> * Search that works
>> Yes. The Search works very well.
>> * Integrate with FAS
>> I'm not sure of the integration points for FAS2 for Enano. It was actually
>> because our efforts to get the Fedora Project to use Enano last summer that
>> Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it
>> could be done through that. A method will have to be investigated.
>> * Be a CMS as a core function, not an add-on
>> It definitely is a CMS at the core.
>> * Handle making certain pages or content areas static/non-database driven,
>> such as for scaling during times of heavy resource demand
>> Can be done with adding a plugin
>> * Must not lock us in. Data should be portable to another CMS.
>> Any CMS that supports importing MediaWiki and HTML page data from
>> MySQL/Postgres should be able to import any and all documents from Enano
>> straight from the database.
>> """""""""""
>>
>> 2009/1/15 Paul W. Frields <stickster at gmail.com>
>>
>>> On Thu, Jan 15, 2009 at 08:16:31AM -0600, King InuYasha wrote:
>>> > I would like to suggest Enano CMS, which fulfills most of the
>>> requirements
>>> > without plugins. It would take some work to get FAS2 integration and
>>> stuff
>>> > though. It uses MediaWiki syntax, so it is portable among other CMSes
>>> that
>>> > support importing MediaWiki data.
>>>
>>> As I understand the post Karsten made earlier, suggestions will be
>>> given credence if they are accompanied by people willing to deploy and
>>> maintain the suggested system.  I couldn't tell from your post if
>>> you're saying you're willing to do that, but you may in fact be saying
>>> just that.  Could you clarify so the Docs team can understand where to
>>> fit this suggestion into the lineup?
>>>
>>> --
>>> 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
>>>
>>> --
>>> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090115/e11e35c8/attachment.htm>

From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Jan 16 03:43:18 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 16 Jan 2009 12:43:18 +0900
Subject: Package doesn't build in Koji, but can be built locally using
 mock!
In-Reply-To: <496F7FDD.7020304@ioa.s.u-tokyo.ac.jp>
References: <496F7ACE.8040201@grad.com> <496F7FDD.7020304@ioa.s.u-tokyo.ac.jp>
Message-ID: <49700256.6000609@ioa.s.u-tokyo.ac.jp>

Mamoru Tasaka wrote, at 01/16/2009 03:26 AM +9:00:
> Hedayat Vatankhah wrote, at 01/16/2009 03:05 AM +9:00:
>> Hi all,
>> I'm the maintainer of rcssserver3d package. The package has been built 
>> in rawhide successfully, but recently I just removed a font file from 
>> the package and tried to build the package again in koji, but it 
>> failed. The build log says that it is unable to find 
>> /usr/lib64/libIL.so, but it should be able to find it. I didn't change 
>> anything related to it. Also, I tried to build the package using mock 
>> (make mockbuild) and the package was able to find the library! I 
>> wonder what's the problem?!
>>
>> koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=1055760
>>
>> Thanks,
>> Hedayat
> 
> At least DevIL-1.7.5-1.fc11 seems broken as now ldd reports that 
> libIL.so.1 contains undefined non-weak symbols. config.log shows:
> 
> -------------------------------------------------------------------
> configure:22286: g++ -o conftest -O2 -g -pipe -Wall 
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
> --param=ssp-buffer-size=4 -m64 -mtune=generic    -lIL conftest.cpp  >&5
> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
> undefined reference to `ilLoadVtf'
> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
> undefined reference to `ilLoadVtfF'
> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
> undefined reference to `ilLoadVtfL'
> collect2: ld returned 1 exit status
> configure:22293: $? = 1
> configure: failed program was:
> | #include <IL/il.h>
> | #include <stdarg.h> /* _vsnprintf may be undefined (and it is needed 
> by libIL) */
> | extern "C" int _vsnprintf(char *str, size_t size, const char *format, 
> va_list ap) { return 0;}
> | int main(int argc, char **argv) { ilInit(); return 0; }
> configure:22360: WARNING: The DevIL library (libIL.a or libIL.so) cannot 
> be found.
> -------------------------------------------------------------------
> 
> I guess this needs bug report against DevIL.

... and filed:
https://bugzilla.redhat.com/show_bug.cgi?id=480269

Mamoru



From jonstanley at gmail.com  Fri Jan 16 06:12:06 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 16 Jan 2009 01:12:06 -0500
Subject: Plan for tommorow's (20090116) FESCo meeting
In-Reply-To: <da159fda0901151716k7d6bd0eeif262d3a55dda37f1@mail.gmail.com>
References: <da159fda0901151716k7d6bd0eeif262d3a55dda37f1@mail.gmail.com>
Message-ID: <da159fda0901152212t1286118by482f00c12e3f4152@mail.gmail.com>

On Thu, Jan 15, 2009 at 8:16 PM, Jon Stanley <jonstanley at gmail.com> wrote:

> I have not yet added features to the agenda, they are on the wiki in
> the category FeaturesReadyForFesco. I will add trac tickets for them
> when I get back tonight.

I have added all the features to the agenda, it's quite a full plate
for tomorrow.

12	New Sponsor Request: Lubomir Rintel (lkundrak)
14	New Sponsor Request: Itamar Reis Peixoto
19	CUPS PolicyKit Integration
20	Debuginfo Revamp
21	ext4 default filesystem
22	Gnome 2.26
23	Live System for the DVD Image
24	Review O' Matic
25	Xfce 4.6
10	Review list of non-provenpackager committable packages
11	Review FPC report
13	FESCo needs to determine whether ovm is acceptable content
18	FPC item for approval

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.

Thanks!
-Jon



From pmatilai at laiskiainen.org  Fri Jan 16 06:34:13 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 16 Jan 2009 08:34:13 +0200 (EET)
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoobo$2km$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud> <gklo5h$9gm$1@ger.gmane.org>
	<1232037920.14403.1610.camel@rosebud> <gkoobo$2km$1@ger.gmane.org>
Message-ID: <alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>

On Fri, 16 Jan 2009, Kevin Kofler wrote:
> seth vidal wrote:
>
>> Really? Who is making the plans for soft deps. Doesn't seem like it at
>> the rpm layer.
>
> Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
> would be unfortunate, because I think they could be useful, I've seen
> several cases where they would have helped (just one example: Kile (a LaTeX
> editor) can call many tools, most users will want them dragged in, but some
> don't and Kile will still work, with reduced functionality, without them -
> just grep for Requires(hint) in packages (mostly those touched by Rex
> Dieter) to see more places where we'd like soft dependencies) and Debian
> fans keep making fun of us because we don't have them ;-).

It hasn't been dropped, only post-poned until we figure out a bunch of 
details.

 	- Panu -



From james at fedoraproject.org  Fri Jan 16 06:38:14 2009
From: james at fedoraproject.org (James Antill)
Date: Fri, 16 Jan 2009 01:38:14 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoobo$2km$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<gklo5h$9gm$1@ger.gmane.org> <1232037920.14403.1610.camel@rosebud>
	<gkoobo$2km$1@ger.gmane.org>
Message-ID: <1232087894.4934.95.camel@code.and.org>

On Fri, 2009-01-16 at 02:36 +0100, Kevin Kofler wrote:
> seth vidal wrote:
> > Which is why we can do groups of groups and more precisely break them
> > down into smaller sections. so you install what you need, not the whole
> > world.
> 
> That sounds reasonable, but I'm not sure it's going to scale. If we end up
> with one group per package, we're failing.

 Due to the fact comps won't be tied to a UI it really doesn't matter
how many groups there are, one per. source package is probably more than
is needed though.

> > I suspect most users never know what comps is and they do all their
> > discovery by doing:
> > yum search someword
> > or
> > yum list somepkgnametheyknow
> 
> You think most people don't use the GUIs?

 He's claiming, correctly, that are std. GUI packaging tool doesn't use
comps. by default and no normal user will know how to turn it on. And
further that there has been no movement to try and make it usable within
a GUI for the last couple of years, in fact quite the opposite.
 So from the GUI point of view comps doesn't exist. And browsing from
the cmd line is not done by using grouplist/groupinfo.

 So we can make the solution a lot easier by not trying to "solve" a
problem that isn't going to use the solution no matter what we do.

 And without any historical knowledge people expect "groupinstall blah"
to install a group object called "blah" that will continue to exist
after the command is run ... hence the proposed solution.

-- 
James Antill <james at fedoraproject.org>
Fedora



From fedora at leemhuis.info  Fri Jan 16 07:09:15 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 16 Jan 2009 08:09:15 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
References: <1231962712.14403.1559.camel@rosebud>
	<gklo5h$9gm$1@ger.gmane.org>	<1232037920.14403.1610.camel@rosebud>
	<gkoobo$2km$1@ger.gmane.org>
	<alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
Message-ID: <4970329B.2050904@leemhuis.info>

On 16.01.2009 07:34, Panu Matilainen wrote:
> On Fri, 16 Jan 2009, Kevin Kofler wrote:
>> seth vidal wrote:
>>
>>> Really? Who is making the plans for soft deps. Doesn't seem like it at
>>> the rpm layer.
>> Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
>> would be unfortunate, because I think they could be useful, I've seen
>> several cases where they would have helped (just one example: Kile (a LaTeX
>> editor) can call many tools, most users will want them dragged in, but some
>> don't and Kile will still work, with reduced functionality, without them -
>> just grep for Requires(hint) in packages (mostly those touched by Rex
>> Dieter) to see more places where we'd like soft dependencies) and Debian
>> fans keep making fun of us because we don't have them ;-).
> It hasn't been dropped, only post-poned until we figure out a bunch of 
> details.

I don't want to get tracked into the discussions if "Requires(hint)" and 
other soft deps make sense to support in rpm/yum or not.

But if conditionals really go away in comps it would be really nice for 
external repos like RPM Fusion to have a alternative way to 
automatically get (for example(?) ) xine-lib-extras-freeworld installed 
if the users installs (or already has installed) xine-lib.

Something like that is afaics needed to make things "just work" (?) -- 
and that's what we all want, isn't it?

CU
knurd


(?) audacious, gstreamer, qmmp, k3b and some others could benefit from 
this, too

(?) or has somebody a better idea? A yum plugin? A daemon running in the 
background?



From dwmw2 at infradead.org  Fri Jan 16 07:20:46 2009
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 16 Jan 2009 07:20:46 +0000
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
Message-ID: <1232090446.25018.8023.camel@macbook.infradead.org>

On Mon, 2009-01-12 at 16:16 -0500, Josef Bacik wrote:
> Hello,
> 
> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
> the same for F-10 and F-9 shortly. 

Can we have nfs-utils updated too, please? The one we have in F-9
predates my patches to use statfs() to obtain a fsid for exporting the
file system. Not sure about F-10, but 1.1.4 in rawhide is OK.

The failure mode is that mountd returns a root fh which the client then
immediately tries to use, the kernel passes it up to mountd to be
resolved... and mountd disavows all knowledge of it. Stupidly.

This results in either the client's mount saying 'ESTALE', or just going
into a loop trying over and over again, while the server repeatedly logs
that it has authenticated a mount attempt...

The workaround for that is to use an explicit fsid= option
in /etc/exports for btrfs file systems, but updating nfs-utils would be
better.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From pmatilai at laiskiainen.org  Fri Jan 16 07:48:37 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 16 Jan 2009 09:48:37 +0200 (EET)
Subject: comps discussion at fudcon and the future
In-Reply-To: <4970329B.2050904@leemhuis.info>
References: <1231962712.14403.1559.camel@rosebud> <gklo5h$9gm$1@ger.gmane.org>
	<1232037920.14403.1610.camel@rosebud> <gkoobo$2km$1@ger.gmane.org>
	<alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
	<4970329B.2050904@leemhuis.info>
Message-ID: <alpine.DEB.1.10.0901160926310.32512@gotcha.dreamhost.com>

On Fri, 16 Jan 2009, Thorsten Leemhuis wrote:

> On 16.01.2009 07:34, Panu Matilainen wrote:
>> On Fri, 16 Jan 2009, Kevin Kofler wrote:
>>> seth vidal wrote:
>>> 
>>>> Really? Who is making the plans for soft deps. Doesn't seem like it at
>>>> the rpm layer.
>>> Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
>>> would be unfortunate, because I think they could be useful, I've seen
>>> several cases where they would have helped (just one example: Kile (a 
>>> LaTeX
>>> editor) can call many tools, most users will want them dragged in, but 
>>> some
>>> don't and Kile will still work, with reduced functionality, without them -
>>> just grep for Requires(hint) in packages (mostly those touched by Rex
>>> Dieter) to see more places where we'd like soft dependencies) and Debian
>>> fans keep making fun of us because we don't have them ;-).
>> It hasn't been dropped, only post-poned until we figure out a bunch of 
>> details.
>
> I don't want to get tracked into the discussions if "Requires(hint)" and 
> other soft deps make sense to support in rpm/yum or not.
>
> But if conditionals really go away in comps it would be really nice for 
> external repos like RPM Fusion to have a alternative way to automatically get 
> (for example(?) ) xine-lib-extras-freeworld installed if the users installs 
> (or already has installed) xine-lib.
>
> Something like that is afaics needed to make things "just work" (?) -- and 
> that's what we all want, isn't it?

Yup, I remember sorely missing the ability to do this in "former life".

This is the "enhances" use-case, which is why it typically gets bundled up 
with soft-dependencies. Only it's got relatively little to do with the 
elasticity of a dependency, this would be a reverse dependency (whether 
it's soft or not is another issue), which is a completely new dependency 
class and the reason "enhances" is such a platypus.

 	- Panu -



From mschmidt at redhat.com  Fri Jan 16 07:51:41 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Fri, 16 Jan 2009 08:51:41 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <4970329B.2050904@leemhuis.info>
References: <1231962712.14403.1559.camel@rosebud> <gklo5h$9gm$1@ger.gmane.org>
	<1232037920.14403.1610.camel@rosebud> <gkoobo$2km$1@ger.gmane.org>
	<alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
	<4970329B.2050904@leemhuis.info>
Message-ID: <20090116085141.34a07470@hammerfall>

Dne Fri, 16 Jan 2009 08:09:15 +0100
Thorsten Leemhuis <fedora at leemhuis.info> napsal:

> I don't want to get tracked into the discussions if "Requires(hint)"
> and other soft deps make sense to support in rpm/yum or not.
> 
> But if conditionals really go away in comps it would be really nice
> for external repos like RPM Fusion to have a alternative way to 
> automatically get (for example(?) ) xine-lib-extras-freeworld
> installed if the users installs (or already has installed) xine-lib.

How about openSUSE's reverse dependencies ("Essentialfor",
"Supplements")?
http://en.opensuse.org/Software_Management/Dependencies

Michal



From rawhide at fedoraproject.org  Fri Jan 16 08:12:59 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 16 Jan 2009 08:12:59 +0000 (UTC)
Subject: rawhide report: 20090116 changes
Message-ID: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>

Compose started at Fri Jan 16 06:01:04 UTC 2009

New package gfan
        Software for Computing Gr??bner Fans and Tropical Varieties
New package nopaste
        Command-line interface to rafb.net/paste
New package ocaml-preludeml
        OCaml utility functions
New package perl-MooseX-Types-DateTime
        DateTime related constraints and coercions for Moose
New package perl-WWW-Curl
        Perl extension interface for libcurl
New package shcov
        A gcov and lcov coverage test tool for bourne shell / bash scripts
New package sugar-distance
        Distance measurement for Sugar
New package sugar-implode
        Implode for Sugar
New package wxapt
        Console application for decoding and saving weather images
New package xwxapt
        GTK+ graphical application for decoding and saving weather images
Updated Packages:

Pound-2.4.4-1.fc11
------------------
* Thu Jan 15 17:00:00 2009 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.4.4-1
- upstream released new version


afflib-3.3.4-5.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.3.4-5
- rebuild with new openssl
- call libtoolize to refresh libtool


aimage-3.2.0-2.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.2.0-2
- rebuild with new openssl


alpine-2.00-3.fc11
------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.00-3
- rebuild with new openssl

* Wed Nov 26 17:00:00 2008 Joshua Daniel Franklin <joshuadfranklin at yahoo.com> 2.00-2
- Fix package Summary text to not include package name
- http://www.redhat.com/archives/fedora-devel-list/2008-November/msg01484.html


amanda-2.6.0p2-5.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.6.0p2-5
- rebuild with new openssl


amqp-1.0.734452-1.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0:1.0.734452-1
- Rebased to svn rev 734452


apcupsd-3.14.4-3.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.14.4-3
- rebuild with new openssl


asterisk-1.6.1-0.13.beta4.fc11
------------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.6.1-0.13.beta4
- rebuild with new openssl


authd-1.4.3-22.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.4.3-22
- rebuild with new openssl


balsa-2.3.26-4.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.3.26-4
- rebuild with new openssl


bes-3.6.2-2.fc11
----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 3.6.2-2
- rebuild with new openssl


bigloo-3.1b-4.fc11
------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.1b-4
- rebuild with new openssl


bip-0.7.5-3.fc11
----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.7.5-3
- rebuild with new openssl


bitstream-vera-fonts-1.10-14.fc11
---------------------------------
* Thu Jan 15 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.10-14
??? update for new naming guidelines
??? build with new fontpackages (1.15)


blender-2.48a-11.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-11
- Rebuild for new openssl package


bro-1.4-0.3.20080804svn.fc11
----------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.4-0.3.20080804svn
- rebuild with new openssl


bunny-0.93-6.fc11
-----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.93-6
- rebuild with new openssl


cairo-dock-2.0.0-0.3.svn1485_trunk.fc11
---------------------------------------
* Fri Jan 16 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1485

* Thu Jan 15 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1484
- Trademarked icons under plug-ins/Cairo-Penguin/data/themes are
  removed.


cfengine-2.2.8-3.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.2.8-3
- rebuild with new openssl


chntpw-0.99.6-6.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.99.6-6
- rebuild with new openssl


clustermon-0.15.0-7.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.15.0-7
- rebuild with new openssl


compat-erlang-R10B-12.11.fc11
-----------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - R10B-12.11
- rebuild with new openssl


condor-7.2.0-4.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 7.2.0-4
- rebuild with new openssl


cone-0.75-2.fc11
----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.75-2
- rebuild with new openssl


conexus-0.5.98-1.fc11
---------------------
* Tue Jan  6 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.5.98-1
- New release
- Removed pcap reference from description
- Removed cstring patch - upstream fixed
- Added libcap requires
- Added gtkmm, ssl, nspr and nss subpackages
- Changed papyrus-devel to requires to papyrus-gtkmm-devel
- Added papyrus-extras-devel requires


conserver-8.1.16-6.fc11
-----------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 8.1.16-6
- rebuild with new openssl


cpqarrayd-2.3-8.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.3-8
- rebuild with new openssl


ctorrent-1.3.4-7.dnh3.2.fc11
----------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.3.4-7.dnh3.2
- rebuild with new openssl


dar-2.3.8-2.fc11
----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.3.8-2
- rebuild with new openssl


darcs-2.2.0-1.fc11
------------------
* Fri Jan 16 17:00:00 2009 Jens Petersen <petersen at redhat.com> - 2.2.0-1
- update to 2.2.0
- update install targets


dayplanner-0.9.2-1.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.9.2-1
- Updated to 0.9.2


dclib-0.3.11-5.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.3.1-5
- rebuild with new openssl


dejavu-fonts-2.28-2.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot org>
- 2.28-2
??? Update URL
??? update for new naming guidelines
??? warning: provides for the old names will be dropped before F11 beta


dhcp-4.1.0-5.fc11
-----------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 12:4.1.0-5
- rebuild with new openssl


dillo-0.8.6-8.fc11
------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.8.6-8
- rebuild with new openssl


distcache-1.4.5-18
------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.4.5-18
- rebuild with new openssl
- have to run autoreconf in the ssl subdir due to new libtool


dkim-milter-2.7.2-3.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.7.2-3
- rebuild with new openssl


dnsperf-1.0.1.0-6.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.0.1.0-6
- rebuild with new openssl
- seems to require libxml2-devel to build now


edje-0.9.9.050-3.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-3
- edje-devel now depends on inkscape

* Fri Jan 16 17:00:00 2009 Pavel "Stalwart" Shevchuk <stlwrt at gmail.com> - 0.9.9.050-2
- Include inkscape2edc


enet-1.2-1.fc11
---------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.2-1
- Updated to 1.2


epiphany-2.24.2.1-6.fc11
------------------------

fakechroot-2.8-16.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 2.8-16
- Fixed URL


fontconfig-2.6.90-3.git.63.g6bb4b9a.fc11
----------------------------------------
* Fri Jan 16 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.90-3.git.63.g6bb4b9a
- Install fc-scan and fc-query

* Fri Jan 16 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.90-2.git.63.g6bb4b9a
- Update to 2.6.90-1.git.63.g6bb4b9a
- Remove upstreamed patch


fontpackages-1.15-1.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.15-1
??? lua-ize the main macro


foomatic-4.0.0-1.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 4.0.0-1
- 4.0.0.


freetype-2.3.8-1.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> 2.3.8-1
- Update to 2.3.8
- Remove freetype-autohinter-ligature.patch


gflags-1.0-1.fc11
-----------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 1.0-1
- Updated to 1.0.


ginac-1.4.4-1.fc11
------------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.4.4-1
- Updated to 1.4.4


gnotime-2.3.0-2.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.3.0-2
- Fixed Description column text, BZ 480087.


gridengine-6.2u1-2.fc11
-----------------------
* Thu Jan 15 17:00:00 2009 - Orion Poplawski <orion at cora.nwra.com> - 6.2u1-2
- Rebuild with openssl-0.9.8j


gucharmap-2.24.3-1.fc11
-----------------------
* Thu Jan 15 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.24.3-1
- Update to 2.24.3


highlight-2.7-1.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 2.7-1
- New upstream release

* Mon Nov  3 17:00:00 2008 Jochen Schmitt <Jochen herr-schmitt de> 2.6.14-1
- New upstream release


ipsec-tools-0.7.1-7.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.7.1-7
- rebuild with new openssl


jbrout-0.3.159-1.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Mat??j Cepl <mcepl at redhat.com> 0.3.159-1
- New upstream release and this should go to Fedora.

* Sun Jan 11 17:00:00 2009 Mat??j Cepl <mcepl at redhat.com> 0.3.151-0.5
- Fixed building and installing lang files.

* Thu Jan  1 17:00:00 2009 Mat??j Cepl <mcepl at redhat.com> 0.3.131-0.1.f10only
- Testing build of the new upstream release (because of broken upgrade
  build).


kdebindings-4.1.96-4.fc11
-------------------------
* Thu Jan 15 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.1.96-4
- update %description/%summaries for new (sub)pkgs
- use versioned Provides/Requires all over
- BR: akonadi-devel kdegraphics-devel
- don't package kde-plasma-ruby-* (cmake error "rbuic4 not found")

* Thu Jan 15 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 4.1.96-3
- Fixed QtRuby version
- Moved QtRuby tools to QtRuby-devel

* Wed Jan 14 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 4.1.96-2
- Split out Ruby bindings and Kross modules


kernel-2.6.29-0.38.rc1.git4.fc11
--------------------------------
* Thu Jan 15 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- New version of module_ref patch, uses per_cpu instead.
- Fix linux-2.6-hdpvr.patch up and re-enable.
    Nuke .flush, was useless, convert to v4l2_file_operations, fix ioctl ret
- Fix linux-2.6-debug-taint-vm.patch and re-enable.

* Wed Jan 14 17:00:00 2009 Dave Jones <davej at redhat.com>
- Test RODATA and NX during bootup.


kvm-83-1.fc11
-------------
* Thu Jan 15 17:00:00 2009 Mark McLoughlin <markmc at redhat.com> - 83-1
- Update to kvm-83
- Change how we delete pre-built blobs now that qemu/pc-bios has
  patch queue dirs; add a check to make sure we've zapped them all


libewf-20080501-5.fc11
----------------------
* Thu Jan 15 17:00:00 2009 kwizart < kwizart at gmail.com > - 20080501-5
- Update mount_ewf to 20090113


libiec61883-1.2.0-1.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Jarod Wilson <jarod at redhat.com> 1.2.0-1
- Update to libiec61883 v1.2.0 release
- Rework installtests patch to not require autoreconf
- Make iso channel allocation work w/o local fw node r/w


libraw1394-2.0.1-1.fc11
-----------------------
* Thu Jan 15 17:00:00 2009 Jarod Wilson <jarod at redhat.com> - 2.0.1-1
- Update to libraw1394 v2.0.1 release


libsemanage-2.0.31-2.fc11
-------------------------
* Thu Jan 15 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.0.31-2
- Fix link to only link on sandbox


libuninameslist-20080409-1.fc11
-------------------------------
* Thu Jan 15 17:00:00 2009 Roozbeh Pournader <roozbeh at gmail.com> - 20080409-1
- Update to upstream 20080409: Unicode 5.1 support
- Change package versioning scheme
- Update summary and description
- Add DistTag
- Remove copy of GPL from RPM: the only file it applies to is not shipped


libvirt-cim-0.5.3-1.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Kaitlin Rupert <kaitlin at us.ibm.com> - 0.5.3-1
- Updated to latest upstream source


libxml++-2.24.2-1.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 2.24.2-1
- Update to 2.24.2 (memleak fixes)
- Fixed Gnome FTP URL


linuxwacom-0.8.2.1-1.fc11
-------------------------
* Thu Jan 15 17:00:00 2009 Aristeu Rozanski <aris at redhat.com> 0.8.1.2-1
- new production release


liveusb-creator-3.3-1.fc11
--------------------------
* Thu Jan 15 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.3-1
- Update to 3.3


nebula-0.2.3-1.fc11
-------------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.2.3-6
- Updated to 0.2.3


netatalk-2.0.3-22.fc11
----------------------
* Wed Dec  3 17:00:00 2008 Jiri Skala <jskala at redhat.com> -4:2.0.3-22
- fix #473939 netatalk-2.0.3-21.fc10 disable quota


ocaml-ssl-0.4.3-1.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 0.4.3-1
- New upstream version 0.4.3.
- Force rebuild against new OpenSSL 0.9.8j.


ochusha-0.6.0.1-0.2.cvs20090106T1430.fc11.1
-------------------------------------------
* Thu Jan 15 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- F-11: rebuild against new openssl


opensc-0.11.6-2.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.11.6-2
- Add explicit requires for pcsc-lite-libs. Dlopen libpcsclite with the full
  soname.


openssh-5.1p1-5.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.1p1-5
- remove obsolete --with-rsh (#478298)
- add pam_sepermit to allow blocking confined users in permissive mode
  (#471746)
- move system-auth after pam_selinux in the session stack


openssl-0.9.8j-1.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8j-1
- new upstream version with necessary soname bump (#455753)
- temporarily provide symlink to old soname to make it possible to rebuild
  the dependent packages in rawhide
- add eap-fast support (#428181)
- add possibility to disable zlib by setting 
- add fips mode support for testing purposes
- do not null dereference on some invalid smime files
- add buildrequires pkgconfig (#479493)


papyrus-0.8.1-1.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Rick L Vinyard Jr <rvinyard at cs.nmsu.edu> - 0.8.1-1
- New release fixes pkgconfig files


physfs-1.0.1-9.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.1-9
- do not package the tex docs, the html docs are fine
- drop static lib to see if anyone misses it


pyOpenSSL-0.7-4.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 0.7-4
- rebuild against now openssl


python-durus-3.8-1.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 3.8-1
- Updated to 3.8


python-qpid-0.4.734452-1.fc11
-----------------------------
* Wed Jan 14 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.734452-1
- Rebased to svn rev 734452
- BZ 478467: include examples


qpidc-0.4.734452-1.fc11
-----------------------
* Thu Jan 15 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.734452-1
- Rebased to svn rev 734452


rhm-0.4.3045-1.fc11
-------------------
* Thu Jan 15 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.3045-1
- Rebased to svn rev 3045/734452


ruby-qpid-0.4.734452-1.fc11
---------------------------
* Wed Jan 14 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.734452-1
- Rebased to svn rev 734452


silkscreen-fonts-1.0-2.fc11
---------------------------
* Thu Jan 15 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.0-2
- rework package for new font guidelines


suck-4.3.2-24.fc11
------------------
* Thu Jan 15 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 4.3.2-24
- Rebuild for new openssl package


suitesparse-3.2.0-5.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Deji Akingunola <dakingun at gmail.com> - 3.2.0-5
- More fixes for the undefined symbol issue (BZ #475411)


system-config-printer-1.1.2-1.fc11
----------------------------------
* Thu Jan 15 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 1.1.2-1
- 1.1.2.
- Requires gnome-python2-gnomekeyring.


tftp-0.49-2.fc11
----------------
* Thu Jan 15 17:00:00 2009 Jiri Skala <jskala at redhat.com> - 0.49-2
- #473487 - unchecked return values


tiresias-fonts-1.0-3.fc11
-------------------------
* Thu Jan 15 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.0-3
- rework to meet new font packaging guidelines


trac-xmlrpc-plugin-1.0.0-0.1.r3074.fc11
---------------------------------------
* Thu Jan 15 17:00:00 2009 Sergio Pascual <sergio.pasra at gmail.com> - 1.0.0-0.1.r3074
- Source code from vcs, rebased to trunk for trac 0.11 (bz #480101)


Summary:
Added Packages: 10
Removed Packages: 0
Modified Packages: 88
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	egoboo-2.7.5-4.fc9.i386 requires libenet-1.1.so
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	ginac-devel-1.4.4-1.fc11.i386 requires pkgconfig(cln) >= 0:1.1.6
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-3.fc11.i386 requires bitstream-vera-fonts-sans
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	neverball-1.4.0-13.fc11.i386 requires bitstream-vera-fonts-sans
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-serif
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans-mono
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-sans
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	egoboo-2.7.5-4.fc9.x86_64 requires libenet-1.1.so()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	ginac-devel-1.4.4-1.fc11.i386 requires pkgconfig(cln) >= 0:1.1.6
	ginac-devel-1.4.4-1.fc11.x86_64 requires pkgconfig(cln) >= 0:1.1.6
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-3.fc11.x86_64 requires bitstream-vera-fonts-sans
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	neverball-1.4.0-13.fc11.x86_64 requires bitstream-vera-fonts-sans
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-serif
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans-mono
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.i386 requires dejavu-fonts-lgc-sans
	rrdtool-1.3.4-5.fc11.x86_64 requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.x86_64 requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.x86_64 requires dejavu-fonts-lgc-sans
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	egoboo-2.7.5-4.fc9.ppc requires libenet-1.1.so
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	ginac-devel-1.4.4-1.fc11.ppc requires pkgconfig(cln) >= 0:1.1.6
	ginac-devel-1.4.4-1.fc11.ppc64 requires pkgconfig(cln) >= 0:1.1.6
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-3.fc11.ppc requires bitstream-vera-fonts-sans
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	neverball-1.4.0-13.fc11.ppc requires bitstream-vera-fonts-sans
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-serif
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans-mono
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans
	rrdtool-1.3.4-5.fc11.ppc requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.ppc requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.ppc requires dejavu-fonts-lgc-sans
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-sans
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	egoboo-2.7.5-4.fc9.ppc64 requires libenet-1.1.so()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	ginac-devel-1.4.4-1.fc11.ppc64 requires pkgconfig(cln) >= 0:1.1.6
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapserver-5.2.1-3.fc11.ppc64 requires bitstream-vera-fonts-sans
	netbeans-java2-6.1-10.fc11.noarch requires netbeans-javaparser = 0:6.1
	neverball-1.4.0-13.fc11.ppc64 requires bitstream-vera-fonts-sans
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-serif
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans-mono
	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-sans-mono
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-serif
	rrdtool-1.3.4-5.fc11.ppc64 requires dejavu-fonts-lgc-sans
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From yersinia.spiros at gmail.com  Fri Jan 16 08:33:09 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Fri, 16 Jan 2009 09:33:09 +0100
Subject: Lua module packages are not multi-lib, how to do?
In-Reply-To: <1232064840.5086.136.camel@localhost.localdomain>
References: <496D9359.5090000@niemueller.de>
	<1231919919.12251.141.camel@ignacio.lan>
	<b086760e0901140400j2b260046l722b293191750308@mail.gmail.com>
	<1231943326.5086.49.camel@localhost.localdomain>
	<b086760e0901150529j405da58es1b4254f3c58ff82d@mail.gmail.com>
	<1232064840.5086.136.camel@localhost.localdomain>
Message-ID: <b086760e0901160033m6ef0be49r8762824b25559bb4@mail.gmail.com>

2009/1/16 Jesse Keating <jkeating at redhat.com>

> On Thu, 2009-01-15 at 14:29 +0100, devzero2000 wrote:
> > it is very boring not also have the 32 - bit version of httpd on 64 bit
> SO.
> > Often it is required the installation commercial 32 bit apache modules -
> i
> > am speaking of RHEL . But certainly install an 32 bit operating system on
> > machines with 10 g of RAM - that i have - is not a thing magnificent.
> Then
> > it would be useful to install on a 64  bit SO AND an 32 bit Apache  but
> the
> > repo (or RHN) default don't have. Sure, i can do anyway on RHEL5.
> >
> > (Aside) On Fedora 10 64  bit i have also enabled the repo 32 but
> strangely
> > enough, i have an error of conflict (on RHEL5 it is ok) . But that is
>  off
> > topic, perhaps.
> >
> > yum install httpd.i386
> >
> > Transaction Check Error:
> >   file /etc/httpd/modules from install of httpd-2.2.10-2.i386 conflicts
> with
> > file from package httpd-2.2.10-2.x86_64
> >
> > The same with squid.
> >
> > It is also true with %_transaction_color     3 in /etc/rpm/macros.color
>
> The base package can't be multilib, as the paths aren't unique.  You can
> only have one /usr/sbin/httpd and which arch wins if you try to install
> both?  You won't be able to run both a 64bit httpd instance and a 32bit
> httpd instance.
>
> You can do chroots or virt images in order to serve up your 32bit needs
> though.
>

Of course. What i have said is certainly incorrect. Too many mail........

Thanks for the reply.


>
> --
> Jesse Keating
> Fedora -- Freedom? is a feature!
> identi.ca: http://identi.ca/jkeating
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/dffb8c0e/attachment.htm>

From ffesti at redhat.com  Fri Jan 16 09:19:15 2009
From: ffesti at redhat.com (Florian Festi)
Date: Fri, 16 Jan 2009 10:19:15 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoak3$qhf$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
	<gkoak3$qhf$1@ger.gmane.org>
Message-ID: <49705113.4080203@redhat.com>

Matthew Woehlke wrote:
> Florian Festi wrote:
>> Multilib:
>> The situation has changed a lot since we introduced multilib. The 
>> challenge
>> who is going to support 64bit processors first has been decided long 
>> ago and the age of 32bit processors is ending.
> 
> No it isn't. I doubt very much that use of 32-bit processors is going 
> away any time soon. (In "traditional desktops", maybe, but not embedded 
> devices. Perhaps even in devices Fedora is interested in supporting, but 
> that I'm not so sure about. It will depend heavily on a: if netbooks 
> universally switch to 64-bit CPU's, and b: if Fedora decides to support 
> other sorts of MID's, e.g. "phones". Yes, I know, at the point Fedora is 
> running on such a device it will be "an MID that happens to be able to 
> make phone calls", but we're already at that stage.)
> 
> And I hear plenty of embedded devices still use *16*-bit CPU's...

Ok, I should probably a bit more precise: 32 bit being default on 64 bit 
capable computers is coming to an end as the default RAM size for desktops 
goes beyond 4GB. Real 32 bit or even 16 bit processors are completely 
unaffected by any multilib considerations anyway.

>> There are several annoying features
>> of the solution that was chosen at the time (overwriting 32 bit binaries,
>> install lots of files twice) and we should get rid of them at some 
>> point in
>> the (not too near) future. But this may require some other changes 
>> first...
> 
> Other than perhaps binutils, why would you ever have a 32-bit binary on 
> a 64-bit system? ;-) Or do you include libs in "binaries"?

There are several reasons to do so: Third party software that is not build
for 64 bit, software like firefox that uses plugins that are only available
in 32 bit, building software or content for 32 bit and may be some more.

When multilib was introduced 64 bit (x86) processors were new, shiny, 
expensive and
surrounded by 32 bit machines. So chances that you had to deal with 32 bit
software were very high at that time.

> As for the rest, IMO as long as gcc supports -m32, it should stay. The 
> project I work on for my day job would have to completely scrap our 
> build system and break what is currently a one-package multilib 
> distribution into two separate platforms, if multilib went away.

Multilib is not going to go away in the sense that you still will be able to 
32 bit software on a 64 bit installation. But it already got away in the 
sense that we do no longer install 32 bit libs by default. There is still 
some painful implementation details that I hope we can fix in a medium time 
frame.

Florian



From rakesh.pandit at gmail.com  Fri Jan 16 10:11:31 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Fri, 16 Jan 2009 15:41:31 +0530
Subject: rawhide report: 20090116 changes
In-Reply-To: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
Message-ID: <b401d2530901160211n5362bf8eu79f0a85cc380c7b0@mail.gmail.com>

2009/1/16 Rawhide Report <rawhide at fedoraproject.org>:
> ginac-1.4.4-1.fc11
> ------------------
> * Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.4.4-1
> - Updated to 1.4.4
>
[..]
>        ginac-devel-1.4.4-1.fc11.i386 requires pkgconfig(cln) >= 0:1.1.6
>

Bumped cln so as dependencies are solved. It worked on my local
rawhide instance, hopefully it is solved now.

-- 
Regards,
Rakesh Pandit



From debarshi.ray at gmail.com  Fri Jan 16 10:19:14 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 16 Jan 2009 15:49:14 +0530
Subject: rawhide report: 20090116 changes
In-Reply-To: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
Message-ID: <3170f42f0901160219i51857e04uf4da6d9c62905d75@mail.gmail.com>

>        httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
> [...]
>        httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
>        httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
> [...]
>        httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
>        httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
> [...]
>        httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g

I know about this and will fix it with the upcoming version update [1].

Cheers,
Debarshi

----
[1] https://bugzilla.redhat.com/464483



From peter.hutterer at who-t.net  Fri Jan 16 10:24:26 2009
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Fri, 16 Jan 2009 20:24:26 +1000
Subject: Keyboard shortcut buttons logs out of Gnome/X
In-Reply-To: <1231952196.4947.6.camel@scrappy.miketc.net>
References: <1231952196.4947.6.camel@scrappy.miketc.net>
Message-ID: <20090116102426.GA7105@who-t.net>

On Wed, Jan 14, 2009 at 10:56:36AM -0600, Mike Chambers wrote:
> I have a Microsoft Wireless Desktop keyboard/mouse 2000.  And in F10 the
> keyboard shortcuts (buttons to start email, browser, volume adjustments,
> etc..) work just fine.
> 
> In Rawhide, if I hit one of them, it logs me out of Gnome/X and back to
> the login screen.  I tried setting the keyboard to the MS Wireless
> Multimedia keyboard 1A but that doesn't help.  Not sure it matters what
> I select.  Any ideas  and what component would I file a bug against if I
> need to?

xorg-x11-server. Check your /var/log/Xorg.0.log.old after such an incident
occured, it'll probably have an error towards the end reporting a crash.

Please open a bug for that and attach the log file, your xorg.conf (if you
have one) and also tell us which button actually makes the server unhappy.

Cheers,
  Peter



From kevin.kofler at chello.at  Fri Jan 16 10:32:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 11:32:44 +0100
Subject: Heads up openssl-0.9.8j in rawhide
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <gkpnoc$f8k$1@ger.gmane.org>

Tomas Mraz wrote:
> kdebase3
> kdelibs
> kdenetwork
> qt
> redland
> xchat

I submitted rebuilds for all these.

        Kevin Kofler



From denis at poolshark.org  Fri Jan 16 10:47:44 2009
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 16 Jan 2009 11:47:44 +0100
Subject: The move to libgda 4.0
Message-ID: <497065D0.5090506@poolshark.org>

I've been investigating the move to libgda 3.99.8 (4.0 API) for Fedora 
11. The 4.0 API is apparently stable now, and based on the F-11 release 
timeframe, upstream does recommend it. There's also a growing number of 
projects working with the 4.0 API already and I've received a request 
for this for an Anjuta plugin 
(https://bugzilla.redhat.com/show_bug.cgi?id=479298).

There are currently 4 packages that depend on the 3.0 API: glom, 
gnome-python2-extras, qof and gnumeric-plugins-extras. The port to 4.0 
appears to be non-trivial 
(http://library.gnome.org/devel/libgda-4.0/3.99/migration-2.html). We 
can probably work out a patch for something like the gnumeric plugin, 
but I don't know how much work would be required to port 
gnome-python2-extras for example. Glom still uses the 3.0 API, but the 
4.0 port is almost finished in SVN.

2 options here:

1. Wait for glom to release its 4.0 API port, ping upstream for other 
dependencies or work on patches. Not yet clear how much work is required 
for this.

2. Revive the compat-libgda package (currently a dead.package, we used 
to have it for the 2.0 API when 2.99 was packaged) for the 3.0 API and 
move libgda to 3.99. Would this require a new package review ?

I'm strongly leaning toward 2, mostly because of the uncertainty of 
option 1 plus the fact it will hold up other updates waiting for the 4.0 
API and delay 4.0 API testing.



From hughsient at gmail.com  Fri Jan 16 10:55:26 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Jan 2009 10:55:26 +0000
Subject: PackageKit translations
Message-ID: <1232103326.20781.21.camel@hughsie-work.lan>

In a couple of weeks time they'll be a new PackageKit release that we'll
see in F11.

Before that time, I would like the translations for PackageKit to be
updated -- updated translations are very important for the F11 release
quality and also for the F10 backport. There are still quite a few
important languages missing and others that are quite incomplete.

You can see the current stats here:

http://translate.fedoraproject.org/module/packagekit#master

If there are any difficult to translate strings, or any that need more
context, please email the packagekit mailing list and we'll fix them up
as quickly as possible.

Thanks, and keep rocking,

Richard.





From ankit at redhat.com  Fri Jan 16 11:03:47 2009
From: ankit at redhat.com (Ankitkumar Rameshchandra Patel)
Date: Fri, 16 Jan 2009 16:33:47 +0530
Subject: PackageKit translations
In-Reply-To: <1232103326.20781.21.camel@hughsie-work.lan>
References: <1232103326.20781.21.camel@hughsie-work.lan>
Message-ID: <49706993.9050905@redhat.com>

Richard Hughes wrote:
> In a couple of weeks time they'll be a new PackageKit release that we'll
> see in F11.
>
>   
Adding fedora trans list at redhat dot com in the recipients.
> Before that time, I would like the translations for PackageKit to be
> updated -- updated translations are very important for the F11 release
> quality and also for the F10 backport. There are still quite a few
> important languages missing and others that are quite incomplete.
>
>   
What are those important languages? Please be specific.
> You can see the current stats here:
>
> http://translate.fedoraproject.org/module/packagekit#master
>
> If there are any difficult to translate strings, or any that need more
> context, please email the packagekit mailing list and we'll fix them up
> as quickly as possible.
>
> Thanks, and keep rocking,
>
> Richard.
>   
Thanks,

-- 
Regards,
Ankit Patel
http://www.indianoss.org/



From j.w.r.degoede at hhs.nl  Fri Jan 16 11:03:44 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 16 Jan 2009 12:03:44 +0100
Subject: The move to libgda 4.0
In-Reply-To: <497065D0.5090506@poolshark.org>
References: <497065D0.5090506@poolshark.org>
Message-ID: <49706990.1020200@hhs.nl>

Denis Leroy wrote:
> I've been investigating the move to libgda 3.99.8 (4.0 API) for Fedora 
> 11. The 4.0 API is apparently stable now, and based on the F-11 release 
> timeframe, upstream does recommend it. There's also a growing number of 
> projects working with the 4.0 API already and I've received a request 
> for this for an Anjuta plugin 
> (https://bugzilla.redhat.com/show_bug.cgi?id=479298).
> 
> There are currently 4 packages that depend on the 3.0 API: glom, 
> gnome-python2-extras, qof and gnumeric-plugins-extras. The port to 4.0 
> appears to be non-trivial 
> (http://library.gnome.org/devel/libgda-4.0/3.99/migration-2.html). We 
> can probably work out a patch for something like the gnumeric plugin, 
> but I don't know how much work would be required to port 
> gnome-python2-extras for example. Glom still uses the 3.0 API, but the 
> 4.0 port is almost finished in SVN.
> 
> 2 options here:
> 
> 1. Wait for glom to release its 4.0 API port, ping upstream for other 
> dependencies or work on patches. Not yet clear how much work is required 
> for this.
> 
> 2. Revive the compat-libgda package (currently a dead.package, we used 
> to have it for the 2.0 API when 2.99 was packaged) for the 3.0 API and 
> move libgda to 3.99. Would this require a new package review ?
> 

Depends on if there is more then just a name change. Are libgda3 and libgda4 
parallel installable (including their -devel) without requiring any hacks to 
libgda3 ? (We do not want to hack libgda4, as then we would need to carry those 
hacks for a potential long time).

If its just a rename a review is not needed IMHO.

> I'm strongly leaning toward 2, mostly because of the uncertainty of 
> option 1 plus the fact it will hold up other updates waiting for the 4.0 
> API and delay 4.0 API testing.
> 

+1 for option 2

Regards,

Hans



From hughsient at gmail.com  Fri Jan 16 11:27:33 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Jan 2009 11:27:33 +0000
Subject: PackageKit translations
In-Reply-To: <49706993.9050905@redhat.com>
References: <1232103326.20781.21.camel@hughsie-work.lan>
	<49706993.9050905@redhat.com>
Message-ID: <1232105253.20781.36.camel@hughsie-work.lan>

On Fri, 2009-01-16 at 16:33 +0530, Ankitkumar Rameshchandra Patel wrote:
> Richard Hughes wrote:
> > In a couple of weeks time they'll be a new PackageKit release that we'll
> > see in F11.
> >
> Adding fedora trans list at redhat dot com in the recipients.

Cool, thanks.

> What are those important languages? Please be specific.

Well, for me (personally) I guess, German, French, Spanish, Greek,
Italian and of course British English. There are a lot of untranslated
strings in other languages too. I want to make sure that PackageKit is
easy to translate in all languages, as I guess they are all pretty
important.

Richard.




From wolfy at nobugconsulting.ro  Fri Jan 16 11:41:48 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Fri, 16 Jan 2009 13:41:48 +0200
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <4970727C.2030208@nobugconsulting.ro>

Tomas Mraz wrote:
> pam_mysql
> pam_ssh
> ssmtp
>   

I submitted rebuilds for these.

	wolfy



From benjavalero at gmail.com  Fri Jan 16 11:55:07 2009
From: benjavalero at gmail.com (=?UTF-8?Q?Benjam=C3=ADn_Valero_Espinosa?=)
Date: Fri, 16 Jan 2009 12:55:07 +0100
Subject: PackageKit translations
In-Reply-To: <1232103326.20781.21.camel@hughsie-work.lan>
References: <1232103326.20781.21.camel@hughsie-work.lan>
Message-ID: <a7804a540901160355j3796ec4dx7d8f79b13aa9cd82@mail.gmail.com>

2009/1/16 Richard Hughes

> In a couple of weeks time they'll be a new PackageKit release that we'll
> see in F11.
>
> Before that time, I would like the translations for PackageKit to be
> updated -- updated translations are very important for the F11 release
> quality and also for the F10 backport. There are still quite a few
> important languages missing and others that are quite incomplete.
>
> You can see the current stats here:
>
> http://translate.fedoraproject.org/module/packagekit#master
>

Well, at least for Spanish the stats in this link differs from those from
Damned Lies:

http://l10n.gnome.org/module/gnome-packagekit/
http://l10n.gnome.org/module/packagekit/

Anyway, I will tell the Spanish translator to hurry :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/59540093/attachment.htm>

From happyharrysco1 at yahoo.co.uk  Fri Jan 16 12:06:32 2009
From: happyharrysco1 at yahoo.co.uk (phil smith)
Date: Fri, 16 Jan 2009 12:06:32 +0000
Subject: PackageKit translations
In-Reply-To: <1232105253.20781.36.camel@hughsie-work.lan>
References: <1232103326.20781.21.camel@hughsie-work.lan>	<49706993.9050905@redhat.com>
	<1232105253.20781.36.camel@hughsie-work.lan>
Message-ID: <49707848.1060006@yahoo.co.uk>

Richard Hughes wrote:
> On Fri, 2009-01-16 at 16:33 +0530, Ankitkumar Rameshchandra Patel wrote:
>   
>> Richard Hughes wrote:
>>     
>>> In a couple of weeks time they'll be a new PackageKit release that we'll
>>> see in F11.
>>>
>>>       
>> Adding fedora trans list at redhat dot com in the recipients.
>>     
>
> Cool, thanks.
>
>   
>> What are those important languages? Please be specific.
>>     
>
> Well, for me (personally) I guess, German, French, Spanish, Greek,
> Italian and of course British English. There are a lot of untranslated
> strings in other languages too. I want to make sure that PackageKit is
> easy to translate in all languages, as I guess they are all pretty
> important.
>
> Richard.
>
>
>   
somehow i don't think the british english translation is needed, we can 
read mis-spelled words over here in blighty you know lol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/fb176642/attachment.htm>

From hughsient at gmail.com  Fri Jan 16 12:12:26 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Jan 2009 12:12:26 +0000
Subject: PackageKit translations
In-Reply-To: <a7804a540901160355j3796ec4dx7d8f79b13aa9cd82@mail.gmail.com>
References: <1232103326.20781.21.camel@hughsie-work.lan>
	<a7804a540901160355j3796ec4dx7d8f79b13aa9cd82@mail.gmail.com>
Message-ID: <1232107946.20781.48.camel@hughsie-work.lan>

On Fri, 2009-01-16 at 12:55 +0100, Benjam?n Valero Espinosa wrote:
> Well, at least for Spanish the stats in this link differs from those
> from Damned Lies:
> 
> http://l10n.gnome.org/module/gnome-packagekit/
> http://l10n.gnome.org/module/packagekit/
> 
> Anyway, I will tell the Spanish translator to hurry :D

I didn't know the PK translations were tracked in gnome. Good to know.
Thanks.

Richard.




From hughsient at gmail.com  Fri Jan 16 12:14:30 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Jan 2009 12:14:30 +0000
Subject: PackageKit translations
In-Reply-To: <49707848.1060006@yahoo.co.uk>
References: <1232103326.20781.21.camel@hughsie-work.lan>
	<49706993.9050905@redhat.com>
	<1232105253.20781.36.camel@hughsie-work.lan>
	<49707848.1060006@yahoo.co.uk>
Message-ID: <1232108070.20781.53.camel@hughsie-work.lan>

On Fri, 2009-01-16 at 12:06 +0000, phil smith wrote:
> somehow i don't think the british english translation is needed, we
> can read mis-spelled words over here in blighty you know lol

As a resident of London (UK), I disagree. It really sucks when you see
works like color, honor and other words like that when in en_GB. I
understand most of the C- > en_GB translations are scripted, which
probably just needs to be setup somehow.

Richard.




From aph at redhat.com  Fri Jan 16 12:20:28 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 16 Jan 2009 12:20:28 +0000
Subject: PackageKit translations
In-Reply-To: <49707848.1060006@yahoo.co.uk>
References: <1232103326.20781.21.camel@hughsie-work.lan>	<49706993.9050905@redhat.com>	<1232105253.20781.36.camel@hughsie-work.lan>
	<49707848.1060006@yahoo.co.uk>
Message-ID: <49707B8C.5060604@redhat.com>

phil smith wrote:
> Richard Hughes wrote:
>> On Fri, 2009-01-16 at 16:33 +0530, Ankitkumar Rameshchandra Patel wrote:
>>  
>>> What are those important languages? Please be specific.
>>>     
>>
>> Well, for me (personally) I guess, German, French, Spanish, Greek,
>> Italian and of course British English. There are a lot of untranslated
>> strings in other languages too. I want to make sure that PackageKit is
>> easy to translate in all languages, as I guess they are all pretty
>> important.

> somehow i don't think the british english translation is needed, we can
> read mis-spelled words over here in blighty you know lol

I agree.  Also, translating from American to British English is IME
very difficult to do, so it's not always successful.  Of course there
are trivial spelling differences but these don't cause confusion.  The
worst possible situation occurs with automatic spelling changes (so
you are misled into thinking that the article is in British English)
but American usage.

Andrew.



From vonbrand at inf.utfsm.cl  Fri Jan 16 12:28:08 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 09:28:08 -0300
Subject: Massive fallout from missing libssl.so.7 et al
Message-ID: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>

It seems many packages don't include the Requires needed to use OpenSSL. I
just updated, and now git doesn't work:

  $ /usr/bin/git
  /usr/bin/git: error while loading shared libraries: libcrypto.so.7: cannot open shared object file: No such file or directory

Trying to build assorted stuff:

  make: *** Waiting for unfinished jobs....
  /usr/bin/ld: warning: libssl.so.7, needed by /usr/lib64/libssh2.so.1, not found (try using -rpath or -rpath-link)
  /usr/bin/ld: warning: libcrypto.so.7, needed by /usr/lib64/libssh2.so.1, not found (try using -rpath or -rpath-link)
-- 
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 bnocera at redhat.com  Thu Jan 15 22:19:36 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Thu, 15 Jan 2009 22:19:36 +0000
Subject: Keyboard shortcut buttons logs out of Gnome/X
In-Reply-To: <385866f0901151340q591883d7r826654adc2ef6aff@mail.gmail.com>
References: <1231952196.4947.6.camel@scrappy.miketc.net>
	<1232017338.13084.0.camel@snoogens.fab.redhat.com>
	<385866f0901151340q591883d7r826654adc2ef6aff@mail.gmail.com>
Message-ID: <1232057976.16333.7.camel@snoogens.fab.redhat.com>

On Thu, 2009-01-15 at 23:40 +0200, Muayyad AlSadi wrote:
> > I select.  Any ideas  and what component would I file a bug against
> my guess is hal, because my Xlog says
> 
> (II) config/hal: Adding input device AT Translated Set 2 keyboard
> (II) LoadModule: "evdev"

What would that have to do with anything? The X server uses HAL to find
the input devices. That's it.



From fedora at camperquake.de  Fri Jan 16 12:32:05 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 16 Jan 2009 13:32:05 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
Message-ID: <20090116133205.670448ce@dhcp03.addix.net>

Hi.

On Fri, 16 Jan 2009 09:28:08 -0300, Horst H. von Brand wrote:

>   /usr/bin/git: error while loading shared libraries: libcrypto.so.7:
> cannot open shared object file: No such file or directory

The problem is that the openssl package was supposed to contain symlinks for
libssl.so.7 and libcryoto.so.7, and rpm -ql says that the package does contain
them, but they are, in fact, missing from the filesystem.



From tmraz at redhat.com  Fri Jan 16 12:46:25 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 16 Jan 2009 13:46:25 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <20090116133205.670448ce@dhcp03.addix.net>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
Message-ID: <1232109985.5215.93.camel@vespa.frost.loc>

On Fri, 2009-01-16 at 13:32 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 16 Jan 2009 09:28:08 -0300, Horst H. von Brand wrote:
> 
> >   /usr/bin/git: error while loading shared libraries: libcrypto.so.7:
> > cannot open shared object file: No such file or directory
> 
> The problem is that the openssl package was supposed to contain symlinks for
> libssl.so.7 and libcryoto.so.7, and rpm -ql says that the package does contain
> them, but they are, in fact, missing from the filesystem.

I have tested it, but apparently the hack doesn't work in 100% cases.
The ldconfig probably removes the symlinks in some cases.  :(

I call ldconfig -X in the %post of openssl which should update the cache
and not remove the symlinks. Any subsequent calls to ldconfig should not
remove the symlinks - at least they do not on the system where I tested
that. So there must be someting else in play.

For example in the mock builds the symlinks work otherwise many of the
rebuilds which I've already done would fail.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From fedora at camperquake.de  Fri Jan 16 12:51:50 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 16 Jan 2009 13:51:50 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <1232109985.5215.93.camel@vespa.frost.loc>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
Message-ID: <20090116135150.3a8f4d99@dhcp03.addix.net>

Hi.

On Fri, 16 Jan 2009 13:46:25 +0100, Tomas Mraz wrote:

> I call ldconfig -X in the %post of openssl which should update the
> cache and not remove the symlinks. Any subsequent calls to ldconfig
> should not remove the symlinks - at least they do not on the system
> where I tested that. So there must be someting else in play.

I manually created the two symlinks, and subsequent calls to ldconfig
do not remove them, either.



From SteveD at redhat.com  Fri Jan 16 12:52:35 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Fri, 16 Jan 2009 07:52:35 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <1232090446.25018.8023.camel@macbook.infradead.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<1232090446.25018.8023.camel@macbook.infradead.org>
Message-ID: <49708313.5000209@RedHat.com>



David Woodhouse wrote:
> On Mon, 2009-01-12 at 16:16 -0500, Josef Bacik wrote:
>> Hello,
>>
>> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
>> the same for F-10 and F-9 shortly. 
> 
> Can we have nfs-utils updated too, please? The one we have in F-9
> predates my patches to use statfs() to obtain a fsid for exporting the
> file system. Not sure about F-10, but 1.1.4 in rawhide is OK.

Just to be clear... you are wanting one of or all of the following patch 
back ported to F9?

    Stop exportfs warning about needing fsid, when we actually have one
    Use fsid from statfs for UUID if blkid can't cope (or not used)
    Explicit UUID handling doesn't require blkid; factor out get_uuid_blkdev()
    Fix handling of explicit uuid

steved
 



From tmraz at redhat.com  Fri Jan 16 13:04:59 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Fri, 16 Jan 2009 14:04:59 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <20090116135150.3a8f4d99@dhcp03.addix.net>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
Message-ID: <1232111099.5215.96.camel@vespa.frost.loc>

On Fri, 2009-01-16 at 13:51 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 16 Jan 2009 13:46:25 +0100, Tomas Mraz wrote:
> 
> > I call ldconfig -X in the %post of openssl which should update the
> > cache and not remove the symlinks. Any subsequent calls to ldconfig
> > should not remove the symlinks - at least they do not on the system
> > where I tested that. So there must be someting else in play.
> 
> I manually created the two symlinks, and subsequent calls to ldconfig
> do not remove them, either.

I added a hack to create the symlinks in %post if they do not exist.
Hopefully that helps. I'm building openssl-0.9.8j-2.fc11 just now.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From choeger at cs.tu-berlin.de  Fri Jan 16 13:10:06 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 16 Jan 2009 14:10:06 +0100
Subject: Xorg: xserver using _a lot_ memory
Message-ID: <1232111406.18033.18.camel@choeger6>

Hi,

I am seeing this since a while, Xorg really sucks somewhere in memory
management.

16840 root      20   0  577m 250m  11m S  3.7 12.6  22:10.17 Xorg

xrestop:

2200000    17    2    1   26 1013     6350K     25K   6375K   ?  
4e00000   222  514    1  452  460     4102K     29K   4132K 18030 
2000000   198   61    1   31   88     1510K      9K   1519K 17188 
1c00000    38   57    1   12   43     1334K      4K   1338K 17184 
0000000     2    0    2    0   79     1333K      3K   1337K   ?  
3a00000     0    0    0    1    0     1333K      0B   1333K   ?  
1a00000    32   39    0   18   81      104K      3K    108K 17295
5200000   154   85    1   54  112       60K      9K     69K 18033

So where did my memory go? And who of you guys has it? I want it back ;)

(and how do I make a valid bug report out of this? Is there a way to
attach a tool like valgrind (not at that debug-level), to see where xorg
looses it's memory?)

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/353ca096/attachment.sig>

From aph at redhat.com  Fri Jan 16 13:13:54 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 16 Jan 2009 13:13:54 +0000
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232111406.18033.18.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
Message-ID: <49708812.4090507@redhat.com>

Christoph H?ger wrote:

> I am seeing this since a while, Xorg really sucks somewhere in memory
> management.
> 
> 16840 root      20   0  577m 250m  11m S  3.7 12.6  22:10.17 Xorg
> 
> xrestop:
> 
> 2200000    17    2    1   26 1013     6350K     25K   6375K   ?  
> 4e00000   222  514    1  452  460     4102K     29K   4132K 18030 
> 2000000   198   61    1   31   88     1510K      9K   1519K 17188 
> 1c00000    38   57    1   12   43     1334K      4K   1338K 17184 
> 0000000     2    0    2    0   79     1333K      3K   1337K   ?  
> 3a00000     0    0    0    1    0     1333K      0B   1333K   ?  
> 1a00000    32   39    0   18   81      104K      3K    108K 17295
> 5200000   154   85    1   54  112       60K      9K     69K 18033
> 
> So where did my memory go? And who of you guys has it? I want it back ;)
> 
> (and how do I make a valid bug report out of this? Is there a way to
> attach a tool like valgrind (not at that debug-level), to see where xorg
> looses it's memory?)

X caches memory on behalf of its clients.  Kill them, one by one, and you'll
probably find where the memory is going.

Andrew.



From dwmw2 at infradead.org  Fri Jan 16 13:13:58 2009
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 16 Jan 2009 13:13:58 +0000
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <49708313.5000209@RedHat.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<1232090446.25018.8023.camel@macbook.infradead.org>
	<49708313.5000209@RedHat.com>
Message-ID: <1232111638.25018.8338.camel@macbook.infradead.org>

On Fri, 2009-01-16 at 07:52 -0500, Steve Dickson wrote:
> 
> David Woodhouse wrote:
> > On Mon, 2009-01-12 at 16:16 -0500, Josef Bacik wrote:
> >> Hello,
> >>
> >> I've just updated btrfs-progs to 0.17 in rawhide, and will be doing
> >> the same for F-10 and F-9 shortly. 
> > 
> > Can we have nfs-utils updated too, please? The one we have in F-9
> > predates my patches to use statfs() to obtain a fsid for exporting the
> > file system. Not sure about F-10, but 1.1.4 in rawhide is OK.
> 
> Just to be clear... you are wanting one of or all of the following patch 
> back ported to F9?
> 
>     Stop exportfs warning about needing fsid, when we actually have one
>     Use fsid from statfs for UUID if blkid can't cope (or not used)
>     Explicit UUID handling doesn't require blkid; factor out get_uuid_blkdev()
>     Fix handling of explicit uuid

Those four should be sufficient, I believe. It's dead easy to test --
just export a btrfs file system and try to mount it; see the ESTALE when
the kernel doesn't understand the nfsfh that mountd just gave out.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation



From galibert at pobox.com  Fri Jan 16 13:26:12 2009
From: galibert at pobox.com (Olivier Galibert)
Date: Fri, 16 Jan 2009 14:26:12 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232111406.18033.18.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
Message-ID: <20090116132611.GA9750@dspnet.fr.eu.org>

On Fri, Jan 16, 2009 at 02:10:06PM +0100, Christoph H?ger wrote:
> Hi,
> 
> I am seeing this since a while, Xorg really sucks somewhere in memory
> management.
> 
> 16840 root      20   0  577m 250m  11m S  3.7 12.6  22:10.17 Xorg

How much of that is pci ranges mmaps?

  OG.



From dakingun at gmail.com  Fri Jan 16 13:58:26 2009
From: dakingun at gmail.com (Deji Akingunola)
Date: Fri, 16 Jan 2009 08:58:26 -0500
Subject: rawhide report: 20090116 changes
In-Reply-To: <b401d2530901160211n5362bf8eu79f0a85cc380c7b0@mail.gmail.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	<b401d2530901160211n5362bf8eu79f0a85cc380c7b0@mail.gmail.com>
Message-ID: <b80014de0901160558o5d29c6efw331adbf36bc1f76a@mail.gmail.com>

On Fri, Jan 16, 2009 at 5:11 AM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
> 2009/1/16 Rawhide Report <rawhide at fedoraproject.org>:
>> ginac-1.4.4-1.fc11
>> ------------------
>> * Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.4.4-1
>> - Updated to 1.4.4
>>
> [..]
>>        ginac-devel-1.4.4-1.fc11.i386 requires pkgconfig(cln) >= 0:1.1.6
>>
>
> Bumped cln so as dependencies are solved. It worked on my local
> rawhide instance, hopefully it is solved now.
>
I think you've just bumped cln unnecessarily; its ginac that requires
cln, not the other way round.

Deji

PS: I'm not sure why ginac-devel have a broken dep on cln, might be a
false positive.

> --
> Regards,
> Rakesh Pandit
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From rjones at redhat.com  Fri Jan 16 14:05:04 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 16 Jan 2009 14:05:04 +0000
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <49708812.4090507@redhat.com>
References: <1232111406.18033.18.camel@choeger6> <49708812.4090507@redhat.com>
Message-ID: <20090116140504.GA11822@amd.home.annexia.org>

On Fri, Jan 16, 2009 at 01:13:54PM +0000, Andrew Haley wrote:
> X caches memory on behalf of its clients.  Kill them, one by one, and you'll
> probably find where the memory is going.

Or use xrestop, the non-destructive alternative :-)

On my machine just now I see that gnome-screensaver is using 160 MB of
X resources, which is excellent news - my screensaver is set to a
blank screen :-(

X may also mmap in chunks of video memory.  This isn't "real" memory
usage, but appears under top and might confuse some people.

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 mtasaka at ioa.s.u-tokyo.ac.jp  Fri Jan 16 14:07:08 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 16 Jan 2009 23:07:08 +0900
Subject: rawhide report: 20090116 changes
In-Reply-To: <b80014de0901160558o5d29c6efw331adbf36bc1f76a@mail.gmail.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>	<b401d2530901160211n5362bf8eu79f0a85cc380c7b0@mail.gmail.com>
	<b80014de0901160558o5d29c6efw331adbf36bc1f76a@mail.gmail.com>
Message-ID: <4970948C.3080203@ioa.s.u-tokyo.ac.jp>

Deji Akingunola wrote, at 01/16/2009 10:58 PM +9:00:
> On Fri, Jan 16, 2009 at 5:11 AM, Rakesh Pandit <rakesh.pandit at gmail.com> wrote:
>> 2009/1/16 Rawhide Report <rawhide at fedoraproject.org>:
>>> ginac-1.4.4-1.fc11
>>> ------------------
>>> * Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.4.4-1
>>> - Updated to 1.4.4
>>>
>> [..]
>>>        ginac-devel-1.4.4-1.fc11.i386 requires pkgconfig(cln) >= 0:1.1.6
>>>
>> Bumped cln so as dependencies are solved. It worked on my local
>> rawhide instance, hopefully it is solved now.
>>
> I think you've just bumped cln unnecessarily; its ginac that requires
> cln, not the other way round.
> 
> Deji
> 
> PS: I'm not sure why ginac-devel have a broken dep on cln, might be a
> false positive.

No, actually in this case cln needed rebuilding so as to make cln-devel
have "Provides: pkgconfig(cln)". Similar rebuilds for pkgconfig provides/obsoletes
started with this comment:

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg02173.html

Mamoru



From mtasaka at ioa.s.u-tokyo.ac.jp  Fri Jan 16 14:09:48 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Fri, 16 Jan 2009 23:09:48 +0900
Subject: rawhide report: 20090116 changes
In-Reply-To: <4970948C.3080203@ioa.s.u-tokyo.ac.jp>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>	<b401d2530901160211n5362bf8eu79f0a85cc380c7b0@mail.gmail.com>	<b80014de0901160558o5d29c6efw331adbf36bc1f76a@mail.gmail.com>
	<4970948C.3080203@ioa.s.u-tokyo.ac.jp>
Message-ID: <4970952C.5020800@ioa.s.u-tokyo.ac.jp>

Mamoru Tasaka wrote, at 01/16/2009 11:07 PM +9:00:
> No, actually in this case cln needed rebuilding so as to make cln-devel
> have "Provides: pkgconfig(cln)". Similar rebuilds for pkgconfig 
> provides/obsoletes
> started with this comment:

Not provides/obsoletes but provides/requires.

Mamoru



From choeger at cs.tu-berlin.de  Fri Jan 16 14:10:07 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 16 Jan 2009 15:10:07 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090116132611.GA9750@dspnet.fr.eu.org>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
Message-ID: <1232115007.23797.0.camel@choeger6>


> How much of that is pci ranges mmaps?

How would I figure that out?
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/9598540b/attachment.sig>

From choeger at cs.tu-berlin.de  Fri Jan 16 14:13:02 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Fri, 16 Jan 2009 15:13:02 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090116140504.GA11822@amd.home.annexia.org>
References: <1232111406.18033.18.camel@choeger6> <49708812.4090507@redhat.com>
	<20090116140504.GA11822@amd.home.annexia.org>
Message-ID: <1232115182.24037.1.camel@choeger6>

Am Freitag, den 16.01.2009, 14:05 +0000 schrieb Richard W.M. Jones:
> On Fri, Jan 16, 2009 at 01:13:54PM +0000, Andrew Haley wrote:
> > X caches memory on behalf of its clients.  Kill them, one by one,
> and you'll
> > probably find where the memory is going.
> 
> Or use xrestop, the non-destructive alternative :-)

What I already did. Both suggestions. My top showed that memory usage
when xrestop showed no hotspots and nearly all apps were gone (ok, I did
not kill gnome itself ;))


-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/9890dada/attachment.sig>

From aph at redhat.com  Fri Jan 16 14:15:06 2009
From: aph at redhat.com (Andrew Haley)
Date: Fri, 16 Jan 2009 14:15:06 +0000
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090116140504.GA11822@amd.home.annexia.org>
References: <1232111406.18033.18.camel@choeger6> <49708812.4090507@redhat.com>
	<20090116140504.GA11822@amd.home.annexia.org>
Message-ID: <4970966A.7000702@redhat.com>

Richard W.M. Jones wrote:
> On Fri, Jan 16, 2009 at 01:13:54PM +0000, Andrew Haley wrote:
>> X caches memory on behalf of its clients.  Kill them, one by one, and you'll
>> probably find where the memory is going.
> 
> Or use xrestop, the non-destructive alternative :-)
> 
> On my machine just now I see that gnome-screensaver is using 160 MB of
> X resources, which is excellent news - my screensaver is set to a
> blank screen :-(

1800000     3   27    0   50 1587   784000K     37K 784037K  3138 gnome-screensa

!

Andrew.



From mclasen at redhat.com  Fri Jan 16 14:22:21 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 16 Jan 2009 09:22:21 -0500
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090116140504.GA11822@amd.home.annexia.org>
References: <1232111406.18033.18.camel@choeger6> <49708812.4090507@redhat.com>
	<20090116140504.GA11822@amd.home.annexia.org>
Message-ID: <1232115741.3275.0.camel@matthiasc>

On Fri, 2009-01-16 at 14:05 +0000, Richard W.M. Jones wrote:
> On Fri, Jan 16, 2009 at 01:13:54PM +0000, Andrew Haley wrote:
> > X caches memory on behalf of its clients.  Kill them, one by one, and you'll
> > probably find where the memory is going.
> 
> Or use xrestop, the non-destructive alternative :-)
> 
> On my machine just now I see that gnome-screensaver is using 160 MB of
> X resources, which is excellent news - my screensaver is set to a
> blank screen :-(
> 

Which version of gnome-screensaver is this ? We've fixed a pixmap leak
in gnome-screensaver a while ago:

* Mon Dec 15 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
- Don't leak pixmaps




From igorsoares at gmail.com  Fri Jan 16 14:29:40 2009
From: igorsoares at gmail.com (Igor Pires Soares)
Date: Fri, 16 Jan 2009 12:29:40 -0200
Subject: PackageKit translations
In-Reply-To: <1232103326.20781.21.camel@hughsie-work.lan>
References: <1232103326.20781.21.camel@hughsie-work.lan>
Message-ID: <1232116180.3455.6.camel@localhost.localdomain>

Em Sex, 2009-01-16 ?s 10:55 +0000, Richard Hughes escreveu:
> In a couple of weeks time they'll be a new PackageKit release that we'll
> see in F11.
> 
> Before that time, I would like the translations for PackageKit to be
> updated -- updated translations are very important for the F11 release
> quality and also for the F10 backport. There are still quite a few
> important languages missing and others that are quite incomplete.
> 
> You can see the current stats here:
> 
> http://translate.fedoraproject.org/module/packagekit#master

I'm not sure about these stats. Fedora's Damned Lies differs from the
GNOME instance:

http://l10n.gnome.org/module/packagekit/

Richard, can you confirm which one is right?

Regards,
Igor Pires Soares



From hedayat at grad.com  Fri Jan 16 14:42:03 2009
From: hedayat at grad.com (Hedayat Vatankhah)
Date: Fri, 16 Jan 2009 18:12:03 +0330
Subject: Package doesn't build in Koji, but can be built locally using
 mock!
In-Reply-To: <49700256.6000609@ioa.s.u-tokyo.ac.jp>
References: <496F7ACE.8040201@grad.com> <496F7FDD.7020304@ioa.s.u-tokyo.ac.jp>
	<49700256.6000609@ioa.s.u-tokyo.ac.jp>
Message-ID: <49709CBB.2060203@grad.com>



/*Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>*/ wrote on 01/16/2009 
07:13:18 AM:
> Mamoru Tasaka wrote, at 01/16/2009 03:26 AM +9:00:
>> Hedayat Vatankhah wrote, at 01/16/2009 03:05 AM +9:00:
>>> Hi all,
>>> I'm the maintainer of rcssserver3d package. The package has been 
>>> built in rawhide successfully, but recently I just removed a font 
>>> file from the package and tried to build the package again in koji, 
>>> but it failed. The build log says that it is unable to find 
>>> /usr/lib64/libIL.so, but it should be able to find it. I didn't 
>>> change anything related to it. Also, I tried to build the package 
>>> using mock (make mockbuild) and the package was able to find the 
>>> library! I wonder what's the problem?!
>>>
>>> koji link: http://koji.fedoraproject.org/koji/taskinfo?taskID=1055760
>>>
>>> Thanks,
>>> Hedayat
>>
>> At least DevIL-1.7.5-1.fc11 seems broken as now ldd reports that 
>> libIL.so.1 contains undefined non-weak symbols. config.log shows:
>>
>> -------------------------------------------------------------------
>> configure:22286: g++ -o conftest -O2 -g -pipe -Wall 
>> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
>> --param=ssp-buffer-size=4 -m64 -mtune=generic    -lIL conftest.cpp  >&5
>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
>> undefined reference to `ilLoadVtf'
>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
>> undefined reference to `ilLoadVtfF'
>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/libIL.so: 
>> undefined reference to `ilLoadVtfL'
>> collect2: ld returned 1 exit status
>> configure:22293: $? = 1
>> configure: failed program was:
>> | #include <IL/il.h>
>> | #include <stdarg.h> /* _vsnprintf may be undefined (and it is 
>> needed by libIL) */
>> | extern "C" int _vsnprintf(char *str, size_t size, const char 
>> *format, va_list ap) { return 0;}
>> | int main(int argc, char **argv) { ilInit(); return 0; }
>> configure:22360: WARNING: The DevIL library (libIL.a or libIL.so) 
>> cannot be found.
>> -------------------------------------------------------------------
>>
>> I guess this needs bug report against DevIL.
>
> ... and filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=480269
>
> Mamoru
>
Thanks. I found that my local mock have used DevIL-1.6.8 from rawhide 
and so it worked with no problem.

Hedayat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/40edb573/attachment.htm>

From vonbrand at inf.utfsm.cl  Fri Jan 16 14:47:33 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 11:47:33 -0300
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <20090116133205.670448ce@dhcp03.addix.net>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
Message-ID: <200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>

Ralf Ertzinger <fedora at camperquake.de> wrote:
> On Fri, 16 Jan 2009 09:28:08 -0300, Horst H. von Brand wrote:
> 
> >   /usr/bin/git: error while loading shared libraries: libcrypto.so.7:
> > cannot open shared object file: No such file or directory
> 
> The problem is that the openssl package was supposed to contain symlinks for
> libssl.so.7 and libcryoto.so.7, and rpm -ql says that the package does contain
> them, but they are, in fact, missing from the filesystem.

I created them by hand, and that doesn't work either.
-- 
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 pronix.service at gmail.com  Fri Jan 16 14:51:37 2009
From: pronix.service at gmail.com (pronix pronix)
Date: Fri, 16 Jan 2009 17:51:37 +0300
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>
Message-ID: <639ce0480901160651h70aa854fuaf5a4796b485fdd9@mail.gmail.com>

is this library for x86_64 or x86 ? check it.

2009/1/16 Horst H. von Brand <vonbrand at inf.utfsm.cl>:
> Ralf Ertzinger <fedora at camperquake.de> wrote:
>> On Fri, 16 Jan 2009 09:28:08 -0300, Horst H. von Brand wrote:
>>
>> >   /usr/bin/git: error while loading shared libraries: libcrypto.so.7:
>> > cannot open shared object file: No such file or directory
>>
>> The problem is that the openssl package was supposed to contain symlinks for
>> libssl.so.7 and libcryoto.so.7, and rpm -ql says that the package does contain
>> them, but they are, in fact, missing from the filesystem.
>
> I created them by hand, and that doesn't work either.
> --
> 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
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From rjones at redhat.com  Fri Jan 16 14:58:22 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 16 Jan 2009 14:58:22 +0000
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232115741.3275.0.camel@matthiasc>
References: <1232111406.18033.18.camel@choeger6> <49708812.4090507@redhat.com>
	<20090116140504.GA11822@amd.home.annexia.org>
	<1232115741.3275.0.camel@matthiasc>
Message-ID: <20090116145822.GA12877@amd.home.annexia.org>

On Fri, Jan 16, 2009 at 09:22:21AM -0500, Matthias Clasen wrote:
> On Fri, 2009-01-16 at 14:05 +0000, Richard W.M. Jones wrote:
> > On Fri, Jan 16, 2009 at 01:13:54PM +0000, Andrew Haley wrote:
> > > X caches memory on behalf of its clients.  Kill them, one by one, and you'll
> > > probably find where the memory is going.
> > 
> > Or use xrestop, the non-destructive alternative :-)
> > 
> > On my machine just now I see that gnome-screensaver is using 160 MB of
> > X resources, which is excellent news - my screensaver is set to a
> > blank screen :-(
> > 
> 
> Which version of gnome-screensaver is this ? We've fixed a pixmap leak
> in gnome-screensaver a while ago:
> 
> * Mon Dec 15 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
> - Don't leak pixmaps

Same one:

  $ rpm -qf /usr/bin/gnome-screensaver
  gnome-screensaver-2.24.1-2.fc10.x86_64

HOWEVER I haven't logged out and logged in yet (or rebooted or
whatever is necessary), so it is possible that it is still running an
older version.

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 bdwheele at indiana.edu  Fri Jan 16 15:07:30 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Fri, 16 Jan 2009 10:07:30 -0500
Subject: yum on rawhide broken?
Message-ID: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>

I just ran an update via yum and now yum gives me this error:

[root at wombat gg]# yum list \*google\*
Traceback (most recent call last):
  File "/usr/bin/yum", line 4, in <module>
    import yum
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 49, in <module>
    import config
  File "/usr/lib/python2.6/site-packages/yum/config.py", line 27, in <module>
    from parser import ConfigPreProcessor
  File "/usr/lib/python2.6/site-packages/yum/parser.py", line 3, in <module>
    import urlgrabber
  File "/usr/lib/python2.6/site-packages/urlgrabber/__init__.py", line 53, in <module>
    from grabber import urlgrab, urlopen, urlread
  File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 410, in <module>
    import keepalive
  File "/usr/lib/python2.6/site-packages/urlgrabber/keepalive.py", line 444, in <module>
    class HTTPSConnection(httplib.HTTPSConnection):
AttributeError: 'module' object has no attribute 'HTTPSConnection'



Since it happened right after I did an update, I still had the update
output in the scrollback buffer.  There doesn't seem to be anything that
looks like it'd break yum, though...

[root at wombat bdwheele]# yum update
Loaded plugins: refresh-packagekit
rawhide                                                  | 2.8 kB     00:00     
rawhide/primary_db                                       | 7.1 MB     00:06     
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package PyKDE4.i386 0:4.1.96-4.fc11 set to be updated
---> Package automake.noarch 0:1.10.2-1 set to be updated
---> Package dejavu-fonts-common.noarch 0:2.28-2.fc11 set to be updated
---> Package dejavu-sans-fonts.noarch 0:2.28-2.fc11 set to be updated
---> Package dejavu-sans-mono-fonts.noarch 0:2.28-2.fc11 set to be updated
---> Package dejavu-serif-fonts.noarch 0:2.28-2.fc11 set to be updated
---> Package dhclient.i386 12:4.1.0-5.fc11 set to be updated
---> Package fedora-logos.noarch 0:10.0.1-4.fc11 set to be updated
---> Package file.i386 0:4.26-9.fc11 set to be updated
---> Package file-devel.i386 0:4.26-9.fc11 set to be updated
---> Package file-libs.i386 0:4.26-9.fc11 set to be updated
---> Package fontconfig.i386 0:2.6.90-3.git.63.g6bb4b9a.fc11 set to be updated
---> Package fontconfig-devel.i386 0:2.6.90-3.git.63.g6bb4b9a.fc11 set to be updated
---> Package fontpackages-filesystem.noarch 0:1.15-1.fc11 set to be updated
---> Package foomatic.i386 0:4.0.0-1.fc11 set to be updated
---> Package freetype.i386 0:2.3.8-1.fc11 set to be updated
---> Package freetype-devel.i386 0:2.3.8-1.fc11 set to be updated
---> Package glibmm24.i386 0:2.19.1-1.fc11 set to be updated
---> Package google-gadgets.i386 0:0.10.5-1.fc11 set to be updated
---> Package google-gadgets-qt.i386 0:0.10.5-1.fc11 set to be updated
---> Package grubby.i386 0:6.0.74-1.fc11 set to be updated
---> Package gstreamer-plugins-good.i386 0:0.10.11-4.fc11 set to be updated
---> Package gtkmm24.i386 0:2.15.0-1.fc11 set to be updated
---> Package gucharmap.i386 0:2.24.3-1.fc11 set to be updated
---> Package hdparm.i386 0:9.8-1.fc11 set to be updated
---> Package hunspell-en.noarch 0:0.20090114-1.fc11 set to be updated
---> Package kdebase-workspace.i386 0:4.1.96-3.fc11 set to be updated
---> Package kdebase-workspace-libs.i386 0:4.1.96-3.fc11 set to be updated
---> Package kdebase-workspace-wallpapers.i386 0:4.1.96-3.fc11 set to be updated
---> Package kdepim.i386 6:4.1.96-3.fc11 set to be updated
---> Package kdepim-libs.i386 6:4.1.96-3.fc11 set to be updated
---> Package kdeutils.i386 6:4.1.96-2.fc11 set to be updated
---> Package kernel.i686 0:2.6.29-0.38.rc1.git4.fc11 set to be installed
---> Package kernel-firmware.noarch 0:2.6.29-0.38.rc1.git4.fc11 set to be updated
---> Package ksysguardd.i386 0:4.1.96-3.fc11 set to be updated
---> Package libgpod.i386 0:0.6.0-10.fc11 set to be updated
---> Package libiec61883.i386 0:1.2.0-1.fc11 set to be updated
---> Package libraw1394.i386 0:2.0.1-1.fc11 set to be updated
---> Package libsemanage.i386 0:2.0.31-2.fc11 set to be updated
---> Package libsemanage-python.i386 0:2.0.31-2.fc11 set to be updated
---> Package linuxwacom.i386 0:0.8.2.1-1.fc11 set to be updated
---> Package mingw32-filesystem.noarch 0:42-1.fc11 set to be updated
---> Package mkinitrd.i386 0:6.0.74-1.fc11 set to be updated
---> Package nash.i386 0:6.0.74-1.fc11 set to be updated
---> Package ntp.i386 0:4.2.4p6-1.fc11 set to be updated
---> Package ntpdate.i386 0:4.2.4p6-1.fc11 set to be updated
---> Package openssh.i386 0:5.1p1-5.fc11 set to be updated
---> Package openssh-askpass.i386 0:5.1p1-5.fc11 set to be updated
---> Package openssh-clients.i386 0:5.1p1-5.fc11 set to be updated
---> Package openssh-server.i386 0:5.1p1-5.fc11 set to be updated
---> Package openssl.i686 0:0.9.8j-1.fc11 set to be updated
---> Package policycoreutils.i386 0:2.0.61-2.fc11 set to be updated
---> Package policycoreutils-gui.i386 0:2.0.61-2.fc11 set to be updated
--> Processing Dependency: policycoreutils-python = 2.0.61-2.fc11 for package: policycoreutils-gui
---> Package system-config-printer.i386 0:1.1.2-1.fc11 set to be updated
--> Processing Dependency: gnome-python2-gnomekeyring for package: system-config-printer
---> Package system-config-printer-libs.i386 0:1.1.2-1.fc11 set to be updated
---> Package system-config-users.noarch 0:1.2.84-1.fc11 set to be updated
---> Package usermode.i386 0:1.99-2 set to be updated
---> Package usermode-gtk.i386 0:1.99-2 set to be updated
---> Package vbetool.i386 0:1.1-2.fc11 set to be updated
--> Running transaction check
---> Package gnome-python2-gnomekeyring.i386 0:2.24.1-2.fc11 set to be updated
---> Package policycoreutils-python.i386 0:2.0.61-2.fc11 set to be updated
--> Finished Dependency Resolution
--> Running transaction check
---> Package kernel.i686 0:2.6.29-0.28.rc1.fc11 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                    Arch   Version                        Repository
                                                                           Size
================================================================================
Installing:
 dejavu-sans-fonts          noarch 2.28-2.fc11                    rawhide 2.4 M
     replacing  dejavu-fonts-sans.noarch 2.28-1.fc11

 dejavu-sans-mono-fonts     noarch 2.28-2.fc11                    rawhide 633 k
     replacing  dejavu-fonts-sans-mono.noarch 2.28-1.fc11

 dejavu-serif-fonts         noarch 2.28-2.fc11                    rawhide 1.3 M
     replacing  dejavu-fonts-serif.noarch 2.28-1.fc11

 kernel                     i686   2.6.29-0.38.rc1.git4.fc11      rawhide  20 M
Updating:
 PyKDE4                     i386   4.1.96-4.fc11                  rawhide 4.7 M
 automake                   noarch 1.10.2-1                       rawhide 538 k
 dejavu-fonts-common        noarch 2.28-2.fc11                    rawhide  59 k
 dhclient                   i386   12:4.1.0-5.fc11                rawhide 313 k
 fedora-logos               noarch 10.0.1-4.fc11                  rawhide 1.8 M
 file                       i386   4.26-9.fc11                    rawhide  39 k
 file-devel                 i386   4.26-9.fc11                    rawhide  61 k
 file-libs                  i386   4.26-9.fc11                    rawhide 334 k
 fontconfig                 i386   2.6.90-3.git.63.g6bb4b9a.fc11  rawhide 193 k
 fontconfig-devel           i386   2.6.90-3.git.63.g6bb4b9a.fc11  rawhide 201 k
 fontpackages-filesystem    noarch 1.15-1.fc11                    rawhide 3.7 k
 foomatic                   i386   4.0.0-1.fc11                   rawhide  19 M
 freetype                   i386   2.3.8-1.fc11                   rawhide 384 k
 freetype-devel             i386   2.3.8-1.fc11                   rawhide 395 k
 glibmm24                   i386   2.19.1-1.fc11                  rawhide 313 k
 google-gadgets             i386   0.10.5-1.fc11                  rawhide 2.1 M
 google-gadgets-qt          i386   0.10.5-1.fc11                  rawhide 250 k
 grubby                     i386   6.0.74-1.fc11                  rawhide  90 k
 gstreamer-plugins-good     i386   0.10.11-4.fc11                 rawhide 1.1 M
 gtkmm24                    i386   2.15.0-1.fc11                  rawhide 1.1 M
 gucharmap                  i386   2.24.3-1.fc11                  rawhide 2.4 M
 hdparm                     i386   9.8-1.fc11                     rawhide  71 k
 hunspell-en                noarch 0.20090114-1.fc11              rawhide 624 k
 kdebase-workspace          i386   4.1.96-3.fc11                  rawhide  13 M
 kdebase-workspace-libs     i386   4.1.96-3.fc11                  rawhide 727 k
 kdebase-workspace-wallpapers
                            i386   4.1.96-3.fc11                  rawhide  31 M
 kdepim                     i386   6:4.1.96-3.fc11                rawhide  11 M
 kdepim-libs                i386   6:4.1.96-3.fc11                rawhide 7.3 M
 kdeutils                   i386   6:4.1.96-2.fc11                rawhide 2.8 M
 kernel-firmware            noarch 2.6.29-0.38.rc1.git4.fc11      rawhide 446 k
 ksysguardd                 i386   4.1.96-3.fc11                  rawhide  67 k
 libgpod                    i386   0.6.0-10.fc11                  rawhide 235 k
 libiec61883                i386   1.2.0-1.fc11                   rawhide  37 k
 libraw1394                 i386   2.0.1-1.fc11                   rawhide  58 k
 libsemanage                i386   2.0.31-2.fc11                  rawhide 105 k
 libsemanage-python         i386   2.0.31-2.fc11                  rawhide  85 k
 linuxwacom                 i386   0.8.2.1-1.fc11                 rawhide 239 k
 mingw32-filesystem         noarch 42-1.fc11                      rawhide  18 k
 mkinitrd                   i386   6.0.74-1.fc11                  rawhide  87 k
 nash                       i386   6.0.74-1.fc11                  rawhide 156 k
 ntp                        i386   4.2.4p6-1.fc11                 rawhide 1.4 M
 ntpdate                    i386   4.2.4p6-1.fc11                 rawhide  55 k
 openssh                    i386   5.1p1-5.fc11                   rawhide 306 k
 openssh-askpass            i386   5.1p1-5.fc11                   rawhide  40 k
 openssh-clients            i386   5.1p1-5.fc11                   rawhide 495 k
 openssh-server             i386   5.1p1-5.fc11                   rawhide 296 k
 openssl                    i686   0.9.8j-1.fc11                  rawhide 1.4 M
 policycoreutils            i386   2.0.61-2.fc11                  rawhide 916 k
 policycoreutils-gui        i386   2.0.61-2.fc11                  rawhide 189 k
 system-config-printer      i386   1.1.2-1.fc11                   rawhide 436 k
 system-config-printer-libs i386   1.1.2-1.fc11                   rawhide 703 k
 system-config-users        noarch 1.2.84-1.fc11                  rawhide 388 k
 usermode                   i386   1.99-2                         rawhide 212 k
 usermode-gtk               i386   1.99-2                         rawhide 111 k
 vbetool                    i386   1.1-2.fc11                     rawhide  29 k
Removing:
 kernel                     i686   2.6.29-0.28.rc1.fc11           installed
                                                                           54 M
Installing for dependencies:
 gnome-python2-gnomekeyring i386   2.24.1-2.fc11                  rawhide  21 k
 policycoreutils-python     i386   2.0.61-2.fc11                  rawhide 249 k

Transaction Summary
================================================================================
Install      6 Package(s)         
Update      55 Package(s)         
Remove       1 Package(s)         

Total download size: 134 M
Is this ok [y/N]: y
Downloading Packages:
(1/61): fontpackages-filesystem-1.15-1.fc11.noarch.rpm   | 3.7 kB     00:00     
(2/61): mingw32-filesystem-42-1.fc11.noarch.rpm          |  18 kB     00:00     
(3/61): gnome-python2-gnomekeyring-2.24.1-2.fc11.i386.rp |  21 kB     00:00     
(4/61): vbetool-1.1-2.fc11.i386.rpm                      |  29 kB     00:00     
(5/61): libiec61883-1.2.0-1.fc11.i386.rpm                |  37 kB     00:00     
(6/61): file-4.26-9.fc11.i386.rpm                        |  39 kB     00:00     
(7/61): openssh-askpass-5.1p1-5.fc11.i386.rpm            |  40 kB     00:00     
(8/61): ntpdate-4.2.4p6-1.fc11.i386.rpm                  |  55 kB     00:00     
(9/61): libraw1394-2.0.1-1.fc11.i386.rpm                 |  58 kB     00:00     
(10/61): dejavu-fonts-common-2.28-2.fc11.noarch.rpm      |  59 kB     00:00     
(11/61): file-devel-4.26-9.fc11.i386.rpm                 |  61 kB     00:00     
(12/61): ksysguardd-4.1.96-3.fc11.i386.rpm               |  67 kB     00:00     
(13/61): hdparm-9.8-1.fc11.i386.rpm                      |  71 kB     00:00     
(14/61): libsemanage-python-2.0.31-2.fc11.i386.rpm       |  85 kB     00:00     
(15/61): mkinitrd-6.0.74-1.fc11.i386.rpm                 |  87 kB     00:00     
(16/61): grubby-6.0.74-1.fc11.i386.rpm                   |  90 kB     00:00     
(17/61): libsemanage-2.0.31-2.fc11.i386.rpm              | 105 kB     00:00     
(18/61): usermode-gtk-1.99-2.i386.rpm                    | 111 kB     00:00     
(19/61): nash-6.0.74-1.fc11.i386.rpm                     | 156 kB     00:00     
(20/61): policycoreutils-gui-2.0.61-2.fc11.i386.rpm      | 189 kB     00:00     
(21/61): fontconfig-2.6.90-3.git.63.g6bb4b9a.fc11.i386.r | 193 kB     00:00     
(22/61): fontconfig-devel-2.6.90-3.git.63.g6bb4b9a.fc11. | 201 kB     00:00     
(23/61): usermode-1.99-2.i386.rpm                        | 212 kB     00:00     
(24/61): libgpod-0.6.0-10.fc11.i386.rpm                  | 235 kB     00:00     
(25/61): linuxwacom-0.8.2.1-1.fc11.i386.rpm              | 239 kB     00:00     
(26/61): policycoreutils-python-2.0.61-2.fc11.i386.rpm   | 249 kB     00:00     
(27/61): google-gadgets-qt-0.10.5-1.fc11.i386.rpm        | 250 kB     00:00     
(28/61): openssh-server-5.1p1-5.fc11.i386.rpm            | 296 kB     00:00     
(29/61): openssh-5.1p1-5.fc11.i386.rpm                   | 306 kB     00:00     
(30/61): glibmm24-2.19.1-1.fc11.i386.rpm                 | 313 kB     00:00     
(31/61): dhclient-4.1.0-5.fc11.i386.rpm                  | 313 kB     00:00     
(32/61): file-libs-4.26-9.fc11.i386.rpm                  | 334 kB     00:00     
(33/61): freetype-2.3.8-1.fc11.i386.rpm                  | 384 kB     00:00     
(34/61): system-config-users-1.2.84-1.fc11.noarch.rpm    | 388 kB     00:00     
(35/61): freetype-devel-2.3.8-1.fc11.i386.rpm            | 395 kB     00:00     
(36/61): system-config-printer-1.1.2-1.fc11.i386.rpm     | 436 kB     00:00     
(37/61): kernel-firmware-2.6.29-0.38.rc1.git4.fc11.noarc | 446 kB     00:00     
(38/61): openssh-clients-5.1p1-5.fc11.i386.rpm           | 495 kB     00:00     
(39/61): automake-1.10.2-1.noarch.rpm                    | 538 kB     00:00     
(40/61): hunspell-en-0.20090114-1.fc11.noarch.rpm        | 624 kB     00:00     
(41/61): dejavu-sans-mono-fonts-2.28-2.fc11.noarch.rpm   | 633 kB     00:02     
(42/61): system-config-printer-libs-1.1.2-1.fc11.i386.rp | 703 kB     00:00     
(43/61): kdebase-workspace-libs-4.1.96-3.fc11.i386.rpm   | 727 kB     00:00     
(44/61): policycoreutils-2.0.61-2.fc11.i386.rpm          | 916 kB     00:00     
(45/61): gstreamer-plugins-good-0.10.11-4.fc11.i386.rpm  | 1.1 MB     00:00     
(46/61): gtkmm24-2.15.0-1.fc11.i386.rpm                  | 1.1 MB     00:00     
(47/61): dejavu-serif-fonts-2.28-2.fc11.noarch.rpm       | 1.3 MB     00:00     
(48/61): ntp-4.2.4p6-1.fc11.i386.rpm                     | 1.4 MB     00:00     
(49/61): openssl-0.9.8j-1.fc11.i686.rpm                  | 1.4 MB     00:00     
(50/61): fedora-logos-10.0.1-4.fc11.noarch.rpm           | 1.8 MB     00:00     
(51/61): google-gadgets-0.10.5-1.fc11.i386.rpm           | 2.1 MB     00:01     
(52/61): dejavu-sans-fonts-2.28-2.fc11.noarch.rpm        | 2.4 MB     00:01     
(53/61): gucharmap-2.24.3-1.fc11.i386.rpm                | 2.4 MB     00:01     
(54/61): kdeutils-4.1.96-2.fc11.i386.rpm                 | 2.8 MB     00:01     
(55/61): PyKDE4-4.1.96-4.fc11.i386.rpm                   | 4.7 MB     00:02     
(56/61): kdepim-libs-4.1.96-3.fc11.i386.rpm              | 7.3 MB     00:04     
(57/61): kdepim-4.1.96-3.fc11.i386.rpm                   |  11 MB     00:06     
(58/61): kdebase-workspace-4.1.96-3.fc11.i386.rpm        |  13 MB     00:07     
(59/61): foomatic-4.0.0-1.fc11.i386.rpm                  |  19 MB     00:11     
(60/61): kernel-2.6.29-0.38.rc1.git4.fc11.i686.rpm       |  20 MB     00:11     
(61/61): kdebase-workspace-wallpapers-4.1.96-3.fc11.i386 |  31 MB     00:19     
--------------------------------------------------------------------------------
Total                                           1.5 MB/s | 134 MB     01:32     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : fontpackages-filesystem                                1/120 
  Updating       : dejavu-fonts-common                                    2/120 
  Updating       : kernel-firmware                                        3/120 
  Installing     : dejavu-serif-fonts                                     4/120 
  Installing     : dejavu-sans-mono-fonts                                 5/120 
  Installing     : dejavu-sans-fonts                                      6/120 
  Updating       : automake                                               7/120 
  Updating       : fedora-logos                                           8/120 
  Updating       : mingw32-filesystem                                     9/120 
  Updating       : kdebase-workspace-wallpapers                          10/120 
  Updating       : hunspell-en                                           11/120 
  Updating       : freetype                                              12/120 
  Updating       : fontconfig                                            13/120 
  Updating       : openssl                                               14/120 
  Updating       : file-libs                                             15/120 
  Updating       : libraw1394                                            16/120 
  Updating       : nash                                                  17/120 
  Updating       : libsemanage                                           18/120 
  Updating       : libiec61883                                           19/120 
  Updating       : openssh                                               20/120 
  Updating       : glibmm24                                              21/120 
  Updating       : foomatic                                              22/120 
  Updating       : usermode                                              23/120 
  Updating       : usermode-gtk                                          24/120 
  Updating       : system-config-printer-libs                            25/120 
  Updating       : libsemanage-python                                    26/120 
  Updating       : grubby                                                27/120 
  Updating       : PyKDE4                                                28/120 
  Updating       : dhclient                                              29/120 
  Updating       : kdeutils                                              30/120 
  Updating       : gtkmm24                                               31/120 
  Updating       : policycoreutils                                       32/120 
  Updating       : file                                                  33/120 
  Updating       : gucharmap                                             34/120 
  Updating       : linuxwacom                                            35/120 
  Installing     : gnome-python2-gnomekeyring                            36/120 
  Updating       : libgpod                                               37/120 
  Updating       : ntpdate                                               38/120 
  Updating       : ksysguardd                                            39/120 
  Updating       : ntp                                                   40/120 
  Updating       : openssh-clients                                       41/120 
  Updating       : openssh-server                                        42/120 
  Updating       : openssh-askpass                                       43/120 
  Updating       : gstreamer-plugins-good                                44/120 
  Updating       : vbetool                                               45/120 
  Updating       : hdparm                                                46/120 
  Updating       : freetype-devel                                        47/120 
  Updating       : system-config-printer                                 48/120 
  Installing     : policycoreutils-python                                49/120 
  Updating       : mkinitrd                                              50/120 
  Updating       : policycoreutils-gui                                   51/120 
  Updating       : fontconfig-devel                                      52/120 
  Updating       : file-devel                                            53/120 
  Updating       : system-config-users                                   54/120 
  Installing     : kernel                                                55/120 
  Updating       : google-gadgets                                        56/120 
  Updating       : kdepim-libs                                           57/120 
  Updating       : google-gadgets-qt                                     58/120 
  Updating       : kdebase-workspace-libs                                59/120 
  Updating       : kdebase-workspace                                     60/120 
  Updating       : kdepim                                                61/120 
  Cleanup        : openssh-clients                                       62/120 
  Erasing        : dejavu-fonts-serif                                    63/120 
  Cleanup        : libiec61883                                           64/120 
  Cleanup        : hdparm                                                65/120 
  Cleanup        : libraw1394                                            66/120 
  Cleanup        : gstreamer-plugins-good                                67/120 
  Cleanup        : openssh-server                                        68/120 
  Cleanup        : ksysguardd                                            69/120 
  Cleanup        : ntpdate                                               70/120 
  Cleanup        : libsemanage-python                                    71/120 
  Cleanup        : kernel-firmware                                       72/120 
  Cleanup        : kernel                                                73/120 
  Cleanup        : ntp                                                   74/120 
  Cleanup        : file-devel                                            75/120 
  Cleanup        : libsemanage                                           76/120 
  Cleanup        : usermode-gtk                                          77/120 
  Cleanup        : grubby                                                78/120 
  Cleanup        : dhclient                                              79/120 
  Erasing        : dejavu-fonts-sans-mono                                80/120 
  Cleanup        : usermode                                              81/120 
  Cleanup        : fontconfig                                            82/120 
  Cleanup        : vbetool                                               83/120 
  Cleanup        : gucharmap                                             84/120 
  Cleanup        : hunspell-en                                           85/120 
  Cleanup        : openssh                                               86/120 
  Cleanup        : file-libs                                             87/120 
  Cleanup        : kdebase-workspace-wallpapers                          88/120 
  Cleanup        : freetype                                              89/120 
  Cleanup        : mingw32-filesystem                                    90/120 
  Cleanup        : nash                                                  91/120 
  Cleanup        : freetype-devel                                        92/120 
  Cleanup        : fontpackages-filesystem                               93/120 
  Cleanup        : gtkmm24                                               94/120 
  Cleanup        : system-config-printer                                 95/120 
  Cleanup        : file                                                  96/120 
  Cleanup        : kdebase-workspace-libs                                97/120 
  Cleanup        : google-gadgets-qt                                     98/120 
  Cleanup        : libgpod                                               99/120 
  Cleanup        : kdepim                                               100/120 
  Cleanup        : system-config-users                                  101/120 
  Cleanup        : openssl                                              102/120 
  Cleanup        : mkinitrd                                             103/120 
  Cleanup        : policycoreutils-gui                                  104/120 
  Cleanup        : linuxwacom                                           105/120 
  Cleanup        : system-config-printer-libs                           106/120 
  Cleanup        : fedora-logos                                         107/120 
  Cleanup        : openssh-askpass                                      108/120 
  Cleanup        : PyKDE4                                               109/120 
  Cleanup        : fontconfig-devel                                     110/120 
  Erasing        : dejavu-fonts-sans                                    111/120 
  Cleanup        : policycoreutils                                      112/120 
  Cleanup        : kdebase-workspace                                    113/120 
  Cleanup        : foomatic                                             114/120 
  Cleanup        : dejavu-fonts-common                                  115/120 
  Cleanup        : glibmm24                                             116/120 
  Cleanup        : kdeutils                                             117/120 
  Cleanup        : google-gadgets                                       118/120 
  Cleanup        : automake                                             119/120 
  Cleanup        : kdepim-libs                                          120/120 

Removed:
  kernel.i686 0:2.6.29-0.28.rc1.fc11                                            

Installed:
  dejavu-sans-fonts.noarch 0:2.28-2.fc11                                        
  dejavu-sans-mono-fonts.noarch 0:2.28-2.fc11                                   
  dejavu-serif-fonts.noarch 0:2.28-2.fc11                                       
  kernel.i686 0:2.6.29-0.38.rc1.git4.fc11                                       

Dependency Installed:
  gnome-python2-gnomekeyring.i386 0:2.24.1-2.fc11                               
  policycoreutils-python.i386 0:2.0.61-2.fc11                                   

Updated:
  PyKDE4.i386 0:4.1.96-4.fc11                                                   
  automake.noarch 0:1.10.2-1                                                    
  dejavu-fonts-common.noarch 0:2.28-2.fc11                                      
  dhclient.i386 12:4.1.0-5.fc11                                                 
  fedora-logos.noarch 0:10.0.1-4.fc11                                           
  file.i386 0:4.26-9.fc11                                                       
  file-devel.i386 0:4.26-9.fc11                                                 
  file-libs.i386 0:4.26-9.fc11                                                  
  fontconfig.i386 0:2.6.90-3.git.63.g6bb4b9a.fc11                               
  fontconfig-devel.i386 0:2.6.90-3.git.63.g6bb4b9a.fc11                         
  fontpackages-filesystem.noarch 0:1.15-1.fc11                                  
  foomatic.i386 0:4.0.0-1.fc11                                                  
  freetype.i386 0:2.3.8-1.fc11                                                  
  freetype-devel.i386 0:2.3.8-1.fc11                                            
  glibmm24.i386 0:2.19.1-1.fc11                                                 
  google-gadgets.i386 0:0.10.5-1.fc11                                           
  google-gadgets-qt.i386 0:0.10.5-1.fc11                                        
  grubby.i386 0:6.0.74-1.fc11                                                   
  gstreamer-plugins-good.i386 0:0.10.11-4.fc11                                  
  gtkmm24.i386 0:2.15.0-1.fc11                                                  
  gucharmap.i386 0:2.24.3-1.fc11                                                
  hdparm.i386 0:9.8-1.fc11                                                      
  hunspell-en.noarch 0:0.20090114-1.fc11                                        
  kdebase-workspace.i386 0:4.1.96-3.fc11                                        
  kdebase-workspace-libs.i386 0:4.1.96-3.fc11                                   
  kdebase-workspace-wallpapers.i386 0:4.1.96-3.fc11                             
  kdepim.i386 6:4.1.96-3.fc11                                                   
  kdepim-libs.i386 6:4.1.96-3.fc11                                              
  kdeutils.i386 6:4.1.96-2.fc11                                                 
  kernel-firmware.noarch 0:2.6.29-0.38.rc1.git4.fc11                            
  ksysguardd.i386 0:4.1.96-3.fc11                                               
  libgpod.i386 0:0.6.0-10.fc11                                                  
  libiec61883.i386 0:1.2.0-1.fc11                                               
  libraw1394.i386 0:2.0.1-1.fc11                                                
  libsemanage.i386 0:2.0.31-2.fc11                                              
  libsemanage-python.i386 0:2.0.31-2.fc11                                       
  linuxwacom.i386 0:0.8.2.1-1.fc11                                              
  mingw32-filesystem.noarch 0:42-1.fc11                                         
  mkinitrd.i386 0:6.0.74-1.fc11                                                 
  nash.i386 0:6.0.74-1.fc11                                                     
  ntp.i386 0:4.2.4p6-1.fc11                                                     
  ntpdate.i386 0:4.2.4p6-1.fc11                                                 
  openssh.i386 0:5.1p1-5.fc11                                                   
  openssh-askpass.i386 0:5.1p1-5.fc11                                           
  openssh-clients.i386 0:5.1p1-5.fc11                                           
  openssh-server.i386 0:5.1p1-5.fc11                                            
  openssl.i686 0:0.9.8j-1.fc11                                                  
  policycoreutils.i386 0:2.0.61-2.fc11                                          
  policycoreutils-gui.i386 0:2.0.61-2.fc11                                      
  system-config-printer.i386 0:1.1.2-1.fc11                                     
  system-config-printer-libs.i386 0:1.1.2-1.fc11                                
  system-config-users.noarch 0:1.2.84-1.fc11                                    
  usermode.i386 0:1.99-2                                                        
  usermode-gtk.i386 0:1.99-2                                                    
  vbetool.i386 0:1.1-2.fc11                                                     

Replaced:
  dejavu-fonts-sans.noarch 0:2.28-1.fc11                                        
  dejavu-fonts-sans-mono.noarch 0:2.28-1.fc11                                   
  dejavu-fonts-serif.noarch 0:2.28-1.fc11                                       

Complete!




Any ideas?



From vonbrand at inf.utfsm.cl  Fri Jan 16 15:10:14 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 12:10:14 -0300
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <639ce0480901160651h70aa854fuaf5a4796b485fdd9@mail.gmail.com>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>
	<639ce0480901160651h70aa854fuaf5a4796b485fdd9@mail.gmail.com>
Message-ID: <200901161510.n0GFAEcl024118@laptop14.inf.utfsm.cl>

pronix pronix <pronix.service at gmail.com> wrote:
> is this library for x86_64 or x86 ? check it.

You are right, too long a time knowing only /lib /usr/lib :-(

Will try again.

OK, after reinstalling the offending packages, then I had _broken_ symlinks:
libssl.so.7 --> libssl.so.0.9.8g (old version!). Fixed those by hand, now
it works.
-- 
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 selinux at gmail.com  Fri Jan 16 15:10:29 2009
From: selinux at gmail.com (Tom London)
Date: Fri, 16 Jan 2009 07:10:29 -0800
Subject: rawhide report: 20090116 changes
In-Reply-To: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
Message-ID: <4c4ba1530901160710h5e1fba3am2a2f309162754948@mail.gmail.com>

On Fri, Jan 16, 2009 at 12:12 AM, Rawhide Report
<rawhide at fedoraproject.org> wrote:
>
>
> kernel-2.6.29-0.38.rc1.git4.fc11
> --------------------------------
> * Thu Jan 15 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
> - New version of module_ref patch, uses per_cpu instead.
> - Fix linux-2.6-hdpvr.patch up and re-enable.
>    Nuke .flush, was useless, convert to v4l2_file_operations, fix ioctl ret
> - Fix linux-2.6-debug-taint-vm.patch and re-enable.
>
> * Wed Jan 14 17:00:00 2009 Dave Jones <davej at redhat.com>
> - Test RODATA and NX during bootup.
>

This kernel fails to boot for me:
https://bugzilla.redhat.com/show_bug.cgi?id=480337

Appears to hang/fail about when it would request passphrase for
encrypted partitions....

tom
-- 
Tom London



From skvidal at fedoraproject.org  Fri Jan 16 15:11:31 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Jan 2009 10:11:31 -0500
Subject: yum on rawhide broken?
In-Reply-To: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <1232118691.4912.11.camel@rosebud>

On Fri, 2009-01-16 at 10:07 -0500, Brian Wheeler wrote:
> I just ran an update via yum and now yum gives me this error:
> 
> [root at wombat gg]# yum list \*google\*
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 4, in <module>
>     import yum
>   File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 49, in <module>
>     import config
>   File "/usr/lib/python2.6/site-packages/yum/config.py", line 27, in <module>
>     from parser import ConfigPreProcessor
>   File "/usr/lib/python2.6/site-packages/yum/parser.py", line 3, in <module>
>     import urlgrabber
>   File "/usr/lib/python2.6/site-packages/urlgrabber/__init__.py", line 53, in <module>
>     from grabber import urlgrab, urlopen, urlread
>   File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 410, in <module>
>     import keepalive
>   File "/usr/lib/python2.6/site-packages/urlgrabber/keepalive.py", line 444, in <module>
>     class HTTPSConnection(httplib.HTTPSConnection):
> AttributeError: 'module' object has no attribute 'HTTPSConnection'
> 

I have a feeling it is related to the openssl update that just went out.

-sv




From limb at jcomserv.net  Fri Jan 16 15:15:09 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 16 Jan 2009 09:15:09 -0600 (CST)
Subject: asciidoc abandoned?
In-Reply-To: <20090116025337.GD6975@x200.localdomain>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
	<20090116025337.GD6975@x200.localdomain>
Message-ID: <27fc9c0f23cf9a283c90a9f7518b5611.squirrel@mail.jcomserv.net>


> * Jon Ciesla (limb at jcomserv.net) wrote:
>> Horst, I've been playing with this, and 8.2.7 fixes your issue, and
>> according to the changelog:
>>
>> http://www.methods.co.nz/asciidoc/CHANGELOG.html
>>
>> there are not major compatibility issues WRT 8.2.5.  The ACLs allow
>> provenpackagers to commit, and I am one, so in the event the neither
>> Chris
>> nor Florian gets back to us I can at least build and push 8.2.7 for F-10
>> and F-9.  Then we can discuss 8.3.3 for rawhide, including compat
>> issues,
>> dependencies, etc.
>
> Fine by me.  Just need to double check at least git against it.

Hmm, git build error on F-10 with 8.2.7:

asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
                 -a docbook-xsl-172 -agit_version=1.6.1 -o git-add.html+
git-add.txt
ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11.css
ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-manpage.css
ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-quirks.css
make[1]: *** [git-add.html] Error 1
make[1]: Leaving directory
`/home/limb/rpmbuild/BUILD/git-1.6.1/Documentation'
make: *** [doc] Error 2


> thanks,
> -chris
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From bdwheele at indiana.edu  Fri Jan 16 15:16:47 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Fri, 16 Jan 2009 10:16:47 -0500
Subject: yum on rawhide broken?
In-Reply-To: <1232118691.4912.11.camel@rosebud>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
	<1232118691.4912.11.camel@rosebud>
Message-ID: <1232119007.23820.39.camel@nibbler.dlib.indiana.edu>

On Fri, 2009-01-16 at 10:11 -0500, seth vidal wrote:
> On Fri, 2009-01-16 at 10:07 -0500, Brian Wheeler wrote:
> > I just ran an update via yum and now yum gives me this error:
> > 
> > [root at wombat gg]# yum list \*google\*
> > Traceback (most recent call last):
> >   File "/usr/bin/yum", line 4, in <module>
> >     import yum
> >   File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 49, in <module>
> >     import config
> >   File "/usr/lib/python2.6/site-packages/yum/config.py", line 27, in <module>
> >     from parser import ConfigPreProcessor
> >   File "/usr/lib/python2.6/site-packages/yum/parser.py", line 3, in <module>
> >     import urlgrabber
> >   File "/usr/lib/python2.6/site-packages/urlgrabber/__init__.py", line 53, in <module>
> >     from grabber import urlgrab, urlopen, urlread
> >   File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 410, in <module>
> >     import keepalive
> >   File "/usr/lib/python2.6/site-packages/urlgrabber/keepalive.py", line 444, in <module>
> >     class HTTPSConnection(httplib.HTTPSConnection):
> > AttributeError: 'module' object has no attribute 'HTTPSConnection'
> > 
> 
> I have a feeling it is related to the openssl update that just went out.
> 
> -sv
> 
> 

Probably, but I've been trying the symlink fixes here and I'm not seeing
any improvements.

Love that rawhide :)

Brian



From ggw at wolves.durham.nc.us  Fri Jan 16 15:17:35 2009
From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury)
Date: Fri, 16 Jan 2009 10:17:35 -0500
Subject: sis900 module not being included in initrd.img? (bz479327)
Message-ID: <4970A50F.4090200@wolves.durham.nc.us>

I've been having trouble getting rawhide to install on my ix86 test
machine due to a missing network module (sis900)

I've examined the configs in the recent kernel packages and the module
is enable and appears to build; however, it is not present in the
initrd.img files that appear in the rawhide updates.

I'm not sure where to look further for information about what happens to
this module.  The koji task succedes building the i686 kernel, but the
initrd.img archive fails to contain the module.

I entered a bugzilla (#479327) against the kernel, bit it's gotten no
attention in a week.  Should the bug be reassigned to mkinitrd or some
other component?

Is anyone really interested in missing modules in initrd.img?

-- 
G.Wolfe Woodbury
RHCT (retired)
Fedora Tester



From bdwheele at indiana.edu  Fri Jan 16 15:19:47 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Fri, 16 Jan 2009 10:19:47 -0500
Subject: yum on rawhide broken?
In-Reply-To: <1232119007.23820.39.camel@nibbler.dlib.indiana.edu>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
	<1232118691.4912.11.camel@rosebud>
	<1232119007.23820.39.camel@nibbler.dlib.indiana.edu>
Message-ID: <1232119187.23820.40.camel@nibbler.dlib.indiana.edu>

On Fri, 2009-01-16 at 10:16 -0500, Brian Wheeler wrote:
> Probably, but I've been trying the symlink fixes here and I'm not seeing
> any improvements.
> 
> Love that rawhide :)
> 
> Brian
> 

Actually, symlinking the libcrypto.so libraries makes it work.

Brian




From skvidal at fedoraproject.org  Fri Jan 16 15:24:34 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Jan 2009 10:24:34 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkon30$q8s$3@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
	<20090115204156.GA30791@nostromo.devel.redhat.com>
	<gkoaee$ojq$1@ger.gmane.org> <1232055829.14403.1707.camel@rosebud>
	<gkon30$q8s$3@ger.gmane.org>
Message-ID: <1232119474.4912.17.camel@rosebud>

On Fri, 2009-01-16 at 02:15 +0100, Kevin Kofler wrote:
> seth vidal wrote:
> > they don't help the problem at all, they just introduce a whole other
> > set of difficulties as to what the default behavior should be when we
> > hit them.
> 
> Here's how I see things (which I believe is close if not identical to how it
> works on Debian):
> 
> Recommended = default on.
> Suggested = default off.
> The user can customize it to have both on or both off.
> 
> And in both cases, removing a package with only a soft dep should not remove
> the dependent package (except if an option to treat them as hard deps is
> set).

Right, I just don't see the above making our situation any better at
all.

-sv




From tmz at pobox.com  Fri Jan 16 15:28:21 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 16 Jan 2009 10:28:21 -0500
Subject: asciidoc abandoned?
In-Reply-To: <27fc9c0f23cf9a283c90a9f7518b5611.squirrel@mail.jcomserv.net>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
	<20090116025337.GD6975@x200.localdomain>
	<27fc9c0f23cf9a283c90a9f7518b5611.squirrel@mail.jcomserv.net>
Message-ID: <20090116152821.GK18365@inocybe.teonanacatl.org>

Jon Ciesla wrote:
> Hmm, git build error on F-10 with 8.2.7:
>
> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
>                 -a docbook-xsl-172 -agit_version=1.6.1 -o git-add.html+
> git-add.txt
> ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11.css
> ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-manpage.css
> ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11-quirks.css
> make[1]: *** [git-add.html] Error 1
> make[1]: Leaving directory
> `/home/limb/rpmbuild/BUILD/git-1.6.1/Documentation'
> make: *** [doc] Error 2

Can you try adding ASCIIDOC8=YesPlease in the make_git macro, just
above DOCBOOK_XSL_172=YesPlease?

And if that builds, diffing the man pages and/or carefully inspecting
them visually for regressions from their current state would be a good
idea.  You could even tar up the man pages and post them and others
could poke through them a bit to check for problems.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Never underestimate the power of very stupid people in large groups.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/4ab5f5d3/attachment.sig>

From skvidal at fedoraproject.org  Fri Jan 16 15:28:28 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Jan 2009 10:28:28 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoobo$2km$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<gklo5h$9gm$1@ger.gmane.org> <1232037920.14403.1610.camel@rosebud>
	<gkoobo$2km$1@ger.gmane.org>
Message-ID: <1232119708.4912.20.camel@rosebud>

On Fri, 2009-01-16 at 02:36 +0100, Kevin Kofler wrote:
> > New stuff showing up in the repo is completely unrelated to the groups.
> 
> ... which is exactly why it shouldn't get installed just because it got
> added to some group. :-)

The above is what yum groupupdate groupname does right now.



> Well, I think that with the suggested changes, there will be a lots of
> complaints about unwanted packages getting installed.
> 
> But what do I care? I can just remove all the metapackages. It's average
> users who are going to get hurt (i.e. exactly the people you're trying to
> help). :-(

How about we try it and place a little bet on it :)



> > Which is why we can do groups of groups and more precisely break them
> > down into smaller sections. so you install what you need, not the whole
> > world.
> 
> That sounds reasonable, but I'm not sure it's going to scale. If we end up
> with one group per package, we're failing.

If we end up with that. I doubt we will.

> 
> > I suspect most users never know what comps is and they do all their
> > discovery by doing:
> > yum search someword
> > or
> > yum list somepkgnametheyknow
> 
> You think most people don't use the GUIs? I'm not claiming you're wrong
> because I don't have any stats, but are you sure?

I think browsing even in the GUIs is a disaster area. It's like this -
when was the last time you used yahoo to 'browse the internet'? When was
the last time you used google?

Browsing 10000 pkgs is like browsing the internet - it's a completely
mess if you try it.

-sv




From james at fedoraproject.org  Fri Jan 16 15:29:29 2009
From: james at fedoraproject.org (James Antill)
Date: Fri, 16 Jan 2009 10:29:29 -0500
Subject: yum on rawhide broken?
In-Reply-To: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <1232119769.4934.103.camel@code.and.org>

On Fri, 2009-01-16 at 10:07 -0500, Brian Wheeler wrote:
> I just ran an update via yum and now yum gives me this error:
> 
> [root at wombat gg]# yum list \*google\*
> Traceback (most recent call last):
>   File "/usr/bin/yum", line 4, in <module>
>     import yum
>   File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 49, in <module>
>     import config
>   File "/usr/lib/python2.6/site-packages/yum/config.py", line 27, in <module>
>     from parser import ConfigPreProcessor
>   File "/usr/lib/python2.6/site-packages/yum/parser.py", line 3, in <module>
>     import urlgrabber
>   File "/usr/lib/python2.6/site-packages/urlgrabber/__init__.py", line 53, in <module>
>     from grabber import urlgrab, urlopen, urlread
>   File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 410, in <module>
>     import keepalive
>   File "/usr/lib/python2.6/site-packages/urlgrabber/keepalive.py", line 444, in <module>
>     class HTTPSConnection(httplib.HTTPSConnection):
> AttributeError: 'module' object has no attribute 'HTTPSConnection'

 This happens when openssl breaks, you can probably search for HTTPS in
keepalive and just delete those two classes (although it looks like only
the second one is failing).
 Of course you may find that hashlib.sha1 doesn't work anymore too, at
which point you're out of luck.

-- 
James Antill <james at fedoraproject.org>
Fedora



From skvidal at fedoraproject.org  Fri Jan 16 15:29:44 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Jan 2009 10:29:44 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <alpine.DEB.1.10.0901160926310.32512@gotcha.dreamhost.com>
References: <1231962712.14403.1559.camel@rosebud>
	<gklo5h$9gm$1@ger.gmane.org> <1232037920.14403.1610.camel@rosebud>
	<gkoobo$2km$1@ger.gmane.org>
	<alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
	<4970329B.2050904@leemhuis.info>
	<alpine.DEB.1.10.0901160926310.32512@gotcha.dreamhost.com>
Message-ID: <1232119784.4912.21.camel@rosebud>

On Fri, 2009-01-16 at 09:48 +0200, Panu Matilainen wrote:
> On Fri, 16 Jan 2009, Thorsten Leemhuis wrote:
> 
> > On 16.01.2009 07:34, Panu Matilainen wrote:
> >> On Fri, 16 Jan 2009, Kevin Kofler wrote:
> >>> seth vidal wrote:
> >>> 
> >>>> Really? Who is making the plans for soft deps. Doesn't seem like it at
> >>>> the rpm layer.
> >>> Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
> >>> would be unfortunate, because I think they could be useful, I've seen
> >>> several cases where they would have helped (just one example: Kile (a 
> >>> LaTeX
> >>> editor) can call many tools, most users will want them dragged in, but 
> >>> some
> >>> don't and Kile will still work, with reduced functionality, without them -
> >>> just grep for Requires(hint) in packages (mostly those touched by Rex
> >>> Dieter) to see more places where we'd like soft dependencies) and Debian
> >>> fans keep making fun of us because we don't have them ;-).
> >> It hasn't been dropped, only post-poned until we figure out a bunch of 
> >> details.
> >
> > I don't want to get tracked into the discussions if "Requires(hint)" and 
> > other soft deps make sense to support in rpm/yum or not.
> >
> > But if conditionals really go away in comps it would be really nice for 
> > external repos like RPM Fusion to have a alternative way to automatically get 
> > (for example(?) ) xine-lib-extras-freeworld installed if the users installs 
> > (or already has installed) xine-lib.
> >
> > Something like that is afaics needed to make things "just work" (?) -- and 
> > that's what we all want, isn't it?
> 
> Yup, I remember sorely missing the ability to do this in "former life".
> 
> This is the "enhances" use-case, which is why it typically gets bundled up 
> with soft-dependencies. Only it's got relatively little to do with the 
> elasticity of a dependency, this would be a reverse dependency (whether 
> it's soft or not is another issue), which is a completely new dependency 
> class and the reason "enhances" is such a platypus.

And it means we have to cope with stupidity like:
Enhances: glibc

which pulls in the pkg for EVERYONE.

-sv




From caillon at redhat.com  Fri Jan 16 15:49:33 2009
From: caillon at redhat.com (Christopher Aillon)
Date: Fri, 16 Jan 2009 10:49:33 -0500
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <m3zlhscobw.fsf@ursa.amorsen.dk>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<m3zlhscobw.fsf@ursa.amorsen.dk>
Message-ID: <4970AC8D.4090803@redhat.com>

On 01/15/2009 03:21 PM, Benny Amorsen wrote:
> Not again. Why does openssl make us suffer so?

Because you haven't ported your app to use NSS yet.  Perhaps now is a 
good time to reconsider, or bring it up with your project's upstream. 
Because of openssl's design, this will keep happening at the openssl's 
developers whim.

https://bugzilla.redhat.com/show_bug.cgi?id=333741



From williams at redhat.com  Fri Jan 16 15:50:18 2009
From: williams at redhat.com (Clark Williams)
Date: Fri, 16 Jan 2009 09:50:18 -0600
Subject: yum on rawhide broken?
In-Reply-To: <1232119187.23820.40.camel@nibbler.dlib.indiana.edu>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
	<1232118691.4912.11.camel@rosebud>
	<1232119007.23820.39.camel@nibbler.dlib.indiana.edu>
	<1232119187.23820.40.camel@nibbler.dlib.indiana.edu>
Message-ID: <20090116095018.3abd2c8a@torg>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jan 2009 10:19:47 -0500
Brian Wheeler <bdwheele at indiana.edu> wrote:

> On Fri, 2009-01-16 at 10:16 -0500, Brian Wheeler wrote:
> > Probably, but I've been trying the symlink fixes here and I'm not seeing
> > any improvements.
> > 
> > Love that rawhide :)
> > 
> > Brian
> > 
> 
> Actually, symlinking the libcrypto.so libraries makes it work.
> 
> Brian
> 
> 

For the record I had to:

# cd /lib64
# ln -s libssl.so.0.9.8j libssl.so.7
# ln -s libcrypto.so.0.9.8j libcrypto.so.7

to get both sudo and yum functional. Obviously you'd go to /lib on a
32-bit system.

Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAklwrL4ACgkQHyuj/+TTEp0LUwCcC9Xu80zJwDwYqvnt7xFrtc77
eyMAoN5yTQi/b9z5C/h8NCJa+4Ar/MpJ
=6rYl
-----END PGP SIGNATURE-----



From limb at jcomserv.net  Fri Jan 16 16:08:59 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 16 Jan 2009 10:08:59 -0600 (CST)
Subject: asciidoc abandoned?
In-Reply-To: <20090116152821.GK18365@inocybe.teonanacatl.org>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<853bdac145c080ab91b978b654b6684c.squirrel@mail.jcomserv.net>
	<20090116025337.GD6975@x200.localdomain>
	<27fc9c0f23cf9a283c90a9f7518b5611.squirrel@mail.jcomserv.net>
	<20090116152821.GK18365@inocybe.teonanacatl.org>
Message-ID: <daf4a7d8c9ca2168a6d9cf7c40e438ea.squirrel@mail.jcomserv.net>


> Jon Ciesla wrote:
>> Hmm, git build error on F-10 with 8.2.7:
>>
>> asciidoc -b xhtml11 -d manpage -f asciidoc.conf \
>>                 -a docbook-xsl-172 -agit_version=1.6.1 -o git-add.html+
>> git-add.txt
>> ERROR: unsafe: include file: /etc/asciidoc/./stylesheets/xhtml11.css
>> ERROR: unsafe: include file:
>> /etc/asciidoc/./stylesheets/xhtml11-manpage.css
>> ERROR: unsafe: include file:
>> /etc/asciidoc/./stylesheets/xhtml11-quirks.css
>> make[1]: *** [git-add.html] Error 1
>> make[1]: Leaving directory
>> `/home/limb/rpmbuild/BUILD/git-1.6.1/Documentation'
>> make: *** [doc] Error 2
>
> Can you try adding ASCIIDOC8=YesPlease in the make_git macro, just
> above DOCBOOK_XSL_172=YesPlease?

Same thing.

> And if that builds, diffing the man pages and/or carefully inspecting
> them visually for regressions from their current state would be a good
> idea.  You could even tar up the man pages and post them and others
> could poke through them a bit to check for problems.
>
> --
> Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Never underestimate the power of very stupid people in large groups.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From james at fedoraproject.org  Fri Jan 16 16:10:01 2009
From: james at fedoraproject.org (James Antill)
Date: Fri, 16 Jan 2009 11:10:01 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <4970329B.2050904@leemhuis.info>
References: <1231962712.14403.1559.camel@rosebud>
	<gklo5h$9gm$1@ger.gmane.org>	<1232037920.14403.1610.camel@rosebud>
	<gkoobo$2km$1@ger.gmane.org>
	<alpine.DEB.1.10.0901160823090.32512@gotcha.dreamhost.com>
	<4970329B.2050904@leemhuis.info>
Message-ID: <1232122201.4934.109.camel@code.and.org>

On Fri, 2009-01-16 at 08:09 +0100, Thorsten Leemhuis wrote:

> I don't want to get tracked into the discussions if "Requires(hint)" and 
> other soft deps make sense to support in rpm/yum or not.
> 
> But if conditionals really go away in comps it would be really nice for 
> external repos like RPM Fusion to have a alternative way to 
> automatically get (for example(?) ) xine-lib-extras-freeworld installed 
> if the users installs (or already has installed) xine-lib.

 I think the main point that should be made here is that group
conditionals _don't_ solve this, it requires the user to install the
"correct group" while rpmfusion is enabled.
 In fact the proposed change of how comps/groups works would actually
solve this much more often (as if you had group FOO installed, and then
enabled rpmfusion you'd get the new packages). But even then it requires
the user has installed the "correct group" at some point.

 As Panu says, I think enhances support solves this problem and it'll
just work.

-- 
James Antill <james at fedoraproject.org>
Fedora



From jarod at redhat.com  Fri Jan 16 16:35:44 2009
From: jarod at redhat.com (Jarod Wilson)
Date: Fri, 16 Jan 2009 11:35:44 -0500
Subject: Plan for tommorow's (20090116) FESCo meeting
In-Reply-To: <da159fda0901152212t1286118by482f00c12e3f4152@mail.gmail.com>
References: <da159fda0901151716k7d6bd0eeif262d3a55dda37f1@mail.gmail.com>
	<da159fda0901152212t1286118by482f00c12e3f4152@mail.gmail.com>
Message-ID: <200901161135.44785.jarod@redhat.com>

On Friday 16 January 2009 01:12:06 Jon Stanley wrote:
> On Thu, Jan 15, 2009 at 8:16 PM, Jon Stanley <jonstanley at gmail.com> wrote:
> 
> > I have not yet added features to the agenda, they are on the wiki in
> > the category FeaturesReadyForFesco. I will add trac tickets for them
> > when I get back tonight.
> 
> I have added all the features to the agenda, it's quite a full plate
> for tomorrow.
> 
> 12	New Sponsor Request: Lubomir Rintel (lkundrak)
> 14	New Sponsor Request: Itamar Reis Peixoto
> 19	CUPS PolicyKit Integration
> 20	Debuginfo Revamp
> 21	ext4 default filesystem
> 22	Gnome 2.26
> 23	Live System for the DVD Image
> 24	Review O' Matic
> 25	Xfce 4.6
> 10	Review list of non-provenpackager committable packages
> 11	Review FPC report
> 13	FESCo needs to determine whether ovm is acceptable content
> 18	FPC item for approval
> 
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
> 
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor.

I could have sworn there was at least one more sponsor request, if not two...

-- 
Jarod Wilson
jarod at redhat.com



From vonbrand at inf.utfsm.cl  Fri Jan 16 16:36:15 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 13:36:15 -0300
Subject: yum on rawhide broken?
In-Reply-To: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
References: <1232118450.23820.32.camel@nibbler.dlib.indiana.edu>
Message-ID: <200901161636.n0GGaFpr028928@laptop14.inf.utfsm.cl>

Brian Wheeler <bdwheele at indiana.edu> wrote:
> I just ran an update via yum and now yum gives me this error:

openssl breakage. The symlinks /lib{,64}/lib{ssl,crypto}.so.7 point at
Saturn's rings (really, at the _old_ versions of the libraries, which were
erased, leaving dangling symlinks). Fix them by hand to point at the right
versions.
-- 
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 jkeating at redhat.com  Fri Jan 16 16:56:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 08:56:13 -0800
Subject: [Fedora-spins] Spins SIG Meeting(s) / Agenda!
In-Reply-To: <496FEA01.1090506@fedoraproject.org>
References: <496DD9E6.2050800@kanarip.com> <496E4B4C.6050103@redhat.com>
	<496E67C0.20609@kanarip.com> <496F0A4B.5090504@fedoraproject.org>
	<496F24F4.7090009@kanarip.com> <496F302F.6030905@fedoraproject.org>
	<496F3327.40903@kanarip.com> <496F38E4.1060108@fedoraproject.org>
	<20090115135658.GC2582@yoda.jdub.homelinux.org>
	<496F482B.8090802@fedoraproject.org>	<20090115152712.GB7579@wolff.to>
	<496F56AB.4060809@fedoraproject.org> <gkom4v$q8s$1@ger.gmane.org>
	<496FE129.6060404@fedoraproject.org>
	<1232069293.5086.169.camel@localhost.localdomain>
	<496FE4AC.9060001@fedoraproject.org>
	<1232070667.5086.170.camel@localhost.localdomain>
	<496FEA01.1090506@fedoraproject.org>
Message-ID: <1232124973.5086.171.camel@localhost.localdomain>

On Fri, 2009-01-16 at 07:29 +0530, Rahul Sundaram wrote:
> 
> The point wasn't to find out whom to blame. Just saying that is one 
> instance which clearly did demonstrate that we need to avoid changes in 
> the compose environment.  I have run into issues with other package 
> updates in rawhide (GDM broke Xfce session once, yum failed to dep solve 
> properly at another time and so on ) breaking the compose in regular 
> intervals as well. So not just a livecd-tools specific thing.

Well, until we get to GA, the compose environment changes daily, just
like rawhide.  Because it /is/ rawhide.  And if we have to fix
something, we're not going to wait until the next day's rawhide to do
composes, we'll pull that fix directly from koji or from git.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/1704f831/attachment.sig>

From denis at poolshark.org  Fri Jan 16 17:00:23 2009
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 16 Jan 2009 18:00:23 +0100
Subject: The move to libgda 4.0
In-Reply-To: <49706990.1020200@hhs.nl>
References: <497065D0.5090506@poolshark.org> <49706990.1020200@hhs.nl>
Message-ID: <4970BD27.3070308@poolshark.org>

Hans de Goede wrote:
> Denis Leroy wrote:
>> I've been investigating the move to libgda 3.99.8 (4.0 API) for Fedora 
>> 11. The 4.0 API is apparently stable now, and based on the F-11 
>> release timeframe, upstream does recommend it. There's also a growing 
>> number of projects working with the 4.0 API already and I've received 
>> a request for this for an Anjuta plugin 
>> (https://bugzilla.redhat.com/show_bug.cgi?id=479298).
>>
>> There are currently 4 packages that depend on the 3.0 API: glom, 
>> gnome-python2-extras, qof and gnumeric-plugins-extras. The port to 4.0 
>> appears to be non-trivial 
>> (http://library.gnome.org/devel/libgda-4.0/3.99/migration-2.html). We 
>> can probably work out a patch for something like the gnumeric plugin, 
>> but I don't know how much work would be required to port 
>> gnome-python2-extras for example. Glom still uses the 3.0 API, but the 
>> 4.0 port is almost finished in SVN.
>>
>> 2 options here:
>>
>> 1. Wait for glom to release its 4.0 API port, ping upstream for other 
>> dependencies or work on patches. Not yet clear how much work is 
>> required for this.
>>
>> 2. Revive the compat-libgda package (currently a dead.package, we used 
>> to have it for the 2.0 API when 2.99 was packaged) for the 3.0 API and 
>> move libgda to 3.99. Would this require a new package review ?
>>
> 
> Depends on if there is more then just a name change. Are libgda3 and 
> libgda4 parallel installable (including their -devel) without requiring 
> any hacks to libgda3 ? (We do not want to hack libgda4, as then we would 
> need to carry those hacks for a potential long time).

They are parallel-installable, the ABI suffix is used everywhere, 
including on the /usr/bin executables.



From kwade at redhat.com  Fri Jan 16 17:27:00 2009
From: kwade at redhat.com (Karsten Wade)
Date: Fri, 16 Jan 2009 09:27:00 -0800
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <gknfh5$9ss$1@ger.gmane.org>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
Message-ID: <20090116172700.GU7770@calliope.phig.org>

On Thu, Jan 15, 2009 at 07:59:57AM -0600, Rex Dieter wrote:
> Operator (postnuke.tv) wrote:
> 
> > The Zikula project might be very interested... You could have Zikula
> > deployed with the project's help and support?
> > Moreover, at some point in the near future, we'd like to be providing
> > a Fedora RPM for the FC distrib.
> 
> The latter, being packaged and included in fedora, is pretty much a
> prerequisite for consideration, so... the sooner the better.

+1

This falls under "working within Fedora Infrastructure."

The deployment could be done in parallel with packaging, but the
packaging would have to be in earnest, and we'd need to recruit a
sponsor superfast.

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/e3463688/attachment.sig>

From kwade at redhat.com  Fri Jan 16 17:54:34 2009
From: kwade at redhat.com (Karsten Wade)
Date: Fri, 16 Jan 2009 09:54:34 -0800
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<8278b1b0901150616p1b15588ev91199a9f6fea48bc@mail.gmail.com>
	<20090115152044.GC5966@localhost.localdomain>
	<8278b1b0901151759j26a6532cxa69593d9a42aecd2@mail.gmail.com>
Message-ID: <20090116175434.GV7770@calliope.phig.org>

On Thu, Jan 15, 2009 at 07:59:17PM -0600, King InuYasha wrote:
> Yes, I would be willing to maintain the system if you guys wanted me to.

We also had some good discussions with you on IRC as follow-up.

> Also, I have answers for some of the items on the list just so that I could
> expand on my belief that Enano could get the job done.

I'll also reply to a few items inline:


> """""""""""""""
> * Good security record
> Enano has a good security record, it had few holes in it during its
> development period, and these were quickly spotted and plugged up nicely
> * Proactive, security minded developer community that is ...
> Enano was designed with security in mind, and the developer absolutely
> believes security is top priority
> * Highly responsive, especially to security issues
> The Developer will react VERY quickly to any security issues and fix them
> ASAP

Mike McGrath reminded me there are things we can do to mitigate
security risks, such as isolating the system, but I appreciate the
proactive security approach.

> * Flexible enough auth system to attach to FAS
> Possible. Enano 1.1.x-hg uses HMAC-SHA1 for password storage, and
> DiffieHellman + AES192 for password transmission (that is the whole
> backend). I'm not sure what FAS2 uses for auth system, but it will be likely
> that the auth system backend in Enano would be entirely rewritten for FAS2
> unless FAS2 were to adopt our system. Somehow, I doubt that Fedora would
> adopt OUR system for authentication :)

In IRC, we talked with Toshio for a few minutes.  IIRC, you were going
to look in to the JSON interface to FAS2.

> * L10n that doesn't break the translator workflow
> I have no idea what this means.
> * Output for Transifex (PO/POT)
> Could be done with a helper script according to the Developer.

These two are related.  All software and documentation in Fedora is
translated using PO/POT files.  Many translators use Transifex
(https://l10n.fedoraproject.org) to submit translations.  This
requires that the PO/POT files be put into a version control system.

However, all of that is worked out in advance of building for the
CMS.  We put active content in to projects on fedorahosted.org, where
the PO/POT files live.  The CMS mainly needs to take the rendered HTML
and PDFs (where the toolchain takes PO + XML and creates the
per-language versions of the build document.)  It also needs to keep
track of versions in some way, ideally the same version information
as the actual doc package.

> * Content workflow (write <=> edit => publish)
> No idea what this means.

In my mind, this is the core of what a CMS does.

It lets you create several groups:

* Writers -- can input content up to draft mode; drafts can be
  restricted from being publically viewable, or are shown as clearly
  drafts and not finished work.

* Editors -- can approve/disapprove content.  Some CMS workflows do
  not allow an editor to actually rewrite the content; their only
  choice is to push back to a writer or push ahead to publish.  I
  personally think we should have editors able to make changes in the
  writing; the Docs Project can make that decision.

* Publishers -- take content and push it live as either early-release
  drafts or final content.

People can fill one or more of these roles, even for the same
content.  The key is to make sure that a piece of content is not
published as complete without having an editor read and approve.
However, a team of people could share the effort -- one person writes
Chapter A, one writes Chapter B, and they edit each other's chapters.

> * Content expiration (automatic)
> Not sure, but I think this could be done through a plugin

The idea here is to be able to designate a piece of content as only
relevant for a version of Fedora, and when that version is EOL, the
content is marked as EOL/deprecated.  We don't want to make content
disappear; it remains useful to people who choose not to upgrade.  But
we want to make it clear that we are not supporting content from five
releases ago. :)

> * Multiple roles, e.g. writer, team lead, editor, publisher, managing editor
> Defintely. Group support is in Enano and through its ACLs it is possible to
> set the exact correct permissions for each group to suit its role

OK, and I presume the capabilities tie to the write/edit/publish paradigm.

> * Integrate with FAS
> I'm not sure of the integration points for FAS2 for Enano. It was actually
> because our efforts to get the Fedora Project to use Enano last summer that
> Enano now has Postgres support, so if FAS2 uses Postgres as a backend, it
> could be done through that. A method will have to be investigated.

Toshio specified in IRC that direct access to the db is not likely.

> * Handle making certain pages or content areas static/non-database driven,
> such as for scaling during times of heavy resource demand
> Can be done with adding a plugin

This may or may not matter; the last few releases have handled the
additional load with proxies and caching.  I put it in as a
requirement as a just-in-case feature.

- Karsten
-- 
Karsten 'quaid' Wade, Community Gardener
http://quaid.fedorapeople.org
AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/5e58e723/attachment.sig>

From mw_triad at users.sourceforge.net  Fri Jan 16 17:59:28 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 16 Jan 2009 11:59:28 -0600
Subject: comps discussion at fudcon and the future
In-Reply-To: <49705113.4080203@redhat.com>
References: <1231962712.14403.1559.camel@rosebud>
	<496F5A75.30007@redhat.com>	<gkoak3$qhf$1@ger.gmane.org>
	<49705113.4080203@redhat.com>
Message-ID: <gkqhu1$al0$1@ger.gmane.org>

Florian Festi wrote:
> Matthew Woehlke wrote:
>> Florian Festi wrote:
>>> Multilib:
>>> The situation has changed a lot since we introduced multilib. The
>>>  challenge who is going to support 64bit processors first has
>>> been decided long ago and the age of 32bit processors is ending.
>>
>> No it isn't. [snip]
> 
> Ok, I should probably a bit more precise: 32 bit being default on 64 bit 
> capable computers is coming to an end as the default RAM size for 
> desktops goes beyond 4GB.

Yes, that's better :-). That said, why on earth would you want to run 
32-bit processes on a 64-bit OS when 64-bit flavors are available?

I can think of exactly two reasons. One, there is no 64-bit version 
available (which is rare with Free Software, but can happen if you have 
some proprietary software you need to run). Two, because you are 
building 32-bit programs intended to be shipped to a 32-bit-only OS.

Other than that, my experience seems to be that 32-bit processes on a 
64-bit OS run slower than pure 64-bit flavors, but the above are IMO 
both valid reasons to keep multilib around.

>> Other than perhaps binutils, why would you ever have a 32-bit binary 
>> on a 64-bit system? ;-) Or do you include libs in "binaries"?
> 
> There are several reasons to do so: Third party software that is not build
> for 64 bit, software like firefox that uses plugins that are only available
> in 32 bit, building software or content for 32 bit and may be some more.

Okay, basically the same list I came up with :-).

> Multilib is not going to go away in the sense that you still will be 
> able to 32 bit software on a 64 bit installation. But it already got 
> away in the sense that we do no longer install 32 bit libs by default. 

Ah. Yes, this is a good thing. No one should ever have i*86 libraries 
installed on an x86_64 system unless they have specifically asked for 
them. :-) (I count 'installing something with i*86 dependencies as 
"specifically asking".)

It sounds like we are generally in agreement.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"I can hear you / just barely hear you / I can just barely hear you"
   -- "I Can Hear You", by They Might Be Giants



From zaitcev at redhat.com  Fri Jan 16 18:03:40 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 16 Jan 2009 11:03:40 -0700
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232111406.18033.18.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
Message-ID: <20090116110340.4ebb47b6.zaitcev@redhat.com>

On Fri, 16 Jan 2009 14:10:06 +0100, Christoph H?ger <choeger at cs.tu-berlin.de> wrote:

> 16840 root      20   0  577m 250m  11m S  3.7 12.6  22:10.17 Xorg
> So where did my memory go? And who of you guys has it? I want it back ;)

On my box it looks like this:
 3115 root      20   0  466m  43m  10m S  0.3  2.3   1:18.40 Xorg

A quick look at /proc/3115/maps shows that only 32MB of this
is used to map the framebuffer (I have a Radeon, DRI is active).

The biggest chunk, 270MB, is used to map shared libraries.
We sure have a lot of useless code and rodata in there. For example,
libdbus uses 2.3MB. Seriously, DBus? Then we have XML parser, etc.
Even libpciaccess uses 2MB! For comparison, the whole of libc fits
into 1.5MB.

Second biggest chunk, 55MB, is the heap, which is what librestop shows.
The framebuffer is only the third.

Among the three of them, the above cover 357MB or 87% of the virtual
memory. The rest is gone to small things like DRI, X modules, SYSV IPC,
and process stacks.

My TLB is crying for mercy trying to cover all that.

-- Pete



From skvidal at fedoraproject.org  Fri Jan 16 18:12:29 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 16 Jan 2009 13:12:29 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkqhu1$al0$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<496F5A75.30007@redhat.com>	<gkoak3$qhf$1@ger.gmane.org>
	<49705113.4080203@redhat.com>  <gkqhu1$al0$1@ger.gmane.org>
Message-ID: <1232129549.4912.35.camel@rosebud>

On Fri, 2009-01-16 at 11:59 -0600, Matthew Woehlke wrote:

> Ah. Yes, this is a good thing. No one should ever have i*86 libraries 
> installed on an x86_64 system unless they have specifically asked for 
> them. :-) (I count 'installing something with i*86 dependencies as 
> "specifically asking".)

In fedora 9 we switched yum from being: default to installing both to
default to installing the 'best' arch (which is not always 64bit on all
processors).

-sv




From jkeating at redhat.com  Fri Jan 16 18:15:11 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 10:15:11 -0800
Subject: sis900 module not being included in initrd.img? (bz479327)
In-Reply-To: <4970A50F.4090200@wolves.durham.nc.us>
References: <4970A50F.4090200@wolves.durham.nc.us>
Message-ID: <1232129711.5086.174.camel@localhost.localdomain>

On Fri, 2009-01-16 at 10:17 -0500, G.Wolfe Woodbury wrote:
> I've been having trouble getting rawhide to install on my ix86 test
> machine due to a missing network module (sis900)
> 
> I've examined the configs in the recent kernel packages and the module
> is enable and appears to build; however, it is not present in the
> initrd.img files that appear in the rawhide updates.
> 
> I'm not sure where to look further for information about what happens to
> this module.  The koji task succedes building the i686 kernel, but the
> initrd.img archive fails to contain the module.
> 
> I entered a bugzilla (#479327) against the kernel, bit it's gotten no
> attention in a week.  Should the bug be reassigned to mkinitrd or some
> other component?
> 
> Is anyone really interested in missing modules in initrd.img?
> 
> -- 
> G.Wolfe Woodbury
> RHCT (retired)
> Fedora Tester

There was some anaconda code committed in this area today, things might
be better tomorrow.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/8acf36a4/attachment.sig>

From hughsient at gmail.com  Fri Jan 16 18:21:33 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 16 Jan 2009 18:21:33 +0000
Subject: PackageKit translations
In-Reply-To: <1232116180.3455.6.camel@localhost.localdomain>
References: <1232103326.20781.21.camel@hughsie-work.lan>
	<1232116180.3455.6.camel@localhost.localdomain>
Message-ID: <1232130093.20781.103.camel@hughsie-work.lan>

On Fri, 2009-01-16 at 12:29 -0200, Igor Pires Soares wrote:
> Em Sex, 2009-01-16 ?s 10:55 +0000, Richard Hughes escreveu:
> > In a couple of weeks time they'll be a new PackageKit release that we'll
> > see in F11.
> > 
> > Before that time, I would like the translations for PackageKit to be
> > updated -- updated translations are very important for the F11 release
> > quality and also for the F10 backport. There are still quite a few
> > important languages missing and others that are quite incomplete.
> > 
> > You can see the current stats here:
> > 
> > http://translate.fedoraproject.org/module/packagekit#master
> 
> I'm not sure about these stats. Fedora's Damned Lies differs from the
> GNOME instance:

This seemed odd to me too.

> http://l10n.gnome.org/module/packagekit/
> 
> Richard, can you confirm which one is right?

Neither. The gnome instance looks old (el has been in LINGUAS for quite
some months) and the Fedora instance has a reference to
contrib/gtk-module/PackageKitGtkModule.schemas.in which hasn't been
around for a few weeks either. Maybe I'm doing something wrong.

Richard.




From jkeating at redhat.com  Fri Jan 16 18:21:41 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 10:21:41 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkqhu1$al0$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<496F5A75.30007@redhat.com>	<gkoak3$qhf$1@ger.gmane.org>
	<49705113.4080203@redhat.com>  <gkqhu1$al0$1@ger.gmane.org>
Message-ID: <1232130101.5086.176.camel@localhost.localdomain>

On Fri, 2009-01-16 at 11:59 -0600, Matthew Woehlke wrote:
> Yes, that's better :-). That said, why on earth would you want to run 
> 32-bit processes on a 64-bit OS when 64-bit flavors are available?

You're running on a platform that isn't stooopid.  Only on x86 do x86_64
processes get "faster" due to access to more CPU registers.  But it
comes with a cost of much higher memory consumption.  On non x86 arches,
such as ppc, or s390, or sparc, the 32bit process has the full register
access and will run faster in 32bit mode and consume less memory than
the 64bit counterpart.  You still want a 64bit kernel there for various
reasons (like not even being able to run a 32bit kernel) but the
userland should be mostly 32bit.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/c64adaf3/attachment.sig>

From loganjerry at gmail.com  Fri Jan 16 18:27:27 2009
From: loganjerry at gmail.com (Jerry James)
Date: Fri, 16 Jan 2009 11:27:27 -0700
Subject: Rawhide PPC64
In-Reply-To: <20090115103457.GA17689@host0.dyn.jankratochvil.net>
References: <870180fe0901141840m6bb88713gc11d27805e6000bf@mail.gmail.com>
	<20090115103457.GA17689@host0.dyn.jankratochvil.net>
Message-ID: <870180fe0901161027h61de55e7w72390754c322e42d@mail.gmail.com>

On Thu, Jan 15, 2009 at 3:34 AM, Jan Kratochvil
<jan.kratochvil at redhat.com> wrote:
> confirming current Rawhide GDB segfaults on ppc64, going to fix it; you could
> file a normal Bug for it.

Thanks, Jan.  I just wanted to make sure I was really seeing a bug, as
opposed to doing something stupid. :-)
-- 
Jerry James
http://loganjerry.googlepages.com/



From thomas.moschny at gmail.com  Fri Jan 16 18:30:09 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Fri, 16 Jan 2009 19:30:09 +0100
Subject: Heads up: waf 1.5
In-Reply-To: <a9d183c80811181445h421c1f7dq58f7b08248091c08@mail.gmail.com>
References: <a9d183c80811181445h421c1f7dq58f7b08248091c08@mail.gmail.com>
Message-ID: <a9d183c80901161030t5692eed7xf968ac83cc09bfe@mail.gmail.com>

On 2008/11/18 I wrote:
> I'd like to update waf [1] to version 1.5.0 (which has been released
> only recently, and changes apis) for rawhide, and also as an update
> for f10. As far as I can see, only midori depends on it (although some
> more packages probably should, like kdissert).

Today, waf 1.5.2 has been landed in rawhide.

I'm hesitant also upgrading waf in f10 or f9, as this would be an
incompatible upgrade, being strongly discouraged in Fedora.

Comments?

- Thomas


[1] http://code.google.com/p/waf/

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From walters at verbum.org  Fri Jan 16 19:05:15 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 16 Jan 2009 14:05:15 -0500
Subject: Heads up: waf 1.5
In-Reply-To: <a9d183c80901161030t5692eed7xf968ac83cc09bfe@mail.gmail.com>
References: <a9d183c80811181445h421c1f7dq58f7b08248091c08@mail.gmail.com>
	<a9d183c80901161030t5692eed7xf968ac83cc09bfe@mail.gmail.com>
Message-ID: <faa16b610901161105y47dd3f9fx109f30937b7fa692@mail.gmail.com>

On Fri, Jan 16, 2009 at 1:30 PM, Thomas Moschny
<thomas.moschny at gmail.com> wrote:
> On 2008/11/18 I wrote:
>> I'd like to update waf [1] to version 1.5.0 (which has been released
>> only recently, and changes apis) for rawhide, and also as an update
>> for f10. As far as I can see, only midori depends on it (although some
>> more packages probably should, like kdissert).
>
> Today, waf 1.5.2 has been landed in rawhide.
>
> I'm hesitant also upgrading waf in f10 or f9, as this would be an
> incompatible upgrade, being strongly discouraged in Fedora.

Yes, do not upgrade f10 or f9.

In general with build tools you should *never* break compatibility
(i.e., if the code breaks compat, you should make a new package).  waf
has been in a development period up until now, so that's fine as long
as consumers understand that.  Hopefully now that it's hit 1.5 it will
be stable though.



From kevin.kofler at chello.at  Fri Jan 16 19:13:58 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 20:13:58 +0100
Subject: Massive fallout from missing libssl.so.7 et al
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>
	<639ce0480901160651h70aa854fuaf5a4796b485fdd9@mail.gmail.com>
	<200901161510.n0GFAEcl024118@laptop14.inf.utfsm.cl>
Message-ID: <gkqm9m$pcs$1@ger.gmane.org>

Horst H. von Brand wrote:
> OK, after reinstalling the offending packages, then I had _broken_
> symlinks: libssl.so.7 --> libssl.so.0.9.8g (old version!). Fixed those by
> hand, now it works.

The sooner we can get everything rebuilt and those wacky symlinks removed,
the better.

        Kevin Kofler



From a.badger at gmail.com  Fri Jan 16 19:21:22 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 16 Jan 2009 11:21:22 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkoplt$43e$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>	<y9hr634v6dy.fsf@libation.ircam.fr>
	<496F7214.7020109@gmail.com> <gkoplt$43e$1@ger.gmane.org>
Message-ID: <4970DE32.5090005@gmail.com>

Kevin Kofler wrote:
> Toshio Kuratomi wrote:
>> You'd need to do the removal (yum remove -y mypackage should work) in a
>> %post script.  This is something I've had to do before when making
>> minimal livemedia.
> 
> But that means that for classical uses of kickstart (i.e. run the installer
> with this kickstart on every machine), the package would get installed,
> then removed, on every single machine. :-(
> 
Yes.  But that's already the case.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/3155289d/attachment.sig>

From walters at verbum.org  Fri Jan 16 19:28:05 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 16 Jan 2009 14:28:05 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1232130101.5086.176.camel@localhost.localdomain>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
	<gkoak3$qhf$1@ger.gmane.org> <49705113.4080203@redhat.com>
	<gkqhu1$al0$1@ger.gmane.org>
	<1232130101.5086.176.camel@localhost.localdomain>
Message-ID: <faa16b610901161128l483cb528s57fb622ea9778594@mail.gmail.com>

2009/1/16 Jesse Keating <jkeating at redhat.com>:
> On Fri, 2009-01-16 at 11:59 -0600, Matthew Woehlke wrote:
>> Yes, that's better :-). That said, why on earth would you want to run
>> 32-bit processes on a 64-bit OS when 64-bit flavors are available?
>
> You're running on a platform that isn't stooopid.  Only on x86 do x86_64
> processes get "faster" due to access to more CPU registers.  But it
> comes with a cost of much higher memory consumption.

Note this isn't inherently true, if you're running managed code, a VM
can do some interesting tricks:

http://blogs.sun.com/nike/entry/compressed_object_pointers_in_hotspot



From jkeating at redhat.com  Fri Jan 16 19:34:43 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 11:34:43 -0800
Subject: Why different keys for -testing and non-testing?
Message-ID: <1232134483.5086.180.camel@localhost.localdomain>

Currently we have two gpg keys per release, one for
rawhide/updates-testing and one for the final release and stable
updates.  This complicates a number of things and I'm really wondering
what is the real actual value we get out of having multiple keys per
release?  I have some ideas that I'm going to keep to myself for right
now, but I'd like you, the consumers to help me understand what value
you see in it, and if that value remains if we were to have a key we
applied to all koji builds as the happen which is different from the
'release' key we'd use at release time and updates(-testing?) time for
each release.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/bfaecf13/attachment.sig>

From jkeating at redhat.com  Fri Jan 16 19:35:22 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 11:35:22 -0800
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <gkqm9m$pcs$1@ger.gmane.org>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<200901161447.n0GElXeb016828@laptop14.inf.utfsm.cl>
	<639ce0480901160651h70aa854fuaf5a4796b485fdd9@mail.gmail.com>
	<200901161510.n0GFAEcl024118@laptop14.inf.utfsm.cl>
	<gkqm9m$pcs$1@ger.gmane.org>
Message-ID: <1232134522.5086.181.camel@localhost.localdomain>

On Fri, 2009-01-16 at 20:13 +0100, Kevin Kofler wrote:
> Horst H. von Brand wrote:
> > OK, after reinstalling the offending packages, then I had _broken_
> > symlinks: libssl.so.7 --> libssl.so.0.9.8g (old version!). Fixed those by
> > hand, now it works.
> 
> The sooner we can get everything rebuilt and those wacky symlinks removed,
> the better.
> 
>         Kevin Kofler

This is why I didn't want this done a couple days before the alpha
freeze.  *grumble*

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/dbf10d88/attachment.sig>

From tmz at pobox.com  Fri Jan 16 20:16:58 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Fri, 16 Jan 2009 15:16:58 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <1232134483.5086.180.camel@localhost.localdomain>
References: <1232134483.5086.180.camel@localhost.localdomain>
Message-ID: <20090116201658.GM18365@inocybe.teonanacatl.org>

Jesse Keating wrote:
> Currently we have two gpg keys per release, one for
> rawhide/updates-testing and one for the final release and stable
> updates.  This complicates a number of things and I'm really
> wondering what is the real actual value we get out of having
> multiple keys per release?  I have some ideas that I'm going to keep
> to myself for right now, but I'd like you, the consumers to help me
> understand what value you see in it, and if that value remains if we
> were to have a key we applied to all koji builds as the happen which
> is different from the 'release' key we'd use at release time and
> updates(-testing?) time for each release.

One advantage (which may or may not be enough to warrant keeping the
keys separate) is that if you want to ensure no packages from
updates-testing are installed on a box, you can easily do so by not
importing the testing key.  I don't think any of the tools
automatically import keys without prompting, the user, correct?

I'm more curious whether the plan going forward is to generate a new
key for each release or if that was just a temporary situation due to
the infrastructure intrusion last August.  I think it adds a little
bit of confidence when the signing key remains the same for a
reasonably long time (certainly more than the life of one release).
On the other hand, the lack of any way to revoke a key in the rpm db
is problematic and cycling the keys once per release does mitigate
this a little.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Life is the art of drawing without an eraser.
    -- John Gardner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/334b89dd/attachment.sig>

From notting at redhat.com  Fri Jan 16 20:31:29 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Jan 2009 15:31:29 -0500
Subject: pam_console
Message-ID: <20090116203129.GA5449@nostromo.devel.redhat.com>

I think it's time to retire pam_console from the default configuration.

For device permissions, we already have the hal/consolekit support which
should be use.

The following packages place the following files in
/etc/security/console.perms.d, and would need modified to work with HAL/CK:

barry-libs:	 /etc/security/console.perms.d/10-blackberry.perms (quantumburnz)
pam:	 /etc/security/console.perms.d/50-default.perms	(tmraz)
rainbow:	 /etc/security/console.perms.d/51-rainbow.perms	(kantrn)
em8300:	 /etc/security/console.perms.d/60-em8300.perms	(heffer)
jfbterm:	 /etc/security/console.perms.d/60-jfbterm.perms	(mtasaka)
thinkfinger:	 /etc/security/console.perms.d/60-thinkfinger.perms	(?)
svxlink-server:	 /etc/security/console.perms.d/90-svxlink.perms	(lucilanga)
vdr:	 /etc/security/console.perms.d/95-vdr.perms	(scop)
piklab:	 /etc/security/console.perms.d/icd2.perms	(chitlesh)
piklab:	 /etc/security/console.perms.d/pickit1.perms	(chitlesh)
piklab:	 /etc/security/console.perms.d/pickit2.perms	(chitlesh)

I'd be willing to chip in to get these fixed, it shouldn't be that hard.

The second part of pam_console is that it provides the gating information
for userhelper. There are many more apps that use this, and it's a more
involved port to get them to use PolicyKit, or a similar framework. However,
I don't see why we couldn't just port pam_ck_connector.so to drop the
lock file in /var/run/console, and then usermode/userhelper can just
work the same, without having to have a second extraneous pam module. We
can then work on porting the other apps at our leisure.

Opinions?

Bill



From jkeating at redhat.com  Fri Jan 16 20:38:56 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 12:38:56 -0800
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <20090116201658.GM18365@inocybe.teonanacatl.org>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<20090116201658.GM18365@inocybe.teonanacatl.org>
Message-ID: <1232138336.25346.4.camel@localhost.localdomain>

On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:
>  One advantage (which may or may not be enough to warrant keeping the
> keys separate) is that if you want to ensure no packages from
> updates-testing are installed on a box, you can easily do so by not
> importing the testing key.  I don't think any of the tools
> automatically import keys without prompting, the user, correct?

That's correct.  We could still accomplish this by having

1) a key that is applied to any build that comes from an official koji
build.

2) Only apply a releases key to a package that was in the GOLD release,
and those packages which migrate to stable updates.

If you don't trust the koji key, you'll only ever get something that has
been "blessed" by a human.

> I'm more curious whether the plan going forward is to generate a new
> key for each release or if that was just a temporary situation due to
> the infrastructure intrusion last August.  I think it adds a little
> bit of confidence when the signing key remains the same for a
> reasonably long time (certainly more than the life of one release).
> On the other hand, the lack of any way to revoke a key in the rpm db
> is problematic and cycling the keys once per release does mitigate
> this a little.

Given that we can't revoke, yes, we plan to use new keys each release.
We can use gpg web-o-trust thing and sign the new keys with the old keys
and whatnot, does that actually help people?

I guess we really need to understand what it is that signing gives us.
At a basic level, the gpg signature says that "this package came from
Fedora".  That has an extreme amount of value to it, as you state you
can trust only that key (set) and get only packages that came from
Fedora.  We've tried to go a bit further and apply status to the keys to
indicate "this is a test package that came from Fedora" vs "this is a
stable package that came from Fedora", to allow you to get even more
fine tuned with your trust.

Is there anything else we're getting out of these keys?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/3dd4ac85/attachment.sig>

From notting at redhat.com  Fri Jan 16 21:07:09 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 16 Jan 2009 16:07:09 -0500
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <20090116210709.GA6548@nostromo.devel.redhat.com>

Tomas Mraz (tmraz at redhat.com) said: 
> I am going to build new openssl into rawhide really soon. As the new
> version contains some minor ABI breaks it will require SONAME bump of
> the openssl libraries. That also means all the 288 dependent packages
> will have to be rebuilt. Not counting that some of the dependent
> packages have circular dependencies.
> 
> But do not be scared. As the ABI break is pretty minimal and as it
> should not affect a large majority of applications I am going to
> temporarily provide symlinks to the old library soname and appropriate
> provides in the rpm package. Of course this will be dropped as soon as
> all (or majority of) the dependencies are rebuilt.

Obviously hindsight is 20/20, but is there a reason this couldn't
have been done with:

- a compatiblity openssl098g package?
- a separate buildroot, and then merged?

Bill



From aa.lucelio at gmail.com  Fri Jan 16 21:17:25 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Fri, 16 Jan 2009 19:17:25 -0200
Subject: Help with C Code in Fedora
In-Reply-To: <gkorgn$9hj$1@ger.gmane.org>
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
	<gkorgn$9hj$1@ger.gmane.org>
Message-ID: <f4a59ea0901161317r30ff7807pddd4038f12fe64a1@mail.gmail.com>

Thank you ***Jochen Schmitt, **Kevin Kofler* and *Jud Craft*,

          I developed many commercial applications using UNIX(Interactive),
Fortran, "C", and Pascal some years ago, I'm comming back, and trying to
mount my working environment.   At that time(first CD of Linux RED-HAT)
network was not so common, the environment was single machine, multiuser
serial board and *I*nter *P*rocess *C*ommunications, the beginning of C++.
I would like to port all these applications to linux(just for heating a
litle).   I'm studing and have already got some tools like Advanced Linux
Programing(Mark Mitchell, Jeffrey Oldham and Alex Samuel), some books...,
and  If you would like to help me, I would appreciate.   Show me the way,
and take me for a "tools update ride", I am sure that I can contribute a lot
for the community.   By the way I love Linux(*for me RED-HAT is the one, the
best*), and have a project in mind, and I'll invest on it, and all I said
before is necessary for the bases of my project.   It is necessary to know
some environment to choose what best fits.

Ps1: I've 3(fast dual core, 4Gb, F10-x86_64, 800GB), fast internet(3Mb),
gtk2-devel and qt-devel packages installed.
Ps2: Do you see any problem for us to know each other by making a *
videoconferencing* via Skipe? Any sugestion?

I hope I can count on you.

Thanks,
Luc?lio.

2009/1/16 Kevin Kofler <kevin.kofler at chello.at>

> Fedora Linux wrote:
> > I am new to Linux and just installed Fedora 10 on my Machine. I wanted
> > to develop graphical libraries using C (not C++). Can anyone please
> > tell me if there is some place where I can download these graphical
> > Libraries. For example if I want to display a pixel on the screen can
> > someone please explain how I could do so using C
>
> Do you want to have full control over drawing (e.g. for a game) or do you
> want to write an application which looks like common desktop applications
> (with "widgets", i.e. controls like menus, buttons and textboxes)?
>
> For the first thing, you'll want something like SDL or Allegro. Those are
> the most frequently used ones, but there are some more libraries like that
> in Fedora too.
>
> For the second thing, something like GTK+ (which is in C) or Qt (it's C++,
> but it replaces most of the C++ standard library with better-designed
> classes, so you may end up actually liking it - I used to hate C++ and only
> like C before I started coding with Qt and KDE). In both cases, you will
> quickly notice that you need to think in a more object-oriented way. There
> aren't really any modern GUI toolkits which are strictly procedural. GTK+
> uses some convoluted ways to write object-oriented code in C (macros,
> structures with function pointers in them etc.), Qt uses C++ for it. IMHO
> Qt's solution is better (and yes, I have worked with both), but I'm
> biased. :-) So as a plain C programmer, you'll have to get used to the OO
> paradigm (and also to event-based programming) to do GUI programming,
> objects and events are the main concepts there, whether it's in C++ or in
> OO-style C (like GTK+).
>
>        Kevin Kofler
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/4b1f52a3/attachment.htm>

From kevin.kofler at chello.at  Fri Jan 16 22:08:25 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 16 Jan 2009 23:08:25 +0100
Subject: Help with C Code in Fedora
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
	<gkorgn$9hj$1@ger.gmane.org>
	<f4a59ea0901161317r30ff7807pddd4038f12fe64a1@mail.gmail.com>
Message-ID: <gkr0gp$qsu$1@ger.gmane.org>

Luc?lio Gomes de Freitas wrote:
> Ps2: Do you see any problem for us to know each other by making a *
> videoconferencing* via Skipe?

Yes, 2 of them:
* I don't have the time for such a videoconference.
* I don't use Skype because it is proprietary software.
Sorry.

        Kevin Kofler



From peter at thecodergeek.com  Fri Jan 16 22:09:48 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Fri, 16 Jan 2009 14:09:48 -0800
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231970614.5215.58.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
Message-ID: <1232143788.3316.1.camel@localhost.localdomain>

On Wed, 2009-01-14 at 23:03 +0100, Tomas Mraz wrote:
> Here is the list of all the dependent packages:
> [...]
> rb_libtorrent

I submitted a rebuild for this, which should hit tomorrow's rawhide
compose. Thanks for the heads-up! :)
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.com>
???????????
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/7f0986d5/attachment.sig>

From aa.lucelio at gmail.com  Fri Jan 16 22:52:11 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Fri, 16 Jan 2009 20:52:11 -0200
Subject: Help with C Code in Fedora
In-Reply-To: <gkr0gp$qsu$1@ger.gmane.org>
References: <735284.12620.qm@web112215.mail.gq1.yahoo.com>
	<gkorgn$9hj$1@ger.gmane.org>
	<f4a59ea0901161317r30ff7807pddd4038f12fe64a1@mail.gmail.com>
	<gkr0gp$qsu$1@ger.gmane.org>
Message-ID: <f4a59ea0901161452l6728b77epf10a4e1b54ff0d9a@mail.gmail.com>

Ok, Kevin Kofler,

Take it easy, we are at the same side ok?

     I am learning how I should behave on this list, for me graphichs shows
more infos than command line, even if it last 1 minute or less.
Videoconferencing can last 1 minute or less, less time than you spend
writting an E-mail, even for busy persons.     Let's give time to time.
     No problem, I'm interested on any peace of information on *Fedora Linux
anyway*.   In a war, when we succeed on the battle, we should not broke
enemys weapons, we should use it against him, study the weapon, and make a
better one.

Ps1: I said I'm Fedora(open SW), since the begining believe it, and I need
your help, ok?
Ps2: Don't keep *all* the help you have, share a litle part of it with us.

Thanks,
Luc?lio.

2009/1/16 Kevin Kofler <kevin.kofler at chello.at>

> Luc?lio Gomes de Freitas wrote:
> > Ps2: Do you see any problem for us to know each other by making a *
> > videoconferencing* via Skipe?
>
> Yes, 2 of them:
> * I don't have the time for such a videoconference.
> * I don't use Skype because it is proprietary software.
> Sorry.
>
>        Kevin Kofler
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/20f2c623/attachment.htm>

From sergio.pasra at gmail.com  Fri Jan 16 23:19:27 2009
From: sergio.pasra at gmail.com (Sergio Pascual)
Date: Sat, 17 Jan 2009 00:19:27 +0100
Subject: Help needed with tkimage bug
Message-ID: <89b36810901161519s204579f8w746463ab89fd4485@mail.gmail.com>

I maintain ds9, a viewer of FITS files (a kind of image format used by
astronomers). ds9 is written in tcl and requires other packages, such
as tkimg.

tkimg comes with its own version of libz, libpng, libjpeg and libtiff.
I patched the software to use system libraries instead. Patched tkimg
works well with ds9.

But tkimg seems to crash in other conditions. As reported here
https://bugzilla.redhat.com/show_bug.cgi?id=468357
tkimage crashed with some simple tests.

The bug is caused by my patches, the package without the patches works
well. I could revert them, but that implies using the bundled graphic
libraries instead of the system ones. In the other hand I don't have
the tcl knowledge to fix it. Any help?

By the way, I have reported the problem upstream,
https://sourceforge.net/tracker/index.php?func=detail&aid=2292032&group_id=52039&atid=465495



From benny+usenet at amorsen.dk  Fri Jan 16 23:35:26 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 17 Jan 2009 00:35:26 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkqhu1$al0$1@ger.gmane.org> (Matthew Woehlke's message of "Fri\,
	16 Jan 2009 11\:59\:28 -0600")
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
	<gkoak3$qhf$1@ger.gmane.org> <49705113.4080203@redhat.com>
	<gkqhu1$al0$1@ger.gmane.org>
Message-ID: <m3tz7yrfi9.fsf@ursa.amorsen.dk>

Matthew Woehlke <mw_triad at users.sourceforge.net> writes:

> Yes, that's better :-). That said, why on earth would you want to run
> 32-bit processes on a 64-bit OS when 64-bit flavors are available?

On sane architectures, 32-bit executables are smaller and faster than
64-bit executables.

x86 is the notable exception, because of its lack of registers in
32-bit mode.


/Benny



From Arnaud.Gomes at ircam.fr  Sat Jan 17 00:40:24 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Sat, 17 Jan 2009 01:40:24 +0100
Subject: comps discussion at fudcon and the future
In-Reply-To: <4970DE32.5090005@gmail.com> (Toshio Kuratomi's message of "Fri\,
	16 Jan 2009 11\:21\:22 -0800")
References: <1231962712.14403.1559.camel@rosebud>
	<y9hvdsgv9jz.fsf@libation.ircam.fr>
	<1232038005.14403.1613.camel@rosebud>
	<y9hr634v6dy.fsf@libation.ircam.fr> <496F7214.7020109@gmail.com>
	<gkoplt$43e$1@ger.gmane.org> <4970DE32.5090005@gmail.com>
Message-ID: <y9h8wpaydc7.fsf@libation.ircam.fr>

Toshio Kuratomi <a.badger at gmail.com> writes:

>> But that means that for classical uses of kickstart (i.e. run the installer
>> with this kickstart on every machine), the package would get installed,
>> then removed, on every single machine. :-(
>> 
> Yes.  But that's already the case.

Is it? I'm pretty sure this is not the case on RHEL5 and its clones at
least.

-- 
Arnaud



From vonbrand at inf.utfsm.cl  Sat Jan 17 00:59:05 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 21:59:05 -0300
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkqhu1$al0$1@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud> <496F5A75.30007@redhat.com>
	<gkoak3$qhf$1@ger.gmane.org> <49705113.4080203@redhat.com>
	<gkqhu1$al0$1@ger.gmane.org>
Message-ID: <200901170059.n0H0x5Od005514@laptop14.inf.utfsm.cl>

Matthew Woehlke <mw_triad at users.sourceforge.net> wrote:
> Florian Festi wrote:

[...]

> > Ok, I should probably a bit more precise: 32 bit being default on 64
> > bit capable computers is coming to an end as the default RAM size
> > for desktops goes beyond 4GB.
> 
> Yes, that's better :-). That said, why on earth would you want to run
> 32-bit processes on a 64-bit OS when 64-bit flavors are available?

Because in some cases (SPARC vs SPARC64 comes to mind) 32-bit executables
use _much_ less memory and run a _lot_ faster...
-- 
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  Sat Jan 17 01:12:06 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 22:12:06 -0300
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkon30$q8s$3@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>
	<20090114204638.GD32395@nostromo.devel.redhat.com>
	<1231966755.14403.1570.camel@rosebud>
	<20090114211232.GA1188@nostromo.devel.redhat.com>
	<1231967651.14403.1572.camel@rosebud> <gklnan$5fb$1@ger.gmane.org>
	<20090115204156.GA30791@nostromo.devel.redhat.com>
	<gkoaee$ojq$1@ger.gmane.org> <1232055829.14403.1707.camel@rosebud>
	<gkon30$q8s$3@ger.gmane.org>
Message-ID: <200901170112.n0H1C6Mr005608@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> seth vidal wrote:
> > they don't help the problem at all, they just introduce a whole other
> > set of difficulties as to what the default behavior should be when we
> > hit them.
> 
> Here's how I see things (which I believe is close if not identical to how it
> works on Debian):
> 
> Recommended = default on.
> Suggested = default off.
> The user can customize it to have both on or both off.

But I might want all extra goodies that enhance (La)TeX, while I want only
bare-bones vim (or the other way around). So for this to make any sense, it
would have to be a per-package setting. Or even more fine grained ("I want
all CLI enhancements but no GUI stuff for..."). That way lies utter
madness.

> And in both cases, removing a package with only a soft dep should not remove
> the dependent package (except if an option to treat them as hard deps is
> set).

What use is the suggested package if the package it is supposed to enhance
isn't there? What happens if the same package enhances several others
(i.e., recommend emacs together with each programming language)?
-- 
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  Sat Jan 17 01:47:08 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 22:47:08 -0300
Subject: asciidoc abandoned?
In-Reply-To: <20090116024334.GB6975@x200.localdomain>
References: <200901151643.n0FGhP9x006442@laptop14.inf.utfsm.cl>
	<4410e3690b24968fab381111733ee7f5.squirrel@mail.jcomserv.net>
	<20090116024334.GB6975@x200.localdomain>
Message-ID: <200901170147.n0H1l8YG005943@laptop14.inf.utfsm.cl>

Chris Wright <chrisw at redhat.com> wrote:
> * Jon Ciesla (limb at jcomserv.net) wrote:
> > > I've got an annoying bug in asciidoc (#283351; yes, it is quite old by
> > > now), and I check regularly on that one, there being no movement there
> > > except for automagic assignment to the stable releases. The current
> > > package
> > > is still asciidoc-8.2.5-2.fc9.noarch in Fedora, while upstream it is now
> > > at
> > > 8.3.3. In any case, the homepage warns of possible compatibility issues
> > > WRT
> > > 8.2.7. They look relatively minor to me, but in any case I believe Fedora
> > > 11 should ship the new version.
> > 
> > Looks like Chris Wright owns it, and Florian La Roche did quite a bit with
> > it, but nothing since 2007.  Would either care to comment?
> 
> Horst, you've done most bug filing, you interested in helping maintain
> the package?

I'm interested.

Note that I'm currently Fedora Ambassador (not a developer (yet?)), and not
really versed in Python.

Where should I start reading?
-- 
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  Sat Jan 17 01:55:50 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Fri, 16 Jan 2009 22:55:50 -0300
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <20090116172700.GU7770@calliope.phig.org>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
	<20090116172700.GU7770@calliope.phig.org>
Message-ID: <200901170155.n0H1toNU006051@laptop14.inf.utfsm.cl>

Karsten Wade <kwade at redhat.com> wrote:
> On Thu, Jan 15, 2009 at 07:59:57AM -0600, Rex Dieter wrote:
> > Operator (postnuke.tv) wrote:
> > 
> > > The Zikula project might be very interested... You could have Zikula
> > > deployed with the project's help and support?
> > > Moreover, at some point in the near future, we'd like to be providing
> > > a Fedora RPM for the FC distrib.
> > 
> > The latter, being packaged and included in fedora, is pretty much a
> > prerequisite for consideration, so... the sooner the better.
> 
> +1
> 
> This falls under "working within Fedora Infrastructure."

Does Fedora infrastructure run on Fedora or en Red Hat? I'd assume the
later, in which case it should at least be in EPEL.
-- 
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  Sat Jan 17 02:03:24 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 16 Jan 2009 21:03:24 -0500
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <200901170155.n0H1toNU006051@laptop14.inf.utfsm.cl>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org> <20090116172700.GU7770@calliope.phig.org>
	<200901170155.n0H1toNU006051@laptop14.inf.utfsm.cl>
Message-ID: <da159fda0901161803v67682d3ft4f76c9322439fa7d@mail.gmail.com>

On Fri, Jan 16, 2009 at 8:55 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:

> Does Fedora infrastructure run on Fedora or en Red Hat? I'd assume the
> later, in which case it should at least be in EPEL.

Yes, Fedora Infrastructure runs on RHEL.



From alexl at users.sourceforge.net  Sat Jan 17 02:25:29 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Fri, 16 Jan 2009 19:25:29 -0700
Subject: unnecessary font Provides churn (was Re: rawhide report: 20090116
	changes)
In-Reply-To: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	(Rawhide Report's message of "Fri\,
	16 Jan 2009 08\:12\:59 +0000 \(UTC\)")
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
Message-ID: <fseiz2fz3a.fsf@allele2.eebweb.arizona.edu>

>>>>> Rawhide Report  writes:
> Broken deps for i386
> ----------------------------------------------------------

[...]

> 	mapserver-5.2.1-3.fc11.i386 requires bitstream-vera-fonts-sans

> 	neverball-1.4.0-13.fc11.i386 requires bitstream-vera-fonts-sans

> 	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-serif
> 	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans-mono
> 	php-ZendFramework-tests-1.7.2-4.fc11.noarch requires bitstream-vera-fonts-sans

I just fixed the 'Requires:' that were causing broken deps a few days
ago to match the new 'Provides:', but it appears that the naming for
the provides has changed *yet again*.   

Why wasn't the change done in one hit to avoid all these extra
rebuilds?  Rather than (as it appears to have been done):

bitstream-vera-fonts ->  bitstream-vera-fonts-sans
bitstream-vera-fonts-sans -> bitstream-vera-sans-fonts 

Alex



From cdahlin at redhat.com  Sat Jan 17 03:23:35 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 16 Jan 2009 22:23:35 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <1232138336.25346.4.camel@localhost.localdomain>
References: <1232134483.5086.180.camel@localhost.localdomain>	<20090116201658.GM18365@inocybe.teonanacatl.org>
	<1232138336.25346.4.camel@localhost.localdomain>
Message-ID: <49714F37.9040201@redhat.com>

Jesse Keating wrote:
> On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:
>   
>>  One advantage (which may or may not be enough to warrant keeping the
>> keys separate) is that if you want to ensure no packages from
>> updates-testing are installed on a box, you can easily do so by not
>> importing the testing key.  I don't think any of the tools
>> automatically import keys without prompting, the user, correct?
>>     
>
> That's correct.  We could still accomplish this by having
>
> 1) a key that is applied to any build that comes from an official koji
> build.
>
> 2) Only apply a releases key to a package that was in the GOLD release,
> and those packages which migrate to stable updates.
>
> If you don't trust the koji key, you'll only ever get something that has
> been "blessed" by a human.
>
>   
>> I'm more curious whether the plan going forward is to generate a new
>> key for each release or if that was just a temporary situation due to
>> the infrastructure intrusion last August.  I think it adds a little
>> bit of confidence when the signing key remains the same for a
>> reasonably long time (certainly more than the life of one release).
>> On the other hand, the lack of any way to revoke a key in the rpm db
>> is problematic and cycling the keys once per release does mitigate
>> this a little.
>>     
>
> Given that we can't revoke, yes, we plan to use new keys each release.
> We can use gpg web-o-trust thing and sign the new keys with the old keys
> and whatnot, does that actually help people?
>
> I guess we really need to understand what it is that signing gives us.
> At a basic level, the gpg signature says that "this package came from
> Fedora".  That has an extreme amount of value to it, as you state you
> can trust only that key (set) and get only packages that came from
> Fedora.  We've tried to go a bit further and apply status to the keys to
> indicate "this is a test package that came from Fedora" vs "this is a
> stable package that came from Fedora", to allow you to get even more
> fine tuned with your trust.
>
> Is there anything else we're getting out of these keys?
>
>   
I think its wrong to get the latter out of the keys (though the right 
way might mean touching rpm in a way we aren't allowed/able to). Once we 
have "This package came from Fedora" then for the rest of the info, we 
can just state it in a package header. If the headers are signed then we 
have the necessary level of security. We only need one key to provide 
the non-refutability. The rest of the information can just be stated.

--CJD



From jkeating at redhat.com  Sat Jan 17 03:45:19 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 16 Jan 2009 19:45:19 -0800
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <49714F37.9040201@redhat.com>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<20090116201658.GM18365@inocybe.teonanacatl.org>
	<1232138336.25346.4.camel@localhost.localdomain>
	<49714F37.9040201@redhat.com>
Message-ID: <1232163919.3539.2.camel@localhost.localdomain>

On Fri, 2009-01-16 at 22:23 -0500, Casey Dahlin wrote:
>  I think its wrong to get the latter out of the keys (though the right 
> way might mean touching rpm in a way we aren't allowed/able to). Once we 
> have "This package came from Fedora" then for the rest of the info, we 
> can just state it in a package header. If the headers are signed then we 
> have the necessary level of security. We only need one key to provide 
> the non-refutability. The rest of the information can just be stated.

I'd rather state that in the repodata, rather than the rpm itself.
Stating it in the rpm would mean changing the rpm file between -testing
and updates, which would break the ability to hardlink, and would mean
unnecessary churn.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/c528e664/attachment.sig>

From cdahlin at redhat.com  Sat Jan 17 05:38:31 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sat, 17 Jan 2009 00:38:31 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <1232163919.3539.2.camel@localhost.localdomain>
References: <1232134483.5086.180.camel@localhost.localdomain>	<20090116201658.GM18365@inocybe.teonanacatl.org>	<1232138336.25346.4.camel@localhost.localdomain>	<49714F37.9040201@redhat.com>
	<1232163919.3539.2.camel@localhost.localdomain>
Message-ID: <49716ED7.1030004@redhat.com>

Jesse Keating wrote:
> On Fri, 2009-01-16 at 22:23 -0500, Casey Dahlin wrote:
>   
>>  I think its wrong to get the latter out of the keys (though the right 
>> way might mean touching rpm in a way we aren't allowed/able to). Once we 
>> have "This package came from Fedora" then for the rest of the info, we 
>> can just state it in a package header. If the headers are signed then we 
>> have the necessary level of security. We only need one key to provide 
>> the non-refutability. The rest of the information can just be stated.
>>     
>
> I'd rather state that in the repodata, rather than the rpm itself.
> Stating it in the rpm would mean changing the rpm file between -testing
> and updates, which would break the ability to hardlink, and would mean
> unnecessary churn.
>
>   
That works too. The point is we shouldn't be using keys to categorize 
things. Only to authenticate them. And the only reason to have more than 
one key is to limit the effects of one of the keys being compromised 
(the all-your-eggs-in-one-basket issue).

--CJD



From rawhide at fedoraproject.org  Sat Jan 17 08:27:13 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 17 Jan 2009 08:27:13 +0000 (UTC)
Subject: rawhide report: 20090117 changes
Message-ID: <20090117082714.199601F825D@releng2.fedora.phx.redhat.com>

Compose started at Sat Jan 17 06:01:03 UTC 2009

New package google-droid-fonts
        General-purpose fonts released by Google as part of Android
New package ncmpcpp
        Clone of ncmpc with new features and written in C++
New package perl-DDL-Oracle
        DDL generator for Oracle databases
New package python-py
        Innovative python library containing py.test, greenlets and other niceties
Removed package drivel
Updated Packages:

anaconda-11.5.0.9-1
-------------------
* Fri Jan 16 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 11.5.0.9-1
- Cracklib moved locations, account for this in our keepfiles. (jkeating)
- Look in the right path for kernel module lists. (jkeating)
- Fix more problems in expandModuleSet, based on a patch from markmc
  (#480307). (clumens)
- Allow ext4 without magic argument (keep a flag for migrate) (katzj)
- Fix pulling in network modules (katzj)
- Support mounting NTFS filesystems (#430084) (katzj)
- dejavu fonts changed package names, pick up new names. (jkeating)
- TightVNC is now the default VNC server in Fedora (#480308). (clumens)
- Only skip (over)writing netconfig if we have an actual instPath (jkeating)
- The sets module is deprecated, so no longer use it. (clumens)


anyremote-4.15-1.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Mikhail Fedotov <anyremote at mail.ru> - 4.15-1
- Fixed crash issue in case of anyremote was runned without X.
  Fix hang in Load() command in case of empty file.


audio-entropyd-1.0.5-2.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.0.5-2
- initscript no longer on by default (bz 441273)


bam-0.2.0-1.fc11
----------------
* Fri Jan 16 17:00:00 2009 Simon Wesp <cassmodiah at fedoraproject.org> 0.2.0-1
- Update to 0.2.0


btrfs-progs-0.17-4.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Marek Mahut <mmahut at fedoraproject.org> 0.17-4
- RHBZ#480219 btrfs-convert is missing


cln-1.2.2-2.fc11
----------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 1.2.2-2
- Bump to solve dependency for ginac-devel


control-center-2.25.3-2.fc11
----------------------------
* Sat Jan 17 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.3-2
Make notification theme changing work better


cpanspec-1.78-1.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Steven Pritchard <steve at kspei.com> 1.78-1
- Update to 1.78.


dejavu-fonts-2.28-3.fc11
------------------------
* Fri Jan 16 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 2.28-3
??? Fix lgc-serif obsoletes


djvulibre-3.5.21-1.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 3.5.21-1
- Updated to 3.5.21


echoping-6.0.2-3.fc11
---------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 6.0.2-3
- rebuild with new openssl


eclipse-cdt-5.0.1-2.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Jeff Johnston <jjohnstn at redhat.com> 5.0.1-2
- Rebase libhover to 0.1.1 and autotools to 1.0.2.
- Remove patch for 472731 which is already part of rebased autotools sources.


ecolier-court-fonts-20070702-6.fc11
-----------------------------------
* Fri Jan 16 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 20070702-6
??? Convert to new naming guidelines


ecore-0.9.9.050-4.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.9.050-4
- rebuild with new openssl


ecryptfs-utils-68-1.fc11
------------------------
* Thu Jan 15 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 68-1
- rebuild with new openssl


efreet-0.5.0.050-2.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.5.0.050-2
- rebuild with new openssl


egoboo-2.7.5-4.fc11
-------------------

ejabberd-2.0.2-4.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.0.2-4
- rebuild with new openssl


ekg-1.8-0.3.rc1.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.8-0.3.rc1
- rebuild with new openssl


ekg2-0.2-0.7.rc1.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.2-0.7.rc1
- rebuild with new openssl


ekiga-3.1.0-10.fc11
-------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.1.0-10
- rebuild with new openssl
- add libtoolize call to replace libtool with current version

* Thu Jan 15 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-9
- Add other buildreq for Makefile regen

* Thu Jan 15 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 3.1.0-8
- Regen Makefile.in using autoreconf due to patch


elinks-0.12-0.8.pre2.fc11
-------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.12-0.8.pre2
- rebuild with new openssl


engine_pkcs11-0.1.4-3.fc11
--------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.1.4-3
- rebuild with new openssl


enlightenment-0.16.999.050-2.fc11
---------------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.16.999.050-2
- rebuild with new openssl


epic-2.10-2.fc11
----------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 4:2.10-2
- rebuild with new openssl


epsilon-0.3.0.012-6.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.3.0.012-6
- rebuild with new openssl


erlang-R12B-4.4.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - R12B-4.4
- rebuild with new openssl


esmtp-1.0-3.fc11
----------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.0-3
- rebuild with new openssl


ettercap-0.7.3-28.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.7.3-28
- rebuild with new openssl


evolution-data-server-2.25.4-2.fc11
-----------------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.25.4-2.fc11
- rebuild with new openssl


evolution-exchange-2.25.4-2.fc11
--------------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.25.4-2.fc11
- rebuild with new openssl


fedora-ds-base-1.1.3-8.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.1.3-8
- rebuild with new openssl

* Thu Oct 30 18:00:00 2008 Noriko Hosoi <nhosoi at redhat.com> - 1.1.3-7
- added db4-utils to Requires for verify-db.pl


fetchmail-6.3.9-2.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 6.3.9-2
- rebuild with new openssl


firstboot-1.105-1.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Chris Lumens <clumens at redhat.com> 1.105-1
- Fix a typo in starting up X.


fontmatrix-0.4.2-3.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.4.2-3
- rebuild with new openssl


fuse-encfs-1.5-4.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.5-4
- rebuild with new openssl


g2ipmsg-0.9.6-3.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.6-3
- rebuild with new openssl


getdata-0.5.0-1.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Matthew Truch <matt at truch.net> - 0.5.0-1
- Upstream 0.5.0
-   Includes bugfixes.
-   New gzip and bzip2 encoded dirfile read ability.
-   Uses ltdl dynamic module loading for gzip and bzip2 modules.


gftp-2.0.18-5.fc11
------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2:2.0.18-5
- rebuild with new openssl


gg2-2.3.0-10.fc11
-----------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.3.0-10
- rebuild with new openssl


ghasher-1.2.1-6.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.1-6
- rebuild with new openssl


git-1.6.1-2.fc11
----------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.6.1-2
- rebuild with new openssl


gkrellm-2.3.2-2.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.3.2-2
- rebuild with new openssl


globalplatform-5.0.0-6.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 5.0.0-6
- rebuild with new openssl


gnome-panel-2.25.3-5.fc11
-------------------------
* Fri Jan 16 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.3-4
- And don't write %s into desktop files

* Fri Jan 16 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.3-3
- Fix the 'smart launcher' patch


gnome-vfs2-2.24.0-4.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.24.0-4
- rebuild with new openssl


gq-1.3.4-3.fc11
---------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.3.4-3
- rebuild with new openssl


gsoap-2.7.12-2.fc11
-------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.7.12-2
- rebuild with new openssl


guilt-0.32-2.fc11
-----------------
* Fri Jan 16 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 0.32-2
- New upstream version, supports newer git (1.6)
- Fix minor regression test problem


gyachi-1.1.61-2.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.1.61-2
- rebuild with new openssl


heartbeat-2.1.4-3.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.1.4-3
- rebuild with new openssl


hedgewars-0.9.8-2.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8-2
- rebuild with new openssl


hfsplus-tools-332.14-8.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 332.14-8
- rebuild with new openssl


hplip-2.8.12-6.fc11
-------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.8.12-6
- rebuild with new openssl


htdig-3.2.0-0.4.b6.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 4:3.2.0-0.4.b6
- rebuild with new openssl


htmldoc-1.8.27-8.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.8.27-8
- rebuild with new openssl


httpd-2.2.11-5
--------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.2.11-5
- rebuild with new openssl


icu-4.0.1-1.fc11
----------------
* Fri Jan 16 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 4.0.1-1
- 4.0.1 release


kde-settings-4.1-5.20090116svn.fc11
-----------------------------------
* Fri Jan 16 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1-5
- wallpaper theme for new plasma in 4.2


kdebase3-3.5.10-5.fc11
----------------------
* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 3.5.10-5
- rebuild for new OpenSSL


kdelibs-4.1.96-9.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-9
- drop kdelibs-4.1.85-plasma-default-wallpaper.patch, it's not needed
  since new plasma allows to define default wallpaper, new kde-setting
  is required
- backport fix from trunk to allow symlinks in wallpaper theme

* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 4.1.96-8
- rebuild for new OpenSSL


kdenetwork-4.1.96-3.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 4.1.96-3
- rebuild for new OpenSSL


kernel-2.6.29-0.41.rc2.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- 2.6.29-rc1-git6
- linux-2.6-net-silence-noisy-printks.patch: merged

* Fri Jan 16 17:00:00 2009 Chuck Ebbert <cebbert at redhat.com>
- 2.6.29-rc2


krb5-1.6.3-17.fc11
------------------
* Fri Jan 16 17:00:00 2009 Nalin Dahyabhai <nalin at redhat.com> 1.6.3-17
- rebuild

* Thu Sep  4 18:00:00 2008 Nalin Dahyabhai <nalin at redhat.com>
- if we successfully change the user's password during an attempt to get
  initial credentials, but then fail to get initial creds from a non-master
  using the new password, retry against the master (#432334)


libpst-0.6.25-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Carl Byington <carl at five-ten-sg.com> - 0.6.25-1
- work on proper handling of content-type charset values

* Thu Dec 11 17:00:00 2008 Carl Byington <carl at five-ten-sg.com> - 0.6.24-1
- patch from Chris Eagle to build on cygwin


liveusb-creator-3.5-1.fc11
--------------------------
* Fri Jan 16 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.5-1
- Update to v3.5

* Fri Jan 16 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.4-1
- Update to 3.4.

* Fri Jan 16 17:00:00 2009 Luke Macken <lmacken at redhat.com> 3.3-2
- Require python-urlgrabber


man-pages-3.16-1.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 3.16-1
- update to 3.16


mono-2.4-1.20091601svn123642.fc11
---------------------------------
* Fri Jan 16 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.4-1.20091601svn123642
- Move to 2.4 branch
- Update from svn


netbeans-6.5-1.fc11
-------------------
* Tue Dec  9 17:00:00 2008 Victor Vasilyev <victor.vasilyev at sun.com> 6.5-1
- Bootstrapping of the spec for IDE of the NetBeans 6.5
- Removing of all binaries-list files
- New dependency on jakarta-oro-2.0.8.jar is added
- The Distribution tag is removed
- jsch 0.1.24 -> 0.1.39
- lucene 2.2.0 -> 2.3.1 (2.3.2)
- netbeans-javaparser 6.1 -> 6.5
- junit4 4.1 -> 4.5
- netbeans-platform9 -> netbeans-platform
- netbeans-platform9-harness -> netbeans-platform-harness
- BR netbeans-platform-harness
- svnClientAdapter 0.9.23 -> 1.4.0
- B(R) subversion-javahl >= 1.5.0
- Creation of the .noautoupdate files is  moved to the install section


neverball-1.4.0-14.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.4.0-14
- Fix font Requires bitstream-vera-fonts-sans ->
  bitstream-vera-sans-fonts (another font naming convention change).


ntp-4.2.4p6-2.fc11
------------------
* Fri Jan 16 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 4.2.4p6-2
- rebuild for new openssl


openssl-0.9.8j-3.fc11
---------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8j-3
- even more robust test for the temporary symlinks

* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.8j-2
- try to ensure the temporary symlinks exist


pam_mysql-0.7-0.6.rc1.fc11.1
----------------------------
* Fri Jan 16 17:00:00 2009 Manuel "lonely wolf" Wolfshant <wolfy at nobugconsulting.ro> 0.7-0.6.rc1.1
- rebuild for newer openssl


pam_ssh-1.92-8.fc11.1
---------------------
* Fri Jan 16 17:00:00 2009 Manuel "lonely wolf" Wolfshant <wolfy at nobugconsulting.ro> 1.92-8.1
- rebuild for newer openssl


perl-DateTime-Set-0.26-1.fc11
-----------------------------
* Fri Jan 16 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.26-1
- Update to 0.26.


perl-IPC-Run-0.82-1.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.82-1
- Update to 0.82.
- Use fixperms macro instead of our own chmod incantation.
- Fix Source0 URL.
- BR Test::More.
- Include LICENSE, README, and abuse/ in docs.
- Cleanup to more closely resemble cpanspec output.


perl-PAR-Dist-0.42-1.fc11
-------------------------
* Fri Jan 16 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.42-1
- Update to 0.42.


perl-Parse-CPAN-Meta-0.04-1.fc11
--------------------------------
* Fri Jan 16 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.04-1
- Update to 0.04.
- Update Source0 URL.
- Add version to Test::More dep.
- LICENSE and README went away.


php-ZendFramework-1.7.2-5.fc11
------------------------------
* Fri Jan 16 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.7.2-5
- Fix font [Build]Requires yet again to track moving target of naming
  convention.  Fixes broken deps.


publican-0.40-0.fc11
--------------------
* Mon Jan  5 17:00:00 2009 Jeff Fearn <jfearn at redhat.com> 0.40
- Fix DRAFT mode in web docs.
- Fix TOC CSS spacing.
- Fix missing syntax highlighting templates. BZ #474077
- Added appendix to user guide for Makefile parameters. BZ #476913
- Fix multiple authors in revhistory. Patch by: Paul W. Frields. BZ #478552
- Add LICENSE override for RPMs. BZ #477720
- Fix empty change log. BZ #477728
- Fix spec file location. BZ #477704
- Added newline after country. BZ #477573
- Fix minimum font size breaking TOC. BZ #476884
- Fix missing font-metric files. BZ #479592
- Updated redhat brand license. BZ #478405
- Update jboss brand license. BZ #478416
- Ship PDF with Indic web packages.


publican-fedora-0.17-0.fc11
---------------------------
* Mon Jan  5 17:00:00 2009 Jeff Fearn <jfearn at redhat.com> 0.17
- Add LICENSE override for RPMs. BZ #477720


pycairo-1.8.2-1.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 1.8.2-1
- Update to 1.8.2


python-2.6-4.fc11
-----------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.6-4
- rebuild with new openssl

* Tue Jan  6 17:00:00 2009 James Antill <james.antill at redhat.com> - 2.6-3
- Fix distutils generated rpms.
- Resolves: bug#236535


python-ldap-2.3.5-3.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0:2.3.5-3
- rebuild with new openssl


qt-4.4.3-11.fc11
----------------
* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 4.4.3-11
- rebuild for new OpenSSL


rb_libtorrent-0.14.1-2.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 0.14.1-2
- Rebuild for the soname bump in openssl-0.9.8j


redland-1.0.7-4.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 1.0.7-4
- rebuild for new OpenSSL

* Sun Nov 23 17:00:00 2008 Thomas Vander Stichele <thomas at apestaart dot org>
- 1.0.7-3
- updated summary
- not rebuilt yet


rrdtool-1.3.5-2.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Jarod Wilson <jarod at redhat.com> 1.3.5-2
- dejavu font package names changed again...

* Tue Dec 16 17:00:00 2008 Jarod Wilson <jarod at redhat.com> 1.3.5-1
- Update to rrdtool 1.3.5


smc-fonts-04.1-3.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Rajeesh K Nambiar <rajeeshknambiar at gmail.com> 04.1-3
- update for new font guidelines


ssmtp-2.61-11.8.fc11.1
----------------------
* Fri Jan 16 17:00:00 2009 Manuel "lonely wolf" Wolfshant <wolfy at nobugconsulting.ro> 2.61-11.8.1
- rebuild for newer openssl


stix-fonts-0.9-10.fc11
----------------------
* Fri Jan 16 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 0.9-10
??? Convert to new naming guidelines


taskcoach-0.71.5-1.fc11
-----------------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 0.71.5-1
- Updated to 0.71.5


trac-xmlrpc-plugin-1.0.0-0.2.r3074.fc11
---------------------------------------
* Fri Jan 16 17:00:00 2009 Sergio Pascual <sergio.pasra at gmail.com> - 1.0.0-0.2.r3074
- Adding version to Requires: trac


vodovod-1.10r19-2.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Karel Volny <kvolny at redhat.com> 1.10r19-2
- Use dejavu-fonts-sans-mono instead of bundling the font file (bug #477480)


vsftpd-2.1.0-0.2.pre3.fc11
--------------------------
* Fri Jan 16 17:00:00 2009 Martin Nagy <mnagy at redhat.com> - 2.1.0-0.2.pre3
- disable ptrace sandbox to fix build on i386

* Fri Jan 16 17:00:00 2009 Martin Nagy <mnagy at redhat.com> - 2.1.0-0.1.pre3
- update to latest upstream release
- cleanup the spec file
- drop patches fixed upstream:
    vsftpd-1.0.1-missingok.patch
    vsftpd-1.2.1-nonrootconf.patch
    vsftpd-2.0.1-tcp_wrappers.patch
    vsftpd-2.0.2-signal.patch
    vsftpd-2.0.3-daemonize_fds.patch
    vsftpd-2.0.5-correct_comments.patch
    vsftpd-2.0.5-pasv_dot.patch
    vsftpd-2.0.5-write_race.patch
    vsftpd-2.0.5-fix_unique.patch
    vsftpd-2.0.5-uname_size.patch
    vsftpd-2.0.5-bind_denied.patch
    vsftpd-2.0.5-pam_end.patch
    vsftpd-2.0.5-underscore_uname.patch
    vsftpd-2.0.6-listen.patch
- join all configuration patches into one:
    vsftpd-1.1.3-rh.patch
    vsftpd-1.2.1-conffile.patch
    vsftpd-2.0.1-dir.patch
    vsftpd-2.0.1-server_args.patch
    vsftpd-2.0.3-background.patch
    vsftpd-2.0.5-default_ipv6.patch
    vsftpd-2.0.5-add_ipv6_option.patch
    vsftpd-2.0.5-man.patch


waf-1.5.2-2.fc11
----------------
* Fri Jan 16 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 1.5.2-2
- Remove the documentation again, as it is under CC-BY-NC-ND. Also
  remove it from the tarfile.

* Fri Jan 16 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 1.5.2-1
- Update to 1.5.2.
- Generate html documentation (though without highlighting).

* Fri Dec 19 17:00:00 2008 Thomas Moschny <thomas.moschny at gmx.de> - 1.5.1-1
- Update to 1.5.1.


xchat-2.8.6-5.fc11
------------------
* Fri Jan 16 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 1:2.8.6-5
- rebuild for new OpenSSL


xorg-x11-apps-7.3-6.fc11
------------------------
* Fri Jan 16 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 7.3-6
- xinput 1.4.0


zabbix-1.6.2-1.fc11
-------------------
* Fri Jan 16 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.2-1
- Update to 1.6.2: http://www.zabbix.com/rn1.6.2.php


zile-2.3.0-1.fc11
-----------------
* Fri Jan 16 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 2.3.0-1
- Updated to 2.3.0


Summary:
Added Packages: 4
Removed Packages: 1
Modified Packages: 100
Broken deps for i386
----------------------------------------------------------
	ImageMagick-djvu-6.4.5.5-5.fc11.i386 requires libdjvulibre.so.15
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	djview4-4.3-2.fc10.i386 requires libdjvulibre.so.15
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	evince-djvu-2.25.4-1.fc11.i386 requires libdjvulibre.so.15
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	7:kdegraphics-libs-4.1.96-1.fc11.i386 requires libdjvulibre.so.15
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-3.fc11.i386 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.i386 requires smc-fonts-meera
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	redland-devel-1.0.7-4.fc11.i386 requires pkgconfig(rasqal) <= 0:0.9.15
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	ImageMagick-djvu-6.4.5.5-5.fc11.x86_64 requires libdjvulibre.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	djview4-4.3-2.fc10.x86_64 requires libdjvulibre.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	evince-djvu-2.25.4-1.fc11.x86_64 requires libdjvulibre.so.15()(64bit)
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
	7:kdegraphics-libs-4.1.96-1.fc11.i386 requires libdjvulibre.so.15
	7:kdegraphics-libs-4.1.96-1.fc11.x86_64 requires libdjvulibre.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-3.fc11.x86_64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.x86_64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	redland-devel-1.0.7-4.fc11.i386 requires pkgconfig(rasqal) <= 0:0.9.15
	redland-devel-1.0.7-4.fc11.x86_64 requires pkgconfig(rasqal) <= 0:0.9.15
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	ImageMagick-djvu-6.4.5.5-5.fc11.ppc requires libdjvulibre.so.15
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	djview4-4.3-2.fc10.ppc requires libdjvulibre.so.15
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	evince-djvu-2.25.4-1.fc11.ppc requires libdjvulibre.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	7:kdegraphics-libs-4.1.96-1.fc11.ppc requires libdjvulibre.so.15
	7:kdegraphics-libs-4.1.96-1.fc11.ppc64 requires libdjvulibre.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-3.fc11.ppc requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	redland-devel-1.0.7-4.fc11.ppc requires pkgconfig(rasqal) <= 0:0.9.15
	redland-devel-1.0.7-4.fc11.ppc64 requires pkgconfig(rasqal) <= 0:0.9.15
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	ImageMagick-djvu-6.4.5.5-5.fc11.ppc64 requires libdjvulibre.so.15()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	djview4-4.3-2.fc10.ppc64 requires libdjvulibre.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	evince-djvu-2.25.4-1.fc11.ppc64 requires libdjvulibre.so.15()(64bit)
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	7:kdegraphics-libs-4.1.96-1.fc11.ppc64 requires libdjvulibre.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapserver-5.2.1-3.fc11.ppc64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	redland-devel-1.0.7-4.fc11.ppc64 requires pkgconfig(rasqal) <= 0:0.9.15
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From rakesh.pandit at gmail.com  Sat Jan 17 08:34:36 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sat, 17 Jan 2009 14:04:36 +0530
Subject: rawhide report: 20090117 changes
In-Reply-To: <20090117082714.199601F825D@releng2.fedora.phx.redhat.com>
References: <20090117082714.199601F825D@releng2.fedora.phx.redhat.com>
Message-ID: <b401d2530901170034vb107d3fj963b8219a275cfd@mail.gmail.com>

2009/1/17 Rawhide Report <rawhide at fedoraproject.org>:
> Compose started at Sat Jan 17 06:01:03 UTC 2009
[..]
>        ImageMagick-djvu-6.4.5.5-5.fc11.i386 requires libdjvulibre.so.15
..
>        djview4-4.3-2.fc10.i386 requires libdjvulibre.so.15
..
>        evince-djvu-2.25.4-1.fc11.i386 requires libdjvulibre.so.15
..
>        7:kdegraphics-libs-4.1.96-1.fc11.i386 requires libdjvulibre.so.15
[..]

I created this mess. Will fix it.

-- 
rakesh



From nicolas.mailhot at laposte.net  Sat Jan 17 10:36:19 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 17 Jan 2009 11:36:19 +0100
Subject: unnecessary font Provides churn (was Re: rawhide report:
 20090116 changes)
In-Reply-To: <fseiz2fz3a.fsf@allele2.eebweb.arizona.edu>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	<fseiz2fz3a.fsf@allele2.eebweb.arizona.edu>
Message-ID: <1232188579.14915.80.camel@arekh.okg>

Le vendredi 16 janvier 2009 ? 19:25 -0700, Alex Lancaster a ?crit :

> I just fixed the 'Requires:' that were causing broken deps a few days
> ago to match the new 'Provides:', but it appears that the naming for
> the provides has changed *yet again*.   
> 
> Why wasn't the change done in one hit to avoid all these extra
> rebuilds?  

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#fpc_renaming

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/811a1632/attachment.sig>

From tmraz at redhat.com  Sat Jan 17 10:49:57 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Sat, 17 Jan 2009 11:49:57 +0100
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <20090116210709.GA6548@nostromo.devel.redhat.com>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<20090116210709.GA6548@nostromo.devel.redhat.com>
Message-ID: <1232189397.5215.105.camel@vespa.frost.loc>

On Fri, 2009-01-16 at 16:07 -0500, Bill Nottingham wrote:
> Tomas Mraz (tmraz at redhat.com) said: 
> > I am going to build new openssl into rawhide really soon. As the new
> > version contains some minor ABI breaks it will require SONAME bump of
> > the openssl libraries. That also means all the 288 dependent packages
> > will have to be rebuilt. Not counting that some of the dependent
> > packages have circular dependencies.
> > 
> > But do not be scared. As the ABI break is pretty minimal and as it
> > should not affect a large majority of applications I am going to
> > temporarily provide symlinks to the old library soname and appropriate
> > provides in the rpm package. Of course this will be dropped as soon as
> > all (or majority of) the dependencies are rebuilt.
> 
> Obviously hindsight is 20/20, but is there a reason this couldn't
> have been done with:
> 
> - a compatiblity openssl098g package?
I do not see a real need for such package except the third party
software support. We do not do compatibility packages for many other
important libraries either. But if anyone wants to maintain it feel free
to submit it for review and cc-me on the bugzilla entry, I will happily
review it.

> - a separate buildroot, and then merged?
Separate buildroot would not help alone - it would require either the
compat package or the temporary symlinks and provides anyway because of
the circular build dependencies.

I'm sorry that the first attempt at the temporary symlinks did not work
100%. But the openssl-0.9.8j-3.fc11 which is in the todays rawhide
should fix that.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From mcepl at redhat.com  Sat Jan 17 10:59:36 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sat, 17 Jan 2009 11:59:36 +0100
Subject: Is it time to kill python-sqlite2 on Fedora >= 10?
Message-ID: <o9q846x2su.ln2@ppp1053.in.ipex.cz>

Python 2.5 which is in Fedora 10 (and of course 2.6 in Rawhide as 
well) contains built-in sqlite library. Isn't it time to remove 
python-sqlite2 and remove all Requires for it?

Is there something python-sqlite2 has which python2.5 doesn't?

[root at viklef ~]# repoquery -q --whatrequires python-sqlite2
gnomecatalog-0:0.3.4-3.fc9.noarch
listen-0:0.5-19.fc10.i386
python-kaa-imlib2-0:0.2.3-2.fc9.i386
hamster-applet-0:2.24.0-1.fc10.i386
gcompris-0:8.4.7-1.fc10.i386
roundup-0:1.4.6-1.fc10.noarch
sugar-datastore-0:0.8.3-2.fc10.noarch
pychess-0:0.8.2-1.fc10.noarch
elisa-0:0.3.2-1.fc8.noarch
python-storm-sqlite-0:0.13-2.fc10.i386
python-sqlobject-0:0.10.2-1.fc10.noarch
PackageKit-0:0.3.9-4.fc10.i386
conduit-0:0.3.14-1.fc10.noarch
exaile-0:0.2.14-1.fc10.i386
gourmet-0:0.13.4-3.fc9.noarch
gcompris-0:8.4.8-1.fc10.i386
jabbim-0:0.4.3-3.fc10.noarch
pAgenda-0:3.2-2.fc10.noarch
nmap-frontend-2:4.68-3.fc10.i386
PackageKit-0:0.3.13-1.fc10.i386
PackageKit-0:0.3.12-1.fc10.i386
plague-0:0.4.5.6-1.fc10.noarch
synce-sync-engine-0:0.11.1-1.fc10.noarch
bibus-0:1.4.3-1.fc10.i386
hamster-applet-0:2.24.2-1.fc10.i386
bibus-0:1.4.3.1-2.fc10.i386
python-kaa-base-0:0.4.0-1.fc9.i386
[root at viklef ~]# 




From pertusus at free.fr  Sat Jan 17 11:09:43 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Jan 2009 12:09:43 +0100
Subject: pam_console
In-Reply-To: <20090116203129.GA5449@nostromo.devel.redhat.com>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
Message-ID: <20090117110943.GA2914@free.fr>

On Fri, Jan 16, 2009 at 03:31:29PM -0500, Bill Nottingham wrote:
> 
> The second part of pam_console is that it provides the gating information
> for userhelper. There are many more apps that use this, and it's a more
> involved port to get them to use PolicyKit, or a similar framework. However,
> I don't see why we couldn't just port pam_ck_connector.so to drop the
> lock file in /var/run/console, and then usermode/userhelper can just
> work the same, without having to have a second extraneous pam module. We
> can then work on porting the other apps at our leisure.
> 
> Opinions?

I don't have much opinion on that, but I don't really get how 
pam_ck_connector goes in the picture. Currently it is not used by 
anything but login, since the ConsoleKit session opening is done
either directly by the dm (kdm and gdm), or at the X session start,
using ck-xinit-session (at least xinit does so, and xdm/slim/vnc/nx
would do so once 
https://bugzilla.redhat.com/show_bug.cgi?id=452156
is resolved).

--
Pat



From pp at ee.oulu.fi  Sat Jan 17 13:01:55 2009
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Sat, 17 Jan 2009 15:01:55 +0200
Subject: Is it time to kill python-sqlite2 on Fedora >= 10?
In-Reply-To: <o9q846x2su.ln2@ppp1053.in.ipex.cz>
References: <o9q846x2su.ln2@ppp1053.in.ipex.cz>
Message-ID: <20090117130154.GA19059@ee.oulu.fi>

On Sat, Jan 17, 2009 at 11:59:36AM +0100, Matej Cepl wrote:
> Python 2.5 which is in Fedora 10 (and of course 2.6 in Rawhide as 
> well) contains built-in sqlite library. Isn't it time to remove 
> python-sqlite2 and remove all Requires for it?
> 
> Is there something python-sqlite2 has which python2.5 doesn't?
Well, python-sqlite2 gets to move ahead faster, there's the occasional
performance boost tweak / new feature that takes forever to get into upstream
python. 

I'd minimize/remove dependencies on it, and then just ship the latest
version for those developers that like to live on the edge :-)

-- 
Pekka Pietikainen



From rjones at redhat.com  Sat Jan 17 13:06:06 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 17 Jan 2009 13:06:06 +0000
Subject: pdcurses, readline, sqlite, gdbm, freetype, dlfcn, gettext, SDL
In-Reply-To: <20090115102055.GA30871@amd.home.annexia.org>
References: <20090115102055.GA30871@amd.home.annexia.org>
Message-ID: <20090117130606.GA25721@amd.home.annexia.org>


Many thanks to (... and I hope I remember everyone):

 - Tim Lauridsen
 - Adel Gadllah
 - Itamar Reis Peixoto
 - Levente Farkas
 - Erik van Pienbroek

the 8 packages in $SUBJECT have been added to Rawhide.  Builds in
Fedora 10 and EPEL 5 are either complete or underway (expect that
they'll all be available by Monday evening).

For reference, here are the reviews that were done:

https://bugzilla.redhat.com/show_bug.cgi?id=468376  mingw32-SDL
https://bugzilla.redhat.com/show_bug.cgi?id=478640  mingw32-dlfcn
https://bugzilla.redhat.com/show_bug.cgi?id=467396  mingw32-freetype
https://bugzilla.redhat.com/show_bug.cgi?id=467391  mingw32-gdbm
https://bugzilla.redhat.com/show_bug.cgi?id=467398  mingw32-gettext
https://bugzilla.redhat.com/show_bug.cgi?id=467388  mingw32-pdcurses
https://bugzilla.redhat.com/show_bug.cgi?id=467399  mingw32-readline
https://bugzilla.redhat.com/show_bug.cgi?id=467407  mingw32-sqlite

Here is the list of outstanding mingw32 RR's:

https://bugzilla.redhat.com/buglist.cgi?quicksearch=mingw32

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 rjones at redhat.com  Sat Jan 17 13:15:51 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 17 Jan 2009 13:15:51 +0000
Subject: pdcurses, readline, sqlite, gdbm, freetype, dlfcn, gettext, SDL
In-Reply-To: <20090117130606.GA25721@amd.home.annexia.org>
References: <20090115102055.GA30871@amd.home.annexia.org>
	<20090117130606.GA25721@amd.home.annexia.org>
Message-ID: <20090117131551.GA25779@amd.home.annexia.org>

On Sat, Jan 17, 2009 at 01:06:06PM +0000, Richard W.M. Jones wrote:
> Many thanks to (... and I hope I remember everyone):

& Peter Robinson too for helping with some other tricky RRs.

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 rjones at redhat.com  Sat Jan 17 13:33:28 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 17 Jan 2009 13:33:28 +0000
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <1232111099.5215.96.camel@vespa.frost.loc>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
Message-ID: <20090117133328.GA25986@amd.home.annexia.org>

On Fri, Jan 16, 2009 at 02:04:59PM +0100, Tomas Mraz wrote:
> On Fri, 2009-01-16 at 13:51 +0100, Ralf Ertzinger wrote:
> > Hi.
> > 
> > On Fri, 16 Jan 2009 13:46:25 +0100, Tomas Mraz wrote:
> > 
> > > I call ldconfig -X in the %post of openssl which should update the
> > > cache and not remove the symlinks. Any subsequent calls to ldconfig
> > > should not remove the symlinks - at least they do not on the system
> > > where I tested that. So there must be someting else in play.
> > 
> > I manually created the two symlinks, and subsequent calls to ldconfig
> > do not remove them, either.
> 
> I added a hack to create the symlinks in %post if they do not exist.
> Hopefully that helps. I'm building openssl-0.9.8j-2.fc11 just now.

I have the -3 release installed here and it doesn't seem to work:

# wget
wget: error while loading shared libraries: libcrypto.so.7: cannot open shared object file: No such file or directory

(same with other programs like git)

# rpm -q openssl
openssl-0.9.8j-3.fc11.x86_64

# rpm -q --scripts openssl
postinstall scriptlet (using /bin/sh):
if [ "$(readlink /lib64/libcrypto.so.7)" != libcrypto.so.0.9.8j ] ; then
    ln -sf libcrypto.so.0.9.8j /lib64/libcrypto.so.7 || :
fi
if [ "$(readlink /lib64/libssl.so.7)" != libssl.so.0.9.8j ] ; then
    ln -sf libssl.so.0.9.8j /lib64/libssl.so.7 || :
fi
/sbin/ldconfig -X
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig -X
postinstall scriptlet (using /bin/sh):
/sbin/ldconfig -X
postuninstall scriptlet (using /bin/sh):
/sbin/ldconfig -X

# ll /lib64/libcrypto.so.*
-rwxr-xr-x 1 root root 1570656 2009-01-16 16:19 /lib64/libcrypto.so.0.9.8j
lrwxrwxrwx 1 root root      19 2009-01-17 12:26 /lib64/libcrypto.so.8 -> libcrypto.so.0.9.8j

Anything else I need to try?

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 mdehaan at redhat.com  Sat Jan 17 13:34:50 2009
From: mdehaan at redhat.com (Michael DeHaan)
Date: Sat, 17 Jan 2009 08:34:50 -0500
Subject: Is it time to kill python-sqlite2 on Fedora >= 10?
In-Reply-To: <o9q846x2su.ln2@ppp1053.in.ipex.cz>
References: <o9q846x2su.ln2@ppp1053.in.ipex.cz>
Message-ID: <4971DE7A.1070405@redhat.com>

Matej Cepl wrote:
> Python 2.5 which is in Fedora 10 (and of course 2.6 in Rawhide as 
> well) contains built-in sqlite library. Isn't it time to remove 
> python-sqlite2 and remove all Requires for it?
>
> Is there something python-sqlite2 has which python2.5 doesn't?
>
> [root at viklef ~]# repoquery -q --whatrequires python-sqlite2
> gnomecatalog-0:0.3.4-3.fc9.noarch
> listen-0:0.5-19.fc10.i386
> python-kaa-imlib2-0:0.2.3-2.fc9.i386
> hamster-applet-0:2.24.0-1.fc10.i386
> gcompris-0:8.4.7-1.fc10.i386
> roundup-0:1.4.6-1.fc10.noarch
> sugar-datastore-0:0.8.3-2.fc10.noarch
> pychess-0:0.8.2-1.fc10.noarch
> elisa-0:0.3.2-1.fc8.noarch
> python-storm-sqlite-0:0.13-2.fc10.i386
> python-sqlobject-0:0.10.2-1.fc10.noarch
> PackageKit-0:0.3.9-4.fc10.i386
> conduit-0:0.3.14-1.fc10.noarch
> exaile-0:0.2.14-1.fc10.i386
> gourmet-0:0.13.4-3.fc9.noarch
> gcompris-0:8.4.8-1.fc10.i386
> jabbim-0:0.4.3-3.fc10.noarch
> pAgenda-0:3.2-2.fc10.noarch
> nmap-frontend-2:4.68-3.fc10.i386
> PackageKit-0:0.3.13-1.fc10.i386
> PackageKit-0:0.3.12-1.fc10.i386
> plague-0:0.4.5.6-1.fc10.noarch
> synce-sync-engine-0:0.11.1-1.fc10.noarch
> bibus-0:1.4.3-1.fc10.i386
> hamster-applet-0:2.24.2-1.fc10.i386
> bibus-0:1.4.3.1-2.fc10.i386
> python-kaa-base-0:0.4.0-1.fc9.i386
> [root at viklef ~]# 
>
>
>   

Removing packages that don't need to be removed results in some awesome 
funness when you have to maintain a package that works on EL-4 all the 
way through the latest rawhide.  

In general, don't remove it unless there's a good reason why it doesn't 
work, or there's a major bug you can't fix.

--Michael




From ihok at hotmail.com  Sat Jan 17 13:43:10 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 17 Jan 2009 13:43:10 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
Message-ID: <loom.20090117T133315-565@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:

> 
> I think it's time to retire pam_console from the default configuration.
> 
> For device permissions, we already have the hal/consolekit support which
> should be use.

That may well be correct, but I have no idea how to use hal/consolekit. I
suspect few Fedora users do. Try polling your question on fedoraforum, and see
what those results tell you. I recently posted a question there about
configuring alsa permissions for mpd and the answer I got there was pam_console.
Mind you, I am ready and willing to learn the brave new hal/consolekit way of
things. I looked for docs and examples for hal/consolekit, and found nothing
relevant to my use case.

Bottom line: before you blow away pam_console, please spend some time doing
education (e.g., documenting) and outreach (e.g., responding on fedoraforum)
about the new proper way of doing things that accommodates 80% of the existing
use cases. If you want to be thorough about it, consider the software (like mpd)
in a few prominent third-party repos, too.



From jos at xos.nl  Sat Jan 17 13:44:51 2009
From: jos at xos.nl (Jos Vos)
Date: Sat, 17 Jan 2009 14:44:51 +0100
Subject: Citadel groupware for Fedora
Message-ID: <200901171344.n0HDipoh005706@jasmine.xos.nl>

Hi.

Has somebody ever looked at Citadel <http://www.citadel.org/>, a
groupware solution, and maybe considered including it in Fedora?

Among all the pseudo-OSS and/or the too huge/too complex groupware
packages that are around, this one looks rather promising.

I heard that it is now also included in Debian.

--
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From pertusus at free.fr  Sat Jan 17 14:17:19 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Jan 2009 15:17:19 +0100
Subject: pam_console
In-Reply-To: <loom.20090117T133315-565@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
Message-ID: <20090117141719.GA4726@free.fr>

On Sat, Jan 17, 2009 at 01:43:10PM +0000, Jack Tanner wrote:
> Bill Nottingham <notting <at> redhat.com> writes:
> 
> > 
> > I think it's time to retire pam_console from the default configuration.
> > 
> > For device permissions, we already have the hal/consolekit support which
> > should be use.
> 
> That may well be correct, but I have no idea how to use hal/consolekit. I
> suspect few Fedora users do. Try polling your question on fedoraforum, and see
> what those results tell you. I recently posted a question there about
> configuring alsa permissions for mpd and the answer I got there was pam_console.
> Mind you, I am ready and willing to learn the brave new hal/consolekit way of
> things. I looked for docs and examples for hal/consolekit, and found nothing
> relevant to my use case.

In fact, pam_console is already not used anymore for many devices, usb
devices, for example. The switch has been done since a long time.

In my opinion it was not ready at all at that time (and still not ready),
and not only because of lack of documentation, also because consolekit
was used without proper integration, but I have rehashed that so much,
it is not really needed to do it again.

> Bottom line: before you blow away pam_console, please spend some time doing
> education (e.g., documenting) and outreach (e.g., responding on fedoraforum)
> about the new proper way of doing things that accommodates 80% of the existing
> use cases. If you want to be thorough about it, consider the software (like mpd)
> in a few prominent third-party repos, too.

Are you sure that mpd is relevant here? Isn't it higher layer than
pam_console/hal...?

Even before doing education, talking with other about the design, how
it integrates with pam, xdmcp, X and so on and so forth would have been
even more important, and it wasn't done right, in my opinion.

--
Pat



From silfreed at silfreed.net  Sat Jan 17 15:19:21 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Sat, 17 Jan 2009 10:19:21 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <1232138336.25346.4.camel@localhost.localdomain>
References: <1232134483.5086.180.camel@localhost.localdomain>	<20090116201658.GM18365@inocybe.teonanacatl.org>
	<1232138336.25346.4.camel@localhost.localdomain>
Message-ID: <4971F6F9.4000105@silfreed.net>

On 01/16/2009 Jesse Keating wrote:
> Given that we can't revoke, yes, we plan to use new keys each release.
> We can use gpg web-o-trust thing and sign the new keys with the old 
> keys
> and whatnot, does that actually help people?

Why couldn't we revoke keys?  Even if RPM itself doesn't have the capability,
we could have yum periodically check for updates on installed keys on
keyservers through a plugin, I would imagine.

-Doug



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/9bda8921/attachment.sig>

From sgrubb at redhat.com  Sat Jan 17 15:31:06 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 17 Jan 2009 10:31:06 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <4971F6F9.4000105@silfreed.net>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<1232138336.25346.4.camel@localhost.localdomain>
	<4971F6F9.4000105@silfreed.net>
Message-ID: <200901171031.07001.sgrubb@redhat.com>

On Saturday 17 January 2009 10:19:21 am Douglas E. Warner wrote:
> On 01/16/2009 Jesse Keating wrote:
> > Given that we can't revoke, yes, we plan to use new keys each release.
> > We can use gpg web-o-trust thing and sign the new keys with the old
> > keys and whatnot, does that actually help people?
>
> Why couldn't we revoke keys?  Even if RPM itself doesn't have the
> capability, we could have yum periodically check for updates on installed
> keys on keyservers through a plugin, I would imagine.

I have a machine that has been migrated for a long time. It has 9 
gpg-pubkey packages installed. Which ones are valid? Why don't they get 
retired by obsoletes or something? Could someone use my ancient gpg-pubkeys 
as a basis for an attack on repo metadata 
(http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html) 
and provide an older package with known security holes? 

Old keys should be retired. We should also make import of keys an auditable 
event.

-Steve



From tgl at redhat.com  Sat Jan 17 16:12:54 2009
From: tgl at redhat.com (Tom Lane)
Date: Sat, 17 Jan 2009 11:12:54 -0500
Subject: Is it time to kill python-sqlite2 on Fedora >= 10? 
In-Reply-To: <4971DE7A.1070405@redhat.com> 
References: <o9q846x2su.ln2@ppp1053.in.ipex.cz> <4971DE7A.1070405@redhat.com>
Message-ID: <12636.1232208774@sss.pgh.pa.us>

Michael DeHaan <mdehaan at redhat.com> writes:
> Removing packages that don't need to be removed results in some awesome 
> funness when you have to maintain a package that works on EL-4 all the 
> way through the latest rawhide.  

Huh?  You want him to maintain a useless package forever, so that you
don't have to cope with a Requires: difference across branches?  Get
real.  Requires: footprints change all the time; and even if it weren't
an everyday occurrence, the amount of effort you want him to undertake
is far more than the amount of effort you save.

			regards, tom lane



From pertusus at free.fr  Sat Jan 17 16:45:24 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Jan 2009 17:45:24 +0100
Subject: Is it time to kill python-sqlite2 on Fedora >= 10?
In-Reply-To: <12636.1232208774@sss.pgh.pa.us>
References: <o9q846x2su.ln2@ppp1053.in.ipex.cz> <4971DE7A.1070405@redhat.com>
	<12636.1232208774@sss.pgh.pa.us>
Message-ID: <20090117164524.GD4726@free.fr>

On Sat, Jan 17, 2009 at 11:12:54AM -0500, Tom Lane wrote:
> 
> Huh?  You want him to maintain a useless package forever, so that you
> don't have to cope with a Requires: difference across branches?  Get
> real.  Requires: footprints change all the time; and even if it weren't
> an everyday occurrence, the amount of effort you want him to undertake
> is far more than the amount of effort you save.

Keeping Requires around for a long time to cope with different versions
is, in my opinion, a very good practice. If the module is provided by
the main python package now, the main python package should
Provides/Obsoletes here anyway, so the old Requires can still be used.
I think that fedora maintainers should try to avoid breaking Requires
more, not less. Remember than we maintain packages from EPEL4 up to
rawhide, and third party repo can even go more back in time.

Here the correct solution, though, would be to have something similar
with python than with perl, with auto Requires and Provides.

Also keeping a requires only means modifying one package while removing
it may mean changing all the dependent packages. And to do things
right, this change should be coordinated with a chain build -- or it 
should be verified that all the dependent packages have changed 
Requires. Now I agree that, over time, dependent packages should switch 
to the new Requires, but packages should, in my opinion keep Requires 
along as much as possible.

--
Pat



From jkeating at redhat.com  Sat Jan 17 16:59:09 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 17 Jan 2009 08:59:09 -0800
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <200901171031.07001.sgrubb@redhat.com>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<1232138336.25346.4.camel@localhost.localdomain>
	<4971F6F9.4000105@silfreed.net> <200901171031.07001.sgrubb@redhat.com>
Message-ID: <1232211549.3539.4.camel@localhost.localdomain>

On Sat, 2009-01-17 at 10:31 -0500, Steve Grubb wrote:
>  
> I have a machine that has been migrated for a long time. It has 9 
> gpg-pubkey packages installed. Which ones are valid? Why don't they get 
> retired by obsoletes or something? 

We explored these options after the incident.  Last I heard the only
current way this is going to work is if an updated rpm package is
released that has a hardcoded distrust of the keys that might have been
compromised.  However I do believe it's on their roadmap to revamp how
keys are used so that we could revoke or expire keys, regardless of
where they come from.

> Could someone use my ancient gpg-pubkeys 
> as a basis for an attack on repo metadata 
> (http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html) 
> and provide an older package with known security holes? 
> 
> Old keys should be retired. We should also make import of keys an auditable 
> event.

Are not all rpm actions audited?  Importing a key essentially installs
it into the rpm database.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/39b76851/attachment.sig>

From rakesh.pandit at gmail.com  Sat Jan 17 17:46:11 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sat, 17 Jan 2009 23:16:11 +0530
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
Message-ID: <b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>

2009/1/13 Josef Bacik <josef at toxicpanda.com>:
> Hello,
>
[..]
> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
> of fun new things to tinker with.  A few disclaimers

> Please feel free to file a bugzilla if something goes horribly wrong,
> stability and finishing out the remaining features is what our main
> focus is now.  Thanks,
>

I tried two kernels:

First one:
mkfs.btrfs /dev/sda5

[root at test-rocky /]# uname -a
Linux test-rocky 2.6.29-0.41.rc2.fc11.i686

[root at test-rocky /]# modprobe libcrc32c ; modprobe zlib_inflate
zlib_deflate ; insmod btrfs.ko
FATAL: Module zlib_inflate not found.
insmod: can't read 'btrfs.ko': No such file or directory

btrfsctl -a
Scanning for Btrfs filesystems
cannot register some ioctl error

=========================================

Second one:

mkfs.btrfs /dev/sda5

[root at test-rocky /]# uname -a
Linux test-rocky 2.6.29-0.35.rc1.git4.fc11.i686

btrfsctl -a
Scanning for Btrfs filesystems
failed to open/dev/btrfs-control

I was working on something where I need somewhat stable behaviour, may
you suggest which build I should use ? Or Am I doing something wrong ?

Thanks

-- 
rakesh



From sandeen at redhat.com  Sat Jan 17 17:50:31 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 17 Jan 2009 11:50:31 -0600
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>
Message-ID: <49721A67.2000002@redhat.com>

Rakesh Pandit wrote:
> 2009/1/13 Josef Bacik <josef at toxicpanda.com>:
>> Hello,
>>
> [..]
>> Btrfs has built in snapshotting, subvolumes and RAID support, so lots
>> of fun new things to tinker with.  A few disclaimers
> 
>> Please feel free to file a bugzilla if something goes horribly wrong,
>> stability and finishing out the remaining features is what our main
>> focus is now.  Thanks,
>>
> 
> I tried two kernels:
> 
> First one:
> mkfs.btrfs /dev/sda5
> 
> [root at test-rocky /]# uname -a
> Linux test-rocky 2.6.29-0.41.rc2.fc11.i686
> 
> [root at test-rocky /]# modprobe libcrc32c ; modprobe zlib_inflate
> zlib_deflate ; insmod btrfs.ko
> FATAL: Module zlib_inflate not found.
> insmod: can't read 'btrfs.ko': No such file or directory

# modprobe btrfs

should suffice

heck just

# mount -t btrfs /dev/sda5 /mnt/blah

should suffice, or on uptodate rawhide, just

# mount /dev/sda5 /mnt/blah

-Eric



From a.badger at gmail.com  Sat Jan 17 17:50:04 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 17 Jan 2009 09:50:04 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9h8wpaydc7.fsf@libation.ircam.fr>
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>	<y9hr634v6dy.fsf@libation.ircam.fr>
	<496F7214.7020109@gmail.com>	<gkoplt$43e$1@ger.gmane.org>
	<4970DE32.5090005@gmail.com> <y9h8wpaydc7.fsf@libation.ircam.fr>
Message-ID: <49721A4C.4080300@gmail.com>

Arnaud Gomes-do-Vale wrote:
> Toshio Kuratomi <a.badger at gmail.com> writes:
> 
>>> But that means that for classical uses of kickstart (i.e. run the installer
>>> with this kickstart on every machine), the package would get installed,
>>> then removed, on every single machine. :-(
>>>
>> Yes.  But that's already the case.
> 
> Is it? I'm pretty sure this is not the case on RHEL5 and its clones at
> least.
> 
It was the case around Fedora 5 or 6.  I never tried to generate a RHEL5
livecd using that method so I don't know if anaconda had a significant
difference in RHEL5.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/03dc3d60/attachment.sig>

From rakesh.pandit at gmail.com  Sat Jan 17 18:11:47 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Sat, 17 Jan 2009 23:41:47 +0530
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <49721A67.2000002@redhat.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>
	<49721A67.2000002@redhat.com>
Message-ID: <b401d2530901171011p1865eac5h1d8b738c027e669d@mail.gmail.com>

2009/1/17 Eric Sandeen <sandeen at redhat.com>:
[..]
> # modprobe btrfs
>
> should suffice
>
> heck just
>
> # mount -t btrfs /dev/sda5 /mnt/blah
>
> should suffice, or on uptodate rawhide, just
>
> # mount /dev/sda5 /mnt/blah
>

Thanks

just small session on mounted partition (/data1 folder):

[root at test-rocky data1]# mkdir dir1
[root at test-rocky data1]# cd dir1/
[root at test-rocky dir1]# touch file1 file2; echo "test" > file3
[root at test-rocky data1]# cd ..

root at test-rocky data1]# btrfsctl -s dir1_snap dir1
ioctl:: Inappropriate ioctl for device

[root at test-rocky data1]# cd ~
[root at test-rocky ~]# btrfsctl -a
Scanning for Btrfs filesystems
failed to read /dev/sr0

I am confused, any suggestions here ?

[root at test-rocky ~]# uname -a
Linux test-rocky 2.6.29-0.35.rc1.git4.fc11.i686

-- 
Regards,
Rakesh Pandit



From sandeen at redhat.com  Sat Jan 17 18:19:57 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Sat, 17 Jan 2009 12:19:57 -0600
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <b401d2530901171011p1865eac5h1d8b738c027e669d@mail.gmail.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>	<b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>	<49721A67.2000002@redhat.com>
	<b401d2530901171011p1865eac5h1d8b738c027e669d@mail.gmail.com>
Message-ID: <4972214D.9090902@redhat.com>

Rakesh Pandit wrote:

> Thanks
> 
> just small session on mounted partition (/data1 folder):
> 
> [root at test-rocky data1]# mkdir dir1
> [root at test-rocky data1]# cd dir1/
> [root at test-rocky dir1]# touch file1 file2; echo "test" > file3
> [root at test-rocky data1]# cd ..
> 
> root at test-rocky data1]# btrfsctl -s dir1_snap dir1
> ioctl:: Inappropriate ioctl for device
> 
> [root at test-rocky data1]# cd ~
> [root at test-rocky ~]# btrfsctl -a
> Scanning for Btrfs filesystems
> failed to read /dev/sr0
> 
> I am confused, any suggestions here ?

I'd suggest taking it to the btrfs mailing list :)

-Eric



From kevin.kofler at chello.at  Sat Jan 17 18:39:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 17 Jan 2009 19:39:17 +0100
Subject: comps discussion at fudcon and the future
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>	<y9hr634v6dy.fsf@libation.ircam.fr>
	<496F7214.7020109@gmail.com>	<gkoplt$43e$1@ger.gmane.org>
	<4970DE32.5090005@gmail.com> <y9h8wpaydc7.fsf@libation.ircam.fr>
	<49721A4C.4080300@gmail.com>
Message-ID: <gkt8kl$b7d$2@ger.gmane.org>

Toshio Kuratomi wrote:
> It was the case around Fedora 5 or 6.  I never tried to generate a RHEL5
> livecd using that method so I don't know if anaconda had a significant
> difference in RHEL5.

We aren't talking about live CDs here, but about feeding a .ks to the
installer DVD to install a system (or more commonly, many systems,
rerunning Anaconda on each and feeding them the same .ks file) directly
from the .ks (i.e. what Kickstart was originally designed for before it got
reused for live CDs).

        Kevin Kofler



From paul at all-the-johnsons.co.uk  Fri Jan 16 21:36:21 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Fri, 16 Jan 2009 21:36:21 +0000
Subject: Mono 2.2 and F10
Message-ID: <1232141781.18610.43.camel@PB3.Linux>

Hi,

I'm currently importing and building mono-2.2 (inc. libgdiplus,
mono-debugger, mono-basic, mod_mono and xsp) for F10. I will be doing
mono-tools and monodevelop 1.9.1 at some stage soon, but as I don't have
an f10 install anywhere, is there anyway I can instruct rpmbuild to
build for f10?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090116/20230b5f/attachment.sig>

From cdahlin at redhat.com  Sat Jan 17 19:09:17 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sat, 17 Jan 2009 14:09:17 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <1231962712.14403.1559.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
Message-ID: <49722CDD.9080808@redhat.com>

seth vidal wrote:
> On saturday at fudcon we had a small talk (meaning there were only 4 of
> us there: Jeroen, Jeremy, James, and Me) about the future of comps and
> what we need.
>
> We came up with a fairly radical departure that will take some work to
> implement and probably won't land for F11 but it is worth discussing a
> bit now. Please read through the whole thing before jumping all over it.
>
>
> Problems we see:
> - browsing packages is a difficult problem when you have 10000+ pkgs.
> - comps has a lot of meanings and it is not obvious what they all are/do
> - conditional pkgs (which provide a way of saying "install pkgX only 
>   if pkgY is installed) are several colors of doom b/c they aren't a 
>   dependency relationship and creates clutter on systems.
>   

Upstart has a similar dependency situation with services. One solution 
to this is to have packages that are "lazy-installed."

The relationship reads "install this package only if all of its 
dependencies are going to be installed anyway." In your example, pkgX 
would simply depend on pkgY, and be always installed, but "lazy." If 
pkgY is installed, pkgX gets installed, but if pkgY doesn't get 
installed pkgX won't get installed because it depends on pkgY, and 
dependencies may not be resolved strictly on pkgY's behalf.

Dunno that this is a /good idea/ in your case, but thought I'd coompare 
notes.

--CJD

> - users expect groups to be more persistent on their systems and to act
>   more like pkgs (ie: yum update should update groups, too)
> - optional/default/mandatory pkgs are confusing and not useful to most
>   people - the types are only useful when browsing, not when installing.
>
>
> We're still going to have a comps/groups file in the metadata but we'll
> be removing package types. If a package is a member of a group then
> that's it. It's in the group.
>
> When someone goes to install the group: 'yum groupinstall
> mygroup-of-fun' or 'yum install @mygroup-of-fun' then yum will grab the
> comps/groups file from each repo, look if the group you're requesting is
> there. If so it will create a metapkg rpm (a package containing only
> requirements) on the packages that exist in the repositories that are
> listed in that group. Then it will depsolve and install that pkg. The
> package name will be @mygroup-of-fun. The package version will be a hash
> of the contents of the package along with a timestamp. It needs to be
> timestamp-based so the version is increasing so we can 'update' these
> pkgs.
>
> We'll make sure that yum knows about @pkgs to be looked up against the
> comps file (which should be  significantly smaller now).
>
> A yum update @mygroup-of-fun (or just a yum update) will grab the
> comps/groups file. Check to see if the hash has changed. If it has then
> it will create a new rpm and update it accordingly, pulling in the
> necessary deps as it goes.
>
> An additional feature return that this gets us is being able to have
> groups w/i groups.
>
> The reason we're building the packages on-demand instead of like any
> other pkg is that this allows us to merge comps/groups content from
> multiple repositories easily.
>
>
> We do suggest adding some new metadata (probably originating at the
> pkgdb) that will allow us to have keyword/tags for pkgs and ultimately
> tag-cloud browse them, if necessary. It will also afford us additional
> terms to search against for better search results.
>
> Fun, huh?
>
> There's a fair number more things to iron out and constructive and
> helpful remarks are welcome. :)
>
> -sv
>
>
>   



From a.badger at gmail.com  Sat Jan 17 19:12:20 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Sat, 17 Jan 2009 11:12:20 -0800
Subject: comps discussion at fudcon and the future
In-Reply-To: <gkt8kl$b7d$2@ger.gmane.org>
References: <1231962712.14403.1559.camel@rosebud>	<y9hvdsgv9jz.fsf@libation.ircam.fr>	<1232038005.14403.1613.camel@rosebud>	<y9hr634v6dy.fsf@libation.ircam.fr>	<496F7214.7020109@gmail.com>	<gkoplt$43e$1@ger.gmane.org>	<4970DE32.5090005@gmail.com>
	<y9h8wpaydc7.fsf@libation.ircam.fr>	<49721A4C.4080300@gmail.com>
	<gkt8kl$b7d$2@ger.gmane.org>
Message-ID: <49722D94.1040200@gmail.com>

Kevin Kofler wrote:
> Toshio Kuratomi wrote:
>> It was the case around Fedora 5 or 6.  I never tried to generate a RHEL5
>> livecd using that method so I don't know if anaconda had a significant
>> difference in RHEL5.
> 
> We aren't talking about live CDs here, but about feeding a .ks to the
> installer DVD to install a system (or more commonly, many systems,
> rerunning Anaconda on each and feeding them the same .ks file) directly
> from the .ks (i.e. what Kickstart was originally designed for before it got
> reused for live CDs).
> 
There's too much snippage going on here.

Around the Fedora 5/6 timeframe I was working for a company that made
livecds from Fedora.  The build system for the livecds at this company
used kickstart files and anaconda to install to an alternate root dir.
When writing the kickstart files for this system, I noticed that I
needed to "yum remove -y [FOO]" some packages in the %post that I had
already listed as -FOO in the package list section.  -FOO did not remove
the packages because they were listed in one of the groups that was
being pulled in.

We could all be correct in our observations but confusing each other
because nobody is specifying whether <packagereq
type="mandatory|conditional|default|optional"> is being used for the
packages we're trying to remove and there may be different behaviour for
each of these.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/15ab0980/attachment.sig>

From tmraz at redhat.com  Sat Jan 17 19:23:09 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Sat, 17 Jan 2009 20:23:09 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <20090117133328.GA25986@amd.home.annexia.org>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
	<20090117133328.GA25986@amd.home.annexia.org>
Message-ID: <1232220189.5215.116.camel@vespa.frost.loc>

On Sat, 2009-01-17 at 13:33 +0000, Richard W.M. Jones wrote:
> On Fri, Jan 16, 2009 at 02:04:59PM +0100, Tomas Mraz wrote:
> > On Fri, 2009-01-16 at 13:51 +0100, Ralf Ertzinger wrote:
> > > Hi.
> > > 
> > > On Fri, 16 Jan 2009 13:46:25 +0100, Tomas Mraz wrote:
> > > 
> > > > I call ldconfig -X in the %post of openssl which should update the
> > > > cache and not remove the symlinks. Any subsequent calls to ldconfig
> > > > should not remove the symlinks - at least they do not on the system
> > > > where I tested that. So there must be someting else in play.
> > > 
> > > I manually created the two symlinks, and subsequent calls to ldconfig
> > > do not remove them, either.
> > 
> > I added a hack to create the symlinks in %post if they do not exist.
> > Hopefully that helps. I'm building openssl-0.9.8j-2.fc11 just now.
> 
> I have the -3 release installed here and it doesn't seem to work:

That's definitely weird - I'm really curious how do the links get
removed. On my local rawhide install it does not happen. Does it happen
for you on fresh install of rawhide or during updating?

> # wget
> wget: error while loading shared libraries: libcrypto.so.7: cannot open shared object file: No such file or directory
> 
> (same with other programs like git)
> 
> # rpm -q openssl
> openssl-0.9.8j-3.fc11.x86_64
> 
> # rpm -q --scripts openssl
> postinstall scriptlet (using /bin/sh):
> if [ "$(readlink /lib64/libcrypto.so.7)" != libcrypto.so.0.9.8j ] ; then
>     ln -sf libcrypto.so.0.9.8j /lib64/libcrypto.so.7 || :
> fi
> if [ "$(readlink /lib64/libssl.so.7)" != libssl.so.0.9.8j ] ; then
>     ln -sf libssl.so.0.9.8j /lib64/libssl.so.7 || :
> fi
> /sbin/ldconfig -X
> postuninstall scriptlet (using /bin/sh):
> /sbin/ldconfig -X
> postinstall scriptlet (using /bin/sh):
> /sbin/ldconfig -X
> postuninstall scriptlet (using /bin/sh):
> /sbin/ldconfig -X
Now this is really weird - it seems that there are the old scriptlets
from 0.9.8j-1.fc11 in the rpm database as well. How could that happen?
On my install it reports just the first two scriptlets.

> # ll /lib64/libcrypto.so.*
> -rwxr-xr-x 1 root root 1570656 2009-01-16 16:19 /lib64/libcrypto.so.0.9.8j
> lrwxrwxrwx 1 root root      19 2009-01-17 12:26 /lib64/libcrypto.so.8 -> libcrypto.so.0.9.8j
> 
> Anything else I need to try?
At least you could try to reinstall the 0.9.8j-3.fc11 whether it helps.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From sgrubb at redhat.com  Sat Jan 17 19:50:09 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 17 Jan 2009 14:50:09 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <1232211549.3539.4.camel@localhost.localdomain>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<200901171031.07001.sgrubb@redhat.com>
	<1232211549.3539.4.camel@localhost.localdomain>
Message-ID: <200901171450.09772.sgrubb@redhat.com>

On Saturday 17 January 2009 11:59:09 am Jesse Keating wrote:
> We should also make import of keys an auditable event.
>
> Are not all rpm actions audited?

No. What I'm talking about is perhaps defining a specific audit event type 
that would signify that a key was imported and where it came from. I've seen 
cases where rpm tries to download keys from the network. This is one of the 
few security sensitive actions that is not put into the audit system.

-Steve



From kevin.kofler at chello.at  Sat Jan 17 20:04:46 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 17 Jan 2009 21:04:46 +0100
Subject: Massive fallout from missing libssl.so.7 et al
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
	<20090117133328.GA25986@amd.home.annexia.org>
	<1232220189.5215.116.camel@vespa.frost.loc>
Message-ID: <gktdku$phl$1@ger.gmane.org>

Tomas Mraz wrote:
> Now this is really weird - it seems that there are the old scriptlets
> from 0.9.8j-1.fc11 in the rpm database as well. How could that happen?

The postuninstall scriptlet from the old package is run during upgrades.
(It's run AFTER the postinstall scriptlet of the new one. RPM installs the
new package, then removes the old one. Of course only the files which are
not in the new package are removed. But the postun scriptlet is run.)

        Kevin Kofler



From jkeating at redhat.com  Sat Jan 17 20:23:37 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 17 Jan 2009 12:23:37 -0800
Subject: Trying to debug nfs install issue, increase verbosity of nfs server?
Message-ID: <1232223817.3539.12.camel@localhost.localdomain>

I've got an F10 box acting as the NFS server, and I'm getting failures
loading the install.img from NFS.  The failures are of the type that it
cannot mount the directory, even though I can from another host, so I
have to think that something weird is going on server side.  Does
anybody know of a way to increase the verbosity of the nfs server
daemons so that I can see what it is getting from the client?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/c0a1b9a2/attachment.sig>

From jkeating at j2solutions.net  Sat Jan 17 20:29:57 2009
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 17 Jan 2009 12:29:57 -0800
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <1232223817.3539.12.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>
Message-ID: <1232224197.3539.15.camel@localhost.localdomain>

On Sat, 2009-01-17 at 12:23 -0800, Jesse Keating wrote:
> I've got an F10 box acting as the NFS server, and I'm getting failures
> loading the install.img from NFS.  The failures are of the type that it
> cannot mount the directory, even though I can from another host, so I
> have to think that something weird is going on server side.  Does
> anybody know of a way to increase the verbosity of the nfs server
> daemons so that I can see what it is getting from the client?

Never mind.  Turns out that the client couldn't be looked up via it's IP
address, so mount said no (even though it was a warning in the log, not
an error).  Anybody know how to instruct nfs to not care about this?  I
didn't see anything in a quick scan of the exports man page.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/a49a9145/attachment.sig>

From tmraz at redhat.com  Sat Jan 17 21:02:55 2009
From: tmraz at redhat.com (Tomas Mraz)
Date: Sat, 17 Jan 2009 22:02:55 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <gktdku$phl$1@ger.gmane.org>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
	<20090117133328.GA25986@amd.home.annexia.org>
	<1232220189.5215.116.camel@vespa.frost.loc>
	<gktdku$phl$1@ger.gmane.org>
Message-ID: <1232226175.5215.120.camel@vespa.frost.loc>

On Sat, 2009-01-17 at 21:04 +0100, Kevin Kofler wrote:
> Tomas Mraz wrote:
> > Now this is really weird - it seems that there are the old scriptlets
> > from 0.9.8j-1.fc11 in the rpm database as well. How could that happen?
> 
> The postuninstall scriptlet from the old package is run during upgrades.
> (It's run AFTER the postinstall scriptlet of the new one. RPM installs the
> new package, then removes the old one. Of course only the files which are
> not in the new package are removed. But the postun scriptlet is run.)

That could make sense. In case the old package uninstalled is the 0.9.8g
version it will probably cause the %postun ldconfig to remove the
symlink. I've added a triggerpostun scriptlet to reinstate the symlinks
if they are missing to openssl-0.9.8j-5.fc11.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb



From ihok at hotmail.com  Sat Jan 17 21:07:02 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 17 Jan 2009 21:07:02 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090117141719.GA4726@free.fr>
Message-ID: <loom.20090117T210527-791@post.gmane.org>

Patrice Dumas <pertusus <at> free.fr> writes:

> 
> Are you sure that mpd is relevant here? Isn't it higher layer than
> pam_console/hal...?

All I can tell you is that for mpd to be able to use /dev/sound,
I had to set /dev/sound permissions via console.perms.d .



From pertusus at free.fr  Sat Jan 17 21:14:47 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 17 Jan 2009 22:14:47 +0100
Subject: pam_console
In-Reply-To: <loom.20090117T210527-791@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090117141719.GA4726@free.fr>
	<loom.20090117T210527-791@post.gmane.org>
Message-ID: <20090117211447.GA13029@free.fr>

On Sat, Jan 17, 2009 at 09:07:02PM +0000, Jack Tanner wrote:
> Patrice Dumas <pertusus <at> free.fr> writes:
> 
> > 
> > Are you sure that mpd is relevant here? Isn't it higher layer than
> > pam_console/hal...?
> 
> All I can tell you is that for mpd to be able to use /dev/sound,
> I had to set /dev/sound permissions via console.perms.d .

I see. Indeed, there needs to be some interaction with hal/* to
set the acls/permissions differently.

--
Pat



From yaneti at declera.com  Sat Jan 17 21:56:40 2009
From: yaneti at declera.com (Yanko Kaneti)
Date: Sat, 17 Jan 2009 23:56:40 +0200
Subject: rawhide report: 20090116 changes (broken fc-cache)
In-Reply-To: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
Message-ID: <1232229400.12554.3.camel@d2>


> fontconfig-2.6.90-3.git.63.g6bb4b9a.fc11
> ----------------------------------------
> * Fri Jan 16 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.90-3.git.63.g6bb4b9a
> - Install fc-scan and fc-query
> 
> * Fri Jan 16 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.90-2.git.63.g6bb4b9a
> - Update to 2.6.90-1.git.63.g6bb4b9a
> - Remove upstreamed patch

Breaks fontconfig caching. bisecting points to 
http://cgit.freedesktop.org/~behdad/fontconfig/commit/?id=66a94a0f8347f2d8bf371e99d10f349fc1b4b1ea


Regards
Yanko



From josef at toxicpanda.com  Sat Jan 17 22:27:11 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Sat, 17 Jan 2009 17:27:11 -0500
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <4972214D.9090902@redhat.com>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<b401d2530901170946p2af70e00wde6788f80f425513@mail.gmail.com>
	<49721A67.2000002@redhat.com>
	<b401d2530901171011p1865eac5h1d8b738c027e669d@mail.gmail.com>
	<4972214D.9090902@redhat.com>
Message-ID: <1b7401870901171427g5bd33f93g5d95be6a72575ff2@mail.gmail.com>

On Sat, Jan 17, 2009 at 1:19 PM, Eric Sandeen <sandeen at redhat.com> wrote:
> Rakesh Pandit wrote:
>
>> Thanks
>>
>> just small session on mounted partition (/data1 folder):
>>
>> [root at test-rocky data1]# mkdir dir1
>> [root at test-rocky data1]# cd dir1/
>> [root at test-rocky dir1]# touch file1 file2; echo "test" > file3
>> [root at test-rocky data1]# cd ..
>>
>> root at test-rocky data1]# btrfsctl -s dir1_snap dir1
>> ioctl:: Inappropriate ioctl for device
>>
>> [root at test-rocky data1]# cd ~
>> [root at test-rocky ~]# btrfsctl -a
>> Scanning for Btrfs filesystems
>> failed to read /dev/sr0
>>

Updated ioctl's for -rc2.  I just pushed the -0.18 package into
rawhide, it should start working tomorrow.  The joys of a devel fs :).

Josef



From jamatos at fc.up.pt  Sat Jan 17 23:39:28 2009
From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=)
Date: Sat, 17 Jan 2009 23:39:28 +0000
Subject: comps discussion at fudcon and the future
In-Reply-To: <1232119784.4912.21.camel@rosebud>
References: <1231962712.14403.1559.camel@rosebud>
	<alpine.DEB.1.10.0901160926310.32512@gotcha.dreamhost.com>
	<1232119784.4912.21.camel@rosebud>
Message-ID: <200901172339.29120.jamatos@fc.up.pt>

On Friday 16 January 2009 15:29:44 seth vidal wrote:
> And it means we have to cope with stupidity like:
> Enhances: glibc
>
> which pulls in the pkg for EVERYONE.

SCNR

The appropriate counter-measure would be in glibc

%define __allow_enhancements %{nil}

;-)

> -sv

-- 
Jos? Ab?lio



From mcepl at redhat.com  Sat Jan 17 23:31:15 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Sun, 18 Jan 2009 00:31:15 +0100
Subject: Is it time to kill python-sqlite2 on Fedora >= 10?
References: <o9q846x2su.ln2@ppp1053.in.ipex.cz>
	<20090117130154.GA19059@ee.oulu.fi>
Message-ID: <3b6a46x708.ln2@ppp1053.in.ipex.cz>

On 2009-01-17, 13:01 GMT, Pekka Pietikainen wrote:
>> Is there something python-sqlite2 has which python2.5 doesn't?
> Well, python-sqlite2 gets to move ahead faster, there's the occasional
> performance boost tweak / new feature that takes forever to get into upstream
> python. 
>
> I'd minimize/remove dependencies on it, and then just ship the latest
> version for those developers that like to live on the edge :-)

Yeah, that's probably much more sane -- there is really no reason 
to remove python-sqlite2 from distro; if anybody wants to 
maintain, then she should certainly have a way. However, no-one 
should be forced to have it install against her will.

Best,

Mat?j



From konrad at tylerc.org  Sun Jan 18 00:17:54 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 17 Jan 2009 16:17:54 -0800
Subject: Mono 2.2 and F10
In-Reply-To: <1232141781.18610.43.camel@PB3.Linux>
References: <1232141781.18610.43.camel@PB3.Linux>
Message-ID: <200901171617.55013.konrad@tylerc.org>

On Friday 16 January 2009 01:36:21 pm Paul wrote:
> Hi,
>
> I'm currently importing and building mono-2.2 (inc. libgdiplus,
> mono-debugger, mono-basic, mod_mono and xsp) for F10. I will be doing
> mono-tools and monodevelop 1.9.1 at some stage soon, but as I don't have
> an f10 install anywhere, is there anyway I can instruct rpmbuild to
> build for f10?
>
> TTFN
>
> Paul

mock -r fedora-10-i386 <foo>.srpm

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From paul at all-the-johnsons.co.uk  Sun Jan 18 00:35:19 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Sun, 18 Jan 2009 00:35:19 +0000
Subject: sed question
Message-ID: <1232238919.32529.17.camel@PB3.Linux>

Hi,

mono-debugger has a line in the configure.in with $(prefix)/lib on it
twice.

If I have

sed -i -e 's!$(prefix)/lib!%{_libdir}!' configure.in

then only the first occurrence of the $(prefix)/lib is replaced (same
applies if I create a patch with @libdir@ instead of the $(prefix)/lib
and then apply a similar sed replacement to the patch)

I've looked at the manual and this seems to be correct, but it's not (as
it's not working!). Any clues on how to do a multiple replace on the
same line?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/d467d67e/attachment.sig>

From ivazqueznet at gmail.com  Sun Jan 18 00:43:40 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Sat, 17 Jan 2009 19:43:40 -0500
Subject: sed question
In-Reply-To: <1232238919.32529.17.camel@PB3.Linux>
References: <1232238919.32529.17.camel@PB3.Linux>
Message-ID: <a8d6caf0901171643ocbd3b5cgaf20e62ac7c2c9f6@mail.gmail.com>

2009/1/17 Paul <paul at all-the-johnsons.co.uk>

> Hi,
>
> mono-debugger has a line in the configure.in with $(prefix)/lib on it
> twice.
>
> If I have
>
> sed -i -e 's!$(prefix)/lib!%{_libdir}!' configure.in
>
> then only the first occurrence of the $(prefix)/lib is replaced (same
> applies if I create a patch with @libdir@ instead of the $(prefix)/lib
> and then apply a similar sed replacement to the patch)
>
> I've looked at the manual and this seems to be correct, but it's not (as
> it's not working!). Any clues on how to do a multiple replace on the
> same line?
>
> TTFN
>
> Paul
> --
> ?Sie k?nnen mich aufreizen und wirklich hei? machen!
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

sed -i -e 's!$(prefix)/lib!%{_libdir}!g' configure.in

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/4e2aab0e/attachment.htm>

From lamont at lamontpeterson.org  Sun Jan 18 04:17:47 2009
From: lamont at lamontpeterson.org (Lamont Peterson)
Date: Sat, 17 Jan 2009 21:17:47 -0700
Subject: sed question
In-Reply-To: <1232238919.32529.17.camel@PB3.Linux>
References: <1232238919.32529.17.camel@PB3.Linux>
Message-ID: <200901172117.52873.lamont@lamontpeterson.org>

On Saturday 17 January 2009 05:35:19 pm Paul wrote:
> Hi,
>
> mono-debugger has a line in the configure.in with $(prefix)/lib on it
> twice.
>
> If I have
>
> sed -i -e 's!$(prefix)/lib!%{_libdir}!' configure.in

Just add 'g':

 sed -i -e 's!$(prefix)/lib!%{_libdir}!g' configure.in

> then only the first occurrence of the $(prefix)/lib is replaced (same
> applies if I create a patch with @libdir@ instead of the $(prefix)/lib
> and then apply a similar sed replacement to the patch)
>
> I've looked at the manual and this seems to be correct, but it's not (as
> it's not working!). Any clues on how to do a multiple replace on the
> same line?
>
> TTFN
>
> Paul
-- 
Lamont Peterson <lamont at lamontpeterson.org>
[ http://lamontpeterson.org/ ]
GPG Key fingerprint: C51E DD83 B03F D147 A974  939C 5D13 289C 17F1 FFBE
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090117/b6572042/attachment.sig>

From randyn3lrx at gmail.com  Sun Jan 18 05:34:01 2009
From: randyn3lrx at gmail.com (Randy Berry)
Date: Sun, 18 Jan 2009 00:34:01 -0500
Subject: Problem with autotools
Message-ID: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>

I am trying to build a package and the source relies on autotools. I'm
getting an error during the build install stage that I don't
understand.
Below are the pastes to the errors I am getting when trying to run
'rpmbuild -bi'

rpmbuild full output: http://fpaste.org/paste/1661
spec file: http://fpaste.org/paste/1662
rpmbuild output (short version): http://fpaste.org/paste/1664

Anyone familiar with this error that knows how to fix it?
I'm pretty sure a patch is needed and I know how to make and apply a
patch I just don't know where to begin at making the patch.

Thanks,



From loganjerry at gmail.com  Sun Jan 18 06:11:52 2009
From: loganjerry at gmail.com (Jerry James)
Date: Sat, 17 Jan 2009 23:11:52 -0700
Subject: GCL is back ... mostly
Message-ID: <870180fe0901172211x16b9dedeg8d07e13fc334d7e1@mail.gmail.com>

GCL is building once again.  Although I made some progress on ppc64,
each new problem solved led to a new one.  It looks like that platform
is going to take some work.  In the meantime, the i386, x86_64, and
ppc builds are now available in Rawhide.  I asked for builds to be
pushed directly to stable on F-9 and F-10.  I figured there was no
point in going to testing first, since there are no builds in stable
right now.  Please try it out and bugzilla any problems you have.

SELinux note: GCL now has an accompanying SELinux policy.  If you dump
an image, you will probably need to give it type gcl_exec_t for it to
execute properly on SELinux-enabled systems.
-- 
Jerry James
http://loganjerry.googlepages.com/



From rawhide at fedoraproject.org  Sun Jan 18 08:18:06 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 18 Jan 2009 08:18:06 +0000 (UTC)
Subject: rawhide report: 20090118 changes
Message-ID: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>

Compose started at Sun Jan 18 06:01:03 UTC 2009

New package gtksourceviewmm
        A C++ wrapper for the gtksourceview widget library
New package jpilot-backup
        Enhanced backup plugin for J-Pilot
New package mingw32-SDL
        MinGW Windows port of SDL cross-platform multimedia library
New package mingw32-dlfcn
        Implements a wrapper for dlfcn (dlopen dlclose dlsym dlerror)
New package mingw32-freetype
        Free and portable font rendering engine
New package mingw32-gdbm
        MinGW port of GNU database routines
New package mingw32-gettext
        GNU libraries and utilities for producing multi-lingual messages
New package mingw32-pdcurses
        Curses library for MinGW
New package mingw32-readline
        MinGW port of readline for editing typed command lines
New package mingw32-sqlite
        MinGW Windows port of sqlite embeddable SQL database engine
New package python-libasyncns
        Python binding for libasyncns
New package rubygem-tlsmail
        This library enables pop or smtp via ssl/tls
Updated Packages:

ImageMagick-6.4.5.5-7.fc11
--------------------------
* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 6.4.5.5-7
- Corrected the wrong release and bumped

* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> 6.4.5.5-6
- Rebuild with new djvulibre


Miro-1.2.8-5.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.8-5
- rebuild with new openssl


OpenIPMI-2.0.14-10.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.0.14-10
- rebuild with new openssl


btrfs-progs-0.18-1.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Josef Bacik <josef at toxicpanda.com> 0.18-1
- updated to 0.18 because of the ioctl change in 2.6.29-rc2


cairo-dock-2.0.0-0.3.svn1488_trunk.fc11
---------------------------------------
* Sun Jan 18 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1488


cduce-0.5.2.1-13.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 0.5.2.1-13
- Add ocamlduce subpackage.
- Capitalize the summary line as per packaging guidelines.


control-center-2.25.3-3.fc11
----------------------------

djview4-4.3-3.fc11
------------------
* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 4.3-3
- Rebuild with new djvulibre


dustin-dustismo-fonts-20030318-3.fc11
-------------------------------------

ecolier-court-fonts-20070702-7.fc11
-----------------------------------
* Sat Jan 17 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 20070702-7
??? Convert to new naming guidelines


egoboo-2.7.5-5.fc11
-------------------
* Sun Jan 18 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 2.7.5-5
- Rebuild for new enet update.


ethtool-6-2.20090115git.fc11
----------------------------
* Sat Jan 17 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 6-2.20090115git
- Changes to match with Fedora Packaging Guidelines (#225735)
- Upgrade to GIT 20090115 (#225735, #477498)
- Removed bogus stated need of DEVNAME in -h/--help (#472038)
- Removed completely needless INSTALL file from %doc (#472034)


evince-2.25.4-2.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 2.25.4-2
- Rebuild with mew djvulibre


feh-1.3.4-11.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Ignacio Vazquez-Abrams <ivazqueznet+rpm at gmail.com> 1.3.4-11
- Fix font Requires


gcl-2.6.8-0.1.20080902cvs.1.fc11
--------------------------------
* Sat Jan 17 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 2.6.8-0.1.20080902cvs.1
- ExcludeArch ppc64 for now until I can figure out why it doesn't build

* Fri Jan  9 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 2.6.8-0.1.20080902cvs
- Update from CVS to fix many build problems
- Fix SELinux and BFD problems that blocked the build
- Add patches to address various build and runtime problems
- Drop old patches that are obsoleted by the update from CVS
- Split out emacs and xemacs subpackages

* Mon Jul 21 18:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 2.6.7-19
- fix license tag


goocanvas-0.13-1.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.13-1
- Update to upstream 0.13
- Updated URLs to gnome.org


gwibber-0.7.2-5.165bzr.fc11
---------------------------
* Sat Jan 17 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.2-5.165bzr.fc11
- Enable spell checking by adding missing requires on python-sexy.


heartbeat-2.1.4-4.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 2.1.4-4
- Main package shouldn't require pygtk2 (#480157)


http_ping-20050629-8.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 20050629-8
- rebuild with new openssl


httperf-0.9.0-3.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.0-3
- rebuild with new openssl


ice-3.3.0-11.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.3.0-11
- rebuild with new openssl


ike-scan-1.9-6.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.9-6
- rebuild with new openssl


inkscape-0.46-10.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.46-10
- rebuild with new openssl


ipa-1.2.1-3.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.1-3
- rebuild with new openssl


ipmitool-1.8.10-3.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.8.10-3
- rebuild with new openssl


ircd-hybrid-7.2.3-7.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 7.2.3-7
- rebuild with new openssl


ircd-ratbox-2.2.8-3.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.2.8-3
- rebuild with new openssl


irssi-0.8.12-12.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.8.12-12
- rebuild with new openssl


isns-utils-0.91-1.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.91-1
- rebuild with new openssl


isync-1.0.4-2.fc11
------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.0.4-2
- rebuild with new openssl


jabbim-0.4.3-5.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Michal Schmidt <mschmidt at redhat.com> - 0.4.3-5
- Don't require python-sqlite2. Python >= 2.5 has sqlite support already.


jabbin-2.0-0.7.beta2a.fc11
--------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.0-0.7.beta2a
- rebuild with new openssl


jd-2.2.0-0.1.svn2628_trunk.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2628


jpilot-1.6.0-3.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.6.0-3
- rebuild with new openssl


kadu-0.6.5-8.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.6.5-8
- rebuild with new openssl


kannel-1.4.1-10
---------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.4.1-10
- rebuild with new openssl


kasablanca-0.4.0.2-13.fc11
--------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.4.0.2-13
- rebuild with new openssl


kdegraphics-4.1.96-2.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 4.1.96-2
- Updated with new djvulibre


kdiff3-0.9.94-1.fc11
--------------------
* Fri Jan  9 17:00:00 2009 Neal Becker <ndbecker2 at gmail.com> - 0.9.93-1.3.fc11
- Update to 0.9.93-3


keepalived-1.1.15-7.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.1.15-7
- rebuild with new openssl


kftpgrabber-0.8.1-7.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.8.1-7
- rebuild with new openssl


ldapvi-1.7-7.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.7-7
- rebuild with new openssl


libesmtp-1.0.4-9.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.0.4-9
- rebuild with new openssl

* Sat Nov  1 18:00:00 2008 Manuel "lonely wolf" Wolfshant <wolfy at fedoraproject.org> - 1.0.4-8
- do not package libtool files from the plugin directory


libfprint-0.1.0-4.pre1.fc11
---------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.1.0-4.pre1
- rebuild with new openssl


libgadu-1.8.2-2.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.8.2-2
- rebuild with new openssl


libjingle-0.3.12-2.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.3.12-2
- rebuild with new openssl


libmsn-4.0-0.7.beta2.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 4.0-0.7.beta2
- rebuild with new openssl


libnasl-2.2.11-4.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.2.11-4
- rebuild with new openssl


libp11-0.2.3-5.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.2.3-5
- rebuild with new openssl


libsmbios-2.2.8-1.fc11
----------------------
* Thu Jan 15 17:00:00 2009 Michael E Brown <michael_e_brown at dell.com> - 2.2.8-1
- revert change in upstream renaming rpm to libsmbios2

* Thu Jan 15 17:00:00 2009 Michael E Brown <michael_e_brown at dell.com> - 2.2.7-1
- change source to bz2 format
- Update to latest upstream release. Many changes in the new release:
  - python interface
  - libsmbios_c interface almost fully implemented
  - libsmbios c++ interface deprecated

* Tue Oct 28 18:00:00 2008 Michael E Brown <michael_e_brown at dell.com> - 2.2.0-1
- Spec updates


libssh2-0.18-8.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.18-8
- rebuild with new openssl


libtorrent-0.12.4-2.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.12.4-2
- rebuild with new openssl


libwvstreams-4.5.1-3.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 4.5.1-3
- rebuild with new openssl


licq-1.3.5-5.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.3.5-5
- rebuild with new openssl


lincity-ng-1.97-0.3.beta.fc11
-----------------------------
* Sat Jan 17 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.97-0.3.beta
- fix Requires: dejavu-sans-fonts


linuxdcpp-1.0.2-3.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.0.2-3
- rebuild with new openssl


lynx-2.8.6-19.fc11
------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.8.6-19
- rebuild with new openssl


m2crypto-0.19.1-4
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.19.1-4
- rebuild with new openssl


mail-notification-5.4-8.fc11
----------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.4-8
- rebuild with new openssl


mapserver-5.2.1-4.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 5.2.1-4
- rebuild with new openssl


mcabber-0.9.9-2.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.9-2
- rebuild with new openssl


mod_authz_ldap-0.26-11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.26-11
- rebuild with new openssl


monit-4.10.1-9.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 4.10.1-9
- rebuild with new openssl


mono-tools-2.4-1.20091601svn123182.fc11
---------------------------------------
* Fri Jan 16 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> - 2.4-1.20091601svn123182
- Move to 2.4 svn branch


monodevelop-1.9.2-pre1.20090116svn123651.fc11
---------------------------------------------
* Fri Jan 16 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 1.9.2-pre1.20090116svn123651
- Update from svn
- Altered nunit patch


munin-1.2.6-7.fc11
------------------
* Sat Jan 17 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.6-7
- Adjust font requires for new dejavu-sans-mono-fonts name (fixes #480463)


nagios-plugins-1.4.13-12.fc11
-----------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.4.13-12
- rebuild with new openssl


nagios-plugins-snmp-disk-proc-1.2-3.fc11
----------------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2-3
- rebuild with new openssl


nemiver-0.6.4-1.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.6.4-1
- Update to upstream 0.6.4
- Now build against gtksourceviewmm 2.2.0


nessus-core-2.2.11-2.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.2.11-2
- rebuild with new openssl


net-snmp-5.4.2.1-7.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 5.4.2.1-7
- rebuild with new openssl


netatalk-2.0.3-23.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 4:2.0.3-23
- rebuild with new openssl


nginx-0.6.34-2.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.6.34-2
- rebuild with new openssl


nmap-4.76-3.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2:4.76-3
- rebuild with new openssl


nrpe-2.12-5.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.12-5
- rebuild with new openssl


nsd-3.2.0-4.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.2.0-4
- rebuild with new openssl


nufw-2.2.20-6.fc11
------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.2.20-6
- rebuild with new openssl


nut-2.2.2-6.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.2.2-6
- rebuild with new openssl


nx-3.2.0-32.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.2.0-32
- rebuild with new openssl


ocaml-mysql-1.0.4-6.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-6
- Requires mysql-libs, not automatically found.


ocspd-1.5.1-0.4.rc1.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.5.1-0.4.rc1
- rebuild with new openssl


opal-3.5.2-4.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.5.2-4
- rebuild with new openssl


openconnect-0.99-2.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.99-2
- rebuild with new openssl


openhpi-2.13.1-3.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.13.1-3
- rebuild with new openssl


openhpi-subagent-2.3.4-4.fc11
-----------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.3.4-4
- rebuild with new openssl


openldap-2.4.12-3.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.4.11-3
- rebuild with new openssl


openslp-1.2.1-10.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.1-10
- rebuild with new openssl


openssl-0.9.8j-5.fc11
---------------------

openvpn-2.1-0.31.rc15.fc11
--------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.1-0.31.rc15
- rebuild with new openssl


osslsigncode-1.2-5.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2-5
- rebuild with new openssl


pam_mount-1.4-2.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.4-2
- rebuild with new openssl

* Thu Nov 27 17:00:00 2008 Till Maas <opensource at till.name> - 1.4-1
- Update to new release
- Add patch to support fsck mount option

* Sun Oct 26 18:00:00 2008 Till Maas <opensource at till.name> - 1.2-2
- Add patch to mount luks volumes without -o cipher

* Sat Oct 25 18:00:00 2008 Till Maas <opensource at till.name> - 1.2-1
- Update to new release
- remove config conversion script
- add crypt_LUKS symlinks
- remove psmisc dependency, lsof is no longer used


paraview-3.4.0-3.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.4.0-3
- rebuild with new openssl


perl-Crypt-OpenSSL-AES-0.02-6.fc11
----------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.02-6
- rebuild with new openssl


perl-Crypt-OpenSSL-Bignum-0.04-5.fc11
-------------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.04-5
- rebuild with new openssl


perl-Crypt-OpenSSL-DSA-0.13-8.fc11
----------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.13-8
- rebuild with new openssl


perl-Crypt-OpenSSL-PKCS10-0.06-10.fc11
--------------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.06-10
- rebuild with new openssl


perl-Crypt-OpenSSL-RSA-0.25-7.fc11
----------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.25-7
- rebuild with new openssl


perl-Crypt-OpenSSL-Random-0.04-6.fc11
-------------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.04-6
- rebuild with new openssl


perl-Crypt-OpenSSL-X509-0.7-2.fc11
----------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.7-2
- rebuild with new openssl


perl-Crypt-SSLeay-0.57-10.fc11
------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.57-10
- rebuild with new openssl


perl-Image-Math-Constrain-1.02-1.fc11
-------------------------------------
* Tue Aug  5 18:00:00 2008 Steven Pritchard <steve at kspei.com> 1.02-1
- Update to 1.02.
- BR Test::More, Test::CPAN::Meta, and Test::MinimumVersion.
- Set AUTOMATED_TESTING so we run the pod and meta tests.


perl-Net-SSLeay-1.35-2.fc11
---------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.35-2
- rebuild with new openssl


perl-SVK-2.2.1-1.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Ian Burrell <ianburrell at gmail.com> - 2.2.1-1
- Update to 2.2.1


perl-SVN-Mirror-0.75-1.fc11
---------------------------
* Sat Jan 17 17:00:00 2009 Ian Burrell <ianburrell at gmail.com> - 0.75-1
- Update to 0.75 with test fixes for subversion 1.5.0


perl-Spreadsheet-ParseExcel-0.4500-1.fc11
-----------------------------------------
* Sat Jan 17 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.4500-1
- Update to 0.45.
- s/Get/Extract/ in Summary.
- Update Source0 URL.
- Update description.
- Fix line endings in README and samples.


perl-YAML-Tiny-1.36-1.fc11
--------------------------
* Sat Jan 17 17:00:00 2009 Steven Pritchard <steve at kspei.com> 1.36-1
- Update to 1.36.
- BR Test::More.


pinot-0.89-4.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.89-4
- rebuild with new openssl


pitivi-0.11.3-2.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 0.11.3-2
- Add patch from Denis Leroy to fix running with Python 2.6


pl-5.6.60-3.fc11
----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.6.60-3
- rebuild with new openssl


player-2.1.1-9.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.1.1-9
- rebuild with new openssl


postgresql-8.3.5-3.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 8.3.5-3
- rebuild with new openssl


ptlib-2.5.2-4.fc11
------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.5.2-4
- rebuild with new openssl


pwlib-1.10.10-11.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.10.10-11
- rebuild with new openssl


pwsafe-0.2.0-6.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.2.0-6
- rebuild with new openssl


pygoocanvas-0.13.1-1.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.13.1-1
- Update to 0.13.1
- Updated URLs to gnome.org


pysvn-1.6.2-3.fc11
------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.6.2-3
- rebuild with new openssl


qca-tls-1.0-15.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.0-15
- rebuild with new openssl


qmmp-0.2.3-2.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.2.3-2
- rebuild with new openssl


rasqal-0.9.15-3.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> 0.9.15-3
- disable testsuite so this builds
- rebuild for pkg-config Provides

* Sun Nov 23 17:00:00 2008 Thomas Vander Stichele <thomas at apestaart dot org>
- 0.9.15-2
- update summary
- not rebuilt yet


rdesktop-1.6.0-3.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.6.0-3
- rebuild with new openssl


rdiff-backup-1.2.5-1.fc11
-------------------------
* Sat Jan 17 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.5-1
- Update to 1.2.5


ricci-0.15.0-9.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.15.0-9
- rebuild with new openssl


Summary:
Added Packages: 12
Removed Packages: 0
Modified Packages: 122
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.i386 requires smc-fonts-meera
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.x86_64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From choeger at cs.tu-berlin.de  Sun Jan 18 11:42:48 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sun, 18 Jan 2009 12:42:48 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090116132611.GA9750@dspnet.fr.eu.org>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
Message-ID: <1232278968.4226.14.camel@choeger6>

> How much of that is pci ranges mmaps?

I think thats it:

Taken from xorg's smaps:
(That is alot, isn't it?)

a7cbc000-b7cbc000 rw-s e0000000 00:00
5297       /sys/devices/pci0000:00/0000:00:02.0/resource2
Size:             262144 kB
Rss:              262144 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Swap:                  0 kB
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/54c8eb9d/attachment.sig>

From mspevack at redhat.com  Sun Jan 18 11:58:35 2009
From: mspevack at redhat.com (Max Spevack)
Date: Sun, 18 Jan 2009 12:58:35 +0100 (CET)
Subject: LinuxTag 2009 speaking opportunities
Message-ID: <alpine.LFD.2.00.0901181258210.20810@localhost.localdomain>

If you already know that you will attend LinuxTag 2009 and would like to 
give a talk, please do the right thing on this page.

It should be self-explanatory.  We are looking for talks on a variety of 
subjects and a variety of levels of technical depth.  You may sign up to 
give your talk in either English or German.

 	https://fedoraproject.org/wiki/LinuxTag_2009_talks

Feel free to share the link with anyone in the Fedora or JBoss.org 
community who might be interested.

The (still in planning) page for LinuxTag 2009 is here:

 	https://fedoraproject.org/wiki/LinuxTag2009

--Max



From galibert at pobox.com  Sun Jan 18 12:14:39 2009
From: galibert at pobox.com (Olivier Galibert)
Date: Sun, 18 Jan 2009 13:14:39 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232278968.4226.14.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
Message-ID: <20090118121439.GA72117@dspnet.fr.eu.org>

On Sun, Jan 18, 2009 at 12:42:48PM +0100, Christoph H?ger wrote:
> > How much of that is pci ranges mmaps?
> 
> I think thats it:
> 
> Taken from xorg's smaps:
> (That is alot, isn't it?)
> 
> a7cbc000-b7cbc000 rw-s e0000000 00:00
> 5297       /sys/devices/pci0000:00/0000:00:02.0/resource2
> Size:             262144 kB
> Rss:              262144 kB

Do you have 256M of ram in your video card perchance?

  OG.



From choeger at cs.tu-berlin.de  Sun Jan 18 13:04:59 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sun, 18 Jan 2009 14:04:59 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <20090118121439.GA72117@dspnet.fr.eu.org>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
	<20090118121439.GA72117@dspnet.fr.eu.org>
Message-ID: <1232283899.4226.17.camel@choeger6>

Am Sonntag, den 18.01.2009, 13:14 +0100 schrieb Olivier Galibert:
> On Sun, Jan 18, 2009 at 12:42:48PM +0100, Christoph H?ger wrote:
> > > How much of that is pci ranges mmaps?
> > 
> > I think thats it:
> > 
> > Taken from xorg's smaps:
> > (That is alot, isn't it?)
> > 
> > a7cbc000-b7cbc000 rw-s e0000000 00:00
> > 5297       /sys/devices/pci0000:00/0000:00:02.0/resource2
> > Size:             262144 kB
> > Rss:              262144 kB
> 
> Do you have 256M of ram in your video card perchance?
> 
>   OG.
> 

I don't think so, it's an:

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)

And even if I had that much memory xserver probably should not use the
same amount of RAM.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/dfa2416a/attachment.sig>

From galibert at pobox.com  Sun Jan 18 13:18:56 2009
From: galibert at pobox.com (Olivier Galibert)
Date: Sun, 18 Jan 2009 14:18:56 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232283899.4226.17.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
	<20090118121439.GA72117@dspnet.fr.eu.org>
	<1232283899.4226.17.camel@choeger6>
Message-ID: <20090118131856.GA80859@dspnet.fr.eu.org>

On Sun, Jan 18, 2009 at 02:04:59PM +0100, Christoph H?ger wrote:
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 0c)
> 
> And even if I had that much memory xserver probably should not use the
> same amount of RAM.

Ah indeed, that one shares main ram afaik.  Maybe it's simply the AGP
aperture or something of the kind.  Entirely virtual, in other terms.

  OG.



From fedora at leemhuis.info  Sun Jan 18 13:29:35 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 18 Jan 2009 14:29:35 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232283899.4226.17.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>	<20090116132611.GA9750@dspnet.fr.eu.org>	<1232278968.4226.14.camel@choeger6>	<20090118121439.GA72117@dspnet.fr.eu.org>
	<1232283899.4226.17.camel@choeger6>
Message-ID: <49732EBF.4010509@leemhuis.info>

On 18.01.2009 14:04, Christoph H?ger wrote:
> Am Sonntag, den 18.01.2009, 13:14 +0100 schrieb Olivier Galibert:
>> On Sun, Jan 18, 2009 at 12:42:48PM +0100, Christoph H?ger wrote:
>>>> How much of that is pci ranges mmaps?
>>> I think thats it:
>>>
>>> Taken from xorg's smaps:
>>> (That is alot, isn't it?)
>>>
>>> a7cbc000-b7cbc000 rw-s e0000000 00:00
>>> 5297       /sys/devices/pci0000:00/0000:00:02.0/resource2
>>> Size:             262144 kB
>>> Rss:              262144 kB
>> Do you have 256M of ram in your video card perchance?
> 
> I don't think so, it's an:
> 
> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (rev 0c)

The boards BIOS normally steals 8 MByte RAM (can be changed in some 
BIOSes) from the systems memory as video RAM for the graphics core in 
modern intel chipsets. But the kernel and the drivers for X and windows 
later can request more later (up to 384 iirc; some BIOSes offer options 
to change the maximum amount and the technique to request that memory), 
as you actually need more for 3D apps.

That's what your kernel and X-Server likely did for you. The X servers 
log should tell. On my GM965 is says in one area:

> (II) intel(0): Fixed memory allocation layout:
> (II) intel(0): 0x00000000-0x00000fff: power context (4 kB)
> (II) intel(0): 0x0077f000:            end of stolen memory
> (II) intel(0): 0x0077f000-0x0e6affff: DRI memory manager (228548 kB)
                                                             ^^^^^^^^^
> (II) intel(0): 0x0e6b0000-0x0fffffff: exa offscreen (25920 kB)
                                                        ^^^^^^^^
> (II) intel(0): 0x10000000:            end of aperture
> (II) intel(0): BO memory allocation layout:
> (II) intel(0): 0x0077f000:            start of memory manager
> (II) intel(0): 0x0079f000-0x0100efff: depth buffer (8640 kB) Y tiled
> (II) intel(0): 0x0179f000-0x0200efff: back buffer (8640 kB) X tiled
> (II) intel(0): 0x02800000-0x0306ffff: front buffer (8640 kB) X tiled
> (II) intel(0): 0x0279f000-0x0279ffff: overlay registers (4 kB)
> (II) intel(0): 0x027a0000-0x027b5fff: exa G965 state buffer (88 kB)
> (II) intel(0): 0x027c0000-0x027c7fff: logical 3D context (32 kB)
> (II) intel(0): 0x027c8000-0x027d1fff: HW cursors (40 kB)
> (II) intel(0): 0x0e6b0000:            end of memory manager

HTH

CU
knurd



From choeger at cs.tu-berlin.de  Sun Jan 18 14:11:26 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Sun, 18 Jan 2009 15:11:26 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <49732EBF.4010509@leemhuis.info>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
	<20090118121439.GA72117@dspnet.fr.eu.org>
	<1232283899.4226.17.camel@choeger6>  <49732EBF.4010509@leemhuis.info>
Message-ID: <1232287886.20264.9.camel@choeger6>

That's what I got,

(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB)
(II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB)
(II) intel(0): 0x00032000-0x00041fff: exa G965 state buffer (64 kB)
(II) intel(0): 0x00042000-0x00042fff: overlay registers (4 kB)
(II) intel(0): 0x00043000-0x00043fff: power context (4 kB)
(II) intel(0): 0x00100000-0x0073ffff: front buffer (6400 kB) X tiled
(II) intel(0): 0x00740000-0x019fffff: exa offscreen (19200 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x01a00000-0x0203ffff: back buffer (6400 kB) X tiled
(II) intel(0): 0x02040000-0x0267ffff: depth buffer (6400 kB) Y tiled
(II) intel(0): 0x02680000-0x0467ffff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture
(WW) intel(0): ESR is 0x00000001
(WW) intel(0): Existing errors found in hardware state.

But I still consider it a leakage. I'm following the memory consumption
minute by minute now without doing anything. It raises faster and
faster. From roughly 1/2M per minute to more than 5M/min. Right now it
jumped up by 8M. (All taken from top's RES field)
I would understand that memory is taken as graphics memory if high
performance graphics stuff is done, but I suppose it should drop down
again (and not raise when no intense stuff is done).


-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/82733bfa/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Sun Jan 18 15:46:46 2009
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Sun, 18 Jan 2009 16:46:46 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232111406.18033.18.camel@choeger6> (Christoph
	=?iso-8859-1?Q?H=F6ger's?= message of "Fri, 16 Jan 2009 14:10:06 +0100")
References: <1232111406.18033.18.camel@choeger6>
Message-ID: <87r63039cp.fsf@sheridan.bigo.ensc.de>

Christoph H?ger <choeger at cs.tu-berlin.de> writes:

> I am seeing this since a while, Xorg really sucks somewhere in memory
> management.

Long standing bug since F9 :( Somehow, I think that KDE4 triggers it
but never found a better solution than to restart X all 7-10 days.
Fortunately, F10 makes this easy because machines hangs every weekend
since the F9 -> F10 upgrade.


Enrico



From Jochen at herr-schmitt.de  Sun Jan 18 17:50:48 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Sun, 18 Jan 2009 18:50:48 +0100
Subject: Trouble with koji (%_font_pkg macro)
In-Reply-To: <1232055021.20003.0.camel@arekh.okg>
References: <496FA8EB.6040402@herr-schmitt.de>
	<1232055021.20003.0.camel@arekh.okg>
Message-ID: <0MKwh2-1LObng3Z7F-0002xM@mrelayeu.kundenserver.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 15 Jan 2009 22:30:21 +0100, you wrote:


>See
>https://www.redhat.com/archives/fedora-packaging/2009-January/msg00090.html

Tahnk you, that you have tried to help me. Unfortunately, I
didn't got any success after reading the cited link.

The issue is, that the name of the main package, which is not a
font package is aplus-fsf. The font subpackage should named
aplus-fsf-fonts.

If I'm using the _font_pkg macro with the -n switch the macro
will add a '-fonts' suffix automaticly  to the given argument,
but the subpackage argument in the generate '%post' statement
doesn't have a '-n' flag, so it's seems, that I have to enter an
empty argument. this seems to be impossible.

So again, It's may be nice, if anyoune can help me to fix this
issue.

Best Regards:

Jochen Schmitt

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.9.0 (Build 397)
Charset: us-ascii

wj8DBQFJc2wJT2AHK6txfgwRAl5KAKDuErbOUwNFOKW3RPyi/r/cc6UNwwCggohq
h2Veyp7UGrpw7P62EOCG8RU=
=EJ4L
-----END PGP SIGNATURE-----




From zaitcev at redhat.com  Sun Jan 18 18:08:04 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sun, 18 Jan 2009 11:08:04 -0700
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232287886.20264.9.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
	<20090118121439.GA72117@dspnet.fr.eu.org>
	<1232283899.4226.17.camel@choeger6>
	<49732EBF.4010509@leemhuis.info>
	<1232287886.20264.9.camel@choeger6>
Message-ID: <20090118110804.2ac3ed0e.zaitcev@redhat.com>

On Sun, 18 Jan 2009 15:11:26 +0100, Christoph H?ger <choeger at cs.tu-berlin.de> wrote:

> But I still consider it a leakage. I'm following the memory consumption
> minute by minute now without doing anything. It raises faster and
> faster. From roughly 1/2M per minute to more than 5M/min. Right now it
> jumped up by 8M. (All taken from top's RES field)

The resident amount means nothing. It's just the number of pages
mapped. As they get referenced, this number increases. Memory
pressure makes it decrease.

If you suspect a leak, look at /proc/NNN/maps. Take snapshots
and compare the heap size over time.

-- Pete



From debarshi.ray at gmail.com  Sun Jan 18 18:22:31 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sun, 18 Jan 2009 23:52:31 +0530
Subject: rawhide report: 20090118 changes
In-Reply-To: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>
References: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>
Message-ID: <3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>

> New package gtksourceviewmm
>        A C++ wrapper for the gtksourceview widget library

Does this not replace libgtksourceviewmm [1] ? Or is one related to
gtksourceview and the other to gtksourceview2?

Cheers,
Debarshi

----
[1] https://admin.fedoraproject.org/pkgdb/packages/name/libgtksourceviewmm



From nicolas.mailhot at laposte.net  Sun Jan 18 18:54:33 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 18 Jan 2009 19:54:33 +0100
Subject: Trouble with koji (%_font_pkg macro)
In-Reply-To: <0MKwh2-1LObng3Z7F-0002xM@mrelayeu.kundenserver.de>
References: <496FA8EB.6040402@herr-schmitt.de>
	<1232055021.20003.0.camel@arekh.okg>
	<0MKwh2-1LObng3Z7F-0002xM@mrelayeu.kundenserver.de>
Message-ID: <1232304873.6275.11.camel@arekh.okg>

Le dimanche 18 janvier 2009 ? 18:50 +0100, Jochen Schmitt a ?crit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 15 Jan 2009 22:30:21 +0100, you wrote:
> 
> 
> >See
> >https://www.redhat.com/archives/fedora-packaging/2009-January/msg00090.html
> 
> Tahnk you, that you have tried to help me. Unfortunately, I
> didn't got any success after reading the cited link.
> 
> The issue is, that the name of the main package, which is not a
> font package is aplus-fsf. The font subpackage should named
> aplus-fsf-fonts.

Actually, it should be named aplus-fsf-somefontname-fonts according to
guidelines
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2009-01-13)

Since you're not following guidelines it's not surprising our macros
fail you.

The requirement to specify the font family name in the package name is
here to help users easily identify the package content, to force
packagers to respect
http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21)

and actually make them check they know the history and legal conditions
of the fonts they make us ship
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#How_can_I_check_if_my_fonts_present_a_legal_risk.3F

So you do have to look inside your font files, find the font names and
licensing conditions, and only then sub-package them.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/f0d85728/attachment.sig>

From Jochen at herr-schmitt.de  Sun Jan 18 19:01:50 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Sun, 18 Jan 2009 20:01:50 +0100
Subject: rawhide report: 20090118 changes
In-Reply-To: <3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>
References: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>
	<3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>
Message-ID: <49737C9E.8000805@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Debarshi Ray schrieb:
>> New package gtksourceviewmm
>>        A C++ wrapper for the gtksourceview widget library
>
> Does this not replace libgtksourceviewmm [1] ? Or is one related to
> gtksourceview and the other to gtksourceview2?
>
I have take a closer look on it.

I could find out, that libgtksourceview depends on gtksourceview, but
gtksourceviewmm is depending on gtksourceview2. both packages can be
installed
without any file conflict between both packages.

But unfortunately, I'm was not aware, that we have a
libgtksourceviewmm package.
I propose, we should rename this new package into libgtksourceviewmm2
for clarification.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklzfJUACgkQT2AHK6txfgzM7QCgpjFJSoJiB6EXSAznGYJkMzpk
fx0An2VFq0tfOVAbT3vM5tCxLAeCmKi4
=IKkS
-----END PGP SIGNATURE-----



From fedora at camperquake.de  Sun Jan 18 19:16:21 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 18 Jan 2009 20:16:21 +0100
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <87r63039cp.fsf@sheridan.bigo.ensc.de>
References: <1232111406.18033.18.camel@choeger6>
	<87r63039cp.fsf@sheridan.bigo.ensc.de>
Message-ID: <49738005.4030407@camperquake.de>

Hi.

Enrico Scholz schrieb:

> Fortunately, F10 makes this easy because machines hangs every weekend
> since the F9 -> F10 upgrade.

That's a feature. It's called 'go outside and get some fresh air.'



From josef at toxicpanda.com  Sun Jan 18 19:16:31 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Sun, 18 Jan 2009 14:16:31 -0500
Subject: New btrfs-progs package in rawhide
Message-ID: <1b7401870901181116u39f9b01dnb5dbc3791576cd0c@mail.gmail.com>

Hello,

Sorry, I promise to not send an email everytime there is an update,
this is just particularly important.  If you are using an -rc2 or
later kernel (which is currently whats in rawhide) you must use the
btrfs-progs-0.18 package if you want to use btrfsctl, so doing
snapshots or anything like that.  You can still format/mount etc with
the old btrfs-progs, its just there was a change to the ioctl's so any
of the on the fly stuff won't work.  Thanks,

Josef



From loupgaroublond at gmail.com  Sun Jan 18 19:32:22 2009
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Sun, 18 Jan 2009 14:32:22 -0500
Subject: Testing bugzilla <-> python access
Message-ID: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>

Hey List,

I am looking to do some tools for sending in review requests and
updating them with revised versions via fedora-devshell. I'm also
planning on putting in some bits to query BZ for review requests,
download them, and test them in f-devshell too. There has been some
talk about wanting to help integrate this into review-o-matic, so this
is something that could probably make it easier to do reviews too.

In order to test this, i would need a way to send and read entries in
RH's bugzilla. I'm about to look for libraries to do so, but before i
can start development, i will need a test environment of course.
(Unless everyone likes seeing bogus review requests from me.) How do i
go about emulating the parts of BZ i need to test this?

Cheers,
Yaakov



From denis at poolshark.org  Sun Jan 18 19:39:20 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 18 Jan 2009 20:39:20 +0100
Subject: rawhide report: 20090118 changes
In-Reply-To: <3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>
References: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>
	<3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>
Message-ID: <49738568.6000308@poolshark.org>

Debarshi Ray wrote:
>> New package gtksourceviewmm
>>        A C++ wrapper for the gtksourceview widget library
> 
> Does this not replace libgtksourceviewmm [1] ? Or is one related to
> gtksourceview and the other to gtksourceview2?

The latter. libgtksourceviewmm is the 1.0 API, while gtksourceviewmm is 
the 2.0 API (upstream tarball was renamed, hence the new package 
review). The corresponding C API packages are gtksourceview and 
gtksourceview2 respectively (an interesting "compat package in disguise" 
tactic).

There's only one dependency left on libgtksourceviewmm (glom), after 
which we can EOL it. (glom update to 1.9.0 is currently waiting for 
libgda-4.0-friendly release of gnome-python-extras, which according to 
upstream will happen soon).



From nicolas.mailhot at laposte.net  Sun Jan 18 19:45:19 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 18 Jan 2009 20:45:19 +0100
Subject: Trouble with koji (%_font_pkg macro)
In-Reply-To: <1232304873.6275.11.camel@arekh.okg>
References: <496FA8EB.6040402@herr-schmitt.de>
	<1232055021.20003.0.camel@arekh.okg>
	<0MKwh2-1LObng3Z7F-0002xM@mrelayeu.kundenserver.de>
	<1232304873.6275.11.camel@arekh.okg>
Message-ID: <1232307919.6697.2.camel@arekh.okg>

Le dimanche 18 janvier 2009 ? 19:54 +0100, Nicolas Mailhot a ?crit :

> Since you're not following guidelines it's not surprising our macros
> fail you.

Actually, that was a bit more forceful than I intended. Apologies.
Pointing out the same document every day makes me grumpy.

Everyone please read and re-read the FAQ. Really. It's here to help.

http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_%28FAQ%29

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/f0041985/attachment.sig>

From denis at poolshark.org  Sun Jan 18 20:42:08 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sun, 18 Jan 2009 21:42:08 +0100
Subject: Help needed with tkimage bug
In-Reply-To: <89b36810901161519s204579f8w746463ab89fd4485@mail.gmail.com>
References: <89b36810901161519s204579f8w746463ab89fd4485@mail.gmail.com>
Message-ID: <49739420.5000103@poolshark.org>

Sergio Pascual wrote:
> I maintain ds9, a viewer of FITS files (a kind of image format used by
> astronomers). ds9 is written in tcl and requires other packages, such
> as tkimg.
> 
> tkimg comes with its own version of libz, libpng, libjpeg and libtiff.
> I patched the software to use system libraries instead. Patched tkimg
> works well with ds9.
> 
> But tkimg seems to crash in other conditions. As reported here
> https://bugzilla.redhat.com/show_bug.cgi?id=468357
> tkimage crashed with some simple tests.
> 
> The bug is caused by my patches, the package without the patches works
> well. I could revert them, but that implies using the bundled graphic
> libraries instead of the system ones. In the other hand I don't have
> the tcl knowledge to fix it. Any help?

have you compared the sources of the included libraries versus the 
official tarballs ? The libraries might have been patched, for example 
to use TCL memory allocation mechanisms, in which case you really have 
no choice but to use tkimg' versions...

-denis



From ville.skytta at iki.fi  Sun Jan 18 21:35:12 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Sun, 18 Jan 2009 23:35:12 +0200
Subject: unnecessary font Provides churn (was Re: rawhide report:
	20090116 changes)
In-Reply-To: <1232188579.14915.80.camel@arekh.okg>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	<fseiz2fz3a.fsf@allele2.eebweb.arizona.edu>
	<1232188579.14915.80.camel@arekh.okg>
Message-ID: <200901182335.12603.ville.skytta@iki.fi>

On Saturday 17 January 2009, Nicolas Mailhot wrote:
> Le vendredi 16 janvier 2009 ? 19:25 -0700, Alex Lancaster a ?crit :
> > I just fixed the 'Requires:' that were causing broken deps a few days
> > ago to match the new 'Provides:', but it appears that the naming for
> > the provides has changed *yet again*.
> >
> > Why wasn't the change done in one hit to avoid all these extra
> > rebuilds?
>
> http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)#fpc_renaming

I think it's about time the people responsible for this mess start actually 
fixing the compatibility issues and make-work they have been and still seem 
to be continuously inflicting themselves.

And while at it, how about dropping the arrogance - I have no idea what good 
what do you think you're accomplishing with statements like the following, to 
name a few?

"we feel it is quite possible and desirable to do a clean break and not carry 
on indefinitely old provides in the repository metadata": a 
guideline "justification" after already breaking things several times, both 
before and during the current guideline process.

"it's the usual core fonts brokeness which has existed for as long as we used 
core fonts": when something that has _used to work for ages_ (temporarily?) 
broke due to X server changes.  I suppose this has nothing to do with the 
fonts packaging changes but it does tell something about the poster's level 
of interest towards backwards compatibility in this area.

"it's less critical": essential parts of a sentence used to shrug off three 
unnecessary backwards incompatible changes in dejavu-lgc packaging during the 
past year or so.

"We do try to avoid renammings, but sometimes they happen. Fontconfig apps 
don't care :)":  Right.  It seems that neither do you, and you haven't tried 
very hard at all.  Where did you post the patches that add fontconfig support 
to the packages you think it's ok to keep breaking?



From ville.skytta at iki.fi  Sun Jan 18 22:22:42 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Mon, 19 Jan 2009 00:22:42 +0200
Subject: pam_console
In-Reply-To: <20090116203129.GA5449@nostromo.devel.redhat.com>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
Message-ID: <200901190022.43470.ville.skytta@iki.fi>

On Friday 16 January 2009, Bill Nottingham wrote:
> I think it's time to retire pam_console from the default configuration.
[...]
> em8300:	 /etc/security/console.perms.d/60-em8300.perms	(heffer)
> vdr:	 /etc/security/console.perms.d/95-vdr.perms	(scop)
[...]
> I'd be willing to chip in to get these fixed, it shouldn't be that hard.

Thanks in advance.  I'm pretty clueless wrt hal/consolekit but do know how vdr 
(which I maintain and use all the time) and em8300 (which I used to maintain 
and do still use all the time with vdr) should work.  So here goes an 
explanation - if you can help out with these, maybe it'll serve as a good 
education session for myself and others here:

em8300 is a hardware MPEG decoder.  Locally logged in users should be able to 
use it - I guess the same use cases as for DVB cards apply to it.

vdr is a daemon providing PVR functionality.  It is run as a service, with a 
dedicated unprivileged system user account, needs to be able to use at least 
DVB devices without interference even if people log in locally to the box and 
log out, and also after boot without anyone logging in.  Depending on the 
configuration and available plugins, it should also have similar access to 
the em8300 devices, serial ports, input/event devices and optical drives, 
possibly other devices as well.  Ditto the other way around - the 
configuration shouldn't prevent locally logged in users from using these 
devices (obviously in case they're not in use by vdr but I suppose that's off 
topic).

Both em8300 and vdr currently use the "video" group, udev rules and a 
console.perms.d snippet to get the desired behavior.  IIRC the only purpose 
of the console.perms.d snippet in both was to prevent pam_console from 
fiddling with the device permissions so that vdr could no longer use them 
when people logged in/out and/or to prevent pam_console from overriding the 
permissions set in udev rules by duplicating the rules in the console.perms.d 
snippet.  (Oh, BTW, looks like the vdr one still contains some event/input 
references that should have been moved to the vdr-remote package which is a 
plugin through which vdr may use those devices.)

So... where do we start?



From seg at haxxed.com  Sun Jan 18 22:31:07 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 18 Jan 2009 16:31:07 -0600
Subject: Xorg: xserver using _a lot_ memory
In-Reply-To: <1232278968.4226.14.camel@choeger6>
References: <1232111406.18033.18.camel@choeger6>
	<20090116132611.GA9750@dspnet.fr.eu.org>
	<1232278968.4226.14.camel@choeger6>
Message-ID: <1232317868.16679.5.camel@localhost.localdomain>

On Sun, 2009-01-18 at 12:42 +0100, Christoph H?ger wrote:
> > How much of that is pci ranges mmaps?
> 
> I think thats it:
> 
> Taken from xorg's smaps:
> (That is alot, isn't it?)
> 
> a7cbc000-b7cbc000 rw-s e0000000 00:00
> 5297       /sys/devices/pci0000:00/0000:00:02.0/resource2
> Size:             262144 kB
> Rss:              262144 kB

With 3D capable video hardware, very large blocks of memory mapped IO
registers are not unusual.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/2f5bee28/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Jan 18 22:46:23 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 18 Jan 2009 23:46:23 +0100
Subject: unnecessary font Provides churn (was Re: rawhide report:
 20090116 changes)
In-Reply-To: <200901182335.12603.ville.skytta@iki.fi>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	<fseiz2fz3a.fsf@allele2.eebweb.arizona.edu>
	<1232188579.14915.80.camel@arekh.okg>
	<200901182335.12603.ville.skytta@iki.fi>
Message-ID: <1232318783.9032.18.camel@arekh.okg>

Le dimanche 18 janvier 2009 ? 23:35 +0200, Ville Skytt? a ?crit :
> I think it's about time the people responsible for this mess
> start actually 
> fixing the compatibility issues and make-work they have been and still
> seem to be continuously inflicting themselves.

So, appart from spitting on some community work you didn't contribute
to, do not contribute to, and never bothered to provide useful feedback
on (even when personnaly CC-ed with weeks of advance), do you have
anything useful to say?

Because idiocies like "[not] tried very hard at all" won't get you very
far. CVS, git, wiki, mailing list, and bugzilla logs tell their own
(true) story.

Not trying very hard is writing long hate mails instead of doing
one-liner changes you've been given all the necessary info on.

With no regard,

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/00ac8a49/attachment.sig>

From loganjerry at gmail.com  Sun Jan 18 22:54:55 2009
From: loganjerry at gmail.com (Jerry James)
Date: Sun, 18 Jan 2009 15:54:55 -0700
Subject: Problem with autotools
In-Reply-To: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>
Message-ID: <870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>

On Sat, Jan 17, 2009 at 10:34 PM, Randy Berry <randyn3lrx at gmail.com> wrote:
> I am trying to build a package and the source relies on autotools. I'm
> getting an error during the build install stage that I don't
> understand.
> Below are the pastes to the errors I am getting when trying to run
> 'rpmbuild -bi'
>
> rpmbuild full output: http://fpaste.org/paste/1661
> spec file: http://fpaste.org/paste/1662
> rpmbuild output (short version): http://fpaste.org/paste/1664
>
> Anyone familiar with this error that knows how to fix it?
> I'm pretty sure a patch is needed and I know how to make and apply a
> patch I just don't know where to begin at making the patch.
>
> Thanks,

Randy,

It looks like you just need to copy or link
/usr/share/automake-<version #>/mkinstalldirs into the top-level
source directory.  If you do this at build time (instead of making a
patch), make sure you BuildRequires the appropriate version of
automake.

Regards,
-- 
Jerry James
http://loganjerry.googlepages.com/



From seg at haxxed.com  Sun Jan 18 23:00:08 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Sun, 18 Jan 2009 17:00:08 -0600
Subject: Citadel groupware for Fedora
In-Reply-To: <200901171344.n0HDipoh005706@jasmine.xos.nl>
References: <200901171344.n0HDipoh005706@jasmine.xos.nl>
Message-ID: <1232319608.16679.31.camel@localhost.localdomain>

On Sat, 2009-01-17 at 14:44 +0100, Jos Vos wrote:
> Hi.
> 
> Has somebody ever looked at Citadel <http://www.citadel.org/>, a
> groupware solution, and maybe considered including it in Fedora?
> 
> Among all the pseudo-OSS and/or the too huge/too complex groupware
> packages that are around, this one looks rather promising.

I was attempting to package it some years ago, but then I got really
busy with school and never finished. With the advent of Google Apps I'm
no longer interested in it. Though given the non-freeness of Google Apps
we really need a free equivalent, and Citadel is probably the closest
thing to it right now.

(I began my online life dialing up Citadel BBSs in the Minneapolis area
in 1993-94, including a Citadel/UX board that ran on an early Slackware
that gave out shell accounts, the first time I ever used Linux. The rest
is history...)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090118/723b93fc/attachment.sig>

From jonstanley at gmail.com  Mon Jan 19 00:09:45 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Sun, 18 Jan 2009 19:09:45 -0500
Subject: Testing bugzilla <-> python access
In-Reply-To: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
References: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
Message-ID: <da159fda0901181609k34506189n697b2cf8025a29ad@mail.gmail.com>

There is python-bugzilla, which is an API to the XMLRPC interface of
bugzilla. There's a non-production RHBZ instance at
https://partner-bugzilla.redhat.com too. Let me know if you have any
more questions and sorry for the top post which I can't help :/

On 1/18/09, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> Hey List,
>
> I am looking to do some tools for sending in review requests and
> updating them with revised versions via fedora-devshell. I'm also
> planning on putting in some bits to query BZ for review requests,
> download them, and test them in f-devshell too. There has been some
> talk about wanting to help integrate this into review-o-matic, so this
> is something that could probably make it easier to do reviews too.
>
> In order to test this, i would need a way to send and read entries in
> RH's bugzilla. I'm about to look for libraries to do so, but before i
> can start development, i will need a test environment of course.
> (Unless everyone likes seeing bogus review requests from me.) How do i
> go about emulating the parts of BZ i need to test this?
>
> Cheers,
> Yaakov
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

-- 
Sent from my mobile device

Jon Stanley
Fedora Bug Wrangler
jstanley at fedoraproject.org



From randyn3lrx at gmail.com  Mon Jan 19 00:46:16 2009
From: randyn3lrx at gmail.com (Randall J. Berry)
Date: Sun, 18 Jan 2009 19:46:16 -0500
Subject: Problem with autotools
In-Reply-To: <870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>
	<870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>
Message-ID: <4973CD58.4050008@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jerry James wrote:
> On Sat, Jan 17, 2009 at 10:34 PM, Randy Berry <randyn3lrx at gmail.com> wrote:
>> I am trying to build a package and the source relies on autotools. I'm
>> getting an error during the build install stage that I don't
>> understand.
>> Below are the pastes to the errors I am getting when trying to run
>> 'rpmbuild -bi'
>>
>> rpmbuild full output: http://fpaste.org/paste/1661
>> spec file: http://fpaste.org/paste/1662
>> rpmbuild output (short version): http://fpaste.org/paste/1664
>>
>> Anyone familiar with this error that knows how to fix it?
>> I'm pretty sure a patch is needed and I know how to make and apply a
>> patch I just don't know where to begin at making the patch.
>>
>> Thanks,
> 
> Randy,
> 
> It looks like you just need to copy or link
> /usr/share/automake-<version #>/mkinstalldirs into the top-level
> source directory.  If you do this at build time (instead of making a
> patch), make sure you BuildRequires the appropriate version of
> automake.
> 
> Regards,
	HI Jerry,
I got it to build using the autogen.sh and it works just fine on
rpmbuild but when I try to build it on mock it errors out on 'You must
have 'glib' installed". I added glib to the BR and still the same. I
even tried adding it to the requires as well and it still failed. Even
with glib in both requires and buildrequires it still fails. I'm stuck
there now. I looked for specific version requests but could not find any.
Thanks,
	Randy
- --
Randall J. Berry
IRC: Dp67, N3LRX
Email: <randyn3lrx at gmail.com> gpg key: 0x8479625D
Fingerprint: 40B4 2E18 DE47 29DD 9E13 BFD6 D558 96D3 8479 625D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklzzVgACgkQ1ViW04R5Yl1loACfe1u3vbmiWZWsw1jcUM36sWSO
F7IAn1gBMDhHoQPvcgf/52+rPxqDwPfM
=m630
-----END PGP SIGNATURE-----



From loganjerry at gmail.com  Mon Jan 19 02:27:03 2009
From: loganjerry at gmail.com (Jerry James)
Date: Sun, 18 Jan 2009 19:27:03 -0700
Subject: Problem with autotools
In-Reply-To: <4973CD58.4050008@gmail.com>
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>
	<870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>
	<4973CD58.4050008@gmail.com>
Message-ID: <870180fe0901181827n253e1151w53453e3126f58a1f@mail.gmail.com>

On Sun, Jan 18, 2009 at 5:46 PM, Randall J. Berry <randyn3lrx at gmail.com> wrote:
>        HI Jerry,
> I got it to build using the autogen.sh and it works just fine on
> rpmbuild but when I try to build it on mock it errors out on 'You must
> have 'glib' installed". I added glib to the BR and still the same. I
> even tried adding it to the requires as well and it still failed. Even
> with glib in both requires and buildrequires it still fails. I'm stuck
> there now. I looked for specific version requests but could not find any.
> Thanks,
>        Randy

Did you BR glib, or glib-devel?
-- 
Jerry James
http://loganjerry.googlepages.com/



From randyn3lrx at gmail.com  Mon Jan 19 02:33:22 2009
From: randyn3lrx at gmail.com (Randall J. Berry)
Date: Sun, 18 Jan 2009 21:33:22 -0500
Subject: Problem with autotools
In-Reply-To: <870180fe0901181827n253e1151w53453e3126f58a1f@mail.gmail.com>
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>	<870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>	<4973CD58.4050008@gmail.com>
	<870180fe0901181827n253e1151w53453e3126f58a1f@mail.gmail.com>
Message-ID: <4973E672.5080609@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Jerry James wrote:
> On Sun, Jan 18, 2009 at 5:46 PM, Randall J. Berry <randyn3lrx at gmail.com> wrote:
>>        HI Jerry,
>> I got it to build using the autogen.sh and it works just fine on
>> rpmbuild but when I try to build it on mock it errors out on 'You must
>> have 'glib' installed". I added glib to the BR and still the same. I
>> even tried adding it to the requires as well and it still failed. Even
>> with glib in both requires and buildrequires it still fails. I'm stuck
>> there now. I looked for specific version requests but could not find any.
>> Thanks,
>>        Randy
> 
> Did you BR glib, or glib-devel?

I tried both same result.


- --
Randall J. Berry
IRC: Dp67, N3LRX
Email: <randyn3lrx at gmail.com> gpg key: 0x8479625D
Fingerprint: 40B4 2E18 DE47 29DD 9E13 BFD6 D558 96D3 8479 625D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklz5nIACgkQ1ViW04R5Yl2ykwCdH27lr5s9spTwHfzkAcCbPCg+
6sAAn2o8uhL2Yjz3TPDSCNmsk1tBO0/P
=yxXf
-----END PGP SIGNATURE-----



From kevin.kofler at chello.at  Mon Jan 19 02:30:06 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 19 Jan 2009 03:30:06 +0100
Subject: Problem with autotools
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>
	<870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>
	<4973CD58.4050008@gmail.com>
	<870180fe0901181827n253e1151w53453e3126f58a1f@mail.gmail.com>
Message-ID: <gl0oje$ael$3@ger.gmane.org>

Jerry James wrote:
> Did you BR glib, or glib-devel?

And most likely what's actually needed is glib2-devel. glib-devel is the
obsolete glib version 1.

        Kevin Kofler



From randyn3lrx at gmail.com  Mon Jan 19 03:17:53 2009
From: randyn3lrx at gmail.com (Randall J. Berry)
Date: Sun, 18 Jan 2009 22:17:53 -0500
Subject: Problem with autotools
In-Reply-To: <gl0oje$ael$3@ger.gmane.org>
References: <d6dfee4a0901172134y1a374141qc8ebb32ebc877c8e@mail.gmail.com>	<870180fe0901181454h759675a2ia1eadde4b93ca27e@mail.gmail.com>	<4973CD58.4050008@gmail.com>	<870180fe0901181827n253e1151w53453e3126f58a1f@mail.gmail.com>
	<gl0oje$ael$3@ger.gmane.org>
Message-ID: <4973F0E1.4050906@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Kevin Kofler wrote:
> Jerry James wrote:
>> Did you BR glib, or glib-devel?
> 
> And most likely what's actually needed is glib2-devel. glib-devel is the
> obsolete glib version 1.
> 
>         Kevin Kofler
> 
 Thanks Kevin,
That did the trick.
- --
Randall J. Berry
IRC: Dp67, N3LRX
Email: <randyn3lrx at gmail.com> gpg key: 0x8479625D
Fingerprint: 40B4 2E18 DE47 29DD 9E13 BFD6 D558 96D3 8479 625D

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklz8OEACgkQ1ViW04R5Yl3mSQCfRy7rz2LZyV7JJ2RffQgnRnIa
+WoAn11QmlFu+rlp5QbpQCj6N1rWj4Dz
=Ttks
-----END PGP SIGNATURE-----



From james at fedoraproject.org  Mon Jan 19 05:09:28 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 19 Jan 2009 00:09:28 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <y9h8wpaydc7.fsf@libation.ircam.fr>
References: <1231962712.14403.1559.camel@rosebud>
	<y9hvdsgv9jz.fsf@libation.ircam.fr>
	<1232038005.14403.1613.camel@rosebud>
	<y9hr634v6dy.fsf@libation.ircam.fr> <496F7214.7020109@gmail.com>
	<gkoplt$43e$1@ger.gmane.org> <4970DE32.5090005@gmail.com>
	<y9h8wpaydc7.fsf@libation.ircam.fr>
Message-ID: <1232341768.4934.159.camel@code.and.org>

On Sat, 2009-01-17 at 01:40 +0100, Arnaud Gomes-do-Vale wrote:
> Toshio Kuratomi <a.badger at gmail.com> writes:
> 
> >> But that means that for classical uses of kickstart (i.e. run the installer
> >> with this kickstart on every machine), the package would get installed,
> >> then removed, on every single machine. :-(
> >> 
> > Yes.  But that's already the case.
> 
> Is it? I'm pretty sure this is not the case on RHEL5 and its clones at
> least.

 I think it depends, if I'm following the code right (and I might well
not be). anaconda/kickstart basically does a yb.install() to get
packages and yb.tsInfo.remove() to get rid of them. So you can do:

my-leaf-pkg
-my-leaf-pkg

...and it'll work (as it'll basically be adding and then removing the
pkg from the tsInfo), but if you do:

foo
my-pkg-which-deps-on-foo
-foo

...then foo will be removed from the transaction, but then added back in
due to the dep.
 So it'd all depend on how the "new groups" are implemented, it
certainly wouldn't be hard to have tsInfo.remove() just take the group
out too ... or change how anaconda worked, or any number of others
things.

-- 
James Antill <james at fedoraproject.org>
Fedora



From debarshi.ray at gmail.com  Mon Jan 19 06:00:42 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Mon, 19 Jan 2009 11:30:42 +0530
Subject: rawhide report: 20090118 changes
In-Reply-To: <49738568.6000308@poolshark.org>
References: <20090118081806.B475D1F825D@releng2.fedora.phx.redhat.com>
	<3170f42f0901181022i5954af23n9a6b991556d58be1@mail.gmail.com>
	<49738568.6000308@poolshark.org>
Message-ID: <3170f42f0901182200x35e5815ja89bd5fa19aa5cb8@mail.gmail.com>

> There's only one dependency left on libgtksourceviewmm (glom), after which
> we can EOL it.

Right now libgtksourceviewmm is practically an orphaned package
because its maintainer, Damien Durand, has been non-responsive for
quite some time.

Cheers,
Debarshi



From rakesh.pandit at gmail.com  Mon Jan 19 06:01:02 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 19 Jan 2009 11:31:02 +0530
Subject: Testing bugzilla <-> python access
In-Reply-To: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
References: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
Message-ID: <b401d2530901182201u4a2ddb63x8a1ab4a6ec62450b@mail.gmail.com>

2009/1/19 Yaakov Nemoy <loupgaroublond at gmail.com>:
> Hey List,
>
> I am looking to do some tools for sending in review requests and
> updating them with revised versions via fedora-devshell. I'm also
> planning on putting in some bits to query BZ for review requests,
> download them, and test them in f-devshell too. There has been some
> talk about wanting to help integrate this into review-o-matic, so this
> is something that could probably make it easier to do reviews too.
>

We have already put in efforts and written something which includes
most bits of what you have stated here, though that is still in **not
usable** form. So, I would like you to collaborate with
review-o-matic* effort. In case it is okay with you we can discuss in
detail on review-o-matic* mailing list[1]?


* To be renamed soon.
[1] https://fedorahosted.org/mailman/listinfo/review-o-matic

-- 
rakesh



From pmatilai at laiskiainen.org  Mon Jan 19 07:41:21 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 19 Jan 2009 09:41:21 +0200 (EET)
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <200901171450.09772.sgrubb@redhat.com>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<200901171031.07001.sgrubb@redhat.com>
	<1232211549.3539.4.camel@localhost.localdomain>
	<200901171450.09772.sgrubb@redhat.com>
Message-ID: <alpine.DEB.1.10.0901190935001.27585@gotcha.dreamhost.com>

On Sat, 17 Jan 2009, Steve Grubb wrote:

> On Saturday 17 January 2009 11:59:09 am Jesse Keating wrote:
>> We should also make import of keys an auditable event.
>>
>> Are not all rpm actions audited?
>
> No. What I'm talking about is perhaps defining a specific audit event type
> that would signify that a key was imported and where it came from. I've seen
> cases where rpm tries to download keys from the network. This is one of the
> few security sensitive actions that is not put into the audit system.

FWIW, rpm >= 4.6 will never try to download keys from the network unless 
explicitly told to do so with --import. Only 4.4.x has the "feature" to 
automatically try and fetch unknown keys from public keyservers, and from 
4.4.2.1 onwards that's disabled by default (and every vendor has disabled 
it in their packages for affected versions anyway)

 	- Panu -



From rawhide at fedoraproject.org  Mon Jan 19 08:34:29 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 19 Jan 2009 08:34:29 +0000 (UTC)
Subject: rawhide report: 20090119 changes
Message-ID: <20090119083429.CC2EC1F825F@releng2.fedora.phx.redhat.com>

Compose started at Mon Jan 19 06:01:03 UTC 2009

New package fsniper
        A tool that monitors directories for new files and invokes scripts on them
New package mythes-el
        Greek thesaurus
New package mythes-fr
        French thesaurus
New package perl-MooseX-MultiInitArg
        Attributes with aliases for constructor arguments
New package python-epdb
        Extended Python debugger
New package ris-linux
        RIS for Linux - Boot winpe from the net / Ris Windows Installation
New package rubygem-restr
        Simple client for RESTful web services
Updated Packages:

aplus-fsf-4.22.4-11.fc11
------------------------
* Sun Jan 18 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 4.22.4-11
- Add font family name to font subpackage name

* Thu Jan 15 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 4.22.4-10
- Rebuild for new openssl package
- Remove wrong '-n' flag on subpackage name


baekmuk-ttf-fonts-2.2-13.fc11
-----------------------------
* Mon Jan 19 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-13.fc11
- Resolves: rhbz#477332
- Package renaming for post-1.13 fontpackages.

* Fri Jan 16 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-12.fc11
- Resolves: rhbz#477332 (Repatched buildsys error.)

* Fri Jan 16 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-11.fc11
- Resolves: rhbz#477332 (Included macro _font_pkg and created fontconfig .conf files.)


bash-completion-20080705-2.20090115bzr1252
------------------------------------------
* Sun Jan 18 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 20080705-2.20090115bzr1252
- r1252 snapshot; all patches applied upstream.
- Do not install mercurial completion, an updated version is shipped with it.
- Improve lzop and repomanage completion.


blender-2.48a-12.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 2.48a-12
- Change Req. for font package because fonts naming was changed (#480444)


cgit-0.8.1-2.fc11
-----------------
* Sun Jan 18 17:00:00 2009 Todd Zullinger <tmz at pobox.com> - 0.8.1-2
- Rebuild with new openssl


clive-2.1.3-1.fc11
------------------
* Thu Jan 15 17:00:00 2009 Nicoleau Fabien <nicoleau.fabien at gmail.com> 2.1.3-1
- Rebuild for 2.1.3
- License update

* Wed Dec 31 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> 2.1.2-1
- Rebuild for 2.1.2
- URLs update

* Wed Dec  3 17:00:00 2008 Nicoleau Fabien <nicoleau.fabien at gmail.com> 2.1.0-1
- Rebuild for 2.1.0


emacs-22.3-3.fc11
-----------------
* Sun Jan 18 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 1:22.3-3
- Add /etc/rpm/macros.emacs file


emacs-common-ess-5.3.10-1.fc11
------------------------------
* Sun Jan 18 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 5.3.10-1
- Update to latest upstream (5.3.10)
- Add BR: texinfo-tex
- Fix paths to installation of documentation


goocanvasmm-0.13.0-1.fc11
-------------------------
* Sun Jan 18 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.13.0-1
- Update to upstream 0.13.0


gtkpod-0.99.12-5.fc11
---------------------
* Sat Jan 17 17:00:00 2009 Todd Zullinger <tmz at pobox.com> - 0.99.12-5
- Apply upstream fix for disappearing tooltips (#428940)


iok-1.2.0-1.fc11
----------------
* Mon Jan 19 17:00:00 2009 Parag Nemade <panemade at gmail.com>- 1.2.0-1
- Update to Next release 1.2.0


libxml2-2.7.3-1.fc11
--------------------
* Sun Jan 18 17:00:00 2009 Daniel Veillard <veillard at redhat.com> - 2.7.3-1
- new release 2.7.3
- limit default max size of text nodes
- special parser mode for PHP
- bug fixes and more compiler checks


maxima-5.17.1-3.fc11
--------------------
* Sun Jan 18 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 5.17.1-3
- reenable gcl on i386 (#451801), x86_64 (#427250), ppc (#167952)


mono-debugger-2.4-3.20090116svn123514.fc11
------------------------------------------
* Sat Jan 17 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.4-3.20090116svn123514
- Try another approach for fixing configure.in
- Removed redundant patches

* Sat Jan 17 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.4-2.20090116svn123514
- Fix lib64 issue in configure.in

* Fri Jan 16 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.4-1.20090116svn123514
- Move to 2.4 branch

* Fri Jan  9 17:00:00 2009 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-3.RC2.20090901svn122605
- bump to RC2
- use svn rather than tarballs
- Added mono-debugger-frontend and mono-debugger-frontend.pc files

* Sat Dec  6 17:00:00 2008 Paul F. Johnson <paul at all-the-johnsons.co.uk> 2.2-2.pre2
- bump to 2.2 preview 2


nightfall-1.62-5.fc11
---------------------
* Thu Aug 28 18:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 1.62-5
- Include /usr/share/nightfall directory.


perl-bioperl-1.5.9-0.4.3.fc11
-----------------------------
* Sun Jan 18 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.5.9-0.4.3
- Update to 1.6.0 release candidate 3


ruby-ldap-0.9.7-6.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.7-6
- rebuild with new openssl


rudesocket-1.3.0-3.fc11
-----------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com>
- 1.3.0-3
- rebuild with new openssl


scribus-1.3.5-0.9.12516svn.fc11
-------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.3.4-0.9.12516svn
- rebuild with new openssl


scsi-target-utils-0.9.2-2.fc11
------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.2-2
- rebuild with new openssl


siege-2.67-2.fc11
-----------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2.67-2
- rebuild with new openssl


sim-0.9.5-0.15.20080923svn2261rev.fc11
--------------------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.9.5-0.15.20080923svn2261rev
- rebuild with new openssl

* Sat Nov 22 17:00:00 2008 Pavel Alexeev <Pahan [ at ] Hubbitus [ DOT ] spb [ dOt.] su> - 0.9.5-0.14.20080923svn2261rev
- Remove package name from package description.


sipp-3.1-3.fc11
---------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 3.1-3
- rebuild with new openssl


sipsak-0.9.6-5.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.9.6-5
- rebuild with new openssl


snmp++-3.2.23-6.fc11
--------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.2.23-6
- rebuild with new openssl


socat-1.6.0.1-3.fc11
--------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.6.0.1-3
- disable the upstream openssl fips support


sofia-sip-1.12.10-2.fc11
------------------------
* Sat Jan 17 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.12.10-2
- rebuild with new openssl


spamassassin-3.2.5-4.fc11
-------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.2.5-4
- rebuild with new openssl


squid-3.0.STABLE10-4.fc11
-------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 7:3.0.STABLE10-4
- rebuild with new openssl


stellarium-0.10.0-3.fc11
------------------------
* Sun Jan 18 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> - 0.10.0-3
- Change Req. to fonts pakcage because fonts package renaming (#480474)


stunnel-4.26-2
--------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 4.26-2
- disable openssl upstream fips mode


supertux-0.3.1-4.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> 0.3.1-4
- Fix parsing of translations (#477497)
- Disable debugging console


sylpheed-2.6.0-2.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.6.0-2
- rebuild with new openssl


tcltls-1.6-3.fc11
-----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.6-3
- rebuild with new openssl


teeworlds-0.5.0-1.fc11
----------------------
* Sat Jan 17 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> 0.5.0-1
- New upstream release


telepathy-idle-0.1.2-4.fc11
---------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.1.2-4
- rebuild with new openssl


telepathy-mission-control-4.67-2.fc11
-------------------------------------
* Mon Dec  1 17:00:00 2008 Michael Schwendt <mschwendt at fedoraproject.org> - 4.67-2
- Include /usr/share/mission-control directory.


telepathy-salut-0.3.7-2.fc11
----------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.3.7-2
- rebuild with new openssl


tinyfugue-5.0-0.10.b8.fc11
--------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.0-0.10.b8
- rebuild with new openssl


tn5250-0.17.3-20.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.17.3-20
- rebuild with new openssl


tog-pegasus-2.7.2-3.fc11
------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2:2.7.2-3
- rebuild with new openssl


tomcat-native-1.1.16-2.fc11
---------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.1.16-2
- rebuild with new openssl


tomoe-0.6.0-10.fc11
-------------------
* Mon Jan 19 17:00:00 2009 Ding-Yi Chen <dchen at redhat.com> - 0.6.0-10
- Fix [Bug 343321] multiarch conflicts in tomoe.
  Maybe cause by bug in gtk-doc.
- Also fix the errors from rpmlint:
  chmod 755 /usr/share/tomoe/xml2est.rb


tor-0.2.0.32-2.fc11
-------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.2.0.32-2
- rebuild with new openssl


tpm-tools-1.3.1-6.fc11
----------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.3.1-6
- rebuild with new openssl


tqsllib-2.0-6.fc11
------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.0-6
- rebuild with new openssl


transmission-1.42-2.fc11
------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.42-2
- rebuild with new openssl


tripwire-2.4.1.2-7.fc11
-----------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.4.1.2-7
- rebuild with new openssl


trousers-0.3.1-13.fc11
----------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.3.1-13
- rebuild with new openssl


unbound-1.2.0-2.fc11
--------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.0-2
- rebuild with new openssl


up-imapproxy-1.2.7-0.2.rc1.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.2.7-0.2.rc1
- rebuild with new openssl


uw-imap-2007e-4.fc11
--------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 2007e-4
- rebuild with new openssl


valknut-0.3.11-5.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 0.3.11-5
- rebuild with new openssl


vtun-3.0.1-4.fc11
-----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 3.0.1-4
- rebuild with new openssl


w3c-libwww-5.4.1-0.14.20060206cvs.fc11
--------------------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.4.1-0.14.20060206cvs
- rebuild with new openssl


w3m-0.5.2-12.fc11
-----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.5.2-12
- rebuild with new openssl


wget-1.11.4-2.fc11
------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.11.4-2
- rebuild with new openssl


wireshark-1.1.1-0.pre1.fc11.2
-----------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.1.1-0.pre1.2
- rebuild with new openssl


wmweather+-2.9-9.fc11
---------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.9-9
- rebuild with new openssl


wpa_supplicant-0.6.4-3.fc11
---------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1:0.6.4-3
- rebuild with new openssl


x3270-3.3.6-7.fc11
------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 3.3.6-7
- rebuild with new openssl


xar-1.5.2-2.fc11
----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.5.2-2
- rebuild with new openssl


xca-0.6.4-5.fc11
----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.6.4-5
- rebuild with new openssl


xchat-gnome-0.24.1-3.fc11
-------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.24.1-3
- rebuild with new openssl


xen-3.3.1-2.fc11
----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 3.3.1-2
- rebuild with new openssl


xine-lib-1.1.16-2.fc11
----------------------
* Sun Jan 18 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1.1.16-2
- drop deepbind patch (#480504)


xmlsec1-1.2.11-2
----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.11-2
- rebuild with new openssl


xmms2-0.5-5.fc11
----------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.5-5
- rebuild with new openssl


xsane-0.996-1.fc11
------------------
* Sun Jan 18 17:00:00 2009 Nils Philippsen <nphilipp at redhat.com> - 0.996-1
- version 0.996
- don't use %makeinstall
- use shipped xsane.xpm as application icon


xsupplicant-1.2.8-9.fc11
------------------------
* Sun Jan 18 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 1.2.8-9
- rebuild with new openssl


Summary:
Added Packages: 7
Removed Packages: 0
Modified Packages: 70
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ko_KR-3.0.1-15.1.fc11.i386 requires baekmuk-ttf-fonts-gulim
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.i386 requires smc-fonts-meera
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ko_KR-3.0.1-15.1.fc11.x86_64 requires baekmuk-ttf-fonts-gulim
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.x86_64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ko_KR-3.0.1-15.1.fc11.ppc requires baekmuk-ttf-fonts-gulim
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	livecd-tools-019-2.fc11.ppc64 requires yaboot
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	1:openoffice.org-langpack-ko_KR-3.0.1-15.1.fc11.ppc64 requires baekmuk-ttf-fonts-gulim
	1:openoffice.org-langpack-ml_IN-3.0.1-15.1.fc11.ppc64 requires smc-fonts-meera
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From mschwendt at gmail.com  Mon Jan 19 08:35:35 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Mon, 19 Jan 2009 09:35:35 +0100
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <gktdku$phl$1@ger.gmane.org>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
	<20090117133328.GA25986@amd.home.annexia.org>
	<1232220189.5215.116.camel@vespa.frost.loc>
	<gktdku$phl$1@ger.gmane.org>
Message-ID: <20090119093535.18049925.mschwendt@gmail.com>

On Sat, 17 Jan 2009 21:04:46 +0100, Kevin wrote:

> Tomas Mraz wrote:
> > Now this is really weird - it seems that there are the old scriptlets
> > from 0.9.8j-1.fc11 in the rpm database as well. How could that happen?
> 
> The postuninstall scriptlet from the old package is run during upgrades.
> (It's run AFTER the postinstall scriptlet of the new one. RPM installs the
> new package, then removes the old one. Of course only the files which are
> not in the new package are removed. But the postun scriptlet is run.)

You explain scriptlet ordering here, but Richard quoted the following:

| $ rpm -q openssl
| openssl-0.9.8j-3.fc11.x86_64

A single openssl package in the RPM database.

| # rpm -q --scripts openssl
| postinstall scriptlet (using /bin/sh):
| if [ "$(readlink /lib64/libcrypto.so.7)" != libcrypto.so.0.9.8j ] ; then
|     ln -sf libcrypto.so.0.9.8j /lib64/libcrypto.so.7 || :
| fi
| if [ "$(readlink /lib64/libssl.so.7)" != libssl.so.0.9.8j ] ; then
|     ln -sf libssl.so.0.9.8j /lib64/libssl.so.7 || :
| fi
| /sbin/ldconfig -X
| postuninstall scriptlet (using /bin/sh):
| /sbin/ldconfig -X
| postinstall scriptlet (using /bin/sh):
| /sbin/ldconfig -X
| postuninstall scriptlet (using /bin/sh):
| /sbin/ldconfig -X

Two postun and two post scriplets for a single package. There is no "old"
package until you give RPM a newer package for an upgrade transaction.
Here there should only be a single pair of postun/post scriptlets for
the installed 0.9.8j-3.fc11 pkg.



From rjones at redhat.com  Mon Jan 19 09:00:56 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 19 Jan 2009 09:00:56 +0000
Subject: Massive fallout from missing libssl.so.7 et al
In-Reply-To: <20090119093535.18049925.mschwendt@gmail.com>
References: <200901161228.n0GCS844020073@laptop14.inf.utfsm.cl>
	<20090116133205.670448ce@dhcp03.addix.net>
	<1232109985.5215.93.camel@vespa.frost.loc>
	<20090116135150.3a8f4d99@dhcp03.addix.net>
	<1232111099.5215.96.camel@vespa.frost.loc>
	<20090117133328.GA25986@amd.home.annexia.org>
	<1232220189.5215.116.camel@vespa.frost.loc>
	<gktdku$phl$1@ger.gmane.org>
	<20090119093535.18049925.mschwendt@gmail.com>
Message-ID: <20090119090056.GA14972@amd.home.annexia.org>

On Mon, Jan 19, 2009 at 09:35:35AM +0100, Michael Schwendt wrote:
> Two postun and two post scriplets for a single package. There is no "old"
> package until you give RPM a newer package for an upgrade transaction.
> Here there should only be a single pair of postun/post scriptlets for
> the installed 0.9.8j-3.fc11 pkg.

I don't quite understand what's going on here either.  I rebuilt the
RPM database, did yum clean all, and upgraded openssl to the latest -5
package, and finally I have the /lib64/libcrypto.so.7 link.

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 yersinia.spiros at gmail.com  Mon Jan 19 09:28:19 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Mon, 19 Jan 2009 10:28:19 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs 
	server?
In-Reply-To: <1232224197.3539.15.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
Message-ID: <b086760e0901190128w37e11e29qc1b2ccb1eef980bf@mail.gmail.com>

2009/1/17 Jesse Keating <jkeating at j2solutions.net>

> On Sat, 2009-01-17 at 12:23 -0800, Jesse Keating wrote:
> > I've got an F10 box acting as the NFS server, and I'm getting failures
> > loading the install.img from NFS.  The failures are of the type that it
> > cannot mount the directory, even though I can from another host, so I
> > have to think that something weird is going on server side.  Does
> > anybody know of a way to increase the verbosity of the nfs server
> > daemons so that I can see what it is getting from the client?
>
> Never mind.  Turns out that the client couldn't be looked up via it's IP
> address, so mount said no (even though it was a warning in the log, not
> an error).  Anybody know how to instruct nfs to not care about this?  I
> didn't see anything in a quick scan of the exports man page.
>


AFAICT, it is not possible if the error was something like "

Nov  7 19:14:40 fc10 rpc.mountd: Fake hostname bogus.com for
192.168.1.1 - forward lookup doesn't exis

"
This is a security precaution added into the nfs package that lessens the
likelihood of unauthorized servers from gaining access to files on the NFS
server. Look to
nfs-utils-1.1.4/support/export/hostname.c

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/c63371f9/attachment.htm>

From petersen at redhat.com  Mon Jan 19 11:14:16 2009
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 19 Jan 2009 06:14:16 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <1385605566.67011232363404181.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

Hi,

Peng Huang and Fedora i18n are submitting a Feature to use ibus [1] as the default input method system in F11.

 https://fedoraproject.org/wiki/Features/IBus

iBus was added to Fedora during the F10 cycle and is under active development.  We now feel that it is ready for wider testing and to become sufficiency stable and featured to be the default input method for Fedora 11.

There will also be some more discussion about this in the Fedora I18n meeting tomorrow, announced last week. [2]

Jens

[1] http://code.google.com/p/ibus/

[2] https://fedoraproject.org/wiki/I18N/Meetings



From dominik at greysector.net  Mon Jan 19 12:41:04 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 19 Jan 2009 13:41:04 +0100
Subject: ibus and F11
In-Reply-To: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1385605566.67011232363404181.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <20090119124104.GA4592@mokona.greysector.net>

On Monday, 19 January 2009 at 12:14, Jens Petersen wrote:
> Hi,
> 
> Peng Huang and Fedora i18n are submitting a Feature to use ibus [1] as the
> default input method system in F11.
> 
>  https://fedoraproject.org/wiki/Features/IBus
> 
> iBus was added to Fedora during the F10 cycle and is under active
> development.  We now feel that it is ready for wider testing and to become
> sufficiency stable and featured to be the default input method for Fedora 11.
> 
> There will also be some more discussion about this in the Fedora I18n
> meeting tomorrow, announced last week. [2]

What's the migration path for SCIM users? Can I define my own shortcuts
for switching IMs, like in SCIM? Is there an applet for showing currently
selected IM, like in SCIM?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From mcepl at redhat.com  Mon Jan 19 12:48:47 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 19 Jan 2009 13:48:47 +0100
Subject: New btrfs-progs package in rawhide
References: <1b7401870901181116u39f9b01dnb5dbc3791576cd0c@mail.gmail.com>
Message-ID: <fe9e46xne3.ln2@ppp1053.in.ipex.cz>

On 2009-01-18, 19:16 GMT, Josef Bacik wrote:
> Sorry, I promise to not send an email everytime there is an 
> update, this is just particularly important.  If you are using 
> an -rc2 or later kernel (which is currently whats in rawhide) 
> you must use the btrfs-progs-0.18 package if you want to use 
> btrfsctl, so doing snapshots or anything like that.  You can 
> still format/mount etc with the old btrfs-progs, its just there 
> was a change to the ioctl's so any of the on the fly stuff 
> won't work.  Thanks,

I have installed btrfs on my /tmp (I won't let it go further so 
far ;-)), but I have still one question -- how is SELinux support 
doing? I am used to use for testing purposes SELinux in the 
enforcing mode. Will it work or will btrfs screw up my /tmp to 
non-working state?

Mat?j



From josef at toxicpanda.com  Mon Jan 19 13:15:32 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Mon, 19 Jan 2009 08:15:32 -0500
Subject: New btrfs-progs package in rawhide
In-Reply-To: <fe9e46xne3.ln2@ppp1053.in.ipex.cz>
References: <1b7401870901181116u39f9b01dnb5dbc3791576cd0c@mail.gmail.com>
	<fe9e46xne3.ln2@ppp1053.in.ipex.cz>
Message-ID: <1b7401870901190515v597745b9ybb2c54f0d7686548@mail.gmail.com>

On Mon, Jan 19, 2009 at 7:48 AM, Matej Cepl <mcepl at redhat.com> wrote:
> On 2009-01-18, 19:16 GMT, Josef Bacik wrote:
>> Sorry, I promise to not send an email everytime there is an
>> update, this is just particularly important.  If you are using
>> an -rc2 or later kernel (which is currently whats in rawhide)
>> you must use the btrfs-progs-0.18 package if you want to use
>> btrfsctl, so doing snapshots or anything like that.  You can
>> still format/mount etc with the old btrfs-progs, its just there
>> was a change to the ioctl's so any of the on the fly stuff
>> won't work.  Thanks,
>
> I have installed btrfs on my /tmp (I won't let it go further so
> far ;-)), but I have still one question -- how is SELinux support
> doing? I am used to use for testing purposes SELinux in the
> enforcing mode. Will it work or will btrfs screw up my /tmp to
> non-working state?

There are patches for SELinux support but they're still being tested,
probably won't be pushed till later.  For now SELinux will just treat
it like a volume that doesn't play properly, like FAT or anything like
that.  Thanks,

Josef



From SteveD at redhat.com  Mon Jan 19 14:08:11 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 19 Jan 2009 09:08:11 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <1232224197.3539.15.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
Message-ID: <4974894B.1070100@RedHat.com>

Jesse Keating wrote:
> On Sat, 2009-01-17 at 12:23 -0800, Jesse Keating wrote:
>> I've got an F10 box acting as the NFS server, and I'm getting failures
>> loading the install.img from NFS.  The failures are of the type that it
>> cannot mount the directory, even though I can from another host, so I
>> have to think that something weird is going on server side.  Does
>> anybody know of a way to increase the verbosity of the nfs server
>> daemons so that I can see what it is getting from the client?
> 
> Never mind.  Turns out that the client couldn't be looked up via it's IP
> address, so mount said no (even though it was a warning in the log, not
> an error).  Anybody know how to instruct nfs to not care about this?  I
> didn't see anything in a quick scan of the exports man page.
The discussion about the fact mountd (statd) no longer accept connections from
unknown IP address (similar to other system daemon) due to a "fix" in the tcp
wrapper code is at:

   https://bugzilla.redhat.com/show_bug.cgi?id=448898
and
   https://bugzilla.redhat.com/show_bug.cgi?id=480420 
    
Through some side bar discussion it been suggested an update to
the man page is probably need (which I agree) and maybe a flag
of some sort to allow unknown IP address access. I must admit, I'm
a bit hesitant to do the later, since I don't think its a good idea
to allow unknown client access any system daemon... 

steved.



From galibert at pobox.com  Mon Jan 19 14:28:31 2009
From: galibert at pobox.com (Olivier Galibert)
Date: Mon, 19 Jan 2009 15:28:31 +0100
Subject: Trying to debug nfs install issue,
	increase verbosity of nfs server?
In-Reply-To: <4974894B.1070100@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com>
Message-ID: <20090119142831.GA79580@dspnet.fr.eu.org>

On Mon, Jan 19, 2009 at 09:08:11AM -0500, Steve Dickson wrote:
> Through some side bar discussion it been suggested an update to
> the man page is probably need (which I agree) and maybe a flag
> of some sort to allow unknown IP address access. I must admit, I'm
> a bit hesitant to do the later, since I don't think its a good idea
> to allow unknown client access any system daemon... 

"Not in the DNS" does not mean unknown, it just means it's not in the
DNS yet.  Only the administrator of the system knows whether not in
the DNS indicates a problem or not.  Refusing by default is fine if
documented appropriately, not giving a way out isn't.

  OG.



From jarod at redhat.com  Mon Jan 19 14:48:32 2009
From: jarod at redhat.com (Jarod Wilson)
Date: Mon, 19 Jan 2009 09:48:32 -0500
Subject: firewire devices permissions and ownership
In-Reply-To: <1231095935.3708.58.camel@eagle.danny.cz>
References: <1231074714.3708.49.camel@eagle.danny.cz>
	<1231095935.3708.58.camel@eagle.danny.cz>
Message-ID: <200901190948.32753.jarod@redhat.com>

On Sunday 04 January 2009 14:05:34 Dan Hor?k wrote:
> Dan Hor?k p??e v Ne 04. 01. 2009 v 14:11 +0100:
> > After plugging in a firewire MiniDV camera a new device (/dev/fw1) is
> > correctly created. But they (/dev/fw*) have 0660 as the permission and
> > root:root as owner, so it is impossible to control the camera or grab
> > the videos as a regular user (eg. from Kino). What should be responsible
> > for allowing the user access for firewire devices?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=441073

The latest libraw1394 and libiec61883 in updates-testing finally remedy this.

-- 
Jarod Wilson
jarod at redhat.com



From pertusus at free.fr  Mon Jan 19 15:06:07 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Jan 2009 16:06:07 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
	server?
In-Reply-To: <4974894B.1070100@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com>
Message-ID: <20090119150607.GD2530@free.fr>

On Mon, Jan 19, 2009 at 09:08:11AM -0500, Steve Dickson wrote:

> The discussion about the fact mountd (statd) no longer accept connections from
> unknown IP address (similar to other system daemon) due to a "fix" in the tcp
> wrapper code is at:

This is not a change in tcp_wrapper, but in nfs-utils. And as far as I 
can tell this is not already upstream, so this looks like (but I may
be wrong) a fedora specific change in mountd.

I think that it is a very questionable change. Maybe it makes sense 
for NFSv4 (but is mountd involved in NFSv4?), but for NFSv3, it 
doesn't make sense to me, since there is no security at all in any 
case.

I may very well be missing something, though.

> Through some side bar discussion it been suggested an update to
> the man page is probably need (which I agree) and maybe a flag
> of some sort to allow unknown IP address access. I must admit, I'm
> a bit hesitant to do the later, since I don't think its a good idea
> to allow unknown client access any system daemon... 

Why not? Forcing reverse DNS lookup to be working seems to me to be 
quite extreme. In a typical local network, for NFSv3, not having 
reverse lookup working for clients seems quite natural to me, especially
on NATed networks.

--
Pat



From yersinia.spiros at gmail.com  Mon Jan 19 15:28:41 2009
From: yersinia.spiros at gmail.com (yersinia)
Date: Mon, 19 Jan 2009 16:28:41 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs 
	server?
In-Reply-To: <20090119150607.GD2530@free.fr>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com> <20090119150607.GD2530@free.fr>
Message-ID: <b086760e0901190728y39e86dc1ib0f0c20515a7acc5@mail.gmail.com>

On Mon, Jan 19, 2009 at 4:06 PM, Patrice Dumas <pertusus at free.fr> wrote:

> On Mon, Jan 19, 2009 at 09:08:11AM -0500, Steve Dickson wrote:
>
> > The discussion about the fact mountd (statd) no longer accept connections
> from
> > unknown IP address (similar to other system daemon) due to a "fix" in the
> tcp
> > wrapper code is at:
>
> This is not a change in tcp_wrapper, but in nfs-utils. And as far as I
> can tell this is not already upstream, so this looks like (but I may
> be wrong) a fedora specific change in mountd.
>
> I think that it is a very questionable change. Maybe it makes sense
> for NFSv4 (but is mountd involved in NFSv4?), but for NFSv3, it
> doesn't make sense to me, since there is no security at all in any
> case.
>
> I may very well be missing something, though.
>


In fact the control is in mountd.  In  nfs-utils-1.1.4-6 in FC10
./utils/mountd/auth.c call
auth_authenticate which call client_resolve that do the check
forward/reverse lookup via the
call to get_reliable_hostbyaddr in ./support/export/hostname.c.  And this is
in the upstream release.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/74e8a355/attachment.htm>

From SteveD at redhat.com  Mon Jan 19 15:35:55 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 19 Jan 2009 10:35:55 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <20090119150607.GD2530@free.fr>
References: <1232223817.3539.12.camel@localhost.localdomain>	<1232224197.3539.15.camel@localhost.localdomain>	<4974894B.1070100@RedHat.com>
	<20090119150607.GD2530@free.fr>
Message-ID: <49749DDB.8030505@RedHat.com>



Patrice Dumas wrote:
> On Mon, Jan 19, 2009 at 09:08:11AM -0500, Steve Dickson wrote:
> 
>> The discussion about the fact mountd (statd) no longer accept connections from
>> unknown IP address (similar to other system daemon) due to a "fix" in the tcp
>> wrapper code is at:
> 
> This is not a change in tcp_wrapper, but in nfs-utils. And as far as I 
> can tell this is not already upstream, so this looks like (but I may
> be wrong) a fedora specific change in mountd.
> 
> I think that it is a very questionable change. Maybe it makes sense 
> for NFSv4 (but is mountd involved in NFSv4?), but for NFSv3, it 
> doesn't make sense to me, since there is no security at all in any 
> case.
> 
> I may very well be missing something, though.
> 
>> Through some side bar discussion it been suggested an update to
>> the man page is probably need (which I agree) and maybe a flag
>> of some sort to allow unknown IP address access. I must admit, I'm
>> a bit hesitant to do the later, since I don't think its a good idea
>> to allow unknown client access any system daemon... 
> 
> Why not? Forcing reverse DNS lookup to be working seems to me to be 
> quite extreme. In a typical local network, for NFSv3, not having 
> reverse lookup working for clients seems quite natural to me, especially
> on NATed networks.
hmm... the real need for the lookup is so the 'mountd: <hostsname>' in
either /etc/hosts.deny/allow will work... so I guess the idea of 
not don the tcp wrappers check at all might be the answer...

steved.



From jkeating at redhat.com  Mon Jan 19 16:09:10 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Jan 2009 08:09:10 -0800
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <4974894B.1070100@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com>
Message-ID: <1232381350.3539.42.camel@localhost.localdomain>

On Mon, 2009-01-19 at 09:08 -0500, Steve Dickson wrote:
>  Through some side bar discussion it been suggested an update to
> the man page is probably need (which I agree) and maybe a flag
> of some sort to allow unknown IP address access. I must admit, I'm
> a bit hesitant to do the later, since I don't think its a good idea
> to allow unknown client access any system daemon... 

That kind of interferes with testing environments and home environments.
Requiring the setup of a dns server just to be able to use NFS is pretty
damn lame.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/c7f59ce5/attachment.sig>

From pertusus at free.fr  Mon Jan 19 16:29:35 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Jan 2009 17:29:35 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
	server?
In-Reply-To: <49749DDB.8030505@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com> <20090119150607.GD2530@free.fr>
	<49749DDB.8030505@RedHat.com>
Message-ID: <20090119162935.GE2530@free.fr>

On Mon, Jan 19, 2009 at 10:35:55AM -0500, Steve Dickson wrote:
> hmm... the real need for the lookup is so the 'mountd: <hostsname>' in
> either /etc/hosts.deny/allow will work... so I guess the idea of 
> not don the tcp wrappers check at all might be the answer...

Doing only IP matching also would work. If you want to serve only
clients on an ip subnetwork, you can simply have (if I recall well)
in hosts.allow

mountd: 192.168.0.

and in hosts.deny
ALL: ALL

Now, if hosts.deny indeed uses a host name, then if there is no 
host name, the mount may not be denied, although it should have. 
However the best would be that tcp_wrappers knows if the hostname
is needed, and if needed, and not provided, it denies. The API 
has a possibility to pass STRING_UNKNOWN to hosts_ctl, maybe it 
does things right in that case?

--
Pat



From rda at rincon.com  Mon Jan 19 16:29:49 2009
From: rda at rincon.com (Robert Arendt)
Date: Mon, 19 Jan 2009 09:29:49 -0700
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <1232381350.3539.42.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>	<1232224197.3539.15.camel@localhost.localdomain>	<4974894B.1070100@RedHat.com>
	<1232381350.3539.42.camel@localhost.localdomain>
Message-ID: <4974AA7D.4080206@rincon.com>

Jesse Keating wrote:
> On Mon, 2009-01-19 at 09:08 -0500, Steve Dickson wrote:
>>  Through some side bar discussion it been suggested an update to
>> the man page is probably need (which I agree) and maybe a flag
>> of some sort to allow unknown IP address access. I must admit, I'm
>> a bit hesitant to do the later, since I don't think its a good idea
>> to allow unknown client access any system daemon...
> 
> That kind of interferes with testing environments and home environments.
> Requiring the setup of a dns server just to be able to use NFS is pretty
> damn lame.
> 
Actually, isn't the host-lookup controlled by /etc/nsswitch.conf?
So the test hosts could be added to the server's /etc/hosts file
(assuming "files" is asserted in nsswitch.conf).  No need to get
DNS involved.



From SteveD at redhat.com  Mon Jan 19 16:29:21 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 19 Jan 2009 11:29:21 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <1232381350.3539.42.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>	<1232224197.3539.15.camel@localhost.localdomain>	<4974894B.1070100@RedHat.com>
	<1232381350.3539.42.camel@localhost.localdomain>
Message-ID: <4974AA61.7020405@RedHat.com>



Jesse Keating wrote:
> On Mon, 2009-01-19 at 09:08 -0500, Steve Dickson wrote:
>>  Through some side bar discussion it been suggested an update to
>> the man page is probably need (which I agree) and maybe a flag
>> of some sort to allow unknown IP address access. I must admit, I'm
>> a bit hesitant to do the later, since I don't think its a good idea
>> to allow unknown client access any system daemon... 
> 
> That kind of interferes with testing environments and home environments.
> Requiring the setup of a dns server just to be able to use NFS is pretty
> damn lame.
DNS is not required.... an entry in /etc/hosts will also work... 

steved.



From pertusus at free.fr  Mon Jan 19 16:31:31 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 19 Jan 2009 17:31:31 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
	server?
In-Reply-To: <b086760e0901190728y39e86dc1ib0f0c20515a7acc5@mail.gmail.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com> <20090119150607.GD2530@free.fr>
	<b086760e0901190728y39e86dc1ib0f0c20515a7acc5@mail.gmail.com>
Message-ID: <20090119163131.GF2530@free.fr>

On Mon, Jan 19, 2009 at 04:28:41PM +0100, yersinia wrote:
> 
> In fact the control is in mountd.  In  nfs-utils-1.1.4-6 in FC10
> ./utils/mountd/auth.c call
> auth_authenticate which call client_resolve that do the check
> forward/reverse lookup via the
> call to get_reliable_hostbyaddr in ./support/export/hostname.c.  And this is
> in the upstream release.

But if this fails, it calls get_hostent which seems to fill the
hostname with the ip.

--
Pat



From SteveD at redhat.com  Mon Jan 19 16:35:38 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 19 Jan 2009 11:35:38 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <20090119162935.GE2530@free.fr>
References: <1232223817.3539.12.camel@localhost.localdomain>	<1232224197.3539.15.camel@localhost.localdomain>	<4974894B.1070100@RedHat.com>
	<20090119150607.GD2530@free.fr>	<49749DDB.8030505@RedHat.com>
	<20090119162935.GE2530@free.fr>
Message-ID: <4974ABDA.1050003@RedHat.com>



Patrice Dumas wrote:
> On Mon, Jan 19, 2009 at 10:35:55AM -0500, Steve Dickson wrote:
>> hmm... the real need for the lookup is so the 'mountd: <hostsname>' in
>> either /etc/hosts.deny/allow will work... so I guess the idea of 
>> not don the tcp wrappers check at all might be the answer...
> 
> Doing only IP matching also would work. If you want to serve only
> clients on an ip subnetwork, you can simply have (if I recall well)
> in hosts.allow
> 
> mountd: 192.168.0.
> 
> and in hosts.deny
> ALL: ALL
> 
> Now, if hosts.deny indeed uses a host name, then if there is no 
> host name, the mount may not be denied, although it should have.
Exactly... 
 
> However the best would be that tcp_wrappers knows if the hostname
> is needed, and if needed, and not provided, it denies. The API 
> has a possibility to pass STRING_UNKNOWN to hosts_ctl, maybe it 
> does things right in that case?
Not that I found... Yes its a chick or egg scenario. I need the
hostname to do the 'mountd: <hostname>' check in /etc/hosts.deny,
but there is no way of know that entry exists... :(


steved.



From notting at redhat.com  Mon Jan 19 16:54:04 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 11:54:04 -0500
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1232189397.5215.105.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<20090116210709.GA6548@nostromo.devel.redhat.com>
	<1232189397.5215.105.camel@vespa.frost.loc>
Message-ID: <20090119165403.GC3822@nostromo.devel.redhat.com>

Tomas Mraz (tmraz at redhat.com) said: 
> > - a compatiblity openssl098g package?
> I do not see a real need for such package except the third party
> software support. We do not do compatibility packages for many other
> important libraries either. But if anyone wants to maintain it feel free
> to submit it for review and cc-me on the bugzilla entry, I will happily
> review it.

I'm just wondering if it's worth it even just as a crutch-to-keep-rawhide
-functional in cases like these. Aside from that, I guess the only other
reason to have it is for software built on F9/F10. There's certainly some
of that, but I don't know how much.

Bill



From notting at redhat.com  Mon Jan 19 17:11:04 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 12:11:04 -0500
Subject: pam_console
In-Reply-To: <loom.20090117T133315-565@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
Message-ID: <20090119171103.GD3822@nostromo.devel.redhat.com>

Jack Tanner (ihok at hotmail.com) said: 
> > For device permissions, we already have the hal/consolekit support which
> > should be use.
> 
> That may well be correct, but I have no idea how to use hal/consolekit. I
> suspect few Fedora users do. Try polling your question on fedoraforum, and see
> what those results tell you.

How is positing a change in underlying, not-user-visible-at-all, system
infrastructure to a user's forum a worthwhile endeavor? After all, the
change to set sound device permissions from HAL was done years ago.

> I recently posted a question there about
> configuring alsa permissions for mpd and the answer I got there was pam_console.
> Mind you, I am ready and willing to learn the brave new hal/consolekit way of
> things. I looked for docs and examples for hal/consolekit, and found nothing
> relevant to my use case.

http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control

Examples are in /usr/share/hal/fdi/policy/10osvendor - look at
00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the
most well documented interface, but it should be stable.

Bill



From notting at redhat.com  Mon Jan 19 17:11:32 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 12:11:32 -0500
Subject: pam_console
In-Reply-To: <20090117110943.GA2914@free.fr>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<20090117110943.GA2914@free.fr>
Message-ID: <20090119171130.GE3822@nostromo.devel.redhat.com>

Patrice Dumas (pertusus at free.fr) said: 
> I don't have much opinion on that, but I don't really get how 
> pam_ck_connector goes in the picture. Currently it is not used by 
> anything but login,

It doesn't necessarily have to be in pam_ck_connector - it could be
in the daemon itself.

Bill



From jkeating at redhat.com  Mon Jan 19 17:13:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 19 Jan 2009 09:13:13 -0800
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <4974AA61.7020405@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com>
	<1232381350.3539.42.camel@localhost.localdomain>
	<4974AA61.7020405@RedHat.com>
Message-ID: <1232385193.3539.44.camel@localhost.localdomain>

On Mon, 2009-01-19 at 11:29 -0500, Steve Dickson wrote:
>  DNS is not required.... an entry in /etc/hosts will also work... 

/etc/hosts doesn't support wildcards or $GENERATE lines like dns does.
When testing with virt guests, a new mac is generate each run, which
causes a new DHCP lease to be issued.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/42bc00fc/attachment.sig>

From bpepple at fedoraproject.org  Mon Jan 19 17:18:18 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 19 Jan 2009 12:18:18 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
Message-ID: <1232385498.10018.3.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending January 18th, 2009
were Parag AN(????), Manuel Wolfshant, and Jason Tibbitts.  Below is the
number of package reviews completed.

Parag AN(????) - 14
manuel wolfshant - 9
Jason Tibbitts - 7
Mamoru Tasaka - 6
Tim Lauridsen - 5
Steven M. Parrish - 4
Adel Gadllah - 3
Jesse Keating - 3
Jochen Schmitt - 3
Marcela Maslanova - 3
Michal Marciniszyn - 2
Nicolas Mailhot - 2
Adam Tkac - 1
Brian Pepple - 1
Christoph Wickert - 1
Denis Leroy - 1
Fabian Affolter - 1
Jon Ciesla - 1
Matthias Clasen - 1
Michal Nowak - 1
Orcan 'oget' Ogetbil - 1
Ralf Corsepius - 1
Ray Strode - 1
Robert Scheck - 1
Steve Whitehouse - 1
Toshio Ernie Kuratomi - 1
seth vidal - 1

Review Requests: 66
Merge Reviews: 10
Total reviews modified: 76

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/eac8ce52/attachment.sig>

From joshuacov at googlemail.com  Mon Jan 19 17:14:07 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 19 Jan 2009 18:14:07 +0100
Subject: Wrong security attributes. Maybe a bug?
Message-ID: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>

I used to change the owner of some files to root and set them in 444
mode in order to prevent them from modification. And it worked that
way without any issues.

Recently I saw that I can modify/delete any file in my home directory.
Even if it is owned by root and is set as 444. If I'm the owner of the
directory these files are in, I can do whatever I want with them
regardless of their owner and attributes. This is in
kde-dolphin-4.1.4.fc9.

Is this a security bug or change in the kde/dolphin policies? Has
anyone else experienced this?



From tgl at redhat.com  Mon Jan 19 17:46:21 2009
From: tgl at redhat.com (Tom Lane)
Date: Mon, 19 Jan 2009 12:46:21 -0500
Subject: Heads up openssl-0.9.8j in rawhide 
In-Reply-To: <20090119165403.GC3822@nostromo.devel.redhat.com> 
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<20090116210709.GA6548@nostromo.devel.redhat.com>
	<1232189397.5215.105.camel@vespa.frost.loc>
	<20090119165403.GC3822@nostromo.devel.redhat.com>
Message-ID: <8070.1232387181@sss.pgh.pa.us>

Bill Nottingham <notting at redhat.com> writes:
> Tomas Mraz (tmraz at redhat.com) said: 
>>> - a compatiblity openssl098g package?
>> I do not see a real need for such package except the third party
>> software support. We do not do compatibility packages for many other
>> important libraries either. But if anyone wants to maintain it feel free
>> to submit it for review and cc-me on the bugzilla entry, I will happily
>> review it.

> I'm just wondering if it's worth it even just as a crutch-to-keep-rawhide
> -functional in cases like these. Aside from that, I guess the only other
> reason to have it is for software built on F9/F10. There's certainly some
> of that, but I don't know how much.

Well, we build compatibility packages routinely for RHEL releases, but
I recall having been told there was an explicit policy against it in
Fedora releases, on the grounds that Fedora software should be
up-to-date.

(This was some time ago, though --- if there is a policy it might
have changed?)

Considering how often we force mass rebuilds for toolchain or other
low-level changes, it's hard to believe that a compatibility package
for application-library changes is going to be worth much for long.

			regards, tom lane



From bnocera at redhat.com  Mon Jan 19 17:44:23 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 19 Jan 2009 17:44:23 +0000
Subject: pam_console
In-Reply-To: <loom.20090117T133315-565@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
Message-ID: <1232387063.14929.10734.camel@cookie.hadess.net>

On Sat, 2009-01-17 at 13:43 +0000, Jack Tanner wrote:
> Bill Nottingham <notting <at> redhat.com> writes:
> 
> > 
> > I think it's time to retire pam_console from the default configuration.
> > 
> > For device permissions, we already have the hal/consolekit support which
> > should be use.
<snip>
> Bottom line: before you blow away pam_console, please spend some time doing
> education (e.g., documenting) and outreach (e.g., responding on fedoraforum)
> about the new proper way of doing things that accommodates 80% of the existing
> use cases. If you want to be thorough about it, consider the software (like mpd)
> in a few prominent third-party repos, too.

The problem is that a daemon shouldn't be talking to what should be
session devices. mpd won't work with PulseAudio, and it won't work with
HAL/CK permissions.

The maintainers would be better off adding hacks to set the permissions
on the audio devices in the startup scripts.



From tgl at redhat.com  Mon Jan 19 17:49:48 2009
From: tgl at redhat.com (Tom Lane)
Date: Mon, 19 Jan 2009 12:49:48 -0500
Subject: Wrong security attributes. Maybe a bug? 
In-Reply-To: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com> 
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
Message-ID: <8126.1232387388@sss.pgh.pa.us>

"Joshua C." <joshuacov at googlemail.com> writes:
> Recently I saw that I can modify/delete any file in my home directory.
> Even if it is owned by root and is set as 444. If I'm the owner of the
> directory these files are in, I can do whatever I want with them
> regardless of their owner and attributes.

You can delete or rename anything in a directory you have write
permissions on --- this is not actually affecting the file contents,
only the directory's link.  (This has been standard Unix behavior since
the dawn of time or thereabouts.  For justification consider the
possibility that your directory entry is only one of several hardlinks
to the file.)  If you can modify the file *contents* then it would be
interesting.

			regards, tom lane



From fedora at camperquake.de  Mon Jan 19 17:56:57 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 19 Jan 2009 18:56:57 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
Message-ID: <20090119185657.0c4fb3fb@dhcp03.addix.net>

Hi.

On Mon, 19 Jan 2009 18:14:07 +0100, Joshua C. wrote:

> Recently I saw that I can modify/delete any file in my home directory.
> Even if it is owned by root and is set as 444. If I'm the owner of the
> directory these files are in, I can do whatever I want with them
> regardless of their owner and attributes. This is in
> kde-dolphin-4.1.4.fc9.

This has been the way of UNIX since the dawn of time. Deleting a file
is a directory operation, so the permissions on the directory apply,
not the permissions on the file.

You should not be able to modify the file in place, however (but
you could delete it and create a new one, which would be owned by
you and not root).



From bertrand.benoit at bsquare.no-ip.org  Mon Jan 19 17:25:44 2009
From: bertrand.benoit at bsquare.no-ip.org (bertrand benoit)
Date: Mon, 19 Jan 2009 18:25:44 +0100
Subject: GNU/Bash help offer
Message-ID: <4974B798.9000007@bsquare.no-ip.org>

Hi everybody,

I'm Bertrand BENOIT (freshly new user of fedora-devel-list at redhat.com), 
Engineer in Computer Science (specialized in Artificial Intelligence, 
and Software Engineering).
I've used GNU/Linux Fedora from Fedora core 2, so I'm a faithful user.
In my work, among others things, I've written lots of GNU/Bash scripts 
and I would like to offer my help for GNU/Bash scripting tasks to Fedora 
project.

-- 
Cordially,
Bertrand BENOIT
--------------------------------------------------------------------------------------------
+33 (0)6 70 09 01 01         +33 (0)2 97 40 57 32
Adresse e-mail principale :  bertrand.benoit at bsquare.no-ip.org
Adresse e-mail secondaire :  bertrandbenoit.bsquare at gmail.com
Pages personnelles 	  :  http://bsquare.no-ip.org/personalPages/fr/index_from_fedoradevel.html
--------------------------------------------------------------------------------------------



From james at fedoraproject.org  Mon Jan 19 18:39:27 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 19 Jan 2009 13:39:27 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <20090116201658.GM18365@inocybe.teonanacatl.org>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<20090116201658.GM18365@inocybe.teonanacatl.org>
Message-ID: <1232390367.4934.222.camel@code.and.org>

On Fri, 2009-01-16 at 15:16 -0500, Todd Zullinger wrote:

> One advantage (which may or may not be enough to warrant keeping the
> keys separate) is that if you want to ensure no packages from
> updates-testing are installed on a box, you can easily do so by not
> importing the testing key.  I don't think any of the tools
> automatically import keys without prompting, the user, correct?

 yum-cron will automatically import the key if you enable
updates-testing, and have updates enabled. yum-updatesd should do so as
well, again assuming installing updates is enabled.
 I'd assume that PK will do the same if you have enabled auto updates
there.

 Also given that you can use --nogpgcheck and/or install key; install
pkg; remove key ... you can't guarantee that there are no
updates-testing pkgs just because there is no key currently.
 find-repos-of-install in yum-utils is the much better tool here.

-- 
James Antill <james at fedoraproject.org>
Fedora



From joshuacov at googlemail.com  Mon Jan 19 19:06:03 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 19 Jan 2009 20:06:03 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <20090119185657.0c4fb3fb@dhcp03.addix.net>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<20090119185657.0c4fb3fb@dhcp03.addix.net>
Message-ID: <5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>

2009/1/19 Ralf Ertzinger <fedora at camperquake.de>:
> Hi.
>
> On Mon, 19 Jan 2009 18:14:07 +0100, Joshua C. wrote:
>
>> Recently I saw that I can modify/delete any file in my home directory.
>> Even if it is owned by root and is set as 444. If I'm the owner of the
>> directory these files are in, I can do whatever I want with them
>> regardless of their owner and attributes. This is in
>> kde-dolphin-4.1.4.fc9.
>
> This has been the way of UNIX since the dawn of time. Deleting a file
> is a directory operation, so the permissions on the directory apply,
> not the permissions on the file.
>
> You should not be able to modify the file in place, however (but
> you could delete it and create a new one, which would be owned by
> you and not root).

 I think this concers only deleting a file. But I shouldn't be allowed
to rename it, should I? in kde3 I couldn't delete those files. why?



From james at fedoraproject.org  Mon Jan 19 19:07:28 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 19 Jan 2009 14:07:28 -0500
Subject: Why different keys for -testing and non-testing?
In-Reply-To: <200901171031.07001.sgrubb@redhat.com>
References: <1232134483.5086.180.camel@localhost.localdomain>
	<1232138336.25346.4.camel@localhost.localdomain>
	<4971F6F9.4000105@silfreed.net> <200901171031.07001.sgrubb@redhat.com>
Message-ID: <1232392048.4934.234.camel@code.and.org>

On Sat, 2009-01-17 at 10:31 -0500, Steve Grubb wrote:
> On Saturday 17 January 2009 10:19:21 am Douglas E. Warner wrote:
> > On 01/16/2009 Jesse Keating wrote:
> > > Given that we can't revoke, yes, we plan to use new keys each release.
> > > We can use gpg web-o-trust thing and sign the new keys with the old
> > > keys and whatnot, does that actually help people?
> >
> > Why couldn't we revoke keys?  Even if RPM itself doesn't have the
> > capability, we could have yum periodically check for updates on installed
> > keys on keyservers through a plugin, I would imagine.
> 
> I have a machine that has been migrated for a long time. It has 9 
> gpg-pubkey packages installed. Which ones are valid? Why don't they get 
> retired by obsoletes or something? Could someone use my ancient gpg-pubkeys 
> as a basis for an attack on repo metadata 
> (http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html) 
> and provide an older package with known security holes? 

 If an attacker has broken a key you have installed, they can just sign
bad rpms ... no need to just attack via. munged metadata (which has
other protections).

> Old keys should be retired. We should also make import of keys an auditable 
> event.

 There are a few things to take into account:

1. You can use the yum-keys plugin to look at the installed keys, and
remove old ones.

2. Yum is moving to have all GPG operations outside of rpm. We currently
have repo_gpgkey, and we'll eventually make gpgkey be per. repo too (so
you can't have rpmfusion rpms auto. installed from the fedora repo. ...
or whatever).

3. Yum can run as non-root, as can rpm ... so due to the design of audit
you can't use that.

4. rpm/yum run as root with full SELinux privs. for the package DB and
installing anything. Thus. from a realistic security POV installing any
rpm is on the same level as installing the GPG keys. Thus. it's
worthless to just "audit" GPG key installs.
 Putting audit file watches on everything in /var/lib/rpm is probably
the only viable solution, although adding something else might give a
better "ui" (but unless done very well this will be misleading as people
might only watch for the "nice ui" audit messages, and thus. be
vulnerable).

-- 
James Antill <james at fedoraproject.org>
Fedora



From ihok at hotmail.com  Mon Jan 19 19:07:57 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Mon, 19 Jan 2009 19:07:57 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
Message-ID: <loom.20090119T183621-371@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:

> 
> How is positing a change in underlying, not-user-visible-at-all, system
> infrastructure to a user's forum a worthwhile endeavor? After all, the
> change to set sound device permissions from HAL was done years ago.

It's still visible to this user. Even though sound device permissions are set
through HAL *by default*, pam_console is still a perfectly serviceable
alternative. Now, you're saying you want to take this alternative away. That
places the onus on you to make this transition bearable. (I'm not arguing
against hal/ck on technical merits, just their practical ease-of-use today.)

> http://people.freedesktop.org/~david/hal-spec/hal-spec.html#access-control
> 
> Examples are in /usr/share/hal/fdi/policy/10osvendor - look at
> 00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the
> most well documented interface, but it should be stable.

Wow. That's a lot of stuff to wade through. How about a tutorial, or a
"cookbook"? I don't have a 00-thinkfinger.fdi, that's probably a 
Thinkpad-only file.



From bmr at redhat.com  Mon Jan 19 19:14:27 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Mon, 19 Jan 2009 19:14:27 +0000
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>	<20090119185657.0c4fb3fb@dhcp03.addix.net>
	<5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>
Message-ID: <4974D113.7070801@redhat.com>

Joshua C. wrote:
> 2009/1/19 Ralf Ertzinger <fedora at camperquake.de>:
>> This has been the way of UNIX since the dawn of time. Deleting a file
>> is a directory operation, so the permissions on the directory apply,
>> not the permissions on the file.
>>
>> You should not be able to modify the file in place, however (but
>> you could delete it and create a new one, which would be owned by
>> you and not root).
> 
>  I think this concers only deleting a file. But I shouldn't be allowed
> to rename it, should I? in kde3 I couldn't delete those files. why?
> 

Renaming in unix-like file systems is equivalent to linking the file 
into the directory with a new name and then removing the old one. 
Still a directory level operation.

Try this:

[bmr at bmr ~]# su -
Password:
[root at bmr bmr]# umask 066
[root at bmr bmr]# touch pony
[root at bmr bmr]# su - bmr
[bmr at bmr ~]$ mv pony not-yours
[bmr at bmr ~]$ ll not-yours
-rw------- 1 root root 0 2009-01-19 19:08 not-yours
[bmr at bmr ~]$ cat not-yours
cat: not-yours: Permission denied
[bmr at bmr ~]$ rm not-yours
rm: remove write-protected regular empty file `not-yours'? y
[bmr at bmr ~]$ ll not-yours
ls: cannot access not-yours: No such file or directory

I can move (rename), or delete, but not access this file.

Regards,
Bryn.



From ihok at hotmail.com  Mon Jan 19 19:16:10 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Mon, 19 Jan 2009 19:16:10 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<1232387063.14929.10734.camel@cookie.hadess.net>
Message-ID: <loom.20090119T190834-505@post.gmane.org>

Bastien Nocera <bnocera <at> redhat.com> writes:

> 
> The problem is that a daemon shouldn't be talking to what should be
> session devices. mpd won't work with PulseAudio, and it won't work with
> HAL/CK permissions.

mpd has a special sink for PulseAudio, if you choose to use it that way.
PulseAudio is neat, but it uses too much CPU on my little old PC, so I've
removed it. mpd gets along with ALSA just fine, and I can give it permissions
via console.perms.d just fine. If you take away my ability to do that, please
explain how to grant those same permissions via hal/ck.

> The maintainers would be better off adding hacks to set the permissions
> on the audio devices in the startup scripts.

Sure, that'd be fine. Still, please explain how to set those. hal/ck is far too
underdocumented for average users (and far too important to remain that way).



From notting at redhat.com  Mon Jan 19 19:32:03 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 14:32:03 -0500
Subject: pam_console
In-Reply-To: <loom.20090119T183621-371@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
Message-ID: <20090119193203.GC7067@nostromo.devel.redhat.com>

Jack Tanner (ihok at hotmail.com) said: 
> > How is positing a change in underlying, not-user-visible-at-all, system
> > infrastructure to a user's forum a worthwhile endeavor? After all, the
> > change to set sound device permissions from HAL was done years ago.
> 
> It's still visible to this user.

If the permissions aren't set properly for the logged-in user, that's
a *bug*, not a user-visible change that says something about the underlying
details.

> Even though sound device permissions are set
> through HAL *by default*, pam_console is still a perfectly serviceable
> alternative.

Only in the sense that you now have two disparate systems trying to control
access to the same devices. That will never work well, and it's best to
eliminate any confusion.

Bill



From jspaleta at gmail.com  Mon Jan 19 19:36:03 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 19 Jan 2009 10:36:03 -0900
Subject: pam_console
In-Reply-To: <20090119171103.GD3822@nostromo.devel.redhat.com>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
Message-ID: <604aa7910901191136x501af910x6eaee49b3df6f8e7@mail.gmail.com>

On Mon, Jan 19, 2009 at 8:11 AM, Bill Nottingham <notting at redhat.com> wrote:
> Examples are in /usr/share/hal/fdi/policy/10osvendor - look at
> 00-thinkfinger.fdi, or 20-acl-management.fdi. It's not necessarily the
> most well documented interface, but it should be stable.


I'm still not sure how I expose my own device authorization policy so
that it appears in the authentication guis.

The real win is being able to write the policy and package it up, so
that its exposed via the gui tools so users don't have to hack hal
policy directly that can use the authentication guis or the polkit-*
cmdline tools to do authorization grants in the scope of the
package-specific policy definition.

-jef



From ville.skytta at iki.fi  Mon Jan 19 19:59:17 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Mon, 19 Jan 2009 21:59:17 +0200
Subject: unnecessary font Provides churn (was Re: rawhide report:
	20090116 changes)
In-Reply-To: <1232318783.9032.18.camel@arekh.okg>
References: <20090116081259.EF3E11F825D@releng2.fedora.phx.redhat.com>
	<200901182335.12603.ville.skytta@iki.fi>
	<1232318783.9032.18.camel@arekh.okg>
Message-ID: <200901192159.17560.ville.skytta@iki.fi>

On Monday 19 January 2009, Nicolas Mailhot wrote:
> Le dimanche 18 janvier 2009 ? 23:35 +0200, Ville Skytt? a ?crit :
> > I think it's about time the people responsible for this mess
> > start actually
> > fixing the compatibility issues and make-work they have been and still
> > seem to be continuously inflicting themselves.
>
> So, appart from spitting on some community work you didn't contribute
> to, do not contribute to, and never bothered to provide useful feedback
> on

Hmm.

- Reviewing the templates, discussing how to best adapt rpmdevtools to the 
changes, and doing practically all of the actual work (not that there was too 
much of it): https://bugzilla.redhat.com/477055

- Pointing out how some of the choices made in the fonts packaging guidelines 
make them (IMO) unnecessarily Fedora specific and thus may cause extra work 
for Fedora contributors: https://bugzilla.redhat.com/477606

- Asking for some naming rationale: 
https://www.redhat.com/archives/fedora-packaging/2009-January/msg00000.html

- Private mail asking for assistance with two common fonts packaging related 
issues I regularly run into in server environments, something that at least 
at the time was not really covered at all in anything I had read (haven't 
checked later if they would be addressed).

- My previous (admittedly quite blunt) mail in this thread and this one, in 
which I'm pointing out things that I find arrogant or that have room for 
improvement.  I can't imagine that it wouldn't benefit you and everyone else 
if you took these into consideration and wouldn't start using expressions 
like "idiocies" when facing negative feedback.

Call me whatever you like, or shrug these off, but I think the above is not 
too bad considering I'm really not too interested in fonts packaging at all 
(read more below).

> (even when personnaly CC-ed with weeks of advance), do you have 
> anything useful to say?

How about this: Thankfully practically every invasive change people warn about 
on this list is accompanied with a "I'm going to fix these issues in CVS for 
packages I have commit access to".  I don't know why we haven't seen such an 
offer from you (or from anyone else who's driving these changes; I don't know 
who exactly they are), and to me it looks like you've also turned down an 
related explicit request to help and fix what you probably of all people know 
best how to fix, and should have the permissions for: 
https://bugzilla.redhat.com/480477

I thought it goes without saying that everyone's interested in non-breakage 
and offers to help when breakage can't be avoided, but only as a last resort 
when it's clear that it can't be avoided and when it's clear exactly what to 
do about it.  Personally, that's exactly as far as my interest towards fonts 
packaging extends to at the moment.  I don't know what made you think 
otherwise and send a personal Cc for the initial discussion [0] and why you 
still continue to refer to that after reading 
https://bugzilla.redhat.com/477606#c5 

> Because idiocies like "[not] tried very hard at all" won't get you very
> far. CVS, git, wiki, mailing list, and bugzilla logs tell their own
> (true) story.

Ahh, the i-word.  Anyway, in that case I can only shudder while thinking what 
it would have been without that.  Yet I still refuse to believe better work 
couldn't have been done with this with just a bit more research and taking 
other packages and packagers better into account, and that it's unfair to 
expect that kind of better work.  The real results for one example affected 
package can be read for example from the vdr-skins %changelog for 20061119-4, 
20061119-5, and 20081124-1, as well as bugs #477478 (includes 2 changes) and 
#480477.  Of those 6 changes I count 5 (everything except the dejavu-lgc -> 
dejavu change in #477478) that from my POV have resulted/will result in no 
benefits whatsoever, they're there just to catch up with backwards 
incompatible font packaging changes.

> Not trying very hard is writing long hate mails instead of doing
> one-liner changes you've been given all the necessary info on.

The reason I'm investing this much time writing about this issue is that I 
still for some reason hope that doing so might prevent some similar issues 
happening in the future.


[0] Not that I mind the personal Cc; at some point on various lists I started 
getting so many of them that nowadays my mail is sorted to folders based on 
mailing lists in recipients, no matter what the other recipients are.  The 
consequence is that I do read the mails, but in the context of the list in 
question and usually don't even notice if I'm personally Cc'd or not in 
messages that also went to a list.



From joshuacov at googlemail.com  Mon Jan 19 19:13:27 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Mon, 19 Jan 2009 20:13:27 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<20090119185657.0c4fb3fb@dhcp03.addix.net>
	<5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>
Message-ID: <5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>

How can i make a file "readonly" regardless of its place and other
attributes? It should be edit only be root and be placed in whatever
directory it is needed?



From ihok at hotmail.com  Mon Jan 19 20:25:49 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Mon, 19 Jan 2009 20:25:49 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
	<20090119193203.GC7067@nostromo.devel.redhat.com>
Message-ID: <loom.20090119T202000-183@post.gmane.org>

Bill Nottingham <notting <at> redhat.com> writes:

> 
> > Even though sound device permissions are set
> > through HAL *by default*, pam_console is still a perfectly serviceable
> > alternative.
> 
> Only in the sense that you now have two disparate systems trying to control
> access to the same devices. That will never work well, and it's best to
> eliminate any confusion.

You're concerned about the corner cases. I'm concerned about my use case. To 
say that "it won't ever work well" is wrong, since it works fine for me now. 
What you call "eliminating confusion" I call "throwing out the baby with the
bathwater."

I'm not even saying don't throw out the bathwater. I'm just asking how this
baby should swim in the new bathwater. (Talk about a tortured baby, er,
metaphor.) :)




From poelstra at redhat.com  Sat Jan 17 01:10:40 2009
From: poelstra at redhat.com (John Poelstra)
Date: Fri, 16 Jan 2009 17:10:40 -0800
Subject: Fedora 11 Feature Update Request
Message-ID: <49713010.3090303@redhat.com>

Just a quick reminder that the Alpha freeze is approaching on Tuesday, 
January 20, 2009, and all accepted Fedora 11 feature pages should be 
current on that date.  These updates are important and helpful to a 
number of people inside and outside of Fedora and starting with 
preparation of the release notes by the documentation team.

If you have feature listed here:
     https://fedoraproject.org/wiki/Releases/11/FeatureList
please update your page.

And... if you want to submit a new feature page you have until March 3, 
2009, to submit a feature page and complete the feature.

A list of partially completed feature pages is here:
https://fedoraproject.org/wiki/Category:FeaturePageIncomplete

If anyone has any questions about the feature process feel free to 
contact me directly or ask here on the list.

Thanks,
John

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From sgrubb at redhat.com  Mon Jan 19 21:06:26 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Jan 2009 16:06:26 -0500
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<5f6f8c5f0901191106k70a12118mfba172cacdd4732a@mail.gmail.com>
	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>
Message-ID: <200901191606.26716.sgrubb@redhat.com>

On Monday 19 January 2009 02:13:27 pm Joshua C. wrote:
> How can i make a file "readonly" regardless of its place and other
> attributes?

chattr -i  ./foo

You must have CAP_LINUX_IMMUTABLE to do this which normal users do not. And 
you must be on a filesystem, like ext3, which supports immutable files.

-Steve



From sgrubb at redhat.com  Mon Jan 19 21:07:50 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 19 Jan 2009 16:07:50 -0500
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <200901191606.26716.sgrubb@redhat.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>
	<200901191606.26716.sgrubb@redhat.com>
Message-ID: <200901191607.50904.sgrubb@redhat.com>

On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
> chattr -i ?./foo

whoops...actually, chattr +i ./foo

-Steve



From notting at redhat.com  Mon Jan 19 21:24:13 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 16:24:13 -0500
Subject: pam_console
In-Reply-To: <loom.20090119T202000-183@post.gmane.org>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
	<20090119193203.GC7067@nostromo.devel.redhat.com>
	<loom.20090119T202000-183@post.gmane.org>
Message-ID: <20090119212411.GA9419@nostromo.devel.redhat.com>

Jack Tanner (ihok at hotmail.com) said: 
> You're concerned about the corner cases. I'm concerned about my use case. To 
> say that "it won't ever work well" is wrong, since it works fine for me now. 
> What you call "eliminating confusion" I call "throwing out the baby with the
> bathwater."

Having never played with mpd, what's the specific usage case you're
looking for? (i.e., when X happens, the devices should be writable
by entity Y)

Bill



From walters at verbum.org  Mon Jan 19 21:42:13 2009
From: walters at verbum.org (Colin Walters)
Date: Mon, 19 Jan 2009 16:42:13 -0500
Subject: pam_console
In-Reply-To: <20090119212411.GA9419@nostromo.devel.redhat.com>
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
	<20090119193203.GC7067@nostromo.devel.redhat.com>
	<loom.20090119T202000-183@post.gmane.org>
	<20090119212411.GA9419@nostromo.devel.redhat.com>
Message-ID: <faa16b610901191342p775de04cq82bbc6c074135967@mail.gmail.com>

On Mon, Jan 19, 2009 at 4:24 PM, Bill Nottingham <notting at redhat.com> wrote:
> Jack Tanner (ihok at hotmail.com) said:
>> You're concerned about the corner cases. I'm concerned about my use case. To
>> say that "it won't ever work well" is wrong, since it works fine for me now.
>> What you call "eliminating confusion" I call "throwing out the baby with the
>> bathwater."
>
> Having never played with mpd, what's the specific usage case you're
> looking for? (i.e., when X happens, the devices should be writable
> by entity Y)

mpd likely wants to install a rule that says "this device should
*always* be accessible by this uid".  Also, it should start pulse
internally.



From wolfy at nobugconsulting.ro  Mon Jan 19 21:13:09 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Mon, 19 Jan 2009 23:13:09 +0200
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <200901191607.50904.sgrubb@redhat.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>	<200901191606.26716.sgrubb@redhat.com>
	<200901191607.50904.sgrubb@redhat.com>
Message-ID: <4974ECE5.3050206@nobugconsulting.ro>

On 01/19/2009 09:13 PM, Joshua C. wrote:
> How can i make a file "readonly" regardless of its place and other
> attributes? It should be edit only be root and be placed in whatever
> directory it is needed?

On 01/19/2009 11:07 PM, Steve Grubb wrote:
> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>   
>> chattr -i  ./foo
>>     
>
> whoops...actually, chattr +i ./foo
>
> -Steve
>   
actually after chattr +i not even root can modify / delete the file:
[root at wolfy2 tmp]# touch x
[root at wolfy2 tmp]# chattr +i x
[root at wolfy2 tmp]# echo "1" >> x
-bash: x: Permission denied
[root at wolfy2 tmp]# rm x
rm: remove write-protected regular empty file `x'? y
rm: cannot remove `x': Operation not permitted



From forum at ru.bir.ru  Mon Jan 19 21:42:36 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Tue, 20 Jan 2009 00:42:36 +0300
Subject: Citadel groupware for Fedora
In-Reply-To: <200901171344.n0HDipoh005706@jasmine.xos.nl>
References: <200901171344.n0HDipoh005706@jasmine.xos.nl>
Message-ID: <gl2s4e$siu$1@ger.gmane.org>

Jos Vos wrote:
> Hi.
> 
> Has somebody ever looked at Citadel <http://www.citadel.org/>, a
> groupware solution, and maybe considered including it in Fedora?
> 
> Among all the pseudo-OSS and/or the too huge/too complex groupware
> packages that are around, this one looks rather promising.

Really other is not OSS? [1]
For example I'm recently start use eGroupWare [2] and now working on 
packaging (in fact adopting from Suse rpm) it for Fedora. It is on GPL.

[1] http://en.wikipedia.org/wiki/List_of_project_management_software
[2] http://egroupware.org
> 
> --
> --    Jos Vos <jos at xos.nl>
> --    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
> 



From jos at xos.nl  Mon Jan 19 21:59:40 2009
From: jos at xos.nl (Jos Vos)
Date: Mon, 19 Jan 2009 22:59:40 +0100
Subject: Citadel groupware for Fedora
In-Reply-To: <gl2s4e$siu$1@ger.gmane.org>
References: <200901171344.n0HDipoh005706@jasmine.xos.nl>
	<gl2s4e$siu$1@ger.gmane.org>
Message-ID: <20090119215940.GC26757@jasmine.xos.nl>

On Tue, Jan 20, 2009 at 12:42:36AM +0300, Pavel Alexeev (aka Pahan-Hubbitus) wrote:

> >Among all the pseudo-OSS and/or the too huge/too complex groupware
> >packages that are around, this one looks rather promising.
> 
> Really other is not OSS? [1]
> For example I'm recently start use eGroupWare [2] and now working on 
> packaging (in fact adopting from Suse rpm) it for Fedora. It is on GPL.

I didn't say that all other groupware is not OSS (note the "and/or").

But eGroupware looks at least much more complex and has the caveat that
the main documentation is available only commercially, AFAICS, which
always gives me a bad feeling.

Anyway, it's always good to have it packaged for Fedora.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From forum at ru.bir.ru  Mon Jan 19 22:02:03 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Tue, 20 Jan 2009 01:02:03 +0300
Subject: New package from one source
Message-ID: <gl2t8r$rm$1@ger.gmane.org>

Recently future request for itk apache mpm was declined [1] by 
maintainer of apache (Joe Orton (jorton at redhat.com)). Please see bug for 
details.

As was mentioned in there discussion I want package it and push to 
Fedora (it is open source and maintained). So, main question - is it 
normal situation have second package (I intend call it like apache-itk) 
with one source, which used in other rpm (apache) in repository? Is 
really there any legal issues or etc.?
I think is most correct way is to so-maintain it in main apache package, 
but this suggestion also was declined. So, what is correct way to 
package and push to Fedora additional apache MPM?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=479575



From notting at redhat.com  Mon Jan 19 22:11:49 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 19 Jan 2009 17:11:49 -0500
Subject: New package from one source
In-Reply-To: <gl2t8r$rm$1@ger.gmane.org>
References: <gl2t8r$rm$1@ger.gmane.org>
Message-ID: <20090119221149.GA10949@nostromo.devel.redhat.com>

Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said: 
> As was mentioned in there discussion I want package it and push to  
> Fedora (it is open source and maintained). So, main question - is it  
> normal situation have second package (I intend call it like apache-itk)  
> with one source, which used in other rpm (apache) in repository? Is  
> really there any legal issues or etc.?

I don't think shipping separate rebuilds of core system daemons that
consist of adding 66k of non-upstream patch is a good idea.

Bill



From loupgaroublond at gmail.com  Mon Jan 19 23:18:16 2009
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Mon, 19 Jan 2009 18:18:16 -0500
Subject: Announcing the Fedora Geo Spin
Message-ID: <7f692fec0901191518k5d847ea5t5fd0c7870c30ab5f@mail.gmail.com>

Hi Lists,

Let's begin with an apology, shall we? Sorry for cross posting, but
this does concern people on multiple mailing lists.

I would like to announce the formation of a Fedora Geo Spin with tools
for integration into Open Street Map. For more information, please see
the following link:

https://fedoraproject.org/wiki/User:Ynemoy/Fedora_Geo_Spin

In short, the Fedora Geo Spin will be a respin of Fedora with packages
for doing OSM and cartography installed out of the box, or included on
a LiveCD and/or LiveUSB.  For OSM people, the primary advantage is a
live usb stick that can be used at mapping parties to save time
configuring user computers to do mapping. The USB stick can then be
brought home, and the user can continue doing mapping there. For
Fedora people, it gives us better Fedora exposure.

Right now, the spin is a draft, and once completed will be submitted
to the Fedora Spins process for approval and inclusion in Fedora as a
blessed spin.

The link above will be the canonical todo list, for anyone looking to
participate.  If you wish to help, please feel free to contact me on
or off these email lists.

Cheers,
Yaakov Nemoy



From petersen at redhat.com  Tue Jan 20 00:06:17 2009
From: petersen at redhat.com (Jens Petersen)
Date: Mon, 19 Jan 2009 19:06:17 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <511187499.336701232409913305.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> What's the migration path for SCIM users?

Users upgrading from earlier Fedora releases can continue to use scim or if they wish they can install ibus themselves and use that.  Scim will be continue to be in Fedora for the time being.

> Can I define my own shortcuts for switching IMs, like in SCIM?

Yep, you can in ibus-setup.  Right click on ibus icon and select Preferences.

> Is there an applet for showing currently selected IM, like in SCIM?

Yes, there is.


You can already install and test ibus today if you are running F9, F10, or rawhide:

Install your favourite engine with:

 sudo yum install ibus-<engine> ibus-gtk

where <engine> is one of anthy, chewing, hangul, m17n, pinyin, table-chinese, etc.  Install ibus-qt if you need support for Qt and KDE.

Jens



From linuxguy123 at gmail.com  Tue Jan 20 00:20:42 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 17:20:42 -0700
Subject: How do I allow automatic non root access to my non standard USB
 device ?
Message-ID: <1232410842.3977.4.camel@localhost.localdomain>


I'm doing some embedded development and my flash programmer has a USB
interface.  Everything works fine if I program the device as root, but
I'd like to be able to do it as a regular user.  I get port permission
errors if I try to run the programmer as a regular user.

$ lsusb
Bus 002 Device 003: ID 064e:a101 Suyin Corp. Laptop integrated WebCam
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 006: ID 15ba:0003 Olimex Ltd. OpenOCD JTAG
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 046d:c512 Logitech, Inc. LX-700 Cordless Desktop
Receiver
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
Port
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 07ca:a321 AVerMedia Technologies, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth +
WLAN) Interface [Integrated Module]
Bus 003 Device 002: ID 08ff:2580 AuthenTec, Inc. AES2501 Fingerprint
Sensor
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


My programmer is the Olimex Ltd. OpenOCD JTAG device on bus 7.

The documentation for the device says it needs access to /proc/bus/usb.

I can allow regular user access by manually issuing a chown command for
the port, but then I'd have to do it every time I reboot or unplug the
programmer.   How do I set it up to happen automatically in F10 ?

Thanks !







From dr.diesel at gmail.com  Tue Jan 20 00:25:36 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 19 Jan 2009 19:25:36 -0500
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232410842.3977.4.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
Message-ID: <2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>

On Mon, Jan 19, 2009 at 7:20 PM, Linuxguy123 <linuxguy123 at gmail.com> wrote:

>
> I'm doing some embedded development and my flash programmer has a USB
> interface.  Everything works fine if I program the device as root, but
> I'd like to be able to do it as a regular user.  I get port permission
> errors if I try to run the programmer as a regular user.
>
> $ lsusb
> Bus 002 Device 003: ID 064e:a101 Suyin Corp. Laptop integrated WebCam
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 007 Device 006: ID 15ba:0003 Olimex Ltd. OpenOCD JTAG
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 002: ID 046d:c512 Logitech, Inc. LX-700 Cordless Desktop
> Receiver
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> Port
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 004: ID 07ca:a321 AVerMedia Technologies, Inc.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 003: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth +
> WLAN) Interface [Integrated Module]
> Bus 003 Device 002: ID 08ff:2580 AuthenTec, Inc. AES2501 Fingerprint
> Sensor
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>
>
> My programmer is the Olimex Ltd. OpenOCD JTAG device on bus 7.
>
> The documentation for the device says it needs access to /proc/bus/usb.
>
> I can allow regular user access by manually issuing a chown command for
> the port, but then I'd have to do it every time I reboot or unplug the
> programmer.   How do I set it up to happen automatically in F10 ?
>
> Thanks


You could probably just put "chmod -R 777 /dev/ttyUSB*" into /etc/rc.local,
but this is not a development question, please post this somewhere else like
fedoraforum.org.

Thanks



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/c9d17a80/attachment.htm>

From loupgaroublond at gmail.com  Tue Jan 20 00:35:59 2009
From: loupgaroublond at gmail.com (Yaakov Nemoy)
Date: Mon, 19 Jan 2009 19:35:59 -0500
Subject: Testing bugzilla <-> python access
In-Reply-To: <b401d2530901182201u4a2ddb63x8a1ab4a6ec62450b@mail.gmail.com>
References: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
	<b401d2530901182201u4a2ddb63x8a1ab4a6ec62450b@mail.gmail.com>
Message-ID: <7f692fec0901191635wec411b2r3d9f76a8f7233e0c@mail.gmail.com>

2009/1/19 Rakesh Pandit <rakesh.pandit at gmail.com>:
> 2009/1/19 Yaakov Nemoy <loupgaroublond at gmail.com>:
>> Hey List,
>>
>> I am looking to do some tools for sending in review requests and
>> updating them with revised versions via fedora-devshell. I'm also
>> planning on putting in some bits to query BZ for review requests,
>> download them, and test them in f-devshell too. There has been some
>> talk about wanting to help integrate this into review-o-matic, so this
>> is something that could probably make it easier to do reviews too.
>>
>
> We have already put in efforts and written something which includes
> most bits of what you have stated here, though that is still in **not
> usable** form. So, I would like you to collaborate with
> review-o-matic* effort. In case it is okay with you we can discuss in
> detail on review-o-matic* mailing list[1]?

If you have code to both submit new reviews, and pull information from
reviews in process, i'll use that.  I'm not picky how i get that
information :)

There was a couple of requests at FudCon to integrate code to actually
run an evaluation locally through review-o-matic. It was on my agenda,
as in Whenever I Get Around To It (TM).

I am subscribed to that mailing list, i believe.  I'll have a look
through R-O-M soon.

-Yaakov



From linuxguy123 at gmail.com  Tue Jan 20 01:03:45 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 18:03:45 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
Message-ID: <1232413425.3977.25.camel@localhost.localdomain>

On Mon, 2009-01-19 at 19:25 -0500, Dr. Diesel wrote:
> 
> 
> On Mon, Jan 19, 2009 at 7:20 PM, Linuxguy123 <linuxguy123 at gmail.com>
> wrote:
>         
>         I'm doing some embedded development and my flash programmer
>         has a USB
>         interface.  Everything works fine if I program the device as
>         root, but
>         I'd like to be able to do it as a regular user.  I get port
>         permission
>         errors if I try to run the programmer as a regular user.

<snip>

>         How do I set it up to happen automatically in F10 ?
>         
>         Thanks
> 
> You could probably just put "chmod -R 777 /dev/ttyUSB*"
> into /etc/rc.local, 

Thanks, I'll give that a try.

> but this is not a development question, please post this somewhere
> else like fedoraforum.org.

I did. I posted to the fedora-list mailing list last Thursday at about
2PM Mountain time.  I didn't get a usable answer.  Thanks again for
yours.




From linuxguy123 at gmail.com  Tue Jan 20 01:29:35 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 18:29:35 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
Message-ID: <1232414975.3833.6.camel@localhost.localdomain>

On Mon, 2009-01-19 at 19:25 -0500, Dr. Diesel wrote:


> You could probably just put "chmod -R 777 /dev/ttyUSB*" into /etc/rc.local, 

I don't think this works because USB devices get created when the device
gets plugged in.  I think rc.local only runs during boot up.  I think I
need something that works with hal.

I had this set up properly once a couple years ago, but I think the way
this works has changed since then.

The documentation for the device says it needs access to /proc/bus/usb.

Any other ideas ?

Thanks



From dr.diesel at gmail.com  Tue Jan 20 01:34:43 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Mon, 19 Jan 2009 20:34:43 -0500
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232414975.3833.6.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
	<1232414975.3833.6.camel@localhost.localdomain>
Message-ID: <2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>

You could try putting this into /etc/fstab

none /sys/bus/usb/drivers usbfs devgid=502,devmode=666 0 0



On Mon, Jan 19, 2009 at 8:29 PM, Linuxguy123 <linuxguy123 at gmail.com> wrote:

> On Mon, 2009-01-19 at 19:25 -0500, Dr. Diesel wrote:
>
>
> > You could probably just put "chmod -R 777 /dev/ttyUSB*" into
> /etc/rc.local,
>
> I don't think this works because USB devices get created when the device
> gets plugged in.  I think rc.local only runs during boot up.  I think I
> need something that works with hal.
>
> I had this set up properly once a couple years ago, but I think the way
> this works has changed since then.
>
> The documentation for the device says it needs access to /proc/bus/usb.
>
> Any other ideas ?
>
> Thanks
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/0038563a/attachment.htm>

From linuxguy123 at gmail.com  Tue Jan 20 01:38:40 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 18:38:40 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
	<1232414975.3833.6.camel@localhost.localdomain>
	<2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>
Message-ID: <1232415520.3833.11.camel@localhost.localdomain>

On Mon, 2009-01-19 at 20:34 -0500, Dr. Diesel wrote:
> 
> none /sys/bus/usb/drivers usbfs devgid=502,devmode=666 0 0

No workie !  Thanks for the attempt though.

What did you do to the front suspension to get it to hold up a 6.2 ?



From linuxguy123 at gmail.com  Tue Jan 20 01:41:21 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 18:41:21 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <1232415520.3833.11.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
	<1232414975.3833.6.camel@localhost.localdomain>
	<2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>
	<1232415520.3833.11.camel@localhost.localdomain>
Message-ID: <1232415681.3833.12.camel@localhost.localdomain>

On Mon, 2009-01-19 at 18:38 -0700, Linuxguy123 wrote:
> On Mon, 2009-01-19 at 20:34 -0500, Dr. Diesel wrote:
> > 
> > none /sys/bus/usb/drivers usbfs devgid=502,devmode=666 0 0
> 
> No workie !  Thanks for the attempt though.
> 
> What did you do to the front suspension to get it to hold up a 6.2 ?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oops !  Disregard this... it was supposed to be an offline
conversation... 



From rakesh.pandit at gmail.com  Tue Jan 20 01:54:56 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Tue, 20 Jan 2009 07:24:56 +0530
Subject: Testing bugzilla <-> python access
In-Reply-To: <7f692fec0901191635wec411b2r3d9f76a8f7233e0c@mail.gmail.com>
References: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
	<b401d2530901182201u4a2ddb63x8a1ab4a6ec62450b@mail.gmail.com>
	<7f692fec0901191635wec411b2r3d9f76a8f7233e0c@mail.gmail.com>
Message-ID: <b401d2530901191754r17758897r657475331e4e1498@mail.gmail.com>

2009/1/20 Yaakov Nemoy <loupgaroublond at gmail.com>:
> 2009/1/19 Rakesh Pandit <rakesh.pandit at gmail.com>:
[..]
>> We have already put in efforts and written something which includes
>> most bits of what you have stated here, though that is still in **not
>> usable** form. So, I would like you to collaborate with
>> review-o-matic* effort. In case it is okay with you we can discuss in
>> detail on review-o-matic* mailing list[1]?
>
> If you have code to both submit new reviews, and pull information from
> reviews in process, i'll use that.  I'm not picky how i get that
> information :)
>

Yes, there is. If you look at arch diagram[1] feeder part does the
feeding of information and reporter part does the reporting part. We
started of with implementing the bare minimum workflow and have
minimum implementation of class blocks except middle one (Applcation
block) and that is why it is bit **non usable** collectively. But yes
you can directly look at RomBugzillaFeeder[2] and
RomBugzillaReporter[3] for corresponding bugzilla examples.

> There was a couple of requests at FudCon to integrate code to actually
> run an evaluation locally through review-o-matic. It was on my agenda,
> as in Whenever I Get Around To It (TM).
>
> I am subscribed to that mailing list, i believe.  I'll have a look
> through R-O-M soon.
>

You are welcome. Lets continue the discussion there. I have a request
with infrastructure about changing project details As soon as they are
resolved, I will ping you :)

[1] https://fedorahosted.org/review-o-matic/wiki/arch_image
[2] https://fedorahosted.org/review-o-matic/browser/RomBugzillaFeeder.py
[3] https://fedorahosted.org/review-o-matic/browser/RomBugzillaReporter.py

-- 
rakesh



From alsadi at gmail.com  Tue Jan 20 01:57:36 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 20 Jan 2009 03:57:36 +0200
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232415681.3833.12.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
	<1232414975.3833.6.camel@localhost.localdomain>
	<2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>
	<1232415520.3833.11.camel@localhost.localdomain>
	<1232415681.3833.12.camel@localhost.localdomain>
Message-ID: <385866f0901191757ud22ae1at1403d2907ad38ffd@mail.gmail.com>

in the past it was something in /etc/udev/rules.d/

but I don't now know what does that

if it's like in the past a file with
SYSFS{idVendor}=="XXXX", SYSFS{idProduct}=="YYYY", MODE="666", GROUP="mygroup"

don't do that, I don't know what it will do
I'm just shed some light into some dark corner



From alsadi at gmail.com  Tue Jan 20 02:17:48 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 20 Jan 2009 04:17:48 +0200
Subject: messages eat my harddisk because of alsa or pulse
Message-ID: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>

it was a nightmare I have no space of my hdd
when I was looking for the reason
du -h messages
760M	messages

it's flooded with

Jan 18 15:36:50 localhost kernel: imklog 3.21.9, log source =
/proc/kmsg started.
Jan 18 15:36:50 localhost rsyslogd: [origin software="rsyslogd"
swVersion="3.21.9" x-pid="1969" x-info="http://www.rsyslog.co
m"] restart
Jan 18 15:43:23 localhost pulseaudio[3014]: module-alsa-sink.c: ALSA
woke us up to write new data to the device, but there wa
s actually nothing to write! Most likely this is an ALSA driver bug.
Please report this issue to the PulseAudio developers.
Jan 18 15:43:23 localhost pulseaudio[3014]: module-alsa-sink.c: ALSA
woke us up to write new data to the device, but there wa
s actually nothing to write! Most likely this is an ALSA driver bug.
Please report this issue to the PulseAudio developers.
...
Jan 20 04:00:43 localhost pulseaudio[3021]: module-alsa-sink.c: ALSA
woke us up to write new data to the device, but there wa
s actually nothing to write! Most likely this is an ALSA driver bug.
Please report this issue to the PulseAudio developers.

what is the reason,
an update in alsa or pulse or most likely because I edited
/etc/pulse/default.pa by to add

load-module module-hal-detect tsched=0

https://fedoraproject.org/wiki/Features/GlitchFreeAudio

to get rid of the skips in the sound



From kevin at scrye.com  Tue Jan 20 02:17:55 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 19 Jan 2009 19:17:55 -0700
Subject: Xfce 4.6 beta3 landing in rawhide tomorrow (2009-01-20)
Message-ID: <20090119191755.0c532101@ohm.scrye.com>

Just a heads up to everyone that Xfce 4.6 beta2 will be landing in
rawhide tomorrow. 

https://fedoraproject.org/wiki/Features/Xfce46

If you are using Xfce, you may need to 'rpm -e imsettings-xfce' to get
things to upgrade as it's still using the old obsolete mcs config
backend. (This is being worked on, but not ready yet). 

Testing/Bugs/Comments welcome. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/10cbad6e/attachment.sig>

From linuxguy123 at gmail.com  Tue Jan 20 02:19:03 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Mon, 19 Jan 2009 19:19:03 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <385866f0901191757ud22ae1at1403d2907ad38ffd@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<2a28d2ab0901191625k20c28f97tde686f2c4e82749c@mail.gmail.com>
	<1232414975.3833.6.camel@localhost.localdomain>
	<2a28d2ab0901191734i327110a3maa359259e91e3eec@mail.gmail.com>
	<1232415520.3833.11.camel@localhost.localdomain>
	<1232415681.3833.12.camel@localhost.localdomain>
	<385866f0901191757ud22ae1at1403d2907ad38ffd@mail.gmail.com>
Message-ID: <1232417943.6085.6.camel@localhost.localdomain>

On Tue, 2009-01-20 at 03:57 +0200, Muayyad AlSadi wrote:
> in the past it was something in /etc/udev/rules.d/
> 
> but I don't now know what does that
> 
> if it's like in the past a file with
> SYSFS{idVendor}=="XXXX", SYSFS{idProduct}=="YYYY", MODE="666", GROUP="mygroup"
> 
> don't do that, I don't know what it will do
> I'm just shed some light into some dark corner

That is exactly how it USED to be done.  Now we have:

$ls /etc/udev/rules.d

10-libifp.rules               60-wacom.rules           90-alsa.rules
40-multipath.rules            70-mdadm.rules           90-hal.rules
51-packagekit-firmware.rules  70-persistent-cd.rules
91-drm-modeset.rules
60-libmtp.rules               70-persistent-net.rules
97-bluetooth-serial.rules
60-libnjb.rules               85-pcscd_ccid.rules      99-fuse.rules
60-pcmcia.rules               85-pcscd_egate.rules

And 90-hal.rules contains this:

# pass all events to the HAL daemon
RUN+="socket:/org/freedesktop/hal/udev_event"

Do I need to make a file 71-persistent-usb.rules ?  The reason I am
suspicious of doing that is because I used the gnome set authorization
tool to allow non root access to my ttyUSB devices and I haven't found a
rule for that in this directory.  I'd use that tool to allow access to
the USB port for my programmer, but it doesn't appear to handle non
standard devices.

I don't feel so bad about asking this question now...






From kamei at miraclelinux.com  Tue Jan 20 02:24:14 2009
From: kamei at miraclelinux.com (Ryoji Kamei)
Date: Tue, 20 Jan 2009 11:24:14 +0900
Subject: ibus and F11
In-Reply-To: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <497535CE.9030207@miraclelinux.com>

Hi,

I just read the wiki about iBus, and I have a question as a future user.

> scim loads engines as dl-modules so a problem in any engine can take 
> down scim, whereas in ibus because the processes are separated only a
> faulty process will die leaving rest of the system working normally.

Could anyone point me how iBus resolves input-spoofing or snooping problem?
Doesn't iBus relate inputting itself?
I think it may be a FAQ, however I didn't find it yet.

Jens Petersen wrote:
> Hi,
> 
> Peng Huang and Fedora i18n are submitting a Feature to use ibus [1] as the default input method system in F11.
> 
>  https://fedoraproject.org/wiki/Features/IBus
> 
> iBus was added to Fedora during the F10 cycle and is under active development.  We now feel that it is ready for wider testing and to become sufficiency stable and featured to be the default input method for Fedora 11.
> 
> There will also be some more discussion about this in the Fedora I18n meeting tomorrow, announced last week. [2]
> 
> Jens
> 
> [1] http://code.google.com/p/ibus/
> 
> [2] https://fedoraproject.org/wiki/I18N/Meetings
> 


-- 
Ryoji KAMEI <kamei at miraclelinux.com> (http://www.miraclelinux.com/)
 Linux Distribution Group,
  Server Busyness Development Division, MIRACLE LINUX Corp.



From alsadi at gmail.com  Tue Jan 20 02:37:47 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 20 Jan 2009 04:37:47 +0200
Subject: messages eat my harddisk because of alsa or pulse
In-Reply-To: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
References: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
Message-ID: <385866f0901191837k2daf16d5u5c82a1c2bd658c14@mail.gmail.com>

I have removed tsched=0 from /etc/pulse/default.pa  and rebooted
and I still got those entries in messages

Jan 20 04:28:39 localhost pulseaudio[3035]: module-alsa-sink.c: Increasing wakeu
p watermark to 40.00 ms
Jan 20 04:29:50 localhost pulseaudio[3035]: module-alsa-sink.c: Increasing wakeu
p watermark to 80.00 ms
Jan 20 04:31:02 localhost pulseaudio[3035]: module-alsa-sink.c: Increasing wakeu
p watermark to 160.00 ms
Jan 20 04:31:26 localhost pulseaudio[3035]: module-alsa-sink.c: Increasing wakeu
p watermark to 176.60 ms
Jan 20 04:32:10 localhost pulseaudio[3035]: module-alsa-sink.c: ALSA woke us up
to write new data to the device, but there was actually nothing to write! Most l
ikely this is an ALSA driver bug. Please report this issue to the PulseAudio dev
elopers.
Jan 20 04:32:10 localhost pulseaudio[3035]: module-alsa-sink.c: ALSA woke us up
to write new data to the device, but there was actually nothing to write! Most l
ikely this is an ALSA driver bug. Please report this issue to the PulseAudio dev
elopers.


and worse the sounds skips again



From cdahlin at redhat.com  Tue Jan 20 02:42:08 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Mon, 19 Jan 2009 21:42:08 -0500
Subject: New package from one source
In-Reply-To: <20090119221149.GA10949@nostromo.devel.redhat.com>
References: <gl2t8r$rm$1@ger.gmane.org>
	<20090119221149.GA10949@nostromo.devel.redhat.com>
Message-ID: <49753A00.6060802@redhat.com>

Bill Nottingham wrote:
> Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said: 
>   
>> As was mentioned in there discussion I want package it and push to  
>> Fedora (it is open source and maintained). So, main question - is it  
>> normal situation have second package (I intend call it like apache-itk)  
>> with one source, which used in other rpm (apache) in repository? Is  
>> really there any legal issues or etc.?
>>     
>
> I don't think shipping separate rebuilds of core system daemons that
> consist of adding 66k of non-upstream patch is a good idea.
>
> Bill
>
>   
seconded. If it isn't good enough for upstream we don't want it.

--CJD



From kevin.kofler at chello.at  Tue Jan 20 02:44:53 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 20 Jan 2009 03:44:53 +0100
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
Message-ID: <gl3dr5$eqo$1@ger.gmane.org>

Jack Tanner wrote:
> It's still visible to this user. Even though sound device permissions are
> set through HAL *by default*, pam_console is still a perfectly serviceable
> alternative. Now, you're saying you want to take this alternative away.
> That places the onus on you to make this transition bearable. (I'm not
> arguing against hal/ck on technical merits, just their practical
> ease-of-use today.)

The point is that users shouldn't be murking with pam_console or HAL
permissions at all. They shouldn't have to. It's the packagers' job to make
the permissions be correct out of the box.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan 20 02:44:53 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 20 Jan 2009 03:44:53 +0100
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
Message-ID: <gl3dr5$eqo$1@ger.gmane.org>

Jack Tanner wrote:
> It's still visible to this user. Even though sound device permissions are
> set through HAL *by default*, pam_console is still a perfectly serviceable
> alternative. Now, you're saying you want to take this alternative away.
> That places the onus on you to make this transition bearable. (I'm not
> arguing against hal/ck on technical merits, just their practical
> ease-of-use today.)

The point is that users shouldn't be murking with pam_console or HAL
permissions at all. They shouldn't have to. It's the packagers' job to make
the permissions be correct out of the box.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan 20 02:56:21 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 20 Jan 2009 03:56:21 +0100
Subject: ibus and F11
References: <1385605566.67011232363404181.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <gl3egl$g7e$1@ger.gmane.org>

Jens Petersen wrote:
> Peng Huang and Fedora i18n are submitting a Feature to use ibus [1] as the
> default input method system in F11.

WTF, how often is the wheel going to be reinvented? We've gone through XIM,
IIIMF, UIM (or the other way round), SCIM and now IBus...

        Kevin Kofler



From mzerqung at 0pointer.de  Tue Jan 20 03:10:54 2009
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Tue, 20 Jan 2009 04:10:54 +0100
Subject: messages eat my harddisk because of alsa or pulse
In-Reply-To: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
References: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
Message-ID: <20090120031054.GA27902@tango.0pointer.de>

On Tue, 20.01.09 04:17, Muayyad AlSadi (alsadi at gmail.com) wrote:

> Jan 20 04:00:43 localhost pulseaudio[3021]: module-alsa-sink.c: ALSA
> woke us up to write new data to the device, but there wa
> s actually nothing to write! Most likely this is an ALSA driver bug.
> Please report this issue to the PulseAudio developers.
> 
> what is the reason,

Your ALSA driver is broken.

That said, I didn't expect that this message would be printed that
often on the setups where they happen. PA probably should have some
kind of rate limiter on that. However I think it is mostly a DoS in
rsyslog that no kind of rate limiting is done there:

https://bugzilla.redhat.com/show_bug.cgi?id=478912

> an update in alsa or pulse or most likely because I edited
> /etc/pulse/default.pa by to add
> 
> load-module module-hal-detect tsched=0

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From cweyl at alumni.drew.edu  Tue Jan 20 03:58:42 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 19 Jan 2009 19:58:42 -0800
Subject: Testing bugzilla <-> python access
In-Reply-To: <7f692fec0901191635wec411b2r3d9f76a8f7233e0c@mail.gmail.com>
References: <7f692fec0901181132q39c2c935h2f3457c0f9624907@mail.gmail.com>
	<b401d2530901182201u4a2ddb63x8a1ab4a6ec62450b@mail.gmail.com>
	<7f692fec0901191635wec411b2r3d9f76a8f7233e0c@mail.gmail.com>
Message-ID: <7dd7ab490901191958n4cb31a2eh70f90d88f23e5a37@mail.gmail.com>

On Mon, Jan 19, 2009 at 4:35 PM, Yaakov Nemoy <loupgaroublond at gmail.com> wrote:
> If you have code to both submit new reviews, and pull information from
> reviews in process, i'll use that.  I'm not picky how i get that
> information :)

I'd been holding off on mentioning this publicly (until earlier today,
at least), but given the topic it seems apropos. I've been working on
a replacement to my (venerable but aging) post-to-review script:
reviewtool.

    https://fedoraproject.org/wiki/ReviewTool

reviewtool aims to take some of the pain out of submitting/reviewing
packages, though only the submitting side of the tool is usable at
this point.  It is _not_ a "Review-Oh-Matic", and doesn't do anything
a packager / reviewer can't do on their own... It works with our
standard infrastructure tools (bugzilla, koji and fedorapeople.org) to
automate the routine bits that are common to every submission:
searching for bugs, koji scratch builds, generating correctly
formatted review/branch submissions, pushing the spec/srpm to a
publicly accessible location, etc, etc.

It's still pretty rough -- especially on the documentation side -- but
very usable for submitting tix and managing those tix to completion.

                                            -Chris
-- 
Chris Weyl
Ex astris, scientia



From ihok at hotmail.com  Tue Jan 20 04:18:01 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Tue, 20 Jan 2009 04:18:01 +0000 (UTC)
Subject: pam_console
References: <20090116203129.GA5449@nostromo.devel.redhat.com>
	<loom.20090117T133315-565@post.gmane.org>
	<20090119171103.GD3822@nostromo.devel.redhat.com>
	<loom.20090119T183621-371@post.gmane.org>
	<20090119193203.GC7067@nostromo.devel.redhat.com>
	<loom.20090119T202000-183@post.gmane.org>
	<20090119212411.GA9419@nostromo.devel.redhat.com>
	<faa16b610901191342p775de04cq82bbc6c074135967@mail.gmail.com>
Message-ID: <loom.20090120T041151-517@post.gmane.org>

Colin Walters <walters <at> verbum.org> writes:

> On Mon, Jan 19, 2009 at 4:24 PM, Bill Nottingham <notting <at> redhat.com> 
wrote:
> > Having never played with mpd, what's the specific usage case you're
> > looking for? (i.e., when X happens, the devices should be writable
> > by entity Y)
> 
> mpd likely wants to install a rule that says "this device should
> *always* be accessible by this uid".  Also, it should start pulse
> internally.

That's exactly the use case. The mpd daemon runs all the time, no matter who 
is doing what at the console. While it's running, it should always be able 
to play audio. I'm not sure about Colin's point about starting pulse 
internally... mpd does have an optional pulseaudio sink, but I use it with 
an alsa sink.



From petersen at redhat.com  Tue Jan 20 06:07:09 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 01:07:09 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <gl3egl$g7e$1@ger.gmane.org>
Message-ID: <2020205782.363441232431629666.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Kevin Kofler" <kevin.kofler at chello.at> wrote:
> WTF, how often is the wheel going to be reinvented? We've gone through XIM,
> IIIMF, [snip] SCIM and now IBus...

(uim has never been a default input-method system in fedora - though we still ship it.)

Until we have a good stable system that is well-designed and does what we want it to? :)

Jens



From tagoh at redhat.com  Tue Jan 20 06:09:41 2009
From: tagoh at redhat.com (Akira TAGOH)
Date: Tue, 20 Jan 2009 15:09:41 +0900 (JST)
Subject: ibus and F11
In-Reply-To: <gl3egl$g7e$1@ger.gmane.org>
References: <1385605566.67011232363404181.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gl3egl$g7e$1@ger.gmane.org>
Message-ID: <20090120.150941.525581315788009011.tagoh@redhat.com>

>>>>> On Tue, 20 Jan 2009 03:56:21 +0100,
>>>>> "KK" == Kevin Kofler <kevin.kofler at chello.at> wrote:

KK> WTF, how often is the wheel going to be reinvented? We've gone through XIM,
KK> IIIMF, UIM (or the other way round), SCIM and now IBus...

We've never gone through UIM or any others the above. but
you're right. it's so often.

--
Akira TAGOH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/830e1c3d/attachment.sig>

From petersen at redhat.com  Tue Jan 20 06:17:24 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 01:17:24 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <632155752.364051232431979082.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <757627063.364381232432244461.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Ryoji Kamei" <kamei at miraclelinux.com> wrote:
> Could anyone point me how iBus resolves input-spoofing or snooping problem?

Exactly what kind of attacks do you have in mind?  You mean people snooping tcp/ip?
ibus (like scim) uses unix domain sockets (by default).

> Doesn't iBus relate inputting itself?

ibus is an input method system like scim, uim, etc.

Jens



From poelstra at redhat.com  Tue Jan 20 06:17:53 2009
From: poelstra at redhat.com (John Poelstra)
Date: Mon, 19 Jan 2009 22:17:53 -0800
Subject: Looking for Fedora bugmasters
In-Reply-To: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
References: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
Message-ID: <49756C91.6020708@redhat.com>

Roozbeh Pournader wrote:
> I have been in an awkward situation for quite a while now: I created
> the tracker bug for FE-NEEDSPONSOR three years ago (which made me its
> reporter). Since then, I've been CC-ed on all the changes. I was
> wondering who should I contact to change the "reporter" of the bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=177841
> 
> Or should I open a bug for that? If yes, in product/component?
> 
> roozbeh
> 

Who should the reporter be changed to?

John



From peter at thecodergeek.com  Tue Jan 20 06:33:36 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Mon, 19 Jan 2009 22:33:36 -0800
Subject: ibus and F11
In-Reply-To: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1232433216.4806.15.camel@localhost.localdomain>

Aside from the benefits of having the IMEs more modularized and whatnot,
what would be the user-visible dis/advantages of iBus versus existing
SCIM usage? 

For example, I use SCIM/Anthy to input Japanese text on a frequent basis
(using the R?maji method); and one thing I love about it is that it is
very easy to toggle between English and Japanese with its default
keyboard shortcut (ctrl + space). Is switching back and forth as easy
with iBus? (And if not by default, is that option at least readily
available?) 

Another excellent feature of SCIM, for me, is the
handwriting-recognition features provided through Tomoe. This helps me
*immensely* in my study of Kanji characters since it allows me to search
for the character in StarDict or on Wiktionary when I do not yet know
its readings (and thus could not enter it with the phonetic Anthy/R?maji
method) as I can simply draw it on my Wacom tablet and then have it
inserted into the search window. Does iBus have similar capabilities or
a Tomoe plugin of its own?

Thanks. :)
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.com>
???????????
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090119/bacefe35/attachment.sig>

From kamei at miraclelinux.com  Tue Jan 20 06:51:32 2009
From: kamei at miraclelinux.com (Ryoji Kamei)
Date: Tue, 20 Jan 2009 15:51:32 +0900
Subject: ibus and F11
In-Reply-To: <757627063.364381232432244461.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <757627063.364381232432244461.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <49757474.3070107@miraclelinux.com>

Hi,

Jens Petersen wrote:
> ----- "Ryoji Kamei" <kamei at miraclelinux.com> wrote:
>> Could anyone point me how iBus resolves input-spoofing or snooping problem?
> 
> Exactly what kind of attacks do you have in mind?  You mean people snooping tcp/ip?

Yes.

> ibus (like scim) uses unix domain sockets (by default).

I see. I will be able to try that.

Thank you.
-- 
Ryoji KAMEI <kamei at miraclelinux.com> (http://www.miraclelinux.com/)
 Linux Distribution Group,
  Server Busyness Development Division, MIRACLE LINUX Corp.



From petersen at redhat.com  Tue Jan 20 07:05:34 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 02:05:34 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <1905884393.366101232434663461.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Peter Gordon" <peter at thecodergeek.com> wrote:
> Aside from the benefits of having the IMEs more modularized and whatnot,
> what would be the user-visible dis/advantages of iBus versus existing
> SCIM usage? 

I think the benefits will grow.  Initially users should see quicker startup times for F11 and be able to add or remove IMEs without restarting their desktop for example.

> For example, I use SCIM/Anthy to input Japanese text on a frequent basis
> (using the R?maji method); and one thing I love about it is that it is
> very easy to toggle between English and Japanese with its default
> keyboard shortcut (ctrl + space). Is switching back and forth as easy
> with iBus?

Yep, ibus supports Ctrl+Space for toggling by default just like scim.

> Another excellent feature of SCIM, for me, is the
> handwriting-recognition features provided through Tomoe. This helps
> me *immensely* in my study of Kanji characters since it allows me to search
> for the character in StarDict or on Wiktionary when I do not yet know
> its readings (and thus could not enter it with the phonetic Anthy/R?maji
> method) as I can simply draw it on my Wacom tablet and then have it
> inserted into the search window. Does iBus have similar capabilities
> or a Tomoe plugin of its own?

Not yet, I agree it would be nice to have ibus-tomoe.  Actually scim-tomoe is just a thin layer over tomoe-gtk and tomoe itself so it should not be terribly hard to do.



From cweyl at alumni.drew.edu  Tue Jan 20 07:05:55 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 19 Jan 2009 23:05:55 -0800
Subject: Looking for Fedora bugmasters
In-Reply-To: <49756C91.6020708@redhat.com>
References: <e117404e0901130010h26890e41nabc1ac596418ca88@mail.gmail.com>
	<49756C91.6020708@redhat.com>
Message-ID: <7dd7ab490901192305mf4712e4nc3c76372491244b5@mail.gmail.com>

On Mon, Jan 19, 2009 at 10:17 PM, John Poelstra <poelstra at redhat.com> wrote:
> Roozbeh Pournader wrote:
>>
>> I have been in an awkward situation for quite a while now: I created
>> the tracker bug for FE-NEEDSPONSOR three years ago (which made me its
>> reporter). Since then, I've been CC-ed on all the changes. I was
>> wondering who should I contact to change the "reporter" of the bug:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=177841
>>
>> Or should I open a bug for that? If yes, in product/component?
>>
>> roozbeh
>>
>
> Who should the reporter be changed to?

I would think that nobody at fedoraproject.org is anxious to be chosen :-)

                               -Chris
-- 
Chris Weyl
Ex astris, scientia



From ivazqueznet at gmail.com  Tue Jan 20 06:38:57 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 20 Jan 2009 01:38:57 -0500
Subject: ibus and F11
In-Reply-To: <1232433216.4806.15.camel@localhost.localdomain>
References: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1232433216.4806.15.camel@localhost.localdomain>
Message-ID: <1232433537.30871.50.camel@ignacio.lan>

On Mon, 2009-01-19 at 22:33 -0800, Peter Gordon wrote:
> For example, I use SCIM/Anthy to input Japanese text on a frequent basis
> (using the R?maji method); and one thing I love about it is that it is
> very easy to toggle between English and Japanese with its default
> keyboard shortcut (ctrl + space). Is switching back and forth as easy
> with iBus? (And if not by default, is that option at least readily
> available?) 

Yes, although switching between hiragana and katakana is not as easy
yet.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/08c18ab7/attachment.sig>

From dchen at redhat.com  Tue Jan 20 07:40:28 2009
From: dchen at redhat.com (Ding-Yi Chen)
Date: Tue, 20 Jan 2009 17:40:28 +1000
Subject: ibus and F11
In-Reply-To: <gl3egl$g7e$1@ger.gmane.org>
References: <1385605566.67011232363404181.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<gl3egl$g7e$1@ger.gmane.org>
Message-ID: <1232437228.3607.5.camel@localhost.localdomain>

? ??2009-01-20 ? 03:56 +0100?Kevin Kofler ???
> Jens Petersen wrote:
> > Peng Huang and Fedora i18n are submitting a Feature to use ibus [1] as the
> > default input method system in F11.
> 
> WTF, how often is the wheel going to be reinvented? We've gone through XIM,
> IIIMF, UIM (or the other way round), SCIM and now IBus...
> 
>         Kevin Kofler
> 

Firstly. none of these wheels fits everyone's taste.
So there are  couples of others which are still active, such as OXIM,
GCIN....

Secondly, and most importantly, SCIM is end-of-production.

Regards,
Ding-Yi Chen



From forum at ru.bir.ru  Tue Jan 20 08:08:38 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Tue, 20 Jan 2009 11:08:38 +0300
Subject: New package from one source
In-Reply-To: <20090119221149.GA10949@nostromo.devel.redhat.com>
References: <gl2t8r$rm$1@ger.gmane.org>
	<20090119221149.GA10949@nostromo.devel.redhat.com>
Message-ID: <gl40q6$pob$1@ger.gmane.org>

Bill Nottingham wrote:
> Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said: 
>> As was mentioned in there discussion I want package it and push to  
>> Fedora (it is open source and maintained). So, main question - is it  
>> normal situation have second package (I intend call it like apache-itk)  
>> with one source, which used in other rpm (apache) in repository? Is  
>> really there any legal issues or etc.?
> 
> I don't think shipping separate rebuilds of core system daemons that
> consist of adding 66k of non-upstream patch is a good idea.
Is there other form shipping this mpm axcept of separate rebuild in this 
case??

I'm completely do not understand - why we do not want provide free 
choose for free users? Why Ubuntu has ITK (and Debian I think too)? 
Moreover, this is the most useful mpm for apache to multi-user 
environment! Perchild is very unstable, suPHP and other cgi-based 
solutions is not alternatives... I'm use it on my servers and do not 
find any critical bug or problems very long time of exploitation.

Futermore current httpd.spec contains 14 patches, without ANY mention of 
  BZ# or link, or description [1]! Is it "good idea"?

And main question - Why I can't do it for thus users who want use it in 
Fedora? Is there any guidelines about it?

[1] 
http://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment



From forum at ru.bir.ru  Tue Jan 20 08:11:11 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Tue, 20 Jan 2009 11:11:11 +0300
Subject: New package from one source
In-Reply-To: <49753A00.6060802@redhat.com>
References: <gl2t8r$rm$1@ger.gmane.org>	<20090119221149.GA10949@nostromo.devel.redhat.com>
	<49753A00.6060802@redhat.com>
Message-ID: <gl40uv$pob$2@ger.gmane.org>

Casey Dahlin ?????:
> Bill Nottingham wrote:
>> Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said:  
>>> As was mentioned in there discussion I want package it and push to  
>>> Fedora (it is open source and maintained). So, main question - is it  
>>> normal situation have second package (I intend call it like 
>>> apache-itk)  with one source, which used in other rpm (apache) in 
>>> repository? Is  really there any legal issues or etc.?
>>>     
>>
>> I don't think shipping separate rebuilds of core system daemons that
>> consist of adding 66k of non-upstream patch is a good idea.
>>
>> Bill
>>
>>   
> seconded. If it isn't good enough for upstream we don't want it.
Hmm. May you more explain why??
We have many packages with completely dead upstream. I'm not sure, but 
may be it is even not be presented apache upstream.



From rawhide at fedoraproject.org  Tue Jan 20 08:23:10 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 20 Jan 2009 08:23:10 +0000 (UTC)
Subject: rawhide report: 20090120 changes
Message-ID: <20090120082310.6929F1F825F@releng2.fedora.phx.redhat.com>

Compose started at Tue Jan 20 06:01:02 UTC 2009

New package botan
        Crypto library written in C++
New package gaupol
        Subtitle editor
New package gupnp-igd
        Library to handle UPnP IGD port mapping
New package libxfce4menu
        A freedesktop.org compliant menu implementation for Xfce
New package ratproxy
        A passive web application security assessment tool
New package rubygem-nokogiri
        An HTML, XML, SAX, and Reader parser
New package sbackup
        Simple Backup Suite for desktop use
New package urlwatch
        A tool for monitoring webpages for updates
New package xfce4-settings
        Settings Manager for Xfce
New package xfconf
        Hierarchical configuration system for Xfce
New package zapplet
        Zenoss Tray Applet
Updated Packages:

DevIL-1.7.5-2.fc11
------------------
* Mon Jan 19 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.7.5-2
- Fix missing symbols (rh 480269)
- Fix off by one error in CVE-2008-5262 check (rh 479864)


Thunar-0.9.93-1.fc11
--------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Fri Dec 26 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 0.9.92-1
- Update to 0.9.92

* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.3-1
- Update to 0.9.3
- Respect xdg user directory paths (#457740)
- Don't spawn zombies (bugzilla.xfce.org #2983)
- Add additional sendto helpers for bluethooth and audaciuos (#450784)


anaconda-11.5.0.10-1
--------------------
* Mon Jan 19 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 11.5.0.10-1
- btrfs install support (sandeen)
- Default / to be ext4 (katzj)
- Allow live installs to use ext4 as root and make the error message clearer
  (katzj)
- Add support for Maithili and Nepali (#473209). (clumens)


asymptote-1.59-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.59-1
- 1.59

* Mon Jan 12 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.58-1
- 1.58


baekmuk-ttf-fonts-2.2-14.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-14.fc11
- Resolves: rhbz#477332
- Refined according to Mailhot's comments (477410) on liberaton fonts.


bluez-4.27-1.fc11
-----------------
* Mon Jan 19 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 4.27-1
- Update to 4.27


busybox-1.13.2-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 1:1.13.2-1
- update to 1.13.2


bzr-1.11-1.fc11
---------------
* Mon Jan 19 17:00:00 2009 Henrik Nordstrom <henrik at henriknordstrom.net> - 1.11-1
- Update to 1.11


bzrtools-1.11.0-1.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Henrik Nordstrom <henrik at henriknordstrom.net> - 1.11.0-1
- Update to 1.11.0


cairo-dock-2.0.0-0.3.svn1491_trunk.fc11
---------------------------------------
* Tue Jan 20 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1491


deco-1.6-1.fc11
---------------
* Mon Jan 19 17:00:00 2009 Orcan Ogetbil <oget [DOT] fedora [AT] gmail [DOT] com> 1.6-1
- Version update. Change in work flow for failed extractions.


deco-archive-1.4-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Orcan Ogetbil <oget [DOT] fedora [AT] gmail [DOT] com> 1.4
- Version update. New extensions: gem and tbz2
- Handle .shn format (shorten) with ffmpeg (if installed)
- Handle .alz format with unalz (if installed)


denemo-0.8.0-2.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Roy Rankin <rrankin at ihug.com.au> - 0.8.0-2
-Font split into seperate RPM package (Bugzilla 477375)


devhelp-0.23-1.fc11
-------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 0.23-1
- Update to 0.23


dosfstools-3.0.1-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Peter Vrabec <pvrabec at redhat.com> - 3.0.1-1
- upgrade
- include ChangeLog and COPYING (#225707)


dvipdfmx-0-0.26.20090115cvs.fc11
--------------------------------
* Tue Jan 20 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 0-0.26.20090115cvs
- Update to 20090115 snapshot


eclipse-3.4.1-13.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 1:3.4.1-13
- Fix pdebuild to auto-set javacSouce based on BREE.


evolution-data-server-2.25.5-1.fc11
-----------------------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.5-1.fc11
- Update to 2.25.5
- Bump gtk2_version to 2.14.0.


exo-0.3.93-1.fc11
-----------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> 0.3.93-1
- Update to 0.3.93

* Tue Dec 23 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> 0.3.92-1
- Update to 0.3.92

* Tue Dec 16 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> 0.3.4-5
- Add hal-devel Requires to devel package.


fldigi-3.10-1.fc11
------------------
* Mon Jan 19 17:00:00 2009 Randall J Berry 'Dp67' <dp67 at fedoraproject.org> 3.10-1
- New upstream release


fontconfig-2.6.91-1.git.64.g9feaf34.fc11
----------------------------------------
* Mon Jan 19 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.91-1.git.64.g9feaf34
- Update to 2.6.91-1.git.64.g9feaf34


ghc-6.10.1-7.fc11
-----------------
* Mon Jan 19 17:00:00 2009 Jens Petersen <petersen at redhat.com> - 6.10.1-7
- buildrequire ncurses-devel to fix build of missing editline package needed
  for ghci line-editing (#478466)
- move spec templates to a haskell-packaging for easy updating
- provide correct haddock version


gnomad2-2.9.3-1.fc11
--------------------
* Mon Jan 19 17:00:00 2009 Linus Walleij <triad at df.lth.se> 2.9.3-1
- New upstream, compiles with libmtp < 0.3.0 also (for F-9)


gnome-desktop-2.25.5-1.fc11
---------------------------
* Mon Jan 19 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 2.25.5-1
- Update to 2.25.5


gnome-python2-2.25.1-1.fc11
---------------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1.fc11
- Update to 2.25.1


gnome-python2-desktop-2.25.1-1.fc11
-----------------------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1.fc11
- Update to 2.25.1
- Remove patch for GNOME bug #564525 (fixed upstream).


gperf-3.0.3-5.fc11
------------------
* Mon Jan 19 17:00:00 2009 Roman Rakus <rrakus at redhat.com> - 3.0.3-5
- Specfile fixes
  Resolves: #225854


gromacs-4.0.3-4.fc11
--------------------
* Mon Jan 19 17:00:00 2009 Jussi Lehtola <jussi.lehtola at iki.fi> - 4.0.3-4
- Retry fixing gmxdemo.

* Mon Jan 19 17:00:00 2009 Jussi Lehtola <jussi.lehtola at iki.fi> - 4.0.3-3
- Fixed gmxdemo.

* Mon Jan 19 17:00:00 2009 Jussi Lehtola <jussi.lehtola at iki.fi> - 4.0.3-2
- Fix EPEL 4 build.

* Mon Jan 19 17:00:00 2009 Jussi Lehtola <jussi.lehtola at iki.fi> - 4.0.3-1
- Update to 4.0.3.


gsl-1.12-1.fc11
---------------
* Mon Jan 19 17:00:00 2009 Ivana Varekova <varekova at redhat.com> - 1.12-1
- update to 1.12


gtk-xfce-engine-2.5.93-1.fc11
-----------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 2.5.93-1
- Update to 2.5.93

* Sun Dec 28 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 2.5.92-1
- Update to 2.5.92


gtk2-2.15.0-2.fc11
------------------
* Mon Jan 19 17:00:00 2009 Marek Kasik <mkasik at redhat.com> - 2.15.0-2
- fix a problem with default printer in a network
- Resolves: #478400


gtkhtml3-3.25.5-1.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 3.25.5-1.fc11
- Update to 3.25.5
- Bump gtk2_version to 2.14.0


gyachi-1.1.61-3.fc11
--------------------
* Mon Jan 19 17:00:00 2009 Gregory D Hosler <ghosler at users.sourceforge.net> - 1.1.61.3
- change plugin Obsoletes


initscripts-8.87-1
------------------
* Mon Jan 19 17:00:00 2009 Bill Nottingham <notting at redhat.com> - 8.87-1
- rename_device: be much faster in the presence of many devices (#480687, <danms at us.ibm.com>)
- fix switching from targeted to MLS policy (#479054, <dwalsh at redhat.com>)
- rc.sysinit: don't set $(uname -r) or $(uname -m); they're not used
- network-functions-ipv6: set MTU correctly for 6to4. (#477976, <ackistler at yahoo.com>)
- add more entries to rwtab (#476799, <harald at redhat.com>)
- net.hotplug: Bail out sooner if the network service isn't running
- init.d/halt: determine reboot/halt via existing INIT_HALT environment variable. (#475227)
- event.d/serial: add some docs
- init.d/functions: __pids_var_run: Handle multi-line pid files correctly (#473287)
- remove support for no longer existing 'brctl setgcint' command. (#360471)
- add %config back for ifcfg-lo (#472761)
- rcS/rcS-sulogin: don't match commented lines when finding runlevel (#472717)
- updated translations: de, sk


iok-1.2.0-2.fc11
----------------
* Tue Jan 20 17:00:00 2009 Parag Nemade <panemade at gmail.com>- 1.2.0-2
- Resolves: rh#480289


iproute-2.6.28-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 2.6.28-1
- previous two patches were included into 2.6.28 release.
- update


iptstate-2.2.1-4.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Thomas Woerner <twoerner at redhat.com> 2.2.1-4
- merge review (rhbz#225908)


isdn4k-utils-3.2-62.fc11
------------------------
* Mon Jan 19 17:00:00 2009 Than Ngo <than at redhat.com> - 3.2-62
- fix #398121, capiplugin.so uses non-existent libcapi20.so
- fix CAPI overflow
- fix #471712, add sh architecture support

* Mon Oct 27 18:00:00 2008 Than Ngo <than at redhat.com> 3.2-61
- bz450370, fix multilib issue


isync-1.0.4-3.fc11
------------------
* Mon Jan 19 17:00:00 2009 Fabian Affolter <fabian at bernewireless.net> 1.0.4-3
- Preserved time stamps
- Fixed encoding error


jabbim-0.5-0.2.svn20090119.fc11
-------------------------------
* Mon Jan 19 17:00:00 2009 Michal Schmidt <mschmidt at redhat.com> - 0.5-0.2.svn20090119
- Removed our jabbim.in, already upstream.


jd-2.2.0-0.1.svn2631_trunk.fc11
-------------------------------
* Tue Jan 20 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2631


kdebase-workspace-4.1.96-4.fc11
-------------------------------
* Fri Jan 16 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-4
- backport fix from trunk to allow symlinks in wallpaper theme


kdesdk-4.1.96-4.fc11
--------------------
* Mon Jan 19 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-4
- apply patch to fix  build against Boost 1.37.0


kernel-2.6.29-0.43.rc2.git1.fc11
--------------------------------
* Mon Jan 19 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- execshield fixes: should no longer generate spurious handled GPFs,
  fixes randomization of executables. also some clean ups.

* Sat Jan 17 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc2-git1


liberation-fonts-1.04.93-5.fc11
-------------------------------
* Tue Jan 20 17:00:00 2009 Caius Chance <cchance at redhat.com> - 1.04.93-5.fc11
- Resolved: rhbz#477410
- Refined .spec file based on Mailhot's review on rhbz.

* Mon Jan 19 17:00:00 2009 Caius Chance <cchance at redhat.com> - 1.04.93-4.fc11
- Resolves: thbz#477410
- Package renaming for post-1.13 fontpackages macros.


libnfnetlink-0.0.40-1.fc11
--------------------------
* Mon Jan 19 17:00:00 2009 Paul P. Komkoff Jr <i at stingr.net> - 0.0.40-1
- upstream release


libxfce4util-4.5.93-1.fc11
--------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sun Dec 21 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


libxfcegui4-4.5.93-1.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sun Dec 21 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


livecd-tools-021-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Jeremy Katz <katzj at redhat.com> - 021-1
- Start of support for hybrid GPT/MBR usb sticks (Stewart Adam)
- Fix for udev deprecated syntax (#480109)
- Keep cache with --cache (Jan Kratochvil, #479716)
- Use absolute path to cachedir (#479716)
- Support UDF for large ISO spins (Bruno Wolf, #476696)
- Improvements for encrypted /home setup (mdomsch, #475399)
- Don't allow spaces in labels (#475834)
- Fix --tmpdir relative path (dhuff)
- Support ext4 rootfs
- Fix device command version check (apevec)
- Allow URLs for specifying the kickstart config (bkearney)
- Fix macro name for excludedocs (bkearney)
- Fix up --base-on (#471656)


mgopen-fonts-0.20050515-10.fc11
-------------------------------
* Mon Jan 19 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-9
- Rename subpackages according to 
  http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2009-01-13)
- Differentiate between macro and variable (fontconf->fconf)


mingw32-zlib-1.2.3-12.fc11
--------------------------
* Mon Jan 19 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 1.2.3-12
- Force rebuild to test maintenance account.


mkinitrd-6.0.75-1.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Jeremy Katz <katzj at redhat.com> - 6.0.75-1
- fix live images to be smarter with rootfstype=auto


mkvtoolnix-2.4.2-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Dominik Mierzejewski <rpm at greysector.net> 2.4.2-1
- updated to 2.4.2
- dropped obsolete boost detection patch
- fixed segmentation fault in mmg (bug #477857)
- backported some minor fixes from current git
- fixed build on ppc64 again


neon-0.28.3-3
-------------
* Mon Jan 19 17:00:00 2009 Joe Orton <jorton at redhat.com> 0.28.3-3
- use install-p in "make install" (Robert Scheck, #226189)


netpbm-10.35.58-1.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 10.35.58-1
- update to 10.35.38
- fixes crashes in picttoppm, pbmtomrf, mrftopbm
- fixes bugs in leaftoppm, ilbmtoppm


openoffice.org-3.0.1-15.2.fc11
------------------------------
* Mon Jan 19 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-15.2
- Resolves: rhbz#479624 add
  openoffice.org-3.0.1.ooo98024.vcl.emboldenoverlap.patch
- add hyphen-uk, hyphen-pt, mythes-el, mythes-fr dependency
- Resolves: rhbz#479163 add
  openoffice.org-3.0.1.oooXXXXX.fpicker.allformatsonsave.patch
- Resolves: rhbz#480117 workspace.fwk99.patch
- Resolves: rhbz#480121 add
  openoffice.org-3.1.0.ooo98137.filter.redeclared-variables.patch
- merge openoffice.org-3.0.0.ooo96391.sw.prefsalwaysmodified.patch into
  upstream workspace.sw31bf02.patch
- Resolves: rhbz#477435 font making macro changed


orage-4.5.93-1.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sun Dec 28 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92

* Mon Oct 27 18:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-1
- Update to 4.4.3
- BuildRequire intltool
- No longer BuildRequire dbh-devel
- Configure with --disable-static
- Update gtk-update-icon-cache scriptlets


pam-1.0.90-2.fc11
-----------------
* Mon Jan 19 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.0.90-2
- add helper to pam_mkhomedir for proper SELinux confinement (#476784)


pax-3.4-8.fc11
--------------
* Mon Jan 19 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 3.4-8
- Merge review #226235: fix use of %makeinstall as well

* Mon Jan 19 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> - 3.4-7
- Merge review #226235: do ship doc files,
  do comment patches, use better buildroot and
  defaults for attributes, allow parallel builds


pdns-2.9.22-1.rc3.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.9.22-1.rc3
- New release candidate


perl-5.10.0-54.fc11
-------------------
* Mon Jan 19 17:00:00 2009 Marcela Ma??l????ov?? <mmaslano at redhat.com> - 4:5.10.0-54
- 455410 http://rt.perl.org/rt3/Public/Bug/Display.html?id=54934
  Attempt to free unreferenced scalar fiddling with the symbol table
  Keep the refcount of the globs generated by PerlIO::via balanced.


perl-ExtUtils-PkgConfig-1.12-1.fc11
-----------------------------------
* Mon Jan 19 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.12-1
- Upstream update.


perl-Set-Scalar-1.23-1.fc11
---------------------------
* Mon Jan 19 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.23-1
- Upstream update.


perl-Test-File-1.25-1.fc11
--------------------------
* Tue Jan 20 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.25-1
- Upstream update.


perl-mogilefs-server-2.30-1.fc11
--------------------------------
* Mon Jan 19 17:00:00 2009 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.30-1
- Upstream released new version


phpMyAdmin-3.1.2-1.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 3.1.2-1
- Upstream released 3.1.2


pyke-0.7-1.fc11
---------------
* Mon Jan 19 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 0.7-1
- update to 0.7


pympdtouchgui-0.309-1.fc11
--------------------------
* Mon Jan 19 17:00:00 2009 Sven Lankes <sven at lank.es> - 0.309-1
- new upstream release


python-pyblock-0.33-1.fc11
--------------------------
* Mon Jan 19 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> - 0.33-1
- Allow use as non root (for pychecker)
- Forward port: "ERROR: only one argument allowed for this option"
  workaround from RHEL-5 (#468649, #474399)


rcssserver3d-0.6-7.fc11
-----------------------
* Wed Jan 14 17:00:00 2009 Hedayat Vatankhah <hedayat at grad.com> 0.6-7
- Removing VeraMono.ttf from the package because of new Fedora font guidelines.
- Adding dejavu-fonts-sans-mono as a requirement for VeraMono.ttf replacement.


rhythmbox-0.11.6-22.r6096.fc11
------------------------------
* Mon Jan 19 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.11.6-22.r6096
- Backport patch to fix avahi assertion in DAAP plugin.


rrdtool-1.3.6-1.fc11
--------------------
* Mon Jan 19 17:00:00 2009 Jarod Wilson <jarod at redhat.com> 1.3.6-1
- Update to rrdtool 1.3.6


selinux-policy-3.6.3-1.fc11
---------------------------
* Mon Jan 19 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-1
- Update to upstream

* Thu Jan 15 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.2-5
- Define openoffice as an x_domain


setroubleshoot-2.1.1-1.fc11
---------------------------
* Fri Jan 16 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.1.1-1
- Switch to C Based applet
- Use dbus for messaging.  Only run setroubleshoot when


shadow-utils-4.1.2-11.fc11
--------------------------
* Mon Jan 19 17:00:00 2009 Peter Vrabec <pvrabec at redhat.com> 2:4.1.2-11
- fix license tag (#226416)
- get rid of tabs in spec file (#226416)
- convert HOWTO to UTF8 (#226416)


specto-0.3-0.1.rc1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Xavier Lamien <lxtnow at gmail.com> - 0.3-0.1.rc1
- Update release.


tangogps-0.9.5-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> 0.9.5-1
- New upstream release


vodovod-1.10r19-3.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Karel Volny <kvolny at redhat.com> 1.10r19-3
- Required font package got renamed to dejavu-sans-mono-fonts (bug #480478)


wireshark-1.1.2-0.pre1.fc11
---------------------------
* Mon Jan 19 17:00:00 2009 Radek Vokal <rvokal at redhat.com> - 1.1.2-0.pre1
- upgrade to latest development release
- added support for portaudio (#480195)


xfce-utils-4.5.93-1.fc11
------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sat Dec 27 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfce4-appfinder-4.5.93-1.fc11
-----------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Tue Dec 23 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfce4-battery-plugin-0.5.1-2.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <fedora christoph-wickert de> - 0.5.1-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-clipman-plugin-0.9.0-1.fc11
---------------------------------
* Mon Jan 19 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.9.0-2
- Update to 0.9.0
- Update license tag to GPLv2+

* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.8.1-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-cpugraph-plugin-0.4.0-4.fc11
----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <fedora christoph-wickert de> - 0.4.0-4
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-datetime-plugin-0.6.1-2.fc11
----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.6.1-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-dev-tools-4.5.93-1.fc11
-----------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sun Dec 28 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfce4-dict-0.5.2-2.fc11
-----------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.2-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-diskperf-plugin-2.2.0-2.fc11
----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 2.2.0-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-eyes-plugin-4.4.0-5.fc11
------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.0-5
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-fsguard-plugin-0.4.2-2.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.4.2-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-genmon-plugin-3.2-2.fc11
------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 3.2-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-mailwatch-plugin-1.1.0-2.fc11
-----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 1.1.0-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-mixer-4.5.93-1.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sat Dec 27 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92

* Sat Nov 15 17:00:00 2008 Christoph Wickert <cwickert at fedoraproject.org> - 4.4.3-2
- Fix desktop file (bugzilla.xfce.org #4538)


xfce4-modemlights-plugin-0.1.3.99-3.fc11
----------------------------------------

xfce4-mount-plugin-0.5.5-2.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.5-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-mpc-plugin-0.3.3-2.fc11
-----------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.3.3-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-netload-plugin-0.4.0-8.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.4.0-8
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-notes-plugin-1.6.3-2.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 1.6.3-2
- Rebuild for Xfce 4.6 (Beta 3)
- Enable Xfconf settings dialog


xfce4-panel-4.5.93-1.fc11
-------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sat Dec 27 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfce4-places-plugin-1.1.0-4.fc11
--------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 1.1.0-4
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-quicklauncher-plugin-1.9.4-3.fc11
---------------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 1.9.4-3
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-screenshooter-1.5.0-1.fc11
--------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 1.5.0-1
- Update to 1.5.0 on Xfce 4.5.93.


xfce4-sensors-plugin-0.10.99.6-2.fc11
-------------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.10.99.6-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-session-4.5.93-1.fc11
---------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Fri Dec 26 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update 4.5.92


xfce4-smartbookmark-plugin-0.4.2-7.fc11
---------------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.4.2-7
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-systemload-plugin-0.4.2-5.fc11
------------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.4.2-5
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-time-out-plugin-0.1.1-2.fc11
----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.1.1-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-timer-plugin-0.6.1-2.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.6.1-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-verve-plugin-0.3.6-2.fc11
-------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.3.6-2
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-volstatus-icon-0.1.0-4.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.1.0-4
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-wavelan-plugin-0.5.4-5.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.4-5
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-weather-plugin-0.6.2-4.fc11
---------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.6.2-4
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-websearch-plugin-0.1.1-0.9.20070428svn2704.fc11
-----------------------------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.1.1-0.9.20070428svn2704
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-xfapplet-plugin-0.1.0-7.fc11
----------------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.1.0-7
- Rebuild for Xfce 4.6 (Beta 3)


xfce4-xkb-plugin-0.5.2-2.fc11
-----------------------------
* Sun Jan 18 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.5.2-2
- Rebuild for Xfce 4.6 (Beta 3)


xfdesktop-4.5.93-1.fc11
-----------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sun Dec 28 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update 4.5.92


xfprint-4.5.93-1.fc11
---------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sat Dec 27 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfwm4-4.5.93-1.fc11
-------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Sat Dec 27 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


xfwm4-themes-4.5.93-1.fc11
--------------------------
* Tue Jan 13 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 4.5.93-1
- Update to 4.5.93

* Mon Dec 29 17:00:00 2008 Kevin Fenzi <kevin at tummy.com> - 4.5.92-1
- Update to 4.5.92


Summary:
Added Packages: 11
Removed Packages: 0
Modified Packages: 119
Broken deps for i386
----------------------------------------------------------
	baekmuk-ttf-batang-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-dotum-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-gulim-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-hline-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	liberation-mono-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-sans-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-serif-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	1:openoffice.org-core-3.0.1-15.2.fc11.i386 requires openoffice.org-fonts
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	pygsl-0.9.3-2.fc11.i386 requires gsl = 0:1.11
	pygsl-devel-0.9.3-2.fc11.i386 requires gsl-devel = 0:1.11
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	baekmuk-ttf-batang-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-dotum-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-gulim-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-hline-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	httrack-3.42.93-1.fc10.i386 requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.x86_64 requires openssl = 0:0.9.8g
	liberation-mono-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-sans-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-serif-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	1:openoffice.org-core-3.0.1-15.2.fc11.x86_64 requires openoffice.org-fonts
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	pygsl-0.9.3-2.fc11.x86_64 requires gsl = 0:1.11
	pygsl-devel-0.9.3-2.fc11.i386 requires gsl-devel = 0:1.11
	pygsl-devel-0.9.3-2.fc11.x86_64 requires gsl-devel = 0:1.11
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	baekmuk-ttf-batang-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-dotum-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-gulim-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-hline-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	httrack-3.42.93-1.fc10.ppc requires openssl = 0:0.9.8g
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	liberation-mono-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-sans-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-serif-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	1:openoffice.org-core-3.0.1-15.2.fc11.ppc requires openoffice.org-fonts
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	pygsl-0.9.3-2.fc11.ppc requires gsl = 0:1.11
	pygsl-devel-0.9.3-2.fc11.ppc requires gsl-devel = 0:1.11
	pygsl-devel-0.9.3-2.fc11.ppc64 requires gsl-devel = 0:1.11
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	baekmuk-ttf-batang-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-dotum-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-gulim-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	baekmuk-ttf-hline-fonts-2.2-14.fc11.noarch requires baekmuk-ttf-common-fonts = 0:2.2-14.fc11
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	httrack-3.42.93-1.fc10.ppc64 requires openssl = 0:0.9.8g
	liberation-mono-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-sans-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	liberation-serif-fonts-1.04.93-5.fc11.noarch requires liberation-common-fonts = 0:1.04.93-5.fc11
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	1:openoffice.org-core-3.0.1-15.2.fc11.ppc64 requires openoffice.org-fonts
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	pygsl-0.9.3-2.fc11.ppc64 requires gsl = 0:1.11
	pygsl-devel-0.9.3-2.fc11.ppc64 requires gsl-devel = 0:1.11
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From nicolas.mailhot at laposte.net  Tue Jan 20 08:33:01 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 20 Jan 2009 09:33:01 +0100 (CET)
Subject: ibus and F11
In-Reply-To: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.p
	hx2.redhat.com>
References: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <2d72ba62f03be5c2f6876a39eecdf5bc.squirrel@arekh.dyndns.org>



Le Mar 20 janvier 2009 08:05, Jens Petersen a ?crit :

> Yep, ibus supports Ctrl+Space for toggling by default just like scim.

BTW: this will conflict with some XKB layouts, and some apps. This
needs to be configurable (a successful im switcher would merge with
the gnome xkb keyboard switching applet and keep all its useful
features)

-- 
Nicolas Mailhot



From joshuacov at googlemail.com  Tue Jan 20 08:39:20 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Tue, 20 Jan 2009 09:39:20 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <200901191607.50904.sgrubb@redhat.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>
	<200901191606.26716.sgrubb@redhat.com>
	<200901191607.50904.sgrubb@redhat.com>
Message-ID: <5f6f8c5f0901200039n79291218jc204e8a865991ac3@mail.gmail.com>

2009/1/19 Steve Grubb <sgrubb at redhat.com>:
> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>> chattr -i  ./foo
>
> whoops...actually, chattr +i ./foo
>
> -Steve
>


This is what I want. Thanx.

But as I said earlier I had the impression that changing the owner to
root and settting the files in 444 mode would do the work. Back then
when I created those files I tried deleting them and I couldn't.
Therefore I thought it's sufficient. Maybe there was something else
that I did then and cann't remember now?



From wolfy at nobugconsulting.ro  Tue Jan 20 08:51:07 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Tue, 20 Jan 2009 10:51:07 +0200
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901200039n79291218jc204e8a865991ac3@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>	<200901191606.26716.sgrubb@redhat.com>	<200901191607.50904.sgrubb@redhat.com>
	<5f6f8c5f0901200039n79291218jc204e8a865991ac3@mail.gmail.com>
Message-ID: <4975907B.4050607@nobugconsulting.ro>

Joshua C. wrote:
> 2009/1/19 Steve Grubb <sgrubb at redhat.com>:
>   
>> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>>     
>>> chattr -i  ./foo
>>>       
>> whoops...actually, chattr +i ./foo
>>
>> -Steve
>>
>>     
>
>
> This is what I want. Thanx.
>
> But as I said earlier I had the impression that changing the owner to
> root and settting the files in 444 mode would do the work. Back then
> when I created those files I tried deleting them and I couldn't.
> Therefore I thought it's sufficient. Maybe there was something else
> that I did then and cann't remember now?
>   
No, the behaviour that was already described by several posters (and 
that you have seen before posting here) is the one implemented by any 
Unix since the 60's. You should read the documentation related to file 
permission in Unix and think about what each command does and what part 
of the filesystem is involved. Basically the directories are files and 
the permissions and copy/move/delete operations affect the content of 
the "directory files" and therefore it is done according to the 
permissions *of the directory*. Reading the content of a specific file 
is subject to the access rights related *to the file.*

chattr use extended attributes and is specific to extNfs. a nice other 
tool still using extended attributes is setfacl.



From singularitaet at gmx.net  Tue Jan 20 09:30:26 2009
From: singularitaet at gmx.net (Stefan Grosse)
Date: Tue, 20 Jan 2009 10:30:26 +0100
Subject: TeXlive 2008 in Fedora 11?
Message-ID: <497599B2.6030203@gmx.net>

Hi,

are there any plans for updating texlive to 2008 in Leonidas?

Stefan



From jiteshs at marvell.com  Tue Jan 20 09:32:57 2009
From: jiteshs at marvell.com (Jitesh Shah)
Date: Tue, 20 Jan 2009 15:02:57 +0530
Subject: Koji: ServerOffline
Message-ID: <1232443977.9222.11.camel@localhost.localdomain>

Hi,
I have a koji server running locally at my workplace. 
Recently, I am unable to execute any koji cli command (or I am unable to
access the web interface too, for that matter). I get the following
error:

"[kojiadmin at linux-dev koji]$ koji list-tags
ServerOffline: database outage"

Wireshark shows that the very first xmlrpc call "getAPIVersion" fails
with this error. I couldn't find any logs for koji. 
I can still access the database through commandline and the database is
intact. The role "kojiadmin" exists and has all the proper permissions
(koji was working!.. so, the setup is good)

Any pointers??

(Note: Please redirect me to the proper list if this isn't the one. Its
just that I couldn't find any other lists discussing koji :) )

Jitesh



From petersen at redhat.com  Tue Jan 20 09:35:20 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 04:35:20 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <2d72ba62f03be5c2f6876a39eecdf5bc.squirrel@arekh.dyndns.org>
Message-ID: <2529758.380751232444120818.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Nicolas Mailhot" <nicolas.mailhot at laposte.net> wrote:
> BTW: this will conflict with some XKB layouts, and some apps. This
> needs to be configurable (a successful im switcher would merge with
> the gnome xkb keyboard switching applet and keep all its useful
> features)

It is already configurable so no regression, but yes we want tighter desktop integration for configuration and xkb.

Jens



From petersen at redhat.com  Tue Jan 20 09:37:01 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 04:37:01 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <1232433537.30871.50.camel@ignacio.lan>
Message-ID: <1545901440.381251232444221653.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Ignacio Vazquez-Abrams" <ivazqueznet at gmail.com> wrote:
> Yes, although switching between hiragana and katakana is not as easy yet.

Adding hotkeys for ibus-anthy modes is on the todo list.



From laxathom at fedoraproject.org  Tue Jan 20 09:48:59 2009
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Tue, 20 Jan 2009 10:48:59 +0100
Subject: Koji: ServerOffline
In-Reply-To: <1232443977.9222.11.camel@localhost.localdomain>
References: <1232443977.9222.11.camel@localhost.localdomain>
Message-ID: <62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>

On Tue, Jan 20, 2009 at 10:32 AM, Jitesh Shah <jiteshs at marvell.com> wrote:
> Hi,
> I have a koji server running locally at my workplace.
> Recently, I am unable to execute any koji cli command (or I am unable to
> access the web interface too, for that matter). I get the following
> error:
>
> "[kojiadmin at linux-dev koji]$ koji list-tags
> ServerOffline: database outage"

that means koji can't connect to its database to fetch requested information.
Also , check your koji-hub eta


-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From jiteshs at marvell.com  Tue Jan 20 10:09:20 2009
From: jiteshs at marvell.com (Jitesh Shah)
Date: Tue, 20 Jan 2009 15:39:20 +0530
Subject: Koji: ServerOffline
In-Reply-To: <62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
Message-ID: <1232446160.9222.20.camel@localhost.localdomain>

Hi,
Yes, I have already double-checked my koji-hub configuration. Both the
DBUser and DBName are correct. Infact, I had been running koji here for
more than a fortnight and it worked like a charm. 

Also, I can connect with to the psql database using the same values as
in DBName and DBUser variables through commandline. So, what might cause
the failure when invoked through python scripts?

Jitesh

On Tue, 2009-01-20 at 10:48 +0100, Xavier Lamien wrote:
> On Tue, Jan 20, 2009 at 10:32 AM, Jitesh Shah <jiteshs at marvell.com> wrote:
> > Hi,
> > I have a koji server running locally at my workplace.
> > Recently, I am unable to execute any koji cli command (or I am unable to
> > access the web interface too, for that matter). I get the following
> > error:
> >
> > "[kojiadmin at linux-dev koji]$ koji list-tags
> > ServerOffline: database outage"
> 
> that means koji can't connect to its database to fetch requested information.
> Also , check your koji-hub eta
> 
> 
> -- 
> Xavier.t Lamien
> --
> http://fedoraproject.org/wiki/XavierLamien
> GPG-Key ID: F3903DEB
> Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
> 



From petersen at redhat.com  Tue Jan 20 10:25:31 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 05:25:31 -0500 (EST)
Subject: Fedora I18n project meeting
In-Reply-To: <484617957.382511232445483125.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <2023807288.383841232447131742.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

The log of today's fedora-i81n meeting is now on

https://fedoraproject.org/wiki/I18N/Meetings/2009-01-20

if you missed it.

Thanks, Jens



From laxathom at fedoraproject.org  Tue Jan 20 10:26:37 2009
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Tue, 20 Jan 2009 11:26:37 +0100
Subject: Koji: ServerOffline
In-Reply-To: <1232446160.9222.20.camel@localhost.localdomain>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
	<1232446160.9222.20.camel@localhost.localdomain>
Message-ID: <62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>

On Tue, Jan 20, 2009 at 11:09 AM, Jitesh Shah <jiteshs at marvell.com> wrote:
> Hi,
> Yes, I have already double-checked my koji-hub configuration. Both the
> DBUser and DBName are correct. Infact, I had been running koji here for
> more than a fortnight and it worked like a charm.

did you do any update since ?

>
> Also, I can connect with to the psql database using the same values as
> in DBName and DBUser variables through commandline. So, what might cause
> the failure when invoked through python scripts?

Do you also tried to figure out what happen in the DB side when
invoked your cmd-line ?



-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From rjones at redhat.com  Tue Jan 20 10:36:36 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 20 Jan 2009 10:36:36 +0000
Subject: Bodhi F-10 push problem
Message-ID: <20090120103636.GA24055@amd.home.annexia.org>


How often do Bodhi rebuilds happen?  In this case I've been waiting
for some packages to be pushed to F-10 stable since Saturday:

https://admin.fedoraproject.org/updates/mingw32-readline-5.2-4.fc10
https://admin.fedoraproject.org/updates/mingw32-gettext-0.17-7.fc10
https://admin.fedoraproject.org/updates/mingw32-gdbm-1.8.0-1.fc10
https://admin.fedoraproject.org/updates/mingw32-dlfcn-0-0.3.r11.fc10
https://admin.fedoraproject.org/updates/mingw32-pdcurses-3.4-3.fc10

A related question is, can I build another package against these
packages even if they are not yet pushed?  (Well, it seems that plain
'make build' doesn't work - is there some other way?)

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 kzak at redhat.com  Tue Jan 20 10:39:09 2009
From: kzak at redhat.com (Karel Zak)
Date: Tue, 20 Jan 2009 11:39:09 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
	server?
In-Reply-To: <1232381350.3539.42.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<1232224197.3539.15.camel@localhost.localdomain>
	<4974894B.1070100@RedHat.com>
	<1232381350.3539.42.camel@localhost.localdomain>
Message-ID: <20090120103908.GA2968@nb.net.home>

On Mon, Jan 19, 2009 at 08:09:10AM -0800, Jesse Keating wrote:
> On Mon, 2009-01-19 at 09:08 -0500, Steve Dickson wrote:
> >  Through some side bar discussion it been suggested an update to
> > the man page is probably need (which I agree) and maybe a flag
> > of some sort to allow unknown IP address access. I must admit, I'm
> > a bit hesitant to do the later, since I don't think its a good idea
> > to allow unknown client access any system daemon... 
> 
> That kind of interferes with testing environments and home environments.
> Requiring the setup of a dns server just to be able to use NFS is pretty
> damn lame.

 +1, there should be a way how to disable this "feature". I remember
 BZ reports from customers who use clusters without a DNS servers at
 all. In some cases, the translation from IP to host is an extra step
 only.

    Karel

-- 
 Karel Zak  <kzak at redhat.com>



From pbrobinson at gmail.com  Tue Jan 20 10:42:18 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 20 Jan 2009 11:42:18 +0100
Subject: Bodhi F-10 push problem
In-Reply-To: <20090120103636.GA24055@amd.home.annexia.org>
References: <20090120103636.GA24055@amd.home.annexia.org>
Message-ID: <5256d0b0901200242t4f88fbd1i91e2fab98c193d55@mail.gmail.com>

> How often do Bodhi rebuilds happen?  In this case I've been waiting
> for some packages to be pushed to F-10 stable since Saturday:
>
> https://admin.fedoraproject.org/updates/mingw32-readline-5.2-4.fc10
> https://admin.fedoraproject.org/updates/mingw32-gettext-0.17-7.fc10
> https://admin.fedoraproject.org/updates/mingw32-gdbm-1.8.0-1.fc10
> https://admin.fedoraproject.org/updates/mingw32-dlfcn-0-0.3.r11.fc10
> https://admin.fedoraproject.org/updates/mingw32-pdcurses-3.4-3.fc10
>
> A related question is, can I build another package against these
> packages even if they are not yet pushed?  (Well, it seems that plain
> 'make build' doesn't work - is there some other way?)

I'm not sure how often the admins push the updates from bodhi but I
think it still needs to be done manually due to package signing
requirements.

Peter



From jiteshs at marvell.com  Tue Jan 20 11:05:36 2009
From: jiteshs at marvell.com (Jitesh Shah)
Date: Tue, 20 Jan 2009 16:35:36 +0530
Subject: Koji: ServerOffline
In-Reply-To: <62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
	<1232446160.9222.20.camel@localhost.localdomain>
	<62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>
Message-ID: <1232449536.9222.30.camel@localhost.localdomain>



On Tue, 2009-01-20 at 11:26 +0100, Xavier Lamien wrote:
> On Tue, Jan 20, 2009 at 11:09 AM, Jitesh Shah <jiteshs at marvell.com> wrote:
> > Hi,
> > Yes, I have already double-checked my koji-hub configuration. Both the
> > DBUser and DBName are correct. Infact, I had been running koji here for
> > more than a fortnight and it worked like a charm.
> 
> did you do any update since ?

Nope ... didn't update koji!
> 
> >
> > Also, I can connect with to the psql database using the same values as
> > in DBName and DBUser variables through commandline. So, what might cause
> > the failure when invoked through python scripts?
> 
> Do you also tried to figure out what happen in the DB side when
> invoked your cmd-line ?
> 

As I mentioned earlier, it works fine through commandline!

Update: 
I suspect that the issue is related to failed transactions. 
The file /usr/share/koji-hub/kojixmlrpc.py suggests that the
koji.db.connect fails. 
I had been running koji-shadow script and it failed mysteriously. I see
this "ServerOffline: Database outage" message from that point on. I
think the rollback() in koji.db.connect fails due to some not-yet-known
reason. I am looking into it further.

Jitesh



From bmr at redhat.com  Tue Jan 20 11:09:35 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Tue, 20 Jan 2009 11:09:35 +0000
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901200039n79291218jc204e8a865991ac3@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>	<5f6f8c5f0901191113r27b75347l95646eea68f2ddb7@mail.gmail.com>	<200901191606.26716.sgrubb@redhat.com>	<200901191607.50904.sgrubb@redhat.com>
	<5f6f8c5f0901200039n79291218jc204e8a865991ac3@mail.gmail.com>
Message-ID: <4975B0EF.9030401@redhat.com>

Joshua C. wrote:
> 2009/1/19 Steve Grubb <sgrubb at redhat.com>:
>> On Monday 19 January 2009 04:06:26 pm Steve Grubb wrote:
>>> chattr -i  ./foo
>> whoops...actually, chattr +i ./foo
>>
>> -Steve
>>
> 
> 
> This is what I want. Thanx.
> 
> But as I said earlier I had the impression that changing the owner to
> root and settting the files in 444 mode would do the work. Back then
> when I created those files I tried deleting them and I couldn't.
> Therefore I thought it's sufficient. Maybe there was something else
> that I did then and cann't remember now?

If this was the case then either the directory you had the files in 
had the sticky bit set (causes us to allow unlink/rename if the user 
is either the owner of the file, the owner of the containing 
directory, or root. Normally used on temporary directories) or 
something other than the kernel was preventing you deleting the files.

Regards,
Bryn.



From sgrubb at redhat.com  Tue Jan 20 11:44:51 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Tue, 20 Jan 2009 06:44:51 -0500
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <4974ECE5.3050206@nobugconsulting.ro>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<200901191607.50904.sgrubb@redhat.com>
	<4974ECE5.3050206@nobugconsulting.ro>
Message-ID: <200901200644.51574.sgrubb@redhat.com>

On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> actually after chattr +i not even root can modify / delete the file:

True. But you can chattr -i ./foo and then edit the file remembering to make 
it immutable again when you are done editing it. Not as automatic as one 
might like, but that's how to do it.

-Steve



From SteveD at redhat.com  Tue Jan 20 13:24:43 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 08:24:43 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <1232223817.3539.12.camel@localhost.localdomain>
References: <1232223817.3539.12.camel@localhost.localdomain>
Message-ID: <4975D09B.8050702@RedHat.com>

For those of you not following along in bz480420 or bz448898
There are two new nfs-utils builds that should restore the
use of non-resolvable IP addresses.

F9:
http://admin.fedoraproject.org/updates/nfs-utils-1.1.2-10.fc9

F10:
http://admin.fedoraproject.org/updates/nfs-utils-1.1.4-7.fc10

The builds are in testing, so as soon as I get some good karma
I'll move them to stable....

Please note, these changes were in rawhide and in testing 
since Dec 20 so I thought everything was ready to go (they
even got passed the davej testing! :-) ) 

Plus the man page clear states mountd "is protected by the 
tcp_wrapper library" which was broken and need to be fixed
(something the Red Hat security guys found).

In reality only a very small number of configurations did break 
from this change since it much more common to use resolvable 
address than not.

But any time a working configuration does break from an
update is not good... and need to avoid at all costs...

Believe me... your pain became my pain very quickly... as it should... 

Again, please give me some good karma by testing these
new builds.

tia,

steved.




From fedora at camperquake.de  Tue Jan 20 13:30:43 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Jan 2009 14:30:43 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <4975D09B.8050702@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<4975D09B.8050702@RedHat.com>
Message-ID: <20090120143043.3c50683b@dhcp03.addix.net>

Hi.

On Tue, 20 Jan 2009 08:24:43 -0500, Steve Dickson wrote:

> Plus the man page clear states mountd "is protected by the 
> tcp_wrapper library" which was broken and need to be fixed
> (something the Red Hat security guys found).

Maybe I'm alone in this, but this is the first that I've heard that
using tcp_wrappers equals 'does not work at all without reverse name
lookups', especially if there are no entries at all in hosts.allow
and hosts.deny.



From fedora at matbooth.co.uk  Tue Jan 20 14:29:18 2009
From: fedora at matbooth.co.uk (Mat Booth)
Date: Tue, 20 Jan 2009 14:29:18 +0000
Subject: Bodhi F-10 push problem
In-Reply-To: <20090120103636.GA24055@amd.home.annexia.org>
References: <20090120103636.GA24055@amd.home.annexia.org>
Message-ID: <9497e9990901200629p37de1355ib8f5fca8b484e208@mail.gmail.com>

On Tue, Jan 20, 2009 at 10:36 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>
> A related question is, can I build another package against these
> packages even if they are not yet pushed?  (Well, it seems that plain
> 'make build' doesn't work - is there some other way?)
>
> Rich.
>

I believe the Right Thing To Do(tm) is to raise a ticket against
releng, like these ones:

https://fedorahosted.org/rel-eng/search?q=tagging&noquickjump=1&ticket=on

-- 
Mat Booth
www.matbooth.co.uk



From pbrobinson at gmail.com  Tue Jan 20 14:55:10 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Tue, 20 Jan 2009 15:55:10 +0100
Subject: vala packaging guidelines?
Message-ID: <5256d0b0901200655r7aa489b2h2a81361b324919b4@mail.gmail.com>

Hi All,

I've got a query about vala based packages. It seems that there aren't
many (any) vala binding from what I can see in Fedora yet to use as
examples and I can't see any packaging guidelines for it [1]. My
understanding from the vala site [2] is that it actually generates
code which is C and its then compiled. So my query is regarding vala
bindings. The debuginfo package for my package [3] is empty but as
they're binding for code that will be generated into C I'm not sure
whether there would be or whether something else needs to be done as
well. Can someone advise whether there's more that needs to be done
wrt vala or whether rpmlint is confused by the difference (or more
likely its me that's confused!).

Cheers,
Peter

[1] https://fedoraproject.org/wiki/Packaging/Guidelines
[2] http://live.gnome.org/Vala/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=454668



From wtogami at redhat.com  Tue Jan 20 14:58:11 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 09:58:11 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975B412.9070509@RedHat.com>
References: <4975B412.9070509@RedHat.com>
Message-ID: <4975E683.9050801@redhat.com>

Steve Dickson wrote:
> Its been point out that if there are are no rules in either 
> /etc/hosts.deny or /etc/hosts.allow there is no need to do any
> validity checking on the incoming address.
> 
> Unfortunately there is no interface that will easily
> let me know if there are any rules so I simply read
> in both files looking for non-commented lines.
> 
> steved.

This means if somebody adds a tcp wrapper rule for something other than 
mountd, it still effects the behavior of mountd?  How does that make any 
sense?

Why do you not see that "deny on reverse DNS failure" is not mutually 
exclusive with "enable TCP wrappers"?  This is based upon a 
MISINTERPRETATION of how tcp wrappers should behave.  You are hard 
coding policy into nfs-utils.

All you need to do is make "deny on reverse DNS failure" disabled by 
default, and let the admin choose to enable it.  This would be simpler 
than your above imperfect hack as well as more correct.

Warren Togami
wtogami at redhat.com



From SteveD at redhat.com  Tue Jan 20 14:59:03 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 09:59:03 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <20090120143043.3c50683b@dhcp03.addix.net>
References: <1232223817.3539.12.camel@localhost.localdomain>	<4975D09B.8050702@RedHat.com>
	<20090120143043.3c50683b@dhcp03.addix.net>
Message-ID: <4975E6B7.2000005@RedHat.com>

Hey,

Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 20 Jan 2009 08:24:43 -0500, Steve Dickson wrote:
> 
>> Plus the man page clear states mountd "is protected by the 
>> tcp_wrapper library" which was broken and need to be fixed
>> (something the Red Hat security guys found).
> 
> Maybe I'm alone in this, but this is the first that I've heard that
> using tcp_wrappers equals 'does not work at all without reverse name
> lookups', especially if there are no entries at all in hosts.allow
> and hosts.deny.
> 
Maybe I misstated it... but in this particular usage of tcp wrappers
a reverse name lookup is required when one, there is an entry and 
two, that entry is a host name since there is only an IP address
to start with.

But I do agree, if there are no entries in either file, then
a reverse lookup is not needed... which was the bug... 

steved.



From fedora at camperquake.de  Tue Jan 20 15:04:51 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Jan 2009 16:04:51 +0100
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <4975E6B7.2000005@RedHat.com>
References: <1232223817.3539.12.camel@localhost.localdomain>
	<4975D09B.8050702@RedHat.com>
	<20090120143043.3c50683b@dhcp03.addix.net>
	<4975E6B7.2000005@RedHat.com>
Message-ID: <20090120160451.78e24fc2@dhcp03.addix.net>

Hi.

On Tue, 20 Jan 2009 09:59:03 -0500, Steve Dickson wrote:

> Maybe I misstated it... but in this particular usage of tcp wrappers
> a reverse name lookup is required when one, there is an entry and 
> two, that entry is a host name since there is only an IP address
> to start with.

So, if there is an entry, and it contains only IPs, a reverse lookup
is not required?



From SteveD at redhat.com  Tue Jan 20 15:06:05 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 10:06:05 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975E683.9050801@redhat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
Message-ID: <4975E85D.6030608@RedHat.com>



Warren Togami wrote:
> Steve Dickson wrote:
>> Its been point out that if there are are no rules in either
>> /etc/hosts.deny or /etc/hosts.allow there is no need to do any
>> validity checking on the incoming address.
>>
>> Unfortunately there is no interface that will easily
>> let me know if there are any rules so I simply read
>> in both files looking for non-commented lines.
>>
>> steved.
> 
> This means if somebody adds a tcp wrapper rule for something other than
> mountd, it still effects the behavior of mountd?  How does that make any
> sense?
Good point...

> 
> Why do you not see that "deny on reverse DNS failure" is not mutually
> exclusive with "enable TCP wrappers"?  This is based upon a
> MISINTERPRETATION of how tcp wrappers should behave.  You are hard
> coding policy into nfs-utils.
Please tell how I check a 'mountd: <hostname>' entry in the /etc/hosts.deny 
with only an IP address without doing a reverse name lookup?

> 
> All you need to do is make "deny on reverse DNS failure" disabled by
> default, and let the admin choose to enable it.  This would be simpler
> than your above imperfect hack as well as more correct.
This feels like a bit of hack as well... 

steved.



From wtogami at redhat.com  Tue Jan 20 15:09:18 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 10:09:18 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975E85D.6030608@RedHat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
	<4975E85D.6030608@RedHat.com>
Message-ID: <4975E91E.7080900@redhat.com>

Steve Dickson wrote:
>> Why do you not see that "deny on reverse DNS failure" is not mutually
>> exclusive with "enable TCP wrappers"?  This is based upon a
>> MISINTERPRETATION of how tcp wrappers should behave.  You are hard
>> coding policy into nfs-utils.
> Please tell how I check a 'mountd: <hostname>' entry in the /etc/hosts.deny 
> with only an IP address without doing a reverse name lookup?

I am not saying "without doing a reverse name lookup".  Just remove the 
hardcoded part that makes it fatal.

> 
>> All you need to do is make "deny on reverse DNS failure" disabled by
>> default, and let the admin choose to enable it.  This would be simpler
>> than your above imperfect hack as well as more correct.
> This feels like a bit of hack as well... 
> 

You hard coded policy.  How was that not a hack?

Warren Togami
wtogami at redhat.com



From SteveD at redhat.com  Tue Jan 20 15:10:30 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 10:10:30 -0500
Subject: Trying to debug nfs install issue, increase verbosity of nfs
 server?
In-Reply-To: <20090120160451.78e24fc2@dhcp03.addix.net>
References: <1232223817.3539.12.camel@localhost.localdomain>	<4975D09B.8050702@RedHat.com>	<20090120143043.3c50683b@dhcp03.addix.net>	<4975E6B7.2000005@RedHat.com>
	<20090120160451.78e24fc2@dhcp03.addix.net>
Message-ID: <4975E966.6040902@RedHat.com>



Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 20 Jan 2009 09:59:03 -0500, Steve Dickson wrote:
> 
>> Maybe I misstated it... but in this particular usage of tcp wrappers
>> a reverse name lookup is required when one, there is an entry and 
>> two, that entry is a host name since there is only an IP address
>> to start with.
> 
> So, if there is an entry, and it contains only IPs, a reverse lookup
> is not required?
Unfortunately the tcp wrapper code is that smart... If there is a
matching IP address in the /etc/hosts.allow file then a lookup 
is not needed. But if there isn't, then the /etc/hosts.deny has
to checked with the host name of the incoming IP address...

steved.



From SteveD at redhat.com  Tue Jan 20 15:14:59 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 10:14:59 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975E91E.7080900@redhat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
	<4975E85D.6030608@RedHat.com> <4975E91E.7080900@redhat.com>
Message-ID: <4975EA73.2060806@RedHat.com>



Warren Togami wrote:
> Steve Dickson wrote:
>>> Why do you not see that "deny on reverse DNS failure" is not mutually
>>> exclusive with "enable TCP wrappers"?  This is based upon a
>>> MISINTERPRETATION of how tcp wrappers should behave.  You are hard
>>> coding policy into nfs-utils.
>> Please tell how I check a 'mountd: <hostname>' entry in the
>> /etc/hosts.deny with only an IP address without doing a reverse name
>> lookup?
> 
> I am not saying "without doing a reverse name lookup".  Just remove the
> hardcoded part that makes it fatal.
which means the entry in /etc/hosts.deny will be ignored possibly allowing
access to machine that should be denied. 


steved.



From wtogami at redhat.com  Tue Jan 20 15:21:57 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 10:21:57 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975E85D.6030608@RedHat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
	<4975E85D.6030608@RedHat.com>
Message-ID: <4975EC15.8090009@redhat.com>

Jan 18 01:56:48 newcaprica useradd[15194]: failed adding user `rpcuser', 
data deleted

BTW, why does /var/log/messages have something like this every time the 
nfs-utils package is upgraded?

Warren



From fedora at camperquake.de  Tue Jan 20 15:22:48 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Jan 2009 16:22:48 +0100
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975E85D.6030608@RedHat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
	<4975E85D.6030608@RedHat.com>
Message-ID: <20090120162248.7045cd90@dhcp03.addix.net>

Hi.

On Tue, 20 Jan 2009 10:06:05 -0500, Steve Dickson wrote:

> Please tell how I check a 'mountd: <hostname>' entry in
> the /etc/hosts.deny with only an IP address without doing a reverse
> name lookup?

You can't, and no one is denying that as far as I can see. And I'd
actually consider this to be failing on the safe side.

But, given an entry in hosts.allow like this:

mountd: host.example.com 192.168.1.1

denying the ip 192.168.1.1 just because it does not have a hostname
associated with it would be just wrong.



From wtogami at redhat.com  Tue Jan 20 15:27:30 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 10:27:30 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975EA73.2060806@RedHat.com>
References: <4975B412.9070509@RedHat.com>
	<4975E683.9050801@redhat.com>	<4975E85D.6030608@RedHat.com>
	<4975E91E.7080900@redhat.com> <4975EA73.2060806@RedHat.com>
Message-ID: <4975ED62.3020106@redhat.com>

Steve Dickson wrote:
>> I am not saying "without doing a reverse name lookup".  Just remove the
>> hardcoded part that makes it fatal.
> which means the entry in /etc/hosts.deny will be ignored possibly allowing
> access to machine that should be denied. 
> 

Access control by hostname is highly imperfect and insecure to begin 
with.  Haven't we learned this from rsh?

How much sense does it make for someone to add every possible hostname 
to deny in /etc/hosts.deny?  If they want to limit access via tcp 
wrappers, they would instead mountd: * in /etc/hosts.deny and add 
specific hosts to /etc/hosts.allow.

We need to accept that tcp wrappers is insecure (easy to spoof, 
unencrypted) and thus imperfect.  Stop trying to add hacks to shine up 
this turd.  What other services impose such a denial by default due to 
tcp wrappers?  This is simply a bad idea.

Warren Togami
wtogami at redhat.com



From dominik at greysector.net  Tue Jan 20 15:30:53 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Tue, 20 Jan 2009 16:30:53 +0100
Subject: ibus and F11
In-Reply-To: <374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <511187499.336701232409913305.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <20090120153053.GC14182@mokona.greysector.net>

On Tuesday, 20 January 2009 at 01:06, Jens Petersen wrote:
> ----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> > What's the migration path for SCIM users?
> 
> Users upgrading from earlier Fedora releases can continue to use scim
> or if they wish they can install ibus themselves and use that.  Scim
> will be continue to be in Fedora for the time being.

But if I install ibus, I'll have to configure it from scratch, right?
There is no settings migration from SCIM, is there?

> > Can I define my own shortcuts for switching IMs, like in SCIM?
> 
> Yep, you can in ibus-setup.  Right click on ibus icon and select Preferences.
> 
> > Is there an applet for showing currently selected IM, like in SCIM?
> 
> Yes, there is.
> 
> 
> You can already install and test ibus today if you are running F9, F10,
> or rawhide:
> 
> Install your favourite engine with:
> 
>  sudo yum install ibus-<engine> ibus-gtk
> 
> where <engine> is one of anthy, chewing, hangul, m17n, pinyin,
> table-chinese, etc.  Install ibus-qt if you need support
> for Qt and KDE.

Thanks for the answers, I'll try to test it before beta.

Regards,
R.

PS. Please break your lines around 70th column and please don't Cc: me with
on-list replies.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From SteveD at redhat.com  Tue Jan 20 15:30:43 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 10:30:43 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <20090120162248.7045cd90@dhcp03.addix.net>
References: <4975B412.9070509@RedHat.com>
	<4975E683.9050801@redhat.com>	<4975E85D.6030608@RedHat.com>
	<20090120162248.7045cd90@dhcp03.addix.net>
Message-ID: <4975EE23.6050005@RedHat.com>



Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 20 Jan 2009 10:06:05 -0500, Steve Dickson wrote:
> 
>> Please tell how I check a 'mountd: <hostname>' entry in
>> the /etc/hosts.deny with only an IP address without doing a reverse
>> name lookup?
> 
> You can't, and no one is denying that as far as I can see. And I'd
> actually consider this to be failing on the safe side.
> 
> But, given an entry in hosts.allow like this:
> 
> mountd: host.example.com 192.168.1.1
> 
> denying the ip 192.168.1.1 just because it does not have a hostname
> associated with it would be just wrong.
Remember I said _matching_ IP... meaning if the above line
was in hosts.allow and client 192.168.1.1 did a mount
the client would be allow the mount without doing a lookup 
because there was a matching IP address entry... 

Now if client 192.168.1.2 did a mount, there would not be a 
IP matching entry in hosts.allow so a lookup would be necessary
to see if a 'mountd: <hostname>' exists in hosts.deny. 

Is that making sense? 

steved.



From SteveD at redhat.com  Tue Jan 20 15:35:31 2009
From: SteveD at redhat.com (Steve Dickson)
Date: Tue, 20 Jan 2009 10:35:31 -0500
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975ED62.3020106@redhat.com>
References: <4975B412.9070509@RedHat.com>	<4975E683.9050801@redhat.com>	<4975E85D.6030608@RedHat.com>	<4975E91E.7080900@redhat.com>
	<4975EA73.2060806@RedHat.com> <4975ED62.3020106@redhat.com>
Message-ID: <4975EF43.7040301@RedHat.com>

Warren Togami wrote:
> Steve Dickson wrote:
>>> I am not saying "without doing a reverse name lookup".  Just remove the
>>> hardcoded part that makes it fatal.
>> which means the entry in /etc/hosts.deny will be ignored possibly
>> allowing
>> access to machine that should be denied.
> 
> Access control by hostname is highly imperfect and insecure to begin
> with.  Haven't we learned this from rsh?
> 
> How much sense does it make for someone to add every possible hostname
> to deny in /etc/hosts.deny?  If they want to limit access via tcp
> wrappers, they would instead mountd: * in /etc/hosts.deny and add
> specific hosts to /etc/hosts.allow.
Now who is dictating policy! 8-)

> 
> We need to accept that tcp wrappers is insecure (easy to spoof,
> unencrypted) and thus imperfect.  Stop trying to add hacks to shine up
> this turd.  What other services impose such a denial by default due to
> tcp wrappers?  This is simply a bad idea.
This is not for me to say... I'm just try to get the code working with
out breaking anybody's world... 

steved.



From fedora at camperquake.de  Tue Jan 20 15:37:17 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Jan 2009 16:37:17 +0100
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975EE23.6050005@RedHat.com>
References: <4975B412.9070509@RedHat.com> <4975E683.9050801@redhat.com>
	<4975E85D.6030608@RedHat.com>
	<20090120162248.7045cd90@dhcp03.addix.net>
	<4975EE23.6050005@RedHat.com>
Message-ID: <20090120163717.54d331a4@dhcp03.addix.net>

Hi.

On Tue, 20 Jan 2009 10:30:43 -0500, Steve Dickson wrote:

> Now if client 192.168.1.2 did a mount, there would not be a 
> IP matching entry in hosts.allow so a lookup would be necessary
> to see if a 'mountd: <hostname>' exists in hosts.deny. 
> 
> Is that making sense? 

Yes.



From bruno at wolff.to  Tue Jan 20 16:13:02 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Tue, 20 Jan 2009 10:13:02 -0600
Subject: Heads up openssl-0.9.8j in rawhide
In-Reply-To: <1231971935.5215.61.camel@vespa.frost.loc>
References: <1231970614.5215.58.camel@vespa.frost.loc>
	<1231971503.5086.66.camel@localhost.localdomain>
	<1231971679.5086.67.camel@localhost.localdomain>
	<1231971935.5215.61.camel@vespa.frost.loc>
Message-ID: <20090120161302.GA9680@wolff.to>

On Wed, Jan 14, 2009 at 23:25:35 +0100,
  Tomas Mraz <tmraz at redhat.com> wrote:
> 
> Surely, I am not that stupid to break all the deps a week before freeze.

It still is something that has the possibility of causing problems for
a lot of packages if something does goes wrong. Some of us are testing things
that need a working repository (in my case building livecd spins). And
things that block or slow down testing right before a freeze cause problems.

There should be a very important reason for making a change like this less
than a week before a freeze.



From rjones at redhat.com  Tue Jan 20 16:25:46 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 20 Jan 2009 16:25:46 +0000
Subject: Bodhi F-10 push problem
In-Reply-To: <9497e9990901200629p37de1355ib8f5fca8b484e208@mail.gmail.com>
References: <20090120103636.GA24055@amd.home.annexia.org>
	<9497e9990901200629p37de1355ib8f5fca8b484e208@mail.gmail.com>
Message-ID: <20090120162546.GA9146@amd.home.annexia.org>

Thanks - I opened a ticket.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From peter at thecodergeek.com  Tue Jan 20 16:29:51 2009
From: peter at thecodergeek.com (Peter Gordon)
Date: Tue, 20 Jan 2009 08:29:51 -0800
Subject: ibus and F11
In-Reply-To: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1232468991.3205.0.camel@localhost.localdomain>

Good to know. Thanks, Jens and Ignacio! :)
-- 
Peter Gordon (codergeek42) <peter at thecodergeek.com>

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/dd6f3e3e/attachment.sig>

From martin.langhoff at gmail.com  Tue Jan 20 17:07:12 2009
From: martin.langhoff at gmail.com (Martin Langhoff)
Date: Tue, 20 Jan 2009 12:07:12 -0500
Subject: Shortcut for grabbing latest version of every package from a
	directory?
Message-ID: <46a038f90901200907m597076efn43cd197987ca3ba8@mail.gmail.com>

I've been running a 'testing' repo for the next release of my custom
spin (OLPC XS). It's accumulated a number of interim 'testing'
packages, which I rather not publish in the 'stable' repo. I just want
to migrate the latest of each package tothe stable repo.

I am about to script it, but if there's any existing utility that is
friendly to bash scripting... would be nice to know.

(related - what's the canonical way to compare NVR in bash?)

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff



From skvidal at fedoraproject.org  Tue Jan 20 17:13:11 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 20 Jan 2009 12:13:11 -0500
Subject: Shortcut for grabbing latest version of every package from a
 directory?
In-Reply-To: <46a038f90901200907m597076efn43cd197987ca3ba8@mail.gmail.com>
References: <46a038f90901200907m597076efn43cd197987ca3ba8@mail.gmail.com>
Message-ID: <1232471591.4044.21.camel@rosebud>

On Tue, 2009-01-20 at 12:07 -0500, Martin Langhoff wrote:
> I've been running a 'testing' repo for the next release of my custom
> spin (OLPC XS). It's accumulated a number of interim 'testing'
> packages, which I rather not publish in the 'stable' repo. I just want
> to migrate the latest of each package tothe stable repo.
> 
> I am about to script it, but if there's any existing utility that is
> friendly to bash scripting... would be nice to know.
> 
> (related - what's the canonical way to compare NVR in bash?)

you want to get all the latest versions of all pkgs from a dir listed?
run repomanage

repomanage -n -k 1 /path

and evr comparisons can be done via rpmdev-vercmp

-sv






From zboszor at freemail.hu  Tue Jan 20 18:11:31 2009
From: zboszor at freemail.hu (Zoltan Boszormenyi)
Date: Tue, 20 Jan 2009 19:11:31 +0100
Subject: [PATCH] mountd: Don't do tcp wrapper check when there are no
 rules
In-Reply-To: <4975EF43.7040301@RedHat.com>
References: <4975B412.9070509@RedHat.com>	<4975E683.9050801@redhat.com>	<4975E85D.6030608@RedHat.com>	<4975E91E.7080900@redhat.com>	<4975EA73.2060806@RedHat.com>
	<4975ED62.3020106@redhat.com> <4975EF43.7040301@RedHat.com>
Message-ID: <497613D3.8000800@freemail.hu>

Steve Dickson ?rta:
> Warren Togami wrote:
>   
>> Steve Dickson wrote:
>>     
>>>> I am not saying "without doing a reverse name lookup".  Just remove the
>>>> hardcoded part that makes it fatal.
>>>>         
>>> which means the entry in /etc/hosts.deny will be ignored possibly
>>> allowing
>>> access to machine that should be denied.
>>>       
>> Access control by hostname is highly imperfect and insecure to begin
>> with.  Haven't we learned this from rsh?
>>
>> How much sense does it make for someone to add every possible hostname
>> to deny in /etc/hosts.deny?  If they want to limit access via tcp
>> wrappers, they would instead mountd: * in /etc/hosts.deny and add
>> specific hosts to /etc/hosts.allow.
>>     
> Now who is dictating policy! 8-)
>   

The admin is... by hosts.allow and hosts.deny.
nfs-utils' rule is to obey the policy set by the admin.

>> We need to accept that tcp wrappers is insecure (easy to spoof,
>> unencrypted) and thus imperfect.  Stop trying to add hacks to shine up
>> this turd.  What other services impose such a denial by default due to
>> tcp wrappers?  This is simply a bad idea.
>>     
> This is not for me to say... I'm just try to get the code working with
> out breaking anybody's world... 
>
> steved.
>
>   



From notting at redhat.com  Tue Jan 20 18:42:36 2009
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 20 Jan 2009 13:42:36 -0500
Subject: New package from one source
In-Reply-To: <gl40q6$pob$1@ger.gmane.org>
References: <gl2t8r$rm$1@ger.gmane.org>
	<20090119221149.GA10949@nostromo.devel.redhat.com>
	<gl40q6$pob$1@ger.gmane.org>
Message-ID: <20090120184236.GA10482@nostromo.devel.redhat.com>

Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said: 
>> I don't think shipping separate rebuilds of core system daemons that
>> consist of adding 66k of non-upstream patch is a good idea.
>
> I'm completely do not understand - why we do not want provide free  
> choose for free users?

For the same reason we don't ship non-upstream kernel modules; it's a
matter of maintenance load and coherence.

Bill



From mlichvar at redhat.com  Tue Jan 20 18:59:40 2009
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Tue, 20 Jan 2009 19:59:40 +0100
Subject: sendmail milter shared library
Message-ID: <20090120185940.GA3081@localhost>

Hi,

sendmail now has -milter subpackage which includes libmilter as a
shared library. The static libraries were dropped, if you need them,
let me know and I'll add a -static subpackage.

Here is a list of packages buildrequiring sendmail-devel, if there is
your package, please consider rebuild.

spamass-milter
mimedefang
clamav
milter-regex
dkim-milter
milter-greylist

Thanks,

-- 
Miroslav Lichvar



From zaitcev at redhat.com  Tue Jan 20 20:15:58 2009
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Tue, 20 Jan 2009 13:15:58 -0700
Subject: ibus and F11
In-Reply-To: <1232433216.4806.15.camel@localhost.localdomain>
References: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1232433216.4806.15.camel@localhost.localdomain>
Message-ID: <20090120131558.16cc7f8e.zaitcev@redhat.com>

On Mon, 19 Jan 2009 22:33:36 -0800, Peter Gordon <peter at thecodergeek.com> wrote:

> Another excellent feature of SCIM, for me, is the
> handwriting-recognition features provided through Tomoe. []

This, I suspect, is taking the argument too far. iBus will take time
to catch up with SCIM, like any less mature system. Also consider how
Metacity is less feature full than, for instance, E. But we still ship
it as default. [1]

>From the standpoint of Fedora's architecture in general, I am concerned
with an emerging pattern of trying to fix issues by rewriting everything.
Sure, IIIMF was a disaster and had to go, but SCIM is not that bad.
For me, as a user, it's difficult to estimate just how big the advantage
in maintainability is. What is going to happen when Mr. Huang becomes
bored with this project and moves to the next phase of his life?

-- Pete

[1] In addition, I break kanji up into radicals and look it up in WWDICT
or Wordtank. The search by writing seems like a cute toy, but not essential.
But this is beside the point really: I don't want "my Japanese habits vs.
your Japanese habits" to be an argument. Just FYI.



From tibbs at math.uh.edu  Tue Jan 20 20:18:23 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Jan 2009 14:18:23 -0600
Subject: Summary of the 2009-01-20 Packaging Committee meeting
Message-ID: <ufaprihn33k.fsf@epithumia.math.uh.edu>

Meeting minutes and full logs of the 2009-01-20 FPC meeting are
online:

http://fedoraproject.org/wiki/Packaging:Minutes
http://fedoraproject.org/wiki/Packaging:Minutes/20090120


Summary:

The following drafts are now official guidelines, having been accepted
by FESCo last week:

* Font package splitting rules - 
  http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_%282008-12-21%29
* Font package naming - 
  http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_%282009-01-13%29

These should be written into the guidelines soon if this hasn't
already been done by the time you read this.


Issues pending FESCo ratification:

*  Explicit Requires
 * http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
 * Note that this contains an additional section about commenting
   non-obvious items in spec files.

* Updated Haskell Guidelines
 * http://fedoraproject.org/wiki/PackagingDrafts/Haskell 

* Symlinks
 * http://fedoraproject.org/wiki/PackagingDrafts/Symlinks 

 - J<



From Jochen at herr-schmitt.de  Tue Jan 20 20:30:32 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Tue, 20 Jan 2009 21:30:32 +0100
Subject: Packaging of emacs-addon, which may be part of XEmacs-21
Message-ID: <49763468.7080708@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

I have tried to start a review on

https://bugzilla.redhat.com/show_bug.cgi?id=480486

during the review I have got a look on the homepage of the project. On
this
page I could read, that the content of this package is a part of
XEmacw-21.

So I would to ask, is there any guideline to handle this kind of issues.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkl2NF0ACgkQT2AHK6txfgx4rQCbBAn7slti7i39guKX84lJAcN1
SMoAn27XWEo4v7F3R+i584W3SQf70fvS
=FrOL
-----END PGP SIGNATURE-----



From tibbs at math.uh.edu  Tue Jan 20 20:41:27 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 20 Jan 2009 14:41:27 -0600
Subject: Packaging of emacs-addon, which may be part of XEmacs-21
In-Reply-To: <49763468.7080708@herr-schmitt.de>
References: <49763468.7080708@herr-schmitt.de>
Message-ID: <ufaljt5n214.fsf@epithumia.math.uh.edu>

>>>>> "JS" == Jochen Schmitt <Jochen at herr-schmitt.de> writes:

JS> during the review I have got a look on the homepage of the
JS> project. On this page I could read, that the content of this
JS> package is a part of XEmacw-21.

There are many packages which are bundled with Xemacs or in the
xemacs-packages\* set which aren't included with emacs.  You can just
package them as regular emacs addons, but not include any of the
xemacs subpackages.

 - J<



From rjones at redhat.com  Tue Jan 20 20:54:11 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 20 Jan 2009 20:54:11 +0000
Subject: Summary of the 2009-01-20 Packaging Committee meeting
In-Reply-To: <ufaprihn33k.fsf@epithumia.math.uh.edu>
References: <ufaprihn33k.fsf@epithumia.math.uh.edu>
Message-ID: <20090120205411.GA509@amd.home.annexia.org>

On Tue, Jan 20, 2009 at 02:18:23PM -0600, Jason L Tibbitts III wrote:
> *  Explicit Requires
>  * http://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires
>  * Note that this contains an additional section about commenting
>    non-obvious items in spec files.

... which says:

  "Anything in the spec file which is not obvious should have a
  comment explaining it.

  Some examples of non-obvious items include (but are not limited to):

    * Some explicit requires
    * FHS violations
    * Changes to optflags
    * Not using %configure or make install
    * Provides/Obsoletes
    * Modified tarballs
    * Licensing or legal related changes"

I trust these are really just examples, not a list of things that have
to be commented on.  And that reviewers who are blindly running
through the guidelines and not paying much attention won't treat this
as a bullet list of must-have comments.

All MinGW packages violate FHS [previously discussed ad nauseam] by
using /usr/i686-pc-mingw32.  We also use a custom %_mingw32_configure
macro instead of %configure.  %configure isn't useful for non-autoconf
packages, or for packages which have a ./configure script that isn't
autoconf-generated.  In fact "make install" won't work on packages
that don't use make.

Apart from creating unnecessary make-work for packagers, I wonder what
the point of this is.  A better guideline would just have this
sentence and nothing else:

  "Anything in the spec file which is not obvious to a competent
  packager familiar with the relevant guidelines should have a
  comment explaining it."

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From a.badger at gmail.com  Tue Jan 20 21:00:07 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Tue, 20 Jan 2009 13:00:07 -0800
Subject: Summary of the 2009-01-20 Packaging Committee meeting
In-Reply-To: <20090120205411.GA509@amd.home.annexia.org>
References: <ufaprihn33k.fsf@epithumia.math.uh.edu>
	<20090120205411.GA509@amd.home.annexia.org>
Message-ID: <49763B57.90109@gmail.com>

Richard W.M. Jones wrote:

>   "Anything in the spec file which is not obvious should have a
>   comment explaining it.
> 
>   Some examples of non-obvious items include (but are not limited to):
> 
>     * Some explicit requires
>     * FHS violations
>     * Changes to optflags
>     * Not using %configure or make install
>     * Provides/Obsoletes
>     * Modified tarballs
>     * Licensing or legal related changes"
> 
> I trust these are really just examples, not a list of things that have
> to be commented on.  And that reviewers who are blindly running
> through the guidelines and not paying much attention won't treat this
> as a bullet list of must-have comments.

That's the intention.  If reviewers don't read them that way we'll have
to write it in a way that is clearer.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/8f2a155b/attachment.sig>

From poelstra at redhat.com  Tue Jan 20 21:21:19 2009
From: poelstra at redhat.com (John Poelstra)
Date: Tue, 20 Jan 2009 13:21:19 -0800
Subject: Fedora Release Engineering Meeting Recap 2009-01-19 
Message-ID: <4976404F.1020308@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-jan-19

Please make corrections and clarifications to the wiki page.


== F11 Alpha ==
* freeze on 2009-01-20
* discussion about sha256 signatures
* need to create a new package signing key

== IRC Transcript ==



From ceski at fedoraproject.org  Tue Jan 20 21:59:23 2009
From: ceski at fedoraproject.org (Davide Cescato)
Date: Tue, 20 Jan 2009 22:59:23 +0100
Subject: Proxy error upon Red Hat Bugzilla request_new_account
Message-ID: <4976493B.8090807@fedoraproject.org>

As my very first contribution to Fedora, I have my first bug report to 
file. I am in the process of creating a new Red Hat Bugzilla account for 
this purpose, but a proxy error blocks my way.

I applied for a new account at
https://bugzilla.redhat.com/createaccount.cgi
then I received the e-mail with subject "Red Hat Bugzilla: confirm 
account creation") and followed the link
https://bugzilla.redhat.com/token.cgi?t=xxxxx&a=request_new_account
(token ID replaced by 'xxxxx')

The form on this page asks for "real name", "password", and "confirm 
password". If I fill in the form and submit it, after minutes of waiting 
I get a "502 Proxy Error" page 
(URL:https://bugzilla.redhat.com/token.cgi) with body

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /token.cgi.

Reason: Error reading from remote server

If I however submit the form with a very short password, say one 
character long, I get a Red Hat Bugzilla web page (URL: 
https://bugzilla.redhat.com/token.cgi) displaying a "The password must 
be at least 3 characters long." error. Thus, it looks like the entity 
that verifies the validity of the password is working, whereas the 
entity that should actually activate the account is down.

I apologize if I am abusing of the fedora-devel list. I just cannot 
think of (and was not able to find) any better place to file a Bugzilla 
disfunction without being able to access to Bugzilla itself. After all, 
the ability of reporting bugs in one key aspect of Fedora development.



From wtogami at redhat.com  Tue Jan 20 22:18:45 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 17:18:45 -0500
Subject: NFS tcp wrapper situation
Message-ID: <49764DC5.1050907@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=480420#c17

Here is some background information of how this happened.  A long
standing bug in NFS since August 2000 is that it did not support tcp
wrappers /etc/hosts.deny and /etc/hosts.allow.  This was fixed upstream,
but then they discovered an issue.

/etc/hosts.deny:
mountd: badhost.example.com

If DNS is down or the source IP address lacks a reverse lookup, then it
has no way of knowing that it is meant to be denied.  It allows the
connection.  This was considered to a be an unacceptable bug.  If
someone specifies a hostname, from a security perspective they expect
the failure case to err to the side of caution and deny by default if
cannot affirm that the incoming client is not a listed denied hostname.
  Thus "deny upon reverse DNS failure" became the default behavior in
nfs-utils.

This manifested in F-9 and F-10 with a many people suddenly unable
to NFS mount after nfs-utils update hit mirrors ~January 14th.  This is
especially problematic in cases where people use caching DNS
nameservers, as it is non-trivial to explain to everyone how to setup a
proper DNS for arbitrary addresses.  These individuals might also have
no control over DNS on their network.

I believe that "hostname in /etc/hosts.deny fails to deny" should be
NOTABUG for several reasons:

* BAD POLICY and MISCONFIGURATION.
TCP wrappers is behaving exactly how it is defined in policy.  Hostname
in hosts.deny (itself always a bad idea) is dependent on the DNS server
to be properly configured and operating.  Failure due to hostnames in
/etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
unknown clients connecting to that service, then they should use a
wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
/etc/hosts.allow.
* Host names in iptables or tcp wrappers rules are ALWAYS a bad idea
because you are relying upon an unreliable and insecure external data
source that is DNS.  DNS can be too easily spoofed, hijacked, denial of
service attacked, and it lacks any semblance of authentication or
encryption.
* It is wrong for a service wrapped by tcp wrappers to over-engineer
itself to workaround misconfiguration on the part of the sysadmin.
* It is inconsistent with the behavior of any other service wrapped by
tcp wrappers.  "sshd: badhost.example.com" allows incoming connections
if reverse DNS lookup fails.  Does this mean sshd and every other
service wrapped by tcp wrappers should also be modified?
* This is inconsistent with iptables.  "iptables -A INPUT -p tcp --dport
22 -s badhost.example.com -j REJECT" might also fail to reject an
incoming connection under similar DNS-related conditions.  It would be
clearly wrong for sshd to second-guess and parse iptables rules, and
make its own decision based its own reverse DNS query matching hostnames
found in those iptables rules.  Why is it OK to second guess tcp
wrappers but not iptables?
* Even if we agree that this is a bug that should be fixed and not
simply sysadmin misconfiguration, the correct layer to fix it is in tcp
wrappers itself, not the individual wrapped services.

We had a lengthy discussion and have come to reluctant agreement on how
to proceed from here.  It was decided by the filesystem people that even
if it is only the result of misconfiguration, nfs-utils should protect
and deny by default.

Steve is working on the next build of nfs-utils with slightly different
logic.  It will behave exactly as it did before this change (no tcp
wrappers or deny on reverse DNS lookup failure).  It will only enable
tcp wrapper and the new denial behavior if any mountd, statd or wildcard
lines appear in /etc/hosts.deny or /etc/hosts.allow.

We will hopefully have a new build tomorrow.

Workarounds until this is fixed...
==================================
1) Remove tcpwrappers (if you don't need quotas this might be OK)
2) Downgrade nfs-utils to these versions:
http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.2/7.fc9/
http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.4/4.fc10/
3) For LTSP users, you can opt to stop using NFS entirely.  LTSP users
can switch to NBD instead, which is a little more work, but clients boot
a little faster.
https://fedorahosted.org/k12linux/NBDRootConfiguration

Warren Togami
wtogami at redhat.com




From tcallawa at redhat.com  Tue Jan 20 21:16:09 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Tue, 20 Jan 2009 16:16:09 -0500
Subject: [Guidelines Change] Changes to the Packaging Guidelines
Message-ID: <1232486170.7446.82.camel@localhost.localdomain>

As usual, the Fedora Packaging Committee has been busy adding and 
amending the Fedora Packaging Guidelines.

Specifically:

The Packaging Guidelines describing desktop-file-install have been changed. 
Specifically, new packages no longer need to set "vendor" (existing packages 
must keep using "vendor" for the lifetime of that package).
https://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage

The Packaging Guidelines have been changed to reflect the fact that Fedora 
packages must adhere to the Filesystem Hierarchy Standard (FHS), with the
exception of libexecdir (as specified in the GNU Coding Standards) and 
/usr/target for cross-compilers.
https://fedoraproject.org/wiki/Packaging:Guidelines#layout

The Font Packaging Guidelines have been changed. There is a new section which
covers Font Package Layout:
https://fedoraproject.org/wiki/Packaging:FontsPolicy#Package_layout_for_fonts

In addition, there is a new set of Guidelines covering the naming of Font Packages:
https://fedoraproject.org/wiki/Packaging:FontsPolicy#Naming

Also, there is a new set of Guidelines covering the technical implementation of 
Font Packages:
https://fedoraproject.org/wiki/Packaging:FontsPolicy#Technical_implementation

The Eclipse Plugin Guidelines were updated to reflect Eclipse 3.4:
https://fedoraproject.org/wiki/Packaging:EclipsePlugins

The Ruby Guidelines were updated to better handle situations where a Ruby Gem 
includes an extension library written in C:
https://fedoraproject.org/wiki/Packaging:Ruby#Ruby_Gem_with_extension_libraries_written_in_C

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC) and ratified by FESCo.

Many thanks to Andrew Overholt, Mamoru Tasaka, Nicolas Mailhot, and all 
of the members of the FPC and FESCo, for assisting in drafting, refining, and 
passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If you
find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
http://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

~spot

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From fedora at camperquake.de  Tue Jan 20 22:32:30 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Tue, 20 Jan 2009 23:32:30 +0100
Subject: NFS tcp wrapper situation
In-Reply-To: <49764DC5.1050907@redhat.com>
References: <49764DC5.1050907@redhat.com>
Message-ID: <20090120233230.103dcbf8@lain.camperquake.de>

Hi.

On Tue, 20 Jan 2009 17:18:45 -0500, Warren Togami wrote

> * This is inconsistent with iptables.  "iptables -A INPUT -p tcp
> --dport 22 -s badhost.example.com -j REJECT" might also fail to
> reject an incoming connection under similar DNS-related conditions.
> It would be clearly wrong for sshd to second-guess and parse iptables
> rules, and make its own decision based its own reverse DNS query
> matching hostnames found in those iptables rules.  Why is it OK to
> second guess tcp wrappers but not iptables?

Wait a second. iptables does not support hostnames the same way
tcpwrappers does. The userspace component may, but name resolution is
done on rule creation, not on rule matching later on.



From wtogami at redhat.com  Tue Jan 20 22:52:38 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 17:52:38 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <20090120233230.103dcbf8@lain.camperquake.de>
References: <49764DC5.1050907@redhat.com>
	<20090120233230.103dcbf8@lain.camperquake.de>
Message-ID: <497655B6.7040107@redhat.com>

Ralf Ertzinger wrote:
> Hi.
> 
> On Tue, 20 Jan 2009 17:18:45 -0500, Warren Togami wrote
> 
>> * This is inconsistent with iptables.  "iptables -A INPUT -p tcp
>> --dport 22 -s badhost.example.com -j REJECT" might also fail to
>> reject an incoming connection under similar DNS-related conditions.
>> It would be clearly wrong for sshd to second-guess and parse iptables
>> rules, and make its own decision based its own reverse DNS query
>> matching hostnames found in those iptables rules.  Why is it OK to
>> second guess tcp wrappers but not iptables?
> 
> Wait a second. iptables does not support hostnames the same way
> tcpwrappers does. The userspace component may, but name resolution is
> done on rule creation, not on rule matching later on.
> 

Yes, that is why I said "similar DNS-related conditions".  In the case 
of iptables it would be cases like forward resolver different from 
reverse, or secondary IP from forward resolver, or if the IP address 
referenced changed since iptables parsing, or if the DNS server failed 
during iptables parsing.

Warren Togami
wtogami at redhat.com



From chitlesh.goorah at gmail.com  Tue Jan 20 22:54:34 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Tue, 20 Jan 2009 23:54:34 +0100
Subject: pkg-config-0.21-requires-private-fix.patch breaks Requires.private 
	Cflags
Message-ID: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>

Hello there,

the pkg-config-0.21-requires-private-fix.patch breaks Requires.private
Cflags. There is already a bug opened with respect to this issue since
a year now.
https://bugzilla.redhat.com/show_bug.cgi?id=426106
http://www.linux-archive.org/fedora-development/202148-heads-up-enabling-generation-pkg-config-requires.html

I was recently ping'ed by an upstream complaining about why this patch
is still being shipped.
http://archives.seul.org/geda/user/Jan-2009/msg00591.html

My question is what is the solution to this issue and what should both
packagers and upstream do ?

Since we have many upstream projects using Fedora to develop their
software, I believe we can not afford to keep it broken.

Kind regards,
Chitlesh



From mclasen at redhat.com  Tue Jan 20 22:58:47 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 20 Jan 2009 17:58:47 -0500
Subject: pkg-config-0.21-requires-private-fix.patch breaks
 Requires.private  Cflags
In-Reply-To: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
References: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
Message-ID: <1232492327.3408.3.camel@matthiasc>

On Tue, 2009-01-20 at 23:54 +0100, Chitlesh GOORAH wrote:

> My question is what is the solution to this issue and what should both
> packagers and upstream do ?
> 
> Since we have many upstream projects using Fedora to develop their
> software, I believe we can not afford to keep it broken.

That is why it was fixed.

 Mon Dec  8 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
- Remove a patch that is no longer necessary and causes more
  problems than it solves (#224148)




From dbn.lists at gmail.com  Tue Jan 20 23:14:13 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 20 Jan 2009 15:14:13 -0800
Subject: pkg-config-0.21-requires-private-fix.patch breaks
	Requires.private Cflags
In-Reply-To: <1232492327.3408.3.camel@matthiasc>
References: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
	<1232492327.3408.3.camel@matthiasc>
Message-ID: <91705d080901201514o5132e927l4fd4a5c27053862b@mail.gmail.com>

On Tue, Jan 20, 2009 at 2:58 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Tue, 2009-01-20 at 23:54 +0100, Chitlesh GOORAH wrote:
>
>> My question is what is the solution to this issue and what should both
>> packagers and upstream do ?
>>
>> Since we have many upstream projects using Fedora to develop their
>> software, I believe we can not afford to keep it broken.
>
> That is why it was fixed.
>
>  Mon Dec  8 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
> - Remove a patch that is no longer necessary and causes more
>  problems than it solves (#224148)

You're probably really tired of hearing from me on this issue :)

I think it would be nice to backport that fix to F9 and F10. Since the
feature that patch was originally trying to address (bad pkg-config
autoreqs) is not being used in those fedora releases, I think it would
be good to get pkg-config back in line with the upstream behavior. As
it stands, the patch is only serving to make the F9 and F10 pkg-config
incompatible with other releases out in the wild. There's no gain from
keeping that patch, IMO.

--
Dan



From nathanael at gnat.ca  Tue Jan 20 23:15:24 2009
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Tue, 20 Jan 2009 16:15:24 -0700
Subject: RPM Advice
Message-ID: <49765B0C.8060704@gnat.ca>

Hello,
   I realize this isn't a fedora specific issue, but I know you are all 
very rpm knowledgeable and might have a quick answer to my issue.

   I'm building a few bash scripts for use in our company. We have a few 
fedora based workstations so I thought, easier than copying the scripts 
everywhere - lets create an rpm so I can update them as need be. So 
instead of a bunch of separate bash scripts for each different command, 
I would have a common script that included a common library of 
functions, and then a single file for each command. So the basis is this:

main command located /usr/bin

it has a line

SCRIPTDIR=.....

while developing I need that to be the local files I'm working on so I 
have it set to ./scripts, but when I deploy as an rpm I need it changed 
to %_datadir/%{name}... I couldn't find a 'good' way of doing that. Any 
suggestions?


-- 
Nathanael d. Noblet
T: 403.875.4613



From mclasen at redhat.com  Tue Jan 20 23:18:35 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 20 Jan 2009 18:18:35 -0500
Subject: pkg-config-0.21-requires-private-fix.patch breaks
 Requires.private Cflags
In-Reply-To: <91705d080901201514o5132e927l4fd4a5c27053862b@mail.gmail.com>
References: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
	<1232492327.3408.3.camel@matthiasc>
	<91705d080901201514o5132e927l4fd4a5c27053862b@mail.gmail.com>
Message-ID: <1232493515.3408.5.camel@matthiasc>

On Tue, 2009-01-20 at 15:14 -0800, Dan Nicholson wrote:
> On Tue, Jan 20, 2009 at 2:58 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> > On Tue, 2009-01-20 at 23:54 +0100, Chitlesh GOORAH wrote:
> >
> >> My question is what is the solution to this issue and what should both
> >> packagers and upstream do ?
> >>
> >> Since we have many upstream projects using Fedora to develop their
> >> software, I believe we can not afford to keep it broken.
> >
> > That is why it was fixed.
> >
> >  Mon Dec  8 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
> > - Remove a patch that is no longer necessary and causes more
> >  problems than it solves (#224148)
> 
> You're probably really tired of hearing from me on this issue :)
> 
> I think it would be nice to backport that fix to F9 and F10. Since the
> feature that patch was originally trying to address (bad pkg-config
> autoreqs) is not being used in those fedora releases, I think it would
> be good to get pkg-config back in line with the upstream behavior. As
> it stands, the patch is only serving to make the F9 and F10 pkg-config
> incompatible with other releases out in the wild. There's no gain from
> keeping that patch, IMO.

Maybe.

Will you keep your part of the deal this time and write a brief 'how to
use pkg-config for your project' manual ?





From petersen at redhat.com  Tue Jan 20 23:21:20 2009
From: petersen at redhat.com (Jens Petersen)
Date: Tue, 20 Jan 2009 18:21:20 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <1415176535.666641232493003913.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <3806842.667491232493680943.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> But if I install ibus, I'll have to configure it from scratch, right?
> There is no settings migration from SCIM, is there?

True.  Not that many settings to migrate, but there is no migration
of settings.

I like Pete's analogy with metacity, and hope that ibus can provide
sane defaults where possible to avoid needing too much configuration,
but there will be some configuration available for the input engines.

Jens



From paul at all-the-johnsons.co.uk  Tue Jan 20 07:31:44 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Tue, 20 Jan 2009 07:31:44 +0000
Subject: k3b permissions
Message-ID: <1232436704.6740.8.camel@PB3.Linux>

Hi,

k3b works fine as a non su user, but won't allow me to burn discs. I'm
suspecting something has happened in glibc or selinux to change the
permissions, but even if I chown /dev/sr0 to being mine, it reverts back
to being root.

Any ideas on fixing this?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/5d2a745b/attachment.sig>

From dbn.lists at gmail.com  Tue Jan 20 23:22:35 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Tue, 20 Jan 2009 15:22:35 -0800
Subject: pkg-config-0.21-requires-private-fix.patch breaks
	Requires.private Cflags
In-Reply-To: <1232493515.3408.5.camel@matthiasc>
References: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
	<1232492327.3408.3.camel@matthiasc>
	<91705d080901201514o5132e927l4fd4a5c27053862b@mail.gmail.com>
	<1232493515.3408.5.camel@matthiasc>
Message-ID: <91705d080901201522h2afe702fgf15d441e2f454d9b@mail.gmail.com>

On Tue, Jan 20, 2009 at 3:18 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> On Tue, 2009-01-20 at 15:14 -0800, Dan Nicholson wrote:
>> On Tue, Jan 20, 2009 at 2:58 PM, Matthias Clasen <mclasen at redhat.com> wrote:
>> > On Tue, 2009-01-20 at 23:54 +0100, Chitlesh GOORAH wrote:
>> >
>> >> My question is what is the solution to this issue and what should both
>> >> packagers and upstream do ?
>> >>
>> >> Since we have many upstream projects using Fedora to develop their
>> >> software, I believe we can not afford to keep it broken.
>> >
>> > That is why it was fixed.
>> >
>> >  Mon Dec  8 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
>> > - Remove a patch that is no longer necessary and causes more
>> >  problems than it solves (#224148)
>>
>> You're probably really tired of hearing from me on this issue :)
>>
>> I think it would be nice to backport that fix to F9 and F10. Since the
>> feature that patch was originally trying to address (bad pkg-config
>> autoreqs) is not being used in those fedora releases, I think it would
>> be good to get pkg-config back in line with the upstream behavior. As
>> it stands, the patch is only serving to make the F9 and F10 pkg-config
>> incompatible with other releases out in the wild. There's no gain from
>> keeping that patch, IMO.
>
> Maybe.
>
> Will you keep your part of the deal this time and write a brief 'how to
> use pkg-config for your project' manual ?

groff or html?

--
Dan



From ivazqueznet at gmail.com  Tue Jan 20 23:25:36 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 20 Jan 2009 18:25:36 -0500
Subject: RPM Advice
In-Reply-To: <49765B0C.8060704@gnat.ca>
References: <49765B0C.8060704@gnat.ca>
Message-ID: <1232493936.4002.42.camel@ignacio.lan>

On Tue, 2009-01-20 at 16:15 -0700, Nathanael D. Noblet wrote:
> main command located /usr/bin
> 
> it has a line
> 
> SCRIPTDIR=.....
> 
> while developing I need that to be the local files I'm working on so I 
> have it set to ./scripts, but when I deploy as an rpm I need it changed 
> to %_datadir/%{name}... I couldn't find a 'good' way of doing that. Any 
> suggestions?

%{_sysconfdir}/profile.d

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/1ce2d52d/attachment.sig>

From mclasen at redhat.com  Tue Jan 20 23:27:42 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 20 Jan 2009 18:27:42 -0500
Subject: pkg-config-0.21-requires-private-fix.patch breaks
 Requires.private Cflags
In-Reply-To: <91705d080901201522h2afe702fgf15d441e2f454d9b@mail.gmail.com>
References: <50baabb30901201454x1c70de57mf13a78da33f14343@mail.gmail.com>
	<1232492327.3408.3.camel@matthiasc>
	<91705d080901201514o5132e927l4fd4a5c27053862b@mail.gmail.com>
	<1232493515.3408.5.camel@matthiasc>
	<91705d080901201522h2afe702fgf15d441e2f454d9b@mail.gmail.com>
Message-ID: <1232494062.3408.7.camel@matthiasc>

On Tue, 2009-01-20 at 15:22 -0800, Dan Nicholson wrote:
> On Tue, Jan 20, 2009 at 3:18 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> > On Tue, 2009-01-20 at 15:14 -0800, Dan Nicholson wrote:
> >> On Tue, Jan 20, 2009 at 2:58 PM, Matthias Clasen <mclasen at redhat.com> wrote:
> >> > On Tue, 2009-01-20 at 23:54 +0100, Chitlesh GOORAH wrote:
> >> >
> >> >> My question is what is the solution to this issue and what should both
> >> >> packagers and upstream do ?
> >> >>
> >> >> Since we have many upstream projects using Fedora to develop their
> >> >> software, I believe we can not afford to keep it broken.
> >> >
> >> > That is why it was fixed.
> >> >
> >> >  Mon Dec  8 2008 Matthias Clasen  <mclasen at redhat.com> - 1:0.23-6
> >> > - Remove a patch that is no longer necessary and causes more
> >> >  problems than it solves (#224148)
> >>
> >> You're probably really tired of hearing from me on this issue :)
> >>
> >> I think it would be nice to backport that fix to F9 and F10. Since the
> >> feature that patch was originally trying to address (bad pkg-config
> >> autoreqs) is not being used in those fedora releases, I think it would
> >> be good to get pkg-config back in line with the upstream behavior. As
> >> it stands, the patch is only serving to make the F9 and F10 pkg-config
> >> incompatible with other releases out in the wild. There's no gain from
> >> keeping that patch, IMO.
> >
> > Maybe.
> >
> > Will you keep your part of the deal this time and write a brief 'how to
> > use pkg-config for your project' manual ?
> 
> groff or html?

Whatever works for you. I think it would be nice to have this
information on the pkg-config wiki and in the installed pkg-config docs.
Not sure what that implies for the best format...



From jkeating at redhat.com  Tue Jan 20 23:48:30 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 20 Jan 2009 15:48:30 -0800
Subject: Python and /etc/resolv.conf changes
Message-ID: <1232495310.3539.172.camel@localhost.localdomain>

I'm looking at what might be a bug in python.  The anaconda installer
launches python, then we get network configs going and write out some
files such as /etc/resolv.conf.  However that original python process
can't seem to resolve anything after this file has been written out,
whereas new python processes started on a different terminal can indeed
use the new /etc/resolv.conf data.

My thought is that the original python process is using stale
information, and that something like a res_init() is needed, but google
doesn't seem to have any real connection between python and calling
res_init.  The guys in #python on freenode aren't exactly sure what to
do here either.

In fact, I just did a simple test of an strace on python, where I import
socket, do a lookup, modify /etc/resolv.conf, do more lookups and review
the results.  Strace shows that python opens /etc/resolv.conf exactly
once (after I've imported socket), and never again, so it never sees any
of the changes made.

Can anybody confirm what I'm seeing as buggy and in need of fixing?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/bfcd997e/attachment.sig>

From dchen at redhat.com  Wed Jan 21 00:16:38 2009
From: dchen at redhat.com (Ding-Yi Chen)
Date: Wed, 21 Jan 2009 10:16:38 +1000
Subject: ibus and F11
In-Reply-To: <20090120153053.GC14182@mokona.greysector.net>
References: <511187499.336701232409913305.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20090120153053.GC14182@mokona.greysector.net>
Message-ID: <1232496998.3759.11.camel@localhost.localdomain>


? ??2009-01-20 ? 16:30 +0100?Dominik 'Rathann' Mierzejewski ???
> On Tuesday, 20 January 2009 at 01:06, Jens Petersen wrote:
> > ----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> > > What's the migration path for SCIM users?
> > 
> > Users upgrading from earlier Fedora releases can continue to use scim
> > or if they wish they can install ibus themselves and use that.  Scim
> > will be continue to be in Fedora for the time being.
> 
> But if I install ibus, I'll have to configure it from scratch, right?
> There is no settings migration from SCIM, is there?

No, as it usually only involves a few mouse clicks or may be some key
press.

Just curious, what settings you did that make you think that the
settings migration would be a necessity? 





From linuxguy123 at gmail.com  Wed Jan 21 00:54:50 2009
From: linuxguy123 at gmail.com (Linuxguy123)
Date: Tue, 20 Jan 2009 17:54:50 -0700
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <1232410842.3977.4.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
Message-ID: <1232499290.10991.1.camel@localhost.localdomain>

On Mon, 2009-01-19 at 17:20 -0700, Linuxguy123 wrote:
> I'm doing some embedded development and my flash programmer has a USB
> interface.  Everything works fine if I program the device as root, but
> I'd like to be able to do it as a regular user.  I get port permission
> errors if I try to run the programmer as a regular user.
> 
> $ lsusb
> Bus 002 Device 003: ID 064e:a101 Suyin Corp. Laptop integrated WebCam
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 007 Device 006: ID 15ba:0003 Olimex Ltd. OpenOCD JTAG
> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 006 Device 002: ID 046d:c512 Logitech, Inc. LX-700 Cordless Desktop
> Receiver
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> Port
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 004: ID 07ca:a321 AVerMedia Technologies, Inc.
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 003: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth +
> WLAN) Interface [Integrated Module]
> Bus 003 Device 002: ID 08ff:2580 AuthenTec, Inc. AES2501 Fingerprint
> Sensor
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> 
> 
> My programmer is the Olimex Ltd. OpenOCD JTAG device on bus 7.
> 
> The documentation for the device says it needs access to /proc/bus/usb.
> 
> I can allow regular user access by manually issuing a chown command for
> the port, but then I'd have to do it every time I reboot or unplug the
> programmer.   How do I set it up to happen automatically in F10 ?
> 
> Thanks !

Anyone ?



From rwheeler at redhat.com  Wed Jan 21 01:19:25 2009
From: rwheeler at redhat.com (Ric Wheeler)
Date: Tue, 20 Jan 2009 20:19:25 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <49764DC5.1050907@redhat.com>
References: <49764DC5.1050907@redhat.com>
Message-ID: <4976781D.2020109@redhat.com>

Warren Togami wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=480420#c17
>
> Here is some background information of how this happened.  A long
> standing bug in NFS since August 2000 is that it did not support tcp
> wrappers /etc/hosts.deny and /etc/hosts.allow.  This was fixed upstream,
> but then they discovered an issue.
>
> /etc/hosts.deny:
> mountd: badhost.example.com
>
> If DNS is down or the source IP address lacks a reverse lookup, then it
> has no way of knowing that it is meant to be denied.  It allows the
> connection.  This was considered to a be an unacceptable bug.  If
> someone specifies a hostname, from a security perspective they expect
> the failure case to err to the side of caution and deny by default if
> cannot affirm that the incoming client is not a listed denied hostname.
>  Thus "deny upon reverse DNS failure" became the default behavior in
> nfs-utils.
>
> This manifested in F-9 and F-10 with a many people suddenly unable
> to NFS mount after nfs-utils update hit mirrors ~January 14th.  This is
> especially problematic in cases where people use caching DNS
> nameservers, as it is non-trivial to explain to everyone how to setup a
> proper DNS for arbitrary addresses.  These individuals might also have
> no control over DNS on their network.
>
> I believe that "hostname in /etc/hosts.deny fails to deny" should be
> NOTABUG for several reasons:
>
> * BAD POLICY and MISCONFIGURATION.
> TCP wrappers is behaving exactly how it is defined in policy.  Hostname
> in hosts.deny (itself always a bad idea) is dependent on the DNS server
> to be properly configured and operating.  Failure due to hostnames in
> /etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
> unknown clients connecting to that service, then they should use a
> wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
> /etc/hosts.allow.

I disagree - you can easily get into a situation here where a user has 
put "badhost.example.com" into hosts.deny and by your argument, if DNS 
lookup fails, you will always allow them in.

Clearly, not the correct response for a security policy.

As we discussed with Steve D this afternoon, I think that the correct 
behaviour would be to:

    (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable 
this denial if no rules for your service are defined.
    (2) If you don't believe in this policy, either uninstall TCP 
wrappers OR use only IP addresses in the /etc/hosts.* files.

What you are proposing would flip the security policy on its head - if 
you cannot resolve the hostname, always allow access.

To recap, to trigger this concern you have, you have to take the 
following steps:

    (1) Edit either file and install an allow or deny rule with 
hostnames (we currently ship without any rules defined, the files are 
effectively empty)
    (2) Have a DNS failure
    (3) Have configured NFS service

The fix for a user is easy - change the hostnames to IP addresses or 
uninstall TCP wrappers, right?

I really, really don't see this as anything other than correcting a long 
standing bug.

A different (and very valid) argument can be made that tcp wrappers are 
garbage and that we should not ship them. Until then, I would argue that 
we should fix them to work as expected.

What would be nice is if tcp wrappers itself had an easy to use API that 
allowed us to query for a specific service - if no rules (default or 
specific to your service) have been specified, you can disable the DNS 
reverse lookup path.

Regards,

Ric

> * Host names in iptables or tcp wrappers rules are ALWAYS a bad idea
> because you are relying upon an unreliable and insecure external data
> source that is DNS.  DNS can be too easily spoofed, hijacked, denial of
> service attacked, and it lacks any semblance of authentication or
> encryption.
> * It is wrong for a service wrapped by tcp wrappers to over-engineer
> itself to workaround misconfiguration on the part of the sysadmin.
> * It is inconsistent with the behavior of any other service wrapped by
> tcp wrappers.  "sshd: badhost.example.com" allows incoming connections
> if reverse DNS lookup fails.  Does this mean sshd and every other
> service wrapped by tcp wrappers should also be modified?
> * This is inconsistent with iptables.  "iptables -A INPUT -p tcp --dport
> 22 -s badhost.example.com -j REJECT" might also fail to reject an
> incoming connection under similar DNS-related conditions.  It would be
> clearly wrong for sshd to second-guess and parse iptables rules, and
> make its own decision based its own reverse DNS query matching hostnames
> found in those iptables rules.  Why is it OK to second guess tcp
> wrappers but not iptables?
> * Even if we agree that this is a bug that should be fixed and not
> simply sysadmin misconfiguration, the correct layer to fix it is in tcp
> wrappers itself, not the individual wrapped services.
>
> We had a lengthy discussion and have come to reluctant agreement on how
> to proceed from here.  It was decided by the filesystem people that even
> if it is only the result of misconfiguration, nfs-utils should protect
> and deny by default.
>
> Steve is working on the next build of nfs-utils with slightly different
> logic.  It will behave exactly as it did before this change (no tcp
> wrappers or deny on reverse DNS lookup failure).  It will only enable
> tcp wrapper and the new denial behavior if any mountd, statd or wildcard
> lines appear in /etc/hosts.deny or /etc/hosts.allow.
>
> We will hopefully have a new build tomorrow.
>
> Workarounds until this is fixed...
> ==================================
> 1) Remove tcpwrappers (if you don't need quotas this might be OK)
> 2) Downgrade nfs-utils to these versions:
> http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.2/7.fc9/
> http://kojipkgs.fedoraproject.org/packages/nfs-utils/1.1.4/4.fc10/
> 3) For LTSP users, you can opt to stop using NFS entirely.  LTSP users
> can switch to NBD instead, which is a little more work, but clients boot
> a little faster.
> https://fedorahosted.org/k12linux/NBDRootConfiguration
>
> Warren Togami
> wtogami at redhat.com
>
>



From walters at verbum.org  Wed Jan 21 01:19:41 2009
From: walters at verbum.org (Colin Walters)
Date: Tue, 20 Jan 2009 20:19:41 -0500
Subject: Python and /etc/resolv.conf changes
In-Reply-To: <1232495310.3539.172.camel@localhost.localdomain>
References: <1232495310.3539.172.camel@localhost.localdomain>
Message-ID: <faa16b610901201719s637c631ah178119f833b59d5@mail.gmail.com>

2009/1/20 Jesse Keating <jkeating at redhat.com>:
> I'm looking at what might be a bug in python.  The anaconda installer
> launches python, then we get network configs going and write out some
> files such as /etc/resolv.conf.  However that original python process
> can't seem to resolve anything after this file has been written out,
> whereas new python processes started on a different terminal can indeed
> use the new /etc/resolv.conf data.
>
> My thought is that the original python process is using stale
> information, and that something like a res_init() is needed, but google
> doesn't seem to have any real connection between python and calling
> res_init.  The guys in #python on freenode aren't exactly sure what to
> do here either.

Nothing specific to Python here as far as I know; glibc just caches
its first read of /etc/resolv.conf.  Everything is affected.  The only
program that mostly works is Firefox because they go out of their way
to unbreak things (i.e. call res_init when they get notification from
NetworkManager).

The previous thread was here:

http://www.mailinglistarchive.com/fedora-devel-list at redhat.com/msg39340.html

I think we were stuck on the choice between nscd, bind, and some other
caching package.

Both Debian/Ubuntu
(http://patches.ubuntu.com/g/glibc/extracted/any/local-dynamic-resolvconf.diff)
and OpenSUSE (http://download.opensuse.org/distribution/11.0/repo/src-oss/suse/src/glibc-2.8-14.1.src.rpm,
resolv.dynamic.diff) ship a patch to glibc which stats() resolv.conf.
We do not.



From mmcgrath at redhat.com  Wed Jan 21 02:02:01 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Tue, 20 Jan 2009 20:02:01 -0600 (CST)
Subject: Python and /etc/resolv.conf changes
In-Reply-To: <1232495310.3539.172.camel@localhost.localdomain>
References: <1232495310.3539.172.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0901201958480.3456@laptop.mmcgrath.net>

On Tue, 20 Jan 2009, Jesse Keating wrote:

> I'm looking at what might be a bug in python.  The anaconda installer
> launches python, then we get network configs going and write out some
> files such as /etc/resolv.conf.  However that original python process
> can't seem to resolve anything after this file has been written out,
> whereas new python processes started on a different terminal can indeed
> use the new /etc/resolv.conf data.
>
> My thought is that the original python process is using stale
> information, and that something like a res_init() is needed, but google
> doesn't seem to have any real connection between python and calling
> res_init.  The guys in #python on freenode aren't exactly sure what to
> do here either.
>
> In fact, I just did a simple test of an strace on python, where I import
> socket, do a lookup, modify /etc/resolv.conf, do more lookups and review
> the results.  Strace shows that python opens /etc/resolv.conf exactly
> once (after I've imported socket), and never again, so it never sees any
> of the changes made.
>
> Can anybody confirm what I'm seeing as buggy and in need of fixing?
>

I believe this might be the same thing that happens to preupgrade and
smolt.  It's a hacky fix but here's how we dealt with it:

http://tinyurl.com/8lz8gh

	-Mike



From bcrl at kvack.org  Wed Jan 21 02:55:33 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Tue, 20 Jan 2009 21:55:33 -0500
Subject: F10 and no root login - impossible to maintain systems!
Message-ID: <20090121025533.GF19788@kvack.org>

Hi folks,

I've been holding back my tongue on this one, but I've been bitten by it 
enough times now that I think I can write something with a clear head.  To 
put it shortly: disallowing root logins by default is a complete headache 
for systems where anything goes wrong.  I've run into several different 
failure modes now: if / and /tmp get full, it's impossible to login as a 
normal user, and if NFS goes down and /home isn't accessible, one cannot login 
to fix the problem.

I think the push for never allowing root to login is daft and inconsiderate 
of the needs of users who maintain systems.  I much prefer the F9 policy of 
putting up a warning and allowing me to proceed -- I know it's impossible to 
make everything on the desktop root-safe and I don't expect it.  The system 
should not decree that it knows better than me, though.

		-ben



From sundaram at fedoraproject.org  Wed Jan 21 02:59:33 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Jan 2009 08:29:33 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121025533.GF19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
Message-ID: <49768F95.5080800@fedoraproject.org>

Benjamin LaHaise wrote:
> Hi folks,
> 
> I've been holding back my tongue on this one, but I've been bitten by it 
> enough times now that I think I can write something with a clear head.  To 
> put it shortly: disallowing root logins by default is a complete headache 
> for systems where anything goes wrong.  I've run into several different 
> failure modes now: if / and /tmp get full, it's impossible to login as a 
> normal user, and if NFS goes down and /home isn't accessible, one cannot login 
> to fix the problem.

You can at run level 3. You can even start X after that.

Rahul



From bcrl at kvack.org  Wed Jan 21 03:01:32 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Tue, 20 Jan 2009 22:01:32 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <49768F95.5080800@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
Message-ID: <20090121030132.GG19788@kvack.org>

On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
> You can at run level 3. You can even start X after that.

You're assuming all users of a system are technical.  That is not the case.

		-ben



From ivazqueznet at gmail.com  Wed Jan 21 03:28:08 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Tue, 20 Jan 2009 22:28:08 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121030132.GG19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
Message-ID: <1232508488.4002.54.camel@ignacio.lan>

On Tue, 2009-01-20 at 22:01 -0500, Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
> > You can at run level 3. You can even start X after that.
> 
> You're assuming all users of a system are technical.  That is not the case.

How would a non-technical user know to log in as root?

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090120/8b2bf432/attachment.sig>

From wtogami at redhat.com  Wed Jan 21 04:17:15 2009
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 20 Jan 2009 23:17:15 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <4976781D.2020109@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
Message-ID: <4976A1CB.4050600@redhat.com>

Ric Wheeler wrote:
>>
>> * BAD POLICY and MISCONFIGURATION.
>> TCP wrappers is behaving exactly how it is defined in policy.  Hostname
>> in hosts.deny (itself always a bad idea) is dependent on the DNS server
>> to be properly configured and operating.  Failure due to hostnames in
>> /etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
>> unknown clients connecting to that service, then they should use a
>> wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
>> /etc/hosts.allow.
> 
> I disagree - you can easily get into a situation here where a user has 
> put "badhost.example.com" into hosts.deny and by your argument, if DNS 
> lookup fails, you will always allow them in.

My point is a sysadmin shouldn't be doing that, because it is ALWAYS a 
bad idea and a misconfiguration.  They should instead set a wildcard to 
deny everything and allow only specific hosts in /etc/hosts.allow.  Then 
the DNS-is-down or DNS-reverse-failure case properly fail as expected.

My points go on further to say that we don't second guess the bad policy 
if the user does something equally foolish with iptables, or tcp 
wrappers with sshd remains "vulnerable" in the way you are trying to 
shoe-horn into nfs-utils.

In any case I think it is a bad idea to add this to nfs-utils, but we 
did agree to do so today.  While I continue to disagree, I'm satisfied 
enough to just let it happen.  We all wasted a serious amount of time 
over this non-issue.

> 
> A different (and very valid) argument can be made that tcp wrappers are 
> garbage and that we should not ship them. Until then, I would argue that 
> we should fix them to work as expected.
> 

+1.  We really need to stop shipping this crap.

Warren Togami
wtogami at redhat.com



From jiteshs at marvell.com  Wed Jan 21 06:53:44 2009
From: jiteshs at marvell.com (Jitesh Shah)
Date: Wed, 21 Jan 2009 12:23:44 +0530
Subject: Koji: ServerOffline
In-Reply-To: <1232449536.9222.30.camel@localhost.localdomain>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
	<1232446160.9222.20.camel@localhost.localdomain>
	<62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>
	<1232449536.9222.30.camel@localhost.localdomain>
Message-ID: <1232520824.3036.6.camel@localhost.localdomain>

Hi,
The problem isn't related to failed transactions, as I suspected
earlier. However, I restarted postgresql in vain. Then, reinstalled
postgresql to no avail. 

I also, removed and reinstalled koji and reconfigured it, but I still
get the same "ServerOffline" error. I am out of things to do.

Any pointers as to why this might be happening?

Jitesh

On Tue, 2009-01-20 at 16:35 +0530, Jitesh Shah wrote:
> 
> On Tue, 2009-01-20 at 11:26 +0100, Xavier Lamien wrote:
> > On Tue, Jan 20, 2009 at 11:09 AM, Jitesh Shah <jiteshs at marvell.com> wrote:
> > > Hi,
> > > Yes, I have already double-checked my koji-hub configuration. Both the
> > > DBUser and DBName are correct. Infact, I had been running koji here for
> > > more than a fortnight and it worked like a charm.
> > 
> > did you do any update since ?
> 
> Nope ... didn't update koji!
> > 
> > >
> > > Also, I can connect with to the psql database using the same values as
> > > in DBName and DBUser variables through commandline. So, what might cause
> > > the failure when invoked through python scripts?
> > 
> > Do you also tried to figure out what happen in the DB side when
> > invoked your cmd-line ?
> > 
> 
> As I mentioned earlier, it works fine through commandline!
> 
> Update: 
> I suspect that the issue is related to failed transactions. 
> The file /usr/share/koji-hub/kojixmlrpc.py suggests that the
> koji.db.connect fails. 
> I had been running koji-shadow script and it failed mysteriously. I see
> this "ServerOffline: Database outage" message from that point on. I
> think the rollback() in koji.db.connect fails due to some not-yet-known
> reason. I am looking into it further.
> 
> Jitesh
> 



From kevin.kofler at chello.at  Wed Jan 21 07:27:27 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 08:27:27 +0100
Subject: ibus and F11
References: <966740565.67551232363656159.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<1232433216.4806.15.camel@localhost.localdomain>
	<20090120131558.16cc7f8e.zaitcev@redhat.com>
Message-ID: <gl6iov$fn1$2@ger.gmane.org>

Pete Zaitcev wrote:
> For me, as a user, it's difficult to estimate just how big the advantage
> in maintainability is. What is going to happen when Mr. Huang becomes
> bored with this project and moves to the next phase of his life?

Another rewrite. ;-)

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 21 07:28:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 08:28:23 +0100
Subject: ibus and F11
References: <1890800670.367251232435134584.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<2d72ba62f03be5c2f6876a39eecdf5bc.squirrel@arekh.dyndns.org>
Message-ID: <gl6iqn$fn1$3@ger.gmane.org>

Nicolas Mailhot wrote:
> BTW: this will conflict with some XKB layouts, and some apps. This
> needs to be configurable (a successful im switcher would merge with
> the gnome xkb keyboard switching applet and keep all its useful
> features)

It also needs to integrate with KDE systemsettings.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 21 07:35:58 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 08:35:58 +0100
Subject: BTRFS 0.17 in rawhide (at some point)
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
Message-ID: <gl6j8u$fn1$4@ger.gmane.org>

One question I couldn't find a definite answer to: Does btrfs-convert also
work on ext4? In other words: Can we upgrade from ext3 to ext4 and then
from ext4 to btrfs? Or are we painting ourselves in a corner by using ext4?

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 21 07:41:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 08:41:50 +0100
Subject: Fedora I18n project meeting
References: <484617957.382511232445483125.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<2023807288.383841232447131742.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <gl6jjv$jmj$1@ger.gmane.org>

Jens Petersen wrote:
> The log of today's fedora-i81n meeting is now on
> 
> https://fedoraproject.org/wiki/I18N/Meetings/2009-01-20
> 
> if you missed it.

>From the log:
> <asgeirf> KDE4 had a feature called 'sonnet' which was supposed to do
> language detection and stuff... not sure if it was ever included though... 

Unfortunately, those features never got completed (mainly because Jacob
Rideout, who wanted to implement them, "vanished"). The Sonnet in KDE 4 is
mainly a port of KDE 3's KSpell2 with a slightly cleaned-up API. Features
beyond spellchecking may be added in a later 4.x release, but at the moment
they're just not there. :-( The algorithms which were supposed to be used
should be still there on developer blogs, but they haven't been implemented
in Sonnet.

        Kevin Kofler



From rawhide at fedoraproject.org  Wed Jan 21 08:16:56 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 21 Jan 2009 08:16:56 +0000 (UTC)
Subject: rawhide report: 20090121 changes
Message-ID: <20090121081656.152591F825F@releng2.fedora.phx.redhat.com>

Compose started at Wed Jan 21 06:01:02 UTC 2009

New package cjkuni-fonts
        Chinese Unicode TrueType fonts in Ming and Kai face.
New package cpphs
        C pre-processor for Haskell
New package cups-pk-helper
        A helper that makes system-config-printer use PolicyKit
New package gtkparasite
        A GUI debugging tool for GTK+ applications
New package mythes-it
        Italian thesaurus
New package mythes-mi
        Maori thesaurus
New package radial
        A simple program for calculating radial velocities of stars in a binary system
New package tunneler
        Clone of legendary Tunneler game
Removed package wxsvg
Updated Packages:

SDL_mixer-1.2.8-10.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Peter Robinson <pbrobinson at gmail.com> - 1.2.8-10
- Add Provides: SDL_mixer-midi in prep for moving samples to sub-package


TnL-data-071111-3.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 071111-3
- Adjust font requires for font rename (rh 480475)


alacarte-0.11.7-1.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 0.11.7-1
- Update to 0.11.7


alsa-lib-1.0.19-1.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Jaroslav Kysela <jkysela at redhat.com> - 1.0.19-1
- Updated to 1.0.19 final

* Tue Nov  4 17:00:00 2008 Jaroslav Kysela <jkysela at redhat.com> - 1.0.18-7
- Updated to 1.0.18 final


alsa-utils-1.0.19-1.fc11
------------------------
* Tue Jan 20 17:00:00 2009 Jaroslav Kysela <jkysela at redhat.com> 1.0.19-1
- updated to 1.0.19 final


at-spi-1.25.5-1.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1.25.5-1
- Update to 2.25.5


baekmuk-ttf-fonts-2.2-15.fc11
-----------------------------

blitz-0.9-8.fc11
----------------
* Tue Jan 20 17:00:00 2009 Sergio Pascual <sergiopr at fedoraproject.org> - 0.9-8
- New patch (from upstream) to build with gcc4.3


brasero-0.9.1-1.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.9.1-1
- Update to upstream 0.9.1
- Added development package


cairo-dock-2.0.0-0.3.svn1494_trunk.fc11
---------------------------------------
* Wed Jan 21 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1494


chkconfig-1.3.41-1
------------------
* Tue Jan 20 17:00:00 2009 Bill Nottingham <notting at redhat.com> 1.3.41-1
- restore return code & error on unconfigured services (#480805)


cmigemo-1.3-0.7.c_MIT.fc11
--------------------------
* Tue Jan 20 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1.3-0.7.c_MIT
- Also install zen2han (JD 6 comment 976)


collectl-3.1.2-1.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Dan Horak <dan[at]danny.cz> 3.1.2-1
- upgrade to upstream version 3.1.2


control-center-2.25.3-4.fc11
----------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-4
- Set HTTPS handler correctly when changing default browser (#480707)


e2fsprogs-1.41.3-4.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 1.41.3-4
- resize2fs fixes, esp. for ext4


eclipse-changelog-2.6.6-1.fc11
------------------------------
* Mon Jan 19 17:00:00 2009 Jeff Johnston <jjohnstn at redhat.com> 2.6.6-1
- 2.6.6.
- Fixes #260719, #260722, #261694, #261379

* Fri Jan  9 17:00:00 2009 Jeff Johnston <jjohnstn at redhat.com> 2.6.5-1
- 2.6.5.
- Fixes #260393


egoboo-data-2.7.5-4.fc11
------------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 2.7.5-4
- Fix dejavu font Requires (again) (#480448)


eog-2.25.5-1.fc11
-----------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


evince-2.25.5-1.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


evolution-2.25.5-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.5-1.fc11
- Update to 2.25.5
- Ditch eds_version and use our own version.  This will keep evolution
  and evolution-data-server versions in lockstep from now on.


evolution-exchange-2.25.5-1.fc11
--------------------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.5-1.fc11
- Update to 2.25.5
- Ditch eds_version and evo_version and use our own version.  This will
  keep evolution, evolution-exchange and evolution-data-server versions
  in lockstep from now on.


evolution-sharp-0.19.1-1.fc11
-----------------------------
* Mon Jan 19 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 0.19.1-1.fc11
- Update to 0.19.1


file-roller-2.25.2-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.2-1
- Update to 2.25.2


fontconfig-2.6.93-1.git.64.g6aa4dce.fc11
----------------------------------------
* Tue Jan 20 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.93-1.git.64.g6aa4dce
- Update to 2.6.93-1.git.64.g6aa4dce


freecol-0.8.0-1.fc11
--------------------
* Thu Jan 15 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.8.0-1
- New upstream release 0.8.0


freedink-1.08.20090120-1.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 Sylvain Beucler <beuc at beuc.net> - 1.08.20090120-1
- New upstream release (fix engine freeze in some DinkC scripts)


ganglia-3.1.1-4.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Kostas Georgiou <k.georgiou at imperial.ac.uk> - 3.1.1-4
- [480236] Updated patch for the buffer overflow from upstream with
  additional fixes


ganyremote-5.6-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Mikhail Fedotov <anyremote at mail.ru> - 5.6-1
- Check java client version on the web site


gcalctool-5.25.5-1.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 5.25.5-1
- Update to 2.25.5


gedit-2.25.5-1.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.5-1
- Update to 2.25.5


glib2-2.19.5-1.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.19.5-1
- Update to 2.19.5


gnome-applets-2.25.4-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.4-1
- Update to 2.25.4


gnome-keyring-2.25.5-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 2.25.5-1
- Update to 2.25.5


gnome-menus-2.25.5-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> 2.25.5-1
- Update to 2.25.5


gnome-panel-2.25.5-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


gnome-session-2.25.5-2.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.5-2
- Update to 2.25.5
- Fix BuildRequires


gnome-settings-daemon-2.25.3-4.fc11
-----------------------------------
* Mon Jan 19 17:00:00 2009 - Ray Strode <rstrode at redhat.com> - 2.25.3-4
- Update fade patch for new gnome-desktop release


gnome-system-monitor-2.24.4-1.fc11
----------------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.24.4-1
- Update to 2.24.4

* Fri Jan 16 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.24.3-1
- Update to 2.24.3

* Sun Nov 23 17:00:00 2008 Matthias Clasen <mclasen at redhat.com> - 2.24.1-2
- Improve description


gnome-terminal-2.25.5-1.fc11
----------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


gnome-themes-2.25.5-1.fc11
--------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


gnubg-0.9.0.1-6.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 1:0.9.0.1-6
- Fix for dejavu renaming, BZ 480456.


gok-2.25.3-2.fc11
-----------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.3-2
- Update to 2.25.3


gstreamer-0.10.22-1.fc11
------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.22-1
- Update to 0.10.22
- Remove upstreamed patches, update rpm provides patch


gstreamer-plugins-base-0.10.22-1.fc11
-------------------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.22-1
- Update to 0.10.22
- Remove upstreamed patches


gstreamer-plugins-good-0.10.11-5.fc11
-------------------------------------
* Wed Jan 21 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.10.11-5
- Rebuild for new gstreamer base library


gtksourceview2-2.5.3-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.5.3-1
- Update to 2.5.3


gvfs-1.1.4-1.fc11
-----------------
* Tue Jan 20 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 1.1.4-1
- Update to 1.1.4


hedgewars-0.9.9-1.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.9.9-1
- New upstream release 0.9.9
- Fix dejavu font Requires (again) (rh 480458)


httrack-3.43.2-1.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Debarshi Ray <rishi at fedoraproject.org> - 3.43.2-1
- Version bump to 3.43.2. Closes Red Hat Bugzilla bug #476110.
- Updated 'Requires: openssl = 0.9.8j' and fixed the sources for Rawhide.


initscripts-8.88-1
------------------
* Tue Jan 20 17:00:00 2009 Bill Nottingham <notting at redhat.com> - 8.88-1
- init.d/network: return success/failure correctly (#480677)
- init.d/halt: fix typo (#480799)


jd-2.2.0-0.2.svn2631_trunk.fc11
-------------------------------

kanyremote-5.6-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Mikhail Fedotov <anyremote at mail.ru> - 5.6-1
- Check java client version on the web site


kvm-83-2.fc11
-------------
* Tue Jan 20 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 83-2
- sdl sound output to avoid grabbing OSS and causing pulseaudio failure


libHX-2.3-1.fc11
----------------
* Tue Jan 20 17:00:00 2009 Till Maas <opensource at till.name> - 2.3-1
- Update to new release

* Mon Dec 29 17:00:00 2008 Till Maas <opensource at till.name> - 2.1-1
- Update to new release


libaio-0.3.107-7.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Jeff Moyer <jmoyer at redhat.com> - 0.3.107-7
- Fix the install to / patch.

* Wed Oct  1 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.3.107-6
- add patch with sparc support

* Wed Oct  1 18:00:00 2008 Dennis Gilmore <dennis at ausil.us> - 0.3.107-5
- remove ExclusiveArch line


liberation-fonts-1.04.93-6.fc11
-------------------------------

libgweather-2.25.5-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> 2.25.5-1
- Upate to 2.25.5


libwnck-2.25.5-1.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


lilypond-2.12.1-2.fc11
----------------------
* Wed Jan 14 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.12.1-2
- Implementing font_pkg.


mgopen-fonts-0.20050515-11.fc11
-------------------------------
* Tue Jan 20 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-11
- Fix comments from https://bugzilla.redhat.com/show_bug.cgi?id=477425#c5
  (thanks Nicolas Mailhot)
  - remove requires: fontpackages-filesystem from the main package, add it
    to the -common subpackage.
  - put space around "<" in  Obsoletes to make rpm understand it
  - provide fontconfig substitution rules for all the families (according to 
    http://www.ellak.gr/fonts/mgopen/index.en.html)


mousetweaks-2.25.5-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


nautilus-2.25.3-2.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Tomas Bzatek <tbzatek at redhat.com> - 2.25.3-1
- Update to 2.25.3

* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com>- 2.25.3-2
- Reenable the translation size reduction

* Mon Jan 19 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 2.25.2-7
- Update fade patch to work with updated gnome-desktop api
- Fix fade start pixmap


nexuiz-2.4.2-4.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.4.2-4
- Rebuild to fix odd icon issue, BZ 480686.


ogre-1.6.0-5.fc11
-----------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.6.0-5
- Adjust font requires for font rename (rh 480465)
use regular (full) instead of lgc dejavu fonts for the demos (rh 477434)


openct-0.6.15-3.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 0.6.15-3
- fix usrsbindir in configure (fix by Oskari Saarenmaa) (#480756)


openoffice.org-3.0.1-15.3.fc11
------------------------------
* Tue Jan 20 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-15.3
- Resolves: rhbz#480362 add
  openoffice.org-3.0.1.ooo98240.sc.basicworkaround.patch
- add mythes-it
- rhbz#477435 tweak to get font packaging macros to give a usable
  package


orca-2.25.5-1.fc11
------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


pciutils-3.1.0-1.fc11
---------------------
* Mon Jan 19 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> 3.1.0-1
- version 3.1.0


perl-Log-Log4perl-1.20-1.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 1.20-1
- Upstream update.
- Reactivate testsuite.
- Remove examples (eg, ldap) from %doc.
- Don't chmod -x eg/*.
- Remove BR: perl(IPC::Shareable).


policycoreutils-2.0.61-3.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-3
- Add Domains Page to system-config-selinux
- Add ability to create dbus confined applications to polgen


poppler-0.10.3-2.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.10.3-2
- add needed scriptlets
- nuke rpaths


pygsl-0.9.3-3.fc11
------------------
* Wed Jan 21 17:00:00 2009 Jos?? Matos <jamatos at fc.up.pt> - 0.9.3-3
- Rebuild for new gsl (F11+).


python-Coherence-0.6.0-2.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> 0.6.0-2
- Install the D-Bus service file so that the Totem plugin can work


rhythmbox-0.11.6-23.r6096.fc11
------------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.11.6-23.r6096
- Fix UPNP plugin for use with external Louie (#480036)


scorched3d-41.3-5.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 41.3-5
- Adjust font requires for font rename (rh 480471)


seahorse-adventures-1.0-4.fc11
------------------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.0-4
- Adjust font requires for font rename (rh 480472)


selinux-policy-3.6.3-2.fc11
---------------------------

sendmail-8.14.3-4.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 8.14.3-4
- build shared libmilter (#309281)
- drop static libraries
- convert RELEASE_NOTES to UTF-8


setup-2.7.6-1.fc11
------------------
* Tue Jan 20 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2.7.6-1
- make uidgid file better parseable (synchronize tabs)
- reserve gid 11 for group cdrom (udev,MAKEDEV)
- reserve gid 33 for group tape (udev,MAKEDEV)
- reserve gid 87 for group dialout (udev,MAKEDEV)


socat-1.7.0.0-1.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Paul Wouters <paul at xelerance.com 1.7.0.0-1
- Updated to new upstream version
- utf8 the CHANGES file


sugar-0.83.5-1.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.5-1
- make the journal entries in the favorites palette resumable
- simplify the constants used to identify favorite layouts
- separate debug settings from xsession #163
- add logout option #207 to xomenu (sayamindu, icon by eben)
- change jabber server without sugar restart #142
- About my XO -> About my Computer
- #196 Fix setting the timezone in debian
- autoconnect to AP that we connected to last #8
- add a favorites mode setting for deciding if the favorites view resumes by default or not
- resume by default the last activity from the favorites view
- implement filtering by file type for removable devices
- #132 Filter by timestamp, not by mtime
- add support for text queries on removable devices
- dont abort if we cannot read a file from a removable device
- add a favorite filter to the journal toolbar
- sanitize the file name when we copy to removable devices
- #36 Refresh the detailed view when the entry changes
- #38 Refresh full metadata when editing so we dont lose properties
- Focus Search is not exposed via dbus anymore #89
- #131 'open with' does not work for clipboard item
- #165 Install bundles when they get into the journal
- add Resume item to the file transfer palette
- #126 Fix erase button in the journal
- following eben's spec for the device positions


sugar-artwork-0.83.3-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.3-1
- add activity-journal icon to artwork
- add system-logout icon (part of #207)
- add everything needed for the colorpicker. That is a small icon and a bit in the gtkrc.
- fix triangular arrows by looking at the parent_bg_color option
- add icons for object transfers


sugar-base-0.83.3-2.fc11
------------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.3-2
- Don't print logs to tty instead of shell.log in the emulator
- Trivial port to GIO instead of GnomeVFS


sugar-datastore-0.83.2-1.fc11
-----------------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.2-1
- #181 Replace deprecated os.popen by subprocess
- #140 Crash when joining a shared Read


sugar-presence-service-0.83.3-2.fc11
------------------------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.3-2
- #142 Restart a server-based collaboration session / switch servers on the fly


sugar-toolkit-0.83.4-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 0.83.4-1
- separate debug settings from xsession #163
- show an alert on activity close for suggesting the user to set properties of the entry #215
- add a colorpicker to Sugar, only the ColorToolButton is public for now
- move the palette to new style gobject properties
- #3060 Add the possibility of filtering the object chooser by data type
- fix uninstallling of activities that use symlinks #171
- remove the hacks for asking the X server for screenshots and use gtk.Widget.get_snapshot() instead


tcpdump-3.9.8-7.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> - 14:3.9.8-7
- rebuild for new openssl
- convert CREDITS to UTF-8 (#226481)


telepathy-glib-0.7.23-1.fc11
----------------------------
* Tue Jan 20 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.23-1
- Update to 0.7.23.


terminator-0.12-1.fc11
----------------------
* Tue Jan 20 17:00:00 2009 Ian Weller <ianweller at gmail.com> 0.12-1
- New upstream release
- Upstream fixed desktop file, removing patch0


thunar-media-tags-plugin-0.1.2-5.fc11
-------------------------------------
* Tue Jan 20 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 0.1.2-5
- Rebuild for Thunar 0.9.93 (Xfce 4.6. Beta 3)


tkimg-1.4-0.3.20081115svn.fc11
------------------------------
* Tue Jan 20 17:00:00 2009 Sergio Pascual <sergiopr at fedoraproject.org>  1.4-0.3.20081115svn
- Adding libXft-devel to build requires

* Tue Jan 20 17:00:00 2009 Sergio Pascual <sergiopr at fedoraproject.org>  1.4-0.2.20081115svn
- Reverting patches to fix bz #468357


tomboy-0.13.3-1.fc11
--------------------
* Tue Jan 20 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 0.13.3-1
- Update to 0.13.3


trackballs-1.1.4-8.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.1.4-8
- Adjust font requires for font rename (rh 480476)


udev-136-2.fc11
---------------
* Tue Jan 20 17:00:00 2009 Harald Hoyer <harald at redhat.com> 136-2
- added some rule fixes, which will be in udev-137

* Tue Jan 20 17:00:00 2009 Harald Hoyer <harald at redhat.com> 136-1
- test for restorecon in start_udev before it is used (bug #480608)
- added groups video audio cdrom tape dialout in post
  (might be moved to MAKEDEV)
- version 136


virt-manager-0.6.0-7.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 Mark McLoughlin <markmc at redhat.com> - 0.6.0-7
- Add patch to ignore fix crash on force-poweroff with serial console (#470548)


wallpapoz-0.4.1-8.svn87_trunk.fc11
----------------------------------
* Wed Jan 21 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 0.4.1-8.svn87_trunk
- Always once kill daemon_wallpapoz process if it exists before start


wordwarvi-0.25-1.fc11
---------------------
* Tue Jan 20 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.25-1
- New upstream release 0.25


xmoto-0.5.0-4.fc11
------------------
* Tue Jan 20 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> 0.5.0-4
- Font requires change for BZ 480480, dejavu rename.


xsane-0.996-3.fc11
------------------
* Tue Jan 20 17:00:00 2009 Nils Philippsen <nphilipp at redhat.com> - 0.996-3
- pickup changed desktop file, close-fds patch in F9, F10

* Tue Jan 20 17:00:00 2009 Nils Philippsen <nphilipp at redhat.com> - 0.996-2
- BR: lcms-devel


yum-3.2.21-3.fc11
-----------------
* Tue Jan 20 17:00:00 2009 Seth Vidal <skvidal at fedoraproject.org> - 3.2.21-3
- add a small patch to make things play a bit nicer with the logging module
  in 2.6


Summary:
Added Packages: 8
Removed Packages: 1
Modified Packages: 100
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	lilypond-2.12.1-2.fc11.i386 requires lilypond-feta-fonts = 0:2.12.1-2.fc11
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mgopen-fonts-common-0.20050515-11.fc11.noarch requires fontpackages-fileysystem
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	lilypond-2.12.1-2.fc11.x86_64 requires lilypond-feta-fonts = 0:2.12.1-2.fc11
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mgopen-fonts-common-0.20050515-11.fc11.noarch requires fontpackages-fileysystem
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	lilypond-2.12.1-2.fc11.ppc requires lilypond-feta-fonts = 0:2.12.1-2.fc11
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mgopen-fonts-common-0.20050515-11.fc11.noarch requires fontpackages-fileysystem
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-moderna
	fedora-business-cards-0.2.4-2.fc11.noarch requires mgopen-fonts-modata
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	lilypond-2.12.1-2.fc11.ppc64 requires lilypond-feta-fonts = 0:2.12.1-2.fc11
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mgopen-fonts-common-0.20050515-11.fc11.noarch requires fontpackages-fileysystem
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From denis at poolshark.org  Wed Jan 21 08:48:54 2009
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Jan 2009 09:48:54 +0100
Subject: Alpha-freeze, when ?
Message-ID: <4976E176.5020906@poolshark.org>

When is the Alpha-freeze scheduled ? Must've missed some announcement...

-denis



From rakesh.pandit at gmail.com  Wed Jan 21 08:53:31 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Wed, 21 Jan 2009 14:23:31 +0530
Subject: Alpha-freeze, when ?
In-Reply-To: <4976E176.5020906@poolshark.org>
References: <4976E176.5020906@poolshark.org>
Message-ID: <b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>

2009/1/21 Denis Leroy <denis at poolshark.org>:
> When is the Alpha-freeze scheduled ? Must've missed some announcement...
>

"""
== F11 Alpha ==
* freeze on 2009-01-20
"""

https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01240.html

-- 
rakesh



From denis at poolshark.org  Wed Jan 21 08:59:01 2009
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Jan 2009 09:59:01 +0100
Subject: Alpha-freeze, when ?
In-Reply-To: <b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
References: <4976E176.5020906@poolshark.org>
	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
Message-ID: <4976E3D5.5010704@poolshark.org>

Rakesh Pandit wrote:
> 2009/1/21 Denis Leroy <denis at poolshark.org>:
>> When is the Alpha-freeze scheduled ? Must've missed some announcement...
>>
> 
> """
> == F11 Alpha ==
> * freeze on 2009-01-20
> """
> 
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01240.html

Well that's yesterday and I just saw a rawhide build report. So is the 
freeze in effect now, and are all builds from now on queued up until the 
freeze release ?

thx
-denis



From mtasaka at ioa.s.u-tokyo.ac.jp  Wed Jan 21 09:08:59 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Wed, 21 Jan 2009 18:08:59 +0900
Subject: Alpha-freeze, when ?
In-Reply-To: <4976E3D5.5010704@poolshark.org>
References: <4976E176.5020906@poolshark.org>	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
	<4976E3D5.5010704@poolshark.org>
Message-ID: <4976E62B.7040004@ioa.s.u-tokyo.ac.jp>

Denis Leroy wrote, at 01/21/2009 05:59 PM +9:00:
> Rakesh Pandit wrote:
>> 2009/1/21 Denis Leroy <denis at poolshark.org>:
>>> When is the Alpha-freeze scheduled ? Must've missed some announcement...
>> """
>> == F11 Alpha ==
>> * freeze on 2009-01-20
>> """
>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01240.html 
>>
> Well that's yesterday and I just saw a rawhide build report. So is the 
> freeze in effect now, and are all builds from now on queued up until the 
> freeze release ?

According to the explanation by Jesse, no.
https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00664.html

Mamoru



From debarshi.ray at gmail.com  Wed Jan 21 09:22:12 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Wed, 21 Jan 2009 14:52:12 +0530
Subject: rawhide report: 20090121 changes
In-Reply-To: <20090121081656.152591F825F@releng2.fedora.phx.redhat.com>
References: <20090121081656.152591F825F@releng2.fedora.phx.redhat.com>
Message-ID: <3170f42f0901210122h5cfdfffdn2be8088c5941a6c4@mail.gmail.com>

> New package gtkparasite
>        A GUI debugging tool for GTK+ applications

Is it really a good idea to put a program that has not yet been
released [1] into our stable Fedora 9 and Fedora 10 repositories? I
can understand that it is really useful, so maybe we could start off
in Rawhide and only expose it to the stable releases a bit later.

Cheers,
Debarshi
----
[1] http://chipx86.github.com/gtkparasite/#download



From kevin.kofler at chello.at  Wed Jan 21 09:39:09 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 10:39:09 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
Message-ID: <gl6qft$64i$1@ger.gmane.org>

Benjamin LaHaise wrote:
> I think the push for never allowing root to login is daft and
> inconsiderate of the needs of users who maintain systems.  I much prefer
> the F9 policy of putting up a warning and allowing me to proceed -- I know
> it's impossible to make everything on the desktop root-safe and I don't
> expect it.  The system should not decree that it knows better than me,
> though. 

Remove the offending line from your /etc/pam.d/gdm file.

And yes, I also think that default setting sucks (and FWIW, KDM currently
isn't set up that way).

        Kevin Kofler



From denis at poolshark.org  Wed Jan 21 09:41:06 2009
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Jan 2009 10:41:06 +0100
Subject: Alpha-freeze, when ?
In-Reply-To: <4976E62B.7040004@ioa.s.u-tokyo.ac.jp>
References: <4976E176.5020906@poolshark.org>	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>	<4976E3D5.5010704@poolshark.org>
	<4976E62B.7040004@ioa.s.u-tokyo.ac.jp>
Message-ID: <4976EDB2.6050108@poolshark.org>

Mamoru Tasaka wrote:
> Denis Leroy wrote, at 01/21/2009 05:59 PM +9:00:
>> Rakesh Pandit wrote:
>>> 2009/1/21 Denis Leroy <denis at poolshark.org>:
>>>> When is the Alpha-freeze scheduled ? Must've missed some 
>>>> announcement...
>>> """
>>> == F11 Alpha ==
>>> * freeze on 2009-01-20
>>> """
>>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01240.html 
>>>
>> Well that's yesterday and I just saw a rawhide build report. So is the 
>> freeze in effect now, and are all builds from now on queued up until 
>> the freeze release ?
> 
> According to the explanation by Jesse, no.
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00664.html 

Thanks for the clarification.
-denis



From abu_hurayrah at hidayahonline.org  Wed Jan 21 09:55:52 2009
From: abu_hurayrah at hidayahonline.org (Basil Mohamed Gohar)
Date: Wed, 21 Jan 2009 17:55:52 +0800
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <1232508488.4002.54.camel@ignacio.lan>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<1232508488.4002.54.camel@ignacio.lan>
Message-ID: <1232531752.3986.33.camel@localhost.localdomain>

On Tue, 2009-01-20 at 22:28 -0500, Ignacio Vazquez-Abrams wrote:

> On Tue, 2009-01-20 at 22:01 -0500, Benjamin LaHaise wrote:
> > On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
> > > You can at run level 3. You can even start X after that.
> > 
> > You're assuming all users of a system are technical.  That is not the case.
> 
> How would a non-technical user know to log in as root?


I knew about the root user in *nix long before I knew about run levels
and how to start X manually.  It's like the Administrator account in
Windows (at least, that's how most non-techies would understand it).
Besides, some references online will frequently mention logging-in as
root, even if it's not the most advisable.  So there are many vectors
through which someone can know about logging in as root without having
the strongest technical background.

________________________________________________________________________

Basil Mohamed Gohar
abu_hurayrah at hidayahonline.org
www.basilgohar.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/28a54b74/attachment.htm>
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/28a54b74/attachment.sig>

From denis at poolshark.org  Wed Jan 21 10:00:18 2009
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Jan 2009 11:00:18 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <1232531752.3986.33.camel@localhost.localdomain>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>	<1232508488.4002.54.camel@ignacio.lan>
	<1232531752.3986.33.camel@localhost.localdomain>
Message-ID: <4976F232.9090907@poolshark.org>

Basil Mohamed Gohar wrote:
> On Tue, 2009-01-20 at 22:28 -0500, Ignacio Vazquez-Abrams wrote:
>> On Tue, 2009-01-20 at 22:01 -0500, Benjamin LaHaise wrote:
>> > On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
>> > > You can at run level 3. You can even start X after that.
>> > 
>> > You're assuming all users of a system are technical.  That is not the case.
>>
>> How would a non-technical user know to log in as root?
> 
> I knew about the root user in *nix long before I knew about run levels 
> and how to start X manually.  It's like the Administrator account in 
> Windows (at least, that's how most non-techies would understand it).  
> Besides, some references online will frequently mention logging-in as 
> root, even if it's not the most advisable.  So there are many vectors 
> through which someone can know about logging in as root without having 
> the strongest technical background.

Wouldn't it be nice if there were a "launch console window" or "launch 
terminal window" option or button on the GDM login screen ? That 
certainly would solve the issues of people not familiar with getty 
screens and/or runlevels...



From petersen at redhat.com  Wed Jan 21 10:11:22 2009
From: petersen at redhat.com (Jens Petersen)
Date: Wed, 21 Jan 2009 05:11:22 -0500 (EST)
Subject: ibus and F11
In-Reply-To: <1111132440.717921232532196096.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <1860274932.718391232532682161.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

----- "Pete Zaitcev" <zaitcev at redhat.com> wrote:
> From the standpoint of Fedora's architecture in general, I am
> concerned with an emerging pattern of trying to fix issues by
> rewriting everything.
> Sure, IIIMF was a disaster and had to go, but SCIM is not that bad.
> For me, as a user, it's difficult to estimate just how big the
> advantage in maintainability is.

You have to understand that input methods projects are not big.
SCIM has architectural limitations that stop us doing things we
want to.  Fixing those would largely mean rewriting it anyway.

Jens



From sundaram at fedoraproject.org  Wed Jan 21 10:19:09 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Jan 2009 15:49:09 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121030132.GG19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
Message-ID: <4976F69D.2050805@fedoraproject.org>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
>> You can at run level 3. You can even start X after that.
> 
> You're assuming all users of a system are technical.  That is not the case.

Non technical users shouldn't be logging in as root and more so X. They 
should be either launching graphical programs that ask for a password or 
use su - or sudo. It an potentially be made easier by giving them a 
"administrator shell" or something like that in the menu which launches 
the terminal and asks for a root/sudo password but it would be better to 
understand why it is ever needed and solve that issue in a perhaps more 
elegant way.

What are the specific use cases, where non technical users are being 
compelled to login as root (and other alternatives won't work)?

Rahul



From ivazqueznet at gmail.com  Wed Jan 21 09:57:54 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 21 Jan 2009 04:57:54 -0500
Subject: rawhide report: 20090121 changes
In-Reply-To: <3170f42f0901210122h5cfdfffdn2be8088c5941a6c4@mail.gmail.com>
References: <20090121081656.152591F825F@releng2.fedora.phx.redhat.com>
	<3170f42f0901210122h5cfdfffdn2be8088c5941a6c4@mail.gmail.com>
Message-ID: <1232531874.4002.61.camel@ignacio.lan>

On Wed, 2009-01-21 at 14:52 +0530, Debarshi Ray wrote:
> > New package gtkparasite
> >        A GUI debugging tool for GTK+ applications
> 
> Is it really a good idea to put a program that has not yet been
> released [1] into our stable Fedora 9 and Fedora 10 repositories? I
> can understand that it is really useful, so maybe we could start off
> in Rawhide and only expose it to the stable releases a bit later.

It wasn't submitted for stable, it was submitted for testing. If someone
else takes issue with it being in there then I'll withdraw it.
Otherwise, I see no problem.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/251aeb8c/attachment.sig>

From kanarip at kanarip.com  Wed Jan 21 10:21:12 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 21 Jan 2009 11:21:12 +0100
Subject: Spins SIG Meeting Minutes 19-01-2009
Message-ID: <4976F718.9030702@kanarip.com>

These are the meeting minutes for our last meeting, and as you can see 
there's lots of stuff to do still, even some of our agenda items needed 
to be moved to our mailing list or to the next meeting.

The minutes are also available on the meeting wiki page at:

https://fedoraproject.org/wiki/Spins_SIG_Meeting_2009-01-19

Before the week is over, you'll see some threads on our Spins SIG list ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip

PS: Can someone point me to the irc2html log converter?

= Meeting Minutes =

== Attendees ==

* [[User:Kanarip|Jeroen van Meeuwen]]
* [[User:Bkearney|Bryan Kearney]]
* [[User:Bruno|Bruno Wolff]]
* [[User:Poelcat|John Poelstra]]
* [[User:Notting|Bill Nottingham]]
* [[User:Nirik|Kevin Fenzi]]
* [[User:Jwb|Josh Boyer]]
* [[User:Sundaram|Rahul Sundaram]]
* [[User:Huff|David Huff]]
* [[User:Igor|Igor Pires Soares]]

== Spins Process ==

* [[User:Kanarip]]: Q&A
* bkearney: Accepted means "will be composed and released through 
Release Engineering"?
** kanarip: Accepted means it'll be handed off to Release Engineering to 
be composed and released, and get a torrent and page on 
spins.fedoraproject.org
** poelcat: If it does not fail testing
* bruno: No wiki name space described for the Spins pages
** kanarip: /Foo_Spin or SIGs/Education/Education_Live_Spin
** nirik: $name_Spin would be better as wiki hates /'s
* bkearney: If trademark is not accepted, it is not a spin?
** kanarip: then it's a "Fedora Remix", and goes back to category 
Incomplete_Spin, yes
* kanarip: Take the process up for vote now, get people to draft up the 
details and review in 2 weeks
* kanarip: Vote is: Do you agree with the process set forth in the 
Spins_Process wiki page, bearing in mind some of the details still need 
to be filled out?
** kanarip, bkearney, nirik, bruno, notting, huff, igorps, poelcat: +1
** Vote passed
* kanarip: i need 1-3 volunteers who can take on the details on the 
process, the 5 sub-items for agenda item #1
** bryan, bruno, kanarip taking on the details on Spins_Process, up for 
review and voting during our next meeting in two weeks

== Action Items ==

* Create details pages up for review in our next meeting (bkearney, 
bruno, kanarip)

== Meeting Time and Schedule ==

* kanarip: Does the current time and schedule work for most of us?
** SIG: Yes
* kanarip: Meeting time and schedule set until someone brings it up again

== Determining the Spins SIG workflow ==

* kanarip: i'd like to see a more formalized set of tasks to be 
performed by the Spins SIG and the spin maintainers, so that we know 
when to branch off GIT, what to branch, what to compose(-test), what to 
expect from spin maintainers, etc.
** huff, bruno; since the process details are not there yet, part of the 
timeline and such isn't available to formalize

== Process of recurring releases ==

* The question is whether Spins that have been approved for Fedora N-1 
need to get trademark approval again
* The question also is what to do with the Wiki pages?
** nirik: How about they have to add a page for each release, but can 
automagically pass some steps? board approval? spins sig approval?
** kanarip: poelcat and myself have thought of a way to maintain the 
same page for different releases, linking to the release-specific 
revision of that page.
** poelcat: Overview pages would have to be modified
** kanarip: Category: package are overview pages
** ianweller chimes in but since there's only 10 minutes left, we need 
to take this to the fedora-wiki mailing list

== Action Items ==

* kanarip to take the recurring releases process wiki tracking 
discussion to the fedora-wiki mailing list

== Media larger then 4GB ==

* A vote was started, but due to the time constraint it didn't pass nor fail
* kanarip suggested bruno strips the Games spin to under 4GiB for now, 
so that it is not an issue, and revisit for Beta

== Action Item ==

* kanarip to put the 4GiB limit on the Agenda for the next meeting

== Current Spins ==

* Call for volunteers to check the current spin pages and add them to 
the appropriate category is moved to mailing list.




From denis at poolshark.org  Wed Jan 21 10:29:32 2009
From: denis at poolshark.org (Denis Leroy)
Date: Wed, 21 Jan 2009 11:29:32 +0100
Subject: rawhide report: 20090121 changes
In-Reply-To: <3170f42f0901210122h5cfdfffdn2be8088c5941a6c4@mail.gmail.com>
References: <20090121081656.152591F825F@releng2.fedora.phx.redhat.com>
	<3170f42f0901210122h5cfdfffdn2be8088c5941a6c4@mail.gmail.com>
Message-ID: <4976F90C.2030202@poolshark.org>

Debarshi Ray wrote:
>> New package gtkparasite
>>        A GUI debugging tool for GTK+ applications
> 
> Is it really a good idea to put a program that has not yet been
> released [1] into our stable Fedora 9 and Fedora 10 repositories? I
> can understand that it is really useful, so maybe we could start off
> in Rawhide and only expose it to the stable releases a bit later.

That's going a little far. The only people that will be exposed to it 
are those that are specifically looking for it, which probably will be 
very happy to find it available for F-9 or F-10...



From laxathom at fedoraproject.org  Wed Jan 21 10:34:59 2009
From: laxathom at fedoraproject.org (Xavier Lamien)
Date: Wed, 21 Jan 2009 11:34:59 +0100
Subject: Spins SIG Meeting Minutes 19-01-2009
In-Reply-To: <4976F718.9030702@kanarip.com>
References: <4976F718.9030702@kanarip.com>
Message-ID: <62bc09df0901210234x74f88d32mdc60c3ab97692275@mail.gmail.com>

On Wed, Jan 21, 2009 at 11:21 AM, Jeroen van Meeuwen
<kanarip at kanarip.com> wrote:
> These are the meeting minutes for our last meeting, and as you can see
> there's lots of stuff to do still, even some of our agenda items needed to
> be moved to our mailing list or to the next meeting.
>
> The minutes are also available on the meeting wiki page at:
>
> https://fedoraproject.org/wiki/Spins_SIG_Meeting_2009-01-19
>
> Before the week is over, you'll see some threads on our Spins SIG list ;-)
>
> Kind regards,
>
> Jeroen van Meeuwen
> -kanarip
>
> PS: Can someone point me to the irc2html log converter?

yum install irclog2html


-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB



From sundaram at fedoraproject.org  Wed Jan 21 11:39:34 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Jan 2009 17:09:34 +0530
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <gl6j8u$fn1$4@ger.gmane.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>
	<gl6j8u$fn1$4@ger.gmane.org>
Message-ID: <49770976.2070203@fedoraproject.org>

Kevin Kofler wrote:
> One question I couldn't find a definite answer to: Does btrfs-convert also
> work on ext4? In other words: Can we upgrade from ext3 to ext4 and then
> from ext4 to btrfs? Or are we painting ourselves in a corner by using ext4?

I asked this question to Eric Sandeen earlier on IRC and Chris Mason has 
confirmed that it should work. Someone probably needs to test that however.

Besides, Btrfs is probably going to take a couple more releases before 
it gets to the stage where we can trust it enough to use it as default 
and Ext4 provides us good advantages meanwhile.

Rahul




From pingou at pingoured.fr  Wed Jan 21 11:56:07 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Wed, 21 Jan 2009 12:56:07 +0100
Subject: Tracking new review requests?
In-Reply-To: <200901061431.53501.ville.skytta@iki.fi>
References: <200901061431.53501.ville.skytta@iki.fi>
Message-ID: <49770D57.2070803@pingoured.fr>

Ville Skytt? wrote:
> Hello,
> 
> I'd like to be notified about new Fedora package review requests by mail, only 
> once.  I'm currently subscribed to fedora-package-review which is otherwise 
> fine, except that I receive all of the review mail and not only the first 
> mail sent when a new review request is submitted.
> 
> I suppose I could set up a filter that gets the mails I'm not usually 
> interested out of the way, but I'd rather not receive anything but the first 
> one in the first place (unless I'm submitter/reviewer/cc'd of course, but 
> that's handled by direct mails).
> 
> Would it be possible to add a mailman topic to fedora-package-review that 
> receives only new submissions?  I don't know how mailman topics are 
> configured, but I suppose these can be detected by matching "New: " at the 
> beginning of the subject.  Any other solutions?
> 

Did you finally find a solution ?

Regards,

Pierre



From walters at verbum.org  Wed Jan 21 13:05:00 2009
From: walters at verbum.org (Colin Walters)
Date: Wed, 21 Jan 2009 08:05:00 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121025533.GF19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
Message-ID: <faa16b610901210505x4faa71e1s424a9e576249c16c@mail.gmail.com>

On Tue, Jan 20, 2009 at 9:55 PM, Benjamin LaHaise <bcrl at kvack.org> wrote:
>  if / and /tmp get full, it's impossible to login as a
> normal user,

This is the real bug.  What we need is a system that detects this
condition very early on login and initiates a program to help you
clean things up.



From christoph.wickert at googlemail.com  Wed Jan 21 13:20:02 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 21 Jan 2009 14:20:02 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121025533.GF19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
Message-ID: <1232544002.3448.5.camel@wicktop.localdomain>

Am Dienstag, den 20.01.2009, 21:55 -0500 schrieb Benjamin LaHaise:
> 
> I think the push for never allowing root to login is daft and inconsiderate 
> of the needs of users who maintain systems. 

I don't think so, but if you _really_ want to enable root login in gdm,
edit /etc/pam.d/gdm comment out the line reading

        auth required pam_succeed_if.so user != root quiet

Simple as that.

Regards,
Christoph




From dominik at greysector.net  Wed Jan 21 13:24:19 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 21 Jan 2009 14:24:19 +0100
Subject: ibus and F11
In-Reply-To: <1232496998.3759.11.camel@localhost.localdomain>
References: <511187499.336701232409913305.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20090120153053.GC14182@mokona.greysector.net>
	<1232496998.3759.11.camel@localhost.localdomain>
Message-ID: <20090121132419.GB23450@mokona.greysector.net>

On Wednesday, 21 January 2009 at 01:16, Ding-Yi Chen wrote:
> 
> ? ??2009-01-20 ? 16:30 +0100?Dominik 'Rathann' Mierzejewski ???
> > On Tuesday, 20 January 2009 at 01:06, Jens Petersen wrote:
> > > ----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> > > > What's the migration path for SCIM users?
> > > 
> > > Users upgrading from earlier Fedora releases can continue to use scim
> > > or if they wish they can install ibus themselves and use that.  Scim
> > > will be continue to be in Fedora for the time being.
> > 
> > But if I install ibus, I'll have to configure it from scratch, right?
> > There is no settings migration from SCIM, is there?
> 
> No, as it usually only involves a few mouse clicks or may be some key
> press.
> 
> Just curious, what settings you did that make you think that the
> settings migration would be a necessity? 

Keyboard shortcut settings. Reconfiguring them is time-consuming.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jam at zoidtechnologies.com  Wed Jan 21 13:36:32 2009
From: jam at zoidtechnologies.com (Jeff MacDonald)
Date: Wed, 21 Jan 2009 08:36:32 -0500
Subject: Proxy error upon Red Hat Bugzilla request_new_account
In-Reply-To: <4976493B.8090807@fedoraproject.org>
References: <4976493B.8090807@fedoraproject.org>
Message-ID: <200901210836.36005.jam@zoidtechnologies.com>

On Tuesday 20 January 2009 16:59:23 Davide Cescato wrote:
> As my very first contribution to Fedora, I have my first bug report to
> file. I am in the process of creating a new Red Hat Bugzilla account for
> this purpose, but a proxy error blocks my way.
>

Is your browser configured to use any kind of proxy? Does your service provider 
put a proxy between you and the Bugzilla instance? I've seen this problem 
before in the wild, so I do not think it is specific to this instance of 
Bugzilla.



From rdieter at math.unl.edu  Wed Jan 21 14:04:25 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 21 Jan 2009 08:04:25 -0600
Subject: k3b permissions
References: <1232436704.6740.8.camel@PB3.Linux>
Message-ID: <gl7a1k$qoj$1@ger.gmane.org>

Paul wrote:

> k3b works fine as a non su user, but won't allow me to burn discs. I'm
> suspecting something has happened in glibc or selinux to change the
> permissions, but even if I chown /dev/sr0 to being mine, it reverts back
> to being root.
> 
> Any ideas on fixing this?

ConsoleKit is supposed to grant permissions for local devices and such on
login.  

What does this say?
getfacl /dev/sr0

-- Rex



From ceski at fedoraproject.org  Wed Jan 21 14:04:51 2009
From: ceski at fedoraproject.org (Davide Cescato)
Date: Wed, 21 Jan 2009 15:04:51 +0100
Subject: Proxy error upon Red Hat Bugzilla request_new_account
In-Reply-To: <200901210836.36005.jam@zoidtechnologies.com>
References: <4976493B.8090807@fedoraproject.org>
	<200901210836.36005.jam@zoidtechnologies.com>
Message-ID: <49772B83.7000807@fedoraproject.org>

I experience the same problem both from home and from work (two 
different ISPs). In both cases, the browser is configured not to use a 
proxy, and furthermore I can access lots of bug web pages hosted on the 
same web server (https://bugzilla.redhat.com/) that handles the 
request_new_account form. So I would exclude the possibility of a proxy 
set up by the ISPs.

The strange thing is that if I pick a password which is too short, or 
even if the two passwords do not match, the script token.cgi that 
processes the form generates a Bugzilla web page containing a specific 
error message, whereas if the form is filled in correctly, that very 
same script fails with "502 Proxy Error."

Whatever its source is, the problem does not seem a transient one, since 
it is still occurs now as it did about 16 hours ago.

The last sentence in my previous e-mail should have read "After all, the 
ability of reporting bugs IS one key aspect of Fedora development."

Jeff MacDonald wrote:
> On Tuesday 20 January 2009 16:59:23 Davide Cescato wrote:
>> As my very first contribution to Fedora, I have my first bug report to
>> file. I am in the process of creating a new Red Hat Bugzilla account for
>> this purpose, but a proxy error blocks my way.
>>
> 
> Is your browser configured to use any kind of proxy? Does your service provider 
> put a proxy between you and the Bugzilla instance? I've seen this problem 
> before in the wild, so I do not think it is specific to this instance of 
> Bugzilla.
> 



From stickster at gmail.com  Wed Jan 21 14:07:15 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 21 Jan 2009 09:07:15 -0500
Subject: [Fedora-spins] Spins SIG Meeting Minutes 19-01-2009
In-Reply-To: <4976F718.9030702@kanarip.com>
References: <4976F718.9030702@kanarip.com>
Message-ID: <20090121140715.GB30705@localhost.localdomain>

On Wed, Jan 21, 2009 at 11:21:12AM +0100, Jeroen van Meeuwen wrote:
> PS: Can someone point me to the irc2html log converter?

You may already have an answer, but there's now a package in Fedora:

yum install irclog2html

-- 
Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/9e189569/attachment.sig>

From walters at verbum.org  Wed Jan 21 14:26:42 2009
From: walters at verbum.org (Colin Walters)
Date: Wed, 21 Jan 2009 09:26:42 -0500
Subject: Python and /etc/resolv.conf changes
In-Reply-To: <faa16b610901201719s637c631ah178119f833b59d5@mail.gmail.com>
References: <1232495310.3539.172.camel@localhost.localdomain>
	<faa16b610901201719s637c631ah178119f833b59d5@mail.gmail.com>
Message-ID: <faa16b610901210626w34b7158bka26246ca5d2b3979@mail.gmail.com>

On Tue, Jan 20, 2009 at 8:19 PM, Colin Walters <walters at verbum.org> wrote:
>
> Both Debian/Ubuntu
> (http://patches.ubuntu.com/g/glibc/extracted/any/local-dynamic-resolvconf.diff)
> and OpenSUSE (http://download.opensuse.org/distribution/11.0/repo/src-oss/suse/src/glibc-2.8-14.1.src.rpm,
> resolv.dynamic.diff) ship a patch to glibc which stats() resolv.conf.
> We do not.

Thinking about this a bit more this morning on the shuttle, there's a
strong argument that this is a glibc bug, and that the stat() approach
is a correct fix, if not necessarily the most ideal one.  That
argument is simply that glibc is caching data without a mechanism for
invalidation; and a cache without invalidation is always a bug.



From tgl at redhat.com  Wed Jan 21 14:38:59 2009
From: tgl at redhat.com (Tom Lane)
Date: Wed, 21 Jan 2009 09:38:59 -0500
Subject: Alpha-freeze, when ? 
In-Reply-To: <4976EDB2.6050108@poolshark.org> 
References: <4976E176.5020906@poolshark.org>
	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
	<4976E3D5.5010704@poolshark.org>
	<4976E62B.7040004@ioa.s.u-tokyo.ac.jp>
	<4976EDB2.6050108@poolshark.org>
Message-ID: <1207.1232548739@sss.pgh.pa.us>

Denis Leroy <denis at poolshark.org> writes:
> Mamoru Tasaka wrote:
>> Denis Leroy wrote, at 01/21/2009 05:59 PM +9:00:
>>> Well that's yesterday and I just saw a rawhide build report. So is the 
>>> freeze in effect now, and are all builds from now on queued up until 
>>> the freeze release ?
>> 
>> According to the explanation by Jesse, no.
>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00664.html 
> Thanks for the clarification.

The clarification I'd like is an all-clear signal that the alpha tag has
been made and we can go back to breaking rawhide ;-).  According to the
stated schedule it should have been done by now; so will I get my wrist
slapped if I push mysql 5.1 today?

			regards, tom lane



From jwboyer at gmail.com  Wed Jan 21 14:41:59 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 21 Jan 2009 09:41:59 -0500
Subject: Alpha-freeze, when ?
In-Reply-To: <1207.1232548739@sss.pgh.pa.us>
References: <4976E176.5020906@poolshark.org>
	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
	<4976E3D5.5010704@poolshark.org>
	<4976E62B.7040004@ioa.s.u-tokyo.ac.jp>
	<4976EDB2.6050108@poolshark.org> <1207.1232548739@sss.pgh.pa.us>
Message-ID: <20090121144159.GA24965@yoda.jdub.homelinux.org>

On Wed, Jan 21, 2009 at 09:38:59AM -0500, Tom Lane wrote:
>Denis Leroy <denis at poolshark.org> writes:
>> Mamoru Tasaka wrote:
>>> Denis Leroy wrote, at 01/21/2009 05:59 PM +9:00:
>>>> Well that's yesterday and I just saw a rawhide build report. So is the 
>>>> freeze in effect now, and are all builds from now on queued up until 
>>>> the freeze release ?
>>> 
>>> According to the explanation by Jesse, no.
>>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00664.html 
>> Thanks for the clarification.
>
>The clarification I'd like is an all-clear signal that the alpha tag has
>been made and we can go back to breaking rawhide ;-).  According to the
>stated schedule it should have been done by now; so will I get my wrist
>slapped if I push mysql 5.1 today?

[jwboyer at yoda ~]$ koji list-tags | grep f11-alpha
f11-alpha
[jwboyer at yoda ~]$ koji list-tag-inheritance f11-alpha
f11-alpha (75)
[jwboyer at yoda ~]$ 

I don't know the answer to the wrist slap question.

josh



From craftjml at gmail.com  Wed Jan 21 15:18:08 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 21 Jan 2009 09:18:08 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4976F69D.2050805@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
Message-ID: <20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>

On Wed, Jan 21, 2009 at 4:19 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> What are the specific use cases, where non technical users are being
> compelled to login as root (and other alternatives won't work)?

The chief compelling one he mentions seems to be when NFS goes down
and Linux can't find the /home partition.

Or, to put it bluntly, when the Linux distribution isn't smart enough
to protect "non-technical users" (an admittedly subjective term) from
technical problems.  Which is often.

But your critique, Mr. Sundaram, doesn't seem to imply that people
shouldn't login as root -- merely that you disagree with allowing them
to open a root session in X.  To be rhetorical, we must ask, why?
After all, there's no such thing as "partial root power" -- you either
have full root privileges in a terminal in a normal user X session, or
full root privileges in a root X session.

Here's the why:  you feel that a root X session is too insecure --
which it may indeed be.  So we believe that the "ideal" method is to
not allow X root logins.  But keep in mind, this is not actually an
ideal.  It's a kludge to go around the fact that X is designed rather
horribly from a security standpoint.  The "user session only" method
allows you to work around that.

But in the above case, user-session-X goes down.  You say login at
runlevel 3.  But let's face it, many users comfortable with Linux
still aren't at the "I roll my own shell-scripts" stage -- they still
work in GUI mentalities, and odds are, even if they can roll their own
shell-scripts, they won't understand how to fix administrative errors
as well as if they use the actual GUI administrative tools.

For most users, the GUI is critical for maintaining their system.  So
it is critical that the GUI be not allowed to fail.

Hence, leave the root-session-X backdoor open, (perhaps with a catch
-- for example, network functionality is disabled in root-session-X --
so that the only possible errors can come from user error, rather than
security vulnerabilities.  how about that?) or come up with another
solution.  "No GUI" for the sake of safety is a no-go solution for
many people.



From ihok at hotmail.com  Wed Jan 21 15:24:50 2009
From: ihok at hotmail.com (Jack Tanner)
Date: Wed, 21 Jan 2009 15:24:50 +0000 (UTC)
Subject: plans for kernel in F10?
Message-ID: <loom.20090121T152315-474@post.gmane.org>

There are two recent kernels built in Koji:

kernel-2.6.27.12-170.2.5.fc10
kernel-2.6.28.1-17.fc10

So, is F10 on the 2.6.27 track, or on the 2.6.28 track?

Thanks!



From kyle at mcmartin.ca  Wed Jan 21 15:32:44 2009
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Wed, 21 Jan 2009 10:32:44 -0500
Subject: plans for kernel in F10?
In-Reply-To: <loom.20090121T152315-474@post.gmane.org>
References: <loom.20090121T152315-474@post.gmane.org>
Message-ID: <20090121153244.GD27998@bombadil.infradead.org>

On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
> There are two recent kernels built in Koji:
> 
> kernel-2.6.27.12-170.2.5.fc10
> kernel-2.6.28.1-17.fc10
> 
> So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
> 

2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
fixes.

regards, Kyle



From bcrl at kvack.org  Wed Jan 21 15:53:44 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 10:53:44 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4976F69D.2050805@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
Message-ID: <20090121155344.GI19788@kvack.org>

On Wed, Jan 21, 2009 at 03:49:09PM +0530, Rahul Sundaram wrote:
> Benjamin LaHaise wrote:
> >On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
> >>You can at run level 3. You can even start X after that.
> >
> >You're assuming all users of a system are technical.  That is not the case.
> 
> Non technical users shouldn't be logging in as root and more so X. They 
> should be either launching graphical programs that ask for a password or 
> use su - or sudo. It an potentially be made easier by giving them a 
> "administrator shell" or something like that in the menu which launches 
> the terminal and asks for a root/sudo password but it would be better to 
> understand why it is ever needed and solve that issue in a perhaps more 
> elegant way.

And how do you propose that a user login to fix a problem when they call 
tech support saying "I get a blank screen when I login"?   I'm curious, 
because these are real world cases where the GUI login fails.  By disallowing 
root logins, there is no way to fix that short of rebooting the system to 
even narrow down what the problem is.  Even then, with F10 using a 0 second 
wait at the grub prompt, it's almost impossible to catch grub in time to 
specify the runlevel or init=/bin/sh.

> What are the specific use cases, where non technical users are being 
> compelled to login as root (and other alternatives won't work)?

Systems break, and administrators need to fix them.  There are plenty of 
non-technical business users who have local technical users who maintain 
the systems.  Making life harder for these people when systems break is 
just plain stupid.

		-ben



From sandeen at redhat.com  Wed Jan 21 16:07:03 2009
From: sandeen at redhat.com (Eric Sandeen)
Date: Wed, 21 Jan 2009 10:07:03 -0600
Subject: BTRFS 0.17 in rawhide (at some point)
In-Reply-To: <49770976.2070203@fedoraproject.org>
References: <1b7401870901121316u2275fc1an195a543cf2607fd3@mail.gmail.com>	<gl6j8u$fn1$4@ger.gmane.org>
	<49770976.2070203@fedoraproject.org>
Message-ID: <49774827.3070309@redhat.com>

Rahul Sundaram wrote:
> Kevin Kofler wrote:
>> One question I couldn't find a definite answer to: Does btrfs-convert also
>> work on ext4? In other words: Can we upgrade from ext3 to ext4 and then
>> from ext4 to btrfs? Or are we painting ourselves in a corner by using ext4?
> 
> I asked this question to Eric Sandeen earlier on IRC and Chris Mason has 
> confirmed that it should work. Someone probably needs to test that however.
> 
> Besides, Btrfs is probably going to take a couple more releases before 
> it gets to the stage where we can trust it enough to use it as default 
> and Ext4 provides us good advantages meanwhile.

It does basically work; the ext4 snapshot is bloated because the tool
doesn't understand uninitialized ext4 block groups, but that's just a
detail.  (But yes, I did test this).

Because the tool was properly written to use libext2fs, ext4 should
"just work" (modulo some little kinks like above).  :)

-Eric



From sundaram at fedoraproject.org  Wed Jan 21 16:20:54 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Jan 2009 21:50:54 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121155344.GI19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>
Message-ID: <49774B66.6050408@fedoraproject.org>

Benjamin LaHaise wrote:

> 
> And how do you propose that a user login to fix a problem when they call 
> tech support saying "I get a blank screen when I login"?   I'm curious, 
> because these are real world cases where the GUI login fails. 

If the GUI login, your fallback is command line, obviously. Having had 
support experience for a good number of years, I can tell you that, 
instructing people to type some command is far more easier as well.

Rahul



From robert at marcanoonline.com  Wed Jan 21 16:20:58 2009
From: robert at marcanoonline.com (Robert Marcano)
Date: Wed, 21 Jan 2009 11:50:58 -0430
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
Message-ID: <1232554858.4932.13.camel@localhost.localdomain>

On Wed, 2009-01-21 at 09:18 -0600, Jud Craft wrote:
> On Wed, Jan 21, 2009 at 4:19 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:

> Hence, leave the root-session-X backdoor open, (perhaps with a catch
> -- for example, network functionality is disabled in root-session-X --
> so that the only possible errors can come from user error, rather than
> security vulnerabilities.  how about that?) or come up with another
> solution.  "No GUI" for the sake of safety is a no-go solution for
> many people.
> 

To login as root on a X session does not only generates security
vulnerabilities, have you thought of people just dragging and
dropping /usr to another location by mistake (I know people that tried),
at least on Windows platforms you get a message about the directory
being used if you try to move/rename C:\windows, and how many of you
have not dragged by mistake a file and dropped it without noticing?
(dumb trackpads, long live trackpoints :-P)

The root console on GDM is a nice idea, but what about adding access to
the GNOME menu System->Administration, use case: I need to add a new
user to the system I only manage without a local user for me, some users
prefer to add the user using the GUI, instead of running adduser



From kevin at finway.co.uk  Wed Jan 21 16:23:17 2009
From: kevin at finway.co.uk (Kevin Coffin)
Date: Wed, 21 Jan 2009 16:23:17 +0000
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <1232499290.10991.1.camel@localhost.localdomain>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
Message-ID: <1232554997.3610.11.camel@warbird.finway.co.uk>

On Tue, 2009-01-20 at 17:54 -0700, Linuxguy123 wrote:
> On Mon, 2009-01-19 at 17:20 -0700, Linuxguy123 wrote:
> > I'm doing some embedded development and my flash programmer has a USB
> > interface.  Everything works fine if I program the device as root, but
> > I'd like to be able to do it as a regular user.  I get port permission
> > errors if I try to run the programmer as a regular user.
> > 
> > $ lsusb
> > Bus 002 Device 003: ID 064e:a101 Suyin Corp. Laptop integrated WebCam
> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 007 Device 006: ID 15ba:0003 Olimex Ltd. OpenOCD JTAG
> > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 006 Device 002: ID 046d:c512 Logitech, Inc. LX-700 Cordless Desktop
> > Receiver
> > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 005 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial
> > Port
> > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 001 Device 004: ID 07ca:a321 AVerMedia Technologies, Inc.
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > Bus 003 Device 003: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth +
> > WLAN) Interface [Integrated Module]
> > Bus 003 Device 002: ID 08ff:2580 AuthenTec, Inc. AES2501 Fingerprint
> > Sensor
> > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> > 
> > 
> > My programmer is the Olimex Ltd. OpenOCD JTAG device on bus 7.
> > 
> > The documentation for the device says it needs access to /proc/bus/usb.
> > 
> > I can allow regular user access by manually issuing a chown command for
> > the port, but then I'd have to do it every time I reboot or unplug the
> > programmer.   How do I set it up to happen automatically in F10 ?
> > 
> > Thanks !
> 
> Anyone ?
> 

I did the following for accessing my jtag device.
Created /usr/share/hal/fdi/information/20thirdparty/10-olimex-programmer.fdi containing :-

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>

    <!-- Grant access to program the Olimex devices to uucp group. -->

  <!-- <match key="info.subsystem" contains="usb_device"> -->
      <match key="usb_device.vendor_id" int="0x15ba">
         <append key="info.capabilities"
type="strlist">olimex-device</append>
          <append key="info.capabilities"
type="strlist">access_control</append>
          <merge key="access_control.file"
type="copy_property">linux.device_file</merge>
          <merge key="access_control.type"
type="string">olimex-device</merge>
          <merge key="access_control.grant_group"
type="strlist">uucp</merge>
     </match>
    <!-- </match> -->
  </device>
</deviceinfo>

I then added myself to the uucp group and rebooted, for some reason
restarting haldaemon did not work correctly. Now openocd works without
having to be root. Hope this helps.

I do wish this udev/hal/policykit magic was better documented.

Kevin




From sundaram at fedoraproject.org  Wed Jan 21 16:29:55 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 21 Jan 2009 21:59:55 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
Message-ID: <49774D83.9000509@fedoraproject.org>

Jud Craft wrote:

> 
> Or, to put it bluntly, when the Linux distribution isn't smart enough
> to protect "non-technical users" (an admittedly subjective term) from
> technical problems.  Which is often.

Then let's fix that problem.

> But your critique, Mr. Sundaram, doesn't seem to imply that people
> shouldn't login as root -- merely that you disagree with allowing them
> to open a root session in X.  To be rhetorical, we must ask, why?
> After all, there's no such thing as "partial root power" -- you either
> have full root privileges in a terminal in a normal user X session, or
> full root privileges in a root X session.

There is a big difference in terms of security between a person, login 
in as a non-root user and then doing su - compared to a root X session. 
Having a root X shell makes it trivial to damage your system 
accidentally as well.

> Here's the why:  you feel that a root X session is too insecure --
> which it may indeed be.  So we believe that the "ideal" method is to
> not allow X root logins.  But keep in mind, this is not actually an
> ideal.  It's a kludge to go around the fact that X is designed rather
> horribly from a security standpoint.  The "user session only" method
> allows you to work around that.

While moving X out of root is the right decision and work is being done 
on that, it is also going to take more time. Meanwhile, it is always 
good to run programs with the least amount of privileges possible as a 
basic security principle. That isn't a kludge.

> But in the above case, user-session-X goes down.  You say login at
> runlevel 3.  But let's face it, many users comfortable with Linux
> still aren't at the "I roll my own shell-scripts" stage -- they still
> work in GUI mentalities, and odds are, even if they can roll their own
> shell-scripts, they won't understand how to fix administrative errors
> as well as if they use the actual GUI administrative tools.

If they can't fix it, then they are going to need somebody else to help 
it. If you don't know what you are doing, you shouldn't be playing 
around in a root shell.
> 
> For most users, the GUI is critical for maintaining their system.  So
> it is critical that the GUI be not allowed to fail.

I am not sure about most but no disagreement on that in principle, we 
should take steps to avoid failure.

> 
> Hence, leave the root-session-X backdoor open, (perhaps with a catch
> -- for example, network functionality is disabled in root-session-X --
> so that the only possible errors can come from user error, rather than
> security vulnerabilities.  how about that?) or come up with another
> solution.

That isn't a solution since network capabilities are how you 
troubleshoot the problem in my instances.

   "No GUI" for the sake of safety is a no-go solution for
> many people.

It isn't no GUI however. It is about minimizing the number of programs 
running with elevates privileges.

Rahul



From txtoth at gmail.com  Wed Jan 21 17:25:18 2009
From: txtoth at gmail.com (Xavier Toth)
Date: Wed, 21 Jan 2009 11:25:18 -0600
Subject: plans for kernel in F10?
In-Reply-To: <20090121153244.GD27998@bombadil.infradead.org>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
Message-ID: <cadfc0e40901210925q621f06cfl3724fd157638cfe2@mail.gmail.com>

On Wed, Jan 21, 2009 at 9:32 AM, Kyle McMartin <kyle at mcmartin.ca> wrote:
> On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
>> There are two recent kernels built in Koji:
>>
>> kernel-2.6.27.12-170.2.5.fc10
>> kernel-2.6.28.1-17.fc10
>>
>> So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
>>
>
> 2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
> fixes.
>
> regards, Kyle
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

You can get a 2.6.28 fc10 kernel from koji
(http://koji.fedoraproject.org/koji/packageinfo?packageID=8)

Ted



From jonstanley at gmail.com  Wed Jan 21 17:30:34 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 21 Jan 2009 12:30:34 -0500
Subject: Koji: ServerOffline
In-Reply-To: <1232520824.3036.6.camel@localhost.localdomain>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
	<1232446160.9222.20.camel@localhost.localdomain>
	<62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>
	<1232449536.9222.30.camel@localhost.localdomain>
	<1232520824.3036.6.camel@localhost.localdomain>
Message-ID: <da159fda0901210930x274d57ddt564cc99b9cc1294f@mail.gmail.com>

On Wed, Jan 21, 2009 at 1:53 AM, Jitesh Shah <jiteshs at marvell.com> wrote:

> Any pointers as to why this might be happening?

fedora-buildsys-list might get you better response.



From loganjerry at gmail.com  Wed Jan 21 17:44:07 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 21 Jan 2009 10:44:07 -0700
Subject: Edits to Emacs packaging guidelines page
Message-ID: <870180fe0901210944q65cfcc98r769ddde46e261bae@mail.gmail.com>

The wiki tells me that I don't have permission to edit
https://fedoraproject.org/wiki/Packaging:Emacs.  Will someone who can
edit that page please make the following changes?

Under "Location of installed files", subheading "XEmacs", add a "lisp"
subdirectory to both paths, like so:

%define xemacs_lispdir %{_datadir}/xemacs/site-packages/lisp
%define xemacs_startdir %{_datadir}/xemacs/site-packages/lisp/site-start.d

Under "Requires for GNU Emacs and XEmacs", subheading "Determining the
Required (X)Emacs version at package build time", change

%define emacs_version 22.1

to

%define emacs_version 22.2

Under "Templates for Emacsen add-on package spec files", make both of
the above changes in the first template, and the second change in the
second template.

Thanks,
-- 
Jerry James, who wonders why the wiki pages with problems he knows how
to fix are almost never editable by him
http://loganjerry.googlepages.com/



From mw_triad at users.sourceforge.net  Wed Jan 21 17:49:09 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 21 Jan 2009 11:49:09 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121155344.GI19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>
Message-ID: <gl7n6l$c00$1@ger.gmane.org>

Benjamin LaHaise wrote:
> Even then, with F10 using a 0 second 
> wait at the grub prompt, it's almost impossible to catch grub in time to 
> specify the runlevel or init=/bin/sh.

No it's not (as I know from personal experience[1]). Start holding F8 as 
your BIOS is completing POST. It's not only possible, it's not even 
especially hard (the hardest part by far is simply remembering to do it).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=478878

...which, btw, no one seems to be working on. Good to know that Fedora 
cares that I can't boot an updated kernel.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Inches: An antiquated measurement unit still in use in certain 
backwards countries with incredibly low-cost computer equipment."
   -- groff documentation



From mw_triad at users.sourceforge.net  Wed Jan 21 17:54:42 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 21 Jan 2009 11:54:42 -0600
Subject: plans for kernel in F10?
In-Reply-To: <20090121153244.GD27998@bombadil.infradead.org>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
Message-ID: <gl7nh3$ehi$1@ger.gmane.org>

Kyle McMartin wrote:
> On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
>> There are two recent kernels built in Koji:
>>
>> kernel-2.6.27.12-170.2.5.fc10
>> kernel-2.6.28.1-17.fc10
>>
>> So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
>>
> 
> 2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
> fixes.

I don't suppose any of those fixes would relate to 
https://bugzilla.redhat.com/show_bug.cgi?id=478878 or 
https://bugzilla.redhat.com/show_bug.cgi?id=475495 (i.e. people that 
/can't boot new kernels/)?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"Inches: An antiquated measurement unit still in use in certain 
backwards countries with incredibly low-cost computer equipment."
   -- groff documentation



From jonathan.underwood at gmail.com  Wed Jan 21 18:07:04 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 21 Jan 2009 18:07:04 +0000
Subject: Edits to Emacs packaging guidelines page
In-Reply-To: <870180fe0901210944q65cfcc98r769ddde46e261bae@mail.gmail.com>
References: <870180fe0901210944q65cfcc98r769ddde46e261bae@mail.gmail.com>
Message-ID: <645d17210901211007w24f3936ft35a850b51ec41019@mail.gmail.com>

2009/1/21 Jerry James <loganjerry at gmail.com>:
> The wiki tells me that I don't have permission to edit
> https://fedoraproject.org/wiki/Packaging:Emacs.  Will someone who can
> edit that page please make the following changes?
>
> Under "Location of installed files", subheading "XEmacs", add a "lisp"
> subdirectory to both paths, like so:
>
> %define xemacs_lispdir %{_datadir}/xemacs/site-packages/lisp
> %define xemacs_startdir %{_datadir}/xemacs/site-packages/lisp/site-start.d
>
> Under "Requires for GNU Emacs and XEmacs", subheading "Determining the
> Required (X)Emacs version at package build time", change
>
> %define emacs_version 22.1
>
> to
>
> %define emacs_version 22.2
>
> Under "Templates for Emacsen add-on package spec files", make both of
> the above changes in the first template, and the second change in the
> second template.

Well, actually, the version number is really an indication of the
lowest version that is compatible with the elisp that you're about to
generate - nothing changed in this regard between 22.1 and 22.2 (or
22.3).

Within the buildsystem, the hardcoded versions here are never used, as
the true version is found at package build time. However, those stupid
hardcoded versions are there to stop the building of SRPMs breaking
prior to package building - BuildRequires aren't satisfied when the
SRPM is built, so pkg-config isn't present.

So, yeah, no harm in those updates, but not a big deal.

[Aside: I am in the process of adding RPM macros to simplify this
rather messy pkg-config use, once that is in place I'll propose
changes to the guidelines.]

J.



From loganjerry at gmail.com  Wed Jan 21 18:11:54 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 21 Jan 2009 11:11:54 -0700
Subject: Edits to Emacs packaging guidelines page
In-Reply-To: <645d17210901211007w24f3936ft35a850b51ec41019@mail.gmail.com>
References: <870180fe0901210944q65cfcc98r769ddde46e261bae@mail.gmail.com>
	<645d17210901211007w24f3936ft35a850b51ec41019@mail.gmail.com>
Message-ID: <870180fe0901211011r64e155bayd5ff3f6322fa01c6@mail.gmail.com>

On Wed, Jan 21, 2009 at 11:07 AM, Jonathan Underwood
<jonathan.underwood at gmail.com> wrote:
> Well, actually, the version number is really an indication of the
> lowest version that is compatible with the elisp that you're about to
> generate - nothing changed in this regard between 22.1 and 22.2 (or
> 22.3).
>
> Within the buildsystem, the hardcoded versions here are never used, as
> the true version is found at package build time. However, those stupid
> hardcoded versions are there to stop the building of SRPMs breaking
> prior to package building - BuildRequires aren't satisfied when the
> SRPM is built, so pkg-config isn't present.
>
> So, yeah, no harm in those updates, but not a big deal.
>
> [Aside: I am in the process of adding RPM macros to simplify this
> rather messy pkg-config use, once that is in place I'll propose
> changes to the guidelines.]
>
> J.

Okay.  However, the XEmacs paths are still wrong.  Can those be fixed
in the meantime?  Thanks,
-- 
Jerry James
http://loganjerry.googlepages.com/



From jonathan.underwood at gmail.com  Wed Jan 21 18:14:08 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Wed, 21 Jan 2009 18:14:08 +0000
Subject: Edits to Emacs packaging guidelines page
In-Reply-To: <870180fe0901211011r64e155bayd5ff3f6322fa01c6@mail.gmail.com>
References: <870180fe0901210944q65cfcc98r769ddde46e261bae@mail.gmail.com>
	<645d17210901211007w24f3936ft35a850b51ec41019@mail.gmail.com>
	<870180fe0901211011r64e155bayd5ff3f6322fa01c6@mail.gmail.com>
Message-ID: <645d17210901211014l147dc668p4aa5d308e467685e@mail.gmail.com>

2009/1/21 Jerry James <loganjerry at gmail.com>:
> Okay.  However, the XEmacs paths are still wrong.  Can those be fixed
> in the meantime?  Thanks,

Oh, yeah, good point!

J.



From vonbrand at inf.utfsm.cl  Wed Jan 21 18:15:22 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 21 Jan 2009 15:15:22 -0300
Subject: oowriter loses tables!
Message-ID: <200901211815.n0LIFM7L015725@laptop14.inf.utfsm.cl>

It happened now with several Office XP *.doc files with tables that
modifying them, and then saving the file with the original format, and then
reopening the file (or opening it in Word) the tables are utterly gone. BZ
at 481012.
-- 
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 poelstra at redhat.com  Wed Jan 21 18:19:56 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 21 Jan 2009 10:19:56 -0800
Subject: Stale Feature Pages
Message-ID: <4977674C.8020302@redhat.com>

Hello Feature Owners,

With the Alpha Freeze starting yesterday (2009-01-20) we still have a 
few feature pages in need of an update.  Several have not been updated 
for a month or more.  This information is important as the Documentation 
team starts to prepare the release notes for the Alpha Release.

Please make sure the information listed on your feature page is current 
and then update the "Last Updated" date--even if you haven't changed any 
information on the page.

If any of the features below remain unchanged by January 28, 2009, I 
will propose them to FESCo to dropped from the Fedora 11 Feature list.

https://fedoraproject.org/wiki/Features/Policy/Dropping

https://fedoraproject.org/wiki/Features/20SecondStartup

https://fedoraproject.org/wiki/Features/Fingerprint

https://fedoraproject.org/wiki/Features/Multiseat

https://fedoraproject.org/wiki/Features/Presto

https://fedoraproject.org/wiki/Features/TightVNC

https://fedoraproject.org/wiki/Features/VolumeControl

Thank you for your help,
John

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From jspaleta at gmail.com  Wed Jan 21 20:41:11 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Jan 2009 11:41:11 -0900
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232554997.3610.11.camel@warbird.finway.co.uk>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
Message-ID: <604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>

On Wed, Jan 21, 2009 at 7:23 AM, Kevin Coffin <kevin at finway.co.uk> wrote:
> I then added myself to the uucp group and rebooted, for some reason
> restarting haldaemon did not work correctly. Now openocd works without
> having to be root. Hope this helps.
>
> I do wish this udev/hal/policykit magic was better documented.

Did your rule get picked up in the authorizations gui as well?

What form of documentation is the highest priority need right now?

-jef



From loganjerry at gmail.com  Wed Jan 21 20:41:45 2009
From: loganjerry at gmail.com (Jerry James)
Date: Wed, 21 Jan 2009 13:41:45 -0700
Subject: MIT License page typo
Message-ID: <870180fe0901211241i2535f9car55d238a1e4727517@mail.gmail.com>

Another page I can't edit:

https://fedoraproject.org/wiki/Licensing/MIT

"Old Style with legal disclaimer 3" has the same "<code></code>AS
IS''" that I reported awhile ago for some of the other licenses.

Is this the right place to report wiki typos?
-- 
Jerry James
http://loganjerry.googlepages.com/



From paul at all-the-johnsons.co.uk  Wed Jan 21 21:10:03 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Wed, 21 Jan 2009 21:10:03 +0000
Subject: k3b permissions
In-Reply-To: <gl7a1k$qoj$1@ger.gmane.org>
References: <1232436704.6740.8.camel@PB3.Linux> <gl7a1k$qoj$1@ger.gmane.org>
Message-ID: <1232572203.6740.21.camel@PB3.Linux>

Hi,

> What does this say?
> getfacl /dev/sr0

# file: dev/sr0
# owner: root
# group: disk
user::rw-
user:paul:rw-
group::rw-
mask::rw-
other::---

I should be able to use /dev/sr0, but it won't allow me to burn (keeps
saying to insert a blank disc - login as su and it's fine).

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/d617483b/attachment.sig>

From joshuacov at googlemail.com  Wed Jan 21 21:14:41 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Wed, 21 Jan 2009 22:14:41 +0100
Subject: plans for kernel in F10?
In-Reply-To: <20090121153244.GD27998@bombadil.infradead.org>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
Message-ID: <5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>

2009/1/21 Kyle McMartin <kyle at mcmartin.ca>:
> On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
>> There are two recent kernels built in Koji:
>>
>> kernel-2.6.27.12-170.2.5.fc10
>> kernel-2.6.28.1-17.fc10
>>
>> So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
>>
>
> 2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
> fixes.
>
> regards, Kyle
>

Does this include f9?



From sgrubb at redhat.com  Wed Jan 21 21:27:13 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 21 Jan 2009 16:27:13 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <4976781D.2020109@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
Message-ID: <200901211627.13649.sgrubb@redhat.com>

On Tuesday 20 January 2009 08:19:25 pm Ric Wheeler wrote:
> > * BAD POLICY and MISCONFIGURATION.
> > TCP wrappers is behaving exactly how it is defined in policy.  Hostname
> > in hosts.deny (itself always a bad idea) is dependent on the DNS server
> > to be properly configured and operating.  Failure due to hostnames in
> > /etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
> > unknown clients connecting to that service, then they should use a
> > wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
> > /etc/hosts.allow.
>
> I disagree - you can easily get into a situation here where a user has
> put "badhost.example.com" into hosts.deny and by your argument, if DNS
> lookup fails, you will always allow them in.
>
> Clearly, not the correct response for a security policy.

Generally, you should put allow rules and not the reverse. If you want a 
bulletproof security policy, you have to have ALL: ALL in hosts.deny so that 
any failure results in denial. What the deny file can safely be used for is 
excluding a network you control from a larger selection. IOW, you allow all 
of the 192.168. network except for the 192.168.1. subnet. But even then you 
can use the EXCEPT operator in the allow file for this condition. So, you 
likely do not need to ever put something in the deny file other than ALL: 
ALL.


> As we discussed with Steve D this afternoon, I think that the correct
> behaviour would be to:
>
>     (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable
> this denial if no rules for your service are defined.
>     (2) If you don't believe in this policy, either uninstall TCP
> wrappers OR use only IP addresses in the /etc/hosts.* files.

Look at hosts_access(5) for the rules governing tcp_wrappers. They haven't 
changed in a long long time.


> What you are proposing would flip the security policy on its head - if
> you cannot resolve the hostname, always allow access.
>
> To recap, to trigger this concern you have, you have to take the
> following steps:
>
>     (1) Edit either file and install an allow or deny rule with
> hostnames (we currently ship without any rules defined, the files are
> effectively empty)
>     (2) Have a DNS failure
>     (3) Have configured NFS service
>
> The fix for a user is easy - change the hostnames to IP addresses or
> uninstall TCP wrappers, right?

Or rewrite the rules from the mostly closed perspective which means you deny 
everyone and allow some connections.


> I really, really don't see this as anything other than correcting a long
> standing bug.
>
> A different (and very valid) argument can be made that tcp wrappers are
> garbage and that we should not ship them. Until then, I would argue that
> we should fix them to work as expected.

They are working just as expected. 


> What would be nice is if tcp wrappers itself had an easy to use API that
> allowed us to query for a specific service - if no rules (default or
> specific to your service) have been specified, you can disable the DNS
> reverse lookup path.

What some services do is have a configuration flag that tells the daemon 
whether or not to use tcp_wrappers. This way you have an escape hatch if 
you'd rather write iptables rules.

-Steve



From kevin at finway.co.uk  Wed Jan 21 21:29:07 2009
From: kevin at finway.co.uk (Kevin Coffin)
Date: Wed, 21 Jan 2009 21:29:07 +0000
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
Message-ID: <1232573347.3610.13.camel@warbird.finway.co.uk>

On Wed, 2009-01-21 at 11:41 -0900, Jeff Spaleta wrote:
> On Wed, Jan 21, 2009 at 7:23 AM, Kevin Coffin <kevin at finway.co.uk> wrote:
> > I then added myself to the uucp group and rebooted, for some reason
> > restarting haldaemon did not work correctly. Now openocd works without
> > having to be root. Hope this helps.
> >
> > I do wish this udev/hal/policykit magic was better documented.
> 
> Did your rule get picked up in the authorizations gui as well?
> 
> What form of documentation is the highest priority need right now?
> 
> -jef
> 

What authorisations gui ? I am running a kde desktop.

Kevin




From johannbg at hi.is  Wed Jan 21 21:46:48 2009
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Wed, 21 Jan 2009 21:46:48 +0000
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
Message-ID: <497797C8.1050209@hi.is>

When a Bug Hunter encounters the same bug in past (supported ) release, 
current release and rawhide.

Should he..

A.
     File the same bug 3 times as in once for each release?

Or

B.
     File the bug once and comment on that report that the same bug
     is present in the other release(s) as well?

Cast your opinions and vote on how you prefer it.

The majority of the outcome will decide on how Bug Hunters will be 
directed to
handle this.

JBG




From kevin at finway.co.uk  Wed Jan 21 22:09:39 2009
From: kevin at finway.co.uk (Kevin Coffin)
Date: Wed, 21 Jan 2009 22:09:39 +0000
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
Message-ID: <1232575779.3610.30.camel@warbird.finway.co.uk>

On Wed, 2009-01-21 at 11:41 -0900, Jeff Spaleta wrote:
> On Wed, Jan 21, 2009 at 7:23 AM, Kevin Coffin <kevin at finway.co.uk> wrote:
> > I then added myself to the uucp group and rebooted, for some reason
> > restarting haldaemon did not work correctly. Now openocd works without
> > having to be root. Hope this helps.
> >
> > I do wish this udev/hal/policykit magic was better documented.
> 
> Did your rule get picked up in the authorizations gui as well?
> 
> What form of documentation is the highest priority need right now?
> 
> -jef
> 

Sorry Jef I was a bit hasty and forgot to answer your second question.
Although I have read the specs for hal/policykit I don't understand how
the authorisations are actually done. Although the quick hack that I
posted does seem to work for me I am not sure exactly how it is
achieved. I do not see the group/owner on the endpoints for the usb
device change. If you have any pointers to further reading on the
inter-actions between hal and policykit they would be gratefully
received.

There is probably a better way to do this. Further reading today
indicated that this should have been placed in /etc/hal directory
structure. I do have an rpm for openocd and it would be nice to have it
install the correct permissions in the right place.

Kevin





From lsof at nodata.co.uk  Wed Jan 21 22:19:39 2009
From: lsof at nodata.co.uk (nodata)
Date: Wed, 21 Jan 2009 23:19:39 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <200901200644.51574.sgrubb@redhat.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<200901191607.50904.sgrubb@redhat.com>
	<4974ECE5.3050206@nobugconsulting.ro>
	<200901200644.51574.sgrubb@redhat.com>
Message-ID: <1232576379.12250.0.camel@localhost.localdomain>

Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
> On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> > actually after chattr +i not even root can modify / delete the file:
> 
> True. But you can chattr -i ./foo and then edit the file remembering to make 
> it immutable again when you are done editing it. Not as automatic as one 
> might like, but that's how to do it.
> 
> -Steve
> 

That would mean a race though. Better to fix directory permissions :)



From jspaleta at gmail.com  Wed Jan 21 22:19:40 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Jan 2009 13:19:40 -0900
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232575779.3610.30.camel@warbird.finway.co.uk>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232575779.3610.30.camel@warbird.finway.co.uk>
Message-ID: <604aa7910901211419i18ada7a1x9530016ee09d6f5e@mail.gmail.com>

On Wed, Jan 21, 2009 at 1:09 PM, Kevin Coffin <kevin at finway.co.uk> wrote:

>Although the quick hack that I
> posted does seem to work for me I am not sure exactly how it is
> achieved. I do not see the group/owner on the endpoints for the usb
> device change. If you have any pointers to further reading on the
> inter-actions between hal and policykit they would be gratefully
> received.

Aren't they done via acl manipulations?

Do you see changes in the getfacl  output?

>
> There is probably a better way to do this. Further reading today
> indicated that this should have been placed in /etc/hal directory
> structure. I do have an rpm for openocd and it would be nice to have it
> install the correct permissions in the right place.

The question remains. If a new documentation effort were to be made
what form of documentation would be the first priority to work on?

-jef



From orion at cora.nwra.com  Wed Jan 21 22:20:13 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Wed, 21 Jan 2009 15:20:13 -0700
Subject: F10 updates status?
Message-ID: <49779F9D.6050001@cora.nwra.com>

Did something go crazy with the F10 updates repo?  I'm seeing files from 
  Jan 16 in 
http://download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/repodata/
and some installs using that repo are having trouble.


-- 
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 jspaleta at gmail.com  Wed Jan 21 22:20:52 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 21 Jan 2009 13:20:52 -0900
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232573347.3610.13.camel@warbird.finway.co.uk>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232573347.3610.13.camel@warbird.finway.co.uk>
Message-ID: <604aa7910901211420w242d50eckaa0675b0b8883217@mail.gmail.com>

On Wed, Jan 21, 2009 at 12:29 PM, Kevin Coffin <kevin at finway.co.uk> wrote:
> What authorisations gui ? I am running a kde desktop.

I think my question will make more sense to you with the kde 4.2
update. My understanding is that it will have the corresponding gui
that gnome has right now.

-jef



From sgrubb at redhat.com  Wed Jan 21 22:25:02 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 21 Jan 2009 17:25:02 -0500
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <1232576379.12250.0.camel@localhost.localdomain>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<200901200644.51574.sgrubb@redhat.com>
	<1232576379.12250.0.camel@localhost.localdomain>
Message-ID: <200901211725.02679.sgrubb@redhat.com>

On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
> Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
> > On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
> > > actually after chattr +i not even root can modify / delete the file:
> >
> > True. But you can chattr -i ./foo and then edit the file remembering to
> > make it immutable again when you are done editing it. Not as automatic as
> > one might like, but that's how to do it.
>
> That would mean a race though. Better to fix directory permissions :)

The original question was about a file owned by root but readable by others. I 
assume 0644 permissions. The root ownership still protects it.

-Steve



From rwheeler at redhat.com  Wed Jan 21 22:28:34 2009
From: rwheeler at redhat.com (Ric Wheeler)
Date: Wed, 21 Jan 2009 17:28:34 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <200901211627.13649.sgrubb@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<200901211627.13649.sgrubb@redhat.com>
Message-ID: <4977A192.2060401@redhat.com>

Steve Grubb wrote:
> On Tuesday 20 January 2009 08:19:25 pm Ric Wheeler wrote:
>   
>>> * BAD POLICY and MISCONFIGURATION.
>>> TCP wrappers is behaving exactly how it is defined in policy.  Hostname
>>> in hosts.deny (itself always a bad idea) is dependent on the DNS server
>>> to be properly configured and operating.  Failure due to hostnames in
>>> /etc/hosts.deny is MISCONFIGURATION.  If they are really concerned about
>>> unknown clients connecting to that service, then they should use a
>>> wildcard like "mountd: ALL" and allow specific hosts or IP ranges in
>>> /etc/hosts.allow.
>>>       
>> I disagree - you can easily get into a situation here where a user has
>> put "badhost.example.com" into hosts.deny and by your argument, if DNS
>> lookup fails, you will always allow them in.
>>
>> Clearly, not the correct response for a security policy.
>>     
>
> Generally, you should put allow rules and not the reverse. If you want a 
> bulletproof security policy, you have to have ALL: ALL in hosts.deny so that 
> any failure results in denial. What the deny file can safely be used for is 
> excluding a network you control from a larger selection. IOW, you allow all 
> of the 192.168. network except for the 192.168.1. subnet. But even then you 
> can use the EXCEPT operator in the allow file for this condition. So, you 
> likely do not need to ever put something in the deny file other than ALL: 
> ALL.
>
>   

I don't disagree with the best way to use it as you suggest, but the 
specific issue is for those who (naively?) put a hostname into the deny 
file. I don't think that we can assume that users will always do the 
optimal thing :-)

The way the code works today, you will get the expected behavior (mounts 
from that client are denied) only as long as DNS is working properly. 
When the DNS lookup fails, it will be allowed.

ric

>   
>> As we discussed with Steve D this afternoon, I think that the correct
>> behaviour would be to:
>>
>>     (1) Fix tcp wrappers to parse the /etc/hosts.* files and disable
>> this denial if no rules for your service are defined.
>>     (2) If you don't believe in this policy, either uninstall TCP
>> wrappers OR use only IP addresses in the /etc/hosts.* files.
>>     
>
> Look at hosts_access(5) for the rules governing tcp_wrappers. They haven't 
> changed in a long long time.
>
>
>   
>> What you are proposing would flip the security policy on its head - if
>> you cannot resolve the hostname, always allow access.
>>
>> To recap, to trigger this concern you have, you have to take the
>> following steps:
>>
>>     (1) Edit either file and install an allow or deny rule with
>> hostnames (we currently ship without any rules defined, the files are
>> effectively empty)
>>     (2) Have a DNS failure
>>     (3) Have configured NFS service
>>
>> The fix for a user is easy - change the hostnames to IP addresses or
>> uninstall TCP wrappers, right?
>>     
>
> Or rewrite the rules from the mostly closed perspective which means you deny 
> everyone and allow some connections.
>
>
>   
>> I really, really don't see this as anything other than correcting a long
>> standing bug.
>>
>> A different (and very valid) argument can be made that tcp wrappers are
>> garbage and that we should not ship them. Until then, I would argue that
>> we should fix them to work as expected.
>>     
>
> They are working just as expected. 
>
>
>   
>> What would be nice is if tcp wrappers itself had an easy to use API that
>> allowed us to query for a specific service - if no rules (default or
>> specific to your service) have been specified, you can disable the DNS
>> reverse lookup path.
>>     
>
> What some services do is have a configuration flag that tells the daemon 
> whether or not to use tcp_wrappers. This way you have an escape hatch if 
> you'd rather write iptables rules.
>
> -Steve
>   



From jkeating at redhat.com  Wed Jan 21 22:28:28 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Jan 2009 14:28:28 -0800
Subject: F10 updates status?
In-Reply-To: <49779F9D.6050001@cora.nwra.com>
References: <49779F9D.6050001@cora.nwra.com>
Message-ID: <1232576908.3539.215.camel@localhost.localdomain>

On Wed, 2009-01-21 at 15:20 -0700, Orion Poplawski wrote:
> Did something go crazy with the F10 updates repo?  I'm seeing files from 
>   Jan 16 in 
> http://download.fedora.redhat.com/pub/fedora/linux/updates/10/i386/repodata/
> and some installs using that repo are having trouble.
> 

A push just finished, perhaps you're hitting a mirror that is only
partially synced.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/4bd67c2f/attachment.sig>

From sgrubb at redhat.com  Wed Jan 21 22:42:53 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 21 Jan 2009 17:42:53 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <4976A1CB.4050600@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com>
Message-ID: <200901211742.54124.sgrubb@redhat.com>

On Tuesday 20 January 2009 11:17:15 pm Warren Togami wrote:
> > A different (and very valid) argument can be made that tcp wrappers are
> > garbage and that we should not ship them. Until then, I would argue that
> > we should fix them to work as expected.
>
> +1. ?We really need to stop shipping this crap.

The day when no one tries IP address spoofing and source routing is the day we 
can stop shipping this "crap". Until then I thank it for every denial I see 
in my logs.

-Steve



From airlied at redhat.com  Wed Jan 21 22:51:57 2009
From: airlied at redhat.com (Dave Airlie)
Date: Thu, 22 Jan 2009 08:51:57 +1000
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <49774B66.6050408@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<49774B66.6050408@fedoraproject.org>
Message-ID: <1232578317.32223.11.camel@optimus>

On Wed, 2009-01-21 at 21:50 +0530, Rahul Sundaram wrote:
> Benjamin LaHaise wrote:
> 
> > 
> > And how do you propose that a user login to fix a problem when they call 
> > tech support saying "I get a blank screen when I login"?   I'm curious, 
> > because these are real world cases where the GUI login fails. 
> 
> If the GUI login, your fallback is command line, obviously. Having had 
> support experience for a good number of years, I can tell you that, 
> instructing people to type some command is far more easier as well.
> 

I don't understand the difference between dropping the user to a
console, and just starting gnome-terminal + metacity when they login as
root on the console.

Or even xterm + twm.

They get the same power to destroy.

disabling root login just seems like the wrong answer, a hack to
workaround the fact that we can't fully enable selinux.

Dave.




From kevin.kofler at chello.at  Wed Jan 21 22:52:01 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 23:52:01 +0100
Subject: How do I allow automatic non root access to my non standard USB
	device ?
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232573347.3610.13.camel@warbird.finway.co.uk>
Message-ID: <gl88uh$p63$2@ger.gmane.org>

Kevin Coffin wrote:
> What authorisations gui ? I am running a kde desktop.

polkit-gnome-authorization in the PolicyKit-gnome package. Also works on
KDE.

As an alternative, PolicyKit-kde, which provides a KDE version
(polkit-kde-authorization), is being pushed out as an update, you'll be
able to install it soon.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 21 22:59:21 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 23:59:21 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>
	<49774B66.6050408@fedoraproject.org>
	<1232578317.32223.11.camel@optimus>
Message-ID: <gl89c9$p63$4@ger.gmane.org>

Dave Airlie wrote:
> disabling root login just seems like the wrong answer, a hack to
> workaround the fact that we can't fully enable selinux.

Crippling root with SELinux so it is practically no longer root isn't any
more useful than just disallowing it (they're both bad ideas).

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 21 22:56:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 21 Jan 2009 23:56:47 +0100
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
References: <497797C8.1050209@hi.is>
Message-ID: <gl897f$p63$3@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> Should he..
> 
> A.
>      File the same bug 3 times as in once for each release?
> 
> Or
> 
> B.
>      File the bug once and comment on that report that the same bug
>      is present in the other release(s) as well?
> 
> Cast your opinions and vote on how you prefer it.

B

Doing A is a major annoyance for us packagers, it splits the discussion into
multiple threads, it floods us with even more bugmail and it brings no
benefit as we have to fix the issue in all affected releases anyway, we
should do it for all at the same time and close it once the updates are
pushed (just set any of the updates to close the bug and the others not,
they should be going out at the same time anyway - Rawhide should just get
fixed right away). I'm also very unhappy with the Security Team doing A and
think the security bug policy should be changed.

        Kevin Kofler



From wtogami at redhat.com  Wed Jan 21 23:11:31 2009
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 21 Jan 2009 18:11:31 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <4977A192.2060401@redhat.com>
References: <49764DC5.1050907@redhat.com>
	<4976781D.2020109@redhat.com>	<200901211627.13649.sgrubb@redhat.com>
	<4977A192.2060401@redhat.com>
Message-ID: <4977ABA3.1040901@redhat.com>

Ric Wheeler wrote:
> 
> I don't disagree with the best way to use it as you suggest, but the 
> specific issue is for those who (naively?) put a hostname into the deny 
> file. I don't think that we can assume that users will always do the 
> optimal thing :-)

Exactly the same thing can be said about misconfiguration with iptables.

Why is misconfigured tcp wrappers important enough to second guess, 
while misconfigured iptables is not?

This is one of the key reasons why this is NOT A BUG, and it does not 
belong in nfs-utils upstream.

If the concern is for the behavior to match the man page, the man page 
should have big fat warnings, it NEVER a good idea to use hostnames in 
/etc/hosts.deny.

Warren Togami
wtogami at redhat.com



From cmadams at hiwaay.net  Wed Jan 21 23:18:25 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 21 Jan 2009 17:18:25 -0600
Subject: NFS tcp wrapper situation
In-Reply-To: <200901211742.54124.sgrubb@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com>
	<200901211742.54124.sgrubb@redhat.com>
Message-ID: <20090121231825.GA1111797@hiwaay.net>

Once upon a time, Steve Grubb <sgrubb at redhat.com> said:
> The day when no one tries IP address spoofing and source routing is the day we 
> can stop shipping this "crap". Until then I thank it for every denial I see 
> in my logs.

Those would be good reasons, if tcpd protected you against those things.

The Linux IPv4 stack has an option "accept_source_route" that is off by
default, so that protects you there (as do most decent ISPs that disable
source routing).

TCP_wrappers does nothing to protect against IP spoofing.  Secure
sequence numbers should protect TCP, and proper network design and
filtering is the only thing that can protect UDP against spoofing.

TCP_wrappers was good before we had host-based firewalls, but is really
obsolete at this point, except for trying to do access control based on
DNS (which, for the most part, is a bad idea, as seen in this thread).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From rwheeler at redhat.com  Wed Jan 21 23:27:25 2009
From: rwheeler at redhat.com (Ric Wheeler)
Date: Wed, 21 Jan 2009 18:27:25 -0500
Subject: NFS tcp wrapper situation
In-Reply-To: <20090121231825.GA1111797@hiwaay.net>
References: <49764DC5.1050907@redhat.com>
	<4976781D.2020109@redhat.com>	<4976A1CB.4050600@redhat.com>	<200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net>
Message-ID: <4977AF5D.8020302@redhat.com>

Chris Adams wrote:
> Once upon a time, Steve Grubb <sgrubb at redhat.com> said:
>   
>> The day when no one tries IP address spoofing and source routing is the day we 
>> can stop shipping this "crap". Until then I thank it for every denial I see 
>> in my logs.
>>     
>
> Those would be good reasons, if tcpd protected you against those things.
>
> The Linux IPv4 stack has an option "accept_source_route" that is off by
> default, so that protects you there (as do most decent ISPs that disable
> source routing).
>
> TCP_wrappers does nothing to protect against IP spoofing.  Secure
> sequence numbers should protect TCP, and proper network design and
> filtering is the only thing that can protect UDP against spoofing.
>
> TCP_wrappers was good before we had host-based firewalls, but is really
> obsolete at this point, except for trying to do access control based on
> DNS (which, for the most part, is a bad idea, as seen in this thread).
>
>   
Sounds like it is something that we might want to try to deprecate and 
eventually remove.

ric



From jkeating at redhat.com  Wed Jan 21 23:27:52 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Jan 2009 15:27:52 -0800
Subject: [QA] To clone or not to clone ( a bug report ) that's the
 question...
In-Reply-To: <497797C8.1050209@hi.is>
References: <497797C8.1050209@hi.is>
Message-ID: <1232580472.3539.250.camel@localhost.localdomain>

On Wed, 2009-01-21 at 21:46 +0000, "J?hann B. Gu?mundsson" wrote:
>  
> A.
>      File the same bug 3 times as in once for each release?

I'd prefer A.  My reasons:

  1) the same "bug" may be caused by different things in different
releases.  Not every package has the same code for the entire release
family.

  2) different sets of users care about bugs in different release trees.
Closing a bug as fixed->rawhide doesn't help the user who is hitting
this issue on say F-9.

  3) bodhi auto-closing.  Not every update gets pushed at the same time,
and closing a single bug when an F-10 update goes out doesn't help the
F-9 users know that the update for their release has gone out, or been
delayed, or just not provided.

  4) The maintainer is the right person to decide if the bugs should be
collapsed into one, rather than the triager trying to make a judgement
call.  It's easier to close->dup than to clone in the first place, if
all the above doesn't apply.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/0efd979f/attachment.sig>

From kevin.kofler at chello.at  Wed Jan 21 23:39:32 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 00:39:32 +0100
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
Message-ID: <gl8bnm$2tm$1@ger.gmane.org>

Jesse Keating wrote:
>   1) the same "bug" may be caused by different things in different
> releases.  Not every package has the same code for the entire release
> family.

That's pretty rare. Even where the version differs, the bug can still be the
same. Even for Amarok 1 and 2, which are very different, there are bugs in
common with almost the same code involved (like the recently-fixed security
issue).

>   2) different sets of users care about bugs in different release trees.
> Closing a bug as fixed->rawhide doesn't help the user who is hitting
> this issue on say F-9.

Solution: make it a policy that bugs should never be closed Rawhide unless
they only affected Rawhide. It should also be required to push bugfixes out
to at least updates-testing as soon as the bug gets fixed in Rawhide,
unless there is a really good reason not to (e.g. the fix needs a rewrite
of the whole application).

>   3) bodhi auto-closing.  Not every update gets pushed at the same time,

Then that's the issue to solve.

> and closing a single bug when an F-10 update goes out doesn't help the
> F-9 users know that the update for their release has gone out, or been
> delayed, or just not provided.

But having the bug cloned does not solve this, requiring bugfixes to be
pushed to all supported releases at the same time (unless there's a strong
reason not to) does.

>   4) The maintainer is the right person to decide if the bugs should be
> collapsed into one, rather than the triager trying to make a judgement
> call.  It's easier to close->dup than to clone in the first place, if
> all the above doesn't apply.

I really don't want to have to close clones as duplicates all the time, and
triagers might even end up creating new clones if they notice there's only
one.

        Kevin Kofler



From jkeating at redhat.com  Wed Jan 21 23:51:20 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Jan 2009 15:51:20 -0800
Subject: [QA] To clone or not to clone ( a bug report ) that's the
 question...
In-Reply-To: <gl8bnm$2tm$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
	<gl8bnm$2tm$1@ger.gmane.org>
Message-ID: <1232581880.3539.253.camel@localhost.localdomain>

On Thu, 2009-01-22 at 00:39 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> >   1) the same "bug" may be caused by different things in different
> > releases.  Not every package has the same code for the entire release
> > family.
> 
> That's pretty rare. Even where the version differs, the bug can still be the
> same. Even for Amarok 1 and 2, which are very different, there are bugs in
> common with almost the same code involved (like the recently-fixed security
> issue).

Might be rare in your world, but isn't rare in mine.

> >   2) different sets of users care about bugs in different release trees.
> > Closing a bug as fixed->rawhide doesn't help the user who is hitting
> > this issue on say F-9.
> 
> Solution: make it a policy that bugs should never be closed Rawhide unless
> they only affected Rawhide. It should also be required to push bugfixes out
> to at least updates-testing as soon as the bug gets fixed in Rawhide,
> unless there is a really good reason not to (e.g. the fix needs a rewrite
> of the whole application).

Then that just means our rawhide bug lingers open even when it may be
fixed, which throws off trackers and blockers and queries.  Not a
solution.

> 
> >   3) bodhi auto-closing.  Not every update gets pushed at the same time,
> 
> Then that's the issue to solve.

Right, and how do you propose we "solve" this (not that I agree that
this is a problem)?

> 
> > and closing a single bug when an F-10 update goes out doesn't help the
> > F-9 users know that the update for their release has gone out, or been
> > delayed, or just not provided.
> 
> But having the bug cloned does not solve this, requiring bugfixes to be
> pushed to all supported releases at the same time (unless there's a strong
> reason not to) does.

At the same time doesn't work.  What if your attempted fix on F-9 fails,
but the fix on F-10 succeeds?  Should the F-10 build sit in
updates-testing until the say that F-9 works?  F-10 users just suffer
for the sake of having the push go at the same time?  Ridiculous.

> 
> >   4) The maintainer is the right person to decide if the bugs should be
> > collapsed into one, rather than the triager trying to make a judgement
> > call.  It's easier to close->dup than to clone in the first place, if
> > all the above doesn't apply.
> 
> I really don't want to have to close clones as duplicates all the time, and
> triagers might even end up creating new clones if they notice there's only
> one.

You can always opt out of having triagers touch KDE bugs.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/b77ca617/attachment.sig>

From kamisamanou at kamisamanou.net  Wed Jan 21 23:54:29 2009
From: kamisamanou at kamisamanou.net (Kamisamanou Burgess)
Date: Wed, 21 Jan 2009 17:54:29 -0600
Subject: MIT License page typo
In-Reply-To: <870180fe0901211241i2535f9car55d238a1e4727517@mail.gmail.com>
References: <870180fe0901211241i2535f9car55d238a1e4727517@mail.gmail.com>
Message-ID: <5dbb83710901211554u3dc6b92t3b31d6349892167b@mail.gmail.com>

No, the right place to report wiki typos would be
webmaster at fedoraproject.org. Or the webites list(
fedora-websites-list at redhat.com)

Sayonara,
Kamisamanou Burgess
http://www.kamisamanou.net

On Wed, Jan 21, 2009 at 14:41, Jerry James <loganjerry at gmail.com> wrote:

> Another page I can't edit:
>
> https://fedoraproject.org/wiki/Licensing/MIT
>
> "Old Style with legal disclaimer 3" has the same "<code></code>AS
> IS''" that I reported awhile ago for some of the other licenses.
>
> Is this the right place to report wiki typos?
> --
> Jerry James
> http://loganjerry.googlepages.com/
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com<https://mail.google.com/mail?view=cm&tf=0&to=fedora-devel-list at redhat.com>
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/a1cb24ce/attachment.htm>

From notting at redhat.com  Wed Jan 21 23:56:34 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 21 Jan 2009 18:56:34 -0500
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
In-Reply-To: <gl8bnm$2tm$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
	<gl8bnm$2tm$1@ger.gmane.org>
Message-ID: <20090121235634.GA5638@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> >   2) different sets of users care about bugs in different release trees.
> > Closing a bug as fixed->rawhide doesn't help the user who is hitting
> > this issue on say F-9.
> 
> Solution: make it a policy that bugs should never be closed Rawhide unless
> they only affected Rawhide. It should also be required to push bugfixes out
> to at least updates-testing as soon as the bug gets fixed in Rawhide,
> unless there is a really good reason not to (e.g. the fix needs a rewrite
> of the whole application).

For any bug that's filed? Wow, and people thought we did a lot of
updates *now*.

Bill



From petersen at redhat.com  Thu Jan 22 00:00:58 2009
From: petersen at redhat.com (Jens Petersen)
Date: Wed, 21 Jan 2009 19:00:58 -0500 (EST)
Subject: comps discussion at fudcon and the future
In-Reply-To: <1922227151.1010571232582022925.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <783022041.1011321232582458070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>

[oops, thought I already had sent this but just found it in my drafts folder]

----- "Bill Nottingham" <notting at redhat.com> wrote:
> Well... attached is a prototype of a yum plugin to do this sort of
> stuff.

Great - thanks.  I was actually going to write something very similar for yum-utils for F11 to allow automatic installing of langpacks, etc, for when installing packages.

My idea was to use meta-packages for that though.  So if you have have say the "japanese-support" metapackage installed and then go to install openoffice it would pull in the Japanese lang pack for you automatically.  I agree with Rex that it needs to support more than just langpacks.  Eg installing kde should pull in ibus-qt if you are using ibus for example, but I think that could be done.  There was also a request for such support for emacs support subpackages, which might work both ways (ie either when installing emacs and/or the program the subpackage is supporting (eg emacs-git)).

So how about including this in yum-utils?

Jens



From jkeating at redhat.com  Thu Jan 22 00:07:02 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Jan 2009 16:07:02 -0800
Subject: Alpha-freeze, when ?
In-Reply-To: <1207.1232548739@sss.pgh.pa.us>
References: <4976E176.5020906@poolshark.org>
	<b401d2530901210053j1acd9f27o7ed4e61243fb5de8@mail.gmail.com>
	<4976E3D5.5010704@poolshark.org> <4976E62B.7040004@ioa.s.u-tokyo.ac.jp>
	<4976EDB2.6050108@poolshark.org>  <1207.1232548739@sss.pgh.pa.us>
Message-ID: <1232582822.3539.255.camel@localhost.localdomain>

On Wed, 2009-01-21 at 09:38 -0500, Tom Lane wrote:
>  
> The clarification I'd like is an all-clear signal that the alpha tag has
> been made and we can go back to breaking rawhide ;-).  According to the
> stated schedule it should have been done by now; so will I get my wrist
> slapped if I push mysql 5.1 today?

Sorry, I've been slacking on that one.  The alpha tag has been made.
You could break rawhide if you want, but if it's going to break a lot of
deps you may want to ask for a koji tag specifically to land it and
build all the deps for it before moving it into rawhide itself.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/a0672806/attachment.sig>

From notting at redhat.com  Thu Jan 22 00:14:27 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 21 Jan 2009 19:14:27 -0500
Subject: comps discussion at fudcon and the future
In-Reply-To: <783022041.1011321232582458070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
References: <1922227151.1010571232582022925.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<783022041.1011321232582458070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
Message-ID: <20090122001427.GB5638@nostromo.devel.redhat.com>

Jens Petersen (petersen at redhat.com) said: 
> So how about including this in yum-utils?

The metadata that this uses would need to be defined and added somewhere
first - hardcoding it in the plugin works for a proof-of-concept, but isn't
the way we want to go long-term.

Bill



From cmadams at hiwaay.net  Thu Jan 22 00:48:54 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 21 Jan 2009 18:48:54 -0600
Subject: NFS tcp wrapper situation
In-Reply-To: <4977AF5D.8020302@redhat.com>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com>
	<200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net> <4977AF5D.8020302@redhat.com>
Message-ID: <20090122004854.GC1111797@hiwaay.net>

Once upon a time, Ric Wheeler <rwheeler at redhat.com> said:
> Chris Adams wrote:
> >TCP_wrappers was good before we had host-based firewalls, but is really
> >obsolete at this point, except for trying to do access control based on
> >DNS (which, for the most part, is a bad idea, as seen in this thread).
> >  
> Sounds like it is something that we might want to try to deprecate and 
> eventually remove.

I hadn't really given it much thought before this thread, but that
really may be the case (IMHO of course).

TCP_wrappers functions that are not really useful now:

- connection logging; this came when executed directly (e.g. from old
  inetd), but I don't think anything uses that now (xinetd, NFS,
  OpenSSH, etc. use their own logging instead of tcp_wrappers'); now
  that I look, I see rpcbind has a "-l" option that looks like it uses
  libwrap's logging (option is not on by default)

- basic allow/deny access control on a per-host and per-service basis;
  this can also be done with iptables for most services (and iptables is
  better, since that keeps any system daemon from even seeing a
  connection => lower load, less possible vulnerability, etc.)

- IDENT lookup (I don't believe anything uses this now)

There are some things that you can still do with TCP_wrappers that you
can't easily do in other ways:

- control access to RPC services that live on essentially random ports

- do DNS-based access control (which can seem useful but is often a bad
  idea)

- easier to manage "dynamic" access control such as done with denyhosts


The annoying thing about even considering deprecating TCP_wrappers is
that for most (if not all) current use, it is a build-time decision.  If
you build e.g. OpenSSH without -lwrap, there is no way to add that
functionality back.  Somebody could teach denyhosts about iptables
instead of /etc/hosts.deny (shouldn't be too hard to manage with a
couple of new scripts).

That brings me back to RPC services though, which means NFS (which
started all of this).  Some of the NFS component services have fixed
ports now (even though they still register with portmapper), such as
nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
statd all run on portmapper-assigned random ports.  The only way to
control access to them is currently TCP_wrappers.

Ideally, there'd be an iptables module or something that could track RPC
assigments and limit access, but that isn't a simple thing.
Alternately, you could have the portmapper have a callout to a script
that could modify iptables settings.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From jwboyer at gmail.com  Thu Jan 22 01:29:41 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 21 Jan 2009 20:29:41 -0500
Subject: plans for kernel in F10?
In-Reply-To: <5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
	<5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>
Message-ID: <20090122012941.GA3657@yoda.jdub.homelinux.org>

On Wed, Jan 21, 2009 at 10:14:41PM +0100, Joshua C. wrote:
>2009/1/21 Kyle McMartin <kyle at mcmartin.ca>:
>> On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
>>> There are two recent kernels built in Koji:
>>>
>>> kernel-2.6.27.12-170.2.5.fc10
>>> kernel-2.6.28.1-17.fc10
>>>
>>> So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
>>>
>>
>> 2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
>> fixes.
>>
>> regards, Kyle
>>
>
>Does this include f9?

To my knowledge, not soon.  .28 kernel mode setting and the X version
in F9 don't get along.

josh



From jonathan.underwood at gmail.com  Thu Jan 22 01:34:56 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 22 Jan 2009 01:34:56 +0000
Subject: NFS tcp wrapper situation
In-Reply-To: <20090122004854.GC1111797@hiwaay.net>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com> <200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net> <4977AF5D.8020302@redhat.com>
	<20090122004854.GC1111797@hiwaay.net>
Message-ID: <645d17210901211734i6b56dd17jed7ee838fc3982d7@mail.gmail.com>

2009/1/22 Chris Adams <cmadams at hiwaay.net>:
[snip]
> - easier to manage "dynamic" access control such as done with denyhosts
>
[snip]
> functionality back.  Somebody could teach denyhosts about iptables
> instead of /etc/hosts.deny (shouldn't be too hard to manage with a
> couple of new scripts).

Incidentally this is precisely what fail2ban can do (i.e. use iptables
rather than /etc/hosts.deny).

J.



From cdahlin at redhat.com  Thu Jan 22 01:49:54 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 20:49:54 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121030132.GG19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
Message-ID: <4977D0C2.9090900@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
>   
>> You can at run level 3. You can even start X after that.
>>     
>
> You're assuming all users of a system are technical.  That is not the case.
>
> 		-ben
>
>   
Then they don't need root.

Is it wrong that I actually /miss/ the linux community's sense of 
elitism? It kept us so much more sensible on so many things.

--CJD



From jkeating at redhat.com  Thu Jan 22 01:50:10 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 21 Jan 2009 17:50:10 -0800
Subject: NFS tcp wrapper situation
In-Reply-To: <20090122004854.GC1111797@hiwaay.net>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com> <200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net> <4977AF5D.8020302@redhat.com>
	<20090122004854.GC1111797@hiwaay.net>
Message-ID: <1232589010.3539.263.camel@localhost.localdomain>

On Wed, 2009-01-21 at 18:48 -0600, Chris Adams wrote:
>  
> That brings me back to RPC services though, which means NFS (which
> started all of this).  Some of the NFS component services have fixed
> ports now (even though they still register with portmapper), such as
> nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
> statd all run on portmapper-assigned random ports.  The only way to
> control access to them is currently TCP_wrappers.

However each of these do allow you to set a specific port they'll run
on, so that you /can/ use iptables with them.  I've been running them
that way for years.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/d9371cfc/attachment.sig>

From cdahlin at redhat.com  Thu Jan 22 01:54:07 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 20:54:07 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
Message-ID: <4977D1BF.709@redhat.com>

Jud Craft wrote:
> On Wed, Jan 21, 2009 at 4:19 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
>   
>> What are the specific use cases, where non technical users are being
>> compelled to login as root (and other alternatives won't work)?
>>     
>
> The chief compelling one he mentions seems to be when NFS goes down
> and Linux can't find the /home partition.
>
> Or, to put it bluntly, when the Linux distribution isn't smart enough
> to protect "non-technical users" (an admittedly subjective term) from
> technical problems.  Which is often.
>
> But your critique, Mr. Sundaram, doesn't seem to imply that people
> shouldn't login as root -- merely that you disagree with allowing them
> to open a root session in X.  To be rhetorical, we must ask, why?
> After all, there's no such thing as "partial root power" -- you either
> have full root privileges in a terminal in a normal user X session, or
> full root privileges in a root X session.
>
> Here's the why:  you feel that a root X session is too insecure --
> which it may indeed be.  So we believe that the "ideal" method is to
> not allow X root logins.  But keep in mind, this is not actually an
> ideal.  It's a kludge to go around the fact that X is designed rather
> horribly from a security standpoint.  The "user session only" method
> allows you to work around that.
>   
If I gave you a gun that had an excellent safety mechanism that was 
presently activated, would you be willing to play Russian roulette?

The point of having a separate root user is not to trust things. It 
doesn't matter how much effort we put into securing them, if they don't 
need to run as root, they never should. Gnome-panel doesn't need to ever 
run as root.

--CJD



From cdahlin at redhat.com  Thu Jan 22 01:55:51 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 20:55:51 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090121155344.GI19788@kvack.org>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>
Message-ID: <4977D227.4010109@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 03:49:09PM +0530, Rahul Sundaram wrote:
>   
>> Benjamin LaHaise wrote:
>>     
>>> On Wed, Jan 21, 2009 at 08:29:33AM +0530, Rahul Sundaram wrote:
>>>       
>>>> You can at run level 3. You can even start X after that.
>>>>         
>>> You're assuming all users of a system are technical.  That is not the case.
>>>       
>> Non technical users shouldn't be logging in as root and more so X. They 
>> should be either launching graphical programs that ask for a password or 
>> use su - or sudo. It an potentially be made easier by giving them a 
>> "administrator shell" or something like that in the menu which launches 
>> the terminal and asks for a root/sudo password but it would be better to 
>> understand why it is ever needed and solve that issue in a perhaps more 
>> elegant way.
>>     
>
> And how do you propose that a user login to fix a problem when they call 
> tech support saying "I get a blank screen when I login"?   I'm curious, 
> because these are real world cases where the GUI login fails.  By disallowing 
> root logins, there is no way to fix that short of rebooting the system to 
> even narrow down what the problem is.  Even then, with F10 using a 0 second 
> wait at the grub prompt, it's almost impossible to catch grub in time to 
> specify the runlevel or init=/bin/sh.
>
>   
Ctrl+Alt+F2

--CJD



From mrmazda at ij.net  Thu Jan 22 02:10:29 2009
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 21 Jan 2009 21:10:29 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D227.4010109@redhat.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>	<20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com>
Message-ID: <4977D595.6070305@ij.net>

On 2009/01/21 20:55 (GMT-0500) Casey Dahlin composed:

>> ...Even then, with F10 using a 0 second 
>> wait at the grub prompt, it's almost impossible to catch grub in time to 
>> specify the runlevel or init=/bin/sh.

> Ctrl+Alt+F2

Not much help when system is configured to start X automatically, and X
proceeds to lock up the whole system because of an Intel video chip's broken
driver.
-- 
"Train a child in the way he should go, and when he
is old he will not turn from it." Proverbs 22:6 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From cdahlin at redhat.com  Thu Jan 22 02:12:45 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 21:12:45 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D595.6070305@ij.net>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>	<20090121155344.GI19788@kvack.org>	<4977D227.4010109@redhat.com>
	<4977D595.6070305@ij.net>
Message-ID: <4977D61D.7020501@redhat.com>

Felix Miata wrote:
> On 2009/01/21 20:55 (GMT-0500) Casey Dahlin composed:
>
>   
>>> ...Even then, with F10 using a 0 second 
>>> wait at the grub prompt, it's almost impossible to catch grub in time to 
>>> specify the runlevel or init=/bin/sh.
>>>       
>
>   
>> Ctrl+Alt+F2
>>     
>
> Not much help when system is configured to start X automatically, and X
> proceeds to lock up the whole system because of an Intel video chip's broken
> driver.
>   
And how does allowing graphical root login fix that?

--CJD



From craftjml at gmail.com  Thu Jan 22 02:18:38 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 21 Jan 2009 20:18:38 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D1BF.709@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
	<4977D1BF.709@redhat.com>
Message-ID: <20d6441a0901211818v2cd40ad1y2e448a77b752a4ce@mail.gmail.com>

On Wed, Jan 21, 2009 at 7:54 PM, Casey Dahlin wrote:
> If I gave you a gun that had an excellent safety mechanism that was
> presently activated, would you be willing to play Russian roulette?

Probably not, but conversely, when it comes time to pop a cap in
someone's arse, I want that gun to _work_, darn it.



From craftjml at gmail.com  Thu Jan 22 02:21:14 2009
From: craftjml at gmail.com (Jud Craft)
Date: Wed, 21 Jan 2009 20:21:14 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20d6441a0901211818v2cd40ad1y2e448a77b752a4ce@mail.gmail.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
	<4977D1BF.709@redhat.com>
	<20d6441a0901211818v2cd40ad1y2e448a77b752a4ce@mail.gmail.com>
Message-ID: <20d6441a0901211821r17ce06egde0b57e23ad0f3ac@mail.gmail.com>

> Probably not, but conversely, when it comes time to pop a cap in
> someone's arse, I want that gun to _work_, darn it.

Not sure if I got that metaphor quite right...



From mrmazda at ij.net  Thu Jan 22 02:29:42 2009
From: mrmazda at ij.net (Felix Miata)
Date: Wed, 21 Jan 2009 21:29:42 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D61D.7020501@redhat.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>	<20090121155344.GI19788@kvack.org>	<4977D227.4010109@redhat.com>	<4977D595.6070305@ij.net>
	<4977D61D.7020501@redhat.com>
Message-ID: <4977DA16.2040901@ij.net>

On 2009/01/21 21:12 (GMT-0500) Casey Dahlin composed:

> Felix Miata wrote:

>> On 2009/01/21 20:55 (GMT-0500) Casey Dahlin composed:

>>>> ...Even then, with F10 using a 0 second 
>>>> wait at the grub prompt, it's almost impossible to catch grub in time to 
>>>> specify the runlevel or init=/bin/sh.

>>> Ctrl+Alt+F2

>> Not much help when system is configured to start X automatically, and X
>> proceeds to lock up the whole system because of an Intel video chip's broken
>> driver.

> And how does allowing graphical root login fix that?

It doesn't. It's the reason why nothing graphical should happen before
everything else that graphical requires is known to be functioning, while
typically fixing the broke stuff requires root power.

Graphical boot is obfuscatory nonsense. I just put W2K on an old puter a few
days ago. Linux boots right up, but W2K takes 5 minutes to reach the login
window. The graphical blanket makes it impossible to see what is taking so
bloody long. I know there's a startup option to avoid the graphical doz
curtain, but that should be the default, not a hidden option. Same for Linux:
Graphical should be a selected option for those who want it, not the default.
-- 
"Train a child in the way he should go, and when he
is old he will not turn from it." Proverbs 22:6 NIV

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/



From cdahlin at redhat.com  Thu Jan 22 02:59:16 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 21:59:16 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977DA16.2040901@ij.net>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>	<20090121155344.GI19788@kvack.org>	<4977D227.4010109@redhat.com>	<4977D595.6070305@ij.net>	<4977D61D.7020501@redhat.com>
	<4977DA16.2040901@ij.net>
Message-ID: <4977E104.4070706@redhat.com>

Felix Miata wrote:
> On 2009/01/21 21:12 (GMT-0500) Casey Dahlin composed:
>
>   
>> Felix Miata wrote:
>>     
>
>   
>>> On 2009/01/21 20:55 (GMT-0500) Casey Dahlin composed:
>>>       
>
>   
>>>>> ...Even then, with F10 using a 0 second 
>>>>> wait at the grub prompt, it's almost impossible to catch grub in time to 
>>>>> specify the runlevel or init=/bin/sh.
>>>>>           
>
>   
>>>> Ctrl+Alt+F2
>>>>         
>
>   
>>> Not much help when system is configured to start X automatically, and X
>>> proceeds to lock up the whole system because of an Intel video chip's broken
>>> driver.
>>>       
>
>   
>> And how does allowing graphical root login fix that?
>>     
>
> It doesn't. It's the reason why nothing graphical should happen before
> everything else that graphical requires is known to be functioning, while
> typically fixing the broke stuff requires root power.
>
> Graphical boot is obfuscatory nonsense. I just put W2K on an old puter a few
> days ago. Linux boots right up, but W2K takes 5 minutes to reach the login
> window. The graphical blanket makes it impossible to see what is taking so
> bloody long. I know there's a startup option to avoid the graphical doz
> curtain, but that should be the default, not a hidden option. Same for Linux:
> Graphical should be a selected option for those who want it, not the default.
>   
Defaults exist for people who aren't smart enough to change them.

And graphical boot will go away when Fedora boots in 5 seconds (which it 
may do soon).

--CJD



From cmadams at hiwaay.net  Thu Jan 22 03:03:20 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 21 Jan 2009 21:03:20 -0600
Subject: NFS tcp wrapper situation
In-Reply-To: <1232589010.3539.263.camel@localhost.localdomain>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com>
	<200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net> <4977AF5D.8020302@redhat.com>
	<20090122004854.GC1111797@hiwaay.net>
	<1232589010.3539.263.camel@localhost.localdomain>
Message-ID: <20090122030320.GG1111797@hiwaay.net>

Once upon a time, Jesse Keating <jkeating at redhat.com> said:
> On Wed, 2009-01-21 at 18:48 -0600, Chris Adams wrote:
> > That brings me back to RPC services though, which means NFS (which
> > started all of this).  Some of the NFS component services have fixed
> > ports now (even though they still register with portmapper), such as
> > nfsd (2049) and rquotad (875), but I believe that mountd, lockd, and
> > statd all run on portmapper-assigned random ports.  The only way to
> > control access to them is currently TCP_wrappers.
> 
> However each of these do allow you to set a specific port they'll run
> on, so that you /can/ use iptables with them.  I've been running them
> that way for years.

I saw that, but I haven't tried it myself.  I guess they still register
with portmapper (i.e. portmapper allows a program to require a specific
port; I haven't done RPC programming in at least 10 years), since that
appears to be how nfsd and rquotad work.

It looks like the init scripts already support setting this (including
for the kernel lockd using sysctl).

Is there a reason to not go ahead and do that for Fedora 11?  That would
make recommending iptables instead of tcp_wrappers a lot easier.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From kevin at scrye.com  Thu Jan 22 03:04:33 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Wed, 21 Jan 2009 20:04:33 -0700
Subject: [QA] To clone or not to clone ( a bug report ) that's the
 question...
In-Reply-To: <497797C8.1050209@hi.is>
References: <497797C8.1050209@hi.is>
Message-ID: <20090121200433.3dffaf5e@ohm.scrye.com>

On Wed, 21 Jan 2009 21:46:48 +0000
"J?hann B. Gu?mundsson" <johannbg at hi.is> wrote:

> When a Bug Hunter encounters the same bug in past (supported )
> release, current release and rawhide.
> 
> Should he..
> 
> A.
>      File the same bug 3 times as in once for each release?
> 
> Or
> 
> B.
>      File the bug once and comment on that report that the same bug
>      is present in the other release(s) as well?

I prefer B. If it becomes obvious to the maintainer that they need to
separate things out, they can clone the bug then. If their work flow
works best doing that then they can, without forcing more bugs on them
if it does not. 

I personally ask submitters when they say it's affecting more releases
or if they report against f10: "Do you think this warrants an update?
Will you test it for me on that release?"

Sometimes they say "no, I just wanted it fixed, fix it in rawhide and I
will get it the next time there is a reason to update stable releases"
and sometimes they want/need it fixed in the release they are seeing it
in. 

> Cast your opinions and vote on how you prefer it.

I don't think voting is a good idea. 
I think we should try and come to a consensus on what will help our
maintainers and triagers and reporters handle bugs.

> The majority of the outcome will decide on how Bug Hunters will be 
> directed to
> handle this.

I don't think a poll on the devel list should be used for this... 
Can't we agree on whats least disruptive and use that?

> JBG

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/fb009371/attachment.sig>

From bcrl at kvack.org  Thu Jan 22 03:19:35 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:19:35 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D227.4010109@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
Message-ID: <20090122031935.GG29367@kvack.org>

On Wed, Jan 21, 2009 at 08:55:51PM -0500, Casey Dahlin wrote:
> Ctrl+Alt+F2

Gee, that got disabled too.

		-ben



From cdahlin at redhat.com  Thu Jan 22 03:22:05 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:22:05 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122031935.GG29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org>
Message-ID: <4977E65D.7070905@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:55:51PM -0500, Casey Dahlin wrote:
>   
>> Ctrl+Alt+F2
>>     
>
> Gee, that got disabled too.
>
> 		-ben
>   
Uhh..no?

--CJD



From bcrl at kvack.org  Thu Jan 22 03:22:02 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:22:02 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D0C2.9090900@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
Message-ID: <20090122032202.GH29367@kvack.org>

On Wed, Jan 21, 2009 at 08:49:54PM -0500, Casey Dahlin wrote:
> Then they don't need root.
> 
> Is it wrong that I actually /miss/ the linux community's sense of 
> elitism? It kept us so much more sensible on so many things.

If systems didn't break we wouldn't need root, sure.  But back here in 
reality, things aren't there yet.  Disallowing root logins merely makes 
life hard for those of us trying to fix broken systems.

		-ben



From bcrl at kvack.org  Thu Jan 22 03:23:11 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:23:11 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E65D.7070905@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
Message-ID: <20090122032311.GI29367@kvack.org>

On Wed, Jan 21, 2009 at 10:22:05PM -0500, Casey Dahlin wrote:
> Uhh..no?

Doesn't work on my F10 box...

		-ben



From cdahlin at redhat.com  Thu Jan 22 03:23:46 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:23:46 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032202.GH29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org>
Message-ID: <4977E6C2.7080905@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:49:54PM -0500, Casey Dahlin wrote:
>   
>> Then they don't need root.
>>
>> Is it wrong that I actually /miss/ the linux community's sense of 
>> elitism? It kept us so much more sensible on so many things.
>>     
>
> If systems didn't break we wouldn't need root, sure.  But back here in 
> reality, things aren't there yet.  Disallowing root logins merely makes 
> life hard for those of us trying to fix broken systems.
>
> 		-ben
>   
If you aren't technical, how will you fix your own system?

--CJD



From cdahlin at redhat.com  Thu Jan 22 03:24:39 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:24:39 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032311.GI29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
	<20090122032311.GI29367@kvack.org>
Message-ID: <4977E6F7.8090407@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:22:05PM -0500, Casey Dahlin wrote:
>   
>> Uhh..no?
>>     
>
> Doesn't work on my F10 box...
>
> 		-ben
>   
Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
instead of Ctrl+Alt+F7). F2-6 should be fine.

If not, file a bug.

--CJD



From bcrl at kvack.org  Thu Jan 22 03:25:12 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:25:12 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E6C2.7080905@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
Message-ID: <20090122032512.GJ29367@kvack.org>

On Wed, Jan 21, 2009 at 10:23:46PM -0500, Casey Dahlin wrote:
> If you aren't technical, how will you fix your own system?

By calling tech support or asking a technical user to help.  This isn't 
rocket science, but you're trying to make it as hard as possible.

		-ben



From bcrl at kvack.org  Thu Jan 22 03:26:39 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:26:39 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E6F7.8090407@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
	<20090122032311.GI29367@kvack.org> <4977E6F7.8090407@redhat.com>
Message-ID: <20090122032639.GK29367@kvack.org>

On Wed, Jan 21, 2009 at 10:24:39PM -0500, Casey Dahlin wrote:
> Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
> instead of Ctrl+Alt+F7). F2-6 should be fine.

No, it does not.  If it did, I wouldn't be ranting about the utterly insane 
defaults Fedora is deeming essential for all users without care for how it 
impacts the *entire* community.

		-ben



From cdahlin at redhat.com  Thu Jan 22 03:27:17 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:27:17 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032512.GJ29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org>
Message-ID: <4977E795.9030902@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:23:46PM -0500, Casey Dahlin wrote:
>   
>> If you aren't technical, how will you fix your own system?
>>     
>
> By calling tech support or asking a technical user to help.  This isn't 
> rocket science, but you're trying to make it as hard as possible.
>
> 		-ben
>   
And won't tech support know how to get root?

--CJD



From cdahlin at redhat.com  Thu Jan 22 03:27:53 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:27:53 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032639.GK29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
	<20090122032311.GI29367@kvack.org> <4977E6F7.8090407@redhat.com>
	<20090122032639.GK29367@kvack.org>
Message-ID: <4977E7B9.2050301@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:24:39PM -0500, Casey Dahlin wrote:
>   
>> Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
>> instead of Ctrl+Alt+F7). F2-6 should be fine.
>>     
>
> No, it does not.  If it did, I wouldn't be ranting about the utterly insane 
> defaults Fedora is deeming essential for all users without care for how it 
> impacts the *entire* community.
>
> 		-ben
>   
I maintain the init system. We did not disable these keys. File a bug.

--CJD



From bcrl at kvack.org  Thu Jan 22 03:29:40 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:29:40 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E795.9030902@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org> <4977E795.9030902@redhat.com>
Message-ID: <20090122032940.GL29367@kvack.org>

On Wed, Jan 21, 2009 at 10:27:17PM -0500, Casey Dahlin wrote:
> And won't tech support know how to get root?

Exactly, they won't be able to.

This cavalier to-hell-with-the-users attitude seems to get worse with every 
release.  It doesn't seem to matter how much effort is put into fighting the 
bad user attitude of people like you.  It's like zombies -- they're dead but 
keep trying to eat you.

		-ben



From cdahlin at redhat.com  Thu Jan 22 03:38:53 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:38:53 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032940.GL29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org> <4977E795.9030902@redhat.com>
	<20090122032940.GL29367@kvack.org>
Message-ID: <4977EA4D.3060908@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:27:17PM -0500, Casey Dahlin wrote:
>   
>> And won't tech support know how to get root?
>>     
>
> Exactly, they won't be able to.
>
> This cavalier to-hell-with-the-users attitude seems to get worse with every 
> release.  It doesn't seem to matter how much effort is put into fighting the 
> bad user attitude of people like you.  It's like zombies -- they're dead but 
> keep trying to eat you.
>
> 		-ben
>   
You can get root on a Fedora box. Easily. The reason for my attitude is 
confirmed. You clearly have /no idea what you're talking about/.

I've asked you twice now to file a bug against a legitimate problem. If 
you can't get a TTY on your box with Ctrl+Alt+F2 your install is broken.

--CJD



From tmz at pobox.com  Thu Jan 22 03:41:11 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Wed, 21 Jan 2009 22:41:11 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032940.GL29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com> <20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com> <20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com> <20090122032940.GL29367@kvack.org>
Message-ID: <20090122034110.GC25716@inocybe.teonanacatl.org>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:27:17PM -0500, Casey Dahlin wrote:
>> And won't tech support know how to get root?
>
> Exactly, they won't be able to.

Sure they will.  They just won't be doing it via a GUI, unless they
first change the default in the gdm pam config -- which is trivial for
someone that is capable of fixing your linux system.  Even more likely
is that they won't see any reason to login to a full desktop session
as root to perform such maintenance.

"Relax.  Have a homebrew." :-)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is OK to let your mind go blank, but please turn off the sound.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/75e5eefb/attachment.sig>

From ivazqueznet at gmail.com  Thu Jan 22 03:42:59 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 21 Jan 2009 22:42:59 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122031935.GG29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com>  <20090122031935.GG29367@kvack.org>
Message-ID: <1232595779.4002.91.camel@ignacio.lan>

On Wed, 2009-01-21 at 22:19 -0500, Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:55:51PM -0500, Casey Dahlin wrote:
> > Ctrl+Alt+F2
> 
> Gee, that got disabled too.

That would be because your video driver is broken.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/437ae984/attachment.sig>

From bcrl at kvack.org  Thu Jan 22 03:45:58 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Wed, 21 Jan 2009 22:45:58 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977EA4D.3060908@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org> <4977E795.9030902@redhat.com>
	<20090122032940.GL29367@kvack.org> <4977EA4D.3060908@redhat.com>
Message-ID: <20090122034558.GM29367@kvack.org>

On Wed, Jan 21, 2009 at 10:38:53PM -0500, Casey Dahlin wrote:
> You can get root on a Fedora box. Easily. The reason for my attitude is 
> confirmed. You clearly have /no idea what you're talking about/.

Please enlighten me how one gets root on a system where you can't get to a 
login prompt, and where logging in as a regular user fails?

> I've asked you twice now to file a bug against a legitimate problem. If 
> you can't get a TTY on your box with Ctrl+Alt+F2 your install is broken.

I've given up filing bugs on anything gnome or X related in the Fedora 
bugzilla, as they get closed when a release goes EOL without being fixed.  
Please prove me wrong this time.

		-ben



From cdahlin at redhat.com  Thu Jan 22 03:48:52 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Wed, 21 Jan 2009 22:48:52 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122034558.GM29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org> <4977E795.9030902@redhat.com>
	<20090122032940.GL29367@kvack.org> <4977EA4D.3060908@redhat.com>
	<20090122034558.GM29367@kvack.org>
Message-ID: <4977ECA4.9010604@redhat.com>

Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 10:38:53PM -0500, Casey Dahlin wrote:
>   
>> You can get root on a Fedora box. Easily. The reason for my attitude is 
>> confirmed. You clearly have /no idea what you're talking about/.
>>     
>
> Please enlighten me how one gets root on a system where you can't get to a 
> login prompt, and where logging in as a regular user fails?
>
>   
>> I've asked you twice now to file a bug against a legitimate problem. If 
>> you can't get a TTY on your box with Ctrl+Alt+F2 your install is broken.
>>     
>
> I've given up filing bugs on anything gnome or X related in the Fedora 
> bugzilla, as they get closed when a release goes EOL without being fixed.  
> Please prove me wrong this time.
>
> 		-ben
>   
I'll need to see the problem first, and all my F10 boxes are working in 
this regard.

--CJD



From cmadams at hiwaay.net  Thu Jan 22 03:59:01 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 21 Jan 2009 21:59:01 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032639.GK29367@kvack.org>
References: <49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
	<20090122032311.GI29367@kvack.org> <4977E6F7.8090407@redhat.com>
	<20090122032639.GK29367@kvack.org>
Message-ID: <20090122035901.GH1111797@hiwaay.net>

Once upon a time, Benjamin LaHaise <bcrl at kvack.org> said:
> On Wed, Jan 21, 2009 at 10:24:39PM -0500, Casey Dahlin wrote:
> > Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
> > instead of Ctrl+Alt+F7). F2-6 should be fine.
> 
> No, it does not.

Then your system is broken, and it doesn't matter if X is in F7 or F1,
apparently a console switch won't work in any case.

At that point someone that knows how to use root to fix things reboots
into text mode (or even single-user mode).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From rdieter at math.unl.edu  Thu Jan 22 04:40:44 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 21 Jan 2009 22:40:44 -0600
Subject: k3b permissions
References: <1232436704.6740.8.camel@PB3.Linux> <gl7a1k$qoj$1@ger.gmane.org>
	<1232572203.6740.21.camel@PB3.Linux>
Message-ID: <gl8t97$9fi$1@ger.gmane.org>

Paul wrote:

> I should be able to use /dev/sr0, but it won't allow me to burn (keeps
> saying to insert a blank disc - login as su and it's fine).

The problem lies elsewhere then, it's not device permissions at issue.

-- Rex




From jiteshs at marvell.com  Thu Jan 22 04:59:18 2009
From: jiteshs at marvell.com (Jitesh Shah)
Date: Wed, 21 Jan 2009 20:59:18 -0800
Subject: Koji: ServerOffline
In-Reply-To: <da159fda0901210930x274d57ddt564cc99b9cc1294f@mail.gmail.com>
References: <1232443977.9222.11.camel@localhost.localdomain>
	<62bc09df0901200148r51e20b76u48e56bd9b01a6993@mail.gmail.com>
	<1232446160.9222.20.camel@localhost.localdomain>
	<62bc09df0901200226k5406632bm69b832db6e2a1df2@mail.gmail.com>
	<1232449536.9222.30.camel@localhost.localdomain>
	<1232520824.3036.6.camel@localhost.localdomain>
	<da159fda0901210930x274d57ddt564cc99b9cc1294f@mail.gmail.com>
Message-ID: <1232600358.3077.1.camel@localhost.localdomain>

Hi Jon,
Thank you.. 

Jitesh

On Wed, 2009-01-21 at 12:30 -0500, Jon Stanley wrote:
> fedora-buildsys-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090121/bdabe6a1/attachment.htm>

From dchen at redhat.com  Thu Jan 22 05:55:31 2009
From: dchen at redhat.com (Ding-Yi Chen)
Date: Thu, 22 Jan 2009 15:55:31 +1000
Subject: ibus and F11
In-Reply-To: <20090121132419.GB23450@mokona.greysector.net>
References: <511187499.336701232409913305.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<374597091.336721232409977420.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20090120153053.GC14182@mokona.greysector.net>
	<1232496998.3759.11.camel@localhost.localdomain>
	<20090121132419.GB23450@mokona.greysector.net>
Message-ID: <1232603731.3987.10.camel@localhost.localdomain>


? ??2009-01-21 ? 14:24 +0100?Dominik 'Rathann' Mierzejewski ???
> On Wednesday, 21 January 2009 at 01:16, Ding-Yi Chen wrote:
> > 
> > ? ??2009-01-20 ? 16:30 +0100?Dominik 'Rathann' Mierzejewski ???
> > > On Tuesday, 20 January 2009 at 01:06, Jens Petersen wrote:
> > > > ----- "Dominik 'Rathann' Mierzejewski" <dominik at greysector.net> wrote:
> > > > > What's the migration path for SCIM users?
> > > > 
> > > > Users upgrading from earlier Fedora releases can continue to use scim
> > > > or if they wish they can install ibus themselves and use that.  Scim
> > > > will be continue to be in Fedora for the time being.
> > > 
> > > But if I install ibus, I'll have to configure it from scratch, right?
> > > There is no settings migration from SCIM, is there?
> > 
> > No, as it usually only involves a few mouse clicks or may be some key
> > press.
> > 
> > Just curious, what settings you did that make you think that the
> > settings migration would be a necessity? 
> 
> Keyboard shortcut settings. Reconfiguring them is time-consuming.
> 
> Regards,
> R.

Well let me put in this way. 
There are two ways to install fedora: Fresh install or upgrade.

For fresh install, people need to configure it from scratch anyway.
For upgrade, the present IM and setting are kept. iBus might be
installed, but you can either test it, remove it, or ignore it as
you please. :-)

> -- 
> Fedora http://fedoraproject.org/wiki/User:Rathann
> RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
> "Faith manages."
>         -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
> 



From joshuacov at googlemail.com  Thu Jan 22 06:43:26 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Thu, 22 Jan 2009 07:43:26 +0100
Subject: plans for kernel in F10?
In-Reply-To: <20090122012941.GA3657@yoda.jdub.homelinux.org>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
	<5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>
	<20090122012941.GA3657@yoda.jdub.homelinux.org>
Message-ID: <5f6f8c5f0901212243o2e96c075r1715a5cb95a08c27@mail.gmail.com>

2009/1/22 Josh Boyer <jwboyer at gmail.com>:
> To my knowledge, not soon.  .28 kernel mode setting and the X version
> in F9 don't get along.
>
> josh
>
Maybe it's time to go to f10. But I still have problems with this mode setting.



From joshuacov at googlemail.com  Thu Jan 22 06:50:39 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Thu, 22 Jan 2009 07:50:39 +0100
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <200901211725.02679.sgrubb@redhat.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>
	<200901200644.51574.sgrubb@redhat.com>
	<1232576379.12250.0.camel@localhost.localdomain>
	<200901211725.02679.sgrubb@redhat.com>
Message-ID: <5f6f8c5f0901212250h3cdeb338uea0461659891a452@mail.gmail.com>

2009/1/21 Steve Grubb <sgrubb at redhat.com>:
> On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
>> Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
>> > On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
>> > > actually after chattr +i not even root can modify / delete the file:
>> >
>> > True. But you can chattr -i ./foo and then edit the file remembering to
>> > make it immutable again when you are done editing it. Not as automatic as
>> > one might like, but that's how to do it.
>>
>> That would mean a race though. Better to fix directory permissions :)
>
> The original question was about a file owned by root but readable by others. I
> assume 0644 permissions. The root ownership still protects it.
>
> -Steve
>

This makes part of it useless: If the owner is root but I still can
delete/modify the file (because if dir permissions) then the ownership
doesn't matter. The file was set to 444. The idea was to have a file
that cannot be deleted/modified but only read by everyone regardless
of the directory permissions. And the only suitable answer is to set
it +i.



From wtogami at redhat.com  Thu Jan 22 07:13:32 2009
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Jan 2009 02:13:32 -0500
Subject: Root Logins in X...
Message-ID: <49781C9C.4000007@redhat.com>

Let us step back and consider the actual goal of preventing root logins.

We want to stop people from logging in as root on their X desktop
because it is almost always done out of laziness.  We want to discourage
these lazy users from logging in as root and using desktop applications,
which can be a dangerous thing.

The only legitimate reason to allow root login is disaster recovery.
The case where /home filesystem is full and logins fail, or /home is
remote and inaccessible are cases where graphical non-root logins can fail.

So why don't we make root logins from GDM a stripped down desktop with
only a terminal and a menu with only configuration tools?  This desktop
should be ugly and with a very obvious note explaining why they
shouldn't be logged in as root.

Benefits?
- Educates the users.
- Prevents future stupid flame wars.

Just a thought... I don't particularly care what happens here.  I never
log in as root on X.

Warren Togami
wtogami at redhat.com



From oliver at linux-kernel.at  Thu Jan 22 07:24:38 2009
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 22 Jan 2009 08:24:38 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977ECA4.9010604@redhat.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com>	<20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com>	<20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com>	<20090122032940.GL29367@kvack.org>
	<4977EA4D.3060908@redhat.com>	<20090122034558.GM29367@kvack.org>
	<4977ECA4.9010604@redhat.com>
Message-ID: <49781F36.80408@linux-kernel.at>

Casey Dahlin wrote:
> Benjamin LaHaise wrote:
>> On Wed, Jan 21, 2009 at 10:38:53PM -0500, Casey Dahlin wrote:
>>  
>>> You can get root on a Fedora box. Easily. The reason for my attitude 
>>> is confirmed. You clearly have /no idea what you're talking about/.
>>>     
>>
>> Please enlighten me how one gets root on a system where you can't get 
>> to a login prompt, and where logging in as a regular user fails?
>>
>>  
>>> I've asked you twice now to file a bug against a legitimate problem. 
>>> If you can't get a TTY on your box with Ctrl+Alt+F2 your install is 
>>> broken.
>>>     
>>
>> I've given up filing bugs on anything gnome or X related in the Fedora 
>> bugzilla, as they get closed when a release goes EOL without being 
>> fixed.  Please prove me wrong this time.
>>
>>         -ben
>>   
> I'll need to see the problem first, and all my F10 boxes are working in 
> this regard.

I've seen boxes where you cannot login any more because of LDAP and/or 
Kerberos Auth not working (for whatever reasons).

That's true for >root< account as well - even if the nsswitch.conf is 
*correct*.

However. Single User mode always helped and your Tech support will know 
how to get into init 1. I hope. If not, you should find another Tech 
Support :-P

Regarding your (Ctrl-)Alt-F2 Problem. I've never seen this. In no 
release. Well, something similar on a Desktop Box, where you try to 
switch from X to text console and the system freezes -> This was some 
nvid** driver bug. Already fixed with latest drivers of course.


Still. Single User mode is an option that *always* worked since I know 
UN*X/Linux and all their flavours :-)

-of



From wtogami at redhat.com  Thu Jan 22 07:35:07 2009
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Jan 2009 02:35:07 -0500
Subject: killall5 during halt, trouble with nbd-client
Message-ID: <497821AB.5000601@redhat.com>

https://fedorahosted.org/k12linux/wiki/NBDRootConfiguration
The fastest way to boot a diskless client is with NBD root filesystem
instead of NFS.  It works great.

/dev/nbd0 squashfs mounted at /
/dev/nbd1 dm_crypt swap as /dev/mapper/swap0

Unfortunately there is a problem during shutdown...

/etc/init.d/halt contains:
action $"Sending all processes the TERM signal..." /sbin/killall5 -15
sleep 2
action $"Sending all processes the KILL signal..."  /sbin/killall5 -9

Thereafter it stops swap and unmounts filesystems.  Only it gets stuck
and fails to reboot or poweroff here, because the underlying block
devices have disappeared due to killall5.  The two nbd-client instances
that were running /dev/nbd0 and /dev/nbd1 block devices are now gone,
causing the system to get stuck.

Would iscsi root filesystem have the same problem during shutdown?

It seems NFS root shutdown doesn't have this issue because there is no
userspace process to kill that would kill the filesystem mount.

Any ideas how we can cleanly handle shutdown in cases like NBD where a
userspace process is providing the block device, but gets killed
prematurely?

Warren Togami
wtogami at redhat.com



From robert at fedoraproject.org  Thu Jan 22 07:36:41 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 22 Jan 2009 08:36:41 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <49768F95.5080800@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
Message-ID: <20090122073641.GA6637@hurricane.linuxnetz.de>

On Wed, 21 Jan 2009, Rahul Sundaram wrote:
> You can at run level 3. You can even start X after that.

Haha, if the machine is a few hundred miles away at the customer and you
don't have any longer access? Ever tried to explain a non-computer user
being near to the machine how to solve issues via phone if it's urgent or
even critical and time to drive the few hundred miles is not available,
too? Very clever suggestion, you've made...


Greetings,
  Robert



From shamardin at gmail.com  Thu Jan 22 07:43:28 2009
From: shamardin at gmail.com (Lev Shamardin)
Date: Thu, 22 Jan 2009 10:43:28 +0300
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <49781F36.80408@linux-kernel.at>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4977D0C2.9090900@redhat.com>	<20090122032202.GH29367@kvack.org>	<4977E6C2.7080905@redhat.com>	<20090122032512.GJ29367@kvack.org>	<4977E795.9030902@redhat.com>	<20090122032940.GL29367@kvack.org>	<4977EA4D.3060908@redhat.com>	<20090122034558.GM29367@kvack.org>	<4977ECA4.9010604@redhat.com>
	<49781F36.80408@linux-kernel.at>
Message-ID: <497823A0.9090009@gmail.com>

On 01/22/2009 10:24 AM, Oliver Falk wrote:
>>>> I've asked you twice now to file a bug against a legitimate problem.
>>>> If you can't get a TTY on your box with Ctrl+Alt+F2 your install is
>>>> broken.
>>>>     
>>>
>>> I've given up filing bugs on anything gnome or X related in the
>>> Fedora bugzilla, as they get closed when a release goes EOL without
>>> being fixed.  Please prove me wrong this time.
>>>
>>>         -ben
>>>   
>> I'll need to see the problem first, and all my F10 boxes are working
>> in this regard.
> 
> Regarding your (Ctrl-)Alt-F2 Problem. I've never seen this. In no
> release. Well, something similar on a Desktop Box, where you try to
> switch from X to text console and the system freezes -> This was some
> nvid** driver bug. Already fixed with latest drivers of course.

I've seen broken Ctrl-Alt-F2 problem on the box I'm using right now to write
this mail. However this problem is not persistent and I yet haven't found a
reliable way to reproduce it. On the GDM screen and right after logging in
switching works fine, but some time later it does brake. If I find how to
reproduce this I will file a bug.

--
Lev.



From kanarip at kanarip.com  Thu Jan 22 08:01:00 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 22 Jan 2009 09:01:00 +0100
Subject: [Fedora-spins] Spins SIG Meeting Minutes 19-01-2009
In-Reply-To: <20090121140715.GB30705@localhost.localdomain>
References: <4976F718.9030702@kanarip.com>
	<20090121140715.GB30705@localhost.localdomain>
Message-ID: <497827BC.1090706@kanarip.com>

Paul W. Frields wrote:
> On Wed, Jan 21, 2009 at 11:21:12AM +0100, Jeroen van Meeuwen wrote:
>> PS: Can someone point me to the irc2html log converter?
> 
> You may already have an answer, but there's now a package in Fedora:
> 
> yum install irclog2html
> 

Haha, and I was searching for irc2html ;-)

Thanks!

Kind regards,

Jeroen van Meeuwen
-kanarip



From sundaram at fedoraproject.org  Thu Jan 22 08:01:32 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Jan 2009 13:31:32 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122073641.GA6637@hurricane.linuxnetz.de>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>
	<20090122073641.GA6637@hurricane.linuxnetz.de>
Message-ID: <497827DC.7030303@fedoraproject.org>

Robert Scheck wrote:
> On Wed, 21 Jan 2009, Rahul Sundaram wrote:
>> You can at run level 3. You can even start X after that.
> 
> Haha, if the machine is a few hundred miles away at the customer and you
> don't have any longer access? Ever tried to explain a non-computer user
> being near to the machine how to solve issues via phone if it's urgent or
> even critical and time to drive the few hundred miles is not available,
> too? Very clever suggestion, you've made...

Yes. I have. For a few years actually and in my experience, it has 
always been more efficient to instruct people type things in the 
terminal rather than login via GDM as root user. For one, the shell is 
pretty consistent, commands don't change often if at all and for 
administration, you frequently have to fall back to the terminal anyway.

Never once have I felt a real need to tell people to get a root X login 
for any reason at all.

Rahul



From rawhide at fedoraproject.org  Thu Jan 22 08:03:52 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 22 Jan 2009 08:03:52 +0000 (UTC)
Subject: rawhide report: 20090122 changes
Message-ID: <20090122080352.55D401B8001@releng2.fedora.phx.redhat.com>

Compose started at Thu Jan 22 06:01:03 UTC 2009

New package cas
        Tool to analyze and configure core file environment
New package ctan-cm-lgc-fonts
        CM-LGC Type1 fonts
New package python-ldaphelper
        A python wrapper for LDAP search results
New package pywebdav
        WebDAV library
New package udev-extras
        Extra rules and tools for udev
Removed package vnc
Updated Packages:

akonadi-1.1.1-1.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1.1.1-1
- 1.1.1


anaconda-11.5.0.11-1
--------------------
* Wed Jan 21 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 11.5.0.11-1
- Fix a logic problem with network file write outs. (480769) (jkeating)
- Only run selectBestKernel, selectBootloader, etc. for new installs.
  (wwoods)


autofs-5.0.4-6
--------------
* Wed Jan 21 17:00:00 2009 Jeff Moyer <jmoyer at redhat.com> - 5.0.4-6
- fix a bug in the program map parsing routine


automake-1.10.2-2
-----------------
* Wed Jan 21 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 1.10.2-2
- convert NEWS file to UTF-8 (#225302)


bind-9.6.0-3.P1.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Adam Tkac <atkac redhat com> 32:9.6.0-3.P1
- rebuild against new openssl


cairo-dock-2.0.0-0.3.svn1496_trunk.fc11
---------------------------------------
* Thu Jan 22 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1496
- Include Wanda directory in Cairo-Penguin plug-in again


calcurse-2.4-1.fc11
-------------------
* Wed Jan 21 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> 2.4-1
- Update to 2.4.


cjkuni-fonts-0.2.20080216.1-17.fc11
-----------------------------------
* Thu Jan 22 17:00:00 2009 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-17.fc11
- Resolves: rhbz#477373
- Refined package dependencies and compat font symlinks.

* Wed Jan 21 17:00:00 2009 Caius Chance <cchance at redhat.com> - 0.2.20080216.1-16.fc11
- Resolves: rhbz#253813
- Renamed from cjkunifonts to cjkuni-fonts according to new font packaging
  guidelines.


cluster-3.0.0-3.alpha2.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Fabio M. Di Nitto <fdinitto at redhat.com> - 3.0.0-3.alpha2
- Move all binaries where they belong. All the legacy stuff is now dead.


clutter-0.8.6-1.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.8.6-1
- Update to 0.8.6


cyrus-imapd-2.3.13-2.fc11
-------------------------
* Wed Jan 21 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> - 2.3.13-2
- fix: #480138 - assertion failed: libcyr_cfg.c: cyrus_options[opt].opt == opt


fedora-business-cards-0.2.4-3.fc11
----------------------------------
* Wed Jan 21 17:00:00 2009 Ian Weller <ianweller at gmail.com> 0.2.4-3
- Fix F11 dependency on the MgOpen fonts (again)


fedora-release-10.91-1
----------------------
* Wed Jan 21 17:00:00 2009 Jesse Keating <jkeating at redhat.com> - 10.91-1
- Update for Fedora 11 Alpha
- Use metalink urls to get mirror information


fontpackages-1.16-1.fc11
------------------------
* Thu Jan 22 17:00:00 2009 Nicolas Mailhot <nim at fedoraproject dot org>
- 1.16-1


freehoo-3.5.3-1.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Ray Van Dolson <rayvd at fedoraproject.org> - 3.5.3-1
- Upstream released 3.5.3


freetds-0.82-3.fc10
-------------------
* Sun Jan 11 17:00:00 2009 Dmitry Butskoy <Dmitry at Butskoy.name> - 0.82-3
- Use gnutls for SSL (#479148)


gnome-applet-music-2.5.1-1.fc11
-------------------------------
* Wed Jan 21 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 2.5.1-1
- Update to new upstream release (2.5.1), which fixes the applet hanging when
  the player is closed, and processing of album art from Rhythmbox so that it
  is shown properly in the information tooltip.


gnome-applets-2.25.4-2.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.4-2
- Fix trash applet not starting up


gnomint-0.9.1-1.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Adam Huffman <bloch at verdurin.com> - 0.9.1-1
- new upstream release including command-line interface
- thanks to Seva Epsteyn for spec patch

* Fri Nov 21 17:00:00 2008 Adam Huffman <bloch at verdurin.com> - 0.6.0-1
- new upstream release


hunspell-ru-0.99f7-2.fc11
-------------------------
* Wed Jan 21 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 1:0.99f7-2
- add alias


hwdata-0.221-1.fc11
-------------------
* Wed Jan 21 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 0.221-1
- update usb.ids pci.ids oui.txt

* Tue Dec  2 17:00:00 2008 Karsten Hopp <karsten at redhat.com> 0.220-1
- add new monitor entries from Mandriva hardware database (Thierry Vignaud)
- make generic entries have properly formated frequencies (Thierry Vignaud)
- remove duplicate Dell monitor entries (Thierry Vignaud)
- more vendor name fixes
- fix extra field in 'Compudyne KD-1500N' definition (Thierry Vignaud)
- make Dell monitors case consistent (Thierry Vignaud)
- make all GoldStar monitors have the same vendor name (Thierry Vignaud)
- add URL of git repository
- fix spacing (Thierry Vignaud)
- sort MonitorDB file with LANG=C sort -f -t ";" -k1,2
- add Samsung SyncMaster 2443BWX (Marc van den Dikkenberg)
- add some Lenovo monitors (Im Sza)


hyphen-ru-0.20020727-2.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20020727-2
- add an alias


inksmoto-0.5.0-4.fc11
---------------------
* Wed Jan 21 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 0.5.0-4
- New upstream, 0.5.0 final.


iperf-2.0.4-1.fc11
------------------
* Wed Jan 21 17:00:00 2009 Gabriel Somlo <somlo at cmu.edu> 2.0.4-1
- update to 2.0.4
- patch to avoid tcp/dualtest server from quitting (bugzilla #449796), also submitted to iperf sourceforge ticket tracker (#1983829)


kipi-plugins-0.2.0-0.12.beta6.fc11
----------------------------------
* Wed Jan 21 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.2.0-0.12.beta6
- update %description
- License: +Adobe (DNGConverter)


ksh-20081104-1.fc11
-------------------
* Wed Jan 21 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> 20091104-1
- update to 2008-11-04
- ast-ksh-locales are not useable remove them


lftp-3.7.7-1.fc11
-----------------
* Wed Jan 14 17:00:00 2009 Jiri Skala <jskala at redhat.com> - 3.7.7-1
- rebase to latest upstream version
- resolves license conflict GPLv2 -> GPLv3+ due to gnulib


libcanberra-0.11-5.fc11
-----------------------
* Wed Jan 21 17:00:00 2009 Lennart Poettering <lpoetter at redhat.com> 0.11-1
- New version


libmtp-0.3.6-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Linus Walleij <triad at df.lth.se> 0.3.6-1
- New upstream bugfix release.


lilypond-2.12.1-3.fc11
----------------------
* Wed Jan 21 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.12.1-3
- Drop feta-fonts package cruft.


mgopen-fonts-0.20050515-13.fc11
-------------------------------
* Wed Jan 21 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-13
- Drop provides mgopen-fonts for the -compat subpackage.

* Wed Jan 21 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-12
- Fix typo in provides: fontpackages-filesystem
- Add provides mgopen-fonts to the -compat subpackage.


moodle-1.9.3-5.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 1.9.3-5
- Dropped and symlinked illegal sm and to fonts.
- Symlinking to FreeSans.
- Drop spell-check-logic.cgi, CVE-2008-5153, per upstream, BZ 472117, 472119, 472120.


mtools-4.0.0-3.fc11
-------------------
* Wed Jan 21 17:00:00 2009 Adam Tkac <atkac redhat com> 4.0.0-3
- fixed off-by-two error in unix_name function (#480112)


mythes-ga-0.20071001-2.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20071001-2
- fix typos


netpbm-10.35.58-2.fc11
----------------------
* Wed Jan 21 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 10.35.58-2
- fix pnmtofiasco to accept image from stdin (#476989, #227283)


ocaml-cil-1.3.6-10.fc11
-----------------------
* Wed Jan 21 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 1.3.6-10
- Fix prelink configuration file.


ocaml-ocamlnet-2.2.9-10.fc11
----------------------------
* Wed Jan 21 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 2.2.9-10
- Fix prelink configuration file.


openoffice.org-voikko-3.0.1-1.fc11
----------------------------------
* Wed Jan 21 17:00:00 2009 Ville-Pekka Vainio <vpivaini AT cs.helsinki.fi> - 3.0.1-1
- openoffice.org-voikko 3.0.1
- Drop integrated OOO 3.0.1 compatibility patch
- Require OOO 3.0.1


pdf-renderer-0-0.4.20090118cvs.fc11
-----------------------------------
* Wed Jan 21 17:00:00 2009 Orcan Ogetbil <oget [DOT] fedora [AT] gmail [DOT] com> 0-0.4.20090118cvs
- New cvs checkout


perl-Devel-GlobalDestruction-0.02-3.fc11
----------------------------------------

policycoreutils-2.0.61-4.fc11
-----------------------------
* Wed Jan 21 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-4
- Fix Translations


qpidc-0.4.734452-3.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.734452-3
- BZ474614 and BZ474613 - qpidc/rhm unowned directories


ruby-openid-2.1.4-1.fc11
------------------------
* Wed Jan 21 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 2.1.4-1
- Update to 2.1.4


rubygem-hoe-1.8.3-1.fc11
------------------------
* Wed Jan 21 17:00:00 2009 Darryl Pierce <dpierce at redhat.com> - 1.8.3-1
- Release 1.8.3 of Hoe.


selinux-policy-3.6.3-6.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-6
- Add wm policy
- Make mls work in graphics mode

* Tue Jan 20 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-3
- Fixed for DeviceKit


setroubleshoot-2.1.2-1.fc11
---------------------------
* Wed Jan 21 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 2.1.2-1
- Fixes missing dbus config files


smolt-1.2-3.fc11
----------------
* Wed Jan 21 17:00:00 2009 Mike McGrath <mmcgrath at redhat.com> - 1.2-3
- Added os_detect.py as it is now required.


trytond-1.0.2-2.fc11
--------------------
* Wed Jan 21 17:00:00 2009 Dan Hor??k <dan[at]danny.cz> 1.0.2-2
- add modular support for webdav


wmx-7-3.fc11
------------
* Mon Jan 19 17:00:00 2009 Gabriel Somlo <somlo at cmu.edu> 7-3
- applied patch for use of compositing offscreen storage to speed up rendering
- added buildreq for libxcomposite-devel


xfconf-4.5.93-2.fc11
--------------------

Summary:
Added Packages: 5
Removed Packages: 1
Modified Packages: 50
Broken deps for i386
----------------------------------------------------------
	cas-0.13-118.fc10.noarch requires python(abi) = 0:2.5
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for x86_64
----------------------------------------------------------
	cas-0.13-118.fc10.noarch requires python(abi) = 0:2.5
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.i386 requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.x86_64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cas-0.13-118.fc10.noarch requires python(abi) = 0:2.5
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc requires pkgconfig(libtelepathy) >= 0:0.0.54
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cas-0.13-118.fc10.noarch requires python(abi) = 0:2.5
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	publican-0.40-0.fc11.noarch requires baekmuk-ttf-fonts-batang
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.3.2
	telepathy-mission-control-devel-4.67-2.fc11.ppc64 requires pkgconfig(libtelepathy) >= 0:0.0.54
	tetex-font-cm-lgc-0.5-11.fc11.noarch requires cm-lgc-fonts
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11





From thomas.moschny at gmail.com  Thu Jan 22 09:04:31 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 22 Jan 2009 10:04:31 +0100
Subject: NFS tcp wrapper situation
In-Reply-To: <1232589010.3539.263.camel@localhost.localdomain>
References: <49764DC5.1050907@redhat.com> <4976781D.2020109@redhat.com>
	<4976A1CB.4050600@redhat.com> <200901211742.54124.sgrubb@redhat.com>
	<20090121231825.GA1111797@hiwaay.net> <4977AF5D.8020302@redhat.com>
	<20090122004854.GC1111797@hiwaay.net>
	<1232589010.3539.263.camel@localhost.localdomain>
Message-ID: <a9d183c80901220104p197e0446r828b315d01a68c5@mail.gmail.com>

2009/1/22 Jesse Keating <jkeating at redhat.com>:
> However each of these do allow you to set a specific port they'll run
> on, so that you /can/ use iptables with them.  I've been running them
> that way for years.

Unless there are bugs like this one:
https://bugzilla.redhat.com/show_bug.cgi?id=458448 (YP, not NFS, but
anyway).

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From nicolas.mailhot at laposte.net  Thu Jan 22 09:18:40 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Jan 2009 10:18:40 +0100 (CET)
Subject: comps discussion at fudcon and the future
In-Reply-To: <20090122001427.GB5638@nostromo.devel.redhat.com>
References: <1922227151.1010571232582022925.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<783022041.1011321232582458070.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com>
	<20090122001427.GB5638@nostromo.devel.redhat.com>
Message-ID: <262a81e5941be7ec956750c81b89f43e.squirrel@arekh.dyndns.org>



Le Jeu 22 janvier 2009 01:14, Bill Nottingham a ?crit :
>
> Jens Petersen (petersen at redhat.com) said:
>> So how about including this in yum-utils?
>
> The metadata that this uses would need to be defined and added
> somewhere
> first - hardcoding it in the plugin works for a proof-of-concept, but
> isn't
> the way we want to go long-term.

BTW if someone works on this kind of stuff it would be great if compat
packages could declare "I am a compat package, I will go away
mid-term" so that tools (rpmbuild, yum, pk...) could warn when someone
makes an operation involving those packages (adding a (build)dep on
it, etc).

-- 
Nicolas Mailhot



From fedora at camperquake.de  Thu Jan 22 09:31:31 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Thu, 22 Jan 2009 10:31:31 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E104.4070706@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<4977D595.6070305@ij.net> <4977D61D.7020501@redhat.com>
	<4977DA16.2040901@ij.net> <4977E104.4070706@redhat.com>
Message-ID: <20090122103131.69d05708@dhcp03.addix.net>

Hi.

On Wed, 21 Jan 2009 21:59:16 -0500, Casey Dahlin wrote:

> And graphical boot will go away when Fedora boots in 5 seconds (which
> it may do soon).

To be completely honest, I'm not holding my breath for that one.



From nicolas.mailhot at laposte.net  Thu Jan 22 09:32:40 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 22 Jan 2009 10:32:40 +0100 (CET)
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <1232595779.4002.91.camel@ignacio.lan>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com> <20090122031935.GG29367@kvack.org>
	<1232595779.4002.91.camel@ignacio.lan>
Message-ID: <2f0550d6fbee0ee58bde703a2d3de06d.squirrel@arekh.dyndns.org>



Le Jeu 22 janvier 2009 04:42, Ignacio Vazquez-Abrams a ?crit :
> On Wed, 2009-01-21 at 22:19 -0500, Benjamin LaHaise wrote:
>> On Wed, Jan 21, 2009 at 08:55:51PM -0500, Casey Dahlin wrote:
>> > Ctrl+Alt+F2
>>
>> Gee, that got disabled too.
>
> That would be because your video driver is broken.

Or if the system was upgraded and some xfree86 => xorg or kbd => evdev
input migration went wrong. One of the symptoms can be dead CTRL in X.

-- 
Nicolas Mailhot



From dan at danny.cz  Thu Jan 22 09:44:40 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 22 Jan 2009 10:44:40 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977E6F7.8090407@redhat.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com> <20090122031935.GG29367@kvack.org>
	<4977E65D.7070905@redhat.com> <20090122032311.GI29367@kvack.org>
	<4977E6F7.8090407@redhat.com>
Message-ID: <1232617480.3681.16.camel@eagle.danny.cz>

Casey Dahlin p??e v St 21. 01. 2009 v 22:24 -0500:
> Benjamin LaHaise wrote:
> > On Wed, Jan 21, 2009 at 10:22:05PM -0500, Casey Dahlin wrote:
> >   
> >> Uhh..no?
> >>     
> >
> > Doesn't work on my F10 box...
> >
> > 		-ben
> >   
> Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
> instead of Ctrl+Alt+F7). F2-6 should be fine.
> 
> If not, file a bug.

The F2-6 are blocked when you have getty running on vt1
(/etc/event.d/tty1 is the same tty[2-6]) and Xorg server runs on vt1 too
(gdm runs with --force-active-vt)
Then there are messages like "unable to switch vt" in /var/log/Xorg.log


		Dan




From singularitaet at gmx.net  Thu Jan 22 10:06:19 2009
From: singularitaet at gmx.net (Stefan Grosse)
Date: Thu, 22 Jan 2009 11:06:19 +0100
Subject: smart package manager oddities
Message-ID: <20090122110619.40ad8525@gmx.net>

Hi,

I was trying to clean up my system. When I was running kdirstat I
discovered that the smart package manager consumed 30 percent of my
disk space since it seems to create a huge file in /var/lib/channels at
every channel update. (140 MB for fedora-development)

I reported the bug in smart/launchpad:
https://bugs.launchpad.net/smart/+bug/319965

Can someone confirm this problem?

Unfortunately removing smart does not remove those files. So I have to
manually remove them. Why is yum not cleaning completely?

Cheers
Stefan



From bmr at redhat.com  Thu Jan 22 10:51:25 2009
From: bmr at redhat.com (Bryn M. Reeves)
Date: Thu, 22 Jan 2009 10:51:25 +0000
Subject: Wrong security attributes. Maybe a bug?
In-Reply-To: <5f6f8c5f0901212250h3cdeb338uea0461659891a452@mail.gmail.com>
References: <5f6f8c5f0901190914k5f51e939m7141134a7b805dac@mail.gmail.com>	<200901200644.51574.sgrubb@redhat.com>	<1232576379.12250.0.camel@localhost.localdomain>	<200901211725.02679.sgrubb@redhat.com>
	<5f6f8c5f0901212250h3cdeb338uea0461659891a452@mail.gmail.com>
Message-ID: <49784FAD.1070506@redhat.com>

Joshua C. wrote:
> 2009/1/21 Steve Grubb <sgrubb at redhat.com>:
>> On Wednesday 21 January 2009 05:19:39 pm nodata wrote:
>>> Am Dienstag, den 20.01.2009, 06:44 -0500 schrieb Steve Grubb:
>>>> On Monday 19 January 2009 04:13:09 pm Manuel Wolfshant wrote:
>>>>> actually after chattr +i not even root can modify / delete the file:
>>>> True. But you can chattr -i ./foo and then edit the file remembering to
>>>> make it immutable again when you are done editing it. Not as automatic as
>>>> one might like, but that's how to do it.
>>> That would mean a race though. Better to fix directory permissions :)
>> The original question was about a file owned by root but readable by others. I
>> assume 0644 permissions. The root ownership still protects it.
>>
>> -Steve
>>
> 
> This makes part of it useless: If the owner is root but I still can
> delete/modify the file (because if dir permissions) then the ownership
> doesn't matter. The file was set to 444. The idea was to have a file
> that cannot be deleted/modified but only read by everyone regardless
> of the directory permissions. And the only suitable answer is to set
> it +i.
> 

Or make the directory sticky if you must give untrusted users write 
access to it and do not want them to be able to unlink or rename one 
another's files?

Bryn.



From mcepl at redhat.com  Thu Jan 22 10:50:16 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:50:16 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com> <20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com> <20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com> <20090122032940.GL29367@kvack.org>
	<4977EA4D.3060908@redhat.com> <20090122034558.GM29367@kvack.org>
Message-ID: <8kvl46xrac.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 03:45 GMT, Benjamin LaHaise wrote:
> I've given up filing bugs on anything gnome or X related in the 
> Fedora bugzilla, as they get closed when a release goes EOL 
> without being fixed.  Please prove me wrong this time.

Prove yourself wrong yourself -- what happens when you do 
Ctrl+Alt+F2 in X?

Matej



From mcepl at redhat.com  Thu Jan 22 10:58:59 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:58:59 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com> <20090122031935.GG29367@kvack.org>
Message-ID: <j40m46x0hc.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 03:19 GMT, Benjamin LaHaise wrote:
> On Wed, Jan 21, 2009 at 08:55:51PM -0500, Casey Dahlin wrote:
>> Ctrl+Alt+F2
>
> Gee, that got disabled too.

No, it didn't.



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Jan 22 11:04:56 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 22 Jan 2009 20:04:56 +0900
Subject: [QA] To clone or not to clone ( a bug report ) that's
	the	question...
In-Reply-To: <497797C8.1050209@hi.is>
References: <497797C8.1050209@hi.is>
Message-ID: <497852D8.7030902@ioa.s.u-tokyo.ac.jp>

J?hann B. Gu?mundsson wrote, at 01/22/2009 06:46 AM +9:00:
> When a Bug Hunter encounters the same bug in past (supported ) release, 
> current release and rawhide.
> 
> Should he..
> 
> A.
>     File the same bug 3 times as in once for each release?
> 
> Or
> 
> B.
>     File the bug once and comment on that report that the same bug
>     is present in the other release(s) as well?
> 
> Cast your opinions and vote on how you prefer it.
> 
> The majority of the outcome will decide on how Bug Hunters will be 
> directed to
> handle this.
> 
> JBG

Just FYI this topic once brought up one year ago:
http://www.redhat.com/archives/fedora-devel-list/2008-January/msg02836.html

Mamoru



From mcepl at redhat.com  Thu Jan 22 10:47:42 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:47:42 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090122073641.GA6637@hurricane.linuxnetz.de>
Message-ID: <efvl46xrac.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 07:36 GMT, Robert Scheck wrote:
> Haha, if the machine is a few hundred miles away at the 
> customer and you don't have any longer access?

How would root X login help you in this situation (if apparently 
ssh is not enough)?

Matej



From mcepl at redhat.com  Thu Jan 22 10:58:44 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:58:44 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
Message-ID: <440m46x0hc.ln2@ppp1053.in.ipex.cz>

On 2009-01-21, 15:53 GMT, Benjamin LaHaise wrote:
> Even then, with F10 using a 0 second wait at the grub prompt, 
> it's almost impossible to catch grub in time to specify the 
> runlevel or init=/bin/sh.

OK, is THIS the problem? Then don't babble about disallowing root 
login (which is nonsense and your repeating won't make it true 
ever). I don't like this default either, but pressing 'a' 
repeatedly will get you to the kernel command prompt. And the 
problem is not 0 timeout (there is 5 IIRC), but the 'hiddenmenu' 
option which makes grub menu invisible.

Matej



From dr.diesel at gmail.com  Thu Jan 22 11:17:48 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 22 Jan 2009 06:17:48 -0500
Subject: Root Logins in X...
In-Reply-To: <49781C9C.4000007@redhat.com>
References: <49781C9C.4000007@redhat.com>
Message-ID: <2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>

On Thu, Jan 22, 2009 at 2:13 AM, Warren Togami <wtogami at redhat.com> wrote:

> Let us step back and consider the actual goal of preventing root logins.
>
> We want to stop people from logging in as root on their X desktop
> because it is almost always done out of laziness.  We want to discourage
> these lazy users from logging in as root and using desktop applications,
> which can be a dangerous thing.
>
> The only legitimate reason to allow root login is disaster recovery.
> The case where /home filesystem is full and logins fail, or /home is
> remote and inaccessible are cases where graphical non-root logins can fail.
>
> So why don't we make root logins from GDM a stripped down desktop with
> only a terminal and a menu with only configuration tools?  This desktop
> should be ugly and with a very obvious note explaining why they
> shouldn't be logged in as root.
>
> Benefits?
> - Educates the users.
> - Prevents future stupid flame wars.
>
> Just a thought... I don't particularly care what happens here.  I never
> log in as root on X.
>
> Warren Togami
> wtogami at redhat.com



Who are we to police log-ins anyhow?  If they are too lazy and completely
hose the system that is their problem.  I frankly find it quite irritating
that a couple of the servers stuffed away in my locked server room that are
only accessible my me, only accessed once in 60-90 days, can't sit there
logged in as root.

What's next?  We going to force Gnome, Firefox, SElinux, etc cause we feel
it is safer?

We are about choice, ask the user during install if he/she wants to prevent
root logg-ins.



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/0c6bb7d7/attachment.htm>

From aph at redhat.com  Thu Jan 22 11:19:23 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 22 Jan 2009 11:19:23 +0000
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <440m46x0hc.ln2@ppp1053.in.ipex.cz>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>
	<440m46x0hc.ln2@ppp1053.in.ipex.cz>
Message-ID: <4978563B.1020400@redhat.com>

Matej Cepl wrote:
> On 2009-01-21, 15:53 GMT, Benjamin LaHaise wrote:
>> Even then, with F10 using a 0 second wait at the grub prompt, 
>> it's almost impossible to catch grub in time to specify the 
>> runlevel or init=/bin/sh.
> 
> OK, is THIS the problem? Then don't babble about disallowing root 
> login (which is nonsense and your repeating won't make it true 
> ever). I don't like this default either, but pressing 'a' 
> repeatedly will get you to the kernel command prompt. And the 
> problem is not 0 timeout (there is 5 IIRC), but the 'hiddenmenu' 
> option which makes grub menu invisible.

I didn't know that pressing 'a' repeatedly will get you to the kernel
command prompt.  The problem with a lot of these changes is that they
break techniques that people have used for many years.  And if you don't
know that the pressing 'a' trick exists, you don't know how to ask
how to do it -- especially if your computer doesn't boot.

Andrew.



From mcepl at redhat.com  Thu Jan 22 10:51:55 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:51:55 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com> <20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com> <20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com> <20090122032940.GL29367@kvack.org>
	<4977EA4D.3060908@redhat.com> <20090122034558.GM29367@kvack.org>
	<4977ECA4.9010604@redhat.com> <49781F36.80408@linux-kernel.at>
	<497823A0.9090009@gmail.com>
Message-ID: <bnvl46xrac.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 07:43 GMT, Lev Shamardin wrote:
> I've seen broken Ctrl-Alt-F2 problem on the box I'm using right 
> now to write this mail.

Yes, there are bugs like that with some drivers -- we are working 
on it as much as we can, but there is certainly not policy about 
non-X root login, and we are dancing as fast as we can to fix it.

Matej



From mcepl at redhat.com  Thu Jan 22 10:49:01 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 11:49:01 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com> <20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com> <20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com> <20090122032940.GL29367@kvack.org>
Message-ID: <thvl46xrac.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 03:29 GMT, Benjamin LaHaise wrote:
> Exactly, they won't be able to.

Since when Ctrl+Alt+F2 doesn't work (well, it doesn't work 
sometimes due to bugs in graphics drivers, then you have to 
resort to ssh)? Please, don't spread false rumours.

Matej



From mcepl at redhat.com  Thu Jan 22 11:07:14 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 12:07:14 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20d6441a0901210718n5f975195o96b379a083959742@mail.gmail.com>
Message-ID: <2k0m46x0hc.ln2@ppp1053.in.ipex.cz>

On 2009-01-21, 15:18 GMT, Jud Craft wrote:
> To be rhetorical, we must ask, why?

Don't be rhetorical -- X apps have been written for many years 
now with explicit understanding that they will never be run as 
root. Firefox is just much more complicated than lynx. If you 
don't like it and you trust Firefox more than its developers, 
than go ahead and change that pam config.

Matej



From dan at danny.cz  Thu Jan 22 11:31:59 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Thu, 22 Jan 2009 12:31:59 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <1232617480.3681.16.camel@eagle.danny.cz>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<4977D227.4010109@redhat.com> <20090122031935.GG29367@kvack.org>
	<4977E65D.7070905@redhat.com> <20090122032311.GI29367@kvack.org>
	<4977E6F7.8090407@redhat.com> <1232617480.3681.16.camel@eagle.danny.cz>
Message-ID: <1232623919.3681.34.camel@eagle.danny.cz>

Dan Hor?k p??e v ?t 22. 01. 2009 v 10:44 +0100:
> Casey Dahlin p??e v St 21. 01. 2009 v 22:24 -0500:
> > Benjamin LaHaise wrote:
> > > On Wed, Jan 21, 2009 at 10:22:05PM -0500, Casey Dahlin wrote:
> > >   
> > >> Uhh..no?
> > >>     
> > >
> > > Doesn't work on my F10 box...
> > >
> > > 		-ben
> > >   
> > Ctrl+Alt+F1 no longer works (or rather, it brings up the X server 
> > instead of Ctrl+Alt+F7). F2-6 should be fine.
> > 
> > If not, file a bug.
> 
> The F2-6 are blocked when you have getty running on vt1
> (/etc/event.d/tty1 is the same tty[2-6]) and Xorg server runs on vt1 too
> (gdm runs with --force-active-vt)
> Then there are messages like "unable to switch vt" in /var/log/Xorg.log

The behaviour above requires manual editing of at
least /etc/event.d/tty1, it should not happen in default setups.


		Dan




From kevin.kofler at chello.at  Thu Jan 22 11:56:08 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 12:56:08 +0100
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
	<gl8bnm$2tm$1@ger.gmane.org>
	<20090121235634.GA5638@nostromo.devel.redhat.com>
Message-ID: <gl9mso$m5t$1@ger.gmane.org>

Bill Nottingham wrote:
> For any bug that's filed? Wow, and people thought we did a lot of
> updates *now*.

Well, if it's something like "please update Summary/Description/URL", then
really nobody cares when it gets fixed in a release, so it can be closed as
RAWHIDE and I don't see why we would bother tracking when if ever it gets
fixed in existing releases. But if it's a real issue, I don't see why it
shouldn't get fixed in releases ASAP.

        Kevin Kofler



From mcepl at redhat.com  Thu Jan 22 12:03:59 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 13:03:59 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<440m46x0hc.ln2@ppp1053.in.ipex.cz> <4978563B.1020400@redhat.com>
Message-ID: <fu3m46xv3d.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 11:19 GMT, Andrew Haley wrote:
> I didn't know that pressing 'a' repeatedly will get you to the 
> kernel command prompt.

Well, strictly speaking you can press any key (I think even Ctrl 
will do), but advantage of 'a' is that it gets you straight to 
kernel command line ('a' command in grub).

Matej



From navneetrastogi99 at gmail.com  Thu Jan 22 12:06:26 2009
From: navneetrastogi99 at gmail.com (navneet rastogi)
Date: Thu, 22 Jan 2009 17:36:26 +0530
Subject: Problem with login in root account in Fedora10
Message-ID: <b081db690901220406w1488c587s16822e96badf3980@mail.gmail.com>

Hello,
      I am a member of GLUG Meerut and we are distributing Fedora10.I
want to tell u about a bug in fedora10. It's just a simple mistake of
a '#' but you never ignore it because a small ant can kill a big
ELEPHANT .



From kevin.kofler at chello.at  Thu Jan 22 12:08:09 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 13:08:09 +0100
Subject: [QA] To clone or not to clone ( a bug report ) that's the
	question...
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
	<gl8bnm$2tm$1@ger.gmane.org>
	<1232581880.3539.253.camel@localhost.localdomain>
Message-ID: <gl9njb$rg8$1@ger.gmane.org>

Jesse Keating wrote:
> Then that just means our rawhide bug lingers open even when it may be
> fixed, which throws off trackers and blockers and queries.  Not a
> solution.

Then push the fix out to releases sooner, maybe even directly to stable if
it's important enough to be on the tracker for the next release. Why would
it be so important as to block the next release and not worth being fixed
in the current one ASAP (unless the current one is not affected at all,
which is exactly when you'd use CLOSED RAWHIDE)?

>> >   3) bodhi auto-closing.  Not every update gets pushed at the same
>> >   time,
>> 
>> Then that's the issue to solve.
> 
> Right, and how do you propose we "solve" this (not that I agree that
> this is a problem)?

By pushing the updates out to the releases at the same time.

> At the same time doesn't work.  What if your attempted fix on F-9 fails,
> but the fix on F-10 succeeds?  Should the F-10 build sit in
> updates-testing until the say that F-9 works?  F-10 users just suffer
> for the sake of having the push go at the same time?  Ridiculous.

Well, in the cases I've seen, we just used the same fix everywhere, so I
don't see why it would work in one release and not the other. Generally, I
just wait for the first positive feedback on any release or for a week or
two without negative feedback and then push it to stable on all releases.
Waiting for feedback on all releases is a lost cause (except for some
packages like the kernel, but feedback there generally gets ignored
altogether), we already have to be happy to get any feedback at all. Having
bugfixes stalled in testing for ages doesn't help anyone.

> You can always opt out of having triagers touch KDE bugs.

Well, our KDE triager is doing good work and is also working with KDE SIG,
so I'm sure we can have him follow KDE-specific policies and the other
triagers rarely ever touch KDE bugs. But I'd rather policies weren't
radically different across components. Inconsistencies confuse everyone.
For example, not everything I maintain or comaintain is a KDE package.
Reporters, triagers and maintainers will be working with packages from
unfamiliar components occasionally, differing policies will confuse them
pretty quickly. That's why I think consistency is important (and also why
I'm complaining about the security team following a policy to clone bugs
for each release when almost nobody else is doing that).

        Kevin Kofler



From ol.morgan at telia.com  Thu Jan 22 12:13:59 2009
From: ol.morgan at telia.com (Morgan Olausson)
Date: Thu, 22 Jan 2009 13:13:59 +0100
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
Message-ID: <1232626439.2631.17.camel@localhost.localdomain>

Hi, I am a non technical user of Fedora.

I think there should (and finally will) be two different versions:

(I) For non-technical users a version that just works. Easy to install,
all settings are default. Simply a for free Microsoft Windows
replacement. This is the Linux version that will be most widely spread.
Most users have absolutely no idea of how to use a terminal window, and
with this version they will not need to know it. 

(II) For technical or want to be technical users and developers, where
there are many more alternatives to set things up.    




On Thu, 2009-01-22 at 06:17 -0500, Dr. Diesel wrote:
> 
> 
> On Thu, Jan 22, 2009 at 2:13 AM, Warren Togami <wtogami at redhat.com>
> wrote:
>         Let us step back and consider the actual goal of preventing
>         root logins.
>         
>         We want to stop people from logging in as root on their X
>         desktop
>         because it is almost always done out of laziness.  We want to
>         discourage
>         these lazy users from logging in as root and using desktop
>         applications,
>         which can be a dangerous thing.
>         
>         The only legitimate reason to allow root login is disaster
>         recovery.
>         The case where /home filesystem is full and logins fail,
>         or /home is
>         remote and inaccessible are cases where graphical non-root
>         logins can fail.
>         
>         So why don't we make root logins from GDM a stripped down
>         desktop with
>         only a terminal and a menu with only configuration tools?
>          This desktop
>         should be ugly and with a very obvious note explaining why
>         they
>         shouldn't be logged in as root.
>         
>         Benefits?
>         - Educates the users.
>         - Prevents future stupid flame wars.
>         
>         Just a thought... I don't particularly care what happens
>         here.  I never
>         log in as root on X.
>         
>         Warren Togami
>         wtogami at redhat.com
>  
> 
> Who are we to police log-ins anyhow?  If they are too lazy and
> completely hose the system that is their problem.  I frankly find it
> quite irritating that a couple of the servers stuffed away in my
> locked server room that are only accessible my me, only accessed once
> in 60-90 days, can't sit there logged in as root.
> 
> What's next?  We going to force Gnome, Firefox, SElinux, etc cause we
> feel it is safer?
> 
> We are about choice, ask the user during install if he/she wants to
> prevent root logg-ins.
> 
> 
> 
> 
> -- 
> projecthuh.com
> All of my bits are free, are yours?  Fedoraproject.org
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list



From robert at fedoraproject.org  Thu Jan 22 12:14:39 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 22 Jan 2009 13:14:39 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <497827DC.7030303@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090122073641.GA6637@hurricane.linuxnetz.de>
	<497827DC.7030303@fedoraproject.org>
Message-ID: <20090122121439.GA3201@hurricane.linuxnetz.de>

On Thu, 22 Jan 2009, Rahul Sundaram wrote:
> Never once have I felt a real need to tell people to get a root X login  
> for any reason at all.

I'm always suggesting using a terminal rather a whole X login, but we don't
life in a perfect world. We just have the reality being not perfect - so we
have to deal with such things as well.


Greetings,
  Robert



From skvidal at fedoraproject.org  Thu Jan 22 12:18:11 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 22 Jan 2009 07:18:11 -0500
Subject: smart package manager oddities
In-Reply-To: <20090122110619.40ad8525@gmx.net>
References: <20090122110619.40ad8525@gmx.net>
Message-ID: <1232626691.3802.63.camel@rosebud>

On Thu, 2009-01-22 at 11:06 +0100, Stefan Grosse wrote:
> Hi,
> 
> I was trying to clean up my system. When I was running kdirstat I
> discovered that the smart package manager consumed 30 percent of my
> disk space since it seems to create a huge file in /var/lib/channels at
> every channel update. (140 MB for fedora-development)
> 
> I reported the bug in smart/launchpad:
> https://bugs.launchpad.net/smart/+bug/319965
> 
> Can someone confirm this problem?
> 
> Unfortunately removing smart does not remove those files. So I have to
> manually remove them. Why is yum not cleaning completely?

yum is not cleaning completely? Or do you mean smart is not cleaning
completely?

-sv




From johannbg at hi.is  Thu Jan 22 12:23:47 2009
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Thu, 22 Jan 2009 12:23:47 +0000
Subject: [QA] To clone or not to clone ( a bug report )
	that's	the	question...
In-Reply-To: <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
Message-ID: <49786553.3070805@hi.is>

Mamoru Tasaka wrote:
> J?hann B. Gu?mundsson wrote, at 01/22/2009 06:46 AM +9:00:
>> When a Bug Hunter encounters the same bug in past (supported ) 
>> release, current release and rawhide.
>>
>> Should he..
>>
>> A.
>>     File the same bug 3 times as in once for each release?
>>
>> Or
>>
>> B.
>>     File the bug once and comment on that report that the same bug
>>     is present in the other release(s) as well?
>>
>> Cast your opinions and vote on how you prefer it.
>>
>> The majority of the outcome will decide on how Bug Hunters will be 
>> directed to
>> handle this.
>>
>> JBG
>
> Just FYI this topic once brought up one year ago:
> http://www.redhat.com/archives/fedora-devel-list/2008-January/msg02836.html 
>
>
> Mamoru
>
I can see were this is heading and I honestly did not think that this 
could be that complicated.

FYI this is neither about Bodhi nor Triaging nor will the outcome of 
this just stay in a thread on
a mailing list.

This is about if a TESTER aka "Bug Hunter" shall report the bug
he came across ONCE and comment on that report if he comes accross the 
same bug
in another release.

OR

If he should file another separate report describing the exact same bug 
for that release.

This subject WILL be a topic on the next QA meeting and votes counted 
and a FINAL decision be made.

The decision that is made on that meeting WILL end up in testers guide 
and be mentioned on the QA TESTERS page.

YOU as a maintainer or developer of a component have a week to choose 
either A or B and express your opinion on that chose.

There will be an option where YOU can add your component as an exception 
to that final outcome on that TESTERS page.

YOU could perhaps ask the triage team to handle reports against YOUR 
component differently then the outcome of final decision
but that's something the triage team have to decide if they will offer 
that service to a maintainer or a developer.

Please take your time and participate in the voting so we can get as 
accurate result
A result that express the will of the ( majority of the ) community.

Thank you for your time.

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/2cad8cd1/attachment.vcf>

From billcrawford1970 at gmail.com  Thu Jan 22 12:37:23 2009
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 22 Jan 2009 12:37:23 +0000
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <49781F36.80408@linux-kernel.at>
References: <20090121025533.GF19788@kvack.org> <4977ECA4.9010604@redhat.com>
	<49781F36.80408@linux-kernel.at>
Message-ID: <200901221237.23213.billcrawford1970@gmail.com>

On Thursday 22 January 2009 07:24:38 Oliver Falk wrote:

> Regarding your (Ctrl-)Alt-F2 Problem. I've never seen this. In no
> release. Well, something similar on a Desktop Box, where you try to
> switch from X to text console and the system freezes -> This was some
> nvid** driver bug. Already fixed with latest drivers of course.

Or trying to boot F10 on my desktop machine here at work, and run X.

Seriously, things do sometimes go wrong, and when they do, it helps no one to 
go "oh, well, it works on my machine so you must be wrong". It doesn't always 
involve the nVidia drivers.



From gbofspam at gmail.com  Thu Jan 22 12:41:51 2009
From: gbofspam at gmail.com (Andrew Parker)
Date: Thu, 22 Jan 2009 07:41:51 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122032311.GI29367@kvack.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org> <4977D227.4010109@redhat.com>
	<20090122031935.GG29367@kvack.org> <4977E65D.7070905@redhat.com>
	<20090122032311.GI29367@kvack.org>
Message-ID: <6c3f5e6c0901220441u7b302fd5g7c747aa6c75ff166@mail.gmail.com>

2009/1/21 Benjamin LaHaise <bcrl at kvack.org>:
> On Wed, Jan 21, 2009 at 10:22:05PM -0500, Casey Dahlin wrote:
>> Uhh..no?
>
> Doesn't work on my F10 box...

mine too, but oddly enogh Ctrl-Alt-F3 does.  Bizzare.



From kevin.kofler at chello.at  Thu Jan 22 12:55:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 13:55:56 +0100
Subject: [QA] To clone or not to clone ( a bug report )
	that's	the	question...
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is>
Message-ID: <gl9qcs$3av$1@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> This subject WILL be a topic on the next QA meeting and votes counted 
> and a FINAL decision be made.

I don't think this arrogant attitude is helping anyone, no matter what
option ends up chosen. I don't see why the decision has to be rushed nor
why a QA team vote would be the right way to decide about this issue (it
affects packagers at least as much as QA and triage folks).

        Kevin Kofler



From singularitaet at gmx.net  Thu Jan 22 12:56:23 2009
From: singularitaet at gmx.net (Stefan Grosse)
Date: Thu, 22 Jan 2009 13:56:23 +0100
Subject: smart package manager oddities
In-Reply-To: <1232626691.3802.63.camel@rosebud>
References: <20090122110619.40ad8525@gmx.net>
	<1232626691.3802.63.camel@rosebud>
Message-ID: <20090122135623.3227ed66@gmx.net>

On Thu, 22 Jan 2009 07:18:11 -0500 seth vidal
<skvidal at fedoraproject.org> wrote:
SV> > Unfortunately removing smart does not remove those files. So I
SV> > have to manually remove them. Why is yum not cleaning completely?

SV> yum is not cleaning completely? Or do you mean smart is not cleaning
SV> completely?

Sorry when I was not that clear. The bug in smart caused the contents
of /var/lib/smart/channels to grow especially with the
fedora-development-channel. This is because smart did not clean up
properly.

Now I thought that when I use yum to remove smart, it (yum) would
 clean/delete the files in /var/lib/smart/ as well. This was not the
 case. But maybe this is intentional? I am not an expert. 

In my case this leftover of smart was just a bit large (5GB) ...

Stefan

PS It seems that this smart bug is a duplicate and was fixed today
upstream.



From kevin.kofler at chello.at  Thu Jan 22 13:14:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 14:14:47 +0100
Subject: smart package manager oddities
References: <20090122110619.40ad8525@gmx.net>
	<1232626691.3802.63.camel@rosebud>
	<20090122135623.3227ed66@gmx.net>
Message-ID: <gl9rg7$817$2@ger.gmane.org>

Stefan Grosse wrote:
> Now I thought that when I use yum to remove smart, it (yum) would
>  clean/delete the files in /var/lib/smart/ as well. This was not the
>  case. But maybe this is intentional? I am not an expert.

Removing a package does not remove files created at runtime by the software
contained in the package (except if the preuninstall or postuninstall
script of the package removes them, but in general it doesn't), only files
contained in the package itself.

        Kevin Kofler



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Jan 22 13:22:24 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 22 Jan 2009 22:22:24 +0900
Subject: [QA] To clone or not to clone ( a bug report
	)	that's	the	question...
In-Reply-To: <49786553.3070805@hi.is>
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is>
Message-ID: <49787310.40904@ioa.s.u-tokyo.ac.jp>

J?hann B. Gu?mundsson wrote, at 01/22/2009 09:23 PM +9:00:
> This subject WILL be a topic on the next QA meeting and votes counted 
> and a FINAL decision be made.
.....

Please see:
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Do_not_use_ALL_CAPITALS

Anyway as I wrote one year ago,
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02841.html
I don't think filing the same bug for each branch is needed.

Mamoru



From bdwheele at indiana.edu  Thu Jan 22 13:27:50 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Thu, 22 Jan 2009 08:27:50 -0500
Subject: Root Logins in X...
In-Reply-To: <1232626439.2631.17.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
Message-ID: <1232630870.13042.8.camel@nibbler.dlib.indiana.edu>

On Thu, 2009-01-22 at 13:13 +0100, Morgan Olausson wrote:
> Hi, I am a non technical user of Fedora.
> 
> I think there should (and finally will) be two different versions:
> 
> (I) For non-technical users a version that just works. Easy to install,
> all settings are default. Simply a for free Microsoft Windows
> replacement. This is the Linux version that will be most widely spread.
> Most users have absolutely no idea of how to use a terminal window, and
> with this version they will not need to know it. 

You don't want non-technical users logging into the machine as root by
default no matter what because, as they say:  unix gives you enough rope
to shoot yourself in the foot. These situations are much better handled
with a non-privileged user logging in and then using sudo or the gui
equivalent.  So the root login thing doesn't really apply here.

I think a minimal "yukky" root desktop for maintenance is really the
right way to go:  it discourages unsafe usage, and it is obvious that
you're there to fix something.

Brian




From johannbg at hi.is  Thu Jan 22 13:28:57 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Thu, 22 Jan 2009 13:28:57 +0000
Subject: [QA] To clone or not to clone ( a bug report
	)	that's	the	question...
In-Reply-To: <gl9qcs$3av$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>
	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>
	<gl9qcs$3av$1@ger.gmane.org>
Message-ID: <49787499.7000906@hi.is>

Kevin Kofler wrote:
> "J?hann B. Gu?mundsson" wrote:
>   
>> This subject WILL be a topic on the next QA meeting and votes counted 
>> and a FINAL decision be made.
>>     
>
> I don't think this arrogant attitude is helping anyone, no matter what
> option ends up chosen. I don't see why the decision has to be rushed nor
> why a QA team vote would be the right way to decide about this issue (it
> affects packagers at least as much as QA and triage folks).
>
>         Kevin Kofler
>
>   
It's the packager/maintainer/developer and only them that make this 
decision.

If maintainer decides not to participate and then finds him disliking 
the end result
then he got nobody else to blame but him self.

This outcome of this will affect how testers are guided on how to report 
bugs
and will be in section under Reporting Bugs.

This is done to improve overall quality of bug reporting.

You got to excuse me if you and others feel that I'm being arrogant
or harsh but i'm not doing this to win popularity contents or beauty 
patents!

I'm doing this to improve overall quality of the bug reporting.

I'm not about to let this thread take 180 degree turn and the focus on 
the actual topic
be lost as so happens to many others topics on this list.

If you and other maintainers feel that week is to little to vote and 
discuss this matter please express
that along with how much time you think it takes to come to a final 
conclusion.

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/e67e71e0/attachment.vcf>

From dr.diesel at gmail.com  Thu Jan 22 13:35:01 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 22 Jan 2009 08:35:01 -0500
Subject: Root Logins in X...
In-Reply-To: <1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
Message-ID: <2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>

On Thu, Jan 22, 2009 at 8:27 AM, Brian Wheeler <bdwheele at indiana.edu> wrote:

> On Thu, 2009-01-22 at 13:13 +0100, Morgan Olausson wrote:
> > Hi, I am a non technical user of Fedora.
> >
> > I think there should (and finally will) be two different versions:
> >
> > (I) For non-technical users a version that just works. Easy to install,
> > all settings are default. Simply a for free Microsoft Windows
> > replacement. This is the Linux version that will be most widely spread.
> > Most users have absolutely no idea of how to use a terminal window, and
> > with this version they will not need to know it.
>
> You don't want non-technical users logging into the machine as root by
> default no matter what because, as they say:  unix gives you enough rope
> to shoot yourself in the foot. These situations are much better handled
> with a non-privileged user logging in and then using sudo or the gui
> equivalent.  So the root login thing doesn't really apply here.
>
> I think a minimal "yukky" root desktop for maintenance is really the
> right way to go:  it discourages unsafe usage, and it is obvious that
> you're there to fix something.
>
> Brian
>

Great, we are on the way to hundreds of "Are You Sure" pop up windows....

There is nothing wrong with root X IMO.

-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/31fae61a/attachment.htm>

From kevin.kofler at chello.at  Thu Jan 22 13:43:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 14:43:44 +0100
Subject: [QA] To clone or not to clone ( a bug report
	)	that's	the	question...
References: <497797C8.1050209@hi.is>
	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>
	<gl9qcs$3av$1@ger.gmane.org> <49787499.7000906@hi.is>
Message-ID: <gl9t6g$dis$1@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> It's the packager/maintainer/developer and only them that make this
> decision.

Then the decision should be made through a channel of
packagers/maintainers/developers (or maybe their representatives, i.e.
FESCo), not in a QA meeting!

> If maintainer decides not to participate and then finds him disliking
> the end result then he got nobody else to blame but him self.

If you want maintainers to take the decision, a QA meeting is the wrong
venue.

        Kevin Kofler



From mschmidt at redhat.com  Thu Jan 22 13:50:51 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 22 Jan 2009 14:50:51 +0100
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
Message-ID: <20090122145051.70da89b8@brian.englab.brq.redhat.com>

On Thu, 22 Jan 2009 08:35:01 -0500
"Dr. Diesel" <dr.diesel at gmail.com> wrote:

> On Thu, Jan 22, 2009 at 8:27 AM, Brian Wheeler <bdwheele at indiana.edu>
> wrote:
> 
> > On Thu, 2009-01-22 at 13:13 +0100, Morgan Olausson wrote:
> > > Hi, I am a non technical user of Fedora.
> > >
> > > I think there should (and finally will) be two different versions:
> > >
> > > (I) For non-technical users a version that just works. Easy to
> > > install, all settings are default. Simply a for free Microsoft
> > > Windows replacement. This is the Linux version that will be most
> > > widely spread. Most users have absolutely no idea of how to use a
> > > terminal window, and with this version they will not need to know
> > > it.
> >
> > You don't want non-technical users logging into the machine as root
> > by default no matter what because, as they say:  unix gives you
> > enough rope to shoot yourself in the foot. These situations are
> > much better handled with a non-privileged user logging in and then
> > using sudo or the gui equivalent.  So the root login thing doesn't
> > really apply here.
> >
> > I think a minimal "yukky" root desktop for maintenance is really the
> > right way to go:  it discourages unsafe usage, and it is obvious
> > that you're there to fix something.
> >
> > Brian
> >
> 
> Great, we are on the way to hundreds of "Are You Sure" pop up
> windows....
> 
> There is nothing wrong with root X IMO.

Does "root X" mean a session with xterm, xclock and xload (i.e. the
three programs X Window System was designed to run [1] ;-)) ?

Michal

[1] The UNIX-HATERS Handbook, chapter 7,
http://web.mit.edu/~simsong/www/ugh.pdf



From bdwheele at indiana.edu  Thu Jan 22 13:51:24 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Thu, 22 Jan 2009 08:51:24 -0500
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
Message-ID: <1232632284.13042.23.camel@nibbler.dlib.indiana.edu>

On Thu, 2009-01-22 at 08:35 -0500, Dr. Diesel wrote:
> 
> 
> On Thu, Jan 22, 2009 at 8:27 AM, Brian Wheeler <bdwheele at indiana.edu>
> wrote:
>         On Thu, 2009-01-22 at 13:13 +0100, Morgan Olausson wrote:
>         > Hi, I am a non technical user of Fedora.
>         >
>         > I think there should (and finally will) be two different
>         versions:
>         >
>         > (I) For non-technical users a version that just works. Easy
>         to install,
>         > all settings are default. Simply a for free Microsoft
>         Windows
>         > replacement. This is the Linux version that will be most
>         widely spread.
>         > Most users have absolutely no idea of how to use a terminal
>         window, and
>         > with this version they will not need to know it.
>         
>         
>         You don't want non-technical users logging into the machine as
>         root by
>         default no matter what because, as they say:  unix gives you
>         enough rope
>         to shoot yourself in the foot. These situations are much
>         better handled
>         with a non-privileged user logging in and then using sudo or
>         the gui
>         equivalent.  So the root login thing doesn't really apply
>         here.
>         
>         I think a minimal "yukky" root desktop for maintenance is
>         really the
>         right way to go:  it discourages unsafe usage, and it is
>         obvious that
>         you're there to fix something.
>         
>         Brian
> 
> Great, we are on the way to hundreds of "Are You Sure" pop up
> windows....
> 

Yuk, no.  More like a desktop where things not related to sysadmin
aren't immediately obvious.  Things like openoffice, media players,
games, etc could be hidden.  If you know what you're doing and you need
them, no problem:  you know what you're doing :)  But if you're the
"lazy" sort that has come up in these discussions, then you're going to
want to use a normal login to do your day-to-day tasks like you should.


> There is nothing wrong with root X IMO.
> 

Not in and of itself, no.  Of course, there's nothing wrong (in theory)
with logging into windows as administrator every time...

The problem comes in where people use root by default and there's a
security exploit which gives it control of the machine.  Or when a
newbie decides to clean stuff up with the file manager and gets carried
away.  Or accidentially "dials" the hard disk...

Making root logins unpalatable goes a long way to stop users from
complaining that Linux sucks...

Brian 





From dr.diesel at gmail.com  Thu Jan 22 14:01:20 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 22 Jan 2009 09:01:20 -0500
Subject: Root Logins in X...
In-Reply-To: <1232632284.13042.23.camel@nibbler.dlib.indiana.edu>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
	<1232632284.13042.23.camel@nibbler.dlib.indiana.edu>
Message-ID: <2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>

On Thu, Jan 22, 2009 at 8:51 AM, Brian Wheeler <bdwheele at indiana.edu> wrote:

> On Thu, 2009-01-22 at 08:35 -0500, Dr. Diesel wrote:
> >
>
>
> Yuk, no.  More like a desktop where things not related to sysadmin
> aren't immediately obvious.  Things like openoffice, media players,
> games, etc could be hidden.  If you know what you're doing and you need
> them, no problem:  you know what you're doing :)  But if you're the
> "lazy" sort that has come up in these discussions, then you're going to
> want to use a normal login to do your day-to-day tasks like you should.
>
>
> > There is nothing wrong with root X IMO.
> >
>
> Not in and of itself, no.  Of course, there's nothing wrong (in theory)
> with logging into windows as administrator every time...
>
> The problem comes in where people use root by default and there's a
> security exploit which gives it control of the machine.  Or when a
> newbie decides to clean stuff up with the file manager and gets carried
> away.  Or accidentially "dials" the hard disk...
>
> Making root logins unpalatable goes a long way to stop users from
> complaining that Linux sucks...
>
> Brian
>

Not sure how or why we would try to prevent utter stupidity!  I am firmly
against forcing uses in any direction.

Please just make it easy to switch back.



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/7b910ab2/attachment.htm>

From billcrawford1970 at gmail.com  Thu Jan 22 14:34:35 2009
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 22 Jan 2009 14:34:35 +0000
Subject: smart package manager oddities
In-Reply-To: <20090122135623.3227ed66@gmx.net>
References: <20090122110619.40ad8525@gmx.net>
	<1232626691.3802.63.camel@rosebud>
	<20090122135623.3227ed66@gmx.net>
Message-ID: <200901221434.35942.billcrawford1970@gmail.com>

On Thursday 22 January 2009 12:56:23 Stefan Grosse wrote:

> Sorry when I was not that clear. The bug in smart caused the contents
> of /var/lib/smart/channels to grow especially with the
> fedora-development-channel. This is because smart did not clean up
> properly.
...
> In my case this leftover of smart was just a bit large (5GB) ...

Sounds like a side-effect of the change to use different filenames with the 
content hash in for the metadata. Smart will need modifying to throw those away 
once they are no longer needed ...



From arequipeno at gmail.com  Thu Jan 22 14:47:00 2009
From: arequipeno at gmail.com (Ian Pilcher)
Date: Thu, 22 Jan 2009 08:47:00 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977D0C2.9090900@redhat.com>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com>
Message-ID: <gla0t4$poj$1@ger.gmane.org>

Casey Dahlin wrote:
> Is it wrong that I actually /miss/ the linux community's sense of
> elitism? It kept us so much more sensible on so many things.

It's my sense of elitism that makes me irritated when y'all try to
protect me from myself.  ;-)

-- 
========================================================================
Ian Pilcher                                         arequipeno at gmail.com
========================================================================



From arequipeno at gmail.com  Thu Jan 22 14:55:27 2009
From: arequipeno at gmail.com (Ian Pilcher)
Date: Thu, 22 Jan 2009 08:55:27 -0600
Subject: Root Logins in X...
In-Reply-To: <49781C9C.4000007@redhat.com>
References: <49781C9C.4000007@redhat.com>
Message-ID: <gla1d0$tg0$1@ger.gmane.org>

Warren Togami wrote:
> We want to stop people from logging in as root on their X desktop
> because it is almost always done out of laziness.  We want to discourage
> these lazy users from logging in as root and using desktop applications,
> which can be a dangerous thing.

Let's step back farther and ask ourselves whether discouraging users
from doing stupid things (other than running non-free software) is one
of Fedora's goals.  I certainly don't see anything to that effect at
http://fedoraproject.org/wiki/Overview.

-- 
========================================================================
Ian Pilcher                                         arequipeno at gmail.com
========================================================================



From johannbg at hi.is  Thu Jan 22 14:58:05 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Thu, 22 Jan 2009 14:58:05 +0000
Subject: [QA] To clone or not to clone ( a bug
	report	)	that's	the	question...
In-Reply-To: <gl9t6g$dis$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>
	<49787499.7000906@hi.is> <gl9t6g$dis$1@ger.gmane.org>
Message-ID: <4978897D.4020201@hi.is>

Kevin Kofler wrote:
> "J?hann B. Gu?mundsson" wrote:
>   
>> It's the packager/maintainer/developer and only them that make this
>> decision.
>>     
>
> Then the decision should be made through a channel of
> packagers/maintainers/developers (or maybe their representatives, i.e.
> FESCo), not in a QA meeting!
>
>   
>> If maintainer decides not to participate and then finds him disliking
>> the end result then he got nobody else to blame but him self.
>>     
>
> If you want maintainers to take the decision, a QA meeting is the wrong
> venue.
>
>         Kevin Kofler
>
>   
If you and others think this decision should be in the hand of FESCo 
instead of QA
then I would like FESCo to add this topic to their next meeting agenda 
and I truly
hope they can reach a satisfying result.

The QA meeting topic as I see it was just about counting the votes on 
the thread
and make that an official decision.

I also see that asking the maintainers for what they wanted was an error 
on my behalf.

Testers need training guidelines and policies to work by, a proper "work 
flow" and if the
responses to every matter are going to be like this one I simply cut out 
the inefficient process.

I will write those guidelines policy and provide testers with a decent 
work flow.

Anyone that opposes anything in that guideline can than pick out 
questionable issues , make them to a topic on this
list or ask FESCo to address those issue(s) in their meetings.

There will be no time "pressure" matter since the guideline has already 
been written and made
so debates can be stuck in infinite loop until the storage space on the 
mail server fills up..

When and if an actually satisfying result comes out of it, a person can 
simply log into the wiki and adjust the
the guidelines to that result..

With this approach testers will at least have something in their hand to 
work with
which will indeed improve the overall process of bug reporting.

Thank you for your time.

JBG

/*JFDI to da bone.. */

-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/2d8628d4/attachment.vcf>

From bdwheele at indiana.edu  Thu Jan 22 15:10:45 2009
From: bdwheele at indiana.edu (Brian Wheeler)
Date: Thu, 22 Jan 2009 10:10:45 -0500
Subject: Root Logins in X...
In-Reply-To: <gla1d0$tg0$1@ger.gmane.org>
References: <49781C9C.4000007@redhat.com>  <gla1d0$tg0$1@ger.gmane.org>
Message-ID: <1232637045.13042.30.camel@nibbler.dlib.indiana.edu>

On Thu, 2009-01-22 at 08:55 -0600, Ian Pilcher wrote:
> Warren Togami wrote:
> > We want to stop people from logging in as root on their X desktop
> > because it is almost always done out of laziness.  We want to discourage
> > these lazy users from logging in as root and using desktop applications,
> > which can be a dangerous thing.
> 
> Let's step back farther and ask ourselves whether discouraging users
> from doing stupid things (other than running non-free software) is one
> of Fedora's goals.  I certainly don't see anything to that effect at
> http://fedoraproject.org/wiki/Overview.


I don't see anything about encouraging them to do stupid things either,
so maybe we should just set all file permissions to 0777 so people don't
have to worry about those pesky permissions issues.  I'm just kidding,
but I'm not sure how promoting good behavior is a bad thing...if you
really know what you're doing, you can customize the root environment
however you want (no matter what the OS is shipped with) and if you
don't, then perhaps you shouldn't login as root all the time...

Brian






From tcallawa at redhat.com  Thu Jan 22 15:13:07 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 22 Jan 2009 10:13:07 -0500
Subject: MIT License page typo
In-Reply-To: <870180fe0901211241i2535f9car55d238a1e4727517@mail.gmail.com>
References: <870180fe0901211241i2535f9car55d238a1e4727517@mail.gmail.com>
Message-ID: <1232637187.3807.16.camel@localhost.localdomain>

On Wed, 2009-01-21 at 13:41 -0700, Jerry James wrote:
> Another page I can't edit:
> 
> https://fedoraproject.org/wiki/Licensing/MIT
> 
> "Old Style with legal disclaimer 3" has the same "<code></code>AS
> IS''" that I reported awhile ago for some of the other licenses.
> 
> Is this the right place to report wiki typos?

Jerry,

Throughout the entire wiki, there should only be three places where you
cannot edit:

Packaging/
Licensing/
Legal/

I maintain all of these sections, so you can send any suggested changes
on pages that you cannot edit to me.

Thanks,

~spot, Fedora Legal



From tcallawa at redhat.com  Thu Jan 22 15:19:19 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 22 Jan 2009 10:19:19 -0500
Subject: Root Logins in X...
In-Reply-To: <1232637045.13042.30.camel@nibbler.dlib.indiana.edu>
References: <49781C9C.4000007@redhat.com>  <gla1d0$tg0$1@ger.gmane.org>
	<1232637045.13042.30.camel@nibbler.dlib.indiana.edu>
Message-ID: <1232637559.3807.20.camel@localhost.localdomain>

On Thu, 2009-01-22 at 10:10 -0500, Brian Wheeler wrote:
> I'm just kidding, but I'm not sure how promoting good behavior is a
> bad thing.

A few more ideas, off the top of my head:

A "Rescue Mode" in GDM which goes to a root session with minimal apps,
marked as "Rescue Mode", rather than a root X login (even though it does
need root credentials).

A prompt upon the first time a user tried to login to a normal X session
via GDM as root (separate from the "Rescue Mode"), warning them of the
risk they're taking, with a small checkbox that says something like
"never show me this warning again".

I'm more inclined to put a safety on the gun than to unload it entirely.

~spot



From dr.diesel at gmail.com  Thu Jan 22 15:23:08 2009
From: dr.diesel at gmail.com (Dr. Diesel)
Date: Thu, 22 Jan 2009 10:23:08 -0500
Subject: Root Logins in X...
In-Reply-To: <1232637559.3807.20.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com> <gla1d0$tg0$1@ger.gmane.org>
	<1232637045.13042.30.camel@nibbler.dlib.indiana.edu>
	<1232637559.3807.20.camel@localhost.localdomain>
Message-ID: <2a28d2ab0901220723m30a2d41cl152d788248d052da@mail.gmail.com>

On Thu, Jan 22, 2009 at 10:19 AM, Tom spot Callaway <tcallawa at redhat.com>wrote:

> On Thu, 2009-01-22 at 10:10 -0500, Brian Wheeler wrote:
>
>
> A prompt upon the first time a user tried to login to a normal X session
> via GDM as root (separate from the "Rescue Mode"), warning them of the
> risk they're taking, with a small checkbox that says something like
> "never show me this warning again".
>
> I'm more inclined to put a safety on the gun than to unload it entirely.
>
> ~spot


Yes, I second this, perfect solution.



-- 
projecthuh.com
All of my bits are free, are yours?  Fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/67429347/attachment.htm>

From markmc at redhat.com  Thu Jan 22 15:27:19 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 22 Jan 2009 15:27:19 +0000
Subject: [QA] To clone or not to clone ( a bug report ) that's	the
 question...
In-Reply-To: <49786553.3070805@hi.is>
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is>
Message-ID: <1232638039.4533.44.camel@blaa>

Hi J?hann,

On Thu, 2009-01-22 at 12:23 +0000, "J?hann B. Gu?mundsson" wrote:
> Mamoru Tasaka wrote:
> > J?hann B. Gu?mundsson wrote, at 01/22/2009 06:46 AM +9:00:
> >> When a Bug Hunter encounters the same bug in past (supported ) 
> >> release, current release and rawhide.
> >>
> >> Should he..
> >>
> >> A.
> >>     File the same bug 3 times as in once for each release?
> >>
> >> Or
> >>
> >> B.
> >>     File the bug once and comment on that report that the same bug
> >>     is present in the other release(s) as well?

I think a sensible policy is:

  1) File the bug against the version you have tested with

  2) If this version is not rawhide, there is generally no need to also
     file a bug against rawhide. Maintainers should always check 
     whether the bug is fixed in rawhide. Commenting whether you 
     believe the bug exists in rawhide is always useful.

  3) If you think this is a critical bug and have checked that it 
     exists other released versions, then you should clone the bug for 
     those other versions.

  4) Otherwise, just comment on the impact to other versions and let 
     the maintainer decide whether cloning the bug is appropriate.

No, it's not a black/white policy. It requires a little bit of common
sense. But that's okay, right?

> This subject WILL be a topic on the next QA meeting and votes counted 
> and a FINAL decision be made.
> 
> The decision that is made on that meeting WILL end up in testers guide 
> and be mentioned on the QA TESTERS page.
> 
> YOU as a maintainer or developer of a component have a week to choose 
> either A or B and express your opinion on that chose.

Voting sucks, rough consensus is preferable.

> There will be an option where YOU can add your component as an exception 
> to that final outcome on that TESTERS page.

(B) is pretty much the status quo; if this voting thing means that (A)
is chosen and the triage team starts cloning a bunch of bugs, you can be
sure you'll have maintainers who haven't read or replied to this thread
waking up and getting annoyed that they've 3x bug reports to deal
with :-)

Cheers,
Mark.



From casimiro.barreto at gmail.com  Thu Jan 22 15:29:04 2009
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Thu, 22 Jan 2009 13:29:04 -0200
Subject: X Problem in Fedora 10
Message-ID: <497890C0.2050505@gmail.com>

Hello,

Yesterday I recovered a box from a crash (HD toasted). As I had to
reinstall OS, previous configurations were lost. This box has an old
video monitor (capable of 1024x768 or even 1240x1024 if you "pull
strings") but after reinstall I'm limited to 800x600. Since
/etc/X11/xorg.conf doesn't work anymore I'll be gratefull if someone
points out where I can reconfigure X in order to set proper parameters
(like VideoChip and video mode)???

Best regards,

Casimiro

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/70a8a2f7/attachment.sig>

From berrange at redhat.com  Thu Jan 22 15:32:30 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 22 Jan 2009 15:32:30 +0000
Subject: [QA] To clone or not to clone ( a bug report ) that's	the
	question...
In-Reply-To: <1232638039.4533.44.camel@blaa>
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is> <1232638039.4533.44.camel@blaa>
Message-ID: <20090122153230.GG31201@redhat.com>

On Thu, Jan 22, 2009 at 03:27:19PM +0000, Mark McLoughlin wrote:
> Hi J?hann,
> 
> On Thu, 2009-01-22 at 12:23 +0000, "J?hann B. Gu?mundsson" wrote:
> > Mamoru Tasaka wrote:
> > > J?hann B. Gu?mundsson wrote, at 01/22/2009 06:46 AM +9:00:
> > >> When a Bug Hunter encounters the same bug in past (supported ) 
> > >> release, current release and rawhide.
> > >>
> > >> Should he..
> > >>
> > >> A.
> > >>     File the same bug 3 times as in once for each release?
> > >>
> > >> Or
> > >>
> > >> B.
> > >>     File the bug once and comment on that report that the same bug
> > >>     is present in the other release(s) as well?
> 
> I think a sensible policy is:
> 
>   1) File the bug against the version you have tested with
> 
>   2) If this version is not rawhide, there is generally no need to also
>      file a bug against rawhide. Maintainers should always check 
>      whether the bug is fixed in rawhide. Commenting whether you 
>      believe the bug exists in rawhide is always useful.
> 
>   3) If you think this is a critical bug and have checked that it 
>      exists other released versions, then you should clone the bug for 
>      those other versions.
> 
>   4) Otherwise, just comment on the impact to other versions and let 
>      the maintainer decide whether cloning the bug is appropriate.
> 
> No, it's not a black/white policy. It requires a little bit of common
> sense. But that's okay, right?

I agree - common sense is the most important thing - there are plenty
of scenarios where cloning makes sense - and also plenty of scenarios
where it is just creating alot of extra work for no gain. So mandating
either of those two options is sub-optimal. Flexible guidelines are 
preferable to hard rules.

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 wtogami at redhat.com  Thu Jan 22 15:32:35 2009
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 22 Jan 2009 10:32:35 -0500
Subject: X Problem in Fedora 10
In-Reply-To: <497890C0.2050505@gmail.com>
References: <497890C0.2050505@gmail.com>
Message-ID: <49789193.3020407@redhat.com>

Casimiro de Almeida Barreto wrote:
> Hello,
> 
> Yesterday I recovered a box from a crash (HD toasted). As I had to
> reinstall OS, previous configurations were lost. This box has an old
> video monitor (capable of 1024x768 or even 1240x1024 if you "pull
> strings") but after reinstall I'm limited to 800x600. Since
> /etc/X11/xorg.conf doesn't work anymore I'll be gratefull if someone
> points out where I can reconfigure X in order to set proper parameters
> (like VideoChip and video mode)???
> 

Who said /etc/X11/xorg.conf doesn't work anymore?  If it exists, it uses it.

Warren Togami
wtogami at redhat.com



From pingou at pingoured.fr  Thu Jan 22 15:39:30 2009
From: pingou at pingoured.fr (Pierre-Yves)
Date: Thu, 22 Jan 2009 16:39:30 +0100
Subject: Root Logins in X...
In-Reply-To: <1232637559.3807.20.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>
	<gla1d0$tg0$1@ger.gmane.org>	<1232637045.13042.30.camel@nibbler.dlib.indiana.edu>
	<1232637559.3807.20.camel@localhost.localdomain>
Message-ID: <49789332.3050500@pingoured.fr>

Tom "spot" Callaway wrote:
> On Thu, 2009-01-22 at 10:10 -0500, Brian Wheeler wrote:
>> I'm just kidding, but I'm not sure how promoting good behavior is a
>> bad thing.
> 
> A few more ideas, off the top of my head:
> 
> A "Rescue Mode" in GDM which goes to a root session with minimal apps,
> marked as "Rescue Mode", rather than a root X login (even though it does
> need root credentials).
> 
> A prompt upon the first time a user tried to login to a normal X session
> via GDM as root (separate from the "Rescue Mode"), warning them of the
> risk they're taking, with a small checkbox that says something like
> "never show me this warning again".

To me it sounds like the original proposal of this thread from Warren.

It would be fine by me :)

Regards,

Pierre



From jkeating at j2solutions.net  Thu Jan 22 15:40:51 2009
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 22 Jan 2009 07:40:51 -0800
Subject: [QA] To clone or not to clone ( a bug report ) that's the
 question...
In-Reply-To: <gl9njb$rg8$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>
	<1232580472.3539.250.camel@localhost.localdomain>
	<gl8bnm$2tm$1@ger.gmane.org>
	<1232581880.3539.253.camel@localhost.localdomain>
	<gl9njb$rg8$1@ger.gmane.org>
Message-ID: <1232638851.3539.267.camel@localhost.localdomain>

On Thu, 2009-01-22 at 13:08 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > Then that just means our rawhide bug lingers open even when it may be
> > fixed, which throws off trackers and blockers and queries.  Not a
> > solution.
> 
> Then push the fix out to releases sooner, maybe even directly to stable if
> it's important enough to be on the tracker for the next release. Why would
> it be so important as to block the next release and not worth being fixed
> in the current one ASAP (unless the current one is not affected at all,
> which is exactly when you'd use CLOSED RAWHIDE)?

Again because the fix for rawhide vs a release tree may be different, as
the versions are different.  Also the fix needs to be in -testing on the
release tree to make sure that the fix integrates well with the other
software, whereas it needs to go out in rawhide immediately.  I really
think you're stuck in the mindset of same software on every branch,
which just isn't and shouldn't be the case for everybody.

> 
> >> >   3) bodhi auto-closing.  Not every update gets pushed at the same
> >> >   time,
> >> 
> >> Then that's the issue to solve.
> > 
> > Right, and how do you propose we "solve" this (not that I agree that
> > this is a problem)?
> 
> By pushing the updates out to the releases at the same time.

Gee it's so simple.  The hat goes on the head! </sarcasm>

> 
> > At the same time doesn't work.  What if your attempted fix on F-9 fails,
> > but the fix on F-10 succeeds?  Should the F-10 build sit in
> > updates-testing until the say that F-9 works?  F-10 users just suffer
> > for the sake of having the push go at the same time?  Ridiculous.
> 
> Well, in the cases I've seen, we just used the same fix everywhere, so I
> don't see why it would work in one release and not the other.

Because for a lot of people, software is /different/ on one release vs
the other.  Particularly software that is used by lots of other things.

>  Generally, I
> just wait for the first positive feedback on any release or for a week or
> two without negative feedback and then push it to stable on all releases.
> Waiting for feedback on all releases is a lost cause (except for some
> packages like the kernel, but feedback there generally gets ignored
> altogether), we already have to be happy to get any feedback at all. Having
> bugfixes stalled in testing for ages doesn't help anyone.
> 
> > You can always opt out of having triagers touch KDE bugs.
> 
> Well, our KDE triager is doing good work and is also working with KDE SIG,
> so I'm sure we can have him follow KDE-specific policies and the other
> triagers rarely ever touch KDE bugs. But I'd rather policies weren't
> radically different across components. Inconsistencies confuse everyone.
> For example, not everything I maintain or comaintain is a KDE package.
> Reporters, triagers and maintainers will be working with packages from
> unfamiliar components occasionally, differing policies will confuse them
> pretty quickly. That's why I think consistency is important (and also why
> I'm complaining about the security team following a policy to clone bugs
> for each release when almost nobody else is doing that).
> 
>         Kevin Kofler
> 
-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/f9f76cbc/attachment.sig>

From dcbw at redhat.com  Thu Jan 22 16:00:14 2009
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 22 Jan 2009 11:00:14 -0500
Subject: Python and /etc/resolv.conf changes
In-Reply-To: <faa16b610901210626w34b7158bka26246ca5d2b3979@mail.gmail.com>
References: <1232495310.3539.172.camel@localhost.localdomain>
	<faa16b610901201719s637c631ah178119f833b59d5@mail.gmail.com>
	<faa16b610901210626w34b7158bka26246ca5d2b3979@mail.gmail.com>
Message-ID: <1232640014.2623.3.camel@localhost.localdomain>

On Wed, 2009-01-21 at 09:26 -0500, Colin Walters wrote:
> On Tue, Jan 20, 2009 at 8:19 PM, Colin Walters <walters at verbum.org> wrote:
> >
> > Both Debian/Ubuntu
> > (http://patches.ubuntu.com/g/glibc/extracted/any/local-dynamic-resolvconf.diff)
> > and OpenSUSE (http://download.opensuse.org/distribution/11.0/repo/src-oss/suse/src/glibc-2.8-14.1.src.rpm,
> > resolv.dynamic.diff) ship a patch to glibc which stats() resolv.conf.
> > We do not.
> 
> Thinking about this a bit more this morning on the shuttle, there's a
> strong argument that this is a glibc bug, and that the stat() approach
> is a correct fix, if not necessarily the most ideal one.  That
> argument is simply that glibc is caching data without a mechanism for
> invalidation; and a cache without invalidation is always a bug.

This was discussed with the glibc maintainers a long time ago, and was
rejected for various reasons (see below).  Their answer at the time was
to use "lwresd", a lightweight caching nameserver, or nscd to provide
this functionality.  This was back in 2004, so perhaps things have
changed, and maybe it's time to strike up the conversation again.
However, I suspect the answer is still "use nscd".

Dan

--------------------------------------
On Fri, 2004-06-04 at 07:48 -0700, Ulrich Drepper wrote:
> Dan Williams wrote:
> 
> > 1) make glibc stat() /etc/resolv.conf on every call that does name
> > lookups
> > 2) make glibc re-read /etc/resolv.conf every time something does a name
> > lookup
> > 3) use nscd instead, and modify ncsd to do either (1) or (2)?
> 
> None of this is an option.  There is no way we are going to make
> everybody pay the price for the needs of a few people who wants
> everything to happen automatically.
> 
> The solution is to use nscd and have some external code explicitly flush
> the cache with
> 
>   service nscd reload
> 
> This is already possible for, I guess, 5-6 years.





From mcepl at redhat.com  Thu Jan 22 15:48:13 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Thu, 22 Jan 2009 16:48:13 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <20090121025533.GF19788@kvack.org> <4977ECA4.9010604@redhat.com>
	<49781F36.80408@linux-kernel.at>
	<200901221237.23213.billcrawford1970@gmail.com>
Message-ID: <t2hm46x5ag.ln2@ppp1053.in.ipex.cz>

On 2009-01-22, 12:37 GMT, Bill Crawford wrote:
> Seriously, things do sometimes go wrong, and when they do, it 
> helps no one to go "oh, well, it works on my machine so you 
> must be wrong". It doesn't always involve the nVidia drivers.

I have never said we don't have bugs breaking access to VT[2-*], 
but it seemed to me that this thread was originally about POLICY 
-- "OMG, Fedora disallowed root access!!!" or crap like this.

Mat?j



From johannbg at hi.is  Thu Jan 22 16:02:10 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Thu, 22 Jan 2009 16:02:10 +0000
Subject: [QA] To clone or not to clone ( a bug report ) that's	the
	question...
In-Reply-To: <1232638039.4533.44.camel@blaa>
References: <497797C8.1050209@hi.is>
	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>
	<1232638039.4533.44.camel@blaa>
Message-ID: <49789882.6050302@hi.is>

Mark McLoughlin wrote:

<snip>
.....
<snip>
>
> I think a sensible policy is:
>
>   1) File the bug against the version you have tested with
>
>   2) If this version is not rawhide, there is generally no need to also
>      file a bug against rawhide. Maintainers should always check 
>      whether the bug is fixed in rawhide. Commenting whether you 
>      believe the bug exists in rawhide is always useful.
>
>   3) If you think this is a critical bug and have checked that it 
>      exists other released versions, then you should clone the bug for 
>      those other versions.
>
>   4) Otherwise, just comment on the impact to other versions and let 
>      the maintainer decide whether cloning the bug is appropriate.
>   

I do believe you nailed this one Mark :)

+1
> No, it's not a black/white policy. It requires a little bit of common
> sense. But that's okay, right?
>
>   

Of course not and alternative, different approaches,
better suggestions/solution are always welcome.

JBG

-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/a4bbfec0/attachment.vcf>

From jskala at redhat.com  Thu Jan 22 16:06:07 2009
From: jskala at redhat.com (Jiri Skala)
Date: Thu, 22 Jan 2009 17:06:07 +0100
Subject: X Problem in Fedora 10
In-Reply-To: <49789193.3020407@redhat.com>
References: <497890C0.2050505@gmail.com>  <49789193.3020407@redhat.com>
Message-ID: <1232640367.4537.22.camel@dhcp-lab-234.englab.brq.redhat.com>

On Thu, 2009-01-22 at 10:32 -0500, Warren Togami wrote:
> Casimiro de Almeida Barreto wrote:
> > Hello,
> > 
> > Yesterday I recovered a box from a crash (HD toasted). As I had to
> > reinstall OS, previous configurations were lost. This box has an old
> > video monitor (capable of 1024x768 or even 1240x1024 if you "pull
> > strings") but after reinstall I'm limited to 800x600. Since
> > /etc/X11/xorg.conf doesn't work anymore I'll be gratefull if someone
> > points out where I can reconfigure X in order to set proper parameters
> > (like VideoChip and video mode)???
> > 
> 
> Who said /etc/X11/xorg.conf doesn't work anymore?  If it exists, it uses it.
> 

I don't think that the sentence: "If it exists, it uses it." solves
described problem.

The xorg.conf doesn't work fine after installation/upgrade. I use my
notebook (1440x900) in the dock with external LCD (1280x1024) and the
resolutions are incorrect after starting up. The resolution doesn't
match to resolution in the xorg.conf.

I use xrandr then everything is fine (for dual monitors).

But settings of xorg.conf during installation should be used and this
isn't.

Jiri

> Warren Togami
> wtogami at redhat.com
> 



From kevin at finway.co.uk  Thu Jan 22 16:22:30 2009
From: kevin at finway.co.uk (Kevin Coffin)
Date: Thu, 22 Jan 2009 16:22:30 +0000
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <gl88uh$p63$2@ger.gmane.org>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232573347.3610.13.camel@warbird.finway.co.uk>
	<gl88uh$p63$2@ger.gmane.org>
Message-ID: <1232641350.3760.5.camel@warbird.finway.co.uk>

On Wed, 2009-01-21 at 23:52 +0100, Kevin Kofler wrote:
> Kevin Coffin wrote:
> > What authorisations gui ? I am running a kde desktop.
> 
> polkit-gnome-authorization in the PolicyKit-gnome package. Also works on
> KDE.
> 
> As an alternative, PolicyKit-kde, which provides a KDE version
> (polkit-kde-authorization), is being pushed out as an update, you'll be
> able to install it soon.
> 
>         Kevin Kofler
> 

Thanks for the info. I will test it out when it arrives, for now I have
run polkit-gnome authorization.

Kevin




From mw_triad at users.sourceforge.net  Thu Jan 22 16:38:25 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 22 Jan 2009 10:38:25 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <4977DA16.2040901@ij.net>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>	<20090121155344.GI19788@kvack.org>	<4977D227.4010109@redhat.com>	<4977D595.6070305@ij.net>	<4977D61D.7020501@redhat.com>
	<4977DA16.2040901@ij.net>
Message-ID: <gla7e1$kk9$1@ger.gmane.org>

Felix Miata wrote:
> Graphical boot is obfuscatory nonsense. I just put W2K on an old puter a few
> days ago. Linux boots right up, but W2K takes 5 minutes to reach the login
> window. The graphical blanket makes it impossible to see what is taking so
> bloody long. I know there's a startup option to avoid the graphical doz
> curtain, but that should be the default, not a hidden option. Same for Linux:
> Graphical should be a selected option for those who want it, not the default.

I strongly disagree. Putting all that "junk" (note the quotes, please) 
on screen is confusing to people that think a computer should behave 
like their microwave and turns people off from using Linux. Joe Average 
User doesn't want to see what's going on under the hood, but he does 
appreciate pretty graphics. It's a question of target audience.

Besides, unlike 'doze, Fedora gets it right in that hitting ESC makes 
the graphics go away and shows you "what's going on under the hood". You 
don't need to remember to fiddle with boot options to get it.

IOW, the people that care about watching the verbose boot sequence know 
how to configure that. The people that don't know are the same people 
that don't want to see what's going on in the first place.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Who let the hippos out?



From mw_triad at users.sourceforge.net  Thu Jan 22 16:44:00 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 22 Jan 2009 10:44:00 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <fu3m46xv3d.ln2@ppp1053.in.ipex.cz>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>
	<20090121030132.GG19788@kvack.org>	<4976F69D.2050805@fedoraproject.org>
	<20090121155344.GI19788@kvack.org>	<440m46x0hc.ln2@ppp1053.in.ipex.cz>
	<4978563B.1020400@redhat.com> <fu3m46xv3d.ln2@ppp1053.in.ipex.cz>
Message-ID: <gla7og$kk9$2@ger.gmane.org>

Matej Cepl wrote:
> On 2009-01-22, 11:19 GMT, Andrew Haley wrote:
>> I didn't know that pressing 'a' repeatedly will get you to the 
>> kernel command prompt.
> 
> Well, strictly speaking you can press any key (I think even Ctrl 
> will do), but advantage of 'a' is that it gets you straight to 
> kernel command line ('a' command in grub).

You mean it isn't supposed to be F8? :-) Wonder where I got that idea 
from, then.

You don't have to "press repeatedly" either, just start holding 
something as the BIOS is finishing with POST.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Who let the hippos out?



From jkeating at redhat.com  Thu Jan 22 16:54:31 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Jan 2009 08:54:31 -0800
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <gla7og$kk9$2@ger.gmane.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org> <20090121030132.GG19788@kvack.org>
	<4976F69D.2050805@fedoraproject.org> <20090121155344.GI19788@kvack.org>
	<440m46x0hc.ln2@ppp1053.in.ipex.cz> <4978563B.1020400@redhat.com>
	<fu3m46xv3d.ln2@ppp1053.in.ipex.cz>  <gla7og$kk9$2@ger.gmane.org>
Message-ID: <1232643271.3539.268.camel@localhost.localdomain>

On Thu, 2009-01-22 at 10:44 -0600, Matthew Woehlke wrote:
>  You mean it isn't supposed to be F8? :-) Wonder where I got that idea 
> from, then.

It's any key.

> 
> You don't have to "press repeatedly" either, just start holding 
> something as the BIOS is finishing with POST.

Right, so long as your bios doesn't freak out about a stuck key.
Typically I use shift as it doesn't have any bios level bindings, nor
any grub level bindings.  You can just lay on the shift and grub will
eventually bring up a gui for you.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/9e13b8c3/attachment.sig>

From mlichvar at redhat.com  Thu Jan 22 17:03:54 2009
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Thu, 22 Jan 2009 18:03:54 +0100
Subject: updating statistics
Message-ID: <20090122170354.GA1800@localhost>

I was wondering, do we have any data that show how often are Fedora
users pulling updates? There was an information about how many unique
IP addresses hit Fedora mirrors, this had to come from somewhere.

The reason I'm asking is that one of my updates hit a yum bug. How
long after fixed yum is pushed to stable should I wait if I wanted
to have it updated on say 90 % of the machines?

-- 
Miroslav Lichvar



From mike at miketc.net  Thu Jan 22 17:07:33 2009
From: mike at miketc.net (Mike Chambers)
Date: Thu, 22 Jan 2009 11:07:33 -0600
Subject: X Problem in Fedora 10
In-Reply-To: <1232640367.4537.22.camel@dhcp-lab-234.englab.brq.redhat.com>
References: <497890C0.2050505@gmail.com>  <49789193.3020407@redhat.com>
	<1232640367.4537.22.camel@dhcp-lab-234.englab.brq.redhat.com>
Message-ID: <1232644053.28336.1.camel@scrappy.miketc.net>

On Thu, 2009-01-22 at 17:06 +0100, Jiri Skala wrote:

> The xorg.conf doesn't work fine after installation/upgrade. I use my
> notebook (1440x900) in the dock with external LCD (1280x1024) and the
> resolutions are incorrect after starting up. The resolution doesn't
> match to resolution in the xorg.conf.
> 
> I use xrandr then everything is fine (for dual monitors).
> 
> But settings of xorg.conf during installation should be used and this
> isn't.

And to get an xorg.conf created or to make changes, make sure
system-config-display rpm is installed, then run same command to make
changes.

-- 
Mike Chambers
Fedora Project - Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From mw_triad at users.sourceforge.net  Thu Jan 22 17:11:05 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 22 Jan 2009 11:11:05 -0600
Subject: Root Logins in X...
In-Reply-To: <49781C9C.4000007@redhat.com>
References: <49781C9C.4000007@redhat.com>
Message-ID: <gla9b9$qgm$1@ger.gmane.org>

Warren Togami wrote:
> Let us step back and consider the actual goal of preventing root logins.
> 
> We want to stop people from logging in as root on their X desktop
> because it is almost always done out of laziness.  We want to discourage
> these lazy users from logging in as root and using desktop applications,
> which can be a dangerous thing.
> 
> The only legitimate reason to allow root login is disaster recovery.
> The case where /home filesystem is full and logins fail, or /home is
> remote and inaccessible are cases where graphical non-root logins can fail.
> 
> So why don't we make root logins from GDM a stripped down desktop with
> only a terminal and a menu with only configuration tools?  This desktop
> should be ugly and with a very obvious note explaining why they
> shouldn't be logged in as root.
> 
> Benefits?
> - Educates the users.
> - Prevents future stupid flame wars.

+1. At one point I had my box set up that way (not sure if it still is, 
or not); root login would get... twm + xterm. Why? Because I would use 
it when things went wrong, and because generally I can fix it with a 
console, or /limited/ use of X apps. And because running xterm in X is 
still light-years better than a text-mode console. (Yes, even if KMS 
worked on my system - which it doesn't - because I can take advantage of 
all three screens I have hooked up with multiple xterms open at a time.)

Personally, I'd even suggest the same setup, twm + xterm. It certainly 
qualifies as 'ugly' ;-).

Oh... Michal's right about one thing, though; xclock (in text mode, 
please!) would be a nice addition if we set this up as default.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Who let the hippos out?



From a.badger at gmail.com  Thu Jan 22 17:23:48 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 22 Jan 2009 09:23:48 -0800
Subject: smart package manager oddities
In-Reply-To: <gl9rg7$817$2@ger.gmane.org>
References: <20090122110619.40ad8525@gmx.net>	<1232626691.3802.63.camel@rosebud>	<20090122135623.3227ed66@gmx.net>
	<gl9rg7$817$2@ger.gmane.org>
Message-ID: <4978ABA4.7060109@gmail.com>

Kevin Kofler wrote:
> Stefan Grosse wrote:
>> Now I thought that when I use yum to remove smart, it (yum) would
>>  clean/delete the files in /var/lib/smart/ as well. This was not the
>>  case. But maybe this is intentional? I am not an expert.
> 
> Removing a package does not remove files created at runtime by the software
> contained in the package (except if the preuninstall or postuninstall
> script of the package removes them, but in general it doesn't), only files
> contained in the package itself.
> 
This could be a packaging problem in smart.  If the files have
predictable names and don't contain non-replacable content then it might
need to %ghost them.  Not being a smart user, though, I don't know if
that's the case with these files or not.  If you're using the smart
package from Fedora you might want to open a bug against the package
here as well.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/aa58dedc/attachment.sig>

From kevin at finway.co.uk  Thu Jan 22 17:43:40 2009
From: kevin at finway.co.uk (Kevin Coffin)
Date: Thu, 22 Jan 2009 17:43:40 +0000
Subject: How do I allow automatic non root access to my non standard
 USB device ?
In-Reply-To: <604aa7910901211419i18ada7a1x9530016ee09d6f5e@mail.gmail.com>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232575779.3610.30.camel@warbird.finway.co.uk>
	<604aa7910901211419i18ada7a1x9530016ee09d6f5e@mail.gmail.com>
Message-ID: <1232646220.3760.83.camel@warbird.finway.co.uk>

On Wed, 2009-01-21 at 13:19 -0900, Jeff Spaleta wrote:
> On Wed, Jan 21, 2009 at 1:09 PM, Kevin Coffin <kevin at finway.co.uk> wrote:
> 
> >Although the quick hack that I
> > posted does seem to work for me I am not sure exactly how it is
> > achieved. I do not see the group/owner on the endpoints for the usb
> > device change. If you have any pointers to further reading on the
> > inter-actions between hal and policykit they would be gratefully
> > received.
> 
> Aren't they done via acl manipulations?
> 
> Do you see changes in the getfacl  output?

Ah, I didn't know about this command. Yes it does show that the acl's
have changed. Also when using ls -la you get this:

crw-rw-r--+ 1 root root 189, 4 2009-01-22 14:28 005

I have not seen the plus sign being used before.

> 
> >
> > There is probably a better way to do this. Further reading today
> > indicated that this should have been placed in /etc/hal directory
> > structure. I do have an rpm for openocd and it would be nice to have it
> > install the correct permissions in the right place.
> 
> The question remains. If a new documentation effort were to be made
> what form of documentation would be the first priority to work on?
> 
> -jef
> 

I guess what I was looking for was something which would give the steps
of how to integrate a totally unknown device into the hal/policykit
structure so that it could be used by a user other than root.

For example:

1. add a policy file to the /usr/share/PolicyKit/policy directory
containing

  <action id="org.freedesktop.hal.device-access.usb-jtag">
    <description>Directly access to usb jtag devices</description>
    <message>System policy prevents access to usb jtag devices</message>
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>yes</allow_active>
    </defaults>
  </action>

This then shows up in the authorizations gui so that users can be added
to the acl.

2. Hal requires some metadata about this device, so add a .fd file in
the /usr/share/hal/fdi/information/20thirdparty directory containing

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>

      <match key="usb_device.vendor_id" int="0x15ba">
         <append key="info.capabilities"
type="strlist">olimex-device</append>
         <append key="info.capabilities"
type="strlist">usb-jtag</append>
          <append key="info.capabilities"
type="strlist">access_control</append>
          <merge key="access_control.file"
type="copy_property">linux.device_file</merge>
          <merge key="access_control.type"
type="string">usb-jtag</merge>
     </match>
  
  </device>
</deviceinfo>

3. Add .fdi file for hal policy to
the /usr/share/hal/fdi/policy/20thirdparty directory containing

   <match key="info.capabilities" contains="usbraw">
      <match key="info.capabilities" sibling_contains="usb-jtag">
	<append key="info.capabilities" type="strlist">access_control</append>
	<merge key="access_control.file"
type="copy_property">usbraw.device</merge>
	<merge key="access_control.type" type="string">usb-jtag</merge>
      </match>
    </match>

    <!-- support for Linux USB stack where linux.device_file is set
(e.g. device node is on the main usb device) -->
    <match key="info.subsystem" string="usb">
      <match key="@info.parent:linux.device_file" exists="true">
       <match key="info.capabilities" contains="usb-jtag">
          <append key="info.capabilities"
type="strlist">access_control</append>
          <merge key="access_control.type"
type="string">usb-jtag</merge>
          <merge key="access_control.file"
type="copy_property">@info.parent:linux.device_file</merge>
        </match>
     </match>
    </match>

4 Run the authorizations gui and grant the user the right to access the
device.


Oh look I've done it now - its simple when you have done it once. Would
you like me to write it up with more detail ? Someone will need to look
over it because I am not sure that everything I have done is correct.

Comments and suggestions welcome.

Kevin







From jonstanley at gmail.com  Thu Jan 22 17:53:40 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 22 Jan 2009 12:53:40 -0500
Subject: Plan for tomorrow's (20090123) FESCo meeting
Message-ID: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>

Here's a list of items that will come up during tomorrow's FESCo meeting.

26	Archer
27	IBus
28	Stronger Hashes
30	KVM PCI Device Assignment -
https://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment
31	SSSD - https://fedoraproject.org/wiki/Features/SSSD
32	Instant on Fedora - https://fedoraproject.org/wiki/Features/instant-on-Fedora
29	Review FPC Report -
https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01235.html

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.

Thanks!
-Jon



From Jochen at herr-schmitt.de  Thu Jan 22 18:00:42 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 22 Jan 2009 19:00:42 +0100
Subject: Plan for tomorrow's (20090123) FESCo meeting
In-Reply-To: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
References: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
Message-ID: <4978B44A.8090606@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Stanley schrieb:
> Here's a list of items that will come up during tomorrow's FESCo meeting.
I would ask, where is the summary of the last FESCo meeting.

In  the past a summary of the FESCo meeting was posting here on the
mailing list.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkl4tDgACgkQT2AHK6txfgzQrwCgyhweffM3mTmAWIQ0Dp5ayI2I
bKYAn3R9uPcx2f/XcnrCurBayQdVarBG
=NEpg
-----END PGP SIGNATURE-----



From sundaram at fedoraproject.org  Thu Jan 22 18:08:46 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Jan 2009 23:38:46 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090122121439.GA3201@hurricane.linuxnetz.de>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090122073641.GA6637@hurricane.linuxnetz.de>	<497827DC.7030303@fedoraproject.org>
	<20090122121439.GA3201@hurricane.linuxnetz.de>
Message-ID: <4978B62E.1040309@fedoraproject.org>

Robert Scheck wrote:
> On Thu, 22 Jan 2009, Rahul Sundaram wrote:
>> Never once have I felt a real need to tell people to get a root X login  
>> for any reason at all.
> 
> I'm always suggesting using a terminal rather a whole X login, but we don't
> life in a perfect world. We just have the reality being not perfect - so we
> have to deal with such things as well.

This is a argument for always retaining the status quo no matter what. I 
don't buy it. If you are encouraging using a terminal rather than a root 
X login, then you should be supporting the current default. Those who 
know, what they are doing can edit the pam configuration anyway.

Rahul



From rjones at redhat.com  Thu Jan 22 18:10:05 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Jan 2009 18:10:05 +0000
Subject: Is Yum broken in Rawhide?
Message-ID: <20090122181005.GA14933@amd.home.annexia.org>

I did a 'yum clean all', but I still get the stack trace below from
commands such as 'yum install foo' or 'yum update'.

Rich.

# yum install yum
Loaded plugins: dellsysidplugin2, refresh-packagekit

(process:1645): GLib-CRITICAL **: g_timer_stop: assertion `timer != NULL' failed

(process:1645): GLib-CRITICAL **: g_timer_destroy: assertion `timer != NULL' failed
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 229, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 104, in main
    result, resultmsgs = base.doCommands()
  File "/usr/share/yum-cli/cli.py", line 339, in doCommands
    self._getTs(needTsRemove)
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 101, in _getTs
    self._getTsInfo(remove_only)
  File "/usr/lib/python2.6/site-packages/yum/depsolve.py", line 112, in _getTsInfo
    pkgSack = self.pkgSack
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 592, in <lambda>
    pkgSack = property(fget=lambda self: self._getSacks(),
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 435, in _getSacks
    self.repos.populateSack(which=repos)
  File "/usr/lib/python2.6/site-packages/yum/repos.py", line 251, in populateSack
    sack.populate(repo, mdtype, callback, cacheonly)
  File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 184, in populate
    dobj = repo_cache_function(xml, csum)
  File "/usr/lib64/python2.6/site-packages/sqlitecachec.py", line 45, in getPrimary
    self.repoid))
TypeError: Can not create packages table: near "release": syntax error


-- 
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 sundaram at fedoraproject.org  Thu Jan 22 18:11:38 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Jan 2009 23:41:38 +0530
Subject: Problem with login in root account in Fedora10
In-Reply-To: <b081db690901220406w1488c587s16822e96badf3980@mail.gmail.com>
References: <b081db690901220406w1488c587s16822e96badf3980@mail.gmail.com>
Message-ID: <4978B6DA.5030503@fedoraproject.org>

navneet rastogi wrote:
> Hello,
>       I am a member of GLUG Meerut and we are distributing Fedora10.I
> want to tell u about a bug in fedora10. It's just a simple mistake of
> a '#' but you never ignore it because a small ant can kill a big
> ELEPHANT .

You have to be more specific.  Root is disabled in GDM by default and 
that is not a bug.

Rahul



From rjones at redhat.com  Thu Jan 22 18:12:36 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Jan 2009 18:12:36 +0000
Subject: Is Yum broken in Rawhide?
In-Reply-To: <20090122181005.GA14933@amd.home.annexia.org>
References: <20090122181005.GA14933@amd.home.annexia.org>
Message-ID: <20090122181236.GA14966@amd.home.annexia.org>


I should have noted what version I am using:

# rpm -qa | grep yum
PackageKit-yum-plugin-0.4.0-1.fc11.x86_64
yum-metadata-parser-1.1.2-11.fc11.x86_64
yum-3.2.21-3.fc11.noarch
PackageKit-yum-0.4.0-1.fc11.x86_64
yum-utils-1.1.19-1.fc11.noarch
anaconda-yum-plugins-1.0-3.fc10.noarch

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 navneetrastogi99 at gmail.com  Thu Jan 22 18:16:31 2009
From: navneetrastogi99 at gmail.com (navneet rastogi)
Date: Thu, 22 Jan 2009 23:46:31 +0530
Subject: Problem with login in root account in Fedora10
In-Reply-To: <4978B6DA.5030503@fedoraproject.org>
References: <b081db690901220406w1488c587s16822e96badf3980@mail.gmail.com>
	<4978B6DA.5030503@fedoraproject.org>
Message-ID: <b081db690901221016m6706a29q4b7212d6e5b5dd68@mail.gmail.com>

I think it should enable as like fedora9 because without login root
nothing is possible.

On Thu, Jan 22, 2009 at 11:41 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> navneet rastogi wrote:
>>
>> Hello,
>>      I am a member of GLUG Meerut and we are distributing Fedora10.I
>> want to tell u about a bug in fedora10. It's just a simple mistake of
>> a '#' but you never ignore it because a small ant can kill a big
>> ELEPHANT .
>
> You have to be more specific.  Root is disabled in GDM by default and that
> is not a bug.
>
> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From sstarr at platform.com  Thu Jan 22 18:17:07 2009
From: sstarr at platform.com (Shawn Starr)
Date: Thu, 22 Jan 2009 13:17:07 -0500
Subject: F10 and no root login - impossible to maintain systems!
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
> Rahul Sundaram
> Sent: Thursday, January 22, 2009 3:02 AM
> To: Development discussions related to Fedora
> Subject: Re: F10 and no root login - impossible to maintain systems!
> 
> 
> Robert Scheck wrote:
> > On Wed, 21 Jan 2009, Rahul Sundaram wrote:
> >> You can at run level 3. You can even start X after that.
> > 
> > Haha, if the machine is a few hundred miles away at the 
> customer and you
> > don't have any longer access? Ever tried to explain a 
> non-computer user
> > being near to the machine how to solve issues via phone if 
> it's urgent or
> > even critical and time to drive the few hundred miles is 
> not available,
> > too? Very clever suggestion, you've made...
> 
> Yes. I have. For a few years actually and in my experience, it has 
> always been more efficient to instruct people type things in the 
> terminal rather than login via GDM as root user. For one, the 
> shell is 
> pretty consistent, commands don't change often if at all and for 
> administration, you frequently have to fall back to the 
> terminal anyway.
> 
> Never once have I felt a real need to tell people to get a 
> root X login 
> for any reason at all.

I'm going to jump into this flamefest, Can we STOP with the "Mother knows best" menality in Fedora? I have needed to log in as root with X a few times.     Stop turning Fedora into a 'Ubuntu'.

> 
> Rahul
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



From markmc at redhat.com  Thu Jan 22 18:21:18 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 22 Jan 2009 18:21:18 +0000
Subject: Plan for tomorrow's (20090123) FESCo meeting
In-Reply-To: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
References: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
Message-ID: <1232648478.4533.50.camel@blaa>

Hi Jon,

On Thu, 2009-01-22 at 12:53 -0500, Jon Stanley wrote:
> Here's a list of items that will come up during tomorrow's FESCo meeting.

Is it at 19.00 UTC?

Wiki says it's on Wednesdays:

  http://fedoraproject.org/wiki/Development/SteeringCommittee

Cheers,
Mark.



From skvidal at fedoraproject.org  Thu Jan 22 18:21:19 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 22 Jan 2009 13:21:19 -0500
Subject: updating statistics
In-Reply-To: <20090122170354.GA1800@localhost>
References: <20090122170354.GA1800@localhost>
Message-ID: <1232648479.3802.93.camel@rosebud>

On Thu, 2009-01-22 at 18:03 +0100, Miroslav Lichvar wrote:
> I was wondering, do we have any data that show how often are Fedora
> users pulling updates? There was an information about how many unique
> IP addresses hit Fedora mirrors, this had to come from somewhere.
> 
> The reason I'm asking is that one of my updates hit a yum bug. How
> long after fixed yum is pushed to stable should I wait if I wanted
> to have it updated on say 90 % of the machines?
> 

What yum bug is this?

-sv




From selinux at gmail.com  Thu Jan 22 18:20:16 2009
From: selinux at gmail.com (Tom London)
Date: Thu, 22 Jan 2009 10:20:16 -0800
Subject: Is Yum broken in Rawhide?
In-Reply-To: <20090122181236.GA14966@amd.home.annexia.org>
References: <20090122181005.GA14933@amd.home.annexia.org>
	<20090122181236.GA14966@amd.home.annexia.org>
Message-ID: <4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 22, 2009 at 10:12 AM, Richard W.M. Jones  wrote:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAkl4uNwACgkQuCS0flj2OB11mACg30NqfrpcQs/6WZamaLW3lLBz
E90AnRZw9qbcmg/LdkNL6DpvCcavX3gL
=SAtZ
-----END PGP SIGNATURE-----

>
> I should have noted what version I am using:
>
> # rpm -qa | grep yum
> PackageKit-yum-plugin-0.4.0-1.fc11.x86_64
> yum-metadata-parser-1.1.2-11.fc11.x86_64
> yum-3.2.21-3.fc11.noarch
> PackageKit-yum-0.4.0-1.fc11.x86_64
> yum-utils-1.1.19-1.fc11.noarch
> anaconda-yum-plugins-1.0-3.fc10.noarch
>
> Rich.
>

Not sure its the same: https://bugzilla.redhat.com/show_bug.cgi?id=481189

Reverting sqlite to sqlite-3.6.7-1.fc11.x86_64 "works for me".

tom
-- 
Tom London



From sundaram at fedoraproject.org  Thu Jan 22 18:22:11 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Jan 2009 23:52:11 +0530
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
Message-ID: <4978B953.9010209@fedoraproject.org>

Shawn Starr wrote:

> 
> I'm going to jump into this flamefest, Can we STOP with the "Mother knows best" menality in Fedora? I have needed to log in as root with X a few times.     Stop turning Fedora into a 'Ubuntu'.
> 

If you want to change it, edit your pam settings.

Rahul



From sundaram at fedoraproject.org  Thu Jan 22 18:23:29 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 22 Jan 2009 23:53:29 +0530
Subject: Problem with login in root account in Fedora10
In-Reply-To: <b081db690901221016m6706a29q4b7212d6e5b5dd68@mail.gmail.com>
References: <b081db690901220406w1488c587s16822e96badf3980@mail.gmail.com>	<4978B6DA.5030503@fedoraproject.org>
	<b081db690901221016m6706a29q4b7212d6e5b5dd68@mail.gmail.com>
Message-ID: <4978B9A1.90309@fedoraproject.org>

navneet rastogi wrote:
> I think it should enable as like fedora9 because without login root
> nothing is possible.

Sure it is possible. Just use su - or configure sudo.  There is already 
an ongoing thread on this topic. Read and follow that instead of 
starting another.

Rahul



From Jochen at herr-schmitt.de  Thu Jan 22 18:24:39 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Thu, 22 Jan 2009 19:24:39 +0100
Subject: Plan for tomorrow's (20090123) FESCo meeting
In-Reply-To: <1232648478.4533.50.camel@blaa>
References: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
	<1232648478.4533.50.camel@blaa>
Message-ID: <4978B9E7.2050708@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark McLoughlin schrieb:
> Is it at 19.00 UTC?
>
> Wiki says it's on Wednesdays:
>
> http://fedoraproject.org/wiki/Development/SteeringCommittee
>
Since the last week the FESco meeting is on Friday.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkl4udIACgkQT2AHK6txfgzzNACeNl/JZjfFvM/CxGPaUsGkeECk
FBAAoKdJxwUI/6hal+Lu8QiFWU60ZQja
=Ydld
-----END PGP SIGNATURE-----



From james at fedoraproject.org  Thu Jan 22 18:37:54 2009
From: james at fedoraproject.org (James Antill)
Date: Thu, 22 Jan 2009 13:37:54 -0500
Subject: Is Yum broken in Rawhide?
In-Reply-To: <4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
References: <20090122181005.GA14933@amd.home.annexia.org>
	<20090122181236.GA14966@amd.home.annexia.org>
	<4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
Message-ID: <1232649474.20759.103.camel@code.and.org>

On Thu, 2009-01-22 at 10:20 -0800, Tom London wrote:
> 
> Not sure its the same:
> https://bugzilla.redhat.com/show_bug.cgi?id=481189
> 
> Reverting sqlite to sqlite-3.6.7-1.fc11.x86_64 "works for me".

 It is, we are investigating but it looks like sqlite in rawhide is
broken. upstream sqlite bug:

http://www.sqlite.org/cvstrac/tktview?tn=3584

...might be a cause.

-- 
James Antill <james at fedoraproject.org>
Fedora



From mlichvar at redhat.com  Thu Jan 22 18:55:47 2009
From: mlichvar at redhat.com (Miroslav Lichvar)
Date: Thu, 22 Jan 2009 19:55:47 +0100
Subject: updating statistics
In-Reply-To: <1232648479.3802.93.camel@rosebud>
References: <20090122170354.GA1800@localhost>
	<1232648479.3802.93.camel@rosebud>
Message-ID: <20090122185547.GA8470@localhost>

On Thu, Jan 22, 2009 at 01:21:19PM -0500, seth vidal wrote:
> On Thu, 2009-01-22 at 18:03 +0100, Miroslav Lichvar wrote:
> > I was wondering, do we have any data that show how often are Fedora
> > users pulling updates? There was an information about how many unique
> > IP addresses hit Fedora mirrors, this had to come from somewhere.
> > 
> > The reason I'm asking is that one of my updates hit a yum bug. How
> > long after fixed yum is pushed to stable should I wait if I wanted
> > to have it updated on say 90 % of the machines?
> > 
> 
> What yum bug is this?

#472756

-- 
Miroslav Lichvar



From gbofspam at gmail.com  Thu Jan 22 19:01:42 2009
From: gbofspam at gmail.com (Andrew Parker)
Date: Thu, 22 Jan 2009 14:01:42 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <497827DC.7030303@fedoraproject.org>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090122073641.GA6637@hurricane.linuxnetz.de>
	<497827DC.7030303@fedoraproject.org>
Message-ID: <6c3f5e6c0901221101q3a7ddfa9le6e051d662da3aaa@mail.gmail.com>

On Thu, Jan 22, 2009 at 3:01 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:

> Never once have I felt a real need to tell people to get a root X login for
> any reason at all.

What if /home is hosed and they need the network (WIFI) to fix it?
How would you get NetworkManager configured from the command line?
How would I get that new kernel that resolves the problem?

What if /home is hosed, or / and /tmp are full, and system-config-lvm
is needed to help fix it?  Or any one of the other splendid GUIs we
now have that are an awful lot less error prone than doing something
from the command line.

Note that I'm not necessarily in favour of allowing root logins on X
*by default*, its just that I don't like the argument of "I have
never..." being falsely extrapolated to "Nobody will ever ..."



From jonstanley at gmail.com  Thu Jan 22 19:10:04 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 22 Jan 2009 14:10:04 -0500
Subject: Plan for tomorrow's (20090123) FESCo meeting
In-Reply-To: <1232648478.4533.50.camel@blaa>
References: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
	<1232648478.4533.50.camel@blaa>
Message-ID: <da159fda0901221110q15a9697dx3d8458f92a69e810@mail.gmail.com>

On Thu, Jan 22, 2009 at 1:21 PM, Mark McLoughlin <markmc at redhat.com> wrote:

> Is it at 19.00 UTC?
>
> Wiki says it's on Wednesdays:
>
>  http://fedoraproject.org/wiki/Development/SteeringCommittee

Apologies, I updated the Wiki page, it's at 17:00UTC (noon EST)



From jonstanley at gmail.com  Thu Jan 22 19:11:29 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 22 Jan 2009 14:11:29 -0500
Subject: Plan for tomorrow's (20090123) FESCo meeting
In-Reply-To: <4978B44A.8090606@herr-schmitt.de>
References: <da159fda0901220953r660767fdi562cbfa0153f749@mail.gmail.com>
	<4978B44A.8090606@herr-schmitt.de>
Message-ID: <da159fda0901221111o4a40d74fqe77f67d1b69e08f9@mail.gmail.com>

On Thu, Jan 22, 2009 at 1:00 PM, Jochen Schmitt <Jochen at herr-schmitt.de> wrote:

> I would ask, where is the summary of the last FESCo meeting.
>
> In  the past a summary of the FESCo meeting was posting here on the
> mailing list.

We decided to divy up that task.  I'll chase down the individual
responsible and see what happend. Apologies.



From jkeating at redhat.com  Thu Jan 22 19:21:45 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Jan 2009 11:21:45 -0800
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <6c3f5e6c0901221101q3a7ddfa9le6e051d662da3aaa@mail.gmail.com>
References: <20090121025533.GF19788@kvack.org>
	<49768F95.5080800@fedoraproject.org>
	<20090122073641.GA6637@hurricane.linuxnetz.de>
	<497827DC.7030303@fedoraproject.org>
	<6c3f5e6c0901221101q3a7ddfa9le6e051d662da3aaa@mail.gmail.com>
Message-ID: <1232652105.3539.275.camel@localhost.localdomain>

On Thu, 2009-01-22 at 14:01 -0500, Andrew Parker wrote:
> On Thu, Jan 22, 2009 at 3:01 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
> 
> > Never once have I felt a real need to tell people to get a root X login for
> > any reason at all.
> 
> What if /home is hosed and they need the network (WIFI) to fix it?
> How would you get NetworkManager configured from the command line?
> How would I get that new kernel that resolves the problem?
> 
> What if /home is hosed, or / and /tmp are full, and system-config-lvm
> is needed to help fix it?  Or any one of the other splendid GUIs we
> now have that are an awful lot less error prone than doing something
> from the command line.
> 
> Note that I'm not necessarily in favour of allowing root logins on X
> *by default*, its just that I don't like the argument of "I have
> never..." being falsely extrapolated to "Nobody will ever ..."

So create a user with a homedir of /tmp or some rot, that isn't on your
network mounted /home that you can use for maint tasks.  IE a completely
local user to use for recovery purposes.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/1a0521d2/attachment.sig>

From casimiro.barreto at gmail.com  Thu Jan 22 19:46:38 2009
From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto)
Date: Thu, 22 Jan 2009 17:46:38 -0200
Subject: Kernel message
Message-ID: <4978CD1E.3080309@gmail.com>

Hello,

I'm receiving this message:

[casimiro at terra ~]$  terra kernel: P0 eprtr bv hehl,cucoktrtld(oa vns=1819

Someone knows what's going on? Error in CPU0 ???

Thanks

Casimiro


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/b68edbba/attachment.sig>

From james at fedoraproject.org  Thu Jan 22 19:57:21 2009
From: james at fedoraproject.org (James Antill)
Date: Thu, 22 Jan 2009 14:57:21 -0500
Subject: Is Yum broken in Rawhide?
In-Reply-To: <1232649474.20759.103.camel@code.and.org>
References: <20090122181005.GA14933@amd.home.annexia.org>
	<20090122181236.GA14966@amd.home.annexia.org>
	<4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
	<1232649474.20759.103.camel@code.and.org>
Message-ID: <1232654241.20759.105.camel@code.and.org>

On Thu, 2009-01-22 at 13:37 -0500, James Antill wrote:
> On Thu, 2009-01-22 at 10:20 -0800, Tom London wrote:
> > 
> > Not sure its the same:
> > https://bugzilla.redhat.com/show_bug.cgi?id=481189
> > 
> > Reverting sqlite to sqlite-3.6.7-1.fc11.x86_64 "works for me".
> 
>  It is, we are investigating but it looks like sqlite in rawhide is
> broken. upstream sqlite bug:
> 
> http://www.sqlite.org/cvstrac/tktview?tn=3584
> 
> ...might be a cause.

 This is the actual bug ("release" accidentally became a reserved word):

 http://www.sqlite.org/cvstrac/tktview?tn=3590

-- 
James Antill - james at fedoraproject.org
"I'd just like to see a realistic approach to updates via
 packages." -- Les Mikesell



From pmatilai at laiskiainen.org  Thu Jan 22 20:04:37 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 22 Jan 2009 22:04:37 +0200 (EET)
Subject: Is Yum broken in Rawhide?
In-Reply-To: <1232654241.20759.105.camel@code.and.org>
References: <20090122181005.GA14933@amd.home.annexia.org>
	<20090122181236.GA14966@amd.home.annexia.org>
	<4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
	<1232649474.20759.103.camel@code.and.org>
	<1232654241.20759.105.camel@code.and.org>
Message-ID: <alpine.LFD.2.00.0901222203050.21524@turre.koti.laiskiainen.org>

On Thu, 22 Jan 2009, James Antill wrote:

> On Thu, 2009-01-22 at 13:37 -0500, James Antill wrote:
>> On Thu, 2009-01-22 at 10:20 -0800, Tom London wrote:
>>>
>>> Not sure its the same:
>>> https://bugzilla.redhat.com/show_bug.cgi?id=481189
>>>
>>> Reverting sqlite to sqlite-3.6.7-1.fc11.x86_64 "works for me".
>>
>>  It is, we are investigating but it looks like sqlite in rawhide is
>> broken. upstream sqlite bug:
>>
>> http://www.sqlite.org/cvstrac/tktview?tn=3584
>>
>> ...might be a cause.
>
> This is the actual bug ("release" accidentally became a reserved word):
>
> http://www.sqlite.org/cvstrac/tktview?tn=3590

Yup. Fixed sqlite built to rawhide already, sorry for the breakage :-/

 	- Panu -



From jspaleta at gmail.com  Thu Jan 22 20:14:54 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 22 Jan 2009 11:14:54 -0900
Subject: updating statistics
In-Reply-To: <20090122170354.GA1800@localhost>
References: <20090122170354.GA1800@localhost>
Message-ID: <604aa7910901221214mcd061b9x5debfded3938ebdc@mail.gmail.com>

On Thu, Jan 22, 2009 at 8:03 AM, Miroslav Lichvar <mlichvar at redhat.com> wrote:
> I was wondering, do we have any data that show how often are Fedora
> users pulling updates? There was an information about how many unique
> IP addresses hit Fedora mirrors, this had to come from somewhere.

I'm not aware of any automated analysis. I can certainly do it this
sort of thing, but I am wary of working with log data directly because
I do not want access to the raw information. I have a lot of analysis
ideas in this area. Some of which I've shared.

I'd like to be able to just pop analysis scripts into infrastructure
workflow which produce aggregate data.  To be able to do that I just
need a python object that I can iterate over which represents a time
window of mirrormanager log information. That way I could build a set
of python based analysis scripts using fake log data, and then I hand
them over to infrastructure to run at whatever frequency is deemed
appropriate..without leaking any log information to me directly.

-jef



From rjones at redhat.com  Thu Jan 22 20:20:09 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Thu, 22 Jan 2009 20:20:09 +0000
Subject: Is Yum broken in Rawhide?
In-Reply-To: <4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
References: <20090122181005.GA14933@amd.home.annexia.org>
	<20090122181236.GA14966@amd.home.annexia.org>
	<4c4ba1530901221020r95be21fs139f23ed931f0ef3@mail.gmail.com>
Message-ID: <20090122202009.GA15614@amd.home.annexia.org>

On Thu, Jan 22, 2009 at 10:20:16AM -0800, Tom London wrote:
> Not sure its the same: https://bugzilla.redhat.com/show_bug.cgi?id=481189
> 
> Reverting sqlite to sqlite-3.6.7-1.fc11.x86_64 "works for me".

That worked for me, thanks!

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From davej at redhat.com  Thu Jan 22 20:29:01 2009
From: davej at redhat.com (Dave Jones)
Date: Thu, 22 Jan 2009 15:29:01 -0500
Subject: Kernel message
In-Reply-To: <4978CD1E.3080309@gmail.com>
References: <4978CD1E.3080309@gmail.com>
Message-ID: <20090122202901.GA17920@redhat.com>

On Thu, Jan 22, 2009 at 05:46:38PM -0200, Casimiro de Almeida Barreto wrote:
 > Hello,
 > 
 > I'm receiving this message:
 > 
 > [casimiro at terra ~]$  terra kernel: P0 eprtr bv hehl,cucoktrtld(oa vns=1819
 > 
 > Someone knows what's going on? Error in CPU0 ???
 
I have no idea what kind of moon language that is, but
it means absolutely nothing to me.

No idea, sorry.

	Dave

-- 
http://www.codemonkey.org.uk



From jspaleta at gmail.com  Thu Jan 22 20:29:25 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 22 Jan 2009 11:29:25 -0900
Subject: How do I allow automatic non root access to my non standard USB
	device ?
In-Reply-To: <1232646220.3760.83.camel@warbird.finway.co.uk>
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232575779.3610.30.camel@warbird.finway.co.uk>
	<604aa7910901211419i18ada7a1x9530016ee09d6f5e@mail.gmail.com>
	<1232646220.3760.83.camel@warbird.finway.co.uk>
Message-ID: <604aa7910901221229p3bc79d08j27f30cd5a06668f8@mail.gmail.com>

On Thu, Jan 22, 2009 at 8:43 AM, Kevin Coffin <kevin at finway.co.uk> wrote:
> Oh look I've done it now - its simple when you have done it once. Would
> you like me to write it up with more detail ? Someone will need to look
> over it because I am not sure that everything I have done is correct.
>
> Comments and suggestions welcome.

Where is the right place to put that sort of step-by-step guide?

Release notes? I'm not sure.
/usr/share/docs ?

I just don't know where people expect to find and read this sort of stuff.

And I think we are still in a transitionary state in how we handle
authorizations.  I think the new tech is very very interesting but the
comfort level people have with it is lagging behind its capabilities.
If I'm going to write documentation aimed at closing that gap, I want
to make sure its written in format and location that it's preferred.

-jef



From tgl at redhat.com  Thu Jan 22 20:51:58 2009
From: tgl at redhat.com (Tom Lane)
Date: Thu, 22 Jan 2009 15:51:58 -0500
Subject: Heads up: MySQL 5.1 coming soon to rawhide 
In-Reply-To: <17843.1231955552@sss.pgh.pa.us> 
References: <17597.1231954770@sss.pgh.pa.us>
	<d0c4ab73fbf661e5662789bbc2dbb204.squirrel@mail.jcomserv.net>
	<17843.1231955552@sss.pgh.pa.us>
Message-ID: <12523.1232657518@sss.pgh.pa.us>

Tom Lane <tgl at redhat.com> writes:
> I intend to push mysql 5.1.30 into rawhide next week, as soon as the
> alpha freeze has lifted.

> "Jon Ciesla" <limb at jcomserv.net> writes:
>> Will you give us a shout here right after yuo do it?

> Sure, will do.

mysql 5.1.30-2 is built in rawhide.  I'm not sure how long it takes to
hit the buildroots, but things should start breaking shortly ;-)

			regards, tom lane



From kevin.kofler at chello.at  Thu Jan 22 22:19:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 23:19:56 +0100
Subject: How do I allow automatic non root access to my non standard USB
	device ?
References: <1232410842.3977.4.camel@localhost.localdomain>
	<1232499290.10991.1.camel@localhost.localdomain>
	<1232554997.3610.11.camel@warbird.finway.co.uk>
	<604aa7910901211241g1f0674ev992edc7e38536185@mail.gmail.com>
	<1232575779.3610.30.camel@warbird.finway.co.uk>
	<604aa7910901211419i18ada7a1x9530016ee09d6f5e@mail.gmail.com>
	<1232646220.3760.83.camel@warbird.finway.co.uk>
Message-ID: <glarec$thj$1@ger.gmane.org>

Kevin Coffin wrote:
> Ah, I didn't know about this command. Yes it does show that the acl's
> have changed. Also when using ls -la you get this:
> 
> crw-rw-r--+ 1 root root 189, 4 2009-01-22 14:28 005
> 
> I have not seen the plus sign being used before.

That + sign means ACLs have been set on the file.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Jan 22 22:28:41 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 23:28:41 +0100
Subject: [QA] To clone or not to clone ( a bug
	report	)	that's	the	question...
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>
	<49787499.7000906@hi.is> <gl9t6g$dis$1@ger.gmane.org>
	<4978897D.4020201@hi.is>
Message-ID: <glarup$thj$2@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> Testers need training guidelines and policies to work by, a proper "work
> flow" and if the responses to every matter are going to be like this one I
> simply cut out the inefficient process.

The "inefficient process" is required to achieve a solution which actually
SATISFIES everybody rather than somebody's arbitrary decision.

> I will write those guidelines policy and provide testers with a decent
> work flow.

With what authority?

> Anyone that opposes anything in that guideline can than pick out
> questionable issues , make them to a topic on this list or ask FESCo to
> address those issue(s) in their meetings.

In fact I ask this to be escalated to FESCo right NOW and to get a clear
statement that you aren't allowed to unilaterally decide on a policy for
the entire project. This is not Gu?mundssonix, it's Fedora!

> There will be no time "pressure" matter since the guideline has already
> been written and made

With what authority?

        Kevin Kofler



From kevin.kofler at chello.at  Thu Jan 22 22:37:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 22 Jan 2009 23:37:36 +0100
Subject: F10 and no root login - impossible to maintain systems!
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
Message-ID: <glasfg$thj$3@ger.gmane.org>

Shawn Starr wrote:
> I'm going to jump into this flamefest, Can we STOP with the "Mother knows
> best" menality in Fedora? I have needed to log in as root with X a few
> times.     Stop turning Fedora into a 'Ubuntu'.

+1

The funny thing is, the GDM config file even used to say in a comment that
anybody who disables root login "should be shot". That was back when GDM
actually had this as a config option, rather than the current PAM hack
which makes root login fail with a confusing error message because GDM
doesn't even understand what's going on. (The GDM rewrite dropped the old
option.)

        Kevin Kofler



From mmcgrath at redhat.com  Thu Jan 22 22:58:01 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Thu, 22 Jan 2009 16:58:01 -0600 (CST)
Subject: updating statistics
In-Reply-To: <20090122185547.GA8470@localhost>
References: <20090122170354.GA1800@localhost>
	<1232648479.3802.93.camel@rosebud>
	<20090122185547.GA8470@localhost>
Message-ID: <alpine.LFD.2.00.0901221657300.22477@laptop.mmcgrath.net>

On Thu, 22 Jan 2009, Miroslav Lichvar wrote:

> On Thu, Jan 22, 2009 at 01:21:19PM -0500, seth vidal wrote:
> > On Thu, 2009-01-22 at 18:03 +0100, Miroslav Lichvar wrote:
> > > I was wondering, do we have any data that show how often are Fedora
> > > users pulling updates? There was an information about how many unique
> > > IP addresses hit Fedora mirrors, this had to come from somewhere.
> > >
> > > The reason I'm asking is that one of my updates hit a yum bug. How
> > > long after fixed yum is pushed to stable should I wait if I wanted
> > > to have it updated on say 90 % of the machines?
> > >
> >
> > What yum bug is this?
>
> #472756
>

Not sure, one way to do it is to ensure that yum is sending its version as
part of the user agent when it hits our servers.  At that point we can
easily grep and say "k, looks like 90% of our users have updated"

	-Mike



From lyos.gemininorezel at gmail.com  Thu Jan 22 23:36:32 2009
From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel)
Date: Thu, 22 Jan 2009 18:36:32 -0500
Subject: Root Logins in X...
In-Reply-To: <1232637559.3807.20.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>
	<gla1d0$tg0$1@ger.gmane.org>	<1232637045.13042.30.camel@nibbler.dlib.indiana.edu>
	<1232637559.3807.20.camel@localhost.localdomain>
Message-ID: <49790300.3030301@gmail.com>

Tom "spot" Callaway wrote:

[out of order quote]

I'm more inclined to put a safety on the gun than to unload it entirely.
[/quote]

I agree 100%... however...


> A few more ideas, off the top of my head:
>
> A "Rescue Mode" in GDM which goes to a root session with minimal apps,
> marked as "Rescue Mode", rather than a root X login (even though it does
> need root credentials).
>
> A prompt upon the first time a user tried to login to a normal X session
> via GDM as root (separate from the "Rescue Mode"), warning them of the
> risk they're taking, with a small checkbox that says something like
> "never show me this warning again".
>   

I disagree with this (as well as Warren's idea).
Why add additional software to the (already) horribly bloated default 
install?
A simple warning like you already mentioned would be great...
but, I say, the root login should use the user selected interface 
(gnome, kde, xfce, etc).

A safety is fine (the warning dialog)... but unnecessarily crippling the 
root gui
interface is a foolish move.

> ~spot
>   

Lyos Gemini Norezel



From johannbg at hi.is  Thu Jan 22 23:41:36 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Thu, 22 Jan 2009 23:41:36 +0000
Subject: [QA] To clone or not to clone ( a
	bug	report	)	that's	the	question...
In-Reply-To: <glarup$thj$2@ger.gmane.org>
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>	<49787499.7000906@hi.is>
	<gl9t6g$dis$1@ger.gmane.org>	<4978897D.4020201@hi.is>
	<glarup$thj$2@ger.gmane.org>
Message-ID: <49790430.2010607@hi.is>

Kevin Kofler wrote:
> "J?hann B. Gu?mundsson" wrote:
>   
>> Testers need training guidelines and policies to work by, a proper "work
>> flow" and if the responses to every matter are going to be like this one I
>> simply cut out the inefficient process.
>>     
>
> The "inefficient process" is required to achieve a solution which actually
> SATISFIES everybody rather than somebody's arbitrary decision.
>
>   
A solution to this has been proposed and been added here 
https://fedorahosted.org/fedora-qa/ticket/5
>> I will write those guidelines policy and provide testers with a decent
>> work flow.
>>     
>
> With what authority?
>   

With mine and QA authority and let's time I checked I had the free will 
to write whatever I felt like
under my space on the wiki which I have I done ..

For example the new QA wiki page this as been approved on the QA meeting.

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA

Here's a suggestion for components layout on the QA Namespace and yes 
this means
that there will be a similar page that needs to be created for each 
component in Fedora

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA/file-roller

Here's another one  ( This one waits Haralds approval )

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA/Test_Days/Features/20SecondStartup

Here you can see I layout I suggested for Gnome Desktop

http://fedoraproject.org/wiki/Desktop/Testing

And more on the way..

We might even rewrite things to be coming more closer to what's being 
done on ltp.sf.net

>   
>> Anyone that opposes anything in that guideline can than pick out
>> questionable issues , make them to a topic on this list or ask FESCo to
>> address those issue(s) in their meetings.
>>     
>
> In fact I ask this to be escalated to FESCo right NOW and to get a clear
> statement that you aren't allowed to unilaterally decide on a policy for
> the entire project. This is not Gu?mundssonix, it's Fedora!
>
>   

Since when did I say that that I was Fedora?

>> There will be no time "pressure" matter since the guideline has already
>> been written and made
>>     
>
> With what authority?
>
>   
See above.

Dont worry you can bother yourself with writing your own proper 
testing/test pages for your own components.

Looking forward to see them.

JBG



From mw_triad at users.sourceforge.net  Thu Jan 22 23:53:30 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Thu, 22 Jan 2009 17:53:30 -0600
Subject: Root Logins in X...
In-Reply-To: <49790300.3030301@gmail.com>
References: <49781C9C.4000007@redhat.com>	<gla1d0$tg0$1@ger.gmane.org>	<1232637045.13042.30.camel@nibbler.dlib.indiana.edu>	<1232637559.3807.20.camel@localhost.localdomain>
	<49790300.3030301@gmail.com>
Message-ID: <glb0tq$fdp$1@ger.gmane.org>

Lyos Gemini Norezel wrote:
> A safety is fine (the warning dialog)... but unnecessarily crippling the 
> root gui interface is a foolish move.

I disagree. Starting a minimal DE is fewer applications that might have 
exploitable bugs. I therefore claim that we would not be doing so 
"unnecessarily".

(It's also less maintenance work than trying to make something that 
works for all DE's that we ship. You either have to change the DE 
startup, or the DM, and in both cases that's more than one target. 
Though you might have to change all the DM's regardless, since shipping 
/root/.xinitrc may not be the best strategy ;-).)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Who let the hippos out?



From kevin.kofler at chello.at  Fri Jan 23 00:10:49 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Jan 2009 01:10:49 +0100
Subject: [QA] To clone or not to clone ( a
	bug	report	)	that's	the	question...
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>	<49787499.7000906@hi.is>
	<gl9t6g$dis$1@ger.gmane.org>	<4978897D.4020201@hi.is>
	<glarup$thj$2@ger.gmane.org> <49790430.2010607@hi.is>
Message-ID: <glb1u9$hou$1@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> Dont worry you can bother yourself with writing your own proper
> testing/test pages for your own components.
> 
> Looking forward to see them.

I just proposed a competing arbitrary policy in your QA ticket:
https://fedorahosted.org/fedora-qa/ticket/5

It's easy to write up an arbitrary policy without asking anyone, even easier
to copy somebody else's as you did (and while this does mean at least 2
people are supporting the policy, that's not a consensus). But that's not
how decisions are made in a community project.

        Kevin Kofler



From johannbg at hi.is  Fri Jan 23 00:40:32 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Fri, 23 Jan 2009 00:40:32 +0000
Subject: [QA] To clone or not to clone (
	a	bug	report	)	that's	the	question...
In-Reply-To: <glb1u9$hou$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>	<49787499.7000906@hi.is>	<gl9t6g$dis$1@ger.gmane.org>	<4978897D.4020201@hi.is>	<glarup$thj$2@ger.gmane.org>
	<49790430.2010607@hi.is> <glb1u9$hou$1@ger.gmane.org>
Message-ID: <49791200.9040108@hi.is>

Kevin Kofler wrote:
> "J?hann B. Gu?mundsson" wrote:
>   
>> Dont worry you can bother yourself with writing your own proper
>> testing/test pages for your own components.
>>
>> Looking forward to see them.
>>     
>
> I just proposed a competing arbitrary policy in your QA ticket:
> https://fedorahosted.org/fedora-qa/ticket/5
>
> It's easy to write up an arbitrary policy without asking anyone, even easier
> to copy somebody else's as you did (and while this does mean at least 2
> people are supporting the policy, that's not a consensus). But that's not
> how decisions are made in a community project.
>
>         Kevin Kofler
>
>   
Please dont mix testers with triagers these are 2 separated teams.

It would be good if you could spend some time of your writing energy
writing testing/ test cases for your components and how you would like
testers to report to components that you maintain.

And of course I copied Mark suggestion it's a dam good one but that does 
not mean
that it will be the one that makes into the final chapter.

And so far I have not published anything without it being approved 
first  either on a QA meeting
or by the maintainer giving his blessing on testing/test cases that it's 
like he wants it.

And I offer my service to those maintainers that dont have the time to 
write theirs and gladly accept my
aid in that matter.

JBG



From jkeating at redhat.com  Fri Jan 23 00:48:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 22 Jan 2009 16:48:55 -0800
Subject: Alpha freeze refresh on Tuesday?
Message-ID: <1232671735.8363.8.camel@localhost.localdomain>

So we're actually in a better place for alpha than I thought we'd be.
Installer, which we care most about for Alpha, is in a good place and
working well, for the most part.  There are a couple lingering issues,
some with work arounds, some without (ppc) but if we wanted to, we could
take the current frozen content and produce the bits for Alpha.  Only
our release date is a week from Tuesday, which would put Alpha a bit
long in the tooth.

Since we've got installer where we want it, and rawhide itself isn't too
terrible (minus the sqlite issue today), I'm considering a refresh of
the alpha tag on Tuesday and making the Alpha from that content.  This
of course depends on rawhide not destroying itself in the next few days,
but we can make a judgment call on Tuesday for that.

Thoughts?
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/8c6caddb/attachment.sig>

From josef at toxicpanda.com  Fri Jan 23 01:11:13 2009
From: josef at toxicpanda.com (Josef Bacik)
Date: Thu, 22 Jan 2009 20:11:13 -0500
Subject: Alpha freeze refresh on Tuesday?
In-Reply-To: <1232671735.8363.8.camel@localhost.localdomain>
References: <1232671735.8363.8.camel@localhost.localdomain>
Message-ID: <1b7401870901221711j3e4d474ay4fb7a7b2622b8920@mail.gmail.com>

2009/1/22 Jesse Keating <jkeating at redhat.com>:
> So we're actually in a better place for alpha than I thought we'd be.
> Installer, which we care most about for Alpha, is in a good place and
> working well, for the most part.  There are a couple lingering issues,
> some with work arounds, some without (ppc) but if we wanted to, we could
> take the current frozen content and produce the bits for Alpha.  Only
> our release date is a week from Tuesday, which would put Alpha a bit
> long in the tooth.
>
> Since we've got installer where we want it, and rawhide itself isn't too
> terrible (minus the sqlite issue today), I'm considering a refresh of
> the alpha tag on Tuesday and making the Alpha from that content.  This
> of course depends on rawhide not destroying itself in the next few days,
> but we can make a judgment call on Tuesday for that.
>
> Thoughts?

I would love that personally, it will give me some time to test the
btrfs part of the install to make sure any other random issues are
mostly worked out.  I know its not an important part or anything, but
it would be nice for something thats been advertised to not completely
throw up on an unsuspecting tester.  Thanks,

Josef



From bcrl at kvack.org  Fri Jan 23 01:17:55 2009
From: bcrl at kvack.org (Benjamin LaHaise)
Date: Thu, 22 Jan 2009 20:17:55 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <8kvl46xrac.ln2@ppp1053.in.ipex.cz>
References: <20090121030132.GG19788@kvack.org> <4977D0C2.9090900@redhat.com>
	<20090122032202.GH29367@kvack.org> <4977E6C2.7080905@redhat.com>
	<20090122032512.GJ29367@kvack.org> <4977E795.9030902@redhat.com>
	<20090122032940.GL29367@kvack.org> <4977EA4D.3060908@redhat.com>
	<20090122034558.GM29367@kvack.org>
	<8kvl46xrac.ln2@ppp1053.in.ipex.cz>
Message-ID: <20090123011755.GA10047@kvack.org>

On Thu, Jan 22, 2009 at 11:50:16AM +0100, Matej Cepl wrote:
> Prove yourself wrong yourself -- what happens when you do 
> Ctrl+Alt+F2 in X?

I've known about this trick for more than a decade, and when I try to switch 
to any text console on my F10 installs, nothing occurs -- the system remains 
in X.  The combination of that with no more root logins (which I'm vehemently 
opposed to as I think this nannying of experienced users is against the whole 
Linux experience) and changes to the grub config that make the window to 
catch the boot loader much narrower, my overall impression of Fedora 10 as a 
long time Linux user is very negative.  Firefox keeps losing my bookmarks 
(yes, there's a bug filed for that with mozilla), arrow keys don't work 
correctly in qemu or vmware, metacity crashes on startup 1 in 5 logins, 
suspend doesn't work despite the next generation suspend code being used 
in other distributions that do work, and all my systems have had their nfs 
mounts denied due to another overzealous "security improvement"...

Sure, some of these are simple bugs, but the one that drives me nuts is the 
system denying me the ability to fix it.  The security concerns are 
unreasonable given that Fedora 9 popped up a dialog warning a user when 
logging in as root.  This is a step backwards in usability, not an improvement.

		-ben



From jwboyer at gmail.com  Fri Jan 23 01:29:27 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 22 Jan 2009 20:29:27 -0500
Subject: FESCo Meeting Summary for 2009-01-16
Message-ID: <20090123012927.GC20080@yoda.jdub.homelinux.org>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Kevin Fenzi           (nirik)
* Josh Boyer            (jwb)
* Bill Nottingham       (notting)
* David Woodhouse       (dwmw2) (partly)
* Dennis Gilmore        (dgilmore)
* Jon Stanley           (jds2001)

== Summary ==

=== Features ===

      * FESCo did not feel the ReviewOMatic feature fit the
        criteria of a feature but encouraged it otherwise:
        https://fedoraproject.org/wiki/Features/ReviewOMatic

      * FESCo approved CUPS PolicyKit Integration as a feature:
        https://fedoraproject.org/wiki/Features/CupsPolicyKitIntegration

      * FESCo defered the decision on the Debuginfo Revamp feature
        and requested more information:
        https://fedoraproject.org/wiki/Features/DebugInfoRevamp

      * FESCo approved the EXT4 Default Filesystem feature after much
        debate, with the caveat that it will be reverted if Alpha/Beta
        find too many issues.  I, for one, welcome our new ext4 overlords:
        https://fedoraproject.org/wiki/Features/Ext4DefaultFs

      * FESCo approved the Gnome 2.26 Feature:
        https://fedoraproject.org/wiki/Features/Gnome2_26

      * FESCo declined the Live System on DVD feature on the grounds that
        it was not technically possible due to space constraints on
        everything except i386, had no proposed patches to enable the
        feature, and generally seemed like a wishlist item rather than an
        actual feature request:
        https://fedoraproject.org/wiki/Features/Live_System_for_the_DVD_Image

      * FESCo approved the XFCE 4.6 feature:
        https://fedoraproject.org/wiki/Features/Xfce46

=== FPC Font Package Naming Guidelines ===

      * FESCo had no objections to the FPC proposal:
        https://fedorahosted.org/fesco/ticket/18

=== ovm ===

      * FESCo ruled that ovm was acceptable as long as iverilog (or other
        similar toolsets) get in at the same time.  They realize that those
        tools might not be immediately usable.

=== New Sponsor Requests ===

      * Lubomir Rintel (lkundrak) was approved as a sponsor.

      * Itamar Reis Peixoto was declined as a sponsor on the grounds that he
        has done no reviews.  FESCo encourages him to do some package reviews
        and reapply.

      * Ian Weller was declined as a new sponsor.  FESCo encourages him to
        do some more package reviews and reapply.

      * Kevin Kofler was approved as a sponsor.
       

IRC log can be found at:
http://jwboyer.fedorapeople.org/fesco/fesco-meeting-2009-01-16.txt.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/ab64ca89/attachment.sig>

From jwboyer at gmail.com  Fri Jan 23 01:40:21 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Thu, 22 Jan 2009 20:40:21 -0500
Subject: No F11 Alpha for PowerPC
Message-ID: <20090123014021.GD20080@yoda.jdub.homelinux.org>

Hi All,

Due to some unforeseen circumstances, there will not be an
F11 Alpha release for PowerPC.  Aside from the normal issues
that effect all the architectures, there were two things that
contributed to this being the case:

1) The ppc64 kernels have not booted in quite some time.  This
   is due to yaboot not being able to handle a kernel with
   CONFIG_RELOCATABLE=y being set because of the differences
   that creates in the elf file type.

   I fixed yaboot today and the ppc64 kernel will again at
   least try to boot.  However...

2) While everyone was rejoicing over the upstream merge of
   squashfs into the kernel (myself included), we didn't quite
   realize that squashfs-tools does not work on big-endian
   architectures.  This prevents ananconda from building the
   images needed for daily rawhide boot.isos and the actual
   composed install media.

   This is an upstream problem, and I have emailed them to see
   if there is anything I can do to help.  However given the
   timeframe in question, it is quite unlikely that this will
   be fixed before the Alpha date.  Even if it was, the lack of
   testing since Jan 12 would lead me to hesitate doing an Alpha
   release.

I'll work on this as best I can.  Hopefully by the time Beta
rolls around we'll be back on track.

josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090122/ea1e0ee2/attachment.sig>

From dgboles at comcast.net  Fri Jan 23 03:12:04 2009
From: dgboles at comcast.net (David)
Date: Thu, 22 Jan 2009 22:12:04 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090123011755.GA10047@kvack.org>
References: <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com>	<20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com>	<20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com>	<20090122032940.GL29367@kvack.org>
	<4977EA4D.3060908@redhat.com>	<20090122034558.GM29367@kvack.org>	<8kvl46xrac.ln2@ppp1053.in.ipex.cz>
	<20090123011755.GA10047@kvack.org>
Message-ID: <49793584.3090200@comcast.net>

Benjamin LaHaise wrote:
> On Thu, Jan 22, 2009 at 11:50:16AM +0100, Matej Cepl wrote:
>> Prove yourself wrong yourself -- what happens when you do 
>> Ctrl+Alt+F2 in X?

> I've known about this trick for more than a decade, and when I try to switch 
> to any text console on my F10 installs, nothing occurs -- the system remains 
> in X.  The combination of that with no more root logins (which I'm vehemently 
> opposed to as I think this nannying of experienced users is against the whole 
> Linux experience) and changes to the grub config that make the window to 
> catch the boot loader much narrower, my overall impression of Fedora 10 as a 
> long time Linux user is very negative.  Firefox keeps losing my bookmarks 
> (yes, there's a bug filed for that with mozilla), arrow keys don't work 
> correctly in qemu or vmware, metacity crashes on startup 1 in 5 logins, 
> suspend doesn't work despite the next generation suspend code being used 
> in other distributions that do work, and all my systems have had their nfs 
> mounts denied due to another overzealous "security improvement"...

> Sure, some of these are simple bugs, but the one that drives me nuts is the 
> system denying me the ability to fix it.  The security concerns are 
> unreasonable given that Fedora 9 popped up a dialog warning a user when 
> logging in as root.  This is a step backwards in usability, not an improvement.

> 		-ben



First... I apologize. I don't really relong here. I am not a sys admin,
a developer, nothing special. I am just a long time, ordinary,
interested Linux user. Period. No training. No schooling. Other than my
at home, 'hands on' experience, self taught knowledge.

*I* know how to cold boot to a CLI bootup. *I* know how to boot to a
level 1 emergency (rescue) boot. *I* know how to get out of a user level
5 GUI and drop to a CLI level 3. *I* know how to start a 'root session'
GUI from the level 3 CLI as well as work from the CLI. I know what, and
how, to edit what it takes to permit a GUI root login from the DM. All
with todays Fedora, and other distro's, releases offered.

So the *real* complaint is what here is what? Really? That a stupid ole'
user like me knows how to do what the self proclaimed 'super experts'
don't know how to do? Get real.

So change this to suit your needs and wants. Or, please. Shut the hell
up about this already.

<sigh>
-- 


  David



From kevin.kofler at chello.at  Fri Jan 23 03:38:14 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Jan 2009 04:38:14 +0100
Subject: [QA] To clone or not to clone (
	a	bug	report	)	that's	the	question...
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>	<49787499.7000906@hi.is>	<gl9t6g$dis$1@ger.gmane.org>	<4978897D.4020201@hi.is>	<glarup$thj$2@ger.gmane.org>
	<49790430.2010607@hi.is> <glb1u9$hou$1@ger.gmane.org>
	<49791200.9040108@hi.is>
Message-ID: <glbe36$dpd$1@ger.gmane.org>

"J?hann B. Gu?mundsson" wrote:
> Please dont mix testers with triagers these are 2 separated teams.

But if one of the teams is not expected to clone bugs, then neither is the
other. :-) So this policy is equally relevant to both teams.

And there are activities which are really both testing and triaging, like
retesting if a bug still applies, at least at KDE upstream this is
something the triagers do. Is there already a policy who's responsible for
such activity? If not, I'd suggest you go talking to the triagers about it.
(Right now, I don't see any such retesting going on, so I get the (possibly
mistaken) impression that each team is expecting the other to do it. ;-) )

> It would be good if you could spend some time of your writing energy
> writing testing/ test cases for your components and how you would like
> testers to report to components that you maintain.

If I start writing test cases for KDE, I'll never finish... Canned test
plans just don't work for huge GUI apps with many features, unless you have
a specific feature you want to test (e.g. to verify whether a given bug is
fixed).

> And so far I have not published anything without it being approved
> first  either on a QA meeting
> or by the maintainer giving his blessing on testing/test cases that it's
> like he wants it.

The problem is that the way to handle bug reports is something which affects
packagers and triagers much more than it affects testers. You just file the
bug(s), the packagers and triagers will have to deal with them. So a tester
meeting is a bad place to decide on such a policy.

In addition, a statement like "There will be no time "pressure" matter since
the guideline has already been written and made so debates can be stuck in
infinite loop until the storage space on the mail server fills up.." makes
you sound totalitarian. Maybe I should give you the benefit of the doubt
and assume something got lost in translation?

        Kevin Kofler



From orion at cora.nwra.com  Fri Jan 23 04:31:41 2009
From: orion at cora.nwra.com (Orion Poplawski)
Date: Thu, 22 Jan 2009 21:31:41 -0700 (MST)
Subject: Xorg plans for F10?
Message-ID: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>

Are there any plans to get ati driver 6.10 into F10?  I'm getting pretty
lousy results with 6.9 in F10 on my RV370, but promising results with 6.10
and Xorg server 1.5.99.  It doesn't work with 1.5.3 though it installs
without any rpm/dependency issues.  Anything on the wiki about current
Xorg plans?


-- 
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 arjan at infradead.org  Fri Jan 23 05:06:48 2009
From: arjan at infradead.org (Arjan van de Ven)
Date: Thu, 22 Jan 2009 21:06:48 -0800
Subject: Kernel message
In-Reply-To: <4978CD1E.3080309@gmail.com>
References: <4978CD1E.3080309@gmail.com>
Message-ID: <20090122210648.2f58927a@infradead.org>

On Thu, 22 Jan 2009 17:46:38 -0200
Casimiro de Almeida Barreto <casimiro.barreto at gmail.com> wrote:

> Hello,
> 
> I'm receiving this message:
> 
> [casimiro at terra ~]$  terra kernel: P0 eprtr bv hehl,cucoktrtld(oa
> vns=1819
> 
> Someone knows what's going on? Error in CPU0 ???

you might want to scan for rootkits ;)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From fedora at leemhuis.info  Fri Jan 23 05:49:19 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Fri, 23 Jan 2009 06:49:19 +0100
Subject: Alpha freeze refresh on Tuesday?
In-Reply-To: <1b7401870901221711j3e4d474ay4fb7a7b2622b8920@mail.gmail.com>
References: <1232671735.8363.8.camel@localhost.localdomain>
	<1b7401870901221711j3e4d474ay4fb7a7b2622b8920@mail.gmail.com>
Message-ID: <49795A5F.2050201@leemhuis.info>

On 23.01.2009 02:11, Josef Bacik wrote:
> 2009/1/22 Jesse Keating <jkeating at redhat.com>:
>> So we're actually in a better place for alpha than I thought we'd be.
>> Installer, which we care most about for Alpha, is in a good place and
>> working well, for the most part.  There are a couple lingering issues,
>> some with work arounds, some without (ppc) but if we wanted to, we could
>> take the current frozen content and produce the bits for Alpha.  Only
>> our release date is a week from Tuesday, which would put Alpha a bit
>> long in the tooth.
>>
>> Since we've got installer where we want it, and rawhide itself isn't too
>> terrible (minus the sqlite issue today), I'm considering a refresh of
>> the alpha tag on Tuesday and making the Alpha from that content.  This
>> of course depends on rawhide not destroying itself in the next few days,
>> but we can make a judgment call on Tuesday for that.
> 
> I would love that personally, it will give me some time to test the
> btrfs part of the install to make sure any other random issues are
> mostly worked out.  I know its not an important part or anything, but
> it would be nice for something thats been advertised to not completely
> throw up on an unsuspecting tester.  Thanks,

Would also be nice to get the fix for
https://bugzilla.redhat.com/show_bug.cgi?id=481112
into anaconda to make sure ext4 gets properly tested in the alpha. Fix 
is discussed on anaconda-devel right now, but not applied yet to git 
(and thus not yet in rawhide) afaics.

CU
knurd



From cdahlin at redhat.com  Fri Jan 23 06:00:10 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 23 Jan 2009 01:00:10 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <1232652105.3539.275.camel@localhost.localdomain>
References: <20090121025533.GF19788@kvack.org>	<49768F95.5080800@fedoraproject.org>	<20090122073641.GA6637@hurricane.linuxnetz.de>	<497827DC.7030303@fedoraproject.org>	<6c3f5e6c0901221101q3a7ddfa9le6e051d662da3aaa@mail.gmail.com>
	<1232652105.3539.275.camel@localhost.localdomain>
Message-ID: <49795CEA.30407@redhat.com>

Jesse Keating wrote:
> On Thu, 2009-01-22 at 14:01 -0500, Andrew Parker wrote:
>   
>> On Thu, Jan 22, 2009 at 3:01 AM, Rahul Sundaram
>> <sundaram at fedoraproject.org> wrote:
>>
>>     
>>> Never once have I felt a real need to tell people to get a root X login for
>>> any reason at all.
>>>       
>> What if /home is hosed and they need the network (WIFI) to fix it?
>> How would you get NetworkManager configured from the command line?
>> How would I get that new kernel that resolves the problem?
>>
>> What if /home is hosed, or / and /tmp are full, and system-config-lvm
>> is needed to help fix it?  Or any one of the other splendid GUIs we
>> now have that are an awful lot less error prone than doing something
>> from the command line.
>>
>> Note that I'm not necessarily in favour of allowing root logins on X
>> *by default*, its just that I don't like the argument of "I have
>> never..." being falsely extrapolated to "Nobody will ever ..."
>>     
>
> So create a user with a homedir of /tmp or some rot, that isn't on your
> network mounted /home that you can use for maint tasks.  IE a completely
> local user to use for recovery purposes.
>
>   
More to the point, NetworkManager should be a lot easier to use from the 
command line. Thank you for your suggestion, we are working on it.

And the guis are less error prone? I've always found most of 
system-config-* to be a ghetto.

--CJD



From cdahlin at redhat.com  Fri Jan 23 06:05:21 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Fri, 23 Jan 2009 01:05:21 -0500
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
Message-ID: <49795E21.3060106@redhat.com>

Dr. Diesel wrote:
>
>
> We are about choice, ask the user during install if he/she wants to 
> prevent root logg-ins.
>
We should probably build a kernel in anaconda too, in case they want 
TOMOYO instead of SELinux or feel like reverting the CFS patches.

--CJD



From rawhide at fedoraproject.org  Fri Jan 23 08:06:24 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 23 Jan 2009 08:06:24 +0000 (UTC)
Subject: rawhide report: 20090123 changes
Message-ID: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>

Compose started at Fri Jan 23 06:01:03 UTC 2009

New package jrosetta
        A common base to build a graphical console
Removed package cjkunifonts
Removed package tetex-font-cm-lgc
Updated Packages:

MySQL-python-1.2.2-9.fc11
-------------------------
* Thu Jan 22 17:00:00 2009 Tom Lane <tgl at redhat.com> 1.2.2-9
- Rebuild for mysql 5.1


R-Biobase-2.2.1-1.fc11
----------------------
* Thu Jan 22 17:00:00 2009 pingou <pingoufc4-at-yahoo.fr> 2.2.1-1
- New update

* Thu Nov 20 17:00:00 2008 pingou <pingoufc4-at-yahoo.fr> 2.2.0-2
- Correct the Source0


R-GeneR-2.12.0-1.fc11
---------------------
* Mon Oct 27 18:00:00 2008 pingou <pingou at pingoured.fr> 2.12.0-1
- New version 2.12.0 for R >= 2.8.0


R-affyio-1.10.1-2.fc11
----------------------
* Thu Jan 22 17:00:00 2009 pingou <pingou-at-pingoured.fr> 1.10.1-2
- Typo on the release number

* Thu Jan 22 17:00:00 2009 pingou <pingou-at-pingoured.fr> 1.10.1-1
- Update to newest version


amarok-2.0.1.1-2.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 2.0.1.1-2
- respin (mysql)


apcupsd-3.14.5-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Michal Hlavinka <mhlavink at redhat.com> - 3.14.5-1
- update to 3.14.5


automoc-1.0-0.11.rc3.fc11
-------------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 1.0-0.11.rc3
- automoc4-0.9.88 (1.0-rc3)

* Sat Nov 22 17:00:00 2008 Lorenzo Villani <lvillani at binaryhelix.net> - 1.0-0.10.rc2
- fix package summary and descriptions (as requested by Richard Hughes)
- match cmake minimum required version with the contents of CMakeLists.txt
  (paranoid fix)


avogadro-0.9.0-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Sebastian Dziallas <sebastian at when.com> 0.9.0-1
- update to new release


baekmuk-ttf-fonts-2.2-16.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Caius Chance <cchance at redhat.com> - 2.2-16.fc11
- Resolves: rhbz#477332
- Refined dependencies.


bodhi-0.5.17-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.5.17-1
- Latest upstream bugfix release.


botan-1.8.1-1.fc11
------------------
* Wed Jan 21 17:00:00 2009 Thomas Moschny <thomas.moschny at gmx.de> - 1.8.1-1
- Update to 1.8.1. This is a bugfix release, see
  http://botan.randombit.net/news/releases/1_8_1.html for changes.
- No need to explicitly enable modules that will be enabled by
  configure.pl anyway.


btrfs-progs-0.18-3.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Josef Bacik <josef at toxicpanda.com> 0.18-3
- updated label patch

* Thu Jan 22 17:00:00 2009 Josef Bacik <josef at toxicpanda.com> 0.18-2
- add a patch to handle having /'s in labels


cas-0.13-118.fc11
-----------------

cddlib-094f-7.fc11
------------------
* Fri Nov 28 17:00:00 2008 Conrad Meyer <konrad at tylerc.org> - 094f-7
- Install headers with install -p to save timestamps.
- Install headers to namespaced directory.
- Generate pdf from latex source.


clutter-0.8.6-3.fc11
--------------------

cudd-2.4.1-3.fc11
-----------------
* Thu Jan 22 17:00:00 2009 Jerry James <loganjerry at gmail.com> - 2.4.1-3
- Add patches to address various minor build infelicities
- Build both shared and static libraries
- Install the test binary, nanotrav, and its man page
- Gather documentation from all of the subdirectories


desktop-file-utils-0.15-3.fc11
------------------------------
* Thu Jan 22 17:00:00 2009 Richard Hughes <rhughes at redhat.com> - 0.15-4
- Rename desktop-mime-type.prov to desktop_mime_type.prov and add the tiny
  macros.desktop_mime_type file so that we can trivially patch rpm to enable
  this new functionality.


dictd-1.11.0-2
--------------
* Thu Jan 22 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 1.11.0-2
- add postun script (#225694)
- fix file permissions (defattr)


digikam-0.10.0-0.14.rc1.fc11
----------------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.10-0-0.14.rc1
- digikam-0.10.0-rc1


eigen2-2.0-0.9.beta6.fc11
-------------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.9.beta6
- eigen-2.0-beta6


freeglut-2.4.0-15.fc11
----------------------
* Thu Jan 22 17:00:00 2009 Tomas Smetana <tsmetana at redhat.com> - 2.4.0-15
- fix #481049 - rebuild to pick up %{_isa} provides


freeipmi-0.6.4-2.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Karsten Hopp <karsten at redhat.com> 0.6.4-2
- fix ipmiconsole log directory


gdm-2.25.2-3.fc11
-----------------
* Thu Jan 22 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 1:2.25.2-3
- Open log files for append to make selinux lock down easier


gnomad2-2.9.4-1.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Linus Walleij <triad at df.lth.se> 2.9.4-1
- New upstream, fix Fedora bug 480366


gnome-common-2.24.0-1.fc11
--------------------------
* Wed Jan 21 17:00:00 2009 Toshio Kuratomi <toshio at fedoraproject.org> - 2.24.0-1
- Update to version 2.24.0

* Mon Apr  7 18:00:00 2008 Toshio Kuratomi <toshio at fedoraproject.org> - 2.20.0-1
- Update to version 2.20.0.


gnome-media-2.25.5-1.fc11
-------------------------
* Tue Jan 20 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.5-1
- Update to 2.25.5
- Add work-around for fontconfig crasher


gphoto2-2.4.4-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 2.4.4-1
- update to 2.4.4


httpd-2.2.11-6
--------------
* Thu Jan 22 17:00:00 2009 Joe Orton <jorton at redhat.com> 2.2.11-6
- Require: apr-util-ldap (#471898)
- init script changes: pass pidfile to status(), use status() in
  condrestart (#480602), support try-restart as alias for
  condrestart
- change /etc/httpd/run symlink to have destination /var/run/httpd,
  and restore "run/httpd.conf" as default PidFile (#478688)


kanyremote-5.6.1-1.fc11
-----------------------
* Wed Jan 21 17:00:00 2009 Mikhail Fedotov <anyremote at mail.ru> - 5.6.1-1
- Minor bugfix


kernel-2.6.29-0.45.rc2.git1.fc11
--------------------------------
* Thu Jan 22 17:00:00 2009 Dave Airlie <airlied at redhat.com>
- rebase drm patches - nouveau TODO

* Wed Jan 21 17:00:00 2009 John W. Linville <linville at redhat.com>
- rt2x00: back-port activity LED init patches


koffice-1.9.98.5-2.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.5-2
- respin (mysql)


ksplice-0.9.6-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Jochen Schmitt <Jochen herr-schmitt de> 0.9.6-1
- New upstream release


libdbi-drivers-0.8.3-3.fc11
---------------------------
* Thu Jan 22 17:00:00 2009 Tom Lane <tgl at redhat.com> 0.8.3-3
- Rebuild for mysql 5.1


libedit-2.11-2.20080712cvs.fc11
-------------------------------
* Thu Jan 22 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 2.11-2.20080712cvs
- Add ncurses-devel requires to -devel subpackage (BZ#481252)


libgphoto2-2.4.4-1.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 2.4.4-1
- update to 2.4.4
- many fixes and improvements to Nikon and Canon cameras
- translation updates


libtelepathy-0.3.3-1.fc11
-------------------------

libtirpc-0.1.10-2.fc11
----------------------
* Thu Jan 22 17:00:00 2009 Steve Dickson  <steved at redhat.com> 0.1.10-2
- Header file fixes for C++


lilypond-2.12.1-4.fc11
----------------------
* Thu Jan 22 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.12.1-4
- More font refinements.


mysql-5.1.30-2.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Tom Lane <tgl at redhat.com> 5.1.30-2
- hm, apparently --with-innodb and --with-ndbcluster are still needed
  even though no longer documented ...

* Thu Jan 22 17:00:00 2009 Tom Lane <tgl at redhat.com> 5.1.30-1
- Update to MySQL 5.1.30.  Note that this includes an ABI break for
  libmysqlclient (it's now got .so major version 16).
- This also updates mysql for new openssl build


mysql-connector-odbc-5.1.5r1144-1.fc11
--------------------------------------
* Thu Jan 22 17:00:00 2009 Tom Lane <tgl at redhat.com> 5.1.5r1144-1
- Update to mysql-connector-odbc 5.1.5r1144, to go with MySQL 5.1.x.
  Note the library name has changed from libmyodbc3 to libmyodbc5.


netpbm-10.35.58-3.fc11
----------------------
* Thu Jan 22 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 10.35.58-3
- fix cmuwmtopbm and other utilities by making endianess
  functions work correctly on 64bit systems (#476863)


parted-1.8.8-12.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Joel Granados <jgranado at redhat.com> - 1.8.8.-12
- Avoid the calling of stat for strings that don't begin with the "/" char (#353191).

* Sat Dec 13 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.8.8-11
- fix typo in last patch

* Sat Dec 13 17:00:00 2008 Tom "spot" Callaway <tcallawa at redhat.com> - 1.8.8-10
- enable RAID partition types on sun disklabels for sparc

* Thu Nov  6 17:00:00 2008 Joel Granados <jgranado at redhat.com> - 1.8.8-9
- Fix the build for the s390(x) archs (#470211).


perl-DBD-MySQL-4.005-9.fc11
---------------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.005-9
- respin (mysql)


perl-Date-Simple-3.03-1.fc11
----------------------------
* Thu Jan 22 17:00:00 2009 Paul Howarth <paul at city-fan.org> 3.03-1
- Update to 3.03
- Don't package Artistic license text, not included in upstream release
- New upstream maintainer -> new source URL


perl-IO-Socket-SSL-1.20-1.fc11
------------------------------
* Thu Jan 22 17:00:00 2009 Paul Howarth <paul at city-fan.org> - 1.20-1
- Update to latest upstream version: 1.20


perl-Spreadsheet-ParseExcel-0.4700-1.fc11
-----------------------------------------
* Thu Jan 22 17:00:00 2009 Steven Pritchard <steve at kspei.com> 0.4700-1
- Update to 0.47.


perl-Test-Prereq-1.036-1.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Steven Pritchard <steve at kspei.com> 1.036-1
- Update to 1.036.
- Add some dependencies when building with --with-check.


perl-bioperl-1.5.9-0.5.4.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.5.9-0.5.4
- Update to 1.6.0 release candidate 4


phonon-4.3.0-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.3.0-1
- 4.3.0


php-pear-XML-Parser-1.3.2-1.fc11
--------------------------------
* Thu Jan 22 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> 1.3.2-1
- update to 1.3.2


policycoreutils-2.0.61-6.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-6
- Move sepolgen-ifgen to post python


postfix-2.5.6-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 2:2.5.6-1
- update to 2.5.6 (#479108)
- rebuild /etc/aliases.db only when necessary (#327651)
- convert doc files to UTF-8


postgresql-8.3.5-4.fc11
-----------------------
* Wed Jan 21 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> 8.3.5-4
- use -O1 on sparc64


publican-0.40-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 0.40-1
- Font changes baekmuk-ttf-fonts-batang -> baekmuk-ttf-batang-fonts to
  fix broken deps in rawhide


pygpgme-0.1-11.20090121bzr54.fc11
---------------------------------
* Thu Jan 22 17:00:00 2009 Toshio Kuratomi <toshio at fedoraproject.org> - 0.1-11.20090121bzr54
- Add patch to cvs.

* Wed Jan 21 17:00:00 2009 Toshio Kuratomi <toshio at fedoraproject.org> - 0.1-10.20090121bzr54
- Update to upstream snapshot.


python-decorator-2.3.2-1.fc11
-----------------------------
* Wed Jan 21 17:00:00 2009 Toshio Kuratomi <toshio at fedoraproject.org> - 2.3.2-1
- Update to 2.3.2
- Enable tests via nose


python-gdata-1.2.4-1.fc11
-------------------------
* Thu Jan 22 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 1.2.4-1
- Update to 1.2.4


python-sqlalchemy-0.5.1-1.fc11
------------------------------
* Wed Jan 21 17:00:00 2009 Toshio Kuratomi <toshio at fedoraproject.org> - 0.5.1-1
- Update to 0.5.1.


qt-4.4.3-12.fc11
----------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.4.3-12
- respin (mysql)


qt3-3.3.8b-18.fc11
------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 3.3.8b-18
- respin (mysql)


redland-1.0.7-5.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 1.0.7-5
- respin (mysql)


ruby-RMagick-2.9.0-1.fc11
-------------------------
* Thu Jan 22 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 2.9.0-1
- 2.9.0


scala-2.7.3-1.fc11
------------------
* Wed Jan 21 17:00:00 2009 Geoff Reedy <geoff at programmer-monk.net> - 2.7.3-1
- update to 2.7.3 final


selinux-policy-3.6.3-7.fc11
---------------------------
* Thu Jan 22 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-7
- Remove polgen-ifgen from post and add trigger to policycoreutils-python


setup-2.7.7-1.fc11
------------------
* Thu Jan 22 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2.7.7-1
- synchronize /etc/services with latest IANA, do not use
  tabs in that file to have consistent output
- fix indentation in /etc/profile and /etc/bashrc
  (#481074)
- assign uid 36 for vdsm, gid 36 for kvm
  (#346151,#481021)


smc-fonts-04.1-4.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Rajeesh K Nambiar <rajeeshknambiar at gmail.com> 04.1-4
- change descriptions
- fix bug in kalyani font's obsoleting version number
- move _font_pkg macros next to corresponding packages


sqlite-3.6.10-2.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Panu Matilainen <pmatilai at redhat.com> - 3.6.10-2
- upstream fix yum breakage caused by new keywords (#481189)

* Thu Jan 22 17:00:00 2009 Panu Matilainen <pmatilai at redhat.com> - 3.6.10-1
- update to 3.6.10


tor-0.2.0.33-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Enrico Scholz <enrico.scholz at informatik.tu-chemnitz.de> - 0.2.0.33-1
- updated to 0.2.0.33 (SECURITY: fixed heap-corruption bug)


translate-toolkit-1.3.0-0.1.beta1.fc11
--------------------------------------
* Thu Jan 22 17:00:00 2009 Dwayne Bailey <dwayne at translate.org.za> - 1.3.0-0.1.beta1
- Update to 1.3.0 beta1


util-linux-ng-2.14.2-0.2.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Karel Zak <kzak at redhat.com> 2.14.2-0.2
- fix #480413 - util-linux-ng doesn't include scriptreplay
- fix #479002 - remove dependency on ConsoleKit-libs
- upgrade to 2.14.2-rc2


virtaal-0.3-0.1.beta1.fc11
--------------------------
* Thu Jan 22 17:00:00 2009 Dwayne Bailey <dwayne at translate.org.za> - 0.3-0.1.beta1
- Update for 0.3-beta1 release
- Refresh MO setup patch
- Add version patch to prevent dependency on Translate Toolkit 
  when building


xfce4-settings-4.5.93-2.fc11
----------------------------
* Thu Jan 22 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 4.5.93-2
- Add Obsoletes for mcs packages to make sure xfce4-settings gets installed
- Don't package desktop files twice
- Require xfconf
- Use Nodoka theme and Fedora icons
- Add docs


xfconf-4.5.93-3.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 4.5.93-3
- Let xfce4-settings Obsolete mcs manager and plugin packages

* Thu Jan 22 17:00:00 2009 Christoph Wickert <cwickert at fedoraproject.org> - 4.5.93-2
- Add Obsoletes for mcs devel package


xguest-1.0.6-8.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 1.0.6-8
- Modify xguest to be able to be installed in a livecd


xscreensaver-5.08-5.fc11
------------------------
* Thu Jan 22 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp> - 1:5.08-5
- Fix phosphor segv when changing window size (bug 481146)


yaboot-1.3.14-9.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Josh Boyer <jwboyer at gmail.com> - 1.3.14-9
- Add patch to handle relocatable kernels


Summary:
Added Packages: 1
Removed Packages: 2
Modified Packages: 76
Broken deps for i386
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15
	Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	apr-util-mysql-1.3.4-1.fc10.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	apr-util-mysql-1.3.4-1.fc10.i386 requires libmysqlclient_r.so.15
	bacula-director-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15
	bacula-director-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	bacula-storage-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15
	bacula-storage-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	32:bind-sdb-9.6.0-3.P1.fc11.i386 requires libmysqlclient.so.15
	32:bind-sdb-9.6.0-3.P1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	callweaver-mysql-1.2.0.1-1.2.fc10.i386 requires libmysqlclient.so.15
	callweaver-mysql-1.2.0.1-1.2.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	collectd-mysql-4.5.1-2.fc11.i386 requires libmysqlclient.so.15
	collectd-mysql-4.5.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	cyrus-sasl-sql-2.1.22-19.fc10.i386 requires libmysqlclient.so.15
	cyrus-sasl-sql-2.1.22-19.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	1:dovecot-mysql-1.1.8-2.fc11.i386 requires libmysqlclient.so.15
	1:dovecot-mysql-1.1.8-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.i386 requires libmysqlclient.so.15
	exim-mysql-4.69-8.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.i386 requires libmysqlclient_r.so.15
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gambas2-gb-db-2.10.2-1.fc11.i386 requires libmysqlclient.so.15
	gambas2-gb-db-2.10.2-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gmyth-0.7.1-7.fc10.i386 requires libmysqlclient.so.15
	gmyth-0.7.1-7.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gnokii-smsd-mysql-0.6.27-2.fc10.i386 requires libmysqlclient.so.15
	gnokii-smsd-mysql-0.6.27-2.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	jabberd-2.2.4-1.fc11.i386 requires libmysqlclient.so.15
	jabberd-2.2.4-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	1:libgda-mysql-3.1.2-6.fc10.i386 requires libmysqlclient.so.15
	1:libgda-mysql-3.1.2-6.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	libnss-mysql-1.5-7.fc9.i386 requires libmysqlclient.so.15
	libnss-mysql-1.5-7.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	libpreludedb-mysql-0.9.15.1-2.fc11.i386 requires libmysqlclient.so.15
	libpreludedb-mysql-0.9.15.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.i386 requires libmysqlclient.so.15
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	lua-sql-mysql-2.1.1-4.fc9.i386 requires libmysqlclient.so.15
	lua-sql-mysql-2.1.1-4.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:mod_auth_mysql-3.0.0-6.i386 requires libmysqlclient.so.15
	1:mod_auth_mysql-3.0.0-6.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mysql++-3.0.8-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	mysql++-3.0.8-1.fc11.i386 requires libmysqlclient_r.so.15
	mysql-administrator-5.0r12-9.fc10.i386 requires libmysqlclient_r.so.15
	mysql-administrator-5.0r12-9.fc10.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	mysql-query-browser-5.0r12-9.fc10.i386 requires libmysqlclient_r.so.15
	mysql-query-browser-5.0r12-9.fc10.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nagios-plugins-mysql-1.4.13-12.fc11.i386 requires libmysqlclient.so.15
	nagios-plugins-mysql-1.4.13-12.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15
	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	ntop-3.3.8-1.fc10.i386 requires libmysqlclient_r.so.15
	ntop-3.3.8-1.fc10.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.i386 requires libmysqlclient_r.so.15
	ocaml-mysql-1.0.4-6.fc11.i386 requires libmysqlclient.so.15
	1:openoffice.org-langpack-zh_CN-3.0.1-15.3.fc11.i386 requires cjkunifonts-uming
	1:openoffice.org-langpack-zh_TW-3.0.1-15.3.fc11.i386 requires cjkunifonts-uming
	openser-mysql-1.3.4-1.fc11.i386 requires libmysqlclient.so.15
	openser-mysql-1.3.4-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pam_mysql-0.7-0.6.rc1.fc11.1.i386 requires libmysqlclient.so.15
	1:pam_mysql-0.7-0.6.rc1.fc11.1.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	pdns-backend-mysql-2.9.22-1.rc3.fc11.i386 requires libmysqlclient.so.15
	pdns-backend-mysql-2.9.22-1.rc3.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	php-mysql-5.2.8-2.fc11.i386 requires libmysqlclient.so.15
	php-mysql-5.2.8-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	2:postfix-2.5.6-1.fc11.i386 requires libmysqlclient.so.15
	2:postfix-2.5.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.i386 requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.i386 requires libmysqlclient.so.15
	pure-ftpd-1.0.21-17.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	rsyslog-mysql-3.21.9-2.fc11.i386 requires libmysqlclient.so.15
	rsyslog-mysql-3.21.9-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-mysql-2.7.5-1.fc9.i386 requires libmysqlclient.so.15
	ruby-mysql-2.7.5-1.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ser-mysql-0.9.6-15.fc10.i386 requires libmysqlclient.so.15
	ser-mysql-0.9.6-15.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	snort-bloat-2.8.1-5.fc10.i386 requires libmysqlclient.so.15
	snort-bloat-2.8.1-5.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	snort-mysql-2.8.1-5.fc10.i386 requires libmysqlclient.so.15
	snort-mysql-2.8.1-5.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	snort-mysql+flexresp-2.8.1-5.fc10.i386 requires libmysqlclient.so.15
	snort-mysql+flexresp-2.8.1-5.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11
	totem-mythtv-2.25.3-6.fc11.i386 requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.i386 requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	zabbix-proxy-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15
	zabbix-proxy-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	zabbix-server-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15
	zabbix-server-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	zoneminder-1.23.3-2.fc11.i386 requires libmysqlclient.so.15
	zoneminder-1.23.3-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for x86_64
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	Io-language-mysql-20071010-7.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	apr-util-mysql-1.3.4-1.fc10.x86_64 requires libmysqlclient_r.so.15()(64bit)
	apr-util-mysql-1.3.4-1.fc10.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	bacula-director-mysql-2.4.4-1.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	bacula-director-mysql-2.4.4-1.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	bacula-storage-mysql-2.4.4-1.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	bacula-storage-mysql-2.4.4-1.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	callweaver-mysql-1.2.0.1-1.2.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	callweaver-mysql-1.2.0.1-1.2.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	collectd-mysql-4.5.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	collectd-mysql-4.5.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.i386 requires libmysqlclient.so.15
	cyrus-sasl-sql-2.1.22-19.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	cyrus-sasl-sql-2.1.22-19.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	exim-mysql-4.69-8.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	gambas2-gb-db-2.10.2-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gambas2-gb-db-2.10.2-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gmyth-0.7.1-7.fc10.i386 requires libmysqlclient.so.15
	gmyth-0.7.1-7.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gmyth-0.7.1-7.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	gmyth-0.7.1-7.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gnokii-smsd-mysql-0.6.27-2.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gnokii-smsd-mysql-0.6.27-2.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	jabberd-2.2.4-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	jabberd-2.2.4-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:libgda-mysql-3.1.2-6.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	1:libgda-mysql-3.1.2-6.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libnss-mysql-1.5-7.fc9.i386 requires libmysqlclient.so.15
	libnss-mysql-1.5-7.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	libnss-mysql-1.5-7.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libnss-mysql-1.5-7.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	lua-sql-mysql-2.1.1-4.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lua-sql-mysql-2.1.1-4.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:mod_auth_mysql-3.0.0-6.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:mod_auth_mysql-3.0.0-6.x86_64 requires libmysqlclient.so.15()(64bit)
	mysql++-3.0.8-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	mysql++-3.0.8-1.fc11.i386 requires libmysqlclient_r.so.15
	mysql++-3.0.8-1.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mysql++-3.0.8-1.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	mysql-administrator-5.0r12-9.fc10.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mysql-administrator-5.0r12-9.fc10.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	mysql-query-browser-5.0r12-9.fc10.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mysql-query-browser-5.0r12-9.fc10.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15
	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nekovm-1.8.0-2.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	nekovm-1.8.0-2.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	ntop-3.3.8-1.fc10.x86_64 requires libmysqlclient_r.so.15()(64bit)
	ntop-3.3.8-1.fc10.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	1:openoffice.org-langpack-zh_CN-3.0.1-15.3.fc11.x86_64 requires cjkunifonts-uming
	1:openoffice.org-langpack-zh_TW-3.0.1-15.3.fc11.x86_64 requires cjkunifonts-uming
	openser-mysql-1.3.4-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	openser-mysql-1.3.4-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.i386 requires libmysqlclient.so.15
	1:pam_mysql-0.7-0.6.rc1.fc11.1.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.x86_64 requires libmysqlclient.so.15()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	pdns-backend-mysql-2.9.22-1.rc3.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	pdns-backend-mysql-2.9.22-1.rc3.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	php-mysql-5.2.8-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mysql-5.2.8-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	2:postfix-2.5.6-1.fc11.i386 requires libmysqlclient.so.15
	2:postfix-2.5.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	2:postfix-2.5.6-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	2:postfix-2.5.6-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	pure-ftpd-1.0.21-17.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rsyslog-mysql-3.21.9-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	ruby-mysql-2.7.5-1.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ruby-mysql-2.7.5-1.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ser-mysql-0.9.6-15.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ser-mysql-0.9.6-15.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-bloat-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	snort-bloat-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-mysql-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	snort-mysql-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-mysql+flexresp-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	snort-mysql+flexresp-2.8.1-5.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11
	totem-mythtv-2.25.3-6.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	ulogd-mysql-1.24-9.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
	zabbix-proxy-mysql-1.6.2-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	zabbix-proxy-mysql-1.6.2-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	zabbix-server-mysql-1.6.2-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	zabbix-server-mysql-1.6.2-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)



Broken deps for ppc
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.ppc requires libmysqlclient.so.15
	Io-language-mysql-20071010-7.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	apr-util-mysql-1.3.4-1.fc10.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	apr-util-mysql-1.3.4-1.fc10.ppc requires libmysqlclient_r.so.15
	bacula-director-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15
	bacula-director-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	bacula-storage-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15
	bacula-storage-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc requires libmysqlclient.so.15
	32:bind-sdb-9.6.0-3.P1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	callweaver-mysql-1.2.0.1-1.2.fc10.ppc requires libmysqlclient.so.15
	callweaver-mysql-1.2.0.1-1.2.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.ppc requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	collectd-mysql-4.5.1-2.fc11.ppc requires libmysqlclient.so.15
	collectd-mysql-4.5.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.ppc requires libmysqlclient.so.15
	cyrus-sasl-sql-2.1.22-19.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	cyrus-sasl-sql-2.1.22-19.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:dovecot-mysql-1.1.8-2.fc11.ppc requires libmysqlclient.so.15
	1:dovecot-mysql-1.1.8-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.ppc requires libmysqlclient.so.15
	exim-mysql-4.69-8.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	flow-tools-0.68.4-1.fc9.ppc requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.ppc requires libmysqlclient_r.so.15
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gmyth-0.7.1-7.fc10.ppc requires libmysqlclient.so.15
	gmyth-0.7.1-7.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gmyth-0.7.1-7.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	gmyth-0.7.1-7.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gnokii-smsd-mysql-0.6.27-2.fc10.ppc requires libmysqlclient.so.15
	gnokii-smsd-mysql-0.6.27-2.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	jabberd-2.2.4-1.fc11.ppc requires libmysqlclient.so.15
	jabberd-2.2.4-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	1:libgda-mysql-3.1.2-6.fc10.ppc requires libmysqlclient.so.15
	1:libgda-mysql-3.1.2-6.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	libnss-mysql-1.5-7.fc9.ppc requires libmysqlclient.so.15
	libnss-mysql-1.5-7.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	libnss-mysql-1.5-7.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libnss-mysql-1.5-7.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc requires libmysqlclient.so.15
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc requires libmysqlclient.so.15
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	lua-sql-mysql-2.1.1-4.fc9.ppc requires libmysqlclient.so.15
	lua-sql-mysql-2.1.1-4.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:mod_auth_mysql-3.0.0-6.ppc requires libmysqlclient.so.15
	1:mod_auth_mysql-3.0.0-6.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mysql++-3.0.8-1.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	mysql++-3.0.8-1.fc11.ppc requires libmysqlclient_r.so.15
	mysql++-3.0.8-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mysql++-3.0.8-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	mysql-administrator-5.0r12-9.fc10.ppc requires libmysqlclient_r.so.15
	mysql-administrator-5.0r12-9.fc10.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	mysql-query-browser-5.0r12-9.fc10.ppc requires libmysqlclient_r.so.15
	mysql-query-browser-5.0r12-9.fc10.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc requires libmysqlclient.so.15
	nagios-plugins-mysql-1.4.13-12.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	nekovm-1.8.0-2.fc11.ppc requires libmysqlclient_r.so.15
	nekovm-1.8.0-2.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nekovm-1.8.0-2.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	nekovm-1.8.0-2.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	ntop-3.3.8-1.fc10.ppc requires libmysqlclient_r.so.15
	ntop-3.3.8-1.fc10.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.ppc requires libmysqlclient_r.so.15
	ocaml-mysql-1.0.4-6.fc11.ppc requires libmysqlclient.so.15
	1:openoffice.org-langpack-zh_CN-3.0.1-15.3.fc11.ppc requires cjkunifonts-uming
	1:openoffice.org-langpack-zh_TW-3.0.1-15.3.fc11.ppc requires cjkunifonts-uming
	openser-mysql-1.3.4-1.fc11.ppc requires libmysqlclient.so.15
	openser-mysql-1.3.4-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc requires libmysqlclient.so.15
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc64 requires libmysqlclient.so.15()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	pdns-backend-mysql-2.9.22-1.rc3.fc11.ppc requires libmysqlclient.so.15
	pdns-backend-mysql-2.9.22-1.rc3.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	php-mysql-5.2.8-2.fc11.ppc requires libmysqlclient.so.15
	php-mysql-5.2.8-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	2:postfix-2.5.6-1.fc11.ppc requires libmysqlclient.so.15
	2:postfix-2.5.6-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	2:postfix-2.5.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	2:postfix-2.5.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.ppc requires libmysqlclient.so.15
	pure-ftpd-1.0.21-17.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.ppc requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc requires libmysqlclient.so.15
	rsyslog-mysql-3.21.9-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-mysql-2.7.5-1.fc9.ppc requires libmysqlclient.so.15
	ruby-mysql-2.7.5-1.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ser-mysql-0.9.6-15.fc10.ppc requires libmysqlclient.so.15
	ser-mysql-0.9.6-15.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	snort-bloat-2.8.1-5.fc10.ppc requires libmysqlclient.so.15
	snort-bloat-2.8.1-5.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	snort-mysql-2.8.1-5.fc10.ppc requires libmysqlclient.so.15
	snort-mysql-2.8.1-5.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	snort-mysql+flexresp-2.8.1-5.fc10.ppc requires libmysqlclient.so.15
	snort-mysql+flexresp-2.8.1-5.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11
	totem-mythtv-2.25.3-6.fc11.ppc requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.ppc requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	zabbix-proxy-mysql-1.6.2-1.fc11.ppc requires libmysqlclient.so.15
	zabbix-proxy-mysql-1.6.2-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	zabbix-server-mysql-1.6.2-1.fc11.ppc requires libmysqlclient.so.15
	zabbix-server-mysql-1.6.2-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	zoneminder-1.23.3-2.fc11.ppc requires libmysqlclient.so.15
	zoneminder-1.23.3-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for ppc64
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	Io-language-mysql-20071010-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	apr-util-mysql-1.3.4-1.fc10.ppc64 requires libmysqlclient_r.so.15()(64bit)
	apr-util-mysql-1.3.4-1.fc10.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	bacula-director-mysql-2.4.4-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	bacula-director-mysql-2.4.4-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	bacula-storage-mysql-2.4.4-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	bacula-storage-mysql-2.4.4-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	callweaver-mysql-1.2.0.1-1.2.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	callweaver-mysql-1.2.0.1-1.2.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	collectd-mysql-4.5.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	collectd-mysql-4.5.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cyrus-sasl-sql-2.1.22-19.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	exim-mysql-4.69-8.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gmyth-0.7.1-7.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	gmyth-0.7.1-7.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gnokii-smsd-mysql-0.6.27-2.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gnokii-smsd-mysql-0.6.27-2.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	jabberd-2.2.4-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	jabberd-2.2.4-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:libgda-mysql-3.1.2-6.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	1:libgda-mysql-3.1.2-6.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libnss-mysql-1.5-7.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libnss-mysql-1.5-7.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	lua-sql-mysql-2.1.1-4.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lua-sql-mysql-2.1.1-4.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:mod_auth_mysql-3.0.0-6.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:mod_auth_mysql-3.0.0-6.ppc64 requires libmysqlclient.so.15()(64bit)
	mysql++-3.0.8-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mysql++-3.0.8-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	mysql-administrator-5.0r12-9.fc10.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mysql-administrator-5.0r12-9.fc10.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	mysql-query-browser-5.0r12-9.fc10.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mysql-query-browser-5.0r12-9.fc10.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	nekovm-1.8.0-2.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	nekovm-1.8.0-2.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	ntop-3.3.8-1.fc10.ppc64 requires libmysqlclient_r.so.15()(64bit)
	ntop-3.3.8-1.fc10.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	1:openoffice.org-langpack-zh_CN-3.0.1-15.3.fc11.ppc64 requires cjkunifonts-uming
	1:openoffice.org-langpack-zh_TW-3.0.1-15.3.fc11.ppc64 requires cjkunifonts-uming
	openser-mysql-1.3.4-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	openser-mysql-1.3.4-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:pam_mysql-0.7-0.6.rc1.fc11.1.ppc64 requires libmysqlclient.so.15()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	pdns-backend-mysql-2.9.22-1.rc3.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	pdns-backend-mysql-2.9.22-1.rc3.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	php-mysql-5.2.8-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mysql-5.2.8-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	2:postfix-2.5.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	2:postfix-2.5.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	pure-ftpd-1.0.21-17.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	ruby-mysql-2.7.5-1.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ruby-mysql-2.7.5-1.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ser-mysql-0.9.6-15.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ser-mysql-0.9.6-15.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-bloat-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	snort-bloat-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-mysql-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	snort-mysql-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	snort-mysql+flexresp-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	snort-mysql+flexresp-2.8.1-5.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	tetex-font-kerkis-2.0-16.fc11.noarch requires kerkis-fonts = 0:2.0-16.fc11
	totem-mythtv-2.25.3-6.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	ulogd-mysql-1.24-9.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	zabbix-proxy-mysql-1.6.2-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	zabbix-proxy-mysql-1.6.2-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	zabbix-server-mysql-1.6.2-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	zabbix-server-mysql-1.6.2-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)





From sundaram at fedoraproject.org  Fri Jan 23 08:31:51 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 23 Jan 2009 14:01:51 +0530
Subject: Fedora Alpha release notes - Help required
Message-ID: <49798077.10705@fedoraproject.org>

Hi,

As usual. we need a single page release notes for Fedora 11 Alpha.
Edit the following page and fill in the notes for major new features, 
known bugs and things that need more explicit testing.

https://fedoraproject.org/w/index.php?title=Fedora_11_Alpha_release_notes&action=edit&redlink=1

Add link to https://fedoraproject.org/wiki/Releases/11/FeatureList and 
release schedule.

[ To get started, here are some notes]

* Ext4 has been a experimentally supported option from Fedora 9 release 
and is now the default filesystem for the Fedora 11 Alpha release.  List 
of new features at

http://kernelnewbies.org/Ext4

FS shrink is not supported yet but planned to be made available by 
Fedora 11 release. Backup data for safety

* Btrfs (link to http://btrfs.wiki.kernel.org/index.php/Main_Page), the 
next generation filessytem is a experimentally supported option in this 
release. To enable it within the installer, pass "icantbelieveitsnotbtr" 
in the installation boot prompt.

Screenshot and reference at

http://www.heise-online.co.uk/news/Ext4-to-be-standard-for-Fedora-11-Btrfs-also-included--/112467

More testing and feedback is requested.  Backup data for safety.

* <add info on Mingw - level of support, list of packages etc>

* GNOME 2.26 development snapshot is part of the release and is the 
default environment in the Fedora Desktop Edition (installable live cd). 
<add more info>

* KDE 4.2 RC2 is part of this release and is the default environment in 
the Fedora KDE Desktop Edition (installable live cd).  <add more info 
including the new volume control and provide a screenshot>

* A major new release of Xfce, Xfce 4.6 beta is available in the 
repository and is the default environment in the Fedora Xfce Spin 
(installable live cd)


* Python 2.6 has been integrated into the release and all the software 
in the distribution has been made compatible with it. This effort will 
help lead the way to Python 3.0, a major release with some 
incompatibilities.

[ Do add information on any major changes in PackageKit, Plymouth ..]

Rahul



From sundaram at fedoraproject.org  Fri Jan 23 08:40:18 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 23 Jan 2009 14:10:18 +0530
Subject: rawhide report: 20090123 changes
In-Reply-To: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
Message-ID: <49798272.9000807@fedoraproject.org>

Rawhide Report wrote:

> 
> xguest-1.0.6-8.fc11
> -------------------
> * Thu Jan 22 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 1.0.6-8
> - Modify xguest to be able to be installed in a livecd

Is it going to be available in the Alpha live cd as default?  How much 
work is needed to enable it on other display managers besides GDM?

[only slightly related, is the C rewrite of SELinux troubleshooter, 
going to be available in the alpha release as well?]

Rahul



From markmc at redhat.com  Fri Jan 23 09:07:32 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Fri, 23 Jan 2009 09:07:32 +0000
Subject: [QA] To clone or not to clone ( a	bug	report	)	that's	the
 question...
In-Reply-To: <glbe36$dpd$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>
	<49787499.7000906@hi.is>	<gl9t6g$dis$1@ger.gmane.org>
	<4978897D.4020201@hi.is>	<glarup$thj$2@ger.gmane.org>
	<49790430.2010607@hi.is> <glb1u9$hou$1@ger.gmane.org>
	<49791200.9040108@hi.is>  <glbe36$dpd$1@ger.gmane.org>
Message-ID: <1232701652.5115.54.camel@blaa>

On Fri, 2009-01-23 at 04:38 +0100, Kevin Kofler wrote:

> Maybe I should give you the benefit of the doubt and assume something
> got lost in translation?

That's always a good idea :-)

GNOME's "code of conduct" spells out some common sense that can be easy
to forget in the middle of a debate:

  http://live.gnome.org/CodeOfConduct

  Be respectful and considerate: 
    Disagreement is no excuse for poor behaviour or personal attacks.
    Remember that a community where people feel uncomfortable is not a
    productive one.

  Be patient and generous: 
    If someone asks for help it is because they need it. Do politely
    suggest specific documentation or more appropriate venues where
    appropriate, but avoid aggressive or vague responses such as
    "RTFM". 

  Assume people mean well: 
    Remember that decisions are often a difficult choice between
    competing priorities. If you disagree, please do so politely. If
    something seems outrageous, check that you did not misinterpret it.
    Ask for clarification, but do not assume the worst.

  Try to be concise: 
    Avoid repeating what has been said already. Making a conversation
    larger makes it difficult to follow, and people often feel
    personally attacked if they receive multiple messages telling them
    the same thing. 

(Not suggesting that we need to go through this process of writing a
code, debating it endlessly and getting people to sign up for it - but
it is a nice set of guidelines)

Cheers,
Mark.



From debarshi.ray at gmail.com  Fri Jan 23 09:42:39 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Fri, 23 Jan 2009 15:12:39 +0530
Subject: The move to libgda 4.0
In-Reply-To: <4970BD27.3070308@poolshark.org>
References: <497065D0.5090506@poolshark.org> <49706990.1020200@hhs.nl>
	<4970BD27.3070308@poolshark.org>
Message-ID: <3170f42f0901230142h6a93f896r1e8368cda411bab3@mail.gmail.com>

So what is the latest situation? Sorry for being irritating, but I am
just itching to build Anjuta 2.25.x for Rawhide as soon as possible.
:-)

Cheers,
Debarshi



From rjones at redhat.com  Fri Jan 23 09:55:33 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 23 Jan 2009 09:55:33 +0000
Subject: rawhide report: 20090123 changes
In-Reply-To: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
Message-ID: <20090123095533.GA18665@amd.home.annexia.org>

On Fri, Jan 23, 2009 at 08:06:24AM +0000, Rawhide Report wrote:
> 	collectd-mysql-4.5.1-2.fc11.i386 requires libmysqlclient.so.15
> 	collectd-mysql-4.5.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)

Done,

> 	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15
> 	nekovm-1.8.0-2.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)

done, and

> 	ocaml-mysql-1.0.4-6.fc11.i386 requires libmysqlclient.so.15

done.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rjones at redhat.com  Fri Jan 23 10:11:16 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 23 Jan 2009 10:11:16 +0000
Subject: Fedora Alpha release notes - Help required
In-Reply-To: <49798077.10705@fedoraproject.org>
References: <49798077.10705@fedoraproject.org>
Message-ID: <20090123101116.GB18665@amd.home.annexia.org>

On Fri, Jan 23, 2009 at 02:01:51PM +0530, Rahul Sundaram wrote:
> Hi,
>
> As usual. we need a single page release notes for Fedora 11 Alpha.
> Edit the following page and fill in the notes for major new features,  
> known bugs and things that need more explicit testing.
>
> https://fedoraproject.org/w/index.php?title=Fedora_11_Alpha_release_notes&action=edit&redlink=1

Not sure if you intended anyone to create that page, but I have gone
and done it, and added notes about the Windows cross-compiler feature.

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  Fri Jan 23 10:12:10 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Fri, 23 Jan 2009 10:12:10 +0000
Subject: Fedora Alpha release notes - Help required
In-Reply-To: <20090123101116.GB18665@amd.home.annexia.org>
References: <49798077.10705@fedoraproject.org>
	<20090123101116.GB18665@amd.home.annexia.org>
Message-ID: <20090123101210.GA18796@amd.home.annexia.org>

This page, I mean:

https://fedoraproject.org/wiki/Fedora_11_Alpha_release_notes

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From denis at poolshark.org  Fri Jan 23 10:30:44 2009
From: denis at poolshark.org (Denis Leroy)
Date: Fri, 23 Jan 2009 11:30:44 +0100
Subject: The move to libgda 4.0
In-Reply-To: <3170f42f0901230142h6a93f896r1e8368cda411bab3@mail.gmail.com>
References: <497065D0.5090506@poolshark.org>
	<49706990.1020200@hhs.nl>	<4970BD27.3070308@poolshark.org>
	<3170f42f0901230142h6a93f896r1e8368cda411bab3@mail.gmail.com>
Message-ID: <49799C54.1040806@poolshark.org>

Debarshi Ray wrote:
> So what is the latest situation? Sorry for being irritating, but I am
> just itching to build Anjuta 2.25.x for Rawhide as soon as possible.
> :-)
>

Let me push the builds this afternoon. There is still one open issue wrt 
gnumeric: its plugin also depends on libgnomedb. Instead of creating 
'compat-libgnomedb', I'd rather disable the plugin for now and work on a 
port to the 4.0 API at some point. Huzaifa, is that ok with you ?

-denis



From sundaram at fedoraproject.org  Fri Jan 23 11:08:12 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 23 Jan 2009 16:38:12 +0530
Subject: Fedora Alpha release notes - Help required
In-Reply-To: <20090123101116.GB18665@amd.home.annexia.org>
References: <49798077.10705@fedoraproject.org>
	<20090123101116.GB18665@amd.home.annexia.org>
Message-ID: <4979A51C.3000603@fedoraproject.org>

Richard W.M. Jones wrote:
> On Fri, Jan 23, 2009 at 02:01:51PM +0530, Rahul Sundaram wrote:
>> Hi,
>>
>> As usual. we need a single page release notes for Fedora 11 Alpha.
>> Edit the following page and fill in the notes for major new features,  
>> known bugs and things that need more explicit testing.
>>
>> https://fedoraproject.org/w/index.php?title=Fedora_11_Alpha_release_notes&action=edit&redlink=1
> 
> Not sure if you intended anyone to create that page, but I have gone
> and done it, and added notes about the Windows cross-compiler feature

Yes, thank you.

Rahul





From johannbg at hi.is  Fri Jan 23 12:51:17 2009
From: johannbg at hi.is (=?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=)
Date: Fri, 23 Jan 2009 12:51:17 +0000
Subject: [QA] To clone or not to clone
	(	a	bug	report	)	that's	the	question...
In-Reply-To: <glbe36$dpd$1@ger.gmane.org>
References: <497797C8.1050209@hi.is>	<497852D8.7030902@ioa.s.u-tokyo.ac.jp>	<49786553.3070805@hi.is>	<gl9qcs$3av$1@ger.gmane.org>	<49787499.7000906@hi.is>	<gl9t6g$dis$1@ger.gmane.org>	<4978897D.4020201@hi.is>	<glarup$thj$2@ger.gmane.org>	<49790430.2010607@hi.is>
	<glb1u9$hou$1@ger.gmane.org>	<49791200.9040108@hi.is>
	<glbe36$dpd$1@ger.gmane.org>
Message-ID: <4979BD45.8040808@hi.is>

Kevin Kofler wrote:
> "J?hann B. Gu?mundsson" wrote:
>   
>> Please dont mix testers with triagers these are 2 separated teams.
>>     
>
> But if one of the teams is not expected to clone bugs, then neither is the
> other. :-) So this policy is equally relevant to both teams.
>
>   
There are exceptions to every rule :)

But indeed in most cases the same applies and from my perspective
more to testers than to triagers.

Testers need to report as correctly and add correct attachments and so
on from the start.

If that goal is accomplished it should really take load off both
triagers and maintainers.

But to reach that goal we need documentation, train testers.

We need test cases and above all what the maintainer wants on a reports 
against his component.

Unfortunately we have little to nothing on the above :(

I and others are trying to address that issue.

> And there are activities which are really both testing and triaging, like
> retesting if a bug still applies, at least at KDE upstream this is
> something the triagers do. Is there already a policy who's responsible for
> such activity? If not, I'd suggest you go talking to the triagers about it.
> (Right now, I don't see any such retesting going on, so I get the (possibly
> mistaken) impression that each team is expecting the other to do it. ;-) )
>
>   
Retesting from my perspective should be in the hand of A) the reporter 
and B) Testers

If maintainers need testing send a mail to the test-list.

If you need test cases or help setting up or anything else from QA
open a ticket in the new fedora-qa trac instance on fedorahosted.

>> It would be good if you could spend some time of your writing energy
>> writing testing/ test cases for your components and how you would like
>> testers to report to components that you maintain.
>>     
>
> If I start writing test cases for KDE, I'll never finish... Canned test
> plans just don't work for huge GUI apps with many features, unless you have
> a specific feature you want to test (e.g. to verify whether a given bug is
> fixed).
>
>   
I disagree I think this is doable, we need to come up with template for 
the most common
nominators in the gui app ( open new save help etc..  ) then just add 
test cases for those
that are not.
>> And so far I have not published anything without it being approved
>> first  either on a QA meeting
>> or by the maintainer giving his blessing on testing/test cases that it's
>> like he wants it.
>>     
>
> The problem is that the way to handle bug reports is something which affects
> packagers and triagers much more than it affects testers. You just file the
> bug(s), the packagers and triagers will have to deal with them. So a tester
> meeting is a bad place to decide on such a policy.
>
>   
Again if the report does this properly from start the need of triaging 
should be to minimum.
> In addition, a statement like "There will be no time "pressure" matter since
> the guideline has already been written and made so debates can be stuck in
> infinite loop until the storage space on the mail server fills up.." makes
> you sound totalitarian. Maybe I should give you the benefit of the doubt
> and assume something got lost in translation?
>   
My good man your not asking the right question and you don't get answers 
to question you don't ask.

You should be asking me why do I feel that the -devel list is an
inefficient way to use for communication/intellect discussion 
invention's and finally a decision making.

I'll try to be more subtle this time and explain in more detail what I 
mean..

I feel that way because a lot of topics here are..

A) The same ones over and over again and finally when things have settle 
down we make a release and
     since there was no solution found or that solution/decision not 
properly documented and put on a page on the wiki
     the whole thing starts again.

B) A lot of topic start as A but end up as Y or Z so the original topic 
got lost and the answer to
     that topic still remains unresolved..
     ( that's why you saw me being so harsh I sensed it start heading in 
that direction )

C)  A lot of great ideas ( and not so great ) come up on this list are 
we documenting them
      For example are we putting them on think tank page on the wiki? 
      So they can be revisited when time or manpower are in place to 
work on some of those ideas
      I believe we are not doing it and I feel that they just get lost 
and buried in the paper flood.

D) Allot of the discussion that happens here are without people 
proposing alternative solution a different approach
     to the task at hand but instead you see people start taking sides 
and the debate continues and the task at stays stale.
     ( And in this case Mark did come with an alternative answer to the 
questions being asked and so did you later in the game )

D) A lot of topic here do no belong on this list and should redirected 
to their appropriate mailing lists
     Redirect end users topic to their list, test related topics to the 
test list etc..

And the answer to all this boils down to things being as they are 
because we allowed them to be.

Instead of redirect traffic to they appropriate mailing list...
Instead of taking notes when good solution come..
Instead of when the same topic reappear the person that brought up that 
topic is redirect to the place that holds the final solution that was 
found..
.....
....

So my question is..

Are we doing any stats on the traffic on this mailing list as in how 
many threads are constructive and how many reach final decision vs
how many end up in "my side is better than yours" and traffic that 
should be else where etc.. ?

So the conclusion that I have come to regarding this mailing list can be 
proven wrong...

JBG


-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 372 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/d5d9a16f/attachment.vcf>

From jeff at ocjtech.us  Fri Jan 23 13:36:01 2009
From: jeff at ocjtech.us (Jeffrey Ollie)
Date: Fri, 23 Jan 2009 07:36:01 -0600
Subject: rawhide report: 20090123 changes
In-Reply-To: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
Message-ID: <935ead450901230536i3ed34f65n7a3bdf7500bc9f6f@mail.gmail.com>

On Fri, Jan 23, 2009 at 2:06 AM, Rawhide Report
<rawhide at fedoraproject.org> wrote:
>
>        callweaver-mysql-1.2.0.1-1.2.fc10.i386 requires libmysqlclient.so.15
>        callweaver-mysql-1.2.0.1-1.2.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)

Done.

>        zabbix-proxy-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15
>        zabbix-proxy-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
>        zabbix-server-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15
>        zabbix-server-mysql-1.6.2-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)

Done.

-- 
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

	-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"



From limb at jcomserv.net  Fri Jan 23 13:37:34 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 23 Jan 2009 07:37:34 -0600 (CST)
Subject: Alpha freeze refresh on Tuesday?
In-Reply-To: <1232671735.8363.8.camel@localhost.localdomain>
References: <1232671735.8363.8.camel@localhost.localdomain>
Message-ID: <9067dbf21daff570f2dabfdb1575a67d.squirrel@mail.jcomserv.net>


> So we're actually in a better place for alpha than I thought we'd be.
> Installer, which we care most about for Alpha, is in a good place and
> working well, for the most part.  There are a couple lingering issues,
> some with work arounds, some without (ppc) but if we wanted to, we could
> take the current frozen content and produce the bits for Alpha.  Only
> our release date is a week from Tuesday, which would put Alpha a bit
> long in the tooth.
>
> Since we've got installer where we want it, and rawhide itself isn't too
> terrible (minus the sqlite issue today), I'm considering a refresh of
> the alpha tag on Tuesday and making the Alpha from that content.  This
> of course depends on rawhide not destroying itself in the next few days,
> but we can make a judgment call on Tuesday for that.

If most of the libgda and mysql rebuild get done, I think that'd be great.

> Thoughts?
> --
> Jesse Keating
> Fedora -- Freedom?? is a feature!
> identi.ca: http://identi.ca/jkeating
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From limb at jcomserv.net  Fri Jan 23 13:38:53 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 23 Jan 2009 07:38:53 -0600 (CST)
Subject: Broken dependencies: bacula
In-Reply-To: <20090123074001.0B4031F829C@releng2.fedora.phx.redhat.com>
References: <20090123074001.0B4031F829C@releng2.fedora.phx.redhat.com>
Message-ID: <e2e8eca33ba6719027fd4f9e5804b251.squirrel@mail.jcomserv.net>

Rebuilt.
>
>
> bacula has broken dependencies in the development tree:
> On ppc:
> 	bacula-storage-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15
> 	bacula-storage-mysql-2.4.4-1.fc11.ppc requires
> libmysqlclient_r.so.15(libmysqlclient_15)
> On x86_64:
> 	bacula-storage-mysql-2.4.4-1.fc11.x86_64 requires
> libmysqlclient_r.so.15()(64bit)
> 	bacula-storage-mysql-2.4.4-1.fc11.x86_64 requires
> libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
> On i386:
> 	bacula-storage-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15
> 	bacula-storage-mysql-2.4.4-1.fc11.i386 requires
> libmysqlclient_r.so.15(libmysqlclient_15)
> On ppc64:
> 	bacula-storage-mysql-2.4.4-1.fc11.ppc64 requires
> libmysqlclient_r.so.15()(64bit)
> 	bacula-storage-mysql-2.4.4-1.fc11.ppc64 requires
> libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
> On ppc:
> 	bacula-director-mysql-2.4.4-1.fc11.ppc requires libmysqlclient_r.so.15
> 	bacula-director-mysql-2.4.4-1.fc11.ppc requires
> libmysqlclient_r.so.15(libmysqlclient_15)
> On x86_64:
> 	bacula-director-mysql-2.4.4-1.fc11.x86_64 requires
> libmysqlclient_r.so.15()(64bit)
> 	bacula-director-mysql-2.4.4-1.fc11.x86_64 requires
> libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
> On i386:
> 	bacula-director-mysql-2.4.4-1.fc11.i386 requires libmysqlclient_r.so.15
> 	bacula-director-mysql-2.4.4-1.fc11.i386 requires
> libmysqlclient_r.so.15(libmysqlclient_15)
> On ppc64:
> 	bacula-director-mysql-2.4.4-1.fc11.ppc64 requires
> libmysqlclient_r.so.15()(64bit)
> 	bacula-director-mysql-2.4.4-1.fc11.ppc64 requires
> libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
> Please resolve this as soon as possible.
>
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From hughsient at gmail.com  Fri Jan 23 13:57:32 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 23 Jan 2009 13:57:32 +0000
Subject: Alpha freeze refresh on Tuesday?
In-Reply-To: <9067dbf21daff570f2dabfdb1575a67d.squirrel@mail.jcomserv.net>
References: <1232671735.8363.8.camel@localhost.localdomain>
	<9067dbf21daff570f2dabfdb1575a67d.squirrel@mail.jcomserv.net>
Message-ID: <1232719052.4198.29.camel@hughsie-work.lan>

On Fri, 2009-01-23 at 07:37 -0600, Jon Ciesla wrote:
>  If most of the libgda and mysql rebuild get done, I think that'd be
> great.

Sure, PackageKit also. I did a new build of 0.4.2 today which is much
better than 0.4.0. I'll come up with something for the feature pages
later.

Richard.




From kevin.kofler at chello.at  Fri Jan 23 14:23:09 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Jan 2009 15:23:09 +0100
Subject: Alpha freeze refresh on Tuesday?
References: <1232671735.8363.8.camel@localhost.localdomain>
	<9067dbf21daff570f2dabfdb1575a67d.squirrel@mail.jcomserv.net>
Message-ID: <glcjsd$l1k$1@ger.gmane.org>

Jon Ciesla wrote:
> If most of the libgda and mysql rebuild get done, I think that'd be great.

And openssl too so the fragile symlink hack can be dropped!

        Kevin Kofler



From paul at xelerance.com  Fri Jan 23 14:38:26 2009
From: paul at xelerance.com (Paul Wouters)
Date: Fri, 23 Jan 2009 09:38:26 -0500 (EST)
Subject: Fedora Alpha release notes - Help required
In-Reply-To: <49798077.10705@fedoraproject.org>
References: <49798077.10705@fedoraproject.org>
Message-ID: <alpine.LFD.1.10.0901230937290.9177@newtla.xelerance.com>

On Fri, 23 Jan 2009, Rahul Sundaram wrote:

> As usual. we need a single page release notes for Fedora 11 Alpha.
> Edit the following page and fill in the notes for major new features, known 
> bugs and things that need more explicit testing.
>
> https://fedoraproject.org/w/index.php?title=Fedora_11_Alpha_release_notes&action=edit&redlink=1
>
> Add link to https://fedoraproject.org/wiki/Releases/11/FeatureList and 
> release schedule.

I am not sure why this is required? It will just duplicate information from the FeatureList page?

Paul



From mcepl at redhat.com  Fri Jan 23 15:35:25 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Fri, 23 Jan 2009 16:35:25 +0100
Subject: Xorg plans for F10?
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
Message-ID: <tm4p46xld8.ln2@ppp1053.in.ipex.cz>

On 2009-01-23, 04:31 GMT, Orion Poplawski wrote:
> Are there any plans to get ati driver 6.10 into F10?  I'm getting pretty
> lousy results with 6.9 in F10 on my RV370, but promising results with 6.10
> and Xorg server 1.5.99.  It doesn't work with 1.5.3 though it installs
> without any rpm/dependency issues.  Anything on the wiki about current
> Xorg plans?

I asked about that our X guys, and airlied (our ATI magician 
in-house) told me that a) there is not that much difference 
between 6.9 and 6.10, b) probably the best what you should do is 
running with nomodeset kernel command line parameter.

Matej



From jonstanley at gmail.com  Fri Jan 23 16:25:02 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Fri, 23 Jan 2009 11:25:02 -0500
Subject: [QA] To clone or not to clone ( a bug report ) that's the 
	question...
In-Reply-To: <glarup$thj$2@ger.gmane.org>
References: <497797C8.1050209@hi.is> <497852D8.7030902@ioa.s.u-tokyo.ac.jp>
	<49786553.3070805@hi.is> <gl9qcs$3av$1@ger.gmane.org>
	<49787499.7000906@hi.is> <gl9t6g$dis$1@ger.gmane.org>
	<4978897D.4020201@hi.is> <glarup$thj$2@ger.gmane.org>
Message-ID: <da159fda0901230825l572ccf35ve9fda95171318f4f@mail.gmail.com>

On Thu, Jan 22, 2009 at 5:28 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:

> In fact I ask this to be escalated to FESCo right NOW and to get a clear
> statement that you aren't allowed to unilaterally decide on a policy for
> the entire project. This is not Gu?mundssonix, it's Fedora!

So Kevin withdrew his complaint to FESCo, but I felt like I should
still chime in here (and if the larger FESCo needs/wants to discuss
this, I'm all in favor of that).  When I started the triage process ~1
year ago, since it would affect ALL maintainers, I took it to FESCo
since that seemed the right thing to do. I still believe that any
proposal that affects maintainer workflow needs FESCo review. We
review all of the packaging guidelines that are prepared by the FPC
prior to their adoption, for example.

So if you're looking to change something, I'd take it to FESCo for approval.



From tim at niemueller.de  Fri Jan 23 16:30:10 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Fri, 23 Jan 2009 17:30:10 +0100
Subject: rawhide report: 20090123 changes
In-Reply-To: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
Message-ID: <4979F092.5020406@niemueller.de>

Rawhide Report schrieb:
> Compose started at Fri Jan 23 06:01:03 UTC 2009

Broken deps for:

> 	lua-sql-mysql-2.1.1-4.fc9.i386 requires libmysqlclient.so.15
> 	lua-sql-mysql-2.1.1-4.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
> 	lua-sql-mysql-2.1.1-4.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
> 	lua-sql-mysql-2.1.1-4.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
> 	lua-sql-mysql-2.1.1-4.fc9.ppc requires libmysqlclient.so.15
> 	lua-sql-mysql-2.1.1-4.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
> 	lua-sql-mysql-2.1.1-4.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
> 	lua-sql-mysql-2.1.1-4.fc9.ppc64 requires libmysqlclient.so.15()(64bit)

Rebuilt.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From jkeating at redhat.com  Fri Jan 23 16:30:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Jan 2009 08:30:55 -0800
Subject: rawhide report: 20090123 changes
In-Reply-To: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
Message-ID: <1232728256.8363.57.camel@localhost.localdomain>

On Fri, 2009-01-23 at 08:06 +0000, Rawhide Report wrote:
>  Broken deps for i386
> ----------------------------------------------------------
>         Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15
>         Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)

With this many broken deps for mysql, why wasn't a special koji tag used
to handle all this in one fell swoop like I offered?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/3b2e8d0e/attachment.sig>

From rdieter at math.unl.edu  Fri Jan 23 16:39:37 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Jan 2009 10:39:37 -0600
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
Message-ID: <glcrsh$k8i$1@ger.gmane.org>

The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
process will be smooth, so as to introduce little to no breakage during or
after.

We'll also be starting work on updates for F-10 (first) and F-9.  While this
is going on there will almost certainly be times of intermittent buildsys
wierdness.  In particular, kde4-related builds should best wait until this
work is completed.  None of this will affect updates-testing or updates, as
the whole update will be pushed as one group.

Question/comments, ask away, or find us on freenode/#fedora-kde

-- Rex




From tgl at redhat.com  Fri Jan 23 16:46:17 2009
From: tgl at redhat.com (Tom Lane)
Date: Fri, 23 Jan 2009 11:46:17 -0500
Subject: rawhide report: 20090123 changes 
In-Reply-To: <1232728256.8363.57.camel@localhost.localdomain> 
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
	<1232728256.8363.57.camel@localhost.localdomain>
Message-ID: <6813.1232729177@sss.pgh.pa.us>

Jesse Keating <jkeating at redhat.com> writes:
> With this many broken deps for mysql, why wasn't a special koji tag used
> to handle all this in one fell swoop like I offered?

[ shrug... ]  There's not that many, and it would have required more
work on the part of the affected maintainers to deal with a nonstandard
tag than just to rebuild.  If I expected anyone to have to do more than
a respin, then a tag would have been a good idea because the work would
be a bit drawn out.  But no one objected last week to having to do a
respin once 5.1 went into the tree...

			regards, tom lane



From jkeating at redhat.com  Fri Jan 23 16:59:59 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Jan 2009 08:59:59 -0800
Subject: rawhide report: 20090123 changes
In-Reply-To: <6813.1232729177@sss.pgh.pa.us>
References: <20090123080624.E31E31F828C@releng2.fedora.phx.redhat.com>
	<1232728256.8363.57.camel@localhost.localdomain>
	<6813.1232729177@sss.pgh.pa.us>
Message-ID: <1232729999.8363.71.camel@localhost.localdomain>

On Fri, 2009-01-23 at 11:46 -0500, Tom Lane wrote:
>  
> [ shrug... ]  There's not that many, and it would have required more
> work on the part of the affected maintainers to deal with a nonstandard
> tag than just to rebuild.  If I expected anyone to have to do more than
> a respin, then a tag would have been a good idea because the work would
> be a bit drawn out.  But no one objected last week to having to do a
> respin once 5.1 went into the tree...

Well nobody but me, who's supposed to keep the trees something sane and
usable.  To use the non-standard tag would just be adding a bit more to
your make build call, really not that difficult.  Please consider using
it in the future if you're going to break such a wide array of packages.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/ff003620/attachment.sig>

From jkeating at redhat.com  Fri Jan 23 17:00:54 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 23 Jan 2009 09:00:54 -0800
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
In-Reply-To: <glcrsh$k8i$1@ger.gmane.org>
References: <glcrsh$k8i$1@ger.gmane.org>
Message-ID: <1232730054.8363.72.camel@localhost.localdomain>

On Fri, 2009-01-23 at 10:39 -0600, Rex Dieter wrote:
> The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
> process will be smooth, so as to introduce little to no breakage during or
> after.
> 
> We'll also be starting work on updates for F-10 (first) and F-9.  While this
> is going on there will almost certainly be times of intermittent buildsys
> wierdness.  In particular, kde4-related builds should best wait until this
> work is completed.  None of this will affect updates-testing or updates, as
> the whole update will be pushed as one group.
> 
> Question/comments, ask away, or find us on freenode/#fedora-kde
> 
> -- Rex
> 


Would it be worth doing the rawhide work in a dist-f11-kde tag, as to
not run afoul of the alpha freeze refresh early next week?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/193b00a4/attachment.sig>

From sundaram at fedoraproject.org  Fri Jan 23 17:23:45 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Fri, 23 Jan 2009 22:53:45 +0530
Subject: Fedora Alpha release notes - Help required
In-Reply-To: <alpine.LFD.1.10.0901230937290.9177@newtla.xelerance.com>
References: <49798077.10705@fedoraproject.org>
	<alpine.LFD.1.10.0901230937290.9177@newtla.xelerance.com>
Message-ID: <4979FD21.2040008@fedoraproject.org>

Paul Wouters wrote:
> On Fri, 23 Jan 2009, Rahul Sundaram wrote:
> 
>> As usual. we need a single page release notes for Fedora 11 Alpha.
>> Edit the following page and fill in the notes for major new features, 
>> known bugs and things that need more explicit testing.
>>
>> https://fedoraproject.org/w/index.php?title=Fedora_11_Alpha_release_notes&action=edit&redlink=1 
>>
>>
>> Add link to https://fedoraproject.org/wiki/Releases/11/FeatureList and 
>> release schedule.
> 
> I am not sure why this is required? It will just duplicate information 
> from the FeatureList page?

We are just adding a link so that people who are interested in more 
details can read them.

Rahul



From rdieter at math.unl.edu  Fri Jan 23 17:30:44 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 23 Jan 2009 11:30:44 -0600
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
References: <glcrsh$k8i$1@ger.gmane.org>
	<1232730054.8363.72.camel@localhost.localdomain>
Message-ID: <glcusb$ei$1@ger.gmane.org>

Jesse Keating wrote:

> On Fri, 2009-01-23 at 10:39 -0600, Rex Dieter wrote:
>> The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
>> process will be smooth, so as to introduce little to no breakage during
>> or after.
...
> Would it be worth doing the rawhide work in a dist-f11-kde tag, as to
> not run afoul of the alpha freeze refresh early next week?

(parroting what I said on irc...) I can vouche we can have it ready (and
fixed if needed) by then.

-- Rex






From mw_triad at users.sourceforge.net  Fri Jan 23 18:11:47 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Fri, 23 Jan 2009 12:11:47 -0600
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <20090123011755.GA10047@kvack.org>
References: <20090121030132.GG19788@kvack.org>
	<4977D0C2.9090900@redhat.com>	<20090122032202.GH29367@kvack.org>
	<4977E6C2.7080905@redhat.com>	<20090122032512.GJ29367@kvack.org>
	<4977E795.9030902@redhat.com>	<20090122032940.GL29367@kvack.org>
	<4977EA4D.3060908@redhat.com>	<20090122034558.GM29367@kvack.org>	<8kvl46xrac.ln2@ppp1053.in.ipex.cz>
	<20090123011755.GA10047@kvack.org>
Message-ID: <gld193$8o9$1@ger.gmane.org>

Benjamin LaHaise wrote:
> arrow keys don't work correctly in qemu or vmware,

I don't know about vmware, for qemu this may be a bug related to the 
switch to evdev. My keyboard problems (far more than arrow keys weren't 
working!) was fixed by specifying the keyboard type when starting quemu, 
e.g. 'qemu-<flavor> -k en-us ...'.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
|-\ /-\ \ | -+-   |-\  +  \ | -+- /-\
| | | | |\|  |    |-/ /-\ |\|  |  |
|-/ \-/ | \  |    |   | | | \ -+- \-



From notting at redhat.com  Fri Jan 23 18:46:17 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 23 Jan 2009 13:46:17 -0500
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <glasfg$thj$3@ger.gmane.org>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
	<glasfg$thj$3@ger.gmane.org>
Message-ID: <20090123184617.GA11602@nostromo.devel.redhat.com>

Kevin Kofler (kevin.kofler at chello.at) said: 
> The funny thing is, the GDM config file even used to say in a comment that
> anybody who disables root login "should be shot".

Yes, but the Queen of England has no authority here.

Bill



From kevin.kofler at chello.at  Fri Jan 23 21:48:35 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 23 Jan 2009 22:48:35 +0100
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
References: <glcrsh$k8i$1@ger.gmane.org>
	<1232730054.8363.72.camel@localhost.localdomain>
Message-ID: <glddvj$mrp$1@ger.gmane.org>

Jesse Keating wrote:
> Would it be worth doing the rawhide work in a dist-f11-kde tag, as to
> not run afoul of the alpha freeze refresh early next week?

We should be done by then, and it's also just a RC->final update, not a big
one, in particular there should not be any API/ABI breakage.

        Kevin Kofler



From sundaram at fedoraproject.org  Fri Jan 23 22:24:26 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Jan 2009 03:54:26 +0530
Subject: Fedora spins and package groups in kickstart
Message-ID: <497A439A.9030901@fedoraproject.org>

Hi,

In a earlier spins session, I mentioned that it is impossible to remove 
groups inherited via kickstart files directly due to a bug / pending 
enhancement. This has been fixed so you can do something like

% include base.ks

- at foo-support

For reference,

https://bugzilla.redhat.com/show_bug.cgi?id=428835

Rahul



From forum at ru.bir.ru  Fri Jan 23 22:43:50 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Sat, 24 Jan 2009 01:43:50 +0300
Subject: New package from one source
In-Reply-To: <20090120184236.GA10482@nostromo.devel.redhat.com>
References: <gl2t8r$rm$1@ger.gmane.org>	<20090119221149.GA10949@nostromo.devel.redhat.com>	<gl40q6$pob$1@ger.gmane.org>
	<20090120184236.GA10482@nostromo.devel.redhat.com>
Message-ID: <gldh77$3sc$1@ger.gmane.org>

Bill Nottingham wrote:
> Pavel Alexeev (aka Pahan-Hubbitus) (forum at ru.bir.ru) said: 
>>> I don't think shipping separate rebuilds of core system daemons that
>>> consist of adding 66k of non-upstream patch is a good idea.
>> I'm completely do not understand - why we do not want provide free  
>> choose for free users?
> 
> For the same reason we don't ship non-upstream kernel modules; it's a
> matter of maintenance load and coherence.
I'm afraid I don't completely understand you. About what maintenance 
load you are speaking?
Is there any polices or guidelines about it?



From lsof at nodata.co.uk  Fri Jan 23 23:07:03 2009
From: lsof at nodata.co.uk (nodata)
Date: Sat, 24 Jan 2009 00:07:03 +0100
Subject: Root Logins in X...
In-Reply-To: <49781C9C.4000007@redhat.com>
References: <49781C9C.4000007@redhat.com>
Message-ID: <1232752023.7946.1.camel@localhost.localdomain>

Am Donnerstag, den 22.01.2009, 02:13 -0500 schrieb Warren Togami:
> The only legitimate reason to allow root login is disaster recovery.
> The case where /home filesystem is full and logins fail, or /home is
> remote and inaccessible are cases where graphical non-root logins can fail.

So the only benefit would be that root could login when /home was full?

Can't see the point myself. Does root require a graphical login for this
odd edge case?

nd



From sundaram at fedoraproject.org  Fri Jan 23 23:33:33 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Jan 2009 05:03:33 +0530
Subject: New package from one source
In-Reply-To: <gldh77$3sc$1@ger.gmane.org>
References: <gl2t8r$rm$1@ger.gmane.org>	<20090119221149.GA10949@nostromo.devel.redhat.com>	<gl40q6$pob$1@ger.gmane.org>	<20090120184236.GA10482@nostromo.devel.redhat.com>
	<gldh77$3sc$1@ger.gmane.org>
Message-ID: <497A53CD.1050605@fedoraproject.org>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:

> I'm afraid I don't completely understand you. About what maintenance 
> load you are speaking?
> Is there any polices or guidelines about it?

Any upstream deviation usually causes a higher maintenance load since 
the downstream patch set has to be re-based for every upstream release. 
For a active project like Apache, you should focus on getting the 
patches integrated upstream and benefiting all downstream distributions 
and not just Fedora.

For guidelines and policies refer

https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream

Rahul



From jspaleta at gmail.com  Fri Jan 23 23:43:51 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 23 Jan 2009 14:43:51 -0900
Subject: Root Logins in X...
In-Reply-To: <1232752023.7946.1.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>
	<1232752023.7946.1.camel@localhost.localdomain>
Message-ID: <604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>

On Fri, Jan 23, 2009 at 2:07 PM, nodata <lsof at nodata.co.uk> wrote:
> Can't see the point myself. Does root require a graphical login for this
> odd edge case?


The better question is, how do we expect a user of a predominated self
administered system to recover in the edge cases like this?  The
current default partitioning layout certainly is not designed to
prevent this particular edge case from happening.

And a related question, how are RH certified admins been trained to
recover from this sort of thing?

I've already been pre-conditioned from years of exposure to reach for
root, however it takes, to clean that sort of situation up. But I live
in the %1 tail of users, I don't expect my behaviors to be
representative. I doubt my wife knows what to do if she fills up her
home directory on her desktop and can no longer login in as a result.
I can go force a test of that by filling up her harddrive and then
hiding so she can't find me to ask me to fix it.

-jef



From susan_lists at ties.org  Sat Jan 24 01:18:18 2009
From: susan_lists at ties.org (susan_lists at ties.org)
Date: Fri, 23 Jan 2009 20:18:18 -0500
Subject: Intro and wiki info
Message-ID: <e1cf1c3a0901231718l55f68ddbmb45a386ed30002fd@mail.gmail.com>

Greetings,

I thought I should introduce myself to the packaging list and devel list.
I'm here to help with documentation in general and packaging related wiki
pages specifically.  This includes the Packaging:, PackageMaintainers/*, and
PackagingDrafts/* pages of the wiki. My immediate tasks include helping with
page naming and categories to aid with searches.  I am also available to
assist with any proofreading.

My $dayjob is mostly teaching and mostly for Red Hat (RHCE and RHCA
classes). I've been *nix user and admin and instructor for years but I am
fairly new as contributer.  I have started out helping with the Fedora Docs
Project and after meeting several people at FUDConF11, accepted the lead on
the docs team side for the packaging docs.  It is really a liaison position
between the docs team and the packaging team and other contributors to
packaging documentation.  In addition to the renaming, categorizing, and
proofreading, I am sure I will be helping with moving the Packaging
Guidelines to the CMS when we decide on a system and I have DocBook
experience to assist if any of the pages move to XML for other publishing.

>From a docs side, the first thing that needs to occur is some renaming and
categorization.  Since it is a wiki and it is easy to undo changes, I am
going to dig in add some categories and then start some page renaming.  I
won't be offended if anything gets undone but I hope that those who have
worked so hard to get the pages where they are will also jump in with some
suggestions.

Here are some links that will help explain what needs to occur:
https://fedoraproject.org/wiki/Help:Wiki_structure  - This page explains
page naming, namespaces, and categories.
https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_of_the_week - The
first week is about moving pages (preview available now)

For example the current page [[PackageMaintainers/MaintainerResponsibility]]
would not currently be found in a search for either "package" or
"maintainers" because the mediawiki search uses whole word searches only.
We also want to eliminate the hierarchy.  A better name would be [[Package
maintainer responsibilities]].

I was looking at the page
https://fedoraproject.org/wiki/PackageMaintainersand see a lot of good
naming suggestions in the link names and descriptions.
With renaming, categories, and subcategories we can even generate a similar
page automatically.
Check out the fonts pages for an example:
https://fedoraproject.org/wiki/Category:Fonts
Something similar can be done for
https://fedoraproject.org/wiki/Category:Package_Maintainers
I am still looking for suggestions for subcategories for the Package
Maintainers pages.

If there are pages that are old or no longer in use they can be moved to the
Archive namespace.  Simply click the move button at the top of the page and
add Archive: at the beginning of the name.  For instance
PackageMaintainers/FC3Status has recently been moved to
Archive:PackageMaintainers/FC3Status  Anything pointing to the original name
is automatically redirected to the new name. This way the page still exists
and can be found with an advanced search but will not appear in default
search that a visitor to the site may use.  Can
PackageMaintainers/PackageStatus/CompsF9Missing also be archived?

Finally, there is a fedora-wiki mailing list that has announcements and
tips, but is also a good place to ask questions and discuss names and
categories. https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki

And I am often on #fedora-docs as laubersm (or some variation) but anyone
there should also be able to help.

I look forward to helping and I appreciate any suggestions.

Thanks,
Susan

-- 
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE  4C26 EFC3 11C2 BFA1 0974
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090123/a4f27c8b/attachment.htm>

From bashton at brennanashton.com  Sat Jan 24 04:03:49 2009
From: bashton at brennanashton.com (Brennan Ashton)
Date: Fri, 23 Jan 2009 20:03:49 -0800
Subject: koji build error libtinfo.so.5
In-Reply-To: <981da310901231954y63391cbaia0dc3364f21d2ffa@mail.gmail.com>
References: <981da310901231954y63391cbaia0dc3364f21d2ffa@mail.gmail.com>
Message-ID: <981da310901232003r4e97e9bdr3a6c26469c9cc96a@mail.gmail.com>

I have been noticing this in all the root.log for builds on koji both
in F10 and F11:

DEBUG util.py:250:  /bin/sh: error while loading shared libraries:
libtinfo.so.5: cannot open shared object file: No such file or
directory
DEBUG util.py:250:  error: %post(bash-3.2-30.fc10.ppc) scriptlet
failed, exit status 127

It does not appear to be fatal, but what is going on?

Regards,
Brennan Ashton



From cmadams at hiwaay.net  Sat Jan 24 04:16:05 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 23 Jan 2009 22:16:05 -0600
Subject: Root Logins in X...
In-Reply-To: <604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<1232752023.7946.1.camel@localhost.localdomain>
	<604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>
Message-ID: <20090124041605.GA1062410@hiwaay.net>

Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> The better question is, how do we expect a user of a predominated self
> administered system to recover in the edge cases like this?  The
> current default partitioning layout certainly is not designed to
> prevent this particular edge case from happening.

Well, "user can't log in because /home is full" is being used as a
reason here.  Is that the real situation - if /home is full, can users
really not log in?  If that is the case, that's broke and should be
fixed.  The user should be able to log in and remove files.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From mtasaka at ioa.s.u-tokyo.ac.jp  Sat Jan 24 04:34:16 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Sat, 24 Jan 2009 13:34:16 +0900
Subject: koji build error libtinfo.so.5
In-Reply-To: <981da310901232003r4e97e9bdr3a6c26469c9cc96a@mail.gmail.com>
References: <981da310901231954y63391cbaia0dc3364f21d2ffa@mail.gmail.com>
	<981da310901232003r4e97e9bdr3a6c26469c9cc96a@mail.gmail.com>
Message-ID: <497A9A48.2030008@ioa.s.u-tokyo.ac.jp>

Brennan Ashton wrote, at 01/24/2009 01:03 PM +9:00:
> I have been noticing this in all the root.log for builds on koji both
> in F10 and F11:
> 
> DEBUG util.py:250:  /bin/sh: error while loading shared libraries:
> libtinfo.so.5: cannot open shared object file: No such file or
> directory
> DEBUG util.py:250:  error: %post(bash-3.2-30.fc10.ppc) scriptlet
> failed, exit status 127
> 
> It does not appear to be fatal, but what is going on?
> 
> Regards,
> Brennan Ashton

This means
- Installing bash tries to execute some bash script at %post
- To do so, (installed) bash binary needs libtinfo.so.5, 
  i.e. before bash is installed, ncurses-libs should have already
  been installed
- However in fact ncurses-libs is not installed at this time
  (for some reason),
  so trying to execute bash script on bash %post fails

Here I guess dependency loop is happening which leads to this
broken deps.... Actually:

bash -> ncurses-libs -> glibc -> glibc-common -> bash

There may be other dependency loops.

Mamoru



From rawhide at fedoraproject.org  Sat Jan 24 09:02:20 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 24 Jan 2009 09:02:20 +0000 (UTC)
Subject: rawhide report: 20090124 changes
Message-ID: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>

Compose started at Sat Jan 24 06:01:02 UTC 2009

New package ctan-musixtex-fonts
        Type 1 versions of MusiXTeX fonts
New package jeuclid
        MathML rendering solution
New package libproxy
        A library handling all the details of proxy configuration
New package perl-ORLite-Migrate
        Light weight SQLite-specific schema migration
New package rubygem-mechanize
        A handy web browsing ruby object
Removed package tetex-font-kerkis
Updated Packages:

DeviceKit-power-004-1.fc11
--------------------------
* Fri Jan 23 17:00:00 2009 Richard Hughes <richard at hughsie.com> 004-1
- Update to 004


PackageKit-0.4.2-1.fc11
-----------------------
* Mon Jan 19 17:00:00 2009 Richard Hughes  <rhughes at redhat.com> - 0.4.2-1
- New upstream version
- Enable time estimation by default
- Remove the udev helper from PackageKit now the core functionality is in
  udev itself
- Lots of bug fixes

* Thu Jan  8 17:00:00 2009 Richard Hughes  <rhughes at redhat.com> - 0.4.1-1
- New upstream version
- Use NetworkManager to get the network device type for session policy decisions
- Lots of bug fixes


amora-1.1-3.fc11
----------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 1.1-3
- Rebuild


apr-util-1.3.4-2.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Joe Orton <jorton at redhat.com> 1.3.4-2
- rebuild for new MySQL


bacula-2.4.4-2.fc11
-------------------
* Fri Jan 23 17:00:00 2009 Jon Ciesla <limb at jcomserv.net - 2.4.4-2
- Rebuild against mysql 5.1.


bakery-2.6.2-1.fc11
-------------------
* Sat Jan 17 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 1:2.6.2-1
- Update to upstream 2.6.2
- Removed autodetected devel package Rs


banshee-1.4.2-1.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 1.4.2-1
- Update to 1.4.2
- Require mono-addins
- Enable menu entry on other desktops

* Thu Jan  1 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 1.4.1-4
- Manually require libmtp

* Thu Jan  1 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 1.4.1-3
- Split MusicBrainz libraries into separate subpackages
- Properly tag songs ripped from CDs (bug #477669)


binutils-2.19.50.0.1-10.fc11
----------------------------
* Fri Jan 23 17:00:00 2009 Nick Clifton <nickc at redhat.com> 2.19.50.0.1-10
- Only require dejagnu if the testsuites are going to be run.  (BZ 481169)


cairo-dock-2.0.0-0.3.svn1498_trunk.fc11
---------------------------------------
* Sat Jan 24 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1498


callweaver-1.2.0.1-2.fc11
-------------------------
* Fri Jan 23 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.2.0.1-2
- Rebuild for MySQL 5.1.X.


clutter-cairo-0.8.2-2.fc11
--------------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.8.2-2
- Rebuild


clutter-gst-0.8.0-3.fc11
------------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.8.0-3
- Rebuild


clutter-gtk-0.8.2-2.fc11
------------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.8.2-2
- Rebuild


collectd-4.5.1-3.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 4.5.1-3
- Rebuild against new mysql client.


control-center-2.25.3-5.fc11
----------------------------
* Fri Jan 23 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-5
- Don't show enrollment for users if pam_fprintd isn't enabled in
  authconfig (#475804)


cyrus-sasl-2.1.22-20.fc11
-------------------------
* Fri Jan 23 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 2.1.22-20
- set LDAP_OPT_TIMEOUT (#326452)
- provide LSB compatible init script (#246900)


ebook-tools-0.1.1-3.fc11
------------------------
* Sat Jan 24 17:00:00 2009 John5342 <john5342 at, fedoraproject.org> 0.1.1-3
- Actually remove lit2epub this time


eclipse-3.4.1-14.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Andrew Overholt <overholt at redhat.com> 1:3.4.1-14
- Add R:java-devel for -jdt (rh#480979).


elfutils-0.139-1.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Roland McGrath <roland at redhat.com> - 0.139-1
- Update to 0.139
  - libcpu: Add Intel SSE4 disassembler support
  - readelf: Implement call frame information and exception handling dumping.
    	     Add -e option.  Enable it implicitly for -a.
  - elflint: Check PT_GNU_EH_FRAME program header entry.
  - libdwfl: Support automatic gzip/bzip2 decompression of ELF files. (#472136)


fontconfig-2.6.94-1.git.65.g628ee83.fc11
----------------------------------------
* Fri Jan 23 17:00:00 2009 Behdad Esfahbod <besfahbo at redhat.com> - 2.6.94-1.git.65.g628ee83
- Update to 2.6.94-1.git.65.g628ee83


gambas2-2.10.2-2.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 2.10.2-2
- rebuild for new mysql


ghc-6.10.1-8.fc11
-----------------
* Fri Jan 23 17:00:00 2009 Jens Petersen <petersen at redhat.com> - 6.10.1-8
- fix to libedit means can drop ncurses-devel BR workaround (#481252)


glom-1.9.0-1.fc11
-----------------
* Thu Jan 22 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 1.9.0-1
- Update to upstream 1.9.0
- Updated list of BRs


gmyth-0.7.1-8.fc11
------------------
* Fri Jan 23 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 0.7.1-8
- Rebuild for new MySQL libraries


gnokii-0.6.27-3.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 0.6.27-3
- Rebuild for MySQL 5.1


gnome-games-2.25.5-1.fc11
-------------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 1:2.25.5-1
- Update to 2.25.5


gnome-packagekit-0.4.2-1.fc11
-----------------------------
* Mon Jan 19 17:00:00 2009 Richard Hughes  <rhughes at redhat.com> - 0.4.2-1
- New upstream version
- Lots of bug fixes

* Thu Jan  8 17:00:00 2009 Richard Hughes  <rhughes at redhat.com> - 0.4.1-1
- New upstream version
- Add an option to the prefs dialog to prevent checking for updates when
  using mobile broadband connections
- Allow the admin to restrict getting updates when on WiFi connections
- Set the default search mode to details (not name) and preserve the search
  type in GConf if changed in the UI
- Add a simple markdown parser and use it in all applications.
- Send different errors when we fail a method on the session DBus interface
- Support setting timeouts via the interaction mode from the DBus interface
- Lots of bugfixes


gnome-panel-2.25.5.1-1.fc11
---------------------------
* Fri Jan 23 17:00:00 2009 Ray Strode <rstrode at redhat.com> - 2.25.5.1-1
- Update to 2.25.5.1
- Fixes bug 481029


gnome-python2-extras-2.25.1-1.fc11
----------------------------------
* Fri Jan 23 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 2.25.1-1
- Fixed Source URL
- Switch to libgda 4.0 API

* Wed Jan 21 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 2.25.1-1
- Update to 2.25.1
- Remove the xulrunner patches (fixed upstream).
- Remove patch for GNOME bug #553911 (fixed upstream).


gok-2.25.3-3.fc11
-----------------
* Sat Jan 24 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.3-3
- Merge review feedback (#225852)


gtk2-2.15.1-1.fc11
------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.1-1
- Update to 2.15.1


gtkwave-3.2.0-0.1.RC4.fc11
--------------------------
* Thu Jan 29 17:00:00 2009 Paul Howarth <paul at city-fan.org> 3.2.0-0.1.RC4
- update to 3.2.0RC4 (#481264)
- new upstream URLs
- buildreq /usr/include/tcl.h for embedded tcl support


hicolor-icon-theme-0.10-5
-------------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 0.10-5
- Update URL
- Clean up scriptlets
- Include ChangeLog


jabberd-2.2.4-2.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Bernie Innocenti <bernie at codewiz.org> - 2.2.4-2
- Replace /etc/sysconfig/jabberd on upgrade to drop obsolete daemons
- Rebuilt for new libmysqlclient


jwhois-4.0-9.fc11
-----------------
* Fri Jan 23 17:00:00 2009 Vitezslav Crhonek <vcrhonek at redhat.com> - 4.0-9
- Change the server used for .gi domains


kdeaccessibility-4.2.0-1.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdeadmin-4.2.0-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdeartwork-4.2.0-1.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdebase-4.2.0-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdebase-runtime-4.2.0-1.fc11
----------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0
- +BR: pulseaudio-libs-devel xine-lib-devel
- -BR: giflib-devel pcre-devel


kdebase-workspace-4.2.0-1.fc11
------------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdebindings-4.2.0-1.fc11
------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdeedu-4.2.0-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdegames-4.2.0-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdegraphics-4.2.0-1.fc11
------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdelibs-4.2.0-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdemultimedia-4.2.0-1.fc11
--------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdenetwork-4.2.0-1.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdepim-4.2.0-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdepimlibs-4.2.0-1.fc11
-----------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0
- exclude kdepimlibs-apidocs from main pkg

* Thu Jan  8 17:00:00 2009 Lorenzo Villani <lvillani at binaryhelix.net> - 4.1.96-2
- fix build on Fedora 10 (cmake < 2.6.3 seems to have a different
  behaviour here)


kdeplasma-addons-4.2.0-1.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdesdk-4.2.0-1.fc11
-------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdetoys-4.2.0-1.fc11
--------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kdeutils-4.2.0-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0


kernel-2.6.29-0.48.rc2.git1.fc11
--------------------------------
* Fri Jan 23 17:00:00 2009 Kyle McMartin <kyle at redhat.com>
- disable intel_iommu by default (enable with "intel_iommu=on")

* Fri Jan 23 17:00:00 2009 Eric Sandeen <sandeen at redhat.com>
- build the crc32c driver into the kernel
- add selinux fixes for btrfs

* Fri Jan 23 17:00:00 2009 Dave Jones <davej at redhat.com>
- Make NFS work again.


kipi-plugins-0.2.0-0.13.rc1.fc11
--------------------------------
* Thu Jan 22 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 0.2.0-0.13.rc1
- kipi-plugins-0.2.0-rc1


libgda-3.99.8-1.fc11
--------------------
* Fri Jan 16 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 1:3.99.8-1
- Switch to 4.0 ABI
- Update to upstream 3.99.8
- Patch updates (upstreamed and ported)
- Added JAVA package flag, currently disabled


libgdamm-3.99.8-1.fc11
----------------------
* Wed Jan 21 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 3.99.8-1
- Update to upstream 3.99.8 (4.0 API)


libgnomedb-3.99.7-1.fc11
------------------------
* Wed Jan 21 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 1:3.99.7-1
- Update to upstream 3.99.7 (4.0 API)
- Updated list of BRs
- Pruned down devel package Rs


libmsn-4.0-0.9.beta2.fc11
-------------------------
* Fri Jan 23 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.0-0.9.beta2
- revert use of (tm)

* Fri Jan 23 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.0-0.8.beta2
- remove pkgconfig hack/workaround


libnss-mysql-1.5-10.fc11
------------------------
* Fri Jan 23 17:00:00 2009 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 1.5-9
- build fails with autoreconf, removed

* Fri Jan 23 17:00:00 2009 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 1.5-9
- added libtoolize -f and readded autoreconf -f

* Fri Jan 23 17:00:00 2009 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> - 1.5-8
- rebuild against new mysql


lilypond-2.12.1-5.fc11
----------------------
* Fri Jan 23 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 2.12.1-5
- Final font corrections.


lua-sql-2.1.1-5.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Tim Niemueller <tim at niemueller.de> - 2.1.1-5
- Rebuild for MySQL 5.1


mingw32-gettext-0.17-8.fc11
---------------------------
* Fri Jan 23 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 0.17-8
- Use find_lang macro.


mod_auth_mysql-3.0.0-7
----------------------
* Fri Jan 23 17:00:00 2009 Joe Orton <jorton at redhat.com> 1:3.0.0-7
- rebuild for new MySQL


mysql++-3.0.8-2.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> 3.0.8-2
- rebuild against MySQL Client 5.1 (libmysqlclient.so.16)


mysql-gui-tools-5.0r12-10.fc11
------------------------------
* Fri Jan 23 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 5.0r12-10
- rebuild for new mysql


nekovm-1.8.0-3.fc11
-------------------
* Fri Jan 23 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 1.8.0-3
- Rebuild to get updated mysql dep.


ocaml-mysql-1.0.4-7.fc11
------------------------
* Fri Jan 23 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 1.0.4-7
- Force another rebuild to try to get updated MySQL client deps.


openoffice.org-3.0.1-15.4.fc11
------------------------------
* Fri Jan 23 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-15.4
- Resolves: rhbz#480057 add openoffice.org-3.0.1.ooo98288.ucb.neonchange.patch
- cjkunifonts-uming -> cjkuni-uming-fonts


openser-1.3.4-2.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Jan ONDREJ (SAL) <ondrejj(at)salstar.sk> 1.3.4-2
- Rebuild for new mysql.


pam_mysql-0.7-0.6.rc1.fc11.2
----------------------------

patchutils-0.3.1-1.fc11
-----------------------
* Fri Jan 23 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 0.3.1-1
- 0.3.1.


pdns-2.9.22-2.rc3.fc11
----------------------
* Fri Jan 23 17:00:00 2009 Ruben Kerkhof <ruben at rubenkerkhof.com> 2.9.22-2.rc3
- Rebuild for new libmysqlclient


perl-Crypt-Simple-0.06-6.fc11
-----------------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.06-7
- Rebuild


perl-libwww-perl-5.823-1.fc11
-----------------------------
* Thu Jan 22 17:00:00 2009 Marcela Ma??l????ov?? <mmaslano at redhat.com> 5.823-1
- update to 5.823


phonon-4.3.0-2.fc11
-------------------
* Fri Jan 23 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 4.3.0-2
- fix typo in postun scriptlet (introduced in 4.2.96-3)


php-5.2.8-3.fc11
----------------
* Fri Jan 23 17:00:00 2009 Joe Orton <jorton at redhat.com> 5.2.8-3
- rebuild for new MySQL


postfix-2.5.6-2.fc11
--------------------
* Fri Jan 23 17:00:00 2009 Miroslav Lichvar <mlichvar at redhat.com> 2:2.5.6-2
- rebuild for new mysql


pyclutter-0.8.2-1.fc11
----------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 0.8.2-1
- Update to 0.8.2


rt3-3.8.2-1.fc11
----------------
* Fri Jan 23 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.2-1
- Upstream update.
- Preps to add a perl-RT-Test package.


ruby-cairo-1.8.0-2.fc11
-----------------------
* Fri Jan 23 17:00:00 2009 Allisson Azevedo <allisson at gmail.com> 1.8.0-2
- Rebuild


ruby-mysql-2.8-1.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Orion Poplawski <orion at cora.nwra.com> - 2.8-1
- Update to 2.8


selinux-policy-3.6.3-8.fc11
---------------------------
* Fri Jan 23 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-8
- Add policy to make dbus/nm-applet work


snort-2.8.1-6.fc11
------------------
* Fri Jan 23 17:00:00 2009 Dennis Gilmore <dennis at ausil.us> - 2.8.1-6
- rebuild for new mysql


sos-1.8-9.fc11
--------------
* Wed Jan 21 17:00:00 2009 Adam Stokes <ajs at redhat dot com> - 1.8-9
- Resolves: bz436053 /usr/share/sos is not owned by any package 
- Resolves: bz434626 Wrong directory structure for translations


totem-2.25.3-8.fc11
-------------------
* Fri Jan 23 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.3-8
- Rebuild for new MySQL libraries

* Fri Jan 16 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.3-7
- Own /usr/lib/totem


tsclient-2.0.2-1.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.0.2-1
- Update to 2.0.2

* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.0.1-11
- Don't add Utility to the desktop file categories


tzdata-2009a-1.fc11
-------------------
* Fri Jan 23 17:00:00 2009 Petr Machata <pmachata at redhat.com> - 2009a-1
- Upstream 2009a
  - Fix Asia/Kathmandu spelling
  - Historical timestamps for Switzerland and Cuba
  - DST update for America/Resolute


vinagre-2.25.5-1.fc11
---------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


vino-2.25.5-1.fc11
------------------
* Fri Jan 23 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.25.5-1
- Update to 2.25.5


vsftpd-2.1.0-0.3.pre4.fc11
--------------------------
* Fri Jan 23 17:00:00 2009 Martin Nagy <mnagy at redhat.com> - 2.1.0-0.3.pre4
- update to latest upstream release
- enable ptrace sandbox again
- don't mark vsftpd_conf_migrate.sh as a config file


xine-lib-1.1.16.1-1.fc11
------------------------
* Fri Jan 23 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1.1.16.1-1
- xine-lib-1.1.16.1
- include avsync patch (#470568)


zabbix-1.6.2-2.fc11
-------------------
* Fri Jan 23 17:00:00 2009 Jeffrey C. Ollie <jeff at ocjtech.us> - 1.6.2-2
- Rebuild for MySQL 5.1.X


zfs-fuse-0.5.0-7.20081221.fc11
------------------------------
* Sat Jan 24 17:00:00 2009 Uwe Kubosh <uwe at kubosch.no> - 0.5.0-7.20081221
- Updated etc/init.d/zfs-fuse init script after feedback from Rudd-O
  Removed limits for the fuse process which could lead to a hung system
  or use lots of memory.


Summary:
Added Packages: 5
Removed Packages: 1
Modified Packages: 95
Broken deps for i386
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15
	Io-language-mysql-20071010-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	32:bind-sdb-9.6.0-3.P1.fc11.i386 requires libmysqlclient.so.15
	32:bind-sdb-9.6.0-3.P1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	1:dovecot-mysql-1.1.8-2.fc11.i386 requires libmysqlclient.so.15
	1:dovecot-mysql-1.1.8-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.i386 requires libmysqlclient.so.15
	exim-mysql-4.69-8.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.i386 requires libmysqlclient_r.so.15
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	libpreludedb-mysql-0.9.15.1-2.fc11.i386 requires libmysqlclient.so.15
	libpreludedb-mysql-0.9.15.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.i386 requires libmysqlclient.so.15
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nagios-plugins-mysql-1.4.13-12.fc11.i386 requires libmysqlclient.so.15
	nagios-plugins-mysql-1.4.13-12.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	ntop-3.3.8-1.fc10.i386 requires libmysqlclient_r.so.15
	ntop-3.3.8-1.fc10.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.i386 requires libmysqlclient_r.so.15
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.i386 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.i386 requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.i386 requires libmysqlclient.so.15
	pure-ftpd-1.0.21-17.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	rsyslog-mysql-3.21.9-2.fc11.i386 requires libmysqlclient.so.15
	rsyslog-mysql-3.21.9-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	ser-mysql-0.9.6-15.fc10.i386 requires libmysqlclient.so.15
	ser-mysql-0.9.6-15.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	ulogd-mysql-1.24-9.fc9.i386 requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	zoneminder-1.23.3-2.fc11.i386 requires libmysqlclient.so.15
	zoneminder-1.23.3-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for x86_64
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	Io-language-mysql-20071010-7.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	exim-mysql-4.69-8.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ntop-3.3.8-1.fc10.x86_64 requires libmysqlclient_r.so.15()(64bit)
	ntop-3.3.8-1.fc10.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.x86_64 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	pure-ftpd-1.0.21-17.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.x86_64 requires libgdasql-3.0.so.3()(64bit)
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rsyslog-mysql-3.21.9-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	ser-mysql-0.9.6-15.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ser-mysql-0.9.6-15.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.x86_64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)



Broken deps for ppc
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.ppc requires libmysqlclient.so.15
	Io-language-mysql-20071010-7.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc requires libmysqlclient.so.15
	32:bind-sdb-9.6.0-3.P1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cherokee-0.11.6-1.fc11.ppc requires libmysqlclient.so.15
	cherokee-0.11.6-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	1:dovecot-mysql-1.1.8-2.fc11.ppc requires libmysqlclient.so.15
	1:dovecot-mysql-1.1.8-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.ppc requires libmysqlclient.so.15
	exim-mysql-4.69-8.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	flow-tools-0.68.4-1.fc9.ppc requires libmysqlclient.so.15
	flow-tools-0.68.4-1.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	freeradius-mysql-2.1.3-1.fc11.ppc requires libmysqlclient_r.so.15
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc requires libmysqlclient.so.15
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc requires libmysqlclient.so.15
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc requires libmysqlclient.so.15
	nagios-plugins-mysql-1.4.13-12.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	ntop-3.3.8-1.fc10.ppc requires libmysqlclient_r.so.15
	ntop-3.3.8-1.fc10.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	nuauth-log-mysql-2.2.20-6.fc11.ppc requires libmysqlclient_r.so.15
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.ppc requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc requires libmysqlclient.so.15
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.ppc requires libmysqlclient.so.15
	pure-ftpd-1.0.21-17.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	qof-0.7.5-3.fc10.ppc requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc requires libmysqlclient.so.15
	rekall-mysql-2.4.6-7.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc requires libmysqlclient.so.15
	rsyslog-mysql-3.21.9-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	ser-mysql-0.9.6-15.fc10.ppc requires libmysqlclient.so.15
	ser-mysql-0.9.6-15.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	ulogd-mysql-1.24-9.fc9.ppc requires libmysqlclient.so.15
	ulogd-mysql-1.24-9.fc9.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	zoneminder-1.23.3-2.fc11.ppc requires libmysqlclient.so.15
	zoneminder-1.23.3-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for ppc64
----------------------------------------------------------
	Io-language-mysql-20071010-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	Io-language-mysql-20071010-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	32:bind-sdb-9.6.0-3.P1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	cherokee-0.11.6-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	1:dovecot-mysql-1.1.8-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	exim-mysql-4.69-8.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	exim-mysql-4.69-8.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	freeradius-mysql-2.1.3-1.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	libpreludedb-mysql-0.9.15.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	lighttpd-mod_mysql_vhost-1.4.20-6.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	nagios-plugins-mysql-1.4.13-12.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ntop-3.3.8-1.fc10.ppc64 requires libmysqlclient_r.so.15()(64bit)
	ntop-3.3.8-1.fc10.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	nuauth-log-mysql-2.2.20-6.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.ppc64 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	proftpd-mysql-1.3.2-0.2.rc3.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	publican-0.40-1.fc11.noarch requires cjkunifonts-uming
	pure-ftpd-1.0.21-17.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	pure-ftpd-1.0.21-17.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rekall-mysql-2.4.6-7.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	rsyslog-mysql-3.21.9-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	ser-mysql-0.9.6-15.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ser-mysql-0.9.6-15.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	ulogd-mysql-1.24-9.fc9.ppc64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	zoneminder-1.23.3-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)





From lsof at nodata.co.uk  Sat Jan 24 11:02:27 2009
From: lsof at nodata.co.uk (nodata)
Date: Sat, 24 Jan 2009 12:02:27 +0100
Subject: Root Logins in X...
In-Reply-To: <20090124041605.GA1062410@hiwaay.net>
References: <49781C9C.4000007@redhat.com>
	<1232752023.7946.1.camel@localhost.localdomain>
	<604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>
	<20090124041605.GA1062410@hiwaay.net>
Message-ID: <1232794947.10328.0.camel@localhost.localdomain>

Am Freitag, den 23.01.2009, 22:16 -0600 schrieb Chris Adams:
> Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> > The better question is, how do we expect a user of a predominated self
> > administered system to recover in the edge cases like this?  The
> > current default partitioning layout certainly is not designed to
> > prevent this particular edge case from happening.
> 
> Well, "user can't log in because /home is full" is being used as a
> reason here.  Is that the real situation - if /home is full, can users
> really not log in?  If that is the case, that's broke and should be
> fixed.  The user should be able to log in and remove files.
> 

+1

(and I notice that it's difficult to actually fill a disk)



From debarshi.ray at gmail.com  Sat Jan 24 11:03:33 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Sat, 24 Jan 2009 16:33:33 +0530
Subject: libedit soname bump
Message-ID: <3170f42f0901240303t7c93a18bj5dd8ea5fd6758d77@mail.gmail.com>

A new snapshot of libedit [1] is now available and it involves a bump
in the soname. Here is the relevant ChangeLog entry:

2009-01-11  Jess Thrysoee

   * version-info: 0:28:0

   * all: sync with upstream source. MAJOR.MINOR version is now 3.0.
	This is due to NetBSD changing time_t and dev_t to 64 bits. It does
	not really effect this package.

   * configure.ac: Remove '--enable-debug' configure flag. The autoconf way
	to control flags is by specifying them when running configure,
	e.g. 'CFLAGS="-O0 -g" ./configure'

I am planning to update libedit _after_ Fedora 11 Alpha has been
released. According to "repoquery --whatrequires `repoquery --provides
libedit`" the following packages depending on libedit will be affected
by this change:

asterisk
ghc
libreadline-java
Io-language
php-pecl-xdebug
openssh-clients

What do you think?

Happy hacking,
Debarshi

----
[1] http://www.thrysoee.dk/editline/libedit-20090111-3.0.tar.gz



From ngompa13 at gmail.com  Sat Jan 24 11:14:48 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Sat, 24 Jan 2009 05:14:48 -0600
Subject: Root Logins in X...
In-Reply-To: <1232794947.10328.0.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>
	<1232752023.7946.1.camel@localhost.localdomain>
	<604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>
	<20090124041605.GA1062410@hiwaay.net>
	<1232794947.10328.0.camel@localhost.localdomain>
Message-ID: <8278b1b0901240314m48fff9d2od8078f6e8cec7563@mail.gmail.com>

+1
For me, it is quite easy to fill up my hard disk, I already filled up my
flash drives, my secondary hard disks, and I am already nearing full on my
/home directory.

On Sat, Jan 24, 2009 at 5:02 AM, nodata <lsof at nodata.co.uk> wrote:

> Am Freitag, den 23.01.2009, 22:16 -0600 schrieb Chris Adams:
> > Once upon a time, Jeff Spaleta <jspaleta at gmail.com> said:
> > > The better question is, how do we expect a user of a predominated self
> > > administered system to recover in the edge cases like this?  The
> > > current default partitioning layout certainly is not designed to
> > > prevent this particular edge case from happening.
> >
> > Well, "user can't log in because /home is full" is being used as a
> > reason here.  Is that the real situation - if /home is full, can users
> > really not log in?  If that is the case, that's broke and should be
> > fixed.  The user should be able to log in and remove files.
> >
>
> +1
>
> (and I notice that it's difficult to actually fill a disk)
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/1e21d722/attachment.htm>

From kevin.kofler at chello.at  Sat Jan 24 11:19:16 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 24 Jan 2009 12:19:16 +0100
Subject: libedit soname bump
References: <3170f42f0901240303t7c93a18bj5dd8ea5fd6758d77@mail.gmail.com>
Message-ID: <gletfk$23j$1@ger.gmane.org>

Debarshi Ray wrote:
>    * all: sync with upstream source. MAJOR.MINOR version is now 3.0.
> This is due to NetBSD changing time_t and dev_t to 64 bits. It does
> not really effect this package.

Then we should patch it to use the old soname. It's also logically correct
because time_t is not 64-bits on 32-bit Fedora.

        Kevin Kofler



From lsof at nodata.co.uk  Sat Jan 24 11:20:51 2009
From: lsof at nodata.co.uk (nodata)
Date: Sat, 24 Jan 2009 12:20:51 +0100
Subject: Root Logins in X...
In-Reply-To: <8278b1b0901240314m48fff9d2od8078f6e8cec7563@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<1232752023.7946.1.camel@localhost.localdomain>
	<604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>
	<20090124041605.GA1062410@hiwaay.net>
	<1232794947.10328.0.camel@localhost.localdomain>
	<8278b1b0901240314m48fff9d2od8078f6e8cec7563@mail.gmail.com>
Message-ID: <1232796051.10328.1.camel@localhost.localdomain>

Am Samstag, den 24.01.2009, 05:14 -0600 schrieb King InuYasha:
>  +1
> 
> 
> For me, it is quite easy to fill up my hard disk, I already filled up
> my flash drives, my secondary hard disks, and I am already nearing
> full on my /home directory.

Try filling it completely though, I bet you have trouble.




From thomas.moschny at gmail.com  Sat Jan 24 11:49:46 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sat, 24 Jan 2009 12:49:46 +0100
Subject: rawhide report: 20090124 changes
In-Reply-To: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
Message-ID: <a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>

2009/1/24 Rawhide Report <rawhide at fedoraproject.org>:

> pam_mysql-0.7-0.6.rc1.fc11.2

Why isn't that simply named "pam_mysql-0.7-0.7.rc1.fc11", or even
"...-N.rc1.fc11", N being a single integer?

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From konrad at tylerc.org  Sat Jan 24 11:53:07 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 24 Jan 2009 03:53:07 -0800
Subject: rawhide report: 20090124 changes
In-Reply-To: <a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
	<a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>
Message-ID: <200901240353.07467.konrad@tylerc.org>

On Saturday 24 January 2009 03:49:46 am Thomas Moschny wrote:
> 2009/1/24 Rawhide Report <rawhide at fedoraproject.org>:
> > pam_mysql-0.7-0.6.rc1.fc11.2
>
> Why isn't that simply named "pam_mysql-0.7-0.7.rc1.fc11", or even
> "...-N.rc1.fc11", N being a single integer?

http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From thomas.moschny at gmail.com  Sat Jan 24 11:56:05 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sat, 24 Jan 2009 12:56:05 +0100
Subject: rawhide report: 20090124 changes
In-Reply-To: <200901240353.07467.konrad@tylerc.org>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
	<a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>
	<200901240353.07467.konrad@tylerc.org>
Message-ID: <a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>

2009/1/24 Conrad Meyer <konrad at tylerc.org>:
> On Saturday 24 January 2009 03:49:46 am Thomas Moschny wrote:
>> 2009/1/24 Rawhide Report <rawhide at fedoraproject.org>:
>> > pam_mysql-0.7-0.6.rc1.fc11.2
>>
>> Why isn't that simply named "pam_mysql-0.7-0.7.rc1.fc11", or even
>> "...-N.rc1.fc11", N being a single integer?
>
> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages

Yes, that explains -0.N, but not the .2 at the end.

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From konrad at tylerc.org  Sat Jan 24 11:59:57 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Sat, 24 Jan 2009 03:59:57 -0800
Subject: rawhide report: 20090124 changes
In-Reply-To: <a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
	<200901240353.07467.konrad@tylerc.org>
	<a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
Message-ID: <200901240359.57423.konrad@tylerc.org>

On Saturday 24 January 2009 03:56:05 am Thomas Moschny wrote:
> 2009/1/24 Conrad Meyer <konrad at tylerc.org>:
> > On Saturday 24 January 2009 03:49:46 am Thomas Moschny wrote:
> >> 2009/1/24 Rawhide Report <rawhide at fedoraproject.org>:
> >> > pam_mysql-0.7-0.6.rc1.fc11.2
> >>
> >> Why isn't that simply named "pam_mysql-0.7-0.7.rc1.fc11", or even
> >> "...-N.rc1.fc11", N being a single integer?
> >
> > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_pack
> >ages
>
> Yes, that explains -0.N, but not the .2 at the end.

Generally that is used if you need to fix something in a lower branch that 
otherwise has the same version as a higher branch without bumping the higher 
branch(es). For example:

foo-5-1.fc11
foo-5-1.fc10

And we need to fix something F-10 specific:

foo-5-1.fc11
foo-5-1.fc10.1

still follows F-11 > F-10 (upgrade path). However, I'm not sure why this is 
being added to a rawhide (or F-11) package.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>




From thomas.moschny at gmail.com  Sat Jan 24 12:07:28 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Sat, 24 Jan 2009 13:07:28 +0100
Subject: rawhide report: 20090124 changes
In-Reply-To: <200901240359.57423.konrad@tylerc.org>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
	<200901240353.07467.konrad@tylerc.org>
	<a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
	<200901240359.57423.konrad@tylerc.org>
Message-ID: <a9d183c80901240407s5c4e267bn68a1e6d23c912f01@mail.gmail.com>

2009/1/24 Conrad Meyer <konrad at tylerc.org>:
> Generally that is used if you need to fix something in a lower branch that
> otherwise has the same version as a higher branch without bumping the higher
> branch(es). For example:

Ah, right. Thanks for reminding me.

> However, I'm not sure why this is being added to a rawhide (or F-11) package.


Regards,

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From bochecha at fedoraproject.org  Sat Jan 24 12:10:55 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Sat, 24 Jan 2009 13:10:55 +0100
Subject: Claiming ownership of orphaned packages
Message-ID: <2d319b780901240410s2a30eb32y73060dee5089a1ba@mail.gmail.com>

Hi,

This is my first message on this list :)

I'm writing to claim ownership of two orphaned packages that are
needed by the Fedora OLPC project :
- https://admin.fedoraproject.org/pkgdb/packages/name/abyssinica-fonts
- https://admin.fedoraproject.org/pkgdb/packages/name/nafees-web-naskh-fonts

Regards,


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From wolfy at nobugconsulting.ro  Sat Jan 24 12:18:32 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 24 Jan 2009 14:18:32 +0200
Subject: rawhide report: 20090124 changes
In-Reply-To: <a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>	<a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>	<200901240353.07467.konrad@tylerc.org>
	<a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
Message-ID: <497B0718.4080204@nobugconsulting.ro>

On 01/24/2009 01:56 PM, Thomas Moschny wrote:
> 2009/1/24 Conrad Meyer <konrad at tylerc.org>:
>   
>> On Saturday 24 January 2009 03:49:46 am Thomas Moschny wrote:
>>     
>>> 2009/1/24 Rawhide Report <rawhide at fedoraproject.org>:
>>>       
>>>> pam_mysql-0.7-0.6.rc1.fc11.2
>>>>         
>>> Why isn't that simply named "pam_mysql-0.7-0.7.rc1.fc11", or even
>>> "...-N.rc1.fc11", N being a single integer?
>>>       
>> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages
>>     
>
> Yes, that explains -0.N, but not the .2 at the end.
>
>   
You are correct, 0.7-07 / 0.7-0.8 would have been correct. But I am not 
the primary maintainer and I wanted to be sure that Paul's (i.e. primary 
maintainer) local tree is not affected by any changes that I made. And I 
have also tried to emphasize that these were just rebuilds without any 
change in functionality at all.



From fedora at leemhuis.info  Sat Jan 24 12:20:09 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 24 Jan 2009 13:20:09 +0100
Subject: support for latest (radeon) hardware (was: Re: Xorg plans for F10?)
In-Reply-To: <tm4p46xld8.ln2@ppp1053.in.ipex.cz>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>
Message-ID: <497B0779.7020708@leemhuis.info>

On 23.01.2009 16:35, Matej Cepl wrote:
> On 2009-01-23, 04:31 GMT, Orion Poplawski wrote:
>> Are there any plans to get ati driver 6.10 into F10?  I'm getting pretty
>> lousy results with 6.9 in F10 on my RV370, but promising results with 6.10
>> and Xorg server 1.5.99.  It doesn't work with 1.5.3 though it installs
>> without any rpm/dependency issues.  Anything on the wiki about current
>> Xorg plans?
> I asked about that our X guys, and airlied (our ATI magician 
> in-house) told me that a) there is not that much difference 
> between 6.9 and 6.10,

I compared radeon.xinf from 6.9 and 6.10 and found a few important cards 
that 6.10 supports, but 6.9 does not:

"""
>> alias pcivideo:v00001002d0000944Asv*sd*bc*sc*i* radeon # ATI Mobility RADEON HD 4850
>> alias pcivideo:v00001002d0000944Bsv*sd*bc*sc*i* radeon # ATI Mobility RADEON HD 4850 X2
>> alias pcivideo:v00001002d0000945Asv*sd*bc*sc*i* radeon # ATI Mobility RADEON HD 4870
>> alias pcivideo:v00001002d00009490sv*sd*bc*sc*i* radeon # ATI RV730XT [Radeon HD 4670]
>> alias pcivideo:v00001002d00009498sv*sd*bc*sc*i* radeon # ATI RV730 PRO [Radeon HD 4650]
>> alias pcivideo:v00001002d00009540sv*sd*bc*sc*i* radeon # ATI Radeon HD 4550
>> alias pcivideo:v00001002d0000954Fsv*sd*bc*sc*i* radeon # ATI Radeon HD 4350
"""

E.g. most of the models from the current 4xxx series. I'd call that a 
big difference between 6.9 and 6.10 and a very good reason to get 6.10 
(or the parts of the code that make those cards work) into F10 as 
update, as those cards are quite popular these days. Sure, users can

* configure xorg-x11-drv-radeonhd to get their hardware running
* switch to rawhide to get it running
* rebuild the srpm from rawhide to get it running.
* switch to another distro that has more up2date drivers
* wait till F11 comes out

But those options are all bad IMHO. Especially the option "wait till F11 
comes out", because letting users out in the cold without drivers for up 
multiple month sounds stupid to me when those drivers exist already -- 
especially as new graphic card series come out every 6 to 12 months, 
which means we'll run into the same problem quite soon again.

 > [...]

CU
knurd



From wolfy at nobugconsulting.ro  Sat Jan 24 12:24:20 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 24 Jan 2009 14:24:20 +0200
Subject: Root Logins in X...
In-Reply-To: <1232796051.10328.1.camel@localhost.localdomain>
References: <49781C9C.4000007@redhat.com>	<1232752023.7946.1.camel@localhost.localdomain>	<604aa7910901231543ua8a31f6pa0adc0c554fc4715@mail.gmail.com>	<20090124041605.GA1062410@hiwaay.net>	<1232794947.10328.0.camel@localhost.localdomain>	<8278b1b0901240314m48fff9d2od8078f6e8cec7563@mail.gmail.com>
	<1232796051.10328.1.camel@localhost.localdomain>
Message-ID: <497B0874.907@nobugconsulting.ro>

On 01/24/2009 01:20 PM, nodata wrote:
> Am Samstag, den 24.01.2009, 05:14 -0600 schrieb King InuYasha:
>   
>>  +1
>>
>>
>> For me, it is quite easy to fill up my hard disk, I already filled up
>> my flash drives, my secondary hard disks, and I am already nearing
>> full on my /home directory.
>>     
>
> Try filling it completely though, I bet you have trouble.
>   
I almost always do a tune2fs -m0 or a mke2fs -m0, so do not bet with me :)



From drago01 at gmail.com  Sat Jan 24 13:17:40 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 24 Jan 2009 14:17:40 +0100
Subject: plans for kernel in F10?
In-Reply-To: <5f6f8c5f0901212243o2e96c075r1715a5cb95a08c27@mail.gmail.com>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
	<5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>
	<20090122012941.GA3657@yoda.jdub.homelinux.org>
	<5f6f8c5f0901212243o2e96c075r1715a5cb95a08c27@mail.gmail.com>
Message-ID: <f6ca9fed0901240517x7169366djf55897a3a3b326d1@mail.gmail.com>

On Thu, Jan 22, 2009 at 7:43 AM, Joshua C. <joshuacov at googlemail.com> wrote:
> 2009/1/22 Josh Boyer <jwboyer at gmail.com>:
>> To my knowledge, not soon.  .28 kernel mode setting and the X version
>> in F9 don't get along.
>>
>> josh
>>
> Maybe it's time to go to f10. But I still have problems with this mode setting.

you can disable it (pass no modset to the kernel) and fill a bug to get it fixed



From drago01 at gmail.com  Sat Jan 24 14:17:09 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 24 Jan 2009 15:17:09 +0100
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
Message-ID: <f6ca9fed0901240617y299d9ee4l309e255a723f0c48@mail.gmail.com>

2009/1/22 Dr. Diesel <dr.diesel at gmail.com>:
>

> We are about choice,

no.. https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html

> ask the user during install if he/she wants to prevent
> root logg-ins.

Asking the user stupid questions that they don't understand during
install does not solve anything.



From navneetrastogi99 at gmail.com  Sat Jan 24 14:40:35 2009
From: navneetrastogi99 at gmail.com (navneet rastogi)
Date: Sat, 24 Jan 2009 20:10:35 +0530
Subject: how to share internet over a wifi network
Message-ID: <b081db690901240640h26b74630wc07031474bd93046@mail.gmail.com>

Can anyone help me to establishing a WiFi network for internet sharing?
How to configure a LAN in FEDORA10?



From sundaram at fedoraproject.org  Sat Jan 24 14:54:27 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 24 Jan 2009 20:24:27 +0530
Subject: how to share internet over a wifi network
In-Reply-To: <b081db690901240640h26b74630wc07031474bd93046@mail.gmail.com>
References: <b081db690901240640h26b74630wc07031474bd93046@mail.gmail.com>
Message-ID: <497B2BA3.7050903@fedoraproject.org>

navneet rastogi wrote:
> Can anyone help me to establishing a WiFi network for internet sharing?
> How to configure a LAN in FEDORA10?

http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/

LAN - depends on what you want to configure but take a look at 
system-config-network.

Please redirect end user help questions to fedora-list in the future.

http://fedoraproject.org/wiki/PostIsOffTopic

Rahul



From nicolas.mailhot at laposte.net  Sat Jan 24 14:54:38 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 24 Jan 2009 15:54:38 +0100
Subject: Claiming ownership of orphaned packages
In-Reply-To: <2d319b780901240410s2a30eb32y73060dee5089a1ba@mail.gmail.com>
References: <2d319b780901240410s2a30eb32y73060dee5089a1ba@mail.gmail.com>
Message-ID: <1232808878.14502.4.camel@arekh.okg>

Le samedi 24 janvier 2009 ? 13:10 +0100, Mathieu Bridon (bochecha) a
?crit :
> Hi,

Hi,

> This is my first message on this list :)
> 
> I'm writing to claim ownership of two orphaned packages that are
> needed by the Fedora OLPC project :
> - https://admin.fedoraproject.org/pkgdb/packages/name/abyssinica-fonts
> - https://admin.fedoraproject.org/pkgdb/packages/name/nafees-web-naskh-fonts

Do not hesitate to discuss any problem you encounter on the
fedora-fonts-list ;)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/a8e56cec/attachment.sig>

From navneetrastogi99 at gmail.com  Sat Jan 24 14:58:10 2009
From: navneetrastogi99 at gmail.com (navneet rastogi)
Date: Sat, 24 Jan 2009 20:28:10 +0530
Subject: how to share internet over a wifi network
In-Reply-To: <497B2BA3.7050903@fedoraproject.org>
References: <b081db690901240640h26b74630wc07031474bd93046@mail.gmail.com>
	<497B2BA3.7050903@fedoraproject.org>
Message-ID: <b081db690901240658y3f3a1f94m6cad568469ba398b@mail.gmail.com>

thanks for helping me.

On Sat, Jan 24, 2009 at 8:24 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> navneet rastogi wrote:
>>
>> Can anyone help me to establishing a WiFi network for internet sharing?
>> How to configure a LAN in FEDORA10?
>
> http://magazine.redhat.com/2008/10/16/video-fedora-10-connection-sharing/
>
> LAN - depends on what you want to configure but take a look at
> system-config-network.
>
> Please redirect end user help questions to fedora-list in the future.
>
> http://fedoraproject.org/wiki/PostIsOffTopic
>
> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From bochecha at fedoraproject.org  Sat Jan 24 15:07:24 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Sat, 24 Jan 2009 16:07:24 +0100
Subject: Claiming ownership of orphaned packages
In-Reply-To: <1232808878.14502.4.camel@arekh.okg>
References: <2d319b780901240410s2a30eb32y73060dee5089a1ba@mail.gmail.com>
	<1232808878.14502.4.camel@arekh.okg>
Message-ID: <2d319b780901240707k5b8bb0afpe9d3403134b1d4e@mail.gmail.com>

> Do not hesitate to discuss any problem you encounter on the
> fedora-fonts-list ;)

I was about to join the list, but it looks like someone invited me :)

And yes, I have some questions to ask to the Fonts SIG about some
stuff I will need to do for those packages, but that's for later.

Regards,


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From bruno at wolff.to  Sat Jan 24 15:14:20 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 24 Jan 2009 09:14:20 -0600
Subject: support for latest (radeon) hardware (was: Re: Xorg plans for
	F10?)
In-Reply-To: <497B0779.7020708@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>
	<497B0779.7020708@leemhuis.info>
Message-ID: <20090124151420.GA21427@wolff.to>

On Sat, Jan 24, 2009 at 13:20:09 +0100,
  Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>
> I compared radeon.xinf from 6.9 and 6.10 and found a few important cards  
> that 6.10 supports, but 6.9 does not:

> * configure xorg-x11-drv-radeonhd to get their hardware running
> * switch to rawhide to get it running
> * rebuild the srpm from rawhide to get it running.
> * switch to another distro that has more up2date drivers
> * wait till F11 comes out
>
> But those options are all bad IMHO. Especially the option "wait till F11  
> comes out", because letting users out in the cold without drivers for up  
> multiple month sounds stupid to me when those drivers exist already --  
> especially as new graphic card series come out every 6 to 12 months,  
> which means we'll run into the same problem quite soon again.

The current 6.10 driver in rawhide does not work with my rv280 based card.
The Xorg.0.log file suggests that it is a problem with AGP support.
The drivers in F11 are tied to the kernels there more than in the past
because of modesetting support, so there is likely more work in getting
6.10 to work in F10 than there would have been doing something similar
in the past.

There is a lot going on right now in the driver world, so expect things to
be slow for a while. ATI released a bunch of specs. Kernel modesetting is
being turned on. Having the kernel manage the video memory is being turned
on (and changed at the same time for ATI chips). And Dave Airlie has a
new born.

In the future expect a new series of ATI chips to be a lot easier to get
support for.



From jkeating at redhat.com  Sat Jan 24 15:42:53 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Jan 2009 07:42:53 -0800
Subject: rawhide report: 20090124 changes
In-Reply-To: <497B0718.4080204@nobugconsulting.ro>
References: <20090124090220.9A9651F828C@releng2.fedora.phx.redhat.com>
	<a9d183c80901240349m49954de7obc308b0700168aa0@mail.gmail.com>
	<200901240353.07467.konrad@tylerc.org>
	<a9d183c80901240356w72705d2dsb7e6f74ac2b3de39@mail.gmail.com>
	<497B0718.4080204@nobugconsulting.ro>
Message-ID: <1232811773.8363.102.camel@localhost.localdomain>

On Sat, 2009-01-24 at 14:18 +0200, Manuel Wolfshant wrote:
>  You are correct, 0.7-07 / 0.7-0.8 would have been correct. But I am not 
> the primary maintainer and I wanted to be sure that Paul's (i.e. primary 
> maintainer) local tree is not affected by any changes that I made. And I 
> have also tried to emphasize that these were just rebuilds without any 
> change in functionality at all.

That's a good thought, but going to non-standard versioning just
confuses things.  You've made a change to the package, it's going to
"affect" Paul's local tree no matter what.

Please stick to the standard policies when changing packages,
particularly somebody else's package.  Thanks!

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/472f5cf3/attachment.sig>

From jkeating at redhat.com  Sat Jan 24 15:47:52 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Jan 2009 07:47:52 -0800
Subject: Draft guidelines for approving provenpackager
Message-ID: <1232812072.8363.104.camel@localhost.localdomain>

We don't currently have guidelines for granting access to proven
packager.  I took a work item from FESCo to create a draft for this, and
here is my first stab at it (words in camelcase exist to be replaced
with links to pages concerning them):

Provenpackager is a group of highly skilled package maintainers who are
experienced in a wide variety of package types and who are intimately
familiar with the PackagingGuidelines and MaintainerPolicies as well as
acutely aware of ReleaseSchedules and FreezePolicies.  They exist as a
group to lend a hand when help is needed, always with a desire to
improve the quality of Fedora.  By granting membership into
provenpackager for a maintainer you are confirming that at least in your
mind they meet the above criteria and that you would trust them fully
with any of the packages you either maintain or even just use.


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/4c681486/attachment.sig>

From mike at miketc.net  Sat Jan 24 16:59:05 2009
From: mike at miketc.net (Mike Chambers)
Date: Sat, 24 Jan 2009 10:59:05 -0600
Subject: GDM doesn't start
Message-ID: <1232816345.2681.1.camel@scrappy.miketc.net>

After updating my rawhide machine this morning, gdm won't start.  It
comes up and before all the graphics appear all the way, it restarts
itself.

Anyone else seeing this and/or know a fix or work around besides run
level 3?

-- 
Mike Chambers
Fedora Project - Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From rohan at rs3net.net  Sat Jan 24 17:03:04 2009
From: rohan at rs3net.net (Rohan Sheth)
Date: Sat, 24 Jan 2009 09:03:04 -0800
Subject: GDM doesn't start
In-Reply-To: <1232816345.2681.1.camel@scrappy.miketc.net>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
Message-ID: <20090124090304.4282b219@rs3net.net>

Same here just restarts over and over.

Got around it by Control+Alt+F2, login as root, kill X, login as
yourself and startx.

--Rohan

On Sat, 24 Jan 2009 10:59:05 -0600
Mike Chambers <mike at miketc.net> wrote:

> After updating my rawhide machine this morning, gdm won't start.  It
> comes up and before all the graphics appear all the way, it restarts
> itself.
> 
> Anyone else seeing this and/or know a fix or work around besides run
> level 3?
> 



From darrellpf at gmail.com  Sat Jan 24 17:03:25 2009
From: darrellpf at gmail.com (darrell pfeifer)
Date: Sat, 24 Jan 2009 09:03:25 -0800
Subject: GDM doesn't start
In-Reply-To: <1232816345.2681.1.camel@scrappy.miketc.net>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
Message-ID: <f6e5806f0901240903u49decff9yd3b36a02f14c2645@mail.gmail.com>

On Sat, Jan 24, 2009 at 08:59, Mike Chambers <mike at miketc.net> wrote:

> After updating my rawhide machine this morning, gdm won't start.  It
> comes up and before all the graphics appear all the way, it restarts
> itself.
>
> Anyone else seeing this and/or know a fix or work around besides run
> level 3?
>

I'm seeing the same thing.

I tried backing out to an earlier version of gtk2 but that was unsuccessful.

So yes, for now it's runlevel 3 and startx which works fine.

darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/c699db72/attachment.htm>

From jos at xos.nl  Sat Jan 24 17:03:23 2009
From: jos at xos.nl (Jos Vos)
Date: Sat, 24 Jan 2009 18:03:23 +0100
Subject: GDM doesn't start
In-Reply-To: <1232816345.2681.1.camel@scrappy.miketc.net>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
Message-ID: <20090124170323.GA31513@jasmine.xos.nl>

On Sat, Jan 24, 2009 at 10:59:05AM -0600, Mike Chambers wrote:

> Anyone else seeing this and/or know a fix or work around besides run
> level 3?

Is /var/log/Xorg.0.log saying something that may help?

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From mike at miketc.net  Sat Jan 24 17:19:01 2009
From: mike at miketc.net (Mike Chambers)
Date: Sat, 24 Jan 2009 11:19:01 -0600
Subject: GDM doesn't start
In-Reply-To: <20090124170323.GA31513@jasmine.xos.nl>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
	<20090124170323.GA31513@jasmine.xos.nl>
Message-ID: <1232817541.2681.4.camel@scrappy.miketc.net>

On Sat, 2009-01-24 at 18:03 +0100, Jos Vos wrote:
> On Sat, Jan 24, 2009 at 10:59:05AM -0600, Mike Chambers wrote:
> 
> > Anyone else seeing this and/or know a fix or work around besides run
> > level 3?
> 
> Is /var/log/Xorg.0.log saying something that may help?

No errors in the log, as with startx it works just fine.  Below is
my /var/log/gdm/:0-greeter.log file that may help show something.

http://www.miketc.net/greeter.log

I tried adding the timed login feature to gdm to try and bypass the
restarts, so there may be some errors about that in case someone was
wondering.

-- 
Mike Chambers
Fedora Project - Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From mike at miketc.net  Sat Jan 24 17:20:19 2009
From: mike at miketc.net (Mike Chambers)
Date: Sat, 24 Jan 2009 11:20:19 -0600
Subject: GDM doesn't start
In-Reply-To: <20090124170323.GA31513@jasmine.xos.nl>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
	<20090124170323.GA31513@jasmine.xos.nl>
Message-ID: <1232817619.2681.6.camel@scrappy.miketc.net>

On Sat, 2009-01-24 at 18:03 +0100, Jos Vos wrote:
> On Sat, Jan 24, 2009 at 10:59:05AM -0600, Mike Chambers wrote:
> 
> > Anyone else seeing this and/or know a fix or work around besides run
> > level 3?
> 
> Is /var/log/Xorg.0.log saying something that may help?

I also noticed, and I am mentioning this in case they are same problem,
that when hitting reply, the "Send" Button and  the "Attach" button in
evolution appear, but the icons/text don't.

-- 
Mike Chambers
Fedora Project - Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From fedora at leemhuis.info  Sat Jan 24 17:34:08 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 24 Jan 2009 18:34:08 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <20090124151420.GA21427@wolff.to>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to>
Message-ID: <497B5110.8000800@leemhuis.info>

On 24.01.2009 16:14, Bruno Wolff III wrote:
> On Sat, Jan 24, 2009 at 13:20:09 +0100,
>   Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> I compared radeon.xinf from 6.9 and 6.10 and found a few important cards  
>> that 6.10 supports, but 6.9 does not:
> 
>> * configure xorg-x11-drv-radeonhd to get their hardware running
>> * switch to rawhide to get it running
>> * rebuild the srpm from rawhide to get it running.
>> * switch to another distro that has more up2date drivers
>> * wait till F11 comes out
>>
>> But those options are all bad IMHO. Especially the option "wait till F11  
>> comes out", because letting users out in the cold without drivers for up  
>> multiple month sounds stupid to me when those drivers exist already --  
>> especially as new graphic card series come out every 6 to 12 months,  
>> which means we'll run into the same problem quite soon again.
> The current 6.10 driver in rawhide does not work with my rv280 based card.
> The Xorg.0.log file suggests that it is a problem with AGP support.

Well, that needs to be fixed then sooner or later anyway. But that's a 
different topic.

> The drivers in F11 are tied to the kernels there more than in the past
> because of modesetting support, so there is likely more work in getting
> 6.10 to work in F10 than there would have been doing something similar
> in the past.

You have a point, nevertheless I don't think that point is that 
important as modesetting for radeon is in both F10 and rawhide. Further: 
2.6.28 (which was in rawhide until a few weeks ago) will soon be in F10, 
2.6.29 (which is in rawhide) will likely sooner or later get into F10. 
So that relation needs constant maintenance work already in any case.

> There is a lot going on right now in the driver world, so expect things to
> be slow for a while. ATI released a bunch of specs. Kernel modesetting is
> being turned on. Having the kernel manage the video memory is being turned
> on (and changed at the same time for ATI chips). And Dave Airlie has a new born.

(As a lot of people will know) I'm well aware of all of that ;-) (BTW: 
congrats for your little girl Dave!).

But it's not like I requested a update to 6.10 immediately. It's just 
that the mail I replied to sounded a bit like "6.10 for F10 is unlikely 
in general". That's *IMHO* bad. Mainly for two reasons:

* regular users will go and install the fglrx drivers, as those offer 
support for the 4xxxx series; that is something most of us don't want 
users to do, hence we should offer them a better solution

* Fedora in most areas is good for new hardware, as you get new drivers 
(hplip, gutenprint, sane,...) and even new kernels as regular update, 
which improves hardware support (especially for current hardware) over 
time. But Fedora not only would be "good for new hardware", it could 
have "fantastic support for new hardware" if support for other new 
hardware (like the big bunch of the Radeon HD 4xxx series) also could 
find it's way into the stable distro.

 > [...]

Cu
knurd



From jkeating at redhat.com  Sat Jan 24 17:51:00 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Jan 2009 09:51:00 -0800
Subject: support for latest (radeon) hardware
In-Reply-To: <497B5110.8000800@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to>  <497B5110.8000800@leemhuis.info>
Message-ID: <1232819460.8363.106.camel@localhost.localdomain>

On Sat, 2009-01-24 at 18:34 +0100, Thorsten Leemhuis wrote:
>  
> * Fedora in most areas is good for new hardware, as you get new drivers 
> (hplip, gutenprint, sane,...) and even new kernels as regular update, 
> which improves hardware support (especially for current hardware) over 
> time. But Fedora not only would be "good for new hardware", it could 
> have "fantastic support for new hardware" if support for other new 
> hardware (like the big bunch of the Radeon HD 4xxx series) also could 
> find it's way into the stable distro.

Keep in mind that this constant kernel revving comes with a cost.  Look
at the bodhi karma each time we try to bring a new kernel version to a
release.  For everything we fix, we likely break something else (like
various sound issues on intel recently).  Upstream isn't perfect, and if
I had to choose between supporting new people, or keeping existing
people unbroken, I'll choose on the side of existing people every time.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/e66dc24e/attachment.sig>

From greno at verizon.net  Sat Jan 24 18:01:13 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 24 Jan 2009 13:01:13 -0500
Subject: RPM: how to find installed differences?
Message-ID: <497B5769.5050701@verizon.net>

Does anyone know of a way to find the differences between an 
installation and its original RPM?

Regards,
Gerry



From bruno at wolff.to  Sat Jan 24 18:04:34 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 24 Jan 2009 12:04:34 -0600
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5769.5050701@verizon.net>
References: <497B5769.5050701@verizon.net>
Message-ID: <20090124180434.GA3537@wolff.to>

On Sat, Jan 24, 2009 at 13:01:13 -0500,
  Gerry Reno <greno at verizon.net> wrote:
> Does anyone know of a way to find the differences between an  
> installation and its original RPM?

rpm -V will tell you about installed files that don't match what was in
the rpm. This doesn't handle files created by install scripts, but only
a few things create files in install scripts.



From greno at verizon.net  Sat Jan 24 18:10:36 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 24 Jan 2009 13:10:36 -0500
Subject: RPM: how to find installed differences?
In-Reply-To: <20090124180434.GA3537@wolff.to>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
Message-ID: <497B599C.8040801@verizon.net>

Bruno Wolff III wrote:
> On Sat, Jan 24, 2009 at 13:01:13 -0500,
>   Gerry Reno <greno at verizon.net> wrote:
>   
>> Does anyone know of a way to find the differences between an  
>> installation and its original RPM?
>>     
>
> rpm -V will tell you about installed files that don't match what was in
> the rpm. This doesn't handle files created by install scripts, but only
> a few things create files in install scripts.
>
>   
Ok, that sort of works to get some information about which files have 
some changes. It doesn't show any new files that may have been added to 
the installation though.

Regards,
Gerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/4d6af8e8/attachment.htm>

From cdahlin at redhat.com  Sat Jan 24 18:14:51 2009
From: cdahlin at redhat.com (Casey Dahlin)
Date: Sat, 24 Jan 2009 13:14:51 -0500
Subject: RPM: how to find installed differences?
In-Reply-To: <497B599C.8040801@verizon.net>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net>
Message-ID: <497B5A9B.40208@redhat.com>

Gerry Reno wrote:
> Bruno Wolff III wrote:
>> On Sat, Jan 24, 2009 at 13:01:13 -0500,
>>   Gerry Reno <greno at verizon.net> wrote:
>>   
>>> Does anyone know of a way to find the differences between an  
>>> installation and its original RPM?
>>>     
>>
>> rpm -V will tell you about installed files that don't match what was in
>> the rpm. This doesn't handle files created by install scripts, but only
>> a few things create files in install scripts.
>>
>>   
> Ok, that sort of works to get some information about which files have 
> some changes.  It doesn't show any new files that may have been added 
> to the installation though.
>
> Regards,
> Gerry
>
How would it know?

--CJD



From greno at verizon.net  Sat Jan 24 18:22:02 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 24 Jan 2009 13:22:02 -0500
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5A9B.40208@redhat.com>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net> <497B5A9B.40208@redhat.com>
Message-ID: <497B5C4A.5010405@verizon.net>

Casey Dahlin wrote:
> Gerry Reno wrote:
>> Bruno Wolff III wrote:
>>> On Sat, Jan 24, 2009 at 13:01:13 -0500,
>>>   Gerry Reno <greno at verizon.net> wrote:
>>>  
>>>> Does anyone know of a way to find the differences between an  
>>>> installation and its original RPM?
>>>>     
>>>
>>> rpm -V will tell you about installed files that don't match what was in
>>> the rpm. This doesn't handle files created by install scripts, but only
>>> a few things create files in install scripts.
>>>
>>>   
>> Ok, that sort of works to get some information about which files have 
>> some changes.  It doesn't show any new files that may have been added 
>> to the installation though.
>>
> How would it know?
>
Well, what I was hoping was that there was a tool that could install the 
original RPM into a sandbox and then compare the differences between the 
sandbox install and the existing installation and report the differences.
The problem that I'm trying to solve is inevitably we make changes to 
installations due to many reasons; bug fixes, config changes, security 
patches, etc.  Then when we want to upgrade to a later version of that 
installation we don't always know exactly what has been changed in the 
installation since we first installed it.  I looking for a way to see 
all changes in the installation, whether to original files or newly 
added files, as compared to the original RPM.

Regards,
Gerry



From bruno at wolff.to  Sat Jan 24 18:29:32 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 24 Jan 2009 12:29:32 -0600
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5C4A.5010405@verizon.net>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net> <497B5A9B.40208@redhat.com>
	<497B5C4A.5010405@verizon.net>
Message-ID: <20090124182932.GA15263@wolff.to>

On Sat, Jan 24, 2009 at 13:22:02 -0500,
  Gerry Reno <greno at verizon.net> wrote:
> Well, what I was hoping was that there was a tool that could install the  
> original RPM into a sandbox and then compare the differences between the  
> sandbox install and the existing installation and report the differences.
> The problem that I'm trying to solve is inevitably we make changes to  
> installations due to many reasons; bug fixes, config changes, security  
> patches, etc.  Then when we want to upgrade to a later version of that  
> installation we don't always know exactly what has been changed in the  
> installation since we first installed it.  I looking for a way to see  
> all changes in the installation, whether to original files or newly  
> added files, as compared to the original RPM.

How is rpm supposed to know that some new file is considered by you to be
owned by it?

What you could do is use rpm to see what package provides a file that you
want to check and if none does, than it would be a new file (or in a few
cases one created by an install script).



From denis at poolshark.org  Sat Jan 24 18:33:35 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 24 Jan 2009 19:33:35 +0100
Subject: RPM: how to find installed differences?
In-Reply-To: <20090124182932.GA15263@wolff.to>
References: <497B5769.5050701@verizon.net>
	<20090124180434.GA3537@wolff.to>	<497B599C.8040801@verizon.net>
	<497B5A9B.40208@redhat.com>	<497B5C4A.5010405@verizon.net>
	<20090124182932.GA15263@wolff.to>
Message-ID: <497B5EFF.3040107@poolshark.org>

Bruno Wolff III wrote:
> On Sat, Jan 24, 2009 at 13:22:02 -0500,
>   Gerry Reno <greno at verizon.net> wrote:
>> Well, what I was hoping was that there was a tool that could install the  
>> original RPM into a sandbox and then compare the differences between the  
>> sandbox install and the existing installation and report the differences.
>> The problem that I'm trying to solve is inevitably we make changes to  
>> installations due to many reasons; bug fixes, config changes, security  
>> patches, etc.  Then when we want to upgrade to a later version of that  
>> installation we don't always know exactly what has been changed in the  
>> installation since we first installed it.  I looking for a way to see  
>> all changes in the installation, whether to original files or newly  
>> added files, as compared to the original RPM.

You may simply want to write a script to do this comparison, or dump the 
contents of those 2 commands :

  # rpm -ql yourpackage > file1
  # rpm -ql yourpackage.xxx.rpm > file2

and compare the 2 outputs with a tool like 'meld' or with emacs

If you want to install an RPM file into a sandbox, that's easily done with :

# rpm2cpio foo.rpm | cpio -id



From tmz at pobox.com  Sat Jan 24 18:35:48 2009
From: tmz at pobox.com (Todd Zullinger)
Date: Sat, 24 Jan 2009 13:35:48 -0500
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5C4A.5010405@verizon.net>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net> <497B5A9B.40208@redhat.com>
	<497B5C4A.5010405@verizon.net>
Message-ID: <20090124183548.GL25716@inocybe.teonanacatl.org>

Gerry Reno wrote:
> Well, what I was hoping was that there was a tool that could install
> the original RPM into a sandbox and then compare the differences
> between the sandbox install and the existing installation and report
> the differences.

It shouldn't be all that hard to whip up a script for that task.  You
can use rpmdev-extract from rpmdevtools to unpack the original rpm
into a tmp dir, then diff the files in there against what's on the
filesystem.  It could be a handy script to add to rpmdevtools perhaps.

In fact, you may be able to extend the existing rpmdev-diff script to
handle comparing a package with the installed files on the system.

Of course, any moment now I expect someone to chime in and say such a
script already exists. :)

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's not denial. I'm just very selective about what I accept as
reality.
    -- Calvin ("Calvin and Hobbes")

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 542 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/b0d5847b/attachment.sig>

From denis at poolshark.org  Sat Jan 24 18:36:44 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 24 Jan 2009 19:36:44 +0100
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5EFF.3040107@poolshark.org>
References: <497B5769.5050701@verizon.net>	<20090124180434.GA3537@wolff.to>	<497B599C.8040801@verizon.net>	<497B5A9B.40208@redhat.com>	<497B5C4A.5010405@verizon.net>	<20090124182932.GA15263@wolff.to>
	<497B5EFF.3040107@poolshark.org>
Message-ID: <497B5FBC.3060804@poolshark.org>

Denis Leroy wrote:
>  # rpm -ql yourpackage.xxx.rpm > file2

that's "rpm -qlp"



From fedora at leemhuis.info  Sat Jan 24 18:23:16 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 24 Jan 2009 19:23:16 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <1232819460.8363.106.camel@localhost.localdomain>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
Message-ID: <497B5C94.4000203@leemhuis.info>

On 24.01.2009 18:51, Jesse Keating wrote:
> On Sat, 2009-01-24 at 18:34 +0100, Thorsten Leemhuis wrote:
>>  
>> * Fedora in most areas is good for new hardware, as you get new drivers 
>> (hplip, gutenprint, sane,...) and even new kernels as regular update, 
>> which improves hardware support (especially for current hardware) over 
>> time. But Fedora not only would be "good for new hardware", it could 
>> have "fantastic support for new hardware" if support for other new 
>> hardware (like the big bunch of the Radeon HD 4xxx series) also could 
>> find it's way into the stable distro.
> Keep in mind that this constant kernel revving comes with a cost. 

Sure, I'm well aware of it.

> Look
> at the bodhi karma each time we try to bring a new kernel version to a
> release.  For everything we fix, we likely break something else (like
> various sound issues on intel recently).  Upstream isn't perfect, and if
> I had to choose between supporting new people, or keeping existing
> people unbroken, I'll choose on the side of existing people every time.

I partly agree and disagree here:

  * yes, sure, regressions have to be avoided

  * bugs OTOH happen and they need to get fixed sooner or later anyway, 
as they otherwise will bite the user with the next or overnext Fedora 
release, as Fedora users have to update to it sooner or later anyway if 
they want to get security fixes for their distro.

Please note that above description for the second point leaves out a lot 
of details; discussing those here IMHO doesn't make much sense, hence 
I'll try to keep away from discussing that point more, because the real 
question simply is:

How to keep existing people happy while at the same time get drivers for 
new hardware out to the users as soon as possible, to make sure that 
they can run Linux/Fedora(?)?


CU
knurd

(?) And no, "Just ship new kernels and drivers with the next release" 
(e.g.every six months) is IMHO no proper answer, as some hardware 
manufactures itself have devel cycles in the 6 - 12 month range



From greno at verizon.net  Sat Jan 24 18:38:53 2009
From: greno at verizon.net (Gerry Reno)
Date: Sat, 24 Jan 2009 13:38:53 -0500
Subject: RPM: how to find installed differences?
In-Reply-To: <497B5EFF.3040107@poolshark.org>
References: <497B5769.5050701@verizon.net>	<20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net>	<497B5A9B.40208@redhat.com>
	<497B5C4A.5010405@verizon.net>	<20090124182932.GA15263@wolff.to>
	<497B5EFF.3040107@poolshark.org>
Message-ID: <497B603D.9060103@verizon.net>

Denis Leroy wrote:
> Bruno Wolff III wrote:
>> On Sat, Jan 24, 2009 at 13:22:02 -0500,
>>   Gerry Reno <greno at verizon.net> wrote:
>>> Well, what I was hoping was that there was a tool that could install 
>>> the  original RPM into a sandbox and then compare the differences 
>>> between the  sandbox install and the existing installation and 
>>> report the differences.
>>> The problem that I'm trying to solve is inevitably we make changes 
>>> to  installations due to many reasons; bug fixes, config changes, 
>>> security  patches, etc.  Then when we want to upgrade to a later 
>>> version of that  installation we don't always know exactly what has 
>>> been changed in the  installation since we first installed it.  I 
>>> looking for a way to see  all changes in the installation, whether 
>>> to original files or newly  added files, as compared to the original 
>>> RPM.
>
> You may simply want to write a script to do this comparison, or dump 
> the contents of those 2 commands :
>
>  # rpm -ql yourpackage > file1
>  # rpm -ql yourpackage.xxx.rpm > file2
I'll try this, but I think it will always give the same result for both 
since its working from metadata and that won't change.

>
> and compare the 2 outputs with a tool like 'meld' or with emacs
>
> If you want to install an RPM file into a sandbox, that's easily done 
> with :
>
> # rpm2cpio foo.rpm | cpio -id
>
Looks interesting.  I need to try this command.

Regards,
Gerry




From bruno at wolff.to  Sat Jan 24 18:42:10 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 24 Jan 2009 12:42:10 -0600
Subject: support for latest (radeon) hardware
In-Reply-To: <497B5C94.4000203@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>
	<497B0779.7020708@leemhuis.info> <20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<497B5C94.4000203@leemhuis.info>
Message-ID: <20090124184210.GA17217@wolff.to>

On Sat, Jan 24, 2009 at 19:23:16 +0100,
  Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>
> How to keep existing people happy while at the same time get drivers for  
> new hardware out to the users as soon as possible, to make sure that  
> they can run Linux/Fedora(?)?

Wait a while.
As I was trying to imply in one of my previous messages, once we get past
some of the things going on now, keeping up with new video cards (for at
least ATI and Intel) should be significantly easier.



From promac at gmail.com  Sat Jan 24 18:43:44 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sat, 24 Jan 2009 16:43:44 -0200
Subject: xorg.conf - what to do for an input device
Message-ID: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>

Hi,

I was looking at xorg.conf on Fedora 10, and
my question is: what is the correct approach,
when an input device does not work as it was supposed to?

In my case, I have an old tablet (Genius) that was detected,
but its surface area is not mapped correctly onto the screen.
Moving the stylus less than half an inch, makes the cursor cross
the entire screen.

In the past, I used an alternative driver, which was configured
in xorg.conf. Now, this same driver has an undefined external
reference "xf86errno" in F10.

Even if I fix the driver, since the input devices are detected
automatically,
the only way (I see) of using the alternative driver is including

Section "ServerFlags"
        Option "AutoAddDevices" "false"
EndSection

in xorg.conf. But this will force me to specify all other
input drivers one by one, in xorg.conf, that is, it is an
"all or nothing" approach. Is that correct?

The other option is trying to make the detected driver
use  the correct mapping, by suppling some parameters.

According to the instructions available here

https://fedoraproject.org/wiki/Features/EvdevInputDriver

I would have to look at this file:

 /usr/share/hal/fdi/policy/10osvendor/10-tabletPCs.fdi

However, I did not see anything that I could change
to fix my problem.

Any suggestion?

Thanks.


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/bf432b19/attachment.htm>

From jkeating at redhat.com  Sat Jan 24 19:03:14 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Jan 2009 11:03:14 -0800
Subject: support for latest (radeon) hardware
In-Reply-To: <497B5C94.4000203@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<497B5C94.4000203@leemhuis.info>
Message-ID: <1232823794.8363.115.camel@localhost.localdomain>

On Sat, 2009-01-24 at 19:23 +0100, Thorsten Leemhuis wrote:
>    * bugs OTOH happen and they need to get fixed sooner or later anyway, 
> as they otherwise will bite the user with the next or overnext Fedora 
> release, as Fedora users have to update to it sooner or later anyway if 
> they want to get security fixes for their distro.
> 
> Please note that above description for the second point leaves out a lot 
> of details; discussing those here IMHO doesn't make much sense, hence 
> I'll try to keep away from discussing that point more, because the real 
> question simply is:
> 
> How to keep existing people happy while at the same time get drivers for 
> new hardware out to the users as soon as possible, to make sure that 
> they can run Linux/Fedora(?)?

Well there are really two types of users.  Those that want to run
experimental builds of software and help in the bug finding and fixing
of our software, and those that don't.  We shouldn't abuse the latter.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/9d8ea5c8/attachment.sig>

From fedora at leemhuis.info  Sat Jan 24 19:20:58 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 24 Jan 2009 20:20:58 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <1232823794.8363.115.camel@localhost.localdomain>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<497B5C94.4000203@leemhuis.info>
	<1232823794.8363.115.camel@localhost.localdomain>
Message-ID: <497B6A1A.8030206@leemhuis.info>



On 24.01.2009 20:03, Jesse Keating wrote:
> On Sat, 2009-01-24 at 19:23 +0100, Thorsten Leemhuis wrote:
>>    * bugs OTOH happen and they need to get fixed sooner or later anyway, 
>> as they otherwise will bite the user with the next or overnext Fedora 
>> release, as Fedora users have to update to it sooner or later anyway if 
>> they want to get security fixes for their distro.
>>
>> Please note that above description for the second point leaves out a lot 
>> of details; discussing those here IMHO doesn't make much sense, hence 
>> I'll try to keep away from discussing that point more, because the real 
>> question simply is:
>>
>> How to keep existing people happy while at the same time get drivers for 
>> new hardware out to the users as soon as possible, to make sure that 
>> they can run Linux/Fedora(?)?

You didn't really answer the question and went into a different 
direction. But I'll follow there for this mail:

> Well there are really two types of users.  Those that want to run
> experimental builds of software and help in the bug finding and fixing
> of our software, and those that don't.

What I'm up to: The latter group wants to have support for their 
hardware as well and that's what we need a solution for.

Cu
knurd





From dbn.lists at gmail.com  Sat Jan 24 19:35:15 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 24 Jan 2009 11:35:15 -0800
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
Message-ID: <91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>

2009/1/24 Paulo Cavalcanti <promac at gmail.com>:
> Hi,
>
> I was looking at xorg.conf on Fedora 10, and
> my question is: what is the correct approach,
> when an input device does not work as it was supposed to?
>
> In my case, I have an old tablet (Genius) that was detected,
> but its surface area is not mapped correctly onto the screen.
> Moving the stylus less than half an inch, makes the cursor cross
> the entire screen.
>
> In the past, I used an alternative driver, which was configured
> in xorg.conf. Now, this same driver has an undefined external
> reference "xf86errno" in F10.
>
> Even if I fix the driver, since the input devices are detected
> automatically,
> the only way (I see) of using the alternative driver is including
>
> Section "ServerFlags"
>         Option "AutoAddDevices" "false"
> EndSection
>
> in xorg.conf. But this will force me to specify all other
> input drivers one by one, in xorg.conf, that is, it is an
> "all or nothing" approach. Is that correct?

Yeah. An alternative is just to disable hotplugging from HAL for a
specific device. Until the features I needed were ported to the evdev
driver, I had to keep using mouse for my trackpoint. By removing the
input.x11_driver field, Xorg won't try to hotplug it:

$ cat /etc/hal/fdi/policy/no-hotplug-trackpoint.fdi
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
   <match key="info.product" contains="TrackPoint">
     <remove key="input.x11_driver"/>
   </match>
 </device>
</deviceinfo>

Look at the lshal output to find appropriate fields to match on for your device.

> The other option is trying to make the detected driver
> use  the correct mapping, by suppling some parameters.
>
> According to the instructions available here
>
> https://fedoraproject.org/wiki/Features/EvdevInputDriver
>
> I would have to look at this file:
>
>  /usr/share/hal/fdi/policy/10osvendor/10-tabletPCs.fdi
>
> However, I did not see anything that I could change
> to fix my problem.

I'm not really sure how the tablet calibration works. What was the old
driver you were trying to use?

--
Dan



From promac at gmail.com  Sat Jan 24 19:49:25 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sat, 24 Jan 2009 17:49:25 -0200
Subject: xorg.conf - what to do for an input device
In-Reply-To: <91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
Message-ID: <68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>

On Sat, Jan 24, 2009 at 5:35 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:

> 2009/1/24 Paulo Cavalcanti <promac at gmail.com>:
> > Hi,
> >
> > I was looking at xorg.conf on Fedora 10, and
> > my question is: what is the correct approach,
> > when an input device does not work as it was supposed to?
> >
> > In my case, I have an old tablet (Genius) that was detected,
> > but its surface area is not mapped correctly onto the screen.
> > Moving the stylus less than half an inch, makes the cursor cross
> > the entire screen.
> >
> > In the past, I used an alternative driver, which was configured
> > in xorg.conf. Now, this same driver has an undefined external
> > reference "xf86errno" in F10.
> >
> > Even if I fix the driver, since the input devices are detected
> > automatically,
> > the only way (I see) of using the alternative driver is including
> >
> > Section "ServerFlags"
> >         Option "AutoAddDevices" "false"
> > EndSection
> >
> > in xorg.conf. But this will force me to specify all other
> > input drivers one by one, in xorg.conf, that is, it is an
> > "all or nothing" approach. Is that correct?
>
> Yeah. An alternative is just to disable hotplugging from HAL for a
> specific device. Until the features I needed were ported to the evdev
> driver, I had to keep using mouse for my trackpoint. By removing the
> input.x11_driver field, Xorg won't try to hotplug it:
>
> $ cat /etc/hal/fdi/policy/no-hotplug-trackpoint.fdi
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <deviceinfo version="0.2">
>  <device>
>   <match key="info.product" contains="TrackPoint">
>     <remove key="input.x11_driver"/>
>   </match>
>  </device>
> </deviceinfo>
>
> Look at the lshal output to find appropriate fields to match on for your
> device.
>
> > The other option is trying to make the detected driver
> > use  the correct mapping, by suppling some parameters.
> >
> > According to the instructions available here
> >
> > https://fedoraproject.org/wiki/Features/EvdevInputDriver
> >
> > I would have to look at this file:
> >
> >  /usr/share/hal/fdi/policy/10osvendor/10-tabletPCs.fdi
> >
> > However, I did not see anything that I could change
> > to fix my problem.
>
> I'm not really sure how the tablet calibration works. What was the old
> driver you were trying to use?
>
>
It was called wizardpen. It always worked well for my tablet on FC6/F8.

However, the new X does not have xf86errno anymore. I think it is just
a plain errno now, but I am not sure.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/713cbe67/attachment.htm>

From rjones at redhat.com  Sat Jan 24 20:07:38 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 24 Jan 2009 20:07:38 +0000
Subject: RPM: how to find installed differences?
In-Reply-To: <497B599C.8040801@verizon.net>
References: <497B5769.5050701@verizon.net> <20090124180434.GA3537@wolff.to>
	<497B599C.8040801@verizon.net>
Message-ID: <20090124200738.GA2711@amd.home.annexia.org>

On Sat, Jan 24, 2009 at 01:10:36PM -0500, Gerry Reno wrote:
> Ok, that sort of works to get some information about which files have  
> some changes. It doesn't show any new files that may have been added to  
> the installation though.

Sounds as if you might be looking for something like AIDE:

http://www.cs.tut.fi/~rammer/aide.html

which I'm informed by Wikipedia is a type of "Host-based intrusion
detection system":

https://secure.wikimedia.org/wikipedia/en/wiki/Host-based_intrusion_detection_system

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 dbn.lists at gmail.com  Sat Jan 24 20:17:18 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Sat, 24 Jan 2009 12:17:18 -0800
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
Message-ID: <91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>

2009/1/24 Paulo Cavalcanti <promac at gmail.com>:
>
>
> On Sat, Jan 24, 2009 at 5:35 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>>
>> I'm not really sure how the tablet calibration works. What was the old
>> driver you were trying to use?
>>
>
> It was called wizardpen. It always worked well for my tablet on FC6/F8.
>
> However, the new X does not have xf86errno anymore. I think it is just
> a plain errno now, but I am not sure.

I see. Yeah, s/xf86errno/errno/ is fine. I see there's a version of
the driver here newer than what's in ATrpms:

http://code.google.com/p/linuxgenius/

--
Dan



From nicolas.mailhot at laposte.net  Sat Jan 24 21:16:15 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 24 Jan 2009 22:16:15 +0100
Subject: [LONG] The fonts SIG irregular status report
Message-ID: <1232831775.24232.131.camel@arekh.okg>

Hi all,

Since Fedora 11 Alpha is quickly approaching, here is a much-delayed
edition of the fonts SIG irregular status report.

I should probably have done one for Fedora 10 release, but (silly me)
expected then that the new font packaging guidelines would be adopted
quickly. After all, they only reworded existing rules and added material
already presented and discussed on the fonts and devel lists.

Of course various instances decided to celebrate F10 by taking a break,
then there was some bike-shedding, then we had the Christmas vacations,
then FUDCON and more bike-shedding. Live and learn. At least after being
hammered to death the result is clear and clean.

Anyway, to the report.


??? New fonts packaging guidelines ???

After much anguish and unexpected developments FPC and FESCO approved
the complete set of fonts packaging changes that we had submitted.
https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00007.html

The end result is:
  ? a completed and clarified policy page
http://fedoraproject.org/wiki/Packaging:FontsPolicy

  ? two new packaging templates
http://fedoraproject.org/wiki/Simple_fonts_spec_template
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

  ? and a helper package with rpm macros, documentation, plus fontconfig
and spec templates
http://fedoraproject.org/wiki/Fedora_fonts_policy_package


??? Distribution-wide font auditing and repackaging ???

Some innocent repoqueries revealed a distressing number of source
packages (>130) that made us ship fonts while completely ignoring our
previous fonts packaging guidelines and existing licensing rules. So
applying new font guidelines twists quickly turned into
distribution-wide operation.

  ? Its advancement is now tracked in:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=477044

  ? A (long) FAQ was published to help packagers with no fonts
experience:
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)

  ? To make sure documentation, QA and other groups are aware and help
implement the changes they've been proposed as a Fedora 11 feature: 
http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts


??? Wishlist status ???

Our wishlist stood at 56 entries for last report. It has now reached the
76 entries watermark. The current fonts packagers are clearly unable to
cope with Fedora demands, fresh blood is needed before it moves into
3-digits land.

http://fedoraproject.org/wiki/Category:Font_wishlist

At the same time the respected lwn.net is running a front page article
listing more indispensable free or open fonts, some of them being
neither in Fedora nor in our wishlist yet.

http://lwn.net/Articles/315872/
(subscription required right now, will go free in less than a week)

Volunteers to package those or at least add them to our wishlist would
be welcome. The free and open font landscape is really moving now, and
the quality and breadth of its font offerings is now a distribution
differentiator.


??? Review status ???

At this time there are no un-reviewed font packages in Fedora bugzilla.
However, several reviews have been open for quite a long time with their
requesters not acting on review comments.

Please do respond to review comments. Reviewing packages is tedious
ungrateful work and getting no response after one is demotivating.


??? New packages ???

Ignoring renamings ctan-musixtex-fonts, dustin-dustismo-roman-fonts,
dustin-dustismo-sans-fonts, hanazono-fonts, google-droid-sans-fonts,
google-droid-sans-mono-font, google-droid-serif-fonts,
serafettin-cartoon-fonts, and unikurd-web-font are now available in the
repository.

The most user-visible of those are probably the Droid fonts, but Dustimo
had been waited for a long time.

Several other fonts previously hidden deep inside apps have now been
exposed as part of the ongoing F11 auditing and repackaging. The
complete set of changes is documented as usual:
http://fedoraproject.org/wiki/Fonts_inclusion_history

Several new packagers worked on those and on other packages not pushed
yet and I want to thank them publicly for their contribution to a better
Fedora.


??? Web font surveys ???

Fedora 10 shipped with an openjdk plugin that should be complete enough
to run web font surveys. There is no reason left for Fedora users not to
participate in them, and help web designers select fonts that work well
with Fedora browsers. Please take the time to run those:

http://fedoraproject.org/wiki/Linux_fonts_on_the_web:_CSS_and_font_surveys


??? Better fonts whiteboard ???

The desktop team has added a whiteboard page to the wiki to help
identify the software changes needed to improve Fedora fonts and text
handling.

http://fedoraproject.org/wiki/Desktop/Whiteboards/BetterFonts

Please contribute comments and complements to this page to help Fedora
get better.


??? Font autoinstallation ???

Rumors on irc are that the feature is advancing fast. Hopefully we'll
have finished cleaning up our font packages before they need to be
rebuild to add auto-install metadata. Automating this operation requires
clean packages free of historic cruft.

http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

And that's all for this issue, thank you for reading it to its end.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/244288c1/attachment.sig>

From kevin.kofler at chello.at  Sat Jan 24 21:58:39 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 24 Jan 2009 22:58:39 +0100
Subject: support for latest (radeon) hardware
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
Message-ID: <glg2uf$ad5$1@ger.gmane.org>

Thorsten Leemhuis wrote:
> But it's not like I requested a update to 6.10 immediately. It's just
> that the mail I replied to sounded a bit like "6.10 for F10 is unlikely
> in general". That's *IMHO* bad. Mainly for two reasons:
> 
> * regular users will go and install the fglrx drivers, as those offer
> support for the 4xxxx series; that is something most of us don't want
> users to do, hence we should offer them a better solution
> 
> * Fedora in most areas is good for new hardware, as you get new drivers
> (hplip, gutenprint, sane,...) and even new kernels as regular update,
> which improves hardware support (especially for current hardware) over
> time. But Fedora not only would be "good for new hardware", it could
> have "fantastic support for new hardware" if support for other new
> hardware (like the big bunch of the Radeon HD 4xxx series) also could
> find it's way into the stable distro.

+1

Drivers should get updated if at all possible. And it looks like in this
case it is.

        Kevin Kofler



From mclasen at redhat.com  Sat Jan 24 22:06:55 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 24 Jan 2009 17:06:55 -0500
Subject: GDM doesn't start
In-Reply-To: <1232817619.2681.6.camel@scrappy.miketc.net>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
	<20090124170323.GA31513@jasmine.xos.nl>
	<1232817619.2681.6.camel@scrappy.miketc.net>
Message-ID: <1232834815.18830.0.camel@matthiasc>

On Sat, 2009-01-24 at 11:20 -0600, Mike Chambers wrote:
> On Sat, 2009-01-24 at 18:03 +0100, Jos Vos wrote:
> > On Sat, Jan 24, 2009 at 10:59:05AM -0600, Mike Chambers wrote:
> > 
> > > Anyone else seeing this and/or know a fix or work around besides run
> > > level 3?
> > 
> > Is /var/log/Xorg.0.log saying something that may help?
> 
> I also noticed, and I am mentioning this in case they are same problem,
> that when hitting reply, the "Send" Button and  the "Attach" button in
> evolution appear, but the icons/text don't.
> 

I've fixed the blank tool buttons. 
I doubt that thats the same problem as the greeter, though.



From kevin.kofler at chello.at  Sat Jan 24 22:17:29 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 24 Jan 2009 23:17:29 +0100
Subject: support for latest (radeon) hardware
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
Message-ID: <glg41r$dp7$1@ger.gmane.org>

Jesse Keating wrote:
> various sound issues on intel recently).  Upstream isn't perfect, and if
> I had to choose between supporting new people, or keeping existing
> people unbroken, I'll choose on the side of existing people every time.

Actually it might often be the case that adding the support for the new
hardware is the better choice. The "existing people" can just run the old
kernel/driver/whatever until the regression is fixed.

That said, it's a tough topic, because regressions tend to really annoy
people, they feel "WTF, this always worked, WhyTF is it no longer working
now?", even though from a purely practical point of view, unfixed bugs (and
not working on some hardware is practically speaking a bug, even though
technically it's a missing feature) are much worse because there's no
working build to revert to.

One problem is that even once they're known, some of the regressions are
taking a lot of time to fix. If some improvement were possible there,
that'd help a lot, but the complexity of hardware drivers makes things
hard. It's often very difficult to figure out what caused a specific
regression.

What would ideally happen is:
1. The known regressions are fixed (e.g. the rv280 regressions in this
case).
2. The update gets pushed out to updates-testing.
3. If new regressions are found during (1-2 weeks of) testing, go back to
step 1.
4. The update gets pushed out to stable. At this point it is well worth the
remaining risk.
5. Any new bug reports get handled the usual way.
Kernel updates have skipped step 3 in several occasions and got pushed out
to stable despite known regressions. We should try to figure out why it
happened in the different occasions (a tradeoff as described in my first
paragraph? mixing of security fixes with invasive changes in a single
branch? lack of attention to Bodhi feedback? something else?), then we
could propose possible solutions. But I don't think stopping version
upgrades altogether is a solution.

        Kevin Kofler



From jkeating at redhat.com  Sat Jan 24 22:53:21 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 24 Jan 2009 14:53:21 -0800
Subject: support for latest (radeon) hardware
In-Reply-To: <497B6A1A.8030206@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<497B5C94.4000203@leemhuis.info>
	<1232823794.8363.115.camel@localhost.localdomain>
	<497B6A1A.8030206@leemhuis.info>
Message-ID: <1232837601.8363.118.camel@localhost.localdomain>

On Sat, 2009-01-24 at 20:20 +0100, Thorsten Leemhuis wrote:
>  > Well there are really two types of users.  Those that want to run
> > experimental builds of software and help in the bug finding and
> fixing
> > of our software, and those that don't.
> 
> What I'm up to: The latter group wants to have support for their 
> hardware as well and that's what we need a solution for.

Then we need to entice more of the latter group into being early users
and testers, rather than forcing it upon them without their consent.
What's the point of having releases if we don't try to keep them
somewhat stable.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/bdfcaa74/attachment.sig>

From itamar at ispbrasil.com.br  Sat Jan 24 23:51:37 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Sat, 24 Jan 2009 21:51:37 -0200
Subject: where are the ss5 maintaner ?
Message-ID: <d3ceea380901241551j5d090739i5f2eb2c391486aaa@mail.gmail.com>

where are the ss5 maintainer ?


https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5


------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From promac at gmail.com  Sun Jan 25 00:04:11 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sat, 24 Jan 2009 22:04:11 -0200
Subject: xorg.conf - what to do for an input device
In-Reply-To: <91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
Message-ID: <68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>

On Sat, Jan 24, 2009 at 6:17 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:

> 2009/1/24 Paulo Cavalcanti <promac at gmail.com>:
> >
> >
> > On Sat, Jan 24, 2009 at 5:35 PM, Dan Nicholson <dbn.lists at gmail.com>
> wrote:
> >>
> >> I'm not really sure how the tablet calibration works. What was the old
> >> driver you were trying to use?
> >>
> >
> > It was called wizardpen. It always worked well for my tablet on FC6/F8.
> >
> > However, the new X does not have xf86errno anymore. I think it is just
> > a plain errno now, but I am not sure.
>
> I see. Yeah, s/xf86errno/errno/ is fine. I see there's a version of
> the driver here newer than what's in ATrpms:
>
> http://code.google.com/p/linuxgenius/
>
>

Thanks, Dan

the wiazardpen driver version 0.6.0.2 is working just fine for me.  I did
not know it existed. I disabled the AutoAddDdevices in xorg.conf, but now my
mouse is dead. But it should be easy to fix.

Cheers,

/Paulo Roma


-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/fd9d803b/attachment.htm>

From dcantrell at redhat.com  Sun Jan 25 00:50:07 2009
From: dcantrell at redhat.com (David Cantrell)
Date: Sat, 24 Jan 2009 14:50:07 -1000
Subject: GDM doesn't start
In-Reply-To: <1232816345.2681.1.camel@scrappy.miketc.net>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
Message-ID: <497BB73F.7070302@redhat.com>

Mike Chambers wrote:
> After updating my rawhide machine this morning, gdm won't start.  It
> comes up and before all the graphics appear all the way, it restarts
> itself.
> 
> Anyone else seeing this and/or know a fix or work around besides run
> level 3?

I downgraded gdm to the previous build, which looks like the last one 
built for F-10.  Everything else is from rawhide.

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Honolulu, HI



From vonbrand at inf.utfsm.cl  Sun Jan 25 02:13:01 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 24 Jan 2009 23:13:01 -0300
Subject: Problems with ssh-add
Message-ID: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>

Rawhide x86_64 Gnome

For something like a week now each time I run ssh-add it works fine, but
then trying to use the ssh key ssh complains 

  $ ssh quelen.inf.utfsm.cl
  Error reading response length from authentication socket.
  vonbrand at quelen.inf.utfsm.cl's password:

After that, ssh just asks for the password, and:

  $ ssh-add
  Could not open a connection to your authentication agent.

I got lost in this whole business of who exactly is the autentication agent
now, so I don't know who to BZ against.
-- 
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 kevin at scrye.com  Sun Jan 25 02:07:34 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 24 Jan 2009 19:07:34 -0700
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <1232812072.8363.104.camel@localhost.localdomain>
References: <1232812072.8363.104.camel@localhost.localdomain>
Message-ID: <20090124190734.30ae90f5@ohm.scrye.com>

On Sat, 24 Jan 2009 07:47:52 -0800
Jesse Keating <jkeating at redhat.com> wrote:

> We don't currently have guidelines for granting access to proven
> packager.  I took a work item from FESCo to create a draft for this,
> and here is my first stab at it (words in camelcase exist to be
> replaced with links to pages concerning them):

Thanks for working on this! 

> Provenpackager is a group of highly skilled package maintainers who
> are experienced in a wide variety of package types and who are
> intimately familiar with the PackagingGuidelines and
> MaintainerPolicies as well as acutely aware of ReleaseSchedules and
> FreezePolicies.  They exist as a group to lend a hand when help is
> needed, always with a desire to improve the quality of Fedora.  By
> granting membership into provenpackager for a maintainer you are
> confirming that at least in your mind they meet the above criteria
> and that you would trust them fully with any of the packages you
> either maintain or even just use.

That sounds good to me. 

We might also want to mention and/or revisit/cleanup: 
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
now as well. 

kevin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/a1e3d95c/attachment.sig>

From alexl at users.sourceforge.net  Sun Jan 25 02:37:27 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sat, 24 Jan 2009 19:37:27 -0700
Subject: Heads up: MySQL 5.1 coming soon to rawhide
In-Reply-To: <12523.1232657518@sss.pgh.pa.us> (Tom Lane's message of "Thu\,
	22 Jan 2009 15\:51\:58 -0500")
References: <17597.1231954770@sss.pgh.pa.us>
	<d0c4ab73fbf661e5662789bbc2dbb204.squirrel@mail.jcomserv.net>
	<17843.1231955552@sss.pgh.pa.us> <12523.1232657518@sss.pgh.pa.us>
Message-ID: <g57i4kkt5k.fsf@allele2.eebweb.arizona.edu>

>>>>> "TL" == Tom Lane  writes:

TL> Tom Lane <tgl at redhat.com> writes:
>> I intend to push mysql 5.1.30 into rawhide next week, as soon as
>> the alpha freeze has lifted.

>> "Jon Ciesla" <limb at jcomserv.net> writes:
>>> Will you give us a shout here right after yuo do it?

>> Sure, will do.

TL> mysql 5.1.30-2 is built in rawhide.  I'm not sure how long it
TL> takes to hit the buildroots, but things should start breaking
TL> shortly ;-)

Hi,

Is there any chance you could announce this on the
fedora-devel-announce list, rather than just posting to
fedora-devel-list?  This list gets so much traffic that many
maintainers don't follow it.

Such important distro-wide dependency-breaking announcements such
MySQL updates (or other soname breakage that affects many packages)
should get wide circulation which was the reason why the lower volume
fedora-devel-announce was created in the first place.

Thanks,
Alex



From mclasen at redhat.com  Sun Jan 25 03:55:38 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Sat, 24 Jan 2009 22:55:38 -0500
Subject: GDM doesn't start
In-Reply-To: <497BB73F.7070302@redhat.com>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
	<497BB73F.7070302@redhat.com>
Message-ID: <1232855738.8240.2.camel@matthiasc>

On Sat, 2009-01-24 at 14:50 -1000, David Cantrell wrote:
> Mike Chambers wrote:
> > After updating my rawhide machine this morning, gdm won't start.  It
> > comes up and before all the graphics appear all the way, it restarts
> > itself.
> > 
> > Anyone else seeing this and/or know a fix or work around besides run
> > level 3?
> 
> I downgraded gdm to the previous build, which looks like the last one 
> built for F-10.  Everything else is from rawhide.
> 

Alternatively, update to gtk2-2.15.1-3.fc11 when it comes out of koji.



From jonstanley at gmail.com  Sun Jan 25 04:00:24 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Sat, 24 Jan 2009 23:00:24 -0500
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <20090124190734.30ae90f5@ohm.scrye.com>
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
Message-ID: <da159fda0901242000x30b4ff51l239e25589764187@mail.gmail.com>

2009/1/24 Kevin Fenzi <kevin at scrye.com>:

> We might also want to mention and/or revisit/cleanup:
> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
> now as well.

Keep in mind that we haven't done the actual reseeding yet, IIRC. I'll
draft the announcement to f-d-a about it.



From bruno at wolff.to  Sun Jan 25 05:29:02 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 24 Jan 2009 23:29:02 -0600
Subject: support for latest (radeon) hardware
In-Reply-To: <glg41r$dp7$1@ger.gmane.org>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>
	<497B0779.7020708@leemhuis.info> <20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<glg41r$dp7$1@ger.gmane.org>
Message-ID: <20090125052902.GA8833@wolff.to>

On Sat, Jan 24, 2009 at 23:17:29 +0100,
  Kevin Kofler <kevin.kofler at chello.at> wrote:
> Kernel updates have skipped step 3 in several occasions and got pushed out
> to stable despite known regressions. We should try to figure out why it
> happened in the different occasions (a tradeoff as described in my first
> paragraph? mixing of security fixes with invasive changes in a single
> branch? lack of attention to Bodhi feedback? something else?), then we
> could propose possible solutions. But I don't think stopping version
> upgrades altogether is a solution.

It would be nice to be able to give feedback to koji kernels. By the time
kernels make it to bodhi I have usually moved on.



From mike at miketc.net  Sun Jan 25 06:54:17 2009
From: mike at miketc.net (Mike Chambers)
Date: Sun, 25 Jan 2009 00:54:17 -0600
Subject: (SOLVED) GDM doesn't start
In-Reply-To: <1232855738.8240.2.camel@matthiasc>
References: <1232816345.2681.1.camel@scrappy.miketc.net>
	<497BB73F.7070302@redhat.com>  <1232855738.8240.2.camel@matthiasc>
Message-ID: <1232866457.2802.1.camel@scrappy.miketc.net>

On Sat, 2009-01-24 at 22:55 -0500, Matthias Clasen wrote:
> On Sat, 2009-01-24 at 14:50 -1000, David Cantrell wrote:
> > Mike Chambers wrote:
> > > After updating my rawhide machine this morning, gdm won't start.  It
> > > comes up and before all the graphics appear all the way, it restarts
> > > itself.
> > > 
> > > Anyone else seeing this and/or know a fix or work around besides run
> > > level 3?
> > 
> > I downgraded gdm to the previous build, which looks like the last one 
> > built for F-10.  Everything else is from rawhide.
> > 
> 
> Alternatively, update to gtk2-2.15.1-3.fc11 when it comes out of koji.

Above package does indeed fix the gdm greeter screen, as well as the 2
buttons with no icons/text on them.  

Good job on the fix and speediness of getting it out there.

-- 
Mike Chambers
Fedora Project - Bug Zapper, Tester, User, etc..
mikec302 at fedoraproject.org



From rawhide at fedoraproject.org  Sun Jan 25 08:11:52 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sun, 25 Jan 2009 08:11:52 +0000 (UTC)
Subject: rawhide report: 20090125 changes
Message-ID: <20090125081152.137E91F828C@releng2.fedora.phx.redhat.com>

Compose started at Sun Jan 25 06:01:03 UTC 2009

New package autotrust
        DNSKEY trust anchor update utility that uses RFC-5011
New package cpmtools
        Programs for accessing CP/M disks
New package dateshift
        A date/time test tool
New package dnssec-conf
        DNSSEC and DLV configuration tool (and TLD repository until the root is signed)
New package httping
        Ping alike tool for http requests
New package mingw32-libgpg-error
        MinGW Windows GnuPGP error library
New package mnemosyne
        Flash-card learning tool
New package mythes-ro
        Romanian thesaurus
New package mythes-ru
        Russian thesaurus
New package mythes-sl
        Slovenian thesaurus
New package perl-Devel-SmallProf
        Per-line Perl profiler
New package poweradmin
        A friendly web-based DNS administration tool for Bert Hubert's PowerDNS server
New package python-distutils-extra
        Integrate more support into Python's distutils
Updated Packages:

Io-language-20071010-8.fc11
---------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 20071010-8
- rebuild for dependencies


alsa-firmware-1.0.19-1.fc11
---------------------------
* Tue Jan 20 17:00:00 2009 Tim Jackson <rpm at timj.co.uk> - 1.0.19-1
- Update to 1.0.19


alsa-tools-1.0.19-1.fc11
------------------------
* Sat Jan 24 17:00:00 2009 Tim Jackson <rpm at timj.co.uk> - 1.0.19-1
- Update to version 1.0.19
- Mark udev rules as config


bind-9.6.0-4.P1.fc11
--------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 32:9.6.0-4.P1
- rebuild for dependencies


cherokee-0.11.6-2.fc11
----------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.11.6-2
- rebuild for dependencies


collectl-3.1.3-1.fc11
---------------------
* Sat Jan 24 17:00:00 2009 Dan Horak <dan[at]danny.cz> 3.1.3-1
- upgrade to upstream version 3.1.3


dovecot-1.1.8-3.fc11
--------------------
* Sat Jan 24 17:00:00 2009 Dan Horak <dan[at]danny.cz> - 1:1.1.8-3
- rebuild with new mysql


exim-4.69-9.fc11
----------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 4.69-9
- rebuild for dependencies


flow-tools-0.68.4-2.fc11
------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.68.4-2
- rebuild for dependencies


freeradius-2.1.3-2.fc11
-----------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 2.1.3-2
- rebuild for dependencies


gtk2-2.15.1-3.fc11
------------------
* Sat Jan 24 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.1-3
- Avoid triggering an assertion that makes the gdm greeter nonfunctional

* Sat Jan 24 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.1-2
- Fix blank toolbuttons in the evolution composer


hunspell-uk-1.5.7-1.fc11
------------------------
* Sat Jan 24 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 1.5.7-1
- latest version


jpoker-1.0.14-1.fc11
--------------------
* Sat Jan 24 17:00:00 2009 Jesse Keating <jkeating at redhat.com> - 1.0.14-1
- New upstream release
- Site change
- Update summary and description from upstream


kBuild-0.1.5-1.fc11
-------------------
* Sat Jan 24 17:00:00 2009 Lubomir Rintel <lkundrak at v3.sk> - 0.1.5-1
- Update to new upstream release


kdeedu-4.2.0-2.fc11
-------------------
* Sat Jan 24 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 4.2.0-2
- Requires: dustin-dustismo-roman-fonts


krazy2-2.8-6.20090113svn916151.fc11
-----------------------------------
* Sat Jan 24 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-6.20090113svn916151
- Added flag for building with kdevplatform
- Removed patches applied upstream


libmsn-4.0-0.10.beta4.fc11
--------------------------
* Sat Jan 24 17:00:00 2009 John5342 <john5342 at, fedoraproject.org> 4.0-0.10.beta4
- libmsn-4.0-beta4


libprelude-0.9.21.2-6.fc11
--------------------------
* Sat Jan 24 17:00:00 2009 Steve Grubb <sgrubb at redhat.com> - 0.9.21.2-6
- Rebuild for MySQL 5.1.30


libpreludedb-0.9.15.1-3.fc11
----------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.9.15.1-3
- rebuild for dependencies


lighttpd-1.4.20-7.fc11
----------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 1.4.20-7
- rebuild for dependencies


mingw32-filesystem-43-6.fc11
----------------------------
* Sat Jan 24 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 43-6
- Don't claim C++ compiler exists if it's not installed, as this
  breaks autoconf and (in particular) libtool.


munin-1.2.6-8.fc11
------------------
* Sat Jan 24 17:00:00 2009 Andreas Thienemann <andreas at bawue.net> - 1.2.6-8
- Updated dependencies to better reflect plugin requirements
- Added hddtemp_smartctl patch to only scan for standby state on /dev/[sh]d? devices.


nagios-plugins-1.4.13-13.fc11
-----------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 1.4.13-13
- rebuild for dependencies


ntop-3.3.8-2.fc11
-----------------
* Sat Jan 24 17:00:00 2009 Rakesh Pandit <rakesh at fedoraproject.org> - 3.3.8-2
- Bumped - for new update in mysql


nufw-2.2.20-7.fc11
------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 2.2.20-7
- rebuild for dependencies


perl-IO-Socket-SSL-1.22-1.fc11
------------------------------
* Sat Jan 24 17:00:00 2009 Paul Howarth <paul at city-fan.org> - 1.22-1
- Update to latest upstream version: 1.22


php-pear-Cache-Lite-1.7.5-1.fc11
--------------------------------
* Fri Jan  9 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> 1.7.5-1
- update to 1.7.5


proftpd-1.3.2-0.3.rc3.fc11
--------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara 1.3.2-0.3.rc3
- rebuild for dependencies


publican-0.40-2.fc11
--------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.40-2
- cjkunifonts-uming -> cjkuni-uming-fonts


pure-ftpd-1.0.21-18.fc11
------------------------
* Sat Jan 24 17:00:00 2009 Aurelien Bompard <abompard at fedoraproject.org> 1.0.21-18
- Rebuild for mysql


rekall-2.4.6-8.fc11
-------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 2.4.6-8
- rebuild for dependencies


rsyslog-3.21.9-3.fc11
---------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 3.21.9-3
- rebuild for dependencies


rt3-3.8.2-3.fc11
----------------
* Sat Jan 24 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.2-3
- Fix date in changelog entry.

* Sat Jan 24 17:00:00 2009 Ralf Cors??pius <corsepiu at fedoraproject.org> - 3.8.2-2
- Filter out R: perl(Test::Email).
- Add perl-RT-Test package.
- Activate --with devel_mode.
- Don't pass --enable/disable-devel-mode to configure.
- Add Explicit check for devel-mode deps.


ser-0.9.6-16.fc11
-----------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 0.9.6-16
- rebuild for dependencies


shcov-4-1.fc11
--------------
* Sat Jan 24 17:00:00 2009 Fabian Affolter <fabian at bernewireless.net> - 4-1
- Updated to new upstream version


shorewall-4.2.5-1.fc11
----------------------
* Sat Jan 24 17:00:00 2009 Jonathan G. Underwood <jonathan.underwood at gmail.com> - 4.2.5-1
- Update to version 4.2.5


ulogd-1.24-10.fc11
------------------
* Sat Jan 24 17:00:00 2009 Aurelien Bompard <abompard at fedoraproject.org> 1.24-10
- rebuild for mysql


vim-perl-support-4.0.1-2.fc11
-----------------------------
* Sat Jan 24 17:00:00 2009 Iain Arnell <iarnell at gmail.com> 4.0.1-2
- require perl(Devel::SmallProf) now that it's available


zoneminder-1.23.3-3.fc11
------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1.23.3-3
- rebuild for dependencies


Summary:
Added Packages: 13
Removed Packages: 0
Modified Packages: 39
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.i386 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.i386 requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.x86_64 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.x86_64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15
	gambas-gb-db-1.0.19-7.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.ppc requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.ppc requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15
	showimg-mysql-0.9.5-19.fc10.ppc requires libmysqlclient.so.15(libmysqlclient_15)



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:openoffice.org-langpack-zh_TW-3.0.1-15.4.fc11.ppc64 requires cjkunifonts-uming
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15()(64bit)
	showimg-mysql-0.9.5-19.fc10.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)





From vpivaini at cs.helsinki.fi  Sun Jan 25 09:24:56 2009
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Sun, 25 Jan 2009 11:24:56 +0200
Subject: Restart anacron on hibernate/resume
Message-ID: <1232875496.2955.5.camel@poytakone.lan>

Hi all,

Below is a message I sent to the fedora-list a while ago. I didn't
really get that many answers, so I'd like to discuss the issue on this
list too.

The main point here is: does Fedora restart anacron after a
suspend/hibernate and resume cycle (probably not) and should it?

As you may know, Ubuntu 8.04.2 was recently released and they have
apparently fixed a similar issue. In <http://lwn.net/Articles/316224/>
it says "Stop/start anacron on suspend/resume and on power-cycle
(#249220)".


Ville-Pekka Vainio


------- V?litetty viesti ---------
> L?hett?j?: Ville-Pekka Vainio <vpivaini at cs.helsinki.fi>
> Reply-to: "Community assistance, encouragement, and advice for using
> Fedora." <fedora-list at redhat.com>
> Vastaanottaja: fedora-list at redhat.com
> Aihe: cron.{daily, weekly, ...} and hibernate
> P?iv?ys: Sun, 04 Jan 2009 20:13:42 +0200
> 
> Hi,
> 
> I've been wondering about the cron.{daily, monthly, weekly, hourly}
> scripts and hibernate. It seems to me that when I use hibernate, these
> jobs are almost never run, unless of course I need to do a complete
> reboot due to a kernel update or such.
> 
> Cron almost never gets to run these jobs because the computer is usually
> hibernating when cron is configured to run. It seems like anacron
> doesn't run the jobs either when the computer is actually running. To
> fix this I've written a simple bash script for hibernating which first
> runs hibernate and then restarts crond and anacron when waking up.
> 
> Am I wrong here, is there something wrong with my configuration or is it
> really the situation that the cron jobs are not run after waking up from
> hibernation?
> 
> 
> -- 
> Ville-Pekka Vainio
> 
-- 
Ville-Pekka Vainio



From fedora at leemhuis.info  Sun Jan 25 09:31:41 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 25 Jan 2009 10:31:41 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <497B0779.7020708@leemhuis.info>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>
	<497B0779.7020708@leemhuis.info>
Message-ID: <497C317D.5010500@leemhuis.info>

On 24.01.2009 13:20, Thorsten Leemhuis wrote:
> On 23.01.2009 16:35, Matej Cepl wrote:
>> On 2009-01-23, 04:31 GMT, Orion Poplawski wrote:
>>> Are there any plans to get ati driver 6.10 into F10?  I'm getting pretty
>>> lousy results with 6.9 in F10 on my RV370, but promising results with 6.10
>>> and Xorg server 1.5.99.  It doesn't work with 1.5.3 though it installs
>>> without any rpm/dependency issues.  Anything on the wiki about current
>>> Xorg plans?
>> I asked about that our X guys, and airlied (our ATI magician 
>> in-house) told me that a) there is not that much difference 
>> between 6.9 and 6.10,
> I compared radeon.xinf from 6.9 and 6.10 and found a few important cards 
> that 6.10 supports, but 6.9 does not:

https://admin.fedoraproject.org/updates/xorg-x11-drv-ati-6.10.0-1.fc10

Many thanks airlied!

/me will try to give it a quick test at work tomorrow

CU
knurd



From vpivaini at cs.helsinki.fi  Sun Jan 25 10:36:43 2009
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Sun, 25 Jan 2009 12:36:43 +0200
Subject: Comps change: mozvoikko as firefox conditional for F11
Message-ID: <1232879803.4886.9.camel@poytakone.lan>

Hi,

I'd like to change mozvoikko in the Finnish support group in F11 from
this:

<packagereq type="optional">mozvoikko</packagereq>

to this:

<packagereq type="conditional" requires="firefox">mozvoikko</packagereq>

so that the Finnish spell checking extension for Firefox would be
installed automatically. It's a small package (37K rpm) and all the
dependencies are on the live cd already. Would this be ok?


-- 
Ville-Pekka Vainio



From alexl at users.sourceforge.net  Sun Jan 25 11:37:33 2009
From: alexl at users.sourceforge.net (Alex Lancaster)
Date: Sun, 25 Jan 2009 04:37:33 -0700
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <20090124190734.30ae90f5@ohm.scrye.com> (Kevin Fenzi's message of
	"Sat\, 24 Jan 2009 19\:07\:34 -0700")
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
Message-ID: <bfr62rk45e.fsf@allele2.eebweb.arizona.edu>

>>>>> "KF" == Kevin Fenzi  writes:

KF> On Sat, 24 Jan 2009 07:47:52 -0800
KF> Jesse Keating <jkeating at redhat.com> wrote:

> We don't currently have guidelines for granting access to proven
>> packager.  I took a work item from FESCo to create a draft for
>> this, and here is my first stab at it (words in camelcase exist to
>> be replaced with links to pages concerning them):

KF> Thanks for working on this!

>> Provenpackager is a group of highly skilled package maintainers who
>> are experienced in a wide variety of package types and who are
>> intimately familiar with the PackagingGuidelines and
>> MaintainerPolicies as well as acutely aware of ReleaseSchedules and
>> FreezePolicies.  They exist as a group to lend a hand when help is
>> needed, always with a desire to improve the quality of Fedora.  By
>> granting membership into provenpackager for a maintainer you are
>> confirming that at least in your mind they meet the above criteria
>> and that you would trust them fully with any of the packages you
>> either maintain or even just use.

KF> That sounds good to me.

KF> We might also want to mention and/or revisit/cleanup:
KF> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModifyWhichPackages
KF> now as well.

So is provenpackager going to be reseeded with sponsors only?  If that
is so, I'll lose my current ability to fix packages as I am not a
sponsor at this time.  I have particularly focused on fixing broken
deps in rawhide (my pet peeve, especially close to releases) for the
last few release cycles and I hope my work has been useful.

I thought the initial way of seeding the list (i.e. maintainers with a
large number of packages) was fine, were there any cases where people
passed this threshold and then went abused (inadvertantly or
otherwise) their ability to commit and build a larger number of
packages?

I fear that if the bar for provenpackager is raised too high
(i.e. only sponsors) and requires too many hoops to jump through to
get in, then my motivation to work on Fedora will be severely
curtailed and I suspect there may be others.  Please individually
consider the work of the maintainers in the current provenpackager
list have been doing before removing them en-masse.

Related to this, it seems that there are still maintainers who appear
to want to lock up their packages even from "provenpackager".  As a
concrete example, user "rezso" (I've requested him to re-open them in
private e-mail to no avail) locked down several of his packages such
as:

http://admin.fedoraproject.org/pkgdb/packages/name/mapserver
http://admin.fedoraproject.org/pkgdb/packages/name/mapnik
http://admin.fedoraproject.org/pkgdb/packages/name/gdal

These are packages that regularly needs to be rebuilt when sonames are
bumped and frequently lies dormant in a "broken deps" state for weeks
at a time and would benefit being available to provenpackagers to
rebuild.  (It's currently broken right now because of the MySQL soname
bump and there's no good reason why it shouldn't be available for
provenpackager to fix it).

Alex



From belegdol at gmail.com  Sun Jan 25 11:53:46 2009
From: belegdol at gmail.com (Julian Sikorski)
Date: Sun, 25 Jan 2009 12:53:46 +0100
Subject: Problems with ssh-add
In-Reply-To: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>
References: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>
Message-ID: <497C52CA.9070100@gmail.com>

Horst H. von Brand pisze:
> Rawhide x86_64 Gnome
> 
> For something like a week now each time I run ssh-add it works fine, but
> then trying to use the ssh key ssh complains 
> 
>   $ ssh quelen.inf.utfsm.cl
>   Error reading response length from authentication socket.
>   vonbrand at quelen.inf.utfsm.cl's password:
> 
> After that, ssh just asks for the password, and:
> 
>   $ ssh-add
>   Could not open a connection to your authentication agent.
> 
> I got lost in this whole business of who exactly is the autentication agent
> now, so I don't know who to BZ against.
Does it happen after you resume from S3?

https://bugzilla.redhat.com/show_bug.cgi?id=454186

Regards,
Julian



From Fedora at FamilleCollet.com  Sun Jan 25 14:50:14 2009
From: Fedora at FamilleCollet.com (Remi Collet)
Date: Sun, 25 Jan 2009 15:50:14 +0100
Subject: rpms/php-magickwand/devel php-magickwand.spec,1.9,1.10
In-Reply-To: <20090125142802.ABFA370133@cvs1.fedora.phx.redhat.com>
References: <20090125142802.ABFA370133@cvs1.fedora.phx.redhat.com>
Message-ID: <497C7C26.3@FamilleCollet.com>

Robert Scheck a ?crit :
> Index: php-magickwand.spec
...
>  Requires:	php-api = %((echo %{default_apiver}; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)

Hi,

I notice this in your spec.

I think you should probably require php-(zend-abi) which is really more
accurate (will detecte ABI breaks when major php update).

Even if this not a php extension from "pecl" repository
Read http://fedoraproject.org/wiki/Packaging/PHP#PECL_Packages

Regards



From robert at fedoraproject.org  Sun Jan 25 14:54:33 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 25 Jan 2009 15:54:33 +0100
Subject: rpms/php-magickwand/devel php-magickwand.spec,1.9,1.10
In-Reply-To: <497C7C26.3@FamilleCollet.com>
References: <20090125142802.ABFA370133@cvs1.fedora.phx.redhat.com>
	<497C7C26.3@FamilleCollet.com>
Message-ID: <20090125145433.GA21728@hurricane.linuxnetz.de>

On Sun, 25 Jan 2009, Remi Collet wrote:
> I think you should probably require php-(zend-abi) which is really more
> accurate (will detecte ABI breaks when major php update).
> 
> Even if this not a php extension from "pecl" repository
> Read http://fedoraproject.org/wiki/Packaging/PHP#PECL_Packages

Thank you for your suggestion, but major PHP updates are not happening that
often nowadays; magickwand upstream is usually pushing updates more quickly
as PHP major updates are happening. When looking to the link you've shown:

  Other Packages: PHP addons which are neither PEAR nor PECL should require
  what makes sense (either a base PHP version or a php-api as necessary).

So I will stay at what already is working for now.


Greetings,
  Robert



From robert at fedoraproject.org  Sun Jan 25 15:23:55 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Sun, 25 Jan 2009 16:23:55 +0100
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <1232812072.8363.104.camel@localhost.localdomain>
References: <1232812072.8363.104.camel@localhost.localdomain>
Message-ID: <20090125152355.GA10504@hurricane.linuxnetz.de>

On Sat, 24 Jan 2009, Jesse Keating wrote:
> We don't currently have guidelines for granting access to proven
> packager.  I took a work item from FESCo to create a draft for this, and
> here is my first stab at it (words in camelcase exist to be replaced
> with links to pages concerning them):

Some time ago, I had a discussion with Kevin and Jason - but I'm not really
sure currently, as it already was late night. Maybe somebody can correct me
here if, I'm wrong.

Well, I was unhappy about the uberpackager/provenpackager situation and
that it is too easy to get this status. Ideas resulting of the discussion
has been, that uberpackagers/provenpackagers more should be some kind of
mentors and to help packagers when needed and requested. Yes, that's more
or less currently already case, but I had more the mentor thing in mind.

Uberpackagers/provenpackagers should be persons well known to the community
and having some presence at packagers. So a person only having 5 packages
gets a uberpackager/provenpackager, something really goes wrong IMHO. Yes,
we've changed that, but we should not make the status depend on packages or
some time at all, but on presence and knowledge of the person.

The other thing is, which is much more important, that not a single person
can sponsor a uberpackager/provenpackager. I was thinking about some kind
of "voting". Of course not a voting that kind, that all current sponsors
are getting notified via e-mail, but the possibility, that every sponsor
can add +1/0/-1 in FAS to a guy wanting to get uberpackager/provenpackager.
And if "charma" of that candidate is +5 or +10 in the end, the guy gets
uberpackager/provenpackager. If a sponsor is doing nothing, it's just +0/
-0, but the sponsors should not get bothered about each request of a new
candidate.

Anyway for that we IMHO must reset the current uberpackager/provenpackager
list and restart with an empty one. Otherwise that doesn't make sense to me
and it doesn't change nor solve our problems we introduced in the past...


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/2c414aba/attachment.sig>

From kevin.kofler at chello.at  Sun Jan 25 16:12:28 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Jan 2009 17:12:28 +0100
Subject: Draft guidelines for approving provenpackager
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
	<bfr62rk45e.fsf@allele2.eebweb.arizona.edu>
Message-ID: <gli31c$343$1@ger.gmane.org>

Alex Lancaster wrote:
> So is provenpackager going to be reseeded with sponsors only?  If that
> is so, I'll lose my current ability to fix packages as I am not a
> sponsor at this time.  I have particularly focused on fixing broken
> deps in rawhide (my pet peeve, especially close to releases) for the
> last few release cycles and I hope my work has been useful.

I'm a sponsor now, and AFAIK sponsors in packager will also be sponsors in
provenpackager, so I'll sponsor you into provenpackager (if somebody else
isn't quicker than me ;-) ). You've done great work fixing broken deps, you
really deserve being in provenpackager!

        Kevin Kofler



From kevin.kofler at chello.at  Sun Jan 25 16:15:39 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 25 Jan 2009 17:15:39 +0100
Subject: Draft guidelines for approving provenpackager
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
	<bfr62rk45e.fsf@allele2.eebweb.arizona.edu>
Message-ID: <gli37b$343$2@ger.gmane.org>

Alex Lancaster wrote:
> Related to this, it seems that there are still maintainers who appear
> to want to lock up their packages even from "provenpackager".  As a
> concrete example, user "rezso" (I've requested him to re-open them in
> private e-mail to no avail) locked down several of his packages such
> as:
> 
> http://admin.fedoraproject.org/pkgdb/packages/name/mapserver
> http://admin.fedoraproject.org/pkgdb/packages/name/mapnik
> http://admin.fedoraproject.org/pkgdb/packages/name/gdal
> 
> These are packages that regularly needs to be rebuilt when sonames are
> bumped and frequently lies dormant in a "broken deps" state for weeks
> at a time and would benefit being available to provenpackagers to
> rebuild.  (It's currently broken right now because of the MySQL soname
> bump and there's no good reason why it shouldn't be available for
> provenpackager to fix it).

+1

There's an open ticket at FESCo to look into abuse of provenpackager
lockout, I really hope they'll look into this soon.

        Kevin Kofler



From promac at gmail.com  Sun Jan 25 16:59:56 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Sun, 25 Jan 2009 14:59:56 -0200
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
	<68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
Message-ID: <68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>

On Sat, Jan 24, 2009 at 10:04 PM, Paulo Cavalcanti <promac at gmail.com> wrote:

>
>
> On Sat, Jan 24, 2009 at 6:17 PM, Dan Nicholson <dbn.lists at gmail.com>wrote:
>
>> 2009/1/24 Paulo Cavalcanti <promac at gmail.com>:
>> >
>> >
>> > On Sat, Jan 24, 2009 at 5:35 PM, Dan Nicholson <dbn.lists at gmail.com>
>> wrote:
>> >>
>> >> I'm not really sure how the tablet calibration works. What was the old
>> >> driver you were trying to use?
>> >>
>> >
>> > It was called wizardpen. It always worked well for my tablet on FC6/F8.
>> >
>> > However, the new X does not have xf86errno anymore. I think it is just
>> > a plain errno now, but I am not sure.
>>
>> I see. Yeah, s/xf86errno/errno/ is fine. I see there's a version of
>> the driver here newer than what's in ATrpms:
>>
>> http://code.google.com/p/linuxgenius/
>>
>>
>
> Thanks, Dan
>
> the wiazardpen driver version 0.6.0.2 is working just fine for me.  I did
> not know it existed. I disabled the AutoAddDdevices in xorg.conf, but now my
> mouse is dead. But it should be easy to fix.
>
>
Well, I finished and I included a hal rule for loading wizardpen in xorg
1.5.3

The spec file is here:

http://people.atrpms.net/~pcavalcanti/specs/wizardpen.spec

Do you think that would be any interest in having wizardpen in Fedora?

I really do not know if this type of package is acceptable or not.

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/a0a76af0/attachment.htm>

From jkeating at redhat.com  Sun Jan 25 17:16:47 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 25 Jan 2009 09:16:47 -0800
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <bfr62rk45e.fsf@allele2.eebweb.arizona.edu>
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
	<bfr62rk45e.fsf@allele2.eebweb.arizona.edu>
Message-ID: <1232903807.8363.124.camel@localhost.localdomain>

On Sun, 2009-01-25 at 04:37 -0700, Alex Lancaster wrote:
>  
> So is provenpackager going to be reseeded with sponsors only?  If that
> is so, I'll lose my current ability to fix packages as I am not a
> sponsor at this time.  I have particularly focused on fixing broken
> deps in rawhide (my pet peeve, especially close to releases) for the
> last few release cycles and I hope my work has been useful.

The new plan is to re-seed, however once seeded, the criteria I
mentioned will be used by those people to bring more into the group,
people who actually want the elevated access rather than getting it by
happenstance of having a few packages.

This serves another goal, addressing one of the reasons why people
claimed they didn't feel comfortable opening their packages to
provenpackager, the group was too haphazardly created.

As Kevin states, there shouldn't be difficulty in getting yourself back
into proven packager, you have proven yourself. 

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/b80edffa/attachment.sig>

From jkeating at redhat.com  Sun Jan 25 17:18:27 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 25 Jan 2009 09:18:27 -0800
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <gli37b$343$2@ger.gmane.org>
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090124190734.30ae90f5@ohm.scrye.com>
	<bfr62rk45e.fsf@allele2.eebweb.arizona.edu>
	<gli37b$343$2@ger.gmane.org>
Message-ID: <1232903907.8363.126.camel@localhost.localdomain>

On Sun, 2009-01-25 at 17:15 +0100, Kevin Kofler wrote:
>  +1
> 
> There's an open ticket at FESCo to look into abuse of provenpackager
> lockout, I really hope they'll look into this soon.

This reseeding is in fact part of the result of that looking into.  The
provenpackager group being too big and filled with people who maintain
an arbitrary amount of packages was a big reason why some folks didn't
open their packages.  By rebooting the group with people we've already
had a human review of, and then supplying guidelines for those people to
bring more into the group, we can keep the group to just those that
genuinely want to help, and have had some human trust level applied.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/87c2288b/attachment.sig>

From jkeating at redhat.com  Sun Jan 25 17:23:01 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sun, 25 Jan 2009 09:23:01 -0800
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <20090125152355.GA10504@hurricane.linuxnetz.de>
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090125152355.GA10504@hurricane.linuxnetz.de>
Message-ID: <1232904181.8363.128.camel@localhost.localdomain>

On Sun, 2009-01-25 at 16:23 +0100, Robert Scheck wrote:
>  Uberpackagers/provenpackagers should be persons well known to the community
> and having some presence at packagers. So a person only having 5 packages
> gets a uberpackager/provenpackager, something really goes wrong IMHO. Yes,
> we've changed that, but we should not make the status depend on packages or
> some time at all, but on presence and knowledge of the person.

That's who we're starting the group with, the current package sponsors.
People whom we trust to bring new contributors into the packager group,
we're now also going to trust them to bring new packagers into the
provenpackager group.

> 
> The other thing is, which is much more important, that not a single person
> can sponsor a uberpackager/provenpackager. I was thinking about some kind
> of "voting". Of course not a voting that kind, that all current sponsors
> are getting notified via e-mail, but the possibility, that every sponsor
> can add +1/0/-1 in FAS to a guy wanting to get uberpackager/provenpackager.
> And if "charma" of that candidate is +5 or +10 in the end, the guy gets
> uberpackager/provenpackager. If a sponsor is doing nothing, it's just +0/
> -0, but the sponsors should not get bothered about each request of a new
> candidate.

Interesting thought, I'd like to see a full proposal brought to FESCo
over this matter.

> 
> Anyway for that we IMHO must reset the current uberpackager/provenpackager
> list and restart with an empty one. Otherwise that doesn't make sense to me
> and it doesn't change nor solve our problems we introduced in the past...

We're starting with the existing group of people who have already been
vetted by FESCo, that is the current sponsors.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/29d7394a/attachment.sig>

From tomek at pipebreaker.pl  Sun Jan 25 22:12:23 2009
From: tomek at pipebreaker.pl (Tomasz Torcz)
Date: Sun, 25 Jan 2009 23:12:23 +0100
Subject: messages eat my harddisk because of alsa or pulse
In-Reply-To: <20090120031054.GA27902@tango.0pointer.de>
References: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
	<20090120031054.GA27902@tango.0pointer.de>
Message-ID: <20090125221223.GA2347@mother.fordon.pl.eu.org>

On Tue, Jan 20, 2009 at 04:10:54AM +0100, Lennart Poettering wrote:
> On Tue, 20.01.09 04:17, Muayyad AlSadi (alsadi at gmail.com) wrote:
> 
> > Jan 20 04:00:43 localhost pulseaudio[3021]: module-alsa-sink.c: ALSA
> > woke us up to write new data to the device, but there wa
> > s actually nothing to write! Most likely this is an ALSA driver bug.
> > Please report this issue to the PulseAudio developers.
> > 
> > what is the reason,
> 
> Your ALSA driver is broken.
> 
> That said, I didn't expect that this message would be printed that
> often on the setups where they happen.


  What do you mean by "often"? 
# grep -c "Most likely this is an ALSA driver bug" messages*
messages:1
messages-20081228:16
messages-20090104:5
messages-20090111:7
messages-20090118:13

  On my Thinkpad T400 with Centrino 2 and
echo 5 > /sys/module/snd_hda_intel/parameters/power_save
echo 1 > /sys/module/snd_hda_intel/parameters/power_save_controller 


-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
xmpp: zdzichubg at chrome.pl    wagon filled with backup tapes." -- Jim Gray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 237 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/d5f899ac/attachment.sig>

From mzerqung at 0pointer.de  Sun Jan 25 22:52:35 2009
From: mzerqung at 0pointer.de (Lennart Poettering)
Date: Sun, 25 Jan 2009 23:52:35 +0100
Subject: messages eat my harddisk because of alsa or pulse
In-Reply-To: <20090125221223.GA2347@mother.fordon.pl.eu.org>
References: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
	<20090120031054.GA27902@tango.0pointer.de>
	<20090125221223.GA2347@mother.fordon.pl.eu.org>
Message-ID: <20090125225235.GA31415@tango.0pointer.de>

On Sun, 25.01.09 23:12, Tomasz Torcz (tomek at pipebreaker.pl) wrote:

> On Tue, Jan 20, 2009 at 04:10:54AM +0100, Lennart Poettering wrote:
> > On Tue, 20.01.09 04:17, Muayyad AlSadi (alsadi at gmail.com) wrote:
> > 
> > > Jan 20 04:00:43 localhost pulseaudio[3021]: module-alsa-sink.c: ALSA
> > > woke us up to write new data to the device, but there wa
> > > s actually nothing to write! Most likely this is an ALSA driver bug.
> > > Please report this issue to the PulseAudio developers.
> > > 
> > > what is the reason,
> > 
> > Your ALSA driver is broken.
> > 
> > That said, I didn't expect that this message would be printed that
> > often on the setups where they happen.
> 
> 
>   What do you mean by "often"? 
> # grep -c "Most likely this is an ALSA driver bug" messages*
> messages:1
> messages-20081228:16
> messages-20090104:5
> messages-20090111:7
> messages-20090118:13

That's more how often I expected this message to be printed. However,
some folks complain about gigabytes of data like this. And that's what
I didn't expect.

But still, I think the biggest issue here is that rsyslog doesn't
enforce any kind of rate limitting and is happy to let random users
fill up /var.

This is a first-class DoS. Simply do a "cat /dev/urandom | strings |
logger" and you can make the whole system go bonkers. And it won't
even be accounted to your own disk quota. Yay.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4



From robert at fedoraproject.org  Sun Jan 25 23:13:58 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 00:13:58 +0100
Subject: Draft guidelines for approving provenpackager
In-Reply-To: <1232904181.8363.128.camel@localhost.localdomain>
References: <1232812072.8363.104.camel@localhost.localdomain>
	<20090125152355.GA10504@hurricane.linuxnetz.de>
	<1232904181.8363.128.camel@localhost.localdomain>
Message-ID: <20090125231358.GA21990@hurricane.linuxnetz.de>

On Sun, 25 Jan 2009, Jesse Keating wrote:
> Interesting thought, I'd like to see a full proposal brought to FESCo
> over this matter.

Done so far. Can you please add

  https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal

to the agenda for the next FESCo meeting? Currently it's a proposal which
surely needs love until it maybe can get a policy. Thank you.


Greetings,
  Robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/05fda9ed/attachment.sig>

From christoph.wickert at googlemail.com  Mon Jan 26 00:26:32 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 26 Jan 2009 01:26:32 +0100
Subject: rpms/xfburn/devel .cvsignore, 1.2, 1.3 sources, 1.2, 1.3
	xfburn.spec, 1.2, 1.3
In-Reply-To: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
References: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
Message-ID: <1232929592.5308.6.camel@wicktop.localdomain>

Am Sonntag, den 25.01.2009, 23:53 +0000 schrieb Denis Leroy:
> Author: denis
> 
> Update of /cvs/pkgs/rpms/xfburn/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9621
> 
> Modified Files:
> 	.cvsignore sources xfburn.spec 
> Log Message:
> Update to upstream 0.4.0

Hi Denis,

why not contact the package owner before doing this? I have tested 0.4.0
and found an issue that I would have liked to figure out with upstream
first.

> @@ -67,6 +67,7 @@
>  %doc AUTHORS COPYING ChangeLog NEWS TODO
>  %{_bindir}/%{name}
>  %{_datadir}/applications/%{name}.desktop
> +%{_datadir}/Thunar/sendto/*.desktop
               ^^^^^^^^^^^^^
You have also added 2 unowned dirs to the package. :(

Regards,
Christoph



From kevin.kofler at chello.at  Mon Jan 26 00:53:40 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 01:53:40 +0100
Subject: rpms/xfburn/devel .cvsignore, 1.2, 1.3 sources, 1.2,
	1.3 xfburn.spec, 1.2, 1.3
References: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
	<1232929592.5308.6.camel@wicktop.localdomain>
Message-ID: <glj1ik$235$1@ger.gmane.org>

Christoph Wickert wrote:
> why not contact the package owner before doing this? I have tested 0.4.0
> and found an issue that I would have liked to figure out with upstream
> first.

Use:
koji untag-pkg dist-f11 xfburn-0.4.0-1.fc11
to get rid of the offending build. But better do it fast - rel-eng may lynch
you if you untag the package after it ended up in a nightly Rawhide
compose. Rawhide composes start at 06:00 (AM) UTC.

        Kevin Kofler



From christoph.wickert at googlemail.com  Mon Jan 26 00:56:20 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 26 Jan 2009 01:56:20 +0100
Subject: rpms/xfburn/devel .cvsignore, 1.2, 1.3 sources, 1.2, 1.3
	xfburn.spec, 1.2, 1.3
In-Reply-To: <1232929592.5308.6.camel@wicktop.localdomain>
References: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
	<1232929592.5308.6.camel@wicktop.localdomain>
Message-ID: <1232931380.24331.6.camel@wicktop.localdomain>

Am Montag, den 26.01.2009, 01:26 +0100 schrieb Christoph Wickert:
> Am Sonntag, den 25.01.2009, 23:53 +0000 schrieb Denis Leroy:
> > Author: denis
> > 
> > Update of /cvs/pkgs/rpms/xfburn/devel
> > In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9621
> > 
> > Modified Files:
> > 	.cvsignore sources xfburn.spec 
> > Log Message:
> > Update to upstream 0.4.0
> 
> Hi Denis,
> 
> why not contact the package owner before doing this? 

Meanwhile Denis contacted me and explained what was going on: The
rebuild was necessary because he updated both libburn and libisofs.
During the review I have explicitly even asked him to do so whenever
it's needed, so this definitely was my fault.

Sorry for the noise,
Christoph




From kevin.kofler at chello.at  Mon Jan 26 00:57:55 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 01:57:55 +0100
Subject: rpms/xfburn/devel .cvsignore, 1.2, 1.3 sources, 1.2,
	1.3 xfburn.spec, 1.2, 1.3
References: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
	<1232929592.5308.6.camel@wicktop.localdomain>
	<1232931380.24331.6.camel@wicktop.localdomain>
Message-ID: <glj1qj$235$2@ger.gmane.org>

Christoph Wickert wrote:
> Meanwhile Denis contacted me and explained what was going on: The
> rebuild was necessary because he updated both libburn and libisofs.
> During the review I have explicitly even asked him to do so whenever
> it's needed, so this definitely was my fault.

But at least the unowned directories do need fixing. :-)

        Kevin Kofler



From christoph.wickert at googlemail.com  Mon Jan 26 01:07:31 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Mon, 26 Jan 2009 02:07:31 +0100
Subject: rpms/xfburn/devel .cvsignore, 1.2, 1.3 sources, 1.2, 1.3
	xfburn.spec, 1.2, 1.3
In-Reply-To: <glj1qj$235$2@ger.gmane.org>
References: <20090125235330.3988270105@cvs1.fedora.phx.redhat.com>
	<1232929592.5308.6.camel@wicktop.localdomain>
	<1232931380.24331.6.camel@wicktop.localdomain>
	<glj1qj$235$2@ger.gmane.org>
Message-ID: <1232932051.24331.12.camel@wicktop.localdomain>

Am Montag, den 26.01.2009, 01:57 +0100 schrieb Kevin Kofler:
> Christoph Wickert wrote:
> > Meanwhile Denis contacted me and explained what was going on: The
> > rebuild was necessary because he updated both libburn and libisofs.
> > During the review I have explicitly even asked him to do so whenever
> > it's needed, so this definitely was my fault.
> 
> But at least the unowned directories do need fixing. :-)

I know, thanks for the reminder ;)

>         Kevin Kofler
Regards,
Christoph



From vonbrand at inf.utfsm.cl  Mon Jan 26 03:03:21 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 26 Jan 2009 00:03:21 -0300
Subject: Problems with ssh-add
In-Reply-To: <497C52CA.9070100@gmail.com>
References: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>
	<497C52CA.9070100@gmail.com>
Message-ID: <200901260303.n0Q33L4i020907@laptop14.inf.utfsm.cl>

Julian Sikorski <belegdol at gmail.com> wrote:
> Horst H. von Brand pisze:
> > Rawhide x86_64 Gnome
> > 
> > For something like a week now each time I run ssh-add it works fine, but
> > then trying to use the ssh key ssh complains 
> > 
> >   $ ssh quelen.inf.utfsm.cl
> >   Error reading response length from authentication socket.
> >   vonbrand at quelen.inf.utfsm.cl's password:
> > 
> > After that, ssh just asks for the password, and:
> > 
> >   $ ssh-add
> >   Could not open a connection to your authentication agent.
> > 
> > I got lost in this whole business of who exactly is the autentication agent
> > now, so I don't know who to BZ against.
> Does it happen after you resume from S3?

Only tried to hibernate this machine once by accident. Got a complete hang,
didn't try again.

And seahorse is running, and doesn't get killed when trying to use ssh once.
-- 
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 ianweller at gmail.com  Mon Jan 26 05:30:57 2009
From: ianweller at gmail.com (Ian Weller)
Date: Sun, 25 Jan 2009 23:30:57 -0600
Subject: Wiki tip for the week of Jan 26 2009: Moving pages with ease
Message-ID: <20090126053057.GA1630@gmail.com>

  /-----------------------------------------------------------------
  I'm introducing a series of blog and mailing list posts helping to
  increase knowledge about useful features, policies, and other
  important things relating to the Fedora Project wiki. You can see
  the end of this post for more information on keeping up with
  these.
  -----------------------------------------------------------------/


Wiki tip of the week for Jan 26 2009: Moving pages with ease
============================================================

With the new page naming and wiki structure policy[1] in place, a lot of
users on the wiki have recently been moving pages around, and often have
been doing it the manual way: copy the source from one page to another,
and make a redirect[2] by hand. What most users apparently don't realize
is that there is a move button at the top of every page, and any
logged-in user can use that button.
 
 (Images: [3] and [4])

When moving your page it's a very good idea to give a reason for doing
so. You can also choose to move a page's corresponding discussion page
along with it too, if it has one. This is very useful for archiving
pages (simply tack on Archive: at the beginning of the page name) or
moving your old pages. And of course, please watch your pages[5].
    
    Using the move tab automatically creates a redirect and can also
    fix other redirects to prevent double redirects[6].

Probably the most important part of using the move tab instead of a
manual move is that page histories are kept across both pages, so it's
much easier to find who edited what and when.

However if the new page already has content (perhaps a #REDIRECT),
MediaWiki won't allow you to move the page (unless you have the power to
delete pages). You'll still need to move the page by hand, in this case.

Learn more: Help:Moving a page[7] at meta.wikimedia.org


  The wiki tip of the week series by Ian Weller, published every
  Monday, is an effort to increase knowledge about useful features,
  policies, and other important things relating to the Fedora Project
  wiki.


[1]: https://fedoraproject.org/wiki/Help:Wiki_structure
[2]: http://www.mediawiki.org/wiki/Help:Redirects
[3]: https://fedoraproject.org/wiki/Image:Wiki_move_button.png
[4]: https://fedoraproject.org/wiki/Image:Wiki_move_prompt.png
[5]: http://meta.wikimedia.org/wiki/Help:Watching_pages
[6]: http://en.wikipedia.org/wiki/Wikipedia:Double_redirects
[7]: http://meta.wikimedia.org/wiki/Help:Moving_a_page


Permanent link to this tip:
  https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_20090126
Discuss this tip:
  https://fedoraproject.org/wiki/User_talk:Ianweller/Wiki_tip_20090126
Main page:
  https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_of_the_week
Posts on Ian's blog:
  http://ianweller.org/cat/wiki-tip-of-the-week/
RSS feed of tips of the week:
  http://ianweller.org/cat/wiki-tip-of-the-week/feed/

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090125/8c4ef5a5/attachment.sig>

From fedora at leemhuis.info  Mon Jan 26 05:45:27 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Mon, 26 Jan 2009 06:45:27 +0100
Subject: wiki structure policy (was: Re: Wiki tip for the week of Jan 26
 2009: Moving pages with ease)
In-Reply-To: <20090126053057.GA1630@gmail.com>
References: <20090126053057.GA1630@gmail.com>
Message-ID: <497D4DF7.4040704@leemhuis.info>

On 26.01.2009 06:30, Ian Weller wrote:
> 
> 
> Wiki tip of the week for Jan 26 2009: Moving pages with ease
> ============================================================
> 
> With the new page naming and wiki structure policy[1] in place, 
> [...]
> [1]: https://fedoraproject.org/wiki/Help:Wiki_structure

One question regarding that wiki structure policy: How can I watch a 
certain set of wiki pages closely? In the past I simply read the rss 
feed with rss2email and looked out for pages that started with EPEL/, 
Packaging/ or Feature/ (for example) and ignored the others. That 
doesn't work anymore, thus I'm looking for a alternative.

CU
knurd



From sundaram at fedoraproject.org  Mon Jan 26 07:26:34 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 12:56:34 +0530
Subject: where are the ss5 maintaner ?
In-Reply-To: <d3ceea380901241551j5d090739i5f2eb2c391486aaa@mail.gmail.com>
References: <d3ceea380901241551j5d090739i5f2eb2c391486aaa@mail.gmail.com>
Message-ID: <497D65AA.1070609@fedoraproject.org>

Itamar Reis Peixoto wrote:
> where are the ss5 maintainer ?
> 
> 
> https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5

Every maintainer automatically has a <package>-owner AT 
fedoraproject.org alias to reach them. You can also query buggybot in 
#fedora-devel


Rahul



From sundaram at fedoraproject.org  Mon Jan 26 07:49:56 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 13:19:56 +0530
Subject: Lack of update information
Message-ID: <497D6B24.8050702@fedoraproject.org>

Hi,

A while back, I tried to selectively update some packages and noticed 
that the update information provided by package maintainers (seen via 
PackageKit) is sorely lacking.

* Update foo to upstream 2.16.2

Was very common, which is practically useless since it doesn't refer to 
upstream or downstream bugzillas or feature list or changelog. Would it 
be useful to introduce some guidelines to cover this?

Rahul



From belegdol at gmail.com  Mon Jan 26 08:11:34 2009
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 26 Jan 2009 09:11:34 +0100
Subject: Problems with ssh-add
In-Reply-To: <200901260303.n0Q33L4i020907@laptop14.inf.utfsm.cl>
References: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>	<497C52CA.9070100@gmail.com>
	<200901260303.n0Q33L4i020907@laptop14.inf.utfsm.cl>
Message-ID: <497D7036.2090508@gmail.com>

Horst H. von Brand pisze:
> Julian Sikorski <belegdol at gmail.com> wrote:
>> Horst H. von Brand pisze:
>>> Rawhide x86_64 Gnome
>>>
>>> For something like a week now each time I run ssh-add it works fine, but
>>> then trying to use the ssh key ssh complains 
>>>
>>>   $ ssh quelen.inf.utfsm.cl
>>>   Error reading response length from authentication socket.
>>>   vonbrand at quelen.inf.utfsm.cl's password:
>>>
>>> After that, ssh just asks for the password, and:
>>>
>>>   $ ssh-add
>>>   Could not open a connection to your authentication agent.
>>>
>>> I got lost in this whole business of who exactly is the autentication agent
>>> now, so I don't know who to BZ against.
>> Does it happen after you resume from S3?
> 
> Only tried to hibernate this machine once by accident. Got a complete hang,
> didn't try again.
> 
> And seahorse is running, and doesn't get killed when trying to use ssh once.
I was told in a bug that it is gnome-keyring-daemon that plays the role
of ssh agent, not seahorse.
Also, I meant S4 (hibernate) instead of S3 (suspend), the latter does
not break the agent.

Regards,
Julian



From rawhide at fedoraproject.org  Mon Jan 26 08:13:19 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Mon, 26 Jan 2009 08:13:19 +0000 (UTC)
Subject: rawhide report: 20090126 changes
Message-ID: <20090126081319.6554E1F825C@releng2.fedora.phx.redhat.com>

Compose started at Mon Jan 26 06:01:03 UTC 2009

New package ctan-kerkis-fonts
        Kerkis Type 1 fonts
New package jpcap
        A Java library for capturing and sending network packets
New package pax-utils
        PaX aware and related utilities for ELF binaries
New package raddump
        RADIUS packets interpreter
New package viking
        GPS data editor and analyzer
New package w_scan
        Tool for scanning DVB-C/T transponders
Updated Packages:

allegro-4.2.2-11.fc11
---------------------
* Sun Jan 25 17:00:00 2009 Hans de Goede <j.w.r.degoede at hhs.nl> 4.2.2-11
- Fix wrong file path in semanage call in scriptlets (#481407)


arj-3.10.22-6.fc11
------------------

beldi-0.9.23-1.fc11
-------------------

bitlbee-1.2.3-1.fc11
--------------------

cairo-dock-2.0.0-0.3.svn1501_trunk.fc11
---------------------------------------
* Mon Jan 26 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 1501


calamaris-2.59-1.fc11
---------------------

compiz-fusion-extras-0.7.8-5.fc11
---------------------------------
* Sun Jan 25 17:00:00 2009 Adel Gadllah <adel.gadllah at gmail.com> 0.7.8-5
- Build with libnotify support


ddclient-3.7.3-1.fc11
---------------------

deluge-1.1.1-1.fc11
-------------------
* Sun Jan 25 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> - 1.1.1-1
- Update to new upstream bug-fix release (1.1.1)


digitemp-3.6.0-1.fc11
---------------------
* Sun Jan 25 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 3.6.0-1
- Upgrade to 3.6.0


dircproxy-1.2.0-0.9.RC1.fc11
----------------------------
* Sun Jan 25 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.2.0-0.9.RC1
- Update to RC1


dnssec-conf-1.13-2.fc11
-----------------------

dsniff-2.4-0.4.b1.fc11
----------------------

duplicity-0.5.06-1.fc11
-----------------------
* Sun Jan 25 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 0.5.06-1
- Upgrade to 0.5.06 (#481489)


eggdrop-1.6.19-2.fc11
---------------------

erlang-pgsql-0-2.20080825svn.fc11
---------------------------------

gambas-1.0.19-7.fc11
--------------------

gkrellm-top-2.2.11-1.fc11
-------------------------

glog-0.2-2.fc11
---------------
* Sun Jan 25 17:00:00 2009 John A. Khvatov <ivaxer at fedoraproject.org> 0.2-2
- update to 0.2


glpi-0.71.4-1.fc11
------------------
* Mon Jan 26 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> - 0.71.4-1
- update to 0.71.4 (Security Release)


gtk2-2.15.1-4.fc11
------------------
* Sun Jan 25 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.1-4
- Draw radio action proxies as radio menuitems
- Fix issues with toolitem action proxies and overflow


hatari-1.2.0-1.fc11
-------------------
* Sat Jan 24 17:00:00 2009 Andrea Musuruane <musuruan at gmail.com> 1.2.0-1
- updated to upstream 1.2.0
- dropped no longer needed hmsa tool patch
- updated upstream URL
- updated Source0 URL


iftop-0.17-7.fc11
-----------------

jasper-1.900.1-9.fc11
---------------------
* Sun Jan 25 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 1.900.1-9
- patch for "jpc_dec_tiledecode: Assertion `dec->numcomps == 3' failed)
  (#481284, #481291)


kde-l10n-4.2.0-1.fc11
---------------------
* Thu Jan 22 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-1
- 4.2.0

* Sat Jan 10 17:00:00 2009 Than Ngo <than at redhat.com> - 4.1.96-2
- remove debug


libburn-0.6.0-2.fc11
--------------------
* Sat Jan 24 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.6.0-2
- Updating to pl01 tarball from upstream
- Fixed project URL


libisofs-0.6.12-1.fc11
----------------------
* Sun Jan 25 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.6.12-1
- Update to 0.6.12 upstream version


libnids-1.23-1.fc11
-------------------

libopm-0.1-7.20050731cvs.fc11
-----------------------------

libsoup-2.25.4-2.fc11
---------------------
* Sun Jan 25 17:00:00 2009 Matthias Clasen  <mclasen at redhat.com> - 2.25.4-2
- Build against libproxy


mgopen-fonts-0.20050515-14.fc11
-------------------------------
* Sun Jan 25 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 0.20050515-14
- Fix fontconfig file for moderna ,i.e. 
  https://bugzilla.redhat.com/show_bug.cgi?id=477425#c7


mimedefang-2.65-1.fc11
----------------------

net6-1.3.9-1.fc11
-----------------
* Sun Jan 25 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 1.3.9-1
- Update to 1.3.9


obby-0.4.7-1.fc11
-----------------
* Sun Jan 25 17:00:00 2009 Luke Macken <lmacken at redhat.com> - 0.4.7-1
- Update to 0.4.7


openoffice.org-3.0.1-15.5.fc11
------------------------------
* Sat Jan 24 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> - 1:3.0.1-15.5
- cjkunifonts-uming -> cjkuni-uming-fonts


perl-CGI-SpeedyCGI-2.22-4.fc11
------------------------------

perl-CPAN-Mini-0.576-1.fc11
---------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.576-1
- update to 0.576


perl-Catalyst-Manual-5.7016-1.fc11
----------------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 5.7016-1
- update to 5.7016


perl-Catalyst-Plugin-Authentication-0.100092-1.fc11
---------------------------------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.100092-1
- update to 0.100092


perl-Catalyst-Plugin-ConfigLoader-0.22-1.fc11
---------------------------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.22-1
- update to 0.22
- add br on MRO::Compat


perl-Class-C3-0.20-1.fc11
-------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.20-1
- update to 0.20


perl-Gtk2-GladeXML-1.007-1.fc11
-------------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 1.007-1
- update to 1.007
- correct license tag (LGPLv2+, _not_ GPLv2+)
- minor spec tweaks, mostly cosmetic


perl-Gtk2-Notify-0.05-1.fc11
----------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.05-1
- update to 0.05


perl-Gtk2-Sexy-0.05-1.fc11
--------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.05-1
- update to 0.05


perl-MooseX-Role-Parameterized-0.03-1.fc11
------------------------------------------
* Sun Jan 25 17:00:00 2009 Chris Weyl <cweyl at alumni.drew.edu> 0.03-1
- update to 0.03


perl-Net-LibIDN-0.11-1.fc11
---------------------------
* Sun Jan 25 17:00:00 2009 Robert Scheck <robert at fedoraproject.org> 0.11-1
- Upgrade to 0.11


perl-Razor-Agent-2.85-1.fc11
----------------------------

perl-ccom-1.4.1-2.fc11
----------------------

php-idn-1.2-4.fc11
------------------

php-magickwand-1.0.7-2.fc11
---------------------------

showimg-0.9.5-20.fc11
---------------------
* Sat Jan 24 17:00:00 2009 Aurelien Bompard <abompard at fedoraproject.org> 0.9.5-20
- rebuild for mysql


sip-redirect-0.1.2-2.fc11
-------------------------

soundmodem-0.10-6.fc11
----------------------
* Sun Jan 25 17:00:00 2009 Lucian Langa <cooly at gnome.eu.org> - 0.10-6
- apply debian patch for tx switching in ALSA mode


supertuxkart-0.6-1.fc11
-----------------------
* Sun Jan 25 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.6-1
- New upstream release 0.6


tcpick-0.2.1-14.fc11
--------------------

twinkle-1.4-1.fc11
------------------
* Sun Jan 25 17:00:00 2009 Kevin Fenzi <kevin at tummy.com> - 1.4-1
- Update to 1.4


twitux-0.69-1.fc11
------------------
* Sun Jan 25 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.69-1
- Update to 0.69.


ucview-0.22-2.fc11
------------------

unicap-0.9.3-1.fc11
-------------------

xfburn-0.4.0-1.fc11
-------------------
* Mon Jan 26 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.4.0-1
- Update to upstream 0.4.0


Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 60
Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.x86_64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.ppc requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From belegdol at gmail.com  Mon Jan 26 08:16:45 2009
From: belegdol at gmail.com (Julian Sikorski)
Date: Mon, 26 Jan 2009 09:16:45 +0100
Subject: Lack of update information
In-Reply-To: <497D6B24.8050702@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
Message-ID: <497D716D.3060709@gmail.com>

Rahul Sundaram pisze:
> Hi,
> 
> A while back, I tried to selectively update some packages and noticed
> that the update information provided by package maintainers (seen via
> PackageKit) is sorely lacking.
> 
> * Update foo to upstream 2.16.2
> 
> Was very common, which is practically useless since it doesn't refer to
> upstream or downstream bugzillas or feature list or changelog. Would it
> be useful to introduce some guidelines to cover this?
> 
> Rahul
> 
While I'm always trying to be precise in my update notes, I only
maintain a handful of packages. I can understand how putting verbose
update notes can be a daunting task. Also, what's the problem of going
to upstream website to check what changed in 2.16.2? Or to
/usr/share/doc/foo-2.16.2-1? I think that a more sane reason to put
elaborate update notes would be some packaging changes/patches within
one upstream version.
Btw, how about pulling the data from spec %changelog automatically?

Regards,
Julian



From drago01 at gmail.com  Mon Jan 26 08:28:00 2009
From: drago01 at gmail.com (drago01)
Date: Mon, 26 Jan 2009 09:28:00 +0100
Subject: Lack of update information
In-Reply-To: <497D716D.3060709@gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
Message-ID: <f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>

On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
> Rahul Sundaram pisze:
>> Hi,
>>
>> A while back, I tried to selectively update some packages and noticed
>> that the update information provided by package maintainers (seen via
>> PackageKit) is sorely lacking.
>>
>> * Update foo to upstream 2.16.2
>[..]
> Btw, how about pulling the data from spec %changelog automatically?

Well in most cases the changelog will just contain the same "update to x.y.z"
For some packages the changes just aren't  worth listing.
For example each iw release only contain minor changes, people that
really care about them know how to look it up.
I could also just add "Small fixes and minor updates from upstream"
but that's the same as "Update to x.y.z".
Copying the upstream changelog, that must people do not understand
does not help either.



From sundaram at fedoraproject.org  Mon Jan 26 08:42:19 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 14:12:19 +0530
Subject: Lack of update information
In-Reply-To: <497D716D.3060709@gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
Message-ID: <497D776B.3020609@fedoraproject.org>

Julian Sikorski wrote:

> While I'm always trying to be precise in my update notes, I only
> maintain a handful of packages. I can understand how putting verbose
> update notes can be a daunting task. Also, what's the problem of going
> to upstream website to check what changed in 2.16.2?

Problem is finding out such information. It isn't easy at all for end 
users to do and sometimes doesn't exist in the upstream website. It 
would be very useful if package maintainers spend a little bit more time 
including more complete descriptions in the updates. Note that, I am 
referring here to description that is part of bodhi update and not the 
changelog which can be very brief.

Rahul



From robert at fedoraproject.org  Mon Jan 26 08:49:39 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 09:49:39 +0100
Subject: Lack of update information
In-Reply-To: <497D6B24.8050702@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
Message-ID: <20090126084939.GA16919@hurricane.linuxnetz.de>

On Mon, 26 Jan 2009, Rahul Sundaram wrote:
> Was very common, which is practically useless since it doesn't refer to  
> upstream or downstream bugzillas or feature list or changelog. Would it  
> be useful to introduce some guidelines to cover this?

Well, %changelog should be only used for RPM changes, not for upstream
ones. Something else seems abusing %changelog for me.

Anyway most projects are delivering %doc ChangeLog, %doc Changes, %doc
NEWS. Why is PackageKit not able to handle such things and to show that
changelog or these news?

The only thing looking reasonable to me, would be e.g. a a bugzilla number
after the %changelog entry, which refers to that, but on the other hand why
opening a bug report for each package update?

Finally, I don't get your idea to do things twice.

Instead of that, I really would like to see PackageKit reading Bodhi texts
and not only the bug report numbers. I'm always using the text, I can enter
in Bodhi for upstream and downstream changes. But they're only going to the
mailing lists, not to the PackageKit user - and that's wrong and has to be
changed ASAP. Maybe we can make a guideline for this to cover it...


Greetings,
  Robert



From sundaram at fedoraproject.org  Mon Jan 26 09:01:17 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 14:31:17 +0530
Subject: Lack of update information
In-Reply-To: <20090126084939.GA16919@hurricane.linuxnetz.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126084939.GA16919@hurricane.linuxnetz.de>
Message-ID: <497D7BDD.4030508@fedoraproject.org>

Robert Scheck wrote:
> On Mon, 26 Jan 2009, Rahul Sundaram wrote:
>> Was very common, which is practically useless since it doesn't refer to  
>> upstream or downstream bugzillas or feature list or changelog. Would it  
>> be useful to introduce some guidelines to cover this?
> 
> Well, %changelog should be only used for RPM changes, not for upstream
> ones. Something else seems abusing %changelog for me.

I wasn't talking about changelog at all but update descriptions that are 
put out by maintainers via bodhi. These two serve different purposes. 
One is brief package changelog meant more developers and other is for 
end users and should include upstream changes as well. If you are just 
copy pasting changelog information, then, yes PackageKit might as well 
as show that but that's not the case.

Rahul



From hughsient at gmail.com  Mon Jan 26 09:08:28 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 26 Jan 2009 09:08:28 +0000
Subject: Lack of update information
In-Reply-To: <497D6B24.8050702@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
Message-ID: <1232960908.4081.10.camel@hughsie-work.lan>

On Mon, 2009-01-26 at 13:19 +0530, Rahul Sundaram wrote:
> Hi,
> 
> A while back, I tried to selectively update some packages and noticed 
> that the update information provided by package maintainers (seen via 
> PackageKit) is sorely lacking.
> 
> * Update foo to upstream 2.16.2

Some people don't even put that into Bohdi. I think that some update
text and CVE's should be mandatory and bugzillas should be recommended.

Unless packagers use Bohdi, PackageKit can't really do anything clever
using upstream ChangeLogs and stuff like that.

Richard.




From dan at danny.cz  Mon Jan 26 09:23:45 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 26 Jan 2009 10:23:45 +0100
Subject: Lack of update information
In-Reply-To: <20090126084939.GA16919@hurricane.linuxnetz.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126084939.GA16919@hurricane.linuxnetz.de>
Message-ID: <1232961825.8757.16.camel@eagle.danny.cz>

Robert Scheck p??e v Po 26. 01. 2009 v 09:49 +0100:
> On Mon, 26 Jan 2009, Rahul Sundaram wrote:
> > Was very common, which is practically useless since it doesn't refer to  
> > upstream or downstream bugzillas or feature list or changelog. Would it  
> > be useful to introduce some guidelines to cover this?
> 
> Well, %changelog should be only used for RPM changes, not for upstream
> ones. Something else seems abusing %changelog for me.
> 
> Anyway most projects are delivering %doc ChangeLog, %doc Changes, %doc
> NEWS. Why is PackageKit not able to handle such things and to show that
> changelog or these news?

And there is also the URL tag in the spec file.


		Dan




From dan at danny.cz  Mon Jan 26 09:26:15 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 26 Jan 2009 10:26:15 +0100
Subject: Lack of update information
In-Reply-To: <1232960908.4081.10.camel@hughsie-work.lan>
References: <497D6B24.8050702@fedoraproject.org>
	<1232960908.4081.10.camel@hughsie-work.lan>
Message-ID: <1232961975.8757.18.camel@eagle.danny.cz>

Richard Hughes p??e v Po 26. 01. 2009 v 09:08 +0000:
> On Mon, 2009-01-26 at 13:19 +0530, Rahul Sundaram wrote:
> > Hi,
> > 
> > A while back, I tried to selectively update some packages and noticed 
> > that the update information provided by package maintainers (seen via 
> > PackageKit) is sorely lacking.
> > 
> > * Update foo to upstream 2.16.2
> 
> Some people don't even put that into Bohdi. I think that some update
> text and CVE's should be mandatory and bugzillas should be recommended.
> 
> Unless packagers use Bohdi, PackageKit can't really do anything clever
> using upstream ChangeLogs and stuff like that.

It should be possible to automagically include "clog" into the bodhi
template when creating the update from the command line.


		Dan




From kevin.kofler at chello.at  Mon Jan 26 09:31:33 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 10:31:33 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<1232960908.4081.10.camel@hughsie-work.lan>
	<1232961975.8757.18.camel@eagle.danny.cz>
Message-ID: <gljvtl$vds$1@ger.gmane.org>

Dan Hor?k wrote:
> It should be possible to automagically include "clog" into the bodhi
> template when creating the update from the command line.

That doesn't help much because the RPM changelog usually just says "update
to 1.2.3".

        Kevin Kofler



From dan at danny.cz  Mon Jan 26 09:41:58 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 26 Jan 2009 10:41:58 +0100
Subject: Lack of update information
In-Reply-To: <gljvtl$vds$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<1232960908.4081.10.camel@hughsie-work.lan>
	<1232961975.8757.18.camel@eagle.danny.cz> <gljvtl$vds$1@ger.gmane.org>
Message-ID: <1232962918.8757.22.camel@eagle.danny.cz>

Kevin Kofler p??e v Po 26. 01. 2009 v 10:31 +0100:
> Dan Hor?k wrote:
> > It should be possible to automagically include "clog" into the bodhi
> > template when creating the update from the command line.
> 
> That doesn't help much because the RPM changelog usually just says "update
> to 1.2.3".

But you will have at least this and the main point is that it is done
without manual intervention.


		Dan




From rrakus at redhat.com  Mon Jan 26 09:48:04 2009
From: rrakus at redhat.com (Roman Rakus)
Date: Mon, 26 Jan 2009 10:48:04 +0100
Subject: bash-4.0-rc1
Message-ID: <497D86D4.6000607@redhat.com>

Hi.
I'm preparing bash 4.0 rc1 to rawhide. Trying to finish before freeze. 
To ensure this change as smooth as possible, everyone can read changes 
section and inform me about any issue. For now you can pick a bash from 
gnu's ftp: http://ftp.gnu.org/gnu/bash/bash-4.0-rc1.tar.gz
RR



From mmaslano at redhat.com  Mon Jan 26 09:50:37 2009
From: mmaslano at redhat.com (Marcela Maslanova)
Date: Mon, 26 Jan 2009 10:50:37 +0100
Subject: Restart anacron on hibernate/resume
In-Reply-To: <1232875496.2955.5.camel@poytakone.lan>
References: <1232875496.2955.5.camel@poytakone.lan>
Message-ID: <497D876D.4070304@redhat.com>

Ville-Pekka Vainio wrote:
> Hi all,
> 
> Below is a message I sent to the fedora-list a while ago. I didn't
> really get that many answers, so I'd like to discuss the issue on this
> list too.
> 
> The main point here is: does Fedora restart anacron after a
> suspend/hibernate and resume cycle (probably not) and should it?
> 
> As you may know, Ubuntu 8.04.2 was recently released and they have
> apparently fixed a similar issue. In <http://lwn.net/Articles/316224/>
> it says "Stop/start anacron on suspend/resume and on power-cycle
> (#249220)".
> 
> 
> Ville-Pekka Vainio
> 
> 
Hello,
I was testing for some time changes in crontabs/anacron, which should 
fix running daily jobs after hibernation and running daily jobs only 
once per day. I didn't use pm-utils hacks like Ubuntu to make anacron 
work because this hack didn't solve 'don't run daily jobs twice' problem.
Anacron is now checking every hour daily jobs whether they ran or not 
and execute them only once per day. I put this changes into rawhide, 
I'll be glad if you can test it.
Regards,
-- 
Marcela Ma?l??ov?
BaseOS team Brno



From tim at niemueller.de  Mon Jan 26 10:02:19 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Mon, 26 Jan 2009 11:02:19 +0100
Subject: bash-4.0-rc1
In-Reply-To: <497D86D4.6000607@redhat.com>
References: <497D86D4.6000607@redhat.com>
Message-ID: <497D8A2B.9040006@niemueller.de>

Roman Rakus schrieb:
> I'm preparing bash 4.0 rc1 to rawhide. Trying to finish before freeze.
> To ensure this change as smooth as possible, everyone can read changes
> section and inform me about any issue. For now you can pick a bash from
> gnu's ftp: http://ftp.gnu.org/gnu/bash/bash-4.0-rc1.tar.gz

What are the major changes that make up a new major release? All I saw
in the changelog were dozens of "Fixed X" entries and the bash website
is not very helpful either. Anything really new or any stuff that could
break existing scripts easily?

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From sundaram at fedoraproject.org  Mon Jan 26 10:07:02 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 15:37:02 +0530
Subject: bash-4.0-rc1
In-Reply-To: <497D86D4.6000607@redhat.com>
References: <497D86D4.6000607@redhat.com>
Message-ID: <497D8B46.4080800@fedoraproject.org>

Roman Rakus wrote:
> Hi.
> I'm preparing bash 4.0 rc1 to rawhide. Trying to finish before freeze. 
> To ensure this change as smooth as possible, everyone can read changes 
> section and inform me about any issue. For now you can pick a bash from 
> gnu's ftp: http://ftp.gnu.org/gnu/bash/bash-4.0-rc1.tar.gz

What about http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/. 
Did this get enabled by default? Did the patch go upstream?

Rahul



From vpivaini at cs.helsinki.fi  Mon Jan 26 10:13:02 2009
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Mon, 26 Jan 2009 12:13:02 +0200
Subject: Restart anacron on hibernate/resume
In-Reply-To: <497D876D.4070304@redhat.com>
References: <1232875496.2955.5.camel@poytakone.lan>
	<497D876D.4070304@redhat.com>
Message-ID: <1232964782.5441.2.camel@localhost.localdomain>

ma, 2009-01-26 kello 10:50 +0100, Marcela Maslanova kirjoitti:
> Anacron is now checking every hour daily jobs whether they ran or not 
> and execute them only once per day. I put this changes into rawhide, 
> I'll be glad if you can test it.

Good to hear, thanks. I have a Rawhide installation, but I'm not using
it that often. I'll try to give it some testing and report bugs if
needed.


-- 
Ville-Pekka Vainio



From jakub at redhat.com  Mon Jan 26 10:15:01 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 11:15:01 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for glibc
Message-ID: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>

Hi!

dist-f11-gcc44 currently has gcc 4.4.0-0.X packages, which are almost ready
for moving into dist-f11, but before doing that, I'd like to discuss
defaults.  gcc on most arches has a switch to select which ISA it can assume
(i.e. what minimum CPU will gcc compiled code run on) and a separate option
to tune for the same or other CPU.  Currently in Fedora the tuning is
I believe:
		ISA		 tuning
i386		-march=i386	 -mtune=generic
x86_64		-march=x86-64	 -mtune=generic
ppc		lowest		 -mtune=power6
ppc64		lowest		 -mtune=power6
s390		-march=g5	 -mtune=z9-109
s390x		-march=z900	 -mtune=z9-109
ia64		lowest		 -mtune=itanium2
sparc		-mcpu=v7	 -mtune=v7
sparcv9		-mcpu=v7	 -mtune=v7
sparc64		-mcpu=ultrasparc -mtune=ultrasparc

plus redhat-rpm-config tweaks something (-fasynchronous-unwind-tables
and -mminimal-toc tweaking should IMHO remain in redhat-rpm-config):
i686		-march=i686	 -mtune=generic
sparc		-mcpu=v7	 -mtune=ultrasparc
sparcv9		-mcpu=ultrasparc -mtune=ultrasparc

The question is, do we want to change anything on this for F11?
E.g. I believe Fedora hasn't shipped an i386 or i486 kernel for years,
and especially the -march=i386 vs. -march=i486 difference is significant
(-march=i386 doesn't have sufficient atomic instructions).  The only
-lpthread library we are using is NPTL and that doesn't support i386
anyway, so I think we should either use -march=i486 or -march=i586
(the latter has 8 byte compare and swap instruction) as the default,
when -march= isn't specified.
Similarly, I wonder what CPUs we want to support in Fedora for PowerPC,
if e.g. -march=power4 default wouldn't be possible.  On s390, is somebody
running Fedora on some 31-bit hw still (G5/G6), or could we safely default to
-march=z900 for -m31 as well and say -mtune=z10?  On sparc I guess
we could just -mcpu=ultrasparc -mtune=ultrasparc always, given that the
32-bit support is being dropped.

Another question is if we finally could bump the minimum supported kernel
version in Fedora 11 glibc.  Currently Fedora 10 glibc requires 2.6.9 or
later kernel, which means it can't assume a lot of stuff (e.g. private
futexes, a lot of added syscalls etc.), which means it has to test for them
at runtime of every program (e.g. every threaded program does a dummy futex
syscall to check for private futexes, for futex realtime clock support and
has to use variables for this, instead of oring constants in the mutexes
etc., and glibc has to check for ENOSYS and have fallbacks compiled in).
2.6.9 default comes I think still from the RHEL4 kernels.
Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
only runs on 2.6.29 and later kernels, but we could gain speed and decrease
size of glibc shared libraries.

For the -march/-mcpu default changes, I think nothing is required from the
koji build infrastructure (I don't think there are 31-bit mainframes
around in koji/brew and I don't think there are 32-bit powerpcs or
i386/i486s among the build boxes either), on the other side that decision
has to be made almost immediately (before the world is rebuilt with gcc
4.4.0).

For glibc --enable-kernel= default this requires that all koji build boxes
and anything else that needs to run Fedora 11 binaries runs at least 2.6.29
kernels, but the change might be still delayed for a few weeks.

	Jakub



From ml at bendler-net.de  Mon Jan 26 10:37:29 2009
From: ml at bendler-net.de (Thomas Bendler)
Date: Mon, 26 Jan 2009 11:37:29 +0100
Subject: Root Logins in X...
In-Reply-To: <2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
	<1232632284.13042.23.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>
Message-ID: <e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>

2009/1/22 Dr. Diesel <dr.diesel at gmail.com>

> [...]
> Not sure how or why we would try to prevent utter stupidity!  I am firmly
> against forcing uses in any direction.
> Please just make it easy to switch back.
>

A root login on X is not nessaccary, in no situation (except the design of
your installation is crap or you switch to init S and you have password
based login enabled). But it cause big problems if you talk about audit and
other nice security and controls. So for what reason should there be a root
login in X. It is not even needed in a console. Everything could be done
with normal user rights and escalation of privilegies on specific tasks.

Regars, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/65e76ca5/attachment.htm>

From ml at bendler-net.de  Mon Jan 26 10:49:17 2009
From: ml at bendler-net.de (Thomas Bendler)
Date: Mon, 26 Jan 2009 11:49:17 +0100
Subject: F10 and no root login - impossible to maintain systems!
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B42@catoexm05.noam.corp.platform.com>
Message-ID: <e5f36bc70901260249y5c90b841l992d8944b9930bd5@mail.gmail.com>

On Thu, Jan 22, 2009 at 7:17 PM, Shawn Starr <sstarr at platform.com> wrote:

> [...]
> I'm going to jump into this flamefest, Can we STOP with the "Mother knows
> best" menality in Fedora? I have needed to log in as root with X a few
> times.     Stop turning Fedora into a 'Ubuntu'.


Then you have done something wrong. I never used a root login on X and I
administrate a lot of UNIX systems (not only LNX). There is no reason where
you need it (except a wrong system installation or system design).

Regards, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/5f4f2bd2/attachment.htm>

From rrakus at redhat.com  Mon Jan 26 10:53:09 2009
From: rrakus at redhat.com (Roman Rakus)
Date: Mon, 26 Jan 2009 11:53:09 +0100
Subject: bash-4.0-rc1
In-Reply-To: <497D8A2B.9040006@niemueller.de>
References: <497D86D4.6000607@redhat.com> <497D8A2B.9040006@niemueller.de>
Message-ID: <497D9615.9060501@redhat.com>

Tim Niemueller wrote:
> Roman Rakus schrieb:
>   
>> I'm preparing bash 4.0 rc1 to rawhide. Trying to finish before freeze.
>> To ensure this change as smooth as possible, everyone can read changes
>> section and inform me about any issue. For now you can pick a bash from
>> gnu's ftp: http://ftp.gnu.org/gnu/bash/bash-4.0-rc1.tar.gz
>>     
>
> What are the major changes that make up a new major release? All I saw
> in the changelog were dozens of "Fixed X" entries and the bash website
> is not very helpful either. Anything really new or any stuff that could
> break existing scripts easily?
>
> 	Tim
>
>   
quotation from upstream:
'''

The most notable new features are associative arrays, improvements to the
programmable completion functionality, case-modifying word expansions,
co-processes, support for the `**' special glob pattern, and additions to
the shell syntax and redirections.  The shell has been changed to be more
rigorous about parsing commands inside command substitutions, fixing one
piece of Posix non-compliance.

'''

I don't see anything that could break anything.
RR



From rrakus at redhat.com  Mon Jan 26 10:59:20 2009
From: rrakus at redhat.com (Roman Rakus)
Date: Mon, 26 Jan 2009 11:59:20 +0100
Subject: bash-4.0-rc1
In-Reply-To: <497D8B46.4080800@fedoraproject.org>
References: <497D86D4.6000607@redhat.com> <497D8B46.4080800@fedoraproject.org>
Message-ID: <497D9788.7060401@redhat.com>

Rahul Sundaram wrote:
> Roman Rakus wrote:
>> Hi.
>> I'm preparing bash 4.0 rc1 to rawhide. Trying to finish before 
>> freeze. To ensure this change as smooth as possible, everyone can 
>> read changes section and inform me about any issue. For now you can 
>> pick a bash from gnu's ftp: 
>> http://ftp.gnu.org/gnu/bash/bash-4.0-rc1.tar.gz
>
> What about 
> http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/. Did this 
> get enabled by default? Did the patch go upstream?
>
> Rahul
>
Yes. Yes. The handler name by default is "command_not_found_handle".
RR



From dominik at greysector.net  Mon Jan 26 11:06:49 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 26 Jan 2009 12:06:49 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
In-Reply-To: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126110648.GA8937@mokona.greysector.net>

On Monday, 26 January 2009 at 11:15, Jakub Jelinek wrote:
> Hi!
> 
> dist-f11-gcc44 currently has gcc 4.4.0-0.X packages, which are almost ready
> for moving into dist-f11, but before doing that, I'd like to discuss
> defaults.  gcc on most arches has a switch to select which ISA it can assume
> (i.e. what minimum CPU will gcc compiled code run on) and a separate option
> to tune for the same or other CPU.  Currently in Fedora the tuning is
> I believe:
> 		ISA		 tuning
> i386		-march=i386	 -mtune=generic
> x86_64		-march=x86-64	 -mtune=generic
> ppc		lowest		 -mtune=power6
> ppc64		lowest		 -mtune=power6
> s390		-march=g5	 -mtune=z9-109
> s390x		-march=z900	 -mtune=z9-109
> ia64		lowest		 -mtune=itanium2
> sparc		-mcpu=v7	 -mtune=v7
> sparcv9		-mcpu=v7	 -mtune=v7
> sparc64		-mcpu=ultrasparc -mtune=ultrasparc
> 
> plus redhat-rpm-config tweaks something (-fasynchronous-unwind-tables
> and -mminimal-toc tweaking should IMHO remain in redhat-rpm-config):
> i686		-march=i686	 -mtune=generic
> sparc		-mcpu=v7	 -mtune=ultrasparc
> sparcv9		-mcpu=ultrasparc -mtune=ultrasparc
> 
> The question is, do we want to change anything on this for F11?
> E.g. I believe Fedora hasn't shipped an i386 or i486 kernel for years,
> and especially the -march=i386 vs. -march=i486 difference is significant
> (-march=i386 doesn't have sufficient atomic instructions).  The only
> -lpthread library we are using is NPTL and that doesn't support i386
> anyway, so I think we should either use -march=i486 or -march=i586
> (the latter has 8 byte compare and swap instruction) as the default,
> when -march= isn't specified.

I don't know about non-x86 arches (it's probably less of a problem), but
for x86 such change can (as you probably know) affect the overall speed
of the generated code and must be benchmarked. I would be in favour of
changing the default cflags to include -march=i586 if it gives measurable
benefits, i.e. faster binaries and/or smaller code size, but slower binaries
are not acceptable.

[...]
> Another question is if we finally could bump the minimum supported kernel
> version in Fedora 11 glibc.  Currently Fedora 10 glibc requires 2.6.9 or
> later kernel, which means it can't assume a lot of stuff (e.g. private
> futexes, a lot of added syscalls etc.), which means it has to test for them
> at runtime of every program (e.g. every threaded program does a dummy futex
> syscall to check for private futexes, for futex realtime clock support and
> has to use variables for this, instead of oring constants in the mutexes
> etc., and glibc has to check for ENOSYS and have fallbacks compiled in).
> 2.6.9 default comes I think still from the RHEL4 kernels.
> Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
> only runs on 2.6.29 and later kernels, but we could gain speed and decrease
> size of glibc shared libraries.

Could you elaborate more on why it gives a speedup (along with some
benchmarks, preferably) or at least give some links to explanations? If it
really gives us more speed, I'm all for it. One issue to consider, though
is that it'd be impossible to run an OpenVZ-virtualized Fedora 11 instance
on an earlier kernel, but I guess that's a minor issue.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From mcepl at redhat.com  Mon Jan 26 11:11:37 2009
From: mcepl at redhat.com (Matej Cepl)
Date: Mon, 26 Jan 2009 12:11:37 +0100
Subject: plans for kernel in F10?
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
	<5f6f8c5f0901211314u27ed8d52s2600d24325aa632c@mail.gmail.com>
	<20090122012941.GA3657@yoda.jdub.homelinux.org>
	<5f6f8c5f0901212243o2e96c075r1715a5cb95a08c27@mail.gmail.com>
	<f6ca9fed0901240517x7169366djf55897a3a3b326d1@mail.gmail.com>
Message-ID: <9ci056xgbu.ln2@ppp1053.in.ipex.cz>

On 2009-01-24, 13:17 GMT, drago01 wrote:
> you can disable it (pass no modset to the kernel) and fill 

That should read nomodeset (one word).

Mat?j



From kevin.kofler at chello.at  Mon Jan 26 11:20:18 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 12:20:18 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <glk69i$k5q$1@ger.gmane.org>

Jakub Jelinek wrote:
> Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
> only runs on 2.6.29 and later kernels, but we could gain speed and
> decrease size of glibc shared libraries.

The big problem with that is this one:
> For glibc --enable-kernel= default this requires that all koji build boxes
> and anything else that needs to run Fedora 11 binaries runs at least
> 2.6.29 kernels, but the change might be still delayed for a few weeks.

This is also a major inconvenience for local mock builds, which can no
longer be run on older Fedora releases until the kernel gets upgraded nor
on EL5 hosts. Upgrading the kernel on the build host is not always an
option: running a F11 kernel on EL5 or even on older Fedora isn't really
supported, and there are setups where the kernel cannot be upgraded at all
(e.g. Virtuozzo/OpenVZ VPSes or kernels with custom patches which have not
been ported to the latest version yet).

It'd also break online "yum upgrade" F9/F10->F11 upgrades.

I don't think requiring a newer kernel than the EL5 one (2.6.18) is a good
idea.

        Kevin Kofler



From jakub at redhat.com  Mon Jan 26 11:30:10 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 12:30:10 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126110648.GA8937@mokona.greysector.net>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126110648.GA8937@mokona.greysector.net>
Message-ID: <20090126113010.GF5690@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Jan 26, 2009 at 12:06:49PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> I don't know about non-x86 arches (it's probably less of a problem), but
> for x86 such change can (as you probably know) affect the overall speed
> of the generated code and must be benchmarked. I would be in favour of
> changing the default cflags to include -march=i586 if it gives measurable
> benefits, i.e. faster binaries and/or smaller code size, but slower binaries
> are not acceptable.

Performance on i?86 is mostly the matter of -mtune, which should stay the
same (-mtune=generic, tuning for contemporary Intel and AMD CPUs).
The difference between -march=i386 -mtune=generic and -march=i486 -mtune=generic
is just that xadd[bwl], bswap and cmpxchg[bwl] insns can be generated for the
latter, for -march=i586 -mtune=generic also cmpxchg8b insn.  Except for
bswap, that's mainly for __sync_* builtins, OpenMP #pragma omp atomic, and
other users of atomic insns.

	Jakub



From pertusus at free.fr  Mon Jan 26 12:02:02 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 26 Jan 2009 13:02:02 +0100
Subject: Lack of update information
In-Reply-To: <497D6B24.8050702@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
Message-ID: <20090126120202.GA2548@free.fr>

On Mon, Jan 26, 2009 at 01:19:56PM +0530, Rahul Sundaram wrote:
> Hi,
>
> A while back, I tried to selectively update some packages and noticed  
> that the update information provided by package maintainers (seen via  
> PackageKit) is sorely lacking.
>
> * Update foo to upstream 2.16.2
>
> Was very common, which is practically useless since it doesn't refer to  
> upstream or downstream bugzillas or feature list or changelog. Would it  
> be useful to introduce some guidelines to cover this?

It looks good to me, users should refer to the package documentation or
to the package url. The only thing I see that could be made mandatory,
would be to associate it with the fedora bugs that were solved by this 
update.

Also, if the maintainer knows where the information about the update is
it could be nice to have it in bodhi, but not mandatory. Something like

  See some.site.org/release_notes.html for the changes.

or 
  See /usr/share/doc/foo-1.0/NEWS for the changes.

--
Pat



From bochecha at fedoraproject.org  Mon Jan 26 12:12:23 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Mon, 26 Jan 2009 13:12:23 +0100
Subject: Lack of update information
In-Reply-To: <20090126120202.GA2548@free.fr>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
Message-ID: <2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>

> Also, if the maintainer knows where the information about the update is
> it could be nice to have it in bodhi, but not mandatory. Something like
>
>  See some.site.org/release_notes.html for the changes.
>
> or
>  See /usr/share/doc/foo-1.0/NEWS for the changes.

The first one is nice, but the second one causes a problem: how can
you review the changes _before_ updating if the file listing changes
is inside the updated package ?

You could of course yumdownload the package and install it in some
safe root where you would check the file, but we're talking about
reviewing changes in Bohdi / PackageKit, which means avoiding these
kind of acrobatics.

Regards,


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From pertusus at free.fr  Mon Jan 26 12:15:05 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Mon, 26 Jan 2009 13:15:05 +0100
Subject: Lack of update information
In-Reply-To: <2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
Message-ID: <20090126121504.GC2548@free.fr>

On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
> > Also, if the maintainer knows where the information about the update is
> > it could be nice to have it in bodhi, but not mandatory. Something like
> >
> >  See some.site.org/release_notes.html for the changes.
> >
> > or
> >  See /usr/share/doc/foo-1.0/NEWS for the changes.
> 
> The first one is nice, but the second one causes a problem: how can
> you review the changes _before_ updating if the file listing changes
> is inside the updated package ?

You can't. But this is something for upstream, in my opinion.

--
Pat



From alsadi at gmail.com  Mon Jan 26 12:17:37 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Mon, 26 Jan 2009 14:17:37 +0200
Subject: telling gnome-package kit not use NetworkManager
Message-ID: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>

hi,

I temporarily disabled fedora repos and create my own locale repo for
offline installation

yum and yumex works fine but gpk tells me that it can't work off-line
as reported by Netowork manager
how can I tell it to skip checking it

note: kpackagekit passes this



From sundaram at fedoraproject.org  Mon Jan 26 12:22:39 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 17:52:39 +0530
Subject: Lack of update information
In-Reply-To: <20090126121504.GC2548@free.fr>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>
Message-ID: <497DAB0F.109@fedoraproject.org>

Patrice Dumas wrote:
> On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
>>> Also, if the maintainer knows where the information about the update is
>>> it could be nice to have it in bodhi, but not mandatory. Something like
>>>
>>>  See some.site.org/release_notes.html for the changes.
>>>
>>> or
>>>  See /usr/share/doc/foo-1.0/NEWS for the changes.
>> The first one is nice, but the second one causes a problem: how can
>> you review the changes _before_ updating if the file listing changes
>> is inside the updated package ?
> 
> You can't. But this is something for upstream, in my opinion.

If upstream does it on their own, package maintainers must add pointers 
to it. If not, the job of summarizing the need for an update rests with 
the package maintainers since they are the ones pushing it to end users. 
Package maintainers can help upstream in the process if necessary as 
well. Version numbers by themselves don't mean much, if anything at all 
since they aren't used consistently across different projects or even 
between releases.  The whole point of enforcing a description field is 
to help end users get more information beyond just version numbers.

Rahul



From mschmidt at redhat.com  Mon Jan 26 12:34:34 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Mon, 26 Jan 2009 13:34:34 +0100
Subject: telling gnome-package kit not use NetworkManager
In-Reply-To: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>
References: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>
Message-ID: <20090126133434.5472f054@brian.englab.brq.redhat.com>

On Mon, 26 Jan 2009 14:17:37 +0200
Muayyad AlSadi <alsadi at gmail.com> wrote:

> hi,
> 
> I temporarily disabled fedora repos and create my own locale repo for
> offline installation
> 
> yum and yumex works fine but gpk tells me that it can't work off-line
> as reported by Netowork manager
> how can I tell it to skip checking it

/etc/PackageKit/PackageKit.conf: UseNetworkManager

Michal



From jwboyer at gmail.com  Mon Jan 26 12:45:20 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 26 Jan 2009 07:45:20 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126124520.GA2381@yoda.jdub.homelinux.org>

On Mon, Jan 26, 2009 at 11:15:01AM +0100, Jakub Jelinek wrote:
>Hi!
>Similarly, I wonder what CPUs we want to support in Fedora for PowerPC,
>if e.g. -march=power4 default wouldn't be possible.  On s390, is somebody

For ppc, the most common hardware would be the G4 PowerMacs.  Use of
-march=power4 would seem suboptimal there.  Which sort of sucks because
we run as much of the OS as we can at 32-bit, even on 64-bit hardware.
I'll look at this a bit more today and see what -march=power4 would really
do here in terms of compatibility.

For ppc64, using -march=power4 would be fine with me.  We don't really claim
to support the POWER3 or older 64-bit hardware, and POWER4 is fairly close
to the most common CPU (ppc970 in the G5 Mac/Powerstation).

>Another question is if we finally could bump the minimum supported kernel
>version in Fedora 11 glibc.  Currently Fedora 10 glibc requires 2.6.9 or
>later kernel, which means it can't assume a lot of stuff (e.g. private
>futexes, a lot of added syscalls etc.), which means it has to test for them
>at runtime of every program (e.g. every threaded program does a dummy futex
>syscall to check for private futexes, for futex realtime clock support and
>has to use variables for this, instead of oring constants in the mutexes
>etc., and glibc has to check for ENOSYS and have fallbacks compiled in).
>2.6.9 default comes I think still from the RHEL4 kernels.
>Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
>only runs on 2.6.29 and later kernels, but we could gain speed and decrease
>size of glibc shared libraries.
>
>For the -march/-mcpu default changes, I think nothing is required from the
>koji build infrastructure (I don't think there are 31-bit mainframes
>around in koji/brew and I don't think there are 32-bit powerpcs or
>i386/i486s among the build boxes either), on the other side that decision
>has to be made almost immediately (before the world is rebuilt with gcc
>4.4.0).

I'm going to assmue that you are wanting a mass-rebuild of all of Fedora with
gcc 4.4.  Is that going to land this week?  From a scheduling perspective,
if a rebuild is going to happen it would be fairly important to have most of
it done by Beta.  Feature freeze is March 3rd.  Beta freeze is March 10.

>For glibc --enable-kernel= default this requires that all koji build boxes
>and anything else that needs to run Fedora 11 binaries runs at least 2.6.29
>kernels, but the change might be still delayed for a few weeks.

The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
released kernel seems unlikely.

josh



From ngompa13 at gmail.com  Mon Jan 26 12:54:42 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Mon, 26 Jan 2009 06:54:42 -0600
Subject: Root Logins in X...
In-Reply-To: <e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
	<1232632284.13042.23.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>
	<e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>
Message-ID: <8278b1b0901260454w779cf49dh3c0a96f428c87c15@mail.gmail.com>

You will not be able to log in if your home subdirectory and/or its
associated partition is full. Everytime you log in, it writes something, and
if it can't... Well, unless you can log in as root, you are stuck.

2009/1/26 Thomas Bendler <ml at bendler-net.de>

> 2009/1/22 Dr. Diesel <dr.diesel at gmail.com>
>
>> [...]
>> Not sure how or why we would try to prevent utter stupidity!  I am firmly
>> against forcing uses in any direction.
>> Please just make it easy to switch back.
>>
>
> A root login on X is not nessaccary, in no situation (except the design of
> your installation is crap or you switch to init S and you have password
> based login enabled). But it cause big problems if you talk about audit and
> other nice security and controls. So for what reason should there be a root
> login in X. It is not even needed in a console. Everything could be done
> with normal user rights and escalation of privilegies on specific tasks.
>
> Regars, Thomas
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/bfbf7ce8/attachment.htm>

From sundaram at fedoraproject.org  Mon Jan 26 12:59:15 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 18:29:15 +0530
Subject: Root Logins in X...
In-Reply-To: <8278b1b0901260454w779cf49dh3c0a96f428c87c15@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>	<1232626439.2631.17.camel@localhost.localdomain>	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>	<1232632284.13042.23.camel@nibbler.dlib.indiana.edu>	<2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>	<e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>
	<8278b1b0901260454w779cf49dh3c0a96f428c87c15@mail.gmail.com>
Message-ID: <497DB3A3.2060403@fedoraproject.org>

King InuYasha wrote:
> You will not be able to log in if your home subdirectory and/or its 
> associated partition is full. Everytime you log in, it writes something, 
> and if it can't... Well, unless you can log in as root, you are stuck.

File a bug report and get the problem fixed instead of continuously
working around them.

Rahul



From jakub at redhat.com  Mon Jan 26 13:12:09 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 14:12:09 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126124520.GA2381@yoda.jdub.homelinux.org>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
Message-ID: <20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Jan 26, 2009 at 07:45:20AM -0500, Josh Boyer wrote:
> On Mon, Jan 26, 2009 at 11:15:01AM +0100, Jakub Jelinek wrote:
> For ppc, the most common hardware would be the G4 PowerMacs.  Use of
> -march=power4 would seem suboptimal there.  Which sort of sucks because

Suboptimal is probably wrong word, it would preclude Fedora 11 running on
G4.  I guess we can keep -march for -m32 powerpc unchanged then, -mtune
will be still power6.  We can default to -march=power4 for -m32 for RHEL
only (already RHEL5 has power4 built shared glibc libraries).

> >For the -march/-mcpu default changes, I think nothing is required from the
> >koji build infrastructure (I don't think there are 31-bit mainframes
> >around in koji/brew and I don't think there are 32-bit powerpcs or
> >i386/i486s among the build boxes either), on the other side that decision
> >has to be made almost immediately (before the world is rebuilt with gcc
> >4.4.0).
> 
> I'm going to assmue that you are wanting a mass-rebuild of all of Fedora with
> gcc 4.4.  Is that going to land this week?  From a scheduling perspective,
> if a rebuild is going to happen it would be fairly important to have most of
> it done by Beta.  Feature freeze is March 3rd.  Beta freeze is March 10.

Yes, I want a mass rebuild with gcc 4.4 for Fedora 11, and new gcc can land
into dist-f11 during this week.

> >For glibc --enable-kernel= default this requires that all koji build boxes
> >and anything else that needs to run Fedora 11 binaries runs at least 2.6.29
> >kernels, but the change might be still delayed for a few weeks.
> 
> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> released kernel seems unlikely.

I know it is a pain, on the other hand it would really improve Fedora 11.

	Jakub



From jwboyer at gmail.com  Mon Jan 26 13:18:52 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Mon, 26 Jan 2009 08:18:52 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126131852.GB2381@yoda.jdub.homelinux.org>

On Mon, Jan 26, 2009 at 02:12:09PM +0100, Jakub Jelinek wrote:
>On Mon, Jan 26, 2009 at 07:45:20AM -0500, Josh Boyer wrote:
>> On Mon, Jan 26, 2009 at 11:15:01AM +0100, Jakub Jelinek wrote:
>> For ppc, the most common hardware would be the G4 PowerMacs.  Use of
>> -march=power4 would seem suboptimal there.  Which sort of sucks because
>
>Suboptimal is probably wrong word, it would preclude Fedora 11 running on

Yes, I was being cautious because I didn't have any coffee in me yet and
didn't want to proclaim DOOM immediately :).

>G4.  I guess we can keep -march for -m32 powerpc unchanged then, -mtune
>will be still power6.  We can default to -march=power4 for -m32 for RHEL
>only (already RHEL5 has power4 built shared glibc libraries).

OK.  So default32 for ppc, power4 for ppc64.

(btw, it's -mcpu on PowerPC, but you probably knew that already.)

>> >For the -march/-mcpu default changes, I think nothing is required from the
>> >koji build infrastructure (I don't think there are 31-bit mainframes
>> >around in koji/brew and I don't think there are 32-bit powerpcs or
>> >i386/i486s among the build boxes either), on the other side that decision
>> >has to be made almost immediately (before the world is rebuilt with gcc
>> >4.4.0).
>> 
>> I'm going to assmue that you are wanting a mass-rebuild of all of Fedora with
>> gcc 4.4.  Is that going to land this week?  From a scheduling perspective,
>> if a rebuild is going to happen it would be fairly important to have most of
>> it done by Beta.  Feature freeze is March 3rd.  Beta freeze is March 10.
>
>Yes, I want a mass rebuild with gcc 4.4 for Fedora 11, and new gcc can land
>into dist-f11 during this week.

OK.  We'll need to run that past FESCo, but I don't think there will be much
opposition to it.

>> >For glibc --enable-kernel= default this requires that all koji build boxes
>> >and anything else that needs to run Fedora 11 binaries runs at least 2.6.29
>> >kernels, but the change might be still delayed for a few weeks.
>> 
>> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
>> released kernel seems unlikely.
>
>I know it is a pain, on the other hand it would really improve Fedora 11.

I agree.  Does it have to be .29, or would something slightly older (and
theoretically more stable) suffice?  The .27.x release has been in use for
F-9 and F-10 for a while now.

josh



From jakub at redhat.com  Mon Jan 26 13:35:17 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 14:35:17 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126131852.GB2381@yoda.jdub.homelinux.org>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126131852.GB2381@yoda.jdub.homelinux.org>
Message-ID: <20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Jan 26, 2009 at 08:18:52AM -0500, Josh Boyer wrote:
> >I know it is a pain, on the other hand it would really improve Fedora 11.
> 
> I agree.  Does it have to be .29, or would something slightly older (and
> theoretically more stable) suffice?  The .27.x release has been in use for
> F-9 and F-10 for a while now.

For glibc 2.9 (F10) it would suffice to just have .27, but for rawhide
.29 introduces futex bitset and realtime clock support, which means an extra
syscall for every threaded program.  We could bump it in steps, first start
requiring .27 and then if .29 is sufficiently stable in a month (or when
we really need to freeze), rebuild just glibc requiring a newer kernel.

	Jakub



From dan at danny.cz  Mon Jan 26 13:37:28 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 26 Jan 2009 14:37:28 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <1232977048.8757.56.camel@eagle.danny.cz>

Jakub Jelinek p??e v Po 26. 01. 2009 v 11:15 +0100:
> Hi!
> 
> dist-f11-gcc44 currently has gcc 4.4.0-0.X packages, which are almost ready
> for moving into dist-f11, but before doing that, I'd like to discuss
> defaults.  gcc on most arches has a switch to select which ISA it can assume
> (i.e. what minimum CPU will gcc compiled code run on) and a separate option
> to tune for the same or other CPU.  Currently in Fedora the tuning is
> I believe:
> 		ISA		 tuning
> i386		-march=i386	 -mtune=generic
> x86_64		-march=x86-64	 -mtune=generic
> ppc		lowest		 -mtune=power6
> ppc64		lowest		 -mtune=power6
> s390		-march=g5	 -mtune=z9-109
> s390x		-march=z900	 -mtune=z9-109
> ia64		lowest		 -mtune=itanium2
> sparc		-mcpu=v7	 -mtune=v7
> sparcv9		-mcpu=v7	 -mtune=v7
> sparc64		-mcpu=ultrasparc -mtune=ultrasparc
> 
> plus redhat-rpm-config tweaks something (-fasynchronous-unwind-tables
> and -mminimal-toc tweaking should IMHO remain in redhat-rpm-config):
> i686		-march=i686	 -mtune=generic
> sparc		-mcpu=v7	 -mtune=ultrasparc
> sparcv9		-mcpu=ultrasparc -mtune=ultrasparc
> 
> The question is, do we want to change anything on this for F11?
> E.g. I believe Fedora hasn't shipped an i386 or i486 kernel for years,
> and especially the -march=i386 vs. -march=i486 difference is significant
> (-march=i386 doesn't have sufficient atomic instructions).  The only
> -lpthread library we are using is NPTL and that doesn't support i386
> anyway, so I think we should either use -march=i486 or -march=i586
> (the latter has 8 byte compare and swap instruction) as the default,
> when -march= isn't specified.
> Similarly, I wonder what CPUs we want to support in Fedora for PowerPC,
> if e.g. -march=power4 default wouldn't be possible.  On s390, is somebody
> running Fedora on some 31-bit hw still (G5/G6), or could we safely default to
> -march=z900 for -m31 as well and say -mtune=z10?  On sparc I guess

There is no plan for 31-bit Fedora on s390 AFAIK, and regarding 64-bit
please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=463830

> we could just -mcpu=ultrasparc -mtune=ultrasparc always, given that the
> 32-bit support is being dropped.

The general question is what should be the relation between GCC defaults
and parameters set in the rpm build macros.


		Dan




From sundaram at fedoraproject.org  Mon Jan 26 13:45:24 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 19:15:24 +0530
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <1232977048.8757.56.camel@eagle.danny.cz>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<1232977048.8757.56.camel@eagle.danny.cz>
Message-ID: <497DBE74.9010108@fedoraproject.org>

Dan Hor?k wrote:

> There is no plan for 31-bit Fedora on s390 AFAIK, and regarding 64-bit
> please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=463830

Permission seems to be denied to non Red Hat logins.

Rahul



From jakub at redhat.com  Mon Jan 26 13:51:37 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 14:51:37 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <1232977048.8757.56.camel@eagle.danny.cz>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<1232977048.8757.56.camel@eagle.danny.cz>
Message-ID: <20090126135137.GI5690@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Jan 26, 2009 at 02:37:28PM +0100, Dan Hor?k wrote:
> There is no plan for 31-bit Fedora on s390 AFAIK, and regarding 64-bit
> please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=463830

If we are to use -march=z9-109 -mtune=z10 instead of -march=z900 -mtune=z10
for s390 -m31 and -m64, then releng is important.  Aren't the current
mainframes used for Fedora (and RHEL) building z990?  If yes, then this
can't be switched until they are z9-109 or z10 based.

> > we could just -mcpu=ultrasparc -mtune=ultrasparc always, given that the
> > 32-bit support is being dropped.
> 
> The general question is what should be the relation between GCC defaults
> and parameters set in the rpm build macros.

Certainly redhat-rpm-config macros shouldn't be weaker than what we default
in gcc (say if gcc defaults to -march=i486 -mtune=generic, then
redhat-rpm-config shouldn't override this to -march=i386 -mtune=generic).

	Jakub



From dbn.lists at gmail.com  Mon Jan 26 14:26:12 2009
From: dbn.lists at gmail.com (Dan Nicholson)
Date: Mon, 26 Jan 2009 06:26:12 -0800
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
	<68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
	<68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
Message-ID: <91705d080901260626r6968571drf5bebd290ba96f50@mail.gmail.com>

2009/1/25 Paulo Cavalcanti <promac at gmail.com>:
>
> The spec file is here:
>
> http://people.atrpms.net/~pcavalcanti/specs/wizardpen.spec
>
> Do you think that would be any interest in having wizardpen in Fedora?

I would think so. 3rd party X drivers tend to not be a lot of fun, but
if it's the only way to use the genius tablets, then I think it should
be included. The license is acceptable.

> I really do not know if this type of package is acceptable or not.

What I think would be more interesting is trying to get it into Xorg
or at least discussing other ways that the genius tablets could be
supported. One thing that's interesting is that your spec file says
GPLv2, but the driver itself (src/wizardpen.c) is MIT/X Consortium.
The calibration tool is GPLv2+. Since the driver itself is compatible
with Xorg, they might just be able to drop (or rewrite) the
calibration tool and pull it in.

--
Dan



From dan at danny.cz  Mon Jan 26 14:30:48 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Mon, 26 Jan 2009 15:30:48 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126135137.GI5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<1232977048.8757.56.camel@eagle.danny.cz>
	<20090126135137.GI5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <1232980248.8757.98.camel@eagle.danny.cz>

Jakub Jelinek p??e v Po 26. 01. 2009 v 14:51 +0100:
> On Mon, Jan 26, 2009 at 02:37:28PM +0100, Dan Hor?k wrote:
> > There is no plan for 31-bit Fedora on s390 AFAIK, and regarding 64-bit
> > please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=463830
> 
> If we are to use -march=z9-109 -mtune=z10 instead of -march=z900 -mtune=z10
> for s390 -m31 and -m64, then releng is important.  Aren't the current
> mainframes used for Fedora (and RHEL) building z990?  If yes, then this
> can't be switched until they are z9-109 or z10 based.
> 

Good question, that needs to be checked.


		Dan




From rjones at redhat.com  Mon Jan 26 14:38:59 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 14:38:59 +0000
Subject: Lack of update information
In-Reply-To: <497D6B24.8050702@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
Message-ID: <20090126143859.GA11540@amd.home.annexia.org>


Is rpm still this other-worldly tool which we're not allowed to
change, even for blindingly obvious stuff like needing an identical
%clean section in every RPM in the world?

Anyway, _if_ we are allowed to change rpm, then we could have

  %doc(changelog) ChangeLog

which would be the upstream changelog, and other tools could pull this
out and display it to end users to their hearts' content.

And it would involve only minimal extra effort for packagers.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From notting at redhat.com  Mon Jan 26 14:53:20 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 09:53:20 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126135137.GI5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<1232977048.8757.56.camel@eagle.danny.cz>
	<20090126135137.GI5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126145320.GC3523@nostromo.devel.redhat.com>

Jakub Jelinek (jakub at redhat.com) said: 
> > There is no plan for 31-bit Fedora on s390 AFAIK, and regarding 64-bit
> > please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=463830
> 
> If we are to use -march=z9-109 -mtune=z10 instead of -march=z900 -mtune=z10
> for s390 -m31 and -m64, then releng is important.  Aren't the current
> mainframes used for Fedora (and RHEL) building z990?  If yes, then this
> can't be switched until they are z9-109 or z10 based.

They appear to be z9-109.

Bill



From sundaram at fedoraproject.org  Mon Jan 26 14:54:57 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Mon, 26 Jan 2009 20:24:57 +0530
Subject: Lack of update information
In-Reply-To: <20090126143859.GA11540@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
Message-ID: <497DCEC1.6080204@fedoraproject.org>

Richard W.M. Jones wrote:
> Is rpm still this other-worldly tool which we're not allowed to
> change, even for blindingly obvious stuff like needing an identical
> %clean section in every RPM in the world?
> 
> Anyway, _if_ we are allowed to change rpm, then we could have
> 
>   %doc(changelog) ChangeLog
> 
> which would be the upstream changelog, and other tools could pull this
> out and display it to end users to their hearts' content.
> 
> And it would involve only minimal extra effort for packagers.

rpm.org is pretty active now and still focused on bug fixes and solving 
common issues like these, primarily. If you have RFE's please file them 
at http://rpm.org trac.

Rahul



From dcbw at redhat.com  Mon Jan 26 14:58:47 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Jan 2009 09:58:47 -0500
Subject: telling gnome-package kit not use NetworkManager
In-Reply-To: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>
References: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>
Message-ID: <1232981927.5605.22.camel@localhost.localdomain>

On Mon, 2009-01-26 at 14:17 +0200, Muayyad AlSadi wrote:
> hi,
> 
> I temporarily disabled fedora repos and create my own locale repo for
> offline installation
> 
> yum and yumex works fine but gpk tells me that it can't work off-line
> as reported by Netowork manager
> how can I tell it to skip checking it

Or, if you don't want to use NM, why not turn it off?

Dan




From drepper at redhat.com  Mon Jan 26 15:04:46 2009
From: drepper at redhat.com (Ulrich Drepper)
Date: Mon, 26 Jan 2009 07:04:46 -0800
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <497DD10E.5000309@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jakub Jelinek wrote:
>> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
>> released kernel seems unlikely.
> 
> I know it is a pain, on the other hand it would really improve Fedora 11.

Not only that.  It is the only way to actually test what we are shipping.

At least from glibc's POV (but indirectly from a much wider range) we
have to compile everything on the kernel we are shipping for the
release.  Period.  I know that the current build infrastructure doesn't
do this but this only means it has to change.  We have virtualization
available, there is no excuse.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl90Q4ACgkQ2ijCOnn/RHRIDQCfSxR7kAeqcyv9Z5gIMi6/QyKu
lqcAoI0VHmknfFObJwsq0eTkLD/Nsivq
=NLvA
-----END PGP SIGNATURE-----



From sstarr at platform.com  Mon Jan 26 15:31:10 2009
From: sstarr at platform.com (Shawn Starr)
Date: Mon, 26 Jan 2009 10:31:10 -0500
Subject: F10 and no root login - impossible to maintain systems!
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B52@catoexm05.noam.corp.platform.com>


>-----Original Message-----
>From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Thomas Bendler
>Sent: Monday, January 26, 2009 5:49 AM
>To: Development discussions related to Fedora
>Subject: Re: F10 and no root login - impossible to maintain systems!


>On Thu, Jan 22, 2009 at 7:17 PM, Shawn Starr <sstarr at platform.com> wrote:

>[...]
>I'm going to jump into this flamefest, Can we STOP with the "Mother knows best" menality in Fedora? I have needed to log in as root with X a few times.     >Stop turning Fedora into a 'Ubuntu'.

>Then you have done something wrong. I never used a root login on X and I administrate a lot of UNIX systems (not only LNX). There is no reason where >you need it (except a wrong system installation or system design).
>
>Regards, Thomas

Maybe you're new to Rawhide, It's not standard 'administration' when your playing with bleeding edge things that might just fsck up :-)



From mmcgrath at redhat.com  Mon Jan 26 15:39:55 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Mon, 26 Jan 2009 09:39:55 -0600 (CST)
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497DD10E.5000309@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
Message-ID: <alpine.LFD.2.00.0901260929450.1833@laptop.mmcgrath.net>

On Mon, 26 Jan 2009, Ulrich Drepper wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jakub Jelinek wrote:
> >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> >> released kernel seems unlikely.
> >
> > I know it is a pain, on the other hand it would really improve Fedora 11.
>
> Not only that.  It is the only way to actually test what we are shipping.
>
> At least from glibc's POV (but indirectly from a much wider range) we
> have to compile everything on the kernel we are shipping for the
> release.  Period.  I know that the current build infrastructure doesn't
> do this but this only means it has to change.  We have virtualization
> available, there is no excuse.
>

Ehh, I assure you if we don't change it... Fedora 11 will still ship so it
doesn't "have to change".  So someone needs to articulate, very precisely,
what benefit investing time into our buildsystem, testing, release
upgrading (Fedora is more expensive then RHEL), etc is going to have.
Keep in mind we still can't even build epel on our normal buildsystem yet
because of $PEOPLE_TIME

What benefit will it have to our users?

What benefit will it have to our developers?

	-Mike



From robert at marcanoonline.com  Mon Jan 26 15:49:05 2009
From: robert at marcanoonline.com (Robert Marcano)
Date: Tue, 27 Jan 2009 11:19:05 +1930
Subject: Spec file source URL and file names
Message-ID: <a9ba50e50901260749n7e4ee89k3661206265024658@mail.gmail.com>

I have to use the URL
http://www.trilead.com/DesktopModules/Releases/download_file.aspx?ReleaseId=4102as
the source for a package, that address returns the correct source code
filename "trilead-ssh2-build213.zip". but rpmbuild is not able to find that
name because it is not part of the URL, I think the only way to fix this is
to not use the real URL and only add it as a Spec file comment, am I right?

-- 
Robert Marcano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/3bef6dfa/attachment.htm>

From ssorce at redhat.com  Mon Jan 26 15:52:55 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Mon, 26 Jan 2009 10:52:55 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <alpine.LFD.2.00.0901260929450.1833@laptop.mmcgrath.net>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<alpine.LFD.2.00.0901260929450.1833@laptop.mmcgrath.net>
Message-ID: <1232985175.4263.1.camel@localhost.localdomain>

On Mon, 2009-01-26 at 09:39 -0600, Mike McGrath wrote:
> On Mon, 26 Jan 2009, Ulrich Drepper wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Jakub Jelinek wrote:
> > >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> > >> released kernel seems unlikely.
> > >
> > > I know it is a pain, on the other hand it would really improve Fedora 11.
> >
> > Not only that.  It is the only way to actually test what we are shipping.
> >
> > At least from glibc's POV (but indirectly from a much wider range) we
> > have to compile everything on the kernel we are shipping for the
> > release.  Period.  I know that the current build infrastructure doesn't
> > do this but this only means it has to change.  We have virtualization
> > available, there is no excuse.
> >
> 
> Ehh, I assure you if we don't change it... Fedora 11 will still ship so it
> doesn't "have to change".  So someone needs to articulate, very precisely,
> what benefit investing time into our buildsystem, testing, release
> upgrading (Fedora is more expensive then RHEL), etc is going to have.
> Keep in mind we still can't even build epel on our normal buildsystem yet
> because of $PEOPLE_TIME
> 
> What benefit will it have to our users?
> 
> What benefit will it have to our developers?

Mike, some features in our packages are determined at build time
depending on what kernel you build them on.
So if the kernel is old enough, you might miss functionality in the
resulting packages, even more so if that package happens to be glibc I
think.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From mmcgrath at redhat.com  Mon Jan 26 16:01:42 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Mon, 26 Jan 2009 10:01:42 -0600 (CST)
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <1232985175.4263.1.camel@localhost.localdomain>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<alpine.LFD.2.00.0901260929450.1833@laptop.mmcgrath.net>
	<1232985175.4263.1.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0901260955250.7426@laptop.mmcgrath.net>

On Mon, 26 Jan 2009, Simo Sorce wrote:
> On Mon, 2009-01-26 at 09:39 -0600, Mike McGrath wrote:
> >
> > Ehh, I assure you if we don't change it... Fedora 11 will still ship so it
> > doesn't "have to change".  So someone needs to articulate, very precisely,
> > what benefit investing time into our buildsystem, testing, release
> > upgrading (Fedora is more expensive then RHEL), etc is going to have.
> > Keep in mind we still can't even build epel on our normal buildsystem yet
> > because of $PEOPLE_TIME
> >
> > What benefit will it have to our users?
> >
> > What benefit will it have to our developers?
>
> Mike, some features in our packages are determined at build time
> depending on what kernel you build them on.
> So if the kernel is old enough, you might miss functionality in the
> resulting packages, even more so if that package happens to be glibc I
> think.
>

K, so we have a "might miss functionality".  I think we can be more
specific then that.  I'm not trying to be annoying about this, more
realistic about the changes that have been proposed actually getting in
place.  It's going to have to be a _real_ good reason for the types of
code changes you guys are talking about which is essentially:

"Change koji/mock to create virtual machines on demand" [1]

"change our non-xen builders to become xen"

"Build differently x86/x86_64 then all of the other archs"

"test test test"

I'm not even sure this is a realistic F12 or F13 request as far a timing
goes.

	-Mike

[1] This is epic btw.



From berrange at redhat.com  Mon Jan 26 16:04:02 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 26 Jan 2009 16:04:02 +0000
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
In-Reply-To: <1232985175.4263.1.camel@localhost.localdomain>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<alpine.LFD.2.00.0901260929450.1833@laptop.mmcgrath.net>
	<1232985175.4263.1.camel@localhost.localdomain>
Message-ID: <20090126160401.GH5701@redhat.com>

On Mon, Jan 26, 2009 at 10:52:55AM -0500, Simo Sorce wrote:
> On Mon, 2009-01-26 at 09:39 -0600, Mike McGrath wrote:
> > On Mon, 26 Jan 2009, Ulrich Drepper wrote:
> > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Jakub Jelinek wrote:
> > > >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> > > >> released kernel seems unlikely.
> > > >
> > > > I know it is a pain, on the other hand it would really improve Fedora 11.
> > >
> > > Not only that.  It is the only way to actually test what we are shipping.
> > >
> > > At least from glibc's POV (but indirectly from a much wider range) we
> > > have to compile everything on the kernel we are shipping for the
> > > release.  Period.  I know that the current build infrastructure doesn't
> > > do this but this only means it has to change.  We have virtualization
> > > available, there is no excuse.
> > >
> > 
> > Ehh, I assure you if we don't change it... Fedora 11 will still ship so it
> > doesn't "have to change".  So someone needs to articulate, very precisely,
> > what benefit investing time into our buildsystem, testing, release
> > upgrading (Fedora is more expensive then RHEL), etc is going to have.
> > Keep in mind we still can't even build epel on our normal buildsystem yet
> > because of $PEOPLE_TIME
> > 
> > What benefit will it have to our users?
> > 
> > What benefit will it have to our developers?
> 
> Mike, some features in our packages are determined at build time
> depending on what kernel you build them on.

Any case where a build probes for features in the build host's kernel,
or runs just compiled binaries to probe for features, should always also
have  an explicit configure argument (or equivalent) to override the
automatic logic. This is same problem you face with cross-compiling and
places where people left out the 'ACTION-IF-CROSS-COMPILING' arg to the
autoconf AC_TRY_RUN() macro.

> So if the kernel is old enough, you might miss functionality in the
> resulting packages, even more so if that package happens to be glibc I
> think.

If you want to guarentee functionality is built in, then an explicit
configure arg can do this, without requiring that the build host be
running the same kernel version as the eventual target host. This will
give you much more reliably reproducable builds, because you won't find
functionality suddenly turns itself off when rebuilt on a different
system where someone doesn't know about the undocumented requirement
on a particular host kernel version.

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 jos at xos.nl  Mon Jan 26 16:04:01 2009
From: jos at xos.nl (Jos Vos)
Date: Mon, 26 Jan 2009 17:04:01 +0100
Subject: Spec file source URL and file names
In-Reply-To: <a9ba50e50901260749n7e4ee89k3661206265024658@mail.gmail.com>
References: <a9ba50e50901260749n7e4ee89k3661206265024658@mail.gmail.com>
Message-ID: <20090126160401.GB7030@jasmine.xos.nl>

On Tue, Jan 27, 2009 at 11:19:05AM +1930, Robert Marcano wrote:

> I have to use the URL
> http://www.trilead.com/DesktopModules/Releases/download_file.aspx?ReleaseId=4102as
> the source for a package, that address returns the correct source code
> filename "trilead-ssh2-build213.zip". but rpmbuild is not able to find that
> name because it is not part of the URL, I think the only way to fix this is
> to not use the real URL and only add it as a Spec file comment, am I right?

Yes.

B.t.w. I don't know if there are Fedora guidelines for this,
but RPM-wise this is correct.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From dcbw at redhat.com  Mon Jan 26 16:03:11 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Jan 2009 11:03:11 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <497DD10E.5000309@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
Message-ID: <1232985792.6319.23.camel@localhost.localdomain>

On Mon, 2009-01-26 at 07:04 -0800, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jakub Jelinek wrote:
> >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> >> released kernel seems unlikely.
> > 
> > I know it is a pain, on the other hand it would really improve Fedora 11.
> 
> Not only that.  It is the only way to actually test what we are shipping.
> 
> At least from glibc's POV (but indirectly from a much wider range) we
> have to compile everything on the kernel we are shipping for the
> release.  Period.  I know that the current build infrastructure doesn't
> do this but this only means it has to change.  We have virtualization
> available, there is no excuse.

Well... do we have stable hardware assisted virtualization available on
all the architectures that Fedora builds on?  Do the current build hosts
have the necessary hardware support for it?  Just wondering...

Dan



From rjones at redhat.com  Mon Jan 26 16:19:43 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 16:19:43 +0000
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <497DD10E.5000309@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
Message-ID: <20090126161943.GA12163@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 07:04:46AM -0800, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jakub Jelinek wrote:
> >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> >> released kernel seems unlikely.
> > 
> > I know it is a pain, on the other hand it would really improve Fedora 11.
> 
> Not only that.  It is the only way to actually test what we are shipping.
> 
> At least from glibc's POV (but indirectly from a much wider range) we
> have to compile everything on the kernel we are shipping for the
> release.  Period.  I know that the current build infrastructure doesn't
> do this but this only means it has to change.  We have virtualization
> available, there is no excuse.

Is the requirement here to build or to test on the same kernel
version?  It might be more feasible for set up an extra (virtual)
machine to run some tests and leave the build infrastructure as it is.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From jkeating at redhat.com  Mon Jan 26 16:24:14 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 08:24:14 -0800
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497DD10E.5000309@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
Message-ID: <1232987054.8363.137.camel@localhost.localdomain>

On Mon, 2009-01-26 at 07:04 -0800, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jakub Jelinek wrote:
> >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> >> released kernel seems unlikely.
> > 
> > I know it is a pain, on the other hand it would really improve Fedora 11.
> 
> Not only that.  It is the only way to actually test what we are shipping.
> 
> At least from glibc's POV (but indirectly from a much wider range) we
> have to compile everything on the kernel we are shipping for the
> release.  Period.  I know that the current build infrastructure doesn't
> do this but this only means it has to change.  We have virtualization
> available, there is no excuse.

Oh?  And what stable reliable fast software virt do we have for ppc,
ppc64, ia64, s390, and s390x?

This is not likely to happen any time soon, so if we want to pick a
kernel to run on the builders, it should be the same kernel we pick as
the "lowest acceptable kernel" for the variety of targets we build for,
which includes RHEL4.  What happens if we pick up the 2.6.29 kernel and
try to build RHEL4 packages on it, will they suddenly turn on
functionality that can't possibly work on their intended target?

I'm with Dan P.B., to obtain specific kernel level functionality it
should be possible to override, so that you get a reliable reproducible
build result.

As for Jakub's question about the gcc flags, that's likely a FESCo
decision, as this sounds very much Feature like.  It would require a
Feature page, and all the fun that goes along with it, including scope,
help for test plans, a contingency plan, and release notes.  It will
also help us plan a mass rebuild along with other needs of our distro,
like potential rpm changes that would also benefit from a mass rebuild.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/86628752/attachment.sig>

From rjones at redhat.com  Mon Jan 26 16:27:47 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 16:27:47 +0000
Subject: Lack of update information
In-Reply-To: <497DCEC1.6080204@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<497DCEC1.6080204@fedoraproject.org>
Message-ID: <20090126162747.GB12163@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 08:24:57PM +0530, Rahul Sundaram wrote:
> rpm.org is pretty active now and still focused on bug fixes and solving  
> common issues like these, primarily. If you have RFE's please file them  
> at http://rpm.org trac.

Added:

  http://rpm.org/ticket/24

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 pmatilai at laiskiainen.org  Mon Jan 26 16:28:43 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 26 Jan 2009 18:28:43 +0200 (EET)
Subject: Lack of update information
In-Reply-To: <20090126143859.GA11540@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
Message-ID: <alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>

On Mon, 26 Jan 2009, Richard W.M. Jones wrote:
>
> Is rpm still this other-worldly tool which we're not allowed to
> change, even for blindingly obvious stuff like needing an identical
> %clean section in every RPM in the world?

Heh, too bad names like "Plan-9" and "alien" are already taken ;)

Sure we can and do change rpm, but changes in rpm world tend to take ages 
to get actually deployed & used. Yes, even in Fedora.

> Anyway, _if_ we are allowed to change rpm, then we could have
>
>  %doc(changelog) ChangeLog
>
> which would be the upstream changelog, and other tools could pull this
> out and display it to end users to their hearts' content.
>
> And it would involve only minimal extra effort for packagers.

But what exactly would that solve? The ChangeLog file would be in the rpm 
payload, so the contents are only accessible after the package has already 
been installed. The intended audience here seems to be "end users", to 
whom the raw upstream SCM changelogs aren't often that useful. Somebody 
has to actually write the nice end-user friendly executive summaries for 
packages, they unfortunately don't come to existence by wishing :)

If it's the Bodhi update messages we're primarily talking about here, then 
how about just adding an optional field for a link to the upstream release 
notes/summary for the upstreams that happen to provide nice end-user 
friendly release summaries?

 	- Panu -



From jkeating at redhat.com  Mon Jan 26 16:29:25 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 08:29:25 -0800
Subject: Fedora Release Engineering Meeting Today at 1800 UTC
Message-ID: <1232987365.8363.139.camel@localhost.localdomain>

#fedora-meeting

Topics:
- Fedora 10 Alpha
  - Current state
  - Tag refresh

- Open Floor

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/bdfdc47b/attachment.sig>

From robert at fedoraproject.org  Mon Jan 26 16:31:54 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 17:31:54 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <glk69i$k5q$1@ger.gmane.org>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<glk69i$k5q$1@ger.gmane.org>
Message-ID: <20090126163154.GA411@hurricane.linuxnetz.de>

On Mon, 26 Jan 2009, Kevin Kofler wrote:
> supported, and there are setups where the kernel cannot be upgraded at all
> (e.g. Virtuozzo/OpenVZ VPSes or kernels with custom patches which have not
> been ported to the latest version yet).

Since when do we care about third party? We have KVM, no need in Fedora for
SWsoft software. The only argument could be RHEL 5 where our buildsystem is
running on.


Greetings,
  Robert



From notting at redhat.com  Mon Jan 26 16:34:16 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 11:34:16 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126131852.GB2381@yoda.jdub.homelinux.org>
	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126163415.GF15413@nostromo.devel.redhat.com>

Jakub Jelinek (jakub at redhat.com) said: 
> > I agree.  Does it have to be .29, or would something slightly older (and
> > theoretically more stable) suffice?  The .27.x release has been in use for
> > F-9 and F-10 for a while now.
> 
> For glibc 2.9 (F10) it would suffice to just have .27, but for rawhide
> .29 introduces futex bitset and realtime clock support, which means an extra
> syscall for every threaded program.  We could bump it in steps, first start
> requiring .27 and then if .29 is sufficiently stable in a month (or when
> we really need to freeze), rebuild just glibc requiring a newer kernel.

Realistically, the build environment we support both for ourselves
to build on, and what we tell our customers and users to use, is mock.
Mock relies on the host kernel version. Heck, call it the build hypervisor.

Moreover, you still have to support the oldest kernel you want to support
a live upgrade from, otherwise your system will fall over partway through
the transaction.

Hence, for Fedora 11, I don't see how we can set the required kernel
to anything greater than 'the RHEL 5 version'. Whether that's 2.6.18 directly,
or some later version that encapsulates both 2.6.18 and whatever backports
were made to the RHEL 5 kernel, should be determined.

Bill



From ssorce at redhat.com  Mon Jan 26 16:36:42 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Mon, 26 Jan 2009 16:36:42 +0000
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <1232987054.8363.137.camel@localhost.localdomain>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<1232987054.8363.137.camel@localhost.localdomain>
Message-ID: <1232987802.4263.6.camel@localhost.localdomain>

On Mon, 2009-01-26 at 08:24 -0800, Jesse Keating wrote:
> On Mon, 2009-01-26 at 07:04 -0800, Ulrich Drepper wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Jakub Jelinek wrote:
> > >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> > >> released kernel seems unlikely.
> > > 
> > > I know it is a pain, on the other hand it would really improve Fedora 11.
> > 
> > Not only that.  It is the only way to actually test what we are shipping.
> > 
> > At least from glibc's POV (but indirectly from a much wider range) we
> > have to compile everything on the kernel we are shipping for the
> > release.  Period.  I know that the current build infrastructure doesn't
> > do this but this only means it has to change.  We have virtualization
> > available, there is no excuse.
> 
> Oh?  And what stable reliable fast software virt do we have for ppc,
> ppc64, ia64, s390, and s390x?
> 
> This is not likely to happen any time soon, so if we want to pick a
> kernel to run on the builders, it should be the same kernel we pick as
> the "lowest acceptable kernel" for the variety of targets we build for,
> which includes RHEL4.  What happens if we pick up the 2.6.29 kernel and
> try to build RHEL4 packages on it, will they suddenly turn on
> functionality that can't possibly work on their intended target?

It might, things like inotify comes to mind ...

> I'm with Dan P.B., to obtain specific kernel level functionality it
> should be possible to override, so that you get a reliable reproducible
> build result.

Sure, ideally Dan's arguments are perfectly true, but in practice,
sometimes, you don't even know where to look for (and by you I mean the
package maintainer, which is not always necessarily aware of the same
things upstream is), so the choice I think is:
- let's pretend we are in the ideal situation and risk shipping some
broken package
- let's assume upstream is not perfect so let's try to build on the
kernel we are going to ship packages with (or a recent enough version
anyway).

It is also a problem of testing.
I, and most other developers build at most on something as old as an
updated Fedora 9, which has quite a recent kernel. The maintainer may
not even notice that there are problems when the package is built on
something as old as 2.6.9

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From notting at redhat.com  Mon Jan 26 16:39:19 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 11:39:19 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <1232987802.4263.6.camel@localhost.localdomain>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<1232987054.8363.137.camel@localhost.localdomain>
	<1232987802.4263.6.camel@localhost.localdomain>
Message-ID: <20090126163919.GG15413@nostromo.devel.redhat.com>

Simo Sorce (ssorce at redhat.com) said: 
> It is also a problem of testing.
> I, and most other developers build at most on something as old as an
> updated Fedora 9, which has quite a recent kernel. The maintainer may
> not even notice that there are problems when the package is built on
> something as old as 2.6.9

... but it's been exactly that way since Fedora 5 or so, and if they
haven't noticed, they're not doing their job as maintainer very well.

Bill



From rakesh.pandit at gmail.com  Mon Jan 26 16:39:08 2009
From: rakesh.pandit at gmail.com (Rakesh Pandit)
Date: Mon, 26 Jan 2009 22:09:08 +0530
Subject: Fedora Release Engineering Meeting Today at 1800 UTC
In-Reply-To: <1232987365.8363.139.camel@localhost.localdomain>
References: <1232987365.8363.139.camel@localhost.localdomain>
Message-ID: <b401d2530901260839s4759315fq488c3256ca7dce63@mail.gmail.com>

2009/1/26 Jesse Keating <jkeating at redhat.com>:
> #fedora-meeting
>
> Topics:
> - Fedora 10 Alpha

I guess Fedora 11 Alpha :)

>  - Current state
>  - Tag refresh
>


-- 
rakesh



From robert at fedoraproject.org  Mon Jan 26 16:38:30 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 17:38:30 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <497DD10E.5000309@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
Message-ID: <20090126163830.GB411@hurricane.linuxnetz.de>

On Mon, 26 Jan 2009, Ulrich Drepper wrote:
> release.  Period.  I know that the current build infrastructure doesn't
> do this but this only means it has to change.  We have virtualization
> available, there is no excuse.

Well, we're doing AFAIK only lazy virtualization AKA para-virtualization on
our build systems, so we're using the same kernel on host system and on the
virtual machines.

That makes IMHO it more hard to replace the RHEL 5 kernel, as it affects
just everything. If we would to full virtualization, there shouldn't be any
effect to the host/base system running RHEL 5.


Greetings,
  Robert



From berrange at redhat.com  Mon Jan 26 16:49:46 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 26 Jan 2009 16:49:46 +0000
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
In-Reply-To: <20090126163830.GB411@hurricane.linuxnetz.de>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<20090126163830.GB411@hurricane.linuxnetz.de>
Message-ID: <20090126164946.GI5701@redhat.com>

On Mon, Jan 26, 2009 at 05:38:30PM +0100, Robert Scheck wrote:
> On Mon, 26 Jan 2009, Ulrich Drepper wrote:
> > release.  Period.  I know that the current build infrastructure doesn't
> > do this but this only means it has to change.  We have virtualization
> > available, there is no excuse.
> 
> Well, we're doing AFAIK only lazy virtualization AKA para-virtualization on
> our build systems, so we're using the same kernel on host system and on the
> virtual machines.

There is no such restriction with Xen paravirtualization. The host & guest
kernel have no need to be running the same version. The hypervisor ABI,
and device ABI is what is fixed & this is independant of kernel version.
You are thinking of container based virtualization where there is no
separate guest kernel.

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 kevin.kofler at chello.at  Mon Jan 26 16:41:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 17:41:10 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<glk69i$k5q$1@ger.gmane.org>
	<20090126163154.GA411@hurricane.linuxnetz.de>
Message-ID: <glkp37$n8l$1@ger.gmane.org>

Robert Scheck wrote:
> Since when do we care about third party? We have KVM, no need in Fedora
> for SWsoft software. The only argument could be RHEL 5 where our
> buildsystem is running on.

A lot of us packagers are doing test mock builds on a variety of machines,
e.g. as part of reviews or for a variety of other reasons. For example,
many of us run the latest stable release and do mock builds targeting
Rawhide on it. This is not possible if the release only has 2.6.27 or
2.6.28 and the Rawhide glibc requires 2.6.29. The stricter the requirements
on the build host are, the harder it gets to do such test builds. Mock is a
big help there, we'd lose many of its advantages by coupling our userspace
too closely to our kernel.

In addition, this also makes things hard for third-party repositories, who
often build on a variety of hosts which are not even necessarily Fedora.
See for example the OpenSUSE build service, which is used to build some
third-party Fedora packages. Mock is even packaged for Debian.

        Kevin Kofler



From dcbw at redhat.com  Mon Jan 26 16:51:58 2009
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 26 Jan 2009 11:51:58 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <1232987802.4263.6.camel@localhost.localdomain>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<1232987054.8363.137.camel@localhost.localdomain>
	<1232987802.4263.6.camel@localhost.localdomain>
Message-ID: <1232988718.6319.45.camel@localhost.localdomain>

On Mon, 2009-01-26 at 16:36 +0000, Simo Sorce wrote:
> On Mon, 2009-01-26 at 08:24 -0800, Jesse Keating wrote:
> > On Mon, 2009-01-26 at 07:04 -0800, Ulrich Drepper wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > Jakub Jelinek wrote:
> > > >> The koji build boxes all run RHEL 5.  Getting them upgraded to a not-yet-
> > > >> released kernel seems unlikely.
> > > > 
> > > > I know it is a pain, on the other hand it would really improve Fedora 11.
> > > 
> > > Not only that.  It is the only way to actually test what we are shipping.
> > > 
> > > At least from glibc's POV (but indirectly from a much wider range) we
> > > have to compile everything on the kernel we are shipping for the
> > > release.  Period.  I know that the current build infrastructure doesn't
> > > do this but this only means it has to change.  We have virtualization
> > > available, there is no excuse.
> > 
> > Oh?  And what stable reliable fast software virt do we have for ppc,
> > ppc64, ia64, s390, and s390x?
> > 
> > This is not likely to happen any time soon, so if we want to pick a
> > kernel to run on the builders, it should be the same kernel we pick as
> > the "lowest acceptable kernel" for the variety of targets we build for,
> > which includes RHEL4.  What happens if we pick up the 2.6.29 kernel and
> > try to build RHEL4 packages on it, will they suddenly turn on
> > functionality that can't possibly work on their intended target?
> 
> It might, things like inotify comes to mind ...

Which  means there should be a configure-time option for
--with-fsnotify=[inotify|dnotify] which will turn on the desired method
explicitly.  This stuff certainly shouldn't be autodetected by the
configure script, or if it is, there should be a --with or --enable
method to turn autodetection off and specify.  That's the only way to
ensure that as a package maintainer, you get hard failures at build
time, not when users figure out stuff is broken and yell at you.

Dan

> 
> > I'm with Dan P.B., to obtain specific kernel level functionality it
> > should be possible to override, so that you get a reliable reproducible
> > build result.
> 
> Sure, ideally Dan's arguments are perfectly true, but in practice,
> sometimes, you don't even know where to look for (and by you I mean the
> package maintainer, which is not always necessarily aware of the same
> things upstream is), so the choice I think is:
> - let's pretend we are in the ideal situation and risk shipping some
> broken package
> - let's assume upstream is not perfect so let's try to build on the
> kernel we are going to ship packages with (or a recent enough version
> anyway).
> 
> It is also a problem of testing.
> I, and most other developers build at most on something as old as an
> updated Fedora 9, which has quite a recent kernel. The maintainer may
> not even notice that there are problems when the package is built on
> something as old as 2.6.9
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 



From jkeating at redhat.com  Mon Jan 26 16:56:58 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 08:56:58 -0800
Subject: Lack of update information
In-Reply-To: <f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
Message-ID: <1232989018.8363.143.camel@localhost.localdomain>

On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
> > Rahul Sundaram pisze:
> >> Hi,
> >>
> >> A while back, I tried to selectively update some packages and noticed
> >> that the update information provided by package maintainers (seen via
> >> PackageKit) is sorely lacking.
> >>
> >> * Update foo to upstream 2.16.2
> >[..]
> > Btw, how about pulling the data from spec %changelog automatically?
> 
> Well in most cases the changelog will just contain the same "update to x.y.z"
> For some packages the changes just aren't  worth listing.
> For example each iw release only contain minor changes, people that
> really care about them know how to look it up.
> I could also just add "Small fixes and minor updates from upstream"
> but that's the same as "Update to x.y.z".
> Copying the upstream changelog, that must people do not understand
> does not help either.

If they're really such minor and uninteresting changes, why push them
out to users?  Why consume infrastructure resources to build, releng
resources to sign and push, bandwidth resources to mirror, bandwidth
resources and cpu resources on the clients to consume the metadata, and
cpu / disk resources on the clients to do the update?

If you don't have anything interesting to say about the update, maybe
you shouldn't be pushing the update at all.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/ee2e6182/attachment.sig>

From jkeating at redhat.com  Mon Jan 26 16:58:31 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 08:58:31 -0800
Subject: Lack of update information
In-Reply-To: <20090126084939.GA16919@hurricane.linuxnetz.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126084939.GA16919@hurricane.linuxnetz.de>
Message-ID: <1232989111.8363.144.camel@localhost.localdomain>

On Mon, 2009-01-26 at 09:49 +0100, Robert Scheck wrote:
>  
> Instead of that, I really would like to see PackageKit reading Bodhi texts
> and not only the bug report numbers. I'm always using the text, I can enter
> in Bodhi for upstream and downstream changes. But they're only going to the
> mailing lists, not to the PackageKit user - and that's wrong and has to be
> changed ASAP. Maybe we can make a guideline for this to cover it...

PackageKit /does/ read the text you input into Bodhi as far as update
notes.  It also does read the bug numbers, and categorizes the updates
as you do in bodhi (enhancement, bugfix, security, etc.)

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/60445931/attachment.sig>

From kevin.kofler at chello.at  Mon Jan 26 17:00:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 18:00:56 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<20090126163830.GB411@hurricane.linuxnetz.de>
	<20090126164946.GI5701@redhat.com>
Message-ID: <glkq88$qto$1@ger.gmane.org>

Daniel P. Berrange wrote:
> There is no such restriction with Xen paravirtualization. The host & guest
> kernel have no need to be running the same version. The hypervisor ABI,
> and device ABI is what is fixed & this is independant of kernel version.
> You are thinking of container based virtualization where there is no
> separate guest kernel.

But Koji just uses a plain chroot, not actual virtualization at all.

        Kevin Kofler



From dominik at greysector.net  Mon Jan 26 17:03:15 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Mon, 26 Jan 2009 18:03:15 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
In-Reply-To: <20090126163154.GA411@hurricane.linuxnetz.de>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<glk69i$k5q$1@ger.gmane.org>
	<20090126163154.GA411@hurricane.linuxnetz.de>
Message-ID: <20090126170315.GB12639@mokona.greysector.net>

On Monday, 26 January 2009 at 17:31, Robert Scheck wrote:
> On Mon, 26 Jan 2009, Kevin Kofler wrote:
> > supported, and there are setups where the kernel cannot be upgraded at all
> > (e.g. Virtuozzo/OpenVZ VPSes or kernels with custom patches which have not
> > been ported to the latest version yet).
> 
> Since when do we care about third party? We have KVM,

Does KVM work on CPUs that don't support hardware virtualization? According
to its wiki, it doesn't, so users of older CPUs (for example, me) can't use
it. Do you have any alternatives for me in Fedora?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jkeating at redhat.com  Mon Jan 26 17:04:06 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 09:04:06 -0800
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126161943.GA12163@amd.home.annexia.org>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<20090126161943.GA12163@amd.home.annexia.org>
Message-ID: <1232989446.8363.145.camel@localhost.localdomain>

On Mon, 2009-01-26 at 16:19 +0000, Richard W.M. Jones wrote:
>  
> Is the requirement here to build or to test on the same kernel
> version?  It might be more feasible for set up an extra (virtual)
> machine to run some tests and leave the build infrastructure as it is.

That's exactly whats on tap from the Fedora QA efforts.  The FUDCon talk
(which there is a video of) covers this.

https://fedoraproject.org/wiki/FUDCon:FUDConF11_BarCamp_schedule

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/01ca3b70/attachment.sig>

From jkeating at redhat.com  Mon Jan 26 17:06:21 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 09:06:21 -0800
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <glkq88$qto$1@ger.gmane.org>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<20090126163830.GB411@hurricane.linuxnetz.de>
	<20090126164946.GI5701@redhat.com>  <glkq88$qto$1@ger.gmane.org>
Message-ID: <1232989581.8363.146.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:00 +0100, Kevin Kofler wrote:
> Daniel P. Berrange wrote:
> > There is no such restriction with Xen paravirtualization. The host & guest
> > kernel have no need to be running the same version. The hypervisor ABI,
> > and device ABI is what is fixed & this is independant of kernel version.
> > You are thinking of container based virtualization where there is no
> > separate guest kernel.
> 
> But Koji just uses a plain chroot, not actual virtualization at all.
> 
>         Kevin Kofler

There is some confusion  here.  Many koji builders themselves are Xen
guests.  Within the guest, mock is used to generate clean chroots to
build in.  Of course, for the arches that don't support Xen, we have the
builder running on real hardware.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/86e7d949/attachment.sig>

From jkeating at redhat.com  Mon Jan 26 17:08:04 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 09:08:04 -0800
Subject: Fedora Release Engineering Meeting Today at 1800 UTC
In-Reply-To: <b401d2530901260839s4759315fq488c3256ca7dce63@mail.gmail.com>
References: <1232987365.8363.139.camel@localhost.localdomain>
	<b401d2530901260839s4759315fq488c3256ca7dce63@mail.gmail.com>
Message-ID: <1232989684.8363.147.camel@localhost.localdomain>

On Mon, 2009-01-26 at 22:09 +0530, Rakesh Pandit wrote:
> 2009/1/26 Jesse Keating <jkeating at redhat.com>:
> > #fedora-meeting
> >
> > Topics:
> > - Fedora 10 Alpha
> 
> I guess Fedora 11 Alpha :)

Yeesh, Yes.  It's early out here for me.

> 
> >  - Current state
> >  - Tag refresh
> >
> 
> 
> -- 
> rakesh

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/d3f7deb7/attachment.sig>

From kevin.kofler at chello.at  Mon Jan 26 17:05:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 18:05:23 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<497DD10E.5000309@redhat.com>
	<20090126163830.GB411@hurricane.linuxnetz.de>
	<20090126164946.GI5701@redhat.com> <glkq88$qto$1@ger.gmane.org>
Message-ID: <glkqgj$qto$2@ger.gmane.org>

I wrote:
> But Koji just uses a plain chroot, not actual virtualization at all.

To be more precise, some Koji build hosts are running Xen, but the Xen
guests are also EL5 guests, it uses mock chroots inside those.

        Kevin Kofler



From notting at redhat.com  Mon Jan 26 17:18:07 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 12:18:07 -0500
Subject: Comps change: mozvoikko as firefox conditional for F11
In-Reply-To: <1232879803.4886.9.camel@poytakone.lan>
References: <1232879803.4886.9.camel@poytakone.lan>
Message-ID: <20090126171807.GA16274@nostromo.devel.redhat.com>

Ville-Pekka Vainio (vpivaini at cs.helsinki.fi) said: 
> I'd like to change mozvoikko in the Finnish support group in F11 from
> this:
> 
> <packagereq type="optional">mozvoikko</packagereq>
> 
> to this:
> 
> <packagereq type="conditional" requires="firefox">mozvoikko</packagereq>
> 
> so that the Finnish spell checking extension for Firefox would be
> installed automatically. It's a small package (37K rpm) and all the
> dependencies are on the live cd already. Would this be ok?

Seems reasonable, although if we move to plugin-based installation
of language support packages, it may need renamed. That's in the future,
though.

Bill



From skvidal at fedoraproject.org  Mon Jan 26 17:22:45 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Jan 2009 12:22:45 -0500
Subject: Comps change: mozvoikko as firefox conditional for F11
In-Reply-To: <20090126171807.GA16274@nostromo.devel.redhat.com>
References: <1232879803.4886.9.camel@poytakone.lan>
	<20090126171807.GA16274@nostromo.devel.redhat.com>
Message-ID: <1232990565.3249.10.camel@rosebud>

On Mon, 2009-01-26 at 12:18 -0500, Bill Nottingham wrote:
> Ville-Pekka Vainio (vpivaini at cs.helsinki.fi) said: 
> > I'd like to change mozvoikko in the Finnish support group in F11 from
> > this:
> > 
> > <packagereq type="optional">mozvoikko</packagereq>
> > 
> > to this:
> > 
> > <packagereq type="conditional" requires="firefox">mozvoikko</packagereq>
> > 
> > so that the Finnish spell checking extension for Firefox would be
> > installed automatically. It's a small package (37K rpm) and all the
> > dependencies are on the live cd already. Would this be ok?
> 
> Seems reasonable, although if we move to plugin-based installation
> of language support packages, it may need renamed. That's in the future,
> though.

and by future I think we're talking F12 - it's a bit late for F11, I
think.
-sv




From kyle at mcmartin.ca  Mon Jan 26 17:37:57 2009
From: kyle at mcmartin.ca (Kyle McMartin)
Date: Mon, 26 Jan 2009 12:37:57 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <20090126173757.GA7500@bombadil.infradead.org>

On Mon, Jan 26, 2009 at 11:15:01AM +0100, Jakub Jelinek wrote:
> Another question is if we finally could bump the minimum supported kernel
> version in Fedora 11 glibc.  Currently Fedora 10 glibc requires 2.6.9 or
> later kernel, which means it can't assume a lot of stuff (e.g. private
> futexes, a lot of added syscalls etc.), which means it has to test for them
> at runtime of every program (e.g. every threaded program does a dummy futex
> syscall to check for private futexes, for futex realtime clock support and
> has to use variables for this, instead of oring constants in the mutexes
> etc., and glibc has to check for ENOSYS and have fallbacks compiled in).
> 2.6.9 default comes I think still from the RHEL4 kernels.
> Could we bump this ideally to 2.6.29?  It would mean Fedora 11 userland
> only runs on 2.6.29 and later kernels, but we could gain speed and decrease
> size of glibc shared libraries.
> 

No. No. No.

No. No.

No.

Breaking userspace for anyone attempting to bisect a regression?

Get real. You owe your users better than that.

Ship two copies of glibc and decide at runtime, but a hardcoded limit
is just BROKEN software design.

regards, Kyle



From kevin.kofler at chello.at  Mon Jan 26 17:40:08 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 18:40:08 +0100
Subject: Default ISA/tuning flags for GCC,
	--enable-kernel= level for glibc
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<glk69i$k5q$1@ger.gmane.org>
	<20090126163154.GA411@hurricane.linuxnetz.de>
	<20090126170315.GB12639@mokona.greysector.net>
Message-ID: <glksho$2ns$1@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:
> Does KVM work on CPUs that don't support hardware virtualization?
> According to its wiki, it doesn't, so users of older CPUs (for example,
> me) can't use it. Do you have any alternatives for me in Fedora?

QEMU software virtualization if you can live with the VM being 50 times
slower than a native machine (speaking from experience there, I used to do
x86_64 builds for CalcForge that way, with QEMU software virt running on a
32-bit host).

There's kmod-kqemu in RPM Fusion free which can speed things up a bit (only
32-bit on 32-bit or 64-bit on 64-bit though - you'll get away with running
32-bit code inside qemu-system-x86_64 on a 64-bit host though).

        Kevin Kofler



From rjones at redhat.com  Mon Jan 26 17:43:31 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 17:43:31 +0000
Subject: Lack of update information
In-Reply-To: <alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
Message-ID: <20090126174331.GA12774@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> But what exactly would that solve? The ChangeLog file would be in the rpm 
> payload, so the contents are only accessible after the package has 
> already been installed.

Yum already pulls out lots of meta-info from the RPMs and stores it in
its own database, eg:

$ zless repodata/primary.xml.gz
[...]
<package type="rpm">
  <name>mingw32-portablexdr</name>
  <arch>noarch</arch>
  <version epoch="0" ver="4.0.11" rel="1.fc10"/>
[...]
  <summary>MinGW Windows PortableXDR XDR / RPC library</summary>
  <description>MinGW Windows PortableXDR XDR / RPC library.</description>
  <packager></packager>
  <url>http://et.redhat.com/~rjones/portablexdr/</url>
  <time file="1227118253" build="1227118253"/>
  <size package="33005" installed="104342" archive="105656"/>
<location href="RPMS/mingw32-portablexdr-4.0.11-1.fc10.noarch.rpm"/>
  <format>
    <rpm:license>LGPLv2+</rpm:license>
    <rpm:vendor/>
    <rpm:group>Development/Libraries</rpm:group>
    <rpm:buildhost>intel-mb</rpm:buildhost>
[...]

It can equally pull out the changelog file (or part of it) if required.

> The intended audience here seems to be "end 
> users", to whom the raw upstream SCM changelogs aren't often that useful. 

The stereotypical grandmum end user won't care about any of this
stuff.  Giving people detailed changelogs is useful if you're trying
to find out what *really* changed in the package.

Additionally the metadata is useful for other tools, eg. rpm2html
which generates sites like http://rpmfind.net/

To be honest I can't see a downside to adding extra metadata to RPMs,
except that someone has to write the code to do it.

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 skvidal at fedoraproject.org  Mon Jan 26 17:45:12 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Jan 2009 12:45:12 -0500
Subject: Lack of update information
In-Reply-To: <20090126174331.GA12774@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
Message-ID: <1232991912.3249.11.camel@rosebud>

On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > But what exactly would that solve? The ChangeLog file would be in the rpm 
> > payload, so the contents are only accessible after the package has 
> > already been installed.
> 
> Yum already pulls out lots of meta-info from the RPMs and stores it in
> its own database, eg:
> 
> It can equally pull out the changelog file (or part of it) if required.
> 
> > The intended audience here seems to be "end 
> > users", to whom the raw upstream SCM changelogs aren't often that useful. 
> 
> The stereotypical grandmum end user won't care about any of this
> stuff.  Giving people detailed changelogs is useful if you're trying
> to find out what *really* changed in the package.
> 
> Additionally the metadata is useful for other tools, eg. rpm2html
> which generates sites like http://rpmfind.net/
> 
> To be honest I can't see a downside to adding extra metadata to RPMs,
> except that someone has to write the code to do it.

And we potentially have to change the sqlite db format and the repodata
formats to accommodate them.

So, it better be an important change.

-sv





From vpivaini at cs.helsinki.fi  Mon Jan 26 17:46:06 2009
From: vpivaini at cs.helsinki.fi (Ville-Pekka Vainio)
Date: Mon, 26 Jan 2009 19:46:06 +0200
Subject: Comps change: mozvoikko as firefox conditional for F11
In-Reply-To: <20090126171807.GA16274@nostromo.devel.redhat.com>
References: <1232879803.4886.9.camel@poytakone.lan>
	<20090126171807.GA16274@nostromo.devel.redhat.com>
Message-ID: <1232991966.3209.1.camel@poytakone.lan>

ma, 2009-01-26 kello 12:18 -0500, Bill Nottingham kirjoitti:
> Seems reasonable

Thanks, done.

> although if we move to plugin-based installation
> of language support packages, it may need renamed.

I've noticed the comps discussion on this list, I'll keep an eye on the
situation.


-- 
Ville-Pekka Vainio



From notting at redhat.com  Mon Jan 26 17:48:49 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 12:48:49 -0500
Subject: Lack of update information
In-Reply-To: <20090126174331.GA12774@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
Message-ID: <20090126174849.GC16274@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> Yum already pulls out lots of meta-info from the RPMs and stores it in
> its own database, eg:
> 
> $ zless repodata/primary.xml.gz
...

*All* of that is in the RPM header. It's not pulling anything out of the
file payload.

Bill



From rjones at redhat.com  Mon Jan 26 17:50:32 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 17:50:32 +0000
Subject: Lack of update information
In-Reply-To: <1232991912.3249.11.camel@rosebud>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<1232991912.3249.11.camel@rosebud>
Message-ID: <20090126175032.GB12774@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 12:45:12PM -0500, seth vidal wrote:
> On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> > On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > > But what exactly would that solve? The ChangeLog file would be in the rpm 
> > > payload, so the contents are only accessible after the package has 
> > > already been installed.
> > 
> > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > its own database, eg:
> > 
> > It can equally pull out the changelog file (or part of it) if required.
> > 
> > > The intended audience here seems to be "end 
> > > users", to whom the raw upstream SCM changelogs aren't often that useful. 
> > 
> > The stereotypical grandmum end user won't care about any of this
> > stuff.  Giving people detailed changelogs is useful if you're trying
> > to find out what *really* changed in the package.
> > 
> > Additionally the metadata is useful for other tools, eg. rpm2html
> > which generates sites like http://rpmfind.net/
> > 
> > To be honest I can't see a downside to adding extra metadata to RPMs,
> > except that someone has to write the code to do it.
> 
> And we potentially have to change the sqlite db format and the repodata
> formats to accommodate them.

The repodata is in XML where the X stands for eXtensible.  Extra
fields should be ignored if not used.

Typical SQL databases don't mind at all if you add extra columns to
tables.  Whether this is true of the on-disk binary(?) format used by
sqlite I have no idea, but if the sqlite format cannot handle such
changes, then it surely must be the wrong format for the task.

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 Jan 26 17:51:47 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 17:51:47 +0000
Subject: Lack of update information
In-Reply-To: <20090126174849.GC16274@nostromo.devel.redhat.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
Message-ID: <20090126175147.GC12774@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 12:48:49PM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > its own database, eg:
> > 
> > $ zless repodata/primary.xml.gz
> ...
> 
> *All* of that is in the RPM header. It's not pulling anything out of the
> file payload.

So?  createrepo would need to parse a bit more of the RPM.

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 james at fedoraproject.org  Mon Jan 26 17:54:40 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 26 Jan 2009 12:54:40 -0500
Subject: updating statistics
In-Reply-To: <alpine.LFD.2.00.0901221657300.22477@laptop.mmcgrath.net>
References: <20090122170354.GA1800@localhost>
	<1232648479.3802.93.camel@rosebud> <20090122185547.GA8470@localhost>
	<alpine.LFD.2.00.0901221657300.22477@laptop.mmcgrath.net>
Message-ID: <1232992480.28200.9.camel@code.and.org>

On Thu, 2009-01-22 at 16:58 -0600, Mike McGrath wrote:

> Not sure, one way to do it is to ensure that yum is sending its version as
> part of the user agent when it hits our servers.  At that point we can
> easily grep and say "k, looks like 90% of our users have updated"

 yum has been doing this since ~3.2.8 (it's in RHEL-5.2's 3.2.8).

-- 
James Antill <james at fedoraproject.org>
Fedora



From rjones at redhat.com  Mon Jan 26 17:58:16 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Mon, 26 Jan 2009 17:58:16 +0000
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
	glibc
In-Reply-To: <20090126170315.GB12639@mokona.greysector.net>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<glk69i$k5q$1@ger.gmane.org>
	<20090126163154.GA411@hurricane.linuxnetz.de>
	<20090126170315.GB12639@mokona.greysector.net>
Message-ID: <20090126175816.GD12774@amd.home.annexia.org>

On Mon, Jan 26, 2009 at 06:03:15PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 26 January 2009 at 17:31, Robert Scheck wrote:
> > On Mon, 26 Jan 2009, Kevin Kofler wrote:
> > > supported, and there are setups where the kernel cannot be upgraded at all
> > > (e.g. Virtuozzo/OpenVZ VPSes or kernels with custom patches which have not
> > > been ported to the latest version yet).
> > 
> > Since when do we care about third party? We have KVM,
> 
> Does KVM work on CPUs that don't support hardware virtualization? According
> to its wiki, it doesn't, so users of older CPUs (for example, me) can't use
> it. Do you have any alternatives for me in Fedora?

KVM isn't really a substitute for OpenVZ anyway.  Longer term, bits of
the kernel are being changed to support containers (with support from
OpenVZ and others), and libvirt supports this too.

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 skvidal at fedoraproject.org  Mon Jan 26 17:57:07 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Mon, 26 Jan 2009 12:57:07 -0500
Subject: Lack of update information
In-Reply-To: <20090126175032.GB12774@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<1232991912.3249.11.camel@rosebud>
	<20090126175032.GB12774@amd.home.annexia.org>
Message-ID: <1232992627.3249.12.camel@rosebud>

On Mon, 2009-01-26 at 17:50 +0000, Richard W.M. Jones wrote:
> On Mon, Jan 26, 2009 at 12:45:12PM -0500, seth vidal wrote:
> > On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> > > On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > > > But what exactly would that solve? The ChangeLog file would be in the rpm 
> > > > payload, so the contents are only accessible after the package has 
> > > > already been installed.
> > > 
> > > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > > its own database, eg:
> > > 
> > > It can equally pull out the changelog file (or part of it) if required.
> > > 
> > > > The intended audience here seems to be "end 
> > > > users", to whom the raw upstream SCM changelogs aren't often that useful. 
> > > 
> > > The stereotypical grandmum end user won't care about any of this
> > > stuff.  Giving people detailed changelogs is useful if you're trying
> > > to find out what *really* changed in the package.
> > > 
> > > Additionally the metadata is useful for other tools, eg. rpm2html
> > > which generates sites like http://rpmfind.net/
> > > 
> > > To be honest I can't see a downside to adding extra metadata to RPMs,
> > > except that someone has to write the code to do it.
> > 
> > And we potentially have to change the sqlite db format and the repodata
> > formats to accommodate them.
> 
> The repodata is in XML where the X stands for eXtensible.  Extra
> fields should be ignored if not used.

heh, that's quaint.

> 
> Typical SQL databases don't mind at all if you add extra columns to
> tables.  Whether this is true of the on-disk binary(?) format used by
> sqlite I have no idea, but if the sqlite format cannot handle such
> changes, then it surely must be the wrong format for the task.


I never said it couldn't be extended. But if we do add to it we should
have a good reason. That's all I said.
-sv




From jkeating at redhat.com  Mon Jan 26 17:59:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 09:59:55 -0800
Subject: Lack of update information
In-Reply-To: <20090126175147.GC12774@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
Message-ID: <1232992795.8363.151.camel@localhost.localdomain>

On Mon, 2009-01-26 at 17:51 +0000, Richard W.M. Jones wrote:
> On Mon, Jan 26, 2009 at 12:48:49PM -0500, Bill Nottingham wrote:
> > Richard W.M. Jones (rjones at redhat.com) said: 
> > > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > > its own database, eg:
> > > 
> > > $ zless repodata/primary.xml.gz
> > ...
> > 
> > *All* of that is in the RPM header. It's not pulling anything out of the
> > file payload.
> 
> So?  createrepo would need to parse a bit more of the RPM.
> 

Please, lets not make createrepo any slower.  A lot of hard work has
gone into getting it as fast as it is today, I don't want to see that
move the other direction.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/bd753850/attachment.sig>

From james at fedoraproject.org  Mon Jan 26 18:13:49 2009
From: james at fedoraproject.org (James Antill)
Date: Mon, 26 Jan 2009 13:13:49 -0500
Subject: Lack of update information
In-Reply-To: <f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
Message-ID: <1232993629.28200.16.camel@code.and.org>

On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
> > Rahul Sundaram pisze:
> >> Hi,
> >>
> >> A while back, I tried to selectively update some packages and noticed
> >> that the update information provided by package maintainers (seen via
> >> PackageKit) is sorely lacking.
> >>
> >> * Update foo to upstream 2.16.2
> >[..]
> > Btw, how about pulling the data from spec %changelog automatically?
> 
> Well in most cases the changelog will just contain the same "update to x.y.z"
> For some packages the changes just aren't  worth listing.
> For example each iw release only contain minor changes, people that
> really care about them know how to look it up.
> I could also just add "Small fixes and minor updates from upstream"
> but that's the same as "Update to x.y.z".

 It's the same _to you_, because you know that there are only some minor
number of fixes. But for almost anyone not you it could mean:

. fix for specific bug

. minor fixes

. minor fixes and minor feature or two

. minor fixes and one huge new feature

. lots of new features

...so putting the longer form in there helps everyone else.

> Copying the upstream changelog, that must people do not understand
> does not help either.

 There's a big difference between a "git log"?, a complete overview
changelog? and something you put in a bodhi update?.


?
http://yum.baseurl.org/gitweb?p=yum.git;a=shortlog;h=refs/heads/yum-3_2_X

? http://james.fedorapeople.org/yum/yum%20overview%20changelog

? https://admin.fedoraproject.org/updates/F10/FEDORA-2008-11027

-- 
James Antill <james at fedoraproject.org>
Fedora



From notting at redhat.com  Mon Jan 26 18:17:40 2009
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 26 Jan 2009 13:17:40 -0500
Subject: Lack of update information
In-Reply-To: <20090126175147.GC12774@amd.home.annexia.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
Message-ID: <20090126181740.GB17390@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> > *All* of that is in the RPM header. It's not pulling anything out of the
> > file payload.
> 
> So?  createrepo would need to parse a bit more of the RPM.

1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...

Bill



From jkeating at redhat.com  Mon Jan 26 18:28:45 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 10:28:45 -0800
Subject: Lack of update information
In-Reply-To: <20090126181740.GB17390@nostromo.devel.redhat.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
	<20090126181740.GB17390@nostromo.devel.redhat.com>
Message-ID: <1232994525.8363.152.camel@localhost.localdomain>

On Mon, 2009-01-26 at 13:17 -0500, Bill Nottingham wrote:
>  1) Having createrepo have to parse the entire cpio metadata to
> look for a particular file would be insanely slow
> 2) I just picked a random package I maintain. The ChangeLog is
> 1.4MB uncompressed, 326k compressed. Even if that's larger than
> typical, imagine scaling that out across 7000 source packages,
> and then the size of the resulting XML to download...

Not to mention that the CHANGELOG is typically in the -docs package,
whereas the repo being generated may not /have/ the -docs package.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/d122502e/attachment.sig>

From jakub at redhat.com  Mon Jan 26 18:30:47 2009
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 26 Jan 2009 19:30:47 +0100
Subject: Lack of update information
In-Reply-To: <20090126181740.GB17390@nostromo.devel.redhat.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
	<20090126181740.GB17390@nostromo.devel.redhat.com>
Message-ID: <20090126183047.GJ5690@tyan-ft48-01.lab.bos.redhat.com>

On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > > *All* of that is in the RPM header. It's not pulling anything out of the
> > > file payload.
> > 
> > So?  createrepo would need to parse a bit more of the RPM.
> 
> 1) Having createrepo have to parse the entire cpio metadata to
> look for a particular file would be insanely slow
> 2) I just picked a random package I maintain. The ChangeLog is
> 1.4MB uncompressed, 326k compressed. Even if that's larger than
> typical, imagine scaling that out across 7000 source packages,
> and then the size of the resulting XML to download...

In gcc ChangeLogs are 5.2MB bzip2 -9ed, glibc has 6.5MB of uncompressed
ChangeLogs (haven't checked how big they are compressed).  Putting that
all into metadata is going to grow it a lot.

	Jakub



From pmatilai at laiskiainen.org  Mon Jan 26 19:05:23 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 26 Jan 2009 21:05:23 +0200 (EET)
Subject: Lack of update information
In-Reply-To: <20090126183047.GJ5690@tyan-ft48-01.lab.bos.redhat.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
	<20090126181740.GB17390@nostromo.devel.redhat.com>
	<20090126183047.GJ5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <alpine.LFD.2.00.0901262052230.25966@turre.koti.laiskiainen.org>

On Mon, 26 Jan 2009, Jakub Jelinek wrote:

> On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
>> Richard W.M. Jones (rjones at redhat.com) said:
>>>> *All* of that is in the RPM header. It's not pulling anything out of the
>>>> file payload.
>>>
>>> So?  createrepo would need to parse a bit more of the RPM.
>>
>> 1) Having createrepo have to parse the entire cpio metadata to
>> look for a particular file would be insanely slow
>> 2) I just picked a random package I maintain. The ChangeLog is
>> 1.4MB uncompressed, 326k compressed. Even if that's larger than
>> typical, imagine scaling that out across 7000 source packages,
>> and then the size of the resulting XML to download...
>
> In gcc ChangeLogs are 5.2MB bzip2 -9ed, glibc has 6.5MB of uncompressed
> ChangeLogs (haven't checked how big they are compressed).  Putting that
> all into metadata is going to grow it a lot.

...and the header data is not compressed whereas the payload is. It 
would not only hugely bloat the download size but rpmdb size too. And 
having it in metadata (ie in the header) would mean you'd have to use rpm 
--someswitch to access it, whereas it's on the filesystem now. All doable, 
but I *really* dont see the average upstream ChangeLog available as 
metadata worth all this.

Adding a "news" or "changelog" file attribute would cost exactly one bit 
of a bitfield, that would be quite another story. Except .. well, rpm 
already supports %readme and %license "file attributes", but nothing at 
all uses them for anything. Part of that is probably that they aren't 
compatible with %doc so they're pretty cumbersome to use in a spec. Maybe 
that'd be worth fixing, and at least licenses are something that would 
want special treatment anyway (ie get installed even with --nodocs)

 	- Panu -



From pmatilai at laiskiainen.org  Mon Jan 26 19:13:13 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 26 Jan 2009 21:13:13 +0200 (EET)
Subject: Lack of update information
In-Reply-To: <alpine.LFD.2.00.0901262052230.25966@turre.koti.laiskiainen.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
	<20090126181740.GB17390@nostromo.devel.redhat.com>
	<20090126183047.GJ5690@tyan-ft48-01.lab.bos.redhat.com>
	<alpine.LFD.2.00.0901262052230.25966@turre.koti.laiskiainen.org>
Message-ID: <alpine.LFD.2.00.0901262106380.25966@turre.koti.laiskiainen.org>

On Mon, 26 Jan 2009, Panu Matilainen wrote:
> Adding a "news" or "changelog" file attribute would cost exactly one bit of a 
> bitfield, that would be quite another story. Except .. well, rpm already 
> supports %readme and %license "file attributes", but nothing at all uses them 
> for anything. Part of that is probably that they aren't compatible with %doc 
> so they're pretty cumbersome to use in a spec. Maybe that'd be worth fixing, 
> and at least licenses are something that would want special treatment anyway 
> (ie get installed even with --nodocs)

...and of course, this is what the original request was about. Only then 
you're back to the point that the file contents are in the payload, and 
accessing it is way too expensive to do in createrepo. And still you'd get 
this *huge* blob of xml/sqlite that you'd have to download to access the 
data...

 	- Panu -



From cweyl at alumni.drew.edu  Mon Jan 26 19:37:14 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 11:37:14 -0800
Subject: Lack of update information
In-Reply-To: <497DAB0F.109@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
Message-ID: <7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>

On Mon, Jan 26, 2009 at 4:22 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Patrice Dumas wrote:
>>
>> On Mon, Jan 26, 2009 at 01:12:23PM +0100, Mathieu Bridon (bochecha) wrote:
>>>>
>>>> Also, if the maintainer knows where the information about the update is
>>>> it could be nice to have it in bodhi, but not mandatory. Something like
>>>>
>>>>  See some.site.org/release_notes.html for the changes.
>>>>
>>>> or
>>>>  See /usr/share/doc/foo-1.0/NEWS for the changes.
>>>
>>> The first one is nice, but the second one causes a problem: how can
>>> you review the changes _before_ updating if the file listing changes
>>> is inside the updated package ?
>>
>> You can't. But this is something for upstream, in my opinion.
>
> If upstream does it on their own, package maintainers must add pointers to
> it. If not, the job of summarizing the need for an update rests with the
> package maintainers since they are the ones pushing it to end users. Package
> maintainers can help upstream in the process if necessary as well. Version
> numbers by themselves don't mean much, if anything at all since they aren't
> used consistently across different projects or even between releases.  The
> whole point of enforcing a description field is to help end users get more
> information beyond just version numbers.

Sigh.  I hesitate to get in the middle of this one, but...

Let's not make anything more difficult for the package maintainers,
eh?  Over the last couple years we've already seen a slew of new
policy, requirements, etc, that make things more onerous for our
(largely UNPAID volunteer) maintainers; I suspect some are still
not-so-happy with having to go through bodhi for that.  I know that if
I had to manually touch each update's notes, I'd be very hard pressed
to maintain my packages.  Any policy along these lines seems like a
HUGE amount of extra work (every maintainer summarizing a changelog
that may or may not exist for every update) with little added benefit
(those who are likely to be looking at this are those who probably
know how to find and read a changelog; those who don't probably will
just update anyways).

Also, as others have pointed out, the rpm %changelog is the place to
summarize changes to the _delivered_ package, not the program itself.
e.g. "added examples/ to %%doc" or "resolved RHBZ#123456 by excluding
*.a from %%files" would be appropriate in a changelog, whereas "major
changes to the functionality of this version include the new
frobnicate feature of the Fedora Orbital Laser, ..." would be out of
place.  Let's not overload %changelog to be something it isn't.

In any case, regardless of this, a couple solutions with little to no
maintainer impact present themselves to me:

1) Have the graphical updater tool present a message like "These are
the package update notes and changes as noted by the packager; for a
comprehensive list please find the package changelog through its
homepage at <url>"
2) Submit such a statement at the head of the bodhi update notes.
I'll be updating my bodhi-enh[1] script to do just this.

                        -Chris

[1] right now, something like this:

#!/bin/sh

set -ex

REL=`cat branch | sed -e s/-//`

make clog
bodhi -n -c "`cat clog`" -r $REL -t enhancement -R testing `make verrel`

-- 
Chris Weyl
Ex astris, scientia



From sundaram at fedoraproject.org  Mon Jan 26 19:47:12 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 01:17:12 +0530
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
Message-ID: <497E1340.8000303@fedoraproject.org>

Chris Weyl wrote:

> Let's not make anything more difficult for the package maintainers,
> eh?  

In general, I certainly agree but policies weren't introduced in the 
last to make life harder for maintainers but easier for end users and 
for a small additional cost to maintainers, we can benefit end users 
much more. We are doing a pretty sloppy job with updates and are 
providing good information on why those massive amount of updates are 
needed for end users. Just simply pushing the latest version isn't a 
good reason. There must be a definite need for it and bodhi should have 
that information from the package maintainers. I also suggest everyone 
to get more co-maintainers. Certainly made life much more easier for me.

> Also, as others have pointed out, the rpm %changelog is the place to
> summarize changes to the _delivered_ package, not the program itself.

... and I have pointed out repeatedly that I wasn't talking about the 
changelog but the description field in bodhi.

Rahul



From robert at fedoraproject.org  Mon Jan 26 19:57:16 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 20:57:16 +0100
Subject: Lack of update information
In-Reply-To: <497E1340.8000303@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
Message-ID: <20090126195716.GA21250@hurricane.linuxnetz.de>

On Tue, 27 Jan 2009, Rahul Sundaram wrote:
> much more. We are doing a pretty sloppy job with updates and are  
> providing good information on why those massive amount of updates are  
> needed for end users. Just simply pushing the latest version isn't a  

In general, I agree with you. Maintainers must and have to put information
and details into Bodhi when submitting an update. Just "upgrade to xxx" is
not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
an important security fix, details will follow in the next days or so" as
this already happend multiple times in the past. Usually then, it is a more
bigger security issue with remote impacts which has to pass through without
any stoppers except for or by the Fedora Security team.

So yes, we need some kind of guideline, either some fazit about the update
or the upstream changelog (depends on what is understandable, so gcc, glibc
and friends are also some exceptions, I would guess). On the other hand,
the Bodhi stuff has to be handable for the package maintainer. Speaking for
me and the other unpaid Fedora package maintainers, it is our time, we like
to spend and we spend for the project. Making it unnecessary complicated
shouldn't be the goal at all: Keep it simple, doable and suitable for both
sides: Maintainers and users.

> ... and I have pointed out repeatedly that I wasn't talking about the  
> changelog but the description field in bodhi.

I think, I brought this wrong understanding up a couple of hours ago. I'm
sorry, that I misunderstood you. I was thinking, you are referring to RPM
%changelog, not do Bodhi.


Greetings,
  Robert



From robert at fedoraproject.org  Mon Jan 26 20:01:37 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 21:01:37 +0100
Subject: Lack of update information
In-Reply-To: <1232960908.4081.10.camel@hughsie-work.lan>
References: <497D6B24.8050702@fedoraproject.org>
	<1232960908.4081.10.camel@hughsie-work.lan>
Message-ID: <20090126200137.GB21250@hurricane.linuxnetz.de>

On Mon, 26 Jan 2009, Richard Hughes wrote:
> Some people don't even put that into Bohdi. I think that some update
> text and CVE's should be mandatory and bugzillas should be recommended.

It doesn't make sense to make CVEs mandatory. For packages like phpMyAdmin
and ClamAV security issues the CVEs are often created after the update
happened, so the only thing, I can do there, when preparing the update is
to add the Red Hat Bugzilla ID.

Making CVE mandatory for a bugfix-only or for an enhancement update also
doesn't make any sense.


Greetings,
  Robert



From sundaram at fedoraproject.org  Mon Jan 26 20:04:58 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 01:34:58 +0530
Subject: Lack of update information
In-Reply-To: <20090126195716.GA21250@hurricane.linuxnetz.de>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>
	<20090126195716.GA21250@hurricane.linuxnetz.de>
Message-ID: <497E176A.50603@fedoraproject.org>

Robert Scheck wrote:
> On Tue, 27 Jan 2009, Rahul Sundaram wrote:
>> much more. We are doing a pretty sloppy job with updates and are  
>> providing good information on why those massive amount of updates are  
>> needed for end users. Just simply pushing the latest version isn't a  
> 
> In general, I agree with you. Maintainers must and have to put information
> and details into Bodhi when submitting an update. Just "upgrade to xxx" is
> not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
> phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
> an important security fix, details will follow in the next days or so" as
> this already happend multiple times in the past. Usually then, it is a more
> bigger security issue with remote impacts which has to pass through without
> any stoppers except for or by the Fedora Security team.

I wasn't aware of this. This seems a very odd practise. Why is this 
happening?

> So yes, we need some kind of guideline, either some fazit about the update
> or the upstream changelog (depends on what is understandable, so gcc, glibc
> and friends are also some exceptions, I would guess). On the other hand,
> the Bodhi stuff has to be handable for the package maintainer. Speaking for
> me and the other unpaid Fedora package maintainers, it is our time, we like
> to spend and we spend for the project. Making it unnecessary complicated
> shouldn't be the goal at all: Keep it simple, doable and suitable for both
> sides: Maintainers and users.

Absolutely. So would you mind drafting a guideline for this? My goal 
from this as a end user was just to more intelligently cherry pick 
updates (bandwidth issues, cost of connection etc) and some of the 
updates give me zero information beyond just semi random version numbers 
to do this. Another potential problem is that third party repositories 
typically don't make use of bodhi or equivalent so the experience is 
very inconsistent across updates.

Rahul



From cweyl at alumni.drew.edu  Mon Jan 26 20:06:56 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 12:06:56 -0800
Subject: Lack of update information
In-Reply-To: <497E1340.8000303@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
Message-ID: <7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>

On Mon, Jan 26, 2009 at 11:47 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Chris Weyl wrote:
>
>> Let's not make anything more difficult for the package maintainers,
>> eh?
>
> In general, I certainly agree but policies weren't introduced in the last to
> make life harder for maintainers but easier for end users and for a small
> additional cost to maintainers, we can benefit end users much more. We are
> doing a pretty sloppy job with updates and are providing good information on
> why those massive amount of updates are needed for end users. Just simply
> pushing the latest version isn't a good reason. There must be a definite
> need for it and bodhi should have that information from the package
> maintainers. I also suggest everyone to get more co-maintainers. Certainly
> made life much more easier for me.

It's hardly a "small additional cost", especially when looked at in
aggregate; this would be an additional non-automateable step required
for every update release that is of very questionable value/utility to
the vast majority of our users.  I realize it would make your life
easier, but is it worth an additional imposition on our already
highly-regulated maintainers just to make your life easier?  I stand
by my earlier assessment that the vast bulk of our users could care
less, and those that do care would know how to find a package's
changelog.  If this is important, we should find some way of
automatically including a pointer to upstream's changelog in the
update tool itself.

Basically, this seems to be "I don't really trust the package
maintainer's decision on why I should upgrade, so I want to know what
changes this introduces."  Which is absolutely fine -- and also when
someone should be reading upstream's changelog to understand the
changes introduced by upstream.  In terms of the spec changes as
documented in %changelog, "updated to version x.y.z" is all the
justification needed as to why the new level was built and released;
what actually changed in that new level is the purview of the upstream
maintainer.

>> Also, as others have pointed out, the rpm %changelog is the place to
>> summarize changes to the _delivered_ package, not the program itself.
>
> ... and I have pointed out repeatedly that I wasn't talking about the
> changelog but the description field in bodhi.

Not all pontifications are specifically aimed your way :-)

                                -Chris

-- 
Chris Weyl
Ex astris, scientia



From sundaram at fedoraproject.org  Mon Jan 26 20:19:53 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 01:49:53 +0530
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
Message-ID: <497E1AE9.20606@fedoraproject.org>

Chris Weyl wrote:

> 
> It's hardly a "small additional cost", especially when looked at in
> aggregate; this would be an additional non-automateable step required
> for every update release that is of very questionable value/utility to
> the vast majority of our users.  

I wouldn't say that. Currently it is of questionable value currently but 
it would be much more valuable without just version bumping and more 
careful thought put into justifying the need for updates. Every update 
adds to a large cost in terms of build time, bandwidth, potential 
regressions etc.

I realize it would make your life
> easier, but is it worth an additional imposition on our already
> highly-regulated maintainers just to make your life easier? 

This is hardly about just me. I am not the only user on low bandwidth 
connections at times. Many regions of the world are as you can see from 
the number of people agreeing with the general idea.

> Basically, this seems to be "I don't really trust the package
> maintainer's decision on why I should upgrade, so I want to know what
> changes this introduces."  

There are other considerations including but not limited to bandwidth 
and yes, the criteria that users choose for consuming updates can be 
quite different from the maintainer's reason for pushing the update and 
without the maintainers informing me of why they decided to do a push, 
users can't arbitrate their decisions either.

This step requires human intelligence and cannot be automated 
completely. You will have to take into account not only things like 
upstream changelogs (names,location etc differ widely and may not even 
be provided) but also downstream patches, downstream bugs filed that are 
being fixed by a particular update, CVE information for security updates
and much more information that a package maintainer would know about and 
is very valuable to be passed on to end users.  Some portions which can 
be automated, already are, such as bodhi closing updates optionally if 
the bug numbers are specified.

Rahul



From robert at fedoraproject.org  Mon Jan 26 20:22:04 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Mon, 26 Jan 2009 21:22:04 +0100
Subject: Lack of update information
In-Reply-To: <497E176A.50603@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<20090126195716.GA21250@hurricane.linuxnetz.de>
	<497E176A.50603@fedoraproject.org>
Message-ID: <20090126202204.GC21250@hurricane.linuxnetz.de>

On Tue, 27 Jan 2009, Rahul Sundaram wrote:
> Robert Scheck wrote:
>> In general, I agree with you. Maintainers must and have to put information
>> and details into Bodhi when submitting an update. Just "upgrade to xxx" is
>> not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
>> phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this is
>> an important security fix, details will follow in the next days or so" as
>> this already happend multiple times in the past. Usually then, it is a more
>> bigger security issue with remote impacts which has to pass through without
>> any stoppers except for or by the Fedora Security team.
>
> I wasn't aware of this. This seems a very odd practise. Why is this  
> happening?

Very good question. When asking, I didn't get a real answer. Sometimes, a
public proof of concept exists already. Maybe the intention is, that if
they make the security issue public, the vendors had time to put updated
packages into their systems. Luckily, that doesn't happen all the time, but
only sometimes. If you click through my phpMyAdmin updates, you will find
some bug reports referencing "not yet clearly specified security issue" or
similar things. Much more can a packager not do, I would guess.


Greetings,
  Robert



From bpepple at fedoraproject.org  Mon Jan 26 20:29:09 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Mon, 26 Jan 2009 15:29:09 -0500
Subject: Package Review Stats for the week ending January 25th, 2009
Message-ID: <1233001749.7907.2.camel@localhost.localdomain>

Top three  FAS account holders who have completed reviewing "Package
review" components on bugzilla for the week ending January 25th, 2009
were Parag AN(????), Nicolas Mailhot, and Orcan 'oget' Ogetbil.  Below
is the number of package reviews completed.

Parag AN(????) - 8
Nicolas Mailhot - 5
Orcan 'oget' Ogetbil - 4
Jochen Schmitt - 3
Adel Gadllah - 2
Kevin Fenzi - 2
Tom "spot" Callaway - 2
manuel wolfshant - 2
Adam Tkac - 1
Alexander Kurtakov - 1
Bill Nottingham - 1
Dan Hor?k - 1
Darryl L. Pierce - 1
Dominik 'Rathann' Mierzejewski - 1
Fabian Affolter - 1
Ian Weller - 1
Ignacio Vazquez-Abrams - 1
Jens Petersen - 1
Jon Ciesla - 1
Lubomir Rintel - 1
Lucian Langa - 1
Mamoru Tasaka - 1
Marcela Maslanova - 1
Martin-Gomez Pablo - 1
Matthias Clasen - 1
Michel Alexandre Salim - 1
Ruben Kerkhof - 1
Simon Wesp - 1
Thibault North - 1
?imon Luka??k - 1

Review Requests: 44
Merge Reviews: 6
Total reviews modified: 50

Thanks,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/f8fb8431/attachment.sig>

From nicolas.mailhot at laposte.net  Mon Jan 26 20:35:56 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 26 Jan 2009 21:35:56 +0100
Subject: Lack of update information
In-Reply-To: <497E1340.8000303@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
Message-ID: <1233002156.31492.13.camel@arekh.okg>

Le mardi 27 janvier 2009 ? 01:17 +0530, Rahul Sundaram a ?crit :
> Chris Weyl wrote:
> 
> > Let's not make anything more difficult for the package maintainers,
> > eh?  
> 
> In general, I certainly agree but policies weren't introduced in the 
> last to make life harder for maintainers but easier for end users and 
> for a small additional cost to maintainers,

A lot of policies are introduced to make maintainer life easier and help
them avoid known pitfalls. If they all added a new layer, the whole
distribution would become unmaintainable.

I believe the reason rpm has so far avoided triaging upstream-provided
doc and puts it all indiscriminately in %doc, is that the packager
triaging cost is just too high.

Before more English writing is asked of packagers (most of whom are not
native English speakers), in an area the average non-techie user doesn't
consult, and which is useless to a lot of people since it's not
translated, it would be great if some editors did review, fix and
improve of all our package summaries and descriptions, which is
something that *would* have high user impact, and *would* make packager
life easier, by relieving them of a shore which has nothing to do with
technical packaging.

And I'm sure all the localization teams that have to translate the
pidgin English some of us use would cheer too.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/a3496447/attachment.sig>

From habig at neutrino.d.umn.edu  Mon Jan 26 20:34:46 2009
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Mon, 26 Jan 2009 14:34:46 -0600
Subject: Root Logins in X...
In-Reply-To: <e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>
References: <49781C9C.4000007@redhat.com>
	<2a28d2ab0901220317h743dc7f6kc0605a4c6bf51909@mail.gmail.com>
	<1232626439.2631.17.camel@localhost.localdomain>
	<1232630870.13042.8.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220535j432b3b98w8fe21573763c6d2e@mail.gmail.com>
	<1232632284.13042.23.camel@nibbler.dlib.indiana.edu>
	<2a28d2ab0901220601gf9d820cw2db7acf2dd9cf95a@mail.gmail.com>
	<e5f36bc70901260237g6553e587ncf3b06ef90931ed0@mail.gmail.com>
Message-ID: <20090126203446.GA4253@neutrino.d.umn.edu>

Thomas Bendler writes:
> 
> A root login on X is not nessaccary, in no situation (except the
> design of your installation is crap or you switch to init S and you
> have password based login enabled).

What about the case where the user auth is all off on an LDAP server
somewhere, /home is nfs mounted, and the network settings on the box are
borked for some reason?  This or a very similar use case is the norm
rather than the exception in an enterprise situation.

When confronted with a gdm session in this case, where root is the only
local user (as well as what one needs to be logged in as to fix the
network configuration), what does one do?  You need a command line
prompt to type "init S".  One could reboot, intercept grub and do "linux
single", I suppose, but using linux seems to be all about avoiding the
reboot :)

Dropping to a different console with crtl-alt-Fsomething gets you there
too.  But in either case, better hope you haven't been using the fancy
system admin GUIs which rewrite your conf files in non-obvious ways to
set up whatever service has fallen over.  More and more of the
"system-config-blah-tui" tools have fallen by the wayside over the
releases. 

When confronted with the above network situation I was able to fix
things - but as we try to depreciate working at the command line, the
fraction of the user base able to fix things from a console continues to
shrink.  While unix gives you all the rope you want to hang yourself,
the current gdm default of "no root X login" hides the knife people are
expecting to be able to use to saw through the noose.

      Alec

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/dc6c6c15/attachment.sig>

From sundaram at fedoraproject.org  Mon Jan 26 20:36:05 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 02:06:05 +0530
Subject: Lack of update information
In-Reply-To: <20090126202204.GC21250@hurricane.linuxnetz.de>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<20090126195716.GA21250@hurricane.linuxnetz.de>	<497E176A.50603@fedoraproject.org>
	<20090126202204.GC21250@hurricane.linuxnetz.de>
Message-ID: <497E1EB5.1030307@fedoraproject.org>

Robert Scheck wrote:

> 
> Very good question. When asking, I didn't get a real answer. Sometimes, a
> public proof of concept exists already. Maybe the intention is, that if
> they make the security issue public, the vendors had time to put updated
> packages into their systems. Luckily, that doesn't happen all the time, but
> only sometimes. If you click through my phpMyAdmin updates, you will find
> some bug reports referencing "not yet clearly specified security issue" or
> similar things. Much more can a packager not do, I would guess.

Maybe you can take this up to

http://lists.freedesktop.org/mailman/listinfo/distributions

Collectively apply some pressure to upstream or atleast find good 
consistent workarounds.

Rahul



From kraxel at redhat.com  Mon Jan 26 20:39:43 2009
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Mon, 26 Jan 2009 21:39:43 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126124520.GA2381@yoda.jdub.homelinux.org>	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126131852.GB2381@yoda.jdub.homelinux.org>
	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <497E1F8F.4050203@redhat.com>

Jakub Jelinek wrote:

> For glibc 2.9 (F10) it would suffice to just have .27, but for rawhide
> .29 introduces futex bitset and realtime clock support, which means an extra
> syscall for every threaded program.  We could bump it in steps, first start
> requiring .27 and then if .29 is sufficiently stable in a month (or when
> we really need to freeze), rebuild just glibc requiring a newer kernel.

Can we *please* wait a bit until raising the bar *that* high?  Breaking
mock builds for rawhide on F9/10 releases is a really bad idea IMHO.
Which meas supporting at least 2.6.27.  Maybe in a year when F9 is EOL
and F10 has a 2.6.29 kernel update we can reconsider 2.6.29.

cheers,
  Gerd



From mike at cchtml.com  Mon Jan 26 20:59:09 2009
From: mike at cchtml.com (Michael Cronenworth)
Date: Mon, 26 Jan 2009 14:59:09 -0600
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497E1F8F.4050203@redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126124520.GA2381@yoda.jdub.homelinux.org>	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126131852.GB2381@yoda.jdub.homelinux.org>	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
	<497E1F8F.4050203@redhat.com>
Message-ID: <497E241D.3050801@cchtml.com>

-------- Original Message --------
Subject: Re: Default ISA/tuning flags for GCC, --enable-kernel= level 
for glibc
From: Gerd Hoffmann <kraxel at redhat.com>
To: Jakub Jelinek <jakub at redhat.com>, Development discussions related to 
Fedora <fedora-devel-list at redhat.com>
CC: Jesse Keating <jkeating at redhat.com>, Tom Callaway 
<tcallawa at redhat.com>, Bill Nottingham <notting at redhat.com>, Ulrich 
Drepper <drepper at redhat.com>
Date: 01/26/2009 02:39 PM
> 
> Can we *please* wait a bit until raising the bar *that* high?  Breaking
> mock builds for rawhide on F9/10 releases is a really bad idea IMHO.
> Which meas supporting at least 2.6.27.  Maybe in a year when F9 is EOL
> and F10 has a 2.6.29 kernel update we can reconsider 2.6.29.
> 
> cheers,
>   Gerd
> 


So when 2010 rolls around you'll be saying "pleaseeeee wait until F12 
has reached EOL"?

The pain has to occur sometime.

How about rolling up to 2.6.18 right now? That shouldn't hurt anything, 
should it?

Make 2.6.29 a Fedora 12 priority. This shouldn't go against what you 
requested.



From jkeating at redhat.com  Mon Jan 26 21:00:44 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 13:00:44 -0800
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497E241D.3050801@cchtml.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126124520.GA2381@yoda.jdub.homelinux.org>
	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126131852.GB2381@yoda.jdub.homelinux.org>
	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>
	<497E1F8F.4050203@redhat.com>  <497E241D.3050801@cchtml.com>
Message-ID: <1233003644.8363.158.camel@localhost.localdomain>

On Mon, 2009-01-26 at 14:59 -0600, Michael Cronenworth wrote:
>  
> So when 2010 rolls around you'll be saying "pleaseeeee wait until F12 
> has reached EOL"?
> 
> The pain has to occur sometime.
> 
> How about rolling up to 2.6.18 right now? That shouldn't hurt anything, 
> should it?
> 
> Make 2.6.29 a Fedora 12 priority. This shouldn't go against what you 
> requested.
> 

This is going to sound horrible coming from a Red Hat person, but
ideally we'd never lose backwards compat to the previous RHEL version.
IE we can bump it up to whatever RHEL5 supports now, and when RHEL6
ships bump it again.  This should give us a reasonable amount of
backwards compat.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/ee101cb7/attachment.sig>

From cry_regarder at yahoo.com  Mon Jan 26 21:07:40 2009
From: cry_regarder at yahoo.com (Cry)
Date: Mon, 26 Jan 2009 21:07:40 +0000 (UTC)
Subject: Attn FESco:  Non-Responsive Maintainer - John Berninger
Message-ID: <loom.20090126T205342-438@post.gmane.org>

Attn Fesco,

Per the Fedora Non-Responsive Maintainer Policy at:

https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

    * After another 7 days (now 3 weeks total), the reporter posts a formal
request to the fedora-devel list with the bug link, indicating all reasonable
efforts have been made to contact the maintainer have failed and that they wish
to take over the package. 

I would like to trigger the next phase of the non-responsive maintainer policy.

Extensive efforts have been made at various email addresses to contact John but
no replies have been received.  In addition two separate bugzilla entries were
made against his package gallery2 asking for his response:

https://bugzilla.redhat.com/show_bug.cgi?id=474870
https://bugzilla.redhat.com/show_bug.cgi?id=476477

Please remove him from the primary maintainer list for his packages.  orphan any
packages that that leaves maintainerless. 

Involved packages include ratpoison, squidguard, wordpress, bugzilla, gallery2.

Jon Ciesla (https://bugzilla.redhat.com/show_bug.cgi?id=474870#c7) requested
maintainership for gallery2.  He has already provided updates.

Thanks,

Cry



From itamar at ispbrasil.com.br  Mon Jan 26 21:12:22 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Mon, 26 Jan 2009 19:12:22 -0200
Subject: Attn FESco: Non-Responsive Maintainer - John Berninger
In-Reply-To: <loom.20090126T205342-438@post.gmane.org>
References: <loom.20090126T205342-438@post.gmane.org>
Message-ID: <d3ceea380901261312r3cefb111mb6baf01b538e0911@mail.gmail.com>

We have the same problem for SS5 package

https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5



On Mon, Jan 26, 2009 at 7:07 PM, Cry <cry_regarder at yahoo.com> wrote:
> Attn Fesco,
>
> Per the Fedora Non-Responsive Maintainer Policy at:
>
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>
>    * After another 7 days (now 3 weeks total), the reporter posts a formal
> request to the fedora-devel list with the bug link, indicating all reasonable
> efforts have been made to contact the maintainer have failed and that they wish
> to take over the package.
>
> I would like to trigger the next phase of the non-responsive maintainer policy.
>
> Extensive efforts have been made at various email addresses to contact John but
> no replies have been received.  In addition two separate bugzilla entries were
> made against his package gallery2 asking for his response:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=474870
> https://bugzilla.redhat.com/show_bug.cgi?id=476477
>
> Please remove him from the primary maintainer list for his packages.  orphan any
> packages that that leaves maintainerless.
>
> Involved packages include ratpoison, squidguard, wordpress, bugzilla, gallery2.
>
> Jon Ciesla (https://bugzilla.redhat.com/show_bug.cgi?id=474870#c7) requested
> maintainership for gallery2.  He has already provided updates.
>
> Thanks,
>
> Cry
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From ianweller at gmail.com  Mon Jan 26 21:35:09 2009
From: ianweller at gmail.com (Ian Weller)
Date: Mon, 26 Jan 2009 15:35:09 -0600
Subject: wiki structure policy (was: Re: Wiki tip for the week of Jan
	26 2009: Moving pages with ease)
In-Reply-To: <497D4DF7.4040704@leemhuis.info>
References: <20090126053057.GA1630@gmail.com> <497D4DF7.4040704@leemhuis.info>
Message-ID: <20090126213509.GB26008@gmail.com>

On Mon, Jan 26, 2009 at 06:45:27AM +0100, Thorsten Leemhuis wrote:
> On 26.01.2009 06:30, Ian Weller wrote:
>>
>>
>> Wiki tip of the week for Jan 26 2009: Moving pages with ease
>> ============================================================
>>
>> With the new page naming and wiki structure policy[1] in place, [...]
>> [1]: https://fedoraproject.org/wiki/Help:Wiki_structure
>
> One question regarding that wiki structure policy: How can I watch a  
> certain set of wiki pages closely? In the past I simply read the rss  
> feed with rss2email and looked out for pages that started with EPEL/,  
> Packaging/ or Feature/ (for example) and ignored the others. That  
> doesn't work anymore, thus I'm looking for a alternative.
>
I'm working on something that will allow you to watch pages by category.
Until then, hitting the [watch] tab at the top of each page is your best
bet, unfortunately.

-- 
Ian Weller <ianweller at gmail.com>                  http://ianweller.org
GnuPG fingerprint:  E51E 0517 7A92 70A2 4226  B050 87ED 7C97 EFA8 4A36
"Technology is a word that describes something that doesn't work yet."
  ~ Douglas Adams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/45bc5b6b/attachment.sig>

From cweyl at alumni.drew.edu  Mon Jan 26 21:37:15 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 13:37:15 -0800
Subject: Lack of update information
In-Reply-To: <497E1AE9.20606@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
Message-ID: <7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>

On Mon, Jan 26, 2009 at 12:19 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Chris Weyl wrote:
>
>> It's hardly a "small additional cost", especially when looked at in
>> aggregate; this would be an additional non-automateable step required
>> for every update release that is of very questionable value/utility to
>> the vast majority of our users.
>
> I wouldn't say that. Currently it is of questionable value currently but it
> would be much more valuable without just version bumping and more careful
> thought put into justifying the need for updates. Every update adds to a
> large cost in terms of build time, bandwidth, potential regressions etc.

...costs which are trivial next to the packager/maintainer time and
increase in their workload.  (did I mention, largely unpaid workload?)

If you think that "version bumping" is a bad thing (which, frankly, I
suspect most people refer to as "tracking upstream"), then argue we
should put in place guidelines requiring "maintainers evaluate and
justify issuing an update"... of course, then we'd need a review
board, appeal process, procedures, etc, etc.  If you're worried about
regressions, then let's get something going that tracks what packages
depend on the package the update and exercises their functionality...
Which would be next to impossible for programs that don't have a test
suite.  (Arguably, the best way to detect and correct regressions is
to track upstream and provide feedback to them.)

None of these "goals" will be helped by imposing a barely related new
manual process requirement that you concede is "[c]ertainly of
questionable value".

>> I realize it would make your life
>> easier, but is it worth an additional imposition on our already
>> highly-regulated maintainers just to make your life easier?
>
> This is hardly about just me. I am not the only user on low bandwidth
> connections at times. Many regions of the world are as you can see from the
> number of people agreeing with the general idea.

I suspect those on low-bandwidth connections would be better served by presto.

>> Basically, this seems to be "I don't really trust the package
>> maintainer's decision on why I should upgrade, so I want to know what
>> changes this introduces."
>
> There are other considerations including but not limited to bandwidth and
> yes, the criteria that users choose for consuming updates can be quite
> different from the maintainer's reason for pushing the update and without
> the maintainers informing me of why they decided to do a push, users can't
> arbitrate their decisions either.

Not to be blunt, but "too bad".  That's why we're called
"maintainers", and they are "end users".  If "updating to 1.2.3" isn't
good enough, and someone really wants to know what's going on with the
package, then they should read upstream's changelog.  That's what it's
there for, and why we incorporate it by reference.

People know that Fedora aims to be leading-edge technology.  They
expect our packages to track upstream pretty closely, and understand,
yes, we do sometimes have regressions (that are generally tracked
pretty quickly, from what I've seen).  If "too many updates" is a
problem, then perhaps they should rethink what they're doing.

                                         -Chris
-- 
Chris Weyl
Ex astris, scientia



From kevin.kofler at chello.at  Mon Jan 26 21:43:54 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 22:43:54 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<20090126195716.GA21250@hurricane.linuxnetz.de>
Message-ID: <gllaqq$qls$1@ger.gmane.org>

Robert Scheck wrote:
> In general, I agree with you. Maintainers must and have to put information
> and details into Bodhi when submitting an update. Just "upgrade to xxx" is
> not suitable, yes. But there are exceptions sometimes, e.g. when ClamAV or
> phpMyAdmin upstream goes crazy again and pushes out the fix, tells "this
> is an important security fix, details will follow in the next days or so"
> as this already happend multiple times in the past. Usually then, it is a
> more bigger security issue with remote impacts which has to pass through
> without any stoppers except for or by the Fedora Security team.

diff -Nur foo-old foo-new
and you'll see fairly quickly what they fixed. (And it's also trivial for a
cracker to do that, so it's utterly pointless to try withholding
information that way.)

        Kevin Kofler



From jkeating at redhat.com  Mon Jan 26 21:55:41 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 13:55:41 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
Message-ID: <1233006941.8363.161.camel@localhost.localdomain>

On Mon, 2009-01-26 at 13:37 -0800, Chris Weyl wrote:
>  "maintainers evaluate and
> justify issuing an update"... 

http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/8b352385/attachment.sig>

From jspaleta at gmail.com  Mon Jan 26 21:58:27 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 26 Jan 2009 12:58:27 -0900
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
Message-ID: <604aa7910901261358o575dd1bs4def6df7ef0f4275@mail.gmail.com>

On Mon, Jan 26, 2009 at 12:37 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> People know that Fedora aims to be leading-edge technology.  They
> expect our packages to track upstream pretty closely, and understand,
> yes, we do sometimes have regressions (that are generally tracked
> pretty quickly, from what I've seen).  If "too many updates" is a
> problem, then perhaps they should rethink what they're doing.

The is another option, which is to grow some refinement in our update
collection structuring.   We keep updates-testing and updates exactly
as they are but introduce a self-consistent culled-updates collection
with a higher reporting mandate that is a subset of what flows through
updates-released.   People step forward to do the work to meet the
higher reporting mandate of the culled collection so that each culled
update has adequate information in its bodhi record to meet the higher
standard.  That would keep current package maintainers are not
burdened by the additional requirement, but would create a space for
people to prove that the additional information has a cost to benefit
ratio that makes it worth doing as a best practise.

However such a culled space is still not zero cost, as it would
require its own repository layout and mirroring since it would be
slower moving than updates. We'd still have to decide if it were worth
doing with project resources even as an experiment.

-jef



From kevin.kofler at chello.at  Mon Jan 26 22:02:46 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 23:02:46 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
Message-ID: <gllbu8$ep$1@ger.gmane.org>

Chris Weyl wrote:
> It's hardly a "small additional cost", especially when looked at in
> aggregate; this would be an additional non-automateable step required
> for every update release that is of very questionable value/utility to
> the vast majority of our users.  I realize it would make your life
> easier, but is it worth an additional imposition on our already
> highly-regulated maintainers just to make your life easier?  I stand
> by my earlier assessment that the vast bulk of our users could care
> less, and those that do care would know how to find a package's
> changelog.  If this is important, we should find some way of
> automatically including a pointer to upstream's changelog in the
> update tool itself.

As one of those maintainers who always fill in useful update notes, I'll say
that:
* Updates should include at least one sentence of rationale why they're
being pushed, and either a summary of the changes or the URL of such a
summary from upstream. (And in some cases the rationale and the summary of
changes are the same thing - if the update fixes some critical bug, that's
an obvious reason to push it.) IMHO updates with empty update details
should get rejected by Bodhi outright, and there should also be a policy
that "update to 1.2.3" is not sufficient.
* It takes almost no time to fill that in. You have to fill in a form for
the update anyway, typing a sentence or two and copying&pasting a URL into
it isn't going to hurt your fingers.
* I'm not a fan of selective updates at all (they tend not to work
properly), but as a user I still want to know *what* I'm getting in the
update. Each time I see an update with blank update notes or just "new
upstream version", I feel an urge to kick the maintainer in the rear.

You can see my updates for examples of how I'd expect update details to look
like:
https://admin.fedoraproject.org/updates/user/kkofler
They're not always perfect (for example, I should have tried to figure out
what changed in the latest qt-copy patches included in that qt-4.4.3-6.fc10
update - I did give the rationale for pushing it though (fixing the upgrade
path from F9)), but if you can do as good as me, that'd already be
great. ;-) And it isn't that much work.

So in case it wasn't obvious I'm in favor of a policy for useful update
details.

        Kevin Kofler



From cweyl at alumni.drew.edu  Mon Jan 26 22:07:03 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 14:07:03 -0800
Subject: Lack of update information
In-Reply-To: <1233006941.8363.161.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<1233006941.8363.161.camel@localhost.localdomain>
Message-ID: <7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>

2009/1/26 Jesse Keating <jkeating at redhat.com>:
> On Mon, 2009-01-26 at 13:37 -0800, Chris Weyl wrote:
>>  "maintainers evaluate and
>> justify issuing an update"...
>
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

And that's exactly what we are (or should be) doing; we just don't
write an essay about it afterwards :-)

                            -Chris
-- 
Chris Weyl
Ex astris, scientia



From kevin.kofler at chello.at  Mon Jan 26 22:11:57 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 23:11:57 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<1233002156.31492.13.camel@arekh.okg>
Message-ID: <gllcfe$2dp$1@ger.gmane.org>

Nicolas Mailhot wrote:
> Before more English writing is asked of packagers (most of whom are not
> native English speakers), in an area the average non-techie user doesn't
> consult, and which is useless to a lot of people since it's not
> translated, it would be great if some editors did review, fix and
> improve of all our package summaries and descriptions, which is
> something that *would* have high user impact, and *would* make packager
> life easier, by relieving them of a shore which has nothing to do with
> technical packaging.

IMHO update details are at least as important as the summaries and
descriptions.

They're not translated, but that's the nature of current information.
There's just no time to translate it. In fact, I think our process of
freezing release notes early so they can get translated is harmful, I'd
rather have current information in English (which is only my 4th language!)
than old translated information.

> And I'm sure all the localization teams that have to translate the
> pidgin English some of us use would cheer too.

Your English is just fine, in fact I didn't notice a single error in your
entire mail. Most if not all Fedora maintainers are writing decent to
flawless English.

        Kevin Kofler



From jkeating at redhat.com  Mon Jan 26 22:14:01 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 14:14:01 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<1233006941.8363.161.camel@localhost.localdomain>
	<7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>
Message-ID: <1233008041.8363.162.camel@localhost.localdomain>

On Mon, 2009-01-26 at 14:07 -0800, Chris Weyl wrote:
>  
> And that's exactly what we are (or should be) doing; we just don't
> write an essay about it afterwards :-)

Did you actually read the link?

* Package Maintainers should not push every single upstream update to
all branches. Examine the changes in each upstream release and ask if
the update is worth download and update time for many users. For
upstreams that update very often with many small updates, consider
waiting and updated only when the amount of changes is worth updating.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/7808d55a/attachment.sig>

From berrange at redhat.com  Mon Jan 26 22:34:46 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Mon, 26 Jan 2009 22:34:46 +0000
Subject: Lack of update information
In-Reply-To: <20090126181740.GB17390@nostromo.devel.redhat.com>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126143859.GA11540@amd.home.annexia.org>
	<alpine.DEB.1.10.0901261737120.32276@gotcha.dreamhost.com>
	<20090126174331.GA12774@amd.home.annexia.org>
	<20090126174849.GC16274@nostromo.devel.redhat.com>
	<20090126175147.GC12774@amd.home.annexia.org>
	<20090126181740.GB17390@nostromo.devel.redhat.com>
Message-ID: <20090126223446.GA22673@redhat.com>

On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
> Richard W.M. Jones (rjones at redhat.com) said: 
> > > *All* of that is in the RPM header. It's not pulling anything out of the
> > > file payload.
> > 
> > So?  createrepo would need to parse a bit more of the RPM.
> 
> 1) Having createrepo have to parse the entire cpio metadata to
> look for a particular file would be insanely slow
> 2) I just picked a random package I maintain. The ChangeLog is
> 1.4MB uncompressed, 326k compressed. Even if that's larger than
> typical, imagine scaling that out across 7000 source packages,
> and then the size of the resulting XML to download...

Perhaps this idea of including changelogs in the metdata is addressing
the issue with the wrong hammer. When getting a set of 50 updates, very
few users are likely to want or need the changelogs to all of them
prior to install. More likely, they'll just want to occassionaly read
a changelog for an ad-hoc package to find out some info. 

This suggests that rather than including the full changelog for each
package in the createrepo metadata, just include a URL linking to the
changlog on a static webserver. It'd be easy enough to extract changelogs 
for each newly built package somewhere easily linkable (and mirrorable if
neccessary). So on a rare occassion when a tool processing repodata does
want the changelog it can quickly download it on demand.

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 kevin.kofler at chello.at  Mon Jan 26 22:34:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Mon, 26 Jan 2009 23:34:36 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<604aa7910901261358o575dd1bs4def6df7ef0f4275@mail.gmail.com>
Message-ID: <glldps$560$1@ger.gmane.org>

Jeff Spaleta wrote:
> The is another option, which is to grow some refinement in our update
> collection structuring.   We keep updates-testing and updates exactly
> as they are but introduce a self-consistent culled-updates collection
> with a higher reporting mandate that is a subset of what flows through
> updates-released.   People step forward to do the work to meet the
> higher reporting mandate of the culled collection so that each culled
> update has adequate information in its bodhi record to meet the higher
> standard.  That would keep current package maintainers are not
> burdened by the additional requirement, but would create a space for
> people to prove that the additional information has a cost to benefit
> ratio that makes it worth doing as a best practise.

I don't think that makes sense. We should just require proper update details
for the existing updates. It takes almost no time to fill them in.

        Kevin Kofler



From mw_triad at users.sourceforge.net  Mon Jan 26 22:54:08 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 26 Jan 2009 16:54:08 -0600
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497E241D.3050801@cchtml.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126124520.GA2381@yoda.jdub.homelinux.org>	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126131852.GB2381@yoda.jdub.homelinux.org>	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>	<497E1F8F.4050203@redhat.com>
	<497E241D.3050801@cchtml.com>
Message-ID: <glleug$ad8$1@ger.gmane.org>

Michael Cronenworth wrote:
> -------- Original Message --------

Can you please not quote full e-mail headers? Aside from feeding 
spammers, it's a waste of bandwidth.

> Gerd Hoffmann wrote:
>> Can we *please* wait a bit until raising the bar *that* high?  Breaking
>> mock builds for rawhide on F9/10 releases is a really bad idea IMHO.
>> Which meas supporting at least 2.6.27.  Maybe in a year when F9 is EOL
>> and F10 has a 2.6.29 kernel update we can reconsider 2.6.29.
> 
> So when 2010 rolls around you'll be saying "pleaseeeee wait until F12 
> has reached EOL"?

If at that point you're calling for 2.6.34 or whatever is current then, 
then of course you'll get the same complaining.

I fail to see how supporting live upgrade from an in-support version is 
unreasonable.

> The pain has to occur sometime.

Why? Drop support for not-supported kernels. Currently that seems to 
mean 'earlier than 2.6.18'. In the future, that will be something 
higher, and we can bump accordingly. There is a lag built into this 
system, but that's much different than stagnation.

> How about rolling up to 2.6.18 right now? That shouldn't hurt anything, 
> should it?

Unless I missed something, Gerd didn't say anything to indicate a 
problem with that. I see rather 2.6.27 was mentioned, which is later 
even than 2.6.18 (although I'd have to agree with Jesse about supporting 
2.6.18).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown



From robert at fedoraproject.org  Mon Jan 26 23:03:41 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Tue, 27 Jan 2009 00:03:41 +0100
Subject: Lack of update information
In-Reply-To: <gllaqq$qls$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<20090126195716.GA21250@hurricane.linuxnetz.de>
	<gllaqq$qls$1@ger.gmane.org>
Message-ID: <20090126230341.GA7844@hurricane.linuxnetz.de>

On Mon, 26 Jan 2009, Kevin Kofler wrote:
> diff -Nur foo-old foo-new
> and you'll see fairly quickly what they fixed. (And it's also trivial for a
> cracker to do that, so it's utterly pointless to try withholding
> information that way.)

In theory, yes. But nearly always, these upstreams are putting the security
fixes into the forward development. Further development, sometimes even
code rewrites after last stable release and somewhen a security fix doesn't
make it readable that easy (unified diff can be ~ 2500-7500 lines). For PHP
that might be readable easily, but when not being a C coder, reading/seeing
an overflow, memory games or other leaks might be more hard in such a diff.


Greetings,
  Robert



From allisson at gmail.com  Mon Jan 26 23:12:11 2009
From: allisson at gmail.com (Allisson Azevedo)
Date: Mon, 26 Jan 2009 20:12:11 -0300
Subject: Koji error
Message-ID: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>

Hi,

I can't build perl-MooseX-Async, all branches return this error:

[allisson at notebook F-10]$ make build
/usr/bin/koji  build  dist-f10-updates-candidate 'cvs://
cvs.fedoraproject.org/cvs/pkgs?rpms/perl-MooseX-Async/F-10#perl-MooseX-Async-0_07-1_fc10
'
Created task: 1084508
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=1084508
Watching tasks (this may be safely interrupted)...
1084508 build (dist-f10-updates-candidate,
/cvs/pkgs:rpms/perl-MooseX-Async/F-10:perl-MooseX-Async-0_07-1_fc10): open (
x86-6.fedora.phx.redhat.com)
  1084509 buildSRPMFromSCM
(/cvs/pkgs:rpms/perl-MooseX-Async/F-10:perl-MooseX-Async-0_07-1_fc10): open
(ppc5.fedora.phx.redhat.com)
  1084509 buildSRPMFromSCM
(/cvs/pkgs:rpms/perl-MooseX-Async/F-10:perl-MooseX-Async-0_07-1_fc10): open
(ppc5.fedora.phx.redhat.com) -> closed
  0 free  1 open  1 done  0 failed
1084508 build (dist-f10-updates-candidate,
/cvs/pkgs:rpms/perl-MooseX-Async/F-10:perl-MooseX-Async-0_07-1_fc10): open (
x86-6.fedora.phx.redhat.com) -> FAILED: BuildError: package
perl-MooseX-Async not in list for tag dist-f10-updates-candidate
  0 free  0 open  1 done  1 failed

1084508 build (dist-f10-updates-candidate,
/cvs/pkgs:rpms/perl-MooseX-Async/F-10:perl-MooseX-Async-0_07-1_fc10) failed
make: *** [koji] Error 1

Regards,

Allisson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/4501affc/attachment.htm>

From jkeating at redhat.com  Mon Jan 26 23:15:42 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 15:15:42 -0800
Subject: Koji error
In-Reply-To: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
Message-ID: <1233011742.8363.163.camel@localhost.localdomain>

On Mon, 2009-01-26 at 20:12 -0300, Allisson Azevedo wrote:
>  I can't build perl-MooseX-Async, all branches return this error:

This package was likely just added to koji, please try again.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/e0b150a2/attachment.sig>

From mw_triad at users.sourceforge.net  Mon Jan 26 23:22:01 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 26 Jan 2009 17:22:01 -0600
Subject: Lack of update information
In-Reply-To: <gllaqq$qls$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<20090126195716.GA21250@hurricane.linuxnetz.de>
	<gllaqq$qls$1@ger.gmane.org>
Message-ID: <gllgiq$ghb$1@ger.gmane.org>

Kevin Kofler wrote:
> diff -Nur foo-old foo-new
> and you'll see fairly quickly what they fixed. (And it's also trivial for a
> cracker to do that, so it's utterly pointless to try withholding
> information that way.)

I disagree.

I recently fixed something that could be considered "denial of service" 
in a program I maintain. The patch basically replaces some instances of 
"foo=object; object.incrementRefCount();' with 'foo=object.clone();'. 
I'd challenge you to figure out from just that how to exploit the 
problem, whereas the bug report might contain a detailed description of 
what you had to do, how the timing has to work out, and exactly what 
effect would be seen.

There's a difference between having to engineer an exploit from the 
patch (especially if even the commit is vaguely worded), and having full 
documentation on the problem and its cause.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown



From kevin at scrye.com  Mon Jan 26 23:19:14 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Mon, 26 Jan 2009 16:19:14 -0700
Subject: Koji error
In-Reply-To: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
Message-ID: <20090126161914.77b72a8f@ohm.scrye.com>

On Mon, 26 Jan 2009 20:12:11 -0300
Allisson Azevedo <allisson at gmail.com> wrote:

> Hi,
> 
> I can't build perl-MooseX-Async, all branches return this error:

Wait a bit and try again. 

The job that syncs new package info over to koji only runs once an hour
or once every 30min. 

You managed to build it before it was synced.

> Regards,
> 
> Allisson.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/f0b42a86/attachment.sig>

From allisson at gmail.com  Mon Jan 26 23:27:25 2009
From: allisson at gmail.com (Allisson Azevedo)
Date: Mon, 26 Jan 2009 20:27:25 -0300
Subject: Koji error
In-Reply-To: <20090126161914.77b72a8f@ohm.scrye.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
	<20090126161914.77b72a8f@ohm.scrye.com>
Message-ID: <2c7834580901261527k472cbb70qd53d2db52a85900e@mail.gmail.com>

Hi,

Everything is fine now :)

Allisson.

2009/1/26 Kevin Fenzi <kevin at scrye.com>

> On Mon, 26 Jan 2009 20:12:11 -0300
> Allisson Azevedo <allisson at gmail.com> wrote:
>
> > Hi,
> >
> > I can't build perl-MooseX-Async, all branches return this error:
>
> Wait a bit and try again.
>
> The job that syncs new package info over to koji only runs once an hour
> or once every 30min.
>
> You managed to build it before it was synced.
>
> > Regards,
> >
> > Allisson.
>
> kevin
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/50894902/attachment.htm>

From mw_triad at users.sourceforge.net  Mon Jan 26 23:29:14 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 26 Jan 2009 17:29:14 -0600
Subject: Lack of update information
In-Reply-To: <497E1AE9.20606@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
Message-ID: <gllh0a$ha1$1@ger.gmane.org>

Rahul Sundaram wrote:
> Chris Weyl wrote:
>> It's hardly a "small additional cost", especially when looked at in
>> aggregate; this would be an additional non-automateable step required
>> for every update release that is of very questionable value/utility to
>> the vast majority of our users.  
> 
> I wouldn't say that. Currently it is of questionable value currently but 
> it would be much more valuable without just version bumping and more 
> careful thought put into justifying the need for updates. Every update 
> adds to a large cost in terms of build time, bandwidth, potential 
> regressions etc.

There are distros for people that feel that way. I don't think any of 
them are named "Fedora".

Then there are distros that believe in following upstream and shipping 
their bug-fixes and feature enhancements. I'm using my favorite one of 
those :-). Such distros, incidentally, are great for developers (/me 
waves) who need to follow upstream (due to dependencies, or just desire 
to watch upstream) but who need something more stable than rawhide.

Should we not release any updates without a Fedora bug being filed 
asking to upgrade to the latest upstream?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown



From jkeating at redhat.com  Mon Jan 26 23:48:34 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 15:48:34 -0800
Subject: Lack of update information
In-Reply-To: <gllh0a$ha1$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>  <gllh0a$ha1$1@ger.gmane.org>
Message-ID: <1233013714.8363.167.camel@localhost.localdomain>

On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>  
> Then there are distros that believe in following upstream and shipping 
> their bug-fixes and feature enhancements. I'm using my favorite one of 
> those :-). Such distros, incidentally, are great for developers (/me 
> waves) who need to follow upstream (due to dependencies, or just desire 
> to watch upstream) but who need something more stable than rawhide.

If everybody is just throwing the latest from upstream in whatever the
feel like it, what keeps a release from being more stable than rawhide?

> 
> Should we not release any updates without a Fedora bug being filed 
> asking to upgrade to the latest upstream?

That's actually not unreasonable.  The update process should be user
driven, as in a user needs or wants something specific from the new
upstream code, we don't just install a bot to throw whatever falls out
of upstream directly at our users whether they want/need it or not.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/b6771c65/attachment.sig>

From mw_triad at users.sourceforge.net  Tue Jan 27 00:05:03 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 26 Jan 2009 18:05:03 -0600
Subject: Lack of update information
In-Reply-To: <1233013714.8363.167.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
Message-ID: <gllj3h$nro$1@ger.gmane.org>

Jesse Keating wrote:
> If everybody is just throwing the latest from upstream in whatever the
> feel like it, what keeps a release from being more stable than rawhide?

Aside from upstream (hopefully) not being a mess, there is a difference 
between "this seems to work" and "what justification, besides that 
upstream has fixed bugs and added features, can I give to push this update"?

If a package seems to be non-broken and fixes bugs, that's good enough 
for me to update. (Of course, I'm also not in a limited-bandwidth 
situation, but...) Just because I haven't been bitten by a particular 
bug /yet/ doesn't make updating useless; maybe it saves me from being 
bit tomorrow.

Also, notice I didn't actually object to asking for better "what's 
changed" information. I objected to putting bureaucracy in the way of 
what Fedora currently is; a distro that tends to closely track upstream.

> On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>> Should we not release any updates without a Fedora bug being filed 
>> asking to upgrade to the latest upstream?
> 
> That's actually not unreasonable.  The update process should be user
> driven, as in a user needs or wants something specific from the new
> upstream code, we don't just install a bot to throw whatever falls out
> of upstream directly at our users whether they want/need it or not.

...except now I have to run around opening a ticket every time KDE bumps 
its requirement on CMake version, or libical version, or...

No, thanks.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown



From denis at poolshark.org  Tue Jan 27 00:07:24 2009
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 27 Jan 2009 01:07:24 +0100
Subject: Lack of update information
In-Reply-To: <497E1AE9.20606@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
Message-ID: <497E503C.8090400@poolshark.org>

Rahul Sundaram wrote:
> Chris Weyl wrote:
> 
>>
>> It's hardly a "small additional cost", especially when looked at in
>> aggregate; this would be an additional non-automateable step required
>> for every update release that is of very questionable value/utility to
>> the vast majority of our users.  
> 
> I wouldn't say that. Currently it is of questionable value currently but 
> it would be much more valuable without just version bumping and more 
> careful thought put into justifying the need for updates. Every update 
> adds to a large cost in terms of build time, bandwidth, potential 
> regressions etc.

I find it unreasonable to ask of package maintainers to take the role of 
technical writers. Anything beyond copy/pasting will widen the gap 
between packages maintained by native english speakers and packages that 
aren't. ChangeLog typically contains a large number of fairly detailed 
technical changes that has no place in the RPM spec log or in bodhi. i 
think it's unreasonable to ask anything more that a comment such as 'bug 
fix release' or 'introduces some new features'.

-denis



From jkeating at redhat.com  Tue Jan 27 00:07:45 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 16:07:45 -0800
Subject: Lack of update information
In-Reply-To: <gllj3h$nro$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<gllj3h$nro$1@ger.gmane.org>
Message-ID: <1233014865.8363.169.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:05 -0600, Matthew Woehlke wrote:
>  
> Aside from upstream (hopefully) not being a mess, there is a difference 
> between "this seems to work" and "what justification, besides that 
> upstream has fixed bugs and added features, can I give to push this update"?
> 
> If a package seems to be non-broken and fixes bugs, that's good enough 
> for me to update. (Of course, I'm also not in a limited-bandwidth 
> situation, but...) Just because I haven't been bitten by a particular 
> bug /yet/ doesn't make updating useless; maybe it saves me from being 
> bit tomorrow.
> 
> Also, notice I didn't actually object to asking for better "what's 
> changed" information. I objected to putting bureaucracy in the way of 
> what Fedora currently is; a distro that tends to closely track upstream.
> 
> > On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
> >> Should we not release any updates without a Fedora bug being filed 
> >> asking to upgrade to the latest upstream?
> > 
> > That's actually not unreasonable.  The update process should be user
> > driven, as in a user needs or wants something specific from the new
> > upstream code, we don't just install a bot to throw whatever falls out
> > of upstream directly at our users whether they want/need it or not.
> 
> ...except now I have to run around opening a ticket every time KDE bumps 
> its requirement on CMake version, or libical version, or...

But Fedora /releases/ aren't your personal rawhide.  We're providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before.  We
have a developmental stream for that, and it makes releases fairly
often.  I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/682e1ab2/attachment.sig>

From vonbrand at inf.utfsm.cl  Tue Jan 27 00:09:56 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 26 Jan 2009 21:09:56 -0300
Subject: Lack of update information
In-Reply-To: <497D776B.3020609@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<497D776B.3020609@fedoraproject.org>
Message-ID: <200901270009.n0R09ubk022043@laptop14.inf.utfsm.cl>

Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> Julian Sikorski wrote:
> > While I'm always trying to be precise in my update notes, I only
> > maintain a handful of packages. I can understand how putting verbose
> > update notes can be a daunting task. Also, what's the problem of going
> > to upstream website to check what changed in 2.16.2?

> Problem is finding out such information. It isn't easy at all for end
> users to do and sometimes doesn't exist in the upstream website. It
> would be very useful if package maintainers spend a little bit more
> time including more complete descriptions in the updates. Note that, I
> am referring here to description that is part of bodhi update and not
> the changelog which can be very brief.

The %changelog remains. I'd prefer a decent entry there, and copy that (by
default?) 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 vonbrand at inf.utfsm.cl  Tue Jan 27 00:13:57 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Mon, 26 Jan 2009 21:13:57 -0300
Subject: Lack of update information
In-Reply-To: <20090126120202.GA2548@free.fr>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
Message-ID: <200901270013.n0R0DvAh022080@laptop14.inf.utfsm.cl>

Patrice Dumas <pertusus at free.fr> wrote:

[...]

>                ... The only thing I see that could be made mandatory,
> would be to associate it with the fedora bugs that were solved by this 
> update.

It has happened more than one time to me that my bugs were fixed without
the packager noticing/being able to tell.
-- 
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 jkeating at redhat.com  Tue Jan 27 00:18:54 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 16:18:54 -0800
Subject: Lack of update information
In-Reply-To: <497E503C.8090400@poolshark.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>  <497E503C.8090400@poolshark.org>
Message-ID: <1233015534.8363.170.camel@localhost.localdomain>

On Tue, 2009-01-27 at 01:07 +0100, Denis Leroy wrote:
>  I find it unreasonable to ask of package maintainers to take the role of 
> technical writers. Anything beyond copy/pasting will widen the gap 
> between packages maintained by native english speakers and packages that 
> aren't. ChangeLog typically contains a large number of fairly detailed 
> technical changes that has no place in the RPM spec log or in bodhi. i 
> think it's unreasonable to ask anything more that a comment such as 'bug 
> fix release' or 'introduces some new features'.

Particularly in the case of updates-testing, if you want your users to
know what they're supposed to test for, you need to provide accurate
information about why you're putting this update out to test.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/7930b421/attachment.sig>

From rc040203 at freenet.de  Tue Jan 27 00:22:59 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Jan 2009 01:22:59 +0100
Subject: Lack of update information
In-Reply-To: <1233013714.8363.167.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
Message-ID: <497E53E3.1060302@freenet.de>

Jesse Keating wrote:
> On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>
>> Should we not release any updates without a Fedora bug being filed 
>> asking to upgrade to the latest upstream?
> 
> That's actually not unreasonable.  The update process should be user
> driven, as in a user needs or wants something specific from the new
> upstream code, we don't just install a bot to throw whatever falls out
> of upstream directly at our users whether they want/need it or not.

Reality is: In most cases, updates are upstream driven, because Fedora is
just a small subset of an upstream's user-base. Also upstreams typically 
happen to habe
the better insights in issue/bugs/defects a package might suffer from.

Therefore, if upstreams are doing a reasonable job (many do), keeping in 
close sync to upstream releases means "preventive bug fixing".

The problem with this: Users don't notice the cases in which upgrades 
"simply work" - They only notice the case, something already has gone wrong.

Ralf






From mw_triad at users.sourceforge.net  Tue Jan 27 00:32:48 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Mon, 26 Jan 2009 18:32:48 -0600
Subject: Lack of update information
In-Reply-To: <1233014865.8363.169.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>	<1233013714.8363.167.camel@localhost.localdomain>	<gllj3h$nro$1@ger.gmane.org>
	<1233014865.8363.169.camel@localhost.localdomain>
Message-ID: <gllknh$s0m$1@ger.gmane.org>

Jesse Keating wrote:
> On Mon, 2009-01-26 at 18:05 -0600, Matthew Woehlke wrote:
>>> On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
>>>> Should we not release any updates without a Fedora bug being filed 
>>>> asking to upgrade to the latest upstream?
>>> That's actually not unreasonable.  The update process should be user
>>> driven, as in a user needs or wants something specific from the new
>>> upstream code, we don't just install a bot to throw whatever falls out
>>> of upstream directly at our users whether they want/need it or not.
>> ...except now I have to run around opening a ticket every time KDE bumps 
>> its requirement on CMake version, or libical version, or...
> 
> But Fedora /releases/ aren't your personal rawhide.  We're providing
> releases that are supposed to stay somewhat stable, not to just be a
> dumping ground for whatever upstream chooses to drop the day before.  We
> have a developmental stream for that, and it makes releases fairly
> often.  I just don't understand why we want to treat our /release/
> branches as if they were just another rawhide.

Where did I say that? If you read what I said above, I said that 
releases should be for tested packages that the maintainer considers 
sand to push to a release. I also said that "sane to push to a release" 
should not mandate a bug report being filed.

The current update rate works well for me and has a lot to do with why I 
chose Fedora (particularly over RH, which I was using before, which is 
absolutely horrible at being out of date, and for which I had to either 
roll all sorts of packages by hand or else pull in half of Fedora 
anyway). Do you consider what we currently have to be no different from 
rawhide?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
find / -user your -name base -print0 | xargs -0 chown us:cats -- Unknown



From alsadi at gmail.com  Tue Jan 27 00:55:17 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 27 Jan 2009 02:55:17 +0200
Subject: telling gnome-package kit not use NetworkManager
In-Reply-To: <1232981927.5605.22.camel@localhost.localdomain>
References: <385866f0901260417n5560ef08n6218d0959474b7cb@mail.gmail.com>
	<1232981927.5605.22.camel@localhost.localdomain>
Message-ID: <385866f0901261655y6a137895o25bdbfcda40ae88f@mail.gmail.com>

thanks



From jkeating at redhat.com  Tue Jan 27 00:54:03 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 16:54:03 -0800
Subject: Lack of update information
In-Reply-To: <gllknh$s0m$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<gllj3h$nro$1@ger.gmane.org>
	<1233014865.8363.169.camel@localhost.localdomain>
	<gllknh$s0m$1@ger.gmane.org>
Message-ID: <1233017643.8363.181.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:32 -0600, Matthew Woehlke wrote:
>  
> The current update rate works well for me and has a lot to do with why I 
> chose Fedora (particularly over RH, which I was using before, which is 
> absolutely horrible at being out of date, and for which I had to either 
> roll all sorts of packages by hand or else pull in half of Fedora 
> anyway).

There is a big gap between RH(EL) which is extremely stable, new
releases every few years, and Fedora which has a new release out every 6
months.  There are also differences with what and why updates are
pushed, and how they are done.  Primarily RHEL fixes bugs by back
porting fixes to shipped releases to keep further stable, whereas in
Fedora we're free to pull in new upstream releases to fix bugs.   I'd
just prefer that we spend more time pulling things in when necessary,
rather than whenever we can.

>  Do you consider what we currently have to be no different from 
> rawhide?

I think the only thing keeping it from being like rawhide is the bodhi
hurdle.  If bodhi wasn't as much of a process as it is, I don't think
there would be much difference, except that for some key packages the
maintainers choose to not just do every new release everywhere, and tend
to treat our releases as just that, stable releases not to be trifled
with unless there is darn good reason.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/36bed411/attachment.sig>

From jkeating at redhat.com  Tue Jan 27 00:55:58 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Mon, 26 Jan 2009 16:55:58 -0800
Subject: Lack of update information
In-Reply-To: <497E53E3.1060302@freenet.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
Message-ID: <1233017758.8363.183.camel@localhost.localdomain>

On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>  The problem with this: Users don't notice the cases in which upgrades 
> "simply work" - They only notice the case, something already has gone wrong.

Many users notice a plethora of updates for unknown reasons that chew up
their bandwidth, cpu, and disk time while they're just trying to get
work done.  So much so that many opt out of applying updates at all,
because there are so many of them, which hurts our abilities to deliver
security updates.

People in bandwidth rich situations and with new expensive fast hardware
may not see a problem.  Those without certainly do.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090126/fb1d90b6/attachment.sig>

From alsadi at gmail.com  Tue Jan 27 00:58:24 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 27 Jan 2009 02:58:24 +0200
Subject: messages eat my harddisk because of alsa or pulse
In-Reply-To: <20090125225235.GA31415@tango.0pointer.de>
References: <385866f0901191817q3d5fac69x4c20d25503b9f99a@mail.gmail.com>
	<20090120031054.GA27902@tango.0pointer.de>
	<20090125221223.GA2347@mother.fordon.pl.eu.org>
	<20090125225235.GA31415@tango.0pointer.de>
Message-ID: <385866f0901261658r2b5612c0u35524c9bb5569551@mail.gmail.com>

Oh yes, it's mentioned in PA site that my card is ugly



From alsadi at gmail.com  Tue Jan 27 01:06:47 2009
From: alsadi at gmail.com (Muayyad AlSadi)
Date: Tue, 27 Jan 2009 03:06:47 +0200
Subject: haldaemon or devicekit for keyboard layout
Message-ID: <385866f0901261706h6006ad37ic3dde97521d4a19d@mail.gmail.com>

hi,

I was trying to compose an locale livcd based on fedora
I set the layout in in the .ks
but hal won't get them

as you know the layout is set by /usr/bin/fedora-setup-keyboard which
is called by /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi

I put some stubs in the script like
echo "1" >>$log

and it was not printed but if I go into runlevel 3 then restarted hal
it will be logged and when I change back to runlevel 5 the layout will
be working

so I added this braindamage to my .ks file
[ -f /var/cache/hald/fdi-cache ] && rm /var/cache/hald/fdi-cache &&
service haldaemon restart

to force hal to start again but this time it will set the layout

my question what is the reason for the early started haldaemon not
running /usr/bin/fedora-setup-keyboard
and will hal be responsible  for layout in F11 or it will be devicekit ?



From rc040203 at freenet.de  Tue Jan 27 02:11:46 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Jan 2009 03:11:46 +0100
Subject: Lack of update information
In-Reply-To: <1233017758.8363.183.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>	<1233013714.8363.167.camel@localhost.localdomain>	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
Message-ID: <497E6D62.4060708@freenet.de>

Jesse Keating wrote:
> On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>>  The problem with this: Users don't notice the cases in which upgrades 
>> "simply work" - They only notice the case, something already has gone wrong.
> 
> Many users notice a plethora of updates for unknown reasons that chew up
> their bandwidth, cpu, and disk time while they're just trying to get
> work done.  So much so that many opt out of applying updates at all,
> because there are so many of them, which hurts our abilities to deliver
> security updates.

These problems do not originate from the number of upgrades/update, they 
originate from the _size_ of updates few packages introduce.

> People in bandwidth rich situations 
Correct.

> and with new expensive fast hardware
> may not see a problem. 

Well, I would label this an urban legend - Updating recent Fedoras using 
yum has not been much of a performance problem, even on slower and older 
HW (e.g. a 1GHz i686/512MB)

Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be 
"really slow".

However, wrt. to bandwidth, I see another problem: Your strategy of 
pushing updates in "big batches", instead of "small chunks".

This makes a significant difference to users with limited bandwidth. 
While they could easily poll "small chunks", e.g. once a day (blocking 
their network for, e.g. 1 hour), the current strategy would block they 
network for very much longer (e.g. 7 hours).

Another aspect related to bandwidth: Revisiting
* the sizes of rpms (e.g. different payload compressors).
* differential updates/rpms.

Seems to me as if these once "hot topics" have dropped off the Fedora 
radar, in favor of "strangling/nagging the distro's contributors".

Ralf



From cweyl at alumni.drew.edu  Tue Jan 27 02:17:29 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 18:17:29 -0800
Subject: Lack of update information
In-Reply-To: <1233008041.8363.162.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<1233006941.8363.161.camel@localhost.localdomain>
	<7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>
	<1233008041.8363.162.camel@localhost.localdomain>
Message-ID: <7dd7ab490901261817p309c061dl98edbc9ec254ba4e@mail.gmail.com>

2009/1/26 Jesse Keating <jkeating at redhat.com>:
> On Mon, 2009-01-26 at 14:07 -0800, Chris Weyl wrote:
>>
>> And that's exactly what we are (or should be) doing; we just don't
>> write an essay about it afterwards :-)
>
> Did you actually read the link?
>
> * Package Maintainers should not push every single upstream update to
> all branches. Examine the changes in each upstream release and ask if
> the update is worth download and update time for many users. For
> upstreams that update very often with many small updates, consider
> waiting and updated only when the amount of changes is worth updating.

Yes, actually I did.  Perhaps I misunderstood your meaning here: are
you saying that it's policy in Fedora that a maintainer should not
keep their packages up to date in the best fashion that their
judgement suggests, in line with the above?

In any case, this is off-topic to the discussion; the question is
about imposing another manual task on a maintainer, rather than how
maintainers should exercise their judgement as to pushing updates
(which the above quote appears to address quite nicely).

                                      -Chris
-- 
Chris Weyl
Ex astris, scientia



From cweyl at alumni.drew.edu  Tue Jan 27 02:27:37 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 18:27:37 -0800
Subject: Lack of update information
In-Reply-To: <1233014865.8363.169.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<gllj3h$nro$1@ger.gmane.org>
	<1233014865.8363.169.camel@localhost.localdomain>
Message-ID: <7dd7ab490901261827icc0e7b6o9ed81df9c802882c@mail.gmail.com>

2009/1/26 Jesse Keating <jkeating at redhat.com>:
> But Fedora /releases/ aren't your personal rawhide.  We're providing
> releases that are supposed to stay somewhat stable, not to just be a
> dumping ground for whatever upstream chooses to drop the day before.  We
> have a developmental stream for that, and it makes releases fairly
> often.  I just don't understand why we want to treat our /release/
> branches as if they were just another rawhide.

I doubt anyone here intentionally treats a release in the same way
it's acceptable to beat up rawhide with.  There's a _huge_ difference
in sanely tracking upstream in a release and injecting potentially
massively unstable stuff in rawhide.

                                   -Chris
-- 
Chris Weyl
Ex astris, scientia



From lmacken at redhat.com  Tue Jan 27 02:29:10 2009
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 26 Jan 2009 21:29:10 -0500
Subject: Lack of update information
In-Reply-To: <1232989018.8363.143.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
Message-ID: <20090127022910.GQ5565@x300>

On Mon, Jan 26, 2009 at 08:56:58AM -0800, Jesse Keating wrote:
> On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
> > On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
> > > Rahul Sundaram pisze:
> > >> Hi,
> > >>
> > >> A while back, I tried to selectively update some packages and noticed
> > >> that the update information provided by package maintainers (seen via
> > >> PackageKit) is sorely lacking.
> > >>
> > >> * Update foo to upstream 2.16.2
> > >[..]
> > > Btw, how about pulling the data from spec %changelog automatically?
> > 
> > Well in most cases the changelog will just contain the same "update to x.y.z"
> > For some packages the changes just aren't  worth listing.
> > For example each iw release only contain minor changes, people that
> > really care about them know how to look it up.
> > I could also just add "Small fixes and minor updates from upstream"
> > but that's the same as "Update to x.y.z".
> > Copying the upstream changelog, that must people do not understand
> > does not help either.
> 
> If they're really such minor and uninteresting changes, why push them
> out to users?  Why consume infrastructure resources to build, releng
> resources to sign and push, bandwidth resources to mirror, bandwidth
> resources and cpu resources on the clients to consume the metadata, and
> cpu / disk resources on the clients to do the update?

All good questions.

> If you don't have anything interesting to say about the update, maybe
> you shouldn't be pushing the update at all.

Not only is 'Update foo to upstream 2.16.2' pointless, but that text
lives in both bodhi and koji's databases, the updateinfo.xml in our
repodata, mailing lists, CVS commit logs, and RPM changelogs...

luke



From cweyl at alumni.drew.edu  Tue Jan 27 02:47:02 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Mon, 26 Jan 2009 18:47:02 -0800
Subject: Lack of update information
In-Reply-To: <20090127022910.GQ5565@x300>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
Message-ID: <7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>

On Mon, Jan 26, 2009 at 6:29 PM, Luke Macken <lmacken at redhat.com> wrote:
> On Mon, Jan 26, 2009 at 08:56:58AM -0800, Jesse Keating wrote:
>> If they're really such minor and uninteresting changes, why push them
>> out to users?  Why consume infrastructure resources to build, releng
>> resources to sign and push, bandwidth resources to mirror, bandwidth
>> resources and cpu resources on the clients to consume the metadata, and
>> cpu / disk resources on the clients to do the update?
>
> All good questions.

And all obviated by Fedora policy and practice: we expressly give and
expect maintainers to exercise their judgement here.

Unless, of course, we need a Committee of Update Oversight set up...?
Maybe a new set of highly detailed guidelines, detailing when and how
updates are to be blessed and released to the great unwashed, or cast
asunder?

                             -Chris
-- 
Chris Weyl
Ex astris, scientia



From fedora at leemhuis.info  Tue Jan 27 05:41:02 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 27 Jan 2009 06:41:02 +0100
Subject: wiki structure policy
In-Reply-To: <20090126213509.GB26008@gmail.com>
References: <20090126053057.GA1630@gmail.com> <497D4DF7.4040704@leemhuis.info>
	<20090126213509.GB26008@gmail.com>
Message-ID: <497E9E6E.4020401@leemhuis.info>

On 26.01.2009 22:35, Ian Weller wrote:
> On Mon, Jan 26, 2009 at 06:45:27AM +0100, Thorsten Leemhuis wrote:
>> On 26.01.2009 06:30, Ian Weller wrote:
>>>
>>> Wiki tip of the week for Jan 26 2009: Moving pages with ease
>>> ============================================================
>>>
>>> With the new page naming and wiki structure policy[1] in place, [...]
>>> [1]: https://fedoraproject.org/wiki/Help:Wiki_structure
>> One question regarding that wiki structure policy: How can I watch a  
>> certain set of wiki pages closely? In the past I simply read the rss  
>> feed with rss2email and looked out for pages that started with EPEL/,  
>> Packaging/ or Feature/ (for example) and ignored the others. That  
>> doesn't work anymore, thus I'm looking for a alternative.
> I'm working on something that will allow you to watch pages by category.
> Until then, hitting the [watch] tab at the top of each page is your best
> bet, unfortunately.

That doesn't catch new pages and makes the whole concept mostly useless 
for me. And wasn't it mediawiki that has this imho broken watch feature 
where you don't get a diffs by mail? And the one where you have to click 
on links in each of the mails to make sure you get change notification 
in the future as well?

What would make things work for me is: Add the Category to the rss feed 
subject in the first place (e.g. before the page title). Would that be 
possible without to much work? Ideally the author would be in there 
somewhere (last field), too.

CU
knurd



From tagoh at redhat.com  Tue Jan 27 06:04:12 2009
From: tagoh at redhat.com (Akira TAGOH)
Date: Tue, 27 Jan 2009 15:04:12 +0900 (JST)
Subject: Call for Ruby package maintainer
Message-ID: <20090127.150412.1090654878994195729.tagoh@redhat.com>


Hi,

I'm still trying to have a time to work on our ruby package,
but failing so far. so I'm considering to find any good
person out to work on that to make it better. I could work
together as co-maintainer though, please let me know if
anyone is interested in and can actively maintain.

TIA,
--
Akira TAGOH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/9ffac8b1/attachment.sig>

From markmc at redhat.com  Tue Jan 27 08:10:50 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Tue, 27 Jan 2009 08:10:50 +0000
Subject: Lack of update information
In-Reply-To: <1233014865.8363.169.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<gllj3h$nro$1@ger.gmane.org>
	<1233014865.8363.169.camel@localhost.localdomain>
Message-ID: <1233043850.4789.20.camel@blaa>

On Mon, 2009-01-26 at 16:07 -0800, Jesse Keating wrote:

>  But Fedora /releases/ aren't your personal rawhide.  We're providing
> releases that are supposed to stay somewhat stable, not to just be a
> dumping ground for whatever upstream chooses to drop the day before.  We
> have a developmental stream for that, and it makes releases fairly
> often.  I just don't understand why we want to treat our /release/
> branches as if they were just another rawhide.

Agree completely.

Another worrying sentiment I heard lately was that it makes sense to
push a new, untested upstream release into updates-testing so that it
actually gets testing because "no-one runs rawhide".

The idea being that if you disable the bodhi-karma-auto-push thing, then
it won't hit updates until all the wrinkles have been ironed out.

To me that's just wrong - if someone enables updates-testing, they
shouldn't be immediately exposed to new upstream release. IMHO, the
process should be:

  a) push to rawhide and let stew

  b) if there's some serious bug fix or important user feature requested
     that can't be trivially backported, then push to updates-testing

  c) push to updates

Cheers,
Mark.



From rawhide at fedoraproject.org  Tue Jan 27 08:20:33 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Tue, 27 Jan 2009 08:20:33 +0000 (UTC)
Subject: rawhide report: 20090127 changes
Message-ID: <20090127082033.229001B8001@releng2.fedora.phx.redhat.com>

Compose started at Tue Jan 27 06:01:02 UTC 2009

Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	4:netatalk-timeout-2.0.3-24.fc11.i386 requires netatalk = 0:2.0.3-24.fc11
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::SCF)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::Graphics::Browser::Util)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	4:netatalk-timeout-2.0.3-24.fc11.x86_64 requires netatalk = 0:2.0.3-24.fc11
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::SCF)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::Graphics::Browser::Util)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.x86_64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	4:netatalk-timeout-2.0.3-24.fc11.ppc requires netatalk = 0:2.0.3-24.fc11
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::SCF)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::Graphics::Browser::Util)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.ppc requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	eclipse-linuxprofilingframework-0.1.0-0.1.fc11.noarch requires eclipse-cdt >= 1:4.0.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	4:netatalk-timeout-2.0.3-24.fc11.ppc64 requires netatalk = 0:2.0.3-24.fc11
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::SCF)
	perl-Bio-Graphics-1.83-2.fc11.noarch requires perl(Bio::Graphics::Browser::Util)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From dan at danny.cz  Tue Jan 27 08:39:21 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 27 Jan 2009 09:39:21 +0100
Subject: how to show upstream changes to the user
Message-ID: <1233045561.3687.37.camel@eagle.danny.cz>

Both sides in the "Lack if update information" thread are true. The
presented information about changes is almost useless for the user, but
rewriting the upstream changelogs into bodhi is a superfluous burden for
the maintainers. There is, in my opinion, a technical solution for this
issue that can make both sides happy.

And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
upstream changelog and GUI package management tools can open a browser
window to show the content, like they do for the home page.

pros:
- low overhead for maintainer
- can provide complete info to the user even when he/she skips some
updates
- allows changelogs per sub-package

cons:
- slightly larger metadata


		Dan




From sundaram at fedoraproject.org  Tue Jan 27 08:42:13 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 14:12:13 +0530
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
Message-ID: <497EC8E5.3000607@fedoraproject.org>

Chris Weyl wrote:

> 
> None of these "goals" will be helped by imposing a barely related new
> manual process requirement that you concede is "[c]ertainly of
> questionable value".

You aren't reading what I said. I said, the updates aren't useful 
without even a short sentence about what it is required.

> I suspect those on low-bandwidth connections would be better served by presto.

Presto works for some use cases but not others and is cpu intensive as 
well.

> Not to be blunt, but "too bad".  That's why we're called
> "maintainers", and they are "end users".  

Maintainers are supposed to serve and meet end user needs and not the 
other way around.

If "updating to 1.2.3" isn't
> good enough, and someone really wants to know what's going on with the
> package, then they should read upstream's changelog.  That's what it's
> there for, and why we incorporate it by reference.

Many maintainers don't and sometimes there is no proper upstream 
changelog to refer to. This is why, ultimately it is the maintainer's 
responsibility to summarize the need for an update. As I said earlier, 
upstream changelog would have no knowledge on Fedora downstream bugs, 
backported patches etc.

Rahul



From tim at niemueller.de  Tue Jan 27 08:49:07 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Tue, 27 Jan 2009 09:49:07 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <1233045561.3687.37.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
Message-ID: <497ECA83.90709@niemueller.de>

Dan Hor?k schrieb:
> Both sides in the "Lack if update information" thread are true. The
> presented information about changes is almost useless for the user, but
> rewriting the upstream changelogs into bodhi is a superfluous burden for
> the maintainers. There is, in my opinion, a technical solution for this
> issue that can make both sides happy.
> 
> And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> upstream changelog and GUI package management tools can open a browser
> window to show the content, like they do for the home page.

Ideally changelogs could be RSS/atom feeds which can easily be parsed
and shown in packagekit. Packagekit (or Bodhi for that matter) could try
to download the feed and if it has the correct MIME type and formatting
extract the version's changelog.

The title of the feed should be something like "<package name>
<version>" so that Bodhi could extract the correct version. All this
would take is kind of a blog category/tag that produces only the version
information, since this is only using standard technologies most people
will not need to do much besides actually creating the entries. Maybe
bigger sites like sourceforge will pick up this idea and provide such
information automagically for hosted projects.

What this takes is package maintainers asking upstream to provide such a
feed. Alternatively we could write a few scripts that are able to parse
the most common ChangeLog formats and produce the feed from that.

I'm aware this is a huge task, but it would be useful, streamline the
workflow for upstream->downstream communication, and give more info to
users that really want it (I do, just thought about the Bash 4.0rc1
thread with missing changelog info, the only way to read being to
download the tarball).

Just thinking into the wild here,
	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From sundaram at fedoraproject.org  Tue Jan 27 09:00:20 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 14:30:20 +0530
Subject: Lack of update information
In-Reply-To: <497E503C.8090400@poolshark.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<497E503C.8090400@poolshark.org>
Message-ID: <497ECD24.5080905@fedoraproject.org>

Denis Leroy wrote:

> I find it unreasonable to ask of package maintainers to take the role of 
> technical writers. Anything beyond copy/pasting will widen the gap 
> between packages maintained by native english speakers and packages that 
> aren't. ChangeLog typically contains a large number of fairly detailed 
> technical changes that has no place in the RPM spec log or in bodhi. i 
> think it's unreasonable to ask anything more that a comment such as 'bug 
> fix release' or 'introduces some new features'.

Adding a reference and a sentence or two does not need any technical 
writer. Besides, being a technical writer isn't that hard. I was one for 
a while.

Rahul



From nicolas.mailhot at laposte.net  Tue Jan 27 09:03:50 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Jan 2009 10:03:50 +0100 (CET)
Subject: wiki structure policy
In-Reply-To: <497E9E6E.4020401@leemhuis.info>
References: <20090126053057.GA1630@gmail.com>
	<497D4DF7.4040704@leemhuis.info> <20090126213509.GB26008@gmail.com>
	<497E9E6E.4020401@leemhuis.info>
Message-ID: <c874407447eded8fc577596c61a2e9f9.squirrel@arekh.dyndns.org>



Le Mar 27 janvier 2009 06:41, Thorsten Leemhuis a ?crit :

> What would make things work for me is: Add the Category to the rss
> feed subject in the first place

There are various tickets in infra track asking to install the various
mediawiki extensions that claim to support watching/indexing/feeding
of categories.

Though, most of them do not seem to do "category and sub-categories".
Which is what's actually needed if you don't want to maintain a copy
of the subcategory tree on all the client sides.

-- 
Nicolas Mailhot



From sundaram at fedoraproject.org  Tue Jan 27 09:06:09 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 14:36:09 +0530
Subject: how to show upstream changes to the user
In-Reply-To: <1233045561.3687.37.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
Message-ID: <497ECE81.1020801@fedoraproject.org>

Dan Hor?k wrote:
> Both sides in the "Lack if update information" thread are true. The
> presented information about changes is almost useless for the user, but
> rewriting the upstream changelogs into bodhi is a superfluous burden for
> the maintainers. There is, in my opinion, a technical solution for this
> issue that can make both sides happy.

I didn't ask for upstream changelogs to be rewritten within bodhi. If 
there is a upstream changelog, just adding a reference would be very 
helpful. If that can be automated, that's great.

> And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> upstream changelog and GUI package management tools can open a browser
> window to show the content, like they do for the home page.

This might solve part of the problem. It doesn't solve the problem where 
downstream bugs are not referred to or closed for example. The thing is 
that this process requires human intelligence and cannot be completely 
automated in all cases.

Rahul



From kevin.kofler at chello.at  Tue Jan 27 09:08:11 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 27 Jan 2009 10:08:11 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
	<7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
Message-ID: <glmitr$uvt$1@ger.gmane.org>

Chris Weyl wrote:
> And all obviated by Fedora policy and practice: we expressly give and
> expect maintainers to exercise their judgement here.

Yes, we let maintainers decide when to push updates, and that's a good
thing. But is it really so hard to write one or two sentences explaining
why your decided that way and what other changes to expect? For me it was
always just a matter of seconds for the updates I submitted. Some users
(like me) want to know what they're getting in an update. I still end up
installing them all unless something is known broken, but that doesn't mean
I don't want to know what I'm getting.

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan 27 09:16:09 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 27 Jan 2009 10:16:09 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
Message-ID: <glmjcp$uvt$2@ger.gmane.org>

Jesse Keating wrote:
> People in bandwidth rich situations and with new expensive fast hardware
> may not see a problem.  Those without certainly do.

Those who do not have the bandwidth to pull Fedora updates shouldn't be
running Fedora. There are plenty of distros with few updates which would be
a lot more suitable for people with slow Internet connections.

IMHO we should add "broadband Internet connection" to Fedora's system
requirements and list it prominently on the download page.

That said, Presto would certainly help a lot there. Too bad it's still not
officially supported. :-(

        Kevin Kofler



From kevin.kofler at chello.at  Tue Jan 27 09:20:27 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Tue, 27 Jan 2009 10:20:27 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
Message-ID: <glmjkr$uvt$3@ger.gmane.org>

Denis Leroy wrote:
> I find it unreasonable to ask of package maintainers to take the role of
> technical writers.

Oh come on, writing a couple of sentences to explain what's new and why it's
being pushed doesn't need a technical writer at all.

> Anything beyond copy/pasting will widen the gap between packages
> maintained by native english speakers and packages that aren't.

Your English is just fine. Why are the ones who speak practically perfect
English (Nicolas Mailhot and you so far) the ones who complain about
this? ;-)

> ChangeLog typically contains a large number of fairly detailed technical
> changes that has no place in the RPM spec log or in bodhi.

That's clear. But that's why it would be nice to summarize it. In those
cases where it really can't be done, a link (URL) to the upstream changelog
is easy to add.

> i think it's unreasonable to ask anything more that a comment such
> as 'bug fix release' or 'introduces some new features'.

I don't.

        Kevin Kofler



From nicolas.mailhot at laposte.net  Tue Jan 27 09:47:01 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Jan 2009 10:47:01 +0100 (CET)
Subject: Lack of update information
In-Reply-To: <glmjkr$uvt$3@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>
Message-ID: <55317f8f412c6f53bf7f862189311213.squirrel@arekh.dyndns.org>



Le Mar 27 janvier 2009 10:20, Kevin Kofler a ?crit :

>> Anything beyond copy/pasting will widen the gap between packages
>> maintained by native english speakers and packages that aren't.
>
> Your English is just fine. Why are the ones who speak practically
> perfect
> English (Nicolas Mailhot and you so far) the ones who complain about
> this? ;-)

Because the others do not have the necessary English skills to parse
or participate in a complex fedora-devel debate.

That does not mean they can't and do not do good packaging, as long as
they're not asked to write English essays. (not that I disagree with
Jesse's point people are too hasty to push updates Bodhi-side, but
this is not the correct way to stem the tide).

Again, the value of this information is limited at best and only
concerns a very small user minority that both speaks English and
understands technical jargon (ie, not a lot of people). Even those who
have some grasp of English would usually not be able to parse it!

The typical writing you Rahul asks of, even if it was perfectly filed,
would be as useful to our average user as:

? Corrig? le fripouillard qui perturbait l'ordonnancement des travaux
de mise ? jour du schmilblick (inversion de priorit? dans le zorglub)
?

ie something that vaguely mimics a foreign language taught as school
with enough jargon and arcane references to be totally unparsable.

-- 
Nicolas Mailhot



From dan at danny.cz  Tue Jan 27 10:23:57 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 27 Jan 2009 11:23:57 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <497ECE81.1020801@fedoraproject.org>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<497ECE81.1020801@fedoraproject.org>
Message-ID: <1233051837.3687.59.camel@eagle.danny.cz>

Rahul Sundaram p??e v ?t 27. 01. 2009 v 14:36 +0530:
> Dan Hor?k wrote:
> > Both sides in the "Lack if update information" thread are true. The
> > presented information about changes is almost useless for the user, but
> > rewriting the upstream changelogs into bodhi is a superfluous burden for
> > the maintainers. There is, in my opinion, a technical solution for this
> > issue that can make both sides happy.
> 
> I didn't ask for upstream changelogs to be rewritten within bodhi. If 
> there is a upstream changelog, just adding a reference would be very 
> helpful. If that can be automated, that's great.
> 
> > And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> > upstream changelog and GUI package management tools can open a browser
> > window to show the content, like they do for the home page.
> 
> This might solve part of the problem. It doesn't solve the problem where 
> downstream bugs are not referred to or closed for example. The thing is 
> that this process requires human intelligence and cannot be completely 
> automated in all cases.

There is some support in Makefile.common to transfer bug numbers from
package changelog to bodhi.


		Dan




From pmatilai at laiskiainen.org  Tue Jan 27 10:28:10 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Jan 2009 12:28:10 +0200 (EET)
Subject: how to show upstream changes to the user
In-Reply-To: <1233045561.3687.37.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
Message-ID: <alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>

On Tue, 27 Jan 2009, Dan Hor?k wrote:

> Both sides in the "Lack if update information" thread are true. The
> presented information about changes is almost useless for the user, but
> rewriting the upstream changelogs into bodhi is a superfluous burden for
> the maintainers. There is, in my opinion, a technical solution for this
> issue that can make both sides happy.
>
> And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> upstream changelog and GUI package management tools can open a browser
> window to show the content, like they do for the home page.
>
> pros:
> - low overhead for maintainer
> - can provide complete info to the user even when he/she skips some
> updates
> - allows changelogs per sub-package
>
> cons:
> - slightly larger metadata

cons continued:
- It introduces a spec incompatibility, which can be taken care of in
   Fedora land but not so easy for EPEL side of things. Dunno if our
   buildsys ever does anything with the rpmbuild of the host system
   (I seem to recall it doing some part there but could easily be wrong),
   IF so this is pretty much a no-go.

Would be trivial to add, sure. The question is, would it make any 
difference to either
a) asking packagers to add pointer to existing %changelog when rebasing
    packages
b) have such a field in bodhi instead

 	- Panu -



From kraxel at redhat.com  Tue Jan 27 10:57:24 2009
From: kraxel at redhat.com (Gerd Hoffmann)
Date: Tue, 27 Jan 2009 11:57:24 +0100
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <497E241D.3050801@cchtml.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126124520.GA2381@yoda.jdub.homelinux.org>	<20090126131209.GG5690@tyan-ft48-01.lab.bos.redhat.com>	<20090126131852.GB2381@yoda.jdub.homelinux.org>	<20090126133517.GH5690@tyan-ft48-01.lab.bos.redhat.com>	<497E1F8F.4050203@redhat.com>
	<497E241D.3050801@cchtml.com>
Message-ID: <497EE894.8050903@redhat.com>

Michael Cronenworth wrote:
> -------- Original Message --------
> Subject: Re: Default ISA/tuning flags for GCC, --enable-kernel= level
> for glibc
> From: Gerd Hoffmann <kraxel at redhat.com>
> To: Jakub Jelinek <jakub at redhat.com>, Development discussions related to
> Fedora <fedora-devel-list at redhat.com>
> CC: Jesse Keating <jkeating at redhat.com>, Tom Callaway
> <tcallawa at redhat.com>, Bill Nottingham <notting at redhat.com>, Ulrich
> Drepper <drepper at redhat.com>
> Date: 01/26/2009 02:39 PM
>>
>> Can we *please* wait a bit until raising the bar *that* high?  Breaking
>> mock builds for rawhide on F9/10 releases is a really bad idea IMHO.
>> Which meas supporting at least 2.6.27.  Maybe in a year when F9 is EOL
>> and F10 has a 2.6.29 kernel update we can reconsider 2.6.29.
>>
>> cheers,
>>   Gerd

> So when 2010 rolls around you'll be saying "pleaseeeee wait until F12
> has reached EOL"?

The point is that IMHO the rawhide glibc must be able to work with any
kernel in a supported Fedora release.  Needed for upgrades and mock
builds.  Which means 2.6.27 at this point in time.

There is also RHEL-5 aka 2.6.18.  I doubt anyone does serious Fedora
development on a RHEL-5 machine (due to increasing gap in package
versions and features between el5+rawhide), so I'm not sure how much
pain it would bring to people if the rawhide glibc stops working on RHEL-5.

> The pain has to occur sometime.

No.  We just can't make the huge jump from .9 to .29.  We have to do it
smaller steps, considering kernel versions at least in supported Fedora
versions, maybe also latest RHEL.

> How about rolling up to 2.6.18 right now? That shouldn't hurt anything,
> should it?

2.6.18 should be fine.

> Make 2.6.29 a Fedora 12 priority. This shouldn't go against what you
> requested.

Should work when we care about Fedora only.  When also requiring latest
RHEL I'd suspect it will more likely be Fedora 13 because we'll have to
wait for RHEL-6 being out there to jump from .18 to .29.

cheers,
  Gerd



From dan at danny.cz  Tue Jan 27 11:04:33 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 27 Jan 2009 12:04:33 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
Message-ID: <1233054273.3687.76.camel@eagle.danny.cz>

Panu Matilainen p??e v ?t 27. 01. 2009 v 12:28 +0200:
> On Tue, 27 Jan 2009, Dan Hor?k wrote:
> 
> > Both sides in the "Lack if update information" thread are true. The
> > presented information about changes is almost useless for the user, but
> > rewriting the upstream changelogs into bodhi is a superfluous burden for
> > the maintainers. There is, in my opinion, a technical solution for this
> > issue that can make both sides happy.
> >
> > And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
> > upstream changelog and GUI package management tools can open a browser
> > window to show the content, like they do for the home page.
> >
> > pros:
> > - low overhead for maintainer
> > - can provide complete info to the user even when he/she skips some
> > updates
> > - allows changelogs per sub-package
> >
> > cons:
> > - slightly larger metadata
> 
> cons continued:
> - It introduces a spec incompatibility, which can be taken care of in
>    Fedora land but not so easy for EPEL side of things. Dunno if our
>    buildsys ever does anything with the rpmbuild of the host system
>    (I seem to recall it doing some part there but could easily be wrong),
>    IF so this is pretty much a no-go.

I can't comment the buildsys issues, but it can be useful to break the
compatibility (in one direction only) now and then.

> 
> Would be trivial to add, sure. The question is, would it make any 
> difference to either
> a) asking packagers to add pointer to existing %changelog when rebasing
>     packages

There is a chance that the changelog attached in the source archive is
developer oriented (based on CVS/SVN/whatever) while the web-based one
is user oriented.

> b) have such a field in bodhi instead

The keyword should be "automation". Why to copy&paste when it can be
done by script. I can imagine a "hidden" field in spec (special comment
like #changelog: http://....) that is transformed into a field in bodhi.
It can be a macro in spec that gets evaluated before including in bodhi,
etc.


		Dan




From sundaram at fedoraproject.org  Tue Jan 27 11:19:17 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 16:49:17 +0530
Subject: how to show upstream changes to the user
In-Reply-To: <1233051837.3687.59.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>	<497ECE81.1020801@fedoraproject.org>
	<1233051837.3687.59.camel@eagle.danny.cz>
Message-ID: <497EEDB5.1060902@fedoraproject.org>

Dan Hor?k wrote:

> There is some support in Makefile.common to transfer bug numbers from
> package changelog to bodhi.

Yes but the package maintainers have to fill in the bug numbers 
manually. Whether it is done via changelog or bodhi doesn't matter much 
as long as end users have that information available to them *before* 
doing an update.

Rahul



From peter.hutterer at who-t.net  Tue Jan 27 12:03:37 2009
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Tue, 27 Jan 2009 22:03:37 +1000
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
	<68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
	<68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
Message-ID: <20090127120337.GB7569@who-t.net>

On Sun, Jan 25, 2009 at 02:59:56PM -0200, Paulo Cavalcanti wrote:
> Well, I finished and I included a hal rule for loading wizardpen in xorg
> 1.5.3
> 
> The spec file is here:
> 
> http://people.atrpms.net/~pcavalcanti/specs/wizardpen.spec
> 
> Do you think that would be any interest in having wizardpen in Fedora?

our current long-term approach is to get support for input devices into the
kernel and then let evdev deal with it automagically*. The times when X needed
a separate driver for each device are gone and the sooner we forget about it,
the happier we'll be.

Cheers,
  Peter

* doesn't work with all devices yet, but evdev is moving fast and is easy
enough to hack on.



From pmatilai at laiskiainen.org  Tue Jan 27 12:05:31 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Tue, 27 Jan 2009 14:05:31 +0200 (EET)
Subject: how to show upstream changes to the user
In-Reply-To: <1233054273.3687.76.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
Message-ID: <alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>

On Tue, 27 Jan 2009, Dan Hor?k wrote:

> Panu Matilainen p??e v ?t 27. 01. 2009 v 12:28 +0200:
>> On Tue, 27 Jan 2009, Dan Hor?k wrote:
>>
>>> Both sides in the "Lack if update information" thread are true. The
>>> presented information about changes is almost useless for the user, but
>>> rewriting the upstream changelogs into bodhi is a superfluous burden for
>>> the maintainers. There is, in my opinion, a technical solution for this
>>> issue that can make both sides happy.
>>>
>>> And it is new "ChangeLog" tag in RPM. It should be an URL pointing to
>>> upstream changelog and GUI package management tools can open a browser
>>> window to show the content, like they do for the home page.
>>>
>>> pros:
>>> - low overhead for maintainer
>>> - can provide complete info to the user even when he/she skips some
>>> updates
>>> - allows changelogs per sub-package
>>>
>>> cons:
>>> - slightly larger metadata
>>
>> cons continued:
>> - It introduces a spec incompatibility, which can be taken care of in
>>    Fedora land but not so easy for EPEL side of things. Dunno if our
>>    buildsys ever does anything with the rpmbuild of the host system
>>    (I seem to recall it doing some part there but could easily be wrong),
>>    IF so this is pretty much a no-go.
>
> I can't comment the buildsys issues, but it can be useful to break the
> compatibility (in one direction only) now and then.

To keep people on their toes, yes :) Part of the problem is that rpm has 
remained compatible for so long people simply take it for granted and 
whenever something new is suggested, bunch of folks goes wild over "but 
you cant do that it breaks compatibility to RHEL 3" or whatever.

>>
>> Would be trivial to add, sure. The question is, would it make any
>> difference to either
>> a) asking packagers to add pointer to existing %changelog when rebasing
>>     packages
>
> There is a chance that the changelog attached in the source archive is
> developer oriented (based on CVS/SVN/whatever) while the web-based one
> is user oriented.

I sense a misunderstanding here... what I meant is instead of just 
the "update to x.y.z", drop in a link too - simply something like 
(taking sqlite has an example):

* Thu Jan 22 2009 Panu Matilainen <pmatilai at redhat.com> - 3.6.10-1
- update to 3.6.10 (http://www.sqlite.org/releaselog/3_6_10.html)

Having something like that in the existing changelog would mean it's also 
trivial to browse back in history, whereas a single tag would only point 
to the current release.

>> b) have such a field in bodhi instead
>
> The keyword should be "automation". Why to copy&paste when it can be
> done by script. I can imagine a "hidden" field in spec (special comment
> like #changelog: http://....) that is transformed into a field in bodhi.
> It can be a macro in spec that gets evaluated before including in bodhi,
> etc.

If such a thing is in the package, obviously it should be pulled 
automatically by bodhi. You almost certainly need to copy-paste the link 
once anyway - if the field only exists in bodhi then there's just one 
copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
possibilities :)

 	- Panu -



From promac at gmail.com  Tue Jan 27 12:34:47 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Tue, 27 Jan 2009 10:34:47 -0200
Subject: xorg.conf - what to do for an input device
In-Reply-To: <20090127120337.GB7569@who-t.net>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
	<68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
	<68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
	<20090127120337.GB7569@who-t.net>
Message-ID: <68720af30901270434x77514343k7cafcad425092e78@mail.gmail.com>

On Tue, Jan 27, 2009 at 10:03 AM, Peter Hutterer
<peter.hutterer at who-t.net>wrote:

> On Sun, Jan 25, 2009 at 02:59:56PM -0200, Paulo Cavalcanti wrote:
> > Well, I finished and I included a hal rule for loading wizardpen in xorg
> > 1.5.3
> >
> > The spec file is here:
> >
> > http://people.atrpms.net/~pcavalcanti/specs/wizardpen.spec<http://people.atrpms.net/%7Epcavalcanti/specs/wizardpen.spec>
> >
> > Do you think that would be any interest in having wizardpen in Fedora?
>
> our current long-term approach is to get support for input devices into the
> kernel and then let evdev deal with it automagically*. The times when X
> needed
> a separate driver for each device are gone and the sooner we forget about
> it,
> the happier we'll be.
>
> Cheers,
>  Peter
>
> * doesn't work with all devices yet, but evdev is moving fast and is easy
> enough to hack on.
>


evdev used to be easier, but it is not accepting the device identification
by name anymore. One has to use /dev/input/by-id/ or /dev/input/by-path.
And what about bluetooth devices? Would you know where can I get
its identification?

Thanks.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/9436f790/attachment.htm>

From dan at danny.cz  Tue Jan 27 12:57:34 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 27 Jan 2009 13:57:34 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>
Message-ID: <1233061054.3687.98.camel@eagle.danny.cz>

Panu Matilainen p??e v ?t 27. 01. 2009 v 14:05 +0200:
> On Tue, 27 Jan 2009, Dan Hor?k wrote:
> >> Would be trivial to add, sure. The question is, would it make any
> >> difference to either
> >> a) asking packagers to add pointer to existing %changelog when rebasing
> >>     packages
> >
> > There is a chance that the changelog attached in the source archive is
> > developer oriented (based on CVS/SVN/whatever) while the web-based one
> > is user oriented.
> 
> I sense a misunderstanding here... what I meant is instead of just 
> the "update to x.y.z", drop in a link too - simply something like 
> (taking sqlite has an example):
> 
> * Thu Jan 22 2009 Panu Matilainen <pmatilai at redhat.com> - 3.6.10-1
> - update to 3.6.10 (http://www.sqlite.org/releaselog/3_6_10.html)
> 
> Having something like that in the existing changelog would mean it's also 
> trivial to browse back in history, whereas a single tag would only point 
> to the current release.
> 

Yes, there was a misunderstanding and your idea looks good.

> >> b) have such a field in bodhi instead
> >
> > The keyword should be "automation". Why to copy&paste when it can be
> > done by script. I can imagine a "hidden" field in spec (special comment
> > like #changelog: http://....) that is transformed into a field in bodhi.
> > It can be a macro in spec that gets evaluated before including in bodhi,
> > etc.
> 
> If such a thing is in the package, obviously it should be pulled 
> automatically by bodhi. You almost certainly need to copy-paste the link 
> once anyway - if the field only exists in bodhi then there's just one 
> copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
> possibilities :)

I am looking for possibilities too, so there is chance we will meet
somewhere :-)


		Dan




From mschwendt at gmail.com  Tue Jan 27 13:12:27 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 27 Jan 2009 14:12:27 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <1233061054.3687.98.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>
	<1233061054.3687.98.camel@eagle.danny.cz>
Message-ID: <20090127141227.9eff6c85.mschwendt@gmail.com>

On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:

> > >> b) have such a field in bodhi instead
> > >
> > > The keyword should be "automation". Why to copy&paste when it can be
> > > done by script. I can imagine a "hidden" field in spec (special comment
> > > like #changelog: http://....) that is transformed into a field in bodhi.
> > > It can be a macro in spec that gets evaluated before including in bodhi,
> > > etc.
> > 
> > If such a thing is in the package, obviously it should be pulled 
> > automatically by bodhi. You almost certainly need to copy-paste the link 
> > once anyway - if the field only exists in bodhi then there's just one 
> > copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
> > possibilities :)
> 
> I am looking for possibilities too, so there is chance we will meet
> somewhere :-)

So far it smells like needless bureaucracy, which you try to advertise as
"low overhead for maintainers". Only few maintainers would be interested
in hunting for URLs of changelog web pages for minor/major releases. The
benefit would be small. Users of open source software packages, which are
sceptical of updates/upgrades, ought to fetch the source packages and take
a look at the documentation files in addition to the package changelog.
Conclusively, make it easy to fetch'n'browse the src.rpm for updates.



From johannbg at hi.is  Tue Jan 27 14:21:20 2009
From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=)
Date: Tue, 27 Jan 2009 14:21:20 +0000
Subject: how to show upstream changes to the user
In-Reply-To: <20090127141227.9eff6c85.mschwendt@gmail.com>
References: <1233045561.3687.37.camel@eagle.danny.cz>	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>	<1233054273.3687.76.camel@eagle.danny.cz>	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>	<1233061054.3687.98.camel@eagle.danny.cz>
	<20090127141227.9eff6c85.mschwendt@gmail.com>
Message-ID: <497F1860.5010404@hi.is>

Michael Schwendt wrote:
> On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
>
>   
>>>>> b) have such a field in bodhi instead
>>>>>           
>>>> The keyword should be "automation". Why to copy&paste when it can be
>>>> done by script. I can imagine a "hidden" field in spec (special comment
>>>> like #changelog: http://....) that is transformed into a field in bodhi.
>>>> It can be a macro in spec that gets evaluated before including in bodhi,
>>>> etc.
>>>>         
>>> If such a thing is in the package, obviously it should be pulled 
>>> automatically by bodhi. You almost certainly need to copy-paste the link 
>>> once anyway - if the field only exists in bodhi then there's just one 
>>> copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
>>> possibilities :)
>>>       
>> I am looking for possibilities too, so there is chance we will meet
>> somewhere :-)
>>     
>
> So far it smells like needless bureaucracy, which you try to advertise as
> "low overhead for maintainers". Only few maintainers would be interested
> in hunting for URLs of changelog web pages for minor/major releases. The
> benefit would be small. Users of open source software packages, which are
> sceptical of updates/upgrades, ought to fetch the source packages and take
> a look at the documentation files in addition to the package changelog.
> Conclusively, make it easy to fetch'n'browse the src.rpm for updates.
>
>   
For the record the change log and reference to bug fixes either in our 
bugzilla or upstream
are extremely useful information for at least testers,triagers and other 
developers to monitor.

So please contain either an http url to the upstream changelog file or an 
file:///usr/share/doc/<component>/changelog at least in the rawhide and 
updates-testing report.

Both the http an file url are easy to use click able solutions.

And please do not remove the reference to a report(s) in bugzilla
 
This tell testers absolutely nothing

- New upstream version
- Update to
- Lots of bug fixes

What does the new upstream/update version bring?
which feature(s)?
which bug(s) got fixed?

While this does....

 References:
[ 1 ] Bug #471709 - add sh architecture support
https://bugzilla.redhat.com/show_bug.cgi?id=471709

Update to kernel 2.6.27.12:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27.10


Well you could of course provide testers with test cases each
time an new update/version is released instead of provide a reference to 
the bug(s) that
are fixed and an url to the changelog so QA could come up with those 
test cases if needed.

JBG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: johannbg.vcf
Type: text/x-vcard
Size: 356 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/1c2c1e64/attachment.vcf>

From roopesh.majeti at gmail.com  Tue Jan 27 14:31:33 2009
From: roopesh.majeti at gmail.com (Roopesh Majeti)
Date: Tue, 27 Jan 2009 20:01:33 +0530
Subject: Request Info & Help
Message-ID: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>

Hi All,

Not sure if this is the right group to send the email.
When i tried to download the Fedora 10 iso from the following link :

http://ftp.iitm.ac.in/fedora/releases/10/Live/i686/F10-i686-Live.iso
Get Fedora 10 Desktop Edition Now *Installable Live CD*
I ended up with the following error :

Forbidden

You don't have permission to access
/fedora/releases/10/Live/i686/F10-i686-Live.iso on this server.
------------------------------
Apache/2.0.52 (CentOS) Server at ftp.iitm.ac.in Port 80


Can somebody please let me know, where i can download the Fedora 10  or its
VM player version, so that i can download and install the same.

Thanks a lot in advance and sorry for spaming to the group.


Thanks & Regards
Roopesh Kumar M.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/a1ce3fc5/attachment.htm>

From frankly3d at fedoraproject.org  Tue Jan 27 14:38:33 2009
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Tue, 27 Jan 2009 14:38:33 +0000
Subject: Request Info & Help
In-Reply-To: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>
References: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>
Message-ID: <497F1C69.4090405@fedoraproject.org>

Roopesh Majeti wrote:
> Hi All,
> 
> Not sure if this is the right group to send the email.
> When i tried to download the Fedora 10 iso from the following link :
> 
> http://ftp.iitm.ac.in/fedora/releases/10/Live/i686/F10-i686-Live.iso
> 

Use another mirror, there doesn't appear to be an iso at that link

Frank



From rc040203 at freenet.de  Tue Jan 27 14:50:02 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Jan 2009 15:50:02 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <497F1860.5010404@hi.is>
References: <1233045561.3687.37.camel@eagle.danny.cz>	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>	<1233054273.3687.76.camel@eagle.danny.cz>	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>	<1233061054.3687.98.camel@eagle.danny.cz>	<20090127141227.9eff6c85.mschwendt@gmail.com>
	<497F1860.5010404@hi.is>
Message-ID: <497F1F1A.4070208@freenet.de>

J?hann B. Gu?mundsson wrote:
> Michael Schwendt wrote:
>> On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
>
> This tell testers absolutely nothing
> 
> - New upstream version
> - Update to
Untrue. It tells those people who are interested into details, to look 
into upstreams.

Ralf



From sstarr at platform.com  Tue Jan 27 14:57:16 2009
From: sstarr at platform.com (Shawn Starr)
Date: Tue, 27 Jan 2009 09:57:16 -0500
Subject: how to show upstream changes to the user
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>


> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
> Ralf Corsepius
> Sent: Tuesday, January 27, 2009 9:50 AM
> To: Development discussions related to Fedora
> Subject: Re: how to show upstream changes to the user
> 
> 
> J?hann B. Gu?mundsson wrote:
> > Michael Schwendt wrote:
> >> On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
> >
> > This tell testers absolutely nothing
> > 
> > - New upstream version
> > - Update to
> Untrue. It tells those people who are interested into 
> details, to look 
> into upstreams.
> 
> Ralf

Please don't force packagers to have to bug upstream about what changed. Unless another set of Fedora people 
want to dig for that information to update the packager. Some of us don't have the time to nag upstream about what they changed.
Be happy you GET a package, don't be greedy :)

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



From dan at danny.cz  Tue Jan 27 15:00:05 2009
From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=)
Date: Tue, 27 Jan 2009 16:00:05 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <20090127141227.9eff6c85.mschwendt@gmail.com>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>
	<1233061054.3687.98.camel@eagle.danny.cz>
	<20090127141227.9eff6c85.mschwendt@gmail.com>
Message-ID: <1233068405.3687.124.camel@eagle.danny.cz>

Michael Schwendt p??e v ?t 27. 01. 2009 v 14:12 +0100:
> On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
> 
> > > >> b) have such a field in bodhi instead
> > > >
> > > > The keyword should be "automation". Why to copy&paste when it can be
> > > > done by script. I can imagine a "hidden" field in spec (special comment
> > > > like #changelog: http://....) that is transformed into a field in bodhi.
> > > > It can be a macro in spec that gets evaluated before including in bodhi,
> > > > etc.
> > > 
> > > If such a thing is in the package, obviously it should be pulled 
> > > automatically by bodhi. You almost certainly need to copy-paste the link 
> > > once anyway - if the field only exists in bodhi then there's just one 
> > > copy-paste. Mind you, I'm not trying to shoot this down, just looking at 
> > > possibilities :)
> > 
> > I am looking for possibilities too, so there is chance we will meet
> > somewhere :-)
> 
> So far it smells like needless bureaucracy, which you try to advertise as
> "low overhead for maintainers". Only few maintainers would be interested
> in hunting for URLs of changelog web pages for minor/major releases. The
> benefit would be small. Users of open source software packages, which are
> sceptical of updates/upgrades, ought to fetch the source packages and take
> a look at the documentation files in addition to the package changelog.
> Conclusively, make it easy to fetch'n'browse the src.rpm for updates.
> 

>From my side this is purely technical discussion what and how is doable
when such requirement will go into the guidelines after ratifying by
FESCo. I personally do updates via "yum update" so it useless for me,
but I agree that people using GUIs to update can find that information
useful though I am skeptical in general.

I tried to find the changelogs for few of my packages and adding 1 fixed
URL somewhere into the spec wouldn't be so hard.

The other thing is how to automatically add bug numbers from spec
changelog into bodhi - now it requires to have them one bug per line in
'#<number>' format, no other text on that lines.


		Dan




From rc040203 at freenet.de  Tue Jan 27 15:13:31 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Tue, 27 Jan 2009 16:13:31 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
Message-ID: <497F249B.4010005@freenet.de>

Shawn Starr wrote:
>> -----Original Message-----
>> From: fedora-devel-list-bounces at redhat.com
>> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
>> Ralf Corsepius
>> Sent: Tuesday, January 27, 2009 9:50 AM
>> To: Development discussions related to Fedora
>> Subject: Re: how to show upstream changes to the user
>>
>>
>> J?hann B. Gu?mundsson wrote:
>>> Michael Schwendt wrote:
>>>> On Tue, 27 Jan 2009 13:57:34 +0100, Dan wrote:
>>> This tell testers absolutely nothing
>>>
>>> - New upstream version
>>> - Update to
>> Untrue. It tells those people who are interested into 
>> details, to look 
>> into upstreams.
>>
>> Ralf
> 
> Please don't force packagers to have to bug upstream about what changed.

To put this clear: I do not want these changelog URLs and consider
Mr. Sundaram's proposal to be a unhelpful campaign to adding yet more 
bureaucracy to the already overboarding bureaucracy, package maintainers 
in Fedora are confronted with.

> Unless another set of Fedora people 
> want to dig for that information to update the packager.
 > Some of us don't have the time to nag upstream about what they
 > changed.
Agreed.

> Be happy you GET a package, don't be greedy :)
Agreed.

Ralf



From notting at redhat.com  Tue Jan 27 16:04:47 2009
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 27 Jan 2009 11:04:47 -0500
Subject: how to show upstream changes to the user
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
Message-ID: <20090127160447.GA3474@nostromo.devel.redhat.com>

Shawn Starr (sstarr at platform.com) said: 
> Please don't force packagers to have to bug upstream about what changed. Unless another set of Fedora people 
> want to dig for that information to update the packager. Some of us don't have the time to nag upstream about what they changed.

If you don't have the time to find out, *as a maintainer*, what changed,
you shouldn't be maintaining it.

Bill



From sstarr at platform.com  Tue Jan 27 16:08:42 2009
From: sstarr at platform.com (Shawn Starr)
Date: Tue, 27 Jan 2009 11:08:42 -0500
Subject: how to show upstream changes to the user
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5A@catoexm05.noam.corp.platform.com>

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Bill
> Nottingham
> Sent: Tuesday, January 27, 2009 11:05 AM
> To: Development discussions related to Fedora
> Subject: Re: how to show upstream changes to the user
> 
> 
> Shawn Starr (sstarr at platform.com) said: 
> > Please don't force packagers to have to bug upstream about 
> what changed. Unless another set of Fedora people 
> > want to dig for that information to update the packager. 
> Some of us don't have the time to nag upstream about what 
> they changed.
> 
> If you don't have the time to find out, *as a maintainer*, 
> what changed,
> you shouldn't be maintaining it.
> 
> Bill

I get whatever is in the git changlogs. That's all that's available. If I choose to mention
something important from it I will, otherwise I will just mention a new upstream version
Just like Debian packages do. I see no reason to be any different.

> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



From mschmidt at redhat.com  Tue Jan 27 16:23:08 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Tue, 27 Jan 2009 17:23:08 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5A@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5A@catoexm05.noam.corp.platform.com>
Message-ID: <20090127172308.00351cd4@brian.englab.brq.redhat.com>

On Tue, 27 Jan 2009 11:08:42 -0500
"Shawn Starr" <sstarr at platform.com> wrote:

> I get whatever is in the git changlogs. That's all that's available.
> If I choose to mention something important from it I will, otherwise
> I will just mention a new upstream version Just like Debian packages
> do. I see no reason to be any different.

How about: If, after looking at the git changelogs, I am unable to find
anything worth mentioning, I only update the package in Rawhide
and do not bother with updates for released Fedoras?

Michal



From sstarr at platform.com  Tue Jan 27 16:37:15 2009
From: sstarr at platform.com (Shawn Starr)
Date: Tue, 27 Jan 2009 11:37:15 -0500
Subject: how to show upstream changes to the user
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5C@catoexm05.noam.corp.platform.com>

> > -----Original Message-----
> > From: fedora-devel-list-bounces at redhat.com
> > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
> > Michal Schmidt
> > Sent: Tuesday, January 27, 2009 11:23 AM
> > To: fedora-devel-list at redhat.com
> > Subject: Re: how to show upstream changes to the user
> >
> > How about: If, after looking at the git changelogs, I am 
> > unable to find
> > anything worth mentioning, I only update the package in Rawhide
> > and do not bother with updates for released Fedoras?
> > 
> > Michal
> > 
> That's what I do normally. Once a Fedora releases, I won't 
> backport to it
> unless the changelog mentions something severe. Otherwise 
> resume pushing
> periodical updates to rawhide.
> 

To answer myself, If this policy is ONLY for released Fedoras not Rawhide
I'd have no problem. If this was for rawhide I'd have a problem.

> > -- 
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
> > 
> 



From sstarr at platform.com  Tue Jan 27 16:35:57 2009
From: sstarr at platform.com (Shawn Starr)
Date: Tue, 27 Jan 2009 11:35:57 -0500
Subject: how to show upstream changes to the user
Message-ID: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5B@catoexm05.noam.corp.platform.com>


> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com
> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of 
> Michal Schmidt
> Sent: Tuesday, January 27, 2009 11:23 AM
> To: fedora-devel-list at redhat.com
> Subject: Re: how to show upstream changes to the user
> 
> 
> On Tue, 27 Jan 2009 11:08:42 -0500
> "Shawn Starr" <sstarr at platform.com> wrote:
> 
> > I get whatever is in the git changlogs. That's all that's available.
> > If I choose to mention something important from it I will, otherwise
> > I will just mention a new upstream version Just like Debian packages
> > do. I see no reason to be any different.
> 
> How about: If, after looking at the git changelogs, I am 
> unable to find
> anything worth mentioning, I only update the package in Rawhide
> and do not bother with updates for released Fedoras?
> 
> Michal
> 
That's what I do normally. Once a Fedora releases, I won't backport to it
unless the changelog mentions something severe. Otherwise resume pushing
periodical updates to rawhide.

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
> 



From ville.skytta at iki.fi  Tue Jan 27 16:41:14 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-15?q?Skytt=E4?=)
Date: Tue, 27 Jan 2009 18:41:14 +0200
Subject: how to show upstream changes to the user
In-Reply-To: <alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
Message-ID: <200901271841.15939.ville.skytta@iki.fi>

On Tuesday 27 January 2009, Panu Matilainen wrote:

> - It introduces a spec incompatibility, which can be taken care of in
>    Fedora land but not so easy for EPEL side of things. Dunno if our
>    buildsys ever does anything with the rpmbuild of the host system
>    (I seem to recall it doing some part there but could easily be wrong),
>    IF so this is pretty much a no-go.

I suppose this has been asked/suggested before, but how about changing rpm so 
that its spec file parser doesn't error out but rather issues a big warning 
when it sees a tag like structure it doesn't understand, and ignores it?  And 
add a command line option like --lenient to rpmbuild that enables this 
behavior (default would be "strict" like currently).  After this option has 
trickled to all supported environments, every use of a newly added tag would 
no longer render the package unbuildable with earlier rpmbuild versions.



From mschwendt at gmail.com  Tue Jan 27 16:51:32 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Tue, 27 Jan 2009 17:51:32 +0100
Subject: how to show upstream changes to the user
In-Reply-To: <497F1860.5010404@hi.is>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271353050.8659@gotcha.dreamhost.com>
	<1233061054.3687.98.camel@eagle.danny.cz>
	<20090127141227.9eff6c85.mschwendt@gmail.com>
	<497F1860.5010404@hi.is>
Message-ID: <20090127175132.7d0a897c.mschwendt@gmail.com>

On Tue, 27 Jan 2009 14:21:20 +0000, J?hann wrote:

> For the record the change log and reference to bug fixes either in our 
> bugzilla or upstream
> are extremely useful information for at least testers,triagers and other 
> developers to monitor.

Maybe. Maybe they are useful. What problem does it fix, though?
There is not much testing activity outside of bugzilla PRs. And the
triagers still touch bugzilla tickets without reading any part of it.

If, however, you want to raise criticism about specific RPM %changelog
entries, let's discuss some examples first.

> So please contain either an http url to the upstream changelog file or an 
> file:///usr/share/doc/<component>/changelog at least in the rawhide and 
> updates-testing report.

Why?

You can visit the upstream URL and hunt for news there if you have
strong/reasonable interest in a package. You can download the src.rpm and
examine the upstream tarball contents, or you can skim over the %doc files
included in the binary rpms.

The stronger your interest in a package, the more you ought to volunteer
as a package co-maintainer. Preferably we have a good mix of power-users
and package maintainers for every Fedora package.

> Both the http an file url are easy to use click able solutions.

The file URI is useless IMO. For uninstalled packages it points to a
non-existant file. A web page URL adds maintenance overhead just like the
"Source" URLs, btw. There are locations, which change silently, whereas a
package maintainer notices changes in the update tarball.

> And please do not remove the reference to a report(s) in bugzilla

Most package maintainers mention bz ticket numbers in the %changelog.
That is more than enough.
  
> This tell testers absolutely nothing
> 
> - New upstream version
> - Update to

Both are good enough in a %changelog, as they sum up the only change
that has been applied to the RPM package. If you're interested in 
details, look out for developer's ChangeLog (or NEWS files, e.g.).

> - Lots of bug fixes

That is a sufficient summary for a version upgrade, which is advertised as
a bug-fix release. If the RPM package users have not submitted any PR, it
seems they are not affected.
 
> What does the new upstream/update version bring?
> which feature(s)?

Where upstream README or NEWS files, which can be included in a package as
%doc files, don't cover such details, step up and become the upstream
project's documentation writer.

> which bug(s) got fixed?

Monitor the upstream bug tracking system if you are seriously
interested in such details.

> Well you could of course provide testers with test cases each
> time an new update/version is released instead of provide a reference to 
> the bug(s) that
> are fixed and an url to the changelog so QA could come up with those 
> test cases if needed.

You show a misunderstanding of what upstream maintainers and distribution
package maintainers are supposed to do.

Except for a few key packages in Fedora maybe, the majority of package
maintainers have zero expectations with regard to any QA. There simply is
no one to do such QA, not even WRT packages submitted as stable update
requests.



From aa.lucelio at gmail.com  Tue Jan 27 16:59:41 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Tue, 27 Jan 2009 14:59:41 -0200
Subject: Request Info & Help
In-Reply-To: <497F1C69.4090405@fedoraproject.org>
References: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>
	<497F1C69.4090405@fedoraproject.org>
Message-ID: <f4a59ea0901270859nc017ebfk8869a6e64c6f5ec2@mail.gmail.com>

Roopesh Majeti,

Don't wory, if you don't know where to get information, I also was unhappy
and felt like in the film "I am Legend" with "WILL SMITH", desert and very
agressive ambient.   The solution is: just don't feeed some agresive and
wild animals, and all will be ok.   I also don't know where is the right
place to start, but there are many ways to get what you need.  One of them
is:

=====>  *http://torrent.fedoraproject.org/*

First if you don't have Utorrent get it, it is free.  Then, at that address
you download a smal file(.torrent) responsable for getting the CD/DVD in the
address above.   This file will be used by Utorrent and guarantee that you
get a perfect CD/DVD copy.    After, search in this CD/DVD that you
downloaded, a "*readme*" file, that explains how to do installation.

My be someone could show shomething better, but now you have a start, that
works.
I think that this is what you need, otherwise let me now, please.   I hope
that they undersatand that cooperation is better than competition, and that
we are at the same side.

Ps:  I spent 1 minute to write this E-mail.

Hope to see you later,
Luc?lio.

2009/1/27 Frank Murphy <frankly3d at fedoraproject.org>

> Roopesh Majeti wrote:
> > Hi All,
> >
> > Not sure if this is the right group to send the email.
> > When i tried to download the Fedora 10 iso from the following link :
> >
> > http://ftp.iitm.ac.in/fedora/releases/10/Live/i686/F10-i686-Live.iso
> >
>
> Use another mirror, there doesn't appear to be an iso at that link
>
> Frank
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/5600afa4/attachment.htm>

From sundaram at fedoraproject.org  Tue Jan 27 17:12:01 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 22:42:01 +0530
Subject: how to show upstream changes to the user
In-Reply-To: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5C@catoexm05.noam.corp.platform.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B5C@catoexm05.noam.corp.platform.com>
Message-ID: <497F4061.1040306@fedoraproject.org>

Shawn Starr wrote:

> To answer myself, If this policy is ONLY for released Fedoras not Rawhide
> I'd have no problem. If this was for rawhide I'd have a problem.

Yes, this is primarily a concern for general releases and not rawhide.

Rahul



From jkeating at redhat.com  Tue Jan 27 17:31:54 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 09:31:54 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261817p309c061dl98edbc9ec254ba4e@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<1233006941.8363.161.camel@localhost.localdomain>
	<7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>
	<1233008041.8363.162.camel@localhost.localdomain>
	<7dd7ab490901261817p309c061dl98edbc9ec254ba4e@mail.gmail.com>
Message-ID: <1233077514.8363.188.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:17 -0800, Chris Weyl wrote:
>  Yes, actually I did.  Perhaps I misunderstood your meaning here: are
> you saying that it's policy in Fedora that a maintainer should not
> keep their packages up to date in the best fashion that their
> judgement suggests, in line with the above?

No, I'm trying to illustrate that there is a difference between
"tracking upstream" and making judgment calls on proper updates for a
release, and in fact we have policy about it.

> 
> In any case, this is off-topic to the discussion; the question is
> about imposing another manual task on a maintainer, rather than how
> maintainers should exercise their judgement as to pushing updates
> (which the above quote appears to address quite nicely).
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/0da7e94a/attachment.sig>

From jkeating at redhat.com  Tue Jan 27 17:36:57 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 09:36:57 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261827icc0e7b6o9ed81df9c802882c@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<gllj3h$nro$1@ger.gmane.org>
	<1233014865.8363.169.camel@localhost.localdomain>
	<7dd7ab490901261827icc0e7b6o9ed81df9c802882c@mail.gmail.com>
Message-ID: <1233077818.8363.190.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:27 -0800, Chris Weyl wrote:
> 2009/1/26 Jesse Keating <jkeating at redhat.com>:
> > But Fedora /releases/ aren't your personal rawhide.  We're providing
> > releases that are supposed to stay somewhat stable, not to just be a
> > dumping ground for whatever upstream chooses to drop the day before.  We
> > have a developmental stream for that, and it makes releases fairly
> > often.  I just don't understand why we want to treat our /release/
> > branches as if they were just another rawhide.
> 
> I doubt anyone here intentionally treats a release in the same way
> it's acceptable to beat up rawhide with.  There's a _huge_ difference
> in sanely tracking upstream in a release and injecting potentially
> massively unstable stuff in rawhide.
> 

YOU may see it that way, however given some of the updates I've seen
tossed at Fedora, spammed to every release including rawhide at the same
time, with extremely little (often no) information about what the update
is, and why users should process that update, I have a hard time
believing that the maintainer base as a whole agrees with you.  So yeah,
I want to introduce a step where the maintainer actually has to think
about why they are issuing this update, what value it brings to users,
and what they should test for in order to help the maintainer know if
the intended value was met or not.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/6c5fa514/attachment.sig>

From jkeating at j2solutions.net  Tue Jan 27 17:41:55 2009
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 27 Jan 2009 09:41:55 -0800
Subject: Lack of update information
In-Reply-To: <497E6D62.4060708@freenet.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
Message-ID: <1233078115.8363.194.camel@localhost.localdomain>

On Tue, 2009-01-27 at 03:11 +0100, Ralf Corsepius wrote:
> Jesse Keating wrote:
> > On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
> >>  The problem with this: Users don't notice the cases in which upgrades 
> >> "simply work" - They only notice the case, something already has gone wrong.
> > 
> > Many users notice a plethora of updates for unknown reasons that chew up
> > their bandwidth, cpu, and disk time while they're just trying to get
> > work done.  So much so that many opt out of applying updates at all,
> > because there are so many of them, which hurts our abilities to deliver
> > security updates.
> 
> These problems do not originate from the number of upgrades/update, they 
> originate from the _size_ of updates few packages introduce.

Size is in direct correlation to number.

> 
> > People in bandwidth rich situations 
> Correct.
> 
> > and with new expensive fast hardware
> > may not see a problem. 
> 
> Well, I would label this an urban legend - Updating recent Fedoras using 
> yum has not been much of a performance problem, even on slower and older 
> HW (e.g. a 1GHz i686/512MB)
> 
> Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be 
> "really slow".

Try doing updates on a netbook, or any other system with relatively slow
"disk" I/O, or "slow" CPU.  Yum isn't really the problem here, it's the
rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
hardlinking, etc...  and while people are working to correct some of
this, the fact still remains that processing updates chews up system
resources.

> 
> However, wrt. to bandwidth, I see another problem: Your strategy of 
> pushing updates in "big batches", instead of "small chunks".
> 
> This makes a significant difference to users with limited bandwidth. 
> While they could easily poll "small chunks", e.g. once a day (blocking 
> their network for, e.g. 1 hour), the current strategy would block they 
> network for very much longer (e.g. 7 hours).

If I were to push updates once a day, the mirrors would be in shambles,
constantly trying to pick up the new content and users would have a
terrible experience.  Pushing updates faster doesn't magically make the
number of updates get smaller.

> 
> Another aspect related to bandwidth: Revisiting
> * the sizes of rpms (e.g. different payload compressors).
> * differential updates/rpms.
> 
> Seems to me as if these once "hot topics" have dropped off the Fedora 
> radar, in favor of "strangling/nagging the distro's contributors".
> 
> Ralf
> 

People are working on both of the above issues.  Just not me personally.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/b4c5bf99/attachment.sig>

From jkeating at redhat.com  Tue Jan 27 17:43:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 09:43:13 -0800
Subject: Lack of update information
In-Reply-To: <glmjcp$uvt$2@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<glmjcp$uvt$2@ger.gmane.org>
Message-ID: <1233078193.8363.195.camel@localhost.localdomain>

On Tue, 2009-01-27 at 10:16 +0100, Kevin Kofler wrote:
>  Those who do not have the bandwidth to pull Fedora updates shouldn't be
> running Fedora. There are plenty of distros with few updates which would be
> a lot more suitable for people with slow Internet connections.
> 
> IMHO we should add "broadband Internet connection" to Fedora's system
> requirements and list it prominently on the download page.

That's the kind of elitist crap attitude I hate to see in Fedora.

I agree that broadband should be a requirement for using /rawhide/ where
the churn is expected to be great, however I refuse to agree that we
should treat our /stable/ releases in the same way.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/0bf59cde/attachment.sig>

From jkeating at redhat.com  Tue Jan 27 18:04:58 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 10:04:58 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
	<7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
Message-ID: <1233079498.8363.196.camel@localhost.localdomain>

On Mon, 2009-01-26 at 18:47 -0800, Chris Weyl wrote:
>  And all obviated by Fedora policy and practice: we expressly give and
> expect maintainers to exercise their judgement here.
> 
> Unless, of course, we need a Committee of Update Oversight set up...?
> Maybe a new set of highly detailed guidelines, detailing when and how
> updates are to be blessed and released to the great unwashed, or cast
> asunder?

Given that we have maintainers not following the policy, we need to do
something.  By having maintainers mention in the update request /why/
they are issuing an update, it's far easier to spot check and verify.

Trust, but verify.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/3c609845/attachment.sig>

From sundaram at fedoraproject.org  Tue Jan 27 18:18:45 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Tue, 27 Jan 2009 23:48:45 +0530
Subject: Draft: simple update description guidelines
Message-ID: <497F5005.4060107@fedoraproject.org>

Hi,

The following are a set of simple guidelines for the update descriptions 
via bodhi (which is used by PackageKit to inform users of what has 
changed). These guidelines are intended to help end users understand the 
nature of changes in the update better. Bodhi is not used in rawhide, so 
these guidelines are not applicable for rawhide updates. Note that this 
is not connected to the rpm changelog.

I have tried to summarize what has been suggested in a couple of earlier 
threads. If there is anything else that needed to be added, do let me 
know. If there is FESCo approval and general consensus, we can add this to

http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility

and add a reference to

http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo#Submit_your_update_to_Bodhi

---

* All Updates must refer to a upstream changelog or equivalent if one 
exists. Otherwise a brief description (a couple of sentence at most) 
justifying the need for an update must be provided by the maintainers 
pushing the update.

* If there are downstream bugs being fixed or intended to be fixed with 
an update, it must be referred within the update. Maintainers can choose 
to let bodhi auto close bugs or close it manually as well.

* For security update, add CVE information, if one exists.

* It is highly recommended that package maaintainers highlight major new 
features, critical bug fixes or anything else that has a potential high 
impact on consumers of your update.

---

Please be specific in your comments and try and be constructive. Thank you.

Rahul



From nicolas.mailhot at laposte.net  Sat Jan 24 21:48:42 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 24 Jan 2009 22:48:42 +0100
Subject: [LONG] The fonts SIG irregular status report
In-Reply-To: <1232831775.24232.131.camel@arekh.okg>
References: <1232831775.24232.131.camel@arekh.okg>
Message-ID: <1232833722.24232.133.camel@arekh.okg>

Hi all,

Since Fedora 11 Alpha is quickly approaching, here is a much-delayed
edition of the fonts SIG irregular status report.

I should probably have done one for Fedora 10 release, but (silly me)
expected then that the new font packaging guidelines would be adopted
quickly. After all, they only reworded existing rules and added material
already presented and discussed on the fonts and devel lists.

Of course various instances decided to celebrate F10 by taking a break,
then there was some bike-shedding, then we had the Christmas vacations,
then FUDCON and more bike-shedding. Live and learn. At least after being
hammered to death the result is clear and clean.

Anyway, to the report.


??? New fonts packaging guidelines ???

After much anguish and unexpected developments FPC and FESCO approved
the complete set of fonts packaging changes that we had submitted.
https://www.redhat.com/archives/fedora-devel-announce/2009-January/msg00007.html

The end result is:
  ? a completed and clarified policy page
http://fedoraproject.org/wiki/Packaging:FontsPolicy

  ? two new packaging templates
http://fedoraproject.org/wiki/Simple_fonts_spec_template
http://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts

  ? and a helper package with rpm macros, documentation, plus fontconfig
and spec templates
http://fedoraproject.org/wiki/Fedora_fonts_policy_package


??? Distribution-wide font auditing and repackaging ???

Some innocent repoqueries revealed a distressing number of source
packages (>130) that made us ship fonts while completely ignoring our
previous fonts packaging guidelines and existing licensing rules. So
applying new font guidelines twists quickly turned into
distribution-wide operation.

  ? Its advancement is now tracked in:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=477044

  ? A (long) FAQ was published to help packagers with no fonts
experience:
http://fedoraproject.org/wiki/Shipping_fonts_in_Fedora_(FAQ)

  ? To make sure documentation, QA and other groups are aware and help
implement the changes they've been proposed as a Fedora 11 feature: 
http://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts


??? Wishlist status ???

Our wishlist stood at 56 entries for last report. It has now reached the
76 entries watermark. The current fonts packagers are clearly unable to
cope with Fedora demands, fresh blood is needed before it moves into
3-digits land.

http://fedoraproject.org/wiki/Category:Font_wishlist

At the same time the respected lwn.net is running a front page article
listing more indispensable free or open fonts, some of them being
neither in Fedora nor in our wishlist yet.

http://lwn.net/Articles/315872/
(subscription required right now, will go free in less than a week)

Volunteers to package those or at least add them to our wishlist would
be welcome. The free and open font landscape is really moving now, and
the quality and breadth of its font offerings is now a distribution
differentiator.


??? Review status ???

At this time there are no un-reviewed font packages in Fedora bugzilla.
However, several reviews have been open for quite a long time with their
requesters not acting on review comments.

Please do respond to review comments. Reviewing packages is tedious
ungrateful work and getting no response after one is demotivating.


??? New packages ???

Ignoring renamings ctan-musixtex-fonts, dustin-dustismo-roman-fonts,
dustin-dustismo-sans-fonts, hanazono-fonts, google-droid-sans-fonts,
google-droid-sans-mono-font, google-droid-serif-fonts,
serafettin-cartoon-fonts, and unikurd-web-font are now available in the
repository.

The most user-visible of those are probably the Droid fonts, but Dustimo
had been waited for a long time.

Several other fonts previously hidden deep inside apps have now been
exposed as part of the ongoing F11 auditing and repackaging. The
complete set of changes is documented as usual:
http://fedoraproject.org/wiki/Fonts_inclusion_history

Several new packagers worked on those and on other packages not pushed
yet and I want to thank them publicly for their contribution to a better
Fedora.


??? Web font surveys ???

Fedora 10 shipped with an openjdk plugin that should be complete enough
to run web font surveys. There is no reason left for Fedora users not to
participate in them, and help web designers select fonts that work well
with Fedora browsers. Please take the time to run those:

http://fedoraproject.org/wiki/Linux_fonts_on_the_web:_CSS_and_font_surveys


??? Better fonts whiteboard ???

The desktop team has added a whiteboard page to the wiki to help
identify the software changes needed to improve Fedora fonts and text
handling.

http://fedoraproject.org/wiki/Desktop/Whiteboards/BetterFonts

Please contribute comments and complements to this page to help Fedora
get better.


??? Font autoinstallation ???

Rumors on irc are that the feature is advancing fast. Hopefully we'll
have finished cleaning up our font packages before they need to be
rebuild to add auto-install metadata. Automating this operation requires
clean packages free of historic cruft.

http://fedoraproject.org/wiki/Features/AutomaticFontInstallation

And that's all for this issue, thank you for reading it to its end.

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090124/27c0caf3/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From jkeating at redhat.com  Tue Jan 27 18:22:47 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 10:22:47 -0800
Subject: Fedora 11 Alpha Status
Message-ID: <1233080567.8363.202.camel@localhost.localdomain>

Last night we refreshed the alpha freeze (see koji tag f11-alpha-2).
This will be the content we're using for the Alpha, provided our testing
is successful.  Anything else added will only be for critical path
items, that is the path to install, boot, obtain network, and update.
If a reasonable workaround is found for a problem in that path, the work
around will be advertised rather than respinning the Alpha.

Today's rawhide is not functional due to some changes in createrepo/yum.
Newer builds of these packages have been made and tested and added to
the new alpha tag, so tomorrow's rawhide is a bit closer to what the
Alpha will be.

We hope to have the alpha fully composed by midday tomorrow and on its
way to mirrors for staging.  I'll announce when this happens.  Release
date is still planned for Tuesday, February 3rd.

Thanks all!
-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/2c70c2dd/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From fedora at leemhuis.info  Tue Jan 27 18:47:04 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 27 Jan 2009 19:47:04 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <497F56A8.7010803@leemhuis.info>

On 27.01.2009 19:18, Rahul Sundaram wrote:
> The following are a set of simple guidelines for the update descriptions 
> via bodhi (which is used by PackageKit to inform users of what has 
> changed). These guidelines are intended to help end users understand the 
> nature of changes in the update better. Bodhi is not used in rawhide, so 
> these guidelines are not applicable for rawhide updates. Note that this 
> is not connected to the rpm changelog.
> 
> I have tried to summarize what has been suggested in a couple of earlier 
> threads. If there is anything else that needed to be added, do let me 
> know. If there is FESCo approval and general consensus, we can add this to
> 
> http://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility
> 
> and add a reference to
> 
> http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo#Submit_your_update_to_Bodhi

Don't we have way to many guidelines and policies already?

At least I think we have way to many of them already. That makes 
contributing to Fedora (and especially starting to contribute) harder 
and harder -- especially as finding, reading, understanding and 
remembering all the different rules and guidelines (and follow their 
changes) gets next to impossible afaics.

Let's please stop this path -- let's make things easier again instead of 
regulating each and every detail.

Note that I don't disagree with the text that was proposed. My 2 cent: 
Put it as text into the wiki somewhere, write "best practices" ontop of 
it (avoid the words "rules" and "guidlines") and add a link to the bodhi 
ui ("best practices for filing this box with information").

Cu
knurd



From sundaram at fedoraproject.org  Tue Jan 27 19:12:16 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 00:42:16 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <497F56A8.7010803@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
Message-ID: <497F5C90.5090909@fedoraproject.org>

Thorsten Leemhuis wrote:

> Don't we have way to many guidelines and policies already?

This is a very minor addition to an existing set of guidelines. I think, 
it is quite helpful to new maintainers to document better what it 
expected. It is pretty much a FAQ on #fedora-devel for a while.

> Note that I don't disagree with the text that was proposed. My 2 cent: 
> Put it as text into the wiki somewhere, write "best practices" ontop of 
> it (avoid the words "rules" and "guidlines") and add a link to the bodhi 
> ui ("best practices for filing this box with information").

This would just be a guideline under a different name. Isn't it? What's 
the advantage?

Rahul



From jspaleta at gmail.com  Tue Jan 27 19:20:13 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Jan 2009 10:20:13 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <497F56A8.7010803@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
Message-ID: <604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>

On Tue, Jan 27, 2009 at 9:47 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> Note that I don't disagree with the text that was proposed. My 2 cent: Put
> it as text into the wiki somewhere, write "best practices" ontop of it
> (avoid the words "rules" and "guidlines") and add a link to the bodhi ui
> ("best practices for filing this box with information").

Just to be clear. You are okay with documenting "best practises" but
not requiring people to use those best practises? To me its a somewhat
semantic difference between the words "guidelines" and "best
practises"  so I just want to make sure I know where you think the
line is with regard to what is too much and what is too little
instruction or guidance.

There is a tension between ease of contributor participation and
quality. Some things can certainly be automated to help relieve some
of that tension, but I'm not sure update notification text snippets
are one of those things.  If we are going to draw a line in the sand
and establish best practises, then we have to find a way to encourage
those best practises get used consistently.    And of course it would
also help if when we established any new best practise to address a
perceived deficiency we also come up with a methodology to see if the
effort to document the best practise actually helps to reduce the
occurrence of the deficiency.

-jef



From seg at haxxed.com  Tue Jan 27 19:21:11 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Tue, 27 Jan 2009 13:21:11 -0600
Subject: support for latest (radeon) hardware
In-Reply-To: <glg41r$dp7$1@ger.gmane.org>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<glg41r$dp7$1@ger.gmane.org>
Message-ID: <1233084071.19014.36.camel@localhost.localdomain>

On Sat, 2009-01-24 at 23:17 +0100, Kevin Kofler wrote:
> That said, it's a tough topic, because regressions tend to really annoy
> people, they feel "WTF, this always worked, WhyTF is it no longer working
> now?", even though from a purely practical point of view, unfixed bugs (and
> not working on some hardware is practically speaking a bug, even though
> technically it's a missing feature) are much worse because there's no
> working build to revert to.

Your logic is flawed. People with not yet supported hardware, can find
supported hardware, or live with workarounds like VESA. You can not make
progress by accepting regressions. At best, you are spinning your wheels
in place, at worst you are taking one step forward and two steps back.
Regression means just that, you are regressing. Fedora is about
progress, not regress. The linux kernel has a rather strict
no-regressions policy, for good reason:

http://lwn.net/Articles/261713/

I wish Xorg and Fedora as a whole, would adopt a similar policy. I'm
very unhappy with how the Xorg update went in F10. Just when we started
getting reliable, usable open source OpenGL, F10 came along and broke
*everything*:

https://bugzilla.redhat.com/show_bug.cgi?id=474977
https://bugzilla.redhat.com/show_bug.cgi?id=441665
https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html

Not a single one of my machines works out of the box like they did in
F9, they all need work-arounds. But OpenGL support has been quite
thoroughly broken. This has pretty well fucked any ability to get back
to working on Second Life:

https://bugzilla.redhat.com/show_bug.cgi?id=233946

I have Shit To Do, and it looks like I'm going to have to revert my
entire Xorg back to F9 to do it.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/0e4c0173/attachment.sig>

From rjones at redhat.com  Tue Jan 27 19:36:29 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 27 Jan 2009 19:36:29 +0000
Subject: how to show upstream changes to the user
In-Reply-To: <200901271841.15939.ville.skytta@iki.fi>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<200901271841.15939.ville.skytta@iki.fi>
Message-ID: <20090127193629.GA18789@amd.home.annexia.org>

On Tue, Jan 27, 2009 at 06:41:14PM +0200, Ville Skytt? wrote:
> On Tuesday 27 January 2009, Panu Matilainen wrote:
> 
> > - It introduces a spec incompatibility, which can be taken care of in
> >    Fedora land but not so easy for EPEL side of things. Dunno if our
> >    buildsys ever does anything with the rpmbuild of the host system
> >    (I seem to recall it doing some part there but could easily be wrong),
> >    IF so this is pretty much a no-go.
> 
> I suppose this has been asked/suggested before, but how about changing rpm so 
> that its spec file parser doesn't error out but rather issues a big warning 
> when it sees a tag like structure it doesn't understand, and ignores it? 

Or allow RPM field names to be listed in a configuration file.  The
ones which RPM doesn't recognize, but which are in the file, are
ignored.  You break compatibility once, but allow future versions of
RPM to handle all future tags with relative ease (just add them to the
configuration file of earlier versions).

Did that make sense .....

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 fedora at leemhuis.info  Tue Jan 27 19:36:54 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 27 Jan 2009 20:36:54 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5C90.5090909@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>	<497F56A8.7010803@leemhuis.info>
	<497F5C90.5090909@fedoraproject.org>
Message-ID: <497F6256.5000504@leemhuis.info>

On 27.01.2009 20:12, Rahul Sundaram wrote:
> Thorsten Leemhuis wrote:
> 
>> Don't we have way to many guidelines and policies already?
> This is a very minor addition to an existing set of guidelines.

Well, those minor additions in different places sum up over time.

> I think, it is quite helpful to new maintainers [...] 

Maybe that's why I suggested to put it in the wiki ;-)

>> Note that I don't disagree with the text that was proposed. My 2 cent: 
>> Put it as text into the wiki somewhere, write "best practices" ontop of 
>> it (avoid the words "rules" and "guidlines") and add a link to the bodhi 
>> ui ("best practices for filing this box with information").
> This would just be a guideline under a different name. Isn't it? What's 
> the advantage?

The word guidelines in fedora is used for things that are quite 
important -- take the packaging guidelines as example, which often seem 
to be more handled like rules and not like something that is allowed to 
ignore/breach when it makes sense.

So you have to know, understand and remember all guidelines in Fedora if 
you want to prevent than someone yells at you "but it's written".

The word "best practices" make it clearer that this  is the best way, 
but not a must.

Cu
knurd



From rjones at redhat.com  Tue Jan 27 19:38:59 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 27 Jan 2009 19:38:59 +0000
Subject: how to show upstream changes to the user
In-Reply-To: <20090127160447.GA3474@nostromo.devel.redhat.com>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
	<20090127160447.GA3474@nostromo.devel.redhat.com>
Message-ID: <20090127193859.GB18789@amd.home.annexia.org>

On Tue, Jan 27, 2009 at 11:04:47AM -0500, Bill Nottingham wrote:
> Shawn Starr (sstarr at platform.com) said: 
> > Please don't force packagers to have to bug upstream about what changed. Unless another set of Fedora people 
> > want to dig for that information to update the packager. Some of us don't have the time to nag upstream about what they changed.
> 
> If you don't have the time to find out, *as a maintainer*, what changed,
> you shouldn't be maintaining it.

I don't think that's true at all.  As a *packager*, my job is to
package correctly and respond to packaging bugs.  Sometimes that
involves a little bit of code maintenance -- so you need to be a jack
of all trades^Wprogramming languages -- but I am by no means an expert
on the ins and outs of every version of every package I look after.

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 rjones at redhat.com  Tue Jan 27 19:43:53 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 27 Jan 2009 19:43:53 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <20090127194353.GC18789@amd.home.annexia.org>

On Tue, Jan 27, 2009 at 11:48:45PM +0530, Rahul Sundaram wrote:
> * All Updates must refer to a upstream changelog or equivalent if one  
> exists. Otherwise a brief description (a couple of sentence at most)  
> justifying the need for an update must be provided by the maintainers  
> pushing the update.

I'm happy this applies only to released versions of Fedora[1].  But I
think this should also exclude 'newpackage' updates explicitly (ie.
where a new package is added to a released version of Fedora).

Rich.

[1] Although it will certainly mean I feel much less inclined to just
upgrade any released packages unless there's a security issue.

-- 
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 jlaska at redhat.com  Tue Jan 27 19:43:17 2009
From: jlaska at redhat.com (James Laska)
Date: Tue, 27 Jan 2009 14:43:17 -0500
Subject: 2009-01-29 - Fedora Test Day - Text-mode install removal
Message-ID: <1233085397.3427.88.camel@localhost.localdomain>

Greetings,

Okay now that I got your attention.  Don't worry, text-mode is not going
away.  But in order to simplify maintenance it will be greatly reduced
in terms of functionality.  

I'd like to invite testers and users to join #fedora-qa this Thursday,
January 29, 2009.  Test efforts will focus on:

 * anaconda text-mode simplification
 * Fedora 11 Alpha

Come with questions and/or suggested test areas.

More details will be posted to
https://fedoraproject.org/wiki/QA/Test_Days/2009-01-29.

Hope to see you there,
James

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/ed98c98c/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From fedora at leemhuis.info  Tue Jan 27 19:49:30 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 27 Jan 2009 20:49:30 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org>	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
Message-ID: <497F654A.7090503@leemhuis.info>

On 27.01.2009 20:20, Jeff Spaleta wrote:
> On Tue, Jan 27, 2009 at 9:47 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> Note that I don't disagree with the text that was proposed. My 2 cent: Put
>> it as text into the wiki somewhere, write "best practices" ontop of it
>> (avoid the words "rules" and "guidlines") and add a link to the bodhi ui
>> ("best practices for filing this box with information").
> 
> Just to be clear. You are okay with documenting "best practises" but
> not requiring people to use those best practises? 

Yes.

> [...] 
> There is a tension between ease of contributor participation and
> quality. 

Sure.

> Some things can certainly be automated to help relieve some
> of that tension, but I'm not sure update notification text snippets
> are one of those things. 

Well, we have done fine without special rules for update text many years 
now afaics. So why do we need them now? Why can't "best practises" do, 
if it worked fine for so many years?

Whatever:  I don't care much about this specific set of rules. It just 
seems to me a general trend that more and more rules and guidelines are 
put into place in Fedora-land; and more and more work is outsourced onto 
the packagers. Sure, some of the rules and the outsourcing is needed -- 
but I find this trend very alarming.

Cu
knurd



From sundaram at fedoraproject.org  Tue Jan 27 19:52:31 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 01:22:31 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090127194353.GC18789@amd.home.annexia.org>
References: <497F5005.4060107@fedoraproject.org>
	<20090127194353.GC18789@amd.home.annexia.org>
Message-ID: <497F65FF.2030204@fedoraproject.org>

Richard W.M. Jones wrote:
> On Tue, Jan 27, 2009 at 11:48:45PM +0530, Rahul Sundaram wrote:
>> * All Updates must refer to a upstream changelog or equivalent if one  
>> exists. Otherwise a brief description (a couple of sentence at most)  
>> justifying the need for an update must be provided by the maintainers  
>> pushing the update.
> 
> I'm happy this applies only to released versions of Fedora[1].  But I
> think this should also exclude 'newpackage' updates explicitly (ie.
> where a new package is added to a released version of Fedora).

Ah, yes.  I will add a explicit sentence as follows:

* These guidelines are not applicable to updates in rawhide or for 
completely new packages being introduced into the repository.

Thanks.

Rahul



From sundaram at fedoraproject.org  Tue Jan 27 19:55:31 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 01:25:31 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <497F6256.5000504@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>	<497F56A8.7010803@leemhuis.info>	<497F5C90.5090909@fedoraproject.org>
	<497F6256.5000504@leemhuis.info>
Message-ID: <497F66B3.1000607@fedoraproject.org>

Thorsten Leemhuis wrote:
> On 27.01.2009 20:12, Rahul Sundaram wrote:
>> Thorsten Leemhuis wrote:
>>
>>> Don't we have way to many guidelines and policies already?
>> This is a very minor addition to an existing set of guidelines.
> 
> Well, those minor additions in different places sum up over time.

It does but in this case, a existing set of guidelines already exist and 
are relatively well known. Scattering information across more pages is 
not very helpful, I think but point noted. Let's leave room for other 
feedback on the content itself and I will let FESCo decide where to 
place it.

Rahul






From jkeating at redhat.com  Tue Jan 27 19:59:28 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 11:59:28 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <497F654A.7090503@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
Message-ID: <1233086368.8363.210.camel@localhost.localdomain>

On Tue, 2009-01-27 at 20:49 +0100, Thorsten Leemhuis wrote:
>  
> Whatever:  I don't care much about this specific set of rules. It just 
> seems to me a general trend that more and more rules and guidelines are 
> put into place in Fedora-land; and more and more work is outsourced onto 
> the packagers. Sure, some of the rules and the outsourcing is needed -- 
> but I find this trend very alarming.

The alarming trend is the folks who won't do things, unless there is a
guideline for them.  I hate having an abundance of guidlines just like
you do, however almost all the recent guidelines have been done in
reaction to a lack of people following "best practices".  Ergo we create
guidelines to /help/ people understand what those best practices are.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/0141e178/attachment.sig>

From oliver at linux-kernel.at  Tue Jan 27 19:58:07 2009
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 27 Jan 2009 20:58:07 +0100
Subject: AW: 2009-01-29 - Fedora Test Day - Text-mode install removal
Message-ID: <200901271957.n0RJvY05018479@mail.linux-kernel.at>

As long as you don't break text mode installs on Alpha I'm OK with simplifications... :-)
If you break it -> Lot of bugzillas :-)

And, I think it already has reduced functionality, right?

-of

----- Urspr?ngliche Nachricht -----
Von: James Laska <jlaska at redhat.com>
Gesendet: Dienstag, 27. Januar 2009 20:43
An: fedora-test-list at redhat.com
Cc: fedora-devel-announce at redhat.com
Betreff: 2009-01-29 - Fedora Test Day - Text-mode install removal

Greetings,

Okay now that I got your attention.  Don't worry, text-mode is not going
away.  But in order to simplify maintenance it will be greatly reduced
in terms of functionality. =20

I'd like to invite testers and users to join #fedora-qa this Thursday,
January 29, 2009.  Test efforts will focus on:

 * anaconda text-mode simplification
 * Fedora 11 Alpha

Come with questions and/or suggested test areas.

More details will be posted to
https://fedoraproject.org/wiki/QA/Test_Days/2009-01-29.

Hope to see you there,
James





From oliver at linux-kernel.at  Tue Jan 27 19:58:07 2009
From: oliver at linux-kernel.at (Oliver Falk)
Date: Tue, 27 Jan 2009 20:58:07 +0100
Subject: AW: 2009-01-29 - Fedora Test Day - Text-mode install removal
Message-ID: <200901271957.n0RJvY05018479@mail.linux-kernel.at>

As long as you don't break text mode installs on Alpha I'm OK with simplifications... :-)
If you break it -> Lot of bugzillas :-)

And, I think it already has reduced functionality, right?

-of

----- Urspr?ngliche Nachricht -----
Von: James Laska <jlaska at redhat.com>
Gesendet: Dienstag, 27. Januar 2009 20:43
An: fedora-test-list at redhat.com
Cc: fedora-devel-announce at redhat.com
Betreff: 2009-01-29 - Fedora Test Day - Text-mode install removal

Greetings,

Okay now that I got your attention.  Don't worry, text-mode is not going
away.  But in order to simplify maintenance it will be greatly reduced
in terms of functionality. =20

I'd like to invite testers and users to join #fedora-qa this Thursday,
January 29, 2009.  Test efforts will focus on:

 * anaconda text-mode simplification
 * Fedora 11 Alpha

Come with questions and/or suggested test areas.

More details will be posted to
https://fedoraproject.org/wiki/QA/Test_Days/2009-01-29.

Hope to see you there,
James





From jwboyer at gmail.com  Tue Jan 27 20:02:08 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Tue, 27 Jan 2009 15:02:08 -0500
Subject: Fedora 11 Alpha Status
In-Reply-To: <1233080567.8363.202.camel@localhost.localdomain>
References: <1233080567.8363.202.camel@localhost.localdomain>
Message-ID: <20090127200208.GA808@yoda.jdub.homelinux.org>

On Tue, Jan 27, 2009 at 10:22:47AM -0800, Jesse Keating wrote:
>Last night we refreshed the alpha freeze (see koji tag f11-alpha-2).
>This will be the content we're using for the Alpha, provided our testing
>is successful.  Anything else added will only be for critical path
>items, that is the path to install, boot, obtain network, and update.
>If a reasonable workaround is found for a problem in that path, the work
>around will be advertised rather than respinning the Alpha.
>
>Today's rawhide is not functional due to some changes in createrepo/yum.
>Newer builds of these packages have been made and tested and added to
>the new alpha tag, so tomorrow's rawhide is a bit closer to what the
>Alpha will be.
>
>We hope to have the alpha fully composed by midday tomorrow and on its
>way to mirrors for staging.  I'll announce when this happens.  Release
>date is still planned for Tuesday, February 3rd.

Oh, and PowerPC may or may not be available.  The squashfs-tools issue
that was blocking things last week was fixed upstream (awesome) but there
has been little testing done on the results yet.

josh



From nicolas.mailhot at laposte.net  Tue Jan 27 20:17:45 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Jan 2009 21:17:45 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F654A.7090503@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
Message-ID: <1233087465.9693.10.camel@arekh.okg>

Le mardi 27 janvier 2009 ? 20:49 +0100, Thorsten Leemhuis a ?crit :

> Whatever:  I don't care much about this specific set of rules. It just 
> seems to me a general trend that more and more rules and guidelines are 
> put into place in Fedora-land; and more and more work is outsourced onto 
> the packagers. Sure, some of the rules and the outsourcing is needed -- 
> but I find this trend very alarming.

This is a natural effect of the distribution growth. To reach a
particular size you need more people and to manage more people of uneven
experience you need more documents and procedures.

However, the primary target of any new guideline should be to avoid
unnecessary work at some level, increase efficiency, and permit more
growth, not add another source of inefficiencies to an already stressed
organisation.

Thus, if the aim is to limit needless pushes to stable (+10), I'd favour
a simple wording that says so plainly, instead of hiding behind a
complex "fill comments" page that will be at best ignored (and at worst
tragically misunderstood).

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/85a5ad62/attachment.sig>

From jspaleta at gmail.com  Tue Jan 27 20:20:42 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 27 Jan 2009 11:20:42 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <497F654A.7090503@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
Message-ID: <604aa7910901271220q63e58100h70c0570d5989a83f@mail.gmail.com>

On Tue, Jan 27, 2009 at 10:49 AM, Thorsten Leemhuis
<fedora at leemhuis.info> wrote:
> Well, we have done fine without special rules for update text many years now
> afaics. So why do we need them now? Why can't "best practises" do, if it
> worked fine for so many years?

Has it worked fine?  I've no way to really measure whether the
introduction of any optional "best practice" has resulted in a more
consistent packaging landscape. Do the documentation of best practises
as non-mandatory suggestions on workflow materially help the
consistency of the packaging quality?  I don't know, I've seen no
supporting evidence either way.

Historically, guidance has evolved to addressed identified
deficiencies, has it not? We don't really know if this is the best
approach, but to suggest things have been working is to discount every
single complaint that has resulted in a guidance change.  I don't
think you are making a self-consistent argument.   The fact that
guidance is evolving is a reaction to identified deficiencies.  What I
don't know really is if we've gotten to the point with guidance that
we are chasing down problems that are in the random noise of human
error.
In this case are we talking about guidance to address 10% of the updates? 30%?
How widespread does a problem need to be before we make packager wide guidance?
I don't know.

>
> Whatever:  I don't care much about this specific set of rules. It just seems
> to me a general trend that more and more rules and guidelines are put into
> place in Fedora-land; and more and more work is outsourced onto the
> packagers. Sure, some of the rules and the outsourcing is needed -- but I
> find this trend very alarming.

You'd probably make more sense to me if you were arguing about a set
of rules you do care about.  I would appreciate it if you would limit
using the word trend to describe something that can be depicted
quantitatively on a graph.  I would love to be able to trend the
impact of best practise documentation and guidance, but we don't
really have any quantifiable metrics here at all.

But here's something we can graph.  How has our contributor growth
month-to-month  release-cycle to release cycle looked like?  I think
we could probably did that out of fas.
Is our rate of contributor growth slowing?

-jef



From fedora at leemhuis.info  Tue Jan 27 20:20:54 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Tue, 27 Jan 2009 21:20:54 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233086368.8363.210.camel@localhost.localdomain>
References: <497F5005.4060107@fedoraproject.org>	<497F56A8.7010803@leemhuis.info>	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>	<497F654A.7090503@leemhuis.info>
	<1233086368.8363.210.camel@localhost.localdomain>
Message-ID: <497F6CA6.4070802@leemhuis.info>

On 27.01.2009 20:59, Jesse Keating wrote:
> On Tue, 2009-01-27 at 20:49 +0100, Thorsten Leemhuis wrote:
>> Whatever:  I don't care much about this specific set of rules. It just 
>> seems to me a general trend that more and more rules and guidelines are 
>> put into place in Fedora-land; and more and more work is outsourced onto 
>> the packagers. Sure, some of the rules and the outsourcing is needed -- 
>> but I find this trend very alarming.
> The alarming trend is the folks who won't do things, unless there is a
> guideline for them.  I hate having an abundance of guidlines just like
> you do, however almost all the recent guidelines have been done in
> reaction to a lack of people following "best practices".  

I know, I know.

> Ergo we create
> guidelines to /help/ people understand what those best practices are.

At least in this case I don't really understand why. Bodhi should simply 
enforce all of those rules/guidelines/best practices that were in the 
draf. Then the packager doesn't need to learn and remember those 
rules/guidelines/best practices.

Example with the first point from the draft:

> * All Updates must refer to a upstream changelog or equivalent if one 
> exists. Otherwise a brief description (a couple of sentence at most)
> justifying the need for an update must be provided by the maintainers 
> pushing the update.

Add a text fiel in bodhi with that text above/beneath it; require that 
this text-filed is filled (maybe even do some basic sanity checks). Then 
this point gets automatically enforced and the packagers doesn't have to 
remember or look up what to do exactly. That's not only easier, but 
likely leads to better results and better quality of the data.

And even better: if that rule need to be adjusted that you can just 
update the text in bodhi and add a small highlight button that says 
"Updated recently" -- then most packagers will learn the new way 
automatically.

Cu
knurd

P.S.: Enough said. I'll try to stay away from this thread now.



From cweyl at alumni.drew.edu  Tue Jan 27 20:24:22 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:24:22 -0800
Subject: how to show upstream changes to the user
In-Reply-To: <1233054273.3687.76.camel@eagle.danny.cz>
References: <1233045561.3687.37.camel@eagle.danny.cz>
	<alpine.DEB.1.10.0901271213570.8659@gotcha.dreamhost.com>
	<1233054273.3687.76.camel@eagle.danny.cz>
Message-ID: <7dd7ab490901271224u5f0433a5t266216990977251b@mail.gmail.com>

On Tue, Jan 27, 2009 at 3:04 AM, Dan Hor?k <dan at danny.cz> wrote:
>
> The keyword should be "automation". Why to copy&paste when it can be
> done by script. I can imagine a "hidden" field in spec (special comment
> like #changelog: http://....) that is transformed into a field in bodhi.
> It can be a macro in spec that gets evaluated before including in bodhi,
> etc.

Hmm, you know, one of the things the CPAN does [1] is to pull out any
README and META.yml the package contains...  While we don't need
either of those, and given how changelogs tend to fit a fairly regular
naming scheme (e.g. Changes, ChangeLog, various case permutations,
etc), why not emulate this as part of the update process?

e.g.

1) a scanning of the package for matching filenames, preference to
those under the %_docdir; if none found generate a dummy changelog
2) normalizing of the names and hosting somewhere (e.g.
Http://..../changelogs/Changes.packagename-x.y.z-rel
3) update the gui tool to display the link to this changelog as well
as the URL to the project, with something like "the changelog for this
release is at <above url>; you may find additional information at the
project homepage <rpm url tag>."

This will make it easy to get this information into people's hands and
is fully automateable.

                        -Chris

[1] Which has been around WAY longer than rpm, possibly even Linux, if
memory serves.
--
Chris Weyl
Ex astris, scientia



From nicolas.mailhot at laposte.net  Tue Jan 27 20:25:52 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Jan 2009 21:25:52 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <20090127194353.GC18789@amd.home.annexia.org>
References: <497F5005.4060107@fedoraproject.org>
	<20090127194353.GC18789@amd.home.annexia.org>
Message-ID: <1233087952.9693.18.camel@arekh.okg>

Le mardi 27 janvier 2009 ? 19:43 +0000, Richard W.M. Jones a ?crit :
> On Tue, Jan 27, 2009 at 11:48:45PM +0530, Rahul Sundaram wrote:
> > * All Updates must refer to a upstream changelog or equivalent if one  
> > exists. Otherwise a brief description (a couple of sentence at most)  
> > justifying the need for an update must be provided by the maintainers  
> > pushing the update.
> 
> I'm happy this applies only to released versions of Fedora[1].  But I
> think this should also exclude 'newpackage' updates explicitly (ie.
> where a new package is added to a released version of Fedora).

Since some people insist a simple package renaming creates a new
package, that must be audited to death, when we still have not finished
doing fedora core merge reviews, and accept to continue carry years of
legacy cruft in some historic Red Hat packages, I vigorously object to
this proposal.

Instead of requiring new levels of over-pure whiteness of new packages,
please focus on how the existing morass can be improved.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/4f12912f/attachment.sig>

From cweyl at alumni.drew.edu  Tue Jan 27 20:27:19 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:27:19 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <7dd7ab490901271227l32cd325dt2ab04a7728472a7d@mail.gmail.com>

On Tue, Jan 27, 2009 at 10:18 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Hi,
>
> The following are a set of simple guidelines for the update descriptions via
> bodhi (which is used by PackageKit to inform users of what has changed).
> These guidelines are intended to help end users understand the nature of
> changes in the update better. Bodhi is not used in rawhide, so these
> guidelines are not applicable for rawhide updates. Note that this is not
> connected to the rpm changelog.

-1.  Yet another manual task of admittedly "questionable value" being
imposed on our volunteers.

                         -Chris
-- 
Chris Weyl
Ex astris, scientia



From nicolas.mailhot at laposte.net  Tue Jan 27 20:28:54 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 27 Jan 2009 21:28:54 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233087952.9693.18.camel@arekh.okg>
References: <497F5005.4060107@fedoraproject.org>
	<20090127194353.GC18789@amd.home.annexia.org>
	<1233087952.9693.18.camel@arekh.okg>
Message-ID: <1233088134.9693.20.camel@arekh.okg>

Le mardi 27 janvier 2009 ? 21:25 +0100, Nicolas Mailhot a ?crit :
> Le mardi 27 janvier 2009 ? 19:43 +0000, Richard W.M. Jones a ?crit :
> > On Tue, Jan 27, 2009 at 11:48:45PM +0530, Rahul Sundaram wrote:
> > > * All Updates must refer to a upstream changelog or equivalent if one  
> > > exists. Otherwise a brief description (a couple of sentence at most)  
> > > justifying the need for an update must be provided by the maintainers  
> > > pushing the update.
> > 
> > I'm happy this applies only to released versions of Fedora[1].  But I
> > think this should also exclude 'newpackage' updates explicitly (ie.
> > where a new package is added to a released version of Fedora).
> 
> Since some people insist a simple package renaming creates a new
> package, that must be audited to death, when we still have not finished
> doing fedora core merge reviews, and accept to continue carry years of
> legacy cruft in some historic Red Hat packages, I vigorously object to
> this proposal.

(if this section is not added). Though if it needs to be added, that
means yet another level of complexity to manage

> 
> Instead of requiring new levels of over-pure whiteness of new packages,
> please focus on how the existing morass can be improved.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/f18a127f/attachment.sig>

From cweyl at alumni.drew.edu  Tue Jan 27 20:30:17 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:30:17 -0800
Subject: Lack of update information
In-Reply-To: <glmitr$uvt$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
	<7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
	<glmitr$uvt$1@ger.gmane.org>
Message-ID: <7dd7ab490901271230n5ae22c78ga374945ee80577ba@mail.gmail.com>

On Tue, Jan 27, 2009 at 1:08 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Chris Weyl wrote:
>> And all obviated by Fedora policy and practice: we expressly give and
>> expect maintainers to exercise their judgement here.
>
> Yes, we let maintainers decide when to push updates, and that's a good
> thing. But is it really so hard to write one or two sentences explaining
> why your decided that way and what other changes to expect? For me it was
> always just a matter of seconds for the updates I submitted. Some users
> (like me) want to know what they're getting in an update. I still end up
> installing them all unless something is known broken, but that doesn't mean
> I don't want to know what I'm getting.

Neither is it difficult to rig something to point automatically at an
included package changelog.  Before we mandate a new manual task,
can't we at least try an automated approach first?

                              -Chris
-- 
Chris Weyl
Ex astris, scientia



From robert at fedoraproject.org  Tue Jan 27 20:08:54 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Tue, 27 Jan 2009 21:08:54 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F654A.7090503@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
Message-ID: <20090127200854.GA10997@hurricane.linuxnetz.de>

On Tue, 27 Jan 2009, Thorsten Leemhuis wrote:
> Whatever:  I don't care much about this specific set of rules. It just  
> seems to me a general trend that more and more rules and guidelines are  
> put into place in Fedora-land; and more and more work is outsourced onto  
> the packagers. Sure, some of the rules and the outsourcing is needed --  
> but I find this trend very alarming.

We've much rules and we're extending it all the time. We _maybe_ increase
thereby the quality, but to new packagers, that's a lot to read, understand
and to handle. I definately will expect, if we drive that road further on,
new packagers won't join us because of frustration how complicated we are.
And as we enforce some of our "Guidelines" as rules and policy...well.

Why don't we simply make Bodhi more packager friendly? Why do we really
need a guideline rather solving the problem at its cause: Bodhi. Can't we
request all the needed information more packager friendly? Why can't we ask
for bug reports, CVEs, upstream changelog, links, summary/fazit or similar
things explicitly? Currently, we have two or three input fields and that's
it. If we solve things with guidelines rather taking really care of it and
solving it on the right end, we're doing something very wrong.


Greetings,
  Robert



From cweyl at alumni.drew.edu  Tue Jan 27 20:35:46 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:35:46 -0800
Subject: Lack of update information
In-Reply-To: <1233077514.8363.188.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<1233006941.8363.161.camel@localhost.localdomain>
	<7dd7ab490901261407n346b5aa8h8e2b241f67b9987b@mail.gmail.com>
	<1233008041.8363.162.camel@localhost.localdomain>
	<7dd7ab490901261817p309c061dl98edbc9ec254ba4e@mail.gmail.com>
	<1233077514.8363.188.camel@localhost.localdomain>
Message-ID: <7dd7ab490901271235r6de637bdq4ad774339bc2067b@mail.gmail.com>

2009/1/27 Jesse Keating <jkeating at redhat.com>:
> On Mon, 2009-01-26 at 18:17 -0800, Chris Weyl wrote:
>>  Yes, actually I did.  Perhaps I misunderstood your meaning here: are
>> you saying that it's policy in Fedora that a maintainer should not
>> keep their packages up to date in the best fashion that their
>> judgement suggests, in line with the above?
>
> No, I'm trying to illustrate that there is a difference between
> "tracking upstream" and making judgment calls on proper updates for a
> release, and in fact we have policy about it.

Obviously there's a difference; but just because two things are
different doesn't mean they can't be done concomitantly, or that
they're mutally exclusive.  e.g. I can eat both an apple and an
orange.

                            -Chris
-- 
Chris Weyl
Ex astris, scientia



From cweyl at alumni.drew.edu  Tue Jan 27 20:38:57 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:38:57 -0800
Subject: Lack of update information
In-Reply-To: <497EC8E5.3000607@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
Message-ID: <7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>

On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Chris Weyl wrote:
>> Not to be blunt, but "too bad".  That's why we're called
>> "maintainers", and they are "end users".
>
> Maintainers are supposed to serve and meet end user needs and not the other
> way around.

That would be completely true IF we were being paid for this;
otherwise we have to acknowledge that it's a matter of enlightened
self-interest to contribute.  Right?

                              -Chris
-- 
Chris Weyl
Ex astris, scientia



From jkeating at redhat.com  Tue Jan 27 20:37:55 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 12:37:55 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <497F6CA6.4070802@leemhuis.info>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
	<1233086368.8363.210.camel@localhost.localdomain>
	<497F6CA6.4070802@leemhuis.info>
Message-ID: <1233088675.8363.215.camel@localhost.localdomain>

On Tue, 2009-01-27 at 21:20 +0100, Thorsten Leemhuis wrote:
>  
> Add a text fiel in bodhi with that text above/beneath it; require that 
> this text-filed is filled (maybe even do some basic sanity checks). Then 
> this point gets automatically enforced and the packagers doesn't have to 
> remember or look up what to do exactly. That's not only easier, but 
> likely leads to better results and better quality of the data.
> 
> And even better: if that rule need to be adjusted that you can just 
> update the text in bodhi and add a small highlight button that says 
> "Updated recently" -- then most packagers will learn the new way 
> automatically.
> 
> Cu
> knurd
> 
> P.S.: Enough said. I'll try to stay away from this thread now.

Why stay away?  These are good suggestions and they should be
considered.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/926406f6/attachment.sig>

From denis at poolshark.org  Tue Jan 27 20:44:58 2009
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 27 Jan 2009 21:44:58 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <497F724A.7000006@poolshark.org>

Rahul Sundaram wrote:
> * All Updates must refer to a upstream changelog or equivalent if one 
> exists. Otherwise a brief description (a couple of sentence at most) 
> justifying the need for an update must be provided by the maintainers 
> pushing the update.

-1

This is borderline insane.

Also this draft should be written by somebody who has significant 
packaging experience.



From sundaram at fedoraproject.org  Tue Jan 27 20:51:44 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 02:21:44 +0530
Subject: Lack of update information
In-Reply-To: <7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>
	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
Message-ID: <497F73E0.1030109@fedoraproject.org>

Chris Weyl wrote:
> On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
> <sundaram at fedoraproject.org> wrote:
>> Chris Weyl wrote:
>>> Not to be blunt, but "too bad".  That's why we're called
>>> "maintainers", and they are "end users".
>> Maintainers are supposed to serve and meet end user needs and not the other
>> way around.
> 
> That would be completely true IF we were being paid for this;
> otherwise we have to acknowledge that it's a matter of enlightened
> self-interest to contribute.  Right?

False dichotomy.

Regardless of whether you are paid to do it or not, you are there to 
meet users and community needs. I would argue more so, if you are 
volunteer since the people who are doing it just because they are 
getting paid are doing it for the money instead of the users. I don't 
think anybody in the Fedora community is that way.

If you don't even want to try, you might as well as stop doing it and 
enlightened self interest isn't incompatible with serving users needs at 
all. In fact, your enlightened self interest must compel you to work 
together with other contributors to do a good job of it instead of 
excusing yourself because you are volunteer just like the majority in 
this community.

If you read the guidelines, they are very simple common sense items that 
package maintainers have been expected to follow all along. I am merely 
documenting them for everybody's benefit especially new maintainers.

Rahul



From cweyl at alumni.drew.edu  Tue Jan 27 20:59:21 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 12:59:21 -0800
Subject: Lack of update information
In-Reply-To: <497F73E0.1030109@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
Message-ID: <7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>

On Tue, Jan 27, 2009 at 12:51 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Chris Weyl wrote:
>>
>> On Tue, Jan 27, 2009 at 12:42 AM, Rahul Sundaram
>> <sundaram at fedoraproject.org> wrote:
>>>
>>> Chris Weyl wrote:
>>>>
>>>> Not to be blunt, but "too bad".  That's why we're called
>>>> "maintainers", and they are "end users".
>>>
>>> Maintainers are supposed to serve and meet end user needs and not the
>>> other
>>> way around.
>>
>> That would be completely true IF we were being paid for this;
>> otherwise we have to acknowledge that it's a matter of enlightened
>> self-interest to contribute.  Right?
>
> False dichotomy.
>
> Regardless of whether you are paid to do it or not, you are there to meet
> users and community needs. I would argue more so, if you are volunteer since
> the people who are doing it just because they are getting paid are doing it
> for the money instead of the users. I don't think anybody in the Fedora
> community is that way.
>
> If you don't even want to try, you might as well as stop doing it and
> enlightened self interest isn't incompatible with serving users needs at
> all. In fact, your enlightened self interest must compel you to work
> together with other contributors to do a good job of it instead of excusing
> yourself because you are volunteer just like the majority in this community.
>
> If you read the guidelines, they are very simple common sense items that
> package maintainers have been expected to follow all along. I am merely
> documenting them for everybody's benefit especially new maintainers.

Of course we're here to meet users needs, but WE are those users as
well... and we're putting ourselves in a bad spot when we forget that.

I'm not sure what this "if you don't even want to try" bit is about,
since this isn't about me, it's about imposing another manual task on
our maintainers.  Arguing against that isn't not working "together
with other contributors", it's discussing how we can make use of those
limited resources.  Every little thing may seem reasonable, but then,
that's also what they thought about the DMV.

I do read the guidelines, and while there are MANY of them, they tend
to make sense, and where I don't think they do, I still respect them.
I don't think you're "merely documenting them" here, however; this is
_clearly_ a new task being discussed.

                        -Chris
-- 
Chris Weyl
Ex astris, scientia



From sundaram at fedoraproject.org  Tue Jan 27 21:10:39 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 02:40:39 +0530
Subject: Lack of update information
In-Reply-To: <7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>	<497EC8E5.3000607@fedoraproject.org>	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
Message-ID: <497F784F.8040507@fedoraproject.org>

Chris Weyl wrote:

> Of course we're here to meet users needs, but WE are those users as
> well... and we're putting ourselves in a bad spot when we forget that.

We are largely meeting needs other than ourselves though. Volunteer or 
not has nothing to do with it.

> I'm not sure what this "if you don't even want to try" bit is about,
> since this isn't about me, it's about imposing another manual task on
> our maintainers.

> I do read the guidelines, and while there are MANY of them, they tend
> to make sense, and where I don't think they do, I still respect them.

No. Don't do that. If you don't think anything doesn't make sense, ask 
questions. We don't need to blindly respect anything.

> I don't think you're "merely documenting them" here, however; this is
> _clearly_ a new task being discussed.

I don't think so. Bodhi description fields have been considered 
mandatory and filling them has always been a manual task. People just 
assumed, everyone would know what to fill it with. That hasn't worked 
out very well for us and has been a common question as well in 
#fedora-devel. By documenting them, we get that knowledge more easily 
preserved.

Rahul



From dtimms at iinet.net.au  Tue Jan 27 21:10:26 2009
From: dtimms at iinet.net.au (David Timms)
Date: Wed, 28 Jan 2009 08:10:26 +1100
Subject: Attn FESco:  Non-Responsive Maintainer - John Berninger
In-Reply-To: <loom.20090126T205342-438@post.gmane.org>
References: <loom.20090126T205342-438@post.gmane.org>
Message-ID: <497F7842.40306@iinet.net.au>

Cry wrote:
> Per the Fedora Non-Responsive Maintainer Policy at:
> 
> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
> 
>     * After another 7 days (now 3 weeks total), the reporter posts a formal
Given that this time of year in some places is the long holiday period, 
ending within a week or so, perhaps it's worth holding off for another 
week ?



From rjones at redhat.com  Tue Jan 27 21:12:24 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Tue, 27 Jan 2009 21:12:24 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <1233087952.9693.18.camel@arekh.okg>
References: <497F5005.4060107@fedoraproject.org>
	<20090127194353.GC18789@amd.home.annexia.org>
	<1233087952.9693.18.camel@arekh.okg>
Message-ID: <20090127211224.GA19378@amd.home.annexia.org>

On Tue, Jan 27, 2009 at 09:25:52PM +0100, Nicolas Mailhot wrote:
> Instead of requiring new levels of over-pure whiteness of new packages,
> please focus on how the existing morass can be improved.

I think you're right on the money here.

But we can learn from Debian.  Debian rebuild the whole repository
continuously, so that FTBFS bugs are found earlier.  More importantly
they run scripts over existing packages to identify bugs (packages
which are not consistent with the guidelines) and are not afraid to
raise mass-bugs about them.

For example:

 - packages that fail lintian checks (the Debian equivalent of rpmlint)
 - scripts which check licenses on individual source files in each
   package
 - checks which look for MIA packagers (who haven't responded to bug
   reports for years for example)
 - file conflicts

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 dennis at ausil.us  Tue Jan 27 21:16:54 2009
From: dennis at ausil.us (Dennis Gilmore)
Date: Tue, 27 Jan 2009 15:16:54 -0600
Subject: 2009-01-29 - Fedora Test Day - Text-mode install removal
In-Reply-To: <1233085397.3427.88.camel@localhost.localdomain>
References: <1233085397.3427.88.camel@localhost.localdomain>
Message-ID: <200901271516.54781.dennis@ausil.us>

On Tuesday 27 January 2009 01:43:17 pm James Laska wrote:
> Greetings,
>
> Okay now that I got your attention.  Don't worry, text-mode is not going
> away.  But in order to simplify maintenance it will be greatly reduced
> in terms of functionality.
>
> I'd like to invite testers and users to join #fedora-qa this Thursday,
> January 29, 2009.  Test efforts will focus on:
>
>  * anaconda text-mode simplification
>  * Fedora 11 Alpha
>
> Come with questions and/or suggested test areas.
>
> More details will be posted to
> https://fedoraproject.org/wiki/QA/Test_Days/2009-01-29.
>
> Hope to see you there,
> James
Many secondary arches only can install via text mode.  the functionality that 
currently exists Really needs to remain. there are enough limitations in it 
already  vnc is not always a practical method of install.

Dennis



From limb at jcomserv.net  Tue Jan 27 21:17:52 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Tue, 27 Jan 2009 15:17:52 -0600 (CST)
Subject: Attn FESco:  Non-Responsive Maintainer - John Berninger
In-Reply-To: <497F7842.40306@iinet.net.au>
References: <loom.20090126T205342-438@post.gmane.org>
	<497F7842.40306@iinet.net.au>
Message-ID: <208ca55b75abd41916d7c086981f9f26.squirrel@mail.jcomserv.net>


> Cry wrote:
>> Per the Fedora Non-Responsive Maintainer Policy at:
>>
>> https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers
>>
>>     * After another 7 days (now 3 weeks total), the reporter posts a
>> formal
> Given that this time of year in some places is the long holiday period,
> ending within a week or so, perhaps it's worth holding off for another
> week ?

+1.  Just in case.  But things were sorta dry before that. . .

> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From denis at poolshark.org  Tue Jan 27 21:18:38 2009
From: denis at poolshark.org (Denis Leroy)
Date: Tue, 27 Jan 2009 22:18:38 +0100
Subject: Lack of update information
In-Reply-To: <glmjkr$uvt$3@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<497E503C.8090400@poolshark.org> <glmjkr$uvt$3@ger.gmane.org>
Message-ID: <497F7A2E.90509@poolshark.org>

Kevin Kofler wrote:
> Denis Leroy wrote:
>> I find it unreasonable to ask of package maintainers to take the role of
>> technical writers.
> 
> Oh come on, writing a couple of sentences to explain what's new and why it's
> being pushed doesn't need a technical writer at all.

Ok, here's a little exercise :-)

Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a 
while ago. How would you summarize it to Bodhi ?


---------------------------------------------------------------------------------
2.15.0:

2009-01-01  Murray Cumming  <murrayc at murrayc.com>

	* gtk/src/cellrendererpixbuf.hg: Added the icon-name and follow-state
	properties, noticed by Mathias Hasselmann.

2009-01-01  Armin Burgmeier  <armin at openismus.com>

	* gtk/src/printer.ccg (SignalProxy_Custom_gtk_callback): Take a new
	reference on the passed printer object, so that we don't unref it at
	the end of the function (Tor Krill).

2008-12-22  Murray Cumming  <murrayc at murrayc.com>

	* gdk/src/gdk_docs_override.xml: Correct the documentation for
	gdk_window_invalidate_rect() to remove C-specific text.
	* gdk/src/window.ccg:
	* gdk/src/window.hg: Added an invalidate() that takes no rect
	parameter because it can be NULL in C.

2008-12-10 Przemys?aw Grzegorczyk  <pgrzegorczyk at gmail.com>

	* Cleaned up gtk includes to use only toplevel headers
	Bug #564006

2008-12-08  Murray Cumming  <murrayc at murrayc.com>

	* gtk/src/treemodel.hg: set_value_impl() documentation: Mention
	row_changed(), not set_row_changed().
	Bug #562505 (Bohumir Zamecnik)

2008-12-06  Murray Cumming  <murrayc at murrayc.com>

	* gtk/src/container.hg:
	* gtk/src/gtk_vfuncs.defs: Use GType instead of GtkType for the
	child_type_vfunc() return type, because that seems to have changed in
	GTK+ and GtkType is deprecated.	Likewise, use GDestroyNotify in other
	vfuncs instead of GtkDestroyNotify.
	This should allow soure code to use gtkmm if it declares
	GTK_DISABLE_DEPRECATED.
	Bug #562893 (D?nes Faluv?gi)

2008-11-18  Murray Cumming  <murrayc at murrayc.com>

	* configure.in:
	* docs/FAQ/Makefile.am:
	* docs/FAQ/gtkmm-faq.xml:
	* docs/Makefile.am: Remove the FAQ because we moved it to
	gtkmm-documentation months ago.

2008-11-14  Murray Cumming  <murrayc at murrayc.com>

	* gtk/src/gtk_signals.defs: Restored the GtkHandleBox::child-attached
	signal definition and the GtkLinkButton::visited property definition,
	so these are really put in the API. At some point in 2.14.x we lost
	these.

2008-11-09  Alexander Shaduri  <ashaduri at gmail.com>

	* gtk/src/cellview.ccg:
	* gtk/src/cellview.hg: Added unset_model().

	* gtk/src/combobox.ccg:
	* gtk/src/combobox.hg: Added unset_model().

	* gtk/src/entrycompletion.ccg:
	* gtk/src/entrycompletion.hg: Added unset_model().

	* gtk/src/iconview.ccg:
	* gtk/src/iconview.hg: Added unset_model().

	* gtk/src/treeview.hg: Marked unset_model() as available since 2.8.

	* gtk/src/gtk_docs_override.xml: Added overrides for
	gtk_tree_view_set_model(), gtk_cell_view_set_model(),
	gtk_entry_completion_set_model(), gtk_entry_completion_set_model()
	and gtk_combo_box_set_model(), because their documentation
	contained an incorrect method of unsetting the models.
	Bug #555268

This is trunk for API additions. See also the gtkmm-2-14 branch.



From sundaram at fedoraproject.org  Tue Jan 27 21:19:38 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 02:49:38 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <497F724A.7000006@poolshark.org>
References: <497F5005.4060107@fedoraproject.org>
	<497F724A.7000006@poolshark.org>
Message-ID: <497F7A6A.8070800@fedoraproject.org>

Denis Leroy wrote:
> Rahul Sundaram wrote:
>> * All Updates must refer to a upstream changelog or equivalent if one 
>> exists. Otherwise a brief description (a couple of sentence at most) 
>> justifying the need for an update must be provided by the maintainers 
>> pushing the update.
> 
> -1
> 
> This is borderline insane.

There is no voting. That is left to FESCo and you are not being specific.

> Also this draft should be written by somebody who has significant 
> packaging experience.

This is a mix of assumptions, elitism and my dad is taller than yours 
territory. Keep the feedback constructive and focus on the proposal 
rather than the proposer. Thanks.

Rahul




From mclasen at redhat.com  Tue Jan 27 21:24:44 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Tue, 27 Jan 2009 16:24:44 -0500
Subject: Lack of update information
In-Reply-To: <497F7A2E.90509@poolshark.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>  <497F7A2E.90509@poolshark.org>
Message-ID: <1233091484.3180.12.camel@matthiasc>

On Tue, 2009-01-27 at 22:18 +0100, Denis Leroy wrote:
> Kevin Kofler wrote:
> > Denis Leroy wrote:
> >> I find it unreasonable to ask of package maintainers to take the role of
> >> technical writers.
> > 
> > Oh come on, writing a couple of sentences to explain what's new and why it's
> > being pushed doesn't need a technical writer at all.
> 
> Ok, here's a little exercise :-)
> 
> Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a 
> while ago. How would you summarize it to Bodhi ?
> 

Update to 2.15.0 

:-)

On a more serious note, I tend to look at release announcements / NEWS
files when I try to collect update information for new releases. Proper
releases should have the user-relevant information about the new release
in those places, as opposed to all the minutiae in the ChangeLog...



From clumens at redhat.com  Tue Jan 27 21:32:24 2009
From: clumens at redhat.com (Chris Lumens)
Date: Tue, 27 Jan 2009 16:32:24 -0500
Subject: 2009-01-29 - Fedora Test Day - Text-mode install removal
In-Reply-To: <200901271516.54781.dennis@ausil.us>
References: <1233085397.3427.88.camel@localhost.localdomain>
	<200901271516.54781.dennis@ausil.us>
Message-ID: <20090127213223.GC7491@localhost.localdomain>

> Many secondary arches only can install via text mode.  the functionality that 
> currently exists Really needs to remain. there are enough limitations in it 
> already  vnc is not always a practical method of install.

"Removal" is a bad word to use here, and was only used to get your
attention.

- Chris



From drago01 at gmail.com  Tue Jan 27 21:35:25 2009
From: drago01 at gmail.com (drago01)
Date: Tue, 27 Jan 2009 22:35:25 +0100
Subject: Lack of update information
In-Reply-To: <1232989018.8363.143.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
Message-ID: <f6ca9fed0901271335h5135161dl8cacd36e1d8d4cb@mail.gmail.com>

2009/1/26 Jesse Keating <jkeating at redhat.com>:
> On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
>> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
>> > Rahul Sundaram pisze:
>> >> Hi,
>> >>
>> >> A while back, I tried to selectively update some packages and noticed
>> >> that the update information provided by package maintainers (seen via
>> >> PackageKit) is sorely lacking.
>> >>
>> >> * Update foo to upstream 2.16.2
>> >[..]
>> > Btw, how about pulling the data from spec %changelog automatically?
>>
>> Well in most cases the changelog will just contain the same "update to x.y.z"
>> For some packages the changes just aren't  worth listing.
>> For example each iw release only contain minor changes, people that
>> really care about them know how to look it up.
>> I could also just add "Small fixes and minor updates from upstream"
>> but that's the same as "Update to x.y.z".
>> Copying the upstream changelog, that must people do not understand
>> does not help either.
>
> If they're really such minor and uninteresting changes, why push them
> out to users?  Why consume infrastructure resources to build, releng
> resources to sign and push, bandwidth resources to mirror, bandwidth
> resources and cpu resources on the clients to consume the metadata, and
> cpu / disk resources on the clients to do the update?
>
> If you don't have anything interesting to say about the update, maybe
> you shouldn't be pushing the update at all.

To keep it in sync with upstream, if a update does not hurt end user
(fix small bugs, add features etc) there is no reason to hold it
unless it breaks something.
For example this update allows the user to see if the wireless card
really runs in 802.11n mode (legacy tools like iwconfig does not know
about it).

Sure I should have mentioned this in the text, but for a package with
small changes like this I just bump the release from time to time.
(And no I do not push it once upstream releases a new version but I
just resync with upstream from time to time).



From drago01 at gmail.com  Tue Jan 27 21:40:16 2009
From: drago01 at gmail.com (drago01)
Date: Tue, 27 Jan 2009 22:40:16 +0100
Subject: Lack of update information
In-Reply-To: <1232993629.28200.16.camel@code.and.org>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232993629.28200.16.camel@code.and.org>
Message-ID: <f6ca9fed0901271340q331596a1m6ef8fec501d19ea8@mail.gmail.com>

On Mon, Jan 26, 2009 at 7:13 PM, James Antill <james at fedoraproject.org> wrote:
> On Mon, 2009-01-26 at 09:28 +0100, drago01 wrote:
>> On Mon, Jan 26, 2009 at 9:16 AM, Julian Sikorski <belegdol at gmail.com> wrote:
>> > Rahul Sundaram pisze:
>> >> Hi,
>> >>
>> >> A while back, I tried to selectively update some packages and noticed
>> >> that the update information provided by package maintainers (seen via
>> >> PackageKit) is sorely lacking.
>> >>
>> >> * Update foo to upstream 2.16.2
>> >[..]
>> > Btw, how about pulling the data from spec %changelog automatically?
>>
>> Well in most cases the changelog will just contain the same "update to x.y.z"
>> For some packages the changes just aren't  worth listing.
>> For example each iw release only contain minor changes, people that
>> really care about them know how to look it up.
>> I could also just add "Small fixes and minor updates from upstream"
>> but that's the same as "Update to x.y.z".
>
>  It's the same _to you_, because you know that there are only some minor
> number of fixes. But for almost anyone not you it could mean:
>
> . fix for specific bug
>
> . minor fixes
>
> . minor fixes and minor feature or two
>
> . minor fixes and one huge new feature
>
> . lots of new features
>
> ...so putting the longer form in there helps everyone else.
>

OK, you (and Jesse) have valid points, will be more verbose in the future.

Note: For packages that have interesting changes I already *do* put
the info into the update, so its not like I always do "update to
x.y.z"



From aa.lucelio at gmail.com  Tue Jan 27 21:56:09 2009
From: aa.lucelio at gmail.com (=?ISO-8859-1?Q?Luc=E9lio_Gomes_de_Freitas?=)
Date: Tue, 27 Jan 2009 19:56:09 -0200
Subject: 2009-01-29 - Fedora Test Day - Text-mode install removal
In-Reply-To: <200901271516.54781.dennis@ausil.us>
References: <1233085397.3427.88.camel@localhost.localdomain>
	<200901271516.54781.dennis@ausil.us>
Message-ID: <f4a59ea0901271356j33906fatc3e1302ab25a07a0@mail.gmail.com>

James,

I know you are kidding, but don't end with one emmergency door.   As Dennis
said:
The functionality that currently exists, really needs to remain.   Let it
sleeping, but there.
I know how it works, start kidding and then....

See you there,
Luc?lio.

2009/1/27 Dennis Gilmore <dennis at ausil.us>

> On Tuesday 27 January 2009 01:43:17 pm James Laska wrote:
> > Greetings,
> >
> > Okay now that I got your attention.  Don't worry, text-mode is not going
> > away.  But in order to simplify maintenance it will be greatly reduced
> > in terms of functionality.
> >
> > I'd like to invite testers and users to join #fedora-qa this Thursday,
> > January 29, 2009.  Test efforts will focus on:
> >
> >  * anaconda text-mode simplification
> >  * Fedora 11 Alpha
> >
> > Come with questions and/or suggested test areas.
> >
> > More details will be posted to
> > https://fedoraproject.org/wiki/QA/Test_Days/2009-01-29.
> >
> > Hope to see you there,
> > James
> Many secondary arches only can install via text mode.  the functionality
> that
> currently exists Really needs to remain. there are enough limitations in it
> already  vnc is not always a practical method of install.
>
> Dennis
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/5a0c6bed/attachment.htm>

From robert at fedoraproject.org  Tue Jan 27 21:42:52 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Tue, 27 Jan 2009 22:42:52 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F7A6A.8070800@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
	<497F724A.7000006@poolshark.org>
	<497F7A6A.8070800@fedoraproject.org>
Message-ID: <20090127214252.GA21679@hurricane.linuxnetz.de>

On Wed, 28 Jan 2009, Rahul Sundaram wrote:
>> -1
>>
>> This is borderline insane.
>
> There is no voting. That is left to FESCo and you are not being specific.

We're not at FESCo here, we're at a mailing list. Or is there a Guideline
aka best practice which is not suggesting us doing so?


Greetings,
  Robert



From peter.hutterer at who-t.net  Tue Jan 27 22:06:05 2009
From: peter.hutterer at who-t.net (Peter Hutterer)
Date: Wed, 28 Jan 2009 08:06:05 +1000
Subject: xorg.conf - what to do for an input device
In-Reply-To: <68720af30901270434x77514343k7cafcad425092e78@mail.gmail.com>
References: <68720af30901241043i14c73e9fp41a1b489674898e7@mail.gmail.com>
	<91705d080901241135x641e051ayffc0c33553d38100@mail.gmail.com>
	<68720af30901241149k4dfac4e0n66b42af0f3e5a6ba@mail.gmail.com>
	<91705d080901241217y24fad04ekb7114480943291a5@mail.gmail.com>
	<68720af30901241604l3352d6cay3f1d793b898ee6b8@mail.gmail.com>
	<68720af30901250859n4123e06ei93149febddb824e2@mail.gmail.com>
	<20090127120337.GB7569@who-t.net>
	<68720af30901270434x77514343k7cafcad425092e78@mail.gmail.com>
Message-ID: <20090127220605.GB6635@who-t.net>

On Tue, Jan 27, 2009 at 10:34:47AM -0200, Paulo Cavalcanti wrote:
> > On Sun, Jan 25, 2009 at 02:59:56PM -0200, Paulo Cavalcanti wrote:
> > > Well, I finished and I included a hal rule for loading wizardpen in xorg
> > > 1.5.3
> > >
> > > The spec file is here:
> > >
> > > http://people.atrpms.net/~pcavalcanti/specs/wizardpen.spec<http://people.atrpms.net/%7Epcavalcanti/specs/wizardpen.spec>
> > >
> > > Do you think that would be any interest in having wizardpen in Fedora?
> >
> > our current long-term approach is to get support for input devices into the
> > kernel and then let evdev deal with it automagically*. The times when X
> > needed
> > a separate driver for each device are gone and the sooner we forget about
> > it,
> > the happier we'll be.
> >
> > Cheers,
> >  Peter
> >
> > * doesn't work with all devices yet, but evdev is moving fast and is easy
> > enough to hack on.
> >
> 
> 
> evdev used to be easier, but it is not accepting the device identification
> by name anymore. One has to use /dev/input/by-id/ or /dev/input/by-path.
> And what about bluetooth devices? Would you know where can I get
> its identification?

if the kernel driver works for the device, HAL should provide the device file
and other information (the name for example) to the server. Check the output
of lshal, you can then merge custom options by adding/modifying an fdi file in
/usr/share/hal/fdi/policies/...
(no, storing input configuration in fdi files is not the best solution, but
the best we have ATM)
 
Cheers,
  Peter



From sundaram at fedoraproject.org  Tue Jan 27 22:05:37 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 03:35:37 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090127214252.GA21679@hurricane.linuxnetz.de>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>
	<20090127214252.GA21679@hurricane.linuxnetz.de>
Message-ID: <497F8531.3070203@fedoraproject.org>

Robert Scheck wrote:
> On Wed, 28 Jan 2009, Rahul Sundaram wrote:
>>> -1
>>>
>>> This is borderline insane.
>> There is no voting. That is left to FESCo and you are not being specific.
> 
> We're not at FESCo here, we're at a mailing list. Or is there a Guideline
> aka best practice which is not suggesting us doing so?

Sure, the best practise would be to give specific feedback as requested 
explicitly but the mailing list guidelines doesn't cover this. Use your 
best judgement ;-)

Rahul



From jkeating at redhat.com  Tue Jan 27 22:20:14 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 14:20:14 -0800
Subject: Lack of update information
In-Reply-To: <f6ca9fed0901271335h5135161dl8cacd36e1d8d4cb@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<f6ca9fed0901271335h5135161dl8cacd36e1d8d4cb@mail.gmail.com>
Message-ID: <1233094814.8363.217.camel@localhost.localdomain>

On Tue, 2009-01-27 at 22:35 +0100, drago01 wrote:
>  To keep it in sync with upstream, if a update does not hurt end user
> (fix small bugs, add features etc) there is no reason to hold it
> unless it breaks something.
> For example this update allows the user to see if the wireless card
> really runs in 802.11n mode (legacy tools like iwconfig does not know
> about it).
> 
> Sure I should have mentioned this in the text, but for a package with
> small changes like this I just bump the release from time to time.
> (And no I do not push it once upstream releases a new version but I
> just resync with upstream from time to time).

Had you put that information in, users of updates-testing could actually
report whether that change was successful or not, given the wide variety
of wireless drivers out there that people are using.  Is that not useful
feedback for upstream?  Maybe something in our kernels isn't enabled for
this to work, or some other distro specific side effect.  If the users
don't know what to expect/test, how can they ever provide relevant
feedback?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/9c2092ac/attachment.sig>

From cweyl at alumni.drew.edu  Tue Jan 27 22:22:26 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 14:22:26 -0800
Subject: Lack of update information
In-Reply-To: <497F784F.8040507@fedoraproject.org>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
Message-ID: <7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>

On Tue, Jan 27, 2009 at 1:10 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Chris Weyl wrote:
>
>> Of course we're here to meet users needs, but WE are those users as
>> well... and we're putting ourselves in a bad spot when we forget that.
>
> We are largely meeting needs other than ourselves though. Volunteer or not
> has nothing to do with it.

Really?  If your management came to you and said that it's a condition
of employment that you fill out daily TPS reports in blood while
standing on your head, with the economy the way it is they could
probably do it.  Try that with a volunteer.

>> I'm not sure what this "if you don't even want to try" bit is about,
>> since this isn't about me, it's about imposing another manual task on
>> our maintainers.
>
>> I do read the guidelines, and while there are MANY of them, they tend
>> to make sense, and where I don't think they do, I still respect them.
>
> No. Don't do that. If you don't think anything doesn't make sense, ask
> questions. We don't need to blindly respect anything.

I ... I'm not even going to respond to that.

>> I don't think you're "merely documenting them" here, however; this is
>> _clearly_ a new task being discussed.
>
> I don't think so. Bodhi description fields have been considered mandatory
> and filling them has always been a manual task. People just assumed,
> everyone would know what to fill it with. That hasn't worked out very well
> for us and has been a common question as well in #fedora-devel. By
> documenting them, we get that knowledge more easily preserved.

Really?  Filling in that field has always been manual? hm. Funny this
works then:

    bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make verrel`

                    -Chris

-- 
Chris Weyl
Ex astris, scientia



From jkeating at redhat.com  Tue Jan 27 22:31:11 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 14:31:11 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
Message-ID: <1233095471.8363.219.camel@localhost.localdomain>

On Tue, 2009-01-27 at 14:22 -0800, Chris Weyl wrote:
>  Really?  Filling in that field has always been manual? hm. Funny this
> works then:
> 
>     bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
> verrel`

You're just being difficult to be difficult.  You could also come up
with a way to script against the web interface, but at the end of the
day, the contents of the notes section have to be generated somewhere.
Bodhi doesn't generate them itself.  That's the point that rahul was
making.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/4a622174/attachment.sig>

From cweyl at alumni.drew.edu  Tue Jan 27 22:38:59 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 14:38:59 -0800
Subject: Lack of update information
In-Reply-To: <1233095471.8363.219.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
	<1233095471.8363.219.camel@localhost.localdomain>
Message-ID: <7dd7ab490901271438h25c45d5ay41d9e09e29cd266b@mail.gmail.com>

2009/1/27 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2009-01-27 at 14:22 -0800, Chris Weyl wrote:
>>  Really?  Filling in that field has always been manual? hm. Funny this
>> works then:
>>
>>     bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
>> verrel`
>
> You're just being difficult to be difficult.  You could also come up
> with a way to script against the web interface, but at the end of the
> day, the contents of the notes section have to be generated somewhere.
> Bodhi doesn't generate them itself.  That's the point that rahul was
> making.

If "being difficult to be difficult" means "showing a counter-example
to something stated as fact", then, alright, that's me.

Bodhi doesn't generate them itself, but neither does it have to be a
manual task.  Reusing existing information through automation
effectively negates that; much like pointing at existing upstream
changelogs would negate having to regurgiate them somewhere else.

                           -Chris
-- 
Chris Weyl
Ex astris, scientia



From jkeating at redhat.com  Tue Jan 27 22:41:37 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Tue, 27 Jan 2009 14:41:37 -0800
Subject: Lack of update information
In-Reply-To: <7dd7ab490901271438h25c45d5ay41d9e09e29cd266b@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
	<1233095471.8363.219.camel@localhost.localdomain>
	<7dd7ab490901271438h25c45d5ay41d9e09e29cd266b@mail.gmail.com>
Message-ID: <1233096097.8363.221.camel@localhost.localdomain>

On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
>  If "being difficult to be difficult" means "showing a counter-example
> to something stated as fact", then, alright, that's me.
> 
> Bodhi doesn't generate them itself, but neither does it have to be a
> manual task.  Reusing existing information through automation
> effectively negates that; much like pointing at existing upstream
> changelogs would negate having to regurgiate them somewhere else.

You're just nit-picking raul's use of the term 'manual'.  Rahul meant
(correct me if I'm wrong here rahul) that bodhi doesn't self generate
that information.  Period.  Do you dispute that?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090127/9b567fa2/attachment.sig>

From cweyl at alumni.drew.edu  Wed Jan 28 00:18:53 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Tue, 27 Jan 2009 16:18:53 -0800
Subject: Lack of update information
In-Reply-To: <1233096097.8363.221.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
	<1233095471.8363.219.camel@localhost.localdomain>
	<7dd7ab490901271438h25c45d5ay41d9e09e29cd266b@mail.gmail.com>
	<1233096097.8363.221.camel@localhost.localdomain>
Message-ID: <7dd7ab490901271618h2e2cb6e8y75189cb00a60e8d@mail.gmail.com>

2009/1/27 Jesse Keating <jkeating at redhat.com>:
> On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
>>  If "being difficult to be difficult" means "showing a counter-example
>> to something stated as fact", then, alright, that's me.
>>
>> Bodhi doesn't generate them itself, but neither does it have to be a
>> manual task.  Reusing existing information through automation
>> effectively negates that; much like pointing at existing upstream
>> changelogs would negate having to regurgiate them somewhere else.
>
> You're just nit-picking raul's use of the term 'manual'.  Rahul meant
> (correct me if I'm wrong here rahul) that bodhi doesn't self generate
> that information.  Period.  Do you dispute that?

"Bodhi description fields have been considered mandatory and filling
them has always been a manual task."

I'm pretty sure the plain meaning of "manual task" is "manual task".
As I can't read minds, I can't tell you what he meant, but I can read
what he wrote.

                 -Chris
-- 
Chris Weyl
Ex astris, scientia



From kanarip at kanarip.com  Wed Jan 28 00:36:00 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Wed, 28 Jan 2009 01:36:00 +0100
Subject: Call for Ruby package maintainer
In-Reply-To: <20090127.150412.1090654878994195729.tagoh@redhat.com>
References: <20090127.150412.1090654878994195729.tagoh@redhat.com>
Message-ID: <497FA870.2030806@kanarip.com>

Akira TAGOH wrote:
> Hi,
> 
> I'm still trying to have a time to work on our ruby package,
> but failing so far. so I'm considering to find any good
> person out to work on that to make it better. I could work
> together as co-maintainer though, please let me know if
> anyone is interested in and can actively maintain.
> 

Are you talking ruby itself, or just "a" ruby package?

-Jeroen



From michel.sylvan at gmail.com  Wed Jan 28 00:50:03 2009
From: michel.sylvan at gmail.com (Michel Salim)
Date: Tue, 27 Jan 2009 19:50:03 -0500
Subject: Problems with ssh-add
In-Reply-To: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>
References: <200901250213.n0P2D15G002523@laptop14.inf.utfsm.cl>
Message-ID: <f224c6140901271650i27f9a9a4ra3fdc6469c741e25@mail.gmail.com>

On Sat, Jan 24, 2009 at 9:13 PM, Horst H. von Brand
<vonbrand at inf.utfsm.cl> wrote:
> Rawhide x86_64 Gnome
>
> For something like a week now each time I run ssh-add it works fine, but
> then trying to use the ssh key ssh complains
>
>  $ ssh quelen.inf.utfsm.cl
>  Error reading response length from authentication socket.
>  vonbrand at quelen.inf.utfsm.cl's password:
>
> After that, ssh just asks for the password, and:
>
>  $ ssh-add
>  Could not open a connection to your authentication agent.
>
I can confirm this. gnome-keyring-daemon dies after that, and the
error is reproducible if g-k-d is then restarted, and the environment
variables updated by hand.

Reverting to 2.25.4.2 fixes the problem:
http://koji.fedoraproject.org/koji/buildinfo?buildID=77797

I've opened a Bugzilla ticket for this problem here:
https://bugzilla.redhat.com/show_bug.cgi?id=482778

-- 
mi?el salim  ?  http://hircus.jaiku.com/
IUCS         ?  msalim at cs.indiana.edu
Fedora       ?  salimma at fedoraproject.org
MacPorts     ?  hircus at macports.org



From vonbrand at inf.utfsm.cl  Wed Jan 28 01:14:32 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Tue, 27 Jan 2009 22:14:32 -0300
Subject: Lack of update information
In-Reply-To: <55317f8f412c6f53bf7f862189311213.squirrel@arekh.dyndns.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<497E503C.8090400@poolshark.org> <glmjkr$uvt$3@ger.gmane.org>
	<55317f8f412c6f53bf7f862189311213.squirrel@arekh.dyndns.org>
Message-ID: <200901280114.n0S1EWSi009801@laptop14.inf.utfsm.cl>

Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:

[...]

> Again, the value of this information is limited at best and only
> concerns a very small user minority that both speaks English and
> understands technical jargon (ie, not a lot of people). Even those who
> have some grasp of English would usually not be able to parse it!

But those people are almost exactly the ones interested in that
information. To do anything at all in <name technical field here> today,
English (at least simple technical English) is a must.
-- 
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 pbrobinson at gmail.com  Wed Jan 28 02:16:06 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 28 Jan 2009 03:16:06 +0100
Subject: Moblin 2 and Fedora
Message-ID: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>

Hi All,

I noticed Intel has announced [1] the first alpha of Moblin 2 which
from memory and by the look of it is based on Fedora [2].

I'm wondering what the outcome of the discussions with them was about
basing it on upstream Fedora and if anyone knows what the differences
are between the source repos [2] and that of base Fedora are?

Cheers,
Peter

[1] http://moblin.org/community/blogs/tshureih/2009/announcing-moblin-v2-core-alpha-release
[2] http://repo.moblin.org/moblin/releases/test/alpha1/



From itamar at ispbrasil.com.br  Wed Jan 28 03:00:36 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 28 Jan 2009 01:00:36 -0200
Subject: where are the ss5 maintaner ?
In-Reply-To: <497D65AA.1070609@fedoraproject.org>
References: <d3ceea380901241551j5d090739i5f2eb2c391486aaa@mail.gmail.com>
	<497D65AA.1070609@fedoraproject.org>
Message-ID: <d3ceea380901271900s65240fe3w791d6daf2e2cb57a@mail.gmail.com>

I have mailed it several times, with no answer.


On Mon, Jan 26, 2009 at 5:26 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Itamar Reis Peixoto wrote:
>>
>> where are the ss5 maintainer ?
>>
>>
>> https://admin.fedoraproject.org/pkgdb/packages/bugs/ss5
>
> Every maintainer automatically has a <package>-owner AT fedoraproject.org
> alias to reach them. You can also query buggybot in #fedora-devel
>
>
> Rahul
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From rc040203 at freenet.de  Wed Jan 28 04:31:59 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Jan 2009 05:31:59 +0100
Subject: Lack of update information
In-Reply-To: <1233078115.8363.194.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>	<1233013714.8363.167.camel@localhost.localdomain>	<497E53E3.1060302@freenet.de>	<1233017758.8363.183.camel@localhost.localdomain>	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
Message-ID: <497FDFBF.4070209@freenet.de>

Jesse Keating wrote:
> On Tue, 2009-01-27 at 03:11 +0100, Ralf Corsepius wrote:
>> Jesse Keating wrote:
>>> On Tue, 2009-01-27 at 01:22 +0100, Ralf Corsepius wrote:
>>>>  The problem with this: Users don't notice the cases in which upgrades 
>>>> "simply work" - They only notice the case, something already has gone wrong.
>>> Many users notice a plethora of updates for unknown reasons that chew up
>>> their bandwidth, cpu, and disk time while they're just trying to get
>>> work done.  So much so that many opt out of applying updates at all,
>>> because there are so many of them, which hurts our abilities to deliver
>>> security updates.
>> These problems do not originate from the number of upgrades/update, they 
>> originate from the _size_ of updates few packages introduce.
> 
> Size is in direct correlation to number.
With all due respect, Mr. Keating, this is non-sense.

One update to openoffice/evolution/kde/gnome/kernel or some game's data 
outweighs many other packages.

>>> and with new expensive fast hardware
>>> may not see a problem. 
>> Well, I would label this an urban legend - Updating recent Fedoras using 
>> yum has not been much of a performance problem, even on slower and older 
>> HW (e.g. a 1GHz i686/512MB)
>>
>> Admitted, on an 64MB/166MHz i586 w/Fedora 10 yum updates tend to be 
>> "really slow".
> 
> Try doing updates on a netbook, 
I own one - Typical "yum update" times are in the order of "very few" 
minutes at average.

Example from a couple minutes ago (comprising kernel/kernel-devel, 
PackageKit, selinux-policy and some rpmfusion updates - 20 packages in 
total; Using local (fast) mirrors):

# cat /proc/cpuinfo
..
model name	: Intel(R) Atom(TM) CPU N270   @ 1.60GHz
..

# time yum -y update
...
real	7m48.916s
user	4m50.155s
sys	0m57.314s

Not fast, but hardly a serious problem.

On an i586, the times requires for yum updates are much higher 
(typically hours), times on old i686's are in the order of several 10 
minutes.

> or any other system with relatively slow
> "disk" I/O, or "slow" CPU.

The cases I mention are real - I do own such machines.

On these, the real yum update related problems are bandwidth and 
disk-space requirements (yum-caches).

PackageKit's GUI and parsing activities adds further (quite measurable) 
requirements on CPU-power and RAM.

>  Yum isn't really the problem here, it's the
> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
> hardlinking, etc... 

 From what I experience, SELinux policy updates are by far means the 
most resource intense/most time consuming part of updating.

>> However, wrt. to bandwidth, I see another problem: Your strategy of 
>> pushing updates in "big batches", instead of "small chunks".
>>
>> This makes a significant difference to users with limited bandwidth. 
>> While they could easily poll "small chunks", e.g. once a day (blocking 
>> their network for, e.g. 1 hour), the current strategy would block they 
>> network for very much longer (e.g. 7 hours).
> 
> If I were to push updates once a day, the mirrors would be in shambles,
I can't prove nor counter-prove this claim, but I doubt that this would 
make much of a difference.

> constantly trying to pick up the new content and users would have a
> terrible experience.  Pushing updates faster doesn't magically make the
> number of updates get smaller.

On the end-user's side it makes a substantial difference if whether one
of your "big pushes" blocks a machine/network for the whole day,
or whether a "yum update" finishes during a "work break".

>> Another aspect related to bandwidth: Revisiting
>> * the sizes of rpms (e.g. different payload compressors).
>> * differential updates/rpms.
>>
>> Seems to me as if these once "hot topics" have dropped off the Fedora 
>> radar, in favor of "strangling/nagging the distro's contributors".
>>
>> Ralf
>>
> 
> People are working on both of the above issues.
Really? I doubt your claim. At least I am not aware of any activities in 
RH's rpm to change rpm's payload rsp. to perform measurements on the 
impact of using modern compressors on rpm-payloads.


Ralf



From skvidal at fedoraproject.org  Wed Jan 28 04:40:12 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Tue, 27 Jan 2009 23:40:12 -0500
Subject: Lack of update information
In-Reply-To: <497FDFBF.4070209@freenet.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de>
Message-ID: <1233117612.14094.83.camel@rosebud>

On Wed, 2009-01-28 at 05:31 +0100, Ralf Corsepius wrote:

> On an i586, the times requires for yum updates are much higher 
> (typically hours), times on old i686's are in the order of several 10 
> minutes.

Any idea how much of the i586 transaction time is swapping?



> > 
> > People are working on both of the above issues.
> Really? I doubt your claim. At least I am not aware of any activities in 
> RH's rpm to change rpm's payload rsp. to perform measurements on the 
> impact of using modern compressors on rpm-payloads.

well one of the memory intensive portions of the transaction is being
worked on. The file fingerprinting. Additionally, Panu noticed an issue
when you test a transaction then turn around and run that transaction.
For odd reasons the memory size gets much bigger.

-sv




From jonstanley at gmail.com  Wed Jan 28 05:46:01 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Wed, 28 Jan 2009 00:46:01 -0500
Subject: Attn FESco: Non-Responsive Maintainer - John Berninger
In-Reply-To: <208ca55b75abd41916d7c086981f9f26.squirrel@mail.jcomserv.net>
References: <loom.20090126T205342-438@post.gmane.org>
	<497F7842.40306@iinet.net.au>
	<208ca55b75abd41916d7c086981f9f26.squirrel@mail.jcomserv.net>
Message-ID: <da159fda0901272146k2ceee8b1q246ff08d7ec3e9f3@mail.gmail.com>

On Tue, Jan 27, 2009 at 4:17 PM, Jon Ciesla <limb at jcomserv.net> wrote:

> +1.  Just in case.  But things were sorta dry before that. . .

Well, this isn't the first time that we've had this discussion, see
https://www.redhat.com/archives/fedora-devel-list/2008-December/msg00237.html
for more, but I'm sure all involved remember :)

I'm fine with waiting however long folks feel is appropriate though.
I'd take Bugzilla, but I'm not a perl expert (or even novice really),
so I don't think I'd be the right person for that job :)

I'd also like to start a discussion of what happens when someone is
declared non-responsive.  Do we remove them from the packager group?
AFAIK, there's no policy around that, packages just get orphaned.

I'll start a new thread on that topic, though.



From fedora at leemhuis.info  Wed Jan 28 05:55:52 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 28 Jan 2009 06:55:52 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233088675.8363.215.camel@localhost.localdomain>
References: <497F5005.4060107@fedoraproject.org>	<497F56A8.7010803@leemhuis.info>	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>	<497F654A.7090503@leemhuis.info>	<1233086368.8363.210.camel@localhost.localdomain>	<497F6CA6.4070802@leemhuis.info>
	<1233088675.8363.215.camel@localhost.localdomain>
Message-ID: <497FF368.8050101@leemhuis.info>

On 27.01.2009 21:37, Jesse Keating wrote:
> On Tue, 2009-01-27 at 21:20 +0100, Thorsten Leemhuis wrote:
>> P.S.: Enough said. I'll try to stay away from this thread now.
> Why stay away?

Maybe because I'm either getting to old for this sort of discussions.

But I guess the real answer is: Fedora is more and more transforming 
into something I don't feel part of; something I don't want to spend my 
spare time on(?).

That's sad, as I invested a good bunch of my spare time on Fedora over 
the past five or six years, but I guess it might be time to look out for 
something else to spend my time on.

> These are good suggestions and they should be considered.

In that case I'll hope they will be considered without me fighting for 
them endlessly in mailing lists discussions.

CU
knurd

(?) I could write a detailed explanation why I feel like that. Does 
anyone want one? But well, I guess writing one is burning time, as it 
likely won't change anything.



From nicolas.mailhot at laposte.net  Wed Jan 28 06:05:57 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 28 Jan 2009 07:05:57 +0100
Subject: Lack of update information
In-Reply-To: <200901280114.n0S1EWSi009801@laptop14.inf.utfsm.cl>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>
	<55317f8f412c6f53bf7f862189311213.squirrel@arekh.dyndns.org>
	<200901280114.n0S1EWSi009801@laptop14.inf.utfsm.cl>
Message-ID: <1233122757.486.3.camel@arekh.okg>

Le mardi 27 janvier 2009 ? 22:14 -0300, Horst H. von Brand a ?crit :
> Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> 
> [...]
> 
> > Again, the value of this information is limited at best and only
> > concerns a very small user minority that both speaks English and
> > understands technical jargon (ie, not a lot of people). Even those who
> > have some grasp of English would usually not be able to parse it!
> 
> But those people are almost exactly the ones interested in that
> information. To do anything at all in <name technical field here> today,
> English (at least simple technical English) is a must.

You seriously need to take some distance. The kind of English you'll
find in those notifications is totally foreign and useless to the vast
majority of our user base. It's not technical English it's pure CS
jargon very few people speak.

A very small minority may be able to parse it, but a versy small
minority is not a sufficient reason to impose this burden on packagers.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/2be30201/attachment.sig>

From sundaram at fedoraproject.org  Wed Jan 28 07:43:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 13:13:41 +0530
Subject: Lack of update information
In-Reply-To: <1233096097.8363.221.camel@localhost.localdomain>
References: <497D6B24.8050702@fedoraproject.org>	<497E1AE9.20606@fedoraproject.org>	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>	<497EC8E5.3000607@fedoraproject.org>	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>	<497F73E0.1030109@fedoraproject.org>	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>	<497F784F.8040507@fedoraproject.org>	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>	<1233095471.8363.219.camel@localhost.localdomain>	<7dd7ab490901271438h25c45d5ay41d9e09e29cd266b@mail.gmail.com>
	<1233096097.8363.221.camel@localhost.localdomain>
Message-ID: <49800CAD.3080201@fedoraproject.org>

Jesse Keating wrote:
> On Tue, 2009-01-27 at 14:38 -0800, Chris Weyl wrote:
>>  If "being difficult to be difficult" means "showing a counter-example
>> to something stated as fact", then, alright, that's me.
>>
>> Bodhi doesn't generate them itself, but neither does it have to be a
>> manual task.  Reusing existing information through automation
>> effectively negates that; much like pointing at existing upstream
>> changelogs would negate having to regurgiate them somewhere else.
> 
> You're just nit-picking raul's use of the term 'manual'.  Rahul meant
> (correct me if I'm wrong here rahul) that bodhi doesn't self generate
> that information.  Period.  

Correct. Scripting doesn't change that. It just makes it easier.

Rahul



From pronix.service at gmail.com  Wed Jan 28 07:51:53 2009
From: pronix.service at gmail.com (=?UTF-8?B?0JLQsNGB0LjQu9C10YYg0JTQvNC40YLRgNC40Lk=?=)
Date: Wed, 28 Jan 2009 10:51:53 +0300
Subject: Call for Ruby package maintainer
In-Reply-To: <497FA870.2030806@kanarip.com>
References: <20090127.150412.1090654878994195729.tagoh@redhat.com>
	<497FA870.2030806@kanarip.com>
Message-ID: <639ce0480901272351y3e9a7dd8ra8774ec50c584504@mail.gmail.com>

hello
it is interesting for me
what must i do ?

2009/1/28 Jeroen van Meeuwen <kanarip at kanarip.com>:
> Akira TAGOH wrote:
>>
>> Hi,
>>
>> I'm still trying to have a time to work on our ruby package,
>> but failing so far. so I'm considering to find any good
>> person out to work on that to make it better. I could work
>> together as co-maintainer though, please let me know if
>> anyone is interested in and can actively maintain.
>>
>
> Are you talking ruby itself, or just "a" ruby package?
>
> -Jeroen
>
> --
> 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  Wed Jan 28 07:58:20 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Wed, 28 Jan 2009 07:58:20 +0000 (UTC)
Subject: rawhide report: 20090128 changes
Message-ID: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>

Compose started at Wed Jan 28 06:01:02 UTC 2009

Broken deps for i386
----------------------------------------------------------
	compat-gda-ldap-1.2.4-1.fc7.i386 requires libldap-2.3.so.0
	compat-gda-ldap-1.2.4-1.fc7.i386 requires liblber-2.3.so.0
	compat-gda-mysql-1.2.4-1.fc7.i386 requires libmysqlclient.so.10
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	compat-gda-ldap-1.2.4-1.fc7.x86_64 requires libldap-2.3.so.0()(64bit)
	compat-gda-ldap-1.2.4-1.fc7.x86_64 requires liblber-2.3.so.0()(64bit)
	compat-gda-mysql-1.2.4-1.fc7.x86_64 requires libmysqlclient.so.10()(64bit)
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	pam_mount-1.4-2.fc11.i386 requires libHX.so.14
	pam_mount-1.4-2.fc11.x86_64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.i386 requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.x86_64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	compat-gda-ldap-1.2.4-1.fc7.ppc requires libldap-2.3.so.0
	compat-gda-ldap-1.2.4-1.fc7.ppc requires liblber-2.3.so.0
	compat-gda-mysql-1.2.4-1.fc7.ppc requires libmysqlclient.so.10
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15
	gammu-1.22.1-2.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgda-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgdasql-3.0.so.3
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgda-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdasql-3.0.so.3
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	pam_mount-1.4-2.fc11.ppc requires libHX.so.14
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	qof-0.7.5-3.fc10.ppc requires libgdasql-3.0.so.3
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	eclipse-linuxprofilingframework-0.1.0-0.1.fc11.noarch requires eclipse-cdt >= 1:4.0.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gammu-1.22.1-2.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgda-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgdasql-3.0.so.3()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgda-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdasql-3.0.so.3()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	pam_mount-1.4-2.fc11.ppc64 requires libHX.so.14()(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	qof-0.7.5-3.fc10.ppc64 requires libgdasql-3.0.so.3()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From j.w.r.degoede at hhs.nl  Wed Jan 28 08:03:41 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Wed, 28 Jan 2009 09:03:41 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <1233084071.19014.36.camel@localhost.localdomain>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<glg41r$dp7$1@ger.gmane.org>
	<1233084071.19014.36.camel@localhost.localdomain>
Message-ID: <4980115D.7070808@hhs.nl>

Callum Lerwick wrote:
> On Sat, 2009-01-24 at 23:17 +0100, Kevin Kofler wrote:
>> That said, it's a tough topic, because regressions tend to really annoy
>> people, they feel "WTF, this always worked, WhyTF is it no longer working
>> now?", even though from a purely practical point of view, unfixed bugs (and
>> not working on some hardware is practically speaking a bug, even though
>> technically it's a missing feature) are much worse because there's no
>> working build to revert to.
> 
> Your logic is flawed. People with not yet supported hardware, can find
> supported hardware, or live with workarounds like VESA. You can not make
> progress by accepting regressions. At best, you are spinning your wheels
> in place, at worst you are taking one step forward and two steps back.
> Regression means just that, you are regressing. Fedora is about
> progress, not regress. The linux kernel has a rather strict
> no-regressions policy, for good reason:
> 
> http://lwn.net/Articles/261713/
> 
> I wish Xorg and Fedora as a whole, would adopt a similar policy. I'm
> very unhappy with how the Xorg update went in F10. Just when we started
> getting reliable, usable open source OpenGL, F10 came along and broke
> *everything*:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=474977
> https://bugzilla.redhat.com/show_bug.cgi?id=441665
> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
> 
> Not a single one of my machines works out of the box like they did in
> F9, they all need work-arounds. But OpenGL support has been quite
> thoroughly broken. This has pretty well fucked any ability to get back
> to working on Second Life:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=233946
> 
> I have Shit To Do, and it looks like I'm going to have to revert my
> entire Xorg back to F9 to do it.
> 

Yes that is what I've done too (revert back to F-9 Xorg), even though I've been 
actively working with airlied (congrats with your kid once more) to get things 
in shape for F-10 and I believe we are in ok shape wrt 2d in F-10 3d is simply 
not usable in F-10, and since I maintain many games in Fedora I need working 3d.

Regards,

Hans



From rc040203 at freenet.de  Wed Jan 28 08:06:19 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Jan 2009 09:06:19 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <498011FB.6060809@freenet.de>

Rahul Sundaram wrote:
> Hi,
> 
> The following are a set of simple guidelines for the update descriptions 
> via bodhi (which is used by PackageKit to inform users of what has 
> changed). These guidelines are intended to help end users understand the 
> nature of changes in the update better. Bodhi is not used in rawhide, so 
> these guidelines are not applicable for rawhide updates. Note that this 
> is not connected to the rpm changelog.
-1, simply nuts



From rc040203 at freenet.de  Wed Jan 28 09:11:42 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Jan 2009 10:11:42 +0100
Subject: Lack of update information
In-Reply-To: <1233117612.14094.83.camel@rosebud>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<gllh0a$ha1$1@ger.gmane.org>	<1233013714.8363.167.camel@localhost.localdomain>	<497E53E3.1060302@freenet.de>	<1233017758.8363.183.camel@localhost.localdomain>	<497E6D62.4060708@freenet.de>	<1233078115.8363.194.camel@localhost.localdomain>	<497FDFBF.4070209@freenet.de>
	<1233117612.14094.83.camel@rosebud>
Message-ID: <4980214E.7060005@freenet.de>

seth vidal wrote:
> On Wed, 2009-01-28 at 05:31 +0100, Ralf Corsepius wrote:
> 
>> On an i586, the times requires for yum updates are much higher 
>> (typically hours), times on old i686's are in the order of several 10 
>> minutes.
> 
> Any idea how much of the i586 transaction time is swapping?
Likely much of it, however I have no idea on how to measure it ;)


Anyway, FWIW, here is a short protocol of a yum update session on this 
machine (performed in recent hours):

* System i586MMX/166MHz, 64MB RAM, 2GB IDE HD.
# cat /proc/cpuinfo
..
vendor_id	: GenuineIntel
cpu family	: 5
model		: 4
model name	: Pentium MMX
stepping	: 4
cpu MHz		: 166.653
..

# cat /proc/meminfo
..
MemTotal:        59264 kB
..
SwapTotal:      131064 kB
..

* SELinux is disabled[1]
* System is running Fedora 10 in runlevel 3, with "top" in a shell on 
vt1 and running "yum update" in an ssh-login from a remote machine.
* Active repos: fedora, updates.


Observations on swap and yum's memory usage:
* no swapping until yum reports "Setting up Update Process"
* During "Setting up Update Process", yum's "VIRT mem" gradually crawls up.
* At "Transaction Summary"/"Is this OK?", yum's "VIRT mem" has reached 
ca. 64MB/ca. 40MB swap is in use.
* No substantial changes to memory/swap during "Downloading Packages"
* During "Running rpm_check_debug", yum's "VIRT mem" increases to ca. 
73MB, using ca. 44MB swap.
* During "Running Transaction Test", yum's "VIRT mem" swings in the 
70-76MB range. During all this, "swap in use" is gradually increases to 
ca. 54MB.
* During "Running Transaction", yum's "VIRT mem" swings in the same 
range, "swap in use" increases to 56MB.
* When the actual installation starts, yum's "VIRT mem" stays near 74MB, 
while "swap in use" swings at a +/-20MB applitude around ca. 65MB [3][4].
* During "cleanup" yum's "VIRT mem" reaches 78MB, while swap stays near 
65MB.

Observations on times being required (wall-clock measured):
* Time until "Is this OK?" had been ca. 10-15 minutes.
* "Downloading Packages" took ca. 5 minutes (using a (fast) local mirror).
* The time from "Is this OK?" to "Finished Transaction Test" was
ca. 1 hour.
* The "Running Transaction" stage took ca. 1 hour.
* The actual "update/installation" stage took ca. 1/2 hour.
* The "cleanup" stage took ca. 1/4 hour.
Total time: ca. 3 hours.


>>> People are working on both of the above issues.
>> Really? I doubt your claim. At least I am not aware of any activities in 
>> RH's rpm to change rpm's payload rsp. to perform measurements on the 
>> impact of using modern compressors on rpm-payloads.
> 
> well one of the memory intensive portions of the transaction is being
> worked on.   The file fingerprinting.
OK.

What I actually would like to know is which impact switching to e.g. 
bzip2 or lzma compressed payloads would have on end-users.

I.e. answers/input related to
* disk-space requirements
Would such step shrink the isos rsp. give room on isos?
* end-user's throughput during downloads.
In the past, there have been claims, bzip2 compression would have 
negative impacts on network-throughput because it would defeat low-level 
compression on networks (e.g. modems, isdn). Is this claim true, can it 
be verified, how about lzma and friends?
* rpm's installation times/memory requirement (time required for 
decompression, memory being used during decompression).
bzip2 has quite


Ralf

[1] Kernel OOMs when SELinux is enabled.

[2] Different setup as in the netbook example. Also, the i586 had not 
been updated since early January.

[3] The maximum swap space usage seems to have occurred, when the kernel 
package was updated. depmod appeared to have caused the maximum of swap 
space usage.

[4] Visible as time-consuming tools in "top" (in decreasing order):
mkinitrd (several minutes), gconftool-2 (several seconds), ldconfig 
(frequently called; very few seconds per invocation).



From tagoh at redhat.com  Wed Jan 28 09:22:08 2009
From: tagoh at redhat.com (Akira TAGOH)
Date: Wed, 28 Jan 2009 18:22:08 +0900 (JST)
Subject: Call for Ruby package maintainer
In-Reply-To: <497FA870.2030806@kanarip.com>
References: <20090127.150412.1090654878994195729.tagoh@redhat.com>
	<497FA870.2030806@kanarip.com>
Message-ID: <20090128.182208.612299192959538683.tagoh@redhat.com>

>>>>> On Wed, 28 Jan 2009 01:36:00 +0100,
>>>>> "JvM" == Jeroen van Meeuwen <kanarip at kanarip.com> wrote:

JvM> Are you talking ruby itself, or just "a" ruby package?

I meant ruby itself. right now what a kind of todo I have in
ruby package is:

- Update to 1.8.7
  - may need to consider updating the packaging policy as
    well since this release has additional installation path
    like perl and python has. e.g. /usr/lib/ruby/vendor_ruby.

- Get rid of old search paths for backward compatibility
  because we should've passed through enough time to
  migrate.

- bug fixes

I hope someone can works as primary maintainer for "ruby"
package and Fedora becomes better environment for ruby.

--
Akira TAGOH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/5296139e/attachment.sig>

From markmc at redhat.com  Wed Jan 28 09:52:49 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Wed, 28 Jan 2009 09:52:49 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <1233136369.22103.25.camel@blaa>

On Tue, 2009-01-27 at 23:48 +0530, Rahul Sundaram wrote:

>  * All Updates must refer to a upstream changelog or equivalent if one 
> exists. Otherwise a brief description (a couple of sentence at most) 
> justifying the need for an update must be provided by the maintainers 
> pushing the update.
> 
> * If there are downstream bugs being fixed or intended to be fixed with 
> an update, it must be referred within the update. Maintainers can choose 
> to let bodhi auto close bugs or close it manually as well.
> 
> * For security update, add CVE information, if one exists.
> 
> * It is highly recommended that package maaintainers highlight major new 
> features, critical bug fixes or anything else that has a potential high 
> impact on consumers of your update.

I'd suggest the tone should be less prescriptive - i.e. not so much "you
must do foo" - and also give some rationale.

e.g. "when preparing your update, consider what the user will see and
how they will decide whether they should apply the update".

Cheers,
Mark.



From markmc at redhat.com  Wed Jan 28 09:57:09 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Wed, 28 Jan 2009 09:57:09 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <1233086368.8363.210.camel@localhost.localdomain>
References: <497F5005.4060107@fedoraproject.org>
	<497F56A8.7010803@leemhuis.info>
	<604aa7910901271120o19bbe666vbe810f7013ec2bbc@mail.gmail.com>
	<497F654A.7090503@leemhuis.info>
	<1233086368.8363.210.camel@localhost.localdomain>
Message-ID: <1233136629.22103.31.camel@blaa>

On Tue, 2009-01-27 at 11:59 -0800, Jesse Keating wrote:
> On Tue, 2009-01-27 at 20:49 +0100, Thorsten Leemhuis wrote:
> >  
> > Whatever:  I don't care much about this specific set of rules. It just 
> > seems to me a general trend that more and more rules and guidelines are 
> > put into place in Fedora-land; and more and more work is outsourced onto 
> > the packagers. Sure, some of the rules and the outsourcing is needed -- 
> > but I find this trend very alarming.
> 
> The alarming trend is the folks who won't do things, unless there is a
> guideline for them.  I hate having an abundance of guidlines just like
> you do, however almost all the recent guidelines have been done in
> reaction to a lack of people following "best practices".  Ergo we create
> guidelines to /help/ people understand what those best practices are.

Yeah, documenting best practices is better than having this stuff as a
body of folklore that new contributors only learn by making mistakes and
getting flamed.

IMHO, though, all of these types of guidelines should end with "but
you're the maintainer, use your own common sense and judgement and you
shouldn't go too far wrong".

We don't need rules to bash people over the head with, but rather we
want to help people understand how to be good packagers.

Cheers,
Mark.



From rjones at redhat.com  Wed Jan 28 10:03:19 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 28 Jan 2009 10:03:19 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <1233136369.22103.25.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>
Message-ID: <20090128100319.GA23464@amd.home.annexia.org>

On Wed, Jan 28, 2009 at 09:52:49AM +0000, Mark McLoughlin wrote:
> On Tue, 2009-01-27 at 23:48 +0530, Rahul Sundaram wrote:
> 
> >  * All Updates must refer to a upstream changelog or equivalent if one 
> > exists. Otherwise a brief description (a couple of sentence at most) 
> > justifying the need for an update must be provided by the maintainers 
> > pushing the update.
> > 
> > * If there are downstream bugs being fixed or intended to be fixed with 
> > an update, it must be referred within the update. Maintainers can choose 
> > to let bodhi auto close bugs or close it manually as well.
> > 
> > * For security update, add CVE information, if one exists.
> > 
> > * It is highly recommended that package maaintainers highlight major new 
> > features, critical bug fixes or anything else that has a potential high 
> > impact on consumers of your update.
> 
> I'd suggest the tone should be less prescriptive - i.e. not so much "you
> must do foo" - and also give some rationale.
> 
> e.g. "when preparing your update, consider what the user will see and
> how they will decide whether they should apply the update".

+1 to this.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rjones at redhat.com  Wed Jan 28 10:04:01 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 28 Jan 2009 10:04:01 +0000
Subject: rawhide report: 20090128 changes
In-Reply-To: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>
References: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>
Message-ID: <20090128100401.GB23464@amd.home.annexia.org>

On Wed, Jan 28, 2009 at 07:58:20AM +0000, Rawhide Report wrote:
> Compose started at Wed Jan 28 06:01:02 UTC 2009
> 
> Broken deps for i386

These mails are tracking the alpha release now?

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From sundaram at fedoraproject.org  Wed Jan 28 10:20:23 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 15:50:23 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <1233136369.22103.25.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>
Message-ID: <49803167.5040000@fedoraproject.org>

Mark McLoughlin wrote:

> I'd suggest the tone should be less prescriptive - i.e. not so much "you
> must do foo" - and also give some rationale.
> 
> e.g. "when preparing your update, consider what the user will see and
> how they will decide whether they should apply the update".

I am probably not going to be very good at doing this. Do you want to try?

Rahul



From hughsient at gmail.com  Wed Jan 28 10:37:08 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 28 Jan 2009 10:37:08 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <498011FB.6060809@freenet.de>
References: <497F5005.4060107@fedoraproject.org> <498011FB.6060809@freenet.de>
Message-ID: <1233139028.3174.46.camel@hughsie-work.lan>

On Wed, 2009-01-28 at 09:06 +0100, Ralf Corsepius wrote:
> Rahul Sundaram wrote:
> > Hi,
> > 
> > The following are a set of simple guidelines for the update descriptions 
> > via bodhi (which is used by PackageKit to inform users of what has 
> > changed). These guidelines are intended to help end users understand the 
> > nature of changes in the update better. Bodhi is not used in rawhide, so 
> > these guidelines are not applicable for rawhide updates. Note that this 
> > is not connected to the rpm changelog.
> -1, simply nuts

By saying "simply nuts" I assume you've not talked to any real users.

This IS useful:
https://admin.fedoraproject.org/updates/hwdata-0.222-1.fc10

This IS NOT useful:
https://admin.fedoraproject.org/updates/gromacs-4.0.3-2.fc10

If we want to push our platform forward as "easy to use" and "suitable
for new users" then this sort of thing is very important. Users are not
typically on the upstream mailing lists, so then they don't know if
"Update to 4.0.3" will fix:

- data corruption when saving to foolib format
- that annoying memory leak that means you don't have to restart anymore
- now you can export to fooapp 2.1 format
- trivial icon corruption that you are not that bothered about

So when the user looks at the update description, they make a decision
"do I download this and install it" -- and for that they need to have
some data to make an informed decision.

Richard.




From kevin.kofler at chello.at  Wed Jan 28 10:49:00 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 11:49:00 +0100
Subject: support for latest (radeon) hardware
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<glg41r$dp7$1@ger.gmane.org>
	<1233084071.19014.36.camel@localhost.localdomain>
	<4980115D.7070808@hhs.nl>
Message-ID: <glpd6s$rqh$1@ger.gmane.org>

Hans de Goede wrote:
> Yes that is what I've done too (revert back to F-9 Xorg), even though I've
> been actively working with airlied (congrats with your kid once more) to
> get things in shape for F-10 and I believe we are in ok shape wrt 2d in
> F-10 3d is simply not usable in F-10, and since I maintain many games in
> Fedora I need working 3d.

This highly depends on the hardware. My laptop has an Intel 965 chipset. In
F9, several 3D apps/games were triggering an assertion failure in the
driver, and all the others had awful performance. In F10 the crashes are
gone and the apps/games are fast.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 28 10:50:24 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 11:50:24 +0100
Subject: support for latest (radeon) hardware
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<glg41r$dp7$1@ger.gmane.org>
	<1233084071.19014.36.camel@localhost.localdomain>
Message-ID: <glpd9g$rqh$2@ger.gmane.org>

Callum Lerwick wrote:
> I have Shit To Do, and it looks like I'm going to have to revert my
> entire Xorg back to F9 to do it.

At least you have that option. If only the old version was available, there
would be no such option.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 28 11:03:32 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 12:03:32 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
	<7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
	<glmitr$uvt$1@ger.gmane.org>
	<7dd7ab490901271230n5ae22c78ga374945ee80577ba@mail.gmail.com>
Message-ID: <glpe24$us0$1@ger.gmane.org>

Chris Weyl wrote:
> Neither is it difficult to rig something to point automatically at an
> included package changelog.  Before we mandate a new manual task,
> can't we at least try an automated approach first?

The included changelog is often way too detailed (especially FSF-style
changelogs, see e.g. the GCC one) and it also doesn't give the rationale
why the update is being pushed. And there are also many packages where the
changelog is provided on some web page, not as part of the source code. So
this is no substitute for doing it properly.

        Kevin Kofler



From billcrawford1970 at gmail.com  Wed Jan 28 11:26:49 2009
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Wed, 28 Jan 2009 11:26:49 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <1233087952.9693.18.camel@arekh.okg>
References: <497F5005.4060107@fedoraproject.org>
	<20090127194353.GC18789@amd.home.annexia.org>
	<1233087952.9693.18.camel@arekh.okg>
Message-ID: <200901281126.49542.billcrawford1970@gmail.com>

On Tuesday 27 January 2009 20:25:52 Nicolas Mailhot wrote:

> Instead of requiring new levels of over-pure whiteness of new packages,
> please focus on how the existing morass can be improved.

"If you're up to your morass in alligators, it's hard to remember that your 
original task was to drain the swamp" ?



From markmc at redhat.com  Wed Jan 28 12:14:48 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Wed, 28 Jan 2009 12:14:48 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <49803167.5040000@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa> <49803167.5040000@fedoraproject.org>
Message-ID: <1233144888.13111.1.camel@blaa>

On Wed, 2009-01-28 at 15:50 +0530, Rahul Sundaram wrote:
> Mark McLoughlin wrote:
> 
> > I'd suggest the tone should be less prescriptive - i.e. not so much "you
> > must do foo" - and also give some rationale.
> > 
> > e.g. "when preparing your update, consider what the user will see and
> > how they will decide whether they should apply the update".
> 
> I am probably not going to be very good at doing this. Do you want to try?

Okay, here's an attempt:

  https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

Cheers,
Mark.

= Package Update Guidelines =

This page is intended to give some guidelines relevant to package
maintainers who wish to update a package on a release branch.

These are not intended to be prescriptive rules. Package maintainers are
free to exercise their own common sense and good judgement.

== Maintaining Stability ==

Many Fedora users update automatically, so it is most important that an
update doesn't cause a users' applications or system to stop working
suddenly.

Bug fix updates should generally be first pushed to testing and only
pushed to stable after it has achieved sufficient karma in bodhi.

New upstream releases should not necessarily be pushed to release
branches. The benefit of the bugfixes and new features should be weighed
up against the risk of regressions. A simple rule of thumb might be to
not push the new release unless it fixes a problem that a user has
reported or introduces a new feature that Fedora users have previously
requested. Even still, for more complex packages it might make sense to
backport the specific patch needed.

The risk of serious regressions always exists and should be considered.
Rawhide is the development branch, so package maintainers may choose to
push an update to rawhide for a period before pushing to a release
branch. This gives rawhide testers the opportunity to catch any issues
before <code>updates-testing</code> or <code>updates</code> users can be
affected.

== Update Descriptions ==

Fedora users who do not update automatically may review the descriptions
attached to updates before choosing whether they should apply them.

Package maintainers should bear this in mind when preparing the update
description and try to help their users make as informed decisions as
possible.

Some suggestions for what a description might include:

# For security issues, links to the appropriate CVEs 
# For bug fixes, links to any relevant bugzillas
# For new upstream releases, a summary of the important changes and/or
  a link to the upstream changelog
# Any other information that might be important to users

Good judgement is required, though. Overly verbose descriptions can be
almost as useless as overly terse descriptions.

== Rate of Updates ==

Package maintainers should bear in mind that not all Fedora users have
good Internet bandwidth available.

Where a package is likely to require many small updates in a short
period of time, a maintainer may decide to combine those into a single
update. This is especially important in the case of large packages.

[[Category:Package Maintainers]]



From airlied at redhat.com  Wed Jan 28 12:18:00 2009
From: airlied at redhat.com (Dave Airlie)
Date: Wed, 28 Jan 2009 22:18:00 +1000
Subject: support for latest (radeon) hardware
In-Reply-To: <4980115D.7070808@hhs.nl>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>
	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>
	<20090124151420.GA21427@wolff.to> <497B5110.8000800@leemhuis.info>
	<1232819460.8363.106.camel@localhost.localdomain>
	<glg41r$dp7$1@ger.gmane.org>
	<1233084071.19014.36.camel@localhost.localdomain>
	<4980115D.7070808@hhs.nl>
Message-ID: <1233145080.22993.1.camel@localhost>

On Wed, 2009-01-28 at 09:03 +0100, Hans de Goede wrote:
> Callum Lerwick wrote:
> > On Sat, 2009-01-24 at 23:17 +0100, Kevin Kofler wrote:
> >> That said, it's a tough topic, because regressions tend to really annoy
> >> people, they feel "WTF, this always worked, WhyTF is it no longer working
> >> now?", even though from a purely practical point of view, unfixed bugs (and
> >> not working on some hardware is practically speaking a bug, even though
> >> technically it's a missing feature) are much worse because there's no
> >> working build to revert to.
> > 
> > Your logic is flawed. People with not yet supported hardware, can find
> > supported hardware, or live with workarounds like VESA. You can not make
> > progress by accepting regressions. At best, you are spinning your wheels
> > in place, at worst you are taking one step forward and two steps back.
> > Regression means just that, you are regressing. Fedora is about
> > progress, not regress. The linux kernel has a rather strict
> > no-regressions policy, for good reason:
> > 
> > http://lwn.net/Articles/261713/
> > 
> > I wish Xorg and Fedora as a whole, would adopt a similar policy. I'm
> > very unhappy with how the Xorg update went in F10. Just when we started
> > getting reliable, usable open source OpenGL, F10 came along and broke
> > *everything*:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=474977
> > https://bugzilla.redhat.com/show_bug.cgi?id=441665
> > https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
> > 
> > Not a single one of my machines works out of the box like they did in
> > F9, they all need work-arounds. But OpenGL support has been quite
> > thoroughly broken. This has pretty well fucked any ability to get back
> > to working on Second Life:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=233946
> > 
> > I have Shit To Do, and it looks like I'm going to have to revert my
> > entire Xorg back to F9 to do it.
> > 
> 
> Yes that is what I've done too (revert back to F-9 Xorg), even though I've been 
> actively working with airlied (congrats with your kid once more) to get things 
> in shape for F-10 and I believe we are in ok shape wrt 2d in F-10 3d is simply 
> not usable in F-10, and since I maintain many games in Fedora I need working 3d.
> 

Didn't I fix the 3D already so it didn't crash for those apps (in
7.2.0-15)? or is it just slow?

The main bug was actually an upstream issue, not kms related in the end.
I'm still awaiting an upstream fix.

Dave.





> Regards,
> 
> Hans
> 



From jwboyer at gmail.com  Wed Jan 28 12:36:27 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Jan 2009 07:36:27 -0500
Subject: Draft: simple update description guidelines
In-Reply-To: <497F7A6A.8070800@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
	<497F724A.7000006@poolshark.org>
	<497F7A6A.8070800@fedoraproject.org>
Message-ID: <20090128123627.GC808@yoda.jdub.homelinux.org>

On Wed, Jan 28, 2009 at 02:49:38AM +0530, Rahul Sundaram wrote:
> Denis Leroy wrote:
>> Rahul Sundaram wrote:
>>> * All Updates must refer to a upstream changelog or equivalent if one 
>>> exists. Otherwise a brief description (a couple of sentence at most)  
>>> justifying the need for an update must be provided by the maintainers 
>>> pushing the update.
>>
>> -1
>>
>> This is borderline insane.
>
> There is no voting. That is left to FESCo and you are not being specific.

There is always voting.  FESCo welcomes commentary and discussion, as we
are elected representatives of the packager and developer communities.
Please do not dissuade people from expressing their opinion.

I will note that specifics are certainly more helpful that simple +/-1
emails.

josh



From jwboyer at gmail.com  Wed Jan 28 12:38:52 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Wed, 28 Jan 2009 07:38:52 -0500
Subject: rawhide report: 20090128 changes
In-Reply-To: <20090128100401.GB23464@amd.home.annexia.org>
References: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>
	<20090128100401.GB23464@amd.home.annexia.org>
Message-ID: <20090128123852.GD808@yoda.jdub.homelinux.org>

On Wed, Jan 28, 2009 at 10:04:01AM +0000, Richard W.M. Jones wrote:
>On Wed, Jan 28, 2009 at 07:58:20AM +0000, Rawhide Report wrote:
>> Compose started at Wed Jan 28 06:01:02 UTC 2009
>> 
>> Broken deps for i386
>
>These mails are tracking the alpha release now?

No.  They still track rawhide.  Alpha is a non-blocking freeze.

josh



From sundaram at fedoraproject.org  Wed Jan 28 12:42:59 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 18:12:59 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128123627.GC808@yoda.jdub.homelinux.org>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>
	<20090128123627.GC808@yoda.jdub.homelinux.org>
Message-ID: <498052D3.3060208@fedoraproject.org>

Josh Boyer wrote:

> Please do not dissuade people from expressing their opinion.
> 
> I will note that specifics are certainly more helpful that simple +/-1
> emails.

I encourage people to express their opinion but not as votes but as more 
directed commentary. Votes are far less helpful if at all.

Rahul



From itamar at ispbrasil.com.br  Wed Jan 28 13:02:32 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 28 Jan 2009 11:02:32 -0200
Subject: script to remove copyrighted content before packaging
Message-ID: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>

Hi.

where are the script to remove copyrighted content before packaging ?


------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From lists at sapience.com  Wed Jan 28 13:02:46 2009
From: lists at sapience.com (Mail Lists)
Date: Wed, 28 Jan 2009 08:02:46 -0500
Subject: Draft: simple update description guidelines
In-Reply-To: <498052D3.3060208@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>	<20090128123627.GC808@yoda.jdub.homelinux.org>
	<498052D3.3060208@fedoraproject.org>
Message-ID: <49805776.7020402@sapience.com>

On 01/28/2009 07:42 AM, Rahul Sundaram wrote:
> Josh Boyer wrote:
> 
>> Please do not dissuade people from expressing their opinion.
>>
>> I will note that specifics are certainly more helpful that simple +/-1
>> emails.
> 
> I encourage people to express their opinion but not as votes but as more
> directed commentary. Votes are far less helpful if at all.
> 
> Rahul
> 

 -2       (this is the first time I have ever used this mechanism)

 A "vote" is simply a compact way of expressing an opinion - yes it is
more useful to add comments  as well, however a numerical opinion does
not exclude that. Encourage communication not discourage.

 Focus on the issue and the information - not on how people choose to
express it - the 'how' is largely tangential and detracts from the
issues at hand.




From fedora at camperquake.de  Wed Jan 28 13:06:14 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 28 Jan 2009 14:06:14 +0100
Subject: script to remove copyrighted content before packaging
In-Reply-To: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
References: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
Message-ID: <20090128140614.3d48fa11@dhcp03.addix.net>

Hi.

On Wed, 28 Jan 2009 11:02:32 -0200, Itamar Reis Peixoto wrote:

> where are the script to remove copyrighted content before packaging ?

There isn't any, really. Usually only humans can decide what exactly
the copyrighted content is, and how to remove it (delete the whole file?
Delete only parts of a file? If the file is code, what else needs to be
changed?)



From itamar at ispbrasil.com.br  Wed Jan 28 13:10:31 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Wed, 28 Jan 2009 11:10:31 -0200
Subject: script to remove copyrighted content before packaging
In-Reply-To: <20090128140614.3d48fa11@dhcp03.addix.net>
References: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
	<20090128140614.3d48fa11@dhcp03.addix.net>
Message-ID: <d3ceea380901280510x5375816aq371df4cf022a2f9a@mail.gmail.com>

i need to remove  a entire sub-directory

On Wed, Jan 28, 2009 at 11:06 AM, Ralf Ertzinger <fedora at camperquake.de> wrote:
> Hi.
>
> On Wed, 28 Jan 2009 11:02:32 -0200, Itamar Reis Peixoto wrote:
>
>> where are the script to remove copyrighted content before packaging ?
>
> There isn't any, really. Usually only humans can decide what exactly
> the copyrighted content is, and how to remove it (delete the whole file?
> Delete only parts of a file? If the file is code, what else needs to be
> changed?)
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From sundaram at fedoraproject.org  Wed Jan 28 13:20:39 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 18:50:39 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <49805776.7020402@sapience.com>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>	<20090128123627.GC808@yoda.jdub.homelinux.org>	<498052D3.3060208@fedoraproject.org>
	<49805776.7020402@sapience.com>
Message-ID: <49805BA7.8060606@fedoraproject.org>

Mail Lists wrote:

>  A "vote" is simply a compact way of expressing an opinion - yes it is
> more useful to add comments  as well, however a numerical opinion does
> not exclude that. Encourage communication not discourage.

  > Focus on the issue and the information - not on how people choose to
  > express it - the 'how' is largely tangential and detracts from the
  > issues at hand.

People who vote tend to use it as a replacement for more useful feedback 
and to try and shout down a proposal.  Even looking in this thread, it 
would be evident, why I discourage voting.  Not all communication is 
useful. Especially communication that doesn't move beyond taking cheap 
shots in irc and emails as has been happening the last couple of days in 
response.  I don't find "how" as tangential especially when it is used a 
excuse to be unnecessarily rude.

Jesse Keating tried to educate people by publically calling out 
offenders. It doesn't scale and sometimes a cultural misfit. I prefer 
documenting things instead. Less second guessing for everyone involved.

Rahul



From pertusus at free.fr  Wed Jan 28 13:20:37 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Wed, 28 Jan 2009 14:20:37 +0100
Subject: script to remove copyrighted content before packaging
In-Reply-To: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
References: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
Message-ID: <20090128132037.GB3020@free.fr>

On Wed, Jan 28, 2009 at 11:02:32AM -0200, Itamar Reis Peixoto wrote:
> Hi.
> 
> where are the script to remove copyrighted content before packaging ?

It is explained at
http://fedoraproject.org/wiki/Packaging:SourceURL#When_Upstream_uses_Prohibited_Code

I do that in the cernlib (very complicated) and grads package (less
complicated). You can use those examples, too.

--
Pat



From sundaram at fedoraproject.org  Wed Jan 28 13:22:59 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 18:52:59 +0530
Subject: script to remove copyrighted content before packaging
In-Reply-To: <20090128140614.3d48fa11@dhcp03.addix.net>
References: <d3ceea380901280502i7f638e2axa0a62e1637b846c6@mail.gmail.com>
	<20090128140614.3d48fa11@dhcp03.addix.net>
Message-ID: <49805C33.1070602@fedoraproject.org>

Ralf Ertzinger wrote:
> Hi.
> 
> On Wed, 28 Jan 2009 11:02:32 -0200, Itamar Reis Peixoto wrote:
> 
>> where are the script to remove copyrighted content before packaging ?
> 
> There isn't any, really. Usually only humans can decide what exactly
> the copyrighted content is, and how to remove it (delete the whole file?
> Delete only parts of a file? If the file is code, what else needs to be
> changed?)

Also, except for very small percentage of public domain content, 
everything else is copyrighted in Fedora. It is just more liberally 
licensed. Copyright != restricted content.

Rahul



From rjones at redhat.com  Wed Jan 28 13:31:27 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Wed, 28 Jan 2009 13:31:27 +0000
Subject: rawhide report: 20090128 changes
In-Reply-To: <20090128123852.GD808@yoda.jdub.homelinux.org>
References: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>
	<20090128100401.GB23464@amd.home.annexia.org>
	<20090128123852.GD808@yoda.jdub.homelinux.org>
Message-ID: <20090128133127.GA25537@amd.home.annexia.org>

On Wed, Jan 28, 2009 at 07:38:52AM -0500, Josh Boyer wrote:
> On Wed, Jan 28, 2009 at 10:04:01AM +0000, Richard W.M. Jones wrote:
> >On Wed, Jan 28, 2009 at 07:58:20AM +0000, Rawhide Report wrote:
> >> Compose started at Wed Jan 28 06:01:02 UTC 2009
> >> 
> >> Broken deps for i386
> >
> >These mails are tracking the alpha release now?
> 
> No.  They still track rawhide.  Alpha is a non-blocking freeze.

OK, I was just wondering why there were no changes for two days :-)

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rda at rincon.com  Wed Jan 28 13:37:37 2009
From: rda at rincon.com (Bob Arendt)
Date: Wed, 28 Jan 2009 06:37:37 -0700
Subject: support for latest (radeon) hardware
In-Reply-To: <glpd6s$rqh$1@ger.gmane.org>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<glg41r$dp7$1@ger.gmane.org>	<1233084071.19014.36.camel@localhost.localdomain>	<4980115D.7070808@hhs.nl>
	<glpd6s$rqh$1@ger.gmane.org>
Message-ID: <49805FA1.5020804@rincon.com>

Kevin Kofler wrote:
> Hans de Goede wrote:
>> Yes that is what I've done too (revert back to F-9 Xorg), even though I've
>> been actively working with airlied (congrats with your kid once more) to
>> get things in shape for F-10 and I believe we are in ok shape wrt 2d in
>> F-10 3d is simply not usable in F-10, and since I maintain many games in
>> Fedora I need working 3d.
> 
> This highly depends on the hardware. My laptop has an Intel 965 chipset. In
> F9, several 3D apps/games were triggering an assertion failure in the
> driver, and all the others had awful performance. In F10 the crashes are
> gone and the apps/games are fast.
> 
Although there's now a single intel driver, for some of the older chipsets
(intel 845G) that *did* have acceleration + 3d under the old i810 driver F9,
it's now terribly broken - even 2d acceleration results in a hang:
   https://bugzilla.redhat.com/show_bug.cgi?id=469292
That laptop's still stuck on F9, using a USB drive to test against rawhide.
-Bob



From rc040203 at freenet.de  Wed Jan 28 13:56:03 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Wed, 28 Jan 2009 14:56:03 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <49805BA7.8060606@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>	<20090128123627.GC808@yoda.jdub.homelinux.org>	<498052D3.3060208@fedoraproject.org>	<49805776.7020402@sapience.com>
	<49805BA7.8060606@fedoraproject.org>
Message-ID: <498063F3.9080506@freenet.de>

Rahul Sundaram wrote:
> Mail Lists wrote:
> 
>>  A "vote" is simply a compact way of expressing an opinion - yes it is
>> more useful to add comments  as well, however a numerical opinion does
>> not exclude that. Encourage communication not discourage.
> 
>  > Focus on the issue and the information - not on how people choose to
>  > express it - the 'how' is largely tangential and detracts from the
>  > issues at hand.
> 
> People who vote tend to use it as a replacement for more useful feedback 
> and to try and shout down a proposal.  Even looking in this thread, it 
> would be evident, why I discourage voting.
Yes, it's evident: You are presuming your proposal to be useful and do 
not want to listen to anybody not sharing your view.



From promac at gmail.com  Wed Jan 28 14:15:41 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Wed, 28 Jan 2009 12:15:41 -0200
Subject: alsa x 2.6.27.12-170.2.5.fc10
Message-ID: <68720af30901280615l5c50c20fu87db7e17bbb2a8fa@mail.gmail.com>

Hi,

the latest Fedora 10 kernel went back to alsa 1.0.17

I really do not understand why not going straight to 1.0.19
instead of patching 1.0.17 again. I agree alsa-1.0.18
had a lot of problems, but the fixes are in alsa 1.0.19.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/6c6324c4/attachment.htm>

From ngompa13 at gmail.com  Wed Jan 28 14:15:59 2009
From: ngompa13 at gmail.com (King InuYasha)
Date: Wed, 28 Jan 2009 08:15:59 -0600
Subject: Your favorite CMS running docs.fedoraproject.org?
In-Reply-To: <gknfh5$9ss$1@ger.gmane.org>
References: <20090114222022.GF7770@calliope.phig.org>
	<20090114222833.GF14350@localhost.localdomain>
	<69db0bf30901142006u1cc7abc1wdae07c32daf64893@mail.gmail.com>
	<gknfh5$9ss$1@ger.gmane.org>
Message-ID: <8278b1b0901280615y20d3c08dr29eb816a3a34f966@mail.gmail.com>

I have sent in Enano CMS for package review. So, now I wait basically.
Though do I need to responsored?
https://bugzilla.redhat.com/show_bug.cgi?id=481536

On Thu, Jan 15, 2009 at 7:59 AM, Rex Dieter <rdieter at math.unl.edu> wrote:

> Operator (postnuke.tv) wrote:
>
> > The Zikula project might be very interested... You could have Zikula
> > deployed with the project's help and support?
> > Moreover, at some point in the near future, we'd like to be providing
> > a Fedora RPM for the FC distrib.
>
> The latter, being packaged and included in fedora, is pretty much a
> prerequisite for consideration, so... the sooner the better.
>
> -- Rex
>
> --
> 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/c9012d35/attachment.htm>

From bruno at wolff.to  Wed Jan 28 14:25:38 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Wed, 28 Jan 2009 08:25:38 -0600
Subject: rawhide report: 20090128 changes
In-Reply-To: <20090128133127.GA25537@amd.home.annexia.org>
References: <20090128075820.5CC4C1F8262@releng2.fedora.phx.redhat.com>
	<20090128100401.GB23464@amd.home.annexia.org>
	<20090128123852.GD808@yoda.jdub.homelinux.org>
	<20090128133127.GA25537@amd.home.annexia.org>
Message-ID: <20090128142538.GB17040@wolff.to>

On Wed, Jan 28, 2009 at 13:31:27 +0000,
  "Richard W.M. Jones" <rjones at redhat.com> wrote:
> On Wed, Jan 28, 2009 at 07:38:52AM -0500, Josh Boyer wrote:
> > On Wed, Jan 28, 2009 at 10:04:01AM +0000, Richard W.M. Jones wrote:
> > >On Wed, Jan 28, 2009 at 07:58:20AM +0000, Rawhide Report wrote:
> > >> Compose started at Wed Jan 28 06:01:02 UTC 2009
> > >> 
> > >> Broken deps for i386
> > >
> > >These mails are tracking the alpha release now?
> > 
> > No.  They still track rawhide.  Alpha is a non-blocking freeze.
> 
> OK, I was just wondering why there were no changes for two days :-)

It's probably related to the alpha freeze somehow, but package updates are
still making it into rawhide even if they aren't being reported in the
daily email.



From surenkarapetyan at gmail.com  Wed Jan 28 15:17:03 2009
From: surenkarapetyan at gmail.com (Suren Karapetyan)
Date: Wed, 28 Jan 2009 19:17:03 +0400
Subject: alsa x 2.6.27.12-170.2.5.fc10
In-Reply-To: <68720af30901280615l5c50c20fu87db7e17bbb2a8fa@mail.gmail.com>
References: <68720af30901280615l5c50c20fu87db7e17bbb2a8fa@mail.gmail.com>
Message-ID: <498076EF.1000605@gmail.com>

Paulo Cavalcanti wrote:
> Hi,
>
> the latest Fedora 10 kernel went back to alsa 1.0.17
>
> I really do not understand why not going straight to 1.0.19
> instead of patching 1.0.17 again. I agree alsa-1.0.18
> had a lot of problems, but the fixes are in alsa 1.0.19.
>
> -- 
> Paulo Roma Cavalcanti
> LCG - UFRJ
Cause "1.0.17 had many problems, but the fixes are in 1.0.18".
1.0.19 is UNTESTED.
Even 1.0.18 was much more tested when 159 kernel was released than 
1.0.19 is now.
Kernel will update to 1.0.19 when we are sure we won't have the same 
problems with it like we had with 1.0.18.

P.S. I really have the feeling that the best thing we can do about alsa 
is to stick with kernel.org's version (at least for stable Fedoras).



From pvrabec at redhat.com  Wed Jan 28 15:24:30 2009
From: pvrabec at redhat.com (Peter Vrabec)
Date: Wed, 28 Jan 2009 16:24:30 +0100
Subject: what requires fedora-release-notes
Message-ID: <200901281624.31502.pvrabec@redhat.com>

Hi folks,

why does fedora-release require fedora-release-notes? There are different aims 
to adjust package dependencies for security or minimal installation reasons. 
For example:

https://fedoraproject.org/wiki/SIGs/Server

I'm wondering if we can avoid fedora-release-notes in minimal installation.

fedora-release-notes ~ 5MB

thnx.,
Peter.



From dominik at greysector.net  Wed Jan 28 15:23:42 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 28 Jan 2009 16:23:42 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <20090128152342.GC3119@mokona.greysector.net>

On Tuesday, 27 January 2009 at 19:18, Rahul Sundaram wrote:
[...]
> ---
> 
> * All Updates must refer to a upstream changelog or equivalent if one 
> exists. Otherwise a brief description (a couple of sentence at most) 
> justifying the need for an update must be provided by the maintainers 
> pushing the update.
> 
> * If there are downstream bugs being fixed or intended to be fixed with 
> an update, it must be referred within the update. Maintainers can choose 
> to let bodhi auto close bugs or close it manually as well.

This is redundant. bodhi has a field for bug numbers and it's pretty
self-explanatory.

> * For security update, add CVE information, if one exists.

As above.

> * It is highly recommended that package maaintainers highlight major new 
> features, critical bug fixes or anything else that has a potential high 
> impact on consumers of your update.
> 
> ---
> 
> Please be specific in your comments and try and be constructive. Thank you.

Nobody reads these anyway, so what's the point? Yum's changelog plugin is
much more useful than this proposal will ever be.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From sundaram at fedoraproject.org  Wed Jan 28 15:24:25 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 20:54:25 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <498063F3.9080506@freenet.de>
References: <497F5005.4060107@fedoraproject.org>	<497F724A.7000006@poolshark.org>	<497F7A6A.8070800@fedoraproject.org>	<20090128123627.GC808@yoda.jdub.homelinux.org>	<498052D3.3060208@fedoraproject.org>	<49805776.7020402@sapience.com>	<49805BA7.8060606@fedoraproject.org>
	<498063F3.9080506@freenet.de>
Message-ID: <498078A9.1080808@fedoraproject.org>

Ralf Corsepius wrote:

> Yes, it's evident: You are presuming your proposal to be useful and do 
> not want to listen to anybody not sharing your view.

I have considered all the feedback given. Yours didn't convey much 
information beyond the fact that you didn't like it which I am already 
aware from earlier discussions as well.

Rahul



From rdieter at math.unl.edu  Wed Jan 28 15:28:14 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 28 Jan 2009 09:28:14 -0600
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
References: <glcrsh$k8i$1@ger.gmane.org>
Message-ID: <glptk0$lci$1@ger.gmane.org>

Just to followup with a progress report...

Rex Dieter wrote:

> The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
> process will be smooth, so as to introduce little to no breakage during or
> after.

rawhide done.

> We'll also be starting work on updates for F-10 (first) and F-9. 

F-10 packages done, in buildroot, close to queue'ing a first batch of
updates, a few periphery plasma-related updates need work.

F-9 packages are about 1/2 done, hopefully sorted out by the end of the day.

-- Rex



From sundaram at fedoraproject.org  Wed Jan 28 15:30:33 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 21:00:33 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <1233144888.13111.1.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>	
	<1233136369.22103.25.camel@blaa>
	<49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
Message-ID: <49807A19.6060804@fedoraproject.org>

Mark McLoughlin wrote:
> On Wed, 2009-01-28 at 15:50 +0530, Rahul Sundaram wrote:
>> Mark McLoughlin wrote:
>>
>>> I'd suggest the tone should be less prescriptive - i.e. not so much "you
>>> must do foo" - and also give some rationale.
>>>
>>> e.g. "when preparing your update, consider what the user will see and
>>> how they will decide whether they should apply the update".
>> I am probably not going to be very good at doing this. Do you want to try?
> 
> Okay, here's an attempt:
> 
>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

Thanks. I have made a minor edit making it explicit that this doesn't 
apply to rawhide or new packages. Looks good to me. I will be sending 
this over to FESCo (cc'ing Jon Stanley) unless anybody has other 
specific feedback.

Rahul



From Jochen at herr-schmitt.de  Wed Jan 28 15:38:12 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 28 Jan 2009 16:38:12 +0100
Subject: Proposal Enhancements for the Fedora Packaging Guidelines
Message-ID: <49807BE4.1040304@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

because I'm reviewing some python relating packages I have got a look
on the Python Packaging guidelines.

I have to find out, that this guidelines doesn't explaints, that you
have to add a BuildRequires: python-devel
for packages which are written in the C programming language.

I want to suppose the extenting of the packaging guildelines for a
explaination about when you have to
add a BuidRequires: python-devel. This may be helpful for newcommers
which plan to going to package
or review python relating packages.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmAe9MACgkQT2AHK6txfgyl4QCg9ScquiuGJ718xLHXVYOdfnBe
jOUAoLBbPnwfxHavas1E3ICP+A4cWg3t
=MQEA
-----END PGP SIGNATURE-----



From mark.bidewell at alumni.clemson.edu  Wed Jan 28 15:48:29 2009
From: mark.bidewell at alumni.clemson.edu (Mark Bidewell)
Date: Wed, 28 Jan 2009 10:48:29 -0500
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
In-Reply-To: <glptk0$lci$1@ger.gmane.org>
References: <glcrsh$k8i$1@ger.gmane.org> <glptk0$lci$1@ger.gmane.org>
Message-ID: <bfdeacfa0901280748q47554ef5i18e967fdf1526c10@mail.gmail.com>

On Wed, Jan 28, 2009 at 10:28 AM, Rex Dieter <rdieter at math.unl.edu> wrote:
> Just to followup with a progress report...
>
> Rex Dieter wrote:
>
>> The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
>> process will be smooth, so as to introduce little to no breakage during or
>> after.
>
> rawhide done.
>
>> We'll also be starting work on updates for F-10 (first) and F-9.
>
> F-10 packages done, in buildroot, close to queue'ing a first batch of
> updates, a few periphery plasma-related updates need work.
>
> F-9 packages are about 1/2 done, hopefully sorted out by the end of the day.
>
> -- Rex
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Will there be any known issues transitioning from kde-testing to the
official update?

-- 
Mark Bidewell
http://www.linkedin.com/in/markbidewell



From rdieter at math.unl.edu  Wed Jan 28 16:03:08 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Wed, 28 Jan 2009 10:03:08 -0600
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
References: <glcrsh$k8i$1@ger.gmane.org> <glptk0$lci$1@ger.gmane.org>
	<bfdeacfa0901280748q47554ef5i18e967fdf1526c10@mail.gmail.com>
Message-ID: <glpvle$s6q$4@ger.gmane.org>

Mark Bidewell wrote:

> Will there be any known issues transitioning from kde-testing to the
> official update?

Should be none.  *fingers crossed*.

-- Rex



From bochecha at fedoraproject.org  Wed Jan 28 16:10:09 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Wed, 28 Jan 2009 17:10:09 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128152342.GC3119@mokona.greysector.net>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
Message-ID: <2d319b780901280810v7f317fc1v1ec08f5ad336926c@mail.gmail.com>

>> Please be specific in your comments and try and be constructive. Thank you.
>
> Nobody reads these anyway,

I do (should I feel ashamed or something ? :-/)

> so what's the point? Yum's changelog plugin is
> much more useful than this proposal will ever be.

Actually, that's my fallback when no infos are provided in PK.

But that doesn't take away the fact that having infos in PK would be
really nice :)

About the proposed guideline, well, I can't say if it will be a burden
with the huge number of packages I maintain (yes, 4, not sure my
opinion matters ^^), but I've always felt "hey, what should I write in
this field in Bohdi ?" (didn't even know it was what would appear in
PK), so this would at least be some indications on what I'll try to
write in the future.

Regards,


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From dmalcolm at redhat.com  Wed Jan 28 16:17:29 2009
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 28 Jan 2009 11:17:29 -0500
Subject: Draft: simple update description guidelines
In-Reply-To: <49807A19.6060804@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa> <49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>  <49807A19.6060804@fedoraproject.org>
Message-ID: <1233159449.4420.21.camel@localhost.localdomain>

On Wed, 2009-01-28 at 21:00 +0530, Rahul Sundaram wrote:
> Mark McLoughlin wrote:
> > On Wed, 2009-01-28 at 15:50 +0530, Rahul Sundaram wrote:
> >> Mark McLoughlin wrote:
> >>
> >>> I'd suggest the tone should be less prescriptive - i.e. not so much "you
> >>> must do foo" - and also give some rationale.
> >>>
> >>> e.g. "when preparing your update, consider what the user will see and
> >>> how they will decide whether they should apply the update".
> >> I am probably not going to be very good at doing this. Do you want to try?
> > 
> > Okay, here's an attempt:
> > 
> >   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 
> Thanks. I have made a minor edit making it explicit that this doesn't 
> apply to rawhide or new packages. Looks good to me. I will be sending 
> this over to FESCo (cc'ing Jon Stanley) unless anybody has other 
> specific feedback.
> 
How about this rewording in the first sentence:
  from "to update a package on a release branch"
  to "?to update a package on an already-released branch"
to make it clearer that it's only talking about updates to released
versions of Fedora.




From sundaram at fedoraproject.org  Wed Jan 28 16:17:20 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 21:47:20 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128152342.GC3119@mokona.greysector.net>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
Message-ID: <49808510.6050204@fedoraproject.org>

Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 27 January 2009 at 19:18, Rahul Sundaram wrote:

>> * If there are downstream bugs being fixed or intended to be fixed with 
>> an update, it must be referred within the update. Maintainers can choose 
>> to let bodhi auto close bugs or close it manually as well.
> 
> This is redundant. bodhi has a field for bug numbers and it's pretty
> self-explanatory.
> 
>> * For security update, add CVE information, if one exists.
> 
> As above.

As evident in the number of package updates that don't provide any 
information at all, I think it is helpful and complimentary to existing 
bodhi descriptions. Also many maintainers are not aware that the update 
descriptions are being used by PackageKit. Documenting it properly would 
encourage them.

> Nobody reads these anyway, so what's the point? Yum's changelog plugin is
> much more useful than this proposal will ever be.

I am sure, quite a few people read them since I have answered questions 
on earlier guidelines several times.  Yum changelog plugin displays the 
rpm changelog while PackageKit shows the update description in the 
graphical interface. Both are useful.

Rahul



From notting at redhat.com  Wed Jan 28 16:24:03 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 28 Jan 2009 11:24:03 -0500
Subject: what requires fedora-release-notes
In-Reply-To: <200901281624.31502.pvrabec@redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>
Message-ID: <20090128162403.GB6735@nostromo.devel.redhat.com>

Peter Vrabec (pvrabec at redhat.com) said: 
> Hi folks,
> 
> why does fedora-release require fedora-release-notes? There are different aims 
> to adjust package dependencies for security or minimal installation reasons. 
> For example:
> 
> https://fedoraproject.org/wiki/SIGs/Server
> 
> I'm wondering if we can avoid fedora-release-notes in minimal installation.
> 
> fedora-release-notes ~ 5MB

Upgrades from prior releases where the release notes were in fedora-release,
IIRC. There may be other reasons.

Bill



From sundaram at fedoraproject.org  Wed Jan 28 16:24:00 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 21:54:00 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <1233159449.4420.21.camel@localhost.localdomain>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>
	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>
	<49807A19.6060804@fedoraproject.org>
	<1233159449.4420.21.camel@localhost.localdomain>
Message-ID: <498086A0.7070208@fedoraproject.org>

David Malcolm wrote:

> How about this rewording in the first sentence:
>   from "to update a package on a release branch"
>   to "?to update a package on an already-released branch"
> to make it clearer that it's only talking about updates to released
> versions of Fedora.

Changed. Thank you.

Rahul



From hughsient at gmail.com  Wed Jan 28 16:25:55 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 28 Jan 2009 16:25:55 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <2d319b780901280810v7f317fc1v1ec08f5ad336926c@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<2d319b780901280810v7f317fc1v1ec08f5ad336926c@mail.gmail.com>
Message-ID: <1233159955.4231.1.camel@hughsie-work.lan>

On Wed, 2009-01-28 at 17:10 +0100, Mathieu Bridon (bochecha) wrote:
>  
> > so what's the point? Yum's changelog plugin is
> > much more useful than this proposal will ever be.
> 
> Actually, that's my fallback when no infos are provided in PK.
> 
> But that doesn't take away the fact that having infos in PK would be
> really nice :)

Sure, file a bug. I didn't know we could get the ChangeLog comments from
yum. There's already support for it in the PK API.

Richard.




From bochecha at fedoraproject.org  Wed Jan 28 16:39:50 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Wed, 28 Jan 2009 17:39:50 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233159955.4231.1.camel@hughsie-work.lan>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<2d319b780901280810v7f317fc1v1ec08f5ad336926c@mail.gmail.com>
	<1233159955.4231.1.camel@hughsie-work.lan>
Message-ID: <2d319b780901280839y65c06025m496b3b550a229609@mail.gmail.com>

>> > so what's the point? Yum's changelog plugin is
>> > much more useful than this proposal will ever be.
>>
>> Actually, that's my fallback when no infos are provided in PK.
>>
>> But that doesn't take away the fact that having infos in PK would be
>> really nice :)
>
> Sure, file a bug. I didn't know we could get the ChangeLog comments from
> yum. There's already support for it in the PK API.

No, I was talking about the infos about the update, the ones the
discussion is about, not the rpm changelog !

As said previously, it doesn't necessarily make sense (depending on
who is speaking) to have the rpm changelog displayed as the
information update in PK.


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From jkeating at redhat.com  Wed Jan 28 16:43:01 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 08:43:01 -0800
Subject: what requires fedora-release-notes
In-Reply-To: <20090128162403.GB6735@nostromo.devel.redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
Message-ID: <1233160981.8363.227.camel@localhost.localdomain>

On Wed, 2009-01-28 at 11:24 -0500, Bill Nottingham wrote:
> Peter Vrabec (pvrabec at redhat.com) said: 
> > Hi folks,
> > 
> > why does fedora-release require fedora-release-notes? There are different aims 
> > to adjust package dependencies for security or minimal installation reasons. 
> > For example:
> > 
> > https://fedoraproject.org/wiki/SIGs/Server
> > 
> > I'm wondering if we can avoid fedora-release-notes in minimal installation.
> > 
> > fedora-release-notes ~ 5MB
> 
> Upgrades from prior releases where the release notes were in fedora-release,
> IIRC. There may be other reasons.
> 
> Bill
> 

The spec has this comment:

# We require release notes to make sure that they don't get dropped during
# upgrades, and just because we always want the release notes available
# instead of explicitly asked for

I do believe this rational came from Jeremy Katz when I took over
fedora-release and we split out the release notes from that package.

I would certainly entertain revisiting this issue.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/dd802ac8/attachment.sig>

From notting at redhat.com  Wed Jan 28 16:50:41 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 28 Jan 2009 11:50:41 -0500
Subject: how to show upstream changes to the user
In-Reply-To: <20090127193859.GB18789@amd.home.annexia.org>
References: <E2AC825D4FC7764DA86D9C8ECA27A2DE02499B58@catoexm05.noam.corp.platform.com>
	<20090127160447.GA3474@nostromo.devel.redhat.com>
	<20090127193859.GB18789@amd.home.annexia.org>
Message-ID: <20090128165041.GA7956@nostromo.devel.redhat.com>

Richard W.M. Jones (rjones at redhat.com) said: 
> > If you don't have the time to find out, *as a maintainer*, what changed,
> > you shouldn't be maintaining it.
> 
> I don't think that's true at all.  As a *packager*, my job is to
> package correctly and respond to packaging bugs.  Sometimes that
> involves a little bit of code maintenance -- so you need to be a jack
> of all trades^Wprogramming languages -- but I am by no means an expert
> on the ins and outs of every version of every package I look after.

'Expert on the ins and outs'? You don't have to be able to rewrite
the program from scratch, but you should at least *look* when there's
a new release to get some idea of what changed, if for no other reason
than that will help you if you get bugs on it later.

Bill



From tcallawa at redhat.com  Wed Jan 28 17:00:26 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Jan 2009 12:00:26 -0500
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <49808F2A.6070906@redhat.com>

On 2009-01-26 at 5:15:01 -0500, Jakub Jelinek <jakub at redhat.com> wrote:
> On sparc I guess
> we could just -mcpu=ultrasparc -mtune=ultrasparc always, given that the
> 32-bit support is being dropped.

To be clear, 32bit hardware support is being dropped, we are continuing
to use a 32bit userland.

Let's leave "sparc" alone, as that is well established and documented as
being v7 optimized only.

Assuming that -m32 is still in play for sparcv9, the ultrasparc tunings
seem logical. We could even tune to niagara1 specific optimizations for
the sparcv9v (32bit) target if they exist.

sparc64 (64bit) already had the ultrasparc tuning, and if any niagara1
opts exist, we could use them for the sparc64v target.

~spot



From Matt_Domsch at dell.com  Wed Jan 28 17:11:36 2009
From: Matt_Domsch at dell.com (Matt Domsch)
Date: Wed, 28 Jan 2009 11:11:36 -0600
Subject: Request Info & Help
In-Reply-To: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>
References: <599059470901270631p3df3858eqeb2a0735cadbfde5@mail.gmail.com>
Message-ID: <20090128171136.GB17658@auslistsprd01.us.dell.com>

On Tue, Jan 27, 2009 at 08:01:33PM +0530, Roopesh Majeti wrote:
>    Hi All,
> 
>    Not sure if this is the right group to send the email.
>    When i tried to download the Fedora 10 iso from the following link :
> 
>    [1]http://ftp.iitm.ac.in/fedora/releases/10/Live/i686/F10-i686-Live.iso
> 

It's served via FTP at the same URL (just substitute ftp for http
above).  I've informed the admin for that mirror.

Thanks,
Matt
Fedora Mirror Wrangler

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux



From mschwendt at gmail.com  Wed Jan 28 17:49:40 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 28 Jan 2009 18:49:40 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233159955.4231.1.camel@hughsie-work.lan>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<2d319b780901280810v7f317fc1v1ec08f5ad336926c@mail.gmail.com>
	<1233159955.4231.1.camel@hughsie-work.lan>
Message-ID: <20090128184940.a2deb86a.mschwendt@gmail.com>

On Wed, 28 Jan 2009 16:25:55 +0000, Richard wrote:

> On Wed, 2009-01-28 at 17:10 +0100, Mathieu Bridon (bochecha) wrote:
> >  
> > > so what's the point? Yum's changelog plugin is
> > > much more useful than this proposal will ever be.
> > 
> > Actually, that's my fallback when no infos are provided in PK.
> > 
> > But that doesn't take away the fact that having infos in PK would be
> > really nice :)
> 
> Sure, file a bug. I didn't know we could get the ChangeLog comments from
> yum. There's already support for it in the PK API.

%changelog retrieval is broken, however, since parts of Yum try to
sort the entries based on timestamps, which are not accurate enough,
( http://yum.baseurl.org/ticket/6 and 7 ) and other parts of the
code try to "fix that" with even more sorting without being
successful.



From sgrubb at redhat.com  Wed Jan 28 18:00:19 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Jan 2009 13:00:19 -0500
Subject: Why does mkinitrd require plymouth?
Message-ID: <200901281300.20281.sgrubb@redhat.com>

why does mkinitrd require plymouth? There are different aims to adjust package 
dependencies for security or minimal installation reasons. For example:

https://fedoraproject.org/wiki/SIGs/Server

We would like to eliminate several packages from the minimal install. 

# rpm -e libpng
error: Failed dependencies:
        libpng12.so.0 is needed by (installed) 
plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
        libpng12.so.0 is needed by (installed) 
plymouth-0.6.0-0.2008.11.17.3.fc10.i386
        libpng12.so.0(PNG12_0) is needed by (installed) 
plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
[root at dhcp-lab-116 init.d]# rpm -e plymouth
error: Failed dependencies:
        plymouth >= 0.6.0-0.2008.09.10.1 is needed by (installed) 
mkinitrd-6.0.71-3.fc10.i386

Can we have mkinitrd to optionally use plymouth? If its there, build it in to 
the initrd. Otherwise let a server boot in text mode since it doesn't have a 
video display on it?

Thanks,
-Steve



From dmach at redhat.com  Wed Jan 28 18:02:41 2009
From: dmach at redhat.com (Daniel Mach)
Date: Wed, 28 Jan 2009 19:02:41 +0100
Subject: what requires fedora-release-notes
In-Reply-To: <1233160981.8363.227.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
Message-ID: <49809DC1.50805@redhat.com>

Jesse Keating wrote:
> On Wed, 2009-01-28 at 11:24 -0500, Bill Nottingham wrote:
>   
>> Peter Vrabec (pvrabec at redhat.com) said: 
>>     
>>> Hi folks,
>>>
>>> why does fedora-release require fedora-release-notes? There are different aims 
>>> to adjust package dependencies for security or minimal installation reasons. 
>>> For example:
>>>
>>> https://fedoraproject.org/wiki/SIGs/Server
>>>
>>> I'm wondering if we can avoid fedora-release-notes in minimal installation.
>>>
>>> fedora-release-notes ~ 5MB
>>>       
>> Upgrades from prior releases where the release notes were in fedora-release,
>> IIRC. There may be other reasons.
>>
>> Bill
>>
>>     
>
> The spec has this comment:
>
> # We require release notes to make sure that they don't get dropped during
> # upgrades, and just because we always want the release notes available
> # instead of explicitly asked for
>
> I do believe this rational came from Jeremy Katz when I took over
> fedora-release and we split out the release notes from that package.
>
> I would certainly entertain revisiting this issue.
>
>   
I think there is no technical reason why to keep this dependency.
fedora-release-notes doesn't contain any essential files and repoquery 
shows that is needed only by redhat-release.
But as was mentioned, there can be another reasons to keep it.

Jesse, is there any important data in this package which needs to be 
shipped in Fedora at any cost?
I can imagine some legal or licensing information about Fedora.

-- 
Daniel Mach <dmach at redhat.com>
Release Engineering, Red Hat



From Jochen at herr-schmitt.de  Wed Jan 28 18:03:38 2009
From: Jochen at herr-schmitt.de (Jochen Schmitt)
Date: Wed, 28 Jan 2009 19:03:38 +0100
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <200901281300.20281.sgrubb@redhat.com>
References: <200901281300.20281.sgrubb@redhat.com>
Message-ID: <49809DFA.4070409@herr-schmitt.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Grubb schrieb:
> why does mkinitrd require plymouth? There are different aims to
> adjust package dependencies for security or minimal installation
> reasons. For example:
As far as I have understood it, plymouth will be put into the initrd
to allow a
switch into a graphical mode as early as possible.

Best Regards:

Jochen Schmitt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmAnegACgkQT2AHK6txfgx5ZgCgisI2s0zHiTyNYwUQ3lsRVpld
n+cAoOeH/A8JB98meDqZR69WFtPpq9lv
=BZr/
-----END PGP SIGNATURE-----



From mschwendt at gmail.com  Wed Jan 28 18:00:17 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 28 Jan 2009 19:00:17 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233139028.3174.46.camel@hughsie-work.lan>
References: <497F5005.4060107@fedoraproject.org> <498011FB.6060809@freenet.de>
	<1233139028.3174.46.camel@hughsie-work.lan>
Message-ID: <20090128190017.fe0c3708.mschwendt@gmail.com>

On Wed, 28 Jan 2009 10:37:08 +0000, Richard wrote:

> On Wed, 2009-01-28 at 09:06 +0100, Ralf Corsepius wrote:
> > Rahul Sundaram wrote:
> > > Hi,
> > > 
> > > The following are a set of simple guidelines for the update descriptions 
> > > via bodhi (which is used by PackageKit to inform users of what has 
> > > changed). These guidelines are intended to help end users understand the 
> > > nature of changes in the update better. Bodhi is not used in rawhide, so 
> > > these guidelines are not applicable for rawhide updates. Note that this 
> > > is not connected to the rpm changelog.
> > -1, simply nuts

Silly and nuts!
 
> By saying "simply nuts" I assume you've not talked to any real users.
> 
> This IS useful:
> https://admin.fedoraproject.org/updates/hwdata-0.222-1.fc10

It's a lousy cut'n'paste job without much benefit for Joe User.
Just skim over the "Details". Intimidating!

> This IS NOT useful:
> https://admin.fedoraproject.org/updates/gromacs-4.0.3-2.fc10

Agreed. It's too brief, in particular since Bodhi doesn't display
the previous pkg EVR and no %changelog diff either.

> If we want to push our platform forward as "easy to use" and "suitable
> for new users" then this sort of thing is very important.

No, because they won't cherry-pick updates anyway. They expect the
package maintainers (== the distribution vendor) to offer updates
that just work.

On the contrary, what would be important to mention are the possible
risks of applying an update.



From mschwendt at gmail.com  Wed Jan 28 18:04:26 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Wed, 28 Jan 2009 19:04:26 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128152342.GC3119@mokona.greysector.net>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
Message-ID: <20090128190426.0a2f661d.mschwendt@gmail.com>

On Wed, 28 Jan 2009 16:23:42 +0100, Dominik wrote:

> On Tuesday, 27 January 2009 at 19:18, Rahul Sundaram wrote:
> [...]
> > ---
> > 
> > * All Updates must refer to a upstream changelog or equivalent if one 
> > exists. Otherwise a brief description (a couple of sentence at most) 
> > justifying the need for an update must be provided by the maintainers 
> > pushing the update.
> > 
> > * If there are downstream bugs being fixed or intended to be fixed with 
> > an update, it must be referred within the update. Maintainers can choose 
> > to let bodhi auto close bugs or close it manually as well.
> 
> This is redundant. bodhi has a field for bug numbers and it's pretty
> self-explanatory.

Bodhi itself, however, floods those bugzilla tickets with
comments. The most confusing comment is the one that notifies about
"submitted" (= pending) updates, which are only available within
koji. If we talk about "real users", this is the first comment
that ought to be killed, since users are confused a lot by 
updates, which are not available.



From jkeating at redhat.com  Wed Jan 28 18:03:06 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 10:03:06 -0800
Subject: what requires fedora-release-notes
In-Reply-To: <49809DC1.50805@redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<49809DC1.50805@redhat.com>
Message-ID: <1233165786.8363.228.camel@localhost.localdomain>

On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
>  
> Jesse, is there any important data in this package which needs to be 
> shipped in Fedora at any cost?
> I can imagine some legal or licensing information about Fedora.

I don't believe so.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/261ea7ae/attachment.sig>

From sundaram at fedoraproject.org  Wed Jan 28 18:05:30 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Wed, 28 Jan 2009 23:35:30 +0530
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <200901281300.20281.sgrubb@redhat.com>
References: <200901281300.20281.sgrubb@redhat.com>
Message-ID: <49809E6A.4070002@fedoraproject.org>

Steve Grubb wrote:
> why does mkinitrd require plymouth? There are different aims to adjust package 
> dependencies for security or minimal installation reasons. For example:
> 
> https://fedoraproject.org/wiki/SIGs/Server
> 
> We would like to eliminate several packages from the minimal install. 
> 
> # rpm -e libpng
> error: Failed dependencies:
>         libpng12.so.0 is needed by (installed) 
> plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
>         libpng12.so.0 is needed by (installed) 
> plymouth-0.6.0-0.2008.11.17.3.fc10.i386
>         libpng12.so.0(PNG12_0) is needed by (installed) 
> plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
> [root at dhcp-lab-116 init.d]# rpm -e plymouth
> error: Failed dependencies:
>         plymouth >= 0.6.0-0.2008.09.10.1 is needed by (installed) 
> mkinitrd-6.0.71-3.fc10.i386
> 
> Can we have mkinitrd to optionally use plymouth? If its there, build it in to 
> the initrd. Otherwise let a server boot in text mode since it doesn't have a 
> video display on it?

Plymouth is what provides the boot log as well.

Rahul



From tibbs at math.uh.edu  Wed Jan 28 18:04:52 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 28 Jan 2009 12:04:52 -0600
Subject: what requires fedora-release-notes
In-Reply-To: <1233160981.8363.227.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
Message-ID: <ufawscf71dn.fsf@epithumia.math.uh.edu>

>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:

JK> I would certainly entertain revisiting this issue.

I end up rebuilding fedora-release so that I can get rid of the
fedora-release-notes dependency; one less thing I have to customize
would be good (although I still won't be able to get away from
rebuilding fedora-release to use different repositories).

 - J<



From sgrubb at redhat.com  Wed Jan 28 18:07:55 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Jan 2009 13:07:55 -0500
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <49809DFA.4070409@herr-schmitt.de>
References: <200901281300.20281.sgrubb@redhat.com>
	<49809DFA.4070409@herr-schmitt.de>
Message-ID: <200901281307.55392.sgrubb@redhat.com>

On Wednesday 28 January 2009 01:03:38 pm Jochen Schmitt wrote:
> > why does mkinitrd require plymouth? There are different aims to
> > adjust package dependencies for security or minimal installation
> > reasons. For example:
>
> As far as I have understood it, plymouth will be put into the initrd
> to allow a switch into a graphical mode as early as possible.

Yeah, but servers never enter run level 5. We would like to remove this 
dependency chain if at all possible.

-Steve




From davej at redhat.com  Wed Jan 28 18:08:10 2009
From: davej at redhat.com (Dave Jones)
Date: Wed, 28 Jan 2009 13:08:10 -0500
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <49809DFA.4070409@herr-schmitt.de>
References: <200901281300.20281.sgrubb@redhat.com>
	<49809DFA.4070409@herr-schmitt.de>
Message-ID: <20090128180810.GB2036@redhat.com>

On Wed, Jan 28, 2009 at 07:03:38PM +0100, Jochen Schmitt wrote:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Steve Grubb schrieb:
 > > why does mkinitrd require plymouth? There are different aims to
 > > adjust package dependencies for security or minimal installation
 > > reasons. For example:
 > As far as I have understood it, plymouth will be put into the initrd
 > to allow a
 > switch into a graphical mode as early as possible.

AIUI, The primary reason it's there is to provide a user interface
for the 'enter your password' dialog if you have encrypted root.

	Dave

-- 
http://www.codemonkey.org.uk



From ville.skytta at iki.fi  Wed Jan 28 18:12:30 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Wed, 28 Jan 2009 20:12:30 +0200
Subject: what requires fedora-release-notes
In-Reply-To: <200901281624.31502.pvrabec@redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>
Message-ID: <200901282012.30892.ville.skytta@iki.fi>

On Wednesday 28 January 2009, Peter Vrabec wrote:

> fedora-release-notes ~ 5MB

By the way, at least as of F-9, there's a lot of different language files 
included in this package, none of which are marked with %lang, 
so %_install_langs doesn't help with the installed size.  I wonder if that's 
on purpose?



From bochecha at fedoraproject.org  Wed Jan 28 18:11:59 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Wed, 28 Jan 2009 19:11:59 +0100
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <20090128180810.GB2036@redhat.com>
References: <200901281300.20281.sgrubb@redhat.com>
	<49809DFA.4070409@herr-schmitt.de> <20090128180810.GB2036@redhat.com>
Message-ID: <2d319b780901281011w4aa80036w5c3093db5bf6e8d5@mail.gmail.com>

>  > As far as I have understood it, plymouth will be put into the initrd
>  > to allow a
>  > switch into a graphical mode as early as possible.
>
> AIUI, The primary reason it's there is to provide a user interface
> for the 'enter your password' dialog if you have encrypted root.

That was possible in text mode in Fedora 9.

In fact, RHGB used to crash on this question and the user then had to
enter the passphrase in text mode, the remaining of the boot being
text (has RHGB had crashed).


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From jkeating at redhat.com  Wed Jan 28 18:14:52 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 10:14:52 -0800
Subject: what requires fedora-release-notes
In-Reply-To: <200901282012.30892.ville.skytta@iki.fi>
References: <200901281624.31502.pvrabec@redhat.com>
	<200901282012.30892.ville.skytta@iki.fi>
Message-ID: <1233166492.8363.230.camel@localhost.localdomain>

On Wed, 2009-01-28 at 20:12 +0200, Ville Skytt? wrote:
> On Wednesday 28 January 2009, Peter Vrabec wrote:
> 
> > fedora-release-notes ~ 5MB
> 
> By the way, at least as of F-9, there's a lot of different language files 
> included in this package, none of which are marked with %lang, 
> so %_install_langs doesn't help with the installed size.  I wonder if that's 
> on purpose?

Probably not on purpose.  Paul Frields owns the package, shoot a patch
his way?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/ec452e8b/attachment.sig>

From jspaleta at gmail.com  Wed Jan 28 18:17:42 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Jan 2009 09:17:42 -0900
Subject: what requires fedora-release-notes
In-Reply-To: <ufawscf71dn.fsf@epithumia.math.uh.edu>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<ufawscf71dn.fsf@epithumia.math.uh.edu>
Message-ID: <604aa7910901281017v773c86bancb86e24522568f71@mail.gmail.com>

On Wed, Jan 28, 2009 at 9:04 AM, Jason L Tibbitts III <tibbs at math.uh.edu> wrote:
>>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:
>
> JK> I would certainly entertain revisiting this issue.
>
> I end up rebuilding fedora-release so that I can get rid of the
> fedora-release-notes dependency; one less thing I have to customize
> would be good (although I still won't be able to get away from
> rebuilding fedora-release to use different repositories).

Can you explain why you are rebuilding fedora-release?

I thought we provided generic-release package so that you don't have
to rebuild fedora-release as part of customization.  generic-release
or anything structured like it in terms of provides, should be a drop
in replacement for fedora-release.

The only packages which should be explicitly requiring
'fedora-release' instead of 'system-release' are packages which have
fedora trademarks.

if I were are going to make a custom release package for local use,
I'd start with generic-release  rename it jef-release and fill it with
the repository definitions I care about. Install jef-release, remove
fedora-release  and then enjoy life.

-jef



From jkeating at redhat.com  Wed Jan 28 18:16:39 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 10:16:39 -0800
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <2d319b780901281011w4aa80036w5c3093db5bf6e8d5@mail.gmail.com>
References: <200901281300.20281.sgrubb@redhat.com>
	<49809DFA.4070409@herr-schmitt.de> <20090128180810.GB2036@redhat.com>
	<2d319b780901281011w4aa80036w5c3093db5bf6e8d5@mail.gmail.com>
Message-ID: <1233166599.8363.232.camel@localhost.localdomain>

On Wed, 2009-01-28 at 19:11 +0100, Mathieu Bridon (bochecha) wrote:
>  
> That was possible in text mode in Fedora 9.
> 
> In fact, RHGB used to crash on this question and the user then had to
> enter the passphrase in text mode, the remaining of the boot being
> text (has RHGB had crashed).

And now instead of two different code paths to get the passphrase
entered, we have one.

Plymouth is what provides the "text" mode bootup.  It /also/ provides
the graphical boot up, via plugins.  It is what generates boot.log,
shows messages on the screen, and captures passphrases for encrypted
root.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/a0eecd0f/attachment.sig>

From halfline at gmail.com  Wed Jan 28 18:19:59 2009
From: halfline at gmail.com (Ray Strode)
Date: Wed, 28 Jan 2009 13:19:59 -0500
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <200901281300.20281.sgrubb@redhat.com>
References: <200901281300.20281.sgrubb@redhat.com>
Message-ID: <45abe7d80901281019y2eefb8c2vff6e84408159b1fb@mail.gmail.com>

Hi,

> We would like to eliminate several packages from the minimal install.
>
> # rpm -e libpng
> error: Failed dependencies:
>        libpng12.so.0 is needed by (installed)
> plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
>        libpng12.so.0 is needed by (installed)
> plymouth-0.6.0-0.2008.11.17.3.fc10.i386
>        libpng12.so.0(PNG12_0) is needed by (installed)
> plymouth-libs-0.6.0-0.2008.11.17.3.fc10.i386
> [root at dhcp-lab-116 init.d]# rpm -e plymouth
> error: Failed dependencies:
>        plymouth >= 0.6.0-0.2008.09.10.1 is needed by (installed)
> mkinitrd-6.0.71-3.fc10.i386
>
> Can we have mkinitrd to optionally use plymouth? If its there, build it in to
> the initrd. Otherwise let a server boot in text mode since it doesn't have a
> video display on it?
Plymouth is a required part of the system. It's not just graphical
boot, it's integral to text boot up, too (rc.sysinit hooks into it for
some reasons, it handles boot.log etc).

It could probably be made to not have a hard libpng dependency,
though.  In fact, I thought I fixed this already for Lennart, but
maybe I'm misremembering.  File a bug in bugzilla.

--Ray



From ivazqueznet at gmail.com  Wed Jan 28 18:15:47 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Wed, 28 Jan 2009 13:15:47 -0500
Subject: what requires fedora-release-notes
In-Reply-To: <49809DC1.50805@redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<49809DC1.50805@redhat.com>
Message-ID: <1233166547.1025.56.camel@ignacio.lan>

On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
> Jesse, is there any important data in this package which needs to be 
> shipped in Fedora at any cost?
> I can imagine some legal or licensing information about Fedora.

What about changing it to a Requires(pre)? That way it's installed, but
can easily be removed once the release notes have been read *smirk*.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/1c79b536/attachment.sig>

From kevin.kofler at chello.at  Wed Jan 28 18:23:01 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 19:23:01 +0100
Subject: support for latest (radeon) hardware
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<glg41r$dp7$1@ger.gmane.org>	<1233084071.19014.36.camel@localhost.localdomain>	<4980115D.7070808@hhs.nl>
	<glpd6s$rqh$1@ger.gmane.org> <49805FA1.5020804@rincon.com>
Message-ID: <glq7q5$vd2$1@ger.gmane.org>

Bob Arendt wrote:
> Although there's now a single intel driver, for some of the older chipsets
> (intel 845G) that *did* have acceleration + 3d under the old i810 driver
> F9, it's now terribly broken

Uh, F9 already shipped only the "intel" driver, not the old "i810" one, it's
just an older version of that driver.

        Kevin Kofler



From vonbrand at inf.utfsm.cl  Wed Jan 28 18:23:50 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 28 Jan 2009 15:23:50 -0300
Subject: what requires fedora-release-notes
In-Reply-To: <1233160981.8363.227.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
Message-ID: <200901281823.n0SINoKb006554@laptop14.inf.utfsm.cl>

Jesse Keating <jkeating at redhat.com> wrote:
> On Wed, 2009-01-28 at 11:24 -0500, Bill Nottingham wrote:
> > Peter Vrabec (pvrabec at redhat.com) said: 
> > > Hi folks,

> > > why does fedora-release require fedora-release-notes? There are
> > > different aims to adjust package dependencies for security or
> > > minimal installation reasons. For example:
> > > 
> > > https://fedoraproject.org/wiki/SIGs/Server
> > > 
> > > I'm wondering if we can avoid fedora-release-notes in minimal
> > > installation.
> > > 
> > > fedora-release-notes ~ 5MB

> > Upgrades from prior releases where the release notes were in
> > fedora-release, IIRC. There may be other reasons.

> The spec has this comment:
> 
> # We require release notes to make sure that they don't get dropped during
> # upgrades, and just because we always want the release notes available
> # instead of explicitly asked for
> 
> I do believe this rational came from Jeremy Katz when I took over
> fedora-release and we split out the release notes from that package.

Sounds reasonable.

> I would certainly entertain revisiting this issue.

Wouldn't it be enough to make it part of the "default package set"? So if
you don't want it (minimal system, LiveCD, ...) you can leave it out
without jumping through hoops.
-- 
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 kevin.kofler at chello.at  Wed Jan 28 18:32:01 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 19:32:01 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>
	<7dd7ab490901261337r5f8273bfh8c3767098541f547@mail.gmail.com>
	<497EC8E5.3000607@fedoraproject.org>
	<7dd7ab490901271238j2b6265d0l3d05881ff836637d@mail.gmail.com>
	<497F73E0.1030109@fedoraproject.org>
	<7dd7ab490901271259l67b0446bnf89bea60374c9f9d@mail.gmail.com>
	<497F784F.8040507@fedoraproject.org>
	<7dd7ab490901271422r28955d0dy24ed37969c0b5a86@mail.gmail.com>
Message-ID: <glq8b2$2ce$1@ger.gmane.org>

Chris Weyl wrote:
> Really?  Filling in that field has always been manual? hm. Funny this
> works then:
> 
>     bodhi -n -c "`cat clog`" -r F-X -t enhancement -R testing `make
>     verrel`

And this is usually a horrible thing to fill in, unless "clog" already
contains a rationale why the update is being pushed and a short summary of
changes rather than a long FSF-style changelog with things like:

2009-01-28 John Doe <foo at example.com>

        * version.c (VERSION): Bump version.
        * main.c (main): Likewise.
        * foo.c (bar): Likewise.

2009-01-01 Luke Pedant <pedant at example.com>

        * a.c: Bump copyright date.
        * b.c: Likewise.
        * c.c: Likewise.
        * foo.c: Likewise.
        * main.c: Likewise.
        * version.c: Likewise.
        * x.c: Likewise.

etc.

        Kevin Kofler



From sgrubb at redhat.com  Wed Jan 28 18:34:02 2009
From: sgrubb at redhat.com (Steve Grubb)
Date: Wed, 28 Jan 2009 13:34:02 -0500
Subject: Why does mkinitrd require plymouth?
In-Reply-To: <45abe7d80901281019y2eefb8c2vff6e84408159b1fb@mail.gmail.com>
References: <200901281300.20281.sgrubb@redhat.com>
	<45abe7d80901281019y2eefb8c2vff6e84408159b1fb@mail.gmail.com>
Message-ID: <200901281334.02471.sgrubb@redhat.com>

On Wednesday 28 January 2009 01:19:59 pm Ray Strode wrote:
> It could probably be made to not have a hard libpng dependency,
> though. ?In fact, I thought I fixed this already for Lennart, but
> maybe I'm misremembering. ?File a bug in bugzilla.

OK, being able to drop libpng would be helpful - bz 482899.

Thanks,
-Steve



From stickster at gmail.com  Wed Jan 28 18:50:15 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 28 Jan 2009 13:50:15 -0500
Subject: what requires fedora-release-notes
In-Reply-To: <1233165786.8363.228.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<49809DC1.50805@redhat.com>
	<1233165786.8363.228.camel@localhost.localdomain>
Message-ID: <20090128185015.GE11811@localhost.localdomain>

On Wed, Jan 28, 2009 at 10:03:06AM -0800, Jesse Keating wrote:
> On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
> >  
> > Jesse, is there any important data in this package which needs to be 
> > shipped in Fedora at any cost?
> > I can imagine some legal or licensing information about Fedora.
> 
> I don't believe so.

The arguable value of the "About Fedora" item -- which as some Desktop
team members have noted, probably needs to be revamped -- is certainly
not enough to keep it.  It would be prudent and probably good manners
to alert the Docs team about contemplating dropping this, too.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/1bc929ce/attachment.sig>

From stickster at gmail.com  Wed Jan 28 18:56:47 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 28 Jan 2009 13:56:47 -0500
Subject: what requires fedora-release-notes
In-Reply-To: <1233166492.8363.230.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<200901282012.30892.ville.skytta@iki.fi>
	<1233166492.8363.230.camel@localhost.localdomain>
Message-ID: <20090128185647.GG11811@localhost.localdomain>

On Wed, Jan 28, 2009 at 10:14:52AM -0800, Jesse Keating wrote:
> On Wed, 2009-01-28 at 20:12 +0200, Ville Skytt? wrote:
> > On Wednesday 28 January 2009, Peter Vrabec wrote:
> > 
> > > fedora-release-notes ~ 5MB
> > 
> > By the way, at least as of F-9, there's a lot of different language files 
> > included in this package, none of which are marked with %lang, 
> > so %_install_langs doesn't help with the installed size.  I wonder if that's 
> > on purpose?
> 
> Probably not on purpose.  Paul Frields owns the package, shoot a patch
> his way?

Yeah, definitely not on purpose.  Patch/bug filing appreciated.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/78f8cf03/attachment.sig>

From jkeating at redhat.com  Wed Jan 28 19:05:41 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 11:05:41 -0800
Subject: what requires fedora-release-notes
In-Reply-To: <20090128185015.GE11811@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<49809DC1.50805@redhat.com>
	<1233165786.8363.228.camel@localhost.localdomain>
	<20090128185015.GE11811@localhost.localdomain>
Message-ID: <1233169541.8363.234.camel@localhost.localdomain>

On Wed, 2009-01-28 at 13:50 -0500, Paul W. Frields wrote:
> On Wed, Jan 28, 2009 at 10:03:06AM -0800, Jesse Keating wrote:
> > On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
> > >  
> > > Jesse, is there any important data in this package which needs to be 
> > > shipped in Fedora at any cost?
> > > I can imagine some legal or licensing information about Fedora.
> > 
> > I don't believe so.
> 
> The arguable value of the "About Fedora" item -- which as some Desktop
> team members have noted, probably needs to be revamped -- is certainly
> not enough to keep it.  It would be prudent and probably good manners
> to alert the Docs team about contemplating dropping this, too.
> 

Well, we would make it a default install item via groupings, but perhaps
not /forced/ install, so that one could remove it/opt out of installing
it should they wish.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/d412111b/attachment.sig>

From vonbrand at inf.utfsm.cl  Wed Jan 28 19:21:29 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 28 Jan 2009 16:21:29 -0300
Subject: Lack of update information
In-Reply-To: <glpe24$us0$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org> <497D716D.3060709@gmail.com>
	<f6ca9fed0901260028u1ec21fefy4b64ac5dbc3b11ac@mail.gmail.com>
	<1232989018.8363.143.camel@localhost.localdomain>
	<20090127022910.GQ5565@x300>
	<7dd7ab490901261847o6ffb8f56kfb87486f43194cc6@mail.gmail.com>
	<glmitr$uvt$1@ger.gmane.org>
	<7dd7ab490901271230n5ae22c78ga374945ee80577ba@mail.gmail.com>
	<glpe24$us0$1@ger.gmane.org>
Message-ID: <200901281921.n0SJLTSj013860@laptop14.inf.utfsm.cl>

Kevin Kofler <kevin.kofler at chello.at> wrote:
> Chris Weyl wrote:
> > Neither is it difficult to rig something to point automatically at an
> > included package changelog.  Before we mandate a new manual task,
> > can't we at least try an automated approach first?

> The included changelog is often way too detailed (especially FSF-style
> changelogs, see e.g. the GCC one) and it also doesn't give the rationale
> why the update is being pushed. And there are also many packages where the
> changelog is provided on some web page, not as part of the source code. So
> this is no substitute for doing it properly.

I for one don't think asking (not demanding!) a short paragraph giving the
rationale of doing the new package is too much to ask. The packager must
have some reason for pushing the new version, particularly for a released
branch.
-- 
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  Wed Jan 28 19:17:52 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Wed, 28 Jan 2009 16:17:52 -0300
Subject: Lack of update information
In-Reply-To: <4980214E.7060005@freenet.de>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de> <1233117612.14094.83.camel@rosebud>
	<4980214E.7060005@freenet.de>
Message-ID: <200901281917.n0SJHquM013841@laptop14.inf.utfsm.cl>

Ralf Corsepius <rc040203 at freenet.de> wrote:
> [Detailed VM/time measurements]

Thanks!

> What I actually would like to know is which impact switching to
> e.g. bzip2 or lzma compressed payloads would have on end-users.
> 
> I.e. answers/input related to
> * disk-space requirements
> Would such step shrink the isos rsp. give room on isos?

It should, but not by very much.

> * end-user's throughput during downloads.
> In the past, there have been claims, bzip2 compression would have
> negative impacts on network-throughput because it would defeat
> low-level compression on networks (e.g. modems, isdn). Is this claim
> true, can it be verified, how about lzma and friends?

This is probably nonsense, modems and such use a variant of the original
compress(1), which won't be able to compress gzip(1)ed data any better than
shiny-new-compression-ed data.

> * rpm's installation times/memory requirement (time required for
> decompression, memory being used during decompression).
> bzip2 has quite

bzip2(1) uncompression requires a lot more RAM and CPU than gzip(1).
-- 
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 nicolas.mailhot at laposte.net  Wed Jan 28 19:45:24 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 28 Jan 2009 20:45:24 +0100
Subject: what requires fedora-release-notes
In-Reply-To: <1233160981.8363.227.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
Message-ID: <1233171924.7063.10.camel@arekh.okg>

Le mercredi 28 janvier 2009 ? 08:43 -0800, Jesse Keating a ?crit :

> The spec has this comment:
> 
> # We require release notes to make sure that they don't get dropped during
> # upgrades, and just because we always want the release notes available
> # instead of explicitly asked for
> 
> I do believe this rational came from Jeremy Katz when I took over
> fedora-release and we split out the release notes from that package.
> 
> I would certainly entertain revisiting this issue.

This certainly suggests removing the dep and just declaring the package
in one of the default install groups

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/b1825a6e/attachment.sig>

From kevin.kofler at chello.at  Wed Jan 28 20:07:08 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 21:07:08 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<glmjcp$uvt$2@ger.gmane.org>
	<1233078193.8363.195.camel@localhost.localdomain>
Message-ID: <glqdtc$mlr$1@ger.gmane.org>

Jesse Keating wrote:
> That's the kind of elitist crap attitude I hate to see in Fedora.
> 
> I agree that broadband should be a requirement for using /rawhide/ where
> the churn is expected to be great, however I refuse to agree that we
> should treat our /stable/ releases in the same way.

Guess what, people like me are using Fedora *because* of its many updates.
That's its niche. If we start pushing only minimal updates, what
distinguishes us from Ubuntu? They also release every 6 months. Having all
distros work the same way means we're all forced to use the "common
denominator" even if it doesn't fit our needs at all.

IMHO people with slow Internet connections are served much better by CentOS:
few updates (only security updates and the occasional bugfix) and no need
to upgrade to a new release (which they have to buy on media, most likely)
at least once a year.

We can try to serve those people with features like Presto (and IMHO it
should have a much higher priority, as it indeed lowers the bar for the
bandwidth requirements and it'll also help mirrors and speed up downloads
for everyone) and LZMA payloads, but dropping one of Fedora's main
distinguishing features just to accomodate low-bandwidth users is really
throwing the baby out with the bathwater!

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 28 20:09:51 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 21:09:51 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de> <1233117612.14094.83.camel@rosebud>
	<4980214E.7060005@freenet.de>
	<200901281917.n0SJHquM013841@laptop14.inf.utfsm.cl>
Message-ID: <glqe2f$mlr$2@ger.gmane.org>

Horst H. von Brand wrote:
> bzip2(1) uncompression requires a lot more RAM and CPU than gzip(1).

But LZMA doesn't and in most cases it compresses even better than bzip2.

        Kevin Kofler



From poelstra at redhat.com  Wed Jan 28 20:24:26 2009
From: poelstra at redhat.com (John Poelstra)
Date: Wed, 28 Jan 2009 12:24:26 -0800
Subject: Fedora Release Engineering Meeting Recap 2009-01-26 
Message-ID: <4980BEFA.9020409@redhat.com>

Recap and full IRC transcript found here:
https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2009-jan-26

Please make corrections and clarifications to the wiki page.


== Fedora 11 Alpha Status ==
* Refreshing freeze tag
* two open issues:
*# nash mounting by label/uuid bug
*# ppc not working
* gpg signing is a bit up in the air right
** we need bigger bit sigs to comply with the sha-256 mandate which will 
require some buildsystem updates
** Alpha will not be signed

== Fedora 11 Alpha Refresh ==
* we're considering refreshing the alpha tag
* koji clone-tag action to bring f11-alpha up to par with dist-f11 late 
tonight
** Tuesday's rawhide == F11 alpha

== IRC Transcript ==



From jkeating at redhat.com  Wed Jan 28 20:26:39 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 12:26:39 -0800
Subject: Lack of update information
In-Reply-To: <glqe2f$mlr$2@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr> <497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de> <1233117612.14094.83.camel@rosebud>
	<4980214E.7060005@freenet.de>
	<200901281917.n0SJHquM013841@laptop14.inf.utfsm.cl>
	<glqe2f$mlr$2@ger.gmane.org>
Message-ID: <1233174399.8363.236.camel@localhost.localdomain>

On Wed, 2009-01-28 at 21:09 +0100, Kevin Kofler wrote:
> Horst H. von Brand wrote:
> > bzip2(1) uncompression requires a lot more RAM and CPU than gzip(1).
> 
> But LZMA doesn't and in most cases it compresses even better than bzip2.
> 
>         Kevin Kofler

IIRC upstream RPM is waiting for lzma to stabilize.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/9a5b4685/attachment.sig>

From jkeating at redhat.com  Wed Jan 28 20:28:31 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 12:28:31 -0800
Subject: Lack of update information
In-Reply-To: <glqdtc$mlr$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<glmjcp$uvt$2@ger.gmane.org>
	<1233078193.8363.195.camel@localhost.localdomain>
	<glqdtc$mlr$1@ger.gmane.org>
Message-ID: <1233174511.8363.238.camel@localhost.localdomain>

On Wed, 2009-01-28 at 21:07 +0100, Kevin Kofler wrote:
>  Guess what, people like me are using Fedora *because* of its many updates.
> That's its niche. If we start pushing only minimal updates, what
> distinguishes us from Ubuntu? They also release every 6 months. Having all
> distros work the same way means we're all forced to use the "common
> denominator" even if it doesn't fit our needs at all.

You know just as well as I do that there is reasonable middle ground
between every upstream release every where every time, and the slowness
that is CentOS or maybe even ubuntu.

All I ask is that updates are being made for actual reasons that benefit
the end user and are easy to explain to the end user, something other
than "well it has a higher number, thus it must be better."

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/2d9d8925/attachment.sig>

From kevin.kofler at chello.at  Wed Jan 28 20:30:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 21:30:44 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>
	<497E503C.8090400@poolshark.org> <glmjkr$uvt$3@ger.gmane.org>
	<497F7A2E.90509@poolshark.org>
Message-ID: <glqf9m$s29$1@ger.gmane.org>

Denis Leroy wrote:
> Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
> while ago. How would you summarize it to Bodhi ?

Ugh, doesn't upstream provide a more user-readable list of changes? IMHO
they should get that complaint...

And it's true that it's particularly hard to summarize bugfixes in a library
(like that printer signal proxy fix) without knowing a concrete application
bug they fix.

In any case, try this:

Update to the latest upstream release, 2.15.0, which fixes the use of some
deprecated APIs and header files (which caused programs using gtkmm with
GTK_DISABLE_DEPRECATED to fail to build) and a bug in the printer signal
proxy which could cause application crashes (the printer object was being
unreferenced at an inappropriate place), adds some new APIs which may be
required to compile new gtkmm-using software:
* GtkHandleBox::child-attached (signal) and GtkLinkButton::visited
(property), which were accidentally missing in 2.14.x
* unset_model() methods for GtkCellView, GtkComboBox, GtkEntryCompletion,
GtkIconView and GtkTreeView
* a parameterless version of GtkWindow::invalidate()
* GtkCellRendererPixbuf::icon-name and GtkCellRendererPixbuf::follow-state
(properties)
and includes some minor documentation fixes.

But I'll admit this took me several minutes to write.

        Kevin Kofler



From rvinyard at cs.nmsu.edu  Wed Jan 28 20:47:18 2009
From: rvinyard at cs.nmsu.edu (rvinyard at cs.nmsu.edu)
Date: Wed, 28 Jan 2009 13:47:18 -0700 (MST)
Subject: PackageKit application icons
Message-ID: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>

I was just noticing that several of the applications in pkg-application
(the PackageKit app) have cool app-specific icons (it really makes the
experience much better).

So my question question is... how did they get there, and how do I add
them for the packages I maintain? I've searched on the fedoraproject.org
wiki to no avail.



From sundaram at fedoraproject.org  Wed Jan 28 20:50:41 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 02:20:41 +0530
Subject: PackageKit application icons
In-Reply-To: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
Message-ID: <4980C521.4030202@fedoraproject.org>

rvinyard at cs.nmsu.edu wrote:
> I was just noticing that several of the applications in pkg-application
> (the PackageKit app) have cool app-specific icons (it really makes the
> experience much better).
> 
> So my question question is... how did they get there, and how do I add
> them for the packages I maintain? I've searched on the fedoraproject.org
> wiki to no avail.

My understanding is that they are picked up  (along with executable 
names) from the desktop files  (foo.desktop). When you are including a 
desktop file for your package, make sure you include a icon as well.

Rahul



From rvinyard at cs.nmsu.edu  Wed Jan 28 21:05:15 2009
From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.)
Date: Wed, 28 Jan 2009 14:05:15 -0700 (MST)
Subject: PackageKit application icons
In-Reply-To: <4980C521.4030202@fedoraproject.org>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
Message-ID: <56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>

Rahul Sundaram wrote:
> rvinyard at cs.nmsu.edu wrote:
>> I was just noticing that several of the applications in pkg-application
>> (the PackageKit app) have cool app-specific icons (it really makes the
>> experience much better).
>>
>> So my question question is... how did they get there, and how do I add
>> them for the packages I maintain? I've searched on the fedoraproject.org
>> wiki to no avail.
>
> My understanding is that they are picked up  (along with executable
> names) from the desktop files  (foo.desktop). When you are including a
> desktop file for your package, make sure you include a icon as well.
>

Ahhh... I see that now, and they're already there.

It's a shame that's the only mechanism for adding icons. I'd like to see
something other than cardboard boxes when looking for devel packages.



From notting at redhat.com  Wed Jan 28 21:17:51 2009
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 28 Jan 2009 16:17:51 -0500
Subject: PackageKit application icons
In-Reply-To: <56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
Message-ID: <20090128211750.GA15085@nostromo.devel.redhat.com>

Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said: 
> Ahhh... I see that now, and they're already there.
> 
> It's a shame that's the only mechanism for adding icons. I'd like to see
> something other than cardboard boxes when looking for devel packages.

The problem is you'd either need to:

- include icons in the metadata (which gets very large, very fast)
- create a package that consists of all the icons that may be in
  the distro (which gets very messy to maintain, very fast)

Neither of these are particularly good solutions.

Bill



From tcallawa at redhat.com  Wed Jan 28 21:23:06 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Jan 2009 16:23:06 -0500
Subject: PackageKit application icons
In-Reply-To: <20090128211750.GA15085@nostromo.devel.redhat.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>	<4980C521.4030202@fedoraproject.org>	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
Message-ID: <4980CCBA.4080006@redhat.com>

On 2009-01-28 at 16:17:51 -0500, Bill Nottingham <notting at redhat.com> wrote:
> Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said: 
>> Ahhh... I see that now, and they're already there.
>>
>> It's a shame that's the only mechanism for adding icons. I'd like to see
>> something other than cardboard boxes when looking for devel packages.
> 
> The problem is you'd either need to:
> 
> - include icons in the metadata (which gets very large, very fast)
> - create a package that consists of all the icons that may be in
>   the distro (which gets very messy to maintain, very fast)
> 
> Neither of these are particularly good solutions.

Well, we do have a PackageDB. Why couldn't we permit maintainers to go to:

https://admin.fedoraproject.org/packagedb

Then, on the page for the package (once logged in, of course), click on
the icon next to the package name (a question mark by default) and
upload an icon. Then, extend the PackageDB API such that PackageKit
tries to call out to PackageDB to get icons on a per package basis
(also, as a list of packages).

~spot



From rvinyard at cs.nmsu.edu  Wed Jan 28 21:24:46 2009
From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.)
Date: Wed, 28 Jan 2009 14:24:46 -0700 (MST)
Subject: PackageKit application icons
In-Reply-To: <20090128211750.GA15085@nostromo.devel.redhat.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
Message-ID: <36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>

Bill Nottingham wrote:
> Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>> Ahhh... I see that now, and they're already there.
>>
>> It's a shame that's the only mechanism for adding icons. I'd like to see
>> something other than cardboard boxes when looking for devel packages.
>
> The problem is you'd either need to:
>
> - include icons in the metadata (which gets very large, very fast)
> - create a package that consists of all the icons that may be in
>   the distro (which gets very messy to maintain, very fast)
>
> Neither of these are particularly good solutions.
>

I agree that neither of those are good solutions, but there is another
option.

Currently, the icons reside in each package and the desktop entry file
(also in the individual packages) is used to associate the package with
the icon.

Why couldn't devel packages (and others without desktop entry files)
follow a similar approach containing the icon and association?



From forum at ru.bir.ru  Wed Jan 28 21:24:29 2009
From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus))
Date: Thu, 29 Jan 2009 00:24:29 +0300
Subject: New package from one source
In-Reply-To: <497A53CD.1050605@fedoraproject.org>
References: <gl2t8r$rm$1@ger.gmane.org>	<20090119221149.GA10949@nostromo.devel.redhat.com>	<gl40q6$pob$1@ger.gmane.org>	<20090120184236.GA10482@nostromo.devel.redhat.com>	<gldh77$3sc$1@ger.gmane.org>
	<497A53CD.1050605@fedoraproject.org>
Message-ID: <glqiee$89u$1@ger.gmane.org>

Rahul Sundaram write:
> Pavel Alexeev (aka Pahan-Hubbitus) wrote:
> 
>> I'm afraid I don't completely understand you. About what maintenance 
>> load you are speaking?
>> Is there any polices or guidelines about it?
> 
> Any upstream deviation usually causes a higher maintenance load since 
> the downstream patch set has to be re-based for every upstream release. 
> For a active project like Apache, you should focus on getting the 
> patches integrated upstream and benefiting all downstream distributions 
> and not just Fedora.
> 
> For guidelines and policies refer
> 
> https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment 
> 
> http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> 
Hello Rahul,
Thank you for the big work what you make writing this document (second 
link). And most of this things is basically known.
As I mention above, what about your first link - main apache rpm package 
fully ignore this guidelines!

But why you are not consider Steinar H. Gunderson as upstream amintainer 
of apache mpm-itk???
In any case, as maintainer of package I take care about maintenance load 
by this rpm. As I remember, it had not any urgent issues with adaptation 
to current releases of apache for the past year or even more.

P.S. I'm write mail to Steinar H. Gunderson with question why it is not 
in upstream...



From drago01 at gmail.com  Wed Jan 28 21:31:57 2009
From: drago01 at gmail.com (drago01)
Date: Wed, 28 Jan 2009 22:31:57 +0100
Subject: PackageKit application icons
In-Reply-To: <4980CCBA.4080006@redhat.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<4980CCBA.4080006@redhat.com>
Message-ID: <f6ca9fed0901281331q236ef272o67af3a0f6818c256@mail.gmail.com>

On Wed, Jan 28, 2009 at 10:23 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
> On 2009-01-28 at 16:17:51 -0500, Bill Nottingham <notting at redhat.com> wrote:
>> Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>>> Ahhh... I see that now, and they're already there.
>>>
>>> It's a shame that's the only mechanism for adding icons. I'd like to see
>>> something other than cardboard boxes when looking for devel packages.
>>
>> The problem is you'd either need to:
>>
>> - include icons in the metadata (which gets very large, very fast)
>> - create a package that consists of all the icons that may be in
>>   the distro (which gets very messy to maintain, very fast)
>>
>> Neither of these are particularly good solutions.
>
> Well, we do have a PackageDB. Why couldn't we permit maintainers to go to:
>
> https://admin.fedoraproject.org/packagedb
>
> Then, on the page for the package (once logged in, of course), click on
> the icon next to the package name (a question mark by default) and
> upload an icon. Then, extend the PackageDB API such that PackageKit
> tries to call out to PackageDB to get icons on a per package basis
> (also, as a list of packages).

Doesn't sound like a good idea. Unless we have packageDB mirrors.



From mw_triad at users.sourceforge.net  Wed Jan 28 21:32:35 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 28 Jan 2009 15:32:35 -0600
Subject: Lack of update information
In-Reply-To: <497FDFBF.4070209@freenet.de>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<gllh0a$ha1$1@ger.gmane.org>	<1233013714.8363.167.camel@localhost.localdomain>	<497E53E3.1060302@freenet.de>	<1233017758.8363.183.camel@localhost.localdomain>	<497E6D62.4060708@freenet.de>	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de>
Message-ID: <glqitj$96k$1@ger.gmane.org>

Ralf Corsepius wrote:
> Jesse Keating wrote:
>> Try doing updates on a netbook, 
> I own one - Typical "yum update" times are in the order of "very few" 
> minutes at average.

Looking only at install times...

Asus EEE 900A (SSD): 3m40s
HP xw4400 Workstation (SATA platter): 1m25s

...and the latter did kernel-devel as well as kernel, kernel-headers and 
kernel-firmware, plus it also had to remove a kmod-nvidia. (Times are 
approximate.)

...so the SSD is about 3x slower or more (especially as I notice 
kernel-devel took the desktop the longest).

>>  Yum isn't really the problem here, it's the
>> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
>> hardlinking, etc... 
> 
>  From what I experience, SELinux policy updates are by far means the 
> most resource intense/most time consuming part of updating.

Really? For me, it's always OOo updates... 100 MB in a single package? 
(What's worse is that OOo can't be updated while running... it doesn't 
crash, but it becomes unable to save; bad news if you forgot to save 
first. That and Firefox are the only things I'm aware of with that 
problem, but at least with FF it only breaks typing addresses into the 
address bar.)

Whereas selinux is a 2.0 MB package :-).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's impossible! But... do-able."
   -- Robert MacDougal (Sean Connery, Entrapment)



From seg at haxxed.com  Wed Jan 28 21:36:38 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Wed, 28 Jan 2009 15:36:38 -0600
Subject: Default ISA/tuning flags for GCC, --enable-kernel= level for
 glibc
In-Reply-To: <20090126113010.GF5690@tyan-ft48-01.lab.bos.redhat.com>
References: <20090126101501.GE5690@tyan-ft48-01.lab.bos.redhat.com>
	<20090126110648.GA8937@mokona.greysector.net>
	<20090126113010.GF5690@tyan-ft48-01.lab.bos.redhat.com>
Message-ID: <1233178599.5955.26.camel@localhost.localdomain>

On Mon, 2009-01-26 at 12:30 +0100, Jakub Jelinek wrote:
> On Mon, Jan 26, 2009 at 12:06:49PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > I don't know about non-x86 arches (it's probably less of a problem), but
> > for x86 such change can (as you probably know) affect the overall speed
> > of the generated code and must be benchmarked. I would be in favour of
> > changing the default cflags to include -march=i586 if it gives measurable
> > benefits, i.e. faster binaries and/or smaller code size, but slower binaries
> > are not acceptable.
> 
> Performance on i?86 is mostly the matter of -mtune, which should stay the
> same (-mtune=generic, tuning for contemporary Intel and AMD CPUs).
> The difference between -march=i386 -mtune=generic and -march=i486 -mtune=generic
> is just that xadd[bwl], bswap and cmpxchg[bwl] insns can be generated for the
> latter, for -march=i586 -mtune=generic also cmpxchg8b insn.  Except for
> bswap, that's mainly for __sync_* builtins, OpenMP #pragma omp atomic, and
> other users of atomic insns.

AFAIK everyone's dumped i386 support already, for reasons I can't find a
good link for right now. (Something to do with the lack of atomic
instructions :) There's no reason to not move up to -march=i486.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/8d55a43e/attachment.sig>

From nathanael at gnat.ca  Wed Jan 28 21:42:05 2009
From: nathanael at gnat.ca (Nathanael D. Noblet)
Date: Wed, 28 Jan 2009 14:42:05 -0700
Subject: PackageKit application icons
In-Reply-To: <f6ca9fed0901281331q236ef272o67af3a0f6818c256@mail.gmail.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>	<4980C521.4030202@fedoraproject.org>	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>	<20090128211750.GA15085@nostromo.devel.redhat.com>	<4980CCBA.4080006@redhat.com>
	<f6ca9fed0901281331q236ef272o67af3a0f6818c256@mail.gmail.com>
Message-ID: <4980D12D.7090607@gnat.ca>

drago01 wrote:
> On Wed, Jan 28, 2009 at 10:23 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
>> On 2009-01-28 at 16:17:51 -0500, Bill Nottingham <notting at redhat.com> wrote:
>>> Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>>>> Ahhh... I see that now, and they're already there.
>>>>
>>>> It's a shame that's the only mechanism for adding icons. I'd like to see
>>>> something other than cardboard boxes when looking for devel packages.
>>> The problem is you'd either need to:
>>>
>>> - include icons in the metadata (which gets very large, very fast)
>>> - create a package that consists of all the icons that may be in
>>>   the distro (which gets very messy to maintain, very fast)
>>>
>>> Neither of these are particularly good solutions.
>> Well, we do have a PackageDB. Why couldn't we permit maintainers to go to:
>>
>> https://admin.fedoraproject.org/packagedb
>>
>> Then, on the page for the package (once logged in, of course), click on
>> the icon next to the package name (a question mark by default) and
>> upload an icon. Then, extend the PackageDB API such that PackageKit
>> tries to call out to PackageDB to get icons on a per package basis
>> (also, as a list of packages).
> 
> Doesn't sound like a good idea. Unless we have packageDB mirrors.
> 
Why not something more low tech. Upload via packageDB or something, 
which puts the icon on the mirrors so packagename-logo.X, pk checks if 
the mirror it received the package list has a icons/packagename-logo.X 
or whatever if it exists display it, otherwise don't.

-- 
Nathanael d. Noblet
Gnat Solutions, Inc
T: 403.875.4613



From a.badger at gmail.com  Wed Jan 28 21:41:41 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Wed, 28 Jan 2009 13:41:41 -0800
Subject: PackageKit application icons
In-Reply-To: <f6ca9fed0901281331q236ef272o67af3a0f6818c256@mail.gmail.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>	
	<4980C521.4030202@fedoraproject.org>	
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>	
	<20090128211750.GA15085@nostromo.devel.redhat.com>	
	<4980CCBA.4080006@redhat.com>
	<f6ca9fed0901281331q236ef272o67af3a0f6818c256@mail.gmail.com>
Message-ID: <4980D115.8050500@gmail.com>

drago01 wrote:
> On Wed, Jan 28, 2009 at 10:23 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
>> On 2009-01-28 at 16:17:51 -0500, Bill Nottingham <notting at redhat.com> wrote:
>>> Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>>>> Ahhh... I see that now, and they're already there.
>>>>
>>>> It's a shame that's the only mechanism for adding icons. I'd like to see
>>>> something other than cardboard boxes when looking for devel packages.
>>> The problem is you'd either need to:
>>>
>>> - include icons in the metadata (which gets very large, very fast)
>>> - create a package that consists of all the icons that may be in
>>>   the distro (which gets very messy to maintain, very fast)
>>>
>>> Neither of these are particularly good solutions.
>> Well, we do have a PackageDB. Why couldn't we permit maintainers to go to:
>>
>> https://admin.fedoraproject.org/packagedb
>>
>> Then, on the page for the package (once logged in, of course), click on
>> the icon next to the package name (a question mark by default) and
>> upload an icon. Then, extend the PackageDB API such that PackageKit
>> tries to call out to PackageDB to get icons on a per package basis
>> (also, as a list of packages).
> 
> Doesn't sound like a good idea. Unless we have packageDB mirrors.
> 
We could generate static metadata from information in the pkgdb instead
of having packagekit download the icon information directly for every
package.

This could fit in with the idea of generating tag metadata from the
pakckagedb.

Someone has to code this, though.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/9dbc192f/attachment.sig>

From jkeating at redhat.com  Wed Jan 28 21:44:27 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 13:44:27 -0800
Subject: PackageKit application icons
In-Reply-To: <36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
Message-ID: <1233179067.8363.239.camel@localhost.localdomain>

On Wed, 2009-01-28 at 14:24 -0700, Rick L. Vinyard, Jr. wrote:
> Bill Nottingham wrote:
> > Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
> >> Ahhh... I see that now, and they're already there.
> >>
> >> It's a shame that's the only mechanism for adding icons. I'd like to see
> >> something other than cardboard boxes when looking for devel packages.
> >
> > The problem is you'd either need to:
> >
> > - include icons in the metadata (which gets very large, very fast)
> > - create a package that consists of all the icons that may be in
> >   the distro (which gets very messy to maintain, very fast)
> >
> > Neither of these are particularly good solutions.
> >
> 
> I agree that neither of those are good solutions, but there is another
> option.
> 
> Currently, the icons reside in each package and the desktop entry file
> (also in the individual packages) is used to associate the package with
> the icon.
> 
> Why couldn't devel packages (and others without desktop entry files)
> follow a similar approach containing the icon and association?

I think the problem then is you don't see the icon for the package until
you've installed the package.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/5bb0c3b5/attachment.sig>

From sundaram at fedoraproject.org  Wed Jan 28 21:56:12 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 03:26:12 +0530
Subject: New package from one source
In-Reply-To: <glqiee$89u$1@ger.gmane.org>
References: <gl2t8r$rm$1@ger.gmane.org>	<20090119221149.GA10949@nostromo.devel.redhat.com>	<gl40q6$pob$1@ger.gmane.org>	<20090120184236.GA10482@nostromo.devel.redhat.com>	<gldh77$3sc$1@ger.gmane.org>	<497A53CD.1050605@fedoraproject.org>
	<glqiee$89u$1@ger.gmane.org>
Message-ID: <4980D47C.1040602@fedoraproject.org>

Pavel Alexeev (aka Pahan-Hubbitus) wrote:

> As I mention above, what about your first link - main apache rpm package 
> fully ignore this guidelines!

These are more best practises and aren't part oaf the packaging 
guidelines except as a reference but maintainers have to ultimately make 
their own decisions. If you find major deviations from upstream, it is 
useful to talk to the maintainers and understand why.
> 
> But why you are not consider Steinar H. Gunderson as upstream amintainer 
> of apache mpm-itk???

This is a patchset for upstream.

> In any case, as maintainer of package I take care about maintenance load 
> by this rpm. As I remember, it had not any urgent issues with adaptation 
> to current releases of apache for the past year or even more.
> 
> P.S. I'm write mail to Steinar H. Gunderson with question why it is not 
> in upstream...

Yes, that is the key question to get an answer for.

Rahul



From kevin.kofler at chello.at  Wed Jan 28 22:07:47 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:07:47 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org> <498011FB.6060809@freenet.de>
	<1233139028.3174.46.camel@hughsie-work.lan>
Message-ID: <glqkvj$fg9$1@ger.gmane.org>

Richard Hughes wrote:
> This IS useful:
> https://admin.fedoraproject.org/updates/hwdata-0.222-1.fc10
> 
> This IS NOT useful:
> https://admin.fedoraproject.org/updates/gromacs-4.0.3-2.fc10

Those are indeed good examples.

        Kevin Kofler



From cweyl at alumni.drew.edu  Wed Jan 28 22:09:34 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 14:09:34 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128152342.GC3119@mokona.greysector.net>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
Message-ID: <7dd7ab490901281409i50ca3a0dp457d052a72ccbac0@mail.gmail.com>

On Wed, Jan 28, 2009 at 7:23 AM, Dominik 'Rathann' Mierzejewski
<dominik at greysector.net> wrote:
> On Tuesday, 27 January 2009 at 19:18, Rahul Sundaram wrote:
>> Please be specific in your comments and try and be constructive. Thank you.
>
> Nobody reads these anyway, so what's the point? Yum's changelog plugin is
> much more useful than this proposal will ever be.

Hear, hear.

                              -Chris
-- 
Chris Weyl
Ex astris, scientia



From kevin.kofler at chello.at  Wed Jan 28 22:09:38 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:09:38 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>
Message-ID: <glql32$fg9$2@ger.gmane.org>

Mark McLoughlin wrote:
> I'd suggest the tone should be less prescriptive - i.e. not so much "you
> must do foo" - and also give some rationale.

That's funny, I found it not prescriptive enough. ;-)

        Kevin Kofler



From hughsient at gmail.com  Wed Jan 28 22:10:49 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 28 Jan 2009 22:10:49 +0000
Subject: PackageKit application icons
In-Reply-To: <1233179067.8363.239.camel@localhost.localdomain>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
Message-ID: <15e53e180901281410l4be9ebb7r278a42cf3275fd9d@mail.gmail.com>

On 1/28/09, Jesse Keating <jkeating at redhat.com> wrote:
> I think the problem then is you don't see the icon for the package until
> you've installed the package.

Correct.

Richard.



From cweyl at alumni.drew.edu  Wed Jan 28 22:11:32 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 14:11:32 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <498078A9.1080808@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
	<497F724A.7000006@poolshark.org> <497F7A6A.8070800@fedoraproject.org>
	<20090128123627.GC808@yoda.jdub.homelinux.org>
	<498052D3.3060208@fedoraproject.org> <49805776.7020402@sapience.com>
	<49805BA7.8060606@fedoraproject.org> <498063F3.9080506@freenet.de>
	<498078A9.1080808@fedoraproject.org>
Message-ID: <7dd7ab490901281411t7fa68ea9y241884b091daf9b2@mail.gmail.com>

On Wed, Jan 28, 2009 at 7:24 AM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Ralf Corsepius wrote:
>
>> Yes, it's evident: You are presuming your proposal to be useful and do not
>> want to listen to anybody not sharing your view.
>
> I have considered all the feedback given. Yours didn't convey much
> information beyond the fact that you didn't like it which I am already aware
> from earlier discussions as well.

Actually, Ralf conveyed a good bit of information AND that he doesn't like it.

                               -Chris
-- 
Chris Weyl
Ex astris, scientia



From rvinyard at cs.nmsu.edu  Wed Jan 28 22:11:44 2009
From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.)
Date: Wed, 28 Jan 2009 15:11:44 -0700 (MST)
Subject: PackageKit application icons
In-Reply-To: <1233179067.8363.239.camel@localhost.localdomain>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
Message-ID: <52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>

Jesse Keating wrote:
> On Wed, 2009-01-28 at 14:24 -0700, Rick L. Vinyard, Jr. wrote:
>> Bill Nottingham wrote:
>> > Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>> >> Ahhh... I see that now, and they're already there.
>> >>
>> >> It's a shame that's the only mechanism for adding icons. I'd like to
>> see
>> >> something other than cardboard boxes when looking for devel packages.
>> >
>> > The problem is you'd either need to:
>> >
>> > - include icons in the metadata (which gets very large, very fast)
>> > - create a package that consists of all the icons that may be in
>> >   the distro (which gets very messy to maintain, very fast)
>> >
>> > Neither of these are particularly good solutions.
>> >
>>
>> I agree that neither of those are good solutions, but there is another
>> option.
>>
>> Currently, the icons reside in each package and the desktop entry file
>> (also in the individual packages) is used to associate the package with
>> the icon.
>>
>> Why couldn't devel packages (and others without desktop entry files)
>> follow a similar approach containing the icon and association?
>
> I think the problem then is you don't see the icon for the package until
> you've installed the package.

But, aren't they currently harvesting them from the packages and desktop
entries?

Or, does pkg-application only show the icons for the packages I currently
have installed?



From jkeating at redhat.com  Wed Jan 28 22:11:50 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:11:50 -0800
Subject: New package from one source
In-Reply-To: <4980D47C.1040602@fedoraproject.org>
References: <gl2t8r$rm$1@ger.gmane.org>
	<20090119221149.GA10949@nostromo.devel.redhat.com>
	<gl40q6$pob$1@ger.gmane.org>
	<20090120184236.GA10482@nostromo.devel.redhat.com>
	<gldh77$3sc$1@ger.gmane.org>	<497A53CD.1050605@fedoraproject.org>
	<glqiee$89u$1@ger.gmane.org>  <4980D47C.1040602@fedoraproject.org>
Message-ID: <1233180710.8363.242.camel@localhost.localdomain>

On Thu, 2009-01-29 at 03:26 +0530, Rahul Sundaram wrote:
>  > As I mention above, what about your first link - main apache rpm package 
> > fully ignore this guidelines!
> 
> These are more best practises and aren't part oaf the packaging 
> guidelines except as a reference but maintainers have to ultimately make 
> their own decisions. If you find major deviations from upstream, it is 
> useful to talk to the maintainers and understand why.

Also, the statements about comments on patches was created long after
the apache package and most if not all of the patches therein.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/4c42bce8/attachment.sig>

From kevin.kofler at chello.at  Wed Jan 28 22:15:20 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:15:20 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<20090128190426.0a2f661d.mschwendt@gmail.com>
Message-ID: <glqldp$fg9$3@ger.gmane.org>

Michael Schwendt wrote:
> Bodhi itself, however, floods those bugzilla tickets with
> comments. The most confusing comment is the one that notifies about
> "submitted" (= pending) updates, which are only available within
> koji. If we talk about "real users", this is the first comment
> that ought to be killed, since users are confused a lot by
> updates, which are not available.

I disagree. It claims nowhere that those updates have been pushed, and for
me it is good to know that a fix has been queued. Maybe the wording could
be changed to be clearer to the new users? I.e. instead of just:
foo-1.2.3-1.fc10 has been submitted as an update for Fedora 10.
it could say something on the lines of:
foo-1.2.3-1.fc10 has been submitted as an update for Fedora 10 and will be
available for testing shortly. A followup will be posted once the update is
available on the mirrors. Note that it may take up to a few days for
updates to become available.

        Kevin Kofler



From hughsient at gmail.com  Wed Jan 28 22:18:25 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Wed, 28 Jan 2009 22:18:25 +0000
Subject: PackageKit application icons
In-Reply-To: <52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
	<52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>
Message-ID: <15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>

On 1/28/09, Rick L. Vinyard, Jr. <rvinyard at cs.nmsu.edu> wrote:
> Jesse Keating wrote:
>> On Wed, 2009-01-28 at 14:24 -0700, Rick L. Vinyard, Jr. wrote:
>>> Bill Nottingham wrote:
>>> > Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>>> >> Ahhh... I see that now, and they're already there.
>>> >>
>>> >> It's a shame that's the only mechanism for adding icons. I'd like to
>>> see
>>> >> something other than cardboard boxes when looking for devel packages.
>>> >
>>> > The problem is you'd either need to:
>>> >
>>> > - include icons in the metadata (which gets very large, very fast)
>>> > - create a package that consists of all the icons that may be in
>>> >   the distro (which gets very messy to maintain, very fast)
>>> >
>>> > Neither of these are particularly good solutions.
>>> >
>>>
>>> I agree that neither of those are good solutions, but there is another
>>> option.
>>>
>>> Currently, the icons reside in each package and the desktop entry file
>>> (also in the individual packages) is used to associate the package with
>>> the icon.
>>>
>>> Why couldn't devel packages (and others without desktop entry files)
>>> follow a similar approach containing the icon and association?
>>
>> I think the problem then is you don't see the icon for the package until
>> you've installed the package.
>
> But, aren't they currently harvesting them from the packages and desktop
> entries?

Yes, as soon as you install the package, PackageKit parses the desktop
file and adds the icon file to a local database.

> Or, does pkg-application only show the icons for the packages I currently
> have installed?

Yup. The only way this could work for not-installed files would be for
the application icons to be put on the mirrors, and for PackageKit to
generate a per-user cache of icons in the session.

Richard.



From robert at fedoraproject.org  Wed Jan 28 22:19:57 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Wed, 28 Jan 2009 23:19:57 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1232385498.10018.3.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
Message-ID: <20090128221957.GA14226@hurricane.linuxnetz.de>

On Mon, 19 Jan 2009, Brian Pepple wrote:
> Review Requests: 66
> Merge Reviews: 10
> Total reviews modified: 76

Wow, so much reviews happened in one week. Unfortunately so much quantity,
but much lesser quality. Do we really need quantity high scores rather the
quality ones?


Greetings,
  Robert



From kevin.kofler at chello.at  Wed Jan 28 22:20:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:20:36 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
Message-ID: <glqlnk$fg9$4@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:
>> * If there are downstream bugs being fixed or intended to be fixed with
>> an update, it must be referred within the update. Maintainers can choose
>> to let bodhi auto close bugs or close it manually as well.
> 
> This is redundant. bodhi has a field for bug numbers and it's pretty
> self-explanatory.
> 
>> * For security update, add CVE information, if one exists.
> 
> As above.

Yet some maintainers fail to fill in that information (and this is also the
claimed reason security updates need approval from the security team). So
it can't hurt to spell this out.

        Kevin Kofler



From jkeating at redhat.com  Wed Jan 28 22:19:56 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:19:56 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <glqldp$fg9$3@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<20090128190426.0a2f661d.mschwendt@gmail.com>
	<glqldp$fg9$3@ger.gmane.org>
Message-ID: <1233181196.8363.244.camel@localhost.localdomain>

On Wed, 2009-01-28 at 23:15 +0100, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > Bodhi itself, however, floods those bugzilla tickets with
> > comments. The most confusing comment is the one that notifies about
> > "submitted" (= pending) updates, which are only available within
> > koji. If we talk about "real users", this is the first comment
> > that ought to be killed, since users are confused a lot by
> > updates, which are not available.
> 
> I disagree. It claims nowhere that those updates have been pushed, and for
> me it is good to know that a fix has been queued. Maybe the wording could
> be changed to be clearer to the new users? I.e. instead of just:
> foo-1.2.3-1.fc10 has been submitted as an update for Fedora 10.
> it could say something on the lines of:
> foo-1.2.3-1.fc10 has been submitted as an update for Fedora 10 and will be
> available for testing shortly. A followup will be posted once the update is
> available on the mirrors. Note that it may take up to a few days for
> updates to become available.
> 
>         Kevin Kofler

That seems reasonable, can you file a bodhi ticket with that?  Luke
could probably get that in the next bodhi refresh.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/22d86772/attachment.sig>

From jkeating at redhat.com  Wed Jan 28 22:20:21 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:20:21 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <7dd7ab490901281409i50ca3a0dp457d052a72ccbac0@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<7dd7ab490901281409i50ca3a0dp457d052a72ccbac0@mail.gmail.com>
Message-ID: <1233181221.8363.245.camel@localhost.localdomain>

On Wed, 2009-01-28 at 14:09 -0800, Chris Weyl wrote:
> On Wed, Jan 28, 2009 at 7:23 AM, Dominik 'Rathann' Mierzejewski
> <dominik at greysector.net> wrote:
> > On Tuesday, 27 January 2009 at 19:18, Rahul Sundaram wrote:
> >> Please be specific in your comments and try and be constructive. Thank you.
> >
> > Nobody reads these anyway, so what's the point? Yum's changelog plugin is
> > much more useful than this proposal will ever be.
> 
> Hear, hear.
> 
>                               -Chris
> -- 
> Chris Weyl
> Ex astris, scientia

I'd like some evidence to backup the claim that nobody reads them.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/e354f51c/attachment.sig>

From jkeating at redhat.com  Wed Jan 28 22:21:27 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:21:27 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090128221957.GA14226@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
Message-ID: <1233181287.8363.246.camel@localhost.localdomain>

On Wed, 2009-01-28 at 23:19 +0100, Robert Scheck wrote:
> On Mon, 19 Jan 2009, Brian Pepple wrote:
> > Review Requests: 66
> > Merge Reviews: 10
> > Total reviews modified: 76
> 
> Wow, so much reviews happened in one week. Unfortunately so much quantity,
> but much lesser quality. Do we really need quantity high scores rather the
> quality ones?
> 
> 
> Greetings,
>   Robert

Are there specific issues of the quality of these reviews you'd like to
point out and share with the rest of us?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/bda6afde/attachment.sig>

From stickster at gmail.com  Wed Jan 28 22:24:04 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Wed, 28 Jan 2009 17:24:04 -0500
Subject: what requires fedora-release-notes
In-Reply-To: <1233169541.8363.234.camel@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<49809DC1.50805@redhat.com>
	<1233165786.8363.228.camel@localhost.localdomain>
	<20090128185015.GE11811@localhost.localdomain>
	<1233169541.8363.234.camel@localhost.localdomain>
Message-ID: <20090128222404.GD5735@localhost.localdomain>

On Wed, Jan 28, 2009 at 11:05:41AM -0800, Jesse Keating wrote:
> On Wed, 2009-01-28 at 13:50 -0500, Paul W. Frields wrote:
> > On Wed, Jan 28, 2009 at 10:03:06AM -0800, Jesse Keating wrote:
> > > On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
> > > >  
> > > > Jesse, is there any important data in this package which needs to be 
> > > > shipped in Fedora at any cost?
> > > > I can imagine some legal or licensing information about Fedora.
> > > 
> > > I don't believe so.
> > 
> > The arguable value of the "About Fedora" item -- which as some Desktop
> > team members have noted, probably needs to be revamped -- is certainly
> > not enough to keep it.  It would be prudent and probably good manners
> > to alert the Docs team about contemplating dropping this, too.
> 
> Well, we would make it a default install item via groupings, but perhaps
> not /forced/ install, so that one could remove it/opt out of installing
> it should they wish.

Thanks for clarifying this.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/b78e5822/attachment.sig>

From jspaleta at gmail.com  Wed Jan 28 22:27:30 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Jan 2009 13:27:30 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <1233181221.8363.245.camel@localhost.localdomain>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<7dd7ab490901281409i50ca3a0dp457d052a72ccbac0@mail.gmail.com>
	<1233181221.8363.245.camel@localhost.localdomain>
Message-ID: <604aa7910901281427u309f6eew91a1cc7c20bbefc4@mail.gmail.com>

2009/1/28 Jesse Keating <jkeating at redhat.com>:
> I'd like some evidence to backup the claim that nobody reads them.

Can you remind me again where these notifications are housed?
Are they part of the repometa on individual mirrors? Separate from
other repodata?

-jef



From jkeating at redhat.com  Wed Jan 28 22:27:18 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:27:18 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <604aa7910901281427u309f6eew91a1cc7c20bbefc4@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<7dd7ab490901281409i50ca3a0dp457d052a72ccbac0@mail.gmail.com>
	<1233181221.8363.245.camel@localhost.localdomain>
	<604aa7910901281427u309f6eew91a1cc7c20bbefc4@mail.gmail.com>
Message-ID: <1233181638.8363.247.camel@localhost.localdomain>

On Wed, 2009-01-28 at 13:27 -0900, Jeff Spaleta wrote:
>  Can you remind me again where these notifications are housed?
> Are they part of the repometa on individual mirrors? Separate from
> other repodata?

They go in updateinfo.xml which is bundled along with the rest of the
yum repodata and is mirrored along with the packages.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/47f11242/attachment.sig>

From tcallawa at redhat.com  Wed Jan 28 22:28:44 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Wed, 28 Jan 2009 17:28:44 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <497599B2.6030203@gmx.net>
References: <497599B2.6030203@gmx.net>
Message-ID: <4980DC1C.8000505@redhat.com>

On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet at gmx.net> wrote:
> Hi,
> 
> are there any plans for updating texlive to 2008 in Leonidas?

I'd have to say the chances of this are extremely unlikely. I'm much
more inclined to propose that we drop texlive altogether. It is a
licensing nightmare, a tangled bundle of millions of files with little
apparent organizational structure, and no overarching licensing
analysis. I started trying to do a license audit on texlive 2008, but it
would probably take me at least a month of doing nothing except auditing
texlive to finish it.

To be fair, the existing texlive has the same problems, I just was
unaware of the scope of things until recently.

~spot



From mw_triad at users.sourceforge.net  Wed Jan 28 22:31:10 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 28 Jan 2009 16:31:10 -0600
Subject: Draft: simple update description guidelines
In-Reply-To: <1233144888.13111.1.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>
	<49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
Message-ID: <glqmbe$k1g$1@ger.gmane.org>

Mark McLoughlin wrote:
> Okay, here's an attempt:
> 
>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 
> Cheers,
> Mark.
> 
> = Package Update Guidelines =
> 
> This page is intended to give some guidelines relevant to package
> maintainers who wish to update a package on a release branch.
> 
> These are not intended to be prescriptive rules. Package maintainers are
> free to exercise their own common sense and good judgement.

s/are free to/should/ ;-)
(...or 'are expected to')

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's impossible! But... do-able."
   -- Robert MacDougal (Sean Connery, Entrapment)



From oget.fedora at gmail.com  Wed Jan 28 22:24:35 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Wed, 28 Jan 2009 17:24:35 -0500
Subject: Draft: simple update description guidelines
In-Reply-To: <497F5005.4060107@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <e76492710901281424o763de02g773f2ad97bc036d5@mail.gmail.com>

This would be my suggestion. It is not only less strict but also
informative. I didn't know what the description field in the Bodhi
interface does until 2 months after I started packaging stuff, because
I don't use PackageKit very often. I don't think the wiki explains
what that field is for. Correct me if I'm wrong.

s@
> * All Updates must refer to a upstream changelog or equivalent if one
> exists. Otherwise a brief description (a couple of sentence at most)
> justifying the need for an update must be provided by the maintainers
> pushing the update.
@
* The description field in the bodhi interface is what the users will see on
the PackageKit GUI regarding the significance of the update. This is not
the same thing as the SPEC file changelog. It would be nice to include the
release highlights in this field together with a URL to the upstream changelog,
if there is any.
@

Cheers,
Orcan



From sundaram at fedoraproject.org  Wed Jan 28 22:31:48 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:01:48 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090128221957.GA14226@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
Message-ID: <4980DCD4.3080301@fedoraproject.org>

Robert Scheck wrote:
> On Mon, 19 Jan 2009, Brian Pepple wrote:
>> Review Requests: 66
>> Merge Reviews: 10
>> Total reviews modified: 76
> 
> Wow, so much reviews happened in one week. Unfortunately so much quantity,
> but much lesser quality. Do we really need quantity high scores rather the
> quality ones?

Quantity is a simple number. How are you measuring quality?

Rahul




From sundaram at fedoraproject.org  Wed Jan 28 22:35:44 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:05:44 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <glqmbe$k1g$1@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>
	<glqmbe$k1g$1@ger.gmane.org>
Message-ID: <4980DDC0.9000902@fedoraproject.org>

Matthew Woehlke wrote:
> Mark McLoughlin wrote:
>> Okay, here's an attempt:
>>
>>   
>> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines 
>>
>>
>> Cheers,
>> Mark.
>>
>> = Package Update Guidelines =
>>
>> This page is intended to give some guidelines relevant to package
>> maintainers who wish to update a package on a release branch.
>>
>> These are not intended to be prescriptive rules. Package maintainers are
>> free to exercise their own common sense and good judgement.
> 
> s/are free to/should/ ;-)
> (...or 'are expected to')

For such minor corrections, please feel free to edit the wiki directly.

Rahul



From kevin.kofler at chello.at  Wed Jan 28 22:37:30 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:37:30 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org>
Message-ID: <glqmnb$mo6$1@ger.gmane.org>

Rahul Sundaram wrote:
> The following are a set of simple guidelines for the update descriptions
> via bodhi (which is used by PackageKit to inform users of what has
> changed). These guidelines are intended to help end users understand the
> nature of changes in the update better. Bodhi is not used in rawhide, so
> these guidelines are not applicable for rawhide updates. Note that this
> is not connected to the rpm changelog.

These look good, I agree with the need for guidelines here.

> * All Updates must refer to a upstream changelog or equivalent if one
> exists. Otherwise a brief description (a couple of sentence at most)
> justifying the need for an update must be provided by the maintainers
> pushing the update.

I think this should not be "Otherwise". There should normally be BOTH,
unless the reason for the update push is clear to everyone reading the
upstream changelog. And if there's no upstream changelog, the package
maintainer should try to summarize the changes.

I'd suggest something like this:
* All updates MUST contain a rationale justifying the need for an update.
They SHOULD contain a summary of the changes in the new version or a link
to such a summary. Where upstream provides such a summary, it MUST be
linked to or quoted (linking is preferred unless it is short). The summary
SHOULD be in a format comprehensible at least by an advanced user, not a
file-level or even function-level changelog as found in some projects. In
some cases, the summary of the changes also doubles as a rationale (e.g.
for a security fix or some other critical bugfix). In all other cases, both
are expected.

Notice the use of all-caps "MUST" to make it clear it is mandatory. We've
been tolerating updates with blank or useless details for way too long.

> * If there are downstream bugs being fixed or intended to be fixed with
> an update, it must be referred within the update. Maintainers can choose
> to let bodhi auto close bugs or close it manually as well.
> 
> * For security update, add CVE information, if one exists.

+1 (to both).

> * It is highly recommended that package maaintainers highlight major new
> features, critical bug fixes or anything else that has a potential high
> impact on consumers of your update.

+1, should be obvious, but unfortunately it isn't to everyone.

        Kevin Kofler



From christoph.wickert at googlemail.com  Wed Jan 28 22:35:04 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Wed, 28 Jan 2009 23:35:04 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233181287.8363.246.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
Message-ID: <1233182104.3786.19.camel@wicktop.localdomain>

Am Mittwoch, den 28.01.2009, 14:21 -0800 schrieb Jesse Keating:
> On Wed, 2009-01-28 at 23:19 +0100, Robert Scheck wrote:
> > On Mon, 19 Jan 2009, Brian Pepple wrote:
> > > Review Requests: 66
> > > Merge Reviews: 10
> > > Total reviews modified: 76
> > 
> > Wow, so much reviews happened in one week. Unfortunately so much quantity,
> > but much lesser quality. Do we really need quantity high scores rather the
> > quality ones?
> > 
> > 
> > Greetings,
> >   Robert
> 
> Are there specific issues of the quality of these reviews you'd like to
> point out and share with the rest of us?

Some examples:
      * Recently I updated some of the Xfce 4.6 packages. One of them
        was approved without _any_ docs.
      * A package was approved with more then 19 missing deps on
        binaries.
      * A font package was approved although it contained another font

I'm not giving the bz # now because I don't want to point fingers. If
you are interested, contact me off-list.

Regards,
Christoph




From mw_triad at users.sourceforge.net  Wed Jan 28 22:42:42 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 28 Jan 2009 16:42:42 -0600
Subject: Draft: simple update description guidelines
In-Reply-To: <4980DDC0.9000902@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>	<glqmbe$k1g$1@ger.gmane.org>
	<4980DDC0.9000902@fedoraproject.org>
Message-ID: <glqn12$k1g$2@ger.gmane.org>

Rahul Sundaram wrote:
> Matthew Woehlke wrote:
>> s/are free to/should/ ;-)
>> (...or 'are expected to')
> 
> For such minor corrections, please feel free to edit the wiki directly.

It was meant as a suggestion :-). Besides, I can't edit the wiki.

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's impossible! But... do-able."
   -- Robert MacDougal (Sean Connery, Entrapment)



From sundaram at fedoraproject.org  Wed Jan 28 22:43:03 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:13:03 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <e76492710901281424o763de02g773f2ad97bc036d5@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<e76492710901281424o763de02g773f2ad97bc036d5@mail.gmail.com>
Message-ID: <4980DF77.7010601@fedoraproject.org>

Orcan Ogetbil wrote:
> This would be my suggestion. It is not only less strict but also
> informative. I didn't know what the description field in the Bodhi
> interface does until 2 months after I started packaging stuff, because
> I don't use PackageKit very often. I don't think the wiki explains
> what that field is for. Correct me if I'm wrong.

Correct. This is among the things, I am trying to address with this 
proposal.

> * The description field in the bodhi interface is what the users will see on
> the PackageKit GUI regarding the significance of the update. This is not
> the same thing as the SPEC file changelog. It would be nice to include the
> release highlights in this field together with a URL to the upstream changelog,
> if there is any.

Merged into

https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

Thank you for your useful feedback.

Rahul



From kevin.kofler at chello.at  Wed Jan 28 22:43:51 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:43:51 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<20090128190426.0a2f661d.mschwendt@gmail.com>
	<glqldp$fg9$3@ger.gmane.org>
	<1233181196.8363.244.camel@localhost.localdomain>
Message-ID: <glqn37$mo6$2@ger.gmane.org>

Jesse Keating wrote:
> That seems reasonable, can you file a bodhi ticket with that?  Luke
> could probably get that in the next bodhi refresh.

Done:
https://fedorahosted.org/bodhi/ticket/293

        Kevin Kofler



From sundaram at fedoraproject.org  Wed Jan 28 22:49:27 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:19:27 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <glqmnb$mo6$1@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
Message-ID: <4980E0F7.6020507@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> The following are a set of simple guidelines for the update descriptions
>> via bodhi (which is used by PackageKit to inform users of what has
>> changed). These guidelines are intended to help end users understand the
>> nature of changes in the update better. Bodhi is not used in rawhide, so
>> these guidelines are not applicable for rawhide updates. Note that this
>> is not connected to the rpm changelog.
> 
> These look good, I agree with the need for guidelines here.

The general consensus seem to push for more of a best practises 
document. So I am going with

https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

It appears, most maintainers only have been ignoring the description 
fields or not filling them properly because of lack of documentation or 
awareness on how it is being used. I am hoping just merging this 
information in the wiki and adding appropriate references would be 
enough to solve that problem. If not, we will deal with that, later.

Rahul




From jkeating at redhat.com  Wed Jan 28 22:48:52 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 14:48:52 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233182104.3786.19.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
Message-ID: <1233182932.8363.252.camel@localhost.localdomain>

On Wed, 2009-01-28 at 23:35 +0100, Christoph Wickert wrote:
>  Some examples:
>       * Recently I updated some of the Xfce 4.6 packages. One of them
>         was approved without _any_ docs.
>       * A package was approved with more then 19 missing deps on
>         binaries.
>       * A font package was approved although it contained another font
> 
> I'm not giving the bz # now because I don't want to point fingers. If
> you are interested, contact me off-list.

I am interested, as it means we have reviewers who need to be re-taught
how to review.  Their sponsors should be made aware of this too.  We
shouldn't be afraid to call out questionable behavior, this is open
source after all, and peer review is key.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/2bff8845/attachment.sig>

From sundaram at fedoraproject.org  Wed Jan 28 22:52:02 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:22:02 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <glqn12$k1g$2@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>	<glqmbe$k1g$1@ger.gmane.org>	<4980DDC0.9000902@fedoraproject.org>
	<glqn12$k1g$2@ger.gmane.org>
Message-ID: <4980E192.6080709@fedoraproject.org>

Matthew Woehlke wrote:
> Rahul Sundaram wrote:
>> Matthew Woehlke wrote:
>>> s/are free to/should/ ;-)
>>> (...or 'are expected to')
>>
>> For such minor corrections, please feel free to edit the wiki directly.
> 
> It was meant as a suggestion :-). Besides, I can't edit the wiki.

Ok, fixed. Getting a account is just a click through process now, btw.

http://admin.fedoraproject.org/accounts

Rahul




From kevin.kofler at chello.at  Wed Jan 28 22:54:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 28 Jan 2009 23:54:10 +0100
Subject: alsa x 2.6.27.12-170.2.5.fc10
References: <68720af30901280615l5c50c20fu87db7e17bbb2a8fa@mail.gmail.com>
Message-ID: <glqnmi$mo6$3@ger.gmane.org>

Paulo Cavalcanti wrote:
> I really do not understand why not going straight to 1.0.19
> instead of patching 1.0.17 again. I agree alsa-1.0.18
> had a lot of problems, but the fixes are in alsa 1.0.19.

I also think reverting is usually a bad solution, move forward, not
backwards. The reversion probably reintroduced some bugs that 1.0.18 had
fixed and regressed hardware support. That said, I don't know the specifics
of this case: are we sure 1.0.19 fixes the regressions?

        Kevin Kofler



From kevin.kofler at chello.at  Wed Jan 28 23:00:03 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 00:00:03 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org>
Message-ID: <glqo1j$mo6$4@ger.gmane.org>

Rahul Sundaram wrote:
> It appears, most maintainers only have been ignoring the description
> fields or not filling them properly because of lack of documentation or
> awareness on how it is being used.

Some of the replies in these threads don't quite suggest that. People
complain about the "bureaucracy" of being "forced" to write such stuff,
which pretty much shows they intentionally do not want to fill in those
fields and won't do it if they can get away without it.

        Kevin Kofler



From sundaram at fedoraproject.org  Wed Jan 28 23:05:15 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 04:35:15 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <glqo1j$mo6$4@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>
	<glqmnb$mo6$1@ger.gmane.org>	<4980E0F7.6020507@fedoraproject.org>
	<glqo1j$mo6$4@ger.gmane.org>
Message-ID: <4980E4AB.5070105@fedoraproject.org>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> It appears, most maintainers only have been ignoring the description
>> fields or not filling them properly because of lack of documentation or
>> awareness on how it is being used.
> 
> Some of the replies in these threads don't quite suggest that. People
> complain about the "bureaucracy" of being "forced" to write such stuff,
> which pretty much shows they intentionally do not want to fill in those
> fields and won't do it if they can get away without it.

Maybe but I am optimistic that most maintainers would want to do a good 
job and are going to be considerate of the needs of users. My primary 
goal is to help new maintainers rather than force a few opposing ones.

Rahul



From robert at fedoraproject.org  Wed Jan 28 23:13:33 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 00:13:33 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <4980E0F7.6020507@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org>
Message-ID: <20090128231333.GA19894@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Rahul Sundaram wrote:
> The general consensus seem to push for more of a best practises  
> document. So I am going with
>
> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

Once more: Why do we not explicitly ask the Bodhi submitter for details
using much more fields? Having more possibilities to fill data in makes it
easier to new packagers - they're remembered. Why do you want to solve a
thing with a Guideline rather enhancing Bodhi and making that software just
packager friendly?


Greetings,
  Robert



From jspaleta at gmail.com  Wed Jan 28 23:14:50 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Jan 2009 14:14:50 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <4980E4AB.5070105@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<4980E4AB.5070105@fedoraproject.org>
Message-ID: <604aa7910901281514j2570a37rb0568b8221214bae@mail.gmail.com>

On Wed, Jan 28, 2009 at 2:05 PM, Rahul Sundaram
<sundaram at fedoraproject.org> wrote:
> Maybe but I am optimistic that most maintainers would want to do a good job
> and are going to be considerate of the needs of users. My primary goal is to
> help new maintainers rather than force a few opposing ones.

Are we confident that the bulk of the updates without information are
being produced by maintainers from your target audience?

All I know for sure is that some updates dont have enough information.
Is this primarily a problem for newer maintainers? I don't know.  Then
your goal to focus on new maintainers might not significantly impact
the problem.

I simply don't know enough about how widespread this is, and the
demographics of the maintainers responsible.

-jef



From mw_triad at users.sourceforge.net  Wed Jan 28 23:30:47 2009
From: mw_triad at users.sourceforge.net (Matthew Woehlke)
Date: Wed, 28 Jan 2009 17:30:47 -0600
Subject: Draft: simple update description guidelines
In-Reply-To: <4980E192.6080709@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>	<glqmbe$k1g$1@ger.gmane.org>	<4980DDC0.9000902@fedoraproject.org>	<glqn12$k1g$2@ger.gmane.org>
	<4980E192.6080709@fedoraproject.org>
Message-ID: <glqpr8$o0$1@ger.gmane.org>

Rahul Sundaram wrote:
> Matthew Woehlke wrote:
>> Rahul Sundaram wrote:
>>> Matthew Woehlke wrote:
>>>> s/are free to/should/ ;-)
>>>> (...or 'are expected to')
>>>
>>> For such minor corrections, please feel free to edit the wiki directly.
>>
>> It was meant as a suggestion :-). Besides, I can't edit the wiki.
> 
> Ok, fixed. Getting a account is just a click through process now, btw.
> 
> http://admin.fedoraproject.org/accounts

If it still involves the CLA (which it did last I remember checking)... 
then I still can't edit the wiki.

(If not, I need to reset my password one of these days :-).)

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"It's impossible! But... do-able."
   -- Robert MacDougal (Sean Connery, Entrapment)



From christoph.wickert at googlemail.com  Wed Jan 28 23:40:43 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 00:40:43 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233182932.8363.252.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
Message-ID: <1233186043.3786.40.camel@wicktop.localdomain>

Am Mittwoch, den 28.01.2009, 14:48 -0800 schrieb Jesse Keating:
> On Wed, 2009-01-28 at 23:35 +0100, Christoph Wickert wrote:
> >  Some examples:
> >       * Recently I updated some of the Xfce 4.6 packages. One of them
> >         was approved without _any_ docs.

https://bugzilla.redhat.com/show_bug.cgi?id=477732
also all the desktop files were installed and listed in %files twice and
if the reviewer had tested the package he would have noticed that. Site
note: The reviewer has been made a sponsor 2 weeks later.

> >       * A package was approved with more then 19 missing deps on
> >         binaries.

https://bugzilla.redhat.com/show_bug.cgi?id=459535

> >       * A font package was approved although it contained another font

https://bugzilla.redhat.com/show_bug.cgi?id=481501 

> > I'm not giving the bz # now because I don't want to point fingers. If
> > you are interested, contact me off-list.
> 
> I am interested, as it means we have reviewers who need to be re-taught
> how to review.  Their sponsors should be made aware of this too.

Do RH employes have sponsors too? A lot of the bad reviews are done by
RH people and a lot of bad specs come from RH folks. Somebody pointed me
to:
https://bugzilla.redhat.com/show_bug.cgi?id=433678
and I had a quick glance over it before Andreas added his comments:
      * no list of tests that have been run
      * SourceURL is missing
      * I can't even find the source because URL is wrong
      * without the source you cannot check the License tag, md5, etc
      * docs not marked %doc 
      * ... (I'm sure Andreas will spot some more issures)

>   We
> shouldn't be afraid to call out questionable behavior, this is open
> source after all, and peer review is key.

Ok, here you are.

Regards,
Christoph



From robert at fedoraproject.org  Wed Jan 28 23:45:45 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 00:45:45 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233186043.3786.40.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
Message-ID: <20090128234545.GA23208@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Christoph Wickert wrote:
> >   We
> > shouldn't be afraid to call out questionable behavior, this is open
> > source after all, and peer review is key.
> 
> Ok, here you are.

https://bugzilla.redhat.com/show_bug.cgi?id=469972 is not brilliant, too.
Other points of Christoph say most or even all, I think.


Greetings,
  Robert



From kevin.kofler at chello.at  Wed Jan 28 23:51:58 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 00:51:58 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
Message-ID: <glqr30$4l0$1@ger.gmane.org>

Tom "spot" Callaway wrote:
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether.

No TeX? That would make Fedora pretty much useless for Mathematics and
anything related!

If concrete licensing issues are found by somebody, of course those need to
be addressed, but dropping all of TeX on the ground that it's too hard to
audit is a horribly bad idea.

        Kevin Kofler



From bpepple at fedoraproject.org  Thu Jan 29 00:08:28 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 28 Jan 2009 19:08:28 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233186043.3786.40.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
Message-ID: <1233187708.6562.1.camel@localhost.localdomain>

On Thu, 2009-01-29 at 00:40 +0100, Christoph Wickert wrote:
> Am Mittwoch, den 28.01.2009, 14:48 -0800 schrieb Jesse Keating:
> > On Wed, 2009-01-28 at 23:35 +0100, Christoph Wickert wrote:
> > >  Some examples:
> > >       * Recently I updated some of the Xfce 4.6 packages. One of them
> > >         was approved without _any_ docs.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=477732
> also all the desktop files were installed and listed in %files twice and
> if the reviewer had tested the package he would have noticed that. Site
> note: The reviewer has been made a sponsor 2 weeks later.

He was approved as a provenpackager, not as a sponsor.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/851519aa/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 00:15:02 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 01:15:02 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
Message-ID: <glqse7$8g0$1@ger.gmane.org>

Christoph Wickert wrote:
> >       * Recently I updated some of the Xfce 4.6 packages. One of them
> >         was approved without _any_ docs.
> https://bugzilla.redhat.com/show_bug.cgi?id=477732
> also all the desktop files were installed and listed in %files twice and
> if the reviewer had tested the package he would have noticed that. Site
> note: The reviewer has been made a sponsor 2 weeks later.

s/he/she/ ;-)
Not that it really matters, I'm just being pedantic. ;-)

As for the complaint, no docs are certainly not ideal, but it's not what is
going to break the distribution either... But yes, reviewers should catch
this.

>> >       * A package was approved with more then 19 missing deps on
>> >         binaries.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=459535

That one sounds like a valid complaint.

>> >       * A font package was approved although it contained another font
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=481501

In this case the reviewer clearly said what needs to be fixed and the
version which got imported was fixed, so it wasn't that bad. Maybe it would
have made more sense to wait for a fixed version, but are there actually
any issues with what was imported?

> Do RH employes have sponsors too? A lot of the bad reviews are done by
> RH people and a lot of bad specs come from RH folks.

In the case of #459535, neither the original reviewer (before you rejected
his review and rereviewed it) nor the people who commented before were RH
employees. The reviewer in #481501 wasn't from Red Hat either. You can't
just blame it all on RH employees.

> Somebody pointed me 
> to:
> https://bugzilla.redhat.com/show_bug.cgi?id=433678
> and I had a quick glance over it before Andreas added his comments:
>       * no list of tests that have been run

Bad.

>       * SourceURL is missing
>       * I can't even find the source because URL is wrong

Very bad.

>       * without the source you cannot check the License tag, md5, etc

You could check the License by extracting the source from the SRPM. But it's
pretty likely that wasn't done here.

>       * docs not marked %doc

RPM marks files in some directories as %doc automatically, AFAIK %{_docdir}
is one of those.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Jan 29 00:19:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 01:19:44 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
Message-ID: <glqsn0$8g0$2@ger.gmane.org>

Robert Scheck wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=469972 is not brilliant, too.

And in this case the bad review was from a community member and the Red Hat
employee actually got it fixed. :-)

So this is another example of how Christoph's generalization about RH
employees being the bad guys/gals is failing.

        Kevin Kofler



From cweyl at alumni.drew.edu  Thu Jan 29 00:35:00 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 16:35:00 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <glqo1j$mo6$4@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
Message-ID: <7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>

On Wed, Jan 28, 2009 at 3:00 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Rahul Sundaram wrote:
>> It appears, most maintainers only have been ignoring the description
>> fields or not filling them properly because of lack of documentation or
>> awareness on how it is being used.
>
> Some of the replies in these threads don't quite suggest that. People
> complain about the "bureaucracy" of being "forced" to write such stuff,
> which pretty much shows they intentionally do not want to fill in those
> fields and won't do it if they can get away without it.

Actually, some of those people are pointing out that this is another
new manual task:

1. Of "questionable usefulness";
2. That most users won't read[1]; which
3. Duplicates the upstream changelog; and
4. Could easily be remedied by providing pointers to the upstream
website and changelog in the installer GUI.

To put it another way, some people are complaining that they actually
have to read the UPSTREAM changelog to determine what UPSTREAM
changed, instead of having the changes summarized and spoon-fed to
them.

To-date, I haven't seen any comment back on my suggestion of pulling
the changelogs out automatically and providing a link + the package
URL link in the GUI.  If CPAN can make README's available like this,
why can't we?  And why isn't this a happy middle ground, providing
detailed upstream change information without another new manual task,
at least worthy of a try?

                                            -Chris

[1] You know, it strikes me that it'd be interesting to see what % of
our users actually run through the update list, rather than just see
the little popup and clicking "update now".  Do we track this, and
maybe we should collect some statistics on this before wasting any
more time with this thread?

-- 
Chris Weyl
Ex astris, scientia



From robert at fedoraproject.org  Thu Jan 29 00:37:19 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 01:37:19 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glqsn0$8g0$2@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
Message-ID: <20090129003719.GA23887@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Kevin Kofler wrote:
> Robert Scheck wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=469972 is not brilliant, too.
> 
> And in this case the bad review was from a community member and the Red Hat
> employee actually got it fixed. :-)

Ex-Red Hat employee AFAIK. But mostly the Red Hat guys are lacking massive
RPM knowledge and ignore Guidelines (How many attempts have been needed to
get e.g. gcc4x.spec renamed to gcc.spec? Libxml2 was another thing being an
example for Christophs claims, I would say).


Greetings,
  Robert



From mclasen at redhat.com  Thu Jan 29 00:38:42 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 28 Jan 2009 19:38:42 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <4980DC1C.8000505@redhat.com>
References: <497599B2.6030203@gmx.net>  <4980DC1C.8000505@redhat.com>
Message-ID: <1233189522.3131.24.camel@matthiasc>

On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway wrote:
> On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet at gmx.net> wrote:
> > Hi,
> > 
> > are there any plans for updating texlive to 2008 in Leonidas?
> 
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether. It is a
> licensing nightmare, a tangled bundle of millions of files with little
> apparent organizational structure, and no overarching licensing
> analysis. I started trying to do a license audit on texlive 2008, but it
> would probably take me at least a month of doing nothing except auditing
> texlive to finish it.
> 
> To be fair, the existing texlive has the same problems, I just was
> unaware of the scope of things until recently.
> 

Right, who needs those oldfashioned TeX users anyway... ?!



From christoph.wickert at googlemail.com  Thu Jan 29 00:45:02 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 01:45:02 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glqse7$8g0$1@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
Message-ID: <1233189903.3786.51.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 01:15 +0100 schrieb Kevin Kofler:
> Christoph Wickert wrote:
> > >       * Recently I updated some of the Xfce 4.6 packages. One of them
> > >         was approved without _any_ docs.
> > https://bugzilla.redhat.com/show_bug.cgi?id=477732
> > also all the desktop files were installed and listed in %files twice and
> > if the reviewer had tested the package he would have noticed that. Site
> > note: The reviewer has been made a sponsor 2 weeks later.
> 
> s/he/she/ ;-)

Thanks, didn't know that.

> Not that it really matters, I'm just being pedantic. ;-)

Me too, epically on reviews. ;)

> >> >       * A font package was approved although it contained another font
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=481501
> 
> In this case the reviewer clearly said what needs to be fixed and the
> version which got imported was fixed, so it wasn't that bad. Maybe it would
> have made more sense to wait for a fixed version, but are there actually
> any issues with what was imported?

None that I know of. The package owner told me a different story on IRC
and I was under the impression that the reviewer did not spot the
problem.
For me it is ok to say "fix this before import", at least if the
packager is experienced enough. 

> > Do RH employes have sponsors too? A lot of the bad reviews are done by
> > RH people and a lot of bad specs come from RH folks.
> 
> In the case of #459535, neither the original reviewer (before you rejected
> his review and rereviewed it) nor the people who commented before were RH
> employees. The reviewer in #481501 wasn't from Red Hat either. You can't
> just blame it all on RH 

I didn't do that, sorry if it sounded like this. I just say "a lot of
reviews". AFAICT RH people are known to do a lot of 3-word-revievs
("looks fine. Approved")

> > Somebody pointed me 
> > to:
> > https://bugzilla.redhat.com/show_bug.cgi?id=433678
> > and I had a quick glance over it before Andreas added his comments:
> >       * no list of tests that have been run
> 
> Bad.
> 
> >       * SourceURL is missing
> >       * I can't even find the source because URL is wrong
> 
> Very bad.
> 
> >       * without the source you cannot check the License tag, md5, etc
> 
> You could check the License by extracting the source from the SRPM. But it's
> pretty likely that wasn't done here.

Yes, the package is GPLv2+ but GPLv2.

> >       * docs not marked %doc
> 
> RPM marks files in some directories as %doc automatically, AFAIK %{_docdir}
> is one of those.

Correct, but IMO there should always be a %doc line, at least for the
usual stuff like AUTHORS, COPYING, ChangeLog etc.

>         Kevin Kofler

Regards,
Christoph



From kevin.kofler at chello.at  Thu Jan 29 00:58:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 01:58:10 +0100
Subject: Draft: simple update description guidelines
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
Message-ID: <glquv3$ern$1@ger.gmane.org>

Chris Weyl wrote:
> To-date, I haven't seen any comment back on my suggestion of pulling
> the changelogs out automatically and providing a link + the package
> URL link in the GUI.  If CPAN can make README's available like this,
> why can't we?  And why isn't this a happy middle ground, providing
> detailed upstream change information without another new manual task,
> at least worthy of a try?

Because upstreams' ways to communicate user-readable lists of changes vary
wildly. Some keep ChangeLog in a user-readable format, some use a NEWS file
in the source tarball, some have a changes.html page on their site which
gets updated with each release, some have separate announcements for each
release, on a new page for each release, some have newsitems on their front
page in a Slashdot-style format and write the lists of changes in there and
finally some don't have such summaries at all and it's your job as the
maintainer to figure out what changed (and complain to upstream about the
lack of documentation). There's just no way to get this right
automatically.

Throwing in an FSF-style changelog full of irrelevant changes like "fix typo
in comment" isn't going to help anyone. And projects don't necessarily ship
with a file called ChangeLog at all. There's plenty of names used, like
ChangeLog.txt, NEWS, NEWS.txt, changes.txt, changes.html, changes.htm,
WhatsNew.txt etc. (there's a lot more). And that's just those which have
the changelog in the tarball, others have it on some website only (and
there names vary even more widely, there are CMS URLs like
index.php?module=changes&someargument=foobar&page=0).

And also all this still doesn't provide the rationale *why* the update is
being pushed.

        Kevin Kofler



From pbrobinson at gmail.com  Thu Jan 29 01:04:00 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Thu, 29 Jan 2009 02:04:00 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233189903.3786.51.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
	<1233189903.3786.51.camel@wicktop.localdomain>
Message-ID: <5256d0b0901281704r24a00d4dl4eee61af59103ee8@mail.gmail.com>

>> RPM marks files in some directories as %doc automatically, AFAIK %{_docdir}
>> is one of those.
>
> Correct, but IMO there should always be a %doc line, at least for the
> usual stuff like AUTHORS, COPYING, ChangeLog etc.

Yes, I thought (but may be wrong) it was a requirement to at least
include the license/copying file.

Peter



From oget.fedora at gmail.com  Thu Jan 29 01:07:06 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Wed, 28 Jan 2009 20:07:06 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233187708.6562.1.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
Message-ID: <e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>

2009/1/28 Brian Pepple :
> On Thu, 2009-01-29 at 00:40 +0100, Christoph Wickert wrote:
>> Am Mittwoch, den 28.01.2009, 14:48 -0800 schrieb Jesse Keating:
>> > On Wed, 2009-01-28 at 23:35 +0100, Christoph Wickert wrote:
>> > >  Some examples:
>> > >       * Recently I updated some of the Xfce 4.6 packages. One of them
>> > >         was approved without _any_ docs.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=477732
>> also all the desktop files were installed and listed in %files twice and
>> if the reviewer had tested the package he would have noticed that. Site
>> note: The reviewer has been made a sponsor 2 weeks later.
>
> He was approved as a provenpackager, not as a sponsor.
>

I really don't want to point fingers on anyone, but how can someone
who completed only 3 reviews (one of them is what you are talking
about above) become a provenpackager? IMHO there is clearly a chain of
people-not-doing-their-job-properly on this. I did 40+ reviews but I
can't still consider myself good enough to apply for
provenpackagership. I still ask for help at certain occasions. There
are so many bits and pieces in doing reviews that I don't think one
can possibly learn most of them in just 3 reviews.

An explanation would be nice.

Orcan



From kevin.kofler at chello.at  Thu Jan 29 01:08:04 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 02:08:04 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
	<1233189903.3786.51.camel@wicktop.localdomain>
Message-ID: <glqvhl$gap$1@ger.gmane.org>

Christoph Wickert wrote:
>> Not that it really matters, I'm just being pedantic. ;-)
> 
> Me too, epically on reviews. ;)

I'm also extremely pedantic on reviews. ;-)

>> >> >       * A font package was approved although it contained another
>> >> >       font
>> > 
>> > https://bugzilla.redhat.com/show_bug.cgi?id=481501
>> 
>> In this case the reviewer clearly said what needs to be fixed and the
>> version which got imported was fixed, so it wasn't that bad. Maybe it
>> would have made more sense to wait for a fixed version, but are there
>> actually any issues with what was imported?
> 
> None that I know of. The package owner told me a different story on IRC
> and I was under the impression that the reviewer did not spot the
> problem.

The reviewer said:
| You have the wrong source archive and the review link in your wiki page is
| not pointing here.
|
| The rest of the package is perfect and you're an experienced packager so
| I'll approve anyway but do make sure you push the right font in koji.

Maybe the submitter missed that. (That's a drawback of "fix
before/during/after import please", the issues may end up overlooked. On
the other hand it does save a pointless turnaround in many cases.)

> For me it is ok to say "fix this before import", at least if the
> packager is experienced enough.

For me too, as long as it's not "you have the following 10+ serious issues
and I've also been unable to verify 5+ more points because the issues make
the package fail to build, but let's approve it and I'll trust you to fix
everything". ;-) In cases like this I definitely want to see the fixed
package first.

        Kevin Kofler



From kevin.kofler at chello.at  Thu Jan 29 01:10:31 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 02:10:31 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
	<1233189903.3786.51.camel@wicktop.localdomain>
	<5256d0b0901281704r24a00d4dl4eee61af59103ee8@mail.gmail.com>
Message-ID: <glqvm7$gap$2@ger.gmane.org>

Peter Robinson wrote:
> Yes, I thought (but may be wrong) it was a requirement to at least
> include the license/copying file.

Yes, if upstream ships one, it must be included. And if upstream doesn't
ship one, that's worth complaining about. It's a violation of most licenses
(and the GPL is one of those) not to include a copy of the license.

        Kevin Kofler



From christoph.wickert at googlemail.com  Thu Jan 29 01:17:04 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 02:17:04 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
Message-ID: <1233191824.3786.55.camel@wicktop.localdomain>

Am Mittwoch, den 28.01.2009, 20:07 -0500 schrieb Orcan Ogetbil:
> 2009/1/28 Brian Pepple :
> > On Thu, 2009-01-29 at 00:40 +0100, Christoph Wickert wrote:
> >> Am Mittwoch, den 28.01.2009, 14:48 -0800 schrieb Jesse Keating:
> >> > On Wed, 2009-01-28 at 23:35 +0100, Christoph Wickert wrote:
> >> > >  Some examples:
> >> > >       * Recently I updated some of the Xfce 4.6 packages. One of them
> >> > >         was approved without _any_ docs.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=477732
> >> also all the desktop files were installed and listed in %files twice and
> >> if the reviewer had tested the package he would have noticed that. Site
> >> note: The reviewer has been made a sponsor 2 weeks later.
> >
> > He was approved as a provenpackager, not as a sponsor.
> >
> 
> I really don't want to point fingers on anyone, but how can someone
> who completed only 3 reviews (one of them is what you are talking
> about above) become a provenpackager? 

Because the whole proven packager model is broken. :(
Therefor I strongly support Robert Scheck's latest proposal.
https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal

> IMHO there is clearly a chain of
> people-not-doing-their-job-properly on this.

+1

Regards,
Christoph



From christoph.wickert at googlemail.com  Thu Jan 29 01:18:38 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 02:18:38 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <5256d0b0901281704r24a00d4dl4eee61af59103ee8@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
	<1233189903.3786.51.camel@wicktop.localdomain>
	<5256d0b0901281704r24a00d4dl4eee61af59103ee8@mail.gmail.com>
Message-ID: <1233191918.3786.58.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 02:04 +0100 schrieb Peter Robinson:
> >> RPM marks files in some directories as %doc automatically, AFAIK %{_docdir}
> >> is one of those.
> >
> > Correct, but IMO there should always be a %doc line, at least for the
> > usual stuff like AUTHORS, COPYING, ChangeLog etc.
> 
> Yes, I thought (but may be wrong) it was a requirement to at least
> include the license/copying file.

You are correct here and this is exactly the point (one of the points)
where the reviewer should have noticed the issue.

> Peter

Regards,
Christoph



From bpepple at fedoraproject.org  Thu Jan 29 01:25:57 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Wed, 28 Jan 2009 20:25:57 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
Message-ID: <1233192357.3509.9.camel@localhost.localdomain>

On Wed, 2009-01-28 at 20:07 -0500, Orcan Ogetbil wrote:
> 2009/1/28 Brian Pepple :
> >
> > He was approved as a provenpackager, not as a sponsor.
> >
> 
> I really don't want to point fingers on anyone, but how can someone
> who completed only 3 reviews (one of them is what you are talking
> about above) become a provenpackager? IMHO there is clearly a chain of
> people-not-doing-their-job-properly on this. I did 40+ reviews but I
> can't still consider myself good enough to apply for
> provenpackagership. I still ask for help at certain occasions. There
> are so many bits and pieces in doing reviews that I don't think one
> can possibly learn most of them in just 3 reviews.
> 
> An explanation would be nice.

This is all a moot point now though, since a couple of weeks ago FESCo
approved a proposal to reset the initial seeding of the provenpackager
group with Packaging Sponsors, and Jesse has made a proposal(1) on
guidelines for approving someone to the provenpackager group.

     1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/5dd5e133/attachment.sig>

From jspaleta at gmail.com  Thu Jan 29 01:25:44 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Jan 2009 16:25:44 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
Message-ID: <604aa7910901281725n7e2ba883s70d2693da540dc06@mail.gmail.com>

On Wed, Jan 28, 2009 at 3:35 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> [1] You know, it strikes me that it'd be interesting to see what % of
> our users actually run through the update list, rather than just see
> the little popup and clicking "update now".  Do we track this, and
> maybe we should collect some statistics on this before wasting any
> more time with this thread?

Simple answer... no we do not have a way to track it...as this the
notification text is part of the repository metadata on each mirror.

Long answer...if there are mirror admins who would be willing to run
analysis scripts...i can work with them to get analysis scripts in
place which provide aggregate statistics concerning the rate at which
yum connections are made to the file holding the notifications.
If clients commonly pull that metadata file in situations even when
there isn't a human to read the data...then that won't tell us much.
But since its an optional repo metadata file, I'm hoping that isn't
happening automatically very often.  But mirror admins would have to
volunteer to run the scripts..or give us access to the logs so we can
parse them ourselves.


-jef



From behdad at behdad.org  Thu Jan 29 02:10:05 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Wed, 28 Jan 2009 21:10:05 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129003719.GA23887@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
Message-ID: <49810FFD.5000106@behdad.org>

Robert Scheck wrote:
> But mostly the Red Hat guys are lacking massive
> RPM knowledge and ignore Guidelines [snip].

Can we please be done with this kind of blanket statements as well as "Red Hat
vs the community" comments?  They are derogatory, demoralizing, and border on
offensive.  And after the third time, simply frustrating.  Red Hat has some of
the best engineers in the world, perhaps some of the worst if you wish, and
most probably a lot of average ones.  So what?

Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
held from the Core days.  Unfortunately (for us "Red Hat guys") most Core
packages were simply thrown upon us as part of our job.  I would never
*volunteer* to do packaging, as that's not what I'm best at.  If someone wants
to go ahead and take maintainership of all my packages, I very well appreciate
it.  I'm sure many other "Red Hat guys" are in the same boat.

behdad
proud Red Hat employee, poor package maintainer, RPM n00b.



From ndbecker2 at gmail.com  Thu Jan 29 02:32:42 2009
From: ndbecker2 at gmail.com (Neal Becker)
Date: Wed, 28 Jan 2009 21:32:42 -0500
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
Message-ID: <glr4gb$qno$1@ger.gmane.org>

Tom "spot" Callaway wrote:

> On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet at gmx.net>
> wrote:
>> Hi,
>> 
>> are there any plans for updating texlive to 2008 in Leonidas?
> 
> I'd have to say the chances of this are extremely unlikely. I'm much
> more inclined to propose that we drop texlive altogether. It is a
> licensing nightmare, a tangled bundle of millions of files with little
> apparent organizational structure, and no overarching licensing
> analysis. I started trying to do a license audit on texlive 2008, but it
> would probably take me at least a month of doing nothing except auditing
> texlive to finish it.
> 
> To be fair, the existing texlive has the same problems, I just was
> unaware of the scope of things until recently.
> 
> ~spot
> 
Really?  I've been reading the texlive list.  I noticed they have been 
dropping many packages due to license issues.




From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Jan 29 04:07:10 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 29 Jan 2009 13:07:10 +0900
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090128221957.GA14226@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
Message-ID: <49812B6E.7090507@ioa.s.u-tokyo.ac.jp>

Robert Scheck wrote, at 01/29/2009 07:19 AM +9:00:
> On Mon, 19 Jan 2009, Brian Pepple wrote:
>> Review Requests: 66
>> Merge Reviews: 10
>> Total reviews modified: 76
> 
> Wow, so much reviews happened in one week. Unfortunately so much quantity,
> but much lesser quality. Do we really need quantity high scores rather the
> quality ones?
> 

Well, although it may be off-topic from what is currently being discussed about
package review stats on this mailing list, however I want to write my opinion
on this.

You may think that the completed number "76" on one week seems large,
however actually from my quick check
- ~265 new review requests are submitted on 2009 January
- Usually I don't care Merge reviews, however even if I don't count
  the number of Merge reviews there are still ~442 reviews which
  are assigned to anybody
  * among them ~72 requests blocks NEEDSPONSOR
And I guess the number of unfinished review requests (or even non-touched requests)
is growing continuously instead of much effort of reviewers.

I won't say that the quantity of review requests one reviewer did can sacrifice
quality of reviews, however it is also true that the current state is almost
unacceptable that there are "so many" unfinished review requests ("so many"
is from my feeling) and some of them are left untouched for months.
(As a sponsor member, I also note that I feel that it is especially
 undesirable that "so many" NEEDSPONSOR-blocking review requests are left
 untouched, because this can take new contributors' will away)

We need much more reviewers and much more reviews to be completed within one week.
I hope that we can find some way to satisfy both quantity and quality.

Mamoru



From mtasaka at ioa.s.u-tokyo.ac.jp  Thu Jan 29 04:10:58 2009
From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka)
Date: Thu, 29 Jan 2009 13:10:58 +0900
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49812B6E.7090507@ioa.s.u-tokyo.ac.jp>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<49812B6E.7090507@ioa.s.u-tokyo.ac.jp>
Message-ID: <49812C52.70903@ioa.s.u-tokyo.ac.jp>

Mamoru Tasaka wrote, at 01/29/2009 01:07 PM +9:00:
> - Usually I don't care Merge reviews, however even if I don't count
>  the number of Merge reviews there are still ~442 reviews which
>  are assigned to anybody

s/anybody/nobody



From cweyl at alumni.drew.edu  Thu Jan 29 04:40:00 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 20:40:00 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <604aa7910901281725n7e2ba883s70d2693da540dc06@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
	<604aa7910901281725n7e2ba883s70d2693da540dc06@mail.gmail.com>
Message-ID: <7dd7ab490901282040x3c23b06ay3cb98ddb3d7f98a8@mail.gmail.com>

On Wed, Jan 28, 2009 at 5:25 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Wed, Jan 28, 2009 at 3:35 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
>> [1] You know, it strikes me that it'd be interesting to see what % of
>> our users actually run through the update list, rather than just see
>> the little popup and clicking "update now".  Do we track this, and
>> maybe we should collect some statistics on this before wasting any
>> more time with this thread?
>
> Simple answer... no we do not have a way to track it...as this the
> notification text is part of the repository metadata on each mirror.
[...snip...]

Hm.  Just off-the-cuff'ing here, but: could we rig the update applet
to provide info that could be reported back via smolt?  All we'd
really need to capture to settle this is the number of times a user
clicked "Update system now" vs "Show updates -> Review", right? ...and
better yet, if any packages were deselected.  A yum plugin could be
used to report the number of times someone does a "yum update."

That would give us some solid data to work with here.

                                    -Chris
-- 
Chris Weyl
Ex astris, scientia



From cweyl at alumni.drew.edu  Thu Jan 29 04:52:13 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 20:52:13 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <glquv3$ern$1@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
	<glquv3$ern$1@ger.gmane.org>
Message-ID: <7dd7ab490901282052j4797812nc682da989d13fef0@mail.gmail.com>

On Wed, Jan 28, 2009 at 4:58 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Chris Weyl wrote:
>> To-date, I haven't seen any comment back on my suggestion of pulling
>> the changelogs out automatically and providing a link + the package
>> URL link in the GUI.  If CPAN can make README's available like this,
>> why can't we?  And why isn't this a happy middle ground, providing
>> detailed upstream change information without another new manual task,
>> at least worthy of a try?
>
> Because upstreams' ways to communicate user-readable lists of changes vary
> wildly. Some keep ChangeLog in a user-readable format, some use a NEWS file
> in the source tarball, some have a changes.html page on their site which
> gets updated with each release, some have separate announcements for each
> release, on a new page for each release, some have newsitems on their front
> page in a Slashdot-style format and write the lists of changes in there and
> finally some don't have such summaries at all and it's your job as the
> maintainer to figure out what changed (and complain to upstream about the
> lack of documentation). There's just no way to get this right
> automatically.
>
> Throwing in an FSF-style changelog full of irrelevant changes like "fix typo
> in comment" isn't going to help anyone. And projects don't necessarily ship
> with a file called ChangeLog at all. There's plenty of names used, like
> ChangeLog.txt, NEWS, NEWS.txt, changes.txt, changes.html, changes.htm,
> WhatsNew.txt etc. (there's a lot more). And that's just those which have
> the changelog in the tarball, others have it on some website only (and
> there names vary even more widely, there are CMS URLs like
> index.php?module=changes&someargument=foobar&page=0).

This is kinda my point exactly.  Our maintainers didn't sign up to
sort through all that and write the equivalent of a legal brief for
each update, especially without any hard data showing that it's
needed; they signed up to maintain packages.

I also tend to think we're downplaying the intelligence of our users.
If they're smart enough to try to sort through the updates and
reasonably figure out what they do and don't want, I'm pretty sure
that if we give them the tools (package URL, direct pointer to any
changelog we can auto-find, etc), they'll be to make those decisions.
If they're not, well...  It doesn't really matter what we put in the
updates field, then.

> And also all this still doesn't provide the rationale *why* the update is
> being pushed.

And, of course, that's the other point: is this a back-door attempt to
require some sort of extended push justification, justification we've
never required before, or a sincere desire to give our users more
information?

                                        -Chris
-- 
Chris Weyl
Ex astris, scientia



From jkeating at redhat.com  Thu Jan 29 05:01:11 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 21:01:11 -0800
Subject: Scrubbing boot.iso from CD1 and DVD
Message-ID: <1233205271.8363.258.camel@localhost.localdomain>

I've committed code to pungi that will prevent boot.iso from being on
CD1 and the DVD.  I've had various discussions with folks about this in
the past, and given that boot.iso is 122M on x86_64 that's a lot of
packages we could have instead.  In the past, boot.iso was much smaller
and it wasn't a big cost, things have changed.

If anybody has a really good reason for why we should continue to put
boot.iso on the media, speak now.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/932b9d95/attachment.sig>

From jkeating at redhat.com  Thu Jan 29 05:01:49 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 21:01:49 -0800
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <1233205271.8363.258.camel@localhost.localdomain>
References: <1233205271.8363.258.camel@localhost.localdomain>
Message-ID: <1233205309.8363.259.camel@localhost.localdomain>

On Wed, 2009-01-28 at 21:01 -0800, Jesse Keating wrote:
>  If anybody has a really good reason for why we should continue to put
> boot.iso on the media, speak now.

This change will be post-alpha.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/fcc212e9/attachment.sig>

From csnook at redhat.com  Thu Jan 29 05:24:50 2009
From: csnook at redhat.com (Chris Snook)
Date: Thu, 29 Jan 2009 00:24:50 -0500
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <1233205271.8363.258.camel@localhost.localdomain>
References: <1233205271.8363.258.camel@localhost.localdomain>
Message-ID: <49813DA2.9080701@redhat.com>

Jesse Keating wrote:
> I've committed code to pungi that will prevent boot.iso from being on
> CD1 and the DVD.  I've had various discussions with folks about this in
> the past, and given that boot.iso is 122M on x86_64 that's a lot of
> packages we could have instead.  In the past, boot.iso was much smaller
> and it wasn't a big cost, things have changed.
> 
> If anybody has a really good reason for why we should continue to put
> boot.iso on the media, speak now.

Have we relaxed the checks that make the installer bail out if your boot.iso 
doesn't precisely match what's in your repo?  If not, decoupling them in the 
downloads will create a lot of pain for a lot of people.

-- Chris



From jkeating at redhat.com  Thu Jan 29 05:25:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 21:25:13 -0800
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <49813DA2.9080701@redhat.com>
References: <1233205271.8363.258.camel@localhost.localdomain>
	<49813DA2.9080701@redhat.com>
Message-ID: <1233206713.8363.260.camel@localhost.localdomain>

On Thu, 2009-01-29 at 00:24 -0500, Chris Snook wrote:
>  
> Have we relaxed the checks that make the installer bail out if your boot.iso 
> doesn't precisely match what's in your repo?  If not, decoupling them in the 
> downloads will create a lot of pain for a lot of people.

Yes, a while ago now.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/934f00c7/attachment.sig>

From csnook at redhat.com  Thu Jan 29 05:27:54 2009
From: csnook at redhat.com (Chris Snook)
Date: Thu, 29 Jan 2009 00:27:54 -0500
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <1233206713.8363.260.camel@localhost.localdomain>
References: <1233205271.8363.258.camel@localhost.localdomain>	<49813DA2.9080701@redhat.com>
	<1233206713.8363.260.camel@localhost.localdomain>
Message-ID: <49813E5A.8050609@redhat.com>

Jesse Keating wrote:
> On Thu, 2009-01-29 at 00:24 -0500, Chris Snook wrote:
>>  
>> Have we relaxed the checks that make the installer bail out if your boot.iso 
>> doesn't precisely match what's in your repo?  If not, decoupling them in the 
>> downloads will create a lot of pain for a lot of people.
> 
> Yes, a while ago now.
> 
> 

In that case, I have no objection.  In the interest of convenience, it might be 
nice to put them on a separate rescue CD (making yet more room on the install 
set) since there tends to be an overlap between the sorts of people who use 
boot.iso and the sorts of people who use the rescue environment.

-- Chris



From jkeating at redhat.com  Thu Jan 29 05:37:44 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 21:37:44 -0800
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <49813E5A.8050609@redhat.com>
References: <1233205271.8363.258.camel@localhost.localdomain>
	<49813DA2.9080701@redhat.com>
	<1233206713.8363.260.camel@localhost.localdomain>
	<49813E5A.8050609@redhat.com>
Message-ID: <1233207464.8363.262.camel@localhost.localdomain>

On Thu, 2009-01-29 at 00:27 -0500, Chris Snook wrote:
>  In that case, I have no objection.  In the interest of convenience, it might be 
> nice to put them on a separate rescue CD (making yet more room on the install 
> set) since there tends to be an overlap between the sorts of people who use 
> boot.iso and the sorts of people who use the rescue environment.

boot.iso has been capable of running the rescue environment since F9 I
do believe.  That's when it grew.  There is no longer an iso that is
just kernel/initrd (stage1), all the isos we generate have both
kernel/initrd (stage1) and install.img (stage2).

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/a1dda139/attachment.sig>

From jspaleta at gmail.com  Thu Jan 29 06:10:28 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 28 Jan 2009 21:10:28 -0900
Subject: Draft: simple update description guidelines
In-Reply-To: <7dd7ab490901282040x3c23b06ay3cb98ddb3d7f98a8@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
	<604aa7910901281725n7e2ba883s70d2693da540dc06@mail.gmail.com>
	<7dd7ab490901282040x3c23b06ay3cb98ddb3d7f98a8@mail.gmail.com>
Message-ID: <604aa7910901282210o5eafc03fu2dd5924105b1de4c@mail.gmail.com>

On Wed, Jan 28, 2009 at 7:40 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
> Hm.  Just off-the-cuff'ing here, but: could we rig the update applet
> to provide info that could be reported back via smolt?  All we'd
> really need to capture to settle this is the number of times a user
> clicked "Update system now" vs "Show updates -> Review", right? ...and
> better yet, if any packages were deselected.  A yum plugin could be
> used to report the number of times someone does a "yum update."
>
> That would give us some solid data to work with here.


You'd have to talk to the smolt developers about that. But my sense is
that that is an abuse of smolt and it should be avoided. I don't think
smolt was built nor advertised to track administrative actions.  I'm
more than happy to analyze logs on mirror servers if admins agree to
run scripts against the logs. I'll even write the scripts. I'm burning
a few cycles now putting a framework in place for us to do more
analysis with our mirrormanager logs.  But I'm really not keen on
turning smolt into an advanced phonehome keylogger just so we can do
marginally better trending. Doing that will hurt smolt's adoption as a
hardware profiler.

-jef



From cweyl at alumni.drew.edu  Thu Jan 29 06:22:08 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Wed, 28 Jan 2009 22:22:08 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <604aa7910901282210o5eafc03fu2dd5924105b1de4c@mail.gmail.com>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
	<7dd7ab490901281635j32b5d485x7042473faa1e58b0@mail.gmail.com>
	<604aa7910901281725n7e2ba883s70d2693da540dc06@mail.gmail.com>
	<7dd7ab490901282040x3c23b06ay3cb98ddb3d7f98a8@mail.gmail.com>
	<604aa7910901282210o5eafc03fu2dd5924105b1de4c@mail.gmail.com>
Message-ID: <7dd7ab490901282222u1fba50a4v143a56e594a1e7f3@mail.gmail.com>

On Wed, Jan 28, 2009 at 10:10 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Wed, Jan 28, 2009 at 7:40 PM, Chris Weyl <cweyl at alumni.drew.edu> wrote:
>> That would give us some solid data to work with here.
>
> You'd have to talk to the smolt developers about that. But my sense is
> that that is an abuse of smolt and it should be avoided. I don't think
> smolt was built nor advertised to track administrative actions.  I'm
> more than happy to analyze logs on mirror servers if admins agree to
> run scripts against the logs. I'll even write the scripts. I'm burning
> a few cycles now putting a framework in place for us to do more
> analysis with our mirrormanager logs.  But I'm really not keen on
> turning smolt into an advanced phonehome keylogger just so we can do
> marginally better trending. Doing that will hurt smolt's adoption as a
> hardware profiler.

Ah well.  Thanks :)

                                -Chris
-- 
Chris Weyl
Ex astris, scientia



From sven at lank.es  Thu Jan 29 06:44:36 2009
From: sven at lank.es (Sven Lankes)
Date: Thu, 29 Jan 2009 07:44:36 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glqvhl$gap$1@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<glqse7$8g0$1@ger.gmane.org>
	<1233189903.3786.51.camel@wicktop.localdomain>
	<glqvhl$gap$1@ger.gmane.org>
Message-ID: <20090129064436.GJ2796@killefiz>

On Thu, Jan 29, 2009 at 02:08:04AM +0100, Kevin Kofler wrote:

>>> In this case the reviewer clearly said what needs to be fixed and the
>>> version which got imported was fixed, so it wasn't that bad. Maybe it
>>> would have made more sense to wait for a fixed version, but are there
>>> actually any issues with what was imported?

>> None that I know of. The package owner told me a different story on IRC
>> and I was under the impression that the reviewer did not spot the
>> problem.

What I said was 'I had a package a approved that had the wrong font in
it' and while this wasn't meant as 'The reviewer didn't spot the error'
it can easily be understood that way (heck - it's probably very
difficult to understand it any other way). 

By the time we clarified this, Christophs first email was already out.

So: It's all my fault and sorry for the noise (of this third of the
issues).

> Maybe the submitter missed that. (That's a drawback of "fix
> before/during/after import please", the issues may end up overlooked. On
> the other hand it does save a pointless turnaround in many cases.)

I agree - while 'wrong content' sounds like a grave error it actually
wasn't as these kind of very simple font packages just include "*.ttf"
from the source-zip. 

Blocking the review for this issue would just have meant another round
trip with no added value.

So again: Apologies for bringing this up.

-- 
sven === jabber/xmpp: sven at lankes.net



From tibbs at math.uh.edu  Thu Jan 29 06:47:56 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 29 Jan 2009 00:47:56 -0600
Subject: what requires fedora-release-notes
In-Reply-To: <604aa7910901281017v773c86bancb86e24522568f71@mail.gmail.com>
References: <200901281624.31502.pvrabec@redhat.com>
	<20090128162403.GB6735@nostromo.devel.redhat.com>
	<1233160981.8363.227.camel@localhost.localdomain>
	<ufawscf71dn.fsf@epithumia.math.uh.edu>
	<604aa7910901281017v773c86bancb86e24522568f71@mail.gmail.com>
Message-ID: <ufad4e6obfn.fsf@epithumia.math.uh.edu>

>>>>> "JS" == Jeff Spaleta <jspaleta at gmail.com> writes:

JS> Can you explain why you are rebuilding fedora-release?

Because I need to replace the set of repos contained within that
package.

JS> I thought we provided generic-release package so that you don't
JS> have to rebuild fedora-release as part of customization.

Doing that buys me nothing.  Because fedora-relase contains more than
just the repos, I have to start with the base package for each release
or I risk missing out on things like system-release-cpe or changes in
the way keys are handled.  So I would still have to check
fedora-release out of CVS, copy the bits somewhere, modify it for my
custom stuff, and build it.  That's actually another step over just
doing the checkout, patching the fedora-release spec and doing make
noarch.

Either way I'm rebuilding fedora-release.  If the only issue is
whether I rename the package, I'm not going to bother.  Now, if the
repos would be split out so that I can provide my own without having
to mess with fedora-release, then that would be ideal but my use case
is pretty narrow so I can understand why the suggestion did not
manage any traction.

 - J<



From dtardon at redhat.com  Thu Jan 29 06:52:25 2009
From: dtardon at redhat.com (David Tardon)
Date: Thu, 29 Jan 2009 07:52:25 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233186043.3786.40.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
Message-ID: <20090129065225.GA20693@localhost.localdomain>

On Thu, Jan 29, 2009 at 12:40:43AM +0100, Christoph Wickert wrote:
> Do RH employes have sponsors too? A lot of the bad reviews are done by
> RH people and a lot of bad specs come from RH folks. Somebody pointed me
> to:
> https://bugzilla.redhat.com/show_bug.cgi?id=433678
> and I had a quick glance over it before Andreas added his comments:
>       * no list of tests that have been run
>       * SourceURL is missing

What about fixing rpmlint to check for missing tags? Just now it simply
ignores them, but, on the other side, checks such _very important_
things as mixing tabs and spaces, that certainly have great impact on
functionality of the package.

Regards,
David



From nicolas.mailhot at laposte.net  Thu Jan 29 07:08:52 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 08:08:52 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glqr30$4l0$1@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org>
Message-ID: <1233212932.19140.6.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 00:51 +0100, Kevin Kofler a ?crit :
> Tom "spot" Callaway wrote:
> > I'd have to say the chances of this are extremely unlikely. I'm much
> > more inclined to propose that we drop texlive altogether.
> 
> No TeX? That would make Fedora pretty much useless for Mathematics and
> anything related!
> 
> If concrete licensing issues are found by somebody, of course those need to
> be addressed, but dropping all of TeX on the ground that it's too hard to
> audit is a horribly bad idea.

People who want TEX kept should create a task force and feed TEXlive
2008 in rawhide bit by bit, checking for each bit the licensing is ok.
That's about the only way the burden of checking TEX can be distributed
enough it won't depend on a couple packagers, when the amount of work is
too much to be humanly doable by a few people alone in a realistic
timeframe.

Our curent TEX packaging would be similar to try to package 80% of CPAN
in a single source package. Of course people crap out when they try to
check licensing correctly (and TEX stuff has more licensing variability
than Perl)

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/fc1125bc/attachment.sig>

From drago01 at gmail.com  Thu Jan 29 07:12:55 2009
From: drago01 at gmail.com (drago01)
Date: Thu, 29 Jan 2009 08:12:55 +0100
Subject: Lack of update information
In-Reply-To: <glqitj$96k$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1AE9.20606@fedoraproject.org> <gllh0a$ha1$1@ger.gmane.org>
	<1233013714.8363.167.camel@localhost.localdomain>
	<497E53E3.1060302@freenet.de>
	<1233017758.8363.183.camel@localhost.localdomain>
	<497E6D62.4060708@freenet.de>
	<1233078115.8363.194.camel@localhost.localdomain>
	<497FDFBF.4070209@freenet.de> <glqitj$96k$1@ger.gmane.org>
Message-ID: <f6ca9fed0901282312o6ba78cf3l81573eb314fc7290@mail.gmail.com>

On Wed, Jan 28, 2009 at 10:32 PM, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> Ralf Corsepius wrote:
>>
>> Jesse Keating wrote:
>>>
>>> Try doing updates on a netbook,
>>
>> I own one - Typical "yum update" times are in the order of "very few"
>> minutes at average.
>
> Looking only at install times...
>
> Asus EEE 900A (SSD): 3m40s
> HP xw4400 Workstation (SATA platter): 1m25s
>
> ...and the latter did kernel-devel as well as kernel, kernel-headers and
> kernel-firmware, plus it also had to remove a kmod-nvidia. (Times are
> approximate.)
>
> ...so the SSD is about 3x slower or more (especially as I notice
> kernel-devel took the desktop the longest).
>
>>>  Yum isn't really the problem here, it's the
>>> rpms themselves, constantly doing ldconfigs, cache updates, tonnes of
>>> hardlinking, etc...
>>
>>  From what I experience, SELinux policy updates are by far means the most
>> resource intense/most time consuming part of updating.
>
> Really? For me, it's always OOo updates... 100 MB in a single package?
> (What's worse is that OOo can't be updated while running... it doesn't
> crash, but it becomes unable to save; bad news if you forgot to save first.
> That and Firefox are the only things I'm aware of with that problem, but at
> least with FF it only breaks typing addresses into the address bar.)
>
> Whereas selinux is a 2.0 MB package :-).

Its not about the filesize but about the scripts that run on upgrade.



From robert at fedoraproject.org  Thu Jan 29 07:22:19 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 08:22:19 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233192357.3509.9.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
Message-ID: <20090129072219.GA5712@hurricane.linuxnetz.de>

On Wed, 28 Jan 2009, Brian Pepple wrote:
> This is all a moot point now though, since a couple of weeks ago FESCo
> approved a proposal to reset the initial seeding of the provenpackager
> group with Packaging Sponsors, and Jesse has made a proposal(1) on
> guidelines for approving someone to the provenpackager group.
> 
>      1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html

Again, Jesse's proposal still keeps the same issues, just puts up new
guidelines and enforces nothing. Provenpackager is to critical to just
handle it just using guidelines and by a single provenpackage sponsor.
The approval of multiple (many) sponsors is needed before a packager
can get a provenpackage one - and this is what my proposal is about...


Greetings,
  Robert



From nicolas.mailhot at laposte.net  Thu Jan 29 07:26:50 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 08:26:50 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233182104.3786.19.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
Message-ID: <1233214010.19140.10.camel@arekh.okg>

Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a ?crit :

>       * A font package was approved although it contained another font

And this was caught in review before the approval and fixed before cvs
import. So go search your quality problems somewhere else.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/91d5c9d2/attachment.sig>

From robert at fedoraproject.org  Thu Jan 29 07:34:46 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 08:34:46 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49810FFD.5000106@behdad.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
Message-ID: <20090129073446.GB5712@hurricane.linuxnetz.de>

On Wed, 28 Jan 2009, Behdad Esfahbod wrote:
> Can we please be done with this kind of blanket statements as well as "Red Hat
> vs the community" comments?  They are derogatory, demoralizing, and border on
> offensive.  And after the third time, simply frustrating.  Red Hat has some of
> the best engineers in the world, perhaps some of the worst if you wish, and
> most probably a lot of average ones.  So what?

Such comparisons must happen. And if you would have read my mail correctly
or even checked what I'm saying, you would have seen, that my examples with
the Merge Reviews are true. In that cases it was even blocking/refusing the
Merge Reviews (or parts of it) - the old story from my December 2008 mail.

When looking e.g. to ethtool, the maintainer was allowed, not to show up
ever on the Merge Review, once I asked Tom Callaway to give him a clout. As
co-maintainer, I've solved the Merge Review, fixed all open bug reports the
maintainer did not take care about, but I can't co-maintain every package.
The ethtool maintainer being upstream as well, did after Tom's clout only
one time reply to my e-mails and to a bug report. So one time in ~ 6 years,
that's neither a good behaviour for a downstream maintainer, nor even for
an upstream one. And when talking in #fedora-devel, I got told, that I am
not alone with this issue.

> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
> held from the Core days.  Unfortunately (for us "Red Hat guys") most Core
> packages were simply thrown upon us as part of our job.  I would never
> *volunteer* to do packaging, as that's not what I'm best at.  If someone wants
> to go ahead and take maintainership of all my packages, I very well appreciate
> it.  I'm sure many other "Red Hat guys" are in the same boat.

Taking co-maintainship or even the package doesn't solve 'em all, as I
pointed out above already. If the "Red Hat guy" is upstream of software,
it's more hard to work around.

> proud Red Hat employee, poor package maintainer, RPM n00b.

Last of it could be easily solved by getting a RPM training, isn't there a
training department inhouse of your employer?


Greetings,
  Robert



From akurtako at redhat.com  Thu Jan 29 07:46:15 2009
From: akurtako at redhat.com (Alexander Kurtakov)
Date: Thu, 29 Jan 2009 08:46:15 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129072219.GA5712@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<1233187708.6562.1.camel@localhost.localdomain>	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
Message-ID: <49815EC7.3060409@redhat.com>

Robert Scheck wrote:
> On Wed, 28 Jan 2009, Brian Pepple wrote:
>   
>> This is all a moot point now though, since a couple of weeks ago FESCo
>> approved a proposal to reset the initial seeding of the provenpackager
>> group with Packaging Sponsors, and Jesse has made a proposal(1) on
>> guidelines for approving someone to the provenpackager group.
>>
>>      1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
>>     
>
> Again, Jesse's proposal still keeps the same issues, just puts up new
> guidelines and enforces nothing. Provenpackager is to critical to just
> handle it just using guidelines and by a single provenpackage sponsor.
> The approval of multiple (many) sponsors is needed before a packager
> can get a provenpackage one - and this is what my proposal is about...
>
>
> Greetings,
>   Robert
>
>   
As everyone is so afraid of the damage provenpackager can do I want to 
propose something else:
Provide a possibility for maintainers to open their package for 
***EVERY*** packager. I would love to do this.  And do you know why?
Because I want to see some community growing and people trying to fix 
things even if they DO mistakes. How can someone learn if he didn't try 
to do it?
I would prefer if someone fix 3 things and break one because I will have 
to fix only 1 thing not 3 :). And after pointing the problem to the 
author it won't happen again ( I believe). 

P.S. Please don't tell me that I don't care for this packages because 
I'm upstream author for this packages and I invested my free time in 
them before started at Red Hat.

Alexander Kurtakov



From rawhide at fedoraproject.org  Thu Jan 29 07:48:01 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Thu, 29 Jan 2009 07:48:01 +0000 (UTC)
Subject: rawhide report: 20090129 changes
Message-ID: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>

Compose started at Thu Jan 29 06:01:03 UTC 2009

Broken deps for i386
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.i386 requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	conexusmm-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.i386 requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.x86_64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc requires libpapyrusmm.so.0
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.ppc requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	conexusmm-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	conexusmm-devel-0.5.0-6.fc8.ppc64 requires libpapyrusmm.so.0()(64bit)
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From drago01 at gmail.com  Thu Jan 29 07:55:51 2009
From: drago01 at gmail.com (drago01)
Date: Thu, 29 Jan 2009 08:55:51 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49815EC7.3060409@redhat.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
Message-ID: <f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>

On Thu, Jan 29, 2009 at 8:46 AM, Alexander Kurtakov <akurtako at redhat.com> wrote:
> Robert Scheck wrote:
>>
>> On Wed, 28 Jan 2009, Brian Pepple wrote:
>>
>>>
>>> This is all a moot point now though, since a couple of weeks ago FESCo
>>> approved a proposal to reset the initial seeding of the provenpackager
>>> group with Packaging Sponsors, and Jesse has made a proposal(1) on
>>> guidelines for approving someone to the provenpackager group.
>>>
>>>     1.
>>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
>>>
>>
>> Again, Jesse's proposal still keeps the same issues, just puts up new
>> guidelines and enforces nothing. Provenpackager is to critical to just
>> handle it just using guidelines and by a single provenpackage sponsor.
>> The approval of multiple (many) sponsors is needed before a packager
>> can get a provenpackage one - and this is what my proposal is about...
>>
>>
>> Greetings,
>>  Robert
>>
>>
>
> As everyone is so afraid of the damage provenpackager can do I want to
> propose something else:
> Provide a possibility for maintainers to open their package for ***EVERY***
> packager. I would love to do this.  And do you know why?
> Because I want to see some community growing and people trying to fix things
> even if they DO mistakes. How can someone learn if he didn't try to do it?
> I would prefer if someone fix 3 things and break one because I will have to
> fix only 1 thing not 3 :). And after pointing the problem to the author it
> won't happen again ( I believe).
> P.S. Please don't tell me that I don't care for this packages because I'm
> upstream author for this packages and I invested my free time in them before
> started at Red Hat.
>
> Alexander Kurtakov

Did it ever happen that a "provenpackager" or any packager in the days
of open ACLs cause any real damage to packages (not owned by him)?
I am not aware of any such cases, it seems to me that we are trying to
solve a non existing problem.



From jkeating at redhat.com  Thu Jan 29 07:54:14 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Wed, 28 Jan 2009 23:54:14 -0800
Subject: rawhide report: 20090129 changes
In-Reply-To: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>
References: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>
Message-ID: <1233215654.8363.266.camel@localhost.localdomain>

On Thu, 2009-01-29 at 07:48 +0000, Rawhide Report wrote:
>  Compose started at Thu Jan 29 06:01:03 UTC 2009

Still trying to get the repodiff utility fully working with new yum api,
this is causing the lack of change information.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090128/490ed415/attachment.sig>

From akurtako at redhat.com  Thu Jan 29 08:12:49 2009
From: akurtako at redhat.com (Alexander Kurtakov)
Date: Thu, 29 Jan 2009 09:12:49 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<1233187708.6562.1.camel@localhost.localdomain>	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>	<1233192357.3509.9.camel@localhost.localdomain>	<20090129072219.GA5712@hurricane.linuxnetz.de>	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
Message-ID: <49816501.5050309@redhat.com>

drago01 wrote:
> On Thu, Jan 29, 2009 at 8:46 AM, Alexander Kurtakov <akurtako at redhat.com> wrote:
>   
>> Robert Scheck wrote:
>>     
>>> On Wed, 28 Jan 2009, Brian Pepple wrote:
>>>
>>>       
>>>> This is all a moot point now though, since a couple of weeks ago FESCo
>>>> approved a proposal to reset the initial seeding of the provenpackager
>>>> group with Packaging Sponsors, and Jesse has made a proposal(1) on
>>>> guidelines for approving someone to the provenpackager group.
>>>>
>>>>     1.
>>>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
>>>>
>>>>         
>>> Again, Jesse's proposal still keeps the same issues, just puts up new
>>> guidelines and enforces nothing. Provenpackager is to critical to just
>>> handle it just using guidelines and by a single provenpackage sponsor.
>>> The approval of multiple (many) sponsors is needed before a packager
>>> can get a provenpackage one - and this is what my proposal is about...
>>>
>>>
>>> Greetings,
>>>  Robert
>>>
>>>
>>>       
>> As everyone is so afraid of the damage provenpackager can do I want to
>> propose something else:
>> Provide a possibility for maintainers to open their package for ***EVERY***
>> packager. I would love to do this.  And do you know why?
>> Because I want to see some community growing and people trying to fix things
>> even if they DO mistakes. How can someone learn if he didn't try to do it?
>> I would prefer if someone fix 3 things and break one because I will have to
>> fix only 1 thing not 3 :). And after pointing the problem to the author it
>> won't happen again ( I believe).
>> P.S. Please don't tell me that I don't care for this packages because I'm
>> upstream author for this packages and I invested my free time in them before
>> started at Red Hat.
>>
>> Alexander Kurtakov
>>     
>
> Did it ever happen that a "provenpackager" or any packager in the days
> of open ACLs cause any real damage to packages (not owned by him)?
> I am not aware of any such cases, it seems to me that we are trying to
> solve a non existing problem.
>   
I'm simply trying to think of a solution for both sides - paranoic-about-security and believe-in-good-will.

Alexander Kurtakov



From mschmidt at redhat.com  Thu Jan 29 08:13:56 2009
From: mschmidt at redhat.com (Michal Schmidt)
Date: Thu, 29 Jan 2009 09:13:56 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <4980E0F7.6020507@fedoraproject.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org>
Message-ID: <20090129091356.12ed0a2d@leela>

Dne Thu, 29 Jan 2009 04:19:27 +0530
Rahul Sundaram <sundaram at fedoraproject.org> napsal(a):

> The general consensus seem to push for more of a best practises 
> document. So I am going with
> 
> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 
> It appears, most maintainers only have been ignoring the description 
> fields or not filling them properly because of lack of documentation
> or awareness on how it is being used. I am hoping just merging this 
> information in the wiki and adding appropriate references would be 
> enough to solve that problem. If not, we will deal with that, later.

More effective than a guideline on the wiki would be to improve the
description of the Notes field in Bodhi web interface. It will help
maintainers understand the purpose of the Notes better:

https://fedorahosted.org/bodhi/ticket/294

Michal



From hughsient at gmail.com  Thu Jan 29 08:22:14 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 29 Jan 2009 08:22:14 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128190017.fe0c3708.mschwendt@gmail.com>
References: <497F5005.4060107@fedoraproject.org> <498011FB.6060809@freenet.de>
	<1233139028.3174.46.camel@hughsie-work.lan>
	<20090128190017.fe0c3708.mschwendt@gmail.com>
Message-ID: <1233217334.9061.2.camel@hughsie-work.lan>

On Wed, 2009-01-28 at 19:00 +0100, Michael Schwendt wrote:
>  No, because they won't cherry-pick updates anyway. They expect the
> package maintainers (== the distribution vendor) to offer updates
> that just work.

You ever watched a user using Fedora on a 56k dial up connection?

Richard.




From paul at all-the-johnsons.co.uk  Thu Jan 29 08:54:08 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 29 Jan 2009 08:54:08 +0000
Subject: mono-tools and MD for f10
Message-ID: <1233219248.6740.43.camel@PB3.Linux>

Hi,

I've more or less completed the update build for f10 to be using
mono-2.2. Unfortunately, I can't build mono-tools or monodevelop for f10
as my box is running mono-2.4 from rawhide and for some reason, this
breaks the build of both of these packages.

I've attempted to build in mock, but get nowhere (mono-tools needs
mono-devel >= 2.2 and mock is not pulling it in).

If anyone has a few spare cycles, any chance of helping me with a build
of both of these?

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/fda8a089/attachment.sig>

From mschwendt at gmail.com  Thu Jan 29 08:55:38 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 29 Jan 2009 09:55:38 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233217334.9061.2.camel@hughsie-work.lan>
References: <497F5005.4060107@fedoraproject.org> <498011FB.6060809@freenet.de>
	<1233139028.3174.46.camel@hughsie-work.lan>
	<20090128190017.fe0c3708.mschwendt@gmail.com>
	<1233217334.9061.2.camel@hughsie-work.lan>
Message-ID: <20090129095538.345fdc2a.mschwendt@gmail.com>

On Thu, 29 Jan 2009 08:22:14 +0000, Richard wrote:

> On Wed, 2009-01-28 at 19:00 +0100, Michael Schwendt wrote:
> >  No, because they won't cherry-pick updates anyway. They expect the
> > package maintainers (== the distribution vendor) to offer updates
> > that just work.
> 
> You ever watched a user using Fedora on a 56k dial up connection?

Yes, they are being killed by having to download the frequently changing
metadata already. That's why they choose different distributions.

Is that our new primary target group?



From rc040203 at freenet.de  Thu Jan 29 09:00:26 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 29 Jan 2009 10:00:26 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233217334.9061.2.camel@hughsie-work.lan>
References: <497F5005.4060107@fedoraproject.org>
	<498011FB.6060809@freenet.de>	<1233139028.3174.46.camel@hughsie-work.lan>	<20090128190017.fe0c3708.mschwendt@gmail.com>
	<1233217334.9061.2.camel@hughsie-work.lan>
Message-ID: <4981702A.5000403@freenet.de>

Richard Hughes wrote:
> On Wed, 2009-01-28 at 19:00 +0100, Michael Schwendt wrote:
>>  No, because they won't cherry-pick updates anyway. They expect the
>> package maintainers (== the distribution vendor) to offer updates
>> that just work.
> 
> You ever watched a user using Fedora on a 56k dial up connection?

Well, living one of the "white spots in Germany's DSL map", I have been 
using Fedora via ISDN (and later over 356k DSL) for quite some time.

The resort on updates had been to manually run updates at carefully 
chosen times, to share yum-caches inside of my local network and to 
exclude certain packages (e.g. openoffice) from updates.

Ralf




From mschwendt at gmail.com  Thu Jan 29 09:08:39 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 29 Jan 2009 10:08:39 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <glqldp$fg9$3@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>
	<20090128152342.GC3119@mokona.greysector.net>
	<20090128190426.0a2f661d.mschwendt@gmail.com>
	<glqldp$fg9$3@ger.gmane.org>
Message-ID: <20090129100839.1a6a2ac0.mschwendt@gmail.com>

On Wed, 28 Jan 2009 23:15:20 +0100, Kevin wrote:

> Michael Schwendt wrote:
> > Bodhi itself, however, floods those bugzilla tickets with
> > comments. The most confusing comment is the one that notifies about
> > "submitted" (= pending) updates, which are only available within
> > koji. If we talk about "real users", this is the first comment
> > that ought to be killed, since users are confused a lot by
> > updates, which are not available.
> 
> I disagree. It claims nowhere that those updates have been pushed, and for
> me it is good to know that a fix has been queued.

Only because you are familiar with bodhi's terminology ("submitted",
"pending", "pushed"). Bugzilla users are presented with a URL to an update
ticket in bodhi, which confuses them. That can be observed both in comments
in bz as well as in bodhi.



From markmc at redhat.com  Thu Jan 29 09:23:34 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 29 Jan 2009 09:23:34 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <glqo1j$mo6$4@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>
	<glqmnb$mo6$1@ger.gmane.org> <4980E0F7.6020507@fedoraproject.org>
	<glqo1j$mo6$4@ger.gmane.org>
Message-ID: <1233221014.6470.33.camel@blaa>

On Thu, 2009-01-29 at 00:00 +0100, Kevin Kofler wrote:
> Rahul Sundaram wrote:
> > It appears, most maintainers only have been ignoring the description
> > fields or not filling them properly because of lack of documentation or
> > awareness on how it is being used.
> 
> Some of the replies in these threads don't quite suggest that. People
> complain about the "bureaucracy" of being "forced" to write such stuff,
> which pretty much shows they intentionally do not want to fill in those
> fields and won't do it if they can get away without it.

If you assume good faith, you might interpret people's opinions as:

  - This doesn't help users, they just blindly apply updates anyway

  - Users who do read the update description have the ability to go 
    read the upstream changelog themselves

  - This will be a lot of manual work for maintainers

  - This could be done automatically

  - This is just yet another attempt by misguided people to turn Fedora 
    into a bureaucratic minefield

I don't fully agree with any of those points, but I can understand where
they come from.

You won't change those opinions with a set of "you MUST do foo" rules.
This is not a technical matter which you can come up with a black and
white policy for. We need package maintainers who exercise their own
good judgement and the flip-side of that is we must *allow* maintainers
to exercise their own judgement.

Each of the sections in the draft:

  https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines

begin with a "user's perspective". If package maintainers take that
perspective on board and read the suggestions that follow, I think we'll
end up with a better situation than we're in now without permanently
alienating anyone in the process.

Cheers,
Mark.



From robert at fedoraproject.org  Thu Jan 29 09:24:41 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 10:24:41 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49815EC7.3060409@redhat.com>
References: <20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
Message-ID: <20090129092441.GA15587@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Alexander Kurtakov wrote:
> Provide a possibility for maintainers to open their package for  
> ***EVERY*** packager. I would love to do this.  And do you know why?
> Because I want to see some community growing and people trying to fix  
> things even if they DO mistakes. How can someone learn if he didn't try  
> to do it?

No - no - no. I won't do that.

Too many packagers, even provenpackagers (it don't want to point on latest
unwanted package touching by provenpackager for example) are "fixing" spec
files or packages by breaking it afterwards and this never sh all happen.

Fedora is not (or at least shouldn't be) the playground of/for unknowledged
packagers. And with your suggestion you're trying to make it that.

Ask e.g. the FAS users ixs, cwickert or red about getting packages unwanted
"fixed" by packagers or even provenpackagers (see Cc:).

As long as our provenpackager policy is not really fixed, I won't change
any of my packages to allow provenpackager commits. Instead I will even
suggest to close packages in Fedora pkgdb and avoid provenpackager commits.

> I would prefer if someone fix 3 things and break one because I will have  
> to fix only 1 thing not 3 :). And after pointing the problem to the  
> author it won't happen again ( I believe). 

Feel free to allow provenpackager commits for your packages, for mine you
will have to file a bug report, that I can review it and avoid the mistake
you maybe did somewhere when actually try to fix something. Four eyes are
seeing much more than only two do.


Greetings,
  Robert



From rc040203 at freenet.de  Thu Jan 29 09:32:49 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 29 Jan 2009 10:32:49 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <glqo1j$mo6$4@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org>
	<glqmnb$mo6$1@ger.gmane.org>	<4980E0F7.6020507@fedoraproject.org>
	<glqo1j$mo6$4@ger.gmane.org>
Message-ID: <498177C1.2070302@freenet.de>

Kevin Kofler wrote:
> Rahul Sundaram wrote:
>> It appears, most maintainers only have been ignoring the description
>> fields or not filling them properly because of lack of documentation or
>> awareness on how it is being used.
> 
> Some of the replies in these threads don't quite suggest that. People
> complain about the "bureaucracy" of being "forced" to write such stuff,
> which pretty much shows they intentionally do not want to fill in those
> fields and won't do it if they can get away without it.
Not quite, I fill %changelog with with what I consider to be reasonable 
in a particular situation.

... the bureaucracy starts with bodhi.



From akurtako at redhat.com  Thu Jan 29 09:33:30 2009
From: akurtako at redhat.com (Alexander Kurtakov)
Date: Thu, 29 Jan 2009 10:33:30 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129092441.GA15587@hurricane.linuxnetz.de>
References: <20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<1233187708.6562.1.camel@localhost.localdomain>	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>	<1233192357.3509.9.camel@localhost.localdomain>	<20090129072219.GA5712@hurricane.linuxnetz.de>	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
Message-ID: <498177EA.7020607@redhat.com>

Robert Scheck wrote:
> On Thu, 29 Jan 2009, Alexander Kurtakov wrote:
>   
>> Provide a possibility for maintainers to open their package for  
>> ***EVERY*** packager. I would love to do this.  And do you know why?
>> Because I want to see some community growing and people trying to fix  
>> things even if they DO mistakes. How can someone learn if he didn't try  
>> to do it?
>>     
>
> No - no - no. I won't do that.
>
> Too many packagers, even provenpackagers (it don't want to point on latest
> unwanted package touching by provenpackager for example) are "fixing" spec
> files or packages by breaking it afterwards and this never sh all happen.
>
> Fedora is not (or at least shouldn't be) the playground of/for unknowledged
> packagers. And with your suggestion you're trying to make it that.
>
> Ask e.g. the FAS users ixs, cwickert or red about getting packages unwanted
> "fixed" by packagers or even provenpackagers (see Cc:).
>
> As long as our provenpackager policy is not really fixed, I won't change
> any of my packages to allow provenpackager commits. Instead I will even
> suggest to close packages in Fedora pkgdb and avoid provenpackager commits.
>
>   
>> I would prefer if someone fix 3 things and break one because I will have  
>> to fix only 1 thing not 3 :). And after pointing the problem to the  
>> author it won't happen again ( I believe). 
>>     
>
> Feel free to allow provenpackager commits for your packages, for mine you
> will have to file a bug report, that I can review it and avoid the mistake
> you maybe did somewhere when actually try to fix something. Four eyes are
> seeing much more than only two do.
>
>
> Greetings,
>   Robert
>
>   
It is already allowed.
I'm not trying to force you to open your packages but I would love to 
have the same freedom to not be forced to limit the packagers that can 
touch my packages by making provenpackager too restrictive and not 
allowing for packagers that want to open their packages for everyone. 
Don't you think that different packages and packagers have different 
needs and packagers should be able to choose the restrictions for their 
own packages?

Regards,
Alexander Kurtakov



From robert at fedoraproject.org  Thu Jan 29 09:35:37 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 10:35:37 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
Message-ID: <20090129093537.GB15587@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, drago01 wrote:
> Did it ever happen that a "provenpackager" or any packager in the days
> of open ACLs cause any real damage to packages (not owned by him)?
> I am not aware of any such cases, it seems to me that we are trying to
> solve a non existing problem.

Walk with more open eyes and ears through the packager community. And see
my previous e-mail as well. I'm not going to repeat myself any longer, as
things are anyway explicitly ignored, except you really fight for it. This
could be a reason why Thorsten Leemhuis seems to be pissed about Fedora...

And then somebody asks, why I'm not writing nice e-mails all the time. Nice
written e-mails and requests are ignored, only unfriendly thing and making
much noise brings things up (my December 2008 thread or latest epel-devel
thing e.g.).


Greetings,
  Robert



From denis at poolshark.org  Thu Jan 29 09:38:15 2009
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 29 Jan 2009 10:38:15 +0100
Subject: Lack of update information
In-Reply-To: <glqf9m$s29$1@ger.gmane.org>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>	<497F7A2E.90509@poolshark.org>
	<glqf9m$s29$1@ger.gmane.org>
Message-ID: <49817907.503@poolshark.org>

Kevin Kofler wrote:
> Denis Leroy wrote:
>> Below is the ChangeLog of gtkmm-2.15.0, which I pushed to rawhide a
>> while ago. How would you summarize it to Bodhi ?
> 
> Ugh, doesn't upstream provide a more user-readable list of changes? IMHO
> they should get that complaint...

They do actually, they provide the NEWS files which is a bit shorter 
(although this one is unusually long, they're typically 3 to 4 
bullet-point long) :

* CellRendererPixbuf: Added the icon-name and follow-state
   properties, noticed by Mathias Hasselmann.
   (Murray Cumming)
* Printer::enumerate_printers(): Fix a refcounting problem found by Tor 
Krill.
   (Armin Burgmeier)
* Gdk::Window: Added an invalidate() that takes no rect
   parameter because it can be NULL in C.
   (Murray Cumming)
* Cleaned up gtk includes to use only toplevel headers, as may be 
required by
   a future GTK+ version.
   (Przemys?aw Grzegorczyk) Bug #564006
* Container: Use GType instead of GtkType for the  child_type_vfunc() 
return type
   This should allow soure code to use gtkmm if it declares 
GTK_DISABLE_DEPRECATED.
   (Murray Cumming) Bug #562893 (D?nes Faluv?gi)
* Documentation:
   TreeModel: set_value_impl() documentation: Mention row_changed(),
   not set_row_changed(). Bug #562505 (Bohumir Zamecnik)
* HandleBox: Restore the child-attached property, which was lost at some 
point
   during 2.14.
* LinkButton: Resore the visited property definition, which was lost at 
some
   point during 2.14.
   (Murray Cumming)
* CellView, ComboBox, EntryCompletion, IconView: Added unset_model().
   (Alexander Shaduri) Bug #555268



> And it's true that it's particularly hard to summarize bugfixes in a library
> (like that printer signal proxy fix) without knowing a concrete application
> bug they fix.
> 
> In any case, try this:
> 
> Update to the latest upstream release, 2.15.0, which fixes the use of some
> deprecated APIs and header files (which caused programs using gtkmm with
> GTK_DISABLE_DEPRECATED to fail to build) and a bug in the printer signal
> proxy which could cause application crashes (the printer object was being
> unreferenced at an inappropriate place), adds some new APIs which may be
> required to compile new gtkmm-using software:
> * GtkHandleBox::child-attached (signal) and GtkLinkButton::visited
> (property), which were accidentally missing in 2.14.x
> * unset_model() methods for GtkCellView, GtkComboBox, GtkEntryCompletion,
> GtkIconView and GtkTreeView
> * a parameterless version of GtkWindow::invalidate()
> * GtkCellRendererPixbuf::icon-name and GtkCellRendererPixbuf::follow-state
> (properties)
> and includes some minor documentation fixes.
> 
> But I'll admit this took me several minutes to write.

Good job :-) But this whole exercise is futile. We DO ALREADY ship both 
the ChangeLog and the NEWS files in the documentation directory, either 
with the library or development package. How is repeating or summarizing 
these internal changes *on Bodhi* useful to anyone ?

- If you're a gtkmm developper, you will not read the Bodhi information 
as you probably already know about the update already, you'll go 
straight to the NEWS or ChangeLog file shipped with the RPM (or on the 
GNOME FTP site) to see if any of the changes impact your work.

- If you're not a gtkmm developper, the information above is impossible 
to understand and not useful at all. At best you want to know if the 
update is a bugfix update, or what ? not a bugfix update ? new features 
? how is that useful ? If a library update maybe fixes an occasional 
crash in an application that uses it, how can you tell that the problem 
was fixed by "Printer::enumerate_printers(): Fix a refcounting problem" 
? As a Fedora user, how is that information going to affect your 
decision making ? Are you going to decline a package update if the 
summary doesn't include some key words ? (I call BS on anyone answering 
yes to that).

So the concept of summarizing the ChangeLog for Bodhi imposes a heavy 
burden on packagers for little added value.

Don't get me wrong, I'm not saying the "Notes" field in Bodhi is 
useless. First, linking Bodhi updates with bugzilla entries is extremely 
useful to start with. And if you're pushing a user-visible application, 
I'd want to know if this adds some interesting new features to it, no 
doubt. But it'd be easier to have a Bodhi field where one can paste a 
URL pointing to the "News" or "Changes" section of the upstream webiste, 
or linking with the Gnome FTP NEWS file...

-denis



From robert at fedoraproject.org  Thu Jan 29 09:38:52 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 10:38:52 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <498177EA.7020607@redhat.com>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<498177EA.7020607@redhat.com>
Message-ID: <20090129093852.GA20414@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Alexander Kurtakov wrote:
> Don't you think that different packages and packagers have different  
> needs and packagers should be able to choose the restrictions for their  
> own packages?

I don't question that.

But I am not satisfied with how provenpackager currently works at all. And
the last changes or in-queue changes won't solve the issue. That is what I
am claiming about with my provenpackager karma proposal.


Greetings,
  Robert



From mschwendt at gmail.com  Thu Jan 29 09:53:06 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 29 Jan 2009 10:53:06 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <glqo1j$mo6$4@ger.gmane.org>
References: <497F5005.4060107@fedoraproject.org> <glqmnb$mo6$1@ger.gmane.org>
	<4980E0F7.6020507@fedoraproject.org> <glqo1j$mo6$4@ger.gmane.org>
Message-ID: <20090129105306.f05860e1.mschwendt@gmail.com>

On Thu, 29 Jan 2009 00:00:03 +0100, Kevin wrote:

> Rahul Sundaram wrote:
> > It appears, most maintainers only have been ignoring the description
> > fields or not filling them properly because of lack of documentation or
> > awareness on how it is being used.
> 
> Some of the replies in these threads don't quite suggest that. People
> complain about the "bureaucracy" of being "forced" to write such stuff,
> which pretty much shows they intentionally do not want to fill in those
> fields and won't do it if they can get away without it.

Bad summary.

The bureaucracy is in taking away the freedom to fill in the free-form
text field for "Details/Notes" about an update. You want to force
maintainers to fill in more fields, and e.g. require them to hunt for a
link to a changelog web page. As if the regular breakage of %SOURCE URLs
had not shown that such URLs would not be invalidated regularly either.

The thing I'm concerned about is the patronising and dominating behaviour
of the people who want to unleash lots of new rules on maintainers.

Thorsten has hit the nail on its head with his "best practices" comment in
this thread. I also believe in "recommendations" instead of "rules" as
well as in educating package maintainers, who queue questionable
upgrades/updates.



From christoph.wickert at googlemail.com  Thu Jan 29 10:05:03 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 11:05:03 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233214010.19140.10.camel@arekh.okg>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
Message-ID: <1233223503.3514.4.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 08:26 +0100 schrieb Nicolas Mailhot:
> Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a ?crit :
> 
> >       * A font package was approved although it contained another font
> 
> And this was caught in review before the approval and fixed before cvs
> import. So go search your quality problems somewhere else.

Both Sven and me corrected my statement already hours before you wrote
that mail. Please go search the list before posting.

To clarify: I have no problems with "fix that before import" in general,
but IMHO for a wrong source it's something different, because a lot of
things can not be checked or the checks are useless.

Regards,
Christoph



From markmc at redhat.com  Thu Jan 29 10:08:04 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 29 Jan 2009 10:08:04 +0000
Subject: Lack of update information
In-Reply-To: <49817907.503@poolshark.org>
References: <497D6B24.8050702@fedoraproject.org>
	<20090126120202.GA2548@free.fr>
	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>
	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>
	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org>	<497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>	<497F7A2E.90509@poolshark.org>
	<glqf9m$s29$1@ger.gmane.org>  <49817907.503@poolshark.org>
Message-ID: <1233223684.6470.48.camel@blaa>

On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> ...
> > a bug in the printer signal
> > proxy which could cause application crashes (the printer object was being
> > unreferenced at an inappropriate place),
...

> Good job :-) But this whole exercise is futile. We DO ALREADY ship both 
> the ChangeLog and the NEWS files in the documentation directory, either 
> with the library or development package. How is repeating or summarizing 
> these internal changes *on Bodhi* useful to anyone ?

Kevin's summary does something the NEWS file does not - it calls out a
particular crasher bug that could affect user applications. IMHO, that
is the only truly compelling reason a user has to apply this update and
it is the most user relevant part of Kevin's description.

> As a Fedora user, how is that information going to affect your 
> decision making ? Are you going to decline a package update if the 
> summary doesn't include some key words ? (I call BS on anyone
> answering yes to that).

It's a fair point that not many users would decline the update just
because it doesn't fix a bug which affects them. It's not so much about
decision making, it's about having some explanation as to why the update
is important.

If PackageKit pops up tells you there are 50 updates pending, it's much
nicer if you can scan through the descriptions and come away with the
conclusion that "oh, there's a bunch of important fixes in there" rather
than "this is just a bunch of gratuitous updates, but if I don't apply
them all I might miss something important".

Cheers,
Mark.



From nicolas.mailhot at laposte.net  Thu Jan 29 10:09:51 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 11:09:51 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233223503.3514.4.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
Message-ID: <1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 11:05, Christoph Wickert a ?crit :
>
> Am Donnerstag, den 29.01.2009, 08:26 +0100 schrieb Nicolas Mailhot:
>> Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a ?crit
>> :
>>
>> >       * A font package was approved although it contained another
>> font
>>
>> And this was caught in review before the approval and fixed before
>> cvs
>> import. So go search your quality problems somewhere else.
>
> Both Sven and me corrected my statement already hours before you wrote
> that mail. Please go search the list before posting.
>
> To clarify: I have no problems with "fix that before import" in
> general,
> but IMHO for a wrong source it's something different, because a lot of
> things can not be checked or the checks are useless.

Why do you assume I didn't check the correct source before approval?

-- 
Nicolas Mailhot



From mschwendt at gmail.com  Thu Jan 29 10:11:40 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Thu, 29 Jan 2009 11:11:40 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233144888.13111.1.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>
	<49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
Message-ID: <20090129111140.654efe7a.mschwendt@gmail.com>

On Wed, 28 Jan 2009 12:14:48 +0000, Mark wrote:

> Okay, here's an attempt:
> 
>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 
> Cheers,
> Mark.

> = Package Update Guidelines =

> == Maintaining Stability ==

> == Update Descriptions ==

> == Rate of Updates ==

Much better, an effort much appreciated, although this is way beyond
the subject of this thread. ;) Such a document goes into the right
direction, since it tries to explain Fedora's fundamental update
strategy and may come as a surprise to some packagers. It will be very
interesting to hear what FESCo members think about the contents.



From christoph.wickert at googlemail.com  Thu Jan 29 10:18:24 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 11:18:24 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
Message-ID: <1233224304.3514.14.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 08:55 +0100 schrieb drago01:

> Did it ever happen that a "provenpackager" or any packager in the days
> of open ACLs cause any real damage to packages (not owned by him)?
> I am not aware of any such cases, it seems to me that we are trying to
> solve a non existing problem.

I do recall a case where a proven packager wanted to fix something in
one of my packages but made an error that needed to be reverted by
another proven packager an hour later. I don't know if you call this
"real damage", but it shows that proven packagers are not perfect.

Regards,
Christoph





From christoph.wickert at googlemail.com  Thu Jan 29 10:20:45 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 11:20:45 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
Message-ID: <1233224445.3514.18.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 11:09 +0100 schrieb Nicolas Mailhot:
> 
> Le Jeu 29 janvier 2009 11:05, Christoph Wickert a ?crit :
> >
> > Am Donnerstag, den 29.01.2009, 08:26 +0100 schrieb Nicolas Mailhot:
> >> Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a ?crit
> >> :
> >>
> >> >       * A font package was approved although it contained another
> >> font
> >>
> >> And this was caught in review before the approval and fixed before
> >> cvs
> >> import. So go search your quality problems somewhere else.
> >
> > Both Sven and me corrected my statement already hours before you wrote
> > that mail. Please go search the list before posting.
> >
> > To clarify: I have no problems with "fix that before import" in
> > general,
> > but IMHO for a wrong source it's something different, because a lot of
> > things can not be checked or the checks are useless.
> 
> Why do you assume I didn't check the correct source before approval?

You might have checked the source, but how do you compare it's md5 to
something that's not there? Or how do you compare the timestamp of the
source in the SRPM, if it's not there?

Regards,
Christoph



From denis at poolshark.org  Thu Jan 29 10:25:26 2009
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 29 Jan 2009 11:25:26 +0100
Subject: Lack of update information
In-Reply-To: <1233223684.6470.48.camel@blaa>
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<497E503C.8090400@poolshark.org>	<glmjkr$uvt$3@ger.gmane.org>	<497F7A2E.90509@poolshark.org>	<glqf9m$s29$1@ger.gmane.org>
	<49817907.503@poolshark.org> <1233223684.6470.48.camel@blaa>
Message-ID: <49818416.70601@poolshark.org>

Mark McLoughlin wrote:
> It's a fair point that not many users would decline the update just
> because it doesn't fix a bug which affects them. It's not so much about
> decision making, it's about having some explanation as to why the update
> is important.

If it's a bugfix release, it's important. period. Bodhi has a combobox 
that specifies that. Whether the bug fix will affect a particular user 
or not if nearly impossible to determine.

> If PackageKit pops up tells you there are 50 updates pending, it's much
> nicer if you can scan through the descriptions and come away with the
> conclusion that "oh, there's a bunch of important fixes in there" rather
> than "this is just a bunch of gratuitous updates, but if I don't apply
> them all I might miss something important".

The necessary vs unnecessary update is a completely different problem, 
although it's also addressed by the draft and that's causing an 
overreaction on the documentation side. I'm pretty sure everyone agrees 
that updates to stable releases should be picked carefully by packagers.


-denis



From fedora at leemhuis.info  Thu Jan 29 10:26:00 2009
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Thu, 29 Jan 2009 11:26:00 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <20090129111140.654efe7a.mschwendt@gmail.com>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>
	<20090129111140.654efe7a.mschwendt@gmail.com>
Message-ID: <49818438.7040409@leemhuis.info>

On 29.01.2009 11:11, Michael Schwendt wrote:
> On Wed, 28 Jan 2009 12:14:48 +0000, Mark wrote:
>> Okay, here's an attempt:
>>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> [...]
> Much better, an effort much appreciated, although this is way beyond
> the subject of this thread. ;) 

That's what I thought as well. The fist draft from Rahul was more a 
"what information to add to bodhi updates request"; this one also 
touches "Maintaining Stability".

And it does so without answering the question properly. So it will 
continue as now: Some maintainers will use a debian-like style, others 
more a rolling-release style. That's a bit confusing from a users point 
of view.

> Such a document goes into the right
> direction, since it tries to explain Fedora's fundamental update
> strategy and may come as a surprise to some packagers. It will be very
> interesting to hear what FESCo members think about the contents.

+1

CU
knurd



From berrange at redhat.com  Thu Jan 29 10:31:57 2009
From: berrange at redhat.com (Daniel P. Berrange)
Date: Thu, 29 Jan 2009 10:31:57 +0000
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <1233205271.8363.258.camel@localhost.localdomain>
References: <1233205271.8363.258.camel@localhost.localdomain>
Message-ID: <20090129103157.GB22110@redhat.com>

On Wed, Jan 28, 2009 at 09:01:11PM -0800, Jesse Keating wrote:
> I've committed code to pungi that will prevent boot.iso from being on
> CD1 and the DVD.  I've had various discussions with folks about this in
> the past, and given that boot.iso is 122M on x86_64 that's a lot of
> packages we could have instead.  In the past, boot.iso was much smaller
> and it wasn't a big cost, things have changed.
> 
> If anybody has a really good reason for why we should continue to put
> boot.iso on the media, speak now.

We still have the kernel+initrd for pxeboot on the CD1/DVD, right ? If
so, then killing boot.iso from the CD1/DVD image shouldn't any problem 
for the virt provisioning tools POV.

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 nicolas.mailhot at laposte.net  Thu Jan 29 10:40:16 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 11:40:16 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233224445.3514.18.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
Message-ID: <7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 11:20, Christoph Wickert a ?crit :
>
> Am Donnerstag, den 29.01.2009, 11:09 +0100 schrieb Nicolas Mailhot:
>>
>> Le Jeu 29 janvier 2009 11:05, Christoph Wickert a ?crit :
>> >
>> > Am Donnerstag, den 29.01.2009, 08:26 +0100 schrieb Nicolas
>> Mailhot:
>> >> Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a
>> ?crit
>> >> :
>> >>
>> >> >       * A font package was approved although it contained
>> another
>> >> font
>> >>
>> >> And this was caught in review before the approval and fixed
>> before
>> >> cvs
>> >> import. So go search your quality problems somewhere else.
>> >
>> > Both Sven and me corrected my statement already hours before you
>> wrote
>> > that mail. Please go search the list before posting.
>> >
>> > To clarify: I have no problems with "fix that before import" in
>> > general,
>> > but IMHO for a wrong source it's something different, because a
>> lot of
>> > things can not be checked or the checks are useless.
>>
>> Why do you assume I didn't check the correct source before approval?
>
> You might have checked the source, but how do you compare it's md5 to
> something that's not there? Or how do you compare the timestamp of the
> source in the SRPM, if it's not there?

I actually knew the exact file source Sven would use because he had
packaged a related font from the same upstream two days before. So
please stop using this review as example of whatever you want to prove
and move along.

If you want to do something useful, I have a pile of packaging changes
in my review queue I'd be happy to pass on to someone obcessing about
review quality in Fedora.

-- 
Nicolas Mailhot



From christoph.wickert at googlemail.com  Thu Jan 29 10:48:57 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 11:48:57 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49810FFD.5000106@behdad.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
Message-ID: <1233226137.3514.32.camel@wicktop.localdomain>

Am Mittwoch, den 28.01.2009, 21:10 -0500 schrieb Behdad Esfahbod:
> Robert Scheck wrote:
> > But mostly the Red Hat guys are lacking massive
> > RPM knowledge and ignore Guidelines [snip].
> 
> Can we please be done with this kind of blanket statements as well as "Red Hat
> vs the community" comments?  They are derogatory, demoralizing, and border on
> offensive.  And after the third time, simply frustrating.  Red Hat has some of
> the best engineers in the world, perhaps some of the worst if you wish, and
> most probably a lot of average ones.  So what?

I think what Robert and me wanted to express is: It's not only that some
(!) people from RH do not follow the guidelines but some also explicitly
refuse to follow them even after they were told them what's wrong. I
have no explanation for that kind of behavior but arrogance. 

> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
> held from the Core days.  

Agreed, but we've had merge reviews with proposals for enhancements and
fixes that did not get applied by the owner. I have never ever seen this
from a community member. If someone did, his review request would be
closed "WONTFIX" pretty soon, but this isn't possible for merge reviews.

> Unfortunately (for us "Red Hat guys") most Core
> packages were simply thrown upon us as part of our job.  I would never
> *volunteer* to do packaging, as that's not what I'm best at.  

Does that mean you are expecting someone who volunteers for something to
do it better than someone who has do to it because he get's paid for? I
can not follow that argument and I doubt your employer will.

> If someone wants
> to go ahead and take maintainership of all my packages, I very well appreciate
> it.  I'm sure many other "Red Hat guys" are in the same boat.

This is what I call a constructive suggestion. ;)

Regards,
Christoph

> behdad
> proud Red Hat employee, poor package maintainer, RPM n00b.




From christoph.wickert at googlemail.com  Thu Jan 29 10:58:54 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 11:58:54 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233192357.3509.9.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
Message-ID: <1233226734.3514.39.camel@wicktop.localdomain>

Am Mittwoch, den 28.01.2009, 20:25 -0500 schrieb Brian Pepple:

> This is all a moot point now though, since a couple of weeks ago FESCo
> approved a proposal to reset the initial seeding of the provenpackager
> group with Packaging Sponsors, and Jesse has made a proposal(1) on
> guidelines for approving someone to the provenpackager group.
> 
>      1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
> 

IMO this is not a moot point at all, because even after the group was
reset, there are people in there that I don't want to see there.

For example I just found out that one of the people I sponsor is proven
packager. Of course I do trust him, otherwise I would not have sponsored
him, but I doubt that 2 packages (!) and 3 months of experience are
enough for a proven packager.

This shows that Jesse's proposal is pretty much useless, because it is
weaker then the previous set of rules, no matter if it was 5 or 8
packages.

> Later,
> /B

Regards,
Christoph



From pvrabec at redhat.com  Thu Jan 29 11:19:43 2009
From: pvrabec at redhat.com (Peter Vrabec)
Date: Thu, 29 Jan 2009 12:19:43 +0100
Subject: what requires fedora-release-notes
In-Reply-To: <20090128222404.GD5735@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<1233169541.8363.234.camel@localhost.localdomain>
	<20090128222404.GD5735@localhost.localdomain>
Message-ID: <200901291219.43434.pvrabec@redhat.com>

thnx. folks,

I have filed two bugs:

1. don't require fedora-release-notes in fedora-release
https://bugzilla.redhat.com/show_bug.cgi?id=483018

2. install fedora-release-notes vie "base" group
https://bugzilla.redhat.com/show_bug.cgi?id=483019

On Wednesday 28 January 2009 11:24:04 pm Paul W. Frields wrote:
> On Wed, Jan 28, 2009 at 11:05:41AM -0800, Jesse Keating wrote:
> > On Wed, 2009-01-28 at 13:50 -0500, Paul W. Frields wrote:
> > > On Wed, Jan 28, 2009 at 10:03:06AM -0800, Jesse Keating wrote:
> > > > On Wed, 2009-01-28 at 19:02 +0100, Daniel Mach wrote:
> > > > > Jesse, is there any important data in this package which needs to
> > > > > be shipped in Fedora at any cost?
> > > > > I can imagine some legal or licensing information about Fedora.
> > > >
> > > > I don't believe so.
> > >
> > > The arguable value of the "About Fedora" item -- which as some Desktop
> > > team members have noted, probably needs to be revamped -- is certainly
> > > not enough to keep it.  It would be prudent and probably good manners
> > > to alert the Docs team about contemplating dropping this, too.
> >
> > Well, we would make it a default install item via groupings, but perhaps
> > not /forced/ install, so that one could remove it/opt out of installing
> > it should they wish.
>
> Thanks for clarifying this.




From robert at fedoraproject.org  Thu Jan 29 11:21:27 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 12:21:27 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233226137.3514.32.camel@wicktop.localdomain>
References: <20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
Message-ID: <20090129112127.GA30483@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Christoph Wickert wrote:
> I think what Robert and me wanted to express is: It's not only that some
> (!) people from RH do not follow the guidelines but some also explicitly
> refuse to follow them even after they were told them what's wrong. I
> have no explanation for that kind of behavior but arrogance. 

Right, thank you for clarifying this again.

> Agreed, but we've had merge reviews with proposals for enhancements and
> fixes that did not get applied by the owner. I have never ever seen this
> from a community member. If someone did, his review request would be
> closed "WONTFIX" pretty soon, but this isn't possible for merge reviews.

Well, there are even some (!) Red Hat people, that tried it that way (via
"WONTFIX"/"NOTABUG") for the Merge Reviews, AFAIK all such actions have
been reverted by the Fedora Community. Bugzilla is maybe tracking that...


Greetings,
  Robert 



From bpepple at fedoraproject.org  Thu Jan 29 11:22:57 2009
From: bpepple at fedoraproject.org (Brian Pepple)
Date: Thu, 29 Jan 2009 06:22:57 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233226734.3514.39.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
Message-ID: <1233228177.2769.1.camel@localhost.localdomain>

On Thu, 2009-01-29 at 11:58 +0100, Christoph Wickert wrote:
> Am Mittwoch, den 28.01.2009, 20:25 -0500 schrieb Brian Pepple:
> 
> > This is all a moot point now though, since a couple of weeks ago FESCo
> > approved a proposal to reset the initial seeding of the provenpackager
> > group with Packaging Sponsors, and Jesse has made a proposal(1) on
> > guidelines for approving someone to the provenpackager group.
> > 
> >      1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
> > 
> 
> IMO this is not a moot point at all, because even after the group was
> reset, there are people in there that I don't want to see there.
> 
> For example I just found out that one of the people I sponsor is proven
> packager. Of course I do trust him, otherwise I would not have sponsored
> him, but I doubt that 2 packages (!) and 3 months of experience are
> enough for a proven packager.

Umm, it is moot, since the *reset* hasn't actually occurred yet.  If the
person your referring to, isn't a Package sponsor he will not be a
provenpackager in the reseed.

Later,
/B
-- 
Brian Pepple <bpepple at fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/98b7aaa1/attachment.sig>

From behdad at behdad.org  Thu Jan 29 11:25:22 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Jan 2009 06:25:22 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233226137.3514.32.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
Message-ID: <49819222.10602@behdad.org>

Christoph Wickert wrote:
> Am Mittwoch, den 28.01.2009, 21:10 -0500 schrieb Behdad Esfahbod:
>> Robert Scheck wrote:
>>> But mostly the Red Hat guys are lacking massive
>>> RPM knowledge and ignore Guidelines [snip].
>> Can we please be done with this kind of blanket statements as well as "Red Hat
>> vs the community" comments?  They are derogatory, demoralizing, and border on
>> offensive.  And after the third time, simply frustrating.  Red Hat has some of
>> the best engineers in the world, perhaps some of the worst if you wish, and
>> most probably a lot of average ones.  So what?
> 
> I think what Robert and me wanted to express is: It's not only that some
> (!) people from RH do not follow the guidelines but some also explicitly
> refuse to follow them even after they were told them what's wrong. I
> have no explanation for that kind of behavior but arrogance. 

I have a very unpleasant experience with a community maintainer over a package
we co-maintained and that I'm the upstream.  Do I extrapolate that to all
non-RH people?  No.  Stop discriminating already.  If an RH person doesn't
follow Fedora rules and guidelines, follow the standard Fedora procedures to
deal with them.  Stop whining.  Please.


>> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
>> held from the Core days.  
> 
> Agreed, but we've had merge reviews with proposals for enhancements and
> fixes that did not get applied by the owner. I have never ever seen this
> from a community member. If someone did, his review request would be
> closed "WONTFIX" pretty soon, but this isn't possible for merge reviews.

Sure.  That's a problem with the merge review procedure perhaps?  Definitely
not something to blame the poor RH developer for.  I still have many merge
reviews unresolved.  Am I blocking them?  Hell no.  Go ahead and complete
them.  I'll give you full maintainership if you need.  As I said a couple
months ago, just because I work for Red Hat doesn't mean Fedora procedures get
to decide what I work on.


>> Unfortunately (for us "Red Hat guys") most Core
>> packages were simply thrown upon us as part of our job.  I would never
>> *volunteer* to do packaging, as that's not what I'm best at.  
> 
> Does that mean you are expecting someone who volunteers for something to
> do it better than someone who has do to it because he get's paid for? I
> can not follow that argument and I doubt your employer will.

If I don't like what I'm doing, I'll do a very shitty job at it.  If I
wouldn't volunteer for something, chances are high that I don't like it.  My
manager and my employer fully understand those two facts.


>> If someone wants
>> to go ahead and take maintainership of all my packages, I very well appreciate
>> it.  I'm sure many other "Red Hat guys" are in the same boat.
> 
> This is what I call a constructive suggestion. ;)

Now wait and see how much real change that makes.  That's the problem...

behdad


> Regards,
> Christoph
> 
>> behdad
>> proud Red Hat employee, poor package maintainer, RPM n00b.



From debarshi.ray at gmail.com  Thu Jan 29 11:30:32 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 29 Jan 2009 17:00:32 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233226137.3514.32.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
Message-ID: <3170f42f0901290330m33de6427m5bc8d931bbbd603a@mail.gmail.com>

>> Can we please be done with this kind of blanket statements as well as "Red Hat
>> vs the community" comments?  They are derogatory, demoralizing, and border on
>> offensive.  And after the third time, simply frustrating.  Red Hat has some of
>> the best engineers in the world, perhaps some of the worst if you wish, and
>> most probably a lot of average ones.  So what?

> I think what Robert and me wanted to express is: It's not only that some
> (!) people from RH do not follow the guidelines but some also explicitly
> refuse to follow them even after they were told them what's wrong. I
> have no explanation for that kind of behavior but arrogance.

Quite true. Recently I did a merge review [1] where among other things
I mentioned the absense of %{?_smp_flags} while building the package.
The owner fixed most of the things but just left it out saying that he
can not be bothered about such irrelevant things. I do not know about
its relevance, but there is another merge review [2] where shared
libraries are being installed without invoking ldconfig, and the
maintainer does not care to respond even a month even though I
provided a patch to fix most of the issues.

Happy hacking,
Debarshi
----
[1] https://bugzilla.redhat.com/225852
[2] https://bugzilla.redhat.com/225865



From behdad at behdad.org  Thu Jan 29 11:38:45 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Jan 2009 06:38:45 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129073446.GB5712@hurricane.linuxnetz.de>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
Message-ID: <49819545.5010604@behdad.org>

Robert Scheck wrote:
> On Wed, 28 Jan 2009, Behdad Esfahbod wrote:
>> Can we please be done with this kind of blanket statements as well as "Red Hat
>> vs the community" comments?  They are derogatory, demoralizing, and border on
>> offensive.  And after the third time, simply frustrating.  Red Hat has some of
>> the best engineers in the world, perhaps some of the worst if you wish, and
>> most probably a lot of average ones.  So what?
> 
> Such comparisons must happen. And if you would have read my mail correctly
> or even checked what I'm saying, you would have seen, that my examples with
> the Merge Reviews are true. In that cases it was even blocking/refusing the
> Merge Reviews (or parts of it) - the old story from my December 2008 mail.

One of my complaints was against blanket statements.  Sure you may have
positive samples of 1, 10, or even 100 Red Hat employees misbehaving.  That
does NOT extend to all Red Hat employees.  Avoid blanket statements.  Avoid
discriminating.  If someone's violating something, point that out,
specifically, and politely.


> When looking e.g. to ethtool, the maintainer was allowed, not to show up
> ever on the Merge Review, once I asked Tom Callaway to give him a clout. As
> co-maintainer, I've solved the Merge Review, fixed all open bug reports the
> maintainer did not take care about, but I can't co-maintain every package.
> The ethtool maintainer being upstream as well, did after Tom's clout only
> one time reply to my e-mails and to a bug report. So one time in ~ 6 years,
> that's neither a good behaviour for a downstream maintainer, nor even for
> an upstream one. And when talking in #fedora-devel, I got told, that I am
> not alone with this issue.

So what?  There's this small package that I co-maintain.  I'm upstream for
(hint, it's the only upstream package I originally wrote).  My co-maintainer
originally got it in Fedora.  He got past the reviews, he went over the Debian
patches and cherry-picked them for Fedora, and was generally very nice,
helpful, and a very good packager.  Then one day I released a new version of
the package upstream, and it happened to bring machines down under certain
circumstances.  I didn't know.  He didn't know.  I pushed the package in
Rawhide.  Against my will, he pushed the package in F-9 and F-8
updates-testing.  When it became clear that the package eats babies I
desperately asked him to retract the updates.  He stopped responding and as
far as I know he disappeared from Fedora.  I did whatever I could to retract
those updates.  They escalated from updates-testing to updates.  Bug reports
poured in.  I filed bugs against rel-eng.  Etc, etc.

Do I walk around saying "all community guys are irresponsible"?  No.


>> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
>> held from the Core days.  Unfortunately (for us "Red Hat guys") most Core
>> packages were simply thrown upon us as part of our job.  I would never
>> *volunteer* to do packaging, as that's not what I'm best at.  If someone wants
>> to go ahead and take maintainership of all my packages, I very well appreciate
>> it.  I'm sure many other "Red Hat guys" are in the same boat.
> 
> Taking co-maintainship or even the package doesn't solve 'em all, as I
> pointed out above already. If the "Red Hat guy" is upstream of software,
> it's more hard to work around.

Why's that?  I don't understand.  Now you're attacking the upstream
maintainers too?


>> proud Red Hat employee, poor package maintainer, RPM n00b.
> 
> Last of it could be easily solved by getting a RPM training, isn't there a
> training department inhouse of your employer?

I'm smart enough to not need training.  I can train myself.  The question is,
should I learn RPM?  I don't think so.  My time is better spent doing upstream
work.  As I've been saying repeatedly, RPM is not my (and many "RH guys"')
strength, and I'm honest about it.  I know how to update my packages to the
new version of the upstream package I just released.  And I hope you don't
have any problem with that.  For anything more complicated, I'd be happy to
let more experienced Fedora packages jump in.  Such collaboration has happened
between me and Nicolas Mailhot already.  He oversees font packaging, and I fix
upstream issues he wants to see fixed.  That's constructive IMO.

Cheers,
behdad

> Greetings,
>   Robert



From debarshi.ray at gmail.com  Thu Jan 29 11:40:36 2009
From: debarshi.ray at gmail.com (Debarshi Ray)
Date: Thu, 29 Jan 2009 17:10:36 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49810FFD.5000106@behdad.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
Message-ID: <3170f42f0901290340h1fd43aesf5c0d9d0c01ccb86@mail.gmail.com>

> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
> held from the Core days.  Unfortunately (for us "Red Hat guys") most Core
> packages were simply thrown upon us as part of our job.  I would never
> *volunteer* to do packaging, as that's not what I'm best at.  If someone wants
> to go ahead and take maintainership of all my packages, I very well appreciate
> it.  I'm sure many other "Red Hat guys" are in the same boat.

Maybe you could drop a mail on the fedora-devel-list listing the names
of the packages that you want to give up and solicit for new owners.
That is the process usually people have adopted in the past.

Cheerio,
Debarshi



From robert at fedoraproject.org  Thu Jan 29 11:42:52 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 12:42:52 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49819222.10602@behdad.org>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
	<49819222.10602@behdad.org>
Message-ID: <20090129114252.GA32459@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Behdad Esfahbod wrote:
> Sure.  That's a problem with the merge review procedure perhaps?  Definitely
> not something to blame the poor RH developer for.  I still have many merge
> reviews unresolved.  Am I blocking them?  Hell no.  Go ahead and complete
> them.  I'll give you full maintainership if you need.  As I said a couple
> months ago, just because I work for Red Hat doesn't mean Fedora procedures get
> to decide what I work on.

You are not blocking them, if you do nothing. But you would block them, if
you would refuse suggestions or pointings to the Guidelines. There were
(are?) reviews, where a patch and/or a full formal review has been done,
but the maintainer never has shown up or just told "no, I won't do that, I
am upstream". That is blocking and/or refusing. I mentioned examples for
exactly such cases in my previous e-mails and Paul is also aware of them
(at least he was, when I told him that 6 months ago).

I know, that I can't expect, that package maintainers of Merge Reviews are
asking to get reviewed, but blocking/refusing it never should happen. Okay,
I've one single lonely Red Hat guy on my todo list, asking by himself to
get his packages reviewed and done. But that was the single exception I've
seen until now (a very positive one).

I'm still very happy, if a maintainer of a package being in Merge Review is
performing the suggested changes, maybe discussing or coming up with ideas.
And as Merge Reviews are mostly Red Hat-related (by history), we're blaming
usually Red Hat people, yes. Shall we blame Fedora people instead? ;-)


Greetings,
  Robert



From behdad at behdad.org  Thu Jan 29 11:45:05 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Jan 2009 06:45:05 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <3170f42f0901290340h1fd43aesf5c0d9d0c01ccb86@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>
	<3170f42f0901290340h1fd43aesf5c0d9d0c01ccb86@mail.gmail.com>
Message-ID: <498196C1.1000505@behdad.org>

Debarshi Ray wrote:
>> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
>> held from the Core days.  Unfortunately (for us "Red Hat guys") most Core
>> packages were simply thrown upon us as part of our job.  I would never
>> *volunteer* to do packaging, as that's not what I'm best at.  If someone wants
>> to go ahead and take maintainership of all my packages, I very well appreciate
>> it.  I'm sure many other "Red Hat guys" are in the same boat.
> 
> Maybe you could drop a mail on the fedora-devel-list listing the names
> of the packages that you want to give up and solicit for new owners.
> That is the process usually people have adopted in the past.

I'm not actively seeking giving away my packages.  I'm fine with them as long
as they don't demand too much time from me.  But I'll just hand them off as
soon as a Fedora contributor shows up and wants to make non-trivial changes in
them.  That's for example how I handed some of my font packages to Nicolas, or
my entire ogg vorbis stack to Hans.  The point being: I am no the bottleneck /
problem / ... with these packages.  The same holds true about many other
ex-core packages and RH "guys".  Just stop attacking us.

Cheers,
behdad

> Cheerio,
> Debarshi



From ivazqueznet at gmail.com  Thu Jan 29 11:46:23 2009
From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams)
Date: Thu, 29 Jan 2009 06:46:23 -0500
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <1233205271.8363.258.camel@localhost.localdomain>
References: <1233205271.8363.258.camel@localhost.localdomain>
Message-ID: <1233229584.1025.87.camel@ignacio.lan>

On Wed, 2009-01-28 at 21:01 -0800, Jesse Keating wrote:
> If anybody has a really good reason for why we should continue to put
> boot.iso on the media, speak now.

Really, the only use case left is people without functioning DVD drives
and little or no Internet access that accidentally download the DVD or
get it from someone/somewhere else. Everyone else already either has the
appropriate media, or can download the net install image.

-- 
Ignacio Vazquez-Abrams <ivazqueznet at gmail.com>

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: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/ea550070/attachment.sig>

From behdad at behdad.org  Thu Jan 29 11:48:22 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Jan 2009 06:48:22 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129114252.GA32459@hurricane.linuxnetz.de>
References: <1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<1233226137.3514.32.camel@wicktop.localdomain>	<49819222.10602@behdad.org>
	<20090129114252.GA32459@hurricane.linuxnetz.de>
Message-ID: <49819786.6030706@behdad.org>

Robert Scheck wrote:

> You are not blocking them, if you do nothing. But you would block them, if
> you would refuse suggestions or pointings to the Guidelines. There were
> (are?) reviews, where a patch and/or a full formal review has been done,
> but the maintainer never has shown up or just told "no, I won't do that, I
> am upstream". That is blocking and/or refusing. I mentioned examples for
> exactly such cases in my previous e-mails and Paul is also aware of them
> (at least he was, when I told him that 6 months ago).

Well, that just makes no sense.  In those cases you should follow up with
Fedora leadership to resolve it.  All I'm asking you is to NOT extend that to
all "RH guys" (that expression is sexist btw).

behdad



From thomas.moschny at gmail.com  Thu Jan 29 11:53:05 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 29 Jan 2009 12:53:05 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
Message-ID: <a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>

2009/1/29 Nicolas Mailhot <nicolas.mailhot at laposte.net>:

>>> Why do you assume I didn't check the correct source before approval?
>>
>> You might have checked the source, but how do you compare it's md5 to
>> something that's not there? Or how do you compare the timestamp of the
>> source in the SRPM, if it's not there?
>
> I actually knew the exact file source Sven would use because he had
> packaged a related font from the same upstream two days before.

No one is really doubting that. But, it's all about *documenting* what
you did (and what you didn't) in the review. That's the most important
reason for the existence of a a review ticket at all.

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From jonathan.underwood at gmail.com  Thu Jan 29 12:06:27 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 12:06:27 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <1233212932.19140.6.camel@arekh.okg>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
Message-ID: <645d17210901290406p2864b236udff26436684b7c99@mail.gmail.com>

2009/1/29 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Le jeudi 29 janvier 2009 ? 00:51 +0100, Kevin Kofler a ?crit :
>> Tom "spot" Callaway wrote:
>> > I'd have to say the chances of this are extremely unlikely. I'm much
>> > more inclined to propose that we drop texlive altogether.
>>
>> No TeX? That would make Fedora pretty much useless for Mathematics and
>> anything related!
>>
>> If concrete licensing issues are found by somebody, of course those need to
>> be addressed, but dropping all of TeX on the ground that it's too hard to
>> audit is a horribly bad idea.
>
> People who want TEX kept should create a task force and feed TEXlive
> 2008 in rawhide bit by bit, checking for each bit the licensing is ok.
> That's about the only way the burden of checking TEX can be distributed
> enough it won't depend on a couple packagers, when the amount of work is
> too much to be humanly doable by a few people alone in a realistic
> timeframe.
>
> Our curent TEX packaging would be similar to try to package 80% of CPAN
> in a single source package. Of course people crap out when they try to
> check licensing correctly (and TEX stuff has more licensing variability
> than Perl)

I have actually been spending a chunk of time looking carefully at the
way in which TeXlive is put together from the various upstreams to see
if we can't do better than taking the monolthic tarball dumps of
texlive as we have in the past. To say that the way the bits and
pieces of TeX are put together is a horrific mess is an
understatement. However, there is some hope. Forefront in my mind is
that we do want to capitalise on the integration work that is done by
texlive, as we don't have the manpower to reproduce that effort. On
the other hand we want something much better integrated and modular
than texlive presently provides for distribution packaging. At the
moment though, I only have time to work on this at weekends, so
progress so far has been slow, and has been entirely learning.

J.



From pertusus at free.fr  Thu Jan 29 12:11:16 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 29 Jan 2009 13:11:16 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <645d17210901290406p2864b236udff26436684b7c99@mail.gmail.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<645d17210901290406p2864b236udff26436684b7c99@mail.gmail.com>
Message-ID: <20090129121116.GC2999@free.fr>

On Thu, Jan 29, 2009 at 12:06:27PM +0000, Jonathan Underwood wrote:
> 
> I have actually been spending a chunk of time looking carefully at the
> way in which TeXlive is put together from the various upstreams to see
> if we can't do better than taking the monolthic tarball dumps of
> texlive as we have in the past. To say that the way the bits and
> pieces of TeX are put together is a horrific mess is an
> understatement. However, there is some hope. Forefront in my mind is
> that we do want to capitalise on the integration work that is done by
> texlive, as we don't have the manpower to reproduce that effort. On
> the other hand we want something much better integrated and modular
> than texlive presently provides for distribution packaging. At the
> moment though, I only have time to work on this at weekends, so
> progress so far has been slow, and has been entirely learning.

Jindrich has done some work on extracting dependency information from 
individual texlive packages. I don't know where this stands now.

--
Pat



From jonathan.underwood at gmail.com  Thu Jan 29 12:15:26 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 12:15:26 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090129121116.GC2999@free.fr>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<645d17210901290406p2864b236udff26436684b7c99@mail.gmail.com>
	<20090129121116.GC2999@free.fr>
Message-ID: <645d17210901290415n7378a5cbwd6e7981fe657289e@mail.gmail.com>

2009/1/29 Patrice Dumas <pertusus at free.fr>:
> On Thu, Jan 29, 2009 at 12:06:27PM +0000, Jonathan Underwood wrote:
>>
>> I have actually been spending a chunk of time looking carefully at the
>> way in which TeXlive is put together from the various upstreams to see
>> if we can't do better than taking the monolthic tarball dumps of
>> texlive as we have in the past. To say that the way the bits and
>> pieces of TeX are put together is a horrific mess is an
>> understatement. However, there is some hope. Forefront in my mind is
>> that we do want to capitalise on the integration work that is done by
>> texlive, as we don't have the manpower to reproduce that effort. On
>> the other hand we want something much better integrated and modular
>> than texlive presently provides for distribution packaging. At the
>> moment though, I only have time to work on this at weekends, so
>> progress so far has been slow, and has been entirely learning.
>
> Jindrich has done some work on extracting dependency information from
> individual texlive packages. I don't know where this stands now.

Yes, have looked at that... very useful. However, I am wondering if we
should really be working from the texlive tree.



From stickster at gmail.com  Thu Jan 29 13:10:32 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Thu, 29 Jan 2009 08:10:32 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49819786.6030706@behdad.org>
References: <1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
	<49819222.10602@behdad.org>
	<20090129114252.GA32459@hurricane.linuxnetz.de>
	<49819786.6030706@behdad.org>
Message-ID: <20090129131032.GC27203@localhost.localdomain>

On Thu, Jan 29, 2009 at 06:48:22AM -0500, Behdad Esfahbod wrote:
> Robert Scheck wrote:
> 
> > You are not blocking them, if you do nothing. But you would block them, if
> > you would refuse suggestions or pointings to the Guidelines. There were
> > (are?) reviews, where a patch and/or a full formal review has been done,
> > but the maintainer never has shown up or just told "no, I won't do that, I
> > am upstream". That is blocking and/or refusing. I mentioned examples for
> > exactly such cases in my previous e-mails and Paul is also aware of them
> > (at least he was, when I told him that 6 months ago).
> 
> Well, that just makes no sense.  In those cases you should follow up with
> Fedora leadership to resolve it. 

He has, and Spot and I are working on the merge review issue with the
different Red Hat teams internally.  We've given the team managers a
number of different options to consider, and right now Spot's in the
process of locating a selection of packages we can concentrate on to
make some progress.  We're trying to balance out our desire to get
these merge reviews completed with the fact that most of the engineers
in question labor under a constant, heavy workload that includes a
great deal of maintenance work for RHEL 4 and 5.

> All I'm asking you is to NOT extend that to all "RH guys" (that
> expression is sexist btw).

Hear, hear.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/2535bef4/attachment.sig>

From nicolas.mailhot at laposte.net  Thu Jan 29 13:15:36 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 14:15:36 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
Message-ID: <ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 12:53, Thomas Moschny a ?crit :
>
> 2009/1/29 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>
>>>> Why do you assume I didn't check the correct source before
>>>> approval?
>>>
>>> You might have checked the source, but how do you compare it's md5
>>> to
>>> something that's not there? Or how do you compare the timestamp of
>>> the
>>> source in the SRPM, if it's not there?
>>
>> I actually knew the exact file source Sven would use because he had
>> packaged a related font from the same upstream two days before.
>
> No one is really doubting that. But, it's all about *documenting* what
> you did (and what you didn't) in the review. That's the most important
> reason for the existence of a a review ticket at all.

The most important reason for the existence of a a review ticket is to
make sure someone in a trusted group did review a package. If there is
any doubt about the quality of one review the checks should start from
the package that was effectively imported in rawhide, ***NOT*** what
the reviewer declared checking in the review ticket.

In case of doubt the information in the review ticket is just as
likely to be flawed as the package itself, and in the end the package
we ship is the only thing that really matters.

Long check-list cut and pastes where some tests are erroneously pasted
from another review with this other review value are not unknown of.

-- 
Nicolas Mailhot



From promac at gmail.com  Thu Jan 29 13:20:59 2009
From: promac at gmail.com (Paulo Cavalcanti)
Date: Thu, 29 Jan 2009 11:20:59 -0200
Subject: alsa x 2.6.27.12-170.2.5.fc10
In-Reply-To: <glqnmi$mo6$3@ger.gmane.org>
References: <68720af30901280615l5c50c20fu87db7e17bbb2a8fa@mail.gmail.com>
	<glqnmi$mo6$3@ger.gmane.org>
Message-ID: <68720af30901290520l10961c07k594339618717fac4@mail.gmail.com>

On Wed, Jan 28, 2009 at 8:54 PM, Kevin Kofler <kevin.kofler at chello.at>wrote:

> Paulo Cavalcanti wrote:
> > I really do not understand why not going straight to 1.0.19
> > instead of patching 1.0.17 again. I agree alsa-1.0.18
> > had a lot of problems, but the fixes are in alsa 1.0.19.
>
> I also think reverting is usually a bad solution, move forward, not
> backwards. The reversion probably reintroduced some bugs that 1.0.18 had
> fixed and regressed hardware support. That said, I don't know the specifics
> of this case: are we sure 1.0.19 fixes the regressions?
>
>



I have been installing new alsa versions, one day after the official
release, since 1.0.15.
I also tried many release-candidates and snapshots.

It took me only 15 min to realize that 1.0.18 had problems for some
of my computers.

What kind of tests have been performed before Fedora moved to 1.0.18 (a
couple of months later),
I do not know.

Alsa 1.0.19 has some new models for some codecs, such as no-jd (no jack
detection)
that could be useful to a lot of people, and It works flawlessly for me. But
I agree
that we need a wider set of hardware to test. In my opinion, these tests
have to be performed
in advance, using external modules, and not waiting for a new kernel to come
up.

My hardware has always been Intel onboard sound (desktops/laptops).
Therefore, very common.

There are two things a typical user can not put up with: sound and video
problems.

-- 
Paulo Roma Cavalcanti
LCG - UFRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/44bdfa79/attachment.htm>

From sundaram at fedoraproject.org  Thu Jan 29 13:21:57 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 18:51:57 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090128231333.GA19894@hurricane.linuxnetz.de>
References: <497F5005.4060107@fedoraproject.org>
	<glqmnb$mo6$1@ger.gmane.org>	<4980E0F7.6020507@fedoraproject.org>
	<20090128231333.GA19894@hurricane.linuxnetz.de>
Message-ID: <4981AD75.6000005@fedoraproject.org>

Robert Scheck wrote:
> On Thu, 29 Jan 2009, Rahul Sundaram wrote:
>> The general consensus seem to push for more of a best practises  
>> document. So I am going with
>>
>> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 
> Once more: Why do we not explicitly ask the Bodhi submitter for details
> using much more fields? Having more possibilities to fill data in makes it
> easier to new packagers - they're remembered. Why do you want to solve a
> thing with a Guideline rather enhancing Bodhi and making that software just
> packager friendly?

We can do both. These guidelines cover more than just update 
descriptions now and it is useful to document all these things in the 
wiki. Then, I can also file a RFE against bodhi to add some more 
information. However, note that existing comments in bodhi has been 
ignored many times. If you want to file a RFE yourself, go ahead and 
post the link when you are done.

Rahul



From bochecha at fedoraproject.org  Thu Jan 29 13:29:37 2009
From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha))
Date: Thu, 29 Jan 2009 14:29:37 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
	<ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
Message-ID: <2d319b780901290529w39f4073fl500beb5d811be8f1@mail.gmail.com>

>> No one is really doubting that. But, it's all about *documenting* what
>> you did (and what you didn't) in the review. That's the most important
>> reason for the existence of a a review ticket at all.
>
> The most important reason for the existence of a a review ticket is to
> make sure someone in a trusted group did review a package. If there is
> any doubt about the quality of one review the checks should start from
> the package that was effectively imported in rawhide, ***NOT*** what
> the reviewer declared checking in the review ticket.
>
> In case of doubt the information in the review ticket is just as
> likely to be flawed as the package itself, and in the end the package
> we ship is the only thing that really matters.
>
> Long check-list cut and pastes where some tests are erroneously pasted
> from another review with this other review value are not unknown of.

>From the POV of a inexperienced packager, having this long list of
checked items with remarks on the ones that don't pass is a great
help.

In fact, I learned much more on packaging during the review of my
packages than when I created them. That's because when you're new, it
can be really hard to understand what those items mean. But when the
reviewer says:
- this item:
  => FAIL because blahblahblah

Then you think "oh, that's what this was supposed to mean ?".

I'm not sure I made myself clear, but I do think that detailed reviews
are necessary. This has nothing to do with the trust we have in
packagers / sponsors, but with the submitter's trainship.

Regards,


----------

Mathieu Bridon (bochecha)
French Fedora Ambassador

----------
"They who can give up essential liberty to obtain a little temporary
safety, deserve neither liberty nor safety." ~Benjamin Franklin



From robert at fedoraproject.org  Thu Jan 29 13:32:50 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 14:32:50 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49819545.5010604@behdad.org>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
Message-ID: <20090129133250.GA11392@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Behdad Esfahbod wrote:
> > Taking co-maintainship or even the package doesn't solve 'em all, as I
> > pointed out above already. If the "Red Hat guy" is upstream of software,
> > it's more hard to work around.
> 
> Why's that?  I don't understand.  Now you're attacking the upstream
> maintainers too?

Maybe next time, when I write another huge e-mail like in December 2008 ;-)

What I want to say is, that if somebody is upstream or one of the upstream
maintainers, he/she/it/they is/are the best knowing people of that piece of
software. If he/she/it/they is/are downstream as well, I see this usually
as a benefit. If upstream is then less responsive (e.g. as at ethtool), it
is hard to do a good job as co-maintainer as well.

> I'm smart enough to not need training.  I can train myself.  The question is,
> should I learn RPM?  I don't think so.  My time is better spent doing upstream
> work.  As I've been saying repeatedly, RPM is not my (and many "RH guys"')
> strength, and I'm honest about it.  I know how to update my packages to the
> new version of the upstream package I just released.  And I hope you don't
> have any problem with that.  For anything more complicated, I'd be happy to
> let more experienced Fedora packages jump in.  Such collaboration has happened
> between me and Nicolas Mailhot already.  He oversees font packaging, and I fix
> upstream issues he wants to see fixed.  That's constructive IMO.

If you don't want to enhance your packaging skills around RPM, you simply
must not be a package maintainer. Go and orphan your packages, if you want
to focus just on upstream. Either do good work up- and downstream or just
do good work downstream or just good work upstream. But doing good work
only upstream and less good work downstream is inacceptable - and as well
indiscutable. Period.


Greetings,
  Robert



From sundaram at fedoraproject.org  Thu Jan 29 13:49:45 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 19:19:45 +0530
Subject: Draft: simple update description guidelines
In-Reply-To: <20090129095538.345fdc2a.mschwendt@gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<498011FB.6060809@freenet.de>	<1233139028.3174.46.camel@hughsie-work.lan>	<20090128190017.fe0c3708.mschwendt@gmail.com>	<1233217334.9061.2.camel@hughsie-work.lan>
	<20090129095538.345fdc2a.mschwendt@gmail.com>
Message-ID: <4981B3F9.5060608@fedoraproject.org>

Michael Schwendt wrote:
> On Thu, 29 Jan 2009 08:22:14 +0000, Richard wrote:
> 
>> On Wed, 2009-01-28 at 19:00 +0100, Michael Schwendt wrote:
>>>  No, because they won't cherry-pick updates anyway. They expect the
>>> package maintainers (== the distribution vendor) to offer updates
>>> that just work.
>> You ever watched a user using Fedora on a 56k dial up connection?
> 
> Yes, they are being killed by having to download the frequently changing
> metadata already. That's why they choose different distributions.
> 
> Is that our new primary target group?

Speaking for myself, I can't really switch distributions every time I 
end up with a slow connections. If I get to cherry pick easily, then I 
can bear with it, till the time, I get back on a fast track.

Rahul



From nicolas.mailhot at laposte.net  Thu Jan 29 13:50:28 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 14:50:28 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <2d319b780901290529w39f4073fl500beb5d811be8f1@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
	<ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
	<2d319b780901290529w39f4073fl500beb5d811be8f1@mail.gmail.com>
Message-ID: <37332479776542f7a12d94b629560b81.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 14:29, Mathieu Bridon (bochecha) a ?crit :

> In fact, I learned much more on packaging during the review of my
> packages than when I created them. That's because when you're new, it
> can be really hard to understand what those items mean. But when the
> reviewer says:
> - this item:
>   => FAIL because blahblahblah
>
> Then you think "oh, that's what this was supposed to mean ?".
>
> I'm not sure I made myself clear, but I do think that detailed reviews
> are necessary. This has nothing to do with the trust we have in
> packagers / sponsors, but with the submitter's trainship.

Of course, failures need to be communicated to the packager with
lotsof details :)

I was objecting to the notion that evaluating a review could be done
on a long list of self-declared OKs.

-- 
Nicolas Mailhot



From thomas.moschny at gmail.com  Thu Jan 29 13:52:44 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 29 Jan 2009 14:52:44 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
	<ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
Message-ID: <a9d183c80901290552y2d7fe221reb23bc5cb8e8adf1@mail.gmail.com>

2009/1/29 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
>>> I actually knew the exact file source Sven would use because he had
>>> packaged a related font from the same upstream two days before.
>>
>> No one is really doubting that. But, it's all about *documenting* what
>> you did (and what you didn't) in the review. That's the most important
>> reason for the existence of a a review ticket at all.
>
> The most important reason for the existence of a a review ticket is to
> make sure someone in a trusted group did review a package.

Even trusted people can make mistakes, oversee something, or
guidelines change over time, etc. Having checklists is generally a
good tool when a task is complicated and/or consists of a series of
subtasks. I'm not ashamed using checklists in such cases, but of
course I understand not everyone else uses them.

> In case of doubt the information in the review ticket is just as
> likely to be flawed as the package itself, and in the end the package
> we ship is the only thing that really matters.

Agreed. But the fact that there's no enforced connection between what
was reviewed and what is imported later on, is basically a flaw in the
tools we use. In most cases the links to the src.rpm and specifles are
invalid shortly after the review has been finished, thus rendering the
review ticket mostly useless. This doesn't however invalidate my
point. That issue has already been discussed here before, with no real
outcome, unfortunately.

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From skvidal at fedoraproject.org  Thu Jan 29 13:55:57 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 29 Jan 2009 08:55:57 -0500
Subject: rawhide report: 20090129 changes
In-Reply-To: <1233215654.8363.266.camel@localhost.localdomain>
References: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>
	<1233215654.8363.266.camel@localhost.localdomain>
Message-ID: <1233237357.14094.106.camel@rosebud>

On Wed, 2009-01-28 at 23:54 -0800, Jesse Keating wrote:
> On Thu, 2009-01-29 at 07:48 +0000, Rawhide Report wrote:
> >  Compose started at Thu Jan 29 06:01:03 UTC 2009
> 
> Still trying to get the repodiff utility fully working with new yum api,
> this is causing the lack of change information.

_new_ yum api? What problems are you seeing?

-sv




From nicolas.mailhot at laposte.net  Thu Jan 29 13:57:07 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 14:57:07 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129133250.GA11392@hurricane.linuxnetz.de>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
	<20090129133250.GA11392@hurricane.linuxnetz.de>
Message-ID: <b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 14:32, Robert Scheck a ?crit :

> If you don't want to enhance your packaging skills around RPM, you
> simply
> must not be a package maintainer. Go and orphan your packages, if you
> want to focus just on upstream.

This pretty definitely shows you have not the faintest idea of what
you're talking about. Should you prod Behdad sufficiently to make him
do exactly that, you'd be on the shit list of a lot of people, me
included (and I suspect that would include releng and most of qa).

We are very lucky Bedhad is the maintainer of some key packages about
all our modern desktop depends on, regardless of what his rpm skill
level is (and he's to modest).

-- 
Nicolas Mailhot



From rvinyard at cs.nmsu.edu  Thu Jan 29 14:41:16 2009
From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.)
Date: Thu, 29 Jan 2009 07:41:16 -0700 (MST)
Subject: PackageKit application icons
In-Reply-To: <15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
	<52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>
	<15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>
Message-ID: <43421.155.148.81.31.1233240076.squirrel@intranet.cs.nmsu.edu>

Richard Hughes wrote:
> On 1/28/09, Rick L. Vinyard, Jr. <rvinyard at cs.nmsu.edu> wrote:
>> Jesse Keating wrote:
>>> On Wed, 2009-01-28 at 14:24 -0700, Rick L. Vinyard, Jr. wrote:
>>>> Bill Nottingham wrote:
>>>> > Rick L. Vinyard, Jr. (rvinyard at cs.nmsu.edu) said:
>>>> >> Ahhh... I see that now, and they're already there.
>>>> >>
>>>> >> It's a shame that's the only mechanism for adding icons. I'd like
>>>> to
>>>> see
>>>> >> something other than cardboard boxes when looking for devel
>>>> packages.
>>>> >
>>>> > The problem is you'd either need to:
>>>> >
>>>> > - include icons in the metadata (which gets very large, very fast)
>>>> > - create a package that consists of all the icons that may be in
>>>> >   the distro (which gets very messy to maintain, very fast)
>>>> >
>>>> > Neither of these are particularly good solutions.
>>>> >
>>>>
>>>> I agree that neither of those are good solutions, but there is another
>>>> option.
>>>>
>>>> Currently, the icons reside in each package and the desktop entry file
>>>> (also in the individual packages) is used to associate the package
>>>> with
>>>> the icon.
>>>>
>>>> Why couldn't devel packages (and others without desktop entry files)
>>>> follow a similar approach containing the icon and association?
>>>
>>> I think the problem then is you don't see the icon for the package
>>> until
>>> you've installed the package.
>>
>> But, aren't they currently harvesting them from the packages and desktop
>> entries?
>
> Yes, as soon as you install the package, PackageKit parses the desktop
> file and adds the icon file to a local database.

That clarifies alot. I thought they were being harvested from the repository?

>
>> Or, does pkg-application only show the icons for the packages I
>> currently
>> have installed?
>
> Yup. The only way this could work for not-installed files would be for
> the application icons to be put on the mirrors, and for PackageKit to
> generate a per-user cache of icons in the session.
>

What about using the same technique to harvest them from the repository
and build an rpm?




From sundaram at fedoraproject.org  Thu Jan 29 14:49:15 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 20:19:15 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <3170f42f0901290330m33de6427m5bc8d931bbbd603a@mail.gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<1233226137.3514.32.camel@wicktop.localdomain>
	<3170f42f0901290330m33de6427m5bc8d931bbbd603a@mail.gmail.com>
Message-ID: <4981C1EB.209@fedoraproject.org>

Debarshi Ray wrote:

> Quite true. Recently I did a merge review [1] where among other things
> I mentioned the absense of %{?_smp_flags} while building the package.
> The owner fixed most of the things but just left it out saying that he
> can not be bothered about such irrelevant things. I do not know about
> its relevance, but there is another merge review [2] where shared
> libraries are being installed without invoking ldconfig, and the
> maintainer does not care to respond even a month even though I
> provided a patch to fix most of the issues.

If you have commit access, drop a mail and commit them directly. Most 
maintainers are overflowing in bugzilla mails and there is the delicate 
dance between Fedora and RHEL priorities. On the plus side, people are 
usually open to co-maintainers or even a take over.

Rahul



From dominik at greysector.net  Thu Jan 29 14:54:17 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 29 Jan 2009 15:54:17 +0100
Subject: mono-tools and MD for f10
In-Reply-To: <1233219248.6740.43.camel@PB3.Linux>
References: <1233219248.6740.43.camel@PB3.Linux>
Message-ID: <20090129145417.GG3119@mokona.greysector.net>

On Thursday, 29 January 2009 at 09:54, Paul wrote:
> Hi,
> 
> I've more or less completed the update build for f10 to be using
> mono-2.2. Unfortunately, I can't build mono-tools or monodevelop for f10
> as my box is running mono-2.4 from rawhide and for some reason, this
> breaks the build of both of these packages.
> 
> I've attempted to build in mock, but get nowhere (mono-tools needs
> mono-devel >= 2.2 and mock is not pulling it in).
> 
> If anyone has a few spare cycles, any chance of helping me with a build
> of both of these?

Why don't you set up a local repo via ftp, add it to mock config and put
the necessary devel packages there?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From sundaram at fedoraproject.org  Thu Jan 29 14:54:18 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 20:24:18 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <498196C1.1000505@behdad.org>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<3170f42f0901290340h1fd43aesf5c0d9d0c01ccb86@mail.gmail.com>
	<498196C1.1000505@behdad.org>
Message-ID: <4981C31A.8050804@fedoraproject.org>

Behdad Esfahbod wrote:

> 
> I'm not actively seeking giving away my packages.  I'm fine with them as long
> as they don't demand too much time from me.  But I'll just hand them off as
> soon as a Fedora contributor shows up and wants to make non-trivial changes in
> them.  That's for example how I handed some of my font packages to Nicolas, or
> my entire ogg vorbis stack to Hans.  The point being: I am no the bottleneck /
> problem / ... with these packages.

One of the rule of thumb was that if you are going to be maintaining the 
package in RHEL, it is better for you to be involved in the Fedora side 
as well for continuity. Otherwise, you would end up inheriting a bunch 
of spec files (and patches) without a complete understanding on the 
history behind them which makes it difficult to work on them, later on. 
Something to consider.

Rahul



From rdieter at math.unl.edu  Thu Jan 29 14:55:42 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 29 Jan 2009 08:55:42 -0600
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org>
Message-ID: <glsg32$lh0$1@ger.gmane.org>

Kevin Kofler wrote:

> Tom "spot" Callaway wrote:
>> I'd have to say the chances of this are extremely unlikely. I'm much
>> more inclined to propose that we drop texlive altogether.
> 
> No TeX? 
> If concrete licensing issues are found by somebody, of course those 
> need to be addressed

+1

Why is a license audit is blocking an update?  Can't these tasks be done in
parallel? 

-- Rex




From sundaram at fedoraproject.org  Thu Jan 29 14:58:04 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 20:28:04 +0530
Subject: PackageKit application icons
In-Reply-To: <43421.155.148.81.31.1233240076.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>	<4980C521.4030202@fedoraproject.org>	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>	<20090128211750.GA15085@nostromo.devel.redhat.com>	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>	<1233179067.8363.239.camel@localhost.localdomain>	<52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>	<15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>
	<43421.155.148.81.31.1233240076.squirrel@intranet.cs.nmsu.edu>
Message-ID: <4981C3FC.20009@fedoraproject.org>

Rick L. Vinyard, Jr. wrote:

> What about using the same technique to harvest them from the repository
> and build an rpm?

PackageKit would become very slow reading all that metadata. Goes back 
to the same problem Bill pointed out earlier.

Rahul



From sundaram at fedoraproject.org  Thu Jan 29 15:00:38 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Thu, 29 Jan 2009 20:30:38 +0530
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
References: <1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<20090129073446.GB5712@hurricane.linuxnetz.de>	<49819545.5010604@behdad.org>	<20090129133250.GA11392@hurricane.linuxnetz.de>
	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
Message-ID: <4981C496.8090501@fedoraproject.org>

Nicolas Mailhot wrote:
> 
> Le Jeu 29 janvier 2009 14:32, Robert Scheck a ?crit :
> 
>> If you don't want to enhance your packaging skills around RPM, you
>> simply
>> must not be a package maintainer. Go and orphan your packages, if you
>> want to focus just on upstream.
> 
> This pretty definitely shows you have not the faintest idea of what
> you're talking about. 

Nicolas,

Please. Instead of antagonizing each other,  it would be useful to add 
information on what he doesn't know about.

Rahul



From katzj at redhat.com  Thu Jan 29 15:07:55 2009
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 29 Jan 2009 10:07:55 -0500
Subject: Scrubbing boot.iso from CD1 and DVD
In-Reply-To: <20090129103157.GB22110@redhat.com>
References: <1233205271.8363.258.camel@localhost.localdomain>
	<20090129103157.GB22110@redhat.com>
Message-ID: <20090129150755.GB30181@redhat.com>

On Thursday, January 29 2009, Daniel P. Berrange said:
> On Wed, Jan 28, 2009 at 09:01:11PM -0800, Jesse Keating wrote:
> > I've committed code to pungi that will prevent boot.iso from being on
> > CD1 and the DVD.  I've had various discussions with folks about this in
> > the past, and given that boot.iso is 122M on x86_64 that's a lot of
> > packages we could have instead.  In the past, boot.iso was much smaller
> > and it wasn't a big cost, things have changed.
> > 
> > If anybody has a really good reason for why we should continue to put
> > boot.iso on the media, speak now.
> 
> We still have the kernel+initrd for pxeboot on the CD1/DVD, right ? If
> so, then killing boot.iso from the CD1/DVD image shouldn't any problem 
> for the virt provisioning tools POV.

Yep, we have to have one copy of them for isolinux to boot the install and 
then just hardlink them out to all the other locations on the disc that people
semi-expect to find them.

Jeremy



From nicolas.mailhot at laposte.net  Thu Jan 29 15:09:16 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 16:09:16 +0100 (CET)
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glsg32$lh0$1@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
Message-ID: <720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 15:55, Rex Dieter a ?crit :
>
> Kevin Kofler wrote:
>
>> Tom "spot" Callaway wrote:
>>> I'd have to say the chances of this are extremely unlikely. I'm
>>> much
>>> more inclined to propose that we drop texlive altogether.
>>
>> No TeX?
>> If concrete licensing issues are found by somebody, of course those
>> need to be addressed
>
> +1
>
> Why is a license audit is blocking an update?

I don't think it's blocking, IIRC texlive 2008 also demands different
packaging, and there is a lack of people to do both the technical
*and* the legal work.

Of course new modular packaging of TEX would take care of both issues,
if enough packagers could be found to submit packages for each part of
TEX, checking its licensing at the same time.

-- 
Nicolas Mailhot



From nicolas.mailhot at laposte.net  Thu Jan 29 15:25:25 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 16:25:25 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <4981C496.8090501@fedoraproject.org>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
	<20090129133250.GA11392@hurricane.linuxnetz.de>
	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
	<4981C496.8090501@fedoraproject.org>
Message-ID: <323e83c236f30e9ca2cd02ffb51fca50.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 16:00, Rahul Sundaram a ?crit :

> Please. Instead of antagonizing each other,  it would be useful to add
> information on what he doesn't know about.

Well, if it needs to be written publicly, a responsive upstream who is
also a Fedora packager and that can push fixes to core libraries in
Fedora as needed (and check we do not miss anything) is a major boon.

Not only Behdad is a responsive upstream for his own stuff but he's
also often pushed fixes for other projects whose canonical upstream
had postponed fixing indefinitely.

The rpm side of packaging is important, but mature packages do not
have a spec that changes every month and do not need an rpm expert to
maintain. Being able to fix the packaged stuff has more value than
understanding rpm arcanes.

-- 
Nicolas Mailhot



From andreas at bawue.net  Thu Jan 29 15:41:39 2009
From: andreas at bawue.net (Andreas Thienemann)
Date: Thu, 29 Jan 2009 16:41:39 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
	<20090129133250.GA11392@hurricane.linuxnetz.de>
	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
Message-ID: <Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>

On Thu, 29 Jan 2009, Nicolas Mailhot wrote:

> > If you don't want to enhance your packaging skills around RPM, you
> > simply must not be a package maintainer. Go and orphan your packages,
> > if you want to focus just on upstream.
> 
> This pretty definitely shows you have not the faintest idea of what
> you're talking about.

Au contraire. I believe Robert knows pretty much what he's talking about. 
Even though his form is not always what I consider cordial, the content of 
his mails and his reasoning is sound.


> Should you prod Behdad sufficiently to make him do exactly that, you'd
> be on the shit list of a lot of people, me included (and I suspect that
> would include releng and most of qa).

No need for shitlists. Please read _again_ what exactly Robert is 
advocating.

I'll even repeat it for you:

	Go and orphan your packages, if you want to focus just on 
	upstream.

He's not advocating forcing people out or forcing them to orphan packages. 
What he suggests is that people wanting to concentrate on upstream 
development are able to do that without being burdened by maintaining 
packages for distributions.




regards,
 andreas



From nicolas.mailhot at laposte.net  Thu Jan 29 15:50:47 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 16:50:47 +0100 (CET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>
References: <1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
	<20090129133250.GA11392@hurricane.linuxnetz.de>
	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
	<Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>
Message-ID: <8dc3b8e100eaffb39737b596f03b0a37.squirrel@arekh.dyndns.org>



Le Jeu 29 janvier 2009 16:41, Andreas Thienemann a ?crit :

> He's not advocating forcing people out or forcing them to orphan
> packages.
> What he suggests is that people wanting to concentrate on upstream
> development are able to do that without being burdened by maintaining
> packages for distributions.

He suggested a little more than that and no I don't believe this would
be a positive result for Fedora. (even assuming enough community
packagers could be found to replace the existing packagers)

-- 
Nicolas Mailhot



From jkeating at redhat.com  Thu Jan 29 15:49:35 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 07:49:35 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <20090129111140.654efe7a.mschwendt@gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa> <49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
	<20090129111140.654efe7a.mschwendt@gmail.com>
Message-ID: <1233244175.8363.272.camel@localhost.localdomain>

On Thu, 2009-01-29 at 11:11 +0100, Michael Schwendt wrote:
>  
> Much better, an effort much appreciated, although this is way beyond
> the subject of this thread. ;) Such a document goes into the right
> direction, since it tries to explain Fedora's fundamental update
> strategy and may come as a surprise to some packagers. It will be very
> interesting to hear what FESCo members think about the contents.

I'm not in FESCo but I really like the content and appreciate the effort
as well.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/8e881640/attachment.sig>

From christoph.wickert at googlemail.com  Thu Jan 29 15:59:24 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 16:59:24 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49819222.10602@behdad.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
	<49819222.10602@behdad.org>
Message-ID: <1233244764.3741.14.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 06:25 -0500 schrieb Behdad Esfahbod:
> Christoph Wickert wrote:
> >
> > I think what Robert and me wanted to express is: It's not only that some
> > (!) people from RH do not follow the guidelines but some also explicitly
> > refuse to follow them even after they were told them what's wrong. I
> > have no explanation for that kind of behavior but arrogance. 
> 
> I have a very unpleasant experience with a community maintainer over a package
> we co-maintained and that I'm the upstream.  Do I extrapolate that to all
> non-RH people?  No.  

Me nether, I repeatedly used the word "some".

> Stop discriminating already.  If an RH person doesn't
> follow Fedora rules and guidelines, follow the standard Fedora procedures to
> deal with them.

The standard procedure would be to 
a) close the review NOTABUG or
b) follow the AWOL procedure if reporter does not respond.
Please show me a single case where we (community AND/OR Red Hat)
successfully applied a) or b) to a RH employee.

> Stop whining.  Please.

I'll shut up if you can show me such a case.

> >> Most of what is seen as "Red Hat guys are bad at packaging" is simply baggage
> >> held from the Core days.  
> > 
> > Agreed, but we've had merge reviews with proposals for enhancements and
> > fixes that did not get applied by the owner. I have never ever seen this
> > from a community member. If someone did, his review request would be
> > closed "WONTFIX" pretty soon, but this isn't possible for merge reviews.
> 
> Sure.  That's a problem with the merge review procedure perhaps?  Definitely
> not something to blame the poor RH developer for.

It's not only the merge reviews. I can show you bugs where a package was
broken for a whole release and the bug was closed "WONTFIX" because the
package was EOL then. Looking at my bugzilla frontpage I see a couple of
bugs that are older than a year and still new or already closed.
Assignees were not even responding when I set NEEDINFO. _All_ these bugs
are assigned to Red Hat developers, _not_a_single_ of them to a
community maintainer. How comes?

Regards,
Christoph



From jkeating at redhat.com  Thu Jan 29 16:02:44 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 08:02:44 -0800
Subject: rawhide report: 20090129 changes
In-Reply-To: <1233237357.14094.106.camel@rosebud>
References: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>
	<1233215654.8363.266.camel@localhost.localdomain>
	<1233237357.14094.106.camel@rosebud>
Message-ID: <1233244964.8363.273.camel@localhost.localdomain>

On Thu, 2009-01-29 at 08:55 -0500, seth vidal wrote:
> On Wed, 2009-01-28 at 23:54 -0800, Jesse Keating wrote:
> > On Thu, 2009-01-29 at 07:48 +0000, Rawhide Report wrote:
> > >  Compose started at Thu Jan 29 06:01:03 UTC 2009
> > 
> > Still trying to get the repodiff utility fully working with new yum api,
> > this is causing the lack of change information.
> 
> _new_ yum api? What problems are you seeing?
> 
> -sv
> 

As discussed on IRC, not an api problem, instead just a new bug. (just
closing the loop here)


-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/bb74e8e4/attachment.sig>

From christoph.wickert at googlemail.com  Thu Jan 29 15:59:33 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 16:59:33 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233228177.2769.1.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233228177.2769.1.camel@localhost.localdomain>
Message-ID: <1233244773.3741.15.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 06:22 -0500 schrieb Brian Pepple:
> On Thu, 2009-01-29 at 11:58 +0100, Christoph Wickert wrote:
> > Am Mittwoch, den 28.01.2009, 20:25 -0500 schrieb Brian Pepple:
> > 
> > > This is all a moot point now though, since a couple of weeks ago FESCo
> > > approved a proposal to reset the initial seeding of the provenpackager
> > > group with Packaging Sponsors, and Jesse has made a proposal(1) on
> > > guidelines for approving someone to the provenpackager group.
> > > 
> > >      1. https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01573.html
> > > 
> > 
> > IMO this is not a moot point at all, because even after the group was
> > reset, there are people in there that I don't want to see there.
> > 
> > For example I just found out that one of the people I sponsor is proven
> > packager. Of course I do trust him, otherwise I would not have sponsored
> > him, but I doubt that 2 packages (!) and 3 months of experience are
> > enough for a proven packager.
> 
> Umm, it is moot, since the *reset* hasn't actually occurred yet.  

Why not, if the proposal was approved already "weeks ago"?

Regards,
Christoph




From kanarip at kanarip.com  Thu Jan 29 16:07:26 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Thu, 29 Jan 2009 17:07:26 +0100
Subject: Call for Ruby package maintainer
In-Reply-To: <20090128.182208.612299192959538683.tagoh@redhat.com>
References: <20090127.150412.1090654878994195729.tagoh@redhat.com>	<497FA870.2030806@kanarip.com>
	<20090128.182208.612299192959538683.tagoh@redhat.com>
Message-ID: <4981D43E.3030404@kanarip.com>

Akira TAGOH wrote:
>>>>>> On Wed, 28 Jan 2009 01:36:00 +0100,
>>>>>> "JvM" == Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> 
> JvM> Are you talking ruby itself, or just "a" ruby package?
> 
> I meant ruby itself. right now what a kind of todo I have in
> ruby package is:
> 
> - Update to 1.8.7
>   - may need to consider updating the packaging policy as
>     well since this release has additional installation path
>     like perl and python has. e.g. /usr/lib/ruby/vendor_ruby.
> 
> - Get rid of old search paths for backward compatibility
>   because we should've passed through enough time to
>   migrate.
> 
> - bug fixes
> 

If you orphan the package in PackageDB, I'll pick it up so you can add 
yourself back as a co-maintainer.

Kind regards,

Jeroen van Meeuwen
-kanarip



From jkeating at redhat.com  Thu Jan 29 16:15:38 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 08:15:38 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233226734.3514.39.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
Message-ID: <1233245738.8363.275.camel@localhost.localdomain>

On Thu, 2009-01-29 at 11:58 +0100, Christoph Wickert wrote:
>  For example I just found out that one of the people I sponsor is proven
> packager. Of course I do trust him, otherwise I would not have sponsored
> him, but I doubt that 2 packages (!) and 3 months of experience are
> enough for a proven packager.
> 
> This shows that Jesse's proposal is pretty much useless, because it is
> weaker then the previous set of rules, no matter if it was 5 or 8
> packages.

My proposal is to seed provenpackager with people who are /sponsors/.
It has absolutely nothing to do with how many packages you have.  How is
this weaker?  How would my suggested seeding lead to your people being
in provenpackager?

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/b78467ef/attachment.sig>

From skvidal at fedoraproject.org  Thu Jan 29 16:16:13 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 29 Jan 2009 11:16:13 -0500
Subject: rawhide report: 20090129 changes
In-Reply-To: <1233244964.8363.273.camel@localhost.localdomain>
References: <20090129074801.E12D21B8001@releng2.fedora.phx.redhat.com>
	<1233215654.8363.266.camel@localhost.localdomain>
	<1233237357.14094.106.camel@rosebud>
	<1233244964.8363.273.camel@localhost.localdomain>
Message-ID: <1233245773.20956.0.camel@rosebud>

On Thu, 2009-01-29 at 08:02 -0800, Jesse Keating wrote:
> On Thu, 2009-01-29 at 08:55 -0500, seth vidal wrote:
> > On Wed, 2009-01-28 at 23:54 -0800, Jesse Keating wrote:
> > > On Thu, 2009-01-29 at 07:48 +0000, Rawhide Report wrote:
> > > >  Compose started at Thu Jan 29 06:01:03 UTC 2009
> > > 
> > > Still trying to get the repodiff utility fully working with new yum api,
> > > this is causing the lack of change information.
> > 
> > _new_ yum api? What problems are you seeing?
> > 
> > -sv
> > 
> 
> As discussed on IRC, not an api problem, instead just a new bug. (just
> closing the loop here)
> 

cool - and patch for that bug is here:
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=ff4908950c25152494f69d5ca38c5dc5aec6b156

if anyone cares.

-sv




From jkeating at redhat.com  Thu Jan 29 16:16:27 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 08:16:27 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233244773.3741.15.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233228177.2769.1.camel@localhost.localdomain>
	<1233244773.3741.15.camel@wicktop.localdomain>
Message-ID: <1233245787.8363.276.camel@localhost.localdomain>

On Thu, 2009-01-29 at 16:59 +0100, Christoph Wickert wrote:
>  Why not, if the proposal was approved already "weeks ago"?

The proposal to reset was approved, on the condition that guidelines get
drafted and accepted on adding more people after the initial re-seed.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/0c3c0c53/attachment.sig>

From paul at all-the-johnsons.co.uk  Thu Jan 29 16:20:28 2009
From: paul at all-the-johnsons.co.uk (Paul)
Date: Thu, 29 Jan 2009 16:20:28 +0000
Subject: mono-tools and MD for f10
In-Reply-To: <20090129145417.GG3119@mokona.greysector.net>
References: <1233219248.6740.43.camel@PB3.Linux>
	<20090129145417.GG3119@mokona.greysector.net>
Message-ID: <1233246028.6740.59.camel@PB3.Linux>

Hi,

> > If anyone has a few spare cycles, any chance of helping me with a build
> > of both of these?
> 
> Why don't you set up a local repo via ftp, add it to mock config and put
> the necessary devel packages there?

Sounds just the job - just one thing, how do I do it?

TTFN

Paul
-- 
?Sie k?nnen mich aufreizen und wirklich hei? machen!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/245aa4d9/attachment.sig>

From a.badger at gmail.com  Thu Jan 29 16:32:21 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 08:32:21 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <4981C31A.8050804@fedoraproject.org>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<3170f42f0901290340h1fd43aesf5c0d9d0c01ccb86@mail.gmail.com>	<498196C1.1000505@behdad.org>
	<4981C31A.8050804@fedoraproject.org>
Message-ID: <4981DA15.6010601@gmail.com>

Rahul Sundaram wrote:
> Behdad Esfahbod wrote:
> 
>>
>> I'm not actively seeking giving away my packages.  I'm fine with them
>> as long
>> as they don't demand too much time from me.  But I'll just hand them
>> off as
>> soon as a Fedora contributor shows up and wants to make non-trivial
>> changes in
>> them.  That's for example how I handed some of my font packages to
>> Nicolas, or
>> my entire ogg vorbis stack to Hans.  The point being: I am no the
>> bottleneck /
>> problem / ... with these packages.
> 
> One of the rule of thumb was that if you are going to be maintaining the
> package in RHEL, it is better for you to be involved in the Fedora side
> as well for continuity. Otherwise, you would end up inheriting a bunch
> of spec files (and patches) without a complete understanding on the
> history behind them which makes it difficult to work on them, later on.
> Something to consider.
> 
....although this can lend itself to a comaintainer role as easily as
ownership.  (Not disagreeing, just adding a clarification).

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/ffd67144/attachment.sig>

From mikeb at redhat.com  Thu Jan 29 16:40:03 2009
From: mikeb at redhat.com (Mike Bonnet)
Date: Thu, 29 Jan 2009 11:40:03 -0500
Subject: Koji error
In-Reply-To: <20090126161914.77b72a8f@ohm.scrye.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
	<20090126161914.77b72a8f@ohm.scrye.com>
Message-ID: <4981DBE3.8070100@redhat.com>

Kevin Fenzi wrote:
> On Mon, 26 Jan 2009 20:12:11 -0300
> Allisson Azevedo <allisson at gmail.com> wrote:
> 
>> Hi,
>>
>> I can't build perl-MooseX-Async, all branches return this error:
> 
> Wait a bit and try again. 
> 
> The job that syncs new package info over to koji only runs once an hour
> or once every 30min. 

Any reason not to run it every 5 minutes?  I imagine that if there's 
nothing for it to do, it doesn't cost much.



From christoph.wickert at googlemail.com  Thu Jan 29 16:42:36 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 17:42:36 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233245738.8363.275.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
Message-ID: <1233247356.3741.30.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 08:15 -0800 schrieb Jesse Keating:
> On Thu, 2009-01-29 at 11:58 +0100, Christoph Wickert wrote:
> >  For example I just found out that one of the people I sponsor is proven
> > packager. Of course I do trust him, otherwise I would not have sponsored
> > him, but I doubt that 2 packages (!) and 3 months of experience are
> > enough for a proven packager.
> > 
> > This shows that Jesse's proposal is pretty much useless, because it is
> > weaker then the previous set of rules, no matter if it was 5 or 8
> > packages.
> 
> My proposal is to seed provenpackager with people who are /sponsors/.
> It has absolutely nothing to do with how many packages you have.  How is
> this weaker?  How would my suggested seeding lead to your people being
> in provenpackager?

>From your proposal:

"By granting membership into
provenpackager for a maintainer you are confirming that at least in your
mind they meet the above criteria and that you would trust them fully
with any of the packages you either maintain or even just use."

Effectively this means: Only a single sponsor needs to trust the
particular person to make him a proven packager, no matter how many
other sponsors disagree with that decision. IMO this requirement is
weaker than a given number of packages.
After he was sponsored the new proven packager can sponsor as many other
"pseudo-proven" packagers as he wants, even if they are not trustworthy.
Other sponsors have no way to prevent this, so I'm pretty sure we'll end
up with a large number of proven packagers again pretty soon.

Or am I mistaken here?

Regards,
Christoph



From kevin.kofler at chello.at  Thu Jan 29 16:44:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 17:44:07 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
Message-ID: <glsmcn$egi$1@ger.gmane.org>

Behdad Esfahbod wrote:
> I pushed the package in Rawhide.  Against my will, he pushed the package
> in F-9 and F-8 updates-testing.  When it became clear that the package
> eats babies I desperately asked him to retract the updates.  He stopped
> responding and as far as I know he disappeared from Fedora.  I did
> whatever I could to retract those updates.  They escalated from
> updates-testing to updates.  Bug reports poured in.  I filed bugs against
> rel-eng.  Etc, etc.

For the record, and in case it happens again: there's really no good way
to "retract" an update once it hit the stable updates, because people who
already upgraded will be stuck with it. So rel-eng will be rightfully
reluctant to do that. What you have to do in such a case is to push another
update to downgrade the package, with a bumped Epoch (use Epoch: 1 if the
package didn't have an Epoch before).

        Kevin Kofler



From christoph.wickert at googlemail.com  Thu Jan 29 16:45:57 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 17:45:57 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
Message-ID: <1233247557.3741.32.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 11:40 +0100 schrieb Nicolas Mailhot: 
> 
> Le Jeu 29 janvier 2009 11:20, Christoph Wickert a ?crit :
> >
> > Am Donnerstag, den 29.01.2009, 11:09 +0100 schrieb Nicolas Mailhot:
> >>
> >> Le Jeu 29 janvier 2009 11:05, Christoph Wickert a ?crit :
> >> >
> >> > Am Donnerstag, den 29.01.2009, 08:26 +0100 schrieb Nicolas
> >> Mailhot:
> >> >> Le mercredi 28 janvier 2009 ? 23:35 +0100, Christoph Wickert a
> >> ?crit
> >> >> :
> >> >>
> >> >> >       * A font package was approved although it contained
> >> another
> >> >> font
> >> >>
> >> >> And this was caught in review before the approval and fixed
> >> before
> >> >> cvs
> >> >> import. So go search your quality problems somewhere else.
> >> >
> >> > Both Sven and me corrected my statement already hours before you
> >> wrote
> >> > that mail. Please go search the list before posting.
> >> >
> >> > To clarify: I have no problems with "fix that before import" in
> >> > general,
> >> > but IMHO for a wrong source it's something different, because a
> >> lot of
> >> > things can not be checked or the checks are useless.
> >>
> >> Why do you assume I didn't check the correct source before approval?
> >
> > You might have checked the source, but how do you compare it's md5 to
> > something that's not there? Or how do you compare the timestamp of the
> > source in the SRPM, if it's not there?
> 
> I actually knew the exact file source Sven would use because he had
> packaged a related font from the same upstream two days before. 

Sorry, but you did not answer my question. How do you compare it to
something that's not there? Ok, you knew the source, but how would you
know if Sven downloads it correctly, preserves the timestamp etc.? The
answer is: you didn't, but you trust Sven.
That's ok for me, at least in case of Sven, but you did not really
follow the review guidelines.

> So
> please stop using this review as example of whatever you want to prove
> and move along.

I recently mailed Spot with a (trivial) correction of the Review
Guidelines and a proposal of more things that should be checked during
review. He told me that Packaging would vote on that in it's next
meeting, but so far I got no response and it's not in the Guidelines
ether. You see: I'm trying to move along, but I can't do more than
making suggestions.

> If you want to do something useful, I have a pile of packaging changes
> in my review queue I'd be happy to pass on to someone obcessing about
> review quality in Fedora.

Then give me some bz # please.

TIA,
Christoph



From christoph.wickert at googlemail.com  Thu Jan 29 16:42:36 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 17:42:36 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233245738.8363.275.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
Message-ID: <1233247356.3741.30.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 08:15 -0800 schrieb Jesse Keating:
> On Thu, 2009-01-29 at 11:58 +0100, Christoph Wickert wrote:
> >  For example I just found out that one of the people I sponsor is proven
> > packager. Of course I do trust him, otherwise I would not have sponsored
> > him, but I doubt that 2 packages (!) and 3 months of experience are
> > enough for a proven packager.
> > 
> > This shows that Jesse's proposal is pretty much useless, because it is
> > weaker then the previous set of rules, no matter if it was 5 or 8
> > packages.
> 
> My proposal is to seed provenpackager with people who are /sponsors/.
> It has absolutely nothing to do with how many packages you have.  How is
> this weaker?  How would my suggested seeding lead to your people being
> in provenpackager?

>From your proposal:

"By granting membership into
provenpackager for a maintainer you are confirming that at least in your
mind they meet the above criteria and that you would trust them fully
with any of the packages you either maintain or even just use."

Effectively this means: Only a single sponsor needs to trust the
particular person to make him a proven packager, no matter how many
other sponsors disagree with that decision. IMO this requirement is
weaker than a given number of packages.
After he was sponsored the new proven packager can sponsor as many other
"pseudo-proven" packagers as he wants, even if they are not trustworthy.
Other sponsors have no way to prevent this, so I'm pretty sure we'll end
up with a large number of proven packagers again pretty soon.

Or am I mistaken here?

Regards,
Christoph



From jkeating at redhat.com  Thu Jan 29 16:52:35 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 08:52:35 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233247356.3741.30.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
Message-ID: <1233247955.8363.278.camel@localhost.localdomain>

On Thu, 2009-01-29 at 17:42 +0100, Christoph Wickert wrote:
>  Effectively this means: Only a single sponsor needs to trust the
> particular person to make him a proven packager, no matter how many
> other sponsors disagree with that decision. IMO this requirement is
> weaker than a given number of packages.
> After he was sponsored the new proven packager can sponsor as many other
> "pseudo-proven" packagers as he wants, even if they are not trustworthy.
> Other sponsors have no way to prevent this, so I'm pretty sure we'll end
> up with a large number of proven packagers again pretty soon.
> 
> Or am I mistaken here?

No, that's one view of it.

It's just a proposal, you're welcome to suggest changes or make your own
proposal like Robert did.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/07114b21/attachment.sig>

From jkeating at redhat.com  Thu Jan 29 16:56:13 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 08:56:13 -0800
Subject: Koji error
In-Reply-To: <4981DBE3.8070100@redhat.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>
	<20090126161914.77b72a8f@ohm.scrye.com> <4981DBE3.8070100@redhat.com>
Message-ID: <1233248173.8363.280.camel@localhost.localdomain>

On Thu, 2009-01-29 at 11:40 -0500, Mike Bonnet wrote:
> Kevin Fenzi wrote:
> > On Mon, 26 Jan 2009 20:12:11 -0300
> > Allisson Azevedo <allisson at gmail.com> wrote:
> > 
> >> Hi,
> >>
> >> I can't build perl-MooseX-Async, all branches return this error:
> > 
> > Wait a bit and try again. 
> > 
> > The job that syncs new package info over to koji only runs once an hour
> > or once every 30min. 
> 
> Any reason not to run it every 5 minutes?  I imagine that if there's 
> nothing for it to do, it doesn't cost much.

The long term answer here is either combine the DBs so that it's
instant, or hook into the amqp bus to react to changes instead of
periodic polling and costly comparison.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/6ee5fc86/attachment.sig>

From rvinyard at cs.nmsu.edu  Thu Jan 29 17:07:39 2009
From: rvinyard at cs.nmsu.edu (Rick L. Vinyard, Jr.)
Date: Thu, 29 Jan 2009 10:07:39 -0700 (MST)
Subject: PackageKit application icons
In-Reply-To: <4981C3FC.20009@fedoraproject.org>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
	<52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>
	<15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>
	<43421.155.148.81.31.1233240076.squirrel@intranet.cs.nmsu.edu>
	<4981C3FC.20009@fedoraproject.org>
Message-ID: <42603.155.148.81.31.1233248859.squirrel@intranet.cs.nmsu.edu>

Rahul Sundaram wrote:
> Rick L. Vinyard, Jr. wrote:
>
>> What about using the same technique to harvest them from the repository
>> and build an rpm?
>
> PackageKit would become very slow reading all that metadata. Goes back
> to the same problem Bill pointed out earlier.

So, in essence, what it comes down to is that PackageKit can't handle the
extra load of (potentially) one icon filename per package, no matter where
they come from or where the metadata resides?

That's a shame, because like I said before I think the icons significantly
improve the user experience.



From christoph.wickert at googlemail.com  Thu Jan 29 17:11:41 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 18:11:41 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233247955.8363.278.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
	<1233247955.8363.278.camel@localhost.localdomain>
Message-ID: <1233249101.3741.41.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 08:52 -0800 schrieb Jesse Keating:
> 
> No, that's one view of it.
> 
> It's just a proposal, you're welcome to suggest changes or make your own
> proposal like Robert did.

In my very first email in this thread I wrote that I fully support
Robert's proposal. With a single confinement: Robert suggested this to
be some automatic process that happens in FAS. I would like to do this
by mail. IMO this is more simple and more in public. I'd like to be able
to follow the discussion while FAS is anonymous.

Regards,
Christoph



From hughsient at gmail.com  Thu Jan 29 17:38:59 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Thu, 29 Jan 2009 17:38:59 +0000
Subject: PackageKit application icons
In-Reply-To: <42603.155.148.81.31.1233248859.squirrel@intranet.cs.nmsu.edu>
References: <44018.155.148.81.31.1233175638.squirrel@intranet.cs.nmsu.edu>
	<4980C521.4030202@fedoraproject.org>
	<56726.155.148.81.31.1233176715.squirrel@intranet.cs.nmsu.edu>
	<20090128211750.GA15085@nostromo.devel.redhat.com>
	<36078.155.148.81.31.1233177886.squirrel@intranet.cs.nmsu.edu>
	<1233179067.8363.239.camel@localhost.localdomain>
	<52277.155.148.81.31.1233180704.squirrel@intranet.cs.nmsu.edu>
	<15e53e180901281418m6da548d4sfe8098a9d620c92e@mail.gmail.com>
	<43421.155.148.81.31.1233240076.squirrel@intranet.cs.nmsu.edu>
	<4981C3FC.20009@fedoraproject.org>
	<42603.155.148.81.31.1233248859.squirrel@intranet.cs.nmsu.edu>
Message-ID: <1233250739.3938.31.camel@hughsie-work.lan>

On Thu, 2009-01-29 at 10:07 -0700, Rick L. Vinyard, Jr. wrote:
> So, in essence, what it comes down to is that PackageKit can't handle
> the extra load of (potentially) one icon filename per package, no
> matter where they come from or where the metadata resides?

No, PackageKit can do it just fine (I did this in early prototypes of
the GUI tools).

> That's a shame, because like I said before I think the icons
> significantly improve the user experience.

I agree too. The method you explain about caching all the icons in the
desktop files is tricky. Ubuntu do exactly this, and it causes the
following problems:

* The data is stale and out of data every time a new package is added /
changed
* you have to build every srpm in the archive, unpack the built rpm(s),
search for desktop files and icon names
* you have to use funny metrics to find the "right" icon -- many
packages have many desktop binaries shipped.

So it's a difficult problem to fix. Certainly, if somebody put the work
into pkgdb or something to get this mapping, I would add support for it
in PackageKit gui tools in a heartbeat.

Richard.




From ville.skytta at iki.fi  Thu Jan 29 17:39:43 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 29 Jan 2009 19:39:43 +0200
Subject: what requires fedora-release-notes
In-Reply-To: <20090128185647.GG11811@localhost.localdomain>
References: <200901281624.31502.pvrabec@redhat.com>
	<1233166492.8363.230.camel@localhost.localdomain>
	<20090128185647.GG11811@localhost.localdomain>
Message-ID: <200901291939.44023.ville.skytta@iki.fi>

On Wednesday 28 January 2009, Paul W. Frields wrote:
> On Wed, Jan 28, 2009 at 10:14:52AM -0800, Jesse Keating wrote:
> > On Wed, 2009-01-28 at 20:12 +0200, Ville Skytt? wrote:
> > > On Wednesday 28 January 2009, Peter Vrabec wrote:
> > > > fedora-release-notes ~ 5MB
> > >
> > > By the way, at least as of F-9, there's a lot of different language
> > > files included in this package, none of which are marked with %lang, so
> > > %_install_langs doesn't help with the installed size.  I wonder if
> > > that's on purpose?
> >
> > Probably not on purpose.  Paul Frields owns the package, shoot a patch
> > his way?
>
> Yeah, definitely not on purpose.  Patch/bug filing appreciated.

https://bugzilla.redhat.com/show_bug.cgi?id=482947



From christoph.wickert at googlemail.com  Thu Jan 29 17:45:19 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 18:45:19 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<a9d183c80901290353n5b777afdvd9d79ab69f43d6d6@mail.gmail.com>
	<ba23fd9d153477590cb010497d2051b1.squirrel@arekh.dyndns.org>
Message-ID: <1233251119.3741.50.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 14:15 +0100 schrieb Nicolas Mailhot:

> The most important reason for the existence of a a review ticket is to
> make sure someone in a trusted group did review a package. If there is
> any doubt about the quality of one review the checks should start from
> the package that was effectively imported in rawhide, ***NOT*** what
> the reviewer declared checking in the review ticket.

Just for the record: In a perfect world (TM) the reviewer imports
exactly the package that was approved. That's why I also post the
package's md5 in every review.
If there are things that need to be fixed after the review, this should
happen after import, because then everybody can track the changes on the
commits list.

> In case of doubt the information in the review ticket is just as
> likely to be flawed as the package itself, and in the end the package
> we ship is the only thing that really matters.

That's a reason for not allowing people to fix anything between approval
and import. Allowing this should be an exception but no the rule.

> Long check-list cut and pastes where some tests are erroneously pasted
> from another review with this other review value are not unknown of.

Who does that? Most reviewers have their private templates or the public
one (yes, there is one, although it's a draft).

Regards,
Christoph



From a.badger at gmail.com  Thu Jan 29 17:44:39 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 09:44:39 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233249101.3741.41.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<1233187708.6562.1.camel@localhost.localdomain>	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>	<1233192357.3509.9.camel@localhost.localdomain>	<1233226734.3514.39.camel@wicktop.localdomain>	<1233245738.8363.275.camel@localhost.localdomain>	<1233247356.3741.30.camel@wicktop.localdomain>	<1233247955.8363.278.camel@localhost.localdomain>
	<1233249101.3741.41.camel@wicktop.localdomain>
Message-ID: <4981EB07.2050500@gmail.com>

Christoph Wickert wrote:
> Am Donnerstag, den 29.01.2009, 08:52 -0800 schrieb Jesse Keating:
>> No, that's one view of it.
>>
>> It's just a proposal, you're welcome to suggest changes or make your own
>> proposal like Robert did.
> 
> In my very first email in this thread I wrote that I fully support
> Robert's proposal. With a single confinement: Robert suggested this to
> be some automatic process that happens in FAS. I would like to do this
> by mail. IMO this is more simple and more in public. I'd like to be able
> to follow the discussion while FAS is anonymous.
> 
+1 to mail vs FAS.  I like the model adopted for packager sponsors here
being applied to provenpackager.

Although that does make me ask -- is there any reason to have separate
discussions for packager-sponsor and provenpackager?  They have
different powers but not necessarily different reasons for trust (I
expect a sponsor to know the Guidelines and packaging well enough to
sponsor people who can also follow the Guidelines.  I expect
provenpackagers to understand the Guidelines and packaging well enough
to make well--thought-out changes to packages that they don't own.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/af5cf14d/attachment.sig>

From rdieter at math.unl.edu  Thu Jan 29 17:47:53 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 29 Jan 2009 11:47:53 -0600
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
Message-ID: <glsq5t$v0i$1@ger.gmane.org>

Nicolas Mailhot wrote:

> Le Jeu 29 janvier 2009 15:55, Rex Dieter a ?crit :

>> Why is a license audit is blocking an update?
> 
> I don't think it's blocking, IIRC texlive 2008 also demands different
> packaging, and there is a lack of people to do both the technical
> *and* the legal work.

fair nuf.  Where's our TeX SIG? :)

-- Rex



From a.badger at gmail.com  Thu Jan 29 17:46:19 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 09:46:19 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233247356.3741.30.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>	<20090128221957.GA14226@hurricane.linuxnetz.de>	<1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<1233187708.6562.1.camel@localhost.localdomain>	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>	<1233192357.3509.9.camel@localhost.localdomain>	<1233226734.3514.39.camel@wicktop.localdomain>	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
Message-ID: <4981EB6B.4020209@gmail.com>

Christoph Wickert wrote:

> After he was sponsored the new proven packager can sponsor as many other
> "pseudo-proven" packagers as he wants, even if they are not trustworthy.
> Other sponsors have no way to prevent this, so I'm pretty sure we'll end
> up with a large number of proven packagers again pretty soon.
> 
This part actually isn't mentioned in the proposal -- Should people in
provenpackagers automatically be sponsor level (as it is now)?  Or
should we differentiate between provenpackager(users) and
provenpackager(sponsors) as packager is now?

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/e94ba51e/attachment.sig>

From christoph.wickert at googlemail.com  Thu Jan 29 17:54:15 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 18:54:15 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <4981EB07.2050500@gmail.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
	<1233247955.8363.278.camel@localhost.localdomain>
	<1233249101.3741.41.camel@wicktop.localdomain>
	<4981EB07.2050500@gmail.com>
Message-ID: <1233251655.3741.52.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 09:44 -0800 schrieb Toshio Kuratomi:

> > 
> +1 to mail vs FAS.  I like the model adopted for packager sponsors here
> being applied to provenpackager.

+10!

Regards,
Christoph



From tibbs at math.uh.edu  Thu Jan 29 17:58:09 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 29 Jan 2009 11:58:09 -0600
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glsq5t$v0i$1@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glsq5t$v0i$1@ger.gmane.org>
Message-ID: <ufavdryc7v2.fsf@epithumia.math.uh.edu>

>>>>> "RD" == Rex Dieter <rdieter at math.unl.edu> writes:

RD> fair nuf.  Where's our TeX SIG? :)

https://fedoraproject.org/wiki/SIGs/TeX

(well, in theory, at least).

I would be willing to devote a little time to TeX, seeing as how I
kind of have to support it.  However, I don't actually use it (such is
the life of a sysadmin) so I'm not much help for some of the more
bizarre aspects.

I'd just hate to see the whole thing go down in a pile of legal
confusion.  At the very least we'd have to go with the stuff that we
know is legally OK and add more as it is cleared.  Going completely
without TeX is not an option for a large number of folks.

 - J<



From robert at fedoraproject.org  Thu Jan 29 17:59:44 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 18:59:44 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <4981EB6B.4020209@gmail.com>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
	<4981EB6B.4020209@gmail.com>
Message-ID: <20090129175944.GA7259@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Toshio Kuratomi wrote:
> This part actually isn't mentioned in the proposal -- Should people in
> provenpackagers automatically be sponsor level (as it is now)?  Or
> should we differentiate between provenpackager(users) and
> provenpackager(sponsors) as packager is now?

There has to be a difference. Sponsors are higher in the hierarchy rather
users and could cause more damage rather a user that can't sponsor. Getting
that state needs be harder to achieve then.


Greetings,
  Robert



From kevin.kofler at chello.at  Thu Jan 29 18:06:08 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:06:08 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
	<49819222.10602@behdad.org>
	<1233244764.3741.14.camel@wicktop.localdomain>
Message-ID: <glsr6i$3pd$1@ger.gmane.org>

Christoph Wickert wrote:
> a) close the review NOTABUG or

... and get the package actually rejected that way, which is different from
closing a merge review as NOTABUG and having the package still sit there.
(Just clarifying what I'm fairly sure you meant.)

        Kevin Kofler



From nicolas.mailhot at laposte.net  Thu Jan 29 18:10:33 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 19:10:33 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233247557.3741.32.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233214010.19140.10.camel@arekh.okg>
	<1233223503.3514.4.camel@wicktop.localdomain>
	<1334eb2baa865f159e1103167e8d191d.squirrel@arekh.dyndns.org>
	<1233224445.3514.18.camel@wicktop.localdomain>
	<7e54530559bb5d41f802268caac0d6fd.squirrel@arekh.dyndns.org>
	<1233247557.3741.32.camel@wicktop.localdomain>
Message-ID: <1233252633.19140.22.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 17:45 +0100, Christoph Wickert a ?crit :

> Sorry, but you did not answer my question. How do you compare it to
> something that's not there? Ok, you knew the source, but how would you
> know if Sven downloads it correctly, preserves the timestamp etc.? The
> answer is: you didn't, but you trust Sven.

Also, I don't really care a lot, because this is something that will
change the first time upstream updates, and will be caught by the BADURL
autochecks anyway. So the value of me spending a lot of time on it
instead of checking the spec and if upstream is legit is rather limited.

And yes some people could try to spoof an upstream and inject malware in
a source, but they could create a web site and propose packaging a file
from this site almost as easily.

> > If you want to do something useful, I have a pile of packaging changes
> > in my review queue I'd be happy to pass on to someone obcessing about
> > review quality in Fedora.
> 
> Then give me some bz # please.

Basically, all the children of
https://bugzilla.redhat.com/show_bug.cgi?id=477044 which saw packager
activity and changes

Especially all the historic packages where all the remaining legacy
cruft may hide packager mistakes in the modernization of the packages.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/8f7836a1/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 18:12:16 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:12:16 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
Message-ID: <glsri0$3pd$2@ger.gmane.org>

drago01 wrote:
> Did it ever happen that a "provenpackager" or any packager in the days
> of open ACLs cause any real damage to packages (not owned by him)?
> I am not aware of any such cases, it seems to me that we are trying to
> solve a non existing problem.

It's mostly just paranoia, as always when the 's' word ("security") is
involved.

IMHO, all packages should have open ACLs, with no exceptions (yes, even the
kernel!), and I don't think we should make it as hard to get into
provenpackager as some people are suggesting (10 to 15 sponsors needed,
WTF?).

        Kevin Kofler



From nicolas.mailhot at laposte.net  Thu Jan 29 18:14:34 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 19:14:34 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glsr6i$3pd$1@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<1233226137.3514.32.camel@wicktop.localdomain>
	<49819222.10602@behdad.org>
	<1233244764.3741.14.camel@wicktop.localdomain>
	<glsr6i$3pd$1@ger.gmane.org>
Message-ID: <1233252874.19140.24.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 19:06 +0100, Kevin Kofler a ?crit :
> Christoph Wickert wrote:
> > a) close the review NOTABUG or
> 
> ... and get the package actually rejected that way, which is different from
> closing a merge review as NOTABUG and having the package still sit there.
> (Just clarifying what I'm fairly sure you meant.)

I've seen a lot of tickets closed NOTABUg lately. I think it's just been
changed to be the default state on CLOSE, and many closers are not
careful enough to change it.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/e693fb51/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 18:20:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:20:07 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <20090128221957.GA14226@hurricane.linuxnetz.de>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
Message-ID: <glss0n$3pd$3@ger.gmane.org>

Robert Scheck wrote:
> As long as our provenpackager policy is not really fixed, I won't change
> any of my packages to allow provenpackager commits. Instead I will even
> suggest to close packages in Fedora pkgdb and avoid provenpackager
> commits.

>From what I could gather from the FESCo task tracker, that sort of
antisocial and possessive behavior is going to be banned soon. I hope you
will be forced to cooperate or leave.

The provenpackager policy is already being "fixed", if you're still not
happy, then that's too bad for you, you'll have to accept that not everyone
is as paranoid as you.

You need to have a valid justification for restricting access to your
packages.

        Kevin Kofler



From jonathan.underwood at gmail.com  Thu Jan 29 18:20:48 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 18:20:48 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <ufavdryc7v2.fsf@epithumia.math.uh.edu>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glsq5t$v0i$1@ger.gmane.org> <ufavdryc7v2.fsf@epithumia.math.uh.edu>
Message-ID: <645d17210901291020g2f5a4ea2tad786701569f39f9@mail.gmail.com>

2009/1/29 Jason L Tibbitts III <tibbs at math.uh.edu>:
>>>>>> "RD" == Rex Dieter <rdieter at math.unl.edu> writes:
>
> RD> fair nuf.  Where's our TeX SIG? :)
>
> https://fedoraproject.org/wiki/SIGs/TeX
>
> (well, in theory, at least).
>
> I would be willing to devote a little time to TeX, seeing as how I
> kind of have to support it.  However, I don't actually use it (such is
> the life of a sysadmin) so I'm not much help for some of the more
> bizarre aspects.
>
> I'd just hate to see the whole thing go down in a pile of legal
> confusion.  At the very least we'd have to go with the stuff that we
> know is legally OK and add more as it is cleared.  Going completely
> without TeX is not an option for a large number of folks.

Count me in, obviously.

I hope to find a bit of time to write up my notes and thoughts on
tl2008 on a wiki page at the weekend, novovirus permitting.



From a.badger at gmail.com  Thu Jan 29 18:25:42 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 10:25:42 -0800
Subject: Koji error
In-Reply-To: <4981DBE3.8070100@redhat.com>
References: <2c7834580901261512j26829edak30801813522e2b00@mail.gmail.com>	<20090126161914.77b72a8f@ohm.scrye.com>
	<4981DBE3.8070100@redhat.com>
Message-ID: <4981F4A6.1060801@gmail.com>

Mike Bonnet wrote:
> Kevin Fenzi wrote:
>> On Mon, 26 Jan 2009 20:12:11 -0300
>> Allisson Azevedo <allisson at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I can't build perl-MooseX-Async, all branches return this error:
>>
>> Wait a bit and try again.
>> The job that syncs new package info over to koji only runs once an hour
>> or once every 30min. 
> 
> Any reason not to run it every 5 minutes?  I imagine that if there's
> nothing for it to do, it doesn't cost much.
> 
Usually building packages blocks on cvs acl permissions rather than koji
permissions.  Syncing the owner information to koji on an empty run only
takes 20s and the cvs sync takes one and a half minutes, though.  I've
updated the frequency of both runs to every ten minutes.  We'll see how
it goes.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/42884f8f/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 18:31:27 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:31:27 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
Message-ID: <glsslv$3pd$4@ger.gmane.org>

Nicolas Mailhot wrote:
> People who want TEX kept should create a task force and feed TEXlive
> 2008 in rawhide bit by bit, checking for each bit the licensing is ok.
> That's about the only way the burden of checking TEX can be distributed
> enough it won't depend on a couple packagers, when the amount of work is
> too much to be humanly doable by a few people alone in a realistic
> timeframe.

I don't think that makes sense:
* Modular packaging is a lot more work than monolithic packaging.
* If we import TeXlive 2008 piecemeal, we'll have a Rawhide with a broken
mix of a monolithic 2007 package and incomplete split 2008 packages.

We have to upgrade 2007 to 2008 and this should not be blocking on a license
review. No other packages get a license audit on each upgrade, I don't see
why TeXlive should be any different.

We should just upgrade TeXlive and then deal with any licensing issues if
they are found and reported. Redoing an audit at every new version is not
going to scale and nothing in our policies requires it.

        Kevin Kofler



From ville.skytta at iki.fi  Thu Jan 29 18:32:59 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Thu, 29 Jan 2009 20:32:59 +0200
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129065225.GA20693@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
Message-ID: <200901292032.59727.ville.skytta@iki.fi>

On Thursday 29 January 2009, David Tardon wrote:
> On Thu, Jan 29, 2009 at 12:40:43AM +0100, Christoph Wickert wrote:
> > Do RH employes have sponsors too? A lot of the bad reviews are done by
> > RH people and a lot of bad specs come from RH folks. Somebody pointed me
> > to:
> > https://bugzilla.redhat.com/show_bug.cgi?id=433678
> > and I had a quick glance over it before Andreas added his comments:
> >       * no list of tests that have been run
> >       * SourceURL is missing
>
> What about fixing rpmlint to check for missing tags? Just now it simply
> ignores them,

$ grep "^'no-.*-tag'" /usr/share/rpmlint/TagsCheck.py
'no-packager-tag',
'no-version-tag',
'no-release-tag',
'no-name-tag',
'no-summary-tag',
'no-description-tag',
'no-group-tag',
'no-changelogname-tag',
'no-epoch-tag',
'no-url-tag',

The no-packager-tag error is filtered in Fedora's rpmlint config (although I'm 
not quite sure why), and a bunch of others are redundant because rpmbuild 
will fail if the tag is not around, but I think "it simply ignores missing 
tags" is not quite accurate.  If you feel something is missing, feel free to 
file a bug report in Bugzilla or upstream rpmlint tracker.

Regarding "SourceURL is missing", there's no such tag.  I guess the OP meant 
that "SourceX is not a URL" which is something rpmlint could check from spec 
files.  Doing it for all SourceX would probably be quite annoying though - 
it's not unusual at all for packagers to add additional sources to packages 
[0] and making them upload them somewhere just to appease rpmlint doesn't 
sound like a good idea to me.  Perhaps it'd be feasible to check that all 
SourceX that are tarballs, zips and the like are URLs.
http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/165
http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/170

[0] Desktop entries, icons, init scripts, launch scripts, sysconfig snippets, 
other config files, scripts to generate tarballs from scm, etc etc



From jkeating at redhat.com  Thu Jan 29 18:33:21 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 10:33:21 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901292032.59727.ville.skytta@iki.fi>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
Message-ID: <1233254001.8363.281.camel@localhost.localdomain>

On Thu, 2009-01-29 at 20:32 +0200, Ville Skytt? wrote:
>  The no-packager-tag error is filtered in Fedora's rpmlint config
> (although I'm 
> not quite sure why)

Because Packager isn't supposed to be defined in Fedora specs.  That
gets filled in by the build system.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/06ee83ac/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 18:32:21 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:32:21 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
Message-ID: <glssnl$3pd$5@ger.gmane.org>

Nicolas Mailhot wrote:
> Of course new modular packaging of TEX would take care of both issues,
> if enough packagers could be found to submit packages for each part of
> TEX, checking its licensing at the same time.

Modular packaging means several orders of magnitude more work. If we don't
even have the manpower for monolithic packaging, we definitely don't have
it for modular packaging.

        Kevin Kofler



From jkeating at redhat.com  Thu Jan 29 18:37:48 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 10:37:48 -0800
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glsslv$3pd$4@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<glsslv$3pd$4@ger.gmane.org>
Message-ID: <1233254268.8363.283.camel@localhost.localdomain>

On Thu, 2009-01-29 at 19:31 +0100, Kevin Kofler wrote:
>  We have to upgrade 2007 to 2008 and this should not be blocking on a license
> review. No other packages get a license audit on each upgrade, I don't see
> why TeXlive should be any different.
> 
> We should just upgrade TeXlive and then deal with any licensing issues if
> they are found and reported. Redoing an audit at every new version is not
> going to scale and nothing in our policies requires it.

When we suspect, and have already found, improper licenses in a set of
software, we certainly can and should block it from coming in until a
audit is done to clear ourselves of any wrong doing.  Doing otherwise
would be willful infringement.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/9dc83302/attachment.sig>

From notting at redhat.com  Thu Jan 29 18:39:51 2009
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 29 Jan 2009 13:39:51 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901292032.59727.ville.skytta@iki.fi>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
Message-ID: <20090129183951.GE13282@nostromo.devel.redhat.com>

Ville Skytt? (ville.skytta at iki.fi) said: 
> The no-packager-tag error is filtered in Fedora's rpmlint config (although I'm 
> not quite sure why),

We don't require it in the spec file, becuase the build system inserts it.

Bill



From kevin.kofler at chello.at  Thu Jan 29 18:35:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:35:50 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org>
Message-ID: <glssu6$3pd$6@ger.gmane.org>

Neal Becker wrote:
> Really?  I've been reading the texlive list.  I noticed they have been
> dropping many packages due to license issues.

That proves that TeXlive upstream cares about the licensing being Free
Software, why can't we just trust them instead of redoing an audit at every
single upgrade? We already did an audit when importing the 2007 version,
for all other packages that's sufficient (in fact in most cases we trust
the reviewer and don't even go through FE-Legal!), why not here?

        Kevin Kofler



From dominik at greysector.net  Thu Jan 29 18:40:09 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 29 Jan 2009 19:40:09 +0100
Subject: mono-tools and MD for f10
In-Reply-To: <1233246028.6740.59.camel@PB3.Linux>
References: <1233219248.6740.43.camel@PB3.Linux>
	<20090129145417.GG3119@mokona.greysector.net>
	<1233246028.6740.59.camel@PB3.Linux>
Message-ID: <20090129184009.GB20174@mokona.greysector.net>

On Thursday, 29 January 2009 at 17:20, Paul wrote:
> Hi,
> 
> > > If anyone has a few spare cycles, any chance of helping me with a build
> > > of both of these?
> > 
> > Why don't you set up a local repo via ftp, add it to mock config and put
> > the necessary devel packages there?
> 
> Sounds just the job - just one thing, how do I do it?

Similarly to this:

# mkdir -p /var/ftp/pub/fedora/development/i386
# cp -p *.rpm /var/ftp/pub/fedora/development/i386
# createrepo /var/ftp/pub/fedora/development/i386
# service vsftpd start
# vim /etc/mock/fedora-rawhide-i386.cfg

Add these lines before """ at the end of the file.
[local]
name=local
baseurl=ftp://localhost/pub/fedora/development/i386/
enabled=1

# [setarch i686] mock -r fedora-devel-i386 monofoo-2.0-1.src.rpm

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From christoph.wickert at googlemail.com  Thu Jan 29 18:41:52 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Thu, 29 Jan 2009 19:41:52 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901292032.59727.ville.skytta@iki.fi>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
Message-ID: <1233254512.3741.58.camel@wicktop.localdomain>

Am Donnerstag, den 29.01.2009, 20:32 +0200 schrieb Ville Skytt?:
> On Thursday 29 January 2009, David Tardon wrote:
> > On Thu, Jan 29, 2009 at 12:40:43AM +0100, Christoph Wickert wrote:
> > > Do RH employes have sponsors too? A lot of the bad reviews are done by
> > > RH people and a lot of bad specs come from RH folks. Somebody pointed me
> > > to:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=433678
> > > and I had a quick glance over it before Andreas added his comments:
> > >       * no list of tests that have been run
> > >       * SourceURL is missing
> >
> > What about fixing rpmlint to check for missing tags? Just now it simply
> > ignores them,
> 
> $ grep "^'no-.*-tag'" /usr/share/rpmlint/TagsCheck.py
> 'no-packager-tag',
> 'no-version-tag',
> 'no-release-tag',
> 'no-name-tag',
> 'no-summary-tag',
> 'no-description-tag',
> 'no-group-tag',
> 'no-changelogname-tag',
> 'no-epoch-tag',
> 'no-url-tag',

Could you make it also check for
a) empty %doc statement as in xfce4-settings
b) duplicate tags as the duplicate description in ricci?

TIA,
Christoph



From skvidal at fedoraproject.org  Thu Jan 29 18:44:12 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 29 Jan 2009 13:44:12 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glssu6$3pd$6@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org>  <glssu6$3pd$6@ger.gmane.org>
Message-ID: <1233254652.20956.1.camel@rosebud>

On Thu, 2009-01-29 at 19:35 +0100, Kevin Kofler wrote:
> Neal Becker wrote:
> > Really?  I've been reading the texlive list.  I noticed they have been
> > dropping many packages due to license issues.
> 
> That proves that TeXlive upstream cares about the licensing being Free
> Software, why can't we just trust them instead of redoing an audit at every
> single upgrade? We already did an audit when importing the 2007 version,
> for all other packages that's sufficient (in fact in most cases we trust
> the reviewer and don't even go through FE-Legal!), why not here?

It's like cancer. You don't worry about it until you get diagnosed once
as having it. Then you get the checks every year.

We know TexLive has had some issues, so we have to keep checking and
assuming it will have more issues.

-sv




From kevin.kofler at chello.at  Thu Jan 29 18:41:28 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:41:28 +0100
Subject: Lack of update information
References: <497D6B24.8050702@fedoraproject.org>	<20090126120202.GA2548@free.fr>	<2d319b780901260412x3febb577i768aac224db00f68@mail.gmail.com>	<20090126121504.GC2548@free.fr>	<497DAB0F.109@fedoraproject.org>	<7dd7ab490901261137o60d42170l3af53377c3389650@mail.gmail.com>	<497E1340.8000303@fedoraproject.org>	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>	<497E1AE9.20606@fedoraproject.org>	<497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org>	<497F7A2E.90509@poolshark.org>
	<glqf9m$s29$1@ger.gmane.org> <49817907.503@poolshark.org>
Message-ID: <glst8o$3pd$7@ger.gmane.org>

Denis Leroy wrote:
> They do actually, they provide the NEWS files which is a bit shorter
> (although this one is unusually long, they're typically 3 to 4
> bullet-point long) :

OK, so they're trying to make a nice summary, but in this case they weren't
all that successful. :-(

        Kevin Kofler



From nicolas.mailhot at laposte.net  Thu Jan 29 18:51:44 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 19:51:44 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glsslv$3pd$4@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<glsslv$3pd$4@ger.gmane.org>
Message-ID: <1233255104.19140.35.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 19:31 +0100, Kevin Kofler a ?crit :
> Nicolas Mailhot wrote:
> > People who want TEX kept should create a task force and feed TEXlive
> > 2008 in rawhide bit by bit, checking for each bit the licensing is ok.
> > That's about the only way the burden of checking TEX can be distributed
> > enough it won't depend on a couple packagers, when the amount of work is
> > too much to be humanly doable by a few people alone in a realistic
> > timeframe.
> 
> I don't think that makes sense:
> * Modular packaging is a lot more work than monolithic packaging.
> * If we import TeXlive 2008 piecemeal, we'll have a Rawhide with a broken
> mix of a monolithic 2007 package and incomplete split 2008 packages.
> 
> We have to upgrade 2007 to 2008 and this should not be blocking on a license
> review. No other packages get a license audit on each upgrade, I don't see
> why TeXlive should be any different.

One of the changes in TeXlive 2008 is it's supposed to be modular
upstream now. Bundling a modular upstream in a single fedora package is
generally a bad idea

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/ad1859cb/attachment.sig>

From kevin.kofler at chello.at  Thu Jan 29 18:54:07 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:54:07 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<1233226734.3514.39.camel@wicktop.localdomain>
	<1233245738.8363.275.camel@localhost.localdomain>
	<1233247356.3741.30.camel@wicktop.localdomain>
	<4981EB6B.4020209@gmail.com>
	<20090129175944.GA7259@hurricane.linuxnetz.de>
Message-ID: <glsu0f$3pd$8@ger.gmane.org>

Robert Scheck wrote:
> There has to be a difference. Sponsors are higher in the hierarchy rather
> users and could cause more damage rather a user that can't sponsor.
> Getting that state needs be harder to achieve then.

+1 to this. (I don't agree with some of your other suggestions, e.g.
requiring 10 to 15 approvals for a provenpackager, but this one fully makes
sense.)

        Kevin Kofler



From pertusus at free.fr  Thu Jan 29 18:57:03 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Thu, 29 Jan 2009 19:57:03 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
Message-ID: <20090129185703.GB2555@free.fr>

On Thu, Jan 29, 2009 at 04:09:16PM +0100, Nicolas Mailhot wrote:
> 
> Of course new modular packaging of TEX would take care of both issues,
> if enough packagers could be found to submit packages for each part of
> TEX, checking its licensing at the same time.

Something more modular may be nice, going to the granularity of CTAN is
certainly a bad idea. Upstream advocated packaging bundles that are quite
large.

--
Pat



From kevin.kofler at chello.at  Thu Jan 29 18:56:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 19:56:56 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<glsslv$3pd$4@ger.gmane.org>
	<1233254268.8363.283.camel@localhost.localdomain>
Message-ID: <glsu5o$3pd$9@ger.gmane.org>

Jesse Keating wrote:
> When we suspect, and have already found, improper licenses in a set of
> software, we certainly can and should block it from coming in until a
> audit is done to clear ourselves of any wrong doing.  Doing otherwise
> would be willful infringement.

So where are the improper licenses in TeXlive 2008 (which have not already
been filtered out in Fedora since the 2007 version)?

        Kevin Kofler



From Arnaud.Gomes at ircam.fr  Thu Jan 29 19:00:17 2009
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Thu, 29 Jan 2009 20:00:17 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <ufavdryc7v2.fsf@epithumia.math.uh.edu> (Jason L. Tibbitts,
	III's message of "29 Jan 2009 11\:58\:09 -0600")
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glsq5t$v0i$1@ger.gmane.org> <ufavdryc7v2.fsf@epithumia.math.uh.edu>
Message-ID: <y9hk58eym2m.fsf@libation.ircam.fr>

Jason L Tibbitts III <tibbs at math.uh.edu> writes:

> I would be willing to devote a little time to TeX, seeing as how I
> kind of have to support it.  However, I don't actually use it (such is
> the life of a sysadmin) so I'm not much help for some of the more
> bizarre aspects.

Same for me.

-- 
Arnaud



From jonathan.underwood at gmail.com  Thu Jan 29 19:02:35 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 19:02:35 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glssnl$3pd$5@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glssnl$3pd$5@ger.gmane.org>
Message-ID: <645d17210901291102nef7886fua09177859bd14e1f@mail.gmail.com>

2009/1/29 Kevin Kofler <kevin.kofler at chello.at>:
> Nicolas Mailhot wrote:
>> Of course new modular packaging of TEX would take care of both issues,
>> if enough packagers could be found to submit packages for each part of
>> TEX, checking its licensing at the same time.
>
> Modular packaging means several orders of magnitude more work. If we don't
> even have the manpower for monolithic packaging, we definitely don't have
> it for modular packaging.

Not necessarily in this case. From a thousand miles up, the process of
creating texlive upstream basically involves taking packages from ctan
and assembling them into the texlive tree using various scripts
(notably ctan2tl and ctan2tds and others) which is then used to create
the texlive distribution. I've been wondering if it would be possible
to adapt these scripts to be used during RPM build time to package
upstream ctan tarballs. More work needed though. An approach like this
is worth considering though I think. Of course, this applies to
packages and fonts mainly, not the tex binaries.

J.



From pmatilai at laiskiainen.org  Thu Jan 29 19:03:09 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Thu, 29 Jan 2009 21:03:09 +0200 (EET)
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233254512.3741.58.camel@wicktop.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
	<1233254512.3741.58.camel@wicktop.localdomain>
Message-ID: <alpine.LFD.2.00.0901292056330.12514@turre.koti.laiskiainen.org>

On Thu, 29 Jan 2009, Christoph Wickert wrote:

> Am Donnerstag, den 29.01.2009, 20:32 +0200 schrieb Ville Skytt?:
>> On Thursday 29 January 2009, David Tardon wrote:
>>> On Thu, Jan 29, 2009 at 12:40:43AM +0100, Christoph Wickert wrote:
>>>> Do RH employes have sponsors too? A lot of the bad reviews are done by
>>>> RH people and a lot of bad specs come from RH folks. Somebody pointed me
>>>> to:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=433678
>>>> and I had a quick glance over it before Andreas added his comments:
>>>>       * no list of tests that have been run
>>>>       * SourceURL is missing
>>>
>>> What about fixing rpmlint to check for missing tags? Just now it simply
>>> ignores them,
>>
>> $ grep "^'no-.*-tag'" /usr/share/rpmlint/TagsCheck.py
>> 'no-packager-tag',
>> 'no-version-tag',
>> 'no-release-tag',
>> 'no-name-tag',
>> 'no-summary-tag',
>> 'no-description-tag',
>> 'no-group-tag',
>> 'no-changelogname-tag',
>> 'no-epoch-tag',
>> 'no-url-tag',
>
> Could you make it also check for
> a) empty %doc statement as in xfce4-settings
> b) duplicate tags as the duplicate description in ricci?

Instead of piling weird checks things like these two into rpmlint, file 
them as rpm bugs (rpm.org Trac is preferred for non-Fedora specific 
issues), rpmbuild shouldn't permit such things in the first place.

 	- Panu -



From ville.skytta at iki.fi  Thu Jan 29 19:07:18 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 29 Jan 2009 21:07:18 +0200
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <1233254001.8363.281.camel@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
	<1233254001.8363.281.camel@localhost.localdomain>
Message-ID: <200901292107.19012.ville.skytta@iki.fi>

On Thursday 29 January 2009, Jesse Keating wrote:
> On Thu, 2009-01-29 at 20:32 +0200, Ville Skytt? wrote:
> >  The no-packager-tag error is filtered in Fedora's rpmlint config
> > (although I'm
> > not quite sure why)
>
> Because Packager isn't supposed to be defined in Fedora specs.  That
> gets filled in by the build system.

Sure, I know.  rpmlint does not run this check on spec files, but rpms.

But then again, I suppose not filtering it would cause unnecessary fuss in 
package reviews where the reviewed packages (created by the submitter or 
built by the reviewer) quite likely lack it.  Ditto signatures, messages 
about missing ones are similarly filtered out for them as well.



From jkeating at redhat.com  Thu Jan 29 19:14:09 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 11:14:09 -0800
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glsu5o$3pd$9@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <1233212932.19140.6.camel@arekh.okg>
	<glsslv$3pd$4@ger.gmane.org>
	<1233254268.8363.283.camel@localhost.localdomain>
	<glsu5o$3pd$9@ger.gmane.org>
Message-ID: <1233256449.8363.286.camel@localhost.localdomain>

On Thu, 2009-01-29 at 19:56 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > When we suspect, and have already found, improper licenses in a set of
> > software, we certainly can and should block it from coming in until a
> > audit is done to clear ourselves of any wrong doing.  Doing otherwise
> > would be willful infringement.
> 
> So where are the improper licenses in TeXlive 2008 (which have not already
> been filtered out in Fedora since the 2007 version)?
> 
>         Kevin Kofler

That's a spot question.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/d9a3579a/attachment.sig>

From robert at fedoraproject.org  Thu Jan 29 19:28:43 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 20:28:43 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <8dc3b8e100eaffb39737b596f03b0a37.squirrel@arekh.dyndns.org>
References: <20090128234545.GA23208@hurricane.linuxnetz.de>
	<glqsn0$8g0$2@ger.gmane.org>
	<20090129003719.GA23887@hurricane.linuxnetz.de>
	<49810FFD.5000106@behdad.org>
	<20090129073446.GB5712@hurricane.linuxnetz.de>
	<49819545.5010604@behdad.org>
	<20090129133250.GA11392@hurricane.linuxnetz.de>
	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
	<Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>
	<8dc3b8e100eaffb39737b596f03b0a37.squirrel@arekh.dyndns.org>
Message-ID: <20090129192843.GA16011@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Nicolas Mailhot wrote:
> He suggested a little more than that and no I don't believe this would
> be a positive result for Fedora. (even assuming enough community
> packagers could be found to replace the existing packagers)

Interesting, that you believe knowing more than me as writer of the text ;)

If a downstream and upstream maintainer wants to focus on upstream rather
on downstream, he/she/it could look for a new maintainer and itself step
down getting just co-maintainer - especially if he/she/it is not interested
in enhancing own RPM packaging skills (which is strange for a packager).
Very similar to this is just to look for a co-maintainer and let him/her do
more packaging work rather bugfixing and upstream <-> downstream handling.

And to repeat myself once more: We still need more quality rather quantity
in Fedora - this also affects packaging.


Greetings,
  Robert



From tcallawa at redhat.com  Thu Jan 29 19:32:43 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Jan 2009 14:32:43 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glssu6$3pd$6@ger.gmane.org>
References: <497599B2.6030203@gmx.net>
	<4980DC1C.8000505@redhat.com>	<glr4gb$qno$1@ger.gmane.org>
	<glssu6$3pd$6@ger.gmane.org>
Message-ID: <4982045B.3020405@redhat.com>

On 2009-01-29 at 13:35:50 -0500, Kevin Kofler <kevin.kofler at chello.at>
wrote:
> Neal Becker wrote:
>> Really?  I've been reading the texlive list.  I noticed they have been
>> dropping many packages due to license issues.
> 
> That proves that TeXlive upstream cares about the licensing being Free
> Software, why can't we just trust them instead of redoing an audit at every
> single upgrade? We already did an audit when importing the 2007 version,
> for all other packages that's sufficient (in fact in most cases we trust
> the reviewer and don't even go through FE-Legal!), why not here?

Because we know it is bad.

Let me start putting facts on the table:

In texlive-texmf-20080822, there are three main directories:

texmf/
texmf-dist/
texmf-doc/

Assuming that texmf-doc/ is all documentation, I focused my initial
audit on texmf/ and texmf-dist/.

texmf/ has 1269 files in it.
texmf-dist/ has 58326 files in it.

I finished auditing texmf/. Of the files in there, I could not determine
any licensing information for 615 (48.5%) contain no licensing
information whatsoever. One file claims to be "BSD-style", but the
license text is missing.

I've barely scratched the surface of texmf-dist, but I have already found:

- texmf-dist/fonts/type1/public/cs/* is under the BaKoMa-CM.Fonts license
  (http://www.netlib.org/bibnet/BaKoMa-CM.Fonts) which is non-free.
- texmf-dist/fonts/truetype/public/xepersian/IranNastaliq.ttf is non-free
- texmf-dist/fonts/truetype/public/xepersian/koodak.ttf is non-free, due
to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/LateefRegOT.ttf is non-free
- texmf-dist/fonts/truetype/public/xepersian/royab.ttf is non-free, due
to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/ScheherazadeRegOT.ttf is
non-free
- texmf-dist/fonts/truetype/public/xepersian/terafikb.ttf is non-free,
due to modification restrictions
- texmf-dist/fonts/truetype/public/xepersian/terafik.ttf is non-free,
due to modification restrictions

I cannot find licensing for:
- texmf-dist/fonts/type1/arphic/*
- texmf-dist/fonts/type1/bluesky/*

Also, given that the licensing information is almost never included in
the texlive fonts themselves, nor is the documentation packaged next to
the files, I have to try to unravel what file belongs to what
documentation and make guesses about the licensing.

I have tens of thousands of files still to audit, just in this tarball,
not even getting to the main texlive package.

~spot



From robert at fedoraproject.org  Thu Jan 29 19:34:26 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 20:34:26 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glsri0$3pd$2@ger.gmane.org>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<glsri0$3pd$2@ger.gmane.org>
Message-ID: <20090129193426.GB16011@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Kevin Kofler wrote:
> IMHO, all packages should have open ACLs, with no exceptions (yes, even the
> kernel!), and I don't think we should make it as hard to get into
> provenpackager as some people are suggesting (10 to 15 sponsors needed,
> WTF?).

That every new packager having a single package can touch the kernel, glibc
and gcc? Nice idea, yes. That would bring up the word "playground" again, I
used today already.


Greetings,
  Robert



From konrad at tylerc.org  Thu Jan 29 19:47:49 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Thu, 29 Jan 2009 11:47:49 -0800
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129193426.GB16011@hurricane.linuxnetz.de>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<glsri0$3pd$2@ger.gmane.org>
	<20090129193426.GB16011@hurricane.linuxnetz.de>
Message-ID: <200901291147.49386.konrad@tylerc.org>

On Thursday 29 January 2009 11:34:26 am Robert Scheck wrote:
> On Thu, 29 Jan 2009, Kevin Kofler wrote:
> > IMHO, all packages should have open ACLs, with no exceptions (yes, even
> > the kernel!), and I don't think we should make it as hard to get into
> > provenpackager as some people are suggesting (10 to 15 sponsors needed,
> > WTF?).
>
> That every new packager having a single package can touch the kernel, glibc
> and gcc? Nice idea, yes. That would bring up the word "playground" again, I
> used today already.
>
>
> Greetings,
>   Robert

You think a newbie packager is just going to dive in and accidentally screw up 
gcc and glibc without, say, contacting the owner(s) first? I can see two 
possible cases for your sarcasm here:

  1) newbie tries to fix something without consulting owners at all
  2) newbie (actually, someone malevolant trying to break Fedora because they 
hate Robert Scheck) breaks package intentionally

In either case, the package owner gets an email summarizing changes to CVS, 
and can revert the CVS change. If the newbie was malevolant and/or the problem 
persists, they can be kicked out of Fedora. If not, they learned their lesson 
(similar to Wikipedia's "please go play in the sandbox, kid").

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>



From kevin.kofler at chello.at  Thu Jan 29 19:52:15 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 20:52:15 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glssnl$3pd$5@ger.gmane.org>
	<645d17210901291102nef7886fua09177859bd14e1f@mail.gmail.com>
Message-ID: <glt1dg$qp5$1@ger.gmane.org>

Jonathan Underwood wrote:
> Not necessarily in this case. From a thousand miles up, the process of
> creating texlive upstream basically involves taking packages from ctan
> and assembling them into the texlive tree using various scripts
> (notably ctan2tl and ctan2tds and others) which is then used to create
> the texlive distribution. I've been wondering if it would be possible
> to adapt these scripts to be used during RPM build time to package
> upstream ctan tarballs. More work needed though. An approach like this
> is worth considering though I think. Of course, this applies to
> packages and fonts mainly, not the tex binaries.

And who handles the dozens of review requests? Our review queue is already
flooded!

        Kevin Kofler



From ville.skytta at iki.fi  Thu Jan 29 19:54:48 2009
From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=)
Date: Thu, 29 Jan 2009 21:54:48 +0200
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <alpine.LFD.2.00.0901292056330.12514@turre.koti.laiskiainen.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233254512.3741.58.camel@wicktop.localdomain>
	<alpine.LFD.2.00.0901292056330.12514@turre.koti.laiskiainen.org>
Message-ID: <200901292154.48697.ville.skytta@iki.fi>

On Thursday 29 January 2009, Panu Matilainen wrote:
> On Thu, 29 Jan 2009, Christoph Wickert wrote:
>
> > Could you make it also check for
> > a) empty %doc statement as in xfce4-settings
> > b) duplicate tags as the duplicate description in ricci?
>
> Instead of piling weird checks things like these two into rpmlint, file
> them as rpm bugs (rpm.org Trac is preferred for non-Fedora specific
> issues), rpmbuild shouldn't permit such things in the first place.

b) filed as http://rpm.org/ticket/27



From kevin.kofler at chello.at  Thu Jan 29 19:52:52 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Thu, 29 Jan 2009 20:52:52 +0100
Subject: TeXlive 2008 in Fedora 11?
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<20090129185703.GB2555@free.fr>
Message-ID: <glt1el$qp5$2@ger.gmane.org>

Patrice Dumas wrote:
> Something more modular may be nice, going to the granularity of CTAN is
> certainly a bad idea. Upstream advocated packaging bundles that are quite
> large.

Something like the KDE modules?

        Kevin Kofler



From nicolas.mailhot at laposte.net  Thu Jan 29 19:59:30 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 29 Jan 2009 20:59:30 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glt1dg$qp5$1@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glssnl$3pd$5@ger.gmane.org>
	<645d17210901291102nef7886fua09177859bd14e1f@mail.gmail.com>
	<glt1dg$qp5$1@ger.gmane.org>
Message-ID: <1233259170.19140.48.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 20:52 +0100, Kevin Kofler a ?crit :
> Jonathan Underwood wrote:
> > Not necessarily in this case. From a thousand miles up, the process of
> > creating texlive upstream basically involves taking packages from ctan
> > and assembling them into the texlive tree using various scripts
> > (notably ctan2tl and ctan2tds and others) which is then used to create
> > the texlive distribution. I've been wondering if it would be possible
> > to adapt these scripts to be used during RPM build time to package
> > upstream ctan tarballs. More work needed though. An approach like this
> > is worth considering though I think. Of course, this applies to
> > packages and fonts mainly, not the tex binaries.
> 
> And who handles the dozens of review requests? Our review queue is already
> flooded!

Not having a human check the license of each file is what got us into
legal problems in the first place.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/a50365be/attachment.sig>

From robert at fedoraproject.org  Thu Jan 29 20:02:56 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 21:02:56 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901291147.49386.konrad@tylerc.org>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<glsri0$3pd$2@ger.gmane.org>
	<20090129193426.GB16011@hurricane.linuxnetz.de>
	<200901291147.49386.konrad@tylerc.org>
Message-ID: <20090129200256.GC16011@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Conrad Meyer wrote:
> In either case, the package owner gets an email summarizing changes to CVS, 
> and can revert the CVS change. If the newbie was malevolant and/or the problem 
> persists, they can be kicked out of Fedora. If not, they learned their lesson 
> (similar to Wikipedia's "please go play in the sandbox, kid").

We usually make a Package Review BEFORE a package goes into Fedora. Why
should somebody be allowed to change something at a package being in Fedora
without having it reviewed BEFORE the CVE commit by somebody else (in this
case by the package maintainer)? If we drive this way, we seriously do not
really need a package review, we can fix/correct stuff always afterwards.
A very interesting thought, you've brought me to. This even would solve my
claims regarding the Merge Reviews. And Wikipedia also works this way - so
everybody can do everything (also create new pages, which equals to Fedora
CVS imports) and if it's considered harmful/low quality, it's handled then
afterwards. What is preventing us from letting initial CVS branchings every
packager do on itself and performing no longer any package review in front
of the CVS branching/import?

This is a real thought, no kidding or irony. That would make us just more
open as we currently are. Yes, I know you don't believe me that, after all
of my e-mails now, but I really have spent some time to think about that.


Greetings,
  Robert



From jonathan.underwood at gmail.com  Thu Jan 29 20:06:00 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 20:06:00 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <glt1dg$qp5$1@ger.gmane.org>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glqr30$4l0$1@ger.gmane.org> <glsg32$lh0$1@ger.gmane.org>
	<720e77dced57774b5846ed035198bff5.squirrel@arekh.dyndns.org>
	<glssnl$3pd$5@ger.gmane.org>
	<645d17210901291102nef7886fua09177859bd14e1f@mail.gmail.com>
	<glt1dg$qp5$1@ger.gmane.org>
Message-ID: <645d17210901291206r62a73d72q4e6bd808a8c3b58c@mail.gmail.com>

2009/1/29 Kevin Kofler <kevin.kofler at chello.at>:
> Jonathan Underwood wrote:
>> Not necessarily in this case. From a thousand miles up, the process of
>> creating texlive upstream basically involves taking packages from ctan
>> and assembling them into the texlive tree using various scripts
>> (notably ctan2tl and ctan2tds and others) which is then used to create
>> the texlive distribution. I've been wondering if it would be possible
>> to adapt these scripts to be used during RPM build time to package
>> upstream ctan tarballs. More work needed though. An approach like this
>> is worth considering though I think. Of course, this applies to
>> packages and fonts mainly, not the tex binaries.
>
> And who handles the dozens of review requests? Our review queue is already
> flooded!

Well, whatever happens, a review is going to be needed for the
collection RPMs. I wasn't imagining one RPM per ctan package :).



From choeger at cs.tu-berlin.de  Thu Jan 29 20:19:26 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 29 Jan 2009 21:19:26 +0100
Subject: look at this: samsung nc10 bootchart with mobil V2
Message-ID: <1233260366.4952.29.camel@choeger6>

Hey there, 

hereby starting the next "what services are really needed" flamewar ;).

No, really, have a look at that bootchart:

 http://www.phoronix.com/scan.php?page=article&item=intel_moblin_2&num=2

They claim that their netbook boots in 7-8s with moblin alpha. 

Ok, they start xfce instead of gnome/kde but just think of booting that
thing into gdm. This would already completely exceed the 10s startup
feature of fedora 12.

And look at what they start: udev, hal, dbus, all those things that tend
to slow down boot are there (well, no sendmail daemon).

So how can they do that?


-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/32759cc2/attachment.sig>

From cweyl at alumni.drew.edu  Thu Jan 29 20:20:27 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Thu, 29 Jan 2009 12:20:27 -0800
Subject: Lack of update information
In-Reply-To: <1233223684.6470.48.camel@blaa>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org> <497F7A2E.90509@poolshark.org>
	<glqf9m$s29$1@ger.gmane.org> <49817907.503@poolshark.org>
	<1233223684.6470.48.camel@blaa>
Message-ID: <7dd7ab490901291220x14b7c911lc8d7e634be924488@mail.gmail.com>

On Thu, Jan 29, 2009 at 2:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> > Good job :-) But this whole exercise is futile. We DO ALREADY ship both
> > the ChangeLog and the NEWS files in the documentation directory, either
> > with the library or development package. How is repeating or summarizing
> > these internal changes *on Bodhi* useful to anyone ?
>
> Kevin's summary does something the NEWS file does not - it calls out a
> particular crasher bug that could affect user applications. IMHO, that
> is the only truly compelling reason a user has to apply this update and
> it is the most user relevant part of Kevin's description.

We already provide the ability to link to bugs in the update; I don't
see the logic in duplicating the information here.

                              -Chris
--
Chris Weyl
Ex astris, scientia



From robert at fedoraproject.org  Thu Jan 29 20:21:33 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 21:21:33 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glss0n$3pd$3@ger.gmane.org>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
Message-ID: <20090129202133.GD16011@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Kevin Kofler wrote:
> You need to have a valid justification for restricting access to your
> packages.

When answering an e-mail a few minutes ago, I was thinking, why we don't
kill restrictions at all - but then without any exceptions. That would make
Package and Merge Reviews completely unnecessary. Every packager can import
what is liked and if the change/package/... doesn't work afterwards, we've
a VCS and can undo it. So why then spending times and ressources on Reviews
as we currently do?

Another scheme, which we didn't brought up until now is the same as our
friends from kernel.org do: Let's approve every commit by multiple people
also known as packagers - without any exception. Single user commits then
should not be possible.

I know, that this won't be taken serious, but it's a serious thought on my
side. No need to fuss around with provenpackager guidelines, package and
merge reviews and AWOL maintainers.


Greetings,
  Robert



From loganjerry at gmail.com  Thu Jan 29 20:26:24 2009
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 29 Jan 2009 13:26:24 -0700
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <4982045B.3020405@redhat.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
Message-ID: <870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>

On Thu, Jan 29, 2009 at 12:32 PM, Tom spot Callaway <tcallawa at redhat.com>wrote:

> I cannot find licensing for:
> - texmf-dist/fonts/type1/arphic/*
> - texmf-dist/fonts/type1/bluesky/*
>

FWIW, information on the Blue Sky fonts can be found here:

http://www.ams.org/tex/type1-fonts.html

For the arphic fonts, see this:

http://www.arphic.com/usa/news/news.htm
-- 
Jerry James
http://loganjerry.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/9a380fb4/attachment.htm>

From thomas.moschny at gmail.com  Thu Jan 29 20:30:12 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 29 Jan 2009 21:30:12 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901291147.49386.konrad@tylerc.org>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<glsri0$3pd$2@ger.gmane.org>
	<20090129193426.GB16011@hurricane.linuxnetz.de>
	<200901291147.49386.konrad@tylerc.org>
Message-ID: <a9d183c80901291230wa042896yaaa684a197695066@mail.gmail.com>

2009/1/29 Conrad Meyer <konrad at tylerc.org>:
> In either case, the package owner gets an email summarizing changes to CVS,
> and can revert the CVS change. If the newbie was malevolant and/or the problem
> persists, they can be kicked out of Fedora. If not, they learned their lesson
> (similar to Wikipedia's "please go play in the sandbox, kid").

Unless (as I was told today on IRC, did not try that myself) there's
still some sort of long-standing bug allowing you to suppress that
email by pressing ctrl-c at the right moment.

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From dominik at greysector.net  Thu Jan 29 20:44:43 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 29 Jan 2009 21:44:43 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129202133.GD16011@hurricane.linuxnetz.de>
References: <1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
Message-ID: <20090129204443.GD20174@mokona.greysector.net>

On Thursday, 29 January 2009 at 21:21, Robert Scheck wrote:
> On Thu, 29 Jan 2009, Kevin Kofler wrote:
> > You need to have a valid justification for restricting access to your
> > packages.
> 
> When answering an e-mail a few minutes ago, I was thinking, why we don't
> kill restrictions at all - but then without any exceptions. That would make
> Package and Merge Reviews completely unnecessary. Every packager can import
> what is liked and if the change/package/... doesn't work afterwards, we've
> a VCS and can undo it. So why then spending times and ressources on Reviews
> as we currently do?
> 
> Another scheme, which we didn't brought up until now is the same as our
> friends from kernel.org do: Let's approve every commit by multiple people
> also known as packagers - without any exception. Single user commits then
> should not be possible.
> 
> I know, that this won't be taken serious, but it's a serious thought on my
> side. No need to fuss around with provenpackager guidelines, package and
> merge reviews and AWOL maintainers.

How about we require at least one co-maintainer per package and all packages
that don't have two maintainers in, say, 6 months from now get dropped?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From robert at fedoraproject.org  Thu Jan 29 20:51:27 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Thu, 29 Jan 2009 21:51:27 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129204443.GD20174@mokona.greysector.net>
References: <1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
Message-ID: <20090129205127.GA23519@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Dominik 'Rathann' Mierzejewski wrote:
> How about we require at least one co-maintainer per package and all packages
> that don't have two maintainers in, say, 6 months from now get dropped?

With which benefit, if we remove the right to package mantainers to forbid
provenpackager commits except for some special canditates needing FESco? If
everybody can touch anything, why a co-maintainer?


Greetings,
  Robert



From tcallawa at redhat.com  Thu Jan 29 20:55:33 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Jan 2009 15:55:33 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
References: <497599B2.6030203@gmx.net>
	<4980DC1C.8000505@redhat.com>	<glr4gb$qno$1@ger.gmane.org>
	<glssu6$3pd$6@ger.gmane.org>	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
Message-ID: <498217C5.2040809@redhat.com>

On 2009-01-29 at 15:26:24 -0500, Jerry James <loganjerry at gmail.com> wrote:
> On Thu, Jan 29, 2009 at 12:32 PM, Tom spot Callaway <tcallawa at redhat.com>wrote:
> 
>> I cannot find licensing for:
>> - texmf-dist/fonts/type1/arphic/*
>> - texmf-dist/fonts/type1/bluesky/*
>>
> 
> FWIW, information on the Blue Sky fonts can be found here:
> 
> http://www.ams.org/tex/type1-fonts.html

Would be nice if that was in texlive somewhere (heck, it might be!).

> For the arphic fonts, see this:
> 
> http://www.arphic.com/usa/news/news.htm

That's not a license. Its a mangled translation at best. However, it did
stir my memory:

http://ftp.gnu.org/gnu/non-gnu/chinese-fonts-truetype/LICENSE

So, at least those two items are taken care of, thanks. Want some more
to try to hunt down? :)

~spot



From dominik at greysector.net  Thu Jan 29 21:04:10 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 29 Jan 2009 22:04:10 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129205127.GA23519@hurricane.linuxnetz.de>
References: <1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
Message-ID: <20090129210410.GF20174@mokona.greysector.net>

On Thursday, 29 January 2009 at 21:51, Robert Scheck wrote:
> On Thu, 29 Jan 2009, Dominik 'Rathann' Mierzejewski wrote:
> > How about we require at least one co-maintainer per package and all packages
> > that don't have two maintainers in, say, 6 months from now get dropped?
> 
> With which benefit, if we remove the right to package mantainers to forbid
> provenpackager commits except for some special canditates needing FESco? If
> everybody can touch anything, why a co-maintainer?

Well, even with provenpackagers, it's not like they will start committing
left and right into other people's packages. A co-maintainer is expected
to be the first person to step in when the other maintainer is unable to
do his job.

I'd also make it mandatory for provenpackagers to be members of at least
one SIG like KDE, Server, Games etc., i.e. ones that deal with certain
group of software packages so that their area of expertise is at least
somewhat defined.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From habig at neutrino.d.umn.edu  Thu Jan 29 21:07:55 2009
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Thu, 29 Jan 2009 15:07:55 -0600
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <498217C5.2040809@redhat.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
Message-ID: <20090129210755.GA13260@neutrino.d.umn.edu>

If texlive is such a can of worms, why not "downgrade" to tetex?  That's
still the RHEL tex solution.  As a latex user, I noticed no functional
difference between the two other than that I have to go re-setup local
configuration stuff when fedora changed from tetex to texlive.

      Alec

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/



From loganjerry at gmail.com  Thu Jan 29 21:14:46 2009
From: loganjerry at gmail.com (Jerry James)
Date: Thu, 29 Jan 2009 14:14:46 -0700
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <498217C5.2040809@redhat.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
Message-ID: <870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>

On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
> So, at least those two items are taken care of, thanks. Want some more
> to try to hunt down? :)

The name "Blue Sky" just happened to stir my memory, and I attempted
to be a good citizen by hunting down the arphic fonts at the same
time, which triggered your memory.  If you have a list of unknowns
handy, I think posting it here could be very valuable, as it may
trigger yet more memories.
--
Jerry James
http://loganjerry.googlepages.com/



From tibbs at math.uh.edu  Thu Jan 29 21:16:42 2009
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: 29 Jan 2009 15:16:42 -0600
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090129210755.GA13260@neutrino.d.umn.edu>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<20090129210755.GA13260@neutrino.d.umn.edu>
Message-ID: <ufa63jxdd8l.fsf@epithumia.math.uh.edu>

>>>>> "ATH" == Alec T Habig <habig at neutrino.d.umn.edu> writes:

ATH> If texlive is such a can of worms, why not "downgrade" to tetex?

Is there some reason to believe that tetex was any better in this
regard?

ATH> That's still the RHEL tex solution.  As a latex user, I noticed
ATH> no functional difference between the two other than that I have
ATH> to go re-setup local configuration stuff when fedora changed from
ATH> tetex to texlive.

I have had various users here (the math department at a large
university) who have issues with either bugs or missing packages in
tetex that are solved by texlive.  The TeX mindset is that you must
always have every package in existence installed because you must
always be able to compile every document you might ever come across,
so random missing packages actually do cause problems for some users.

 - J<



From thomas.moschny at gmail.com  Thu Jan 29 21:25:36 2009
From: thomas.moschny at gmail.com (Thomas Moschny)
Date: Thu, 29 Jan 2009 22:25:36 +0100
Subject: mono-tools and MD for f10
In-Reply-To: <20090129184009.GB20174@mokona.greysector.net>
References: <1233219248.6740.43.camel@PB3.Linux>
	<20090129145417.GG3119@mokona.greysector.net>
	<1233246028.6740.59.camel@PB3.Linux>
	<20090129184009.GB20174@mokona.greysector.net>
Message-ID: <a9d183c80901291325u7c70b201n423fcca8e01673d3@mail.gmail.com>

2009/1/29 Dominik 'Rathann' Mierzejewski <dominik at greysector.net>:
> Similarly to this:
>
> # mkdir -p /var/ftp/pub/fedora/development/i386
> # cp -p *.rpm /var/ftp/pub/fedora/development/i386
> # createrepo /var/ftp/pub/fedora/development/i386
> # service vsftpd start
> # vim /etc/mock/fedora-rawhide-i386.cfg
>
> Add these lines before """ at the end of the file.
> [local]
> name=local
> baseurl=ftp://localhost/pub/fedora/development/i386/
> enabled=1

Using baseurl=file:///var/ftp/pub/fedora/development/i386/ it even
works without actually running the ftp server.

-- 
Thomas Moschny <thomas.moschny at gmail.com>



From habig at neutrino.d.umn.edu  Thu Jan 29 21:27:51 2009
From: habig at neutrino.d.umn.edu (Alec T. Habig)
Date: Thu, 29 Jan 2009 15:27:51 -0600
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <ufa63jxdd8l.fsf@epithumia.math.uh.edu>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<20090129210755.GA13260@neutrino.d.umn.edu>
	<ufa63jxdd8l.fsf@epithumia.math.uh.edu>
Message-ID: <20090129212751.GB13260@neutrino.d.umn.edu>

Jason L Tibbitts III writes:
> 
> Is there some reason to believe that tetex was any better in this
> regard?

Only that I assume RH's lawyers are more rabid about licenses than
Fedora's, having a giant market capitalization to protect.

Of course, if spot's actually the point man for both, then all bets are
off :)

> I have had various users here (the math department at a large
> university) who have issues with either bugs or missing packages in
> tetex that are solved by texlive. 

I'm sure that the actively maintained version is better than the
orphaned one overall.  But, if licensing issues crept into the new that
weren't in the old one (which did pass muster at some point, anyway),
having some version of tex available is infinitely better than no
version.

Of course, if removed from Fedora the rpms will fork over to a
third-party repository somewhere anyhow, but that's sub-optimal for an
application that's been a core part of unix since long before linux
wandered on to the scene.

After all, without tex how would we compile the nethack manual?  :)

-- 
 	    Alec Habig, University of Minnesota Duluth Physics Dept.
	    		    habig at neutrino.d.umn.edu
		       http://neutrino.d.umn.edu/~habig/



From bmaly at redhat.com  Thu Jan 29 21:29:55 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 29 Jan 2009 16:29:55 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233260366.4952.29.camel@choeger6>
References: <1233260366.4952.29.camel@choeger6>
Message-ID: <49821FD3.4020801@redhat.com>

Christoph H?ger wrote:
> Hey there, 
>
> hereby starting the next "what services are really needed" flamewar ;).
>
> No, really, have a look at that bootchart:
>
>  http://www.phoronix.com/scan.php?page=article&item=intel_moblin_2&num=2
>
> They claim that their netbook boots in 7-8s with moblin alpha. 
>
> Ok, they start xfce instead of gnome/kde but just think of booting that
> thing into gdm. This would already completely exceed the 10s startup
> feature of fedora 12.
>
> And look at what they start: udev, hal, dbus, all those things that tend
> to slow down boot are there (well, no sendmail daemon).
>
> So how can they do that?
>
>
>   
This model has a SD card. Such a card is big enough to use as you /boot 
partition (i.e. big enough to store your kernel, initrd, ramdisk etc). 
This configuration will boot much faster than off a hard drive. Embedded 
linux systems boot just as quickly if you use the same type card for 
your boot partition. You then use a ramdisk for the root fs. This is the 
model which most embedded systems that run linux use. They boot fast and 
run fast. Usually you run the root fs in ram and mount only /usr and 
/home off a real hard drive.

Brian







From skvidal at fedoraproject.org  Thu Jan 29 21:30:31 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Thu, 29 Jan 2009 16:30:31 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090129212751.GB13260@neutrino.d.umn.edu>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<20090129210755.GA13260@neutrino.d.umn.edu>
	<ufa63jxdd8l.fsf@epithumia.math.uh.edu>
	<20090129212751.GB13260@neutrino.d.umn.edu>
Message-ID: <1233264631.20956.11.camel@rosebud>

On Thu, 2009-01-29 at 15:27 -0600, Alec T. Habig wrote:
> Jason L Tibbitts III writes:
> > 
> > Is there some reason to believe that tetex was any better in this
> > regard?
> 
> Only that I assume RH's lawyers are more rabid about licenses than
> Fedora's, having a giant market capitalization to protect.

They're the same lawyers.


-sv




From behdad at behdad.org  Thu Jan 29 21:34:47 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Thu, 29 Jan 2009 16:34:47 -0500
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>
References: <1233181287.8363.246.camel@localhost.localdomain>	<1233182104.3786.19.camel@wicktop.localdomain>	<1233182932.8363.252.camel@localhost.localdomain>	<1233186043.3786.40.camel@wicktop.localdomain>	<20090128234545.GA23208@hurricane.linuxnetz.de>	<glqsn0$8g0$2@ger.gmane.org>	<20090129003719.GA23887@hurricane.linuxnetz.de>	<49810FFD.5000106@behdad.org>	<20090129073446.GB5712@hurricane.linuxnetz.de>	<49819545.5010604@behdad.org>	<20090129133250.GA11392@hurricane.linuxnetz.de>	<b231bcb38bf3ce1685ef917d4783c53f.squirrel@arekh.dyndns.org>
	<Pine.LNX.4.58.0901291604350.7805@gate.bb.dicp.net>
Message-ID: <498220F7.1020603@behdad.org>

Andreas Thienemann wrote:
> 
> 	Go and orphan your packages, if you want to focus just on 
> 	upstream.
> 
> He's not advocating forcing people out or forcing them to orphan packages. 
> What he suggests is that people wanting to concentrate on upstream 
> development are able to do that without being burdened by maintaining 
> packages for distributions.

I think I agree with Nicolas here.  It's true that my focus is on upstream
development, but I care about Fedora and try to be a good citizen.  Like
Nicolas said, the more mature packages don't need much packaging attention
anyway.  Lets look at cairo:  We don't hold even a single cairo patch in
Fedora.  And here is the ChangeLog from devel:

* Fri Nov 21 2008 Matthias Clasen <mclasen at redhat.com> 1.8.0-2
- Tweak %%summary and %%documentation

* Thu Sep 25 2008 Behdad Esfahbod <besfahbo at redhat.com> 1.8.0-1
- Update to 1.8.0
- Update dep versions

* Mon Sep 22 2008 Behdad Esfahbod <besfahbo at redhat.com> 1.7.6-1
- Update to 1.7.6

* Mon Aug 11 2008 Matthias Clasen <mclasen at redhat.com> 1.7.4-1
- Update to 1.7.4

* Wed May 21 2008 Tom "spot" Callaway <tcallawa at redhat.com> 1.6.4-3
- fix license tag

* Sun May  4 2008 Matthias Clasen <mclasen at redhat.com> 1.6.4-2
- Fix source url

I'm the owner.  What's wrong with working the way we do?  Trusting our fellows
and just spending time on what really matters, as opposed to, eg, this thread?
 Why should I orphan my packages if there's nothing wrong with the way I
attend to them, even if that means almost no time spent on them and zero RPM
knowledge?


Finally, again, I agree with Nicolas.  You are discounting the value of having
the upstream maintainer or developer keep an eye on the Fedora package.  I
blame Ubuntu on a regular basis for pushing bogus patches in their packages.
Fedora core packages have a much higher quality compare to Ubuntu, and I like
to believe that it's because many of those packages are maintained by their
upstream maintainers.  YMMV.

behdad



From a.badger at gmail.com  Thu Jan 29 21:45:11 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 13:45:11 -0800
Subject: Draft: simple update description guidelines
In-Reply-To: <20090129111140.654efe7a.mschwendt@gmail.com>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>
	<20090129111140.654efe7a.mschwendt@gmail.com>
Message-ID: <49822367.50602@gmail.com>

Michael Schwendt wrote:
> On Wed, 28 Jan 2009 12:14:48 +0000, Mark wrote:
> 
>> Okay, here's an attempt:
>>
>>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
>>
>> Cheers,
>> Mark.
> 
>> = Package Update Guidelines =
> 
>> == Maintaining Stability ==
> 
>> == Update Descriptions ==
> 
>> == Rate of Updates ==
> 
> Much better, an effort much appreciated, although this is way beyond
> the subject of this thread. ;) Such a document goes into the right
> direction, since it tries to explain Fedora's fundamental update
> strategy and may come as a surprise to some packagers. It will be very
> interesting to hear what FESCo members think about the contents.
> 
+1

There's two grounds on which to discuss this:

1) The tone and scope of the document.  I think this gets that spot on.
 It explains what we're trying to achieve with updates rather than how
to achieve it.  There are examples of why doing something is good or bad
but leaves the final judgement up to the maintainer and the cases they
need to solve.

2) The philosophy.  Do we agree with the goals that are expressed here?
 The document is asking that maintainers limit the number of updates
that they do for end user benefit.  Others have said that they use
Fedora precisely for the number of updates that are issued.  Is one of
these the true goal that represents 90% of our opinions?  Do we want to
try to  give a place to both sides?

Myself, I like running a system that gets frequent updates but I'm
willing to curb the number of updates I issue to users.  I'd probably
push packages to updates-testing and let them site there without going
to updates without a user request/good reason if that fits into the big
picture.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/fafbd6e0/attachment.sig>

From tcallawa at redhat.com  Thu Jan 29 21:26:17 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Jan 2009 16:26:17 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
Message-ID: <49821EF9.4040108@redhat.com>

Please, if you're a packager, take a moment and go read this:

https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description

After talking with Red Hat Legal about how we should be handling
trademarks in package summaries and descriptions, we came to the
conclusion that it would be far easier (and less risky for Red Hat) if
we did not use "(TM)" or "(R)" notations at all. This does not mean that
you can use trademarks freely, you still need to be careful in how you
use them. When in doubt, try not to use it. If you have questions, you
can either email me or fedora-legal at redhat.com.

Thanks in advance,

Tom Callaway, Fedora Legal

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce



From choeger at cs.tu-berlin.de  Thu Jan 29 22:14:10 2009
From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=)
Date: Thu, 29 Jan 2009 23:14:10 +0100
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <49821FD3.4020801@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
Message-ID: <1233267250.4952.36.camel@choeger6>

Yep that's true. But note that the other netbook tested (lenovo s10)
boots in about 20s into XFCE.
That gives us a factor of 4 between ssds and hds.
Basically that means that a boot time of <20s (to gdm) is definitely
possible even on outdated hardware.

My question is simply: How do they (the intel developers) reach that
boot time without removing all those comfort services (udev etc.)?

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/879f26ca/attachment.sig>

From vonbrand at inf.utfsm.cl  Thu Jan 29 22:45:35 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 29 Jan 2009 19:45:35 -0300
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <49816501.5050309@redhat.com>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233181287.8363.246.camel@localhost.localdomain>
	<1233182104.3786.19.camel@wicktop.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<49816501.5050309@redhat.com>
Message-ID: <200901292245.n0TMjZ9M003499@laptop14.inf.utfsm.cl>

Alexander Kurtakov <akurtako at redhat.com> wrote:
> drago01 wrote:

[...]

> > Did it ever happen that a "provenpackager" or any packager in the days
> > of open ACLs cause any real damage to packages (not owned by him)?
> > I am not aware of any such cases, it seems to me that we are trying to
> > solve a non existing problem.

Perhaps the packager community has grown a lot since then?

> I'm simply trying to think of a solution for both sides -
> paranoic-about-security and believe-in-good-will.

The problem is that what you as a packager prefer does impact _all_
users. And in such a situation you should prefer to fall to the paranoic
side.
-- 
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 tcallawa at redhat.com  Thu Jan 29 22:46:06 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Thu, 29 Jan 2009 17:46:06 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
References: <497599B2.6030203@gmx.net>
	<4980DC1C.8000505@redhat.com>	<glr4gb$qno$1@ger.gmane.org>
	<glssu6$3pd$6@ger.gmane.org>	<4982045B.3020405@redhat.com>	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
Message-ID: <498231AE.6050801@redhat.com>

On 2009-01-29 at 16:14:46 -0500, Jerry James <loganjerry at gmail.com> wrote:
> On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway <tcallawa at redhat.com> wrote:
>> So, at least those two items are taken care of, thanks. Want some more
>> to try to hunt down? :)
> 
> The name "Blue Sky" just happened to stir my memory, and I attempted
> to be a good citizen by hunting down the arphic fonts at the same
> time, which triggered your memory.  If you have a list of unknowns
> handy, I think posting it here could be very valuable, as it may
> trigger yet more memories.
> --
> Jerry James
> http://loganjerry.googlepages.com/
> 

Okay, here are more files I can't find licensing for (all from
texlive-texmf-20080822):

(These are all the unlicensed files in the "texmf/" directory):
texmf/dvipdfm/*
texmf/dvipdfmx/*
texmf/dvips/base/*
texmf/dvips/config/*
texmf/fmtutil/*
texmf/fonts/enc/dvips/afm2pl/*
texmf/fonts/enc/ttf2pk/base/*
texmf/fonts/lig/afm2pl/*
texmf/fonts/map/*
texmf/fonts/sfd/*
texmf/hbf2gf/*
texmf/scripts/*
texmf/scripts/epstopdf/epstopdf.pl
texmf/tex/*
texmf/texconfig/*
texmf/texdoc/*
texmf/texdoctk/*
texmf/ttf2pk/*
texmf/web2c/*
texmf/xdvi/*
texmf/xindy/*

(These are just some of the unlicensed files in the "texmf-dist/"
directory, there are lots more I haven't had a chance to look at yet)
texmf-dist/fonts/type1/arabi/farsiweb/homa.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazlib.pfb
texmf-dist/fonts/type1/arabi/farsiweb/nazli.pfb
texmf-dist/fonts/type1/arabi/farsiweb/titr.pfb
texmf-dist/fonts/truetype/public/belleek/blex.ttf
texmf-dist/fonts/truetype/public/belleek/blsy.ttf
texmf-dist/fonts/truetype/public/belleek/rblmi.ttf
texmf-dist/fonts/truetype/public/itrans/itxbeng.ttf
texmf-dist/fonts/truetype/public/itrans/itxguj.ttf
texmf-dist/fonts/truetype/public/itrans/ncpi____.ttf
texmf-dist/fonts/truetype/public/itrans/ncpr____.ttf
texmf-dist/fonts/truetype/public/itrans/xdvng.ttf
texmf-dist/fonts/type1/groff/freeeuro.pfa
texmf-dist/fonts/type1/hoekwater/context/*
texmf-dist/fonts/type1/hoekwater/manfnt/manfnt.pfb
texmf-dist/fonts/type1/hoekwater/mflogo/*
texmf-dist/fonts/type1/hoekwater/stmaryrd/*
texmf-dist/fonts/type1/jmn/hans/*
texmf-dist/fonts/type1/public/arabtex/*
texmf-dist/fonts/type1/public/augie/augie___.pfb
texmf-dist/fonts/type1/public/aurical/*
texmf-dist/fonts/type1/public/burmese/burm.pfb
texmf-dist/fonts/type1/public/esint-type1/esint10.pfb
texmf-dist/fonts/type1/public/esvect/*
texmf-dist/fonts/type1/public/gothic/*
texmf-dist/fonts/type1/public/itrans/*
texmf-dist/fonts/type1/public/montex/*
texmf-dist/fonts/type1/public/ocherokee/*
texmf-dist/fonts/type1/public/oinuit/*
texmf-dist/fonts/type1/public/omega/*
texmf-dist/fonts/type1/public/pl/*
texmf-dist/fonts/type1/public/yhmath/yhcmex.pfb
texmf-dist/fonts/type1/uhc/umj/*



From bmaly at redhat.com  Thu Jan 29 22:57:30 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 29 Jan 2009 17:57:30 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233267250.4952.36.camel@choeger6>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6>
Message-ID: <4982345A.2030301@redhat.com>

Christoph H?ger wrote:
> Yep that's true. But note that the other netbook tested (lenovo s10)
> boots in about 20s into XFCE.
> That gives us a factor of 4 between ssds and hds.
> Basically that means that a boot time of <20s (to gdm) is definitely
> possible even on outdated hardware.
>
> My question is simply: How do they (the intel developers) reach that
> boot time without removing all those comfort services (udev etc.)?
>
>   
(1) its UEFI
(2) rc stuff is parallelized (/rc_parallel/="YES") during the startup of 
the rc scripts
(3) /boot lives on the solid state disk and root fs runs in ramdisk

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/f9eb8949/attachment.htm>

From martin.sourada at gmail.com  Thu Jan 29 22:57:39 2009
From: martin.sourada at gmail.com (Martin Sourada)
Date: Thu, 29 Jan 2009 23:57:39 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <1233189522.3131.24.camel@matthiasc>
References: <497599B2.6030203@gmx.net>  <4980DC1C.8000505@redhat.com>
	<1233189522.3131.24.camel@matthiasc>
Message-ID: <1233269859.3136.117.camel@pc-notebook>

On Wed, 2009-01-28 at 19:38 -0500, Matthias Clasen wrote:
> On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway wrote:
> > On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet at gmx.net> wrote:
> > > Hi,
> > > 
> > > are there any plans for updating texlive to 2008 in Leonidas?
> > 
> > I'd have to say the chances of this are extremely unlikely. I'm much
> > more inclined to propose that we drop texlive altogether. It is a
> > licensing nightmare, a tangled bundle of millions of files with little
> > apparent organizational structure, and no overarching licensing
> > analysis. I started trying to do a license audit on texlive 2008, but it
> > would probably take me at least a month of doing nothing except auditing
> > texlive to finish it.
> > 
> > To be fair, the existing texlive has the same problems, I just was
> > unaware of the scope of things until recently.
> > 
> 
> Right, who needs those oldfashioned TeX users anyway... ?!
> 

Er... you are not serious here, are you... There isn't any other
solution to type math formulae both fast and neat. I use TeX (csplain)
on daily basis... There's nothing oldfashioned about TeX, especially
around Physicists and Mathematicians.

But back to the main topic... TeTeX didn't have licensing issues? I'd
guess it had, seeing how cs fonts (which I use) seem to be licensed
under nonfree license (or so I understand what spot said somewhere in
this thread)... How other distributions (especially RHEL, SUSE and
Debian) handle these issues? I wouldn't want Fedora to be the only
distribution in the world without TeX just because its licensing is a
catastrophic mess...

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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/1086e36b/attachment.sig>

From jonathan.underwood at gmail.com  Thu Jan 29 23:13:21 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 23:13:21 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090129210755.GA13260@neutrino.d.umn.edu>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<20090129210755.GA13260@neutrino.d.umn.edu>
Message-ID: <645d17210901291513nf66f304s3c14da61fa8515@mail.gmail.com>

2009/1/29 Alec T. Habig <habig at neutrino.d.umn.edu>:
> If texlive is such a can of worms, why not "downgrade" to tetex?  That's
> still the RHEL tex solution.  As a latex user, I noticed no functional
> difference between the two other than that I have to go re-setup local
> configuration stuff when fedora changed from tetex to texlive.

For reference: Roughly speaking, when Jindrich put the texlive 2007
packages together, he looked at what packages were in tetex and
packaged those up - i.e. the Fedora texlive packages are a subset of
the full texlive 2007 distribution comprisiing more or less an updated
tetex.

Jonathan (Hoping Jindrich will correct me if I am wrong).



From singularitaet at gmx.net  Thu Jan 29 23:12:56 2009
From: singularitaet at gmx.net (Stefan Grosse)
Date: Fri, 30 Jan 2009 00:12:56 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <498231AE.6050801@redhat.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
Message-ID: <20090130001256.506d105c@gmx.net>

Hm well I never thought about licensing issues regarding LaTeX... 

When I look at:
http://tug.org/texlive/copying.html
They state:

"To the best of our knowledge, all the software in TeX Live meets the
requirements of the Free Software Foundation's definition of free
software, and the Debian Free Software Guidelines. Where the two
conflict, we generally follow the FSF."

So maybe you dont want to rely on such a statement. But that makes
quite an effort. 

Some of the mentioned packages also where in tetex which was part in
fedora before and no one complained about license issues.

On Thu, 29 Jan 2009 17:46:06 -0500 "Tom \"spot\" Callaway"
<tcallawa at redhat.com> wrote:
TC> texmf/dvipdfmx/*

dvipdfmx at least is GPL see readme:
http://www.ctan.org/tex-archive/dviware/dvipdfmx/

It would be really sad removing texlive for those license oddities. It
would be quite some competitive disadvantage.

Stefan



From mclasen at redhat.com  Thu Jan 29 23:14:22 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Thu, 29 Jan 2009 18:14:22 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <1233269859.3136.117.camel@pc-notebook>
References: <497599B2.6030203@gmx.net>  <4980DC1C.8000505@redhat.com>
	<1233189522.3131.24.camel@matthiasc>
	<1233269859.3136.117.camel@pc-notebook>
Message-ID: <1233270862.7235.9.camel@matthiasc>

On Thu, 2009-01-29 at 23:57 +0100, Martin Sourada wrote:
> On Wed, 2009-01-28 at 19:38 -0500, Matthias Clasen wrote:
> > On Wed, 2009-01-28 at 17:28 -0500, Tom "spot" Callaway wrote:
> > > On 2009-01-20 at 4:30:26 -0500, Stefan Grosse <singularitaet at gmx.net> wrote:
> > > > Hi,
> > > > 
> > > > are there any plans for updating texlive to 2008 in Leonidas?
> > > 
> > > I'd have to say the chances of this are extremely unlikely. I'm much
> > > more inclined to propose that we drop texlive altogether. It is a
> > > licensing nightmare, a tangled bundle of millions of files with little
> > > apparent organizational structure, and no overarching licensing
> > > analysis. I started trying to do a license audit on texlive 2008, but it
> > > would probably take me at least a month of doing nothing except auditing
> > > texlive to finish it.
> > > 
> > > To be fair, the existing texlive has the same problems, I just was
> > > unaware of the scope of things until recently.
> > > 
> > 
> > Right, who needs those oldfashioned TeX users anyway... ?!
> > 
> 
> Er... you are not serious here, are you... There isn't any other
> solution to type math formulae both fast and neat. I use TeX (csplain)
> on daily basis... There's nothing oldfashioned about TeX, especially
> around Physicists and Mathematicians.

Yeah, I omitted the sarcasm tag. I'm an old TeX user myself. You can
probably find a few of my contributions on ctan if you look hard
enough...

I totally agree that Fedora without TeX would feel very incomplete.



From oget.fedora at gmail.com  Thu Jan 29 23:54:47 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Thu, 29 Jan 2009 18:54:47 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <498231AE.6050801@redhat.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
Message-ID: <e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>

On Thu, Jan 29, 2009 at 5:46 PM, Tom spot Callaway  wrote:
> On 2009-01-29 at 16:14:46 -0500, Jerry James   wrote:
>> On Thu, Jan 29, 2009 at 1:55 PM, Tom spot Callaway   wrote:
>>> So, at least those two items are taken care of, thanks. Want some more
>>> to try to hunt down? :)
>>
>> The name "Blue Sky" just happened to stir my memory, and I attempted
>> to be a good citizen by hunting down the arphic fonts at the same
>> time, which triggered your memory.  If you have a list of unknowns
>> handy, I think posting it here could be very valuable, as it may
>> trigger yet more memories.
>> --
>> Jerry James
>> http://loganjerry.googlepages.com/
>>
>
> Okay, here are more files I can't find licensing for (all from
> texlive-texmf-20080822):
>
> (These are all the unlicensed files in the "texmf/" directory):
> texmf/dvipdfm/*
> texmf/dvipdfmx/*
> texmf/dvips/base/*
> texmf/dvips/config/*
> texmf/fmtutil/*
> texmf/fonts/enc/dvips/afm2pl/*
> texmf/fonts/enc/ttf2pk/base/*
> texmf/fonts/lig/afm2pl/*
> texmf/fonts/map/*
> texmf/fonts/sfd/*
> texmf/hbf2gf/*
> texmf/scripts/*
> texmf/scripts/epstopdf/epstopdf.pl
> texmf/tex/*
> texmf/texconfig/*
> texmf/texdoc/*
> texmf/texdoctk/*
> texmf/ttf2pk/*
> texmf/web2c/*
> texmf/xdvi/*
> texmf/xindy/*
>
> (These are just some of the unlicensed files in the "texmf-dist/"
> directory, there are lots more I haven't had a chance to look at yet)
> texmf-dist/fonts/type1/arabi/farsiweb/homa.pfb
> texmf-dist/fonts/type1/arabi/farsiweb/nazlib.pfb
> texmf-dist/fonts/type1/arabi/farsiweb/nazli.pfb
> texmf-dist/fonts/type1/arabi/farsiweb/titr.pfb
> texmf-dist/fonts/truetype/public/belleek/blex.ttf
> texmf-dist/fonts/truetype/public/belleek/blsy.ttf
> texmf-dist/fonts/truetype/public/belleek/rblmi.ttf
> texmf-dist/fonts/truetype/public/itrans/itxbeng.ttf
> texmf-dist/fonts/truetype/public/itrans/itxguj.ttf
> texmf-dist/fonts/truetype/public/itrans/ncpi____.ttf
> texmf-dist/fonts/truetype/public/itrans/ncpr____.ttf
> texmf-dist/fonts/truetype/public/itrans/xdvng.ttf
> texmf-dist/fonts/type1/groff/freeeuro.pfa
> texmf-dist/fonts/type1/hoekwater/context/*
> texmf-dist/fonts/type1/hoekwater/manfnt/manfnt.pfb
> texmf-dist/fonts/type1/hoekwater/mflogo/*
> texmf-dist/fonts/type1/hoekwater/stmaryrd/*
> texmf-dist/fonts/type1/jmn/hans/*
> texmf-dist/fonts/type1/public/arabtex/*
> texmf-dist/fonts/type1/public/augie/augie___.pfb
> texmf-dist/fonts/type1/public/aurical/*
> texmf-dist/fonts/type1/public/burmese/burm.pfb
> texmf-dist/fonts/type1/public/esint-type1/esint10.pfb
> texmf-dist/fonts/type1/public/esvect/*
> texmf-dist/fonts/type1/public/gothic/*
> texmf-dist/fonts/type1/public/itrans/*
> texmf-dist/fonts/type1/public/montex/*
> texmf-dist/fonts/type1/public/ocherokee/*
> texmf-dist/fonts/type1/public/oinuit/*
> texmf-dist/fonts/type1/public/omega/*
> texmf-dist/fonts/type1/public/pl/*
> texmf-dist/fonts/type1/public/yhmath/yhcmex.pfb
> texmf-dist/fonts/type1/uhc/umj/*
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>


You can find information on many of these TeX packages by going to:

http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=XXX

Replace XXX with dvipdfm, web3c, arabtex etc.

Wow... Thinking about removing TeX from Fedora? I can't imagine how
many people will leave Fedora in the first minute with no hesitation.

Orcan



From jonathan.underwood at gmail.com  Thu Jan 29 23:59:23 2009
From: jonathan.underwood at gmail.com (Jonathan Underwood)
Date: Thu, 29 Jan 2009 23:59:23 +0000
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
Message-ID: <645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>

2009/1/29 Orcan Ogetbil <oget.fedora at gmail.com>:
> Wow... Thinking about removing TeX from Fedora? I can't imagine how
> many people will leave Fedora in the first minute with no hesitation.

Noone's suggested that (in any seriousness)... this is about moving
beyond texlive 2007 which is presently in Fedora.

J.



From drepper at redhat.com  Fri Jan 30 00:48:59 2009
From: drepper at redhat.com (Ulrich Drepper)
Date: Thu, 29 Jan 2009 16:48:59 -0800
Subject: stricter C++ prototypes
Message-ID: <49824E7B.20103@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sometime soon we'll have gcc 4.4 in rawhide as the new system compiler.
 This alone might bring with it changes in the C++ language acceptance
(I don't know details).

What I want to warn people about is another change which will come in
combination with the next glibc.  For a long time some of the function
prototypes for string functions you get when including <cstring> and
<cwchar> (or the underlying C headers) are wrong.  Only for C++, C is
not affected.

   char *strchr (const char *, int)

should be

   char *strchr (char *, int)
and
   const char *strchr (const char *, int)

I.e., the const is preserved correctly.

The result of this that some incorrect programs might not compile
anymore.  For strchr this might look like this:

int foo (const char *s)
{
  char *p = strchr (s, 'f');
  return p == 0 || p[1] == '\0';
}

Previously this worked fine.  strchr returned a value of type char*.
Now, and correctly, it returned a const char*.  But in C++ assigning a
const T* value to a T* variable is an *error* (not a cause for a warning).

I expect the fixes are simple in most cases.  Don't just use casts, use
correct types for the variables etc.  This type safety helps to
eliminate bugs in the code.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmCTnsACgkQ2ijCOnn/RHQFYACdHhWrdTZ9pheyuhurPnSW5fn0
cd4AoKkBmdKyVrpLV4NxxFgMk35gxEry
=gGoC
-----END PGP SIGNATURE-----



From wb8rcr at arrl.net  Fri Jan 30 00:52:22 2009
From: wb8rcr at arrl.net (John J. McDonough)
Date: Thu, 29 Jan 2009 19:52:22 -0500
Subject: stricter C++ prototypes
References: <49824E7B.20103@redhat.com>
Message-ID: <97BA5670030A49F7B7C8AEDE8CBFA69F@Aidan>


----- Original Message ----- 
From: "Ulrich Drepper" <drepper at redhat.com>
To: "Development discussions related to Fedora Core" 
<fedora-devel-list at redhat.com>
Sent: Thursday, January 29, 2009 7:48 PM
Subject: stricter C++ prototypes



> Sometime soon we'll have gcc 4.4 in rawhide as the
> new system compiler.

Ulrich,

I assume "sometime soon" means after Fedora 11?

--McD



From drepper at redhat.com  Fri Jan 30 01:05:29 2009
From: drepper at redhat.com (Ulrich Drepper)
Date: Thu, 29 Jan 2009 17:05:29 -0800
Subject: stricter C++ prototypes
In-Reply-To: <97BA5670030A49F7B7C8AEDE8CBFA69F@Aidan>
References: <49824E7B.20103@redhat.com>
	<97BA5670030A49F7B7C8AEDE8CBFA69F@Aidan>
Message-ID: <49825259.7000207@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John J. McDonough wrote:
> I assume "sometime soon" means after Fedora 11?

No.  F11 will use gcc 4.4.  It'll land soon and AFAIK there will be a
mass-rebuild using this compiler.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmCUlkACgkQ2ijCOnn/RHS7NgCgndlR0mvxcOlxJ0ekQXNHDT7/
Y1oAn0Qssvf6MwlOAEEqVwYHt1XlOsqK
=t/a6
-----END PGP SIGNATURE-----



From jonstanley at gmail.com  Fri Jan 30 01:18:43 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Thu, 29 Jan 2009 20:18:43 -0500
Subject: Plan for tomorrow's (20090130) FESCo meeting
Message-ID: <da159fda0901291718m18045ccel93acecb5a1e8ff57@mail.gmail.com>

Sorry for getting this out so late.

Here's the  list of items that will come up at tomorrow's FESCo
meeting.  We have a very full agenda.

28	Stronger Hashes
36	Architecture Support -
https://fedoraproject.org/wiki/Features/ArchitectureSupport
37	Crash catcher - https://fedoraproject.org/wiki/Features/CrashCatcher
38	DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS
39	Firefox 3.1 - https://fedoraproject.org/wiki/Features/Firefox_3.1
40	OpenChange - https://fedoraproject.org/wiki/Features/OpenChange
41	SsytemTap Static Probes -
https://fedoraproject.org/wiki/Features/SystemtapStaticProbes
42	GCC 4.4 - https://fedoraproject.org/wiki/Features/gcc4.4
43	Repackaging of Fedora Fonts -
https://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts
34	Package Renaming Guidelines
35	vmware-requirements_ and other 'crutch-for-proprietary-software' packages
44	Update description guidelines -
https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
45	provenpackager proposal -
https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor.

Thanks!
-Jon



From wolfy at nobugconsulting.ro  Fri Jan 30 01:37:03 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Fri, 30 Jan 2009 03:37:03 +0200
Subject: Plan for tomorrow's (20090130) FESCo meeting
In-Reply-To: <da159fda0901291718m18045ccel93acecb5a1e8ff57@mail.gmail.com>
References: <da159fda0901291718m18045ccel93acecb5a1e8ff57@mail.gmail.com>
Message-ID: <498259BF.7030505@nobugconsulting.ro>

On 01/30/2009 03:18 AM, Jon Stanley wrote:
> Sorry for getting this out so late.
>
> Here's the  list of items that will come up at tomorrow's FESCo
> meeting.  We have a very full agenda.
>
> 28	Stronger Hashes
> 36	Architecture Support -
> https://fedoraproject.org/wiki/Features/ArchitectureSupport
> 37	Crash catcher - https://fedoraproject.org/wiki/Features/CrashCatcher
> 38	DebugInfoFS - https://fedoraproject.org/wiki/Features/DebuginfoFS
> 39	Firefox 3.1 - https://fedoraproject.org/wiki/Features/Firefox_3.1
> 40	OpenChange - https://fedoraproject.org/wiki/Features/OpenChange
> 41	SsytemTap Static Probes -
> https://fedoraproject.org/wiki/Features/SystemtapStaticProbes
> 42	GCC 4.4 - https://fedoraproject.org/wiki/Features/gcc4.4
> 43	Repackaging of Fedora Fonts -
> https://fedoraproject.org/wiki/Features/Repackaging_of_Fedora_fonts
> 34	Package Renaming Guidelines
> 35	vmware-requirements_ and other 'crutch-for-proprietary-software' packages
> 44	Update description guidelines -
> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> 45	provenpackager proposal -
> https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal
>
> For more complete details, please visit each individual ticket.  The
> report of the agenda items can be found at
> https://fedorahosted.org/fesco/report/9
>
> If you would like to add something to this agenda, you can reply to
> this e-mail, file a new ticket at https://fedorahosted.org/fesco,
> e-mail me directly, or bring it up at the end of the meeting, during
> the open floor.
>   
I would like to call for a revisit of OVM 
(https://bugzilla.redhat.com/show_bug.cgi?id=474980 ) in view of 
decoupling it's inclusion in Fedora of any other package (iverilog or 
anything else). My argumentation is at 
https://bugzilla.redhat.com/show_bug.cgi?id=474980#c17
Thank you.

    manuel



From vonbrand at inf.utfsm.cl  Fri Jan 30 01:37:31 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Thu, 29 Jan 2009 22:37:31 -0300
Subject: stricter C++ prototypes
In-Reply-To: <49825259.7000207@redhat.com>
References: <49824E7B.20103@redhat.com>
	<97BA5670030A49F7B7C8AEDE8CBFA69F@Aidan>
	<49825259.7000207@redhat.com>
Message-ID: <200901300137.n0U1bWnA006706@laptop14.inf.utfsm.cl>

Ulrich Drepper <drepper at redhat.com> wrote:
> John J. McDonough wrote:
> > I assume "sometime soon" means after Fedora 11?
> 
> No.  F11 will use gcc 4.4.  It'll land soon and AFAIK there will be a
> mass-rebuild using this compiler.

Could the changed headers (at least) be pushed out (or made available
somewhere) earlier to start fixing stuff? If is makes sense, timing-wise.
-- 
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 drepper at redhat.com  Fri Jan 30 01:59:34 2009
From: drepper at redhat.com (Ulrich Drepper)
Date: Thu, 29 Jan 2009 17:59:34 -0800
Subject: stricter C++ prototypes
In-Reply-To: <200901300137.n0U1bWnA006706@laptop14.inf.utfsm.cl>
References: <49824E7B.20103@redhat.com>
	<97BA5670030A49F7B7C8AEDE8CBFA69F@Aidan>
	<49825259.7000207@redhat.com>
	<200901300137.n0U1bWnA006706@laptop14.inf.utfsm.cl>
Message-ID: <49825F06.6050802@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Horst H. von Brand wrote:
> Could the changed headers (at least) be pushed out (or made available
> somewhere) earlier to start fixing stuff? If is makes sense, timing-wise.

Shouldn't be necessary and it would also not be that easy since it has
to be done differently for older gccs.  gcc 4.4 is hopefully landing in
rawhide within two weeks or so.

If somebody is interested in changing their own installed headers, take
this patch

http://people.redhat.com/drepper/d-cpp-correct-proto

In addition the installed <cstring> and <wchar> have to be changed.  The
declarations in those files have to be removed.

- --
? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmCXwYACgkQ2ijCOnn/RHTSxQCfRw+uhfURy472w1NI8OuuxZRw
sAAAn14RwdsCrYgc5v8WZGmHrvRYTZOw
=RVjy
-----END PGP SIGNATURE-----



From MathStuf at gmail.com  Fri Jan 30 02:28:25 2009
From: MathStuf at gmail.com (Ben Boeckel)
Date: Thu, 29 Jan 2009 21:28:25 -0500
Subject: Unresponsive Maintianer: salimma
Message-ID: <gltoka$1tq$1@ger.gmane.org>

Over a month ago, a bug was filed 
(https://bugzilla.redhat.com/show_bug.cgi?id=476119) requesting that Falcon 
be updated to 0.8.14 (it is currently 0.8.10). The maintainer has not 
responded at all (multiple requests from upstream to update and one from 
me). At least version 0.8.12 is needed in order to enable the Kross module 
for Falcon in kdebindings (currently disabled).

There have been builds by salimma for his other packages (recently in fact: 
http://koji.fedoraproject.org:80/koji/buildinfo?buildID=80649), so he's not 
AWOL. What should the next course of action be? Not sure if this qualifies 
for the Non-responsive policy since he is active. If it does, I'll go that 
route.

--Ben




From dkaylor at gmail.com  Fri Jan 30 02:42:23 2009
From: dkaylor at gmail.com (David Kaylor)
Date: Thu, 29 Jan 2009 21:42:23 -0500
Subject: Problem with ndesk-dbus packages?
Message-ID: <94a5bde10901291842n3b855a0bo44952c371298614a@mail.gmail.com>

Tasque recently started failing and it seems to be related to the ndesk-dbus
and ndesk-dbus-glib packages.  Running "tasque --debug" shows the following:

** (Tasque:11501): WARNING **: Symbol file
/usr/lib64/mono/gac/NDesk.
DBus.GLib/1.0.0.0__f6716e4f9b2ed099/NDesk.DBus.GLib.dll.mdb
has incorrect version (expected 50.0, got 39)

** (Tasque:11501): WARNING **: Symbol file
/usr/lib64/mono/gac/NDesk.DBus/1.0.0.0__f6716e4f9b2ed099/NDesk.DBus.dll.mdb
has
incorrect version (expected 50.0, got 39)

Rebuilding the packages locally fixes the problem for me.

-Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/2f5f43ff/attachment.htm>

From silfreed at silfreed.net  Fri Jan 30 02:47:33 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Thu, 29 Jan 2009 21:47:33 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49821EF9.4040108@redhat.com>
References: <49821EF9.4040108@redhat.com>
Message-ID: <49826A45.4030809@silfreed.net>

Tom "spot" Callaway wrote:
> Please, if you're a packager, take a moment and go read this:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description
> 

Hope you don't mind the discussion on-list; I thought further examples might help.

I have to packages that are for configuring Logitech Harmony remotes.  That's
all they do - they don't support any other devices.

The summaries for them are:
concordance: Software to program the Logitech? Harmony? remote control
libconcord: Library to talk to Logitech? Harmony? universal remote controls

So, under this new guideline should I just remove the ?'s?  Is the rest of the
information safe?

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/30bbc44a/attachment.sig>

From a.badger at gmail.com  Fri Jan 30 03:12:01 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Thu, 29 Jan 2009 19:12:01 -0800
Subject: Unresponsive Maintianer: salimma
In-Reply-To: <gltoka$1tq$1@ger.gmane.org>
References: <gltoka$1tq$1@ger.gmane.org>
Message-ID: <49827001.6080800@gmail.com>

Ben Boeckel wrote:
> Over a month ago, a bug was filed 
> (https://bugzilla.redhat.com/show_bug.cgi?id=476119) requesting that Falcon 
> be updated to 0.8.14 (it is currently 0.8.10). The maintainer has not 
> responded at all (multiple requests from upstream to update and one from 
> me). At least version 0.8.12 is needed in order to enable the Kross module 
> for Falcon in kdebindings (currently disabled).
> 
> There have been builds by salimma for his other packages (recently in fact: 
> http://koji.fedoraproject.org:80/koji/buildinfo?buildID=80649), so he's not 
> AWOL. What should the next course of action be? Not sure if this qualifies 
> for the Non-responsive policy since he is active. If it does, I'll go that 
> route.
> 
Email directly; offer to comaintain.

You can document those steps in the bug report if you want to start the
Non-responsive policy.

salimma is around.  But if he doesn't have time for the package, having
someone as a comaintainer will help.  Or perhaps prompt him to tell you
there's a reason he doesn't want to update.

-Toshio


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/41498eae/attachment.sig>

From notting at redhat.com  Fri Jan 30 03:54:04 2009
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 29 Jan 2009 22:54:04 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <4982345A.2030301@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
Message-ID: <20090130035404.GC4570@nostromo.devel.redhat.com>

Brian Maly (bmaly at redhat.com) said: 
>> My question is simply: How do they (the intel developers) reach that
>> boot time without removing all those comfort services (udev etc.)?
>>   
> (1) its UEFI

1) I've *NEVER* seen an EFI BIOS that wasn't abysmally slow
2) bootchart doesn't measure BIOS speed anyway

> (2) rc stuff is parallelized (/rc_parallel/="YES") during the startup of  
> the rc scripts
> (3) /boot lives on the solid state disk and root fs runs in ramdisk

It's not tricks - if you really want, there should be data from Arjan
and Auke's plumber's conference talk.

Bill



From oget.fedora at gmail.com  Fri Jan 30 04:02:49 2009
From: oget.fedora at gmail.com (Orcan Ogetbil)
Date: Thu, 29 Jan 2009 23:02:49 -0500
Subject: Unresponsive Maintianer: salimma
In-Reply-To: <gltoka$1tq$1@ger.gmane.org>
References: <gltoka$1tq$1@ger.gmane.org>
Message-ID: <e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>

On Thu, Jan 29, 2009 at 9:28 PM, Ben Boeckel wrote:
> Over a month ago, a bug was filed
> (https://bugzilla.redhat.com/show_bug.cgi?id=476119) requesting that Falcon
> be updated to 0.8.14 (it is currently 0.8.10). The maintainer has not
> responded at all (multiple requests from upstream to update and one from
> me). At least version 0.8.12 is needed in order to enable the Kross module
> for Falcon in kdebindings (currently disabled).
>
> There have been builds by salimma for his other packages (recently in fact:
> http://koji.fedoraproject.org:80/koji/buildinfo?buildID=80649), so he's not
> AWOL. What should the next course of action be? Not sure if this qualifies
> for the Non-responsive policy since he is active. If it does, I'll go that
> route.
>

Why shouldn't it? Please complete steps 1-3 before quick-jumping to step 4:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

Also, I'd suggest sending a direct email and/or pkgdb request. They
help sometimes.

Orcan



From ssorce at redhat.com  Fri Jan 30 04:08:13 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Thu, 29 Jan 2009 23:08:13 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <20090130035404.GC4570@nostromo.devel.redhat.com>
References: <1233260366.4952.29.camel@choeger6>
	<49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
Message-ID: <1233288493.3698.67.camel@localhost.localdomain>

On Thu, 2009-01-29 at 22:54 -0500, Bill Nottingham wrote:
> Brian Maly (bmaly at redhat.com) said: 
> >> My question is simply: How do they (the intel developers) reach that
> >> boot time without removing all those comfort services (udev etc.)?
> >>   
> > (1) its UEFI
> 
> 1) I've *NEVER* seen an EFI BIOS that wasn't abysmally slow
> 2) bootchart doesn't measure BIOS speed anyway
> 
> > (2) rc stuff is parallelized (/rc_parallel/="YES") during the startup of  
> > the rc scripts
> > (3) /boot lives on the solid state disk and root fs runs in ramdisk
> 
> It's not tricks - if you really want, there should be data from Arjan
> and Auke's plumber's conference talk.

In the fedora chart there seem to be a huge time (form sec 2.5, to sec
15) where the only things running are polymouthd and nash-hotplug, then
another gap when udev starts, then everything start booting more or less
in parallel.

In moblin there is no plymouthd/nash-hotplug and udev seem not to
introduce delays.
What are plymouthd/nash-hotplug doing ? (if its their fault)
Why fedora's udev seem to slow down another bit while moblin's udev seem
not ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From bmaly at redhat.com  Fri Jan 30 04:18:55 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 29 Jan 2009 23:18:55 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233288493.3698.67.camel@localhost.localdomain>
References: <1233260366.4952.29.camel@choeger6>	<49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6>	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
Message-ID: <49827FAF.3050306@redhat.com>

Simo Sorce wrote:
> On Thu, 2009-01-29 at 22:54 -0500, Bill Nottingham wrote:
>   
>> Brian Maly (bmaly at redhat.com) said: 
>>     
>>>> My question is simply: How do they (the intel developers) reach that
>>>> boot time without removing all those comfort services (udev etc.)?
>>>>   
>>>>         
>>> (1) its UEFI
>>>       
>> 1) I've *NEVER* seen an EFI BIOS that wasn't abysmally slow
>>     

You have now. FastBoot is a UEFI optimization (optimization of boot 
flow) for sub 2-second boot time. It achieves the same thing as 
LinuxBIOS in this respect. LinuxBIOS which also boots in 2-3 seconds 
with kernel on flash chip. LinuxBIOS only initializes the services 
needed for the kernel to boot. Intel FastBoot does the same because it 
only initializes BIOS modules that are dependent the kernel being 
booted. UEFI and LinuxBIOS are very similar in many respects.

Brian



From bmaly at redhat.com  Fri Jan 30 04:35:38 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 29 Jan 2009 23:35:38 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <49827FAF.3050306@redhat.com>
References: <1233260366.4952.29.camel@choeger6>	<49821FD3.4020801@redhat.com>	<1233267250.4952.36.camel@choeger6>	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
Message-ID: <4982839A.7090202@redhat.com>



FYI, There is a whitepaper on FastBoot from Intel for anyone keenly 
interested:

http://download.intel.com/design/intarch/papers/320497.pdf






 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/6bebacda/attachment.htm>

From bmaly at redhat.com  Fri Jan 30 04:48:41 2009
From: bmaly at redhat.com (Brian Maly)
Date: Thu, 29 Jan 2009 23:48:41 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233288493.3698.67.camel@localhost.localdomain>
References: <1233260366.4952.29.camel@choeger6>	<49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6>	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
Message-ID: <498286A9.3050407@redhat.com>

Simo Sorce wrote:
>
> Why fedora's udev seem to slow down another bit while moblin's udev seem
> not ?
>
>   
Presumably they have pruned the udev rules and possibly custom tailored 
them to this specific hardware. It also looks like rc gets kicked off at 
the same time as udev. Lots of things seem to have been parallelized. So 
basically hardware (BIOS) has been optimized to boot quickly and so has 
the OS.

Brian




From mjg at redhat.com  Fri Jan 30 05:31:44 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Fri, 30 Jan 2009 05:31:44 +0000
Subject: RFC: Disabling blinking cursor by default
Message-ID: <20090130053144.GA25512@srcf.ucam.org>

The blinking cursor causes the processor and GPU to be woken up 
frequently. On one of my test systems, this causes somewhere in the 
region of 2 Watts of extra power consumption. I'd like to change the 
default for this to false. Anyone have any objections?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From behdad at behdad.org  Fri Jan 30 05:33:09 2009
From: behdad at behdad.org (Behdad Esfahbod)
Date: Fri, 30 Jan 2009 00:33:09 -0500
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <49829115.7060102@behdad.org>

Matthew Garrett wrote:
> The blinking cursor causes the processor and GPU to be woken up 
> frequently. On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?

Since GTK+ already supports it, can we just make the timeout be 30s?

behdad



From jkeating at redhat.com  Fri Jan 30 06:09:14 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Thu, 29 Jan 2009 22:09:14 -0800
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <1233295754.3650.9.camel@localhost.localdomain>

On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
>  The blinking cursor causes the processor and GPU to be woken up 
> frequently. On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?

I set this myself everywhere I can, so I would really like to see this
the default.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090129/935a7b19/attachment.sig>

From mclasen at redhat.com  Fri Jan 30 06:21:47 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 30 Jan 2009 01:21:47 -0500
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <1233296507.20786.9.camel@matthiasc>

On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
> The blinking cursor causes the processor and GPU to be woken up 
> frequently. On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?
> 

A slightly less drastical measure would be to set the
gtk-cursor-blink-timeout setting to some reasonable value of seconds:

  /**
   * GtkSettings:gtk-cursor-blink-timeout:
   *
   * Time after which the cursor stops blinking, in seconds.
   * The timer is reset after each user interaction.
   *
   * Setting this to zero has the same effect as setting
   * #GtkSettings:gtk-cursor-blink to %FALSE.
   *
   * Since: 2.12
   */




From dtardon at redhat.com  Fri Jan 30 06:36:43 2009
From: dtardon at redhat.com (David Tardon)
Date: Fri, 30 Jan 2009 07:36:43 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <200901292032.59727.ville.skytta@iki.fi>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<20090129065225.GA20693@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
Message-ID: <20090130063643.GB20693@localhost.localdomain>

On Thu, Jan 29, 2009 at 08:32:59PM +0200, Ville Skytt? wrote:
> On Thursday 29 January 2009, David Tardon wrote:
> > On Thu, Jan 29, 2009 at 12:40:43AM +0100, Christoph Wickert wrote:
> > > Do RH employes have sponsors too? A lot of the bad reviews are done by
> > > RH people and a lot of bad specs come from RH folks. Somebody pointed me
> > > to:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=433678
> > > and I had a quick glance over it before Andreas added his comments:
> > >       * no list of tests that have been run
> > >       * SourceURL is missing
> >
> > What about fixing rpmlint to check for missing tags? Just now it simply
> > ignores them,
> 
> $ grep "^'no-.*-tag'" /usr/share/rpmlint/TagsCheck.py
> 'no-packager-tag',
> 'no-version-tag',
> 'no-release-tag',
> 'no-name-tag',
> 'no-summary-tag',
> 'no-description-tag',
> 'no-group-tag',
> 'no-changelogname-tag',
> 'no-epoch-tag',
> 'no-url-tag',
> 
> The no-packager-tag error is filtered in Fedora's rpmlint config (although I'm 
> not quite sure why), and a bunch of others are redundant because rpmbuild 
> will fail if the tag is not around, but I think "it simply ignores missing 
> tags" is not quite accurate.  If you feel something is missing, feel free to 
> file a bug report in Bugzilla or upstream rpmlint tracker.
> 

I checked it on several packages; for example, when I removed Name,
Version, Release, Group, Summary, License, URL, BuildArch, SourceX,
PatchX from F-10's dcobook-dtds, rmplint happily answered

0 packages and 1 specfiles checked; 0 errors, 0 warnings.

It seems to me rpmlint _will not_ fail if the tag is not around,
therefore I feel free to file a bug report.

David



From nicolas.mailhot at laposte.net  Fri Jan 30 06:52:36 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 30 Jan 2009 07:52:36 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
References: <497599B2.6030203@gmx.net> <4980DC1C.8000505@redhat.com>
	<glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
Message-ID: <1233298356.14086.3.camel@arekh.okg>

Le jeudi 29 janvier 2009 ? 23:59 +0000, Jonathan Underwood a ?crit :
> 2009/1/29 Orcan Ogetbil <oget.fedora at gmail.com>:
> > Wow... Thinking about removing TeX from Fedora? I can't imagine how
> > many people will leave Fedora in the first minute with no hesitation.
> 
> Noone's suggested that (in any seriousness)... this is about moving
> beyond texlive 2007 which is presently in Fedora.

Though eventually it will come to that if there is no resolution of TEX
problems. We can't carry for years in multiple releases packages with
known problems just because they were not identified before and now
there is a lack of people working to solve them. TEX users need to worry
about keeping our TEX packaging into shape IMHO, they should not rely on
inertia forever.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/11d35641/attachment.sig>

From fedora at camperquake.de  Fri Jan 30 07:28:50 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 30 Jan 2009 08:28:50 +0100
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <1233296507.20786.9.camel@matthiasc>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233296507.20786.9.camel@matthiasc>
Message-ID: <20090130082850.6200a1d1@dhcp03.addix.net>

Hi.

On Fri, 30 Jan 2009 01:21:47 -0500, Matthias Clasen wrote:

>   /**
>    * GtkSettings:gtk-cursor-blink-timeout:
>    *
>    * Time after which the cursor stops blinking, in seconds.
>    * The timer is reset after each user interaction.

So the cursor blinks at first, but then stops? I think that may confuse
people ("My cursor is broken, it stopped blinking.")



From markmc at redhat.com  Fri Jan 30 07:32:31 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Fri, 30 Jan 2009 07:32:31 +0000
Subject: Lack of update information
In-Reply-To: <7dd7ab490901291220x14b7c911lc8d7e634be924488@mail.gmail.com>
References: <497D6B24.8050702@fedoraproject.org>
	<497E1340.8000303@fedoraproject.org>
	<7dd7ab490901261206p4a0973c5y7d27df2c2b1d667a@mail.gmail.com>
	<497E1AE9.20606@fedoraproject.org> <497E503C.8090400@poolshark.org>
	<glmjkr$uvt$3@ger.gmane.org> <497F7A2E.90509@poolshark.org>
	<glqf9m$s29$1@ger.gmane.org> <49817907.503@poolshark.org>
	<1233223684.6470.48.camel@blaa>
	<7dd7ab490901291220x14b7c911lc8d7e634be924488@mail.gmail.com>
Message-ID: <1233300751.3989.7.camel@blaa>

 On Thu, 2009-01-29 at 12:20 -0800, Chris Weyl wrote: 
> On Thu, Jan 29, 2009 at 2:08 AM, Mark McLoughlin <markmc at redhat.com> wrote:
> > On Thu, 2009-01-29 at 10:38 +0100, Denis Leroy wrote:
> > > Good job :-) But this whole exercise is futile. We DO ALREADY ship both
> > > the ChangeLog and the NEWS files in the documentation directory, either
> > > with the library or development package. How is repeating or summarizing
> > > these internal changes *on Bodhi* useful to anyone ?
> >
> > Kevin's summary does something the NEWS file does not - it calls out a
> > particular crasher bug that could affect user applications. IMHO, that
> > is the only truly compelling reason a user has to apply this update and
> > it is the most user relevant part of Kevin's description.
> 
> We already provide the ability to link to bugs in the update; I don't
> see the logic in duplicating the information here.
 
Agreed, if a bug fix update includes the bugs it fixes in the Bugs
field, it is in good shape already.

Updated the text to read:

   Fedora users who do not update automatically may review the
   descriptions attached to updates before choosing whether they should
   apply them.

   Package maintainers should bear this in mind when preparing updates
   in bodhi and try to help their users make as informed decisions as
   possible. The Bugs and Notes fields are all the information which
   users have available when reviewing updates in the PackageKit UI (and
   not e.g. the RPM %changelog entries).

   Some suggestions on what to include in an update:

   1. For bug fixes, the appropriate bug numbers in the Bugs field
   2. For security issues, links to the appropriate CVEs 
   3. For new upstream releases, a summary of the important changes
      and/or a link to the upstream changelog
   4. Any other information that might be important to users

   Good judgement is required, though. Overly verbose descriptions can
   be almost as useless as overly terse descriptions.

Thanks,
Mark.



From pmatilai at laiskiainen.org  Fri Jan 30 07:44:33 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 30 Jan 2009 09:44:33 +0200 (EET)
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130082850.6200a1d1@dhcp03.addix.net>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233296507.20786.9.camel@matthiasc>
	<20090130082850.6200a1d1@dhcp03.addix.net>
Message-ID: <alpine.DEB.1.10.0901300935160.6551@gotcha.dreamhost.com>

On Fri, 30 Jan 2009, Ralf Ertzinger wrote:

> Hi.
>
> On Fri, 30 Jan 2009 01:21:47 -0500, Matthias Clasen wrote:
>
>>   /**
>>    * GtkSettings:gtk-cursor-blink-timeout:
>>    *
>>    * Time after which the cursor stops blinking, in seconds.
>>    * The timer is reset after each user interaction.
>
> So the cursor blinks at first, but then stops? I think that may confuse
> people

Sounds a bit weird to me.

> ("My cursor is broken, it stopped blinking.")

LOL :)

As for my "vote", yes kill the annoying blinker by default, please. 
Upgrading to F10 caused quite some rude language down here due to the 
cursor blink setting moving to System -> Preferences -> Hardware -> 
Keyboard. I wouldn't mind if I dont to need to ever again hunt and guess 
the new "intuitive" place when the setting gets moved the next time.

 	- Panu -



From markmc at redhat.com  Fri Jan 30 08:03:07 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Fri, 30 Jan 2009 08:03:07 +0000
Subject: plans for kernel in F10?
In-Reply-To: <20090121153244.GD27998@bombadil.infradead.org>
References: <loom.20090121T152315-474@post.gmane.org>
	<20090121153244.GD27998@bombadil.infradead.org>
Message-ID: <1233302587.3989.11.camel@blaa>

On Wed, 2009-01-21 at 10:32 -0500, Kyle McMartin wrote:
> On Wed, Jan 21, 2009 at 03:24:50PM +0000, Jack Tanner wrote:
> > There are two recent kernels built in Koji:
> > 
> > kernel-2.6.27.12-170.2.5.fc10
> > kernel-2.6.28.1-17.fc10
> > 
> > So, is F10 on the 2.6.27 track, or on the 2.6.28 track?
> > 
> 
> 2.6.28 is coming, 2.6.27 in the near term for low-risk immediate
> fixes.

Ah - the plan has changed:

  https://www.redhat.com/archives/fedora-kernel-list/2009-January/msg00098.html

F10 is going to get 2.6.29. There are some 2.6.29-rc3 builds in koji
already.

Cheers,
Mark.



From markmc at redhat.com  Fri Jan 30 08:19:19 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Fri, 30 Jan 2009 08:19:19 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <49822367.50602@gmail.com>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
	<20090129111140.654efe7a.mschwendt@gmail.com>
	<49822367.50602@gmail.com>
Message-ID: <1233303559.3989.23.camel@blaa>

On Thu, 2009-01-29 at 13:45 -0800, Toshio Kuratomi wrote:
> Michael Schwendt wrote:
> > On Wed, 28 Jan 2009 12:14:48 +0000, Mark wrote:
> > 
> >> Okay, here's an attempt:
> >>
> >>   https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines
> >>
> >> Cheers,
> >> Mark.
> > 
> >> = Package Update Guidelines =
> > 
> >> == Maintaining Stability ==
> > 
> >> == Update Descriptions ==
> > 
> >> == Rate of Updates ==
> > 
> > Much better, an effort much appreciated, although this is way beyond
> > the subject of this thread. ;) Such a document goes into the right
> > direction, since it tries to explain Fedora's fundamental update
> > strategy and may come as a surprise to some packagers. It will be very
> > interesting to hear what FESCo members think about the contents.
> > 
> +1
> 
> There's two grounds on which to discuss this:
> 
> 1) The tone and scope of the document.  I think this gets that spot on.
>  It explains what we're trying to achieve with updates rather than how
> to achieve it.  There are examples of why doing something is good or bad
> but leaves the final judgement up to the maintainer and the cases they
> need to solve.

Thanks.

> 2) The philosophy.  Do we agree with the goals that are expressed here?
>  The document is asking that maintainers limit the number of updates
> that they do for end user benefit.  Others have said that they use
> Fedora precisely for the number of updates that are issued.  Is one of
> these the true goal that represents 90% of our opinions?  Do we want to
> try to  give a place to both sides?

By the way, the first and last sections are just an elaboration of:

  https://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users

Basically, I thought the "update description" bit needed the context of
the existing philosophy with Fedora updates, so I fleshed out those
sections from the only existing text I found.

> Myself, I like running a system that gets frequent updates but I'm
> willing to curb the number of updates I issue to users.  I'd probably
> push packages to updates-testing and let them site there without going
> to updates without a user request/good reason if that fits into the big
> picture.

updates-testing could do with some discussion too - I think we need to
take more care with updates-testing than with rawhide, for example.
Testers of updates shouldn't be subject to completely untested updates.

i.e. if you've got a big, potentially very broken re-base to a new
upstream it would be a good idea to test locally, then push to rawhide
for a while, then updates-testing for another while and, finally, push
to updates.

This clearly doesn't apply to some packages, though - e.g. if there was
a new upstream gcalctool release that fixed some bug, you might even
push that straight to updates-testing without testing locally. Again the
common sense thing.

Cheers,
Mark.



From rc040203 at freenet.de  Fri Jan 30 08:34:21 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 30 Jan 2009 09:34:21 +0100
Subject: Draft: simple update description guidelines
In-Reply-To: <1233303559.3989.23.camel@blaa>
References: <497F5005.4060107@fedoraproject.org>	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>	<1233144888.13111.1.camel@blaa>	<20090129111140.654efe7a.mschwendt@gmail.com>	<49822367.50602@gmail.com>
	<1233303559.3989.23.camel@blaa>
Message-ID: <4982BB8D.40100@freenet.de>

Mark McLoughlin wrote:

> i.e. if you've got a big, potentially very broken re-base to a new
> upstream it would be a good idea to test locally, then push to rawhide
> for a while, then updates-testing for another while and, finally, push
> to updates.
Well, once a package is in rawhide, it in almost all cases sooner or 
later enters "stable", because there often is no way back.

I.e. packages must already provide a certain amount of stability before 
entering rawhide. A mechanically/blindly/careless pushing packages into 
rawhide approach, hoping they will mature there, will hardly work.

Ralf




From rawhide at fedoraproject.org  Fri Jan 30 08:35:46 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Fri, 30 Jan 2009 08:35:46 +0000 (UTC)
Subject: rawhide report: 20090130 changes
Message-ID: <20090130083546.D7C4F1F8277@releng2.fedora.phx.redhat.com>

Compose started at Fri Jan 30 06:01:03 UTC 2009

New package bind-to-tinydns
        Convert DNS zone files in BIND format to tinydns format
New package emacs-magit
        Emacs interface to the most common Git operations
New package findbugs-bcel
        Byte Code Engineering Library with findbugs extensions
New package perl-Fedora-Bugzilla
        Access Fedora's Bugzilla
New package perl-Network-IPv4Addr
        Network-IPv4Addr Perl module
New package pysnmp
        SNMP engine written in Python
New package python-cryptsetup
        Python bindings for cryptsetup
New package qtgpsc
        A client for the gpsd GPS server
Removed package conexusmm
Updated Packages:

WebKit-1.0.0-0.16.svn40351.fc11
-------------------------------
* Thu Jan 29 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> 1.0.0-0.17.svn40351
- Update to new upstream snapshot (SVN 40351): adds the WebPolicyDelegate
  implementaton and related API (#482739).
- Drop Bison 2.4 patch (fixed upstream):
  - bison24.patch


anaconda-11.5.0.12-1
--------------------
* Thu Jan 29 17:00:00 2009 David Cantrell <dcantrell at redhat.com> - 11.5.0.12-1
- If ks=nfs:... is given, don't try to find the file via boot options
  (#480210). (clumens)
- Fix cdrom install on machines with no network devices (wwoods)
- updated fuzzy strings (jsingh)
- Use modinfo to find out what firmware we need in initrd (wwoods)
- Use the preconf object for yum configuration now (jantill). (clumens)
- Updated Dutch translation adn only 1 -fuzzy- string left (zuma)
- Add a boot target for the xdriver=vesa parameter and document it. (clumens)
- repo.proxy is now a property, so check before setting it (#481342).
  (clumens)


bash-4.0-0.3.rc1.fc11
---------------------
* Wed Jan 28 17:00:00 2009 Jesse Keating <jkeating at redhat.com> - 4.0-0.2.rc1
- Replace post code with lua to be able to not have external deps

* Thu Jan 29 17:00:00 2009 Roman Rakus <rrakus at redhat.com> - 4.0-0.3.rc1
- No more debug output
  Resolves: #483002


crypto-utils-2.4.1-9
--------------------
* Wed Jan 21 17:00:00 2009 Elio Maldonado <emaldona at redhat.com> - 2.4.1-7
- certwatch: Fixed cert expiry time warnings (#473860)

* Wed Jan 21 17:00:00 2009 Elio Maldonado <emaldona at redhat.com> - 2.4.1-8
- certwatch: Fixed cert expiry time warnings off by one error (#473860)

* Thu Jan 29 17:00:00 2009 Elio Maldonado <emaldona at redhat.com> - 2.4.1-9
- certwatch: Fixed cert expiry time calculations (#473860)
- keyutil: Fixed segfault on certificate generation (#473860)
- genkey: Fixed key file name extension


dclib-0.3.22-1.fc11
-------------------
* Wed Jan 28 17:00:00 2009 Milos Jakubicek <xjakub at fi.muni.cz> - 0.3.22-1
- Update to 0.3.22
- Many bugfixes, code cleanup etc.
- Upload slot changes
- Major feature changes (together with valknut) mentioned in NEWS from 0.3.11 to 0.3.21:
  0.3.20: Segment size adjustable, Download folders from search, Warnings about settings,
  0.3.19: More search results returned, Switching active/passive mode, StrongDC compatible encryption,
  Partial list uploads, Search window improvements, User list icon changes
  0.3.14: Nick tab completion improvements, Chat command improvements, Filelist storage changes, 
  Public hubs display improved, /rebuild command fixed and improved, Folder search results


docbook-style-xsl-1.74.0-5.fc11
-------------------------------
* Wed Jan 28 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 1.74.0-5
- fix xsl stylesheets for rtl languages(#475077)


e2fsprogs-1.41.4-2.fc11
-----------------------
* Thu Jan 29 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 1.41.4-1
- New upstream release
- Dropped btrfs & resize fixes, upstream now

* Thu Jan 29 17:00:00 2009 Eric Sandeen <sandeen at redhat.com> 1.41.4-2
- Fix debugfs "stat" segfault if no open fs (#482894)
- Fix name of libext2fs info page (#481620)


eigen2-2.0-0.10.rc1.fc11
------------------------
* Wed Jan 28 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> 2.0-0.10.rc1
- eigen-2.0-rc1


gegl-0.0.22-2.fc11
------------------
* Thu Jan 29 17:00:00 2009 Nils Philippsen - 0.0.22-2
- use the same timestamps for certain documentation files on all architectures
  to avoid multi-lib conflicts (#481404)
- consolidate spec files between OS releases
- reenable building documentation on ppc64
- explicitly list more build requirements and/or versions to catch eventual
  problems during future builds


git-1.6.1.2-1.fc11
------------------
* Thu Jan 29 17:00:00 2009 Josh Boyer <jwboyer at gmail.com> 1.6.1.2-1
- git-1.6.1.2


gnome-keyring-sharp-1.0.1-0.1.115768svn.fc11
--------------------------------------------
* Thu Jan 29 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 1.0.1-0.1.115768svn.fc11
- Update to r115768


gnome-user-share-2.25.5-2.fc11
------------------------------
* Thu Jan 29 17:00:00 2009 - Bastien Nocera <bnocera at redhat.com> - 2.25.5-2
- Export the user through the TXT record with the new mod_dnssd


gtk2-2.15.2-4.fc11
------------------
* Thu Jan 29 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.15.2-4
- Split of an immodules subpackage (#444814)
- Disable ia64 hack thats not needed in Fedora
- Remove some .la files that crept in


gutenprint-5.2.3-4.fc11
-----------------------
* Thu Jan 29 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 5.2.3-4
- When updating foomatic PPDs, don't give a traceback if some PPD is
  not strictly conformant (bug #481397).


gwibber-0.7.3-3.199bzr.1.fc11
-----------------------------
* Wed Jan 28 17:00:00 2009 Ian Weller <ianweller at gmail.com> 0.7.3-3.199bzr
- Update upstream to r199:
  - more translations
  - "source" in identica and laconica now identified
  - account manager bug fix

* Thu Jan 29 17:00:00 2009 Ian Weller <ianweller at gmail.com> 0.7.3-3.199bzr.1
- Rawhide bump, failed build


jd-2.2.0-0.3.svn2643_trunk.fc11
-------------------------------
* Fri Jan 30 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- rev 2643


kasumi-2.4-1.fc11
-----------------
* Thu Jan 29 17:00:00 2009 Akira TAGOH <tagoh at redhat.com> - 2.4-1
- New upstream release.


kazehakase-0.5.6-3.svn3598_trunk.fc11
-------------------------------------
* Fri Jan 30 17:00:00 2009 Mamoru Tasaka <mtasaka at ioa.s.u-tokyo.ac.jp>
- Try rev 3598
- Now WebKit >= rev 39421 is needed


kbd-1.15-3.fc11
---------------
* Thu Jan 29 17:00:00 2009 Vitezslav Crhonek <vcrhonek at redhat.com> - 1.15-3
- Rename conflicting keymaps to have unique names
  Resolves: #481674


kdebase-workspace-4.2.0-4.fc11
------------------------------
* Thu Jan 29 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.2.0-3
- Requires: PyKDE4 (for plasmascript bits)
- solid-bluetoothTrunkTo42.diff (bug #481801), and 
  +Provides: solid-bluetooth(-devel) = 4.3

* Thu Jan 29 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.2.0-4
- omit ldap hack (#457638), kde42's reduced linkage to the rescue


kdebluetooth-0.3-1.fc11
-----------------------
* Wed Jan 28 17:00:00 2009 Ville Skytt?? <ville.skytta at iki.fi> - 1:0.3-1
- 0.3 (#481802).
- http://sourceforge.net/project/shownotes.php?group_id=89888&release_id=654566
- (Build)Requires: solid-bluetooth(-devel) >= 4.3


kdelibs-4.2.0-5.fc11
--------------------
* Fri Jan 30 17:00:00 2009 Kevin Kofler <Kevin at tigcc.ticalc.org> - 4.2.0-5
- reenable PolicyKit and NTFS workarounds


kernel-2.6.29-0.66.rc3.fc11
---------------------------
* Thu Jan 29 17:00:00 2009 Mark McLoughlin <markmc at redhat.com>
- Temporarily disable kvmclock, fix for upstream in progress (#475598)


krazy2-2.8-7.20090127svn.fc11
-----------------------------
* Thu Jan 29 17:00:00 2009 Ben Boeckel <MathStuf at gmail.com> 2.8-6.20090127svn
- Updated SVN


linuxwacom-0.8.2.2-1.fc11
-------------------------
* Thu Jan 29 17:00:00 2009 Peter Hutterer <peter.hutterer at redhat.com> 0.8.2.2-1
- update to 0.8.2.2
- linuxwacom-0.8.2.2-fix-mapping.patch: fix button mapping, the X server
  starts with 1, not with 0.


ltsp-5.1.55-1.fc11
------------------
* Thu Jan 15 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 5.1.48-1
- More bug fixes

* Wed Jan 21 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 5.1.49-1
- ltsp-genmenu replaces menu entries in the XDG menu with localapps transparently

* Wed Jan 21 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 5.1.51-1
- Fedora 11 support and more bug fixes

* Wed Jan 28 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 5.1.53-1
- Fix client shutdown with NBD root

* Wed Jan 28 17:00:00 2009 Warren Togami <wtogami at redhat.com> - 5.1.54-1
- Fix ltsp-build-client

* Thu Jan 29 17:00:00 2009 Ryan Niebur <ryanryan52 at gmail.com> - 5.1.55-1
- Fix default setting of ALSA hardware volume. WARNING: This triples
  the default software volume and will be a big surprise if your
  speakers are maxed out.


ltspfs-0.5.8-1.fc11
-------------------

mkdst-0.11-1.fc11
-----------------
* Thu Jan 29 17:00:00 2009 Ryan Niebur <ryanryan52 at gmail.com> - 0.11-1
- 0.11


netpbm-10.35.59-1.fc11
----------------------
* Thu Jan 29 17:00:00 2009 Jindrich Novy <jnovy at redhat.com> 10.35.59-1
- update to 10.35.59
- fixes array bound violation in ilbmtoppm
- fixes garbage output when input in fitstopnm is little endian
  floating point FITS


neverball-1.4.0-15.fc11
-----------------------
* Thu Jan 29 17:00:00 2009 Alex Lancaster <alexlan[AT]fedoraproject org> - 1.4.0-15
- Change from bitstream-vera font to equivalent dejavu font.


phonon-4.3.0-4.fc11
-------------------
* Mon Jan 26 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.3.0-3
- BR: automoc4 >= 0.9.86

* Thu Jan 29 17:00:00 2009 Rex Dietger <rdieter at fedoraproject.org> - 4.3.0-4
- Requires: phonon-backend >= %version
- move icons to hicolor theme and into -backend subpkgs
- BR: libxcb-devel
- move phonon-gstreamer.svg to sources


php-pear-Cache-Lite-1.7.6-1.fc11
--------------------------------
* Thu Jan 29 17:00:00 2009 Remi Collet <Fedora at FamilleCollet.com> 1.7.6-1
- now Requires php-pear(PEAR) >= 1.5.4


pykickstart-1.51-1.fc11
-----------------------
* Thu Jan 29 17:00:00 2009 Chris Lumens <clumens at redhat.com> - 1.51-1
- Make a couple changes to how the logging command is handled.
- Add a lot of test cases (clumens, alindebe, jlaska, fcami, adamwill, pfrields).
- Fix output formatting for the rootpw command.
- For commands that take exactly one argument, check and error correctly.
- Surround module options in quotes on the output side (jlaska).
- Set module opts in the FC3 handler correctly.
- Fix newlines on the device command output (jlaska).
- If --autoscreenshot is not specified, still output "autostep".
- Move the currentCmd and currentLine into getParser(). (jlaska)
- Write out an selinux line if set to disabled, but not if None.
- F9_LogVolData should inherit from FC4_LogVolData, not FC3_LogVolData (jlaska).
- Add unittest framework along with logvol and vnc unittests. (jlaska)
- Don't set the KSOption.required attribute in the constructor (jlaska).


qt-4.4.3-14.fc11
----------------
* Thu Jan 29 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 4.4.3-14
- qt-copy-patches-20090129


ruby-qpid-0.4.738618-1.fc11
---------------------------
* Thu Jan 29 17:00:00 2009 Nuno Santos <nsantos at redhat.com> - 0.4.738618-1
- Rebased to svn rev 738618


scim-anthy-1.2.7-1.fc11
-----------------------
* Thu Jan 29 17:00:00 2009 Akira TAGOH <tagoh at redhat.com> - 1.2.7-1
- New upstream release.


scim-bridge-0.4.15.2-1.fc11
---------------------------
* Thu Jan 29 17:00:00 2009 Jens Petersen <petersen at redhat.com> - 0.4.15.2-1
- update to 0.4.15.2 release
- update scim-bridge-0.4.15-bz461373.patch and
  scim-bridge-0.4.15-hotkey-help.patch


setup-2.7.7-2.fc11
------------------
* Thu Jan 29 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2.7.7-2
- reserve 87 gid for polkituser (just uid was reserved),
  reserve 18 gid for dialout(to prevent conflicts with
  polkituser gid)


soprano-2.2.1-1.fc11
--------------------
* Thu Jan 29 17:00:00 2009 Luk???? Tinkl <ltinkl at redhat.com> 2.2.1-1
- update to 2.2.1


squid-3.0.STABLE12-1.fc11
-------------------------
* Tue Jan 27 17:00:00 2009 Henrik Nordstrom <henrik at henriknordstrom.net> - 7:3.0.STABLE12-1
- upgrade to latest upstream


telepathy-gabble-0.7.19-1.fc11
------------------------------
* Thu Jan 29 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.19-1
- Update to 0.7.19.


telepathy-glib-0.7.24-1.fc11
----------------------------
* Wed Jan 28 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.24-1
- Update to 0.7.24.


udev-137-1.fc11
---------------
* Thu Jan 29 17:00:00 2009 Harald Hoyer <harald at redhat.com> 137-1
- version 137
- add vol_id patches from kzak
- dialout group has gid 18 now


udev-extras-20090125-0.1.20090129git.fc11
-----------------------------------------
* Thu Jan 29 17:00:00 2009 Dan Williams <dcbw at redhat.com> 20090125-0.1.20090129git
- Compatibilty updates and fixes for modem prober


valknut-0.4.8-1.fc11
--------------------
* Wed Jan 28 17:00:00 2009 Milos Jakubicek <xjakub at fi.muni.cz> - 0.4.8-1
- Update to 0.4.8
- Switch to QT4
- Removed Source2:valknut.png (part of the source package now)
- Fixed desktop file
- Man pages
- Many bugfixes, code cleanup etc.
- Upload slot changes
- Major feature changes (together with dclib) mentioned in NEWS from 0.4.0 to 0.4.7:
  0.4.6: Segment size adjustable, Download folders from search, Warnings about settings,
  0.4.5: More search results returned, Switching active/passive mode, StrongDC compatible encryption,
  Partial list uploads, Search window improvements, User list icon changes
  0.4.0: Nick tab completion improvements, Chat command improvements, Filelist storage changes, 
  Public hubs display improved, /rebuild command fixed and improved, Folder search results


wormux-0.8.2-4.fc11
-------------------
* Thu Jan 29 17:00:00 2009 Wart <wart at kobold.org> 0.8.2-4
- Yet another font package rename


xchat-gnome-0.24.3.1-1.fc11
---------------------------
* Thu Jan 29 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.24.3.1-1
- Update to 0.24.3.1.


xorg-x11-drv-ati-6.10.0-2.fc11
------------------------------
* Fri Jan 30 17:00:00 2009 Dave Airlie <airlied at redhat.com> 6.10.0-2
- Fix corruption on rs780 hopefully


yum-3.2.21-7.fc11
-----------------
* Thu Jan 29 17:00:00 2009 Seth Vidal <skvidal at fedoraproject.org> - 3.2.21-7
- update HEAD patch to fix repodiff (and EVR comparisons in certain cases)


Summary:
Added Packages: 8
Removed Packages: 1
Modified Packages: 49
Broken deps for i386
----------------------------------------------------------
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.i386 requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc requires libbit.so.0
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc requires bit-devel >= 0:0.4.1
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gnome-do-0.6.1.0-2.fc10.ppc requires tomboy
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.ppc requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	bitgtkmm-0.4.0-4.fc10.ppc64 requires libbit.so.0()(64bit)
	bitgtkmm-devel-0.4.0-4.fc10.ppc64 requires bit-devel >= 0:0.4.1
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From markmc at redhat.com  Fri Jan 30 08:52:02 2009
From: markmc at redhat.com (Mark McLoughlin)
Date: Fri, 30 Jan 2009 08:52:02 +0000
Subject: Draft: simple update description guidelines
In-Reply-To: <4982BB8D.40100@freenet.de>
References: <497F5005.4060107@fedoraproject.org>
	<1233136369.22103.25.camel@blaa>	<49803167.5040000@fedoraproject.org>
	<1233144888.13111.1.camel@blaa>
	<20090129111140.654efe7a.mschwendt@gmail.com>	<49822367.50602@gmail.com>
	<1233303559.3989.23.camel@blaa>  <4982BB8D.40100@freenet.de>
Message-ID: <1233305522.3989.32.camel@blaa>

On Fri, 2009-01-30 at 09:34 +0100, Ralf Corsepius wrote:
> Mark McLoughlin wrote:
> 
> > i.e. if you've got a big, potentially very broken re-base to a new
> > upstream it would be a good idea to test locally, then push to rawhide
> > for a while, then updates-testing for another while and, finally, push
> > to updates.
> Well, once a package is in rawhide, it in almost all cases sooner or 
> later enters "stable", because there often is no way back.
> 
> I.e. packages must already provide a certain amount of stability before 
> entering rawhide. A mechanically/blindly/careless pushing packages into 
> rawhide approach, hoping they will mature there, will hardly work.

Agree 100% - hence the "test locally" bit.

Rawhide is useless if it's so broken no-one tests it.

Cheers,
Mark.



From seg at haxxed.com  Fri Jan 30 10:00:15 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 30 Jan 2009 04:00:15 -0600
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <1233309615.25769.1.camel@localhost.localdomain>

On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
> The blinking cursor causes the processor and GPU to be woken up 
> frequently.

How about the fading glow flashy thing the gnome panel window switcher
does when a window wants attention? That's even worse.

> On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?

Please do.
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/a1cffe06/attachment.sig>

From bnocera at redhat.com  Fri Jan 30 10:04:46 2009
From: bnocera at redhat.com (Bastien Nocera)
Date: Fri, 30 Jan 2009 10:04:46 +0000
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <1233309615.25769.1.camel@localhost.localdomain>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233309615.25769.1.camel@localhost.localdomain>
Message-ID: <1233309887.3328.2892.camel@cookie.hadess.net>

On Fri, 2009-01-30 at 04:00 -0600, Callum Lerwick wrote:
> On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
> > The blinking cursor causes the processor and GPU to be woken up 
> > frequently.
> 
> How about the fading glow flashy thing the gnome panel window switcher
> does when a window wants attention? That's even worse.

Not really, it blinks for a set amount of time, then doesn't change.
It's a matter of a couple of seconds.




From kanarip at kanarip.com  Fri Jan 30 10:15:09 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 30 Jan 2009 11:15:09 +0100
Subject: what requires fedora-release-notes
In-Reply-To: <200901291219.43434.pvrabec@redhat.com>
References: <200901281624.31502.pvrabec@redhat.com>	<1233169541.8363.234.camel@localhost.localdomain>	<20090128222404.GD5735@localhost.localdomain>
	<200901291219.43434.pvrabec@redhat.com>
Message-ID: <4982D32D.6090102@kanarip.com>

Peter Vrabec wrote:
> thnx. folks,
> 
> I have filed two bugs:
> 
> 1. don't require fedora-release-notes in fedora-release
> https://bugzilla.redhat.com/show_bug.cgi?id=483018
> 
> 2. install fedora-release-notes vie "base" group
> https://bugzilla.redhat.com/show_bug.cgi?id=483019
> 

Right, so now "fedora-release-notes" is in @base, instead of 
"system-release-notes". As commented in the bug, can this be changed?


Kind regards,

Jeroen van Meeuwen
-kanarip



From pertusus at free.fr  Fri Jan 30 11:01:05 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 12:01:05 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <1233298356.14086.3.camel@arekh.okg>
References: <glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg>
Message-ID: <20090130110105.GA2908@free.fr>

On Fri, Jan 30, 2009 at 07:52:36AM +0100, Nicolas Mailhot wrote:
> 
> Though eventually it will come to that if there is no resolution of TEX
> problems. We can't carry for years in multiple releases packages with
> known problems just because they were not identified before and now
> there is a lack of people working to solve them. TEX users need to worry
> about keeping our TEX packaging into shape IMHO, they should not rely on
> inertia forever.

You make it look like TeX packaging is bad. It's not the case. The TeX
packaging is consistent with FHS and with upstream organization. We
can do better at integrating, for the fonts for instance. But this
doesn't render the TeX packaging bad or not acceptable. I can't see
the 'known problems' of the current TeX packaging. If you refer 
to TeX fonts not being available for other packages, sure this is a
shortcoming, but not a problem.

(License issues are another matter, but mostly independent of the 
packaging issues, and upstream is quick at resolving those, quick
here meaning for the next release).

--
Pat



From pertusus at free.fr  Fri Jan 30 11:04:02 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 12:04:02 +0100
Subject: Unresponsive Maintianer: salimma
In-Reply-To: <e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
References: <gltoka$1tq$1@ger.gmane.org>
	<e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
Message-ID: <20090130110402.GB2908@free.fr>

On Thu, Jan 29, 2009 at 11:02:49PM -0500, Orcan Ogetbil wrote:
> 
> Why shouldn't it? Please complete steps 1-3 before quick-jumping to step 4:

No, it doesn't qualify, since the maintainer is known to be active.

--
Pat



From tagoh at redhat.com  Fri Jan 30 11:15:14 2009
From: tagoh at redhat.com (Akira TAGOH)
Date: Fri, 30 Jan 2009 20:15:14 +0900 (JST)
Subject: Call for Ruby package maintainer
In-Reply-To: <4981D43E.3030404@kanarip.com>
References: <497FA870.2030806@kanarip.com>
	<20090128.182208.612299192959538683.tagoh@redhat.com>
	<4981D43E.3030404@kanarip.com>
Message-ID: <20090130.201514.1001913346498032707.tagoh@redhat.com>

>>>>> On Thu, 29 Jan 2009 17:07:26 +0100,
>>>>> "JvM" == Jeroen van Meeuwen <kanarip at kanarip.com> wrote:

JvM> If you orphan the package in PackageDB, I'll pick it up so you can add yourself back as a co-maintainer.

Done.

--
Akira TAGOH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/e48879af/attachment.sig>

From vnpenguin at vnoss.org  Fri Jan 30 11:18:00 2009
From: vnpenguin at vnoss.org (Vnpenguin)
Date: Fri, 30 Jan 2009 12:18:00 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <1233298356.14086.3.camel@arekh.okg>
References: <497599B2.6030203@gmx.net> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg>
Message-ID: <bdd64e1c0901300318s6648d355k702cd134c7b4a4ef@mail.gmail.com>

2009/1/30 Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Le jeudi 29 janvier 2009 ? 23:59 +0000, Jonathan Underwood a ?crit :
>> 2009/1/29 Orcan Ogetbil <oget.fedora at gmail.com>:
>> > Wow... Thinking about removing TeX from Fedora? I can't imagine how
>> > many people will leave Fedora in the first minute with no hesitation.
>>
>> Noone's suggested that (in any seriousness)... this is about moving
>> beyond texlive 2007 which is presently in Fedora.
>
> Though eventually it will come to that if there is no resolution of TEX
> problems. We can't carry for years in multiple releases packages with
> known problems just because they were not identified before and now
> there is a lack of people working to solve them. TEX users need to worry
> about keeping our TEX packaging into shape IMHO, they should not rely on
> inertia forever.
>

TeX, not TEX !

-- 
http://vnoss.org



From itamar at ispbrasil.com.br  Fri Jan 30 11:40:41 2009
From: itamar at ispbrasil.com.br (Itamar Reis Peixoto)
Date: Fri, 30 Jan 2009 09:40:41 -0200
Subject: Call for Ruby package maintainer
In-Reply-To: <20090130.201514.1001913346498032707.tagoh@redhat.com>
References: <497FA870.2030806@kanarip.com>
	<20090128.182208.612299192959538683.tagoh@redhat.com>
	<4981D43E.3030404@kanarip.com>
	<20090130.201514.1001913346498032707.tagoh@redhat.com>
Message-ID: <d3ceea380901300340h2e3f0a03xd1780431a185621b@mail.gmail.com>

ask in pkgdb

2009/1/30 Akira TAGOH <tagoh at redhat.com>:
>>>>>> On Thu, 29 Jan 2009 17:07:26 +0100,
>>>>>> "JvM" == Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
>
> JvM> If you orphan the package in PackageDB, I'll pick it up so you can add yourself back as a co-maintainer.
>
> Done.
>
> --
> Akira TAGOH
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



-- 
------------

Itamar Reis Peixoto

e-mail/msn: itamar at ispbrasil.com.br
sip: itamar at ispbrasil.com.br
skype: itamarjp
icq: 81053601
+55 11 4063 5033
+55 34 3221 8599



From jwboyer at gmail.com  Fri Jan 30 12:27:08 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 30 Jan 2009 07:27:08 -0500
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <1233296507.20786.9.camel@matthiasc>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233296507.20786.9.camel@matthiasc>
Message-ID: <20090130122708.GA31192@yoda.jdub.homelinux.org>

On Fri, Jan 30, 2009 at 01:21:47AM -0500, Matthias Clasen wrote:
>On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
>> The blinking cursor causes the processor and GPU to be woken up 
>> frequently. On one of my test systems, this causes somewhere in the 
>> region of 2 Watts of extra power consumption. I'd like to change the 
>> default for this to false. Anyone have any objections?
>> 
>
>A slightly less drastical measure would be to set the
>gtk-cursor-blink-timeout setting to some reasonable value of seconds:

That works for Gnome, but what about vttys and other desktop environments?

I'm not saying to not use the gtk thing, I'm just wondering if there is a
toggle that would catch it globally somewhere.

josh



From mefoster at gmail.com  Fri Jan 30 12:53:40 2009
From: mefoster at gmail.com (Mary Ellen Foster)
Date: Fri, 30 Jan 2009 13:53:40 +0100
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130122708.GA31192@yoda.jdub.homelinux.org>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233296507.20786.9.camel@matthiasc>
	<20090130122708.GA31192@yoda.jdub.homelinux.org>
Message-ID: <f58861e00901300453j7944b07ek1e2fce18a58a29ee@mail.gmail.com>

On Fri, Jan 30, 2009 at 1:27 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Fri, Jan 30, 2009 at 01:21:47AM -0500, Matthias Clasen wrote:
>>On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
>>> The blinking cursor causes the processor and GPU to be woken up
>>> frequently. On one of my test systems, this causes somewhere in the
>>> region of 2 Watts of extra power consumption. I'd like to change the
>>> default for this to false. Anyone have any objections?
>>>
>>
>>A slightly less drastical measure would be to set the
>>gtk-cursor-blink-timeout setting to some reasonable value of seconds:
>
> That works for Gnome, but what about vttys and other desktop environments?
>
> I'm not saying to not use the gtk thing, I'm just wondering if there is a
> toggle that would catch it globally somewhere.

Yes, this is an issue. I use KDE as a desktop but regularly run
several GTK apps including Firefox, Eclipse, and OpenOffice. A month
or so ago I tried -- and failed -- to find a way to turn off the
blinking cursor in these apps (due to issues with evil proprietary
graphics drivers) without manually running gnome-settings

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 limb at jcomserv.net  Fri Jan 30 13:13:04 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 30 Jan 2009 07:13:04 -0600 (CST)
Subject: rpms/xgalaxy/devel xgalaxy.spec,1.9,1.10
In-Reply-To: <20090130092457.5CD9F70117@cvs1.fedora.phx.redhat.com>
References: <20090130092457.5CD9F70117@cvs1.fedora.phx.redhat.com>
Message-ID: <1fda4cab84292a7429d99e83bdf9016f.squirrel@mail.jcomserv.net>


Thanks!  So, by, "orphaning lots of packages to leave time for RH work",
you meant, "orphan in name only and just do more work", right? ;)

> Author: jwrdegoede
>
> Update of /cvs/extras/rpms/xgalaxy/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv395
>
> Modified Files:
> 	xgalaxy.spec
> Log Message:
> * Fri Jan 30 2009 Hans de Goede <hdegoede at redhat.com> 2.0.34-10
> - Update description for new trademark guidelines
>
>
>
> Index: xgalaxy.spec
> ===================================================================
> RCS file: /cvs/extras/rpms/xgalaxy/devel/xgalaxy.spec,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -u -r1.9 -r1.10
> --- xgalaxy.spec	8 Sep 2008 10:17:02 -0000	1.9
> +++ xgalaxy.spec	30 Jan 2009 09:24:27 -0000	1.10
> @@ -1,7 +1,7 @@
>  Name:           xgalaxy
>  Version:        2.0.34
> -Release:        9%{?dist}
> -Summary:        Galaxian / Galaga like game with powerups
> +Release:        10%{?dist}
> +Summary:        Arcade game: shoot down the space ships attacking the
> planet
>  Group:          Amusements/Games
>  License:        GPL+
>  URL:            http://sourceforge.net/projects/xgalaga/
> @@ -20,9 +20,8 @@
>  Provides:       xgalaga = %{version}-%{release}
>
>  %description
> -Arcade game for the X Window System inspired by the classic game Galaga.
> -Xgalaxy is a Galaxian like game with additional features to produce a
> more
> -interesting game.
> +Arcade game for the X Window System where you have to shoot down the
> space
> +ships attacking the planet.
>
>
>  %prep
> @@ -111,6 +110,9 @@
>
>
>  %changelog
> +* Fri Jan 30 2009 Hans de Goede <hdegoede at redhat.com> 2.0.34-10
> +- Update description for new trademark guidelines
> +
>  * Sun Sep  7 2008 Hans de Goede <hdegoede at redhat.com> 2.0.34-9
>  - Fix patch fuzz build failure
>
>
> --
> fedora-extras-commits mailing list
> fedora-extras-commits at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-commits
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From kevin.kofler at chello.at  Fri Jan 30 13:27:36 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Jan 2009 14:27:36 +0100
Subject: Unresponsive Maintianer: salimma
References: <gltoka$1tq$1@ger.gmane.org>
	<e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
	<20090130110402.GB2908@free.fr>
Message-ID: <gluv88$736$1@ger.gmane.org>

Patrice Dumas wrote:
> No, it doesn't qualify, since the maintainer is known to be active.

It does. A maintainer can be active and still neglecting some packages.

Still, there ought to be a better solution. Comaintainership?

        Kevin Kofler



From nicolas.mailhot at laposte.net  Fri Jan 30 13:37:13 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 30 Jan 2009 14:37:13 +0100 (CET)
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090130110105.GA2908@free.fr>
References: <glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg> <20090130110105.GA2908@free.fr>
Message-ID: <40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>



Le Ven 30 janvier 2009 12:01, Patrice Dumas a ?crit :
>
> On Fri, Jan 30, 2009 at 07:52:36AM +0100, Nicolas Mailhot wrote:
>>
>> Though eventually it will come to that if there is no resolution of
>> TEX
>> problems. We can't carry for years in multiple releases packages
>> with
>> known problems just because they were not identified before and now
>> there is a lack of people working to solve them. TEX users need to
>> worry
>> about keeping our TEX packaging into shape IMHO, they should not
>> rely on
>> inertia forever.
>
> You make it look like TeX packaging is bad. It's not the case. The TeX
> packaging is consistent with FHS and with upstream organization. We
> can do better at integrating, for the fonts for instance. But this
> doesn't render the TeX packaging bad or not acceptable. I can't see
> the 'known problems' of the current TeX packaging. If you refer
> to TeX fonts not being available for other packages, sure this is a
> shortcoming, but not a problem.

Well, if you handwave packaging guidelines conformance away, and legal
checks away, sure there are no problems and all is fine.

This is still normal maintenance work that needs to be done by someone
and can not be postponed indefinitely.

-- 
Nicolas Mailhot



From rdieter at math.unl.edu  Fri Jan 30 13:44:04 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 30 Jan 2009 07:44:04 -0600
Subject: Reminder: Do not use trademarks in Summary or Description
References: <49821EF9.4040108@redhat.com> <49826A45.4030809@silfreed.net>
Message-ID: <glv08o$bgg$1@ger.gmane.org>

Douglas E. Warner wrote:

> Tom "spot" Callaway wrote:

https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description

> Hope you don't mind the discussion on-list; I thought further examples
> might help.
...
> The summaries for them are:
> concordance: Software to program the Logitech? Harmony? remote control
> libconcord: Library to talk to Logitech? Harmony? universal remote
> controls

> So, under this new guideline should I just remove the ?'s? 

As one who was also bitten by this, my understanding is... yes.

Even better would be to consider avoiding the use of those (possibly
trademarked) terms altogether.

-- Rex




From nicolas.mailhot at laposte.net  Fri Jan 30 13:47:09 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 30 Jan 2009 14:47:09 +0100 (CET)
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
References: <glr4gb$qno$1@ger.gmane.org> <glssu6$3pd$6@ger.gmane.org>
	<4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg> <20090130110105.GA2908@free.fr>
	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
Message-ID: <225f54f27e6b1b4f4f4f6d4f142e135e.squirrel@arekh.dyndns.org>



Le Ven 30 janvier 2009 14:37, Nicolas Mailhot a ?crit :

> Well, if you handwave packaging guidelines conformance away, and legal
> checks away,

And the fact we've still not packaged last year's tetex version

-- 
Nicolas Mailhot



From silfreed at silfreed.net  Fri Jan 30 13:49:13 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Fri, 30 Jan 2009 08:49:13 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <glv08o$bgg$1@ger.gmane.org>
References: <49821EF9.4040108@redhat.com> <49826A45.4030809@silfreed.net>
	<glv08o$bgg$1@ger.gmane.org>
Message-ID: <49830559.2010103@silfreed.net>

Rex Dieter wrote:
>> So, under this new guideline should I just remove the ?'s? 
> 
> As one who was also bitten by this, my understanding is... yes.
> 
> Even better would be to consider avoiding the use of those (possibly
> trademarked) terms altogether.
> 

It'd be nice, but since this software *only* works with this specific hardware
it would be best if the user could search for "logitech" and/or "harmony" to
find it rather than a generic description like "software that can program a
remote control".

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/293154b8/attachment.sig>

From silfreed at silfreed.net  Fri Jan 30 13:53:59 2009
From: silfreed at silfreed.net (Douglas E. Warner)
Date: Fri, 30 Jan 2009 08:53:59 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49826A45.4030809@silfreed.net>
References: <49821EF9.4040108@redhat.com> <49826A45.4030809@silfreed.net>
Message-ID: <49830677.8000005@silfreed.net>

Douglas E. Warner wrote:
> So, under this new guideline should I just remove the ?'s?  Is the rest of the
> information safe?
> 

Also just to be clear, we shouldn't rebuild just for this, should we?

-Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/192bda40/attachment.sig>

From pertusus at free.fr  Fri Jan 30 13:53:54 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 14:53:54 +0100
Subject: Unresponsive Maintianer: salimma
In-Reply-To: <gluv88$736$1@ger.gmane.org>
References: <gltoka$1tq$1@ger.gmane.org>
	<e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
	<20090130110402.GB2908@free.fr> <gluv88$736$1@ger.gmane.org>
Message-ID: <20090130135354.GA2566@free.fr>

On Fri, Jan 30, 2009 at 02:27:36PM +0100, Kevin Kofler wrote:
> Patrice Dumas wrote:
> > No, it doesn't qualify, since the maintainer is known to be active.
> 
> It does. A maintainer can be active and still neglecting some packages.

Of course, this happens. But this is not covered by that policy.
 
> Still, there ought to be a better solution. Comaintainership?

There is no formal procedure in that case, with Rahul we proposed 
forced co-maintainership, but the policy was rejected by FESCo.
FESCo said that this would be revised when provenpackager is done.
I don't think anything changed with provenpackager, but, in any case,
since it has been implemented, FESCo could revisit it.

Still this is a controversial and touchy subject, the balance between 
bureaucracy and no handling of bugs is not an easy one. Actually the 
focus was only on bugs with a fix provided or discussed, not for 
every bugs, in our proposal:

https://fedoraproject.org/wiki/RahulSundaram/CollectiveMaintenance

--
Pat



From rc040203 at freenet.de  Fri Jan 30 14:09:51 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 30 Jan 2009 15:09:51 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49821EF9.4040108@redhat.com>
References: <49821EF9.4040108@redhat.com>
Message-ID: <49830A2F.7010601@freenet.de>

Tom "spot" Callaway wrote:
> Please, if you're a packager, take a moment and go read this:
> 
> https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description
> 
> After talking with Red Hat Legal about how we should be handling
> trademarks in package summaries and descriptions, we came to the
> conclusion that it would be far easier (and less risky for Red Hat) if
> we did not use "(TM)" or "(R)" notations at all. This does not mean that
> you can use trademarks freely, you still need to be careful in how you
> use them. When in doubt, try not to use it. If you have questions, you
> can either email me or fedora-legal at redhat.com.

IMO, your advice collides with "fair use" of trademarks, in particular 
when commonly used names actually refer to trademarked items or when 
package even contain something trademarked.

Cf. e.g.
http://www.sgi.com/products/software/opengl/license.html
http://www.sgi.com/products/software/opengl/trademarks.html

Ralf




From pertusus at free.fr  Fri Jan 30 14:10:22 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 15:10:22 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
References: <4982045B.3020405@redhat.com>
	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>
	<498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg>
	<20090130110105.GA2908@free.fr>
	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
Message-ID: <20090130141022.GB2566@free.fr>

On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
> 
> Well, if you handwave packaging guidelines conformance away, 

It is not the point. Exceptions can be made when the cost is high and
the benefit is low. This is the case here. Now, people who are unhappy
can fill bugs (you already did it) and escalate to the list and 
to FESCo for conflict resolution. Nobody stops you from putting 
removal of texlive from Fedora on the FESCo agenda.

But I think that the priority is updating to texlive 2008, not strict
guideline policy conformance.

> and legal checks away, sure there are no problems and all is fine.

Legal checks were done during review, and it is an independent issue.

> This is still normal maintenance work that needs to be done by someone
> and can not be postponed indefinitely.

Sure. But removing texlive is not going to make that happen faster,
on the contrary, Fedora will certainly lose all the TeX users and
contributors, who are already very few.

--
Pat



From kevin.kofler at chello.at  Fri Jan 30 14:19:11 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Jan 2009 15:19:11 +0100
Subject: Unresponsive Maintianer: salimma
References: <gltoka$1tq$1@ger.gmane.org>
	<e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
	<20090130110402.GB2908@free.fr> <gluv88$736$1@ger.gmane.org>
	<20090130135354.GA2566@free.fr>
Message-ID: <glv28v$j4d$1@ger.gmane.org>

Patrice Dumas wrote:
> Of course, this happens. But this is not covered by that policy.

It is. Non-responsive status is per package.

        Kevin Kofler



From kevin.kofler at chello.at  Fri Jan 30 14:21:13 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Jan 2009 15:21:13 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
References: <49821EF9.4040108@redhat.com> <49826A45.4030809@silfreed.net>
	<49830677.8000005@silfreed.net>
Message-ID: <glv2cp$j4d$2@ger.gmane.org>

Douglas E. Warner wrote:
> Also just to be clear, we shouldn't rebuild just for this, should we?

I'd say rebuild for Rawhide, leave release branches alone.

        Kevin Kofler



From pertusus at free.fr  Fri Jan 30 14:30:28 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 15:30:28 +0100
Subject: Unresponsive Maintianer: salimma
In-Reply-To: <glv28v$j4d$1@ger.gmane.org>
References: <gltoka$1tq$1@ger.gmane.org>
	<e76492710901292002i79c0ebfeh9a35828c90ecd7cd@mail.gmail.com>
	<20090130110402.GB2908@free.fr> <gluv88$736$1@ger.gmane.org>
	<20090130135354.GA2566@free.fr> <glv28v$j4d$1@ger.gmane.org>
Message-ID: <20090130143028.GC2566@free.fr>

On Fri, Jan 30, 2009 at 03:19:11PM +0100, Kevin Kofler wrote:
> Patrice Dumas wrote:
> > Of course, this happens. But this is not covered by that policy.
> 
> It is. Non-responsive status is per package.

No, it is per maintainer. If a maintainer is active, it means that he 
can be contacted, and the non maintainer procedure should not be 
continued.

--
Pat



From notting at redhat.com  Fri Jan 30 15:00:46 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 10:00:46 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <49827FAF.3050306@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
Message-ID: <20090130150046.GA8869@nostromo.devel.redhat.com>

Brian Maly (bmaly at redhat.com) said: 
>>>> (1) its UEFI
>>>>       
>>> 1) I've *NEVER* seen an EFI BIOS that wasn't abysmally slow
>
> You have now.

No, I still haven't. That video's from grub, not from cold boot (and
there's nothing there that actally says it's using UEFI/Fastboot.)

Bill



From notting at redhat.com  Fri Jan 30 15:02:17 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 10:02:17 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233288493.3698.67.camel@localhost.localdomain>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
Message-ID: <20090130150217.GB8869@nostromo.devel.redhat.com>

Simo Sorce (ssorce at redhat.com) said: 
> In the fedora chart there seem to be a huge time (form sec 2.5, to sec
> 15) where the only things running are polymouthd and nash-hotplug, then
> another gap when udev starts, then everything start booting more or less
> in parallel.

The first gap is a bug in F10 GA where we weren't properly getting the
events from the kernel to determine that the storage is stabilized.
This should be fixed in updates/rawhide, and will not be there with
dracut anyway.

> Why fedora's udev seem to slow down another bit while moblin's udev seem
> not ?

The second udev is just more rules.

Bill



From benjavalero at gmail.com  Fri Jan 30 15:09:18 2009
From: benjavalero at gmail.com (=?UTF-8?Q?Benjam=C3=ADn_Valero_Espinosa?=)
Date: Fri, 30 Jan 2009 16:09:18 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090130141022.GB2566@free.fr>
References: <4982045B.3020405@redhat.com> <498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg> <20090130110105.GA2908@free.fr>
	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
	<20090130141022.GB2566@free.fr>
Message-ID: <a7804a540901300709x33026372ydd9555c777408ba5@mail.gmail.com>

2009/1/30 Patrice Dumas

> Sure. But removing texlive is not going to make that happen faster,
> on the contrary, Fedora will certainly lose all the TeX users and
> contributors, who are already very few.


Few users or few contributors?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/b2c18705/attachment.htm>

From pertusus at free.fr  Fri Jan 30 15:14:50 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Fri, 30 Jan 2009 16:14:50 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <a7804a540901300709x33026372ydd9555c777408ba5@mail.gmail.com>
References: <498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg>
	<20090130110105.GA2908@free.fr>
	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
	<20090130141022.GB2566@free.fr>
	<a7804a540901300709x33026372ydd9555c777408ba5@mail.gmail.com>
Message-ID: <20090130151450.GE2566@free.fr>

On Fri, Jan 30, 2009 at 04:09:18PM +0100, Benjam?n Valero Espinosa wrote:
> 2009/1/30 Patrice Dumas
> 
> > Sure. But removing texlive is not going to make that happen faster,
> > on the contrary, Fedora will certainly lose all the TeX users and
> > contributors, who are already very few.
> 
> Few users or few contributors?

Few contributors.

--
Pat



From tcallawa at redhat.com  Fri Jan 30 15:23:31 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 10:23:31 -0500
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090130001256.506d105c@gmx.net>
References: <497599B2.6030203@gmx.net>
	<4980DC1C.8000505@redhat.com>	<glr4gb$qno$1@ger.gmane.org>
	<glssu6$3pd$6@ger.gmane.org>	<4982045B.3020405@redhat.com>	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>	<498217C5.2040809@redhat.com>	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>	<498231AE.6050801@redhat.com>
	<20090130001256.506d105c@gmx.net>
Message-ID: <49831B73.1060308@redhat.com>

On 2009-01-29 at 18:12:56 -0500, Stefan Grosse <singularitaet at gmx.net>
wrote:
> "To the best of our knowledge, all the software in TeX Live meets the
> requirements of the Free Software Foundation's definition of free
> software, and the Debian Free Software Guidelines. Where the two
> conflict, we generally follow the FSF."
> 
> So maybe you dont want to rely on such a statement. But that makes
> quite an effort. 

Especially given that we've found 10+ non-free files inside of it.

> Some of the mentioned packages also where in tetex which was part in
> fedora before and no one complained about license issues.

Tetex was never license audited, because we inherited it from Red Hat
Linux, and when I got to it, we were in the process of moving to
texlive. I did a cursory audit of the original texlive import and we
caught some things, but I was nowhere near as thorough when I did that
original audit. I've learned a LOT since then. :)

> On Thu, 29 Jan 2009 17:46:06 -0500 "Tom \"spot\" Callaway"
>  wrote:
> TC> texmf/dvipdfmx/*
> 
> dvipdfmx at least is GPL see readme:
> http://www.ctan.org/tex-archive/dviware/dvipdfmx/

Okay, so the trick is that I need to match up those files in texlive
with the ones from CTAN. I can't assume random files in a directory with
the same name as something sanely licensed are the same. This is a big
reason why you should always always always always always put licensing
attribution in each file included in tarball. Always always always.

> It would be really sad removing texlive for those license oddities. It
> would be quite some competitive disadvantage.

Yes, but at the same time, we know that the texlive in Fedora now has
license issues. I've only scratched the surface of auditing texlive
2008. I'd rather be able to finish the audit and bring texlive 2008 into
Fedora, but there are only so many hours in the day.

~spot



From tcallawa at redhat.com  Fri Jan 30 15:35:21 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 10:35:21 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49830A2F.7010601@freenet.de>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
Message-ID: <49831E39.8060100@redhat.com>

On 2009-01-30 at 9:09:51 -0500, Ralf Corsepius <rc040203 at freenet.de> wrote:
> Tom "spot" Callaway wrote:
>> Please, if you're a packager, take a moment and go read this:
>>
>> https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description
>>
>>
>> After talking with Red Hat Legal about how we should be handling
>> trademarks in package summaries and descriptions, we came to the
>> conclusion that it would be far easier (and less risky for Red Hat) if
>> we did not use "(TM)" or "(R)" notations at all. This does not mean that
>> you can use trademarks freely, you still need to be careful in how you
>> use them. When in doubt, try not to use it. If you have questions, you
>> can either email me or fedora-legal at redhat.com.
> 
> IMO, your advice collides with "fair use" of trademarks, in particular
> when commonly used names actually refer to trademarked items or when
> package even contain something trademarked.
> 
> Cf. e.g.
> http://www.sgi.com/products/software/opengl/license.html
> http://www.sgi.com/products/software/opengl/trademarks.html

Not really. Please keep in mind that SGI's interpretation of fair use is
sketchy at best. In the US, only the owner of a trademark is permitted
to use the (R) symbol, and SGI describes it as fair use for anyone to
use it.

IMHO, SGI should stop writing licenses, all of the ones they've ever
written in house have been awful.

Certainly, it is permissable to use trademarks in according with the US
Lanham Act, in keeping with fair use, but also keep in mind that fair
use for trademarks is much much more complicated than fair use for
copyrights.

The general rule (as a result of US Supreme Court decisions) is that no
more of the trademark should be used than necessary for the legitimate
purpose, and that confusion should be avoided whenever possible.

~spot



From tcallawa at redhat.com  Fri Jan 30 15:36:13 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 10:36:13 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49826A45.4030809@silfreed.net>
References: <49821EF9.4040108@redhat.com> <49826A45.4030809@silfreed.net>
Message-ID: <49831E6D.5070501@redhat.com>

On 2009-01-29 at 21:47:33 -0500, "Douglas E. Warner"
<silfreed at silfreed.net> wrote:
> So, under this new guideline should I just remove the ?'s?  Is the rest
> of the information safe?

Yes, and Yes. :) You're clearly not claiming that the software is
Logitech Harmony, there is minimal chance for confusion there.

~spot



From dominik at greysector.net  Fri Jan 30 15:42:51 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Fri, 30 Jan 2009 16:42:51 +0100
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <20090130154250.GC28945@mokona.greysector.net>

On Friday, 30 January 2009 at 06:31, Matthew Garrett wrote:
> The blinking cursor causes the processor and GPU to be woken up 
> frequently. On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?

Yes. I very much like my blinking cursor and I'd be very annoyed if
it suddenly went away. It's one of those little things that you normally
don't notice.

I'd like to see some more specific data from that test of yours (and
your methodology).

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From limb at jcomserv.net  Fri Jan 30 15:49:42 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 30 Jan 2009 09:49:42 -0600 (CST)
Subject: CVS lock issue
Message-ID: <623bc04f74948961debbae863f2167e4.squirrel@mail.jcomserv.net>

This may be the wrong tree to bark up, but I thought I'd check.

I have a cvs lock in the xmoto/F-10 branch that I can't clear, for the
last few days.  Google instructs me to remove a file, but I don't have
shell access to the repo (AFAIK).  Who do I poke, Inf or Rel-Eng?

Thanks,
J


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From mmcgrath at redhat.com  Fri Jan 30 15:54:38 2009
From: mmcgrath at redhat.com (Mike McGrath)
Date: Fri, 30 Jan 2009 09:54:38 -0600 (CST)
Subject: CVS lock issue
In-Reply-To: <623bc04f74948961debbae863f2167e4.squirrel@mail.jcomserv.net>
References: <623bc04f74948961debbae863f2167e4.squirrel@mail.jcomserv.net>
Message-ID: <alpine.LFD.2.00.0901300954270.3265@laptop.mmcgrath.net>

On Fri, 30 Jan 2009, Jon Ciesla wrote:

> This may be the wrong tree to bark up, but I thought I'd check.
>
> I have a cvs lock in the xmoto/F-10 branch that I can't clear, for the
> last few days.  Google instructs me to remove a file, but I don't have
> shell access to the repo (AFAIK).  Who do I poke, Inf or Rel-Eng?
>

Should be ok now, give it a try.

	-Mike



From mclasen at redhat.com  Fri Jan 30 16:00:13 2009
From: mclasen at redhat.com (Matthias Clasen)
Date: Fri, 30 Jan 2009 11:00:13 -0500
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130082850.6200a1d1@dhcp03.addix.net>
References: <20090130053144.GA25512@srcf.ucam.org>
	<1233296507.20786.9.camel@matthiasc>
	<20090130082850.6200a1d1@dhcp03.addix.net>
Message-ID: <1233331214.3271.30.camel@matthiasc>

On Fri, 2009-01-30 at 08:28 +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 30 Jan 2009 01:21:47 -0500, Matthias Clasen wrote:
> 
> >   /**
> >    * GtkSettings:gtk-cursor-blink-timeout:
> >    *
> >    * Time after which the cursor stops blinking, in seconds.
> >    * The timer is reset after each user interaction.
> 
> So the cursor blinks at first, but then stops? I think that may confuse
> people ("My cursor is broken, it stopped blinking.")

No, it works very well in practice. The blinking starts again the moment
you do something, like move focus. 

Have you ever noticed that we hide the mouse pointer when you are typing
in an entry ? It comes back the moment you move the mouse. I have not
heard a single "My mouse is broken" complaint about that.




From rc040203 at freenet.de  Fri Jan 30 16:05:44 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 30 Jan 2009 17:05:44 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49831E39.8060100@redhat.com>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
	<49831E39.8060100@redhat.com>
Message-ID: <49832558.1050300@freenet.de>

Tom "spot" Callaway wrote:
> On 2009-01-30 at 9:09:51 -0500, Ralf Corsepius <rc040203 at freenet.de> wrote:
>> Tom "spot" Callaway wrote:
>>> Please, if you're a packager, take a moment and go read this:
>>>
>>> https://fedoraproject.org/wiki/Packaging:Guidelines#Trademarks_in_Summary_or_Description
>>>
>>>
>>> After talking with Red Hat Legal about how we should be handling
>>> trademarks in package summaries and descriptions, we came to the
>>> conclusion that it would be far easier (and less risky for Red Hat) if
>>> we did not use "(TM)" or "(R)" notations at all. This does not mean that
>>> you can use trademarks freely, you still need to be careful in how you
>>> use them. When in doubt, try not to use it. If you have questions, you
>>> can either email me or fedora-legal at redhat.com.
>> IMO, your advice collides with "fair use" of trademarks, in particular
>> when commonly used names actually refer to trademarked items or when
>> package even contain something trademarked.
>>
>> Cf. e.g.
>> http://www.sgi.com/products/software/opengl/license.html
>> http://www.sgi.com/products/software/opengl/trademarks.html
> 
> Not really. Please keep in mind that SGI's interpretation of fair use is
> sketchy at best. In the US, only the owner of a trademark is permitted
> to use the (R) symbol, and SGI describes it as fair use for anyone to
> use it.
Then let me ask differently:
RH prefers _us_ to refer to Microsoft instead of Microsoft(TM), rsp. to 
Red Hat instead of Red Hat(TM), rsp. to Fedora instead of Fedora (TM) in 
documents, packages, etc?

This collides with any common practice I've seen so far.

Documents referring to trademarked items typically either use ... 
"Windows(TM)" or "Windows" accompanied with a footnote disclaimer 
"Windows is a trademark of Microsoft ...".

> The general rule (as a result of US Supreme Court decisions) is that no
> more of the trademark should be used than necessary for the legitimate
> purpose, and that confusion should be avoided whenever possible.

OK, I maintain a package originating from SGI(TM) called Inventor(TM)
(a trademark of SGI)? What to do about it?

To me, acknowledging their trademarks in Fedora(TM) is fair use.

Ralf





From jreiser at BitWagon.com  Fri Jan 30 16:22:41 2009
From: jreiser at BitWagon.com (John Reiser)
Date: Fri, 30 Jan 2009 08:22:41 -0800
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <1233331214.3271.30.camel@matthiasc>
References: <20090130053144.GA25512@srcf.ucam.org>	<1233296507.20786.9.camel@matthiasc>	<20090130082850.6200a1d1@dhcp03.addix.net>
	<1233331214.3271.30.camel@matthiasc>
Message-ID: <49832951.4070303@BitWagon.com>

Matthias Clasen wrote:
> Have you ever noticed that we hide the mouse pointer when you are typing
> in an entry ? It comes back the moment you move the mouse. I have not
> heard a single "My mouse is broken" complaint about that.

I noticed this before you mentioned it.  It's the kind of bug
which does not admit a crisp bug report unless you "solve" it
(manage to determine the reason for the behavior) before going
to Bugzilla.  This de-motivates complaints.

-- 



From kanarip at kanarip.com  Fri Jan 30 16:34:31 2009
From: kanarip at kanarip.com (Jeroen van Meeuwen)
Date: Fri, 30 Jan 2009 17:34:31 +0100
Subject: Call for Ruby package maintainer
In-Reply-To: <20090130.201514.1001913346498032707.tagoh@redhat.com>
References: <497FA870.2030806@kanarip.com>	<20090128.182208.612299192959538683.tagoh@redhat.com>	<4981D43E.3030404@kanarip.com>
	<20090130.201514.1001913346498032707.tagoh@redhat.com>
Message-ID: <49832C17.8060203@kanarip.com>

Akira TAGOH wrote:
>>>>>> On Thu, 29 Jan 2009 17:07:26 +0100,
>>>>>> "JvM" == Jeroen van Meeuwen <kanarip at kanarip.com> wrote:
> 
> JvM> If you orphan the package in PackageDB, I'll pick it up so you can add yourself back as a co-maintainer.
> 
> Done.
> 

Done, here too.

Thanks,

Kind regards,

Jeroen van Meeuwen
-kanarip



From rc040203 at freenet.de  Fri Jan 30 16:40:51 2009
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 30 Jan 2009 17:40:51 +0100
Subject: buildsys problems?
Message-ID: <49832D93.2050307@freenet.de>

Hi,

I am trying to build a package in Fedora's buildsys, but any attempts to 
fails due to a missing package:

http://koji.fedoraproject.org/koji/getfile?taskID=1094016&name=root.log
...
DEBUG util.py:250:  No Package Found for perl(Mail::POP3Client)
...

perl-Mail-POP3Client had been built on Monday and should have be pushed 
to "updates" several hours ago:
https://admin.fedoraproject.org/updates/F10/FEDORA-2009-1133
https://www.redhat.com/archives/fedora-package-announce/2009-January/msg01134.html

Seemingly it neither is available in the buildsys nor in "updates".

What is going on?

Ralf



From tcallawa at redhat.com  Fri Jan 30 16:42:13 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 11:42:13 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49832558.1050300@freenet.de>
References: <49821EF9.4040108@redhat.com>
	<49830A2F.7010601@freenet.de>	<49831E39.8060100@redhat.com>
	<49832558.1050300@freenet.de>
Message-ID: <49832DE5.6070107@redhat.com>

On 2009-01-30 at 11:05:44 -0500, Ralf Corsepius <rc040203 at freenet.de> wrote:

> Then let me ask differently:
> RH prefers _us_ to refer to Microsoft instead of Microsoft(TM), rsp. to
> Red Hat instead of Red Hat(TM), rsp. to Fedora instead of Fedora (TM) in
> documents, packages, etc?

This guideline only applies to package Summaries and Descriptions.

However, the answer to your question is yes. Specifically, unless we
(Fedora/Red Hat)
have entered into a license that may require that we mark a trademark,
we should not
do so. We should use the trademark properly, all capital letters or at
least initial cap,
plus as an adjective, not a noun, but not designate with any symbol. The
symbols have
legal ramifications, so having it wrong may cause more trouble than not
doing it at all,

> This collides with any common practice I've seen so far.
> 
> Documents referring to trademarked items typically either use ...
> "Windows(TM)" or "Windows" accompanied with a footnote disclaimer
> "Windows is a trademark of Microsoft ...".
> 
>> The general rule (as a result of US Supreme Court decisions) is that no
>> more of the trademark should be used than necessary for the legitimate
>> purpose, and that confusion should be avoided whenever possible.
> 
> OK, I maintain a package originating from SGI(TM) called Inventor(TM)
> (a trademark of SGI)? What to do about it?
> 
> To me, acknowledging their trademarks in Fedora(TM) is fair use.

If you wish to add "SGI and Inventor are trademarks of SGI" to the
description, you can do so.
However, you should drop the (TM)s.

Thanks,

~spot



From limb at jcomserv.net  Fri Jan 30 16:50:26 2009
From: limb at jcomserv.net (Jon Ciesla)
Date: Fri, 30 Jan 2009 10:50:26 -0600 (CST)
Subject: CVS lock issue
In-Reply-To: <alpine.LFD.2.00.0901300954270.3265@laptop.mmcgrath.net>
References: <623bc04f74948961debbae863f2167e4.squirrel@mail.jcomserv.net>
	<alpine.LFD.2.00.0901300954270.3265@laptop.mmcgrath.net>
Message-ID: <a31e9530c824b593d0103427c9c65ff7.squirrel@mail.jcomserv.net>


> On Fri, 30 Jan 2009, Jon Ciesla wrote:
>
>> This may be the wrong tree to bark up, but I thought I'd check.
>>
>> I have a cvs lock in the xmoto/F-10 branch that I can't clear, for the
>> last few days.  Google instructs me to remove a file, but I don't have
>> shell access to the repo (AFAIK).  Who do I poke, Inf or Rel-Eng?
>>
>
> Should be ok now, give it a try.

Rock and/or Roll, it's good.  Thanks.

What'd I do?

> 	-Mike
>


-- 
in your fear, speak only peace
in your fear, seek only love

-d. bowie



From bmaly at redhat.com  Fri Jan 30 17:07:44 2009
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 30 Jan 2009 12:07:44 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <20090130150046.GA8869@nostromo.devel.redhat.com>
References: <1233260366.4952.29.camel@choeger6>
	<49821FD3.4020801@redhat.com>	<1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>	<1233288493.3698.67.camel@localhost.localdomain>	<49827FAF.3050306@redhat.com>
	<20090130150046.GA8869@nostromo.devel.redhat.com>
Message-ID: <498333E0.3040806@redhat.com>

Bill Nottingham wrote:
> Brian Maly (bmaly at redhat.com) said: 
>   
>>>>> (1) its UEFI
>>>>>       
>>>>>           
>>>> 1) I've *NEVER* seen an EFI BIOS that wasn't abysmally slow
>>>>         
>> You have now.
>>     
>
> No, I still haven't. That video's from grub, not from cold boot (and
> there's nothing there that actally says it's using UEFI/Fastboot.)
>
> Bill
>
>   
All UEFI systems Ive worked with boot incredibly fast. And further the 
Intel Moblin V2 Core's feature Fastboot on top of being UEFI (read the 
specs on this hardware). Further, all LinuxBIOS systems Ive worked with 
boot just as fast. Its not smoke and mirrors. Systems are completely 
capable of booting this quickly. Believe what you want though.

Brian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/4e14c4f4/attachment.htm>

From notting at redhat.com  Fri Jan 30 17:28:38 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 12:28:38 -0500
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130154250.GC28945@mokona.greysector.net>
References: <20090130053144.GA25512@srcf.ucam.org>
	<20090130154250.GC28945@mokona.greysector.net>
Message-ID: <20090130172838.GA11755@nostromo.devel.redhat.com>

Dominik 'Rathann' Mierzejewski (dominik at greysector.net) said: 
> > The blinking cursor causes the processor and GPU to be woken up 
> > frequently. On one of my test systems, this causes somewhere in the 
> > region of 2 Watts of extra power consumption. I'd like to change the 
> > default for this to false. Anyone have any objections?
> 
> Yes. I very much like my blinking cursor and I'd be very annoyed if
> it suddenly went away. It's one of those little things that you normally
> don't notice.

Note - this is about changing the default. Whatever option exists now
to turn it off will still be there for reenabling it.

Bill



From hughsient at gmail.com  Fri Jan 30 17:32:01 2009
From: hughsient at gmail.com (Richard Hughes)
Date: Fri, 30 Jan 2009 17:32:01 +0000
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130053144.GA25512@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
Message-ID: <1233336721.16036.0.camel@hughsie-work.lan>

On Fri, 2009-01-30 at 05:31 +0000, Matthew Garrett wrote:
> The blinking cursor causes the processor and GPU to be woken up 
> frequently. On one of my test systems, this causes somewhere in the 
> region of 2 Watts of extra power consumption. I'd like to change the 
> default for this to false. Anyone have any objections?

Fine for me. As long as people have a way to turn it back on, it should
be good for most people. It's a horrendous amount of power to save.

Richard.




From notting at redhat.com  Fri Jan 30 18:05:17 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 13:05:17 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <498333E0.3040806@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
	<20090130150046.GA8869@nostromo.devel.redhat.com>
	<498333E0.3040806@redhat.com>
Message-ID: <20090130180517.GB11755@nostromo.devel.redhat.com>

Brian Maly (bmaly at redhat.com) said: 
> All UEFI systems Ive worked with boot incredibly fast.

You're lucky, is all I can say. All the one's I've tried (from old Itaniums,
which are close enough, and new servers, which are UEFI) are very slow.

> And further the  
> Intel Moblin V2 Core's feature Fastboot on top of being UEFI (read the  
> specs on this hardware).

That might make sense, if Moblin V2 Core was a hardware spec. It's not:

http://moblin.org/community/blogs/tshureih/2009/announcing-moblin-v2-core-alpha-release

Furthermore, those were stock non-EFI hardware platforms in the demo.
Unless you're saying that the Moblin ISO silently replaces your BIOS
with UEFI. Which would be entertaining.

Bill



From bmaly at redhat.com  Fri Jan 30 18:11:47 2009
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 30 Jan 2009 13:11:47 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <20090130180517.GB11755@nostromo.devel.redhat.com>
References: <1233260366.4952.29.camel@choeger6>
	<49821FD3.4020801@redhat.com>	<1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>	<1233288493.3698.67.camel@localhost.localdomain>	<49827FAF.3050306@redhat.com>	<20090130150046.GA8869@nostromo.devel.redhat.com>	<498333E0.3040806@redhat.com>
	<20090130180517.GB11755@nostromo.devel.redhat.com>
Message-ID: <498342E3.3010106@redhat.com>

Bill Nottingham wrote:
> Brian Maly (bmaly at redhat.com) said: 
>   
>> All UEFI systems Ive worked with boot incredibly fast.
>>     
>
> You're lucky, is all I can say. All the one's I've tried (from old Itaniums,
> which are close enough, and new servers, which are UEFI) are very slow.
>
>   
Agreed. Old EFI was slow as a snail. But UEFI  (aka EFI 2.0) is another 
matter. Its designed to be faster even without Fastboot.
>> And further the  
>> Intel Moblin V2 Core's feature Fastboot on top of being UEFI (read the  
>> specs on this hardware).
>>     
>
> That might make sense, if Moblin V2 Core was a hardware spec. It's not:
>
> http://moblin.org/community/blogs/tshureih/2009/announcing-moblin-v2-core-alpha-release
>
> Furthermore, those were stock non-EFI hardware platforms in the demo.
> Unless you're saying that the Moblin ISO silently replaces your BIOS
> with UEFI. Which would be entertaining.
>
> Bill
>
>   
The Intel Moblin V2 core is UEFI and not legacy BIOS. The result is you 
would get to the bootloader in about 2 seconds from powering up the 
system, Admittedly this isnt demonstrated in video. Most of what you see 
there is due to booting of flash and pruning and reordering of boot 
sequence.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/c9aaeff5/attachment.htm>

From ssorce at redhat.com  Fri Jan 30 18:25:15 2009
From: ssorce at redhat.com (Simo Sorce)
Date: Fri, 30 Jan 2009 13:25:15 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <20090130150217.GB8869@nostromo.devel.redhat.com>
References: <1233260366.4952.29.camel@choeger6>
	<49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<20090130150217.GB8869@nostromo.devel.redhat.com>
Message-ID: <1233339915.30808.6.camel@localhost.localdomain>

On Fri, 2009-01-30 at 10:02 -0500, Bill Nottingham wrote:
> Simo Sorce (ssorce at redhat.com) said: 
> > In the fedora chart there seem to be a huge time (form sec 2.5, to sec
> > 15) where the only things running are polymouthd and nash-hotplug, then
> > another gap when udev starts, then everything start booting more or less
> > in parallel.
> 
> The first gap is a bug in F10 GA where we weren't properly getting the
> events from the kernel to determine that the storage is stabilized.
> This should be fixed in updates/rawhide, and will not be there with
> dracut anyway.

Ok cutting 10-12 seconds would already be a huge win.

> > Why fedora's udev seem to slow down another bit while moblin's udev seem
> > not ?
> 
> The second udev is just more rules.

What about parallelizing udev and rc like in moblin ? Any gotcha there ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



From bmaly at redhat.com  Fri Jan 30 18:33:02 2009
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 30 Jan 2009 13:33:02 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <1233339915.30808.6.camel@localhost.localdomain>
References: <1233260366.4952.29.camel@choeger6>	<49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6>	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>	<1233288493.3698.67.camel@localhost.localdomain>	<20090130150217.GB8869@nostromo.devel.redhat.com>
	<1233339915.30808.6.camel@localhost.localdomain>
Message-ID: <498347DE.9020507@redhat.com>

Simo Sorce wrote:
>
>   
>>> Why fedora's udev seem to slow down another bit while moblin's udev seem
>>> not ?
>>>       
>> The second udev is just more rules.
>>     
>
> What about parallelizing udev and rc like in moblin ? Any gotcha there ?
>
> Simo.
>
>   

What would happen if you parallelizing udev and rc on some ancient piece 
of hardware? Im thinking you might not ever get to a boot screen.
But you could check to see what sort of CPU you have and parallelize 
conditionally if the hardware can handle it. Conceptually I think 
parallelizing this stuff is a novel idea. Its feasible in that its been 
done (i.e. the demo). And if we could optimize udev a bit we might gain 
a few more seconds there too.
Good topic of discussion anyway...


Brian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/16448658/attachment.htm>

From mschwendt at gmail.com  Fri Jan 30 19:01:18 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 20:01:18 +0100
Subject: Too many unowned directories
Message-ID: <20090130200118.dcf06aa3.mschwendt@gmail.com>

| https://fedoraproject.org/wiki/Packaging/ReviewGuidelines
|
| MUST: A package must own all directories that it creates. If it does not
| create a directory that it uses, then it should require a package which
| does create that directory.
|
| https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership
| https://fedoraproject.org/wiki/Packaging/UnownedDirectories

Despite being in the guidelines as above, more and more unowned
directories are found in Fedora/Rawhide.

They spring up like mushrooms.

There must be reviewers and packagers who don't understand above
guideline and who are not familiar with how to include files vs. directories
in RPM package %files lists.

For every dozen unowned directories that got fixed after reporting it in
bugzilla, it seems as if two new dozen unowned directories appear (or
reappear) in other packages. My script examines only new packages in
Rawhide (with EVR not seen before), and still there is no end to be seen
in the logs. Lots of obvious packaging mistakes which could have been
noticed easily in the .spec file already, but also lots of unowned
directories which reveal missing dependencies. For dozens of bugzilla
tickets, the packagers don't respond. Sooner or later the bug triagers
will threaten with closing such tickets. Reopening them semi-automatically
will lead to an ugly fight.

I think what I'm trying to express here is that it's a lost cause.



From ville.skytta at iki.fi  Fri Jan 30 19:15:08 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Fri, 30 Jan 2009 21:15:08 +0200
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090130063643.GB20693@localhost.localdomain>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<200901292032.59727.ville.skytta@iki.fi>
	<20090130063643.GB20693@localhost.localdomain>
Message-ID: <200901302115.09357.ville.skytta@iki.fi>

On Friday 30 January 2009, David Tardon wrote:

> I checked it on several packages;

Actually, based on the following, you checked specfiles, not packages.  See 
CAVEATS in the rpmlint man page.

> for example, when I removed Name, 
> Version, Release, Group, Summary, License, URL, BuildArch, SourceX,
> PatchX from F-10's dcobook-dtds, rmplint happily answered
>
> 0 packages and 1 specfiles checked; 0 errors, 0 warnings.
>
> It seems to me rpmlint _will not_ fail if the tag is not around,

As mentioned in another message in this thread and (quite vaguely) implied in 
the rpmlint manual page, rpmlint does not run these checks on specfiles but 
only on source and binary rpms.  I just made upstream svn query specfiles 
using rpm and pipe errors to its output, so querying separately for this 
purpose is no longer necessary and specfile only checks have some more 
coverage.



From kevin at scrye.com  Fri Jan 30 19:17:22 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Fri, 30 Jan 2009 12:17:22 -0700
Subject: fesco meeting summary - 2009-01-30
Message-ID: <20090130121722.7361f7a3@ohm.scrye.com>

=== Members Present ===
* Brian Pepple          (bpepple)
* Jarod Wilson          (j-rod)
* Kevin Fenzi           (nirik)
* Bill Nottingham       (notting)
* Jon Stanley           (jds2001)
* Dan Hor?k             (sharkcz) 
* Dennis Gilmore        (dgilmore)

=== Members Absent ===
* Josh Boyer            (jwb)
* David Woodhouse       (dwmw2)

== Summary ==

=== Features ===

* Stronger Hashes -
  https://fedoraproject.org/wiki/Features/StrongerHashes

  Many FESCo members were concerned with breaking preupgrade and yum
  upgrades from f9->f11. The feature owner was directed to see if this
  could be avoided and revisit the feature next week. 

* Architecture Support
  https://fedoraproject.org/wiki/Features/ArchitectureSupport

  FESCo tabled this to revisit this next week. There were questions
  about OLPC support and LSTP client machines. Discussion to continue
  on fedora-devel list.

* Crash catcher https://fedoraproject.org/wiki/Features/CrashCatcher

  FESCo has approved this feature. 

* SsytemTap Static Probes
  https://fedoraproject.org/wiki/Features/SystemtapStaticProbes

  FESCo has approved this feature. 

* GCC 4.4  https://fedoraproject.org/wiki/Features/gcc4.4
   
  FESCo has approved this feature.

* vmware-requirements, and other 'crutch-for-proprietary-software'
  packages

  FESCo has decided this is not acceptable content for Fedora. 

* FESCo needs to determine whether ovm is acceptable content

  FESCo re-iterated that this content is fine for Fedora, but something
  in Fedora should be able to use it before adding it to the
  repository. Providing it without a way to use it would be a bad user
  experience. 

* FESCo will meet in special session next week to review features. 
  Time and date to be determined. 

IRC log can be found at: 
http://kevin.fedorapeople.org/fesco-2009-01-30.txt

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/c58416b1/attachment.sig>

From cweyl at alumni.drew.edu  Fri Jan 30 19:18:54 2009
From: cweyl at alumni.drew.edu (Chris Weyl)
Date: Fri, 30 Jan 2009 11:18:54 -0800
Subject: buildsys problems?
In-Reply-To: <49832D93.2050307@freenet.de>
References: <49832D93.2050307@freenet.de>
Message-ID: <7dd7ab490901301118p4b3a5c98vc09d7acc2e709b75@mail.gmail.com>

On Fri, Jan 30, 2009 at 8:40 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> Hi,
>
> I am trying to build a package in Fedora's buildsys, but any attempts to
> fails due to a missing package:
>
[....snip....]
>
> Seemingly it neither is available in the buildsys nor in "updates".
>
> What is going on?

I don't have the details in front of me, but I'm seeing much the same
happen when I try to build perl-Fedora-Bugzilla for F-10: it depends
on a Moose update that was theoretically pushed to updates a day or
two ago.

                               -Chris
-- 
Chris Weyl
Ex astris, scientia



From drago01 at gmail.com  Fri Jan 30 19:22:03 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 20:22:03 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glsri0$3pd$2@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<glsri0$3pd$2@ger.gmane.org>
Message-ID: <f6ca9fed0901301122t43f3c8ebpb9b2cb015248c648@mail.gmail.com>

On Thu, Jan 29, 2009 at 7:12 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> Did it ever happen that a "provenpackager" or any packager in the days
>> of open ACLs cause any real damage to packages (not owned by him)?
>> I am not aware of any such cases, it seems to me that we are trying to
>> solve a non existing problem.
>
> It's mostly just paranoia, as always when the 's' word ("security") is
> involved.
>
> IMHO, all packages should have open ACLs, with no exceptions (yes, even the
> kernel!), and I don't think we should make it as hard to get into
> provenpackager as some people are suggesting (10 to 15 sponsors needed,
> WTF?).

+1

P.S: reading this from you was unexpected but nice to see, considering
that you answered my question why most of the core KDE packages have
closed ACLs (is this still the case?)  you said "because the KDE SIG
is already doing a good job" (which is no reason why other people
should not be allowed to do a good job too ;) )



From a.badger at gmail.com  Fri Jan 30 19:21:39 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 30 Jan 2009 11:21:39 -0800
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <20090130141022.GB2566@free.fr>
References: <4982045B.3020405@redhat.com>	<870180fe0901291226o14304294ua82c412a72c38b5c@mail.gmail.com>	<498217C5.2040809@redhat.com>	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>	<498231AE.6050801@redhat.com>	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>	<1233298356.14086.3.camel@arekh.okg>	<20090130110105.GA2908@free.fr>	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
	<20090130141022.GB2566@free.fr>
Message-ID: <49835343.7030200@gmail.com>

Patrice Dumas wrote:
> On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
>> Well, if you handwave packaging guidelines conformance away, 
> 
> It is not the point. Exceptions can be made when the cost is high and
> the benefit is low.

I think making exceptions is a good thing.  Our Guidelines should be
flexible enough to make exceptions when necessary.  But setting up the
analysis of when to make exceptions as "cost is high and benefit is low"
is doomed to failure.  There's a cost with any changes we make to how a
package wants to install when it comes fresh from upstream.  And the
benefit to that *individual* package is low.  But Fedora Linux, or any
Linux distribution, is more than the sum of its packages.  We're giving
our users a unified experience that is different than merely having them
download the package source, compile and install it themselves.  We're
giving them a unified, coherent set of programs which conform to certain
standards that it is possible for the end user to learn and apply to any
package that comes from us.

So rather than "cost is high, benefit is low", we need to understand
that exceptions are made when it doesn't make sense for the package to
follow the Guideline.  Conforming violates the spirit of the upstream
package.  It causes something to stop working with no way to fix it.  By
its very nature, the package is supposed to violate the Guideline.  And
when those are the case, we should be able to boil the Exception down to
some rule, know that that rule trumps the reasons for our current
Guideline, and write the Exception to cover that and future cases.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/c260a193/attachment.sig>

From mschwendt at gmail.com  Fri Jan 30 19:28:53 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 20:28:53 +0100
Subject: pkgconfig dep problems in rawhide 20090129
Message-ID: <20090130202853.56b67bf8.mschwendt@gmail.com>

Non-devel packages with problematic pkgconfig auto-dependencies
on -devel packages:

  avahi-ui-sharp  (bz 477308)
  deskbar-applet  (bz 477309)
  tomboy          (bz 476251)



From stickster at gmail.com  Fri Jan 30 19:46:36 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 30 Jan 2009 14:46:36 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49832DE5.6070107@redhat.com>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
	<49831E39.8060100@redhat.com> <49832558.1050300@freenet.de>
	<49832DE5.6070107@redhat.com>
Message-ID: <20090130194636.GJ28663@localhost.localdomain>

On Fri, Jan 30, 2009 at 11:42:13AM -0500, Tom spot Callaway wrote:
> On 2009-01-30 at 11:05:44 -0500, Ralf Corsepius <rc040203 at freenet.de> wrote:
> 
> > Then let me ask differently:
> > RH prefers _us_ to refer to Microsoft instead of Microsoft(TM), rsp. to
> > Red Hat instead of Red Hat(TM), rsp. to Fedora instead of Fedora (TM) in
> > documents, packages, etc?
> 
> This guideline only applies to package Summaries and Descriptions.
> 
> However, the answer to your question is yes. Specifically, unless we
> (Fedora/Red Hat) have entered into a license that may require that
> we mark a trademark, we should not do so. We should use the
> trademark properly, all capital letters or at least initial cap,
> plus as an adjective, not a noun, but not designate with any
> symbol. The symbols have legal ramifications, so having it wrong may
> cause more trouble than not doing it at all,
> 
> > This collides with any common practice I've seen so far.
> > 
> > Documents referring to trademarked items typically either use ...
> > "Windows(TM)" or "Windows" accompanied with a footnote disclaimer
> > "Windows is a trademark of Microsoft ...".
> > 
> >> The general rule (as a result of US Supreme Court decisions) is that no
> >> more of the trademark should be used than necessary for the legitimate
> >> purpose, and that confusion should be avoided whenever possible.
> > 
> > OK, I maintain a package originating from SGI(TM) called Inventor(TM)
> > (a trademark of SGI)? What to do about it?
> > 
> > To me, acknowledging their trademarks in Fedora(TM) is fair use.
> 
> If you wish to add "SGI and Inventor are trademarks of SGI" to the
> description, you can do so.
> However, you should drop the (TM)s.

Hi Spot,

Would you say we should treat trademarked terms similarly in Fedora
documentation?  If so, I'll note that in the Style Guide for future
reference.

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/4de09d74/attachment.sig>

From rdieter at math.unl.edu  Fri Jan 30 19:47:04 2009
From: rdieter at math.unl.edu (Rex Dieter)
Date: Fri, 30 Jan 2009 13:47:04 -0600
Subject: Too many unowned directories
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
Message-ID: <glvlhb$qud$1@ger.gmane.org>

Michael Schwendt wrote:

> | https://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> |
> | MUST: A package must own all directories that it creates. If it does not
> | create a directory that it uses, then it should require a package which
> | does create that directory.
> |
> |
https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership
> | https://fedoraproject.org/wiki/Packaging/UnownedDirectories
> 
> Despite being in the guidelines as above, more and more unowned
> directories are found in Fedora/Rawhide.
> 
> They spring up like mushrooms.
> 
> There must be reviewers and packagers who don't understand above
> guideline and who are not familiar with how to include files vs.
> directories in RPM package %files lists.
...
> I think what I'm trying to express here is that it's a lost cause.

It may be a dirty job, but the work you put into this is much appreciated. 
Education (and subsequent fixes) takes time.

-- Rex




From walters at verbum.org  Fri Jan 30 19:48:49 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 30 Jan 2009 14:48:49 -0500
Subject: Too many unowned directories
In-Reply-To: <20090130200118.dcf06aa3.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
Message-ID: <faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>

On Fri, Jan 30, 2009 at 2:01 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
>
> I think what I'm trying to express here is that it's a lost cause.

I think the conclusion was that this problem would just go away if RPM
reference counted directories?  So it doesn't have to be a lost cause;
the conclusion can be instead that it makes sense to
improve/extend/fix core infrastructure rather than having humans
hand-maintain metadata.



From christoph.wickert at googlemail.com  Fri Jan 30 19:49:27 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Fri, 30 Jan 2009 20:49:27 +0100
Subject: Too many unowned directories
In-Reply-To: <20090130200118.dcf06aa3.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
Message-ID: <1233344967.9099.13.camel@wicktop.localdomain>

Am Freitag, den 30.01.2009, 20:01 +0100 schrieb Michael Schwendt:
> | https://fedoraproject.org/wiki/Packaging/ReviewGuidelines
> |
> | MUST: A package must own all directories that it creates. If it does not
> | create a directory that it uses, then it should require a package which
> | does create that directory.
> |
> | https://fedoraproject.org/wiki/Packaging/Guidelines#FileAndDirectoryOwnership
> | https://fedoraproject.org/wiki/Packaging/UnownedDirectories
> 
> Despite being in the guidelines as above, more and more unowned
> directories are found in Fedora/Rawhide.
> 
> They spring up like mushrooms.
> 
> There must be reviewers and packagers who don't understand above
> guideline and who are not familiar with how to include files vs. directories
> in RPM package %files lists.

This underlines what I said recently about the quality of (at least some
of) the latest reviews.

Can you give me a list of packages and/or bugs so I can start working in
that?

Regards,
Christoph



From tcallawa at redhat.com  Fri Jan 30 19:52:25 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 14:52:25 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <20090130194636.GJ28663@localhost.localdomain>
References: <49821EF9.4040108@redhat.com>
	<49830A2F.7010601@freenet.de>	<49831E39.8060100@redhat.com>
	<49832558.1050300@freenet.de>	<49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
Message-ID: <49835A79.1040801@redhat.com>

On 2009-01-30 at 14:46:36 -0500, "Paul W. Frields" <stickster at gmail.com>
wrote:
> Would you say we should treat trademarked terms similarly in Fedora
> documentation?  If so, I'll note that in the Style Guide for future
> reference.

I'll ask RH Legal. The advice given was strictly in reference to package
Summary and Descriptions.

~spot



From stickster at gmail.com  Fri Jan 30 19:57:51 2009
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 30 Jan 2009 14:57:51 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49835A79.1040801@redhat.com>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
	<49831E39.8060100@redhat.com> <49832558.1050300@freenet.de>
	<49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
Message-ID: <20090130195751.GL28663@localhost.localdomain>

On Fri, Jan 30, 2009 at 02:52:25PM -0500, Tom spot Callaway wrote:
> On 2009-01-30 at 14:46:36 -0500, "Paul W. Frields" <stickster at gmail.com>
> wrote:
> > Would you say we should treat trademarked terms similarly in Fedora
> > documentation?  If so, I'll note that in the Style Guide for future
> > reference.
> 
> I'll ask RH Legal. The advice given was strictly in reference to package
> Summary and Descriptions.

Fantastic, thanks Spot... we can move any follow up to
fedora-legal-list if you like.

-- 
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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/59cc0036/attachment.sig>

From mschwendt at gmail.com  Fri Jan 30 20:15:36 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 21:15:36 +0100
Subject: Too many unowned directories
In-Reply-To: <faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
Message-ID: <20090130211536.b7aa63d9.mschwendt@gmail.com>

On Fri, 30 Jan 2009 14:48:49 -0500, Colin wrote:

> I think the conclusion was that this problem would just go away if RPM
> reference counted directories?

When will that happen?

A restrictive umask still creates inaccessible unowned directories when
installing packages. And these bad permissions of such directories cannot
be verified/discovered with "rpm --verify" either.

In other cases, unowned directories are the result of missing
dependencies. And in turn, "yum install foo" installs a non-working
package. Dir refcounting in RPM cannot fix that. 



From kevin at scrye.com  Fri Jan 30 20:15:37 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Fri, 30 Jan 2009 13:15:37 -0700
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <20090130121722.7361f7a3@ohm.scrye.com>
References: <20090130121722.7361f7a3@ohm.scrye.com>
Message-ID: <20090130131537.0e2922be@ohm.scrye.com>

To followup on my own posting: 

- Note that we went long this week and were unable to get to all the
  items on the agenda. Hopefully the special session next week will get
  us caught back up. :( 

- I have put the meeting irc log up at: 
https://fedoraproject.org/wiki/Meeting:Fesco_IRC_Log_20090130
if you would prefer to read it in a nicer format than txt. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/01de4d08/attachment.sig>

From mschwendt at gmail.com  Fri Jan 30 20:20:34 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 21:20:34 +0100
Subject: Too many unowned directories
In-Reply-To: <1233344967.9099.13.camel@wicktop.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<1233344967.9099.13.camel@wicktop.localdomain>
Message-ID: <20090130212034.3389bf53.mschwendt@gmail.com>

On Fri, 30 Jan 2009 20:49:27 +0100, Christoph wrote:

> Can you give me a list of packages and/or bugs so I can start working in
> that?

Quick-search in bz for "Unowned dir" returns plenty of them.



From robert at fedoraproject.org  Fri Jan 30 20:19:46 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 30 Jan 2009 21:19:46 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <a9d183c80901291230wa042896yaaa684a197695066@mail.gmail.com>
References: <1233182104.3786.19.camel@wicktop.localdomain>
	<glsri0$3pd$2@ger.gmane.org>
	<20090129193426.GB16011@hurricane.linuxnetz.de>
	<200901291147.49386.konrad@tylerc.org>
	<a9d183c80901291230wa042896yaaa684a197695066@mail.gmail.com>
Message-ID: <20090130201946.GA4712@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Thomas Moschny wrote:
> 2009/1/29 Conrad Meyer <konrad at tylerc.org>:
> > In either case, the package owner gets an email summarizing changes to CVS,
> > and can revert the CVS change. If the newbie was malevolant and/or the problem
> > persists, they can be kicked out of Fedora. If not, they learned their lesson
> > (similar to Wikipedia's "please go play in the sandbox, kid").
> 
> Unless (as I was told today on IRC, did not try that myself) there's
> still some sort of long-standing bug allowing you to suppress that
> email by pressing ctrl-c at the right moment.

Yes, this issue still exists. It happend to myself accidentally a couple of
times in the past, when switching and acting to the wrong screen.

But didn't we learn in this thread, that Fedora only has good people, that
never wouldn't exploit such an issue? Wasn't there "believe-in-good-will"
mentioned by drago01 or the "you'll have to accept that not everyone is as
paranoid as you" by Kevin Kofler? That are just two examples, the third one
is anyway at the beginning of this e-mail. Believe in good of all Fedora
people can't be the way how we handle security relevant things. And the
provenpackager thing is IMHO somehow related to that, as it currently even
protects us from harmful actions, where we maybe wouldn't get noticed via
e-mail about, caused by this long-standing CVS issue.

And yes, I know I'm the only bad guy in whole Fedora (except the Robert
Scheck-haters as Conrad Meyer luckily pointed out). Nicolas Mailhot is
putting me to his shitlist...so yes, there is really no reason why we do
not need security and some paranoia at the Fedora Project as long as we
have enough believe in good will. And as the former bad guy Thorsten got
more and more inactive in the last time, it looks like it's just me... ;-)

If we're really going to make provenpackagers useless as some people have
suggested on this thread, we must fix that outstanding security issue in
before - independent whether I'm considered to be paranoid or not. I still
wonder, why this didn't get assigned/solved/fixed until now.

Oh, if I've already the salt in my hands: I didn't hear since my December
2008 mail and a more-or-less-reply, that work is going on, no public news
regarding the current status: The intrusion into the servers of the Fedora
Project is still not solved - or does somebody hope, that it gets silently
forgotten? Maybe our "CSI Fedora" [1] can really take care about and do one
or another autopsy to present the facts after 60 minutes as in TV series?
So we could hand out this case to "CSI Miami" or "CSI New York" instead of
trying to close the files in a silent way, too...

Security starts in the beginning and applying security updates is not the
whole thing - same as at quality rather quantity! And the minor details are
deciding whether it is safe, a hole or whether it's a feature or a bug. I
would like to assign the above mentioned issues to Paul and the rest of the
Fedora board with a higher priority as in before - I think we all can agree
here, that the current situation about lack of open communication and the
security issues are absolutely indiscutable, right?

[1] http://infrastructure.fedoraproject.org/csi/


Greetings,
  Robert



From walters at verbum.org  Fri Jan 30 20:25:44 2009
From: walters at verbum.org (Colin Walters)
Date: Fri, 30 Jan 2009 15:25:44 -0500
Subject: Too many unowned directories
In-Reply-To: <20090130211536.b7aa63d9.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
Message-ID: <faa16b610901301225x6b61281ej99d8b8fdfb4af59f@mail.gmail.com>

On Fri, Jan 30, 2009 at 3:15 PM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 30 Jan 2009 14:48:49 -0500, Colin wrote:
>
>> I think the conclusion was that this problem would just go away if RPM
>> reference counted directories?
>
> When will that happen?

I'd guess earlier than all spec files in Fedora become perfect.  I
believe Richard Jones said something recently along the lines of "we
can't treat rpm and lowlevel tools as unchangeable".

> A restrictive umask still creates inaccessible unowned directories when
> installing packages. And these bad permissions of such directories cannot
> be verified/discovered with "rpm --verify" either.

Yeah, I think I remember some flamewar about that.  (The solution
seems obvious to me; yum should set a fixed umask, if we *really* need
to support admins installing RPMs with custom permissions, it only
applies when you use rpm -i, not yum).  Or instead have a custom
--umask argument for rpm.

> In other cases, unowned directories are the result of missing
> dependencies. And in turn, "yum install foo" installs a non-working
> package. Dir refcounting in RPM cannot fix that.

Right, but if dependencies are missing things will be broken anyways.



From robert at fedoraproject.org  Fri Jan 30 20:28:18 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 30 Jan 2009 21:28:18 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129210410.GF20174@mokona.greysector.net>
References: <e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
	<20090129210410.GF20174@mokona.greysector.net>
Message-ID: <20090130202818.GB4712@hurricane.linuxnetz.de>

On Thu, 29 Jan 2009, Dominik 'Rathann' Mierzejewski wrote:
> On Thursday, 29 January 2009 at 21:51, Robert Scheck wrote:
> > With which benefit, if we remove the right to package mantainers to forbid
> > provenpackager commits except for some special canditates needing FESco? If
> > everybody can touch anything, why a co-maintainer?
> 
> Well, even with provenpackagers, it's not like they will start committing
> left and right into other people's packages. A co-maintainer is expected
> to be the first person to step in when the other maintainer is unable to
> do his job.

I was thinking here about to skip the maintainer/co-maintainer stuff at
all. Just one big bucket having everything in without different permissings
or roles.

> I'd also make it mandatory for provenpackagers to be members of at least
> one SIG like KDE, Server, Games etc., i.e. ones that deal with certain
> group of software packages so that their area of expertise is at least
> somewhat defined.

Interesting idea. But to which SIG would you assign me when looking to my
wiki page, my interests and which packages I'm maintaining? Or do I need to
found my own SIG for that then? I don't need to be a provenpackager, but I
am also playing theoretical scenarios.


Greetings,
  Robert



From notting at redhat.com  Fri Jan 30 20:35:05 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 15:35:05 -0500
Subject: Features/ArchitectureSupport - changing what we build for
Message-ID: <20090130203505.GA24850@nostromo.devel.redhat.com>

Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary: 
> * Architecture Support
>   https://fedoraproject.org/wiki/Features/ArchitectureSupport
> 
>   FESCo tabled this to revisit this next week. There were questions
>   about OLPC support and LSTP client machines. Discussion to continue
>   on fedora-devel list.

As a followup to the discussion on compiler flags, this feature was
written up to describe a plan for what to do overall about what
architectures we support. The main points are:

- install x86_64 kernel on 32-bit OS where appropriate
- install PAE kernel on other 32-bit OS installs where appropriate
- build only i686 and above for Fedora

The last one is the issue that caused discussion during the FESCo
meeting. The main points raised:

- XO support

There is concern that building for i686 might break binaries on the XO.
The Geode on the XO self-reports as i586; this may need slight frobbing.
Aside from that, it "supports the i686 (Pentium Pro) instruction set, MMX,
the parts of SSE that do not involve SSE registers, 3DNow! Enhanced, a
couple Geode-specific instructions and a few SSE2 instructions." 
  (http://wiki.laptop.org/go/Geode_instruction_set)

This implies it should work; however, there have been bugs in the past
(https://bugzilla.redhat.com/show_bug.cgi?id=200330). Chris Ball stated
"my input as OLPC software dude is that we're probably okay with dropping
586, but it would be great if someone heled us test that everything's
looking okay first."

- K12Linux/thin client

Some older thin client hardware is not i686 compatible. Warren has more
info on this. One question I have is that some of this is mentioned
as being Geode - wouldn't this fall into the same category as the XO?
Also, just how much of this hardware is out there using Fedora now
(as oppposed to RHEL, CentOS, or some other distribution?)

More info is on the feature page. Note that in the smolt stats, i586
accounts for less than one twentieth of one percent of active systems,
an order of magnitude less than PowerPC.

Bill



From drago01 at gmail.com  Fri Jan 30 20:40:06 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 21:40:06 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090130202818.GB4712@hurricane.linuxnetz.de>
References: <e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
	<20090129210410.GF20174@mokona.greysector.net>
	<20090130202818.GB4712@hurricane.linuxnetz.de>
Message-ID: <f6ca9fed0901301240u2c5eed84j730622718c8ba69@mail.gmail.com>

On Fri, Jan 30, 2009 at 9:28 PM, Robert Scheck <robert at fedoraproject.org> wrote:
> On Thu, 29 Jan 2009, Dominik 'Rathann' Mierzejewski wrote:
>> On Thursday, 29 January 2009 at 21:51, Robert Scheck wrote:
>> > With which benefit, if we remove the right to package mantainers to forbid
>> > provenpackager commits except for some special canditates needing FESco? If
>> > everybody can touch anything, why a co-maintainer?
>>
>> Well, even with provenpackagers, it's not like they will start committing
>> left and right into other people's packages. A co-maintainer is expected
>> to be the first person to step in when the other maintainer is unable to
>> do his job.
>
> I was thinking here about to skip the maintainer/co-maintainer stuff at
> all. Just one big bucket having everything in without different permissings
> or roles.

A maintainer[1] is (supposed to be) more that somebody with commit
access to the package
He/she deals with bugs, coordinate stuff with upstream, etc.


>> I'd also make it mandatory for provenpackagers to be members of at least
>> one SIG like KDE, Server, Games etc., i.e. ones that deal with certain
>> group of software packages so that their area of expertise is at least
>> somewhat defined.
>
> Interesting idea. But to which SIG would you assign me when looking to my
> wiki page, my interests and which packages I'm maintaining? Or do I need to
> found my own SIG for that then? I don't need to be a provenpackager, but I
> am also playing theoretical scenarios.

Well being in some random SIG does not prove anything.

Again I still think that the only problem that is to be solved here is
not the "security issues" but that some people trying to block their
packages for whatever reason.

1: If we want maintainers and not "package monkeys"



From drago01 at gmail.com  Fri Jan 30 20:42:55 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 21:42:55 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <f6ca9fed0901301242h1a4a5706udb0027aa62c99bc@mail.gmail.com>

On Fri, Jan 30, 2009 at 9:35 PM, Bill Nottingham <notting at redhat.com> wrote:
> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary:
>> * Architecture Support
>>   https://fedoraproject.org/wiki/Features/ArchitectureSupport
>>
>>   FESCo tabled this to revisit this next week. There were questions
>>   about OLPC support and LSTP client machines. Discussion to continue
>>   on fedora-devel list.
>
> As a followup to the discussion on compiler flags, this feature was
> written up to describe a plan for what to do overall about what
> architectures we support. The main points are:
>
> - install x86_64 kernel on 32-bit OS where appropriate

How is this going to work for livecd installs ?
Let yum pull in a x86_64 kernel on the first update if supported?



From notting at redhat.com  Fri Jan 30 20:47:01 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 15:47:01 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <f6ca9fed0901301242h1a4a5706udb0027aa62c99bc@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<f6ca9fed0901301242h1a4a5706udb0027aa62c99bc@mail.gmail.com>
Message-ID: <20090130204700.GB24850@nostromo.devel.redhat.com>

drago01 (drago01 at gmail.com) said: 
> > As a followup to the discussion on compiler flags, this feature was
> > written up to describe a plan for what to do overall about what
> > architectures we support. The main points are:
> >
> > - install x86_64 kernel on 32-bit OS where appropriate
> 
> How is this going to work for livecd installs ?

Yet to be determined.

Bill




From robert at fedoraproject.org  Fri Jan 30 20:51:52 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 30 Jan 2009 21:51:52 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <20090130205152.GC4712@hurricane.linuxnetz.de>

On Fri, 30 Jan 2009, Bill Nottingham wrote:
> - install x86_64 kernel on 32-bit OS where appropriate
> - install PAE kernel on other 32-bit OS installs where appropriate

How does the "where appropriate" exactly work? I didn't find technical
details for this...

> - build only i686 and above for Fedora

But we will keep the .i386.rpm for regular RPM packages anyway or are we
"upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?


Greetings,
  Robert



From pmatilai at laiskiainen.org  Fri Jan 30 20:51:59 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Fri, 30 Jan 2009 22:51:59 +0200 (EET)
Subject: Too many unowned directories
In-Reply-To: <20090130211536.b7aa63d9.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>

On Fri, 30 Jan 2009, Michael Schwendt wrote:

> On Fri, 30 Jan 2009 14:48:49 -0500, Colin wrote:
>
>> I think the conclusion was that this problem would just go away if RPM
>> reference counted directories?
>
> When will that happen?

Depends on how high a priority folks want it to have?

> A restrictive umask still creates inaccessible unowned directories when
> installing packages.

Rpm sets a default umask 0022 on initialization since 4.4.2.3. Where are 
you seeing inaccessible unowned directories being created? Ok, RHEL/Centos 
< 5.3 but that's not really Fedora land.

> And these bad permissions of such directories cannot
> be verified/discovered with "rpm --verify" either.
>
> In other cases, unowned directories are the result of missing 
> dependencies. And in turn, "yum install foo" installs a non-working 
> package. Dir refcounting in RPM cannot fix that.

Rpm could stop the install on unowned directories like it does for 
file conflicts. Not maybe the nicest user experience but non-working 
package is not any better.

 	- Panu -



From robert at fedoraproject.org  Fri Jan 30 20:57:44 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 30 Jan 2009 21:57:44 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <f6ca9fed0901301240u2c5eed84j730622718c8ba69@mail.gmail.com>
References: <20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
	<20090129210410.GF20174@mokona.greysector.net>
	<20090130202818.GB4712@hurricane.linuxnetz.de>
	<f6ca9fed0901301240u2c5eed84j730622718c8ba69@mail.gmail.com>
Message-ID: <20090130205744.GD4712@hurricane.linuxnetz.de>

On Fri, 30 Jan 2009, drago01 wrote:
> A maintainer[1] is (supposed to be) more that somebody with commit
> access to the package
> He/she deals with bugs, coordinate stuff with upstream, etc.

[...]

> Again I still think that the only problem that is to be solved here is
> not the "security issues" but that some people trying to block their
> packages for whatever reason.

Ehm? Which things except dealing bugs, upstream stuff etc. has a maintainer
or have the co-maintainers to handle a non-maintainer could do? And which
reason do you see not to let changes always go over the desk of maintainer
or co-maintainers (which is simply disallowing provenpackager)?

Four eyes see more than two. AFAIK the kernel people are reviewing all of
their changes and approve them various times before commiting them. Doing
this or similar things seems to be a quality enhancement to me (which comes
back to my original issue).


Greetings,
  Robert



From drago01 at gmail.com  Fri Jan 30 20:58:38 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 21:58:38 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130205152.GC4712@hurricane.linuxnetz.de>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130205152.GC4712@hurricane.linuxnetz.de>
Message-ID: <f6ca9fed0901301258l707c9e41neb85f1bf0bc20ecd@mail.gmail.com>

On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck <robert at fedoraproject.org> wrote:
> On Fri, 30 Jan 2009, Bill Nottingham wrote:
>> - install x86_64 kernel on 32-bit OS where appropriate
>> - install PAE kernel on other 32-bit OS installs where appropriate
>
> How does the "where appropriate" exactly work? I didn't find technical
> details for this...

If the hw is capable of doing so (ie any "modern" cpu)

>> - build only i686 and above for Fedora
>
> But we will keep the .i386.rpm for regular RPM packages anyway or are we
> "upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?

Mass rebuild to go i686.rpm



From drago01 at gmail.com  Fri Jan 30 21:09:58 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 22:09:58 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090130205744.GD4712@hurricane.linuxnetz.de>
References: <20090129072219.GA5712@hurricane.linuxnetz.de>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
	<20090129210410.GF20174@mokona.greysector.net>
	<20090130202818.GB4712@hurricane.linuxnetz.de>
	<f6ca9fed0901301240u2c5eed84j730622718c8ba69@mail.gmail.com>
	<20090130205744.GD4712@hurricane.linuxnetz.de>
Message-ID: <f6ca9fed0901301309i53d548dclad0230358639a1fb@mail.gmail.com>

On Fri, Jan 30, 2009 at 9:57 PM, Robert Scheck <robert at fedoraproject.org> wrote:
> On Fri, 30 Jan 2009, drago01 wrote:
>> A maintainer[1] is (supposed to be) more that somebody with commit
>> access to the package
>> He/she deals with bugs, coordinate stuff with upstream, etc.
>
> [...]
>
>> Again I still think that the only problem that is to be solved here is
>> not the "security issues" but that some people trying to block their
>> packages for whatever reason.
>
> Ehm? Which things except dealing bugs, upstream stuff etc. has a maintainer
> or have the co-maintainers to handle a non-maintainer could do? And which
> reason do you see not to let changes always go over the desk of maintainer
> or co-maintainers (which is simply disallowing provenpackager)?

see below.

> Four eyes see more than two. AFAIK the kernel people are reviewing all of
> their changes and approve them various times before commiting them. Doing
> this or similar things seems to be a quality enhancement to me (which comes
> back to my original issue).

Of course big changes should not be done without getting the
maintainers agreement.
But waiting for a maintainer to respond to a bug report for trivial
stuff like "rebuild against foo" is not very productive.
Also its easier to just tell a bug reporter (if he is a packager)
"changes look good, go ahead and commit"

That's how stuff worked now (also called "common sense"), do we really
need guidelines and restrictions for *everything*?



From jkeating at redhat.com  Fri Jan 30 21:12:56 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Jan 2009 13:12:56 -0800
Subject: what requires fedora-release-notes
In-Reply-To: <4982D32D.6090102@kanarip.com>
References: <200901281624.31502.pvrabec@redhat.com>
	<1233169541.8363.234.camel@localhost.localdomain>
	<20090128222404.GD5735@localhost.localdomain>
	<200901291219.43434.pvrabec@redhat.com> <4982D32D.6090102@kanarip.com>
Message-ID: <1233349976.3650.27.camel@localhost.localdomain>

On Fri, 2009-01-30 at 11:15 +0100, Jeroen van Meeuwen wrote:
> Peter Vrabec wrote:
> > thnx. folks,
> > 
> > I have filed two bugs:
> > 
> > 1. don't require fedora-release-notes in fedora-release
> > https://bugzilla.redhat.com/show_bug.cgi?id=483018
> > 
> > 2. install fedora-release-notes vie "base" group
> > https://bugzilla.redhat.com/show_bug.cgi?id=483019
> > 
> 
> Right, so now "fedora-release-notes" is in @base, instead of 
> "system-release-notes". As commented in the bug, can this be changed?
> 
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> -kanarip

Not until yum groupinstall operates on provides rather than strictly
package names.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/b02d7c40/attachment.sig>

From robert at fedoraproject.org  Fri Jan 30 21:19:33 2009
From: robert at fedoraproject.org (Robert Scheck)
Date: Fri, 30 Jan 2009 22:19:33 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <f6ca9fed0901301258l707c9e41neb85f1bf0bc20ecd@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130205152.GC4712@hurricane.linuxnetz.de>
	<f6ca9fed0901301258l707c9e41neb85f1bf0bc20ecd@mail.gmail.com>
Message-ID: <20090130211933.GE4712@hurricane.linuxnetz.de>

On Fri, 30 Jan 2009, drago01 wrote:
> On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck wrote:
> > How does the "where appropriate" exactly work? I didn't find technical
> > details for this...
> 
> If the hw is capable of doing so (ie any "modern" cpu)

Means that anaconda and yum will examine /proc/cpuinfo for example and look
for CPU flags and decide on that? And how will other updaters/installers as
e.g. smart/apt handle that? Or will we get this checks directly into RPM?

> > But we will keep the .i386.rpm for regular RPM packages anyway or are we
> > "upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
> 
> Mass rebuild to go i686.rpm

Okay, so we will have then only *.i686.rpm for 32 bit Intel everywhere?


Greetings,
  Robert



From mschwendt at gmail.com  Fri Jan 30 21:16:33 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 22:16:33 +0100
Subject: Too many unowned directories
In-Reply-To: <alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
Message-ID: <20090130221633.a5a82896.mschwendt@gmail.com>

On Fri, 30 Jan 2009 22:51:59 +0200 (EET), Panu wrote:

> Rpm sets a default umask 0022 on initialization since 4.4.2.3.

That seems to be Fedora >= 9. Good to hear that.
And I can confirm it with F10!
That's one annoyance less. :)

Unremoved versioned directories after package removal is a minor issue.
The inability to RPM-verify unowned directories becomes minor if dirs
default to 0755.

> Where are you seeing inaccessible unowned directories being created?

As I recall it, I could still reproduce it end of Nov 2008 in Rawhide, but
there's a small chance I was in a shell on F8 by mistake.



From jkeating at redhat.com  Fri Jan 30 21:22:10 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Jan 2009 13:22:10 -0800
Subject: Too many unowned directories
In-Reply-To: <alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
Message-ID: <1233350530.3650.28.camel@localhost.localdomain>

On Fri, 2009-01-30 at 22:51 +0200, Panu Matilainen wrote:
>  Rpm could stop the install on unowned directories like it does for 
> file conflicts. Not maybe the nicest user experience but non-working 
> package is not any better.

Why not fail the build if unowned directories are found, just like we do
for unowned files?  That way you catch it at build time before you try
and do something useful with the build.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/c3e242eb/attachment.sig>

From mitr at volny.cz  Fri Jan 30 21:26:43 2009
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Fri, 30 Jan 2009 21:26:43 +0000
Subject: Too many unowned directories
In-Reply-To: <1233350530.3650.28.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<1233350530.3650.28.camel@localhost.localdomain>
Message-ID: <1233350803.3345.18.camel@localhost.localdomain>

Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800:
> Why not fail the build if unowned directories are found, just like we do
> for unowned files?  That way you catch it at build time before you try
> and do something useful with the build.
How do we determine which directory is unowned and which is provided by
a dependency?  If we don't, every package would have to own /usr.
	Mirek



From jkeating at redhat.com  Fri Jan 30 21:26:36 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Jan 2009 13:26:36 -0800
Subject: Too many unowned directories
In-Reply-To: <1233350803.3345.18.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<1233350530.3650.28.camel@localhost.localdomain>
	<1233350803.3345.18.camel@localhost.localdomain>
Message-ID: <1233350796.3650.29.camel@localhost.localdomain>

On Fri, 2009-01-30 at 21:26 +0000, Miloslav Trma? wrote:
> Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800:
> > Why not fail the build if unowned directories are found, just like we do
> > for unowned files?  That way you catch it at build time before you try
> > and do something useful with the build.
> How do we determine which directory is unowned and which is provided by
> a dependency?  If we don't, every package would have to own /usr.
> 	Mirek

Good point, since we don't install the Requires at the same time we're
installing the BuildRequires to do the build that would be harder.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/3b0a46ac/attachment.sig>

From cmadams at hiwaay.net  Fri Jan 30 21:29:55 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 30 Jan 2009 15:29:55 -0600
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <20090130212955.GE741830@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> As a followup to the discussion on compiler flags, this feature was
> written up to describe a plan for what to do overall about what
> architectures we support. The main points are:
> 
> - install x86_64 kernel on 32-bit OS where appropriate

IIRC, I asked about this a few years ago and got told that there was a
performance hit (not big but measurable) for running the 64 bit kernel
and 32 bit userland.  Maybe that was wrong or is now outdated.

Right now, it is still possible to install on one i686 system and plug
the drive into another, which this could break (installing on i686 and
moving to <i686 has been broken for a long time, so maybe this isn't a
big consideration).

What are the chances GRUB/syslinux could be taught to look at a few
special CPU flags (can you fetch the important flags from real mode?)
and only present "compatible" (as determined by config arguments, not
GRUB/syslinux poking into kernels) boot options?  That would help the
LiveCD case as well.  You could have both 32-PAE and 64 kernels on the
CD and choose at boot time, although that would take up a large amount
of space (so maybe not feasible for LiveCD).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From mschwendt at gmail.com  Fri Jan 30 21:30:27 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Fri, 30 Jan 2009 22:30:27 +0100
Subject: Too many unowned directories
In-Reply-To: <1233350530.3650.28.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<1233350530.3650.28.camel@localhost.localdomain>
Message-ID: <20090130223027.f9d31439.mschwendt@gmail.com>

On Fri, 30 Jan 2009 13:22:10 -0800, Jesse wrote:

> Why not fail the build if unowned directories are found, just like we do
> for unowned files?  That way you catch it at build time before you try
> and do something useful with the build.

Some directories may be provided only by dependencies. You would need to
list all such dependencies as BuildRequires for a build-failure check
to become quick'n'easy (else it would need a depsolver for a closer look).



From notting at redhat.com  Fri Jan 30 21:36:30 2009
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 30 Jan 2009 16:36:30 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130211933.GE4712@hurricane.linuxnetz.de>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130205152.GC4712@hurricane.linuxnetz.de>
	<f6ca9fed0901301258l707c9e41neb85f1bf0bc20ecd@mail.gmail.com>
	<20090130211933.GE4712@hurricane.linuxnetz.de>
Message-ID: <20090130213630.GE24850@nostromo.devel.redhat.com>

Robert Scheck (robert at fedoraproject.org) said: 
> > If the hw is capable of doing so (ie any "modern" cpu)
> 
> Means that anaconda and yum will examine /proc/cpuinfo for example and look
> for CPU flags and decide on that? And how will other updaters/installers as
> e.g. smart/apt handle that? Or will we get this checks directly into RPM?

The 'choosing the best kernel' logic has always been outside the
package manager, dating back to the days of a separate SMP kernel.

Bill



From drago01 at gmail.com  Fri Jan 30 21:36:43 2009
From: drago01 at gmail.com (drago01)
Date: Fri, 30 Jan 2009 22:36:43 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130211933.GE4712@hurricane.linuxnetz.de>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130205152.GC4712@hurricane.linuxnetz.de>
	<f6ca9fed0901301258l707c9e41neb85f1bf0bc20ecd@mail.gmail.com>
	<20090130211933.GE4712@hurricane.linuxnetz.de>
Message-ID: <f6ca9fed0901301336u4d67e98ex5798919d16fd3a9@mail.gmail.com>

On Fri, Jan 30, 2009 at 10:19 PM, Robert Scheck
<robert at fedoraproject.org> wrote:
> On Fri, 30 Jan 2009, drago01 wrote:
>> On Fri, Jan 30, 2009 at 9:51 PM, Robert Scheck wrote:
>> > How does the "where appropriate" exactly work? I didn't find technical
>> > details for this...
>>
>> If the hw is capable of doing so (ie any "modern" cpu)
>
> Means that anaconda and yum will examine /proc/cpuinfo for example and look
> for CPU flags and decide on that? And how will other updaters/installers as
> e.g. smart/apt handle that? Or will we get this checks directly into RPM?

why should anything but anaconda care?
just upgrade what is installed to what is in the repos.

>> > But we will keep the .i386.rpm for regular RPM packages anyway or are we
>> > "upgrading" all ENVRA namings to .i586.rpm or .i686.rpm?
>>
>> Mass rebuild to go i686.rpm
>
> Okay, so we will have then only *.i686.rpm for 32 bit Intel everywhere?

yes



From chitlesh.goorah at gmail.com  Fri Jan 30 21:40:45 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Fri, 30 Jan 2009 22:40:45 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
Message-ID: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>

Hello there,

Before reading the mail, be brave people read this blog post first,
especially people from FESCo:
http://www.edn.com/blog/920000692/post/1290038929.html

Do comment on that blog post. Afterwards you read my email.

-------------------------------------------------------------



I found it sad that I have to write this email today. Well, it is part
of my contribution to both opensource software and opensource EDA
software communities.

The subject of this email is "Fedora Project, give me 20 Million Euros
or Free Software" ! Unfortunately, I'm not kidding and even 20 Million
Euros is not enough.

Well, let's get to the point !

-- Abstract
----------------------------------------------

I wish to maintain a package called OVM. This package is opensourced
by the two giant EDA Vendors : Cadence and Mentor Graphics, under the
Apache 2.0 license.
However, since there is no opensource tool to use OVM, FESCo has
freezed its entry.

Since when opensource software is more important than opensource content ?

https://bugzilla.redhat.com/show_bug.cgi?id=474980

-- About OVM: Open Verification Methodology
----------------------------------------------------------------------------------------------------------------------------------

The OVM is based on the IEEE 1800 SystemVerilog standard and supports
design and verification engineers developing advanced verification
environments that offer higher levels of integration and portability
of Verification IP. The methodology is non-vendor specific and is
interoperable with multiple languages and simulators. The OVM is fully
open, and includes a robust class library and source code that is
available for download.

-- Explanation of the "Don't kill OpenSource EDA software and its community" cry
-----------------------------------------------------------------------------------------------------------------------------------

About 90% of the opensource software you can use it as a replacement
of another proprietary software. However in the EDA industry this is
not true. There is NO EDA software (whether proprietary or opensource)
that can replace another. If someone tells you the contrary, export
him/her to planet Mars on the spot. NO EDA software is used by users
as the rpm is provided. For each project, you will need to tweak the
software as a user. That's one of the reasons why frontend digital
designers like Tcl and Perl.

Unlike the rest of the opensource SOFTWARE packagers, my users have NO
interest in opensource EDA design tools if in the end they can't
produce hardware with them!!

Why ?

I have 2 types of users ! the students and the hardware amateurs.
But these are not the ones I'm fighting for ! I'm fighting to seduce
the right people to encourage mass Fedora deployment with EDA tools.
These "right" people are lecturers and EDA engineers. You have noticed
that I didn't mention "analog/digital" engineers yet.

Lecturers will _find_ the right tools for the students so that they
can market themselves when looking for a job.
EDA engineers will be _contacted_ by big vendors to help him choose
the right tool for his/her "analog/digital" engineers. Some EDA
engineers will even be invited for several expensive hotels/dinners.

While the opensource software community talks about how they are proud
of AIGLX, fedora, OOo, Amarok, KDE4,..., I am sad to say that I can
not say the same for Open Hardware.

With Fedora Electronic Lab, we do not only attracted users with
respect to opensource EDA tools, but FEL contributors are heavily
divided into the following communities:
- opensource software : by shipping free EDA tools
- open Hardware : by targeting these persons

I will only consider that WE were successful with FEL if open Hardware
projects/companies HAVE USED opensource EDA tools to design their
hardware. This is a goal. A goal to reach and show what we can
achieved with opensource software.
I'm not talking about ghdl being used to simulate OpenSparc T2 for
example, I'm talking about completing the whole Open Hardware project
to Silicon. Amateurs/home made pcbs is simple.

Bridging these two communities, give us(Fedora)[#1] extra
responsibilities, which we are currently the opensource Leader in EDA
deployment. These responsibilities include maintaining the health of
the opensource EDA software community and encourage continuous
deployment. Unlike the opensource Linux ECO system, the EDA world is
dictated by:
- research and development in silicon.
- infinite number of standards.
- various quality-class proprietary EDA tools are available for free download
- ....

Among the industry standards, OVM IEEE 1800 SystemVerilog standard is
under an acceptable license for Fedora's inclusion. As you have surely
guessed the ODF standard was not made standard by some cheap geeks. It
costs money, time and development strategy. We (opensource community)
have nothing such thing to create a standard for electronics! We don't
currently have an opensource simulator for SystemVerilog. Now imagine
OOo without ODF support. Will the opensource software community dump
the ODF initiative ? We don't have human resources[2] to just pop a
simulator tool for systemverilog out of the blue.

Growing Numbers of SV users:
http://theasicguy.com/2009/01/27/dvcon-survey-results-what-do-they-mean/

You have certainly heard couple thousands layoffs in the semiconductor
industry this month. Companies are taking drastic measures to cut
expenses, I believe FEL will be attractive for them. Unlike the normal
fedora user, these companies will do mass fedora deployments from the
Note[1].
http://edablog.com/2009/01/12/edac-mss-q32008/

VMM also suffers the same issue.

--- Additional notes:

[#1]
I referred "us(Fedora)[#1]" because I strongly believe Fedora IS THE
ONLY ANSWER for the opensource EDA community.
Sorry, users from non-Fedora-based distribution should seriously
change their professional career if they are doing ASIC design.
Why ? : Electronic Design Automation Consortium has established EDA
Industry OS Roadmap guidelines for which platforms EDA vendors and
customers should target for design starts.
http://www.edac.org/industry_roadmap.jsp#roadmap
For Linux Users, you have RHEL and SLES. Please don't get excited
Linux was attractive because Vista failed to impress the EDA market.
If Windows 7 prove otherwise, EDA Vendors will provide less Linux
support. While these are proprietary software, they are the only way
to program their hardware devices. Take for example, you buy a
development FPGA kit from Altera or Xilinx, you can only program your
FPGA will their free tools on windows. It is free and users don't need
to care about its source code as they can have good support from their
vendors.

Hence, I have shown you how my users will think and how easy we can
lose linux users. I'm not talking about helping proprietary software,
but avoid dumping software that have been opensourced and are still
being maintained.

[#2].
human resources[2] : Unlike a normal software, electronic simulation
tools should be mature. Because the hardware being developed are the
one you will find in your brand new cars, airplanes, in various
medical devices. Since these are life critical applications, the
designer will not want a 2-week developed simulator. That is why I'm
saying that I don't think we will see a simulator so soon. According
to FESCo, no simulator -> no entry. Hence I see, no OVM entry before
the next five years and I will have to inform the opensource EDA
community that either the major opensource EDA Leader has discarded
the appreciation of this opensource content and initiative.

--- Conclusion
--------------------------------------------------------------------

Have a look around you further than fedora. Have a global view on the
Linux communities.

Answer the following questions:
- Who is the one focussing on electronics for the best electronic user
experience ?
Hint : compare Ngspice release and LTSpice release !
- Why is that one giving better solutions and user experience ?
- Has OS user experience being more important than electronic design
experience ?

- Can you bear that you have deliberately giving up Open content ?


Unlike OOo which tends to give OS user experience by replacing
Microsoft Office. For FEL, I don't have replacement of 70% of the
proprietary tools. If you are shutting down the doors on OVM, you are
also claiming fedora is not promoting open content, but only OS user
experience ? I would recommend FESCo to cancel/revisit each Feature
wiki page proposal as they provide more than OS user experience. Also
have a look at the EDA community promoting our Fedora everywhere:
http://jamespurser.com.au/blog/Open_Source_Startup_Group_-_An_Update
google for more.

Iverilog (which to me had more chance to provide SystemVerilog support
quickly) are focussing on Verilog-AMS which is also very important.
Mixed signal is all around now. The opensource EDA community don't
have that human resources. The 20 Million Euros is about balancing the
losses of that OVM was turned down.

perl-Verilog currently under the Fedora umbrella has incorporated some
extra systemverilog support. This new release will hit fedora mirrors
today.

I am not attacking anyone. I'm just reflecting the current reality. If
Fedora is not an answer for opensource EDA software, the opensource
community
You will laugh about this :

Give me an example of a software that is free in windows but need a
license on Linux.
It is the case in Electronics.

Help me find an answer to:
"What are the verification solutions Fedora provide ?"

What can opensource software community answer when EDA vendors give
away their software for free ?
http://www.eeproductcenter.com/embedded/brief/showArticle.jhtml;jsessionid=RWRCCHW5FOFZIQSNDLRCKH0CJUNN2JVN?articleID=212902950

I'm going to sleep with failure in my mind.
Good night.

A mature opensource EDA software costs at least 20 Million Euros.
Don't dump opensource CONTENT!

PS: in Belgium today, we have carried out meteorological measurements
with Hardware designed under Fedora.

Kind regards,
Chitlesh



From cry_regarder at yahoo.com  Fri Jan 30 22:00:03 2009
From: cry_regarder at yahoo.com (Cry)
Date: Fri, 30 Jan 2009 22:00:03 +0000 (UTC)
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
Message-ID: <loom.20090130T215554-885@post.gmane.org>

Chitlesh GOORAH <chitlesh.goorah <at> gmail.com> writes:

> The subject of this email is "Fedora Project, give me 20 Million Euros
> or Free Software" ! Unfortunately, I'm not kidding and even 20 Million
> Euros is not enough.

Fedora isn't a "if its free stick it in" repository.  It isn't the old sunsite.

Fedora is for linux (and I guess windows now) software and data that software
can use.  There isn't anything that can use OVM so why bundle it into fedora? 
Before you reply with 90 pages of prose, please have someone edit it down to a
readable subset.

If you really want it in, make an OVM browser or indexer and submit a package
for that.

Cry 



From cmadams at hiwaay.net  Fri Jan 30 22:05:17 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 30 Jan 2009 16:05:17 -0600
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <loom.20090130T215554-885@post.gmane.org>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
Message-ID: <20090130220517.GF741830@hiwaay.net>

Once upon a time, Cry <cry_regarder at yahoo.com> said:
> Fedora is for linux (and I guess windows now) software and data that software
> can use.  There isn't anything that can use OVM so why bundle it into fedora? 

That's kind of a poor definition.  What can use OpenOffice files other
than OpenOffice?  What can use GIMP files other than GIMP?

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.



From pmatilai at laiskiainen.org  Fri Jan 30 22:07:40 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 31 Jan 2009 00:07:40 +0200 (EET)
Subject: Too many unowned directories
In-Reply-To: <20090130221633.a5a82896.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<20090130221633.a5a82896.mschwendt@gmail.com>
Message-ID: <alpine.LFD.2.00.0901302353370.27679@turre.koti.laiskiainen.org>

On Fri, 30 Jan 2009, Michael Schwendt wrote:
> On Fri, 30 Jan 2009 22:51:59 +0200 (EET), Panu wrote:
>
>> Rpm sets a default umask 0022 on initialization since 4.4.2.3.
>
> That seems to be Fedora >= 9. Good to hear that.

Yup, since Fedora >= 9.

> And I can confirm it with F10!
> That's one annoyance less. :)
>
> Unremoved versioned directories after package removal is a minor issue.
> The inability to RPM-verify unowned directories becomes minor if dirs
> default to 0755.
>
>> Where are you seeing inaccessible unowned directories being created?
>
> As I recall it, I could still reproduce it end of Nov 2008 in Rawhide, but
> there's a small chance I was in a shell on F8 by mistake.

By Nov 2008 rpm certainly set a default umask, but it only sets it once at 
initialization time, so any API user (python or otherwise) has a chance to 
still change it to something else. I'm not aware of anything doing that 
but possible, yes - or you were on F8 shell :) And sure the umask setting 
could be pushed deep into the file processing mechanism to avoid API users 
messing with it if absolutely necessary.

 	- Panu -



From kevin.kofler at chello.at  Fri Jan 30 22:08:54 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Fri, 30 Jan 2009 23:08:54 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<glsri0$3pd$2@ger.gmane.org>
	<f6ca9fed0901301122t43f3c8ebpb9b2cb015248c648@mail.gmail.com>
Message-ID: <glvtpo$mq7$1@ger.gmane.org>

drago01 wrote:
> P.S: reading this from you was unexpected but nice to see, considering
> that you answered my question why most of the core KDE packages have
> closed ACLs (is this still the case?)  you said "because the KDE SIG
> is already doing a good job" (which is no reason why other people
> should not be allowed to do a good job too ;) )

Most of KDE has now been opened up to provenpackager, only the core packages
(kdelibs and kdebase*) are still closed. And that's probably also not
needed, I won't complain if they get opened up (as long as people don't
start committing nonsense like "follow GNOME HIG", "put the GenericName
into Name" or the like ;-) ).

Still, I must also say that I don't see why we're expected to open up while
at the same time the usual suspects (kernel, glibc etc. and also the
Firefox stack (*)) are allowed to stay locked down. :-/ How's that fair?
The same rules should apply to *all* packages, no exceptions.

        Kevin Kofler

(*) which is really worth a rant of its own - why do we accept those asinine
patch approval policies which keep us from doing cooperative development
and sometimes even from fixing real issues (I remember the
hunspell/xulrunner ABI fiasco) instead of just renaming the f***ing thing
like Debian does?



From jspaleta at gmail.com  Fri Jan 30 22:10:58 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 30 Jan 2009 13:10:58 -0900
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <loom.20090130T215554-885@post.gmane.org>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
Message-ID: <604aa7910901301410q50eab0f7jb87b08b7db03fc21@mail.gmail.com>

On Fri, Jan 30, 2009 at 1:00 PM, Cry <cry_regarder at yahoo.com> wrote:
> Chitlesh GOORAH <chitlesh.goorah <at> gmail.com> writes:
>
>> The subject of this email is "Fedora Project, give me 20 Million Euros
>> or Free Software" ! Unfortunately, I'm not kidding and even 20 Million
>> Euros is not enough.
>
> Fedora isn't a "if its free stick it in" repository.  It isn't the old sunsite.
>
> Fedora is for linux (and I guess windows now) software and data that software
> can use.  There isn't anything that can use OVM so why bundle it into fedora?

It's somewhat more subtle than that I think as OVM breaks some
established concepts about what is code and what is content. OVM is a
library. the OVM stuff sure looks like code to me. The readme even
talks about compiling it. It's code of some sort.  The problem is we
don't have a compiler or interpreter that can process the
instructions.  In the context of Fedora its code that can't be used.

Related questions which I think go to the heart of the matter are these.
Would we allow any c# code into Fedora if the open mono interpreter
wasn't available as part of Fedora?  I don't think we would.

Did we allow any java code into Fedora before there was an open java
interpreter?  I'm pretty sure we didn't...and if some slipped in it
was not intentional.

Before gdl was in Fedora would you let me ship the piles and piles of
open source scientific oriented IDL scripts that I have just sitting
around collecting dust if there was no intepreter for it in Fedora?
I'm pretty sure that would have not been allowed either.

OVM isn't new ground, its just different ground.

-jef



From chitlesh.goorah at gmail.com  Fri Jan 30 22:12:36 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Fri, 30 Jan 2009 23:12:36 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <loom.20090130T215554-885@post.gmane.org>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
Message-ID: <50baabb30901301412h1256d86fw3566266bffe75912@mail.gmail.com>

On Fri, Jan 30, 2009 at 11:00 PM, Cry wrote:
> Fedora is for linux (and I guess windows now) software and data that software
> can use.  There isn't anything that can use OVM so why bundle it into fedora?

If I follow your word "use", kwrite/kate can be used.
But the intention was also to tell you that Fedora has a role in open
hardware development.

> Cry
Please use your real name.

Cheers,
Chitlesh



From nicolas.mailhot at laposte.net  Fri Jan 30 22:04:23 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 30 Jan 2009 23:04:23 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
Message-ID: <1233353063.3733.17.camel@arekh.okg>

Le vendredi 30 janvier 2009 ? 22:40 +0100, Chitlesh GOORAH a ?crit :
> Hello there,
> 
> Before reading the mail, be brave people read this blog post first,
> especially people from FESCo:
> http://www.edn.com/blog/920000692/post/1290038929.html
> 
> Do comment on that blog post. Afterwards you read my email.

If that makes you feel better the EDA community is much much closer to
free software community than some others
http://typophile.com/node/53444
(also much bigger, with more resources, etc)

I don't believe there's any point in bending backwards to accomodate
hostile professional communities. The way to earn their respect and
consideration is to do something worthwhile within the FLOSS community,
not catter to their prejudices by ignoring our own principles.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/1b710aac/attachment.sig>

From ville.skytta at iki.fi  Fri Jan 30 22:29:01 2009
From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=)
Date: Sat, 31 Jan 2009 00:29:01 +0200
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <200901310029.02287.ville.skytta@iki.fi>

On Friday 30 January 2009, Bill Nottingham wrote:
> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary:
> > * Architecture Support
> >   https://fedoraproject.org/wiki/Features/ArchitectureSupport

> * 32-bit x86 would be built for i686 by default. 586-compatible processors
> would no longer be supported.  
[...]
> * i386: -march=i586 -mtune=generic 

Should the latter be -march=i686?



From ben.kreuter at gmail.com  Fri Jan 30 22:34:09 2009
From: ben.kreuter at gmail.com (Benjamin Kreuter)
Date: Fri, 30 Jan 2009 17:34:09 -0500
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <20090130220517.GF741830@hiwaay.net>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
	<20090130220517.GF741830@hiwaay.net>
Message-ID: <200901301734.13257.ben.kreuter@gmail.com>

On Friday 30 January 2009 05:05:17 pm Chris Adams wrote:
> Once upon a time, Cry <cry_regarder at yahoo.com> said:
> > Fedora is for linux (and I guess windows now) software and data that
> > software can use.  There isn't anything that can use OVM so why bundle it
> > into fedora?
>
> That's kind of a poor definition.  What can use OpenOffice files other
> than OpenOffice?

Google docs, KOffice, AbiWord (just for ODT), etc.

> What can use GIMP files other than GIMP?

GIMP exports PNG, which is supported by dozens of platforms including 
Microsoft Windows.

-- Ben



-- 
Message sent on: Fri Jan 30 17:33:07 EST 2009

-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/ffb5720a/attachment.sig>

From erikina at gmail.com  Fri Jan 30 22:35:34 2009
From: erikina at gmail.com (Eric Springer)
Date: Sat, 31 Jan 2009 08:35:34 +1000
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <20090130220517.GF741830@hiwaay.net>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
	<20090130220517.GF741830@hiwaay.net>
Message-ID: <ce9c609e0901301435h1f2658ccxcce096a650afa731@mail.gmail.com>

On 1/31/09, Chris Adams <cmadams at hiwaay.net> wrote:
> That's kind of a poor definition.  What can use OpenOffice files other
>  than OpenOffice?

Kword

> What can use GIMP files other than GIMP?

Krita


(Sorry couldn't help myself. Point taken though)



From pmatilai at laiskiainen.org  Fri Jan 30 22:36:27 2009
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sat, 31 Jan 2009 00:36:27 +0200 (EET)
Subject: Too many unowned directories
In-Reply-To: <1233350803.3345.18.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<1233350530.3650.28.camel@localhost.localdomain>
	<1233350803.3345.18.camel@localhost.localdomain>
Message-ID: <alpine.LFD.2.00.0901310025480.27679@turre.koti.laiskiainen.org>

On Fri, 30 Jan 2009, Miloslav Trma? wrote:

> Jesse Keating p??e v P? 30. 01. 2009 v 13:22 -0800:
>> Why not fail the build if unowned directories are found, just like we do
>> for unowned files?  That way you catch it at build time before you try
>> and do something useful with the build.
> How do we determine which directory is unowned and which is provided by
> a dependency?  If we don't, every package would have to own /usr.

It'd be possible to turn the topmost unowned directory into a file (well, 
directory) dependency. Either at build time, which would cause a big pile 
of new file dependencies in the metadata, or rpm could generate them at 
runtime. The problem with runtime generated dependencies is just that yum 
& the like wouldn't be able to resolve them without fairly big changes.

 	- Panu -



From tcallawa at redhat.com  Fri Jan 30 22:52:52 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Fri, 30 Jan 2009 17:52:52 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <20090130195751.GL28663@localhost.localdomain>
References: <49821EF9.4040108@redhat.com>
	<49830A2F.7010601@freenet.de>	<49831E39.8060100@redhat.com>
	<49832558.1050300@freenet.de>	<49832DE5.6070107@redhat.com>	<20090130194636.GJ28663@localhost.localdomain>	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
Message-ID: <498384C4.4020909@redhat.com>

On 2009-01-30 at 14:57:51 -0500, "Paul W. Frields" <stickster at gmail.com>
wrote:
> On Fri, Jan 30, 2009 at 02:52:25PM -0500, Tom spot Callaway wrote:
>> On 2009-01-30 at 14:46:36 -0500, "Paul W. Frields" <stickster at gmail.com>
>> wrote:
>>> Would you say we should treat trademarked terms similarly in Fedora
>>> documentation?  If so, I'll note that in the Style Guide for future
>>> reference.
>> I'll ask RH Legal. The advice given was strictly in reference to package
>> Summary and Descriptions.
> 
> Fantastic, thanks Spot... we can move any follow up to
> fedora-legal-list if you like.

No need, it can't hurt.

They advised that the same advice applies to Documentation.

Never use "tm" or "(R)". If we are obliged by contract to mention other
trademarks in a legend, add the legend as required by the contract.

In addition, our documentation should contain the disclaimer:  "All
other trademarks are the property of their respective owners."

~spot



From kevin.kofler at chello.at  Fri Jan 30 23:04:56 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 00:04:56 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
Message-ID: <gm012o$1hh$1@ger.gmane.org>

Fedora is not a content distribution. It's a software distribution. We only
ship content which is directly related to software we ship:
https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content

Fedora is not a content library, we cannot ship all the content in
existence, there's just too much of it.

OVM cannot be used with any software in Fedora, so it also does not belong
into Fedora. What's the point of shipping content which cannot be used?

The same rationale is also being applied to MP3 files, which are also not
permitted in Fedora.

        Kevin Kofler



From dominik at greysector.net  Fri Jan 30 23:09:00 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 31 Jan 2009 00:09:00 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <20090130230859.GD4298@mokona.greysector.net>

On Friday, 30 January 2009 at 21:35, Bill Nottingham wrote:
> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary: 
> > * Architecture Support
> >   https://fedoraproject.org/wiki/Features/ArchitectureSupport
> > 
> >   FESCo tabled this to revisit this next week. There were questions
> >   about OLPC support and LSTP client machines. Discussion to continue
> >   on fedora-devel list.
> 
> As a followup to the discussion on compiler flags, this feature was
> written up to describe a plan for what to do overall about what
> architectures we support. The main points are:
> 
> - install x86_64 kernel on 32-bit OS where appropriate
> - install PAE kernel on other 32-bit OS installs where appropriate
> - build only i686 and above for Fedora

There's going to be some screaming from VIA C3 and AMD K6 users about this.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From jan.kratochvil at redhat.com  Fri Jan 30 23:18:47 2009
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Sat, 31 Jan 2009 00:18:47 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <20090130231847.GA20809@host0.dyn.jankratochvil.net>

On Fri, 30 Jan 2009 21:35:05 +0100, Bill Nottingham wrote:
> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary: 
> > * Architecture Support
> >   https://fedoraproject.org/wiki/Features/ArchitectureSupport
[...]
> - install x86_64 kernel on 32-bit OS where appropriate

Could you please provide more public background for this FESCo decision?
Particularly why not to automatically install the whole x86_64 distro where
appropriate?  The DVD media should contain both arches as in the real world
found out the users are not aware if they have 64bit-capable hardware.

x86_64 provides CPU instruction set + ABI improvements which usually overcome
its only performance disadvantage of larger addresses, some benchmarks at:
http://www.amd64.org/fileadmin/user_upload/pub/64bit_Linux-Myths_and_Facts.pdf

Guessing some software (codecs?) may fallback on 64-bit to unoptimized C code
instead of some assembly one but Fedora would at least show the usefulness of
the updates of such software for the x86_64 arch.


Regards,
Jan



From konrad at tylerc.org  Fri Jan 30 23:25:43 2009
From: konrad at tylerc.org (Conrad Meyer)
Date: Fri, 30 Jan 2009 15:25:43 -0800
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130230859.GD4298@mokona.greysector.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130230859.GD4298@mokona.greysector.net>
Message-ID: <200901301525.43846.konrad@tylerc.org>

On Friday 30 January 2009 03:09:00 pm Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 30 January 2009 at 21:35, Bill Nottingham wrote:
> > Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary:
> > > * Architecture Support
> > >   https://fedoraproject.org/wiki/Features/ArchitectureSupport
> > >
> > >   FESCo tabled this to revisit this next week. There were questions
> > >   about OLPC support and LSTP client machines. Discussion to continue
> > >   on fedora-devel list.
> >
> > As a followup to the discussion on compiler flags, this feature was
> > written up to describe a plan for what to do overall about what
> > architectures we support. The main points are:
> >
> > - install x86_64 kernel on 32-bit OS where appropriate
> > - install PAE kernel on other 32-bit OS installs where appropriate
> > - build only i686 and above for Fedora
>
> There's going to be some screaming from VIA C3 and AMD K6 users about this.
>
> Regards,
> R.

Also breaks support for original pentium (i586) CPUs. My router will be 
perpetually stuck at Fedora 10, I guess.

Regards,
-- 
Conrad Meyer <konrad at tylerc.org>



From katzj at redhat.com  Fri Jan 30 23:37:00 2009
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 30 Jan 2009 18:37:00 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130212955.GE741830@hiwaay.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
Message-ID: <20090130233700.GE34421@redhat.com>

On Friday, January 30 2009, Chris Adams said:
> What are the chances GRUB/syslinux could be taught to look at a few
> special CPU flags (can you fetch the important flags from real mode?)
> and only present "compatible" (as determined by config arguments, not
> GRUB/syslinux poking into kernels) boot options?  That would help the
> LiveCD case as well.  You could have both 32-PAE and 64 kernels on the
> CD and choose at boot time, although that would take up a large amount
> of space (so maybe not feasible for LiveCD).

A com32 module could be written without too much trouble for syslinux,
but space on the live images make it kind of a moot point (imho) as it
seems better to ship more applications as opposed to more kernels on the
live image

Jeremy



From katzj at redhat.com  Fri Jan 30 23:37:48 2009
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 30 Jan 2009 18:37:48 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130203505.GA24850@nostromo.devel.redhat.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
Message-ID: <20090130233748.GF34421@redhat.com>

On Friday, January 30 2009, Bill Nottingham said:
> - XO support
> 
> There is concern that building for i686 might break binaries on the XO.
> The Geode on the XO self-reports as i586; this may need slight frobbing.
> Aside from that, it "supports the i686 (Pentium Pro) instruction set, MMX,
> the parts of SSE that do not involve SSE registers, 3DNow! Enhanced, a
> couple Geode-specific instructions and a few SSE2 instructions." 
>   (http://wiki.laptop.org/go/Geode_instruction_set)
> 
> This implies it should work; however, there have been bugs in the past
> (https://bugzilla.redhat.com/show_bug.cgi?id=200330). Chris Ball stated
> "my input as OLPC software dude is that we're probably okay with dropping
> 586, but it would be great if someone heled us test that everything's
> looking okay first."

The live images have been doing i686 kernel and glibc and work okay on
the XO.  So add that as more anecdotal evidence of it not being a
problem

Jeremy



From jwboyer at gmail.com  Fri Jan 30 23:47:05 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Fri, 30 Jan 2009 18:47:05 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130231847.GA20809@host0.dyn.jankratochvil.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130231847.GA20809@host0.dyn.jankratochvil.net>
Message-ID: <20090130234705.GA30170@zod.rchland.ibm.com>

On Sat, Jan 31, 2009 at 12:18:47AM +0100, Jan Kratochvil wrote:
>On Fri, 30 Jan 2009 21:35:05 +0100, Bill Nottingham wrote:
>> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary: 
>> > * Architecture Support
>> >   https://fedoraproject.org/wiki/Features/ArchitectureSupport
>[...]
>> - install x86_64 kernel on 32-bit OS where appropriate
>
>Could you please provide more public background for this FESCo decision?

It isn't a FESCo decision.  It is still being discussed.  See the meeting
minutes for the FESCo meeting where we delayed voting on this until next
week.

josh



From a.badger at gmail.com  Sat Jan 31 00:31:02 2009
From: a.badger at gmail.com (Toshio Kuratomi)
Date: Fri, 30 Jan 2009 16:31:02 -0800
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <200901310029.02287.ville.skytta@iki.fi>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<200901310029.02287.ville.skytta@iki.fi>
Message-ID: <49839BC6.2060006@gmail.com>

Ville Skytt? wrote:
> On Friday 30 January 2009, Bill Nottingham wrote:
>> Kevin Fenzi (kevin at scrye.com) said, in the FESCo meeting summary:
>>> * Architecture Support
>>>   https://fedoraproject.org/wiki/Features/ArchitectureSupport
> 
>> * 32-bit x86 would be built for i686 by default. 586-compatible processors
>> would no longer be supported.  
> [...]
>> * i386: -march=i586 -mtune=generic 
> 
> Should the latter be -march=i686?
> 
I was wondering this too but in the opposite direction -- why build
everything for i686 by default if we're only updating the compiler flags
to i586?

Jakub's email sparking this Feature listed the major benefit from
getting new instructions with -march=i486.  He then listed additional
helpful instructions when using -march=i586.  Nothing listed for
-march=i686.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/2f7b018f/attachment.sig>

From gmaxwell at gmail.com  Sat Jan 31 00:47:45 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Fri, 30 Jan 2009 19:47:45 -0500
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130231847.GA20809@host0.dyn.jankratochvil.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130231847.GA20809@host0.dyn.jankratochvil.net>
Message-ID: <e692861c0901301647j6ffcc34cp7ef933a9eb72f828@mail.gmail.com>

On Fri, Jan 30, 2009 at 6:18 PM, Jan Kratochvil
<jan.kratochvil at redhat.com> wrote:
[snip]
> Guessing some software (codecs?) may fallback on 64-bit to unoptimized C code
> instead of some assembly one but Fedora would at least show the usefulness of
> the updates of such software for the x86_64 arch.

Try GLIBC:  For example, x86_64 exp() (and expf()) is *much* slower
than x86.  (At least as of my testing in Fedora 9, I haven't measured
F10? the point being that these differences can lurk in unexpected
places.

They need to be fixed in anycase, but useful to keep in mind.



From mjg at redhat.com  Sat Jan 31 01:14:50 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Sat, 31 Jan 2009 01:14:50 +0000
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <498333E0.3040806@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
	<20090130150046.GA8869@nostromo.devel.redhat.com>
	<498333E0.3040806@redhat.com>
Message-ID: <20090131011450.GB24549@srcf.ucam.org>

On Fri, Jan 30, 2009 at 12:07:44PM -0500, Brian Maly wrote:

> All UEFI systems Ive worked with boot incredibly fast. And further the Intel
> Moblin V2 Core's feature Fastboot on top of being UEFI (read the specs on this
> hardware). Further, all LinuxBIOS systems Ive worked with boot just as fast.
> Its not smoke and mirrors. Systems are completely capable of booting this
> quickly. Believe what you want though.

The latest Vaio Z-series machines have an Insyde H2O UEFI firmware with 
BIOS compatibility. The boot time is not noticably faster. I /believe/ 
that the Aspire One is based on the same platform, so is technically an 
EFI machine - however, there doesn't appear to be any means of actually 
booting through it (rather than the compatibility layer) so the 
difference is pretty academic.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From mjg at redhat.com  Sat Jan 31 01:25:54 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Sat, 31 Jan 2009 01:25:54 +0000
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090130154250.GC28945@mokona.greysector.net>
References: <20090130053144.GA25512@srcf.ucam.org>
	<20090130154250.GC28945@mokona.greysector.net>
Message-ID: <20090131012554.GC24549@srcf.ucam.org>

On Fri, Jan 30, 2009 at 04:42:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:

> I'd like to see some more specific data from that test of yours (and
> your methodology).

Plug system[1] into Watts Up Pro. Allow values to stabalise at 97W. 
Disable cursor blinking. Note that values now stabalise at 95W. Flick 
between the two and observe that results are consistent.

[1] Quad core AMD, 8GB of RAM, Radeon X1900 graphics card running the 
F10 kernel with my patches to reclock the video harwdare. I'll be 
pushing these into rawhide once I've had a chance to rebase them.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From pertusus at free.fr  Sat Jan 31 01:51:19 2009
From: pertusus at free.fr (Patrice Dumas)
Date: Sat, 31 Jan 2009 02:51:19 +0100
Subject: TeXlive 2008 in Fedora 11?
In-Reply-To: <49835343.7030200@gmail.com>
References: <498217C5.2040809@redhat.com>
	<870180fe0901291314lf3f59d5n49efad4c86695dbd@mail.gmail.com>
	<498231AE.6050801@redhat.com>
	<e76492710901291554id4707cfx720a69a139a2efa6@mail.gmail.com>
	<645d17210901291559t79502e73q5f341db7bd173b11@mail.gmail.com>
	<1233298356.14086.3.camel@arekh.okg>
	<20090130110105.GA2908@free.fr>
	<40c0939f2fb8758bdd7d38ad8b5f88cc.squirrel@arekh.dyndns.org>
	<20090130141022.GB2566@free.fr> <49835343.7030200@gmail.com>
Message-ID: <20090131015118.GA2525@free.fr>

On Fri, Jan 30, 2009 at 11:21:39AM -0800, Toshio Kuratomi wrote:
> Patrice Dumas wrote:
> > On Fri, Jan 30, 2009 at 02:37:13PM +0100, Nicolas Mailhot wrote:
> >> Well, if you handwave packaging guidelines conformance away, 
> > 
> > It is not the point. Exceptions can be made when the cost is high and
> > the benefit is low.
> 
> I think making exceptions is a good thing.  Our Guidelines should be
> flexible enough to make exceptions when necessary.  But setting up the
> analysis of when to make exceptions as "cost is high and benefit is low"
> is doomed to failure.  There's a cost with any changes we make to how a

I am not saying that this should always be a good reason, I think that,
in this precise case, it is.

I am against violation of the guidelines, I am for a packaging quality
as high as possible. But sometimes compromises has to be done. Or somebody
has to step up to do the work.

--
Pat



From seg at haxxed.com  Sat Jan 31 01:58:31 2009
From: seg at haxxed.com (Callum Lerwick)
Date: Fri, 30 Jan 2009 19:58:31 -0600
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <e692861c0901301647j6ffcc34cp7ef933a9eb72f828@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130231847.GA20809@host0.dyn.jankratochvil.net>
	<e692861c0901301647j6ffcc34cp7ef933a9eb72f828@mail.gmail.com>
Message-ID: <1233367111.13932.23.camel@localhost.localdomain>

On Fri, 2009-01-30 at 19:47 -0500, Gregory Maxwell wrote:
> On Fri, Jan 30, 2009 at 6:18 PM, Jan Kratochvil
> <jan.kratochvil at redhat.com> wrote:
> [snip]
> > Guessing some software (codecs?) may fallback on 64-bit to unoptimized C code
> > instead of some assembly one but Fedora would at least show the usefulness of
> > the updates of such software for the x86_64 arch.
> 
> Try GLIBC:  For example, x86_64 exp() (and expf()) is *much* slower
> than x86.  (At least as of my testing in Fedora 9, I haven't measured
> F10? the point being that these differences can lurk in unexpected
> places.

Last I checked, gcc was unable to translate libm calls into nice inline
instructions on x86_64 like it can on i386, as it's apparently only
implemented for x87 and not SSE. x86-64 ends up with function calls
inside inner loops instead of an instruction or two. I've done a lot of
eyeballing of gcc's asm output...

> They need to be fixed in anycase, but useful to keep in mind.

Yes, if someone could get gcc's SSE FP optimization on par with x87, it
would probably speed up quite a few inner loops... :)
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/a019236d/attachment.sig>

From bmaly at redhat.com  Sat Jan 31 02:47:16 2009
From: bmaly at redhat.com (Brian Maly)
Date: Fri, 30 Jan 2009 21:47:16 -0500
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <20090131011450.GB24549@srcf.ucam.org>
References: <1233260366.4952.29.camel@choeger6>
	<49821FD3.4020801@redhat.com>	<1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>	<20090130035404.GC4570@nostromo.devel.redhat.com>	<1233288493.3698.67.camel@localhost.localdomain>	<49827FAF.3050306@redhat.com>	<20090130150046.GA8869@nostromo.devel.redhat.com>	<498333E0.3040806@redhat.com>
	<20090131011450.GB24549@srcf.ucam.org>
Message-ID: <4983BBB4.1000807@redhat.com>

Matthew Garrett wrote:
> On Fri, Jan 30, 2009 at 12:07:44PM -0500, Brian Maly wrote:
>
>   
>> All UEFI systems Ive worked with boot incredibly fast. And further the Intel
>> Moblin V2 Core's feature Fastboot on top of being UEFI (read the specs on this
>> hardware). Further, all LinuxBIOS systems Ive worked with boot just as fast.
>> Its not smoke and mirrors. Systems are completely capable of booting this
>> quickly. Believe what you want though.
>>     
>
> The latest Vaio Z-series machines have an Insyde H2O UEFI firmware with 
> BIOS compatibility. The boot time is not noticably faster. I /believe/ 
> that the Aspire One is based on the same platform, so is technically an 
> EFI machine - however, there doesn't appear to be any means of actually 
> booting through it (rather than the compatibility layer) so the 
> difference is pretty academic.
>
>   
Good info on the Vaio Z-series.  Out of curiosity, is there a UEFI 
shell/console accessible on the Acer One?  Or is this permanently in 
legacy BIOS compatibility mode? Dont know if you actually know or have 
access to the hardware...

Brian




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/9e16f620/attachment.htm>

From mike at flyn.org  Sat Jan 31 03:19:44 2009
From: mike at flyn.org (W. Michael Petullo)
Date: Fri, 30 Jan 2009 22:19:44 -0500
Subject: Orphan: mt-daapd
Message-ID: <20090131031944.GA3117@imp.local>

The mt-daapd package is now an orphan. I have decided to stop maintaining
the package because I am now using my own dmapd software. Dmapd supports
DPAP in addition to DAAP. I hope to create a dmapd package for Fedora
in the near term.

Mike



From skvidal at fedoraproject.org  Sat Jan 31 04:45:10 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Fri, 30 Jan 2009 23:45:10 -0500
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <20090130121722.7361f7a3@ohm.scrye.com>
References: <20090130121722.7361f7a3@ohm.scrye.com>
Message-ID: <1233377110.8810.4.camel@rosebud>

On Fri, 2009-01-30 at 12:17 -0700, Kevin Fenzi wrote:
> * Stronger Hashes -
>   https://fedoraproject.org/wiki/Features/StrongerHashes
> 
>   Many FESCo members were concerned with breaking preupgrade and yum
>   upgrades from f9->f11. The feature owner was directed to see if this
>   could be avoided and revisit the feature next week. 

F9 and F10 both have python 2.5 and yum 3.2.21. Pretty much all yum's
since 3.2.18 or 3.2.19 can cope with sha256sums already. and the
metadata format doesn't change.

The only changes made to yum to deal with sha256sums was the parts of
yum createrepo uses to make the metadata.

-sv




From darth_linux at ameritech.net  Sat Jan 31 04:54:01 2009
From: darth_linux at ameritech.net (Eric Hartwell)
Date: Fri, 30 Jan 2009 23:54:01 -0500
Subject: kde-4.2.0 coming soon, rawhide and F-9/F-10
In-Reply-To: <glcrsh$k8i$1@ger.gmane.org>
References: <glcrsh$k8i$1@ger.gmane.org>
Message-ID: <200901302354.02380.darth_linux@ameritech.net>

On Friday 23 January 2009 11:39:37 Rex Dieter wrote:
> The kde sig will be building kde-4.2.0 into rawhide asap, hopefully the
> process will be smooth, so as to introduce little to no breakage during or
> after.
>
> We'll also be starting work on updates for F-10 (first) and F-9.  While
> this is going on there will almost certainly be times of intermittent
> buildsys wierdness.  In particular, kde4-related builds should best wait
> until this work is completed.  None of this will affect updates-testing or
> updates, as the whole update will be pushed as one group.
>
> Question/comments, ask away, or find us on freenode/#fedora-kde
>
> -- Rex

thanks to you and your team for your efforts!

eah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/9311f2f0/attachment.htm>

From jkeating at redhat.com  Sat Jan 31 06:38:28 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Jan 2009 22:38:28 -0800
Subject: Status of the Alpha
Message-ID: <1233383908.3650.368.camel@localhost.localdomain>

I have bad news, and some good news.  Due to either over use of
kickstart, or a subtle difference in my home composes vs the composes
done in our Phoenix colo, the freeze done last week turns out to not be
a good package set.  There is a bug that manifests itself the first time
a checkbox is checked in the anaconda gui.  I never ran into this with
my testing, and so we thought things were good for a refresh.  We only
discovered the bug while testing composes after the refresh on Tuesday.

We were unable to determine the root cause of the above bug, however we
did discover that later rawhide trees (like say the tree from yesterday)
did not have this bug, a quick test compose was made and tested, and
found to be suitable.  We decided to refresh the tag again all the way
up to rawhide-20090129.

Unfortunately the testing of i386 and ppc didn't uncover a bug with
x86_64 early in anaconda, regarding executing some iscsiadm calls.
These only appear to happen on x86_64 in graphical mode.  Text mode is
fine.  I tried VNC, only to find out that vnc caused an early crash of
anaconda when booting over the network.  This particular vnc bug did not
exist in the earlier freeze tag or was otherwise undetected.

So now we're at a point with a critical bug that existed throughout our
freeze (gtk checkbox) thus no good point to fall back to, and while this
bug is fixed in later rawhide builds (fixed by an unknown component, so
no idea what we could cherry pick to the old freeze tag), newer rawhide
builds introduce new bugs above.

Then I tested today's rawhide, x86_64, gui, and found that it does not
have the iscsi bug.  I then proceeded to do a full iso compose from this
package set and have continued to do testing (of the actual isos and
bits) and continue to find them suitable.

So now I think we have a golden tree, although I can only test on my
limited hardware and KVM.  Such little testing has bitten us before, but
since this time I'm testing the actual bits I feel better about the
limited coverage, particularly because it's Alpha.

I'm going to stage the bits on the master mirror, and try to con some
other folks into testing the isos I've generated.  With luck we'll be
able to release it to mirrors tomorrow and have a chance at things being
ready for Tuesday.  Any further issues or an inability to get a second
opinion in time though will incur a slip of the Alpha release.

Thanks for your patience, and help.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/06367c37/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From jkeating at redhat.com  Sat Jan 31 07:18:04 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Fri, 30 Jan 2009 23:18:04 -0800
Subject: Status of the Alpha
In-Reply-To: <1233383908.3650.368.camel@localhost.localdomain>
References: <1233383908.3650.368.camel@localhost.localdomain>
Message-ID: <1233386284.3650.372.camel@localhost.localdomain>

On Fri, 2009-01-30 at 22:38 -0800, Jesse Keating wrote:
>  So now I think we have a golden tree, although I can only test on my
> limited hardware and KVM.  Such little testing has bitten us before, but
> since this time I'm testing the actual bits I feel better about the
> limited coverage, particularly because it's Alpha.
> 
> I'm going to stage the bits on the master mirror, and try to con some
> other folks into testing the isos I've generated.  With luck we'll be
> able to release it to mirrors tomorrow and have a chance at things being
> ready for Tuesday.  Any further issues or an inability to get a second
> opinion in time though will incur a slip of the Alpha release.

I had to jynx myself.  Shortly after sending this mail I ran across one
major issue.  Installation via NFS is not possible due to
https://bugzilla.redhat.com/show_bug.cgi?id=483375

Rolling back nfs-utils seems to work, however to generate that into a
repo I can compose form is going to take more time than I have energy
for tonight.

This likely means a slip, perhaps only a two day slip, of Alpha.  More
info to come either later this weekend or early next week.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090130/a6c144e7/attachment.sig>
-------------- next part --------------
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce

From rawhide at fedoraproject.org  Sat Jan 31 08:41:14 2009
From: rawhide at fedoraproject.org (Rawhide Report)
Date: Sat, 31 Jan 2009 08:41:14 +0000 (UTC)
Subject: rawhide report: 20090131 changes
Message-ID: <20090131084114.58D1E1B8009@releng2.fedora.phx.redhat.com>

Compose started at Sat Jan 31 06:01:03 UTC 2009

New package PyQwt
        Python bindings for Qwt
New package allgeyer-fonts
        Musical Notation True Type Fonts
New package banshee-mirage
        An Automatic Playlist Generation Extension for Banshee
New package beesu
        Bee's installer script for beesu
New package gsh
        Group Shell - aggregate several remote shells into one
New package log4c
        Library for logging application messages
New package mingw32-cairo
        MinGW Windows Cairo library
New package mingw32-libjpeg
        MinGW Windows Libjpeg library
New package mingw32-pixman
        MinGW Windows Pixman library
New package nullmodem
        A utility to loopback pseudo-terminals
New package perl-Test-Email
        Test Email Contents
New package sil-doulos-fonts
        Doulos SIL fonts
New package sil-gentium-fonts
        SIL Gentium fonts
New package timespan
        A tool that performs date-based time calculations
New package torch
        Torch is a simple machine-learning library
Removed package bitgtkmm
Removed package doulos-fonts
Removed package gentium-fonts
Updated Packages:

ImageMagick-6.4.5.5-8.fc11
--------------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 6.4.5.5-8
- Remove (TM) from description as per new guidelines


WebKit-1.1.0-0.17.svn40351.fc11
-------------------------------
* Fri Jan 30 17:00:00 2009 Peter Gordon <peter at thecodergeek.com> 1.1.0-0.18.svn40351
- Fix ownership of doc directory...this time without the oops (#473619).
- Bump package version number to match that used in the configure/build
  scripts. (Thanks to Martin Sourada for the bug report via email.)


a2ps-4.14-7.fc11
----------------
* Fri Jan 30 17:00:00 2009 Tim Waugh <twaugh at redhat.com> 4.14-7
- Removed trade marks to avoid potential confusion.


agistudio-1.2.3-8.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Jon Ciesla <limb at jcomserv.net> - 1.2.3-8
- Description fix.


aide-0.13.1-6.fc11
------------------
* Fri Jan 30 17:00:00 2009 Steve Grubb <sgrubb at redhat.com> - 0.13.1-6
- enable xattr support and update config file


alienarena-7.21-1.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 7.21-1
- update to 7.21
- apply Paul's patch to print the search paths


alienarena-data-20090115-1.fc11
-------------------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 20090115-1
- update to 20090115 (7.21)


ants-1.4-5.fc11
---------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.4-5
- Update description for new trademark guidelines


apanov-heuristica-fonts-20090125-1.fc11
---------------------------------------
* Fri Jan 30 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 20090125-1


asymptote-1.60-1.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 1.60-1
- 1.60


clanbomber-1.05-10.fc11
-----------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.05-9
- Update description for new trademark guidelines

* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.05-10
- Improve description


ctan-kerkis-fonts-2.0-19.fc11
-----------------------------
* Sat Jan 31 17:00:00 2009 Sarantis Paskalis <paskalis at di.uoa.gr> - 2.0-19
- Add forgotten %{_fontdir} in %files section in -common (bz #483333)


dia-0.96.1-12.fc11
------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1:0.96.1-12
- Update description for new trademark guidelines


dosfstools-3.0.1-3.fc11
-----------------------
* Fri Jan 30 17:00:00 2009 Stepan Kasal <skasal at redhat.com> - 3.0.1-2
- install all the documentation to the usual docdir (#225707)

* Fri Jan 30 17:00:00 2009 Stepan Kasal <skasal at redhat.com> - 3.0.1-3
- fix the previous commit
- omit the most obsolete documents
- after writing the label, exit with exit code 0 (#468050)


eclipse-pydev-1.4.2-2.fc11
--------------------------
* Sat Jan 31 17:00:00 2009 Michal Nowak <mnowak at redhat.com> 1:1.4.2-2
- %defattr(-,root,root,-) for mylyn sub-package
- Disable building -debuginfo due to psyco problems; resolves: rhbz#483357


evolution-sharp-0.19.1-2.fc11
-----------------------------
* Fri Jan 30 17:00:00 2009 Matthew Barnes <mbarnes at redhat.com> - 0.19.1-2.fc11
- Fix unowned directory (RH bug #483345).


farsight2-0.0.7-2.fc11
----------------------
* Mon Jan 19 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.0.7-2
- Add BR on gupnp-igd-devel, pygobject2-devel, and pygtk2-devel.


freecol-0.8.0-2.fc11
--------------------

gawk-3.1.6-4.fc11
-----------------
* Fri Jan 30 17:00:00 2009 Stepan Kasal <skasal at redhat.com> - 3.1.6-4
- remove the versioned binaries even if the version is modified by the
  snapshot patch, modify the file list to check this (#476166)
- update the snapshot patch, dropping the upstreamed
  gawk-3.1.5-test-lc_num1.patch


generic-release-10.90-2
-----------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 10.90-2
- drop Requires: system-release-notes


gnome-do-0.8.0-1.fc11
---------------------
* Thu Jan 29 17:00:00 2009 Michel Salim <salimma at fedoraproject.org> - 0.6.1.0-3
- Remove Tomboy dependency (bz #481183)
- Updated description, from Do

* Fri Jan 30 17:00:00 2009 Sindre Pedersen Bj??rdal <sindrepb at fedoraproject.org> - 0.8.0-1
- New upstream release


gstreamer-python-0.10.14-1.fc11
-------------------------------
* Fri Jan 30 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 0.10.14-1
- Update to upstream 0.10.14, with various bug fixes
- Removed problematic devel Provide


gtksourceview2-2.5.3-2.fc11
---------------------------
* Fri Jan 30 17:00:00 2009 Matthias Clasen <mclasen at redhat.com> - 2.5.3-2
- Recognize %else in spec files (#480587)


hunspell-af-0.20080825-1.fc11
-----------------------------
* Fri Jan 30 17:00:00 2009 Caolan McNamara <caolanm at redhat.com> - 0.20080825-1
- latest version


kde-l10n-4.2.0-2.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Than Ngo <than at redhat.com> - 4.2.0-2
- enable he


kdelibs-4.2.0-7.fc11
--------------------

kernel-2.6.29-0.73.rc3.git2.fc11
--------------------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com>
- Completely drop gspca patches (all upstream now)
- Rebase atk0110 driver to latest from upstream
- Fix some broken error paths in superio hwmon drivers triggered by the
  new acpi_enforce_resources strict default (#483208)

* Fri Jan 30 17:00:00 2009 Josef Bacik <josef at toxicpanda.com>
- add patch to keep btrfs from locking up when creating a new inode
- add patch to let readdir not screw up on 32bit boxes

* Fri Jan 30 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc3-git1

* Fri Jan 30 17:00:00 2009 Dave Jones <davej at redhat.com>
- 2.6.29-rc3-git2


koffice-1.9.98.6-1.fc11
-----------------------
* Wed Jan 28 17:00:00 2009 Rex Dieter <rdieter at fedoraproject.org> - 1:1.9.98.6-1
- koffice-1.9.98.6, koffice2 beta 6


kscope-1.9.1-1.fc11
-------------------
* Tue Jan 20 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 1.9.1-1
- Update to 1.9.1


lacewing-1.10-11.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.10-11
- Update description for new trademark guidelines


lesstif-0.95.0-27.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.95.0-27
- Update description for new trademark guidelines


libdrm-2.4.4-1.fc11
-------------------
* Fri Jan 30 17:00:00 2009 Dave Airlie <airlied at redhat.com> 2.4.4-1
- rebase to 2.4.4


libgcrypt-1.4.4-1.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> 1.4.4-1
- update to 1.4.4
- do not abort when the fips mode kernel flag is inaccessible
  due to permissions (#470219)
- hobble the library to drop the ECC support


libgnomedb-3.99.7-2.fc11
------------------------
* Fri Jan 30 17:00:00 2009 Denis Leroy <denis at poolshark.org> - 1:3.99.7-2
- Fix pre scriptlet to check for upgrade from 3.0 case (#481438)


libgsf-1.14.11-2.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Caol??n McNamara <caolanm at redhat.com> 1.14.11-2
- fix g_enum_register_static use


libsamplerate-0.1.6-1.fc11
--------------------------
* Tue Jan 27 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.1.6-1
- New upstream release 0.1.6


libsidplay-1.36.57-18
---------------------
* Fri Jan 30 17:00:00 2009 Michael Schwendt <mschwendt at fedoraproject.org> 1.36.57-18
- only a few spec file adjustments (including new summaries and
  descriptions)


liferea-1.4.23-3.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Steven M. Parrish <tuxbrewr at fedoraproject.org> 1.4.23-2
- Patch to fix WebKit issue in F11

* Fri Jan 30 17:00:00 2009 Steven M. Parrish <tuxbrewr at fedoraproject.org> 1.4.23-3
- Fix missing -p1 on patch


lincity-ng-2.0-1.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> 2.0-1
- 2.0 final


lsof-4.81-2.fc11
----------------
* Fri Jan 30 17:00:00 2009 Karel Zak <kzak at redhat.com> 4.81-2
- fix #480694 - lsof manpage mismarked and formats badly


methane-1.4.7-5.fc11
--------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.4.7-5
- Update description for new trademark guidelines


midisport-firmware-1.2-4.fc11
-----------------------------
* Thu Jan 29 17:00:00 2009 Dave Jones <davej at redhat.com> [1.2-4.fc11]
- Fix up path for firmware files in udev rules. (#478911)
  (diff from Patrik Elmberg)


mingw32-filesystem-45-1.fc11
----------------------------
* Wed Jan 28 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 45-1
- Use PKG_CONFIG_LIBDIR instead of PKG_CONFIG_PATH so that native pkgconfig
  is never searched.


mingw32-glib2-2.19.5-3.fc11
---------------------------
* Fri Jan 30 17:00:00 2009 Richard W.M. Jones <rjones at redhat.com> - 2.19.5-3
- Requires pkgconfig.


monkey-bubble-0.4.0-11.fc11
---------------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.4.0-11
- Update description for new trademark guidelines


ntfs-3g-2009.1.1-1.fc11
-----------------------
* Fri Jan 30 17:00:00 2009 Tom "spot" Callaway <tcallawa at redhat.com> - 2:2009.1.1-1
- new release, new versioning scheme from upstream


openssh-5.1p1-6.fc11
--------------------
* Fri Jan 30 17:00:00 2009 Tomas Mraz <tmraz at redhat.com> - 5.1p1-6
- enable use of ssl engines (#481100)


overgod-1.0-8.fc11
------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.0-8
- Update description for new trademark guidelines


pachi-1.0-7.fc11
----------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 1.0-7
- Update description for new trademark guidelines


plplot-5.9.2-1.fc11
-------------------
* Mon Jan 26 17:00:00 2009 - Orion Poplawski <orion at cora.nwra.com> - 5.9.2-1
- Update to 5.9.2
- Need rpaths during build
- Explicitly enable tk, itcl, itk, and pygcw
- Update info and multiarch patches
- Re-enable perl tests
- Add proper ocaml provides/requires
- Add patch to handle newer octave


policycoreutils-2.0.61-7.fc11
-----------------------------
* Fri Jan 30 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 2.0.61-7
- Dont report errors on glob match and multiple links


raidem-0.3.1-9.fc11
-------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.3.1-9
- Update description for new trademark guidelines


rpm-4.6.0-0.rc4.1.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Panu Matilainen <pmatilai at redhat.com> - 4.6.0-0.rc4.1
- update to 4.6.0-rc4
- fixes #475582, #478907, #476737, #479869, #476201


selinux-policy-3.6.3-12.fc11
----------------------------
* Fri Jan 30 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-11
- Add virt_content_ro_t and labeling for isos directory

* Fri Jan 30 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> 3.6.3-12
- Add back transition from xguest to mozilla


setup-2.7.7-3.fc11
------------------
* Fri Jan 30 17:00:00 2009 Ondrej Vasik <ovasik at redhat.com> 2.7.7-3
- add support for ctrl+arrow keys in rxvt(#474110)


subversion-1.5.5-5
------------------
* Fri Jan 30 17:00:00 2009 Joe Orton <jorton at redhat.com> 1.5.5-5
- update to 1.5.5


sugar-0.83.5-3.20090130gitf7807dddc0.fc11
-----------------------------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 0.83.5-3.20090130gitf7807dddc0
- Add 'View Details' option to object palette in journal
- Translation updates
- Hide OLPC-specific fields on non-xo machines #133
- Add a 'Clear search' button to 'No matching entries' message #266
- Correctly detect when a query in the journal is empty #255
- Avoid launching two instances of the same activity instance #238
- Add start-with option to objectpalette in the journal
- Fix dnd of icons in the favorite view #213
- Right click on AP should reveal palette not connect to AP #10
- Display space used and left in the volume palette in the journal #33
- Don't update the zoom level when a dialog window pops up
- Fix filtering the objectchooser with data types #219


sugar-browse-103-5.fc11
-----------------------
* Tue Jan 20 17:00:00 2009 Marco Pesenti Gritti <mpg at redhat.com> - 103-2
- use cjson instead of json (nirbheek)
- new translations

* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 103-3
- rebuild

* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 103-4
- cope for removed NEWS file from sources

* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 103-5
- new download url


sugar-calculator-28-1.fc11
--------------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 28-1
- Support 'real' scientific notation (#4250)
- Add switching between exponential/scientific notation
- Allow changing of number of displayed digits
- Change cursor on equations to Hand (#6612)
- Fix fall-through of unhandled CTRL keys (eg CTRL+Q)
- Add recursion detection
- Fixed error-handling bug
- New download url


sugar-chat-62-1.fc11
--------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 62-1
- Use cjson instead of simple-json (nirbheek)
- Updated translations: he, en_US, sv
- New download url


sugar-datastore-0.83.2-2.20090130gite999c1c1e1.fc11
---------------------------------------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 0.83.2-2.20090130gite999c1c1e1
- Only try to remove the checksum dir if it already exists


sugar-terminal-21-1.fc11
------------------------
* Fri Jan 30 17:00:00 2009 Steven M. Parrish <tuxbrewr at fedoraproject.org>
- New release


sugar-toolkit-0.83.4-2.20090130git073336585d.fc11
-------------------------------------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 0.83.4-2.20090130git073336585d
- Translation updates
- Naming alert prevents activity close on keep error #224


sugar-write-61-1.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Simon Schampijer <simon at schampijer.de> - 61-1
- Make use of the ColorToolButton that benzea landed in sugar-toolkit
- Filter object chooser so it shows only images #3060
- Save to OpenDocument if we cannot export in the original format #8972
- new download url


supertux-0.3.1-5.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 0.3.1-5
- Update description for new trademark guidelines


telepathy-glib-0.7.25-1.fc11
----------------------------
* Fri Jan 30 17:00:00 2009 Brian Pepple <bpepple at fedoraproject.org> - 0.7.25-1
- Update to 0.7.25.


udev-137-2.fc11
---------------
* Fri Jan 30 17:00:00 2009 Harald Hoyer <harald at redhat.com> 137-2
- moved groupadd to pre section (bug #483089)


wpa_supplicant-0.6.7-1.fc11
---------------------------
* Fri Jan 30 17:00:00 2009 Dan Williams <dcbw at redhat.com> - 1:0.6.7-1
- Fix PEAP connections to Windows Server 2008 authenticators (rh #465022)
- Stop supplicant on uninstall (rh #447843)
- Suppress scan results message in logs (rh #466601)


wsdl4j-1.5.2-5.5.fc11
---------------------
* Fri Jan 30 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 0:1.5.2-5.5
- Add osgi manifest for eclipse-dtp.


xerces-j2-2.7.1-10.3.fc11
-------------------------
* Fri Jan 30 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 0:2.7.1-10.3
- Add osgi manifest.


xgalaxy-2.0.34-10.fc11
----------------------
* Fri Jan 30 17:00:00 2009 Hans de Goede <hdegoede at redhat.com> 2.0.34-10
- Update description for new trademark guidelines


xgridfit-1.17-1.fc11
--------------------
* Fri Jan 30 17:00:00 2009 <nicolas.mailhot at laposte.net>
- 1.17-1


xguest-1.0.7-2.fc11
-------------------
* Fri Jan 30 17:00:00 2009 Dan Walsh <dwalsh at redhat.com> - 1.0.7-1
- Change xguest init script to have proper summary


xml-commons-apis-1.3.04-1.4.fc11
--------------------------------
* Fri Jan 30 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 0:1.3.04-1.4
- Add osgi metadata.


xml-commons-resolver-1.1-2.15.fc11
----------------------------------
* Fri Jan 30 17:00:00 2009 Alexander Kurtakov <akurtako at redhat.com> 0:1.1-2.15
- Install osgi manifest for eclipse-dtp


Summary:
Added Packages: 15
Removed Packages: 3
Modified Packages: 75
Broken deps for i386
----------------------------------------------------------
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-perl-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.i386 requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.i386 requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libopensync-plugin-syncml-0.35-4.fc10.i386 requires libsyncml.so.0
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.i386 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.i386 requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.i386 requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.i386 requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.i386 requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so



Broken deps for x86_64
----------------------------------------------------------
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.i386 requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.i386 requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.x86_64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.x86_64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.i386 requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.x86_64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.x86_64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.x86_64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.x86_64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.x86_64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.x86_64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	db4o-6.1-4.fc9.ppc requires mono(Mono.Cecil) = 0:0.6.8.8607
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-1.6.0-1.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	gdal-ruby-1.6.0-1.fc11.ppc requires libmysqlclient.so.15
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc requires libgnomedb-3.0.so.4
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	grass-6.3.0-9.fc11.ppc requires libmysqlclient.so.15
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgdamm-3.0.so.10
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_graph-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc requires libgnomedb_extra-3.0.so.4
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc requires libsyncml.so.0
	linkage-0.2.0-4.fc11.ppc requires libtorrent-rasterbar.so.0
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-5.2.1-4.fc11.ppc requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-perl-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	mapserver-python-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15
	mediatomb-0.11.0-4.fc11.ppc requires libmysqlclient_r.so.15(libmysqlclient_15)
	1:pan-0.133-1.fc10.ppc requires libgmime-2.0.so.2
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15(libmysqlclient_15)
	php-mapserver-5.2.1-4.fc11.ppc requires libmysqlclient.so.15
	python-gammu-0.28-1.fc11.ppc requires libGammu.so.5
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so
	ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so



Broken deps for ppc64
----------------------------------------------------------
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-good = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires elisa-plugins-bad = 0:0.5.20
	elisa-0.5.20-1.fc11.noarch requires mgopen-fonts
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	gdal-perl-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	gdal-ruby-1.6.0-1.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	1:gnumeric-plugins-extras-1.8.2-5.fc11.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	grass-6.3.0-9.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_graph-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb-3.0.so.4()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgdamm-3.0.so.10()(64bit)
	libgnomedbmm-2.9.5-4.fc9.ppc64 requires libgnomedb_extra-3.0.so.4()(64bit)
	libopensync-plugin-syncml-0.35-4.fc10.ppc64 requires libsyncml.so.0()(64bit)
	linkage-0.2.0-4.fc11.ppc64 requires libtorrent-rasterbar.so.0()(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-5.2.1-4.fc11.ppc64 requires bitstream-vera-fonts-sans
	mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-perl-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	mapserver-python-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15()(64bit)
	mediatomb-0.11.0-4.fc11.ppc64 requires libmysqlclient_r.so.15(libmysqlclient_15)(64bit)
	1:pan-0.133-1.fc10.ppc64 requires libgmime-2.0.so.2()(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15(libmysqlclient_15)(64bit)
	php-mapserver-5.2.1-4.fc11.ppc64 requires libmysqlclient.so.15()(64bit)
	python-gammu-0.28-1.fc11.ppc64 requires libGammu.so.5()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit)
	ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit)





From drago01 at gmail.com  Sat Jan 31 09:16:52 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 10:16:52 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <glvtpo$mq7$1@ger.gmane.org>
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<glsri0$3pd$2@ger.gmane.org>
	<f6ca9fed0901301122t43f3c8ebpb9b2cb015248c648@mail.gmail.com>
	<glvtpo$mq7$1@ger.gmane.org>
Message-ID: <f6ca9fed0901310116y2c49e737ne6000acb45cc690b@mail.gmail.com>

On Fri, Jan 30, 2009 at 11:08 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> P.S: reading this from you was unexpected but nice to see, considering
>> that you answered my question why most of the core KDE packages have
>> closed ACLs (is this still the case?)  you said "because the KDE SIG
>> is already doing a good job" (which is no reason why other people
>> should not be allowed to do a good job too ;) )
>
> Most of KDE has now been opened up to provenpackager, only the core packages
> (kdelibs and kdebase*) are still closed. And that's probably also not
> needed, I won't complain if they get opened up (as long as people don't
> start committing nonsense like "follow GNOME HIG", "put the GenericName
> into Name" or the like ;-) ).
>
> Still, I must also say that I don't see why we're expected to open up while
> at the same time the usual suspects (kernel, glibc etc. and also the
> Firefox stack (*)) are allowed to stay locked down. :-/ How's that fair?
> The same rules should apply to *all* packages, no exceptions.

Yeah as I already said I am for opening all packages.

>        Kevin Kofler
>
> (*) which is really worth a rant of its own - why do we accept those asinine
> patch approval policies which keep us from doing cooperative development
> and sometimes even from fixing real issues (I remember the
> hunspell/xulrunner ABI fiasco) instead of just renaming the f***ing thing
> like Debian does?

The name "Firefox" is worth having for marketing reasons.



From joshuacov at googlemail.com  Sat Jan 31 09:36:19 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 31 Jan 2009 10:36:19 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <498384C4.4020909@redhat.com>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
	<49831E39.8060100@redhat.com> <49832558.1050300@freenet.de>
	<49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
Message-ID: <5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>

2009/1/30 Tom spot Callaway <tcallawa at redhat.com>:
>
> They advised that the same advice applies to Documentation.
>
> Never use "tm" or "(R)". If we are obliged by contract to mention other
> trademarks in a legend, add the legend as required by the contract.
>
> In addition, our documentation should contain the disclaimer:  "All
> other trademarks are the property of their respective owners."
>
> ~spot


Just a question here:

Since some of the contributors to fedora live/are located outside of
the usa, should they be "restricted" by the us trade mark law? The
code cannot be patented as a sequnce of mathematical formulas making a
given hardware to work in a definite way.

Maybe not complying to these rules could lead to packages being not
redestributed with fedora but they are still fedora-"legal" packages.
So putting them in rpm-fussion or other repos can circumvent this
don't-put-the-TM/R-symbol-in-your-description-policy.

Since these packages are bound to those trademarked names/patented
devices there should be a way to say thier proper name (fair use).
Software written to work with logithek should be described as such,
because the vendor decided to call thier product logithek. I don't see
another way to say this without the trademarked name.

And of course: All other trademarks are property of their respective owners.



From denis at poolshark.org  Sat Jan 31 10:11:00 2009
From: denis at poolshark.org (Denis Leroy)
Date: Sat, 31 Jan 2009 11:11:00 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <gm012o$1hh$1@ger.gmane.org>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<gm012o$1hh$1@ger.gmane.org>
Message-ID: <498423B4.60506@poolshark.org>

Kevin Kofler wrote:
> Fedora is not a content distribution. It's a software distribution. We only
> ship content which is directly related to software we ship:
> https://fedoraproject.org/wiki/Packaging/Guidelines#Code_Vs_Content
> 
> Fedora is not a content library, we cannot ship all the content in
> existence, there's just too much of it.
> 
> OVM cannot be used with any software in Fedora, so it also does not belong
> into Fedora. What's the point of shipping content which cannot be used?
> 
> The same rationale is also being applied to MP3 files, which are also not
> permitted in Fedora.

but not for the same reason, so the comparison is inadequate.

How about: we don't ship packages of CC-licensed free music in OGG 
format (even though that content CAN be used in Fedora) because Fedora 
is not a music library ?

-denis



From rjones at redhat.com  Sat Jan 31 11:11:30 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 31 Jan 2009 11:11:30 +0000
Subject: Too many unowned directories
In-Reply-To: <20090130200118.dcf06aa3.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
Message-ID: <20090131111130.GA23533@amd.home.annexia.org>

On Fri, Jan 30, 2009 at 08:01:18PM +0100, Michael Schwendt wrote:
> Despite being in the guidelines as above, more and more unowned
> directories are found in Fedora/Rawhide.

I appreciate the work you are doing, but let's look at the bigger
picture here.

Why can't RPM deal with it?

It should be able to track which package(s) needed to create a
particular directory, and remove it once those packages are gone.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From rjones at redhat.com  Sat Jan 31 11:15:42 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 31 Jan 2009 11:15:42 +0000
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
Message-ID: <20090131111542.GB23533@amd.home.annexia.org>


tl;dr

Can you summarise that in a few sentences?  I gave up after several
paragraphs of verbiage.

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 drago01 at gmail.com  Sat Jan 31 11:31:46 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 12:31:46 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
References: <49821EF9.4040108@redhat.com> <49830A2F.7010601@freenet.de>
	<49831E39.8060100@redhat.com> <49832558.1050300@freenet.de>
	<49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
Message-ID: <f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>

On Sat, Jan 31, 2009 at 10:36 AM, Joshua C. <joshuacov at googlemail.com> wrote:
> 2009/1/30 Tom spot Callaway <tcallawa at redhat.com>:
>>
>> They advised that the same advice applies to Documentation.
>>
>> Never use "tm" or "(R)". If we are obliged by contract to mention other
>> trademarks in a legend, add the legend as required by the contract.
>>
>> In addition, our documentation should contain the disclaimer:  "All
>> other trademarks are the property of their respective owners."
>>
>> ~spot
>
>
> Just a question here:
>
> Since some of the contributors to fedora live/are located outside of
> the usa, should they be "restricted" by the us trade mark law? The
> code cannot be patented as a sequnce of mathematical formulas making a
> given hardware to work in a definite way.
>
> Maybe not complying to these rules could lead to packages being not
> redestributed with fedora but they are still fedora-"legal" packages.
> So putting them in rpm-fussion or other repos can circumvent this
> don't-put-the-TM/R-symbol-in-your-description-policy.
>
> Since these packages are bound to those trademarked names/patented
> devices there should be a way to say thier proper name (fair use).
> Software written to work with logithek should be described as such,
> because the vendor decided to call thier product logithek. I don't see
> another way to say this without the trademarked name.

Nobody said that logitech should not be used in the name.
You should not say that your software _Is_ logitech and don't use (R) or (TM).



From mschwendt at gmail.com  Sat Jan 31 12:43:47 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 31 Jan 2009 13:43:47 +0100
Subject: Too many unowned directories
In-Reply-To: <20090131111130.GA23533@amd.home.annexia.org>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
Message-ID: <20090131134347.7bb42020.mschwendt@gmail.com>

On Sat, 31 Jan 2009 11:11:30 +0000, Richard wrote:

> Why can't RPM deal with it?

Because it doesn't do it yet? ;)
Perhaps it's not even easy to implement in RPM's current code base?

Sometimes there are lots of reasons why something isn't done. For example,
RPM fails at replacing a symlink with a directory during updates. This has
been discussed several times before [with RPM devs saying that a real
solution would be difficult/complex]. It still hits users around the world
occasionally when package maintainers carelessly hack on their %files
lists.

> It should be able to track which package(s) needed to create a
> particular directory, and remove it once those packages are gone.

Yes, refcounting directories or creating missing %files %dir entries
on-the-fly sounds like a solution. It seems to be at the bottom of
the TODO list, however.

Interestingly, scanning for unowned directories also reveals misplaced
files.



From drago01 at gmail.com  Sat Jan 31 12:45:30 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 13:45:30 +0100
Subject: Too many unowned directories
In-Reply-To: <alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
Message-ID: <f6ca9fed0901310445y7eb83a4kb854b7536e0e570d@mail.gmail.com>

On Fri, Jan 30, 2009 at 9:51 PM, Panu Matilainen
<pmatilai at laiskiainen.org> wrote:

> Rpm could stop the install on unowned directories like it does for file
> conflicts. Not maybe the nicest user experience but non-working package is
> not any better.

Which it should do, this way such issues are easier to spot (just
install the package).



From sundaram at fedoraproject.org  Sat Jan 31 13:16:43 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sat, 31 Jan 2009 18:46:43 +0530
Subject: Moblin 2 and Fedora
In-Reply-To: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
Message-ID: <49844F3B.6060905@fedoraproject.org>

Peter Robinson wrote:
> Hi All,
> 
> I noticed Intel has announced [1] the first alpha of Moblin 2 which
> from memory and by the look of it is based on Fedora [2].

Yes but Intel doesn't seem interested in pushing any changes back to 
Fedora.

> I'm wondering what the outcome of the discussions with them was about
> basing it on upstream Fedora and if anyone knows what the differences
> are between the source repos [2] and that of base Fedora are?

No idea but have you tried asking in the Moblin mailing lists? They 
should know better.

Rahul






From dominik at greysector.net  Sat Jan 31 13:17:14 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 31 Jan 2009 14:17:14 +0100
Subject: RFC: Disabling blinking cursor by default
In-Reply-To: <20090131012554.GC24549@srcf.ucam.org>
References: <20090130053144.GA25512@srcf.ucam.org>
	<20090130154250.GC28945@mokona.greysector.net>
	<20090131012554.GC24549@srcf.ucam.org>
Message-ID: <20090131131714.GA9350@mokona.greysector.net>

On Saturday, 31 January 2009 at 02:25, Matthew Garrett wrote:
> On Fri, Jan 30, 2009 at 04:42:51PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> 
> > I'd like to see some more specific data from that test of yours (and
> > your methodology).
> 
> Plug system[1] into Watts Up Pro. Allow values to stabalise at 97W. 
> Disable cursor blinking. Note that values now stabalise at 95W. Flick 
> between the two and observe that results are consistent.
> 
> [1] Quad core AMD, 8GB of RAM, Radeon X1900 graphics card running the 
> F10 kernel with my patches to reclock the video harwdare. I'll be 
> pushing these into rawhide once I've had a chance to rebase them.

Which Xorg video driver? radeon? radeonhd?

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From dominik at greysector.net  Sat Jan 31 13:44:06 2009
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sat, 31 Jan 2009 14:44:06 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090130202818.GB4712@hurricane.linuxnetz.de>
References: <1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
	<20090129205127.GA23519@hurricane.linuxnetz.de>
	<20090129210410.GF20174@mokona.greysector.net>
	<20090130202818.GB4712@hurricane.linuxnetz.de>
Message-ID: <20090131134406.GB9350@mokona.greysector.net>

On Friday, 30 January 2009 at 21:28, Robert Scheck wrote:
> On Thu, 29 Jan 2009, Dominik 'Rathann' Mierzejewski wrote:
> > On Thursday, 29 January 2009 at 21:51, Robert Scheck wrote:
> > > With which benefit, if we remove the right to package mantainers to forbid
> > > provenpackager commits except for some special canditates needing FESco? If
> > > everybody can touch anything, why a co-maintainer?
> > 
> > Well, even with provenpackagers, it's not like they will start committing
> > left and right into other people's packages. A co-maintainer is expected
> > to be the first person to step in when the other maintainer is unable to
> > do his job.
> 
> I was thinking here about to skip the maintainer/co-maintainer stuff at
> all. Just one big bucket having everything in without different permissings
> or roles.

IMHO skipping out on (co-)maintainers is a bad idea. They are (supposedly) the
people who know their packages best. While fixing small stuff (arguably:
rebuilds, FPG conformance fixes, maybe others) could be done by your average
drive-by provenpackager, more intrusive changes like patching or version
upgrades must be done by people familiar with the software in question, i.e.
(co-)maintainers or at least members of a SIG that covers this particular
area.

> > I'd also make it mandatory for provenpackagers to be members of at least
> > one SIG like KDE, Server, Games etc., i.e. ones that deal with certain
> > group of software packages so that their area of expertise is at least
> > somewhat defined.
> 
> Interesting idea. But to which SIG would you assign me when looking to my
> wiki page, my interests and which packages I'm maintaining? Or do I need to
> found my own SIG for that then? I don't need to be a provenpackager, but I
> am also playing theoretical scenarios.

I'd say Server SIG. Very nice page, by the way.

Regards,
R.

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"



From dtimms at iinet.net.au  Sat Jan 31 14:14:42 2009
From: dtimms at iinet.net.au (David Timms)
Date: Sun, 01 Feb 2009 01:14:42 +1100
Subject: Too many unowned directories
In-Reply-To: <1233350796.3650.29.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>	<20090130211536.b7aa63d9.mschwendt@gmail.com>	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>	<1233350530.3650.28.camel@localhost.localdomain>	<1233350803.3345.18.camel@localhost.localdomain>
	<1233350796.3650.29.camel@localhost.localdomain>
Message-ID: <49845CD2.6080902@iinet.net.au>

Jesse Keating wrote:
> On Fri, 2009-01-30 at 21:26 +0000, Miloslav Trma?? wrote:
>> Jesse Keating p????e v P?? 30. 01. 2009 v 13:22 -0800:
>>> Why not fail the build if unowned directories are found, just like we do
>>> for unowned files?  That way you catch it at build time before you try
>>> and do something useful with the build.
>> How do we determine which directory is unowned and which is provided by
>> a dependency?  If we don't, every package would have to own /usr.
>> 	Mirek
> 
> Good point, since we don't install the Requires at the same time we're
> installing the BuildRequires to do the build that would be harder.
But not for a computer ;)

Would there not be a post-build or pre-publish prcess that could be used 
to determine whether things like this are correct, and return a 'build 
is not publishable' error to the maintainer. Sort of like mock but for 
the install ?

I'm guessing that is how Michaels tests work; could they become part of 
the infrastructure ?

BTW, is it generally config dirs where the unowned dirs are found ?

DaveT.



From tcallawa at redhat.com  Sat Jan 31 14:22:00 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 31 Jan 2009 09:22:00 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
References: <49821EF9.4040108@redhat.com>
	<49830A2F.7010601@freenet.de>	<49831E39.8060100@redhat.com>
	<49832558.1050300@freenet.de>	<49832DE5.6070107@redhat.com>	<20090130194636.GJ28663@localhost.localdomain>	<49835A79.1040801@redhat.com>	<20090130195751.GL28663@localhost.localdomain>	<498384C4.4020909@redhat.com>	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
Message-ID: <49845E88.9000406@redhat.com>

On 2009-01-31 at 6:31:46 -0500, drago01 <drago01 at gmail.com> wrote:
> > Since these packages are bound to those trademarked names/patented
> > > devices there should be a way to say thier proper name (fair use).
> > > Software written to work with logithek should be described as such,
> > > because the vendor decided to call thier product logithek. I don't see
> > > another way to say this without the trademarked name.
> 
> Nobody said that logitech should not be used in the name.
> You should not say that your software _Is_ logitech and don't use (R) or (TM).

Drago01 is correct. You can continue to use trademarks, within the
bounds of fair use. You just shouldn't be marking them with "(R)" or
"(TM)" (or TM, or the unicode equivalents, etc, etc).

As to the greater question of "restricting" Fedora contributors outside
the US, unfortunately, that's how it has to work. Fedora is Red Hat's
legal responsibility, and Red Hat is a US based company. This is why we
have repositories like RPMFusion.

Hopefully, software patents and broken US laws like the DMCA will be
overturned in my lifetime, and we will be able to minimize the need for
such flaming hoops.

~spot



From j.w.r.degoede at hhs.nl  Sat Jan 31 14:26:23 2009
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Sat, 31 Jan 2009 15:26:23 +0100
Subject: support for latest (radeon) hardware
In-Reply-To: <1233145080.22993.1.camel@localhost>
References: <2663.71.208.61.177.1232685101.squirrel@www.cora.nwra.com>	<tm4p46xld8.ln2@ppp1053.in.ipex.cz>	<497B0779.7020708@leemhuis.info>	<20090124151420.GA21427@wolff.to>
	<497B5110.8000800@leemhuis.info>	<1232819460.8363.106.camel@localhost.localdomain>	<glg41r$dp7$1@ger.gmane.org>	<1233084071.19014.36.camel@localhost.localdomain>	<4980115D.7070808@hhs.nl>
	<1233145080.22993.1.camel@localhost>
Message-ID: <49845F8F.3060301@hhs.nl>



Dave Airlie wrote:
> On Wed, 2009-01-28 at 09:03 +0100, Hans de Goede wrote:
>> Callum Lerwick wrote:
>>> On Sat, 2009-01-24 at 23:17 +0100, Kevin Kofler wrote:
>>>> That said, it's a tough topic, because regressions tend to really annoy
>>>> people, they feel "WTF, this always worked, WhyTF is it no longer working
>>>> now?", even though from a purely practical point of view, unfixed bugs (and
>>>> not working on some hardware is practically speaking a bug, even though
>>>> technically it's a missing feature) are much worse because there's no
>>>> working build to revert to.
>>> Your logic is flawed. People with not yet supported hardware, can find
>>> supported hardware, or live with workarounds like VESA. You can not make
>>> progress by accepting regressions. At best, you are spinning your wheels
>>> in place, at worst you are taking one step forward and two steps back.
>>> Regression means just that, you are regressing. Fedora is about
>>> progress, not regress. The linux kernel has a rather strict
>>> no-regressions policy, for good reason:
>>>
>>> http://lwn.net/Articles/261713/
>>>
>>> I wish Xorg and Fedora as a whole, would adopt a similar policy. I'm
>>> very unhappy with how the Xorg update went in F10. Just when we started
>>> getting reliable, usable open source OpenGL, F10 came along and broke
>>> *everything*:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=474977
>>> https://bugzilla.redhat.com/show_bug.cgi?id=441665
>>> https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00435.html
>>>
>>> Not a single one of my machines works out of the box like they did in
>>> F9, they all need work-arounds. But OpenGL support has been quite
>>> thoroughly broken. This has pretty well fucked any ability to get back
>>> to working on Second Life:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=233946
>>>
>>> I have Shit To Do, and it looks like I'm going to have to revert my
>>> entire Xorg back to F9 to do it.
>>>
>> Yes that is what I've done too (revert back to F-9 Xorg), even though I've been 
>> actively working with airlied (congrats with your kid once more) to get things 
>> in shape for F-10 and I believe we are in ok shape wrt 2d in F-10 3d is simply 
>> not usable in F-10, and since I maintain many games in Fedora I need working 3d.
>>
> 
> Didn't I fix the 3D already so it didn't crash for those apps (in
> 7.2.0-15)? or is it just slow?
> 

I've mainly been using rawhide, where the bug definitely still exists (and I do
not have modesetting working in rawhide at all). I've just downgraded, the
kernel, libdrm, xorg-* and mesa-* to F-10 packages. That does give me working
3D without modesetting (which is new to me), but 3d still fails with
modesetting (hard hang when running blobAndConquer). Could you do to rawhide
whatever you've done to F-10 mesa? Running rawhide kernel + rawhide libdrm +
F10 xorg-* + F-10 mesa seems to work well. Better then with Rawhide X + mesa.

Regards,

Hans



From joshuacov at googlemail.com  Sat Jan 31 14:24:23 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 31 Jan 2009 15:24:23 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
References: <49821EF9.4040108@redhat.com> <49831E39.8060100@redhat.com>
	<49832558.1050300@freenet.de> <49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
Message-ID: <5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>

2009/1/31 drago01 <drago01 at gmail.com>:
> On Sat, Jan 31, 2009 at 10:36 AM, Joshua C. <joshuacov at googlemail.com> wrote:
>> 2009/1/30 Tom spot Callaway <tcallawa at redhat.com>:
>>>
>>> They advised that the same advice applies to Documentation.
>>>
>>> Never use "tm" or "(R)". If we are obliged by contract to mention other
>>> trademarks in a legend, add the legend as required by the contract.
>>>
>>> In addition, our documentation should contain the disclaimer:  "All
>>> other trademarks are the property of their respective owners."
>>>
>>> ~spot
>>
>>
>> Just a question here:
>>
>> Since some of the contributors to fedora live/are located outside of
>> the usa, should they be "restricted" by the us trade mark law? The
>> code cannot be patented as a sequnce of mathematical formulas making a
>> given hardware to work in a definite way.
>>
>> Maybe not complying to these rules could lead to packages being not
>> redestributed with fedora but they are still fedora-"legal" packages.
>> So putting them in rpm-fussion or other repos can circumvent this
>> don't-put-the-TM/R-symbol-in-your-description-policy.
>>
>> Since these packages are bound to those trademarked names/patented
>> devices there should be a way to say thier proper name (fair use).
>> Software written to work with logithek should be described as such,
>> because the vendor decided to call thier product logithek. I don't see
>> another way to say this without the trademarked name.
>
> Nobody said that logitech should not be used in the name.
> You should not say that your software _Is_ logitech and don't use (R) or (TM).
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
 The question is if everyone should be bound by these laws. Since the
programmer, the code, the idea (anything) originates outside of the us
(for packagers that are not in the us). it is only "shipped" (I'm not
sure if this is even the right word for this) to a server that's
somewhere in the us. So why should someone be bound (a programmer and
a user outside of the us) by laws just becase the software goes
through a server in us.



From tcallawa at redhat.com  Sat Jan 31 14:26:19 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 31 Jan 2009 09:26:19 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>
References: <49821EF9.4040108@redhat.com>
	<49831E39.8060100@redhat.com>	<49832558.1050300@freenet.de>
	<49832DE5.6070107@redhat.com>	<20090130194636.GJ28663@localhost.localdomain>	<49835A79.1040801@redhat.com>	<20090130195751.GL28663@localhost.localdomain>	<498384C4.4020909@redhat.com>	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
	<5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>
Message-ID: <49845F8B.50402@redhat.com>

On 2009-01-31 at 9:24:23 -0500, "Joshua C." <joshuacov at googlemail.com>
wrote:
>  The question is if everyone should be bound by these laws. Since the
> programmer, the code, the idea (anything) originates outside of the us
> (for packagers that are not in the us). it is only "shipped" (I'm not
> sure if this is even the right word for this) to a server that's
> somewhere in the us. So why should someone be bound (a programmer and
> a user outside of the us) by laws just becase the software goes
> through a server in us.

Basically, the answer is that Fedora takes on legal responsibility for
everything we distribute, even if we're not the
programmer/author/creator/copyright holder.

If I sell a gun to a 5 year old child, I'm liable, not the gun manufacturer.

~spot



From kevin.kofler at chello.at  Sat Jan 31 14:33:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 15:33:23 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<gm012o$1hh$1@ger.gmane.org> <498423B4.60506@poolshark.org>
Message-ID: <gm1nfj$lkf$5@ger.gmane.org>

Denis Leroy wrote:
> but not for the same reason, so the comparison is inadequate.

It is for the same reason: just like MP3 files, OVM is not usable with any
software in Fedora.

        Kevin Kofler



From joshuacov at googlemail.com  Sat Jan 31 14:38:08 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 31 Jan 2009 15:38:08 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <49845F8B.50402@redhat.com>
References: <49821EF9.4040108@redhat.com> <49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
	<5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>
	<49845F8B.50402@redhat.com>
Message-ID: <5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>

2009/1/31 Tom spot Callaway <tcallawa at redhat.com>:
> On 2009-01-31 at 9:24:23 -0500, "Joshua C." <joshuacov at googlemail.com>
> wrote:
>>  The question is if everyone should be bound by these laws. Since the
>> programmer, the code, the idea (anything) originates outside of the us
>> (for packagers that are not in the us). it is only "shipped" (I'm not
>> sure if this is even the right word for this) to a server that's
>> somewhere in the us. So why should someone be bound (a programmer and
>> a user outside of the us) by laws just becase the software goes
>> through a server in us.
>
> Basically, the answer is that Fedora takes on legal responsibility for
> everything we distribute, even if we're not the
> programmer/author/creator/copyright holder.
>
> If I sell a gun to a 5 year old child, I'm liable, not the gun manufacturer.
>
> ~spot

I completely understand your point. The laws have always been a stage
for wide range of interpretation. And I'm sure there're many more
ideas how this should be understood and implemented. Unfortunately
because of the fact that the legal Guardian of the Fedora project is
bound by the US laws we should comply with these, too.
Maybe Paul W. Frields should take the next step and make the project
"completely" independant (this is my personal opinion).



From mitr at volny.cz  Sat Jan 31 14:42:06 2009
From: mitr at volny.cz (Miloslav =?UTF-8?Q?Trma=C4=8D?=)
Date: Sat, 31 Jan 2009 14:42:06 +0000
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>
References: <49821EF9.4040108@redhat.com> <49832DE5.6070107@redhat.com>
	<20090130194636.GJ28663@localhost.localdomain>
	<49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
	<5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>
	<49845F8B.50402@redhat.com>
	<5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>
Message-ID: <1233412926.3403.20.camel@localhost.localdomain>

Joshua C. p??e v So 31. 01. 2009 v 15:38 +0100:
> I completely understand your point. The laws have always been a stage
> for wide range of interpretation. And I'm sure there're many more
> ideas how this should be understood and implemented. Unfortunately
> because of the fact that the legal Guardian of the Fedora project is
> bound by the US laws we should comply with these, too.
If there were no corporation behind Fedora, would you ask the Fedora
release engineers and mirror owners based in the USA to expose
themselves to legal risk?
	Mirek



From tim at niemueller.de  Sat Jan 31 14:41:51 2009
From: tim at niemueller.de (Tim Niemueller)
Date: Sat, 31 Jan 2009 15:41:51 +0100
Subject: Orphan: mt-daapd
In-Reply-To: <20090131031944.GA3117@imp.local>
References: <20090131031944.GA3117@imp.local>
Message-ID: <4984632F.70909@niemueller.de>

W. Michael Petullo schrieb:
> The mt-daapd package is now an orphan. I have decided to stop maintaining
> the package because I am now using my own dmapd software. Dmapd supports
> DPAP in addition to DAAP. I hope to create a dmapd package for Fedora
> in the near term.

Do you know that your website is blocked by Google "may harm your
computer"
(http://www.google.com/interstitial?url=http://www.flyn.org/projects/dmapd/index.html).?
Just found out by searching for dmapd.

	Tim

-- 
    Tim Niemueller <tim at niemueller.de>      www.niemueller.de
=================================================================
 Imagination is more important than knowledge. (Albert Einstein)



From kevin.kofler at chello.at  Sat Jan 31 14:44:17 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 15:44:17 +0100
Subject: fesco meeting summary - 2009-01-30
References: <20090130121722.7361f7a3@ohm.scrye.com>
	<1233377110.8810.4.camel@rosebud>
Message-ID: <gm1o41$lkf$7@ger.gmane.org>

seth vidal wrote:
> F9 and F10 both have python 2.5 and yum 3.2.21. Pretty much all yum's
> since 3.2.18 or 3.2.19 can cope with sha256sums already. and the
> metadata format doesn't change.
> 
> The only changes made to yum to deal with sha256sums was the parts of
> yum createrepo uses to make the metadata.

I think the problem is with SHA256sums in RPMs, not in metadata, so it's RPM
which needs to be fixed, not yum.

        Kevin Kofler



From chitlesh.goorah at gmail.com  Sat Jan 31 14:47:09 2009
From: chitlesh.goorah at gmail.com (Chitlesh GOORAH)
Date: Sat, 31 Jan 2009 15:47:09 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
In-Reply-To: <20090129204443.GD20174@mokona.greysector.net>
References: <1233182932.8363.252.camel@localhost.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
Message-ID: <50baabb30901310647j76f6b9f6p6b90d08904e7ef6e@mail.gmail.com>

Dear all,

The P in Packaging is becoming Politics.

> On Thursday, 29 January 2009 at 21:21, Robert Scheck wrote:
>> Another scheme, which we didn't brought up until now is the same as our
>> friends from kernel.org do: Let's approve every commit by multiple people
>> also known as packagers - without any exception. Single user commits then
>> should not be possible.

On Thu, Jan 29, 2009 at 9:44 PM, Dominik 'Rathann' Mierzejewski  wrote:
> How about we require at least one co-maintainer per package and all packages
> that don't have two maintainers in, say, 6 months from now get dropped?


I maintained many packages for FEL alone together doing marketing and
documentation of my packages. I send upstream feedbacks all the time.

If you are planning this, my 4 hours of work per day proved to be
useless. Then in 6 months FEL will not be a feature. Many Packagers
will be in the same situation.

Please stop making politics and find better ways to spend your time !!
Some people want to achieve something here. By the way, I can find
stuffs for you to work on if you want.

Chitlesh



From kevin.kofler at chello.at  Sat Jan 31 14:41:33 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 15:41:33 +0100
Subject: Too many unowned directories
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
Message-ID: <gm1nut$lkf$6@ger.gmane.org>

Michael Schwendt wrote:
> Sometimes there are lots of reasons why something isn't done. For example,
> RPM fails at replacing a symlink with a directory during updates.

Or a directory with a symlink, which comes up even more often. It's
extremely annoying when you're trying to fix a directory layout without
breaking backwards compatibility.

        Kevin Kofler



From fedora at camperquake.de  Sat Jan 31 14:58:28 2009
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sat, 31 Jan 2009 15:58:28 +0100
Subject: Orphan: mt-daapd
In-Reply-To: <4984632F.70909@niemueller.de>
References: <20090131031944.GA3117@imp.local>
	<4984632F.70909@niemueller.de>
Message-ID: <20090131155828.6d1474d5@lain.camperquake.de>

Hi.

On Sat, 31 Jan 2009 15:41:51 +0100, Tim Niemueller wrote

> Do you know that your website is blocked by Google "may harm your
> computer"
> (http://www.google.com/interstitial?url=http://www.flyn.org/projects/dmapd/index.html).?
> Just found out by searching for dmapd.

Every single web site out there currently displays that in google
at this very moment (at least for me and several other people,
all in germany).



From kevin.kofler at chello.at  Sat Jan 31 15:28:57 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 16:28:57 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1232385498.10018.3.camel@localhost.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<f6ca9fed0901282355l135d0986g5f82f4f58c9d6355@mail.gmail.com>
	<glsri0$3pd$2@ger.gmane.org>
	<f6ca9fed0901301122t43f3c8ebpb9b2cb015248c648@mail.gmail.com>
	<glvtpo$mq7$1@ger.gmane.org>
	<f6ca9fed0901310116y2c49e737ne6000acb45cc690b@mail.gmail.com>
Message-ID: <gm1qnp$1uc$1@ger.gmane.org>

drago01 wrote:
> The name "Firefox" is worth having for marketing reasons.

But at what costs? It prevents us from fixing real issues, it also forces
the packages to be locked down from provenpackager to make sure nobody can
bypass the trademark approval bureaucracy. IMHO a marketing name is not
worth that.

Not to mention that the artwork is also non-Free, as Debian points out.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 31 15:32:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 16:32:10 +0100
Subject: Package Review Stats for the week ending January 18th, 2009
References: <1233182932.8363.252.camel@localhost.localdomain>
	<1233186043.3786.40.camel@wicktop.localdomain>
	<1233187708.6562.1.camel@localhost.localdomain>
	<e76492710901281707o8bcb035p319790fdd5a57496@mail.gmail.com>
	<1233192357.3509.9.camel@localhost.localdomain>
	<20090129072219.GA5712@hurricane.linuxnetz.de>
	<49815EC7.3060409@redhat.com>
	<20090129092441.GA15587@hurricane.linuxnetz.de>
	<glss0n$3pd$3@ger.gmane.org>
	<20090129202133.GD16011@hurricane.linuxnetz.de>
	<20090129204443.GD20174@mokona.greysector.net>
Message-ID: <gm1qtq$1uc$2@ger.gmane.org>

Dominik 'Rathann' Mierzejewski wrote:
> How about we require at least one co-maintainer per package and all
> packages that don't have two maintainers in, say, 6 months from now get
> dropped?

That doesn't make sense. Some lone maintainers are doing a very good job of
it and are available almost 24/7, other packages have 2+ maintainers all
slacking off and all unreachable at many times.

I think we need some better metric than just the number of maintainers.

        Kevin Kofler



From benny+usenet at amorsen.dk  Sat Jan 31 15:12:09 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Sat, 31 Jan 2009 16:12:09 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <20090130212955.GE741830@hiwaay.net> (Chris Adams's message of
	"Fri\, 30 Jan 2009 15\:29\:55 -0600")
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
Message-ID: <m3bptnik6u.fsf@ursa.amorsen.dk>

Chris Adams <cmadams at hiwaay.net> writes:

> IIRC, I asked about this a few years ago and got told that there was a
> performance hit (not big but measurable) for running the 64 bit kernel
> and 32 bit userland.  Maybe that was wrong or is now outdated.

It should be the other way around -- 64 bit kernel should be faster.
The only downside is that the kernel may take a little more memory,
but that isn't really a problem for non-embedded systems.

> What are the chances GRUB/syslinux could be taught to look at a few
> special CPU flags (can you fetch the important flags from real mode?)
> and only present "compatible" (as determined by config arguments, not
> GRUB/syslinux poking into kernels) boot options?  That would help the
> LiveCD case as well.  You could have both 32-PAE and 64 kernels on the
> CD and choose at boot time, although that would take up a large amount
> of space (so maybe not feasible for LiveCD).

That would be rather neat. Tricky, but neat.


/Benny



From kevin.kofler at chello.at  Sat Jan 31 15:57:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 16:57:50 +0100
Subject: Features/ArchitectureSupport - changing what we build for
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk>
Message-ID: <gm1sdu$6tq$1@ger.gmane.org>

Benny Amorsen wrote:
>> What are the chances GRUB/syslinux could be taught to look at a few
>> special CPU flags (can you fetch the important flags from real mode?)
>> and only present "compatible" (as determined by config arguments, not
>> GRUB/syslinux poking into kernels) boot options?  That would help the
>> LiveCD case as well.  You could have both 32-PAE and 64 kernels on the
>> CD and choose at boot time, although that would take up a large amount
>> of space (so maybe not feasible for LiveCD).
> 
> That would be rather neat. Tricky, but neat.

But our live images are already heavily size-constrained. There's definitely
no room for multiple kernels on the KDE live image, and I don't think the
GNOME image has any room left either.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 31 16:06:50 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 17:06:50 +0100
Subject: Features/ArchitectureSupport - changing what we build for
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
Message-ID: <gm1suq$7jh$1@ger.gmane.org>

I wrote:
> But our live images are already heavily size-constrained. There's
> definitely no room for multiple kernels on the KDE live image, and I don't
> think the GNOME image has any room left either.

And I'll add to this that I think the real solution is to make the x86_64
image the default download and the 32-bit image a separate link (maybe
marketed primarily for netbooks). Most computers these days are 64-bit
capable. (Almost all the new non-netbook computers are.) Running 32-bit
userspace on a 64-bit kernel is just a kludge, we should be promoting pure
64-bit instead.

        Kevin Kofler



From jan.kratochvil at redhat.com  Sat Jan 31 16:07:28 2009
From: jan.kratochvil at redhat.com (Jan Kratochvil)
Date: Sat, 31 Jan 2009 17:07:28 +0100
Subject: Validity of the CD size limit nowadays  [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <gm1sdu$6tq$1@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
Message-ID: <20090131160728.GA28571@host0.dyn.jankratochvil.net>

On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> But our live images are already heavily size-constrained. There's definitely
> no room for multiple kernels on the KDE live image, and I don't think the
> GNOME image has any room left either.

Was already discussed the requirement of CDs nowadays?  Even the oldest
computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.


Regards,
Jan



From drago01 at gmail.com  Sat Jan 31 16:11:06 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:11:06 +0100
Subject: Features/ArchitectureSupport - changing what we build for
In-Reply-To: <gm1suq$7jh$1@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org> <gm1suq$7jh$1@ger.gmane.org>
Message-ID: <f6ca9fed0901310811q17c4ad01ub24fab385ca6a48@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:06 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> I wrote:
>> But our live images are already heavily size-constrained. There's
>> definitely no room for multiple kernels on the KDE live image, and I don't
>> think the GNOME image has any room left either.
>
> And I'll add to this that I think the real solution is to make the x86_64
> image the default download and the 32-bit image a separate link (maybe
> marketed primarily for netbooks). Most computers these days are 64-bit
> capable. (Almost all the new non-netbook computers are.) Running 32-bit
> userspace on a 64-bit kernel is just a kludge, we should be promoting pure
> 64-bit instead.

Yeah users should not have to search for the 64bit version, it should
be the default with a link "For older systems click here"(32bit
version).



From drago01 at gmail.com  Sat Jan 31 16:12:18 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:12:18 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131160728.GA28571@host0.dyn.jankratochvil.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
Message-ID: <f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
<jan.kratochvil at redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>> But our live images are already heavily size-constrained. There's definitely
>> no room for multiple kernels on the KDE live image, and I don't think the
>> GNOME image has any room left either.
>
> Was already discussed the requirement of CDs nowadays?  Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.

Well for x86_64 we can/should do this.
Good luck on finding a x86_64 computer/laptop without a DVD drive.



From kevin.kofler at chello.at  Sat Jan 31 16:14:31 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 17:14:31 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
Message-ID: <gm1td7$ah9$1@ger.gmane.org>

drago01 wrote:
> Well for x86_64 we can/should do this.
> Good luck on finding a x86_64 computer/laptop without a DVD drive.

But x86_64 doesn't need multiple kernels, it needs only the x86_64 one. PAE
is not needed on x86_64 and 32-bit kernels don't work with 64-bit
userspace.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 31 16:16:54 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 17:16:54 +0100
Subject: Features/ArchitectureSupport - changing what we build for
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<gm1suq$7jh$1@ger.gmane.org>
	<f6ca9fed0901310811q17c4ad01ub24fab385ca6a48@mail.gmail.com>
Message-ID: <gm1thm$ah9$2@ger.gmane.org>

drago01 wrote:
> Yeah users should not have to search for the 64bit version, it should
> be the default with a link "For older systems click here"(32bit
> version).

+1, except it should be "For netbooks or older computers click here (32-bit
version)".

Unfortunately, most netbooks are not 64-bit capable. :-( The netbook
versions of the Atom have it disabled ("for power consumption reasons",
they say; I think there's also some differential pricing involved) and the
Celeron used on the original EeePCs and some other netbooks is also a
32-bit only version (based on the original Core Solo, AFAIK).

        Kevin Kofler



From wolfy at nobugconsulting.ro  Sat Jan 31 16:38:35 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 31 Jan 2009 18:38:35 +0200
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <gm1o41$lkf$7@ger.gmane.org>
References: <20090130121722.7361f7a3@ohm.scrye.com>	<1233377110.8810.4.camel@rosebud>
	<gm1o41$lkf$7@ger.gmane.org>
Message-ID: <49847E8B.2010304@nobugconsulting.ro>


> seth vidal wrote:
>   
>> F9 and F10 both have python 2.5 and yum 3.2.21. Pretty much all yum's
>> since 3.2.18 or 3.2.19 can cope with sha256sums already. and the
>> metadata format doesn't change.
>>
>> The only changes made to yum to deal with sha256sums was the parts of
>> yum createrepo uses to make the metadata.
>>     
For what it's worth and if anyone is interested [*]: I have compiled all 
the needed deps and I use yum-3.2.19-18 in FC-7 (please, no flames on EOL ).
Thanks Seth for hints and the work on backporting hashlib.

[*] Contact me by private mail or IRC



From drago01 at gmail.com  Sat Jan 31 16:39:59 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:39:59 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <gm1td7$ah9$1@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<gm1td7$ah9$1@ger.gmane.org>
Message-ID: <f6ca9fed0901310839o333c02cdv9f897f7d762a760a@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:14 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> Well for x86_64 we can/should do this.
>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>
> But x86_64 doesn't need multiple kernels, it needs only the x86_64 one. PAE
> is not needed on x86_64 and 32-bit kernels don't work with 64-bit
> userspace.

That's not about kernels, we should move away from a CD atleast for
x86_64 instead of not shipping useful apps for size reasons (ex:
OO.org)



From bruno at wolff.to  Sat Jan 31 16:43:52 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Jan 2009 10:43:52 -0600
Subject: Validity of the CD size limit nowadays  [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131160728.GA28571@host0.dyn.jankratochvil.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
Message-ID: <20090131164352.GA25612@wolff.to>

On Sat, Jan 31, 2009 at 17:07:28 +0100,
  Jan Kratochvil <jan.kratochvil at redhat.com> wrote:
> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
> > But our live images are already heavily size-constrained. There's definitely
> > no room for multiple kernels on the KDE live image, and I don't think the
> > GNOME image has any room left either.
> 
> Was already discussed the requirement of CDs nowadays?  Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.

If you want DVD iso's to be over 4 GiB you should provide comments to
the Spins SIG soon. There are concerns that DVD images over 4 GiB but
less than 4.7 GB (which is what will fit on common DVD types) will cause
problems for people using vfat.



From arjan at infradead.org  Sat Jan 31 16:43:32 2009
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 31 Jan 2009 08:43:32 -0800
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <498342E3.3010106@redhat.com>
References: <1233260366.4952.29.camel@choeger6> <49821FD3.4020801@redhat.com>
	<1233267250.4952.36.camel@choeger6> <4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
	<20090130150046.GA8869@nostromo.devel.redhat.com>
	<498333E0.3040806@redhat.com>
	<20090130180517.GB11755@nostromo.devel.redhat.com>
	<498342E3.3010106@redhat.com>
Message-ID: <20090131084332.37234246@infradead.org>

On Fri, 30 Jan 2009 13:11:47 -0500
Brian Maly <bmaly at redhat.com> wrote:
> The Intel Moblin V2 core is UEFI and not legacy BIOS. 

I'm sorry but I'll need to call BS on this one.
In fact I suspect it's the other way around; I have yet to see a
netbook with "pure" UEFI. And trust me, as one of the Moblin distro
people, I have seen many.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From kevin.kofler at chello.at  Sat Jan 31 16:45:45 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 17:45:45 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to>
Message-ID: <gm1v7p$ft2$1@ger.gmane.org>

Bruno Wolff III wrote:
> If you want DVD iso's to be over 4 GiB you should provide comments to
> the Spins SIG soon. There are concerns that DVD images over 4 GiB but
> less than 4.7 GB (which is what will fit on common DVD types) will cause
> problems for people using vfat.

The vfat limit is 2 GB, so 4 or 4.7 GB will make no difference for vfat
users, neither will work.

        Kevin Kofler



From frankly3d at fedoraproject.org  Sat Jan 31 16:45:57 2009
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Sat, 31 Jan 2009 16:45:57 +0000
Subject: Maybe OT for this list: Programming languages for Fedora?
Message-ID: <49848045.7020602@fedoraproject.org>

What languages, would be good to learn re. Fedora?
(Have started Java currently, on the curriculum)

What extra(s) would be useful?

Frank



From drago01 at gmail.com  Sat Jan 31 16:46:34 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:46:34 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131164352.GA25612@wolff.to>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to>
Message-ID: <f6ca9fed0901310846k70153063x9642bc3fd0712af8@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:43 PM, Bruno Wolff III <bruno at wolff.to> wrote:
> On Sat, Jan 31, 2009 at 17:07:28 +0100,
>  Jan Kratochvil <jan.kratochvil at redhat.com> wrote:
>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>> > But our live images are already heavily size-constrained. There's definitely
>> > no room for multiple kernels on the KDE live image, and I don't think the
>> > GNOME image has any room left either.
>>
>> Was already discussed the requirement of CDs nowadays?  Even the oldest
>> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
>
> If you want DVD iso's to be over 4 GiB you should provide comments to
> the Spins SIG soon. There are concerns that DVD images over 4 GiB but
> less than 4.7 GB (which is what will fit on common DVD types) will cause
> problems for people using vfat.

Well the point is not the size of the DVD image itself but having a
liveDVD instead of a liveCD (going away from the 700MB size limit)



From drago01 at gmail.com  Sat Jan 31 16:50:00 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:50:00 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <gm1v7p$ft2$1@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to> <gm1v7p$ft2$1@ger.gmane.org>
Message-ID: <f6ca9fed0901310850i914b7c0r62ad1a5b37c0528b@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:45 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> Bruno Wolff III wrote:
>> If you want DVD iso's to be over 4 GiB you should provide comments to
>> the Spins SIG soon. There are concerns that DVD images over 4 GiB but
>> less than 4.7 GB (which is what will fit on common DVD types) will cause
>> problems for people using vfat.
>
> The vfat limit is 2 GB, so 4 or 4.7 GB will make no difference for vfat
> users, neither will work.

File size limit on fat32 is 4GB not 2.



From kevin.kofler at chello.at  Sat Jan 31 16:47:31 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 17:47:31 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<gm1td7$ah9$1@ger.gmane.org>
	<f6ca9fed0901310839o333c02cdv9f897f7d762a760a@mail.gmail.com>
Message-ID: <gm1vb3$ft2$2@ger.gmane.org>

drago01 wrote:
> That's not about kernels, we should move away from a CD atleast for
> x86_64 instead of not shipping useful apps for size reasons (ex:
> OO.org)

OO.o still has no working KDE 4 integration, and we don't even have the KDE
3 integration packaged, so I'm not sure it would be a good idea to put it
on the KDE spin anyway. KOffice 2 is the way to go in the long run.

        Kevin Kofler



From drago01 at gmail.com  Sat Jan 31 16:56:47 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 17:56:47 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <gm1vb3$ft2$2@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<gm1td7$ah9$1@ger.gmane.org>
	<f6ca9fed0901310839o333c02cdv9f897f7d762a760a@mail.gmail.com>
	<gm1vb3$ft2$2@ger.gmane.org>
Message-ID: <f6ca9fed0901310856g4afdfadau11747e48adbe4400@mail.gmail.com>

On Sat, Jan 31, 2009 at 5:47 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> That's not about kernels, we should move away from a CD atleast for
>> x86_64 instead of not shipping useful apps for size reasons (ex:
>> OO.org)
>
> OO.o still has no working KDE 4 integration, and we don't even have the KDE
> 3 integration packaged, so I'm not sure it would be a good idea to put it
> on the KDE spin anyway. KOffice 2 is the way to go in the long run.

Even the KDE spin would profit from moving to DVD because its afaik
english only while the Desktop live cd has the translations.



From wolfy at nobugconsulting.ro  Sat Jan 31 16:57:11 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 31 Jan 2009 18:57:11 +0200
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <loom.20090130T215554-885@post.gmane.org>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
Message-ID: <498482E7.5030600@nobugconsulting.ro>

On 01/31/2009 12:00 AM, Cry wrote:
> Chitlesh GOORAH <chitlesh.goorah <at> gmail.com> writes:
>
>   
>> The subject of this email is "Fedora Project, give me 20 Million Euros
>> or Free Software" ! Unfortunately, I'm not kidding and even 20 Million
>> Euros is not enough.
>>     
>
> Fedora isn't a "if its free stick it in" repository.  It isn't the old sunsite.
>
> Fedora is for linux (and I guess windows now) software and data that software
> can use.  There isn't anything that can use OVM so why bundle it into fedora? 
> Before you reply with 90 pages of prose, please have someone edit it down to a
> readable subset.
>   
Scenario:

Data:
I have a Fedora server. The OVM package could be installed on this 
server if it was available in the repositories.
I have several dozens boxes running RHEL which run commercial EDA 
software and could use the OVM content shared by the Fedora server.
You have no license to use the EDA software I have.

Conclusion: because you do not have access to free tools and neither the 
15 K USD/month needed for the license, I may not install OVM from the 
Fedora repos.



Chitlesh and I are the only ones who see a flaw in the reasoning above ?



From bruno at wolff.to  Sat Jan 31 17:07:55 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Jan 2009 11:07:55 -0600
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <49848045.7020602@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org>
Message-ID: <20090131170755.GA32133@wolff.to>

On Sat, Jan 31, 2009 at 16:45:57 +0000,
  Frank Murphy <frankly3d at fedoraproject.org> wrote:
> What languages, would be good to learn re. Fedora?
> (Have started Java currently, on the curriculum)
> 
> What extra(s) would be useful?

For what purposes?



From jwboyer at gmail.com  Sat Jan 31 17:22:19 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 31 Jan 2009 12:22:19 -0500
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
Message-ID: <20090131172219.GB7964@yoda.jdub.homelinux.org>

On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
><jan.kratochvil at redhat.com> wrote:
>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>> But our live images are already heavily size-constrained. There's definitely
>>> no room for multiple kernels on the KDE live image, and I don't think the
>>> GNOME image has any room left either.
>>
>> Was already discussed the requirement of CDs nowadays?  Even the oldest
>> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.
>
>Well for x86_64 we can/should do this.
>Good luck on finding a x86_64 computer/laptop without a DVD drive.

http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=FB7AF02917DF464B80B47A578BC9DD24

Note that while a DVD drive is an option, it does not come with one
by default and it costs $225.00 extra.  It took me 30 seconds to
find that machine.  I'm sure there are more.

josh



From jkeating at redhat.com  Sat Jan 31 17:22:12 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 31 Jan 2009 09:22:12 -0800
Subject: Too many unowned directories
In-Reply-To: <gm1nut$lkf$6@ger.gmane.org>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
	<gm1nut$lkf$6@ger.gmane.org>
Message-ID: <1233422532.3650.377.camel@localhost.localdomain>

On Sat, 2009-01-31 at 15:41 +0100, Kevin Kofler wrote:
>  Or a directory with a symlink, which comes up even more often. It's
> extremely annoying when you're trying to fix a directory layout without
> breaking backwards compatibility.

Right, the question always become "what to do with the
files/folders/symlinks/whatever inside that directory you want to turn
into a symlink?"

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/5883961d/attachment.sig>

From joe at nall.com  Sat Jan 31 17:29:49 2009
From: joe at nall.com (Joe Nall)
Date: Sat, 31 Jan 2009 11:29:49 -0600
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131172219.GB7964@yoda.jdub.homelinux.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
Message-ID: <20A15351-3420-4BE8-A9AD-E1920324A536@nall.com>


On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:

> On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
>> <jan.kratochvil at redhat.com> wrote:
>>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>>> But our live images are already heavily size-constrained. There's  
>>>> definitely
>>>> no room for multiple kernels on the KDE live image, and I don't  
>>>> think the
>>>> GNOME image has any room left either.
>>>
>>> Was already discussed the requirement of CDs nowadays?  Even the  
>>> oldest
>>> computers already have DVD and I miss more a fully-featured  
>>> LiveDVD 5GB spin.
>>
>> Well for x86_64 we can/should do this.
>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>
> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=FB7AF02917DF464B80B47A578BC9DD24
>
> Note that while a DVD drive is an option, it does not come with one
> by default and it costs $225.00 extra.  It took me 30 seconds to
> find that machine.  I'm sure there are more.

I think that is a poor example for this discussion since it doesn't  
have a CD option at all. The link is to a laptop with no optical  
media. The only media choice is a DVD burner.

joe




From jwboyer at gmail.com  Sat Jan 31 17:41:38 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 31 Jan 2009 12:41:38 -0500
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20A15351-3420-4BE8-A9AD-E1920324A536@nall.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
	<20A15351-3420-4BE8-A9AD-E1920324A536@nall.com>
Message-ID: <20090131174138.GA8132@yoda.jdub.homelinux.org>

On Sat, Jan 31, 2009 at 11:29:49AM -0600, Joe Nall wrote:
>
> On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:
>
>> On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>>> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
>>> <jan.kratochvil at redhat.com> wrote:
>>>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>>>> But our live images are already heavily size-constrained. There's 
>>>>> definitely
>>>>> no room for multiple kernels on the KDE live image, and I don't  
>>>>> think the
>>>>> GNOME image has any room left either.
>>>>
>>>> Was already discussed the requirement of CDs nowadays?  Even the  
>>>> oldest
>>>> computers already have DVD and I miss more a fully-featured  
>>>> LiveDVD 5GB spin.
>>>
>>> Well for x86_64 we can/should do this.
>>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>>
>> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=FB7AF02917DF464B80B47A578BC9DD24
>>
>> Note that while a DVD drive is an option, it does not come with one
>> by default and it costs $225.00 extra.  It took me 30 seconds to
>> find that machine.  I'm sure there are more.
>
> I think that is a poor example for this discussion since it doesn't have 
> a CD option at all. The link is to a laptop with no optical media. The 
> only media choice is a DVD burner.

You can think whatever you like.  The assertion was that all x86_64
machines have a CD/DVD drive and that is very much not the case.

josh



From frankly3d at fedoraproject.org  Sat Jan 31 17:45:31 2009
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Sat, 31 Jan 2009 17:45:31 +0000
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <20090131170755.GA32133@wolff.to>
References: <49848045.7020602@fedoraproject.org>
	<20090131170755.GA32133@wolff.to>
Message-ID: <49848E3B.8000809@fedoraproject.org>

Bruno Wolff III wrote:
> On Sat, Jan 31, 2009 at 16:45:57 +0000,
>   Frank Murphy <frankly3d at fedoraproject.org> wrote:
>> What languages, would be good to learn re. Fedora?
>> (Have started Java currently, on the curriculum)
>>
>> What extra(s) would be useful?
> 
> For what purposes?

For helping with packaging\ bringing new stuff in\ crating gui(s) where
the need arises, bug fixing (as distinct from just reporting)

Frank



From drago01 at gmail.com  Sat Jan 31 17:49:28 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 18:49:28 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131174138.GA8132@yoda.jdub.homelinux.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
	<20A15351-3420-4BE8-A9AD-E1920324A536@nall.com>
	<20090131174138.GA8132@yoda.jdub.homelinux.org>
Message-ID: <f6ca9fed0901310949n1299b814l8f6413ab6bc9293d@mail.gmail.com>

On Sat, Jan 31, 2009 at 6:41 PM, Josh Boyer <jwboyer at gmail.com> wrote:
> On Sat, Jan 31, 2009 at 11:29:49AM -0600, Joe Nall wrote:
>>
>> On Jan 31, 2009, at 11:22 AM, Josh Boyer wrote:
>>
>>> On Sat, Jan 31, 2009 at 05:12:18PM +0100, drago01 wrote:
>>>> On Sat, Jan 31, 2009 at 5:07 PM, Jan Kratochvil
>>>> <jan.kratochvil at redhat.com> wrote:
>>>>> On Sat, 31 Jan 2009 16:57:50 +0100, Kevin Kofler wrote:
>>>>>> But our live images are already heavily size-constrained. There's
>>>>>> definitely
>>>>>> no room for multiple kernels on the KDE live image, and I don't
>>>>>> think the
>>>>>> GNOME image has any room left either.
>>>>>
>>>>> Was already discussed the requirement of CDs nowadays?  Even the
>>>>> oldest
>>>>> computers already have DVD and I miss more a fully-featured
>>>>> LiveDVD 5GB spin.
>>>>
>>>> Well for x86_64 we can/should do this.
>>>> Good luck on finding a x86_64 computer/laptop without a DVD drive.
>>>
>>> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=FB7AF02917DF464B80B47A578BC9DD24
>>>
>>> Note that while a DVD drive is an option, it does not come with one
>>> by default and it costs $225.00 extra.  It took me 30 seconds to
>>> find that machine.  I'm sure there are more.
>>
>> I think that is a poor example for this discussion since it doesn't have
>> a CD option at all. The link is to a laptop with no optical media. The
>> only media choice is a DVD burner.
>
> You can think whatever you like.  The assertion was that all x86_64
> machines have a CD/DVD drive and that is very much not the case.

Well lets change this "all x86_64 hardware with optical drives" ...
because it does not matter for such a machine if we use a CD or a DVD.



From gmaxwell at gmail.com  Sat Jan 31 17:53:31 2009
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sat, 31 Jan 2009 12:53:31 -0500
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131174138.GA8132@yoda.jdub.homelinux.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
	<20A15351-3420-4BE8-A9AD-E1920324A536@nall.com>
	<20090131174138.GA8132@yoda.jdub.homelinux.org>
Message-ID: <e692861c0901310953p79f5326br6a4255b2f7d312f6@mail.gmail.com>

On Sat, Jan 31, 2009 at 12:41 PM, Josh Boyer <jwboyer at gmail.com> wrote:
>> I think that is a poor example for this discussion since it doesn't have
>> a CD option at all. The link is to a laptop with no optical media. The
>> only media choice is a DVD burner.
>
> You can think whatever you like.  The assertion was that all x86_64
> machines have a CD/DVD drive and that is very much not the case.

No it wasn't? That was what he *stated*, but its clear from the
context thats not what he intended to assert.

The discussion is regarding switching the LiveCD into a LiveDVD.  The
intended assertion is that these systems which had CD support at all
also had DVD support.

Your counter example is no more useful than pointing out some
screenless x86_64 based telephone switch which didn't have a DVD. :)



From pbrobinson at gmail.com  Sat Jan 31 17:57:42 2009
From: pbrobinson at gmail.com (Peter Robinson)
Date: Sat, 31 Jan 2009 18:57:42 +0100
Subject: Moblin 2 and Fedora
In-Reply-To: <49844F3B.6060905@fedoraproject.org>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
	<49844F3B.6060905@fedoraproject.org>
Message-ID: <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>

>> Hi All,
>>
>> I noticed Intel has announced [1] the first alpha of Moblin 2 which
>> from memory and by the look of it is based on Fedora [2].
>
> Yes but Intel doesn't seem interested in pushing any changes back to Fedora.
>
>> I'm wondering what the outcome of the discussions with them was about
>> basing it on upstream Fedora and if anyone knows what the differences
>> are between the source repos [2] and that of base Fedora are?
>
> No idea but have you tried asking in the Moblin mailing lists? They should
> know better.

The reason I asked was because there was a discussion about on
fedora-devel it back when it was first announced that it would be
based on Fedora. I seem to remember one of the board members was at
the event where it was announced and was going to chat with them or
something.

Peter



From mschwendt at gmail.com  Sat Jan 31 18:14:17 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 31 Jan 2009 19:14:17 +0100
Subject: Too many unowned directories
In-Reply-To: <1233422532.3650.377.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
	<gm1nut$lkf$6@ger.gmane.org>
	<1233422532.3650.377.camel@localhost.localdomain>
Message-ID: <20090131191417.6f69fcf1.mschwendt@gmail.com>

On Sat, 31 Jan 2009 09:22:12 -0800, Jesse wrote:

> On Sat, 2009-01-31 at 15:41 +0100, Kevin Kofler wrote:
> >  Or a directory with a symlink, which comes up even more often. It's
> > extremely annoying when you're trying to fix a directory layout without
> > breaking backwards compatibility.
> 
> Right, the question always become "what to do with the
> files/folders/symlinks/whatever inside that directory you want to turn
> into a symlink?"

One more reason why packagers ought to become familiar with their
%files lists. ;)



From jonstanley at gmail.com  Sat Jan 31 18:17:48 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Sat, 31 Jan 2009 13:17:48 -0500
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <f6ca9fed0901310846k70153063x9642bc3fd0712af8@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to>
	<f6ca9fed0901310846k70153063x9642bc3fd0712af8@mail.gmail.com>
Message-ID: <da159fda0901311017r6d1af75cse6e63acc7607afce@mail.gmail.com>

On Sat, Jan 31, 2009 at 11:46 AM, drago01 <drago01 at gmail.com> wrote:

> Well the point is not the size of the DVD image itself but having a
> liveDVD instead of a liveCD (going away from the 700MB size limit)

Keep in mind that the same spin for all arches is produced using the
same kickstart (i.e. fedora-livecd-desktop.ks). So the technical
feasibility of keeping a LiveCD for x86 and DVD for x86_64 is nearly
nil, unless we broke up the kickstarts (which I for one am not in
favor of).



From jonstanley at gmail.com  Sat Jan 31 18:21:22 2009
From: jonstanley at gmail.com (Jon Stanley)
Date: Sat, 31 Jan 2009 13:21:22 -0500
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <49847E8B.2010304@nobugconsulting.ro>
References: <20090130121722.7361f7a3@ohm.scrye.com>
	<1233377110.8810.4.camel@rosebud> <gm1o41$lkf$7@ger.gmane.org>
	<49847E8B.2010304@nobugconsulting.ro>
Message-ID: <da159fda0901311021w56a9814bhf572e3c7ab8d33d3@mail.gmail.com>

On Sat, Jan 31, 2009 at 11:38 AM, Manuel Wolfshant
<wolfy at nobugconsulting.ro> wrote:

> For what it's worth and if anyone is interested [*]: I have compiled all the
> needed deps and I use yum-3.2.19-18 in FC-7 (please, no flames on EOL ).

Does this include a newer RPM, since that seems to be where the issue is here?



From jwboyer at gmail.com  Sat Jan 31 18:22:11 2009
From: jwboyer at gmail.com (Josh Boyer)
Date: Sat, 31 Jan 2009 13:22:11 -0500
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <49848E3B.8000809@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org>
	<20090131170755.GA32133@wolff.to>
	<49848E3B.8000809@fedoraproject.org>
Message-ID: <20090131182211.GB8132@yoda.jdub.homelinux.org>

On Sat, Jan 31, 2009 at 05:45:31PM +0000, Frank Murphy wrote:
>Bruno Wolff III wrote:
>> On Sat, Jan 31, 2009 at 16:45:57 +0000,
>>   Frank Murphy <frankly3d at fedoraproject.org> wrote:
>>> What languages, would be good to learn re. Fedora?
>>> (Have started Java currently, on the curriculum)
>>>
>>> What extra(s) would be useful?
>> 
>> For what purposes?
>
>For helping with packaging\ bringing new stuff in\ crating gui(s) where

Packaging is going to depend on whatever language the application you are
packaging was written in.  Most of the GUIs are done via some kind of GTK
binding, be it C/C++ or python.

>the need arises, bug fixing (as distinct from just reporting)

Bug fixes also depends on the package you are working with.

Fedora has a variety of languages used throughout it's packages.  The most
common are likely:

C
C++
Python
Perl
Java

josh



From ffesti at redhat.com  Sat Jan 31 18:24:31 2009
From: ffesti at redhat.com (Florian Festi)
Date: Sat, 31 Jan 2009 19:24:31 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <49848045.7020602@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org>
Message-ID: <4984975F.2080101@redhat.com>

Frank Murphy wrote:
> What languages, would be good to learn re. Fedora?
> (Have started Java currently, on the curriculum)
> 
> What extra(s) would be useful?

The kernel and most GNU and GNOME programs and most system tools are written 
in C. KDE is mostly in C++. Python is getting popular for helpers like yum, 
config tools, koji, ...

Perl, Ruby and Lua have their niches.

Java is more or less an universe of its own that has not much connection to 
the Linux universe.

Same is true for PHP which is mainly restricted to dynamic web pages.

Additional to "real" programming languages shell (bash) scripts are used a 
lot in packaging, init scripts, ...

Florian



From jkeating at redhat.com  Sat Jan 31 18:32:24 2009
From: jkeating at redhat.com (Jesse Keating)
Date: Sat, 31 Jan 2009 10:32:24 -0800
Subject: Too many unowned directories
In-Reply-To: <20090131191417.6f69fcf1.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
	<gm1nut$lkf$6@ger.gmane.org>
	<1233422532.3650.377.camel@localhost.localdomain>
	<20090131191417.6f69fcf1.mschwendt@gmail.com>
Message-ID: <1233426744.3650.379.camel@localhost.localdomain>

On Sat, 2009-01-31 at 19:14 +0100, Michael Schwendt wrote:
>  One more reason why packagers ought to become familiar with their
> %files lists. ;)

The files a package owns are one thing, the files another package has
placed there, or a user process has placed there, or just the user
themselves have placed there are a different more difficult matter.

-- 
Jesse Keating
Fedora -- Freedom? is a feature!
identi.ca: http://identi.ca/jkeating
-------------- 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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/f7d8614f/attachment.sig>

From frankly3d at fedoraproject.org  Sat Jan 31 18:34:22 2009
From: frankly3d at fedoraproject.org (Frank Murphy)
Date: Sat, 31 Jan 2009 18:34:22 +0000
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <4984975F.2080101@redhat.com>
References: <49848045.7020602@fedoraproject.org> <4984975F.2080101@redhat.com>
Message-ID: <498499AE.1080102@fedoraproject.org>

Florian Festi wrote:
> Frank Murphy wrote:
>> What languages, would be good to learn re. Fedora?

Thanks for the replies, gives me a base to look at.

Frank




From bruno at wolff.to  Sat Jan 31 18:40:46 2009
From: bruno at wolff.to (Bruno Wolff III)
Date: Sat, 31 Jan 2009 12:40:46 -0600
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <49848E3B.8000809@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org>
	<20090131170755.GA32133@wolff.to>
	<49848E3B.8000809@fedoraproject.org>
Message-ID: <20090131184046.GA25151@wolff.to>

On Sat, Jan 31, 2009 at 17:45:31 +0000,
  Frank Murphy <frankly3d at fedoraproject.org> wrote:
> Bruno Wolff III wrote:
> > On Sat, Jan 31, 2009 at 16:45:57 +0000,
> >   Frank Murphy <frankly3d at fedoraproject.org> wrote:
> >> What languages, would be good to learn re. Fedora?
> >> (Have started Java currently, on the curriculum)
> >>
> >> What extra(s) would be useful?
> > 
> > For what purposes?
> 
> For helping with packaging\ bringing new stuff in\ crating gui(s) where
> the need arises, bug fixing (as distinct from just reporting)

C would probably be encountered the most. But if you think you target some
particular niche the answer could be different.

Besides what other people mentioned, you might want to spend some time
learning build systems such as autotools, make, cmake, scons and the like.

In the realm of general advice, I would look at things I would want to see
packaged in Fedora that currently aren't (or perhaps are orphaned) and look
at what I would need to learn to be able to effectively package those things.
There is more than learning the programming languages used, but packages
using the same languages will often have similarities in what you need to
do from the point of view of a packager. So if there are more things that
you would like to help package than you have time for, you might look for
groups that use the same programming languages or for other reasons are
similar to package. That way you would be able to be more efficient.



From vonbrand at inf.utfsm.cl  Sat Jan 31 18:41:50 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 31 Jan 2009 15:41:50 -0300
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <498499AE.1080102@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org> <4984975F.2080101@redhat.com>
	<498499AE.1080102@fedoraproject.org>
Message-ID: <200901311841.n0VIfohp003803@laptop14.inf.utfsm.cl>

Frank Murphy <frankly3d at fedoraproject.org> wrote:
> Florian Festi wrote:
> > Frank Murphy wrote:
> >> What languages, would be good to learn re. Fedora?
> 
> Thanks for the replies, gives me a base to look at.

In my experience, it makes very little sense to try to learn a language on
its own. Look at packages that interest you, select some (especially ones
written in the same language) and start hacking away. That way you won't
get bored, and learn from more experienced people's (hopefully with good
taste too) code.

Happy hacking!
-- 
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 arjan at infradead.org  Sat Jan 31 19:06:44 2009
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 31 Jan 2009 11:06:44 -0800
Subject: Moblin 2 and Fedora
In-Reply-To: <5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
	<49844F3B.6060905@fedoraproject.org>
	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
Message-ID: <20090131110644.1a80ddf5@infradead.org>

On Sat, 31 Jan 2009 18:57:42 +0100
Peter Robinson <pbrobinson at gmail.com> wrote:

> >> Hi All,
> >>
> >> I noticed Intel has announced [1] the first alpha of Moblin 2 which
> >> from memory and by the look of it is based on Fedora [2].

Various parts from Moblin 2 come from Fedora. Other parts come from
OpenSUSE, and about half is packaged newly based on upstream releases.
(although some descriptions are borrowed from various sources)

> > Yes but Intel doesn't seem interested in pushing any changes back
> > to Fedora.

If there was a "based on" relationship we would. But it's not nearly so
simple.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From mschwendt at gmail.com  Sat Jan 31 19:12:03 2009
From: mschwendt at gmail.com (Michael Schwendt)
Date: Sat, 31 Jan 2009 20:12:03 +0100
Subject: Too many unowned directories
In-Reply-To: <1233426744.3650.379.camel@localhost.localdomain>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
	<gm1nut$lkf$6@ger.gmane.org>
	<1233422532.3650.377.camel@localhost.localdomain>
	<20090131191417.6f69fcf1.mschwendt@gmail.com>
	<1233426744.3650.379.camel@localhost.localdomain>
Message-ID: <20090131201203.57d2d156.mschwendt@gmail.com>

On Sat, 31 Jan 2009 10:32:24 -0800, Jesse wrote:

> >  One more reason why packagers ought to become familiar with their
> > %files lists. ;)
> 
> The files a package owns are one thing, the files another package has
> placed there, or a user process has placed there, or just the user
> themselves have placed there are a different more difficult matter.

Sure, but the important thing here is to notice that a directory is
turnt into a symlink. Once noticed, packager can think twice and
reconsider. Changing all relevant programs to access the link target
path directly would be one possible solution.

%files lists which are overloaded with macros and recursively included
trees aren't readable and require packagers to use "rpm -qlv" (or rpmls)
to examine packages and understand the contents of a package.



From rjones at redhat.com  Sat Jan 31 19:34:47 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 31 Jan 2009 19:34:47 +0000
Subject: Too many unowned directories
In-Reply-To: <20090131134347.7bb42020.mschwendt@gmail.com>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
Message-ID: <20090131193421.GA24526@amd.home.annexia.org>

On Sat, Jan 31, 2009 at 01:43:47PM +0100, Michael Schwendt wrote:
> On Sat, 31 Jan 2009 11:11:30 +0000, Richard wrote:
> > Why can't RPM deal with it?
> 
> Because it doesn't do it yet? ;)
> Perhaps it's not even easy to implement in RPM's current code base?

Sure thing.  We should file a bug (feature enhancement really) against
RPM and then forget about the unowned directories thing until that bug
has been resolved one way or another.

I don't know if you agree with me, but I think the _right_ way to
solve this is once in RPM, not 48235 times over in all the packages in
Fedora.  Even if the RPM implementation is a bit tricky, it's surely
easier than pushing this job down to every packager.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora



From tcallawa at redhat.com  Sat Jan 31 19:35:31 2009
From: tcallawa at redhat.com (Tom "spot" Callaway)
Date: Sat, 31 Jan 2009 14:35:31 -0500
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>
References: <49821EF9.4040108@redhat.com>
	<49832DE5.6070107@redhat.com>	<20090130194636.GJ28663@localhost.localdomain>	<49835A79.1040801@redhat.com>	<20090130195751.GL28663@localhost.localdomain>	<498384C4.4020909@redhat.com>	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>	<5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>	<49845F8B.50402@redhat.com>
	<5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>
Message-ID: <4984A803.9050808@redhat.com>

On 2009-01-31 at 9:38:08 -0500, "Joshua C." <joshuacov at googlemail.com>
wrote:
> Unfortunately
> because of the fact that the legal Guardian of the Fedora project is
> bound by the US laws we should comply with these, too.
> Maybe Paul W. Frields should take the next step and make the project
> "completely" independant (this is my personal opinion).

We've been down this road a few times before, but there are serious
logistical problems. If Fedora was a US non-profit entity, that entity
would still have to comply with US laws (not to mention the financial
issues around where the majority of Fedora's funding comes from).

Even if Fedora incorporated as a separate entity in a legal no-mans-land
(like say, the Isle of Man *cough, cough, cough*), they would be passing
the risk onto US mirrors and users.

I'm of the opinion that Fedora raises awareness of the issues that
stifle innovation, both in the US and worldwide. There are options for
individuals who are not bound by such laws (or who choose to be
conscientious objectors). By playing by "the rules" we set a foundation
for being able to document how broken laws are making developers and
users suffer, and present that material as briefs in cases in In re Bilski:

http://www.groklaw.net/article.php?story=20080409033837121

If you're completely uninterested in trying to fix the system as a
participant, there are other distributions which don't care about legal
issues. I'm proud that Fedora does its best to protect not just itself,
but also its users from legal risk.

~spot



From rjones at redhat.com  Sat Jan 31 19:45:29 2009
From: rjones at redhat.com (Richard W.M. Jones)
Date: Sat, 31 Jan 2009 19:45:29 +0000
Subject: Validity of the CD size limit nowadays  [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131160728.GA28571@host0.dyn.jankratochvil.net>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
Message-ID: <20090131194529.GB24526@amd.home.annexia.org>

On Sat, Jan 31, 2009 at 05:07:28PM +0100, Jan Kratochvil wrote:
> Was already discussed the requirement of CDs nowadays?  Even the oldest
> computers already have DVD and I miss more a fully-featured LiveDVD 5GB spin.

On $SUBJECT don't forget virtualization and .iso files.  I use the ISO
format as a (somewhat inconvenient) way to boot virtual machines, and
probably less than 1 in 10 of those ISOs that I download get burned
onto any physical object.

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 gnomeuser at gmail.com  Sat Jan 31 19:57:02 2009
From: gnomeuser at gmail.com (David Nielsen)
Date: Sat, 31 Jan 2009 20:57:02 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <49848045.7020602@fedoraproject.org>
References: <49848045.7020602@fedoraproject.org>
Message-ID: <1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>

2009/1/31 Frank Murphy <frankly3d at fedoraproject.org>

> What languages, would be good to learn re. Fedora?
> (Have started Java currently, on the curriculum)
>
> What extra(s) would be useful?


If you already know Java, C# is not hard to pick up and more programs are
starting to leverage the .NET framework in Linux these days. With Fedora
comes MonoDevelop which is an excellent easy to approach IDE, it supports
many popular languages but I highly recommend it for working with C#.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/868e03ff/attachment.htm>

From joshuacov at googlemail.com  Sat Jan 31 19:59:26 2009
From: joshuacov at googlemail.com (Joshua C.)
Date: Sat, 31 Jan 2009 20:59:26 +0100
Subject: Reminder: Do not use trademarks in Summary or Description
In-Reply-To: <4984A803.9050808@redhat.com>
References: <49821EF9.4040108@redhat.com> <49835A79.1040801@redhat.com>
	<20090130195751.GL28663@localhost.localdomain>
	<498384C4.4020909@redhat.com>
	<5f6f8c5f0901310136y78ecc7dfpa03e06b472b5d3ab@mail.gmail.com>
	<f6ca9fed0901310331q3b7a87eale871f201db17e72e@mail.gmail.com>
	<5f6f8c5f0901310624j32b3cc29o119c9b153989fd59@mail.gmail.com>
	<49845F8B.50402@redhat.com>
	<5f6f8c5f0901310638g7b21f9bfkf69a8621cb95f3ea@mail.gmail.com>
	<4984A803.9050808@redhat.com>
Message-ID: <5f6f8c5f0901311159h75eee57bm5bab939e2169a4c6@mail.gmail.com>

2009/1/31 Tom spot Callaway <tcallawa at redhat.com>:
> On 2009-01-31 at 9:38:08 -0500, "Joshua C." <joshuacov at googlemail.com>
> wrote:
>> Unfortunately
>> because of the fact that the legal Guardian of the Fedora project is
>> bound by the US laws we should comply with these, too.
>> Maybe Paul W. Frields should take the next step and make the project
>> "completely" independant (this is my personal opinion).
>
> We've been down this road a few times before, but there are serious
> logistical problems. If Fedora was a US non-profit entity, that entity
> would still have to comply with US laws (not to mention the financial
> issues around where the majority of Fedora's funding comes from).
>
> Even if Fedora incorporated as a separate entity in a legal no-mans-land
> (like say, the Isle of Man *cough, cough, cough*), they would be passing
> the risk onto US mirrors and users.
>
> I'm of the opinion that Fedora raises awareness of the issues that
> stifle innovation, both in the US and worldwide. There are options for
> individuals who are not bound by such laws (or who choose to be
> conscientious objectors). By playing by "the rules" we set a foundation
> for being able to document how broken laws are making developers and
> users suffer, and present that material as briefs in cases in In re Bilski:
>
> http://www.groklaw.net/article.php?story=20080409033837121
>
> If you're completely uninterested in trying to fix the system as a
> participant, there are other distributions which don't care about legal
> issues. I'm proud that Fedora does its best to protect not just itself,
> but also its users from legal risk.
>
> ~spot
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

I also like fedora for its innovation and "being on the edge". But
sometimes I think there are too many stiffness because of all these
legal issues. I know this have been discussed several times  (and I
don't want to start a new discussion here) but *maybe* the project
should try to find a way to circumvent the leagl side. I don't mean
non compliance but more projects like rpmfusion. It incorporates the
quality of fedora and is not bound by the *stupidity* of some
lawmakers. I think that copyright is a good think but things like the
DMCA just go *over the bounds*.



From jos at xos.nl  Sat Jan 31 20:09:14 2009
From: jos at xos.nl (Jos Vos)
Date: Sat, 31 Jan 2009 21:09:14 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>
References: <49848045.7020602@fedoraproject.org>
	<1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>
Message-ID: <20090131200914.GC19178@jasmine.xos.nl>

On Sat, Jan 31, 2009 at 08:57:02PM +0100, David Nielsen wrote:

> If you already know Java, C# is not hard to pick up and more programs are
> starting to leverage the .NET framework in Linux these days. With Fedora
> comes MonoDevelop which is an excellent easy to approach IDE, it supports
> many popular languages but I highly recommend it for working with C#.

I think if someone asks for appropriate programming languages for
helping with Fedora, the last advise he should get is looking at C#,
.NET or Java.  The Fedora (and Unix/Linux world) supports these, but
only languages like C/C++/Python/Perl/shell are (and should) used for
the base environment.

Please do not encourage people to use C# or Java for system-level
programs.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From drago01 at gmail.com  Sat Jan 31 20:18:19 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 21:18:19 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <da159fda0901311017r6d1af75cse6e63acc7607afce@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to>
	<f6ca9fed0901310846k70153063x9642bc3fd0712af8@mail.gmail.com>
	<da159fda0901311017r6d1af75cse6e63acc7607afce@mail.gmail.com>
Message-ID: <f6ca9fed0901311218k53c5416cr2a418cf1a2992bbd@mail.gmail.com>

On Sat, Jan 31, 2009 at 7:17 PM, Jon Stanley <jonstanley at gmail.com> wrote:
> On Sat, Jan 31, 2009 at 11:46 AM, drago01 <drago01 at gmail.com> wrote:
>
>> Well the point is not the size of the DVD image itself but having a
>> liveDVD instead of a liveCD (going away from the 700MB size limit)
>
> Keep in mind that the same spin for all arches is produced using the
> same kickstart (i.e. fedora-livecd-desktop.ks). So the technical
> feasibility of keeping a LiveCD for x86 and DVD for x86_64 is nearly
> nil, unless we broke up the kickstarts (which I for one am not in
> favor of).

I am aware of that, but as both need to be tested anyway that should
not be really a blocker.
Instead of just discussion this every 2nd release[1] (same as the boot
time thread [2] that shows up at the beginning of each rawhide cycle),
we should decide whether we[3] want this, and then go on implementing
this.


1: it just feels like this so don't come up with "but there was no
such thread for fedora n"
2: and ends up into a do we need a MTA started by default flamewar
(but that's a different topic)
3: now who is "we" ... FESCO, rel-eng ? Who is app to make this decision ?



From drago01 at gmail.com  Sat Jan 31 20:18:49 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 21:18:49 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <f6ca9fed0901311218k53c5416cr2a418cf1a2992bbd@mail.gmail.com>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to>
	<f6ca9fed0901310846k70153063x9642bc3fd0712af8@mail.gmail.com>
	<da159fda0901311017r6d1af75cse6e63acc7607afce@mail.gmail.com>
	<f6ca9fed0901311218k53c5416cr2a418cf1a2992bbd@mail.gmail.com>
Message-ID: <f6ca9fed0901311218h62f82e3dgede4b2efb91b7538@mail.gmail.com>

On Sat, Jan 31, 2009 at 9:18 PM, drago01 <drago01 at gmail.com> wrote:
> Who is app to make this decision ?
lol should read "up" ;)



From kevin at scrye.com  Sat Jan 31 20:21:15 2009
From: kevin at scrye.com (Kevin Fenzi)
Date: Sat, 31 Jan 2009 13:21:15 -0700
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
Message-ID: <20090131132115.6570018a@ohm.scrye.com>

On Fri, 30 Jan 2009 22:40:45 +0100
Chitlesh GOORAH <chitlesh.goorah at gmail.com> wrote:

> Hello there,
> 
> Before reading the mail, be brave people read this blog post first,
> especially people from FESCo:
> http://www.edn.com/blog/920000692/post/1290038929.html
> 
> Do comment on that blog post. Afterwards you read my email.
> 
> -------------------------------------------------------------
> 
> 
> 
> I found it sad that I have to write this email today. Well, it is part
> of my contribution to both opensource software and opensource EDA
> software communities.
> 
> The subject of this email is "Fedora Project, give me 20 Million Euros
> or Free Software" ! Unfortunately, I'm not kidding and even 20 Million
> Euros is not enough.
> 
> Well, let's get to the point !

... snip ...

First, let me say that I have been impressed and happy with all the
work you have been doing on electronics lab packages. This is a great
area to get folks involved in using and perhaps someday contributing to
Fedora. 

Also, I am happy that OVM is released under a free license. This is
great that an area that is full of closed source solutions now has an
open source content. I hope that this will show how well open source
works to those that might not know anything about it. 

However, allowing this package into Fedora with no way for the vast
majority of Fedora users to use it seems to me to be bad for the
overall user experence. 

On the plus side: users who have access to the non free simulator can
install and use this package and gain all the benifits from doing so. 

On the minus side: user who do not have access to a non free simulator
would possibly install this package, get confused, be unable to run it,
think that Fedora was telling them to go out and buy some commercial
software, etc. 

You mentioned an analogy on IRC: " I have written "Ebook about my car"
that  I want to package for fedora, I have to give the car via yum"

I don't think thats a very close analogy. This case with OVM has no
hardware involved, only software. I think a better one would be: 
Someone comes up with a super new document templating system. It's
released under a free license. OpenOffice says they will support it
sometime, but doesn't currently. It works with Microsoft Office now
however. Should such a package be in Fedora? Wouldn't it cause users to
see it and install it and then realize we are telling them to go buy
MSOffice? 

Now, thinking about it: Are there any other uses for OVM aside from
running it in a non free simulator? Would it somehow be useful for
people to learn from even though they cannot run it? Or is there any
other reasons it would be useful for people who don't have access to
the non free simulator?

> Kind regards,
> Chitlesh

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/f7bc0348/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Jan 31 20:24:59 2009
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 31 Jan 2009 21:24:59 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <20090131200914.GC19178@jasmine.xos.nl>
References: <49848045.7020602@fedoraproject.org>
	<1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>
	<20090131200914.GC19178@jasmine.xos.nl>
Message-ID: <1233433499.27900.7.camel@arekh.okg>

Le samedi 31 janvier 2009 ? 21:09 +0100, Jos Vos a ?crit :
> On Sat, Jan 31, 2009 at 08:57:02PM +0100, David Nielsen wrote:
> 
> > If you already know Java, C# is not hard to pick up and more programs are
> > starting to leverage the .NET framework in Linux these days. With Fedora
> > comes MonoDevelop which is an excellent easy to approach IDE, it supports
> > many popular languages but I highly recommend it for working with C#.
> 
> I think if someone asks for appropriate programming languages for
> helping with Fedora, the last advise he should get is looking at C#,
> .NET or Java.  The Fedora (and Unix/Linux world) supports these, but
> only languages like C/C++/Python/Perl/shell are (and should) used for
> the base environment.
> 
> Please do not encourage people to use C# or Java for system-level
> programs.

For system-level programs no, but for middleware and up Java is a good
choice and we have many Red Hat/Fedora people working hard to make
openjdk work well under Linux. Fedora is more than just low-level system
work.

As for C#/Mono? it has specific adoption problems and it's certainly not
something we should suggest to an innocent beginner.

-- 
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: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/452771c5/attachment.sig>

From kevin.kofler at chello.at  Sat Jan 31 20:34:24 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 21:34:24 +0100
Subject: Too many unowned directories
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<20090131111130.GA23533@amd.home.annexia.org>
	<20090131134347.7bb42020.mschwendt@gmail.com>
	<gm1nut$lkf$6@ger.gmane.org>
	<1233422532.3650.377.camel@localhost.localdomain>
Message-ID: <gm2ckg$l3k$1@ger.gmane.org>

Jesse Keating wrote:
> Right, the question always become "what to do with the
> files/folders/symlinks/whatever inside that directory you want to turn
> into a symlink?"

rm -rf ;-)
Or rename it to .rpmsave or .rpmorig or something.

        Kevin Kofler



From jspaleta at gmail.com  Sat Jan 31 20:35:46 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 31 Jan 2009 11:35:46 -0900
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <498482E7.5030600@nobugconsulting.ro>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
	<498482E7.5030600@nobugconsulting.ro>
Message-ID: <604aa7910901311235v5f38da26y6df4b1ce98f0f0f@mail.gmail.com>

On Sat, Jan 31, 2009 at 7:57 AM, Manuel Wolfshant
<wolfy at nobugconsulting.ro> wrote:
> Chitlesh and I are the only ones who see a flaw in the reasoning above ?

Its not a flaw....

before we could ship a java interpreter in Fedora..we did not package
java based functionality... its the same scenario.

OVM is not setting a precedent, this is a pretty established policy.

If OVM goes in on your reasoning I would be free to package up all the
data visualization scripts written for IDL used widely in my research
area as official fedora packages instead of wasting the time
re-engineering the functionality as python.  Sure the only way to use
them is to purchase the proprietary IDL interpreter which Fedora can
not ship. GDL is not good enough yet to handle IDL's plotting and
graphical widgets.

And I guess the same goes for all the matlab analysis code that is
floating around...even though matlab is proprietary.

You are free to create a package any source or scripted language
material you like, you are free to host that package on hosting you
control. But its not going to be going in to Fedora's repository
unless Fedora can ship the compiler or interpreter to use that code or
script.


-jef



From kevin.kofler at chello.at  Sat Jan 31 20:36:23 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 21:36:23 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to> <gm1v7p$ft2$1@ger.gmane.org>
	<f6ca9fed0901310850i914b7c0r62ad1a5b37c0528b@mail.gmail.com>
Message-ID: <gm2co7$l3k$2@ger.gmane.org>

drago01 wrote:
> File size limit on fat32 is 4GB not 2.

Then try saving a file with more than 2 GB with Window$ Me...

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 31 20:47:57 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 31 Jan 2009 21:47:57 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
References: <49848045.7020602@fedoraproject.org>
	<1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>
Message-ID: <gm2ddt$os8$1@ger.gmane.org>

David Nielsen wrote:
> If you already know Java, C# is not hard to pick up and more programs are
> starting to leverage the .NET framework in Linux these days. With Fedora
> comes MonoDevelop which is an excellent easy to approach IDE, it supports
> many popular languages but I highly recommend it for working with C#.

Do you really have to recommend M$ languages? .NET is a horrible choice for
GNU/Linux programming.

That said, Java isn't that much better... But at least it's not from M$.

        Kevin Kofler



From drago01 at gmail.com  Sat Jan 31 20:48:24 2009
From: drago01 at gmail.com (drago01)
Date: Sat, 31 Jan 2009 21:48:24 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <gm2co7$l3k$2@ger.gmane.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<20090131164352.GA25612@wolff.to> <gm1v7p$ft2$1@ger.gmane.org>
	<f6ca9fed0901310850i914b7c0r62ad1a5b37c0528b@mail.gmail.com>
	<gm2co7$l3k$2@ger.gmane.org>
Message-ID: <f6ca9fed0901311248n4b179a97qf7df35d518db257e@mail.gmail.com>

On Sat, Jan 31, 2009 at 9:36 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
> drago01 wrote:
>> File size limit on fat32 is 4GB not 2.
>
> Then try saving a file with more than 2 GB with Window$ Me...

I never tried that but I did store 3GB+ files on external FAT32
formatted media with both winXP and linux.
A 2GB limit would rather mean that the app you used does not support
LFS (and therefore is limited to 2GB files).
But the filesystem FAT32 has a 4GB filesysize limit ( 4GB - 1 byte to be exact).
"The maximum possible size for a file on a FAT32 volume is 4 GiB minus
1 byte (2^32-1 bytes)" [1]


1: http://en.wikipedia.org/wiki/FAT_32#FAT32



From sundaram at fedoraproject.org  Sat Jan 31 21:02:25 2009
From: sundaram at fedoraproject.org (Rahul Sundaram)
Date: Sun, 01 Feb 2009 02:32:25 +0530
Subject: Moblin 2 and Fedora
In-Reply-To: <20090131110644.1a80ddf5@infradead.org>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>	<49844F3B.6060905@fedoraproject.org>	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
	<20090131110644.1a80ddf5@infradead.org>
Message-ID: <4984BC61.3040908@fedoraproject.org>

Arjan van de Ven wrote:

> 
> If there was a "based on" relationship we would. But it's not nearly so
> simple.

That would depend on what of Moblin came from Fedora and what changes 
Intel made. I wouldn't dismiss the possibility so easily.

Rahul



From jos at xos.nl  Sat Jan 31 21:03:59 2009
From: jos at xos.nl (Jos Vos)
Date: Sat, 31 Jan 2009 22:03:59 +0100
Subject: Maybe OT for this list: Programming languages for Fedora?
In-Reply-To: <1233433499.27900.7.camel@arekh.okg>
References: <49848045.7020602@fedoraproject.org>
	<1dedbbfc0901311157y1cf1186di9bea983462b8f5bb@mail.gmail.com>
	<20090131200914.GC19178@jasmine.xos.nl>
	<1233433499.27900.7.camel@arekh.okg>
Message-ID: <20090131210359.GA21572@jasmine.xos.nl>

On Sat, Jan 31, 2009 at 09:24:59PM +0100, Nicolas Mailhot wrote:

> For system-level programs no, but for middleware and up Java is a good
> choice and we have many Red Hat/Fedora people working hard to make
> openjdk work well under Linux. Fedora is more than just low-level system
> work.

Agreed, but IIRC the context of the original question was more
system-level oriented and not about middleware/application programming.

-- 
--    Jos Vos <jos at xos.nl>
--    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--    Amsterdam, The Netherlands        |     Fax: +31 20 6948204



From wolfy at nobugconsulting.ro  Sat Jan 31 21:42:52 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 31 Jan 2009 23:42:52 +0200
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <da159fda0901311021w56a9814bhf572e3c7ab8d33d3@mail.gmail.com>
References: <20090130121722.7361f7a3@ohm.scrye.com>	<1233377110.8810.4.camel@rosebud>
	<gm1o41$lkf$7@ger.gmane.org>	<49847E8B.2010304@nobugconsulting.ro>
	<da159fda0901311021w56a9814bhf572e3c7ab8d33d3@mail.gmail.com>
Message-ID: <4984C5DC.7010904@nobugconsulting.ro>

On 01/31/2009 08:21 PM, Jon Stanley wrote:
> On Sat, Jan 31, 2009 at 11:38 AM, Manuel Wolfshant
> <wolfy at nobugconsulting.ro> wrote:
>
>   
>> For what it's worth and if anyone is interested [*]: I have compiled all the
>> needed deps and I use yum-3.2.19-18 in FC-7 (please, no flames on EOL ).
>>     
>
> Does this include a newer RPM, since that seems to be where the issue is here?
>
>   
No, as Seth has pointed out, luckily a newer rpm is not needed. The 
issue is to have python-hashlib available for yum. Plus some 
dependencies (urlgrabber for instance).



From wolfy at nobugconsulting.ro  Sat Jan 31 21:58:10 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sat, 31 Jan 2009 23:58:10 +0200
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <20090131132115.6570018a@ohm.scrye.com>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<20090131132115.6570018a@ohm.scrye.com>
Message-ID: <4984C972.7080303@nobugconsulting.ro>

On 01/31/2009 10:21 PM, Kevin Fenzi wrote:
>
> Now, thinking about it: Are there any other uses for OVM aside from
> running it in a non free simulator? Would it somehow be useful for
> people to learn from even though they cannot run it? Or is there any
> other reasons it would be useful for people who don't have access to
> the non free simulator?
>   
Let's put it the other way around: how many people WITHOUT access to a 
commercial simulator would be interested in this package ? What if you 
are in my case, where you have a Fedora server which shares the content 
and dozens of users using Centos + non-free EDA tools ?
As of  "would possibly install this package, get confused, be unable to 
run it" it's easy to solve with a single one liner in %Description: "For 
the moment you will need <add proper application name here> to use it".

This package is interesting for a subset of the people interested in 
EDA. And I am confident that most if not all of those people have access 
to the commercial tools, either via academic licenses or plain 
enterprise licenses. It's a domain where simply put, there exists NO 
free equivalent for the commercial tools. Sad but true. Some bits have 
been touched but there is a very long way to go to reach even 20% of 
what the commercial tools do. And I can tell that as a person who 
has/used to have access to beta releases of Cadence, Synopsys and Mentor 
Graphics tools and has tried to convince fellow colleagues to use free 
tools instead of the commercial ones. As I have already told, the only 
success was using gtkwave IF the licenses for commercial products were 
already occupied by other engineers [*].

[*] Licenses are expensive enough so we cannot afford purchasing the 
number which would allow anyone to run anything anytime. So tasks have 
to be queued or other tools must be used instead when you do not want to 
wait a couple of hours for someone else's simulation to end.

        Manuel



From laubersm at fedoraproject.org  Sat Jan 31 22:01:54 2009
From: laubersm at fedoraproject.org (Susan Lauber)
Date: Sat, 31 Jan 2009 17:01:54 -0500
Subject: PackageMaintainers wiki cleanup update
Message-ID: <e1cf1c3a0901311401q3eca98f5if5558862c45feb0e@mail.gmail.com>

Greetings to the authors/maintainers of Package Maintainer wiki pages,

I  introduced myself last week [1] and since then I have dug into the pages
and set up a task table [2]

I have already added a category to most pages so they can all be found
together [3].
If there are others or if you create a new page just add the string
[[Category:Package Maintainers]] to the bottom of the page.

The next step is renaming so that pages are easier to find in a search.  It
will also make the category page easier to use. I have started making
suggested in the packagemaintainers.psv [4] file in the wikirename.git repo
and

***I encourage others to check the proposed names and offer additional
suggestions.***

I would like to have this file ready for the wikibot by the end of the week
(Feb 7).
Lack of response will be seen as a vote of confidence :)

Thanks,
Susan

[1]
https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01545.html
[2]
https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_materials#Package_Maintainer_pages
[3] https://fedoraproject.org/wiki/Category:Package_Maintainers
[4]
http://git.fedorahosted.org/git/?p=wikirename.git;a=blob_plain;f=packagemaintainers.psv;hb=HEAD

with naming instructions at
https://fedoraproject.org/wiki/Help:Wiki_structure

-- 
Susan Lauber, (RHCX, RHCA, RHCSS)
Lauber System Solutions, Inc.
http://www.laubersolutions.com
gpg: 15AC F794 A3D9 64D1 D9CE  4C26 EFC3 11C2 BFA1 0974
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/54bd6b55/attachment.htm>

From wolfy at nobugconsulting.ro  Sat Jan 31 22:11:29 2009
From: wolfy at nobugconsulting.ro (Manuel Wolfshant)
Date: Sun, 01 Feb 2009 00:11:29 +0200
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <604aa7910901311235v5f38da26y6df4b1ce98f0f0f@mail.gmail.com>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>	<loom.20090130T215554-885@post.gmane.org>	<498482E7.5030600@nobugconsulting.ro>
	<604aa7910901311235v5f38da26y6df4b1ce98f0f0f@mail.gmail.com>
Message-ID: <4984CC91.4030903@nobugconsulting.ro>

On 01/31/2009 10:35 PM, Jeff Spaleta wrote:
>
> And I guess the same goes for all the matlab analysis code that is
> floating around...even though matlab is proprietary.
>   
octave is GPL and we ship it so your reasoning here does not work :)

anyway, I rest my case. I have ovm in my enterprise repo for a month and 
I hope Chitlesh will not be discouraged by this lack of understanding 
from our peers.

    manuel



From jspaleta at gmail.com  Sat Jan 31 22:18:37 2009
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 31 Jan 2009 13:18:37 -0900
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <4984CC91.4030903@nobugconsulting.ro>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<loom.20090130T215554-885@post.gmane.org>
	<498482E7.5030600@nobugconsulting.ro>
	<604aa7910901311235v5f38da26y6df4b1ce98f0f0f@mail.gmail.com>
	<4984CC91.4030903@nobugconsulting.ro>
Message-ID: <604aa7910901311418k540017e6t15b3ab84904d543a@mail.gmail.com>

On Sat, Jan 31, 2009 at 1:11 PM, Manuel Wolfshant
<wolfy at nobugconsulting.ro> wrote:
> octave is GPL and we ship it so your reasoning here does not work :)


gdl is mostly compatible with idl   octave is mostly compatible with
matlab... they are not equivalent  people I maintain linux systems for
write code that won't run with either.  Such is life.

-jef



From galibert at pobox.com  Sat Jan 31 22:26:55 2009
From: galibert at pobox.com (Olivier Galibert)
Date: Sat, 31 Jan 2009 23:26:55 +0100
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131172219.GB7964@yoda.jdub.homelinux.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net>
	<m3bptnik6u.fsf@ursa.amorsen.dk> <gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
Message-ID: <20090131222655.GA84354@dspnet.fr.eu.org>

On Sat, Jan 31, 2009 at 12:22:19PM -0500, Josh Boyer wrote:
> http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:category.details?current-catalog-id=12F0696583E04D86B9B79B0FEC01C087&current-category-id=FB7AF02917DF464B80B47A578BC9DD24
> 
> Note that while a DVD drive is an option, it does not come with one
> by default and it costs $225.00 extra.  It took me 30 seconds to
> find that machine.  I'm sure there are more.

8Gb USB stick, which can hold bootable dvd contents, $15.  Your turn.

  OG.



From mjg at redhat.com  Sat Jan 31 22:36:49 2009
From: mjg at redhat.com (Matthew Garrett)
Date: Sat, 31 Jan 2009 22:36:49 +0000
Subject: look at this: samsung nc10 bootchart with mobil V2
In-Reply-To: <4983BBB4.1000807@redhat.com>
References: <49821FD3.4020801@redhat.com> <1233267250.4952.36.camel@choeger6>
	<4982345A.2030301@redhat.com>
	<20090130035404.GC4570@nostromo.devel.redhat.com>
	<1233288493.3698.67.camel@localhost.localdomain>
	<49827FAF.3050306@redhat.com>
	<20090130150046.GA8869@nostromo.devel.redhat.com>
	<498333E0.3040806@redhat.com>
	<20090131011450.GB24549@srcf.ucam.org>
	<4983BBB4.1000807@redhat.com>
Message-ID: <20090131223648.GA25127@srcf.ucam.org>

On Fri, Jan 30, 2009 at 09:47:16PM -0500, Brian Maly wrote:

> Good info on the Vaio Z-series.  Out of curiosity, is there a UEFI shell/
> console accessible on the Acer One?  Or is this permanently in legacy BIOS
> compatibility mode? Dont know if you actually know or have access to the
> hardware...

Fairly sure that any currently shipping H2O platforms present as legacy 
BIOS at all times.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org



From kevin.kofler at chello.at  Sat Jan 31 23:06:10 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 01 Feb 2009 00:06:10 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<20090131132115.6570018a@ohm.scrye.com>
	<4984C972.7080303@nobugconsulting.ro>
Message-ID: <gm2lh2$npp$1@ger.gmane.org>

Manuel Wolfshant wrote:
> Let's put it the other way around: how many people WITHOUT access to a
> commercial simulator would be interested in this package ? What if you
> are in my case, where you have a Fedora server which shares the content
> and dozens of users using Centos + non-free EDA tools ?

Then why can't you just install the data from the tarball? What does Fedora
have to gain by offering it to you?

> As of  "would possibly install this package, get confused, be unable to
> run it" it's easy to solve with a single one liner in %Description: "For
> the moment you will need <add proper application name here> to use it".

That would be advertising the proprietary application.

> This package is interesting for a subset of the people interested in
> EDA. And I am confident that most if not all of those people have access
> to the commercial tools, either via academic licenses or plain
> enterprise licenses. It's a domain where simply put, there exists NO
> free equivalent for the commercial tools. Sad but true. Some bits have
> been touched but there is a very long way to go to reach even 20% of
> what the commercial tools do. And I can tell that as a person who
> has/used to have access to beta releases of Cadence, Synopsys and Mentor
> Graphics tools and has tried to convince fellow colleagues to use free
> tools instead of the commercial ones. As I have already told, the only
> success was using gtkwave IF the licenses for commercial products were
> already occupied by other engineers [*].

Making it easier to use the proprietary tools is not the way to change that,
quite the opposite.

        Kevin Kofler



From kevin.kofler at chello.at  Sat Jan 31 23:07:42 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 01 Feb 2009 00:07:42 +0100
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>	<loom.20090130T215554-885@post.gmane.org>	<498482E7.5030600@nobugconsulting.ro>
	<604aa7910901311235v5f38da26y6df4b1ce98f0f0f@mail.gmail.com>
	<4984CC91.4030903@nobugconsulting.ro>
Message-ID: <gm2lju$npp$2@ger.gmane.org>

Manuel Wolfshant wrote:
> octave is GPL and we ship it so your reasoning here does not work :)

Unfortunately, several Matlab toolboxes don't work with Octave. Some other
scripts may also need minor tweaking.

        Kevin Kofler



From wes.shull at gmail.com  Sat Jan 31 23:10:25 2009
From: wes.shull at gmail.com (Wes Shull)
Date: Sat, 31 Jan 2009 16:10:25 -0700
Subject: Validity of the CD size limit nowadays [Re:
	Features/ArchitectureSupport - changing what we build for]
In-Reply-To: <20090131222655.GA84354@dspnet.fr.eu.org>
References: <20090130203505.GA24850@nostromo.devel.redhat.com>
	<20090130212955.GE741830@hiwaay.net> <m3bptnik6u.fsf@ursa.amorsen.dk>
	<gm1sdu$6tq$1@ger.gmane.org>
	<20090131160728.GA28571@host0.dyn.jankratochvil.net>
	<f6ca9fed0901310812o4c270664yd484c4d6653adbe5@mail.gmail.com>
	<20090131172219.GB7964@yoda.jdub.homelinux.org>
	<20090131222655.GA84354@dspnet.fr.eu.org>
Message-ID: <d676b7a80901311510y47a69181qd55b313e356a9881@mail.gmail.com>

On Sat, Jan 31, 2009 at 3:26 PM, Olivier Galibert <galibert at pobox.com> wrote:

> 8Gb USB stick, which can hold bootable dvd contents, $15.  Your turn.

So we're leaving the developing world to Ubuntu now?

Not that I necessarily think that's a bad idea; Fedora can't be all
things to all people, and being cutting-edge doesn't always combine so
well with supporting old hardware...

I'm just waiting for a bunch of business-oriented @redhat.com people
to jump in now ;-)

--wes



From vonbrand at inf.utfsm.cl  Sat Jan 31 23:11:07 2009
From: vonbrand at inf.utfsm.cl (Horst H. von Brand)
Date: Sat, 31 Jan 2009 20:11:07 -0300
Subject: Fedora Project, give me 20 Million Euros or Free EDA software
In-Reply-To: <4984C972.7080303@nobugconsulting.ro>
References: <50baabb30901301340l31a116d8o587fdf153c3dea3d@mail.gmail.com>
	<20090131132115.6570018a@ohm.scrye.com>
	<4984C972.7080303@nobugconsulting.ro>
Message-ID: <200901312311.n0VNB7Pm008044@laptop14.inf.utfsm.cl>

Manuel Wolfshant <wolfy at nobugconsulting.ro> wrote:
> On 01/31/2009 10:21 PM, Kevin Fenzi wrote:
> > Now, thinking about it: Are there any other uses for OVM aside from
> > running it in a non free simulator? Would it somehow be useful for
> > people to learn from even though they cannot run it? Or is there any
> > other reasons it would be useful for people who don't have access to
> > the non free simulator?

> Let's put it the other way around: how many people WITHOUT access to a
> commercial simulator would be interested in this package ? What if you
> are in my case, where you have a Fedora server which shares the
> content and dozens of users using Centos + non-free EDA tools ?
> As of  "would possibly install this package, get confused, be unable
> to run it" it's easy to solve with a single one liner in %Description:
> "For the moment you will need <add proper application name here> to
> use it".

And all mirrors have to carry this stuff around, for a tiny minority of
users?  It is much more reasonable to set up your own repo with the stuff
around the non-free tools, whip up a community around it, and go from
there. This is not rocket science. Yes, it does require work on your part,
not just waiting for it to "magically" show up in your nearest Fedora
mirror.
-- 
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 bmaly at redhat.com  Sat Jan 31 23:13:10 2009
From: bmaly at redhat.com (Brian Maly)
Date: Sat, 31 Jan 2009 18:13:10 -0500
Subject: Moblin 2 and Fedora
In-Reply-To: <20090131110644.1a80ddf5@infradead.org>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>	<49844F3B.6060905@fedoraproject.org>	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
	<20090131110644.1a80ddf5@infradead.org>
Message-ID: <4984DB06.2060405@redhat.com>

Arjan van de Ven wrote:
> On Sat, 31 Jan 2009 18:57:42 +0100
> Peter Robinson <pbrobinson at gmail.com> wrote:
>
>   
>>>> Hi All,
>>>>
>>>> I noticed Intel has announced [1] the first alpha of Moblin 2 which
>>>> from memory and by the look of it is based on Fedora [2].
>>>>         
>
> Various parts from Moblin 2 come from Fedora. Other parts come from
> OpenSUSE, and about half is packaged newly based on upstream releases.
> (although some descriptions are borrowed from various sources)
>
>   
>>> Yes but Intel doesn't seem interested in pushing any changes back
>>> to Fedora.
>>>       
>
> If there was a "based on" relationship we would. But it's not nearly so
> simple.
>
>
>   
For anyone interested in the gritty details, there is an article that 
explains the specifics of achieving the fast boot time.  I presume the 
demo in question to be exactly whats discussed in the article.

LPC: Booting Linux in five seconds:
http://lwn.net/Articles/299483/

Brian





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090131/f919fdca/attachment.htm>

From kevin.kofler at chello.at  Sat Jan 31 23:10:15 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 01 Feb 2009 00:10:15 +0100
Subject: fesco meeting summary - 2009-01-30
References: <20090130121722.7361f7a3@ohm.scrye.com>	<1233377110.8810.4.camel@rosebud>
	<gm1o41$lkf$7@ger.gmane.org>	<49847E8B.2010304@nobugconsulting.ro>
	<da159fda0901311021w56a9814bhf572e3c7ab8d33d3@mail.gmail.com>
	<4984C5DC.7010904@nobugconsulting.ro>
Message-ID: <gm2lon$npp$3@ger.gmane.org>

Manuel Wolfshant wrote:
> No, as Seth has pointed out, luckily a newer rpm is not needed. The
> issue is to have python-hashlib available for yum. Plus some
> dependencies (urlgrabber for instance).

That's not what the feature page says. It says an RPM backport would be too
big for F9. I think you're talking about only one part of the feature,
which is SHA256 for metadata. But the plan is to also use it everywhere
inside RPM packages, and that needs support from RPM. Config files in RPM
use MD5 to check for modification. Signatures are done on MD5 hashes. Etc.
All this is to be replaced with SHA256, which needs RPM 4.6.

        Kevin Kofler



From arjan at infradead.org  Sat Jan 31 23:34:57 2009
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 31 Jan 2009 15:34:57 -0800
Subject: Moblin 2 and Fedora
In-Reply-To: <4984BC61.3040908@fedoraproject.org>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
	<49844F3B.6060905@fedoraproject.org>
	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
	<20090131110644.1a80ddf5@infradead.org>
	<4984BC61.3040908@fedoraproject.org>
Message-ID: <20090131153457.573762ab@infradead.org>

On Sun, 01 Feb 2009 02:32:25 +0530
Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Arjan van de Ven wrote:
> 
> > 
> > If there was a "based on" relationship we would. But it's not
> > nearly so simple.
> 
> That would depend on what of Moblin came from Fedora and what changes 
> Intel made. I wouldn't dismiss the possibility so easily.

I don't dismiss anything beforehand, and am quite open to discuss just
about anything.

But frankly, if I look at where things are today in Moblin and where
they are going; the packages we borrowed from Fedora tend to be those
where we don't do much if any changes. 
If there's something specific that the Fedora project wants to get from
Moblin we should discuss that, but lets be specific there rather than
having a discussion on the blanket hand-wavey level...



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org



From christoph.wickert at googlemail.com  Sat Jan 31 23:40:59 2009
From: christoph.wickert at googlemail.com (Christoph Wickert)
Date: Sun, 01 Feb 2009 00:40:59 +0100
Subject: Too many unowned directories
In-Reply-To: <49845CD2.6080902@iinet.net.au>
References: <20090130200118.dcf06aa3.mschwendt@gmail.com>
	<faa16b610901301148q66deafc6uef9cd76bc44c7f05@mail.gmail.com>
	<20090130211536.b7aa63d9.mschwendt@gmail.com>
	<alpine.LFD.2.00.0901302228250.27679@turre.koti.laiskiainen.org>
	<1233350530.3650.28.camel@localhost.localdomain>
	<1233350803.3345.18.camel@localhost.localdomain>
	<1233350796.3650.29.camel@localhost.localdomain>
	<49845CD2.6080902@iinet.net.au>
Message-ID: <1233445259.3705.2.camel@wicktop.localdomain>

Am Sonntag, den 01.02.2009, 01:14 +1100 schrieb David Timms:

> BTW, is it generally config dirs where the unowned dirs are found ?

No, most of the time something in %{_usr} or %{_libdir}. And from what
I've seen so far, most of the time the unowned dirs reveal other serious
problems with the packages in question.

Regards,
Christoph



From freeslkr.wl6x at mailnull.com  Sat Jan 31 22:45:55 2009
From: freeslkr.wl6x at mailnull.com (freeslkr)
Date: Sat, 31 Jan 2009 22:45:55 +0000 (UTC)
Subject: Problem with updates?
Message-ID: <loom.20090131T224402-516@post.gmane.org>

Does anyone here know why updates announced a couple of days ago,
including security updates, haven't shown up in the repos?



From kevin.kofler at chello.at  Sat Jan 31 23:47:44 2009
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sun, 01 Feb 2009 00:47:44 +0100
Subject: Moblin 2 and Fedora
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
	<49844F3B.6060905@fedoraproject.org>
	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
	<20090131110644.1a80ddf5@infradead.org>
	<4984BC61.3040908@fedoraproject.org>
	<20090131153457.573762ab@infradead.org>
Message-ID: <gm2nv0$u95$1@ger.gmane.org>

Arjan van de Ven wrote:
> If there's something specific that the Fedora project wants to get from
> Moblin we should discuss that, but lets be specific there rather than
> having a discussion on the blanket hand-wavey level...

How about a working version of the Poulsbo video driver?

See Adam Williamson's rant:
http://www.happyassassin.net/2009/01/30/intel-gma-500-poulsbo-graphics-on-linux-a-precise-and-comprehensive-summary-as-to-why-youre-screwed/

        Kevin Kofler



From skvidal at fedoraproject.org  Sat Jan 31 23:55:44 2009
From: skvidal at fedoraproject.org (seth vidal)
Date: Sat, 31 Jan 2009 18:55:44 -0500
Subject: fesco meeting summary - 2009-01-30
In-Reply-To: <gm2lon$npp$3@ger.gmane.org>
References: <20090130121722.7361f7a3@ohm.scrye.com>
	<1233377110.8810.4.camel@rosebud> <gm1o41$lkf$7@ger.gmane.org>
	<49847E8B.2010304@nobugconsulting.ro>
	<da159fda0901311021w56a9814bhf572e3c7ab8d33d3@mail.gmail.com>
	<4984C5DC.7010904@nobugconsulting.ro>  <gm2lon$npp$3@ger.gmane.org>
Message-ID: <1233446144.8810.10.camel@rosebud>

On Sun, 2009-02-01 at 00:10 +0100, Kevin Kofler wrote:
> Manuel Wolfshant wrote:
> > No, as Seth has pointed out, luckily a newer rpm is not needed. The
> > issue is to have python-hashlib available for yum. Plus some
> > dependencies (urlgrabber for instance).
> 
> That's not what the feature page says. It says an RPM backport would be too
> big for F9. I think you're talking about only one part of the feature,
> which is SHA256 for metadata. But the plan is to also use it everywhere
> inside RPM packages, and that needs support from RPM. Config files in RPM
> use MD5 to check for modification. Signatures are done on MD5 hashes. Etc.
> All this is to be replaced with SHA256, which needs RPM 4.6.
> 

To use preupgrade I don't think that's as strict a requirement.

preupgrade does what it does by using yum and it's metadata to figure
out what to download. It sets up a repo for anaconda and then sets up
your system to boot into the installer.

Now, preupgrade does do a test transaction, to look for hang ups to
doing the install. That would be the one place where it might get cranky
about the lack of sha256 support in rpm.


-sv




From arjan at infradead.org  Sat Jan 31 23:58:03 2009
From: arjan at infradead.org (Arjan van de Ven)
Date: Sat, 31 Jan 2009 15:58:03 -0800
Subject: Moblin 2 and Fedora
In-Reply-To: <gm2nv0$u95$1@ger.gmane.org>
References: <5256d0b0901271816j7c8d73a5w695c774ecbfeef53@mail.gmail.com>
	<49844F3B.6060905@fedoraproject.org>
	<5256d0b0901310957g2cb373a0qba4a3082e362c10f@mail.gmail.com>
	<20090131110644.1a80ddf5@infradead.org>
	<4984BC61.3040908@fedoraproject.org>
	<20090131153457.573762ab@infradead.org>
	<gm2nv0$u95$1@ger.gmane.org>
Message-ID: <20090131155803.4fb1444f@infradead.org>

On Sun, 01 Feb 2009 00:47:44 +0100
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Arjan van de Ven wrote:
> > If there's something specific that the Fedora project wants to get
> > from Moblin we should discuss that, but lets be specific there
> > rather than having a discussion on the blanket hand-wavey level...
> 
> How about a working version of the Poulsbo video driver?

we currently do not have one, as our release notes mention.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org