From dax at gurulabs.com  Tue Nov  1 08:24:18 2005
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 01 Nov 2005 01:24:18 -0700
Subject: Problems installing rawhide and reporting thereof
In-Reply-To: <1130311443.3223.7.camel@mentorng.gurulabs.com>
References: <1130311443.3223.7.camel@mentorng.gurulabs.com>
Message-ID: <1130833458.3512.32.camel@mentorng.gurulabs.com>

On Wed, 2005-10-26 at 01:24 -0600, Dax Kelson wrote:
> I understand the guts of Anaconda are changing to use yum and that it is
> being actively worked on. Given that, are bug reports useful/wanted?
> 
> I tried installing Oct 25th rawhide on my Thinkpad T42p using the
> images/boot.iso and a NFS shared rawhide tree.
> 
> I noticed two problems:
> 
> 1. X failed to start (all three attempts) with the following error in
> the various X.log files:

> 2. Skipping X and trying either a VNC or text mode install quickly
> resulted in failure with a python traceback in yum code, I think it was
> the "MDrepo" class or something close to that.

Last night I installed rawhide on my laptop with no issues. I can
confirm that both of these are now fixed.

Dax Kelson
Guru Labs



From kyrre at solution-forge.net  Tue Nov  1 09:17:20 2005
From: kyrre at solution-forge.net (Kyrre Ness Sjobak)
Date: Tue, 01 Nov 2005 10:17:20 +0100
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <1130796189.3690.3.camel@coyote.rexursive.com>
References: <1130796189.3690.3.camel@coyote.rexursive.com>
Message-ID: <1130836640.4070.4.camel@localhost.localdomain>

man, 31.10.2005 kl. 23.03 skrev Bojan Smojver:
> Although I normally patch with suspend2, just wanted to try the status
> of suspend to disk in the regular FC5 kernels. The notebook (HP-ZE4201)
> wouldn't suspend at all. This is what I have in dmesg:
> 
> -----------------------------------
> Stopping tasks:
> ================================================================
> ================
>  stopping tasks failed (1 tasks remaining)
> Restarting tasks...<6> Strange, kauditd not stopped
>  done
> -----------------------------------
> 
> In some previous kernels it used to suspend and then crash on resume.

Try an ACPI suspend (echo "mem" > /sys/power/state), and see if you get
the same error. I did (on a Dell Lattitude C600) a couple of weeks back.
(rawhide)

Kyrre



From buildsys at redhat.com  Tue Nov  1 12:23:56 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 1 Nov 2005 07:23:56 -0500
Subject: rawhide report: 20051101 changes
Message-ID: <200511011223.jA1CNuCo023876@porkchop.devel.redhat.com>

New package perl-Net-IP
	Perl module for manipulation of IPv4 and IPv6 addresses


 
Updated Packages:

avahi-0.5.2-6
-------------
* Mon Oct 31 2005 Jason Vas Dias<jvdias at redhat.com> - 0.5.2-6
- put back avahi-devel Obsoletes: howl-devel

* Mon Oct 31 2005 Alexander Larsson <alexl at redhat.com> - 0.5.2-5
- Obsoletes howl, howl-libs, as we want to get rid of them on updates
- No provides yet, as the howl compat library is in Avahi 0.6.0.

cairo-1.0.2-3
-------------
* Mon Oct 31 2005 Matthias Clasen <mclasen at redhat.com> 1.0.2-3
- Require libXrender-devel instead of xorg-X11-devel

* Tue Oct 11 2005 Kristian H??gsberg <krh at redhat.com> 1.0.2-2
- Rebuild against freetype-2.10 to pick up FT_GlyphSlot_Embolden.

* Thu Oct 06 2005 Kristian H??gsberg <krh at redhat.com> - 1.0.2-1
- Update to cairo-1.0.2.

checkpolicy-1.27.17-3
---------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-3
- Rebuild to get latest libsepol

* Fri Oct 28 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-2
- Rebuild to get latest libsepol

* Tue Oct 25 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-1
- Latest upgrade from NSA
	* Merged dismod fix from Joshua Brindle.

elfutils-0.116-1
----------------
* Mon Oct 31 2005 Roland McGrath <roland at redhat.com> - 0.116-1
- update to 0.116
  - libdw fixes, API changes and additions
  - libdwfl fixes (#169672)
  - eu-strip/libelf fix to preserve setuid/setgid permission bits (#167745)

* Fri Sep 09 2005 Roland McGrath <roland at redhat.com> - 0.115-3
- Update requires/conflicts for better biarch update behavior.

* Mon Sep 05 2005 Roland McGrath <roland at redhat.com> - 0.115-2
- update to 0.115
  - New program eu-strings.
  - libdw: New function dwarf_getscopes_die.
  - libelf: speed-ups of non-mmap reading.
  - Implement --enable-gcov option for configure.

fontconfig-2.3.91.cvs20051031-1
-------------------------------
* Mon Oct 31 2005 Matthias Clasen <mclasen at redhat.com> - 2.3.91.cvs20051031-1
- Update to a newer cvs snapshot
- Add a patch which should help to understand broken cache problems

* Fri Oct 21 2005 Matthias Clasen <mclasen at redhat.com> - 2.3.91.cvs20051017-2
- Add new Chinese fonts
- Fix the 40-blacklist-fonts.conf file to use the documented
  fonts.conf syntax, and exclude the Hershey fonts by family
  name.

gnome-games-1:2.12.1-2
----------------------
* Mon Oct 31 2005 Ray Strode <rstrode at redhat.com> 1:2.12.1-2
- remove howl dependency
- modernize make install lines

gnome-session-2.12.0-2
----------------------
* Mon Oct 31 2005 Ray Strode <rstrode at redhat.com> - 2.12.0-2
- remove rhn applet from default session
- s/magicdev/gnome-volume-manager/

gnome-vfs2-2.12.1.1-4
---------------------
* Tue Nov 01 2005 Alexander Larsson <alexl at redhat.com> 2.12.1.1-4
- Remove XFree86-devel buildreq, as it doesn't exist anymore.
  I don't think we actually require it.

gnomemeeting-1.2.2-3
--------------------
* Mon Oct 31 2005 Alexander Larsson <alexl at redhat.com> 1.2.2-3
- Disable howl for now, as we're moving to avahi
- When we upgrade to gnomemeeting 2.0 we'll get avahi support

iproute-2.6.14-7
----------------
* Mon Oct 31 2005 Radek Vokal <rvokal at redhat.com> 2.6.14-7
- add warning to ip tunnel add command (#128107)

jpilot-0.99.8-1
---------------
* Mon Oct 31 2005 Ivana Varekova <varekova at redhat.com> 0.99.8-1
- update to 0.99.8

* Tue Aug 16 2005 Warren Togami <wtogami at redhat.com> 0.99.8-0.pre10.2
- rebuild for new cairo

* Thu Aug 11 2005 Ivana Varekova <varekova at redhat.com> 0.99.8-0.pre10.1
- new upstream version (0.99.8-pre10)

libcap-1.10-23
--------------
* Mon Oct 31 2005 Steve Grubb <sgrubb at redhat.com> 1.10-23
- rebuild to pick up audit capabilities

libselinux-1.27.17-2
--------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-2
- Rebuild for latest libsepol

libsemanage-1.3.39-1
--------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.3.39-1
- Upgrade to latest from NSA
	* Merged record interface, dbase flush, common database code,
	  and record bugfix patches from Ivan Gyurdiev.

libsepol-1.9.34-1
-----------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.9.34-1
- Upgrade to latest from NSA
	* Merged record interface, record bugfix, and set_roles patches 
	  from Ivan Gyurdiev.

man-1.5p-7
----------
* Mon Oct 31 2005 Ivana Varekova <varekova at redhat.com> 1.5p-7
- add ?x sections to MANSECT variable (bug 172002)

* Tue May 17 2005 Ivana Varekova <varekova at redhat.com> 1.5p-6
- change patch 18 (less hard solution) and 
  patch 13 (don't change exit number in one case)

* Wed Apr 13 2005 Ivana Varekova <varekova at redhat.com> 1.5p-5
- fix bug 146849 - makewhatis from cron produce error message
  "zcat: stdout: Broken pipe" (patch 18)
- fix makewhatis problem with sections (patch 19)
- delete strips

nautilus-2.12.1-6
-----------------
* Tue Nov 01 2005 Alexander Larsson <alexl at redhat.com> - 2.12.1-6
- Switch XFree86-devel buildrequirement to libX11-devel

ntp-4.2.0.a.20050816-3
----------------------
* Mon Oct 31 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-3
- A similar patch as ntp-4.0.99j-vsnprintf.patch in FEDORA CORE 4
- (current patch is ntp-stable-4.2.0a-20050816-vsnprintf.patch)

openh323-1.15.6-2
-----------------
* Tue Nov 01 2005 Alexander Larsson <alexl at redhat.com> - 1.15.6-2
- Kill Buildrequire of XFree86-devel. Should not be needed.

pango-1.10.1-4
--------------
* Mon Oct 31 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.1-4
- Switch buildrequires to modular X.
- Don't install .la files for modules.

* Thu Oct 27 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.1-2
- Bump the requirement for glib (#165928)

perl-Net-DNS-0.53-1.fc5
-----------------------
* Sun Oct 30 2005 Warren Togami <wtogami at redhat.com> - 0.53-1
- 0.53 buildreq perl-Net-IP

quota-1:3.13-1
--------------
* Mon Oct 31 2005 Steve Dickson <steved at redhat.com> 3.13-1
- Upgraded to version 3.13 (bz# 171245)

rhgb-0.16.2-9
-------------
* Mon Oct 31 2005 Ray Strode <rstrode at redhat.com> 0.16.2-9
- add BuildRequires: gettext
- don't build in-tree copy of gtkexpander.c
- don't switch to vt1 automatically after 35 seconds (bug 135783)

* Wed Oct 26 2005 Ray Strode <rstrode at redhat.com> 0.16.2-8
- clumens, zombie-hunter, spotted another one of the 
  brain eaters

ruby-1.8.4-0.2.preview1
-----------------------
* Tue Nov 01 2005 Akira TAGOH <tagoh at redhat.com> - 1.8.4-0.2.preview1
- build-deps libX11-devel instead of xorg-x11-devel.

scim-1.4.2-6
------------
* Tue Nov 01 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-6
- avoid errors with postun script when uninstalling

* Thu Oct 06 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-5
- fixing quoting in scim-restart
- make post and postun scripts for scim-libs

* Thu Sep 22 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-4
- make scim-devel require scim-libs
- add xinput.d entries for Indic langs

selinux-policy-mls-1.27.2-11
----------------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-11
- Fix spamc and postfix

* Fri Oct 28 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-10
- Fix file_context

selinux-policy-strict-1.27.2-11
-------------------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-11
- Fix spamc and postfix

selinux-policy-targeted-1.27.2-11
---------------------------------
* Mon Oct 31 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-11
- Fix spamc and postfix

systemtap-0.4.2-2
-----------------
* Mon Oct 31 2005 Roland McGrath <roland at redhat.com> - 0.4.2-2
- Rebuilt for devel

* Mon Oct 31 2005 Roland McGrath <roland at redhat.com> - 0.4.2-1
- Many fixes and improvements: PRs 1344, 1260, 1330, 1295, 1311, 1368,
  1182, 1131, 1332, 1366, 1456, 1271, 1338, 1482, 1477, 1194.

* Wed Sep 14 2005 Roland McGrath <roland at redhat.com> - 0.4.1-1
- Many fixes and improvements since 0.2.2; relevant PRs include:
  1122, 1134, 1155, 1172, 1174, 1175, 1180, 1186, 1187, 1191, 1193, 1195,
  1197, 1205, 1206, 1209, 1213, 1244, 1257, 1258, 1260, 1265, 1268, 1270,
  1289, 1292, 1306, 1335, 1257

tetex-3.0-7
-----------
* Mon Oct 31 2005 Jindrich Novy <jnovy at redhat.com> 3.0-7
- remove preview-latex files as they are incomplete and without
  documentation, preview-latex is now part of AUCTeX (#168859)
- fix xdvi -> navigation with a spacebar does not keep position (#168124)

tog-pegasus-2:2.5-2
-------------------
* Mon Oct 31 2005 Jason Vas Dias <jvdias at redhat.com>
- Add /usr/lib/cmpi alternate providerLibDir for sblim-cmpi-base Fedora Extras pkg
- Fix bug 171124: use numeric ids for pegasus user/group
- guidelines: do not remove pegasus user/group in %postun.
xorg-x11-6.8.2-58
-----------------
* Fri Oct 28 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-58
- Remove virtual provide "XFree86-devel" backward compatibility.  All
  packages that depended on this should now be updated to use the modular
  X library virtual provides included in build -56 and later.

Broken deps for ppc64
----------------------------------------------------------
	ImageMagick-devel - 6.2.2.0-4.ppc64 requires XFree86-devel
	startup-notification-devel - 0.8-2.ppc64 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.ppc64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ppc64 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	gnomemeeting - 1.2.2-3.ppc64 requires howl >= 0:0.9.7
	pango - 1.10.1-4.ppc64 requires libX11
	pango - 1.10.1-4.ppc64 requires libXft
	pango - 1.10.1-4.ppc64 requires libXext
	pango - 1.10.1-4.ppc64 requires libXrender
	gtk2-devel - 2.8.6-3.ppc64 requires XFree86-devel



Broken deps for ia64
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	startup-notification-devel - 0.8-2.ia64 requires XFree86-devel
	pango - 1.10.1-4.ia64 requires libX11
	pango - 1.10.1-4.ia64 requires libXft
	pango - 1.10.1-4.ia64 requires libXext
	pango - 1.10.1-4.ia64 requires libXrender
	ImageMagick-devel - 6.2.2.0-4.ia64 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.ia64 requires XFree86-devel
	gtk2-devel - 2.8.6-3.ia64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ia64 requires XFree86-devel
	gnomemeeting - 1.2.2-3.ia64 requires howl >= 0:0.9.7



Broken deps for x86_64
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.x86_64 requires XFree86-devel
	pango - 1.10.1-4.x86_64 requires libX11
	pango - 1.10.1-4.x86_64 requires libXft
	pango - 1.10.1-4.x86_64 requires libXext
	pango - 1.10.1-4.x86_64 requires libXrender
	gtk2-devel - 2.8.6-3.x86_64 requires XFree86-devel
	gnome-games - 1:2.12.1-2.x86_64 requires libhowl.so.0()(64bit)
	pango - 1.10.1-4.i386 requires libXft
	pango - 1.10.1-4.i386 requires libX11
	pango - 1.10.1-4.i386 requires libXext
	pango - 1.10.1-4.i386 requires libXrender
	ImageMagick-devel - 6.2.2.0-4.x86_64 requires XFree86-devel
	gnomemeeting - 1.2.2-3.x86_64 requires howl >= 0:0.9.7
	startup-notification-devel - 0.8-2.x86_64 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.x86_64 requires XFree86-devel



Broken deps for i386
----------------------------------------------------------
	ImageMagick-devel - 6.2.2.0-4.i386 requires XFree86-devel
	gnome-games - 1:2.12.1-2.i386 requires libhowl.so.0
	startup-notification-devel - 0.8-2.i386 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	pango - 1.10.1-4.i386 requires libXft
	pango - 1.10.1-4.i386 requires libX11
	pango - 1.10.1-4.i386 requires libXext
	pango - 1.10.1-4.i386 requires libXrender
	gtk2-devel - 2.8.6-3.i386 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.i386 requires XFree86-devel
	gnomemeeting - 1.2.2-3.i386 requires howl >= 0:0.9.7
	imlib-devel - 1:1.9.13-24.i386 requires XFree86-devel



Broken deps for ppc
----------------------------------------------------------
	ImageMagick-devel - 6.2.2.0-4.ppc requires XFree86-devel
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ppc requires XFree86-devel
	startup-notification-devel - 0.8-2.ppc requires XFree86-devel
	pango - 1.10.1-4.ppc requires libXft
	pango - 1.10.1-4.ppc requires libX11
	pango - 1.10.1-4.ppc requires libXext
	pango - 1.10.1-4.ppc requires libXrender
	gtk2-devel - 2.8.6-3.ppc requires XFree86-devel
	gnomemeeting - 1.2.2-3.ppc requires howl >= 0:0.9.7
	gtk+-devel - 1:1.2.10-39.ppc requires XFree86-devel



Broken deps for s390
----------------------------------------------------------
	gtk2-devel - 2.8.6-3.s390 requires XFree86-devel
	pango - 1.10.1-4.s390 requires libXft
	pango - 1.10.1-4.s390 requires libX11
	pango - 1.10.1-4.s390 requires libXext
	pango - 1.10.1-4.s390 requires libXrender
	gnomemeeting - 1.2.2-3.s390 requires howl >= 0:0.9.7
	startup-notification-devel - 0.8-2.s390 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.s390 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.s390 requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.s390 requires XFree86-devel



Broken deps for s390x
----------------------------------------------------------
	gnomemeeting - 1.2.2-3.s390x requires howl >= 0:0.9.7
	imlib-devel - 1:1.9.13-24.s390x requires XFree86-devel
	gtk2-devel - 2.8.6-3.s390x requires XFree86-devel
	pango - 1.10.1-4.s390 requires libXft
	pango - 1.10.1-4.s390 requires libX11
	pango - 1.10.1-4.s390 requires libXext
	pango - 1.10.1-4.s390 requires libXrender
	ImageMagick-devel - 6.2.2.0-4.s390x requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.s390x requires XFree86-devel
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel
	pango - 1.10.1-4.s390x requires libXft
	pango - 1.10.1-4.s390x requires libX11
	pango - 1.10.1-4.s390x requires libXext
	pango - 1.10.1-4.s390x requires libXrender
	startup-notification-devel - 0.8-2.s390x requires XFree86-devel





From paul at city-fan.org  Tue Nov  1 12:38:51 2005
From: paul at city-fan.org (Paul Howarth)
Date: Tue, 01 Nov 2005 12:38:51 +0000
Subject: rawhide report: 20051101 changes
In-Reply-To: <200511011223.jA1CNuCo023876@porkchop.devel.redhat.com>
References: <200511011223.jA1CNuCo023876@porkchop.devel.redhat.com>
Message-ID: <436761DB.4060107@city-fan.org>

Build System wrote:
> New package perl-Net-IP
> 	Perl module for manipulation of IPv4 and IPv6 addresses

Is there going to be an "official" procedure for moving packages from 
Extras to Core like this, covering things like whether or not the 
package is removed from the "devel" branch of Extras, notification to 
the original Extras package owner etc.?

Paul.



From sundaram at redhat.com  Tue Nov  1 12:52:03 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 01 Nov 2005 18:22:03 +0530
Subject: rawhide report: 20051101 changes
In-Reply-To: <436761DB.4060107@city-fan.org>
References: <200511011223.jA1CNuCo023876@porkchop.devel.redhat.com>
	<436761DB.4060107@city-fan.org>
Message-ID: <436764F3.60602@redhat.com>

Paul Howarth wrote:

> Build System wrote:
>
>> New package perl-Net-IP
>>     Perl module for manipulation of IPv4 and IPv6 addresses
>
>
> Is there going to be an "official" procedure for moving packages from 
> Extras to Core like this, covering things like whether or not the 
> package is removed from the "devel" branch of Extras, notification to 
> the original Extras package owner etc.?
>
> Paul.
>
Good point. We need a documented procedure for that

regards
Rahul



From johnp at redhat.com  Tue Nov  1 20:05:16 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 01 Nov 2005 15:05:16 -0500
Subject: Needed dependency for all packages that require the D-Bus session
	bus
Message-ID: <1130875516.16531.65.camel@remedyz.boston.redhat.com>

All packages that require the use of the D-Bus session must add a
requirement on dbus-x11.  This package brings in the dbus-launch utility
that starts the session bus.  Without it the session bus does not get
started.   It hasn't been a problem for most because comps brings in
desktop-printing which has a requirement on dbus-x11.  For those who do
not have this installed (nothing depends on desktop-printing so the
situation can come up) will not get the dbus-x11 package and any
application using the session bus will not be able to function at their
full capacity.  Thank you.

-- 
John (J5) Palmieri <johnp at redhat.com>



From ivazquez at ivazquez.net  Tue Nov  1 20:13:38 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 01 Nov 2005 15:13:38 -0500
Subject: Needed dependency for all packages that require the D-Bus
	session bus
In-Reply-To: <1130875516.16531.65.camel@remedyz.boston.redhat.com>
References: <1130875516.16531.65.camel@remedyz.boston.redhat.com>
Message-ID: <1130876018.645.1.camel@ignacio.lan>

On Tue, 2005-11-01 at 15:05 -0500, John (J5) Palmieri wrote:
> All packages that require the use of the D-Bus session must add a
> requirement on dbus-x11.  This package brings in the dbus-launch utility
> that starts the session bus.  Without it the session bus does not get
> started.   It hasn't been a problem for most because comps brings in
> desktop-printing which has a requirement on dbus-x11.  For those who do
> not have this installed (nothing depends on desktop-printing so the
> situation can come up) will not get the dbus-x11 package and any
> application using the session bus will not be able to function at their
> full capacity.  Thank you.

Which package is it that actually invokes dbus-launch? Shouldn't that
package Require it instead?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051101/9191d178/attachment.sig>

From johnp at redhat.com  Tue Nov  1 20:29:22 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 01 Nov 2005 15:29:22 -0500
Subject: Needed dependency for all packages that require the D-Bus
	session bus
In-Reply-To: <1130876018.645.1.camel@ignacio.lan>
References: <1130875516.16531.65.camel@remedyz.boston.redhat.com>
	<1130876018.645.1.camel@ignacio.lan>
Message-ID: <1130876962.16531.68.camel@remedyz.boston.redhat.com>

On Tue, 2005-11-01 at 15:13 -0500, Ignacio Vazquez-Abrams wrote:
> On Tue, 2005-11-01 at 15:05 -0500, John (J5) Palmieri wrote:
> > All packages that require the use of the D-Bus session must add a
> > requirement on dbus-x11.  This package brings in the dbus-launch utility
> > that starts the session bus.  Without it the session bus does not get
> > started.   It hasn't been a problem for most because comps brings in
> > desktop-printing which has a requirement on dbus-x11.  For those who do
> > not have this installed (nothing depends on desktop-printing so the
> > situation can come up) will not get the dbus-x11 package and any
> > application using the session bus will not be able to function at their
> > full capacity.  Thank you.
> 
> Which package is it that actually invokes dbus-launch? Shouldn't that
> package Require it instead?

xinitrc and no because it has logic to say if the dbus-launch binary
does not exist don't run it.

> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
-- 
John (J5) Palmieri <johnp at redhat.com>



From bojan at rexursive.com  Tue Nov  1 22:38:13 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 02 Nov 2005 09:38:13 +1100
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <1130836640.4070.4.camel@localhost.localdomain>
References: <1130796189.3690.3.camel@coyote.rexursive.com>
	<1130836640.4070.4.camel@localhost.localdomain>
Message-ID: <20051102093813.jd70kxa7xko8g8cw@imp.rexursive.com>

Quoting Kyrre Ness Sjobak <kyrre at solution-forge.net>:

> Try an ACPI suspend (echo "mem" > /sys/power/state), and see if you get
> the same error. I did (on a Dell Lattitude C600) a couple of weeks back.
> (rawhide)

Normally suspend to RAM leaves my notebook without vidio on reboot or it
causes it to hang. I was more interested in the state of suspend to
disk, actually.

-- 
Bojan



From tmus at tmus.dk  Wed Nov  2 09:49:04 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Wed, 02 Nov 2005 10:49:04 +0100
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <1130796189.3690.3.camel@coyote.rexursive.com>
References: <1130796189.3690.3.camel@coyote.rexursive.com>
Message-ID: <dka22g$o04$1@sea.gmane.org>

Bojan Smojver wrote:
> Although I normally patch with suspend2, just wanted to try the status
> of suspend to disk in the regular FC5 kernels. The notebook (HP-ZE4201)
> wouldn't suspend at all. This is what I have in dmesg:
> 
> -----------------------------------
> Stopping tasks:
> ================================================================
> ================
>  stopping tasks failed (1 tasks remaining)
> Restarting tasks...<6> Strange, kauditd not stopped
>  done
> -----------------------------------
> 
> In some previous kernels it used to suspend and then crash on resume.
> 

Same thing for suspend to mem in FC4 updates-testing kernel 2.6.14-1633_FC4

Did anyone see/file a bug on this? I can't seem to find any and we'd 
probably like something like this to be fixed!

/Thomas



From buildsys at redhat.com  Wed Nov  2 12:50:48 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 2 Nov 2005 07:50:48 -0500
Subject: rawhide report: 20051102 changes
Message-ID: <200511021250.jA2Com8T016242@porkchop.devel.redhat.com>

 

 
Updated Packages:

ant-0:1.6.5-2fc
---------------
* Tue Nov 01 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:1.6.5-2fc
- Removed .jar files from upstream source

* Mon Oct 31 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:1.6.5-1fc
- Upgraded to 1.6.5
- Removed apache-ant-1.6.2.patch.  It was no longer relevant due to the
  following change upstream:
  src/main/org/apache/tools/ant/taskdefs/compilers/DefaultCompilerAdapter.java,v1.41.2.8
- Updated apache-ant-1.6.2-rpm.patch to apache-ant-1.6.5-rpm.patch
- Replaced apache-ant-bz157750.patch with apache-ant-1.6.5-javah.patch
- Converted this spec file from iso-8859-1 to utf-8. (#159586)

* Wed Aug 03 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_14fc
- Allow subpackages not in Fedora to be installed from JPackage.
- Obsolete the jmf subpackage (#164389).

eclipse-1:3.1.1-1jpp_4fc
------------------------
* Tue Nov 01 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_4fc
- Temporarily exclude ia64 and ppc64 (rh#172174).

* Mon Oct 31 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_4fc
- Bump mozilla requirement.
- Use libXtst-devel instead of xorg-x11-devel.

* Thu Oct 27 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_4fc
- Really fix browser issue on x86_64 (rh#168040).
- Attempt to build on ia64 and ppc64 (include swt-mozilla on the latter).
- Add BuildRequires for libgnome{,ui}-devel (rh#171532).

ethereal-0.10.13-2
------------------
* Wed Nov 02 2005 Radek Vokal <rvokal at redhat.com> 0.10.13-2
- rebuilt against new net-snmp-5.2.2
- depedency fix

gnome-games-1:2.12.1-3
----------------------
* Mon Oct 31 2005 Ray Strode <rstrode at redhat.com> 1:2.12.1-3
- rebuild

gnome-panel-2.12.1-4
--------------------
* Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> 2.12.1-4
- rename "Desktop" menu to "System" menu (bug 170812)

gnomemeeting-1.2.2-4
--------------------
* Tue Nov 01 2005 Alexander Larsson <alexl at redhat.com> 1.2.2-4
- Actually remove howl requirements too

krb5-auth-dialog-0.4-1
----------------------
* Tue Nov 01 2005 Christopher Aillon <caillon at redhat.com> 0.4-1
- Update to 0.4

* Mon Oct 31 2005 Christopher Aillon <caillon at redhat.com> 0.3-1
- Update to 0.3, working with newer versions of krb5 and NetworkManager

mc-1:4.6.1a-0.20
----------------
* Tue Oct 25 2005 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.20
- don't display UTF-8 characters as questionmarks in xterm title (#170971)

net-snmp-5.2.2-0.rc3.1
----------------------
* Tue Nov 01 2005 Radek Vokal <rvokal at redhat.com> - 5.2.2-0.rc3.1
- release candidate 3 of net-snmp-5.2.2

* Tue Oct 25 2005 Radek Vokal <rvokal at redhat.com> - 5.2.2.rc2-1
- rc2 prebuilt

pango-1.10.1-1
--------------
* Mon Oct 03 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.1-1
- Newer upstream version
- Use the docs which are included in the tarball

* Wed Aug 17 2005 Owen Taylor <otaylor at redhat.com> - 1.10.0-1
- Upgrade to 1.10.0

* Mon Aug 15 2005 Kristian H??gsberg <krh at redhat.com> 1.9.1-2
- Patch out libpixman dependency.

php-5.0.5-4
-----------
* Tue Nov 01 2005 Joseph Orton <jorton at redhat.com> 5.0.5-4
- rebuild for new libnetsnmp

procps-3.2.6-1
--------------
* Mon Oct 31 2005 Karel Zak <kzak at redhat.com> 3.2.6-1
- update to new upstream release

pykickstart-0.7-1
-----------------
* Tue Nov 01 2005 Chris Lumens <clumens at redhat.com> 0.7-1
- Fix clearpart --all.
- vnc command does not require --connect option (#172192).
- network --onboot does not take any option.
- Remove extra spaces from firewall --ports and --trust.
- Write out network --<service> options.

scim-tables-0.5.4-1
-------------------
* Wed Nov 02 2005 Jens Petersen <petersen at redhat.com> - 0.5.4-1
- upstream 0.5.4 release
  - indic-icons-1.tar.gz, scim-tables-indic.patch, thai-table.patch, and
    scim-tables-cvs-20051018.patch are no longer needed

startup-notification-0.8-3
--------------------------
* Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> 0.8-3
- change to new modular X dependencies
- move configure to build instead of prep
- use make install DESTDIR=$RPM_BUILD_ROOT instead of
  
  /usr/bin/make \
	prefix=/usr/src/build/631977-x86_64/install/usr \
	exec_prefix=/usr/src/build/631977-x86_64/install/usr \
	bindir=/usr/src/build/631977-x86_64/install/usr/bin \
	sbindir=/usr/src/build/631977-x86_64/install/usr/sbin \
	sysconfdir=/usr/src/build/631977-x86_64/install/etc \
	datadir=/usr/src/build/631977-x86_64/install/usr/share \
	includedir=/usr/src/build/631977-x86_64/install/usr/include \
	libdir=/usr/src/build/631977-x86_64/install/usr/lib64 \
	libexecdir=/usr/src/build/631977-x86_64/install/usr/libexec \
	localstatedir=/usr/src/build/631977-x86_64/install/var \
	sharedstatedir=/usr/src/build/631977-x86_64/install/usr/com \
	mandir=/usr/src/build/631977-x86_64/install/usr/share/man \
	infodir=/usr/src/build/631977-x86_64/install/usr/share/info \
  install

system-config-securitylevel-1.6.7-1
-----------------------------------
* Tue Nov 01 2005 Chris Lumens <clumens at redhat.com> 1.6.7-1
- Let lokkit load iptables modules (#113918, #145242).

xalan-j2-0:2.6.0-3jpp_4fc
-------------------------

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	openhpi - 2.0.3-2.i386 requires libnetsnmp.so.5
	pango-devel - 1.10.1-1.i386 requires XFree86-devel >= 0:4.2.99
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
	gnome-games - 1:2.12.1-3.i386 requires libhowl.so.0
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	OpenIPMI - 1.4.14-10.i386 requires libnetsnmp.so.5
	ImageMagick-devel - 6.2.2.0-4.i386 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.i386 requires XFree86-devel
	nut - 2.0.2-1.i386 requires libnetsnmp.so.5
	gtk2-devel - 2.8.6-3.i386 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.i386 requires XFree86-devel
	kdeutils - 6:3.4.92-1.i386 requires libnetsnmp.so.5



Broken deps for ppc
----------------------------------------------------------
	imlib-devel - 1:1.9.13-24.ppc requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
	openhpi - 2.0.3-2.ppc requires libnetsnmp.so.5
	kdeutils - 6:3.4.92-1.ppc requires libnetsnmp.so.5
	pango-devel - 1.10.1-1.ppc requires XFree86-devel >= 0:4.2.99
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	nut - 2.0.2-1.ppc requires libnetsnmp.so.5
	OpenIPMI - 1.4.14-10.ppc requires libnetsnmp.so.5
	gtk+-devel - 1:1.2.10-39.ppc requires XFree86-devel
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	gtk2-devel - 2.8.6-3.ppc requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.ppc requires XFree86-devel



Broken deps for ia64
----------------------------------------------------------
	ImageMagick-devel - 6.2.2.0-4.ia64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.ia64 requires XFree86-devel
	OpenIPMI - 1.4.14-10.ia64 requires libnetsnmp.so.5()(64bit)
	pango-devel - 1.10.1-1.ia64 requires XFree86-devel >= 0:4.2.99
	gtk2-devel - 2.8.6-3.ia64 requires XFree86-devel
	kdeutils - 6:3.4.92-1.ia64 requires libnetsnmp.so.5()(64bit)
	nut - 2.0.2-1.ia64 requires libnetsnmp.so.5()(64bit)
	imlib-devel - 1:1.9.13-24.ia64 requires XFree86-devel



Broken deps for s390x
----------------------------------------------------------
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	imlib-devel - 1:1.9.13-24.s390x requires XFree86-devel
	gtk2-devel - 2.8.6-3.s390x requires XFree86-devel
	kdeutils - 6:3.4.92-1.s390x requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.s390x requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.s390x requires XFree86-devel
	openhpi - 2.0.3-2.s390x requires libnetsnmp.so.5()(64bit)
	OpenIPMI - 1.4.14-10.s390x requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel
	pango-devel - 1.10.1-1.s390x requires XFree86-devel >= 0:4.2.99



Broken deps for s390
----------------------------------------------------------
	imlib-devel - 1:1.9.13-24.s390 requires XFree86-devel
	gtk2-devel - 2.8.6-3.s390 requires XFree86-devel
	pango-devel - 1.10.1-1.s390 requires XFree86-devel >= 0:4.2.99
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
	kdeutils - 6:3.4.92-1.s390 requires libnetsnmp.so.5
	OpenIPMI - 1.4.14-10.s390 requires libnetsnmp.so.5
	ImageMagick-devel - 6.2.2.0-4.s390 requires XFree86-devel
	openhpi - 2.0.3-2.s390 requires libnetsnmp.so.5
	gtk+-devel - 1:1.2.10-39.s390 requires XFree86-devel



Broken deps for x86_64
----------------------------------------------------------
	ImageMagick-devel - 6.2.2.0-4.x86_64 requires XFree86-devel
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	gtk2-devel - 2.8.6-3.x86_64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.x86_64 requires XFree86-devel
	pango-devel - 1.10.1-1.x86_64 requires XFree86-devel >= 0:4.2.99
	OpenIPMI - 1.4.14-10.x86_64 requires libnetsnmp.so.5()(64bit)
	nut - 2.0.2-1.x86_64 requires libnetsnmp.so.5()(64bit)
	imlib-devel - 1:1.9.13-24.x86_64 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	kdeutils - 6:3.4.92-1.x86_64 requires libnetsnmp.so.5()(64bit)
	openhpi - 2.0.3-2.x86_64 requires libnetsnmp.so.5()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	openhpi - 2.0.3-2.ppc64 requires libnetsnmp.so.5()(64bit)
	ImageMagick-devel - 6.2.2.0-4.ppc64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ppc64 requires XFree86-devel
	pango-devel - 1.10.1-1.ppc64 requires XFree86-devel >= 0:4.2.99
	nut - 2.0.2-1.ppc64 requires libnetsnmp.so.5()(64bit)
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	gtk2-devel - 2.8.6-3.ppc64 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	OpenIPMI - 1.4.14-10.ppc64 requires libnetsnmp.so.5()(64bit)
	kdeutils - 6:3.4.92-1.ppc64 requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.ppc64 requires XFree86-devel





From dstolte at arcor.de  Wed Nov  2 13:13:15 2005
From: dstolte at arcor.de (D. Stolte)
Date: Wed, 02 Nov 2005 14:13:15 +0100
Subject: cryptsetup-lunks support for mount & swapon
In-Reply-To: <1126007224.31359.71.camel@petra>
References: <1126007224.31359.71.camel@petra>
Message-ID: <4368BB6B.4030900@arcor.de>

Karel Zak wrote:
> http://people.redhat.com/kzak/util-linux-cryptsetup/
> 
> It's the place where you can found util-linux patch (or src.rpm) with
> full cryptsetup-luks support for mount, umount, swapon and swapoff. The
> patch supports classic cryptsetup and LUKS extension too.
> 
> 	Karel
> 

When will we see it in rawhide?

/ds



From hk at isphuset.no  Wed Nov  2 14:02:50 2005
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Wed, 02 Nov 2005 15:02:50 +0100
Subject: Updates testing dates seems incorrect
Message-ID: <1130940170.21954.11.camel@linux>

ftp://mirrors.kernel.org/fedora/core/updates/testing/4/i386/

Ex:
File:kernel-2.6.14-1.1633_FC4.i586.rpm 14953 KB 10/31/2004 04:38:00 PM
File:kernel-2.6.14-1.1633_FC4.i686.rpm 14498 KB 10/31/2004 04:39:00 PM

Somehow I doubt that kernel was available a year ago :)

By no means a big issue, but it confused me for a few minutes there
since I actually thought some of the updates had been in testing
for over a year. Until I came to think of the fact that FC4 probably
didn't need updates back then.

I haven't checked other folders, but it seems to me somebody who is
uploading new rpms should check their date settings.

OT: Anyone know why those PHP 5.0.5 packages haven't gone on in yet?

-HK



From bogdan at alterox.ro  Wed Nov  2 14:08:56 2005
From: bogdan at alterox.ro (Rotariu Bogdan-Stefan)
Date: Wed, 02 Nov 2005 16:08:56 +0200
Subject: Updates testing dates seems incorrect
In-Reply-To: <1130940170.21954.11.camel@linux>
References: <1130940170.21954.11.camel@linux>
Message-ID: <4368C878.5030307@alterox.ro>

Hans Kristian Rosbach wrote:

>ftp://mirrors.kernel.org/fedora/core/updates/testing/4/i386/
>
>Ex:
>File:kernel-2.6.14-1.1633_FC4.i586.rpm 14953 KB 10/31/2004 04:38:00 PM
>File:kernel-2.6.14-1.1633_FC4.i686.rpm 14498 KB 10/31/2004 04:39:00 PM
>
>Somehow I doubt that kernel was available a year ago :)
>
>  
>
the dates look ok here, same link.



From arjanv at redhat.com  Wed Nov  2 14:08:19 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 02 Nov 2005 15:08:19 +0100
Subject: Updates testing dates seems incorrect
In-Reply-To: <1130940170.21954.11.camel@linux>
References: <1130940170.21954.11.camel@linux>
Message-ID: <1130940499.2826.15.camel@laptopd505.fenrus.org>


> 
> I haven't checked other folders, but it seems to me somebody who is
> uploading new rpms should check their date settings.

maybe someone forgot that DST is only 1 hour difference not one year ;-)



From hk at isphuset.no  Wed Nov  2 14:24:15 2005
From: hk at isphuset.no (Hans Kristian Rosbach)
Date: Wed, 02 Nov 2005 15:24:15 +0100
Subject: Updates testing dates seems incorrect (FireFox/Mozilla Bug?)
In-Reply-To: <4368C878.5030307@alterox.ro>
References: <1130940170.21954.11.camel@linux>  <4368C878.5030307@alterox.ro>
Message-ID: <1130941455.21954.16.camel@linux>

On Wed, 2005-11-02 at 16:08 +0200, Rotariu Bogdan-Stefan wrote:
> Hans Kristian Rosbach wrote:
> 
> >ftp://mirrors.kernel.org/fedora/core/updates/testing/4/i386/
> >
> >Ex:
> >File:kernel-2.6.14-1.1633_FC4.i586.rpm 14953 KB 10/31/2004 04:38:00 PM
> >File:kernel-2.6.14-1.1633_FC4.i686.rpm 14498 KB 10/31/2004 04:39:00 PM
> >
> >Somehow I doubt that kernel was available a year ago :)
> >
> the dates look ok here, same link.

That is strange..

Using a real ftp client: Dates OK.
Used the http:// prefix: Dates OK.

But using firefox-1.0.7-1.1.fc4 to open the ftp:// link gives me
mostly (more than 50% of the files) the wrong dates.
mozilla-1.7.12-1.5.1 also gives incorrect results.

So I guess this is a firefox/mozilla bug then.

-HK



From sundaram at redhat.com  Wed Nov  2 14:28:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 02 Nov 2005 19:58:58 +0530
Subject: Updates testing dates seems incorrect (FireFox/Mozilla Bug?)
In-Reply-To: <1130941455.21954.16.camel@linux>
References: <1130940170.21954.11.camel@linux> <4368C878.5030307@alterox.ro>
	<1130941455.21954.16.camel@linux>
Message-ID: <4368CD2A.30100@redhat.com>

Hi

>
>That is strange..
>
>Using a real ftp client: Dates OK.
>Used the http:// prefix: Dates OK.
>
>But using firefox-1.0.7-1.1.fc4 to open the ftp:// link gives me
>mostly (more than 50% of the files) the wrong dates.
>mozilla-1.7.12-1.5.1 also gives incorrect results.
>
>So I guess this is a firefox/mozilla bug then.
>
>-HK
>
>  
>
Should be reported in bugzilla then

regards
Rahul



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Wed Nov  2 14:45:22 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Wed, 2 Nov 2005 15:45:22 +0100
Subject: rawhide report: 20051102 changes
In-Reply-To: <200511021250.jA2Com8T016242@porkchop.devel.redhat.com>
References: <200511021250.jA2Com8T016242@porkchop.devel.redhat.com>
Message-ID: <20051102154522.7f4ece5b@python2>

Build System wrote :

> startup-notification-0.8-3
> --------------------------
> * Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> 0.8-3
> - change to new modular X dependencies
> - move configure to build instead of prep
> - use make install DESTDIR=$RPM_BUILD_ROOT instead of
>   
>   /usr/bin/make \
> 	prefix=/usr/src/build/631977-x86_64/install/usr \
> 	exec_prefix=/usr/src/build/631977-x86_64/install/usr \
> 	bindir=/usr/src/build/631977-x86_64/install/usr/bin \
> 	sbindir=/usr/src/build/631977-x86_64/install/usr/sbin \
> 	sysconfdir=/usr/src/build/631977-x86_64/install/etc \
> 	datadir=/usr/src/build/631977-x86_64/install/usr/share \
> 	includedir=/usr/src/build/631977-x86_64/install/usr/include \
> 	libdir=/usr/src/build/631977-x86_64/install/usr/lib64 \
> 	libexecdir=/usr/src/build/631977-x86_64/install/usr/libexec \
> 	localstatedir=/usr/src/build/631977-x86_64/install/var \
> 	sharedstatedir=/usr/src/build/631977-x86_64/install/usr/com \
> 	mandir=/usr/src/build/631977-x86_64/install/usr/share/man \
> 	infodir=/usr/src/build/631977-x86_64/install/usr/share/info \
>   install

You obviously meant to put "%%makeinstall" here, right? :-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.13-1.1532_FC4
Load : 0.19 0.20 0.18



From rstrode at redhat.com  Wed Nov  2 15:49:11 2005
From: rstrode at redhat.com (Ray Strode)
Date: Wed, 02 Nov 2005 10:49:11 -0500
Subject: rawhide report: 20051102 changes
In-Reply-To: <20051102154522.7f4ece5b@python2>
References: <200511021250.jA2Com8T016242@porkchop.devel.redhat.com>
	<20051102154522.7f4ece5b@python2>
Message-ID: <1130946551.2721.0.camel@localhost.localdomain>

Hi, 

> > startup-notification-0.8-3
> > --------------------------
> > * Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> 0.8-3
> > - change to new modular X dependencies
> > - move configure to build instead of prep
> > - use make install DESTDIR=$RPM_BUILD_ROOT instead of
> >   
> >   /usr/bin/make \
> > 	prefix=/usr/src/build/631977-x86_64/install/usr \
> > 	exec_prefix=/usr/src/build/631977-x86_64/install/usr \
> > 	bindir=/usr/src/build/631977-x86_64/install/usr/bin \
> > 	sbindir=/usr/src/build/631977-x86_64/install/usr/sbin \
> > 	sysconfdir=/usr/src/build/631977-x86_64/install/etc \
> > 	datadir=/usr/src/build/631977-x86_64/install/usr/share \
> > 	includedir=/usr/src/build/631977-x86_64/install/usr/include \
> > 	libdir=/usr/src/build/631977-x86_64/install/usr/lib64 \
> > 	libexecdir=/usr/src/build/631977-x86_64/install/usr/libexec \
> > 	localstatedir=/usr/src/build/631977-x86_64/install/var \
> > 	sharedstatedir=/usr/src/build/631977-x86_64/install/usr/com \
> > 	mandir=/usr/src/build/631977-x86_64/install/usr/share/man \
> > 	infodir=/usr/src/build/631977-x86_64/install/usr/share/info \
> >   install
> 
> You obviously meant to put "%%makeinstall" here, right? :-)
yea :-)

--Ray



From davej at redhat.com  Wed Nov  2 17:19:34 2005
From: davej at redhat.com (Dave Jones)
Date: Wed, 2 Nov 2005 12:19:34 -0500
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <dka22g$o04$1@sea.gmane.org>
References: <1130796189.3690.3.camel@coyote.rexursive.com>
	<dka22g$o04$1@sea.gmane.org>
Message-ID: <20051102171934.GA32638@redhat.com>

On Wed, Nov 02, 2005 at 10:49:04AM +0100, Thomas M Steenholdt wrote:
 > Bojan Smojver wrote:
 > >Although I normally patch with suspend2, just wanted to try the status
 > >of suspend to disk in the regular FC5 kernels. The notebook (HP-ZE4201)
 > >wouldn't suspend at all. This is what I have in dmesg:
 > >
 > >-----------------------------------
 > >Stopping tasks:
 > >================================================================
 > >================
 > > stopping tasks failed (1 tasks remaining)
 > >Restarting tasks...<6> Strange, kauditd not stopped
 > > done
 > >-----------------------------------
 > >
 > >In some previous kernels it used to suspend and then crash on resume.
 > >
 > 
 > Same thing for suspend to mem in FC4 updates-testing kernel 2.6.14-1633_FC4
 > 
 > Did anyone see/file a bug on this? I can't seem to find any and we'd 
 > probably like something like this to be fixed!

It's already in bugzilla.

		Dave



From ph18 at cornell.edu  Wed Nov  2 18:23:21 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 02 Nov 2005 13:23:21 -0500
Subject: (Not) Customizing Gnome
Message-ID: <43690419.4070104@cornell.edu>

    Last week I made an attempt to customize the Gnome desktop on 
Fedora/RHEL and was quite shocked to find how hard it is to do.  I've 
been developing a system that lets me log into 20+ server/user 
configurations,  with colorized uxterms (tweaks to the color set so 
color ls is readable on various backgrounds),  expect to pass 
parameters,  all kinds of fun stuff.  When it came time to set up a GUI 
menu,  I hit a brick wall.

    To be fair,  I'm quite impressed with the performance of Gnome on 
older hardware.  I have a ~ 400 MhZ Pentium machine with about ~ 400 MB 
of RAM,  and recent RHEL/Fedora versions boot quickly -- Gnome is 
responsive,  and I've got no complaints about performance.

    The documentation sucks.  Instructions for editing the menu 
graphically "just didn't work."  I spent about four hours searching the 
web before I realized that I'd need to get a PhD in Gnome to be able to 
create arbitrary hiearchies in the 'Hat' menu on the panel.  I had to 
find a mailing list posting to find out that Nautilus is the application 
that displays the right-click menu,  not the WM. 

    The system of vfolders and .desktop files is quite elegant -- it's a 
good set of data structures,  and in a lot of ways it's preferable to 
the way the Start button works on Windows or the non-system of MacOS X.  
To take full advantage of that system,  however,  it would nice to have 
a way to attach categories to applications independent of the .desktop 
file,  perhaps by attaching an emblem to a file.  If one could mark 
applications as being the "Kiosk" category (system wide),  or in the 
"Favorite" category (for a particular user),  that would be a big help.  
What I find particularly exciting about the implementation is that it 
ought to be possible to use the same data structures to create a 
entirely different UI than a 'start button' clone. 

    Gnome is also avoiding the reality that any given user only uses a 
tiny fraction of the applications on a machine.  The Start Menu on 
Windows can get to be a godawful mess,  but at least you can drop  icons 
onto the start button so you can always find your top five 
applications.  People really like the ability to look up the last ten 
apps they ran on Mac OS X,  and this largely makes up for the miserable 
state of the Applications directory.

    It would really help to have an easy way to configure the 
right-click menu,  nautilus-scripts are pretty cool,  but not really 
what I want.  For instance,  on RHEL 4 I'd like to get rid of "Create 
Terminal" and replace it with an entry point to my system so my muscle 
memory doesn't betray me.

    Perhaps I'm bitching too much,  but I still remember the days when 
customizing X Windows on UNIX was as simple as editing a configuration 
file.  Now it's a matter of reading the documentation for hours,  then 
finding out that maybe you need to edit an XML file,  maybe you need to 
use gconf,  or maybe you just can't do it and should write your own 
panel applet instead.

    (That said,  RH has done a lot of good in /etc/sysconfig -- I'm 
always finding new things to love about it.)



From toshio at tiki-lounge.com  Wed Nov  2 18:38:27 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 02 Nov 2005 10:38:27 -0800
Subject: (Not) Customizing Gnome
In-Reply-To: <43690419.4070104@cornell.edu>
References: <43690419.4070104@cornell.edu>
Message-ID: <1130956707.3217.4.camel@localhost>

On Wed, 2005-11-02 at 13:23 -0500, Paul A Houle wrote:
> The documentation sucks.  Instructions for editing the menu 
> graphically "just didn't work."  
That's been broken for quite a while :-(
Try alacarte from Fedora Extras, though.  It seems to work for per user
menu editing.

> I spent about four hours searching the 
> web before I realized that I'd need to get a PhD in Gnome to be able to 
> create arbitrary hiearchies in the 'Hat' menu on the panel.  I had to 
> find a mailing list posting to find out that Nautilus is the application 
> that displays the right-click menu,  not the WM. 
> 
Yeah -- so something will have to be done with Nautilus scripts to work
around that.  FC5 has removed the Open Terminal entry.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051102/5e3aa8ca/attachment.sig>

From sundaram at redhat.com  Wed Nov  2 18:40:22 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 03 Nov 2005 00:10:22 +0530
Subject: (Not) Customizing Gnome
In-Reply-To: <1130956707.3217.4.camel@localhost>
References: <43690419.4070104@cornell.edu> <1130956707.3217.4.camel@localhost>
Message-ID: <43690816.2000803@redhat.com>

Hi

>>    
>>
>Yeah -- so something will have to be done with Nautilus scripts to work
>around that.  FC5 has removed the Open Terminal entry.
>
>-Toshio
>  
>
nautilus-open-terminal in Extras

regards
Rahul



From toshio at tiki-lounge.com  Wed Nov  2 18:54:54 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 02 Nov 2005 10:54:54 -0800
Subject: (Not) Customizing Gnome
In-Reply-To: <43690816.2000803@redhat.com>
References: <43690419.4070104@cornell.edu>
	<1130956707.3217.4.camel@localhost>  <43690816.2000803@redhat.com>
Message-ID: <1130957694.3217.5.camel@localhost>

On Thu, 2005-11-03 at 00:10 +0530, Rahul Sundaram wrote:
> Hi
> 
> >>    
> >>
> >Yeah -- so something will have to be done with Nautilus scripts to work
> >around that.  FC5 has removed the Open Terminal entry.
> >
> >-Toshio
> >  
> >
> nautilus-open-terminal in Extras

I think the other person was asking how to remove Open Terminal in FC4.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051102/7db6d2c5/attachment.sig>

From sundaram at redhat.com  Wed Nov  2 18:57:47 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 03 Nov 2005 00:27:47 +0530
Subject: (Not) Customizing Gnome
In-Reply-To: <1130957694.3217.5.camel@localhost>
References: <43690419.4070104@cornell.edu>	<1130956707.3217.4.camel@localhost>
	<43690816.2000803@redhat.com> <1130957694.3217.5.camel@localhost>
Message-ID: <43690C2B.6040506@redhat.com>

Hi

>>nautilus-open-terminal in Extras
>>    
>>
>
>I think the other person was asking how to remove Open Terminal in FC4.
>
>-Toshio
>  
>
Ah. I misread that. Maybe sabayon in Extras would help then

regards
Rahul



From mricon at gmail.com  Wed Nov  2 19:38:29 2005
From: mricon at gmail.com (Konstantin Ryabitsev)
Date: Wed, 2 Nov 2005 14:38:29 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <43690419.4070104@cornell.edu>
References: <43690419.4070104@cornell.edu>
Message-ID: <f8f6300f0511021138j674c190cj@mail.gmail.com>

On 02/11/05, Paul A Houle <ph18 at cornell.edu> wrote:
>     Gnome is also avoiding the reality that any given user only uses a
> tiny fraction of the applications on a machine.  The Start Menu on
> Windows can get to be a godawful mess,  but at least you can drop  icons
> onto the start button so you can always find your top five
> applications.  People really like the ability to look up the last ten
> apps they ran on Mac OS X,  and this largely makes up for the miserable
> state of the Applications directory.

Drag-and-drop your most common applications from the menu into your
top panel for one-click access.

Regards,
--
Konstantin Ryabitsev
http://www.mricon.com/
Montr?al, Qu?bec



From ph18 at cornell.edu  Wed Nov  2 19:47:13 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 02 Nov 2005 14:47:13 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <1130957694.3217.5.camel@localhost>
References: <43690419.4070104@cornell.edu>	<1130956707.3217.4.camel@localhost>
	<43690816.2000803@redhat.com> <1130957694.3217.5.camel@localhost>
Message-ID: <436917C1.4070707@cornell.edu>


>
>I think the other person was asking how to remove Open Terminal in FC4.
>
>-Toshio
>  
>
    And installing an rpm isn't my favorite way of dealing with this.

    Some users may never use a terminal at all,  and they wouldn't need it.

    Some users may want "Open Terminal" to use gnome-terminal.  Other 
people like rxvt,  xterm,  uxterm or konsole.  This sort of thing should 
be possible to configure on a per-user basis.  This is even ~more~ true 
in a managed environment where you might want,  say,  to have a 'kiosk' 
user who has limited capabilities and an 'admin' user who can use the 
GUI to configure the system.  The sysadmin should be able to turn off 
user configurability on a per-account basis,  but may want some users 
that are different from others.

    Right now I've installed a program (statemenu) that grabs a 
middle-button click on the desktop:  I've got one button that opens a 
local terminal,  and three submenus for three different categories of 
remote machines that I log into.  With statemenu,  I can edit a simple 
xml file and get it the way I want in a few minutes.  If it were up to 
me,  I'd rather put those options at the top of the menu I get when I 
right-click on the background.  (Perhaps this won't bother me when if 
and when my muscle memory adjusts...)

    There are tough questions here...  I ~never~ use anything on the 
right-click menu other than "Open Terminal";  I'd be happy to remove all 
of the items there,  but that's probably bad for the ecology of the 
Desktop,  because that would trash the Nautilus UI,  which I (or a 
friend) might just want to use someday.  Putting my stuff on the middle 
button is probably the best answer,  because I get my bit of "namespace" 
I can do what I want with,  and Nautilus gets one too.  I've even got 
the left button to do something else with.

    People who want to create a kiosk mode,  on the other hand,  need 
complete control of the right-click menu.

    There's a lot of thought in the RH/Fedora desktop about superficial 
kinds of customization (visual themes,  backgrounds -- it's easy to 
change the desktop background from the right-click menu,  for example) 
but you're in bad shape if you want to change behavior.  I couldn't care 
less about changing how focus works:  I switch all the time between mac 
and windows,  linux and solaris,  so my brain adjusts to whatever I 
get:  however,  it ought to be easy to add a new menu to the panel and 
edit it with either a text configuration file,  a graphical tool or both.

    The basic idea here is that there ought to be part of the UI that's 
controlled by the 'OS' and part that's controlled by the user.  The 
'hat' button is a good answer to the problem of creating new entries 
when you install an application by rpm -- but a panel applet that lets 
me create custom menus would obiviate the need to install or write 
software to do really simple things.



From sundaram at redhat.com  Wed Nov  2 19:55:28 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 03 Nov 2005 01:25:28 +0530
Subject: (Not) Customizing Gnome
In-Reply-To: <436917C1.4070707@cornell.edu>
References: <43690419.4070104@cornell.edu>	<1130956707.3217.4.camel@localhost>	<43690816.2000803@redhat.com>
	<1130957694.3217.5.camel@localhost> <436917C1.4070707@cornell.edu>
Message-ID: <436919B0.1050706@redhat.com>

Hi

>  
>
>    People who want to create a kiosk mode,  on the other hand,  need 
> complete control of the right-click menu.
>
>    There's a lot of thought in the RH/Fedora desktop about superficial 
> kinds of customization (visual themes,  backgrounds -- it's easy to 
> change the desktop background from the right-click menu,  for example) 
> but you're in bad shape if you want to change behavior.  I couldn't 
> care less about changing how focus works:  I switch all the time 
> between mac and windows,  linux and solaris,  so my brain adjusts to 
> whatever I get:  however,  it ought to be easy to add a new menu to 
> the panel and edit it with either a text configuration file,  a 
> graphical tool or both.

Look at the following projects

http://www.gnome.org/~seth/blog/sabayon
http://mail.gnome.org/archives/desktop-devel-list/2005-October/msg00359.html

regards
Rahul



From dakingun at gmail.com  Wed Nov  2 19:55:47 2005
From: dakingun at gmail.com (Deji Akingunola)
Date: Wed, 2 Nov 2005 14:55:47 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <43690419.4070104@cornell.edu>
References: <43690419.4070104@cornell.edu>
Message-ID: <b80014de0511021155r5709cc5av8866d9e13f62587@mail.gmail.com>

>     Gnome is also avoiding the reality that any given user only uses a
> tiny fraction of the applications on a machine.  The Start Menu on
> Windows can get to be a godawful mess,  but at least you can drop  icons
> onto the start button so you can always find your top five
> applications.  People really like the ability to look up the last ten
> apps they ran on Mac OS X,  and this largely makes up for the miserable
> state of the Applications directory.
>
Someone has actually proposed the sort of thing you're looking for on
planet gnome [1] a couple of days ago.
You can argue for it with Gnome developers on their desktop-devel list
it you're really interested in it.

[1]. http://blogs.gnome.org/view/michiels/2005/10/31/0



From ph18 at cornell.edu  Wed Nov  2 20:17:17 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 02 Nov 2005 15:17:17 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <f8f6300f0511021138j674c190cj@mail.gmail.com>
References: <43690419.4070104@cornell.edu>
	<f8f6300f0511021138j674c190cj@mail.gmail.com>
Message-ID: <43691ECD.2090808@cornell.edu>

Konstantin Ryabitsev wrote:

>
>Drag-and-drop your most common applications from the menu into your
>top panel for one-click access.
>  
>
    This is a nice answer in some cases,  but it doesn't always scale.  
In a single-panel configuration,  I'd rather have the space for window 
icons.

    I put 'sixtyforce' and 'snes' on the dock on my minimac because my 
toddler loves mario and bomberman -- I took itunes and other 
self-serving stuff off the dock until the day he begged to hear the 
latest 'Gorillaz' song and I figured that 99 cents was a good bargain.  
The only other graphical apps I run on that machine are 'terminal' and 
mozilla,  so this system works great for that use case.

    Application icons (and the tray) are a part of the problem on 
Windows:  every time I install a new app,  I get new buttons that I 
couldn't care less for.

    For the machine I'm customizing now,  panel launchers aren't an 
option at all -- I want to select about 20 different scripts.  I don't 
know if they'd all fit. These are all scripts that use uxterm,  slogin 
and sometimes expect,  so providing small icons that are visually 
distinctive and meaningful would be a big graphic design job.  If I made 
the panel 60 columns wide,  you could write captions under the icons,  
but then they wouldn't fit -- I'd either have to make the icons manually 
with a graphics editor,  or I'd have to write a scheme script to add the 
text in the gimp.

    On the other hand,  the 20 scripts are easily described with words,  
and easily organized in a hiearchy,  so a pull-down menu is just right.  
I'd be happy to have no icon or the same icon for all of them,  so 
specifying a .desktop file would be a waste of time.

    And that's what customization comes down to -- different use cases.  
MythTV has a great interface for a media center,  but I'd hate to do 
software development in that kind of interface.  I've got some computers 
where I spend a lot of time running a few graphical applications.  I've 
got other computers that I only run uxterm and emacs on.

    I've also got a lot of interest in 'passive' customization systems 
-- I love yahoo finance,  because it remembers the stocks that I ask 
quotes for,  so I automatically get a report on the stocks,  mutual 
funds,  and indices that I care about.  This would be useless if I was a 
professional fund manager,  but it's just great for the average person.



From ph18 at cornell.edu  Wed Nov  2 20:21:08 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 02 Nov 2005 15:21:08 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <436919B0.1050706@redhat.com>
References: <43690419.4070104@cornell.edu>	<1130956707.3217.4.camel@localhost>	<43690816.2000803@redhat.com>	<1130957694.3217.5.camel@localhost>
	<436917C1.4070707@cornell.edu> <436919B0.1050706@redhat.com>
Message-ID: <43691FB4.9070606@cornell.edu>

Rahul Sundaram wrote:

>
> http://www.gnome.org/~seth/blog/sabayon
> http://mail.gnome.org/archives/desktop-devel-list/2005-October/msg00359.html 
>

    Sweet.  What are the odds of getting this out of extras or in RHEL?



From sundaram at redhat.com  Wed Nov  2 20:25:29 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 03 Nov 2005 01:55:29 +0530
Subject: (Not) Customizing Gnome
In-Reply-To: <43691FB4.9070606@cornell.edu>
References: <43690419.4070104@cornell.edu>	<1130956707.3217.4.camel@localhost>	<43690816.2000803@redhat.com>	<1130957694.3217.5.camel@localhost>	<436917C1.4070707@cornell.edu>
	<436919B0.1050706@redhat.com> <43691FB4.9070606@cornell.edu>
Message-ID: <436920B9.3090100@redhat.com>

Hi

>>
>> http://www.gnome.org/~seth/blog/sabayon
>> http://mail.gnome.org/archives/desktop-devel-list/2005-October/msg00359.html 
>>
>
>
>    Sweet.  What are the odds of getting this out of extras or in RHEL?
>
Sabayon is already in Fedora Extras. If pessulus is include in GNOME 
2.14 it is likely to be available as part of the Fedora Core 5 release. 
If not anyone including you can package it for Fedora Extras.

regards
Rahul



From skvidal at phy.duke.edu  Wed Nov  2 20:26:29 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 02 Nov 2005 15:26:29 -0500
Subject: (Not) Customizing Gnome
In-Reply-To: <43691FB4.9070606@cornell.edu>
References: <43690419.4070104@cornell.edu>
	<1130956707.3217.4.camel@localhost>	<43690816.2000803@redhat.com>
	<1130957694.3217.5.camel@localhost> <436917C1.4070707@cornell.edu>
	<436919B0.1050706@redhat.com>  <43691FB4.9070606@cornell.edu>
Message-ID: <1130963189.11708.37.camel@cutter>

On Wed, 2005-11-02 at 15:21 -0500, Paul A Houle wrote:
> Rahul Sundaram wrote:
> 
> >
> > http://www.gnome.org/~seth/blog/sabayon
> > http://mail.gnome.org/archives/desktop-devel-list/2005-October/msg00359.html 
> >
> 
>     Sweet.  What are the odds of getting this out of extras or in RHEL?

getting it OUT of extras?

why? just use it from extras.

-sv




From pnasrat at redhat.com  Wed Nov  2 20:35:49 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 02 Nov 2005 14:35:49 -0600
Subject: Draft RPM Guide available online
Message-ID: <1130963750.2928.27.camel@enki.eridu>

I'm very pleased to announce that the Red Hat RPM Guide has been made
available under the Open Publication Licence, Version 1.0.

http://fedora.redhat.com/docs/drafts/rpm-guide-en/

This is much more recent than Maximum RPM and gives a good starting
point to work towards living documentation for RPM.  Although some
sections - notably Chapter 7 requires a complete rewrite.  However I
wanted to get it out in it's current form (basically as published plus
errata).

I'd like to thank Eric Foster-Johnson, all those involved in the
original formation of the Guide (particularly Jeff Johnson) and Tammy
Fox and those at the publishers for helping to make this happen.  Also
thanks to the Fedora Docs team in particular Stuart Ellis and Karsten
Wade for their conversion and push efforts

Participation through normal Fedora Documentation process:

http://fedora.redhat.com/projects/docs/

I'll be attempting to form a team to help edit/update content.  If you
want to help please follow up to fedora-docs-list.

Paul



From kzak at redhat.com  Wed Nov  2 21:16:47 2005
From: kzak at redhat.com (Karel Zak)
Date: Wed, 02 Nov 2005 22:16:47 +0100
Subject: cryptsetup-lunks support for mount & swapon
In-Reply-To: <4368BB6B.4030900@arcor.de>
References: <1126007224.31359.71.camel@petra>  <4368BB6B.4030900@arcor.de>
Message-ID: <1130966207.24413.69.camel@petra>

On Wed, 2005-11-02 at 14:13 +0100, D. Stolte wrote:
> Karel Zak wrote:
> > http://people.redhat.com/kzak/util-linux-cryptsetup/
> > 
> > It's the place where you can found util-linux patch (or src.rpm) with
> > full cryptsetup-luks support for mount, umount, swapon and swapoff. The
> > patch supports classic cryptsetup and LUKS extension too.
> > 
> > 	Karel
> > 
> 
> When will we see it in rawhide?

I would like to see things like this one in the util-linux upstream
rather than add it as a patch to FC package. It means that we should
wait for upstream developer. The official answer is that upstream
maintainer works on more important things now :-(

I'm going to maintain the patch at my "util-linux-cryptsetup" web page.

	Karel

-- 
Karel Zak <kzak at redhat.com>



From nicolas.mailhot at laposte.net  Wed Nov  2 21:47:18 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 02 Nov 2005 22:47:18 +0100
Subject: (Not) Customizing Gnome
In-Reply-To: <43691ECD.2090808@cornell.edu>
References: <43690419.4070104@cornell.edu>
	<f8f6300f0511021138j674c190cj@mail.gmail.com>
	<43691ECD.2090808@cornell.edu>
Message-ID: <1130968039.15396.26.camel@rousalka.dyndns.org>

Le mercredi 02 novembre 2005 ? 15:17 -0500, Paul A Houle a ?crit :
> Konstantin Ryabitsev wrote:
> 
> >
> >Drag-and-drop your most common applications from the menu into your
> >top panel for one-click access.
> >  
> >
>     This is a nice answer in some cases,  but it doesn't always scale.  
> In a single-panel configuration,  I'd rather have the space for window 
> icons.

Just add a drawer to your panel.
Though in your case it would be nice if once could force display of the
text next to the icon in the resulting vertical panel.

Care to add an RFE for this on bugzilla.gnome.org ?

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/20051102/9399f8c5/attachment.sig>

From bojan at rexursive.com  Wed Nov  2 21:52:14 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 03 Nov 2005 08:52:14 +1100
Subject: Draft RPM Guide available online
In-Reply-To: <1130963750.2928.27.camel@enki.eridu>
References: <1130963750.2928.27.camel@enki.eridu>
Message-ID: <20051103085214.jksgr5dq74kkkcwc@imp.rexursive.com>

Quoting Paul Nasrat <pnasrat at redhat.com>:

> I'm very pleased to announce that the Red Hat RPM Guide has been made
> available under the Open Publication Licence, Version 1.0.
>
> http://fedora.redhat.com/docs/drafts/rpm-guide-en/

Awesome! Thanks.

-- 
Bojan



From patmans at us.ibm.com  Wed Nov  2 22:05:29 2005
From: patmans at us.ibm.com (Patrick Mansfield)
Date: Wed, 2 Nov 2005 14:05:29 -0800
Subject: no provider for XFree86-devel dependency
Message-ID: <20051102220529.GA8499@us.ibm.com>

Hi -

yum update to current FC is failing for me. It looks like xorg-x11-devel
no longer provides XFree86-devel, as was done in at least FC4.

I could not find any recent bug reports for this, should I open one? I'm
not sure what category, if its xorg-x11-devel or the (multiple) rpms
requiring it.

Is there a workaround? I have lots of *-devel installed in order to
build anaconda.

Tail end of "yum update" output:

--> Running transaction check
--> Processing Dependency: XFree86-devel >= 4.2.99 for package: pango-devel
--> Processing Dependency: libhowl.so.0 for package: gnome-games
--> Processing Dependency: XFree86-devel for package: gtk2-devel
--> Finished Dependency Resolution
Error: Missing Dependency: XFree86-devel >= 4.2.99 is needed by package pango-devel
Error: Missing Dependency: XFree86-devel is needed by package gtk2-devel
Error: Missing Dependency: libhowl.so.0 is needed by package gnome-games

Thanks ...

-- Patrick Mansfield



From usdanskys at rocketmail.com  Wed Nov  2 22:06:30 2005
From: usdanskys at rocketmail.com (Steven I Usdansky)
Date: Wed, 2 Nov 2005 14:06:30 -0800 (PST)
Subject: gtk2-devel needs XFree86-devel
Message-ID: <20051102220630.17465.qmail@web33101.mail.mud.yahoo.com>

error: Can't install gtk2-devel-2.8.6-3 at i386: no package provides
XFree86-devel. Shouldn't xorg-x11-devel provide this?

-- 
Steven I. Usdansky, PhD
Traveling Geologist
Registered Linux user #360200




===========================
Steven I. Usdansky, PhD
Rock Doctor


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com



From nicolas.mailhot at laposte.net  Wed Nov  2 22:12:15 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 02 Nov 2005 23:12:15 +0100
Subject: no provider for XFree86-devel dependency
In-Reply-To: <20051102220529.GA8499@us.ibm.com>
References: <20051102220529.GA8499@us.ibm.com>
Message-ID: <1130969536.15396.27.camel@rousalka.dyndns.org>

Le mercredi 02 novembre 2005 ? 14:05 -0800, Patrick Mansfield a ?crit :
> Hi -
> 
> yum update to current FC is failing for me. It looks like xorg-x11-devel
> no longer provides XFree86-devel, as was done in at least FC4.

* sam oct 29 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-58
- Remove virtual provide "XFree86-devel" backward compatibility.  All
  packages that depended on this should now be updated to use the
modular
  X library virtual provides included in build -56 and later.

* sam oct 29 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-57
- Re-enable s390x arch

* mer oct 26 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-56
- Added "Provides: lib*-devel" virtual provides to 'devel' subpackage,
so
  that packages updated tp build in the modular tree will still build in
the
  monolithic tree as well.

-- 
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/20051102/29a28f12/attachment.sig>

From patmans at us.ibm.com  Wed Nov  2 23:04:00 2005
From: patmans at us.ibm.com (Patrick Mansfield)
Date: Wed, 2 Nov 2005 15:04:00 -0800
Subject: no provider for XFree86-devel dependency
In-Reply-To: <1130969536.15396.27.camel@rousalka.dyndns.org>
References: <20051102220529.GA8499@us.ibm.com>
	<1130969536.15396.27.camel@rousalka.dyndns.org>
Message-ID: <20051102230400.GA10707@us.ibm.com>

On Wed, Nov 02, 2005 at 11:12:15PM +0100, Nicolas Mailhot wrote:

> * sam oct 29 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-58
> - Remove virtual provide "XFree86-devel" backward compatibility.  All
>   packages that depended on this should now be updated to use the
> modular
>   X library virtual provides included in build -56 and later.

OK.

I guess the workaround is to install with "rpm --nodeps ...".

And sorry, I didn't realize the build reports include the list of broken
dependencies.

In the last build report:

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	openhpi - 2.0.3-2.i386 requires libnetsnmp.so.5
	pango-devel - 1.10.1-1.i386 requires XFree86-devel >= 0:4.2.99
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
	gnome-games - 1:2.12.1-3.i386 requires libhowl.so.0
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	OpenIPMI - 1.4.14-10.i386 requires libnetsnmp.so.5
	ImageMagick-devel - 6.2.2.0-4.i386 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.i386 requires XFree86-devel
	nut - 2.0.2-1.i386 requires libnetsnmp.so.5
	gtk2-devel - 2.8.6-3.i386 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.i386 requires XFree86-devel
	kdeutils - 6:3.4.92-1.i386 requires libnetsnmp.so.5

-- Patrick Mansfield



From mike at mommabears.com  Wed Nov  2 23:28:33 2005
From: mike at mommabears.com (MJang)
Date: Wed, 02 Nov 2005 15:28:33 -0800
Subject: (Not) Customizing Gnome
In-Reply-To: <1130968039.15396.26.camel@rousalka.dyndns.org>
References: <43690419.4070104@cornell.edu>
	<f8f6300f0511021138j674c190cj@mail.gmail.com>
	<43691ECD.2090808@cornell.edu>
	<1130968039.15396.26.camel@rousalka.dyndns.org>
Message-ID: <1130974113.3862.15.camel@localhost>

On Wed, 2005-11-02 at 22:47 +0100, Nicolas Mailhot wrote:
> Le mercredi 02 novembre 2005 ? 15:17 -0500, Paul A Houle a ?crit :
> > Konstantin Ryabitsev wrote:
> > 
> > >
> > >Drag-and-drop your most common applications from the menu into your
> > >top panel for one-click access.
> > >  
> > >
> >     This is a nice answer in some cases,  but it doesn't always scale.  
> > In a single-panel configuration,  I'd rather have the space for window 
> > icons.
> 
> Just add a drawer to your panel.
> Though in your case it would be nice if once could force display of the
> text next to the icon in the resulting vertical panel.

Are there any plans to incorporate smeg (Simple Menu Editor for GNOME),
as has been done for Ubuntu?

Thanks,
Mike




From toshio at tiki-lounge.com  Wed Nov  2 23:42:49 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 02 Nov 2005 15:42:49 -0800
Subject: (Not) Customizing Gnome
In-Reply-To: <1130974113.3862.15.camel@localhost>
References: <43690419.4070104@cornell.edu>
	<f8f6300f0511021138j674c190cj@mail.gmail.com>
	<43691ECD.2090808@cornell.edu>
	<1130968039.15396.26.camel@rousalka.dyndns.org>
	<1130974113.3862.15.camel@localhost>
Message-ID: <1130974969.3217.8.camel@localhost>

On Wed, 2005-11-02 at 15:28 -0800, MJang wrote:
> 
> Are there any plans to incorporate smeg (Simple Menu Editor for GNOME),
> as has been done for Ubuntu?
> 
Unless I'm reading something wrong, smeg was renamed to alacarte.
alacarte is in Fedora Extras and appears to work fine.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051102/aae38186/attachment.sig>

From mhw at wittsend.com  Wed Nov  2 23:50:26 2005
From: mhw at wittsend.com (Michael H. Warfield)
Date: Wed, 02 Nov 2005 18:50:26 -0500
Subject: cryptsetup-lunks support for mount & swapon
In-Reply-To: <1130966207.24413.69.camel@petra>
References: <1126007224.31359.71.camel@petra>  <4368BB6B.4030900@arcor.de>
	<1130966207.24413.69.camel@petra>
Message-ID: <1130975426.4620.1.camel@canyon.wittsend.com>

On Wed, 2005-11-02 at 22:16 +0100, Karel Zak wrote:
> On Wed, 2005-11-02 at 14:13 +0100, D. Stolte wrote:
> > Karel Zak wrote:
> > > http://people.redhat.com/kzak/util-linux-cryptsetup/
> > > 
> > > It's the place where you can found util-linux patch (or src.rpm) with
> > > full cryptsetup-luks support for mount, umount, swapon and swapoff. The
> > > patch supports classic cryptsetup and LUKS extension too.
> > > 
> > > 	Karel
> > > 
> > 
> > When will we see it in rawhide?

> I would like to see things like this one in the util-linux upstream
> rather than add it as a patch to FC package. It means that we should
> wait for upstream developer. The official answer is that upstream
> maintainer works on more important things now :-(

> I'm going to maintain the patch at my "util-linux-cryptsetup" web page.

	Hmmm...  Probably need the same for busybox and nash.  :-/

> 	Karel

> -- 
> Karel Zak <kzak at redhat.com>

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051102/7c6ca449/attachment.sig>

From rodd at clarkson.id.au  Thu Nov  3 01:42:01 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 03 Nov 2005 12:42:01 +1100
Subject: no provider for XFree86-devel dependency
In-Reply-To: <20051102230400.GA10707@us.ibm.com>
References: <20051102220529.GA8499@us.ibm.com>
	<1130969536.15396.27.camel@rousalka.dyndns.org>
	<20051102230400.GA10707@us.ibm.com>
Message-ID: <1130982121.3249.8.camel@localhost.localdomain>

On Wed, 2005-11-02 at 15:04 -0800, Patrick Mansfield wrote:
> On Wed, Nov 02, 2005 at 11:12:15PM +0100, Nicolas Mailhot wrote:
> 
> > * sam oct 29 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-58
> > - Remove virtual provide "XFree86-devel" backward compatibility.  All
> >   packages that depended on this should now be updated to use the
> > modular
> >   X library virtual provides included in build -56 and later.
> 
> OK.
> 
> I guess the workaround is to install with "rpm --nodeps ...".

Ah, how about instead of working around this, you wait until the deps
have been satisfied.

I think it's worth saying that we are about to see some humongous
changes with the introduction of the module xorg into rawhide (of which
these issues are a part) but that, with a little patient a simple 'yum
update' should just work.

While an 'rpm --nodeps' might _solve_ the problem in the short term, it
might also create bigger problems in the long term, making more work for
the developers to figure out because someone forced something to 'make
it work'.

Sorry if this is too harsh, but the use of rawhide needs a little
patience sometimes which include putting up with broken deps, broken
packages and other stuff.  What rawhide doesn't need to 'artificial'
breakage that adds another layer of complexity to and already complex
task.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From sundaram at redhat.com  Thu Nov  3 02:10:17 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 03 Nov 2005 07:40:17 +0530
Subject: no provider for XFree86-devel dependency
In-Reply-To: <1130982121.3249.8.camel@localhost.localdomain>
References: <20051102220529.GA8499@us.ibm.com>	<1130969536.15396.27.camel@rousalka.dyndns.org>	<20051102230400.GA10707@us.ibm.com>
	<1130982121.3249.8.camel@localhost.localdomain>
Message-ID: <43697189.7060903@redhat.com>

Hi

>Ah, how about instead of working around this, you wait until the deps
>have been satisfied.
>
>I think it's worth saying that we are about to see some humongous
>changes with the introduction of the module xorg into rawhide (of which
>these issues are a part) but that, with a little patient a simple 'yum
>update' should just work.
>
>While an 'rpm --nodeps' might _solve_ the problem in the short term, it
>might also create bigger problems in the long term, making more work for
>the developers to figure out because someone forced something to 'make
>it work'.
>
>Sorry if this is too harsh, but the use of rawhide needs a little
>patience sometimes which include putting up with broken deps, broken
>packages and other stuff.  What rawhide doesn't need to 'artificial'
>breakage that adds another layer of complexity to and already complex
>task.
>
>
>Rodd
>  
>
+1 on this. Very well said.

regards
Rahul



From bart.vanbrabant at zoeloelip.be  Thu Nov  3 09:16:11 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Thu, 03 Nov 2005 10:16:11 +0100
Subject: no provider for XFree86-devel dependency
In-Reply-To: <20051102230400.GA10707@us.ibm.com>
References: <20051102220529.GA8499@us.ibm.com>	<1130969536.15396.27.camel@rousalka.dyndns.org>
	<20051102230400.GA10707@us.ibm.com>
Message-ID: <4369D55B.6010101@zoeloelip.be>

Patrick Mansfield wrote:
> On Wed, Nov 02, 2005 at 11:12:15PM +0100, Nicolas Mailhot wrote:
>
>   
>> * sam oct 29 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-58
>> - Remove virtual provide "XFree86-devel" backward compatibility.  All
>>   packages that depended on this should now be updated to use the
>> modular
>>   X library virtual provides included in build -56 and later.
>>     
>
> OK.
>
> I guess the workaround is to install with "rpm --nodeps ...".
>
> And sorry, I didn't realize the build reports include the list of broken
> dependencies.
>
> In the last build report:
>
> Broken deps for i386
> ----------------------------------------------------------
> 	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
> 	openhpi - 2.0.3-2.i386 requires libnetsnmp.so.5
> 	pango-devel - 1.10.1-1.i386 requires XFree86-devel >= 0:4.2.99
> 	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
> 	gnome-games - 1:2.12.1-3.i386 requires libhowl.so.0
> 	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
> 	OpenIPMI - 1.4.14-10.i386 requires libnetsnmp.so.5
> 	ImageMagick-devel - 6.2.2.0-4.i386 requires XFree86-devel
> 	gtk+-devel - 1:1.2.10-39.i386 requires XFree86-devel
> 	nut - 2.0.2-1.i386 requires libnetsnmp.so.5
> 	gtk2-devel - 2.8.6-3.i386 requires XFree86-devel
> 	imlib-devel - 1:1.9.13-24.i386 requires XFree86-devel
> 	kdeutils - 6:3.4.92-1.i386 requires libnetsnmp.so.5
>
> -- Patrick Mansfield
>
>   
I removed most of the gnome devel packages and yum could cleanly install
the updates. You can't compile new stuff on you're
own now until the deps are ok.

Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051103/09bf9ef0/attachment.sig>

From radekvokal at gmail.com  Thu Nov  3 09:16:50 2005
From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=)
Date: Thu, 03 Nov 2005 10:16:50 +0100
Subject: traceroute replacement
Message-ID: <1131009410.3368.83.camel@localhost.localdomain>

Hi,

 there's a new package suggested as traceroute replacement. It works
without requiring a setuid bit. 

<snip>
This traceroute implementation relies on a number of features of the
2.4 Linux kernel. It works pretty much like ANK's tracepath, but 
tries to be command line compatible with the original traceroute.
I also has IPv6 support, and does parallel probes, which makes it
a little faster.
</snip>

The replacement is missing some options on which some scripts might
depend on. Please test the package 

http://people.redhat.com/rvokal/traceroute/traceroute-1.0.3-3.src.rpm

and report any problems to this bugzilla

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172198


missing options are:

       -d     Enable socket level debugging.
       -I     Use ICMP ECHO instead of UDP datagrams.
       -r     Bypass the normal routing tables and send directly to a host on an
attached network.  If the  host
              is  not  on  a directly-attached network, an error is returned. 
This option can be used to ping a
              local host through an interface that has no route  through  it 
(e.g.,  after  the  interface  was
              dropped by routed(8C)).
       -v     Verbose output.  Received ICMP packets other than TIME_EXCEEDED
and UNREACHABLEs are listed.
       -x     Toggle ip checksums. Normally, this prevents traceroute from
calculating  ip  checksums.  In  some
              cases,  the  operating  system  can overwrite parts of the
outgoing packet but not recalculate the
              checksum (so in some cases the default is to not calculate
checksums and using -x causes  them  to
              be  calcualted).  Note  that  checksums are usually required for
the last hop when using ICMP ECHO
              probes (-I).  So they are always calculated when using ICMP.
       -z     Set the time (in milliseconds) to pause between probes (default
0).  Some systems such as  Solaris
              and  routers  such  as  Ciscos rate limit icmp messages. A good
value to use with this this is 500
              (e.g. 1/2 second).

differences:

-S = -s and -I = -i (! the above src rpm has a patch to use -i for interfaces as old traceroute)

-- 
Radek Vok?l <radekvokal at gmail.com>



From Theodore.Papadopoulo at sophia.inria.fr  Thu Nov  3 09:30:13 2005
From: Theodore.Papadopoulo at sophia.inria.fr (Theodore Papadopoulo)
Date: Thu, 03 Nov 2005 10:30:13 +0100
Subject: Draft RPM Guide available online
In-Reply-To: <1130963750.2928.27.camel@enki.eridu>
References: <1130963750.2928.27.camel@enki.eridu>
Message-ID: <1131010213.3400.87.camel@mururoa>

On Wed, 2005-11-02 at 14:35 -0600, Paul Nasrat wrote:
> I'm very pleased to announce that the Red Hat RPM Guide has been made
> available under the Open Publication Licence, Version 1.0.
> 
> http://fedora.redhat.com/docs/drafts/rpm-guide-en/

Any chance to get a pdf version ???

Thank's

	Theo.



From igorm5 at vip.hr  Thu Nov  3 11:52:44 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 03 Nov 2005 12:52:44 +0100
Subject: Open Office 2.0 - GNOME integration
Message-ID: <4369FA0C.8080804@vip.hr>

Is there any chance to see the GNOME version of Open Office 2.0? SUSE
10.0 and Ubuntu 5.10 have it, but not FC4 and Rawhide which uses some
generic icon theme, or something. It looks much better...

Cheers!

-- 
Igor Jagec



From rdieter at math.unl.edu  Thu Nov  3 12:11:56 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 03 Nov 2005 06:11:56 -0600
Subject: gtk2-devel needs XFree86-devel
In-Reply-To: <20051102220630.17465.qmail@web33101.mail.mud.yahoo.com>
References: <20051102220630.17465.qmail@web33101.mail.mud.yahoo.com>
Message-ID: <4369FE8C.2080607@math.unl.edu>

Steven I Usdansky wrote:
> error: Can't install gtk2-devel-2.8.6-3 at i386: no package provides
> XFree86-devel. Shouldn't xorg-x11-devel provide this?

xorg-x11-devel *does* provide XFree86-devel.

That is, unless you're using rawhide/development, then you should know 
better. (-:



From caolanm at redhat.com  Thu Nov  3 12:08:39 2005
From: caolanm at redhat.com (Caolan McNamara)
Date: Thu, 03 Nov 2005 12:08:39 +0000
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <4369FA0C.8080804@vip.hr>
References: <4369FA0C.8080804@vip.hr>
Message-ID: <1131019720.11309.72.camel@localhost.localdomain>

On Thu, 2005-11-03 at 12:52 +0100, Igor Jagec wrote:
> Is there any chance to see the GNOME version of Open Office 2.0? SUSE
> 10.0 and Ubuntu 5.10 have it, but not FC4 and Rawhide which uses some
> generic icon theme, or something. It looks much better...

What you mean is "the Novell version of the icons", rather than the
"GNOME version" as the gnome integration features and components are the
same in FC4, upstream and Novell/Ubuntu. There's no functional different
in that arena.

If you volunteer to verify that all the icons are correct, and there no
left arrows for used for "right" etc. then perhaps :-)

C.



From gilboada at netvision.net.il  Thu Nov  3 12:11:59 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Thu, 03 Nov 2005 14:11:59 +0200
Subject: Draft RPM Guide available online
In-Reply-To: <1130963750.2928.27.camel@enki.eridu>
References: <1130963750.2928.27.camel@enki.eridu>
Message-ID: <1131019919.19742.38.camel@gilboa-work-dev>

Thanks!

I was looking to help build KDE-RedHat on x86-64 but held back due to
may rather poor RPM-authoring skills.

Gilboa

On Wed, 2005-11-02 at 14:35 -0600, Paul Nasrat wrote:
> I'm very pleased to announce that the Red Hat RPM Guide has been made
> available under the Open Publication Licence, Version 1.0.
> 
> http://fedora.redhat.com/docs/drafts/rpm-guide-en/
> 
> This is much more recent than Maximum RPM and gives a good starting
> point to work towards living documentation for RPM.  Although some
> sections - notably Chapter 7 requires a complete rewrite.  However I
> wanted to get it out in it's current form (basically as published plus
> errata).
> 
> I'd like to thank Eric Foster-Johnson, all those involved in the
> original formation of the Guide (particularly Jeff Johnson) and Tammy
> Fox and those at the publishers for helping to make this happen.  Also
> thanks to the Fedora Docs team in particular Stuart Ellis and Karsten
> Wade for their conversion and push efforts
> 
> Participation through normal Fedora Documentation process:
> 
> http://fedora.redhat.com/projects/docs/
> 
> I'll be attempting to form a team to help edit/update content.  If you
> want to help please follow up to fedora-docs-list.
> 
> Paul
> 



From nicu_fedora at nicubunu.ro  Thu Nov  3 12:35:27 2005
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Thu, 03 Nov 2005 14:35:27 +0200
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <1131019720.11309.72.camel@localhost.localdomain>
References: <4369FA0C.8080804@vip.hr>
	<1131019720.11309.72.camel@localhost.localdomain>
Message-ID: <436A040F.7010402@nicubunu.ro>

Caolan McNamara wrote:
> On Thu, 2005-11-03 at 12:52 +0100, Igor Jagec wrote:
> 
>>Is there any chance to see the GNOME version of Open Office 2.0? SUSE
>>10.0 and Ubuntu 5.10 have it, but not FC4 and Rawhide which uses some
>>generic icon theme, or something. It looks much better...
> 
> 
> What you mean is "the Novell version of the icons", rather than the
> "GNOME version" as the gnome integration features and components are the
> same in FC4, upstream and Novell/Ubuntu. There's no functional different
> in that arena.
> 
> If you volunteer to verify that all the icons are correct, and there no
> left arrows for used for "right" etc. then perhaps :-)

As OOo changed the way it use icons, is really easy to change the icon 
set, just replace the /usr/lib/openoffice.org/share/config/images.zip 
file and you are done.

So is just a matter of "lifting" images.zip from a SUSE or Ubuntu 
install and start testing.

PS: I'm still thinking the Bluecurve OOo icon set from FC2-FC3 was the 
most beautiful OOo icon set ever (despite the fact it was incomplete, 
partly Bluecurve and partly Industrial)

-- 
nicu
my hats collection: http://fedora.nicubunu.ro/hats
Open Clip Art Library: http://www.openclipart.org



From buildsys at redhat.com  Thu Nov  3 12:47:46 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 3 Nov 2005 07:47:46 -0500
Subject: rawhide report: 20051103 changes
Message-ID: <200511031247.jA3ClkLf011315@porkchop.devel.redhat.com>

New package libnl
	Convenience library for kernel netlink sockets


 
Updated Packages:

OpenIPMI-1.4.14-11
------------------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-11
- Rebuild to link against new net-snmp libs.

audit-1.0.9-1
-------------
* Wed Nov 02 2005 Steve Grubb <sgrubb at redhat.com> 1.0.9-1
- Updated message types that auditd recognizes
- Added a couple more message types
- Added new standard logging format function
- Update default config
- Make ausearch -m take a list of message types

gd-2.0.33-5
-----------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-5
- Switched BuildPreReqs and Requires to modular xorg-x11 style

* Mon Oct 10 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-4
- Fixed possible gd crash when drawing AA line near image borders (#167843)

* Wed Sep 07 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-3
- Fixed broken freetype-config --libs flags in configure (#165875)

gnome-games-1:2.12.1-4
----------------------
* Wed Nov 02 2005 Ray Strode <rstrode at redhat.com> 1:2.12.1-4
- don't link to howl now that we aren't using it

gnome-keyring-manager-2.12.0-2
------------------------------
* Wed Nov 02 2005 Matthias Clasen <mclasen at redhat.com> 2.12.0-2
- Avoid the error dialog if there is no default keyring.

gnome-utils-1:2.13.1-1
----------------------
* Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> - 1:2.13.1-1
- update to gnome-utils 2.13.1

* Thu Oct 13 2005 Tomas Mraz <tmraz at redhat.com>
- use include config-util instead of pam_stack in pam config

* Thu Oct 13 2005 Matthias Clasen <mclasen at redhat.com> - 1:2.12.1-3
- Add missing Requires

gnuplot-4.0.0-10
----------------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 4.0.0-10
- Switched BuildPreReqs and Requires to modular xorg-x11 style

kernel-2.6.14-1.1639_FC5
------------------------
* Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
- Switch ppc64 and ppc kernels to arch/powerpc
- Add nvram driver back again
- Fix ppc32 initrd with arch/powerpc

* Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
- 2.6.14-git5
- Fix up PPC configs in preparation for using arch/powerpc
- Prevent kauditd from aborting suspend

log4j-0:1.2.8-7jpp_6fc
----------------------
* Thu Nov 03 2005 Archit Shah <ashah at redhat.com> 0:1.2.8-7jpp_6fc
- Reenable building of example that uses rmic

logwatch-7.0-2
--------------
* Wed Nov 02 2005 Ivana Varekova <varekova at redhat.com> 7.0-2
- fix zz-disk_space problem (bug 172230) 
  used michal at harddata.com patch
- fix a few inconsistencies with new directory structure
- changed previous zz-disk_space 
- add secure sript patch allow case insensitivity for GID, UID)

ntp-4.2.0.a.20050816-9
----------------------
* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-9
- Rebuild

* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-8
- Rebuild

* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-7
- Rebuild

openoffice.org-1:2.0.0-3.7.2
----------------------------
* Fri Oct 28 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.0-3.7
- rh#171918# wrong LDAP stuff gets launched from wizard
- upstream patches as cmcfixes20
- rh#171844# make another stab at the klipper problem
- ooo#57107# updated hindi translation
- rh#159381# be less of a gcj bigot
- rh#172149# need more stuff in the classpath for macro creating

openswan-2.4.2-0.dr5.1
----------------------
* Wed Nov 02 2005 Harald Hoyer <harald at redhat.com> - 2.4.2-0.dr5.1
- version 2.4.2dr5

shared-mime-info-0.16.cvs20051018-2
-----------------------------------
* Wed Nov 02 2005 John (J5) Palmieri <johnp at redhat.com> - 0.16.cvs20051018-2
- Change all refs of eog to gthumb in defaults.list

stunnel-4.14-1
--------------
* Thu Nov 03 2005 Miloslav Trmac <mitr at redhat.com> - 4.14-1
- Update to stunnel-4.14
- Override changed default pid file location, keep it in /var/run

system-config-kickstart-2.6.0-1
-------------------------------
* Wed Nov 02 2005 Chris Lumens <clumens at redhat.com> 2.6.0-1
- Use pykickstart instead of our own kickstart file parsing code.

system-config-network-1.3.30-2
------------------------------
* Wed Nov 02 2005 Harald Hoyer <harald at redhat.com> - 1.3.30
- removed interdruid
- reversed Cancel/Ok button ordering

tzdata-2005n-2
--------------
* Wed Nov 02 2005 Jakub Jelinek <jakub at redhat.com> 2005n-2
- 2005n
  - changes for Kyrgyzstan and Uruguay
- fix a typo in the Makefile (used TZDATA env var instead of TZDIR during
  make check), update tst-timezone.c from glibc CVS (#172102)

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	openhpi - 2.0.3-2.i386 requires libnetsnmp.so.5
	pango-devel - 1.10.1-1.i386 requires XFree86-devel >= 0:4.2.99
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.i386 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.i386 requires XFree86-devel
	gtk2-devel - 2.8.6-3.i386 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
	imlib-devel - 1:1.9.13-24.i386 requires XFree86-devel
	kdeutils - 6:3.4.92-1.i386 requires libnetsnmp.so.5
	nut - 2.0.2-1.i386 requires libnetsnmp.so.5



Broken deps for x86_64
----------------------------------------------------------
	gtk+-devel - 1:1.2.10-39.x86_64 requires XFree86-devel
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	ImageMagick-devel - 6.2.2.0-4.x86_64 requires XFree86-devel
	pango-devel - 1.10.1-1.x86_64 requires XFree86-devel >= 0:4.2.99
	nut - 2.0.2-1.x86_64 requires libnetsnmp.so.5()(64bit)
	kdeutils - 6:3.4.92-1.x86_64 requires libnetsnmp.so.5()(64bit)
	imlib-devel - 1:1.9.13-24.x86_64 requires XFree86-devel
	gtk2-devel - 2.8.6-3.x86_64 requires XFree86-devel
	openhpi - 2.0.3-2.x86_64 requires libnetsnmp.so.5()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	kdeutils - 6:3.4.92-1.ppc64 requires libnetsnmp.so.5()(64bit)
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.ppc64 requires XFree86-devel
	openhpi - 2.0.3-2.ppc64 requires libnetsnmp.so.5()(64bit)
	nut - 2.0.2-1.ppc64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.ppc64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ppc64 requires XFree86-devel
	system-config-kickstart - 2.6.0-1.noarch requires rhpxl
	gtk2-devel - 2.8.6-3.ppc64 requires XFree86-devel
	pango-devel - 1.10.1-1.ppc64 requires XFree86-devel >= 0:4.2.99



Broken deps for ppc
----------------------------------------------------------
	gtk2-devel - 2.8.6-3.ppc requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
	kdeutils - 6:3.4.92-1.ppc requires libnetsnmp.so.5
	gtk+-devel - 1:1.2.10-39.ppc requires XFree86-devel
	openhpi - 2.0.3-2.ppc requires libnetsnmp.so.5
	pango-devel - 1.10.1-1.ppc requires XFree86-devel >= 0:4.2.99
	imlib-devel - 1:1.9.13-24.ppc requires XFree86-devel
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	nut - 2.0.2-1.ppc requires libnetsnmp.so.5
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.ppc requires XFree86-devel



Broken deps for s390x
----------------------------------------------------------
	openhpi - 2.0.3-2.s390x requires libnetsnmp.so.5()(64bit)
	pango-devel - 1.10.1-1.s390x requires XFree86-devel >= 0:4.2.99
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel
	gtk2-devel - 2.8.6-3.s390x requires XFree86-devel
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	system-config-kickstart - 2.6.0-1.noarch requires rhpxl
	imlib-devel - 1:1.9.13-24.s390x requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.s390x requires XFree86-devel
	kdeutils - 6:3.4.92-1.s390x requires libnetsnmp.so.5()(64bit)
	gtk+-devel - 1:1.2.10-39.s390x requires XFree86-devel



Broken deps for s390
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
	pango-devel - 1.10.1-1.s390 requires XFree86-devel >= 0:4.2.99
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5
	kdeutils - 6:3.4.92-1.s390 requires libnetsnmp.so.5
	gtk2-devel - 2.8.6-3.s390 requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.s390 requires XFree86-devel
	gtk+-devel - 1:1.2.10-39.s390 requires XFree86-devel
	openhpi - 2.0.3-2.s390 requires libnetsnmp.so.5
	imlib-devel - 1:1.9.13-24.s390 requires XFree86-devel
	system-config-kickstart - 2.6.0-1.noarch requires rhpxl



Broken deps for ia64
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	nut - 2.0.2-1.ia64 requires libnetsnmp.so.5()(64bit)
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	kdeutils - 6:3.4.92-1.ia64 requires libnetsnmp.so.5()(64bit)
	pango-devel - 1.10.1-1.ia64 requires XFree86-devel >= 0:4.2.99
	gtk+-devel - 1:1.2.10-39.ia64 requires XFree86-devel
	gtk2-devel - 2.8.6-3.ia64 requires XFree86-devel
	imlib-devel - 1:1.9.13-24.ia64 requires XFree86-devel
	ImageMagick-devel - 6.2.2.0-4.ia64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)





From emmanuel.seyman at club-internet.fr  Thu Nov  3 13:59:51 2005
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Thu, 3 Nov 2005 14:59:51 +0100
Subject: Draft RPM Guide available online
In-Reply-To: <1130963750.2928.27.camel@enki.eridu>
References: <1130963750.2928.27.camel@enki.eridu>
Message-ID: <20051103135951.GA7316@orient.maison.moi>

On Wed, Nov 02, 2005 at 02:35:49PM -0600, Paul Nasrat wrote:
>
> I'm very pleased to announce that the Red Hat RPM Guide has been made
> available under the Open Publication Licence, Version 1.0.

\o/

> http://fedora.redhat.com/docs/drafts/rpm-guide-en/
                                                 ^^

Translation, translation!

Emmanuel



From clovis at agr.unicamp.br  Thu Nov  3 16:10:17 2005
From: clovis at agr.unicamp.br (Clovis Tristao)
Date: Thu, 03 Nov 2005 14:10:17 -0200
Subject: Yum error
Message-ID: <436A3669.3020602@agr.unicamp.br>

Hello,

When I ran "yum -y update", appear this errors,

My System: Kernel 2.6.13-1.1627_FC5
# yum -y update
Setting up Update Process
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
livna                     100% |=========================|  951 B    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.0 MB    00:03
developmen: ################################################## 3768/3768
Added 129 new packages, deleted 125 old in 7.72 seconds
primary.xml.gz            100% |=========================| 841 kB    00:03
extras-dev: ################################################## 2341/2341
Added 560 new packages, deleted 546 old in 9.67 seconds

Error: Missing Dependency: XFree86-devel is needed by package lesstif-devel
Error: Missing Dependency: XFree86-devel is needed by package imlib-devel
Error: Missing Dependency: XFree86-devel >= 4.2.99 is needed by package 
pango-devel
Error: Missing Dependency: XFree86-devel is needed by package gtk2-devel
Error: Missing Dependency: XFree86-devel is needed by package SDL-devel
Error: Missing Dependency: libnetsnmp.so.5 is needed by package kdeutils
Error: Missing Dependency: XFree86-devel is needed by package gtk+-devel

What's happening?
Thanks a lot,

Cl?vis

-- 
Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola
Administrador de Redes - Secao de Informatica (SINFO)
E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br
Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010



From patmans at us.ibm.com  Thu Nov  3 16:31:40 2005
From: patmans at us.ibm.com (Patrick Mansfield)
Date: Thu, 3 Nov 2005 08:31:40 -0800
Subject: no provider for XFree86-devel dependency
In-Reply-To: <1130982121.3249.8.camel@localhost.localdomain>
References: <20051102220529.GA8499@us.ibm.com>
	<1130969536.15396.27.camel@rousalka.dyndns.org>
	<20051102230400.GA10707@us.ibm.com>
	<1130982121.3249.8.camel@localhost.localdomain>
Message-ID: <20051103163140.GA29999@us.ibm.com>

On Thu, Nov 03, 2005 at 12:42:01PM +1100, Rodd Clarkson wrote:
> On Wed, 2005-11-02 at 15:04 -0800, Patrick Mansfield wrote:

> > 
> > I guess the workaround is to install with "rpm --nodeps ...".
> 
> Ah, how about instead of working around this, you wait until the deps
> have been satisfied.

OK :-/

> I think it's worth saying that we are about to see some humongous
> changes with the introduction of the module xorg into rawhide (of which
> these issues are a part) but that, with a little patient a simple 'yum
> update' should just work.
> 
> While an 'rpm --nodeps' might _solve_ the problem in the short term, it
> might also create bigger problems in the long term, making more work for
> the developers to figure out because someone forced something to 'make
> it work'.
> 
> Sorry if this is too harsh, but the use of rawhide needs a little
> patience sometimes which include putting up with broken deps, broken
> packages and other stuff.  What rawhide doesn't need to 'artificial'
> breakage that adds another layer of complexity to and already complex
> task.

No problem at all, thanks for the information.

I did not think about later breakage it might cause. I'm new to FC devel,
and don't fully understand the development process used (i.e. seems that
it is expected for things like this be broken over multiple days), and I
also don't know future plans.

-- Patrick Mansfield



From jspaleta at gmail.com  Thu Nov  3 16:39:25 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 3 Nov 2005 11:39:25 -0500
Subject: Yum error
In-Reply-To: <436A3669.3020602@agr.unicamp.br>
References: <436A3669.3020602@agr.unicamp.br>
Message-ID: <604aa7910511030839w5c37b139j6947de9a5fe4b32c@mail.gmail.com>

On 11/3/05, Clovis Tristao <clovis at agr.unicamp.br> wrote:
> What's happening?
there are missing dependancies.... the error is pretty clear to me. 
Rawhide packages have errors due to packaging changes, this can and
will happen in rawhide with some frequency.

Please read over the archives of the test-list and devel-list.. this
has already been discussed.

And please, review the daily automatically generated build report
emails from rawhide.  Broken deps like this are usually caught and
reported in those daily reports.  Only the very brave or the very
foolish install updates from rawhide without at least skimming the
recent daily rawhide reports.

-jef" http://www.fedoraproject.org/wiki/JefSpaleta/TestingManifesto "Spaleta



From linux at pilot.org.ua  Thu Nov  3 18:35:38 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Thu, 3 Nov 2005 20:35:38 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
Message-ID: <20051103203538.10167c4a.linux@pilot.org.ua>

Denis Ovsienko
Russia, Moscow
Linux system administrator and developer
ValueCommerce/Russia

I develop /etc/net project (http://etcnet.org) and my goal is to integrate it
into Fedora Core.

I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux
development tree and should soon be seen in 3.0 version.
I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too,
but i haven't heard from them for last months.
My skills include 6 years Linux experience, several programming
languages, 5 years of mixed software development and system/network
administration and so on, but I guess it's not related much to my goal now.
I have reviewed current initscripts buglist.

Some bugs are not bugs in /etc/net:
#65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop...
#75390 it would be nice to tie bandwidth shaping into the networ...
#129820 initscripts maclist patch
#132252 Request for addition of routing rule config file
#132912 No additional IP addresses at ethX without aliased devices
#132925 initscripts use old ifconfig instead of iproute2
#154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup...
#168990 No ifup-gre/ifdown-gre scripts.
#170884 MTU of ethernet card can't be set before interface is up
#171763 Enhancement to initscripts

Some bugs gave me ideas how to improve /etc/net:
#59114 .d-style scripts for ifup/ifdown
#119952 RFE: Add hook for "local" network initialization
#124045 Support setting a metric on interface routes

The whole process, if we don't face some unexpected problems, should take
3 to 6 months. What I need:
1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages.
2. Probably some help with documentation.
How can we start?


pub   1024D/6D1844F2 2002-11-11
      Key fingerprint = AF2F DDAE 7EB3 4699 09FF  F0FC 00B1 6D41 6D18 44F2
uid                  Denis Ovsienko <linux at pilot.org.ua>
uid                  Denis Ovsienko (http://pilot.org.ua) <pilot at altlinux.ru>
sub   2048g/57B7ACBE 2002-11-11

-- 
    DO4-UANIC



From katzj at redhat.com  Thu Nov  3 19:09:45 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 03 Nov 2005 14:09:45 -0500
Subject: Needed dependency for all packages that require the D-Bus
	session bus
In-Reply-To: <1130876962.16531.68.camel@remedyz.boston.redhat.com>
References: <1130875516.16531.65.camel@remedyz.boston.redhat.com>
	<1130876018.645.1.camel@ignacio.lan>
	<1130876962.16531.68.camel@remedyz.boston.redhat.com>
Message-ID: <1131044986.11424.57.camel@bree.local.net>

On Tue, 2005-11-01 at 15:29 -0500, John (J5) Palmieri wrote: 
> On Tue, 2005-11-01 at 15:13 -0500, Ignacio Vazquez-Abrams wrote:
> > On Tue, 2005-11-01 at 15:05 -0500, John (J5) Palmieri wrote:
> > > All packages that require the use of the D-Bus session must add a
> > > requirement on dbus-x11.  This package brings in the dbus-launch utility
> > > that starts the session bus.  Without it the session bus does not get
> > > started.   It hasn't been a problem for most because comps brings in
> > > desktop-printing which has a requirement on dbus-x11.  For those who do
> > > not have this installed (nothing depends on desktop-printing so the
> > > situation can come up) will not get the dbus-x11 package and any
> > > application using the session bus will not be able to function at their
> > > full capacity.  Thank you.
> > 
> > Which package is it that actually invokes dbus-launch? Shouldn't that
> > package Require it instead?
> 
> xinitrc and no because it has logic to say if the dbus-launch binary
> does not exist don't run it.

But is this really a sensible configuration with our current desktop?
It's not like the dbus-x11 package is big and I can't think of a
convincing reason why you'd want X without it at this point.

Jeremy



From nicolas.mailhot at laposte.net  Thu Nov  3 19:17:29 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 03 Nov 2005 20:17:29 +0100
Subject: gnome-utils depends on -devel packages ?
Message-ID: <1131045450.23932.9.camel@rousalka.dyndns.org>

Hi,

This bit of today's rawhide seems seriously b0rked

--> Running transaction check
--> Processing Dependency: libgnome-devel for package: gnome-utils
--> Processing Dependency: gtk2-devel for package: gnome-utils
--> Processing Dependency: libgnomeui-devel for package: gnome-utils
--> Restarting Dependency Resolution with new changes.

A non -devel package should not pull in a bunch of -devel deps like this

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/20051103/8d04b1e8/attachment.sig>

From kwade at redhat.com  Thu Nov  3 19:51:31 2005
From: kwade at redhat.com (Karsten Wade)
Date: Thu, 03 Nov 2005 11:51:31 -0800
Subject: Draft RPM Guide available online
In-Reply-To: <20051103135951.GA7316@orient.maison.moi>
References: <1130963750.2928.27.camel@enki.eridu>
	<20051103135951.GA7316@orient.maison.moi>
Message-ID: <1131047491.5130.26.camel@erato.phig.org>

On Thu, 2005-11-03 at 14:59 +0100, Emmanuel Seyman wrote:
> On Wed, Nov 02, 2005 at 02:35:49PM -0600, Paul Nasrat wrote:
> >
> > I'm very pleased to announce that the Red Hat RPM Guide has been made
> > available under the Open Publication Licence, Version 1.0.
> 
> \o/
> 
> > http://fedora.redhat.com/docs/drafts/rpm-guide-en/
>                                                  ^^
> 
> Translation, translation!

Let's get it fixed before we translate it, ok?

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051103/3fe94cd8/attachment.sig>

From kwade at redhat.com  Thu Nov  3 19:52:40 2005
From: kwade at redhat.com (Karsten Wade)
Date: Thu, 03 Nov 2005 11:52:40 -0800
Subject: Draft RPM Guide available online
In-Reply-To: <1131010213.3400.87.camel@mururoa>
References: <1130963750.2928.27.camel@enki.eridu>
	<1131010213.3400.87.camel@mururoa>
Message-ID: <1131047560.5130.29.camel@erato.phig.org>

On Thu, 2005-11-03 at 10:30 +0100, Theodore Papadopoulo wrote:
> On Wed, 2005-11-02 at 14:35 -0600, Paul Nasrat wrote:
> > I'm very pleased to announce that the Red Hat RPM Guide has been made
> > available under the Open Publication Licence, Version 1.0.
> > 
> > http://fedora.redhat.com/docs/drafts/rpm-guide-en/
> 
> Any chance to get a pdf version ???

PDF build is still broken.

If any Java experts want to help us get Saxon and FOP built using gcj
for FC5, that would be great.  Please see recent threads on fedora-java-
devel-list.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051103/a700ef11/attachment.sig>

From jeff.pitman at gmail.com  Thu Nov  3 20:16:20 2005
From: jeff.pitman at gmail.com (Jeff Pitman)
Date: Thu, 3 Nov 2005 20:16:20 +0000
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051103203538.10167c4a.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
Message-ID: <6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>

On 11/3/05, Denis Ovsienko <linux at pilot.org.ua> wrote:
>
> How can we start?
>

Basically, you are advocating a rewrite of /etc/sysconfig/networking and
/etc/sysconfig/network-scripts. You may start with a detailed explanation as
to why the setup, that Redhat has provided, is not up to task.

--
-jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051103/6f26d125/attachment.htm>

From mharris at redhat.com  Thu Nov  3 20:30:08 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 03 Nov 2005 15:30:08 -0500
Subject: gtk2-devel needs XFree86-devel
In-Reply-To: <4369FE8C.2080607@math.unl.edu>
References: <20051102220630.17465.qmail@web33101.mail.mud.yahoo.com>
	<4369FE8C.2080607@math.unl.edu>
Message-ID: <436A7350.9030000@redhat.com>

Rex Dieter wrote:
> Steven I Usdansky wrote:
> 
>> error: Can't install gtk2-devel-2.8.6-3 at i386: no package provides
>> XFree86-devel. Shouldn't xorg-x11-devel provide this?
> 
> 
> xorg-x11-devel *does* provide XFree86-devel.
> 
> That is, unless you're using rawhide/development, then you should know 
> better. (-:

When we switched over from XFree86 to X.Org in Fedora Core 2, I
added a "Provides: XFree86-devel" to the xorg-x11-devel package,
intending to leave it there for one OS release, in order to
make transitioning easier for people.

It stayed their for 3 full OS releases, so I'm surprised that
that many packages out there still depend on it.  Now is a
good time for people to fix whatever packages never got updated
though.

We are transitioning to modular X for Fedora Core 5, in which
each individual X.Org library is in it's own src.rpm which
generates 2 binary subpackages.  A runtime library package of
the name "lib<libname>" and a development subpackage of the
name "lib<libname>-devel", which is the method prefered by
Fedora packaging guidelines.

The net result of splitting what used to be one monolithic
package full of libraries and one monolithic package full of
header files, into 41 individual library packages with 41
devel subpackages, is that "XFree86-devel" and "xorg-x11-devel"
no longer exist, because no one package provides them.

Packages which link to any individual X libraries, need to
drop any dependency on "XFree86-devel" or "xorg-x11-devel" now,
and specify the individual library-devel packages they need to
build.  To make this process much easier, I have added virtual
provides to the rawhide monolithic X packaging, so that people
can update to using the modular dependencies right now, before
modular X gets pushed to rawhide (really soon).

Right now, xorg-x11-devel continues to work, as monolithic X
still has that package, but it will be disappearing when modular
X hits rawhide too, so all Fedora, Fedora Extras, and other
repository package maintainers are encouraged to update all
rpm packages which link to X libraries, to use dependencies
of the form:

BuildRequires: libX11-devel
BuildRequires: libXt-devel
BuildRequires: libXft-devel

etc.

I'm going to post a web page describing all of this somewhere,
as well as other modularized-X changes, once I can spare the
time to put it together.

Hope this helps!



From mharris at redhat.com  Thu Nov  3 20:37:20 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 03 Nov 2005 15:37:20 -0500
Subject: IMPORTANT: xinitrc soon to be obsolete and replaced by
 xorg-x11-xinit and xorg-x11-xdm
Message-ID: <436A7500.3000903@redhat.com>

In the near future, modular X will be landing in rawhide as
many are aware.  One new change this will bring, is 2 new
packages:

xorg-x11-xdm
xorg-x11-xinit

The xdm package is new, because it is now it's own src.rpm, not
a subpackage of xorg-x11.  The xinit package contains the xinit
binary, and it's related scripts and whatnot.

A side effect of this, is that the "xinitrc" package which we
have shipped for many years, which contained the xinitrc scripts
and configs, and xdm scripts and configs - is now no longer
needed.

The various scripts/configs that were previously in "xinitrc"
will be moved into the xorg-x11-xinit or xorg-x11-xdm modular
X packages as appropriate.  This change will not occur until
modular X is integrated directly into the rawhide tree.

This message is just a heads up of this change, in order to
prepare other developers who might have packages which currently
depend on the "xinitrc" package, that depending on if/how
their package lists its dependencies, it may soon need to be
updated to do one of:

Requires: xorg-x11-xinit

or

Requires: xorg-x11-xdm

Possible packages that might be affected, are gdm, kdm, and
various i18n related packages such as input method servers.



From caillon at redhat.com  Thu Nov  3 20:50:56 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Thu, 03 Nov 2005 15:50:56 -0500
Subject: IMPORTANT: xinitrc soon to be obsolete and replaced by
 xorg-x11-xinit and xorg-x11-xdm
In-Reply-To: <436A7500.3000903@redhat.com>
References: <436A7500.3000903@redhat.com>
Message-ID: <436A7830.70706@redhat.com>

On 11/03/2005 03:37 PM, Mike A. Harris wrote:
> This message is just a heads up of this change, in order to
> prepare other developers who might have packages which currently
> depend on the "xinitrc" package, that depending on if/how
> their package lists its dependencies, it may soon need to be
> updated to do one of: 
I think fedora-maintainers is the better list for this sort of 
announcement.  Might want to copy that, too.



From igorm5 at vip.hr  Thu Nov  3 20:54:50 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 03 Nov 2005 21:54:50 +0100
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <436A040F.7010402@nicubunu.ro>
References: <4369FA0C.8080804@vip.hr>	<1131019720.11309.72.camel@localhost.localdomain>
	<436A040F.7010402@nicubunu.ro>
Message-ID: <436A791A.70706@vip.hr>

Nicu Buculei wrote:

> Caolan McNamara wrote:
>>On Thu, 2005-11-03 at 12:52 +0100, Igor Jagec wrote:
>>>Is there any chance to see the GNOME version of Open Office 2.0? SUSE
>>>10.0 and Ubuntu 5.10 have it, but not FC4 and Rawhide which uses some
>>>generic icon theme, or something. It looks much better...
>>What you mean is "the Novell version of the icons", rather than the
>>"GNOME version" as the gnome integration features and components are the
>>same in FC4, upstream and Novell/Ubuntu. There's no functional different
>>in that arena.
>>If you volunteer to verify that all the icons are correct, and there no
>>left arrows for used for "right" etc. then perhaps :-)
> As OOo changed the way it use icons, is really easy to change the icon 
> set, just replace the /usr/lib/openoffice.org/share/config/images.zip 
> file and you are done.

I'll try that, thanks.

> So is just a matter of "lifting" images.zip from a SUSE or Ubuntu 
> install and start testing.

I have FC4 Rawhide on my test partition so I can try to play with it,
thanks :)

> PS: I'm still thinking the Bluecurve OOo icon set from FC2-FC3 was the 
> most beautiful OOo icon set ever (despite the fact it was incomplete, 
> partly Bluecurve and partly Industrial)

That's what I was thinking about, Bluecurve icon set :) I'd like to see
my favorte Bluecurve set. Hope it would be designed, or something :)

Cheers!

-- 
Igor Jagec



From rodd at clarkson.id.au  Thu Nov  3 20:57:33 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 04 Nov 2005 07:57:33 +1100
Subject: rawhide report: 20051103 changes
In-Reply-To: <200511031247.jA3ClkLf011315@porkchop.devel.redhat.com>
References: <200511031247.jA3ClkLf011315@porkchop.devel.redhat.com>
Message-ID: <1131051453.2890.12.camel@localhost.localdomain>

On Thu, 2005-11-03 at 07:47 -0500, Build System wrote:

> kernel-2.6.14-1.1639_FC5
> ------------------------
> * Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
> - Switch ppc64 and ppc kernels to arch/powerpc
> - Add nvram driver back again
> - Fix ppc32 initrd with arch/powerpc
> 
> * Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
> - 2.6.14-git5
> - Fix up PPC configs in preparation for using arch/powerpc
> - Prevent kauditd from aborting suspend

It seems that the file
	/usr/src/kernels/2.6.14-1.1639_FC5-i686/arch/i386/Makefile
is missing from kernel-devel in 1639

Not sure whether this is an accident or deliberate, but this file exists
in 1635 and 1632.


R.

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From ellson at research.att.com  Thu Nov  3 21:23:15 2005
From: ellson at research.att.com (John Ellson)
Date: Thu, 03 Nov 2005 16:23:15 -0500
Subject: gnome-utils depends on -devel packages ?
In-Reply-To: <1131045450.23932.9.camel@rousalka.dyndns.org>
References: <1131045450.23932.9.camel@rousalka.dyndns.org>
Message-ID: <436A7FC3.3040203@research.att.com>

Nicolas Mailhot wrote:
> Hi,
>
> This bit of today's rawhide seems seriously b0rked
>
> --> Running transaction check
> --> Processing Dependency: libgnome-devel for package: gnome-utils
> --> Processing Dependency: gtk2-devel for package: gnome-utils
> --> Processing Dependency: libgnomeui-devel for package: gnome-utils
> --> Restarting Dependency Resolution with new changes.
>
> A non -devel package should not pull in a bunch of -devel deps like this
>
> Regards,
>
>   
See bug#172365.

Apparently will be fixed in tomorrow's updates.

John



From ellson at research.att.com  Thu Nov  3 21:28:29 2005
From: ellson at research.att.com (John Ellson)
Date: Thu, 03 Nov 2005 16:28:29 -0500
Subject: rawhide report: 20051103 changes
In-Reply-To: <1131051453.2890.12.camel@localhost.localdomain>
References: <200511031247.jA3ClkLf011315@porkchop.devel.redhat.com>
	<1131051453.2890.12.camel@localhost.localdomain>
Message-ID: <436A80FD.1070907@research.att.com>

Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 07:47 -0500, Build System wrote:
>
>   
>> kernel-2.6.14-1.1639_FC5
>> ------------------------
>> * Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
>> - Switch ppc64 and ppc kernels to arch/powerpc
>> - Add nvram driver back again
>> - Fix ppc32 initrd with arch/powerpc
>>
>> * Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
>> - 2.6.14-git5
>> - Fix up PPC configs in preparation for using arch/powerpc
>> - Prevent kauditd from aborting suspend
>>     
>
> It seems that the file
> 	/usr/src/kernels/2.6.14-1.1639_FC5-i686/arch/i386/Makefile
> is missing from kernel-devel in 1639
>
> Not sure whether this is an accident or deliberate, but this file exists
> in 1635 and 1632.
>
>
> R.
>
>   
I'm seeing the same problem with i686 kernels, but was surprised to
find that building the NVIDIA module works fine with the x86_64 kernel.

John



From wtogami at redhat.com  Thu Nov  3 21:35:39 2005
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 03 Nov 2005 16:35:39 -0500
Subject: FC5test1 devel freeze, November 14th
Message-ID: <436A82AB.9070701@redhat.com>

If you are involved in the development of Fedora Core as a packager,
here is information that will be relevant to you.

FC5test1 devel freeze now November 14th
=======================================
Rawhide is undergoing a large amount of churn as we are preparing for
the switch from monolithic to modular X.  Modular X is one of the larger
and more important changes of FC5, meaning we need extensive test
exposure.  For this reason the test1 devel freeze has been postponed
until November 14th.

http://fedora.redhat.com/participate/schedule/
Fedora Core 5 Development Schedule has been updated.

http://fedoraproject.org/wiki/DocsProject/Schedule
Participants of the Fedora Documentation project have an updated
schedule here for release notes content and translation deadlines.

If you are brave and willing to deal with the unpredictability of
rawhide, your assistance in testing, reporting and fixing bugs as we
approach the November 14th devel freeze would be greatly appreciated.

Modular X requires FE5 Fixes
============================
The major change created by modular X is that XFree86-devel and
xorg-x11-devel are no longer provided in the buildroot.  All packages in
both Core and Extras are now expected to have BuildRequires on the
individual libFOO-devel packages of the newly split modular X.  In order
to ease into this, the current monolithic xorg-x11 package in rawhide
contains many virtual provides for libFOO-devel.  Modular X itself will
hit rawhide *REAL SOON NOW*.

In addition to the lack of XFree86-devel and xorg-x11-devel,
/usr/X11R6/lib will disappear so packages that previously hardcoded this
path will need to be fixed.  mharris has indicated that he is preparing
a webpage with further details about modular X and things that need to
be fixed.

Unfortunately FC5 rawhide will not be consistent and suitable for many
FE5 builds until the entire modular X tree is pushed.   But when it does
happen, everyone's help will be needed to find problems in Core and
rebuild packages in Extras in order to rapidly prepare everything for test1.

Warren Togami
wtogami at redhat.com



From michael.favia at insitesinc.com  Thu Nov  3 22:51:59 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Thu, 03 Nov 2005 16:51:59 -0600
Subject: rt2x00 driver support in FC5
Message-ID: <436A948F.8090607@insitesinc.com>

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

The rt2x00 project provides ongoing support for the rt2400 rt2500 and
rt2570 chipsets that were open sourced (GPL) by RaLink. The chipset is
quite popular and used by a few dozen vendors (linksys most notably here
in US) in various PCI and USB based hardware:

http://rt2x00.serialmonkey.com/wiki/index.php/Hardware
http://ralink.rapla.net/

RT2x00 is aiming for eventual adoption into the kernel but a large
number of distros have taken initiative and included them in their
latest releases. A few of those distros:

* SuSE since 10.0
* debian (contrib)
* Gentoo (portage)
* Mandriva

Does fedora have any plans to include support for this hardware in FC5?
Fedora sure could use some help in the wireless support department and I
think this is a good addition that will get a large number of people off
of the inherent dangers of ndiswrapper. If you visit the site you will
notice 4 codebases (1 each 2400/2500/2570 and one 2x00 unification
project). While the unified project is most tempting it is also the
least developed and just began supporting association this week. The 3
individual projects however have a very stable codebase and report very
high success rates. I am also willing to help in any way possible.

- -mf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDapSOBVsNYjF2rDYRAjDCAJ9VYMsG1ZWaqbOEG7WuTAx93i15dgCgkSn4
y95xa61KmAhZdqBnz13femw=
=Oi/7
-----END PGP SIGNATURE-----



From bgerst at didntduck.org  Thu Nov  3 23:12:46 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Thu, 03 Nov 2005 18:12:46 -0500
Subject: rt2x00 driver support in FC5
In-Reply-To: <436A948F.8090607@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
Message-ID: <436A996E.1090408@didntduck.org>

Michael Favia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The rt2x00 project provides ongoing support for the rt2400 rt2500 and
> rt2570 chipsets that were open sourced (GPL) by RaLink. The chipset is
> quite popular and used by a few dozen vendors (linksys most notably here
> in US) in various PCI and USB based hardware:
> 
> http://rt2x00.serialmonkey.com/wiki/index.php/Hardware
> http://ralink.rapla.net/
> 
> RT2x00 is aiming for eventual adoption into the kernel but a large
> number of distros have taken initiative and included them in their
> latest releases. A few of those distros:
> 
> * SuSE since 10.0
> * debian (contrib)
> * Gentoo (portage)
> * Mandriva
> 
> Does fedora have any plans to include support for this hardware in FC5?
> Fedora sure could use some help in the wireless support department and I
> think this is a good addition that will get a large number of people off
> of the inherent dangers of ndiswrapper. If you visit the site you will
> notice 4 codebases (1 each 2400/2500/2570 and one 2x00 unification
> project). While the unified project is most tempting it is also the
> least developed and just began supporting association this week. The 3
> individual projects however have a very stable codebase and report very
> high success rates. I am also willing to help in any way possible.
> 
> - -mf
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDapSOBVsNYjF2rDYRAjDCAJ9VYMsG1ZWaqbOEG7WuTAx93i15dgCgkSn4
> y95xa61KmAhZdqBnz13femw=
> =Oi/7
> -----END PGP SIGNATURE-----
> 

Your best bet is to get the driver into the mainline kernel.  Fedora 
generally doesn't add external drivers to the kernel.

--
				Brian Gerst



From rodd at clarkson.id.au  Thu Nov  3 23:19:16 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 04 Nov 2005 10:19:16 +1100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <436A82AB.9070701@redhat.com>
References: <436A82AB.9070701@redhat.com>
Message-ID: <1131059956.2890.30.camel@localhost.localdomain>

On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> If you are involved in the development of Fedora Core as a packager,
> here is information that will be relevant to you.
> 
> FC5test1 devel freeze now November 14th
> =======================================
> Rawhide is undergoing a large amount of churn as we are preparing for
> the switch from monolithic to modular X.  Modular X is one of the larger
> and more important changes of FC5, meaning we need extensive test
> exposure.  For this reason the test1 devel freeze has been postponed
> until November 14th.

Warren,

While I know that the move to modular X is important, there's some other
nagging issues in rawhide that are going to drive the list mad if they
aren't addressed before test1 is released.

The most obvious of these (IMHO) is devices not appearing on desktop or
appearing to be mounted from Computer (et al) when they are indeed
mounted.

I also suspect that we're going to hear a lot from people with certain
Intel PCI chipsets who will suddenly find that they HDD/DVD performance
sucks in rawhide.  I know that work is being done on this in the kernel,
but that at this stage nothing concrete (that I'm aware of) has been
done.

This last I don't expect to be fixed, but if the one above could be
addressed before test1 then this should really alleviate rampant "my
drive isn't appearing on the desktop" and "my drive isn't showing as
mounted in Computer" emails from eager testers who don't bother to read
the list (and subsequent rude "read the archive" emails too.) ;-]


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From alan at redhat.com  Thu Nov  3 23:21:06 2005
From: alan at redhat.com (Alan Cox)
Date: Thu, 3 Nov 2005 18:21:06 -0500
Subject: rt2x00 driver support in FC5
In-Reply-To: <436A948F.8090607@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
Message-ID: <20051103232106.GB10379@devserv.devel.redhat.com>

On Thu, Nov 03, 2005 at 04:51:59PM -0600, Michael Favia wrote:
> project). While the unified project is most tempting it is also the
> least developed and just began supporting association this week. The 3
> individual projects however have a very stable codebase and report very
> high success rates. I am also willing to help in any way possible.

Fedora tracks upstream fairly closely so if it gets upstream it get into Fedora.
In the mean time various people on the list have been kicking around ideas for
improving the add on driver support in Fedora extras and that seems to be the right
place to start



From davej at redhat.com  Thu Nov  3 23:30:05 2005
From: davej at redhat.com (Dave Jones)
Date: Thu, 3 Nov 2005 18:30:05 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131059956.2890.30.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
Message-ID: <20051103233005.GD32757@redhat.com>

On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:

 > I also suspect that we're going to hear a lot from people with certain
 > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
 > sucks in rawhide.  I know that work is being done on this in the kernel,
 > but that at this stage nothing concrete (that I'm aware of) has been
 > done.

Which bugzilla number is this ?  My Intel chipset boxes run current
rawhide just fine, so I'm puzzled by this.

		Dave



From jon.nettleton at gmail.com  Thu Nov  3 23:37:03 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 03 Nov 2005 18:37:03 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131059956.2890.30.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
Message-ID: <1131061024.10196.8.camel@averatec>

On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> > If you are involved in the development of Fedora Core as a packager,
> > here is information that will be relevant to you.
> > 
> > FC5test1 devel freeze now November 14th
> > =======================================
> > Rawhide is undergoing a large amount of churn as we are preparing for
> > the switch from monolithic to modular X.  Modular X is one of the larger
> > and more important changes of FC5, meaning we need extensive test
> > exposure.  For this reason the test1 devel freeze has been postponed
> > until November 14th.
> 
> Warren,
> 
> While I know that the move to modular X is important, there's some other
> nagging issues in rawhide that are going to drive the list mad if they
> aren't addressed before test1 is released.
> 
> The most obvious of these (IMHO) is devices not appearing on desktop or
> appearing to be mounted from Computer (et al) when they are indeed
> mounted.

This problem is fixed in Hal cvs.  We are working on a timetable for a
0.5.5 release, that will include these changes.  Some of the
accompanying problems, like the duplicating cdrom icon, are bugs in
gnome-vfs.  I have submitted patches but I have no idea when and if they
will be pulled into a new gnome-vfs release.

> 
> I also suspect that we're going to hear a lot from people with certain
> Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> sucks in rawhide.  I know that work is being done on this in the kernel,
> but that at this stage nothing concrete (that I'm aware of) has been
> done.
> 
> This last I don't expect to be fixed, but if the one above could be
> addressed before test1 then this should really alleviate rampant "my
> drive isn't appearing on the desktop" and "my drive isn't showing as
> mounted in Computer" emails from eager testers who don't bother to read
> the list (and subsequent rude "read the archive" emails too.) ;-]
> 
> 
> Rodd
> 
> -- 
> "It's a fine line between denial and faith.
>  It's much better on my side"
> 

Jon



From rodd at clarkson.id.au  Thu Nov  3 23:54:00 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 04 Nov 2005 10:54:00 +1100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <20051103233005.GD32757@redhat.com>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<20051103233005.GD32757@redhat.com>
Message-ID: <1131062040.2890.34.camel@localhost.localdomain>

On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
> On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
> 
>  > I also suspect that we're going to hear a lot from people with certain
>  > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
>  > sucks in rawhide.  I know that work is being done on this in the kernel,
>  > but that at this stage nothing concrete (that I'm aware of) has been
>  > done.
> 
> Which bugzilla number is this ?  My Intel chipset boxes run current
> rawhide just fine, so I'm puzzled by this.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363

I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
capable of playing a DVD smoothly, or burning DVD/CDs disks at full
speed.

Or has something changed since this bug was posted that has improved the
situation and I no longer need ide0=noprobe?


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From davej at redhat.com  Fri Nov  4 00:03:42 2005
From: davej at redhat.com (Dave Jones)
Date: Thu, 3 Nov 2005 19:03:42 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131062040.2890.34.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<20051103233005.GD32757@redhat.com>
	<1131062040.2890.34.camel@localhost.localdomain>
Message-ID: <20051104000342.GE32757@redhat.com>

On Fri, Nov 04, 2005 at 10:54:00AM +1100, Rodd Clarkson wrote:
 > On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
 > > On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
 > > 
 > >  > I also suspect that we're going to hear a lot from people with certain
 > >  > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
 > >  > sucks in rawhide.  I know that work is being done on this in the kernel,
 > >  > but that at this stage nothing concrete (that I'm aware of) has been
 > >  > done.
 > > 
 > > Which bugzilla number is this ?  My Intel chipset boxes run current
 > > rawhide just fine, so I'm puzzled by this.
 > 
 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363
 > 
 > I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
 > capable of playing a DVD smoothly, or burning DVD/CDs disks at full
 > speed.
 > 
 > Or has something changed since this bug was posted that has improved the
 > situation and I no longer need ide0=noprobe?

The PATA vs SATA bug got nuked about 2 weeks ago, so the noprobe thing
shouldn't be needed any more.

the last comment in that bz also suggests all is well now.

		Dave



From ellson at research.att.com  Fri Nov  4 00:05:11 2005
From: ellson at research.att.com (John Ellson)
Date: Thu, 03 Nov 2005 19:05:11 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131061024.10196.8.camel@averatec>
References: <436A82AB.9070701@redhat.com>	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec>
Message-ID: <436AA5B7.5050502@research.att.com>

Jon Nettleton wrote:
> On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
>   
>> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
>>     
>>> If you are involved in the development of Fedora Core as a packager,
>>> here is information that will be relevant to you.
>>>
>>> FC5test1 devel freeze now November 14th
>>> =======================================
>>> Rawhide is undergoing a large amount of churn as we are preparing for
>>> the switch from monolithic to modular X.  Modular X is one of the larger
>>> and more important changes of FC5, meaning we need extensive test
>>> exposure.  For this reason the test1 devel freeze has been postponed
>>> until November 14th.
>>>       
>> Warren,
>>
>> While I know that the move to modular X is important, there's some other
>> nagging issues in rawhide that are going to drive the list mad if they
>> aren't addressed before test1 is released.
>>
>> The most obvious of these (IMHO) is devices not appearing on desktop or
>> appearing to be mounted from Computer (et al) when they are indeed
>> mounted.
>>     
>
> This problem is fixed in Hal cvs.  We are working on a timetable for a
> 0.5.5 release, that will include these changes.

Will this also fix the problems with USB cameras  (all 457 different 
types of USB camera, afaict) ?  

John



From jon.nettleton at gmail.com  Fri Nov  4 00:10:05 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Thu, 03 Nov 2005 19:10:05 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <436AA5B7.5050502@research.att.com>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec> <436AA5B7.5050502@research.att.com>
Message-ID: <1131063006.10196.12.camel@averatec>

On Thu, 2005-11-03 at 19:05 -0500, John Ellson wrote:
> Jon Nettleton wrote:
> > On Fri, 2005-11-04 at 10:19 +1100, Rodd Clarkson wrote:
> >   
> >> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> >>     
> >>> If you are involved in the development of Fedora Core as a packager,
> >>> here is information that will be relevant to you.
> >>>
> >>> FC5test1 devel freeze now November 14th
> >>> =======================================
> >>> Rawhide is undergoing a large amount of churn as we are preparing for
> >>> the switch from monolithic to modular X.  Modular X is one of the larger
> >>> and more important changes of FC5, meaning we need extensive test
> >>> exposure.  For this reason the test1 devel freeze has been postponed
> >>> until November 14th.
> >>>       
> >> Warren,
> >>
> >> While I know that the move to modular X is important, there's some other
> >> nagging issues in rawhide that are going to drive the list mad if they
> >> aren't addressed before test1 is released.
> >>
> >> The most obvious of these (IMHO) is devices not appearing on desktop or
> >> appearing to be mounted from Computer (et al) when they are indeed
> >> mounted.
> >>     
> >
> > This problem is fixed in Hal cvs.  We are working on a timetable for a
> > 0.5.5 release, that will include these changes.
> 
> Will this also fix the problems with USB cameras  (all 457 different 
> types of USB camera, afaict) ?  
> 
> John
> 

These fixes are all limited to removable storage.  I was unaware that
there were problems with USB cameras.  Do you have a bugzilla I can
reference?

Jon



From mharris at redhat.com  Fri Nov  4 00:10:21 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 03 Nov 2005 19:10:21 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131059956.2890.30.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
Message-ID: <436AA6ED.5020608@redhat.com>

Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> 
>>If you are involved in the development of Fedora Core as a packager,
>>here is information that will be relevant to you.
>>
>>FC5test1 devel freeze now November 14th
>>=======================================
>>Rawhide is undergoing a large amount of churn as we are preparing for
>>the switch from monolithic to modular X.  Modular X is one of the larger
>>and more important changes of FC5, meaning we need extensive test
>>exposure.  For this reason the test1 devel freeze has been postponed
>>until November 14th.
> 
> 
> Warren,
> 
> While I know that the move to modular X is important, there's some other
> nagging issues in rawhide that are going to drive the list mad if they
> aren't addressed before test1 is released.
> 
> The most obvious of these (IMHO) is devices not appearing on desktop or
> appearing to be mounted from Computer (et al) when they are indeed
> mounted.
> 
> I also suspect that we're going to hear a lot from people with certain
> Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> sucks in rawhide.  I know that work is being done on this in the kernel,
> but that at this stage nothing concrete (that I'm aware of) has been
> done.
> 
> This last I don't expect to be fixed, but if the one above could be
> addressed before test1 then this should really alleviate rampant "my
> drive isn't appearing on the desktop" and "my drive isn't showing as
> mounted in Computer" emails from eager testers who don't bother to read
> the list (and subsequent rude "read the archive" emails too.) ;-]

Make sure these issues get filed in bugzilla as soon as they're
discovered, in order to maximize the chances of them getting
fixed sooner rather than later.

If everyone does their part in reporting bugs, it greatly helps
to get the distro in better shape earlier.

Thanks in advance, and thanks for testing!

TTYL



From usdanskys at rocketmail.com  Fri Nov  4 00:23:18 2005
From: usdanskys at rocketmail.com (Steven I Usdansky)
Date: Thu, 3 Nov 2005 16:23:18 -0800 (PST)
Subject: Java in firefox-1.5-0.5.0.beta2
Message-ID: <20051104002318.50672.qmail@web33106.mail.mud.yahoo.com>

The test:  http://www.time.gov/timezone.cgi?Central/d/-6/java
works fine with firefox-1.0.7-1.1.fc4, no time display with
firefox-1.5-0.5.0.beta2

-- 
Steven I. Usdansky, PhD
Traveling Geologist
Registered Linux user #360200




===========================
Steven I. Usdansky, PhD
Rock Doctor


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



From sundaram at redhat.com  Fri Nov  4 00:29:13 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 04 Nov 2005 05:59:13 +0530
Subject: Java in firefox-1.5-0.5.0.beta2
In-Reply-To: <20051104002318.50672.qmail@web33106.mail.mud.yahoo.com>
References: <20051104002318.50672.qmail@web33106.mail.mud.yahoo.com>
Message-ID: <436AAB59.9070709@redhat.com>

Steven I Usdansky wrote:

>The test:  http://www.time.gov/timezone.cgi?Central/d/-6/java
>works fine with firefox-1.0.7-1.1.fc4, no time display with
>firefox-1.5-0.5.0.beta2
>
>  
>
You might want to file this in http://bugzilla.mozilla.org. Fedora 
doesnt include the Sun JVM

regards
Rahul



From katzj at redhat.com  Fri Nov  4 00:28:29 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 03 Nov 2005 19:28:29 -0500
Subject: rt2x00 driver support in FC5
In-Reply-To: <436A948F.8090607@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
Message-ID: <1131064110.11424.74.camel@bree.local.net>

On Thu, 2005-11-03 at 16:51 -0600, Michael Favia wrote:
> RT2x00 is aiming for eventual adoption into the kernel but a large
> number of distros have taken initiative and included them in their
> latest releases. A few of those distros:

How is it good enough for distros but not for the mainline kernel?

> Does fedora have any plans to include support for this hardware in FC5?

The general policy is to only ship things which are included in the
upstream kernel to help keep maintenance of the kernel package
"sane".[1]

Jeremy

[1] You'll note that I didn't say keep davej sane -- that has been
written off as impossible ;-)



From usdanskys at rocketmail.com  Fri Nov  4 00:33:35 2005
From: usdanskys at rocketmail.com (Steven I Usdansky)
Date: Thu, 3 Nov 2005 16:33:35 -0800 (PST)
Subject: Java in firefox-1.5-0.5.0.beta2
Message-ID: <20051104003335.13027.qmail@web33109.mail.mud.yahoo.com>

-- On Thu, 3 Nov 2005 16:23:18 -0800 (PST)
Steven I Usdansky <usdanskys at rocketmail.com> attempted to state:

> The test:  http://www.time.gov/timezone.cgi?Central/d/-6/java
> works fine with firefox-1.0.7-1.1.fc4, no time display with
> firefox-1.5-0.5.0.beta2
> 

Turns out the culprit is the adblock-0.5.2.039-fx.xpi plugin
-- 
Steven I. Usdansky, PhD
Traveling Geologist
Registered Linux user #360200




===========================
Steven I. Usdansky, PhD
Rock Doctor


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com



From gawain.lynch at bigpond.com  Fri Nov  4 00:02:54 2005
From: gawain.lynch at bigpond.com (Gawain Lynch)
Date: Fri, 04 Nov 2005 13:02:54 +1300
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131062040.2890.34.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<20051103233005.GD32757@redhat.com>
	<1131062040.2890.34.camel@localhost.localdomain>
Message-ID: <1131062574.2798.1.camel@legolas.felicity.net.au>

On Fri, 2005-11-04 at 10:54 +1100, Rodd Clarkson wrote:
> On Thu, 2005-11-03 at 18:30 -0500, Dave Jones wrote:
> > On Fri, Nov 04, 2005 at 10:19:16AM +1100, Rodd Clarkson wrote:
> > 
> >  > I also suspect that we're going to hear a lot from people with certain
> >  > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> >  > sucks in rawhide.  I know that work is being done on this in the kernel,
> >  > but that at this stage nothing concrete (that I'm aware of) has been
> >  > done.
> > 
> > Which bugzilla number is this ?  My Intel chipset boxes run current
> > rawhide just fine, so I'm puzzled by this.
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363
> 
> I'm having to ide0=noprobe for mine, and my DVD performance sucks (in
> capable of playing a DVD smoothly, or burning DVD/CDs disks at full
> speed.
> 
> Or has something changed since this bug was posted that has improved the
> situation and I no longer need ide0=noprobe?
> 

Yes, same problem hit FC4 and is gone now...

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169569



From ellson at research.att.com  Fri Nov  4 02:47:23 2005
From: ellson at research.att.com (John Ellson)
Date: Thu, 03 Nov 2005 21:47:23 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131063006.10196.12.camel@averatec>
References: <436A82AB.9070701@redhat.com>	<1131059956.2890.30.camel@localhost.localdomain>	<1131061024.10196.8.camel@averatec>
	<436AA5B7.5050502@research.att.com>
	<1131063006.10196.12.camel@averatec>
Message-ID: <436ACBBB.6090309@research.att.com>

Jon Nettleton wrote:
>
>>>> The most obvious of these (IMHO) is devices not appearing on desktop or
>>>> appearing to be mounted from Computer (et al) when they are indeed
>>>> mounted.
>>>>     
>>>>         
>>> This problem is fixed in Hal cvs.  We are working on a timetable for a
>>> 0.5.5 release, that will include these changes.
>>>       
>> Will this also fix the problems with USB cameras  (all 457 different 
>> types of USB camera, afaict) ?  
>>
>> John
>>
>>     
>
> These fixes are all limited to removable storage.  I was unaware that
> there were problems with USB cameras.  Do you have a bugzilla I can
> reference?
>
> Jon
>
>   
Yes:  #170690, #168933, #150985, #165914


John



From rc040203 at freenet.de  Fri Nov  4 03:02:59 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Fri, 04 Nov 2005 04:02:59 +0100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <436A82AB.9070701@redhat.com>
References: <436A82AB.9070701@redhat.com>
Message-ID: <1131073379.19437.294.camel@mccallum.corsepiu.local>

On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> If you are involved in the development of Fedora Core as a packager,
> here is information that will be relevant to you.

> Modular X requires FE5 Fixes
> ============================
> The major change created by modular X is that XFree86-devel and
> xorg-x11-devel are no longer provided in the buildroot.  All packages in
> both Core and Extras are now expected to have BuildRequires on the
> individual libFOO-devel packages of the newly split modular X.  In order
> to ease into this, the current monolithic xorg-x11 package in rawhide
> contains many virtual provides for libFOO-devel.  Modular X itself will
> hit rawhide *REAL SOON NOW*.

Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
compatibility?

Ralf




From rodd at clarkson.id.au  Fri Nov  4 03:40:33 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Fri, 04 Nov 2005 14:40:33 +1100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <436AA6ED.5020608@redhat.com>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<436AA6ED.5020608@redhat.com>
Message-ID: <1131075633.6754.1.camel@localhost.localdomain>

On Thu, 2005-11-03 at 19:10 -0500, Mike A. Harris wrote:
> Rodd Clarkson wrote:
> > On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> > 
> >>If you are involved in the development of Fedora Core as a packager,
> >>here is information that will be relevant to you.
> >>
> >>FC5test1 devel freeze now November 14th
> >>=======================================
> >>Rawhide is undergoing a large amount of churn as we are preparing for
> >>the switch from monolithic to modular X.  Modular X is one of the larger
> >>and more important changes of FC5, meaning we need extensive test
> >>exposure.  For this reason the test1 devel freeze has been postponed
> >>until November 14th.
> > 
> > 
> > Warren,
> > 
> > While I know that the move to modular X is important, there's some other
> > nagging issues in rawhide that are going to drive the list mad if they
> > aren't addressed before test1 is released.
> > 
> > The most obvious of these (IMHO) is devices not appearing on desktop or
> > appearing to be mounted from Computer (et al) when they are indeed
> > mounted.
> > 
> > I also suspect that we're going to hear a lot from people with certain
> > Intel PCI chipsets who will suddenly find that they HDD/DVD performance
> > sucks in rawhide.  I know that work is being done on this in the kernel,
> > but that at this stage nothing concrete (that I'm aware of) has been
> > done.
> > 
> > This last I don't expect to be fixed, but if the one above could be
> > addressed before test1 then this should really alleviate rampant "my
> > drive isn't appearing on the desktop" and "my drive isn't showing as
> > mounted in Computer" emails from eager testers who don't bother to read
> > the list (and subsequent rude "read the archive" emails too.) ;-]
> 
> Make sure these issues get filed in bugzilla as soon as they're
> discovered, in order to maximize the chances of them getting
> fixed sooner rather than later.

Both have already been bugzilla'd for some time now.

> If everyone does their part in reporting bugs, it greatly helps
> to get the distro in better shape earlier.

That's what I do with fedora, report bugs.  I don't code, but I can test
(and if people help me a little I can get the right info to help track
down bugs too ;-])

> Thanks in advance, and thanks for testing!

You're welcome


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From igorm5 at vip.hr  Fri Nov  4 05:50:59 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Fri, 04 Nov 2005 06:50:59 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <20051103232106.GB10379@devserv.devel.redhat.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
Message-ID: <436AF6C3.6090609@vip.hr>

Alan Cox wrote:

> Fedora tracks upstream fairly closely so if it gets upstream it get into Fedora.
> In the mean time various people on the list have been kicking around ideas for
> improving the add on driver support in Fedora extras and that seems to be the right
> place to start

I can definitely agree with that. Speaking about rt2500 which I use
myself, I would be very happy to see at least the SRPM package but there
is no even generic spec file in the archive so we always need to compile
it ourselves. It can be very annoying when you have to install rt2500
drivers on more than one machine.

-- 
Igor Jagec



From bob.deblier at telenet.be  Fri Nov  4 05:59:57 2005
From: bob.deblier at telenet.be (Bob Deblier)
Date: Fri, 04 Nov 2005 05:59:57 +0000
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
Message-ID: <W8379431175319541131083997@nocme1bl6.telenet-ops.be>

>-----Original Message-----
>From: Jeff Pitman [mailto:jeff.pitman at gmail.com]
>Sent: Thursday, November 3, 2005 09:16 PM
>To: 'Development discussions related to Fedora Core'
>Subject: Re: Self-Introduction: Denis Ovsienko and /etc/net project
>
>On 11/3/05, Denis Ovsienko <linux at pilot.org.ua> wrote:
>>
>> How can we start?
>>
>
>Basically, you are advocating a rewrite of /etc/sysconfig/networking and
>/etc/sysconfig/network-scripts. You may start with a detailed explanation as
>to why the setup, that Redhat has provided, is not up to task.

Just my 2 cents worth:

Wireless WPA support is a glaring omission, for one. The wpa_supplicant software doesn't integrate well with the current RedHat scripts.

Sincerely,

Bob Deblier





From michael.favia at insitesinc.com  Fri Nov  4 06:40:09 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Fri, 04 Nov 2005 00:40:09 -0600
Subject: rt2x00 driver support in FC5
In-Reply-To: <20051103232106.GB10379@devserv.devel.redhat.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
Message-ID: <436B0249.5030504@insitesinc.com>

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

Alan Cox wrote:
> Fedora tracks upstream fairly closely so if it gets upstream it get into Fedora.
> In the mean time various people on the list have been kicking around ideas for
> improving the add on driver support in Fedora extras and that seems to be the right
> place to start
I was afraid i was going to get a alexendar dumas style "wait and hope"
response. It is also probably the right one in order to maintain a
semblance of sanity in the kernel maintenance department. With releases
coming every few months i suppose it isnt much to ask people to wait for
its inclusion. I'll see what i can chase down in extras in the meantime.
Thanks for the response.

- --
Michael Favia          michael.favia at insitesinc.com
Insites Incorporated  http://michael.insitesinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDawJIBVsNYjF2rDYRAlzgAJ0XaMklJZHE6CpufMhzR4SRB2SFxgCfbzRA
r/IiEP9eRMXX4eJKlu9zjbQ=
=nPRK
-----END PGP SIGNATURE-----



From arjanv at redhat.com  Fri Nov  4 07:05:53 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 04 Nov 2005 08:05:53 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <436B0249.5030504@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
	<436B0249.5030504@insitesinc.com>
Message-ID: <1131087953.2799.0.camel@laptopd505.fenrus.org>

On Fri, 2005-11-04 at 00:40 -0600, Michael Favia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alan Cox wrote:
> > Fedora tracks upstream fairly closely so if it gets upstream it get into Fedora.
> > In the mean time various people on the list have been kicking around ideas for
> > improving the add on driver support in Fedora extras and that seems to be the right
> > place to start
> I was afraid i was going to get a alexendar dumas style "wait and hope"
> response. It is also probably the right one in order to maintain a
> semblance of sanity in the kernel maintenance department. With releases
> coming every few months i suppose it isnt much to ask people to wait for
> its inclusion. I'll see what i can chase down in extras in the meantime.
> Thanks for the response.
> 

you don't have to be passive about it! You can either help the rt guys
submit it, or ask them if they are ok with you submitting it....
Open source is all about being able to change the course of events
yourself.... and there is a big sign next to the road here saying where
to go ;)



From dwmw2 at infradead.org  Fri Nov  4 07:56:47 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 04 Nov 2005 07:56:47 +0000
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <20051102171934.GA32638@redhat.com>
References: <1130796189.3690.3.camel@coyote.rexursive.com>
	<dka22g$o04$1@sea.gmane.org>  <20051102171934.GA32638@redhat.com>
Message-ID: <1131091007.10031.183.camel@baythorne.infradead.org>

On Wed, 2005-11-02 at 12:19 -0500, Dave Jones wrote:
>  > Did anyone see/file a bug on this? I can't seem to find any and we'd 
>  > probably like something like this to be fixed!
> 
> It's already in bugzilla.

And should be fixed in rawhide.

But you shouldn't have a kauditd running unless you've actually done
something to enable auditing -- did you?

-- 
dwmw2




From alexl at redhat.com  Fri Nov  4 08:44:24 2005
From: alexl at redhat.com (Alexander Larsson)
Date: Fri, 04 Nov 2005 09:44:24 +0100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131061024.10196.8.camel@averatec>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec>
Message-ID: <1131093864.26733.38.camel@greebo>

On Thu, 2005-11-03 at 18:37 -0500, Jon Nettleton wrote:

> > The most obvious of these (IMHO) is devices not appearing on desktop or
> > appearing to be mounted from Computer (et al) when they are indeed
> > mounted.
> 
> This problem is fixed in Hal cvs.  We are working on a timetable for a
> 0.5.5 release, that will include these changes.  Some of the
> accompanying problems, like the duplicating cdrom icon, are bugs in
> gnome-vfs.  I have submitted patches but I have no idea when and if they
> will be pulled into a new gnome-vfs release.

I commited the patch in
http://bugzilla.gnome.org/show_bug.cgi?id=319689 , but its a bit strange
that the second patch is identical to the first. Did you attach the
wrong file?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a suicidal flyboy dog-catcher living undercover at Ringling Bros. Circus. 
She's a vivacious Buddhist bounty hunter with her own daytime radio talk show. 
They fight crime! 



From michael.favia at insitesinc.com  Fri Nov  4 09:29:01 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Fri, 04 Nov 2005 03:29:01 -0600
Subject: rt2x00 driver support in FC5
In-Reply-To: <1131087953.2799.0.camel@laptopd505.fenrus.org>
References: <436A948F.8090607@insitesinc.com>	<20051103232106.GB10379@devserv.devel.redhat.com>	<436B0249.5030504@insitesinc.com>
	<1131087953.2799.0.camel@laptopd505.fenrus.org>
Message-ID: <436B29DD.1050703@insitesinc.com>

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

Arjan van de Ven wrote:
> On Fri, 2005-11-04 at 00:40 -0600, Michael Favia wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Alan Cox wrote:
>>
>>>Fedora tracks upstream fairly closely so if it gets upstream it get into Fedora.
>>>In the mean time various people on the list have been kicking around ideas for
>>>improving the add on driver support in Fedora extras and that seems to be the right
>>>place to start
>>
>>I was afraid i was going to get a alexendar dumas style "wait and hope"
>>response. It is also probably the right one in order to maintain a
>>semblance of sanity in the kernel maintenance department. With releases
>>coming every few months i suppose it isnt much to ask people to wait for
>>its inclusion. I'll see what i can chase down in extras in the meantime.
>>Thanks for the response.
>>
> you don't have to be passive about it! You can either help the rt guys
> submit it, or ask them if they are ok with you submitting it....
> Open source is all about being able to change the course of events
> yourself.... and there is a big sign next to the road here saying where
> to go ;)

Sorry I think that came off wrong. I meant i was going to chase down the
possibilities for getting it into extras in some form (as ac mentioned)
while the unified driver is being stabilized for kernel submission. As a
quick follow up though:

Would you suggest trying to get the (more stable) separate drivers
included upstream while the unified driver codebase settles down?
Meaning, is it a smart move to try to push something in that will be
functionally replaced in a year? If it isnt terribly difficult to
transition from one driver to the next then where should i start? I've
never tried to push any patches into the upstream kernel and don't know
the politics (link or short explanation would be great). :) Thanks.

- -mf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDayndBVsNYjF2rDYRApGLAJ41I4+ALWwHFomPd5VxskM9LRk6RACeJu77
RafM+og6+A1ZUOtkD6jNIPo=
=75cQ
-----END PGP SIGNATURE-----



From arjanv at redhat.com  Fri Nov  4 09:34:51 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 4 Nov 2005 10:34:51 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <436B29DD.1050703@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
	<436B0249.5030504@insitesinc.com>
	<1131087953.2799.0.camel@laptopd505.fenrus.org>
	<436B29DD.1050703@insitesinc.com>
Message-ID: <20051104093451.GA8296@devserv.devel.redhat.com>

On Fri, Nov 04, 2005 at 03:29:01AM -0600, Michael Favia wrote:
> 
> Would you suggest trying to get the (more stable) separate drivers
> included upstream while the unified driver codebase settles down?
> Meaning, is it a smart move to try to push something in that will be
> functionally replaced in a year? If it isnt terribly difficult to

a year is a long time, so long that I'd say try the existing one. Changing
drivers later isn't that big a deal.

> transition from one driver to the next then where should i start? I've
> never tried to push any patches into the upstream kernel and don't know
> the politics (link or short explanation would be great). :) Thanks.

The "politics" as you call them aren't that bad:

1) you need to submit the code as a patch to linux-kernel at vger.kernel.org
2) people will review your patch and will comment on it for 2 reasons
   1) point out things/bugs that really need to be fixed 
   2) see if you respond to issues that are pointed out
3) you fix the stuff that came up, and go back to 1) 

depending on the quality of the driver 1 or 2 cycles are enough most of the
time.

It pays to first check and make sure the driver conforms to the standard
linux coding style (see Documentation/CodingStyle.txt). This is not to
nitpick about cosmetics, but the reviewers can review code a whole lot
faster if it has a cosmetic style.

Greetings,
    Arjan van de Ven



From arjanv at redhat.com  Fri Nov  4 09:40:39 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 04 Nov 2005 10:40:39 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <20051104093451.GA8296@devserv.devel.redhat.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
	<436B0249.5030504@insitesinc.com>
	<1131087953.2799.0.camel@laptopd505.fenrus.org>
	<436B29DD.1050703@insitesinc.com>
	<20051104093451.GA8296@devserv.devel.redhat.com>
Message-ID: <1131097239.2799.6.camel@laptopd505.fenrus.org>


> It pays to first check and make sure the driver conforms to the standard
> linux coding style (see Documentation/CodingStyle.txt). This is not to
> nitpick about cosmetics, but the reviewers can review code a whole lot
> faster if it has a cosmetic style.

eh consistent not cosmetic




From davej at redhat.com  Fri Nov  4 09:45:55 2005
From: davej at redhat.com (Dave Jones)
Date: Fri, 4 Nov 2005 04:45:55 -0500
Subject: rt2x00 driver support in FC5
In-Reply-To: <20051104093451.GA8296@devserv.devel.redhat.com>
References: <436A948F.8090607@insitesinc.com>
	<20051103232106.GB10379@devserv.devel.redhat.com>
	<436B0249.5030504@insitesinc.com>
	<1131087953.2799.0.camel@laptopd505.fenrus.org>
	<436B29DD.1050703@insitesinc.com>
	<20051104093451.GA8296@devserv.devel.redhat.com>
Message-ID: <20051104094555.GA26239@redhat.com>

On Fri, Nov 04, 2005 at 10:34:51AM +0100, Arjan van de Ven wrote:
 > On Fri, Nov 04, 2005 at 03:29:01AM -0600, Michael Favia wrote:
 > > 
 > > Would you suggest trying to get the (more stable) separate drivers
 > > included upstream while the unified driver codebase settles down?
 > > Meaning, is it a smart move to try to push something in that will be
 > > functionally replaced in a year? If it isnt terribly difficult to
 > 
 > a year is a long time, so long that I'd say try the existing one.

You've not seen the existing one I take it ? :)
It's likely a lot less effort to beat the new driver into shape
than to fix up the mess of the old driver, which reinvented
a whole bunch of things the kernel has, and looked like a mangled
windows driver the last time I saw it.

The rewrite takes advantage of things like the in-kernel 80211 core,
and has been written with kernel style in mind.  There may still
be some nits, but it's defintly going in the right direction.

		Dave



From jon.nettleton at gmail.com  Fri Nov  4 12:39:26 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Fri, 04 Nov 2005 07:39:26 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131093864.26733.38.camel@greebo>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec> <1131093864.26733.38.camel@greebo>
Message-ID: <1131107966.4070.7.camel@averatec>

On Fri, 2005-11-04 at 09:44 +0100, Alexander Larsson wrote:
> On Thu, 2005-11-03 at 18:37 -0500, Jon Nettleton wrote:
> 
> > > The most obvious of these (IMHO) is devices not appearing on desktop or
> > > appearing to be mounted from Computer (et al) when they are indeed
> > > mounted.
> > 
> > This problem is fixed in Hal cvs.  We are working on a timetable for a
> > 0.5.5 release, that will include these changes.  Some of the
> > accompanying problems, like the duplicating cdrom icon, are bugs in
> > gnome-vfs.  I have submitted patches but I have no idea when and if they
> > will be pulled into a new gnome-vfs release.
> 
> I commited the patch in
> http://bugzilla.gnome.org/show_bug.cgi?id=319689 , but its a bit strange
> that the second patch is identical to the first. Did you attach the
> wrong file?

Thanks.  That second patch is the wrong version.  I was bouncing from my
desktop to laptop and forgot to sync up my patches directory.  I have
uploaded the proper version of the patch to bugzilla.  If you would like
I can make a smaller one against what you have already committed.

> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc 
>                    alexl at redhat.com    alla at lysator.liu.se 
> He's a suicidal flyboy dog-catcher living undercover at Ringling Bros. Circus. 
> She's a vivacious Buddhist bounty hunter with her own daytime radio talk show. 
> They fight crime! 
> 

Jon



From tmus at tmus.dk  Fri Nov  4 13:15:42 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 04 Nov 2005 14:15:42 +0100
Subject: Suspend to disk with 2.6.14-1.1635_FC5
In-Reply-To: <1131091007.10031.183.camel@baythorne.infradead.org>
References: <1130796189.3690.3.camel@coyote.rexursive.com>	<dka22g$o04$1@sea.gmane.org>
	<20051102171934.GA32638@redhat.com>
	<1131091007.10031.183.camel@baythorne.infradead.org>
Message-ID: <dkfmu6$fms$1@sea.gmane.org>

David Woodhouse wrote:
> On Wed, 2005-11-02 at 12:19 -0500, Dave Jones wrote:
>>  > Did anyone see/file a bug on this? I can't seem to find any and we'd 
>>  > probably like something like this to be fixed!
>>
>> It's already in bugzilla.
> 
> And should be fixed in rawhide.
> 
> But you shouldn't have a kauditd running unless you've actually done
> something to enable auditing -- did you?
> 

Auditing is enabled all-the-time, right?

My recently installed rawhide system has kaudit running and I didn't ask 
it to. Also, i seem to recall from earlier experience that it's really 
not possible to disable auditing at runtime?!?

I could be mistaken!

/Thomas



From jon.nettleton at gmail.com  Fri Nov  4 13:51:56 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Fri, 04 Nov 2005 08:51:56 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <436ACBBB.6090309@research.att.com>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec> <436AA5B7.5050502@research.att.com>
	<1131063006.10196.12.camel@averatec>
	<436ACBBB.6090309@research.att.com>
Message-ID: <1131112317.13011.4.camel@averatec>

On Thu, 2005-11-03 at 21:47 -0500, John Ellson wrote:
> Jon Nettleton wrote:
> >
> >>>> The most obvious of these (IMHO) is devices not appearing on desktop or
> >>>> appearing to be mounted from Computer (et al) when they are indeed
> >>>> mounted.
> >>>>     
> >>>>         
> >>> This problem is fixed in Hal cvs.  We are working on a timetable for a
> >>> 0.5.5 release, that will include these changes.
> >>>       
> >> Will this also fix the problems with USB cameras  (all 457 different 
> >> types of USB camera, afaict) ?  
> >>
> >> John
> >>
> >>     
> >
> > These fixes are all limited to removable storage.  I was unaware that
> > there were problems with USB cameras.  Do you have a bugzilla I can
> > reference?
> >
> > Jon
> >
> >   
> Yes:  #170690, #168933, #150985, #165914
> 
> 
> John
> 

If the camera is seen as a removable usb storage device, which it sounds
like these are, then yes it will.  The quick way to tell if it will fix
your problem is look in the /media directory.  If you camera is being
properly mounted in there and the only problem is it is not showing up
on the nautilus desktop or in drive applet, then these problems are
mostly resolved.

Jon



From bmillett at gmail.com  Fri Nov  4 14:04:52 2005
From: bmillett at gmail.com (Brian Millett)
Date: Fri, 04 Nov 2005 08:04:52 -0600
Subject: what happened to the i386 repo?
Message-ID: <1131113093.3779.3.camel@localhost.localdomain>

Hi, what happened to the development repo?

   [DIR] Parent Directory   -
   [DIR] SRPMS/ 04-Nov-2005 06:50 -
   [DIR] ia64/ 04-Nov-2005 06:50 -
   [DIR] ppc/ 04-Nov-2005 06:50 -
   [DIR] ppc64/ 04-Nov-2005 06:50 -
   [DIR] s390/ 04-Nov-2005 06:50 -
   [DIR] s390x/ 04-Nov-2005 06:50 -
   [DIR] x86_64/ 04-Nov-2005 06:50 -

??

Getting ready for something?
-- 
Brian Millett - [ Dr. Franklin and Londo, "Soul Mates"]
"Londo, do you know where you are?"
'Either in Medlab or in hell. Either way the decor needs work.'




From nphilipp at redhat.com  Fri Nov  4 16:24:44 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 04 Nov 2005 17:24:44 +0100
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131073379.19437.294.camel@mccallum.corsepiu.local>
References: <436A82AB.9070701@redhat.com>
	<1131073379.19437.294.camel@mccallum.corsepiu.local>
Message-ID: <1131121484.14465.4.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2005-11-04 at 04:02 +0100, Ralf Corsepius wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> > If you are involved in the development of Fedora Core as a packager,
> > here is information that will be relevant to you.
> 
> > Modular X requires FE5 Fixes
> > ============================
> > The major change created by modular X is that XFree86-devel and
> > xorg-x11-devel are no longer provided in the buildroot.  All packages in
> > both Core and Extras are now expected to have BuildRequires on the
> > individual libFOO-devel packages of the newly split modular X.  In order
> > to ease into this, the current monolithic xorg-x11 package in rawhide
> > contains many virtual provides for libFOO-devel.  Modular X itself will
> > hit rawhide *REAL SOON NOW*.
> 
> Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
> to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
> compatibility?

Now that would be so _nice_. Mike, pretty please?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From nphilipp at redhat.com  Fri Nov  4 16:27:17 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 04 Nov 2005 17:27:17 +0100
Subject: what happened to the i386 repo?
In-Reply-To: <1131113093.3779.3.camel@localhost.localdomain>
References: <1131113093.3779.3.camel@localhost.localdomain>
Message-ID: <1131121638.14465.6.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2005-11-04 at 08:04 -0600, Brian Millett wrote:
> Hi, what happened to the development repo?
> 
>    [DIR] Parent Directory   -
>    [DIR] SRPMS/ 04-Nov-2005 06:50 -
>    [DIR] ia64/ 04-Nov-2005 06:50 -
>    [DIR] ppc/ 04-Nov-2005 06:50 -
>    [DIR] ppc64/ 04-Nov-2005 06:50 -
>    [DIR] s390/ 04-Nov-2005 06:50 -
>    [DIR] s390x/ 04-Nov-2005 06:50 -
>    [DIR] x86_64/ 04-Nov-2005 06:50 -
> 
> ??
> 
> Getting ready for something?

No, in a moment of confusion the Grinch ate it, albeit a few weeks
early.

SCNR,
Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From buildsys at redhat.com  Fri Nov  4 17:42:13 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 4 Nov 2005 12:42:13 -0500
Subject: rawhide report: 20051104 changes
Message-ID: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>

New package GFS
	GFS - The Global File System

New package GFS-kernel
	GFS-kernel - The Global File System kernel modules

New package ccs
	CCS - The Cluster Configuration System

New package cman
	cman - The Cluster Manager

New package cman-kernel
	cman-kernel - The Cluster Manager kernel modules

New package dlm
	dlm - The Distributed Lock Manager

New package dlm-kernel
	dlm-kernel - The Distributed Lock Manager kernel modules.

New package fence
	fence - The cluster I/O fencing system

New package gnbd
	gnbd - GFS's Network Block Device

New package gnbd-kernel
	gnbd-kernel - The kernel module for GFS's Network Block Device

New package gulm
	gulm - One possible lock manager for GFS

New package iddev
	iddev is a library that identifies device contents.

New package libnl
	Convenience library for kernel netlink sockets

New package magma
	A cluster/lock manager API abstraction library

New package magma-plugins
	Cluster manager plugins for magma

New package rgmanager
	Open Source HA Resource Group Failover for Red Hat Enterprise Linux

New package rgmanager
	Open Source HA Resource Group Failover for Red Hat Enterprise Linux


 
Updated Packages:

GConf2-2.12.1-1
---------------
* Thu Nov 03 2005 Alexander Larsson <alexl at redhat.com> - 2.12.1-1
- Update to 2.12.1

ImageMagick-6.2.5.4-1
---------------------
* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 6.2.5.4-1
- Switch requires to modular X
- Update to 6.2.5

* Tue Sep 20 2005 Matthias Clasen <mclasen at redhat.com> 6.2.4.6-1
- Update to 6.2.4-6
- Drop upstreamed patches
- Disable DPS (#158984)
- Add missing requires (#165931)

OpenIPMI-1.4.14-11
------------------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-11
- Rebuild to link against new net-snmp libs.

ant-0:1.6.5-0jpp_1fc
--------------------
* Thu Nov 03 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:1.6.5-0jpp_1fc
- Changed the Release from 2fc to 0jpp_1fc on the assumption that we
  are going to want to resync this package with JPackage if/when the
  latter releases ant-1.6.5-1jpp.

arts-8:1.4.92-2
---------------
* Fri Nov 04 2005 Than Ngo <than at redhat.com> 8:1.4.92-2
- fix lnusertemp problem #169631

audit-1.0.9-1
-------------
* Wed Nov 02 2005 Steve Grubb <sgrubb at redhat.com> 1.0.9-1
- Updated message types that auditd recognizes
- Added a couple more message types
- Added new standard logging format function
- Update default config
- Make ausearch -m take a list of message types

autofs-1:4.1.4-12
-----------------
* Thu Nov 03 2005 Jeff Moyer <jmoyer at redhat.com> - 1:4.1.4-12
- The sort command no longer accepts options of the form "+0".  This broke
  auto.net, so the option was removed.  Fixes bz #172111.

checkpolicy-1.27.17-4
---------------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-4
- Rebuild to get latest libsepol

ethereal-0.10.13-3
------------------
* Thu Nov 03 2005 Radek Vokal <rvokal at redhat.com> 0.10.13-3
- fix in IRC dissectors - CVE-2005-3313 (#172298)

file-roller-2.12.1-2
--------------------
* Thu Nov 03 2005 Christopher Aillon <caillon at redhat.com> 2.12.1-2
- Add 7-zip to the desktop file, since file-roller supports it

firefox-1.5-0.5.0.rc1
---------------------
* Thu Nov 03 2005 Christopher Aillon <caillon at redhat.com> - 1.5-0.5.0.rc1
- Update to 1.5 rc1
- Clean up the default bookmarks

gd-2.0.33-5
-----------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-5
- Switched BuildPreReqs and Requires to modular xorg-x11 style

* Mon Oct 10 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-4
- Fixed possible gd crash when drawing AA line near image borders (#167843)

* Wed Sep 07 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.33-3
- Fixed broken freetype-config --libs flags in configure (#165875)

gnome-games-1:2.12.1-4
----------------------
* Wed Nov 02 2005 Ray Strode <rstrode at redhat.com> 1:2.12.1-4
- don't link to howl now that we aren't using it

gnome-keyring-manager-2.12.0-2
------------------------------
* Wed Nov 02 2005 Matthias Clasen <mclasen at redhat.com> 2.12.0-2
- Avoid the error dialog if there is no default keyring.

gnome-utils-1:2.13.1-2
----------------------
* Thu Nov 03 2005 Ray Strode <rstrode at redhat.com> - 1:2.13.1-2
- remove unnecessary Requires (bug 172365)
- use make install DESTDIR instead of %makeinstall

* Tue Nov 01 2005 Ray Strode <rstrode at redhat.com> - 1:2.13.1-1
- update to gnome-utils 2.13.1

* Thu Oct 13 2005 Tomas Mraz <tmraz at redhat.com>
- use include config-util instead of pam_stack in pam config

gnuplot-4.0.0-10
----------------
* Wed Nov 02 2005 Phil Knirsch <pknirsch at redhat.com> 4.0.0-10
- Switched BuildPreReqs and Requires to modular xorg-x11 style

gtk+-1:1.2.10-45
----------------
* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-45
- Switch requires to modular X

gtk2-2.8.6-5
------------
* Mon Oct 31 2005 Matthias Clasen <mclasen at redhat.com> 2.8.6-5
- Switch requires to modular X

httpd-2.0.54-15
---------------
* Thu Nov 03 2005 Joe Orton <jorton at redhat.com> 2.0.54-15
- log notice giving SELinux context at startup if enabled
- drop SSLv2 and restrict default cipher suite in default
 SSL configuration

imlib-1:1.9.13-25
-----------------
* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 1:1.9.13-25
- Switch requires to modular X

jonas-0:4.3.3-1jpp_14fc
-----------------------
* Fri Nov 04 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_14fc
- Many testsuite fixes (from Andrew Haley).

kde-i18n-1:3.4.92-2
-------------------
* Thu Nov 03 2005 Than Ngo <than at redhat.com> 1:3.4.92-2
- add workaround for files conflict in Polish #171870

kdelibs-6:3.4.92-2
------------------
* Fri Nov 04 2005 Than Ngo <than at redhat.com> 6:3.4.92-2
- move lnusertemp in arts, workaround for #169631

kdeutils-6:3.4.92-3
-------------------
* Thu Nov 03 2005 Than Ngo <than at redhat.com> 3.4.92-3 
- rebuilt against new net-snmp

* Fri Oct 28 2005 Than Ngo <than at redhat.com> 6:3.4.92-2
- apply patch to initialize correctly the variables

kernel-2.6.14-1.1642_FC5
------------------------
* Thu Nov 03 2005 Dave Jones <davej at redhat.com>
- prereq new kudzu. (Should fix upgrades for mptfusion users)
- 2.6.14-git6
- Copy all Makefiles to -devel packages.

* Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
- Switch ppc64 and ppc kernels to arch/powerpc
- Add nvram driver back again
- Fix ppc32 initrd with arch/powerpc

* Wed Nov 02 2005 David Woodhouse <dwmw2 at redhat.com>
- 2.6.14-git5
- Fix up PPC configs in preparation for using arch/powerpc
- Prevent kauditd from aborting suspend

kexec-tools-1.101-4
-------------------

libselinux-1.27.18-1
--------------------
* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.18-1
* Merged seusers empty level handling patch from Jonathan Kim (TCS).

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-4
- Rebuild for latest libsepol

libsepol-1.9.36-1
-----------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.9.36-1
- Upgrade to latest from NSA
	* Merged context_to_string interface change patch from Ivan Gyurdiev.

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.9.35-1
- Upgrade to latest from NSA
	* Added src/dso.h and src/*_internal.h.
	  Added hidden_def for exported symbols used within libsepol.
	  Added hidden for symbols that should not be exported by
	  the wildcards in libsepol.map.

log4j-0:1.2.8-7jpp_6fc
----------------------
* Thu Nov 03 2005 Archit Shah <ashah at redhat.com> 0:1.2.8-7jpp_6fc
- Reenable building of example that uses rmic

logwatch-7.0-2
--------------
* Wed Nov 02 2005 Ivana Varekova <varekova at redhat.com> 7.0-2
- fix zz-disk_space problem (bug 172230) 
  used michal at harddata.com patch
- fix a few inconsistencies with new directory structure
- changed previous zz-disk_space 
- add secure sript patch allow case insensitivity for GID, UID)

ntp-4.2.0.a.20050816-9
----------------------
* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-9
- Rebuild

* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-8
- Rebuild

* Wed Nov 02 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-7
- Rebuild

nut-2.0.2-2
-----------
* Thu Nov 03 2005 Than Ngo <than at redhat.com> 2.0.2-2
- rebuilt against new libnetsnmp

openhpi-2.0.3-3
---------------
* Thu Nov 03 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.3-3
- Rebuild against new net-snmp libs

openoffice.org-1:2.0.0-3.7.2
----------------------------
* Fri Oct 28 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.0-3.7
- rh#171918# wrong LDAP stuff gets launched from wizard
- upstream patches as cmcfixes20
- rh#171844# make another stab at the klipper problem
- ooo#57107# updated hindi translation
- rh#159381# be less of a gcj bigot
- rh#172149# need more stuff in the classpath for macro creating

openswan-2.4.2-0.dr5.1
----------------------
* Wed Nov 02 2005 Harald Hoyer <harald at redhat.com> - 2.4.2-0.dr5.1
- version 2.4.2dr5

pango-1.10.1-5
--------------
* Fri Nov 04 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.1-5
- Switch buildrequires to modular X.
- Don't install .la files for modules.

* Thu Oct 27 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.1-2
- Bump the requirement for glib (#165928)

perl-DBD-Pg-1.43-2
------------------
* Thu Nov 03 2005 Florian La Roche <laroche at redhat.com>
- make sure correct Provides: are generated for this module

ppp-2.4.3-5
-----------
* Fri Nov 04 2005 David Woodhouse <dwmw2 at redhat.com> 2.4.3-5
- Implement ipv6cp-accept-remote option

pykickstart-0.8-1
-----------------
* Thu Nov 03 2005 Chris Lumens <clumens at redhat.com> 0.8-1
- Default to SELINUX_ENFORCING.
- Default partition sizes to None for anaconda (#172378).
- Don't call shlex.split on anything inside a script (#172313).

redhat-menus-5.0.5-1
--------------------
* Fri Oct 28 2005 Matthias Clasen <mclasen at redhat.com> 5.0.5-1
- Hide usermount by default

selinux-policy-mls-1.27.2-13
----------------------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-13
- Add Russell's patch for sendmail
- Fix postfix and cyrus interaction

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-12
- Add Russell patch to allow transition to strict policy
- Allow pegasus to use pam
- Add back transtion from unconfined_t to httpd_t

selinux-policy-strict-1.27.2-13
-------------------------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-13
- Add Russell's patch for sendmail
- Fix postfix and cyrus interaction

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-12
- Add Russell patch to allow transition to strict policy
- Allow pegasus to use pam
- Add back transtion from unconfined_t to httpd_t

selinux-policy-targeted-1.27.2-13
---------------------------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-13
- Add Russell's patch for sendmail
- Fix postfix and cyrus interaction

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-12
- Add Russell patch to allow transition to strict policy
- Allow pegasus to use pam
- Add back transtion from unconfined_t to httpd_t

setools-2.2-1
-------------
* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 2.2
- Upgrade to upstream version

shared-mime-info-0.16.cvs20051018-2
-----------------------------------
* Wed Nov 02 2005 John (J5) Palmieri <johnp at redhat.com> - 0.16.cvs20051018-2
- Change all refs of eog to gthumb in defaults.list

sharutils-4.6-2
---------------
* Thu Nov 03 2005 Than Ngo <than at redhat.com> 4.6-2
- fix wrong permission #171889

smartmontools-1:5.33-2
----------------------
* Thu Nov 03 2005 Tomas Mraz <tmraz at redhat.com> 1:5.33-2
- Spec file cleanup by Robert Scheck <redhat at linuxnetz.de> (#170959)
- manual release numbering
- remove bogus patch of non-installed file
- only non-removable drives should be added to smartd.conf
- smartd.conf should be owned (#171498)

* Tue Oct 25 2005 Dave Jones <davej at redhat.com>
- Add comments to generated smartd.conf (#135397)

stunnel-4.14-1
--------------
* Thu Nov 03 2005 Miloslav Trmac <mitr at redhat.com> - 4.14-1
- Update to stunnel-4.14
- Override changed default pid file location, keep it in /var/run

system-config-kickstart-2.6.1-1
-------------------------------
* Thu Nov 03 2005 Chris Lumens <clumens at redhat.com> 2.6.1-1
- Remove requirement on rhpxl since we can work around it.

* Wed Nov 02 2005 Chris Lumens <clumens at redhat.com> 2.6.0-1
- Use pykickstart instead of our own kickstart file parsing code.

system-config-network-1.3.30-2
------------------------------
* Wed Nov 02 2005 Harald Hoyer <harald at redhat.com> - 1.3.30
- removed interdruid
- reversed Cancel/Ok button ordering

tar-1.15.1-11
-------------
* Fri Nov 04 2005 Peter Vrabec <pvrabec at redhat.com> 1.15.1-11
- correctly pad archive members that shrunk during archiving (#172373)

tftp-0.41-1
-----------
* Thu Nov 03 2005 Radek Vokal <rvokal at redhat.com> 0.41-1
- upstream update (patterns fixes)

tzdata-2005n-2
--------------
* Wed Nov 02 2005 Jakub Jelinek <jakub at redhat.com> 2005n-2
- 2005n
  - changes for Kyrgyzstan and Uruguay
- fix a typo in the Makefile (used TZDATA env var instead of TZDIR during
  make check), update tst-timezone.c from glibc CVS (#172102)

Broken deps for ia64
----------------------------------------------------------
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5



Broken deps for i386
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)



Broken deps for s390x
----------------------------------------------------------
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel



Broken deps for s390
----------------------------------------------------------
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel




To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,arjanv at REDHAT.COM
Subject: Broken dependencies: cman-kernel




cman-kernel has broken dependencies in the development tree:
On x86_64:
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
On x86_64:
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
On ppc:
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
On ppc64:
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
Please resolve this as soon as possible.



To: devel_orphan at REDHAT.COM
Cc: davej at REDHAT.COM,arjanv at REDHAT.COM
Subject: Broken dependencies: gnbd-kernel




gnbd-kernel has broken dependencies in the development tree:
On i386:
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
On i386:
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
On ppc:
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
On x86_64:
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
On x86_64:
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
On ppc64:
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,arjanv at REDHAT.COM
Subject: Broken dependencies: dlm-kernel




dlm-kernel has broken dependencies in the development tree:
On i386:
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
On ppc:
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
On ppc64:
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
On x86_64:
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
On x86_64:
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
On i386:
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
Please resolve this as soon as possible.



To: twoerner at REDHAT.COM
Cc: 
Subject: Broken dependencies: SDL




SDL has broken dependencies in the development tree:
On ia64:
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
On x86_64:
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
On i386:
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
On ppc:
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
On s390:
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
On ppc64:
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
On s390x:
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel
Please resolve this as soon as possible.



To: twaugh at REDHAT.COM
Cc: 
Subject: Broken dependencies: hplip




hplip has broken dependencies in the development tree:
On i386:
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5
On x86_64:
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
On x86_64:
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
On ppc:
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
On ppc64:
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
On ppc:
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
On ia64:
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
On ia64:
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
On i386:
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
On ppc64:
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
Please resolve this as soon as possible.



To: than at REDHAT.COM
Cc: 
Subject: Broken dependencies: nut




nut has broken dependencies in the development tree:
On s390:
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5
On s390x:
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,arjanv at REDHAT.COM
Subject: Broken dependencies: GFS-kernel




GFS-kernel has broken dependencies in the development tree:
On i386:
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
On x86_64:
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
On i386:
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
On x86_64:
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
On i386:
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
On ppc:
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
Please resolve this as soon as possible.



To: lhh at REDHAT.COM
Cc: jbrassow at REDHAT.COM
Subject: Broken dependencies: rgmanager




rgmanager has broken dependencies in the development tree:
On ia64:
	rgmanager - 1.9.31-3.ia64 requires ccs
Please resolve this as soon as possible.




From gajownik at fedora.pl  Fri Nov  4 17:49:11 2005
From: gajownik at fedora.pl (Dawid Gajownik)
Date: Fri, 04 Nov 2005 18:49:11 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <436A948F.8090607@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
Message-ID: <436B9F17.8000104@fedora.pl>

Dnia 11/03/2005 11:51 PM, U?ytkownik Michael Favia napisa?:

> RT2x00 is aiming for eventual adoption into the kernel but a large
> number of distros have taken initiative and included them in their
> latest releases. A few of those distros:
> 
> * SuSE since 10.0
> * debian (contrib)
> * Gentoo (portage)
> * Mandriva

http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=243

EOT :P

-- 

   ^_*




From brilong at cisco.com  Fri Nov  4 17:51:21 2005
From: brilong at cisco.com (Brian Long)
Date: Fri, 04 Nov 2005 12:51:21 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
Message-ID: <1131126681.3969.51.camel@brilong-lnx>

On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:

Is Red Hat's build system proprietary or is it also open-sourced?  :)

/Brian/

-- 
       Brian Long                      |         |           |
       IT Data Center Systems          |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s



From michael.favia at insitesinc.com  Fri Nov  4 17:53:21 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Fri, 04 Nov 2005 11:53:21 -0600
Subject: rt2x00 driver support in FC5
In-Reply-To: <436B9F17.8000104@fedora.pl>
References: <436A948F.8090607@insitesinc.com> <436B9F17.8000104@fedora.pl>
Message-ID: <436BA011.6050807@insitesinc.com>

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

Dawid Gajownik wrote:
> Dnia 11/03/2005 11:51 PM, U?ytkownik Michael Favia napisa?:
> 
>> RT2x00 is aiming for eventual adoption into the kernel but a large
>> number of distros have taken initiative and included them in their
>> latest releases. A few of those distros:
>>
>> * SuSE since 10.0
>> * debian (contrib)
>> * Gentoo (portage)
>> * Mandriva
> 
> 
> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=243
> 
> EOT :P
> 

Actually they have since recanted this stance after i asked them about
it. But it has been decided that upstream is the way fedora would best
like to handle it anyway.
- -mf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDa6ARBVsNYjF2rDYRAnY4AJkBByTZigrzNvLr1ain58EJaUwSwACbBSr8
VVEFVbZIS66Y39c6hXfdIbI=
=KxRo
-----END PGP SIGNATURE-----



From dennis at ausil.us  Fri Nov  4 18:13:36 2005
From: dennis at ausil.us (Dennis Gilmore)
Date: Fri, 4 Nov 2005 12:13:36 -0600
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131126681.3969.51.camel@brilong-lnx>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>
Message-ID: <200511041213.36948.dennis@ausil.us>

On Friday 04 November 2005 11:51, Brian Long wrote:
> On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
>
> Is Red Hat's build system proprietary or is it also open-sourced?  :)
>
bee hive used for RHEL and Fedora Core is propietory to Red Hat but plague 
that is used for Extras is very much opensource  if you have extras 
configured  yum install plague*   will get you rolling

Dennis



From skvidal at phy.duke.edu  Fri Nov  4 18:20:05 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Nov 2005 13:20:05 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <200511041213.36948.dennis@ausil.us>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>
	<200511041213.36948.dennis@ausil.us>
Message-ID: <1131128405.28400.15.camel@cutter>

On Fri, 2005-11-04 at 12:13 -0600, Dennis Gilmore wrote:
> On Friday 04 November 2005 11:51, Brian Long wrote:
> > On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> >
> > Is Red Hat's build system proprietary or is it also open-sourced?  :)
> >
> bee hive used for RHEL and Fedora Core is propietory to Red Hat but plague 
> that is used for Extras is very much opensource  if you have extras 
> configured  yum install plague*   will get you rolling

I hope that someday soon we'll be able to build fedora core in plague,
too.

-sv




From ellson at research.att.com  Fri Nov  4 21:17:40 2005
From: ellson at research.att.com (John Ellson)
Date: Fri, 04 Nov 2005 16:17:40 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131112317.13011.4.camel@averatec>
References: <436A82AB.9070701@redhat.com>	<1131059956.2890.30.camel@localhost.localdomain>	<1131061024.10196.8.camel@averatec>
	<436AA5B7.5050502@research.att.com>	<1131063006.10196.12.camel@averatec>	<436ACBBB.6090309@research.att.com>
	<1131112317.13011.4.camel@averatec>
Message-ID: <436BCFF4.9050006@research.att.com>

Jon Nettleton wrote:
> On Thu, 2005-11-03 at 21:47 -0500, John Ellson wrote:
>   
>> Jon Nettleton wrote:
>>     
>>>>>> The most obvious of these (IMHO) is devices not appearing on desktop or
>>>>>> appearing to be mounted from Computer (et al) when they are indeed
>>>>>> mounted.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> This problem is fixed in Hal cvs.  We are working on a timetable for a
>>>>> 0.5.5 release, that will include these changes.
>>>>>       
>>>>>           
>>>> Will this also fix the problems with USB cameras  (all 457 different 
>>>> types of USB camera, afaict) ?  
>>>>
>>>> John
>>>>
>>>>     
>>>>         
>>> These fixes are all limited to removable storage.  I was unaware that
>>> there were problems with USB cameras.  Do you have a bugzilla I can
>>> reference?
>>>
>>> Jon
>>>
>>>   
>>>       
>> Yes:  #170690, #168933, #150985, #165914
>>
>>
>> John
>>
>>     
>
> If the camera is seen as a removable usb storage device, which it sounds
> like these are, then yes it will.  The quick way to tell if it will fix
> your problem is look in the /media directory.  If you camera is being
> properly mounted in there and the only problem is it is not showing up
> on the nautilus desktop or in drive applet, then these problems are
> mostly resolved.
>
> Jon
>
>   
The camera is not currently showing up in /media, but running gphoto2 as 
root finds it OK.
I currently have hal-0.5.4.  I'll try again when hal-0.5.5 shows up.

John



From sundaram at redhat.com  Fri Nov  4 21:30:36 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 05 Nov 2005 03:00:36 +0530
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131075633.6754.1.camel@localhost.localdomain>
References: <436A82AB.9070701@redhat.com>	<1131059956.2890.30.camel@localhost.localdomain>	<436AA6ED.5020608@redhat.com>
	<1131075633.6754.1.camel@localhost.localdomain>
Message-ID: <436BD2FC.5040904@redhat.com>

Hi

>That's what I do with fedora, report bugs.  I don't code, but I can test
>(and if people help me a little I can get the right info to help track
>down bugs too ;-])
>  
>
Reporting bugs is a very useful thing to do. Might also want to look at 
bug triaging

http://fedoraproject.org/wiki/BugZappers

regards
Rahul



From mihamina.rakotomandimby at etu.univ-orleans.fr  Fri Nov  4 21:44:19 2005
From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina)
Date: Fri, 04 Nov 2005 22:44:19 +0100
Subject: FC5 or not
Message-ID: <1131140659.2285.6.camel@localhost.localdomain>

Hi,
I am running FC4 but with testing and developpement repos enabled.
Am I FC4 or FC5-rc-somewhat?

-- 
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads & documentation.
Free hosting of CPS groupware: http://www.objectis.org.



From nicolas.mailhot at laposte.net  Fri Nov  4 21:44:32 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 04 Nov 2005 22:44:32 +0100
Subject: FC5 or not
In-Reply-To: <1131140659.2285.6.camel@localhost.localdomain>
References: <1131140659.2285.6.camel@localhost.localdomain>
Message-ID: <1131140673.10387.21.camel@rousalka.dyndns.org>

Le vendredi 04 novembre 2005 ? 22:44 +0100, Rakotomandimby Mihamina a
?crit :
> Hi,
> I am running FC4 but with testing and developpement repos enabled.
> Am I FC4 or FC5-rc-somewhat?

If you've synced with devel you're closer to FC5test1 than to FC4

-- 
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/20051104/74a64812/attachment.sig>

From rodd at clarkson.id.au  Fri Nov  4 21:45:13 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sat, 05 Nov 2005 08:45:13 +1100
Subject: FC5 or not
In-Reply-To: <1131140659.2285.6.camel@localhost.localdomain>
References: <1131140659.2285.6.camel@localhost.localdomain>
Message-ID: <1131140714.3107.20.camel@localhost.localdomain>

On Fri, 2005-11-04 at 22:44 +0100, Rakotomandimby Mihamina wrote:
> Hi,
> I am running FC4 but with testing and developpement repos enabled.
> Am I FC4 or FC5-rc-somewhat?

Hmmm, you could be running a little of each.

When you enable to development stuff, you also need to disable to FC4
stuff too, otherwise you're pulling packages from both sources.

Development and extras-development are all you should need to update to
rawhide.


R.

PS.  This isn't really a question for the development list.  Try the
fedora-test-list which is probably more appropriate.

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From sundaram at redhat.com  Fri Nov  4 21:47:10 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 05 Nov 2005 03:17:10 +0530
Subject: FC5 or not
In-Reply-To: <1131140659.2285.6.camel@localhost.localdomain>
References: <1131140659.2285.6.camel@localhost.localdomain>
Message-ID: <436BD6DE.9030305@redhat.com>

Rakotomandimby Mihamina wrote:

>Hi,
>I am running FC4 but with testing and developpement repos enabled.
>Am I FC4 or FC5-rc-somewhat?
>
>  
>
If you have been enabled the development repository and updated your 
packages, you are running the Fedora development version which will at a 
later point become Fedora Core 5. If you are interested in running the 
development version, you might want to read this for guidelines

http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide

regards
Rahul



From pjones at redhat.com  Fri Nov  4 23:00:56 2005
From: pjones at redhat.com (Peter Jones)
Date: Fri, 04 Nov 2005 18:00:56 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
Message-ID: <1131145257.2844.7.camel@localhost.localdomain>

On Thu, 2005-11-03 at 20:16 +0000, Jeff Pitman wrote:
> 
> On 11/3/05, Denis Ovsienko <linux at pilot.org.ua> wrote:
>         How can we start?
> 
> Basically, you are advocating a rewrite of /etc/sysconfig/networking
> and /etc/sysconfig/network-scripts. You may start with a detailed
> explanation as to why the setup, that Redhat has provided, is not up
> to task.

While you're at it, some thoughts on why this sort of change is
worthwhile in a NetworkManager world would be good, too.

(And don't say "because NM doesn't handle the server case", etc, because
obviously it'll eventually have to handle many of those cases, so we
don't wind up with two conflicting systems for network setup on one
machine.  We should all try to skip over the rather rhetorical "NM
doesn't have $FOO feature yet" lines of thought ;)
-- 
  Peter



From mharris at redhat.com  Fri Nov  4 23:44:18 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 04 Nov 2005 18:44:18 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131126681.3969.51.camel@brilong-lnx>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>
Message-ID: <436BF252.6010107@redhat.com>

Brian Long wrote:
> On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> 
> Is Red Hat's build system proprietary or is it also open-sourced?  :)

"beehive", the Red hat internal buildsystem is Red Hat internal-only
software, that is tightly coupled to internal Red Hat infrastructure,
databases, etc.

Since it is highly customized in-house software, and is not available
in any form outside of Red Hat, it isn't really open source nor
proprietary, but rather "unavailable".

This is not a bad thing however.  ;o)

The mock buildsystem, and plague et al. are much more useful to the
community for building packages, and are both open source, and
publically available, and are not tied to Red Hat operating systems,
nor tied to various internal infrastructure at Red Hat.

In the (hopefully near) future, our internal buildsystem will be
replaced by something else.  I'm not sure if it will be mock based,
or some alternative internal construction however.

Believe me when I say this:  you do not want to run beehive.  ;o)



From mharris at redhat.com  Fri Nov  4 23:47:37 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 04 Nov 2005 18:47:37 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131073379.19437.294.camel@mccallum.corsepiu.local>
References: <436A82AB.9070701@redhat.com>
	<1131073379.19437.294.camel@mccallum.corsepiu.local>
Message-ID: <436BF319.4050709@redhat.com>

Ralf Corsepius wrote:
> On Thu, 2005-11-03 at 16:35 -0500, Warren Togami wrote:
> 
>>If you are involved in the development of Fedora Core as a packager,
>>here is information that will be relevant to you.
> 
> 
>>Modular X requires FE5 Fixes
>>============================
>>The major change created by modular X is that XFree86-devel and
>>xorg-x11-devel are no longer provided in the buildroot.  All packages in
>>both Core and Extras are now expected to have BuildRequires on the
>>individual libFOO-devel packages of the newly split modular X.  In order
>>to ease into this, the current monolithic xorg-x11 package in rawhide
>>contains many virtual provides for libFOO-devel.  Modular X itself will
>>hit rawhide *REAL SOON NOW*.
> 
> 
> Will we see corresponding "Provides: libFOO-devel = x.y.z" being added
> to xorg-x11-devel for FC4/FC3 for better FC5-> FC4/FC3 rpm.spec backward
> compatibility?

That's not a bad idea.  If somebody files separate bug reports against
FC3 and FC4, I'll try to make sure the next Fedora updates have these
virtual provides present.  That will make things even easier for
3rd party repos to share spec files between various distro releases.

Not sure when we'll make the next FC Xorg updates though, we're pretty
tied down right now. ;)  But there will be updates at some point.

Thanks for the suggestion.



From smooge at gmail.com  Fri Nov  4 23:53:55 2005
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Fri, 4 Nov 2005 16:53:55 -0700
Subject: rawhide report: 20051104 changes
In-Reply-To: <436BF252.6010107@redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx> <436BF252.6010107@redhat.com>
Message-ID: <80d7e4090511041553r4f17c0cbwd068febf7d8b1f0d@mail.gmail.com>

On 11/4/05, Mike A. Harris <mharris at redhat.com> wrote:
> Brian Long wrote:
> > On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> >
> > Is Red Hat's build system proprietary or is it also open-sourced?  :)
>
> "beehive", the Red hat internal buildsystem is Red Hat internal-only
> software, that is tightly coupled to internal Red Hat infrastructure,
> databases, etc.
>
>
> Believe me when I say this:  you do not want to run beehive.  ;o)
>

Oh come on... it cant be as bad as some of the things that ran on
porkchop in years gone by... I mean, how many times did developers
spend every night up during 6.x days because for somereason the
rebuild ate / :)


--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From skvidal at phy.duke.edu  Sat Nov  5 00:28:00 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Nov 2005 19:28:00 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <436BF252.6010107@redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>  <436BF252.6010107@redhat.com>
Message-ID: <1131150480.2192.0.camel@cutter>


> In the (hopefully near) future, our internal buildsystem will be
> replaced by something else.  I'm not sure if it will be mock based,
> or some alternative internal construction however.

So red hat is writing yet another buildsystem for internal use as
opposed to hacking on plague?

*boggle*

I mean plague was written by dcbw - he even works for red hat, so it
can't be NIH. :)

-sv




From seandarcy2 at gmail.com  Sat Nov  5 00:56:19 2005
From: seandarcy2 at gmail.com (sean)
Date: Fri, 04 Nov 2005 19:56:19 -0500
Subject: libXext eludes linker, mod X issue?
Message-ID: <dkgvvk$e1p$1@sea.gmane.org>

xorg-x11-6.8.2-58 on amd64.

All of a sudden, builds ( xine, dvdauthor) break with:

/usr/bin/ld: cannot find -lXext

but

ldconfig -v | grep Xext
         libXext.so.6 -> libXext.so.6.4
         libXext.so.6 -> libXext.so.6.4

locate libXext
/usr/X11R6/lib/libXext.so.6.4
/usr/X11R6/lib/libXext.so.6
/usr/X11R6/lib/libXext.a
/usr/X11R6/lib/libXext.so
/usr/X11R6/lib64/libXext.a
/usr/X11R6/lib64/libXext.so
/usr/X11R6/lib64/libXext.so.6
/usr/X11R6/lib64/libXext.so.6.4

Adding LDFLAGS seems to fix this, but why is the linker 
suddenly unable to find -lXext on its own? Does it know 
xorg-x11-devel is going?

sean



From zaitcev at redhat.com  Sat Nov  5 02:13:46 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 4 Nov 2005 18:13:46 -0800
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <1131112317.13011.4.camel@averatec>
References: <436A82AB.9070701@redhat.com>
	<1131059956.2890.30.camel@localhost.localdomain>
	<1131061024.10196.8.camel@averatec>
	<436AA5B7.5050502@research.att.com>
	<1131063006.10196.12.camel@averatec>
	<436ACBBB.6090309@research.att.com>
	<1131112317.13011.4.camel@averatec>
Message-ID: <20051104181346.47c53734.zaitcev@redhat.com>

On Fri, 04 Nov 2005 08:51:56 -0500, Jon Nettleton <jon.nettleton at gmail.com> wrote:

> > > These fixes are all limited to removable storage.  I was unaware that
> > > there were problems with USB cameras.  Do you have a bugzilla I can
> > > reference?

> > Yes:  #170690, #168933, #150985, #165914

> If the camera is seen as a removable usb storage device, which it sounds
> like these are, then yes it will.  The quick way to tell if it will fix
> your problem is look in the /media directory. [...]

There is no need be so indirect. There's an lsusb dump in one of the
innumeorus bugs which John filed. You do not even have to parse it
yourself, David Zeuten pronounced the camera storage-incompatible
in that bug (correctly).

I am not completely convinced that this issue is worth fixing, because of
security implications. However, it would be nice if someone came up with a configuration for pam and udev which would make console user the owner of
/proc/bus/usb/*/*

-- Pete



From bojan at rexursive.com  Sat Nov  5 02:41:14 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 05 Nov 2005 13:41:14 +1100
Subject: Suspend to disk with 2.6.14-1.1642_FC5
Message-ID: <1131158474.2663.9.camel@coyote.rexursive.com>

Here is another quick report for the latest kernel and suspend to disk
on HP-ZE4201 notebook (for full hardware specs see:
http://www.rexursive.com/articles/linuxonhpze4201.html).

This kernel actually suspends, but on resume, the X (and keyboard) locks
up. I can SSH into the box, but that isn't very useful when you're on
the train ;-)

I have to admit that I'm puzzled as to why suspend2 didn't make into the
mainline kernel. It has been rock solid (at least on my box) for months
now, it is much faster to suspend/resume due to compression, it doesn't
free the memory on suspend (so your apps respond faster on resume), it
looks nicer etc. If any of people on this list have the ear of mainline
kernel folk, it would be really nice if they said a thing or two so that
we finally have that patch where it belongs. Please? Pretty please? :-)

-- 
Bojan



From ellson at research.att.com  Sat Nov  5 02:45:00 2005
From: ellson at research.att.com (John Ellson)
Date: Fri, 04 Nov 2005 21:45:00 -0500
Subject: FC5test1 devel freeze, November 14th
In-Reply-To: <20051104181346.47c53734.zaitcev@redhat.com>
References: <436A82AB.9070701@redhat.com>	<1131059956.2890.30.camel@localhost.localdomain>	<1131061024.10196.8.camel@averatec>	<436AA5B7.5050502@research.att.com>	<1131063006.10196.12.camel@averatec>	<436ACBBB.6090309@research.att.com>	<1131112317.13011.4.camel@averatec>
	<20051104181346.47c53734.zaitcev@redhat.com>
Message-ID: <436C1CAC.6080804@research.att.com>

Pete Zaitcev wrote:
> On Fri, 04 Nov 2005 08:51:56 -0500, Jon Nettleton <jon.nettleton at gmail.com> wrote:
>
>   
>>>> These fixes are all limited to removable storage.  I was unaware that
>>>> there were problems with USB cameras.  Do you have a bugzilla I can
>>>> reference?
>>>>         
>
>   
>>> Yes:  #170690, #168933, #150985, #165914
>>>       
>
>   
>> If the camera is seen as a removable usb storage device, which it sounds
>> like these are, then yes it will.  The quick way to tell if it will fix
>> your problem is look in the /media directory. [...]
>>     
>
> There is no need be so indirect. There's an lsusb dump in one of the
> innumeorus bugs which John filed. You do not even have to parse it
> yourself, David Zeuten pronounced the camera storage-incompatible
> in that bug (correctly).
>
> I am not completely convinced that this issue is worth fixing, because of
> security implications. However, it would be nice if someone came up with a configuration for pam and udev which would make console user the owner of
> /proc/bus/usb/*/*
>
> -- Pete
>
>   
Be careful with my multiple bug reports. I've been posting reports for
over a year now to try to get some attention on this problem.  The 
earliest reports
were for a Canon PowerShot G3, but the most recent are for a Canon 
PowerShot Pro1.
I don't know that the protocols are the same.   I no longer have the G3, 
so all I can
tell you is that the Pro1 doesn't work today (except as root).

What security implications?  Are you suggesting it would be better if 
photographers
had to run gphoto2 as root to get their pictures?

Please, lets make this system useful for something other than 
recompiling kernels!
How can I get my wife to use Linux if she can't process her photos!!!

It would be OK if the system administrator had to authorize a new camera 
on the system. 
But don't make me read any more out-of-date, inaccurate, howtos on 
gphoto/hal/udev/hotplug/kitchensink...

I would like to help fix this if someone would provide some direction, 
but right now
this USB stuff strikes me as a first class monster.

John




From jon.jahren at gmail.com  Sat Nov  5 08:19:28 2005
From: jon.jahren at gmail.com (Jon Jahren)
Date: Sat, 05 Nov 2005 09:19:28 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <436A948F.8090607@insitesinc.com>
References: <436A948F.8090607@insitesinc.com>
Message-ID: <1131178768.685.2.camel@jon.lan>

On Thu, 2005-11-03 at 16:51 -0600, Michael Favia wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> The rt2x00 project provides ongoing support for the rt2400 rt2500 and
> rt2570 chipsets that were open sourced (GPL) by RaLink. The chipset is
> quite popular and used by a few dozen vendors (linksys most notably here
> in US) in various PCI and USB based hardware:
[snip]
> 

Have they improved support for smp-kernels yet? I get a kernel panic
instantly when modprobing rt2500 here, and my knowledge of C is not
nearly good enough to start patching a driver.

Jon



From mharris at redhat.com  Sat Nov  5 10:50:57 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 05 Nov 2005 05:50:57 -0500
Subject: libXext eludes linker, mod X issue?
In-Reply-To: <dkgvvk$e1p$1@sea.gmane.org>
References: <dkgvvk$e1p$1@sea.gmane.org>
Message-ID: <436C8E91.3030507@redhat.com>

sean wrote:
> xorg-x11-6.8.2-58 on amd64.
> 
> All of a sudden, builds ( xine, dvdauthor) break with:
> 
> /usr/bin/ld: cannot find -lXext
> 
> but
> 
> ldconfig -v | grep Xext
>         libXext.so.6 -> libXext.so.6.4
>         libXext.so.6 -> libXext.so.6.4
> 
> locate libXext
> /usr/X11R6/lib/libXext.so.6.4
> /usr/X11R6/lib/libXext.so.6
> /usr/X11R6/lib/libXext.a
> /usr/X11R6/lib/libXext.so
> /usr/X11R6/lib64/libXext.a
> /usr/X11R6/lib64/libXext.so
> /usr/X11R6/lib64/libXext.so.6
> /usr/X11R6/lib64/libXext.so.6.4
> 
> Adding LDFLAGS seems to fix this, but why is the linker suddenly unable 
> to find -lXext on its own? Does it know xorg-x11-devel is going?

Wow.  I figured we would not get people blaming things on
modular X, at _least_ until we actually made it available
in rawhide.  ;o)

Seriously though, the libraries you quote above are from monolithic
X.Org 6.8.2, as indicated on the first line of your email.  The
libraries are installed in the correct location for monolithic
X, under the /usr/X11R6/%{_lib} directory, where they are expected
to be.

The monolithic X in rawhide, has had absolutely no code changes
for quite a while now, and the only changes that it has had, have
been the addition/removal of fake rpm Provides to various
subpackages.

I would look at your ld.so.conf configuration firstly, to confirm
that the X libraries are indeed configured there.  If they are, then
this is almost certainly a bug in the software you're trying
to compile.  From the errors above though, I would strongly suspect
that your ld.so configuration is hosed.



From buildsys at redhat.com  Sat Nov  5 12:43:01 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 5 Nov 2005 07:43:01 -0500
Subject: rawhide report: 20051105 changes
Message-ID: <200511051243.jA5Ch1Uc024796@porkchop.devel.redhat.com>

 

 
Updated Packages:

amanda-2.4.5p1-2
----------------
* Fri Nov 04 2005 Jay Fenlason <fenlason at redhat.com>
- New upstream release.

anthy-7100b-1
-------------
* Sat Nov 05 2005 Akira TAGOH <tagoh at redhat.com> - 7100b-1
- New upstream release.

audit-1.0.10-1
--------------
* Fri Nov 04 2005 Steve Grubb <sgrubb at redhat.com> 1.0.10-1
- Add --failed/success flags to aureport to select specific events for reports
- Add --summary to get totals of reported objects
- Add ability to force log rotation by sending sigusr1 to auditd
- Add -i flag to auditctl to ignore errors when reading rules from a file
- Reformat aureports so date & time are always given
- Add cron script for log rotation to docs

dosfstools-2.11-2
-----------------
* Fri Nov 04 2005 Peter Vrabec <pvrabec at redhat.com> 2.11-2
- fix LFS

kernel-2.6.14-1.1644_FC5
------------------------
* Fri Nov 04 2005 Dave Jones <davej at redhat.com>
- Own /lib/modules/<version>/{extra,updates} (#172075)
- 2.6.14-git7

ldapjdk-0:4.17-1jpp_3fc
-----------------------
* Sat Nov 05 2005 Archit Shah <ashah at redhat.com> 0:4.17-1jpp_3fc
- Call javadoc with sourcepath to work aroung gjdoc bug (#170611)

selinux-policy-mls-1.27.2-15
----------------------------
* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-15
- Add mls fixes for getty and login
- Allow getty to send mail

* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-14
- Add policy for ns-slapd

selinux-policy-strict-1.27.2-15
-------------------------------
* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-15
- Add mls fixes for getty and login
- Allow getty to send mail

* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-14
- Add policy for ns-slapd

selinux-policy-targeted-1.27.2-15
---------------------------------
* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-15
- Add mls fixes for getty and login
- Allow getty to send mail

* Fri Nov 04 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-14
- Add policy for ns-slapd

system-config-httpd-5:1.3.3-1
-----------------------------
* Fri Nov 04 2005 Phil Knirsch <pknirsch at redhat.com> 1.3.3-1
- Rewrote XSLT backend to use libxslt-python instead of 4Suite
- Fixed wrongly claimed "file has been manually modified" for fresh 1st run
  (#167633)
- Updated pam config file to latest pam recommendation (#170629)

system-config-securitylevel-1.6.8-1
-----------------------------------
* Fri Nov 04 2005 Chris Lumens <clumens at redhat.com> 1.6.8-1
- Always load the ip_conntrack_netbios_ns module in lokkit (#113918).

tetex-3.0-8
-----------
* Thu Nov 03 2005 Jindrich Novy <jnovy at redhat.com> 3.0-8
- fix obsolete option passed to sort in texconfig - Michal Jaegermann (#172337)
- additional fix to xdvi -> keep position with navigation using
  delete as well (#168124)

x86info-1:1.17-1.15
-------------------
* Fri Nov 04 2005 Dave Jones <davej at redhat.com>
- Update to upstream 1.17

xterm-206-1.0
-------------
* Fri Nov 04 2005 Jason Vas Dias <jvdias at redhat.com> 206-1
- Upgrade to upstream version 206

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5



Broken deps for s390x
----------------------------------------------------------
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel



Broken deps for ia64
----------------------------------------------------------
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for s390
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5



Broken deps for x86_64
----------------------------------------------------------
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc
----------------------------------------------------------
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc64
----------------------------------------------------------
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)





From mharris at redhat.com  Sat Nov  5 13:08:12 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 05 Nov 2005 08:08:12 -0500
Subject: IMPORTANT: font package owners - modular X required changes
Message-ID: <436CAEBC.2090106@redhat.com>

Modular X does not use /usr/X11R6 anymore.  As such, the binaries
once supplied in /usr/X11R6/bin are now located in /usr/bin.  This
applies to all modular X binaries, including applications like
mkfontdir, mkfontscale, ucs2any, bdftruncate, etc.

Most of the font rpm packages in the distribution invoke one or
more of these font utilities in their rpm processing scripts.

Any of these scripts which let the shell search the PATH for the
executables, or use "MKFONTDIR=$(which mkfontdir)" and then invoke
$MKFONTDIR instead of hard coding a path, should continue to work
with modular X without changes.

Scripts which hard code the path to mkfontdir, mkfontscale, or
other binaries found in /usr/X11R6/bin in rpm scripts, or in
%build or %install sections of spec files, or even in Makefiles
or other build or runtime scripts, etc. - should be updated to
do one of the following:

1) Use "which" to find the location of the binary, and store it
    in a variable, then invoke the app using the variable instead.

or

2) Change the code to rely on the shell's PATH, if that makes sense
    for the particular case, and does not create a security issue
    or other problem.

or

3) Hard code several paths to check for the binary, within the
    script/application, and have it check them all.  ie: Check
    for /usr/bin/mkfontdir, and fallback to /usr/X11R6/bin/mkfontdir,
    etc.

In addition to this, many rpm spec files include dependencies on
hard coded paths to executable files like mkfontdir et al.  For
example, many spec files contain:

Requires: /usr/X11R6/bin/mkfontdir

or similar, since the application has moved from package to package
over the years.  In order to permanently solve this problem, I have
added virtual "Provides: mkfontdir mkfontscale ucs2any bdftruncate"
to the modular X package which provides these utilities.  I have also
added the same Provides to the monolithic xorg-x11 which was built
in rawhide tonight.  Future Fedora Core 3 and 4 xorg-x11 updates will
also add these virtual provides.

Please update your packages to use:

BuildRequires: mkfontdir

and/or

Requires: mkfontdir

wherever appropriate.

By making these changes to your rpm spec files, Makefiles, etc., your
packages will become "future-proofed" to whatever currently unforseen
changes might occur in X packaging a year or more down the line.  By
including virtual provides in our next set of updates, it will also
make it a bit easier to keep compatiblity with existing OS releases
that have been updated to the latest updates, once we release them.

Hopefully these changes will help to make packagers lives easier
in the future, by never having to make similar changes ever again,
so long as everyone follows the above recommendations.

This email has been sent to fedora-devel-list, and the primary
Red Hat internal development list.  If anyone would like to see
it posted to other lists as well, please forward this email to
any other list that you feel the information would be useful to.

Thanks in advance.
TTYL



From igorm5 at vip.hr  Sat Nov  5 15:13:22 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Sat, 05 Nov 2005 16:13:22 +0100
Subject: rt2x00 driver support in FC5
In-Reply-To: <1131178768.685.2.camel@jon.lan>
References: <436A948F.8090607@insitesinc.com> <1131178768.685.2.camel@jon.lan>
Message-ID: <436CCC12.1090901@vip.hr>

Speaking about rt2500 driver (I use beta3 and I installed it with 'make;
make install-fedora'), I never managed to set up my WEP key with
system-config-network tool so I put some script in my /etc/rc.local
file. Besides that, system-config-network-tui doesn't have the wireless
network entry, and FC4 Rawhide doesn't have system-config-network-tui at
all (?). Do you have any plans to improve system-config-network tool,
and the ncurces based version of that tool?

Thanks, cheers!

-- 
Igor Jagec



From pjones at redhat.com  Sat Nov  5 19:12:55 2005
From: pjones at redhat.com (Peter Jones)
Date: Sat, 05 Nov 2005 14:12:55 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131150480.2192.0.camel@cutter>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>  <436BF252.6010107@redhat.com>
	<1131150480.2192.0.camel@cutter>
Message-ID: <1131217976.2979.0.camel@localhost.localdomain>

On Fri, 2005-11-04 at 19:28 -0500, seth vidal wrote:
> > In the (hopefully near) future, our internal buildsystem will be
> > replaced by something else.  I'm not sure if it will be mock based,
> > or some alternative internal construction however.
> 
> So red hat is writing yet another buildsystem for internal use as
> opposed to hacking on plague?

I think he's saying he just doesn't know, rather than making any
declarative statement about what it will or won't be.

-- 
  Peter



From caillon at redhat.com  Sat Nov  5 19:29:19 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Sat, 05 Nov 2005 14:29:19 -0500
Subject: rt2x00 driver support in FC5
In-Reply-To: <436CCC12.1090901@vip.hr>
References: <436A948F.8090607@insitesinc.com> <1131178768.685.2.camel@jon.lan>
	<436CCC12.1090901@vip.hr>
Message-ID: <436D080F.3060608@redhat.com>

On 11/05/2005 10:13 AM, Igor Jagec wrote:
> Speaking about rt2500 driver (I use beta3 and I installed it with 'make;
> make install-fedora'), I never managed to set up my WEP key with
> system-config-network tool so I put some script in my /etc/rc.local
> file. Besides that, system-config-network-tui doesn't have the wireless
> network entry, and FC4 Rawhide doesn't have system-config-network-tui at
> all (?). Do you have any plans to improve system-config-network tool,
> and the ncurces based version of that tool?
>   
The plan is to switch over to using NetworkManager.  See 
http://www.gnome.org/projects/NetworkManager/




From goeran at uddeborg.se  Sat Nov  5 22:20:34 2005
From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=)
Date: Sat, 5 Nov 2005 23:20:34 +0100
Subject: Requirements with modular X
In-Reply-To: <436A82AB.9070701@redhat.com>
References: <436A82AB.9070701@redhat.com>
Message-ID: <17261.12338.475077.52511@mimmi.uddeborg.se>

Warren Togami writes:
> In addition to the lack of XFree86-devel and xorg-x11-devel,
> /usr/X11R6/lib will disappear so packages that previously hardcoded this
> path will need to be fixed.

A package needs the truetype fonts luxi*.ttf.  Because of the package
name change from XFree86-truetype-fonts to fonts-xorg-truetype
previously, I made the requirement be
/usr/X11R6/lib/X11/fonts/TTF/luximbi.ttf etc.  I also have a similar
dependency on the xhost program, solved in the same way.

There won't be any way to have a requirement on these fonts for all
three levels: XFree86, monolithic xorg, modular xorg, will there?
(The XFree86 based system I need to support is RHEL3, so this is maybe
"semi off topic".)



From seandarcy2 at gmail.com  Sun Nov  6 00:21:13 2005
From: seandarcy2 at gmail.com (sean)
Date: Sat, 05 Nov 2005 19:21:13 -0500
Subject: libXext eludes linker, mod X issue?
In-Reply-To: <436C8E91.3030507@redhat.com>
References: <dkgvvk$e1p$1@sea.gmane.org> <436C8E91.3030507@redhat.com>
Message-ID: <dkji9q$4m3$1@sea.gmane.org>

Mike A. Harris wrote:
> sean wrote:
> 
>> xorg-x11-6.8.2-58 on amd64.
>>
>> All of a sudden, builds ( xine, dvdauthor) break with:
>>
>> /usr/bin/ld: cannot find -lXext
>>
>> but
>>
>> ldconfig -v | grep Xext
>>         libXext.so.6 -> libXext.so.6.4
>>         libXext.so.6 -> libXext.so.6.4
[.............]
> 
> I would look at your ld.so.conf configuration firstly, to confirm
> that the X libraries are indeed configured there.  If they are, then
> this is almost certainly a bug in the software you're trying
> to compile.  From the errors above though, I would strongly suspect
> that your ld.so configuration is hosed.
> 

/etc/ld.so.conf is pretty simple:

cat ld.so.conf
include ld.so.conf.d/*.conf
/usr/kerberos/lib

/usr/local/lib


and

  ls /etc/ld.so.conf.d
mysql-i386.conf    octave-x86_64.conf  xorg-x11-i386.conf
mysql-x86_64.conf  qt-i386.conf        qt-x86_64.conf 
xorg-x11-x86_64.conf


cat /etc/ld.so.conf.d/xorg-x11-x86_64.conf
/usr/X11R6/lib64

The errors are from autotools configure tests.

I've simplified it further:

cat simple.c
   int
   main ()
   {
     return 0;
   }

gcc -o test.Xext -lXext simple.c
/usr/bin/ld: cannot find -lXext
collect2: ld returned 1 exit status

but ldconfig does find it:

  ldconfig -v | grep Xext
         libXext.so.6 -> libXext.so.6.4
         libXext.so.6 -> libXext.so.6.4

Now, maybe this is an autotools issue, but I've rebuilt 
these src.rpms before without a hitch.

 >Wow.  I figured we would not get people blaming things on
 >modular X, at _least_ until we actually made it available
 >in rawhide.  ;o)

I've got a grease spot on the monitor. I'm sure it's because 
mod X is comming :)

sean



From sopwith at redhat.com  Sun Nov  6 00:27:36 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Sat, 5 Nov 2005 19:27:36 -0500 (EST)
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131150480.2192.0.camel@cutter>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>  <436BF252.6010107@redhat.com>
	<1131150480.2192.0.camel@cutter>
Message-ID: <Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>

On Fri, 4 Nov 2005, seth vidal wrote:

> 
> > In the (hopefully near) future, our internal buildsystem will be
> > replaced by something else.  I'm not sure if it will be mock based,
> > or some alternative internal construction however.
> 
> So red hat is writing yet another buildsystem for internal use as
> opposed to hacking on plague?
> 
> *boggle*
> 
> I mean plague was written by dcbw - he even works for red hat, so it
> can't be NIH. :)

Red Hat's requirements for a build system are quite different from the
community's requirements for a build system. Think about Sarbanes-Oxley
compliance as an example.

Best,
-- Elliot



From 777tahder at schlaegel.com  Sun Nov  6 07:24:21 2005
From: 777tahder at schlaegel.com (Schlaegel)
Date: Sat, 5 Nov 2005 23:24:21 -0800
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <436A040F.7010402@nicubunu.ro>
References: <4369FA0C.8080804@vip.hr>
	<1131019720.11309.72.camel@localhost.localdomain>
	<436A040F.7010402@nicubunu.ro>
Message-ID: <4e1f5c1a0511052324s43f3105bh4a7ca4bb35f9ec85@mail.gmail.com>

On 11/3/05, Nicu Buculei <nicu_fedora at nicubunu.ro> wrote:
> As OOo changed the way it use icons, is really easy to change the icon
> set, just replace the /usr/lib/openoffice.org/share/config/images.zip
> file and you are done.
>
> So is just a matter of "lifting" images.zip from a SUSE or Ubuntu
> install and start testing.
>
> PS: I'm still thinking the Bluecurve OOo icon set from FC2-FC3 was the
> most beautiful OOo icon set ever (despite the fact it was incomplete,
> partly Bluecurve and partly Industrial)
>

I "lifted" the images_industrial.zip from ubuntu and made my FC4 OOo
look so much better.
I agree that Bluecurve was the best. Too bad it seems to be dead.


PS
Don't try to symlink the images.zip file. I did this and OOo blows up
when you load help.
I did a search for this on the OOo website and discovered it is a
known bug they don't plan on fixing.



From 777tahder at schlaegel.com  Sun Nov  6 07:40:48 2005
From: 777tahder at schlaegel.com (Schlaegel)
Date: Sat, 5 Nov 2005 23:40:48 -0800
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <1131019720.11309.72.camel@localhost.localdomain>
References: <4369FA0C.8080804@vip.hr>
	<1131019720.11309.72.camel@localhost.localdomain>
Message-ID: <4e1f5c1a0511052340g4ab5455cx1106d3352e133b2b@mail.gmail.com>

On 11/3/05, Caolan McNamara <caolanm at redhat.com> wrote:
> What you mean is "the Novell version of the icons", rather than the
> "GNOME version" as the gnome integration features and components are the
> same in FC4, upstream and Novell/Ubuntu. There's no functional different
> in that arena.

I known in Ubuntu that there are other changes as well. In Ubuntu
under "Preferences->View->User Interface"
there is an option next to "Icon Size" that allows the user to choose
the icon style. This option lets the user choose between different
"images_*.zip" and also has an *auto* option that I haven't tried.
This change would be great for FC. It would enable the making of icon
theme rpms that contain an "images_*.zip". To the best of my
knowledge, right now there is no way to make a clean rpm that does
this because the rpm would need to replace images.zip which is owned
by the OOo rpm.



From nicolas.mailhot at laposte.net  Sun Nov  6 09:23:26 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 06 Nov 2005 10:23:26 +0100
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <4e1f5c1a0511052340g4ab5455cx1106d3352e133b2b@mail.gmail.com>
References: <4369FA0C.8080804@vip.hr>
	<1131019720.11309.72.camel@localhost.localdomain>
	<4e1f5c1a0511052340g4ab5455cx1106d3352e133b2b@mail.gmail.com>
Message-ID: <1131269008.2696.13.camel@rousalka.dyndns.org>

Le samedi 05 novembre 2005 ? 23:40 -0800, Schlaegel a ?crit :
> On 11/3/05, Caolan McNamara <caolanm at redhat.com> wrote:
> > What you mean is "the Novell version of the icons", rather than the
> > "GNOME version" as the gnome integration features and components are the
> > same in FC4, upstream and Novell/Ubuntu. There's no functional different
> > in that arena.
> 
> I known in Ubuntu that there are other changes as well. In Ubuntu
> under "Preferences->View->User Interface"
> there is an option next to "Icon Size" that allows the user to choose
> the icon style. This option lets the user choose between different
> "images_*.zip" and also has an *auto* option that I haven't tried.
> This change would be great for FC. It would enable the making of icon
> theme rpms that contain an "images_*.zip". 

Though patching OO.o so it can pull images from the freedesktop-approved
icon theme hierarchy would be much better. Right now if I understand it
well there will always be problems trying to sync theme images with the
OO.o zipfile.

This is the kind of patch Sun will never write BTW, if it happens it
will come from the Linux community

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/20051106/5c9a5880/attachment.sig>

From buildsys at redhat.com  Sun Nov  6 12:46:36 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 6 Nov 2005 07:46:36 -0500
Subject: rawhide report: 20051106 changes
Message-ID: <200511061246.jA6Cka2t012031@porkchop.devel.redhat.com>

 

 
Updated Packages:

acl-2.2.32-1
------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 2.2.32

attr-2.4.24-1
-------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 2.4.24

bluez-hcidump-1.27-1
--------------------
* Sun Nov 06 2005 David Woodhouse <dwmw2 at redhat.com> 1.27-1
- update to bluez-hcidump 1.27

bluez-libs-2.22-1
-----------------
* Sun Nov 06 2005 David Woodhouse <dwmw2 at redhat.com> 2.22-1
- Update to bluez-libs 2.22

kernel-2.6.14-1.1649_FC5
------------------------
* Sat Nov 05 2005 David Woodhouse <dwmw2 at redhat.com>
- Attempt ppc smp build again

* Sat Nov 05 2005 Dave Jones <davej at redhat.com>
- Add another IBM Thinkpad to the Radeon whitelist.

* Sat Nov 05 2005 David Woodhouse <dwmw2 at redhat.com>
- 2.6.14-git8
- Fix i8259 cascade initialisation in arch/powerpc
- disable ppc smp build for now

module-init-tools-3.2-0.pre9.1
------------------------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- update to 3.2pre9

shadow-utils-2:4.0.13-2
-----------------------
* Sat Nov 05 2005 Steve Grubb <sgrubb at redhat.com> 2:4.0.13-2
- Update audit communication to standard format messages

thunderbird-0:1.5-0.5.0.rc1
---------------------------
* Sat Nov 05 2005 Christopher Aillon <caillon at redhat.com> 1.5-0.5.0.rc1
- Update to 1.5 rc1

xfsprogs-2.7.3-1
----------------
* Mon Oct 31 2005 Robert Scheck <redhat at linuxnetz.de> 2.7.3-1
- Upgrade to 2.7.3 and enabled termcap support (#154323)

xorg-x11-6.8.2-59
-----------------
* Fri Nov 04 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-59
- Added "Provides: Xserver" virtual provide on xorg-x11 subpackage which
  other packages can use as a dependency if they require a generic X server.
- Added "Provides: Xorg" virtual provide on xorg-x11 subpackage which other
  packages can use if they require the Xorg X server specifically.
- Added "Provides: iceauth" virtual provide for KDE and other things which
  need iceauth, so that they can drop their artificial dependency on the
  xorg-x11 package in preparation for X11R7.
- Added "Provides: mkfontdir mkfontscale ucs2any bdftruncate" to font-utils
  subpackage, to ease the move to modular X.
- Removed "Provides: XFree86-libs = 4.4.0" because it simply is not true.
- Remove some of the build_mharris conditionals that are no longer useful to
  me.

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	libgnomeui - 2.12.0-2.i386 requires XFree86-libs >= 0:4.2.99
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	synaptics - 0.14.3-3.i386 requires XFree86-libs
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5



Broken deps for ppc
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel
	synaptics - 0.14.3-3.ppc requires XFree86-libs
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	libgnomeui - 2.12.0-2.ppc requires XFree86-libs >= 0:4.2.99



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	libgnomeui - 2.12.0-2.ia64 requires XFree86-libs >= 0:4.2.99
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	synaptics - 0.14.3-3.x86_64 requires XFree86-libs
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	libgnomeui - 2.12.0-2.x86_64 requires XFree86-libs >= 0:4.2.99
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for s390
----------------------------------------------------------
	libgnomeui - 2.12.0-2.s390 requires XFree86-libs >= 0:4.2.99
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	libgnomeui - 2.12.0-2.ppc64 requires XFree86-libs >= 0:4.2.99
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel



Broken deps for s390x
----------------------------------------------------------
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	libgnomeui - 2.12.0-2.s390x requires XFree86-libs >= 0:4.2.99
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel





From jdesbonnet at gmail.com  Sun Nov  6 14:55:24 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sun, 6 Nov 2005 14:55:24 +0000
Subject: Default touchpad configuration confusing
Message-ID: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>

This may be more an up stream issue for Gnome or x.org, but it does
seriously impact the usability of FC on laptops:

With recent versions of FC (I think since FC4) I've found using the
touchpad on my laptop a frustrating experience: The Firefox browser
would go back a page at random (eg you compose an email in gmail, you
then reach for the send button, but the browser would just go back to
the login page before you can reach the send button).

Last night after some research I finally discovered this seems to be
related to the Synaptics driver in X.org.  There is all sorts of fancy
stuff to emulate button 4,5,6 and 7 etc. It turns out that by default
if you slide your finger from right to left near the bottom of the pad
you get a button 6 event which will cause Firefox to go back a page.

As far as I can tell there is zero documentation on this on the FC
distribution. The Desktop->Preferences menu assumes you are using a
mouse.  There should be a finger pad menu item there also.

I think it would be best to keep the touch pad functionality at a
minimum by default (ie just mouse movement and button 1 by tapping)
and allow the user to enable extra stuff through the configuration
menus.

BTW: this touchpad driver project is at:
http://web.telia.com/~u89404340/touchpad/
and a touch pad configuration utility here:
http://ltpconf.sourceforge.net/sshots.html


Joe.



From mharris at redhat.com  Sun Nov  6 15:13:06 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 10:13:06 -0500
Subject: Where should the modular X11R7 fonts get installed to?
Message-ID: <436E1D82.6040708@redhat.com>

Now that /usr/X11R6 is obsolete, and all X files are moving to
the /usr hierarchy, it is time to determine where certain things
should live, and comply with the FHS.

By default, unless overridden, the X11R7 font packages install
all of the fonts into /usr/lib/X11/fonts/*.  Since fonts are
architecture independent data files however, it is my opinion
that they belong under /usr/share somewhere, as this is the FHS
mandated location for architecture independent data files.

We currently package the rest of the fonts our OS supplies
under %{_datadir}/fonts, which translates to /usr/share/fonts,
and is FHS compliant.

I'm currently of the opinion that we should install the X.Org
fonts into "/usr/share/fonts/X11", to have them installed into
an FHS compliant location, but also in their own namespace, thus
avoiding conflicts with other packages.

Another possibility, is to install them into /usr/share/X11/fonts,
which would also be FHS compliant, and put more strength on the
namespacing aspect, but also grouping the X font files along with
other architecture independent data included with X.

Since upstream X.Org currently does not honour the FHS very well,
it is our job to figure out where best the files belong in a
Linux FHS compliant world.

As such, I'm seeking opinions from other Red Hat developers, and
Fedora community developers.  I'd really like to solve this, and
get the packages built ASAP, so please reply ASAP.

Also, feel free to forward this email to any other relevant
mailing lists if you think it deserves a wider audience, as I'm
only on this list.

Thanks in advance.



From ihok at hotmail.com  Sun Nov  6 15:16:45 2005
From: ihok at hotmail.com (Jack Tanner)
Date: Sun, 06 Nov 2005 10:16:45 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>	<1131126681.3969.51.camel@brilong-lnx>
	<436BF252.6010107@redhat.com>	<1131150480.2192.0.camel@cutter>
	<Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
Message-ID: <dkl6ot$a0l$1@sea.gmane.org>

Elliot Lee wrote:
> Red Hat's requirements for a build system are quite different from the
> community's requirements for a build system. Think about Sarbanes-Oxley
> compliance as an example.

Wow. That's fascinating. Any chance you could give a very basic, very 
short example of how SOX compliance is relevant to build systems?

Thanks in advance.



From mharris at redhat.com  Sun Nov  6 15:29:13 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 10:29:13 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <dkl6ot$a0l$1@sea.gmane.org>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>	<1131126681.3969.51.camel@brilong-lnx>	<436BF252.6010107@redhat.com>	<1131150480.2192.0.camel@cutter>	<Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
	<dkl6ot$a0l$1@sea.gmane.org>
Message-ID: <436E2149.9040207@redhat.com>

Jack Tanner wrote:
> Elliot Lee wrote:
> 
>> Red Hat's requirements for a build system are quite different from the
>> community's requirements for a build system. Think about Sarbanes-Oxley
>> compliance as an example.
> 
> 
> Wow. That's fascinating. Any chance you could give a very basic, very 
> short example of how SOX compliance is relevant to build systems?

I can perhaps do even better than that...  There is a book entitled
"What is Sarbanes Oxley?" written by Guy P. Lander, ISBN:0-07-143796-7
which details various aspects of what Sarbanes-Oxley requires
publically traded corporations must do in order to be compliant with
the law.

The book should answer most of your questions pertaining to the
above.  If there are further questions after reading the book
however, you may prefer to discuss things further with an attourney
to get a deeper understanding.

Hope this helps.
TTYL



From czar at czarc.net  Sun Nov  6 15:31:59 2005
From: czar at czarc.net (Gene C.)
Date: Sun, 6 Nov 2005 10:31:59 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E1D82.6040708@redhat.com>
References: <436E1D82.6040708@redhat.com>
Message-ID: <200511061031.59405.czar@czarc.net>

On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
> I'm currently of the opinion that we should install the X.Org
> fonts into "/usr/share/fonts/X11", to have them installed into
> an FHS compliant location, but also in their own namespace, thus
> avoiding conflicts with other packages.
>
> Another possibility, is to install them into /usr/share/X11/fonts,
> which would also be FHS compliant, and put more strength on the
> namespacing aspect, but also grouping the X font files along with
> other architecture independent data included with X.

Either will work and I can live with either.  However, I lean toward having 
ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my 
preference.

Now to just get every other font packager to put their fonts 
under /usr/share/fonts ;)
-- 
Gene



From mharris at redhat.com  Sun Nov  6 15:33:24 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 10:33:24 -0500
Subject: IMPORTANT: xinitrc soon to be obsolete and replaced
 by	xorg-x11-xinit and xorg-x11-xdm
In-Reply-To: <436A7830.70706@redhat.com>
References: <436A7500.3000903@redhat.com> <436A7830.70706@redhat.com>
Message-ID: <436E2244.3020106@redhat.com>

Christopher Aillon wrote:
> On 11/03/2005 03:37 PM, Mike A. Harris wrote:
> 
>> This message is just a heads up of this change, in order to
>> prepare other developers who might have packages which currently
>> depend on the "xinitrc" package, that depending on if/how
>> their package lists its dependencies, it may soon need to be
>> updated to do one of: 
> 
> I think fedora-maintainers is the better list for this sort of 
> announcement.  Might want to copy that, too.

I'm currently only subscribed to fedora-devel-list as the time I
devote to mailing lists nowadays is fairly limited, however I have
no objections if someone would like to forward any of the X11
related postings I've sent to fedora-devel-list to other public
lists, if they think it would help others.  The more the merrier!
;o)

Take care,
TTYL



From arjanv at redhat.com  Sun Nov  6 15:34:47 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sun, 06 Nov 2005 16:34:47 +0100
Subject: rawhide report: 20051104 changes
In-Reply-To: <dkl6ot$a0l$1@sea.gmane.org>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx> <436BF252.6010107@redhat.com>
	<1131150480.2192.0.camel@cutter>
	<Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
	<dkl6ot$a0l$1@sea.gmane.org>
Message-ID: <1131291288.2826.12.camel@laptopd505.fenrus.org>

On Sun, 2005-11-06 at 10:16 -0500, Jack Tanner wrote:
> Elliot Lee wrote:
> > Red Hat's requirements for a build system are quite different from the
> > community's requirements for a build system. Think about Sarbanes-Oxley
> > compliance as an example.
> 
> Wow. That's fascinating. Any chance you could give a very basic, very 
> short example of how SOX compliance is relevant to build systems?

Sometimes RH has contracts for which a part of the payment depends on
delivering certain functionality (eg packages) at certain dates, usually
as part of a RHEL release. SOX then dictates that a company needs to be
in full control and have an accurate record of the actual occurrence of
this contractual event and the steps leading to it. So this includes
authentication, record keeping, reproducability etc which for practical
purposes need to tie into the other infrastructure at RH to be useful in
this sense.




From katzj at redhat.com  Sun Nov  6 15:49:02 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sun, 06 Nov 2005 10:49:02 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <200511061031.59405.czar@czarc.net>
References: <436E1D82.6040708@redhat.com> <200511061031.59405.czar@czarc.net>
Message-ID: <1131292143.3003.14.camel@gondor>

On Sun, 2005-11-06 at 10:31 -0500, Gene C. wrote:
> On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
> > I'm currently of the opinion that we should install the X.Org
> > fonts into "/usr/share/fonts/X11", to have them installed into
> > an FHS compliant location, but also in their own namespace, thus
> > avoiding conflicts with other packages.
> >
> > Another possibility, is to install them into /usr/share/X11/fonts,
> > which would also be FHS compliant, and put more strength on the
> > namespacing aspect, but also grouping the X font files along with
> > other architecture independent data included with X.
> 
> Either will work and I can live with either.  However, I lean toward having 
> ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my 
> preference.

Agreed

Jeremy



From mattdm at mattdm.org  Sun Nov  6 15:57:33 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 6 Nov 2005 10:57:33 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E1D82.6040708@redhat.com>
References: <436E1D82.6040708@redhat.com>
Message-ID: <20051106155733.GA14817@jadzia.bu.edu>

On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
> I'm currently of the opinion that we should install the X.Org
> fonts into "/usr/share/fonts/X11", to have them installed into
> an FHS compliant location, but also in their own namespace, thus
> avoiding conflicts with other packages.

I think this is nicest. I like it more than the /usr/share/X11/fonts
alternative, because if one is looking for "what's part of X"? I think one
is more likely to ask rpm; if one is looking for "where are all the various
the font files", it's handy for them to be under one obvious place.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fedora at leemhuis.info  Sun Nov  6 15:57:40 2005
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sun, 06 Nov 2005 16:57:40 +0100
Subject: Default touchpad configuration confusing
In-Reply-To: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
Message-ID: <1131292660.3539.14.camel@localhost.localdomain>

Am Sonntag, den 06.11.2005, 14:55 +0000 schrieb Joe Desbonnet:

> It turns out that by default
> if you slide your finger from right to left near the bottom of the pad
> you get a button 6 event which will cause Firefox to go back a page.

I also think this behavior a bit annoying and IMHO it should be disabled
by default. But complaining here on the list will probably not help if
you don't file a bug report at

http://bugzilla.redhat.com

additionally.

> and a touch pad configuration utility here:
> http://ltpconf.sourceforge.net/sshots.html

Or just use gsynaptics from Fedora Extras. 
http://gsynaptics.sourceforge.jp/

But it can't disable this behavior afaik.
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From mike at miketc.com  Sun Nov  6 16:05:55 2005
From: mike at miketc.com (Mike Chambers)
Date: Sun, 06 Nov 2005 10:05:55 -0600
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131292143.3003.14.camel@gondor>
References: <436E1D82.6040708@redhat.com>
	<200511061031.59405.czar@czarc.net> <1131292143.3003.14.camel@gondor>
Message-ID: <1131293156.2241.0.camel@scrappy.miketc.com>

On Sun, 2005-11-06 at 10:49 -0500, Jeremy Katz wrote:
> On Sun, 2005-11-06 at 10:31 -0500, Gene C. wrote:
> > On Sunday 06 November 2005 10:13, Mike A. Harris wrote:
> > > I'm currently of the opinion that we should install the X.Org
> > > fonts into "/usr/share/fonts/X11", to have them installed into
> > > an FHS compliant location, but also in their own namespace, thus
> > > avoiding conflicts with other packages.
> > >
> > > Another possibility, is to install them into /usr/share/X11/fonts,
> > > which would also be FHS compliant, and put more strength on the
> > > namespacing aspect, but also grouping the X font files along with
> > > other architecture independent data included with X.
> > 
> > Either will work and I can live with either.  However, I lean toward having 
> > ALL fonts under /usr/share/fonts and, thus, /usr/share/fonts/X11 is my 
> > preference.
> 
> Agreed

Agreed here as well, /usr/share/fonts/X11(or whatever) seems right place
to me.

-- 
Mike Chambers
Madisonville, KY

"It's better to hurt a little now, than to hurt a lot later!"



From nicolas.mailhot at laposte.net  Sun Nov  6 16:08:22 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 06 Nov 2005 17:08:22 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E1D82.6040708@redhat.com>
References: <436E1D82.6040708@redhat.com>
Message-ID: <1131293303.4120.4.camel@rousalka.dyndns.org>

Le dimanche 06 novembre 2005 ? 10:13 -0500, Mike A. Harris a ?crit :

> I'm currently of the opinion that we should install the X.Org
> fonts into "/usr/share/fonts/X11", to have them installed into
> an FHS compliant location, but also in their own namespace, thus
> avoiding conflicts with other packages.

Actually, I'd rather you used xorg-x11, since I doubt every single X11
implementation uses the same font set and avoiding useless patch
conflicts is nice.

PS 

is server startup still failing when it doesn't find "fixed" ? On a
modern fontconfig desktop fixed is not used anywhere

PPS

I don't think any of your modular packages obsoletes xorg-x11 or
xorg-x11-libs, which may cause yum update problems

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/20051106/d0453fd2/attachment.sig>

From mharris at redhat.com  Sun Nov  6 16:28:09 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 11:28:09 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <20051106155733.GA14817@jadzia.bu.edu>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>
Message-ID: <436E2F19.6030902@redhat.com>

Matthew Miller wrote:
> On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
> 
>>I'm currently of the opinion that we should install the X.Org
>>fonts into "/usr/share/fonts/X11", to have them installed into
>>an FHS compliant location, but also in their own namespace, thus
>>avoiding conflicts with other packages.
> 
> 
> I think this is nicest. I like it more than the /usr/share/X11/fonts
> alternative, because if one is looking for "what's part of X"? I think one
> is more likely to ask rpm; if one is looking for "where are all the various
> the font files", it's handy for them to be under one obvious place.

I agree, however there's an additional complication involved that
I hadn't thought of before.  In Fedora Core 4 and earlier, the
fontconfig subsystem was only preconfigured to use the following
font directories:

         <dir>/usr/share/fonts</dir>
         <dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
         <dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
         <dir>~/.fonts</dir>

Fontconfig is recursive, meaning it will find all fonts in all
subdirectories of what is listed in fonts.conf.

I believe Owen, or whoever set up our default fonts.conf configuration,
intentionally selected only the above specific /usr/X11R6 font
directories, in order to pick up the scaleable Type1 and OTF fonts
that come with X, intentionally excluding all of the ugly bitmap
fonts and other weirdo fonts from being seen by fontconfig.

If we put all of the fonts into /usr/share/fonts, then fontconfig
will see all of them now, and this might cause you to get a different
font than you expected for a given name, whereas fontconfig would
not have seen them all before.

Another possible problem, is that I'm not sure if fontconfig/Xft
support all of the font types that are supported by the core fonts
system.

Note that these are currently only theoretical problems.  I don't
know if there should be a real concern for these issues or not, as
I haven't tested anything yet.

If someone is interested in testing it however, and seeing the effects,
you can do:

1) Make a backup of /etc/fonts/fonts.conf somewhere safe.

2) Edit /etc/fonts/fonts.conf and remove the 2 existing entries:
         <dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
         <dir>/usr/X11R6/lib/X11/fonts/OTF</dir>

3) Put in a new entry:  <dir>/usr/X11R6/lib/X11/fonts</dir>

4) Run:  fc-cache /usr/share/fonts
          fc-cache /usr/X11R6/lib/X11/fonts

5) Completely reboot your whole system, to ensure that all apps are
    restarted, etc. like they would be after a normal reboot.

6) Log into X, and experiment with various GNOME/KDE applications,
    and see if any fonts have changed, or if anything is now unexpectedly
    ugly by default.

After testing this, please post a reply to this email back to the
list.

If it turns out that having *all* of the X11 supplied fonts visible
to fontconfig is a bad idea, then we can explore other options.  Please
feel free to make suggestions also.

Thanks to everyone who responded so quickly!



From mharris at redhat.com  Sun Nov  6 16:33:28 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 11:33:28 -0500
Subject: Requirements with modular X
In-Reply-To: <17261.12338.475077.52511@mimmi.uddeborg.se>
References: <436A82AB.9070701@redhat.com>
	<17261.12338.475077.52511@mimmi.uddeborg.se>
Message-ID: <436E3058.1030302@redhat.com>

G?ran Uddeborg wrote:
> Warren Togami writes:
> 
>>In addition to the lack of XFree86-devel and xorg-x11-devel,
>>/usr/X11R6/lib will disappear so packages that previously hardcoded this
>>path will need to be fixed.
> 
> 
> A package needs the truetype fonts luxi*.ttf.  Because of the package
> name change from XFree86-truetype-fonts to fonts-xorg-truetype
> previously, I made the requirement be
> /usr/X11R6/lib/X11/fonts/TTF/luximbi.ttf etc.  I also have a similar
> dependency on the xhost program, solved in the same way.
> 
> There won't be any way to have a requirement on these fonts for all
> three levels: XFree86, monolithic xorg, modular xorg, will there?
> (The XFree86 based system I need to support is RHEL3, so this is maybe
> "semi off topic".)

Hmm.  This is an interesting problem.  Any solution that I can
think of to this, has both advantages and disadvantages, however
I think the following solution has the least disadvantages, and
is simple to implement.

I can add a new virtual provide to modular X, and monolithic X,
which provides the luxi fonts.  Of course the disadvantage of this,
is that the virtual provide wont pre-exist in any currently
released OS products, but it can be added in future erratum.

Provides: luxi-truetype-fonts
Provides: luxi-Type1-fonts

Does this sound reasonable?

The other alternative, is to conditionalize the spec file with
build_fc1 build_fc2 build_fc3 build_fc4 build_fc5 macros, but
that's kindof sucktacular.

I'm open to suggestions.



From nicolas.mailhot at laposte.net  Sun Nov  6 16:39:25 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 06 Nov 2005 17:39:25 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E2F19.6030902@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>  <436E2F19.6030902@redhat.com>
Message-ID: <1131295165.4120.9.camel@rousalka.dyndns.org>

Le dimanche 06 novembre 2005 ? 11:28 -0500, Mike A. Harris a ?crit :

> Another possible problem, is that I'm not sure if fontconfig/Xft
> support all of the font types that are supported by the core fonts
> system.

Well, I for one would appreciate if all the weirdo fonts were put in
fonts-xorg-x11-legacy, and only a minimal set needed for server startup
was installed by default.

In fact if we could have a legacy-free default config it would be even
better. The "can not find fixed" problems have been plaguing users which
had absolutely no need for fixed in the first place for years.

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/20051106/6ba5fbfc/attachment.sig>

From jbarnes at virtuousgeek.org  Sun Nov  6 16:48:59 2005
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Sun, 6 Nov 2005 08:48:59 -0800
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E2F19.6030902@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
Message-ID: <200511060849.00109.jbarnes@virtuousgeek.org>

On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
> I believe Owen, or whoever set up our default fonts.conf
> configuration, intentionally selected only the above specific
> /usr/X11R6 font directories, in order to pick up the scaleable Type1
> and OTF fonts that come with X, intentionally excluding all of the
> ugly bitmap fonts and other weirdo fonts from being seen by
> fontconfig.

But don't you *want* to see all your fonts?  I.e. if you chose to 
install xorg-ugly-fonts, you don't want them mysteriously missing from 
your font listings, do you?

I think as long as the ugly fonts are in separate packages, putting them 
all in /usr/share/fonts will be ok based on the principle of least 
surprise (though you bring up a good point that this is a change in 
behavior wrt current FC).

Jesse



From mharris at redhat.com  Sun Nov  6 16:54:04 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 11:54:04 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131295165.4120.9.camel@rousalka.dyndns.org>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
	<1131295165.4120.9.camel@rousalka.dyndns.org>
Message-ID: <436E352C.90309@redhat.com>

Nicolas Mailhot wrote:
> Le dimanche 06 novembre 2005 ? 11:28 -0500, Mike A. Harris a ?crit :
> 
> 
>>Another possible problem, is that I'm not sure if fontconfig/Xft
>>support all of the font types that are supported by the core fonts
>>system.
> 
> 
> Well, I for one would appreciate if all the weirdo fonts were put in
> fonts-xorg-x11-legacy, and only a minimal set needed for server startup
> was installed by default.

That is an orthagonal issue, unrelated to this problem however.
It also creates a font installation granularity problem, where
if you want a single ISO8859-1 set installed, you get all of the
ISO8859-* fonts and anything else all in the one large package.

Many people want to install only the fonts that they will be using,
which is why our X font packaging puts each font type/encoding in
it's own subpackage.  I don't see any reason to stop doing this, at
least until the core fonts system is capable of on-the-fly transcoding
from the UCS masters.  At that point, we only need to ship the
UCS fonts, and that would reduce both the number of font packages,
and the number of disk wastage.

Again however, that is an orthagonal issue, of which I'm not too
concerned about right now.


> In fact if we could have a legacy-free default config it would be even
> better. The "can not find fixed" problems have been plaguing users which
> had absolutely no need for fixed in the first place for years.

It's not very "better" when someone goes to run an application and
their fonts are not installed, and they complain loudly on mailing
lists, and file oodles of bug reports with cursing and swearing in
them.

Don't get me wrong - I'm all in favour of deprecating old technology
and eventually removing it sometime down the road.  But if that causes
too large of an increase in user/customer support problems, bug reports,
support escalations, and hate mail, then I'm strongly opposed to it,
if I'm on the receiving end of it all.

How many people would be upset if we compiled the fixed and cursor font
directly into the X server, so you never see "Can't find font fixed"
again, and we did not install xfs by default, and did not install any
core fonts by default, and also left libXt and libXaw out of a default
OS install?  Yes, this means xterm wont work by default too.

I'm sure people would not be very impressed.  Heck, I still receive
angry email for removing xbiff.

Anyhow, back to the original problem...



From mpeters at mac.com  Sun Nov  6 17:07:15 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Sun, 06 Nov 2005 09:07:15 -0800
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E2F19.6030902@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>  <436E2F19.6030902@redhat.com>
Message-ID: <1131296836.8148.19.camel@locolhost.localdomain>

On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:

> 
> I believe Owen, or whoever set up our default fonts.conf configuration,
> intentionally selected only the above specific /usr/X11R6 font
> directories, in order to pick up the scaleable Type1 and OTF fonts
> that come with X, intentionally excluding all of the ugly bitmap
> fonts and other weirdo fonts from being seen by fontconfig.

bitmap fonts can be turned off in new fontconfig

> 
> If we put all of the fonts into /usr/share/fonts, then fontconfig
> will see all of them now, and this might cause you to get a different
> font than you expected for a given name, whereas fontconfig would
> not have seen them all before.

They can also be blacklisted in new fontconfig



From mharris at redhat.com  Sun Nov  6 17:37:42 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 06 Nov 2005 12:37:42 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131296836.8148.19.camel@locolhost.localdomain>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
	<1131296836.8148.19.camel@locolhost.localdomain>
Message-ID: <436E3F66.2000404@redhat.com>

Michael A. Peters wrote:
> On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
> 
> 
>>I believe Owen, or whoever set up our default fonts.conf configuration,
>>intentionally selected only the above specific /usr/X11R6 font
>>directories, in order to pick up the scaleable Type1 and OTF fonts
>>that come with X, intentionally excluding all of the ugly bitmap
>>fonts and other weirdo fonts from being seen by fontconfig.
> 
> 
> bitmap fonts can be turned off in new fontconfig

Some bitmap fonts are desired however.  The ability to turn them
off, would mean we either include them all by default, giving users
some problems (someone has already confirmed that their fonts changed
when enabling fontconfig across all X fonts), or disable them all
by default, meaning bitmap fonts aren't available for terminals,
and terminal-like programs.

Not an optimal solution IMHO.

>>If we put all of the fonts into /usr/share/fonts, then fontconfig
>>will see all of them now, and this might cause you to get a different
>>font than you expected for a given name, whereas fontconfig would
>>not have seen them all before.
> 
> They can also be blacklisted in new fontconfig

Blacklisted on a directory by directory basis, or file by file?

How do the blacklists get maintained as new font files/dirs get
added?



From michael.favia at insitesinc.com  Sun Nov  6 17:45:26 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Sun, 06 Nov 2005 11:45:26 -0600
Subject: Default touchpad configuration confusing
In-Reply-To: <1131292660.3539.14.camel@localhost.localdomain>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131292660.3539.14.camel@localhost.localdomain>
Message-ID: <436E4136.30000@insitesinc.com>

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

Thorsten Leemhuis wrote:
> Am Sonntag, den 06.11.2005, 14:55 +0000 schrieb Joe Desbonnet:
> 
> 
>>It turns out that by default
>>if you slide your finger from right to left near the bottom of the pad
>>you get a button 6 event which will cause Firefox to go back a page.
> 
> 
> I also think this behavior a bit annoying and IMHO it should be disabled
> by default. But complaining here on the list will probably not help if
> you don't file a bug report at

The problem actually lies in Firefox's default configuration to go back
and forward pages with horizontal scrolling. Combine that with the large
horizontal scrolling area of the default configuration of the touchpad
and you have a recipe for seeing your homepage more than youd like :).


Firefox behavior can be easily disabled with
mousewheel.horizscroll.withnokey.action=0 in about:config IIRC. I don't
think we should disable horizontal scrolling on the syn touchpads
because it is very useful but perhaps we should make it a little smaller
of an area for sensitivities sake.
- -mf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDbkE1BVsNYjF2rDYRAoE1AKCNtsqqAgzwk7a1ZPjV8f4FPMFLSgCePkgQ
BYVf6ocr4SuhIAWo3I5OLJk=
=sSmi
-----END PGP SIGNATURE-----



From jdesbonnet at gmail.com  Sun Nov  6 18:26:12 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sun, 6 Nov 2005 18:26:12 +0000
Subject: Default touchpad configuration confusing
In-Reply-To: <436E4136.30000@insitesinc.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131292660.3539.14.camel@localhost.localdomain>
	<436E4136.30000@insitesinc.com>
Message-ID: <1cef3e950511061026x104afd83h8d72e0d965ca82c2@mail.gmail.com>

Given that Firefox is the only application that affected me, changing
Firefox's default behaviour is probably an acceptable fix.

However, it took me 6 months of casual laptop use to figure out these
advanced features of the touchpad (and I would consider myself an
'expert' user). I think something needs to be done to document it. Two
suggestions come to mind:
1. Add a tool bar applet (like I've seen on some Windows laptops with
the Synaptics touchpad) which the user can click on to configure
settings and get help.
2. Just add a configuration utility to the Desktop->Preferences menu.
Even if all that does is provide a link to a help page detailing it's
operation and how to configure it manually from the xorg.conf file.

I'm surprised this issue has not been brought up before. I have this
impression (and I could be wrong as I don't have time to evaluate
other distros right now) that FC is not a very laptop friendly distro
(?).

Joe.

On 11/6/05, Michael Favia <michael.favia at insitesinc.com> wrote:

>
> Firefox behavior can be easily disabled with
> mousewheel.horizscroll.withnokey.action=0 in about:config IIRC. I don't
> think we should disable horizontal scrolling on the syn touchpads
> because it is very useful but perhaps we should make it a little smaller
> of an area for sensitivities sake.



From pekkas at netcore.fi  Sun Nov  6 18:36:40 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Sun, 6 Nov 2005 20:36:40 +0200 (EET)
Subject: disappointment over default acpid config
Message-ID: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>

Hi,

I just replaced with my laptop's OLD but working RHL73 with FC4.

Let me state a strong disappointment over acpid default config.

What "default config" ?  Exactly, there is none (the sample config for 
power button does not count).

I was stunned how FC could be making ACPI default while completely 
ignoring adding any default configs for the users (e.g., starting from 
something like http://www.thinkwiki.org/wiki/How_to_configure_acpid) ?

Looking at CVS, this problem doesn't seem to have been addressed in 
FC5.  I (or I'm sure a lot of other folks) could submit a patch for 
starters if that'd be the problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From hughsient at gmail.com  Sun Nov  6 18:50:14 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 06 Nov 2005 18:50:14 +0000
Subject: disappointment over default acpid config
In-Reply-To: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
Message-ID: <1131303014.17044.4.camel@localhost.localdomain>

On Sun, 2005-11-06 at 20:36 +0200, Pekka Savola wrote:
> Hi,
> 
> I just replaced with my laptop's OLD but working RHL73 with FC4.
> Let me state a strong disappointment over acpid default config.
> What "default config" ?  Exactly, there is none (the sample config for 
> power button does not count).
> 
> I was stunned how FC could be making ACPI default while completely 
> ignoring adding any default configs for the users (e.g., starting from 
> something like http://www.thinkwiki.org/wiki/How_to_configure_acpid) ?
> 
> Looking at CVS, this problem doesn't seem to have been addressed in 
> FC5.  I (or I'm sure a lot of other folks) could submit a patch for 
> starters if that'd be the problem.

Have you seen the work that HAL and GNOME Power Manager [1] have been
doing?

You can disable acpid, and configure gnome-power-manager to sleep,
hibernate or shutdown on the button presses.

I think FC5 will be shipping g-p-m by default, so this should solve your
problems. There is a yum repo for FC4 users too.

What did you want to do with acpid?

Thanks, 

Richard.

[1] http://www.gnome.org/projects/gnome-power-manager/



From otaylor at redhat.com  Sun Nov  6 19:05:54 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Sun, 06 Nov 2005 14:05:54 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E2F19.6030902@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>  <436E2F19.6030902@redhat.com>
Message-ID: <1131303954.7909.72.camel@localhost.localdomain>

On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
> Matthew Miller wrote:
> > On Sun, Nov 06, 2005 at 10:13:06AM -0500, Mike A. Harris wrote:
> > 
> >>I'm currently of the opinion that we should install the X.Org
> >>fonts into "/usr/share/fonts/X11", to have them installed into
> >>an FHS compliant location, but also in their own namespace, thus
> >>avoiding conflicts with other packages.
> > 
> > 
> > I think this is nicest. I like it more than the /usr/share/X11/fonts
> > alternative, because if one is looking for "what's part of X"? I think one
> > is more likely to ask rpm; if one is looking for "where are all the various
> > the font files", it's handy for them to be under one obvious place.
> 
> I agree, however there's an additional complication involved that
> I hadn't thought of before.  In Fedora Core 4 and earlier, the
> fontconfig subsystem was only preconfigured to use the following
> font directories:
> 
>          <dir>/usr/share/fonts</dir>
>          <dir>/usr/X11R6/lib/X11/fonts/Type1</dir>
>          <dir>/usr/X11R6/lib/X11/fonts/OTF</dir>
>          <dir>~/.fonts</dir>
> 
> Fontconfig is recursive, meaning it will find all fonts in all
> subdirectories of what is listed in fonts.conf.
> 
> I believe Owen, or whoever set up our default fonts.conf configuration,
> intentionally selected only the above specific /usr/X11R6 font
> directories, in order to pick up the scaleable Type1 and OTF fonts
> that come with X, intentionally excluding all of the ugly bitmap
> fonts and other weirdo fonts from being seen by fontconfig.

Yes, that's the case. It's pretty much a disaster if a web page
configured to have Helvetica specifically as a font comes up with
the bitmap Helvetica rather than Nimbus Sans.

Keith has been promoting an alternate solution to the bitmap font
problem - configuring fontconfig to exclude *all* bitmap fonts , but
that doesn't really work for us -- we *want* the bitmap fonts in
bitmap-fonts. (At least a couple of years ago, there was a 
passionate attachment to MiscFixed.)

A different way of going about excluding fonts would be to use
the <rejectfont> mechanism ... see the description of rejectfont
in /usr/share/doc/fontconfig-<version>/fontconfig-user.{txt,html}
and /etc/fonts/conf.d/40-blacklist-fonts.conf for an example
that where we are using it to reject certain of the the Hershey 
fonts which were causing FreeType indigestion.

> If we put all of the fonts into /usr/share/fonts, then fontconfig
> will see all of them now, and this might cause you to get a different
> font than you expected for a given name, whereas fontconfig would
> not have seen them all before.
> 
> Another possible problem, is that I'm not sure if fontconfig/Xft
> support all of the font types that are supported by the core fonts
> system.

This shouldn't be a problem ... if fontconfig doesn't understand
something it will ignore it.

> Note that these are currently only theoretical problems.  I don't
> know if there should be a real concern for these issues or not, as
> I haven't tested anything yet.

We definitely can't drop the full set of X11 fonts right into the
default configuration. The problems will be far from theoretical.
But they should be fixable.

Regards,
					Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051106/62b0d300/attachment.sig>

From otaylor at redhat.com  Sun Nov  6 19:13:05 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Sun, 06 Nov 2005 14:13:05 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131295165.4120.9.camel@rousalka.dyndns.org>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>  <436E2F19.6030902@redhat.com>
	<1131295165.4120.9.camel@rousalka.dyndns.org>
Message-ID: <1131304386.7909.80.camel@localhost.localdomain>

On Sun, 2005-11-06 at 17:39 +0100, Nicolas Mailhot wrote:
> Le dimanche 06 novembre 2005 ? 11:28 -0500, Mike A. Harris a ?crit :
> 
> > Another possible problem, is that I'm not sure if fontconfig/Xft
> > support all of the font types that are supported by the core fonts
> > system.
> 
> Well, I for one would appreciate if all the weirdo fonts were put in
> fonts-xorg-x11-legacy, and only a minimal set needed for server startup
> was installed by default.
> 
> In fact if we could have a legacy-free default config it would be even
> better. The "can not find fixed" problems have been plaguing users which
> had absolutely no need for fixed in the first place for years.

'fixed' has an important role as the font that is *guaranteed* to be
there on X no matter what. The user probably has no need for any
X core font other than 'fixed', but having 'fixed' there is an 
important safety net.

The obvious solution would be to compile fixed into the X server in
some fashion. It's been discussed at various points, but I don't
think anyone has ever looked into actually doing it.

Dropping XFS at this point might be a good idea .... most 'cannot find
fixed' problems are really XFS problems, and if we aren't using core
fonts for anything, we don't need a font server. But dropping XFS
would mean changing the chkfontpath system that we use for maintaining
the core X font path, and, well, that's very fragile stuff and 
intertwined with the %pre/%post in a lot of packages.

So, I think it is better to leave XFS there until nobody needs any
bitmap fonts other than fixed.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051106/f6a4b38f/attachment.sig>

From otaylor at redhat.com  Sun Nov  6 19:16:00 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Sun, 06 Nov 2005 14:16:00 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <200511060849.00109.jbarnes@virtuousgeek.org>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu> <436E2F19.6030902@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>
Message-ID: <1131304560.7909.84.camel@localhost.localdomain>

On Sun, 2005-11-06 at 08:48 -0800, Jesse Barnes wrote:
> On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
> > I believe Owen, or whoever set up our default fonts.conf
> > configuration, intentionally selected only the above specific
> > /usr/X11R6 font directories, in order to pick up the scaleable Type1
> > and OTF fonts that come with X, intentionally excluding all of the
> > ugly bitmap fonts and other weirdo fonts from being seen by
> > fontconfig.
> 
> But don't you *want* to see all your fonts?  I.e. if you chose to 
> install xorg-ugly-fonts, you don't want them mysteriously missing from 
> your font listings, do you?
>
> I think as long as the ugly fonts are in separate packages, putting them 
> all in /usr/share/fonts will be ok based on the principle of least 
> surprise (though you bring up a good point that this is a change in 
> behavior wrt current FC).

I think there is a general principle that installing extra packages
shouldn't break things ... other than cluttering up your menus or
lists of fonts.

But if the -adobe-*-*-*-*--*-*-*-*-*-*-*-* bitmaps get into your
font path, things break. Fontconfig (correctly) thinks that
these are official versions of Times Roman, Helvetica, etc, and
thus prefers them to the URW clones. It has no real way of knowing
that they are ugly bitmap official versions.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051106/ccc773b0/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov  6 19:27:51 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 06 Nov 2005 20:27:51 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131304386.7909.80.camel@localhost.localdomain>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>  <436E2F19.6030902@redhat.com>
	<1131295165.4120.9.camel@rousalka.dyndns.org>
	<1131304386.7909.80.camel@localhost.localdomain>
Message-ID: <1131305272.4120.15.camel@rousalka.dyndns.org>

Le dimanche 06 novembre 2005 ? 14:13 -0500, Owen Taylor a ?crit :
> On Sun, 2005-11-06 at 17:39 +0100, Nicolas Mailhot wrote:

> > In fact if we could have a legacy-free default config it would be even
> > better. The "can not find fixed" problems have been plaguing users which
> > had absolutely no need for fixed in the first place for years.
> 
> 'fixed' has an important role as the font that is *guaranteed* to be
> there on X no matter what. The user probably has no need for any
> X core font other than 'fixed', but having 'fixed' there is an 
> important safety net.

But will this safety net be used say in a fontconfig-enabled app if
fontconfig finds no fonts in /usr/share ? (ie in 90% of FC apps)

If not I don't see what the point of forcing every single user to check
he got this failsafe installed. Especially considering the failsafe
system has historically been brittle and broken for more years than I
care to remember (a ttf dropped in /usr/share will "just work". Fixed
needs lots of fragile black magic to exist at all)

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/20051106/b78aa5c8/attachment.sig>

From mattdm at mattdm.org  Sun Nov  6 19:55:13 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 6 Nov 2005 14:55:13 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131304386.7909.80.camel@localhost.localdomain>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
	<1131295165.4120.9.camel@rousalka.dyndns.org>
	<1131304386.7909.80.camel@localhost.localdomain>
Message-ID: <20051106195513.GA21173@jadzia.bu.edu>

On Sun, Nov 06, 2005 at 02:13:05PM -0500, Owen Taylor wrote:
> fonts for anything, we don't need a font server. But dropping XFS
> would mean changing the chkfontpath system that we use for maintaining
> the core X font path, and, well, that's very fragile stuff and 
> intertwined with the %pre/%post in a lot of packages.

In the long run, I think that's an argument *for* changing it. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From nicolas.mailhot at laposte.net  Sun Nov  6 20:04:23 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 06 Nov 2005 21:04:23 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <20051106195513.GA21173@jadzia.bu.edu>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu> <436E2F19.6030902@redhat.com>
	<1131295165.4120.9.camel@rousalka.dyndns.org>
	<1131304386.7909.80.camel@localhost.localdomain>
	<20051106195513.GA21173@jadzia.bu.edu>
Message-ID: <1131307464.4120.21.camel@rousalka.dyndns.org>

Le dimanche 06 novembre 2005 ? 14:55 -0500, Matthew Miller a ?crit :
> On Sun, Nov 06, 2005 at 02:13:05PM -0500, Owen Taylor wrote:
> > fonts for anything, we don't need a font server. But dropping XFS
> > would mean changing the chkfontpath system that we use for maintaining
> > the core X font path, and, well, that's very fragile stuff and 
> > intertwined with the %pre/%post in a lot of packages.
> 
> In the long run, I think that's an argument *for* changing it. :)

Make core font system 
1. optional installed by default in FC n
2. optional not installed by default in FC n+1
3. pushed to Fedora Extras in FC n+2

3-release roadmap. Surely that's not too ambitious ? The few apps that
don't use fontconfig today won't in 10 years unless someone provides
more incentives to change.

And I wouldn't mind so much if fixed and friends were not en endless
source of X startup crashes

-- 
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/20051106/663ed75e/attachment.sig>

From wtogami at redhat.com  Sun Nov  6 20:07:08 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 06 Nov 2005 15:07:08 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131296836.8148.19.camel@locolhost.localdomain>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
	<1131296836.8148.19.camel@locolhost.localdomain>
Message-ID: <436E626C.6050409@redhat.com>

Michael A. Peters wrote:
> On Sun, 2005-11-06 at 11:28 -0500, Mike A. Harris wrote:
> 
> 
>>I believe Owen, or whoever set up our default fonts.conf configuration,
>>intentionally selected only the above specific /usr/X11R6 font
>>directories, in order to pick up the scaleable Type1 and OTF fonts
>>that come with X, intentionally excluding all of the ugly bitmap
>>fonts and other weirdo fonts from being seen by fontconfig.
> 
> 
> bitmap fonts can be turned off in new fontconfig
> 

How would this effect the cases like Chinese, Japanese or Korean where 
bitmap fonts are substituted at small sizes in order to have readable 
tiny text?

Warren Togami
wtogami at redhat.com



From gtwilliams at gmail.com  Sun Nov  6 20:11:30 2005
From: gtwilliams at gmail.com (Garry Williams)
Date: Sun, 06 Nov 2005 15:11:30 -0500
Subject: Default touchpad configuration confusing
In-Reply-To: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
Message-ID: <1131307890.26257.191.camel@localhost>

On Sun, 2005-11-06 at 14:55 +0000, Joe Desbonnet wrote:
> This may be more an up stream issue for Gnome or x.org, but it does
> seriously impact the usability of FC on laptops:

[snip]

This doesn't fix the problem you report and others have mentioned a bug
report would be appropriate, but...

I found the default behavior very irritating, too.  Here's my fix.
Change xorg.conf making the VertScrollDelta and HorizScrollDelta options
zero.  No more gestures.  I also wanted to speed up my pointer so I
changed the MinSpeed to 0.65 from 0.3.  It used to take more than two
strokes across my pad to get across the screen.  YMMV.

        Section "InputDevice"
                 Identifier  "Synaptics"
                 Driver      "synaptics"
                 Option     "Device" "/dev/input/mice"
                 Option     "Protocol" "auto-dev"
                 Option     "Emulate3Buttons" "yes"
                 Option     "LeftEdge" "120"
                 Option     "RightEdge" "830"
                 Option     "TopEdge" "120"
                 Option     "BottomEdge" "650"
                 Option     "FingerLow" "14"
                 Option     "FingerHigh" "15"
                 Option     "MaxTapMove" "0"
                 Option     "VertScrollDelta" "0"
                 Option     "HorizScrollDelta" "0"
                 Option     "MinSpeed" "0.65"
                 Option     "MaxSpeed" "0.75"
         EndSection

 http://www.zvolve.com/~garry/lappy.html#touch_pad 

-- 
Garry Williams -- +1 (678) 656-4579



From menthos at menthos.com  Sun Nov  6 20:39:44 2005
From: menthos at menthos.com (Christian Rose)
Date: Sun, 6 Nov 2005 21:39:44 +0100
Subject: Default touchpad configuration confusing
In-Reply-To: <1cef3e950511061026x104afd83h8d72e0d965ca82c2@mail.gmail.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131292660.3539.14.camel@localhost.localdomain>
	<436E4136.30000@insitesinc.com>
	<1cef3e950511061026x104afd83h8d72e0d965ca82c2@mail.gmail.com>
Message-ID: <97da516f0511061239g77ed4c73w58ee3bbfc42d2a05@mail.gmail.com>

On 11/6/05, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
> Given that Firefox is the only application that affected me, changing
> Firefox's default behaviour is probably an acceptable fix.

Indeed.  It seems some newer laptops actually have the scrolling areas
on the touchpad clearly marked (I know at least mine has), so I would
consider a change that would disable the touchpad scrolling areas by
default a bug rather than a feature. If the hardware says it's there,
it should be.

However, undocumented (and therefore probably unexpected) features
like the Firefox default behaviour that interprets horizontal
scrolling as going back, would probably be helpful to have disabled by
default.


Christian



From jspaleta at gmail.com  Sun Nov  6 20:44:02 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 6 Nov 2005 15:44:02 -0500
Subject: Default touchpad configuration confusing
In-Reply-To: <97da516f0511061239g77ed4c73w58ee3bbfc42d2a05@mail.gmail.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131292660.3539.14.camel@localhost.localdomain>
	<436E4136.30000@insitesinc.com>
	<1cef3e950511061026x104afd83h8d72e0d965ca82c2@mail.gmail.com>
	<97da516f0511061239g77ed4c73w58ee3bbfc42d2a05@mail.gmail.com>
Message-ID: <604aa7910511061244n32fd6c5cx1a15829fc8aa1294@mail.gmail.com>

On 11/6/05, Christian Rose <menthos at menthos.com> wrote:
> However, undocumented (and therefore probably unexpected) features
> like the Firefox default behaviour that interprets horizontal
> scrolling as going back, would probably be helpful to have disabled by
> default.


Isn't that an argument for upstream firefox.. instead of a
distribution specific change to the application defaults?

-jef



From vallimar at sexorcisto.net  Sun Nov  6 20:45:23 2005
From: vallimar at sexorcisto.net (vallimar at sexorcisto.net)
Date: Sun, 6 Nov 2005 15:45:23 -0500 (EST)
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E3F66.2000404@redhat.com>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>
	<436E2F19.6030902@redhat.com>
	<1131296836.8148.19.camel@locolhost.localdomain>
	<436E3F66.2000404@redhat.com>
Message-ID: <1308.192.168.1.2.1131309923.squirrel@sexorcisto.net>

On Sun, November 6, 2005 12:37 pm, Mike A. Harris wrote:
>
> Some bitmap fonts are desired however.  The ability to turn them
> off, would mean we either include them all by default, giving users some
> problems (someone has already confirmed that their fonts changed when
> enabling fontconfig across all X fonts), or disable them all by default,
> meaning bitmap fonts aren't available for terminals, and terminal-like
> programs.
>
> Not an optimal solution IMHO.
>

What about patching fontconfig to give it priorities?
So that you can tell it to scan TTF, OTF, Type1 and then bitmap?
Or whatever order you choose?  Granted, I've no idea how complex
that might be, but that, with the ability to exclude, would be
the likeliest optimal solution to being able to package all the
bitmap fonts.



From rodd at clarkson.id.au  Sun Nov  6 21:40:12 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 07 Nov 2005 08:40:12 +1100
Subject: Default touchpad configuration confusing
In-Reply-To: <1131307890.26257.191.camel@localhost>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131307890.26257.191.camel@localhost>
Message-ID: <1131313212.5761.2.camel@localhost.localdomain>

On Sun, 2005-11-06 at 15:11 -0500, Garry Williams wrote:
> On Sun, 2005-11-06 at 14:55 +0000, Joe Desbonnet wrote:
> > This may be more an up stream issue for Gnome or x.org, but it does
> > seriously impact the usability of FC on laptops:
> 
> [snip]
> 
> This doesn't fix the problem you report and others have mentioned a bug
> report would be appropriate, but...
> 
> I found the default behavior very irritating, too.  Here's my fix.
> Change xorg.conf making the VertScrollDelta and HorizScrollDelta options
> zero.  No more gestures.  I also wanted to speed up my pointer so I
> changed the MinSpeed to 0.65 from 0.3.  It used to take more than two
> strokes across my pad to get across the screen.  YMMV.

Rather than raising the value of MinSpeed, you might be better of
adding:

        Option      "AccelFactor" "0.0300"

This will move you mouse pointer further the faster you move your finger
on the mouse pad.  But it also leaves your mouse at a nice speed for
working in the local area.  You might need to adjust the value for your
screen size.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From rodd at clarkson.id.au  Sun Nov  6 21:43:36 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 07 Nov 2005 08:43:36 +1100
Subject: Default touchpad configuration confusing
In-Reply-To: <604aa7910511061244n32fd6c5cx1a15829fc8aa1294@mail.gmail.com>
References: <1cef3e950511060655j62c917b2vd23175bf2b1f42eb@mail.gmail.com>
	<1131292660.3539.14.camel@localhost.localdomain>
	<436E4136.30000@insitesinc.com>
	<1cef3e950511061026x104afd83h8d72e0d965ca82c2@mail.gmail.com>
	<97da516f0511061239g77ed4c73w58ee3bbfc42d2a05@mail.gmail.com>
	<604aa7910511061244n32fd6c5cx1a15829fc8aa1294@mail.gmail.com>
Message-ID: <1131313416.5761.4.camel@localhost.localdomain>

On Sun, 2005-11-06 at 15:44 -0500, Jeff Spaleta wrote:
> On 11/6/05, Christian Rose <menthos at menthos.com> wrote:
> > However, undocumented (and therefore probably unexpected) features
> > like the Firefox default behaviour that interprets horizontal
> > scrolling as going back, would probably be helpful to have disabled by
> > default.
> 
> 
> Isn't that an argument for upstream firefox.. instead of a
> distribution specific change to the application defaults?

Yeah it probably is.

I suspect that the way firefox should work is to scroll left and right
on the horizontal scroll, and to go forwards and backwards on
ALT-HozScrll.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From wrrhdev at riede.org  Sun Nov  6 21:47:22 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 06 Nov 2005 21:47:22 +0000
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <436E3F66.2000404@redhat.com> (from mharris@redhat.com on Sun
	Nov  6 12:37:42 2005)
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu> <436E2F19.6030902@redhat.com>
	<1131296836.8148.19.camel@locolhost.localdomain>
	<436E3F66.2000404@redhat.com>
Message-ID: <1131313642l.18274l.1l@serve.riede.org>

On 11/06/2005 12:37:42 PM, Mike A. Harris wrote:
> Michael A. Peters wrote:
>> 
>> They can also be blacklisted in new fontconfig
> 
> Blacklisted on a directory by directory basis, or file by file?
> 
> How do the blacklists get maintained as new font files/dirs get
> added?

Is there a blacklist.d/ ? On the other hand, if only the legacy bitmaps need  
blacklisting, would the blacklist ever change?

Regards, Willem Riede.




From rodd at clarkson.id.au  Sun Nov  6 22:27:15 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Mon, 07 Nov 2005 09:27:15 +1100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131313642l.18274l.1l@serve.riede.org>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu> <436E2F19.6030902@redhat.com>
	<1131296836.8148.19.camel@locolhost.localdomain>
	<436E3F66.2000404@redhat.com> <1131313642l.18274l.1l@serve.riede.org>
Message-ID: <1131316036.5761.15.camel@localhost.localdomain>

On Sun, 2005-11-06 at 21:47 +0000, Willem Riede wrote:
> On 11/06/2005 12:37:42 PM, Mike A. Harris wrote:
> > Michael A. Peters wrote:
> >> 
> >> They can also be blacklisted in new fontconfig
> > 
> > Blacklisted on a directory by directory basis, or file by file?
> > 
> > How do the blacklists get maintained as new font files/dirs get
> > added?
> 
> Is there a blacklist.d/ ? On the other hand, if only the legacy bitmaps need  
> blacklisting, would the blacklist ever change?

Doesn't MacOS and MacOS X have a nice config tool that lets users select
what fonts the system loads?  Could we do something like this (with some
well pick default enable, disable options).

It would be even better if it was done in such a way that font's that
are called, but not loaded get loaded so that that user doesn't need to
worry about apps that call for fonts that they've disabled.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From pekkas at netcore.fi  Sun Nov  6 22:50:41 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 7 Nov 2005 00:50:41 +0200 (EET)
Subject: disappointment over default acpid config
In-Reply-To: <1131303014.17044.4.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0511070048001.8420@netcore.fi>

On Sun, 6 Nov 2005, Richard Hughes wrote:
> On Sun, 2005-11-06 at 20:36 +0200, Pekka Savola wrote:
> Have you seen the work that HAL and GNOME Power Manager [1] have been
> doing?
>
> You can disable acpid, and configure gnome-power-manager to sleep,
> hibernate or shutdown on the button presses.
>
> I think FC5 will be shipping g-p-m by default, so this should solve your
> problems. There is a yum repo for FC4 users too.

What's the solution for non-graphics mode challenged?  There's 
probably no use working on acpid now, if it's going to be replaced -- 
but if it's replaced, the replacement should not assume X.

(I'm just using acpid to put to suspend-to-mem and hopefully at some 
point suspend-to-disk.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From hughsient at gmail.com  Sun Nov  6 22:57:33 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 06 Nov 2005 22:57:33 +0000
Subject: disappointment over default acpid config
In-Reply-To: <Pine.LNX.4.64.0511070048001.8420@netcore.fi>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
Message-ID: <1131317853.17044.21.camel@localhost.localdomain>

On Mon, 2005-11-07 at 00:50 +0200, Pekka Savola wrote:
> On Sun, 6 Nov 2005, Richard Hughes wrote:
> > On Sun, 2005-11-06 at 20:36 +0200, Pekka Savola wrote:
> > Have you seen the work that HAL and GNOME Power Manager [1] have been
> > doing?
> >
> > You can disable acpid, and configure gnome-power-manager to sleep,
> > hibernate or shutdown on the button presses.
> >
> > I think FC5 will be shipping g-p-m by default, so this should solve your
> > problems. There is a yum repo for FC4 users too.
> 
> What's the solution for non-graphics mode challenged?  There's 
> probably no use working on acpid now, if it's going to be replaced -- 
> but if it's replaced, the replacement should not assume X.

Well, you can still use acpid scripts if you like :-) In the g-p-m m/l
we are talking about ways to solve the "no X" situation, maybe involving
a "headless" (i.e. no gui) version of gnome-power-manager starting at
the login screen, or maybe just having a fallback in hal if there is no
g-p-m.

> (I'm just using acpid to put to suspend-to-mem and hopefully at some 
> point suspend-to-disk.)

All of this should "just work" [1] using a recent HAL, pm-utils and
g-p-m.

Richard.

[1] Assuming the kernel doesn't blow up.



From jspaleta at gmail.com  Sun Nov  6 23:05:28 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 6 Nov 2005 18:05:28 -0500
Subject: disappointment over default acpid config
In-Reply-To: <1131317853.17044.21.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
Message-ID: <604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>

On 11/6/05, Richard Hughes <hughsient at gmail.com> wrote:
> Well, you can still use acpid scripts if you like :-) In the g-p-m m/l
> we are talking about ways to solve the "no X" situation, maybe involving
> a "headless" (i.e. no gui) version of gnome-power-manager starting at
> the login screen, or maybe just having a fallback in hal if there is no
> g-p-m.

don't you basically just need a tool that allows cli access to
whatever setable options are allowed? Or is all that crap stored in
gconf and thus can be accessed via ninja gconftool skills?

-jef



From hughsient at gmail.com  Sun Nov  6 23:13:59 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Sun, 06 Nov 2005 23:13:59 +0000
Subject: disappointment over default acpid config
In-Reply-To: <604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
Message-ID: <1131318839.9308.5.camel@localhost.localdomain>

On Sun, 2005-11-06 at 18:05 -0500, Jeff Spaleta wrote:
> On 11/6/05, Richard Hughes <hughsient at gmail.com> wrote:
> > Well, you can still use acpid scripts if you like :-) In the g-p-m m/l
> > we are talking about ways to solve the "no X" situation, maybe involving
> > a "headless" (i.e. no gui) version of gnome-power-manager starting at
> > the login screen, or maybe just having a fallback in hal if there is no
> > g-p-m.
> 
> don't you basically just need a tool that allows cli access to
> whatever setable options are allowed? Or is all that crap stored in
> gconf and thus can be accessed via ninja gconftool skills?

The policy is stored in g-p-m (gconf, per user) and HAL just does the
information processing (battery.time_remaining) and method heavy lifting
(Suspend, Hibernate, SetLCDBrightness, etc.).

HAL doesn't enforce any policy at all. Without g-p-m running you won't
be able to "suspend after 15 minutes of inactivity" or any cleverness
like that.

I'm not sure the "without X" argument is that important (flame retardant
suit ON..) as the typical laptop isn't booting for very long. If we load
a headless g-p-m when gdm loads, then we have 99.999% of the time
covered.

Richard.



From pekkas at netcore.fi  Sun Nov  6 23:20:28 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 7 Nov 2005 01:20:28 +0200 (EET)
Subject: resolving symbols with FORTIFY_SOURCE?
Message-ID: <Pine.LNX.4.64.0511070051040.8420@netcore.fi>

Hi,

How exactly do you resolve the symbols with crashes caused by software 
compiled with FORTIFY_SOURCE=2?

I'm seeing a crash in xsupplicant (from extras) and would like to get 
it fixed, but as the program is halted by glibc/kernel, I can't run 
gdb on it to backtrace and to get the symbols.  Installing debuginfo 
doesn't help; debuginfo can be used to find the symbols manually (w/ 
objdump) but doing so would be a lot of work though.

I googled around quite a bit but couldn't find any automation or help 
(akin to old 'ksymoops') in decoding the numbers.  There's very 
probably something, but I just can't find it.  Or if there isn't, we 
should certainly merge it.

Any pointers?

................
[root at dhcp-142 tmp]# *** buffer overflow detected ***: xsupplicant terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0xa43c45]
xsupplicant[0x8069a77]
xsupplicant[0x806a189]
xsupplicant[0x806a641]
xsupplicant[0x806a6e6]
xsupplicant[0x806a84e]
xsupplicant[0x806bdfa]
xsupplicant[0x804b0bd]
xsupplicant[0x804b243]
/lib/libc.so.6(__libc_start_main+0xdf)[0x97ad5f]
xsupplicant[0x804a7d1]
======= Memory map: ========
004cb000-004da000 r-xp 00000000 03:01 64194      /lib/libresolv-2.3.5.so
004da000-004db000 r-xp 0000e000 03:01 64194      /lib/libresolv-2.3.5.so
004db000-004dc000 rwxp 0000f000 03:01 64194      /lib/libresolv-2.3.5.so
004dc000-004de000 rwxp 004dc000 00:00 0
004e0000-004e2000 r-xp 00000000 03:01 68214      /lib/libcom_err.so.2.1
004e2000-004e3000 rwxp 00001000 03:01 68214      /lib/libcom_err.so.2.1
004e5000-004fc000 r-xp 00000000 03:01 187614     /usr/lib/libgssapi_krb5.so.2.2
004fc000-004fd000 rwxp 00017000 03:01 187614     /usr/lib/libgssapi_krb5.so.2.2
004ff000-0056e000 r-xp 00000000 03:01 187613     /usr/lib/libkrb5.so.3.2
0056e000-00571000 rwxp 0006e000 03:01 187613     /usr/lib/libkrb5.so.3.2
00573000-00596000 r-xp 00000000 03:01 187612     /usr/lib/libk5crypto.so.3.0
00596000-00597000 rwxp 00023000 03:01 187612     /usr/lib/libk5crypto.so.3.0
00599000-0059b000 r-xp 00000000 03:01 180990     /usr/lib/libkrb5support.so.0.0
0059b000-0059c000 rwxp 00001000 03:01 180990     /usr/lib/libkrb5support.so.0.0
0059e000-005d3000 r-xp 00000000 03:01 68216      /lib/libssl.so.0.9.7f
005d3000-005d6000 rwxp 00035000 03:01 68216      /lib/libssl.so.0.9.7f
005d8000-006d0000 r-xp 00000000 03:01 68215      /lib/libcrypto.so.0.9.7f
006d0000-006e2000 rwxp 000f8000 03:01 68215      /lib/libcrypto.so.0.9.7f
006e2000-006e5000 rwxp 006e2000 00:00 0
006f2000-006fb000 r-xp 00000000 03:01 68212      /lib/libgcc_s-4.0.1-20050727.so.1
006fb000-006fc000 rwxp 00009000 03:01 68212      /lib/libgcc_s-4.0.1-20050727.so.1
00948000-00962000 r-xp 00000000 03:01 68207      /lib/ld-2.3.5.so
00962000-00963000 r-xp 00019000 03:01 68207      /lib/ld-2.3.5.so
00963000-00964000 rwxp 0001a000 03:01 68207      /lib/ld-2.3.5.so
00966000-00a89000 r-xp 00000000 03:01 68208      /lib/libc-2.3.5.so
00a89000-00a8b000 r-xp 00123000 03:01 68208      /lib/libc-2.3.5.so
00a8b000-00a8d000 rwxp 00125000 03:01 68208      /lib/libc-2.3.5.so
00a8d000-00a8f000 rwxp 00a8d000 00:00 0
00ab8000-00aba000 r-xp 00000000 03:01 68210      /lib/libdl-2.3.5.so
00aba000-00abb000 r-xp 00001000 03:01 68210      /lib/libdl-2.3.5.so
00abb000-00abc000 rwxp 00002000 03:01 68210      /lib/libdl-2.3.5.so
00abe000-00ad0000 r-xp 00000000 03:01 173735     /usr/lib/libz.so.1.2.2.2
00ad0000-00ad1000 rwxp 00011000 03:01 173735     /usr/lib/libz.so.1.2.2.2
00fc0000-00fc1000 r-xp 00fc0000 00:00 0          [vdso]
08048000-08083000 r-xp 00000000 03:01 175223     /usr/sbin/xsupplicant
08083000-08084000 rw-p 0003b000 03:01 175223     /usr/sbin/xsupplicant
08084000-08085000 rw-p 08084000 00:00 0
09738000-09759000 rw-p 09738000 00:00 0          [heap]
b7fba000-b7fbe000 rw-p b7fba000 00:00 0
b7fc9000-b7fcc000 rw-p b7fc9000 00:00 0
bfab7000-bfacc000 rw-p bfab7000 00:00 0          [stack]

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From nmiell at comcast.net  Sun Nov  6 23:40:41 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sun, 06 Nov 2005 15:40:41 -0800
Subject: resolving symbols with FORTIFY_SOURCE?
In-Reply-To: <Pine.LNX.4.64.0511070051040.8420@netcore.fi>
References: <Pine.LNX.4.64.0511070051040.8420@netcore.fi>
Message-ID: <1131320441.2853.3.camel@entropy>

On Mon, 2005-11-07 at 01:20 +0200, Pekka Savola wrote:
> Hi,
> 
> How exactly do you resolve the symbols with crashes caused by software 
> compiled with FORTIFY_SOURCE=2?
> 
> I'm seeing a crash in xsupplicant (from extras) and would like to get 
> it fixed, but as the program is halted by glibc/kernel, I can't run 
> gdb on it to backtrace and to get the symbols.  Installing debuginfo 
> doesn't help; debuginfo can be used to find the symbols manually (w/ 
> objdump) but doing so would be a lot of work though.
> 
> I googled around quite a bit but couldn't find any automation or help 
> (akin to old 'ksymoops') in decoding the numbers.  There's very 
> probably something, but I just can't find it.  Or if there isn't, we 
> should certainly merge it.
> 
> Any pointers?

IIRC, there was a proposed patch to glibc which would make the backtrace
functions use DWARF line number information (if available) instead of
the ELF symbol table, but the glibc maintainer rejected it.

So, put a breakpoint on __chk_fail and then run xsupplicant or else just
look at the core dump.

-- 
Nicholas Miell <nmiell at comcast.net>



From sundaram at redhat.com  Mon Nov  7 00:31:41 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 06:01:41 +0530
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <4e1f5c1a0511052324s43f3105bh4a7ca4bb35f9ec85@mail.gmail.com>
References: <4369FA0C.8080804@vip.hr>	<1131019720.11309.72.camel@localhost.localdomain>	<436A040F.7010402@nicubunu.ro>
	<4e1f5c1a0511052324s43f3105bh4a7ca4bb35f9ec85@mail.gmail.com>
Message-ID: <436EA06D.5060609@redhat.com>

Hi

>I "lifted" the images_industrial.zip from ubuntu and made my FC4 OOo
>look so much better.
>I agree that Bluecurve was the best. Too bad it seems to be dead.
>  
>
GNOME, Metacity Window manager theme has been changed. However the 
default Icon set is still Bluecurve

regards
Rahul



From pekkas at netcore.fi  Mon Nov  7 01:47:48 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 7 Nov 2005 03:47:48 +0200 (EET)
Subject: resolving symbols with FORTIFY_SOURCE?
In-Reply-To: <1131320441.2853.3.camel@entropy>
References: <Pine.LNX.4.64.0511070051040.8420@netcore.fi>
	<1131320441.2853.3.camel@entropy>
Message-ID: <Pine.LNX.4.64.0511070346030.11675@netcore.fi>

On Sun, 6 Nov 2005, Nicholas Miell wrote:
> IIRC, there was a proposed patch to glibc which would make the backtrace
> functions use DWARF line number information (if available) instead of
> the ELF symbol table, but the glibc maintainer rejected it.
>
> So, put a breakpoint on __chk_fail and then run xsupplicant or else just
> look at the core dump.

Thanks.  (Brown paper bag) due to the message (no mention of core 
dump), I didn't even realize it was dumping core; gdb debugged the 
problem quite nicely.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From nicu_fedora at nicubunu.ro  Mon Nov  7 06:55:28 2005
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 07 Nov 2005 08:55:28 +0200
Subject: Open Office 2.0 - GNOME integration
In-Reply-To: <436EA06D.5060609@redhat.com>
References: <4369FA0C.8080804@vip.hr>	<1131019720.11309.72.camel@localhost.localdomain>	<436A040F.7010402@nicubunu.ro>	<4e1f5c1a0511052324s43f3105bh4a7ca4bb35f9ec85@mail.gmail.com>
	<436EA06D.5060609@redhat.com>
Message-ID: <436EFA60.4000202@nicubunu.ro>

Rahul Sundaram wrote:
> 
>> I "lifted" the images_industrial.zip from ubuntu and made my FC4 OOo
>> look so much better.
>> I agree that Bluecurve was the best. Too bad it seems to be dead.
>>  
>>
> GNOME, Metacity Window manager theme has been changed. However the 
> default Icon set is still Bluecurve

We were talking about the icons in OpenOffice.org.
Just before FC2 release Garrett made a huge effort and created a 
Bluecurve OOo icon set - http://people.redhat.com/~glesage/ooo_icons/
This was used by OOo in FC2 and FC3 ( OOo 1.1.x branch).
In FC4 we have OOo 2.0 with its default icon set, which look just like a 
  MS Office rip-off (probably because its target was StarOffice on Windows).
However, in Linux world we have alternate icon sets for OOo (the 
Bluecurve one is not complete) which at least are conforming with the 
GNOME HIG and would make a much consistent desktop experience.

-- 
nicu
my hats collection: http://fedora.nicubunu.ro/hats
Open Clip Art Library: http://www.openclipart.org



From nicolas.mailhot at laposte.net  Mon Nov  7 08:30:21 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 09:30:21 +0100
Subject: disappointment over default acpid config
In-Reply-To: <1131318839.9308.5.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
Message-ID: <1131352221.10354.6.camel@rousalka.dyndns.org>

Le dimanche 06 novembre 2005 ? 23:13 +0000, Richard Hughes a ?crit :

> I'm not sure the "without X" argument is that important (flame retardant
> suit ON..) as the typical laptop isn't booting for very long. If we load
> a headless g-p-m when gdm loads, then we have 99.999% of the time
> covered.

Good power management is very important for set-top like HTPC boxes,
where you may have a GUI running but it's certainly not the Gnome one
(ie it's a desktop-less setup)

So you're cutting yourself from new market segments, not only old ones.

-- 
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/20051107/121fcff3/attachment.sig>

From hughsient at gmail.com  Mon Nov  7 09:04:21 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 09:04:21 +0000
Subject: disappointment over default acpid config
In-Reply-To: <1131352221.10354.6.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
Message-ID: <1131354261.2490.5.camel@localhost.localdomain>

On Mon, 2005-11-07 at 09:30 +0100, Nicolas Mailhot wrote:
> Le dimanche 06 novembre 2005 ? 23:13 +0000, Richard Hughes a ?crit :
> 
> > I'm not sure the "without X" argument is that important (flame retardant
> > suit ON..) as the typical laptop isn't booting for very long. If we load
> > a headless g-p-m when gdm loads, then we have 99.999% of the time
> > covered.
> 
> Good power management is very important for set-top like HTPC boxes,
> where you may have a GUI running but it's certainly not the Gnome one
> (ie it's a desktop-less setup)
> So you're cutting yourself from new market segments, not only old ones.

So you would be using gnome-power-manager and gnome-power-preferences on
a set top box? Would you use NetworkManager also? STB's are a very
specialised niche, not something that gnome-power-manager is focused on.

There's nothing wrong with creating a stripped down g-p-m (to interact
with HAL) as an optional initscript. But I really don't think this is
required -- feel free to jump on the g-p-m m/l if you require this
functionality.

Richard.



From nicolas.mailhot at laposte.net  Mon Nov  7 09:20:41 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 10:20:41 +0100
Subject: disappointment over default acpid config
In-Reply-To: <1131354261.2490.5.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
Message-ID: <1131355242.10354.15.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 09:04 +0000, Richard Hughes a ?crit :
> On Mon, 2005-11-07 at 09:30 +0100, Nicolas Mailhot wrote:
> > Le dimanche 06 novembre 2005 ? 23:13 +0000, Richard Hughes a ?crit :
> > 
> > > I'm not sure the "without X" argument is that important (flame retardant
> > > suit ON..) as the typical laptop isn't booting for very long. If we load
> > > a headless g-p-m when gdm loads, then we have 99.999% of the time
> > > covered.
> > 
> > Good power management is very important for set-top like HTPC boxes,
> > where you may have a GUI running but it's certainly not the Gnome one
> > (ie it's a desktop-less setup)
> > So you're cutting yourself from new market segments, not only old ones.
> 
> So you would be using gnome-power-manager and gnome-power-preferences on
> a set top box? Would you use NetworkManager also? STB's are a very
> specialised niche, not something that gnome-power-manager is focused on.

If you put all the "niches" you've decided to ignore together that's a
sizeable part of the market. Moreover this "niche" is very concerned
about power management, much more than your average desktop user,
because HTPCs are supposed to be always-on, at worst hibernating.

> There's nothing wrong with creating a stripped down g-p-m (to interact
> with HAL) as an optional initscript. But I really don't think this is
> required -- feel free to jump on the g-p-m m/l if you require this
> functionality.

I personaly don't. But if you've ever jumped on a HTPC forum, I doubt
you could miss the long threads about Cool'n Quiet vs Mobile intel, best
ways to control system fans, etc.

Actually I'm astonished you choose to ignore HTPCs. If someone is going
to sort power management on desktop systems that's HTPC users. And even
it's a niche it's a growing one - much like sound-card enabled PCs where
one a niche and are now the norm.

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/20051107/906612b4/attachment.sig>

From laroche at redhat.com  Mon Nov  7 11:30:12 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 7 Nov 2005 12:30:12 +0100
Subject: moin / bugzilla / qemu
Message-ID: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>

I've briefly tested a nearly current FC-development install
and have put together the following rpm packages to be installed
pretty easy:
- moin 1.3.5 (update to patch 935 to include all patches form the 1.3 branch)
- bugzilla 2.20 (with all patches from 2.20-branch from cvs)
- qemu: this package builds together with the kqemu kernel modul. You have
  to download it from the http://qemu.org/ website and then compile the
  src.rpm)

regards,

Florian La Roche



From twaugh at redhat.com  Mon Nov  7 11:30:55 2005
From: twaugh at redhat.com (Tim Waugh)
Date: Mon, 7 Nov 2005 11:30:55 +0000
Subject: WARNING:  /usr/bin/sort breaks fonts, thunderbird,
	and autofs (Re: rawhide report: 20051029 changes)
In-Reply-To: <4364FB44.2030607@research.att.com>
References: <200510291125.j9TBPLM3003235@porkchop.devel.redhat.com>
	<4364FB44.2030607@research.att.com>
Message-ID: <20051107113055.GV29766@redhat.com>

On Sun, Oct 30, 2005 at 11:56:36AM -0500, John Ellson wrote:

> The latest /usr/bin/sort is causing lots of damage.

This comment refers to the fact that upstream coreutils no longer
accepts 'sort +0' syntax (instead use 'sort -k 1').  In fact,
coreutils has behaved this way for a long time; we have just been
patching in the old behaviour every time someone complains.

Sooner or later, these applications will have to get used to the POSIX
syntax.

Tim.
*/
-------------- 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/20051107/03a0f971/attachment.sig>

From dwmw2 at infradead.org  Mon Nov  7 11:56:50 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 07 Nov 2005 11:56:50 +0000
Subject: disappointment over default acpid config
In-Reply-To: <1131318839.9308.5.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
Message-ID: <1131364610.27347.52.camel@baythorne.infradead.org>

On Sun, 2005-11-06 at 23:13 +0000, Richard Hughes wrote:
> The policy is stored in g-p-m (gconf, per user) and HAL just does the
> information processing (battery.time_remaining) and method heavy lifting
> (Suspend, Hibernate, SetLCDBrightness, etc.).
> 
> HAL doesn't enforce any policy at all. Without g-p-m running you won't
> be able to "suspend after 15 minutes of inactivity" or any cleverness
> like that.
> 
> I'm not sure the "without X" argument is that important (flame retardant
> suit ON..) as the typical laptop isn't booting for very long. If we load
> a headless g-p-m when gdm loads, then we have 99.999% of the time
> covered.

I'm slightly less concerned by the 'without X' case than I am by the
'without user' case.

I was bitten the other day by a NetworkManager regression in this
respect. I'm used to just turning my laptop on and walking (or driving)
away from it. Within a minute or two NetworkManager will make sure it's
on the network.

A few days ago I did this after upgrading NetworkManager, and the laptop
remained inaccessible from the network. When I returned to it, I found
that the GNOME keyring manager now insisted on asking me for a password
before it would access the WEP key which is already stored in the
_standard_ system-wide configuration in /etc/sysconfig/network-scripts.

You need to have a way to set system-wide policies, even if they're only
a default and can be overridden by users in certain cases.

-- 
dwmw2




From dhollis at davehollis.com  Mon Nov  7 12:12:48 2005
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 07 Nov 2005 07:12:48 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131126681.3969.51.camel@brilong-lnx>  <436BF252.6010107@redhat.com>
	<1131150480.2192.0.camel@cutter>
	<Pine.LNX.4.58.0511051924180.23751@devserv.devel.redhat.com>
Message-ID: <1131365568.4768.5.camel@dhollis-lnx.sunera.com>

On Sat, 2005-11-05 at 19:27 -0500, Elliot Lee wrote:
> On Fri, 4 Nov 2005, seth vidal wrote:

> 
> Red Hat's requirements for a build system are quite different from the
> community's requirements for a build system. Think about Sarbanes-Oxley
> compliance as an example.
> 

Oh how I feel your pain!  Having worked for a large firm that is all
about SOX in recent times, I can feel your pain.  Hopefully you are able
to take the mess from the audit side and are to make useful things from
it.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051107/8e5f174d/attachment.sig>

From sundaram at redhat.com  Mon Nov  7 12:14:59 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 17:44:59 +0530
Subject: disappointment over default acpid config
In-Reply-To: <1131364610.27347.52.camel@baythorne.infradead.org>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>
	<1131364610.27347.52.camel@baythorne.infradead.org>
Message-ID: <436F4543.5060405@redhat.com>

David Woodhouse wrote:

>On Sun, 2005-11-06 at 23:13 +0000, Richard Hughes wrote:
>  
>
>>The policy is stored in g-p-m (gconf, per user) and HAL just does the
>>information processing (battery.time_remaining) and method heavy lifting
>>(Suspend, Hibernate, SetLCDBrightness, etc.).
>>
>>HAL doesn't enforce any policy at all. Without g-p-m running you won't
>>be able to "suspend after 15 minutes of inactivity" or any cleverness
>>like that.
>>
>>I'm not sure the "without X" argument is that important (flame retardant
>>suit ON..) as the typical laptop isn't booting for very long. If we load
>>a headless g-p-m when gdm loads, then we have 99.999% of the time
>>covered.
>>    
>>
>
>I'm slightly less concerned by the 'without X' case than I am by the
>'without user' case.
>
>I was bitten the other day by a NetworkManager regression in this
>respect. I'm used to just turning my laptop on and walking (or driving)
>away from it. Within a minute or two NetworkManager will make sure it's
>on the network.
>
>A few days ago I did this after upgrading NetworkManager, and the laptop
>remained inaccessible from the network. When I returned to it, I found
>that the GNOME keyring manager now insisted on asking me for a password
>before it would access the WEP key which is already stored in the
>_standard_ system-wide configuration in /etc/sysconfig/network-scripts.
>
>You need to have a way to set system-wide policies, even if they're only
>a default and can be overridden by users in certain cases.
>
>  
>
You are probably talking about this bug in reference to the keyring issue.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172555

There isnt any enhancements filed for a feature to override system policies.

regards
Rahul



From nicolas.mailhot at laposte.net  Mon Nov  7 12:22:08 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 13:22:08 +0100
Subject: disappointment over default acpid config
In-Reply-To: <1131364610.27347.52.camel@baythorne.infradead.org>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131364610.27347.52.camel@baythorne.infradead.org>
Message-ID: <1131366129.10354.25.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 11:56 +0000, David Woodhouse a ?crit :
> On Sun, 2005-11-06 at 23:13 +0000, Richard Hughes wrote:
> > The policy is stored in g-p-m (gconf, per user) and HAL just does the
> > information processing (battery.time_remaining) and method heavy lifting
> > (Suspend, Hibernate, SetLCDBrightness, etc.).
> > 
> > HAL doesn't enforce any policy at all. Without g-p-m running you won't
> > be able to "suspend after 15 minutes of inactivity" or any cleverness
> > like that.
> > 
> > I'm not sure the "without X" argument is that important (flame retardant
> > suit ON..) as the typical laptop isn't booting for very long. If we load
> > a headless g-p-m when gdm loads, then we have 99.999% of the time
> > covered.
> 
> I'm slightly less concerned by the 'without X' case than I am by the
> 'without user' case.

Right HTPC is more "without user" "without Gnome" than "without X"

-- 
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/20051107/9413a93c/attachment.sig>

From enrico.scholz at informatik.tu-chemnitz.de  Mon Nov  7 12:33:30 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 07 Nov 2005 13:33:30 +0100
Subject: moin / bugzilla / qemu
In-Reply-To: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com> (Florian
	La Roche's message of "Mon, 7 Nov 2005 12:30:12 +0100")
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
Message-ID: <87acggljs5.fsf@kosh.bigo.ensc.de>

laroche at redhat.com (Florian La Roche) writes:

> I've briefly tested a nearly current FC-development install
> and have put together the following rpm packages to be installed
> pretty easy:
> ...
> - qemu: this package builds together with the kqemu kernel modul. You have
>   to download it from the http://qemu.org/ website and then compile the
>   src.rpm)

Which version are you using? Here, 0.7.2 fails to build on FC4 due to
gcc-4 issues (which are not trivial to fix).



Enrico



From sundaram at redhat.com  Mon Nov  7 12:38:14 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 18:08:14 +0530
Subject: Sabayon Screencast
Message-ID: <436F4AB6.3040106@redhat.com>

Hi

Someone was complaining about the difficulty with customizing GNOME and 
disabling the command line among other things. Sabayon can do this and 
much more. Available in Fedora Extras repository. Here is a screencast 
for you to check this out

http://www.gnome.org/~alexl/sabayon-screencast.html

Courtesy: http://fedoraproject.org/people

Have fun!

regards
Rahul



From buildsys at redhat.com  Mon Nov  7 12:38:33 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 7 Nov 2005 07:38:33 -0500
Subject: rawhide report: 20051107 changes
Message-ID: <200511071238.jA7CcXmW024793@porkchop.devel.redhat.com>

 

 
Updated Packages:

NetworkManager-0.5.1-3
----------------------
* Fri Oct 21 2005 Christopher Aillon <caillon at redhat.com> - 0.5.1-3
- Split out the -glib subpackage to have a -glib-devel package as well
- Add epoch to version requirements for bind and wireless-tools
- Update URL of project

* Wed Oct 19 2005 Christopher Aillon <caillon at redhat.com> - 0.5.1-2
- NetworkManager 0.5.1

* Mon Oct 17 2005 Christopher Aillon <caillon at redhat.com> - 0.5.0-2
- NetworkManager 0.5.0

audit-1.0.11-1
--------------
* Sun Nov 06 2005 Steve Grubb <sgrubb at redhat.com> 1.0.11-1
- Fix memory leaks in aureport & ausearch
- Fix auditd reconfig to change mail accts, too
- Fix stray pointer in sorting of aureport
- Added new message type
- Add results to all DAEMON messages

bluez-utils-2.22-1
------------------
* Sun Nov 06 2005 David Woodhouse <dwmw2 at redhat.com> 2.22-1
- Update to bluez-utils 2.22

dosfstools-2.11-3
-----------------
* Sun Nov 06 2005 Peter Vrabec <pvrabec at redhat.com> 2.11-3
- fix LFS (#172369)

eclipse-1:3.1.1-1jpp_6fc
------------------------
* Fri Nov 04 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_6fc
- Patch org.eclipse.help.webapp jasper classpath.

* Thu Nov 03 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_5fc
- Import work done by Debian Eclipse packagers:
  - Add Fedora version in Eclipse about dialog.
  - Update eclipse-javadoc.patch to match Debian's disable-filelog patch.
  - Remove buildDoc patches and add helpindexbuilder patch (e.o#114001).
  - Add patches to build Cairo SWT bindings.

fontconfig-2.3.92-1
-------------------
* Fri Nov 04 2005 Matthias Clasen <mclasen at redhat.com> - 2.3.92-1
- Update to 2.3.92

fonts-ISO8859-2-1.0-16
----------------------
* Mon Nov 07 2005 Caolan McNamara <caolanm at redhat.com> - 1.0-16
- modular X

fonts-KOI8-R-1.0-9
------------------
* Mon Nov 07 2005 Caolan McNamara <caolanm at redhat.com> 1.0-9
gimp-2:2.2.9-1
--------------
* Wed Nov 02 2005 Nils Philippsen <nphilipp at redhat.com> - 2.2.9
- version 2.2.9
- first attempt at dealing with modular X

* Tue Aug 16 2005 Nils Philippsen <nphilipp at redhat.com>
- rebuild

* Thu Jul 28 2005 Nils Philippsen <nphilipp at redhat.com>
- fix gimptool manpage symlink

gphoto2-2.1.6-3
---------------
* Mon Nov 07 2005 Radek Vokal <rvokal at redhat.com> 2.1.6-3
- become self-hosting, don't depend on installed libs (#106442,#172519)

kernel-2.6.14-1.1651_FC5
------------------------
* Mon Nov 07 2005 Dave Jones <davej at redhat.com>
- silence some selinux messages.

* Sun Nov 06 2005 Dave Jones <davej at redhat.com>
- 2.6.14-git9

less-393-1
----------
* Mon Nov 07 2005 Jindrich Novy <jnovy at redhat.com> 393-1
- update to less-393
- groom Foption patch a bit
- remove obsolete ncursesw and utf8detect patches

libgnomeui-2.12.0-3
-------------------
* Sun Nov 06 2005 Matthias Clasen <mclasen at redhat.com> - 2.12.0-3
- Switch requires to modular X

nut-2.0.2-3
-----------
* Mon Nov 07 2005 Than Ngo <than at redhat.com> 2.0.2-3 
- rebuilt

perl-Archive-Tar-1.26-1
-----------------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 1.26

perl-Compress-Zlib-1.41-1
-------------------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 1.41

perl-HTML-Parser-3.46-1
-----------------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 3.46

perl-XML-Dumper-0.79-1
----------------------
* Sun Nov 06 2005 Florian La Roche <laroche at redhat.com>
- 0.79

xorg-x11-6.8.2-60
-----------------
* Sun Nov 06 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-60
- Remove "Provides: XFree86-font-utils" from font-utils subpackage.  Any
  packages which used XFree86-font-utils or xorg-x11-font-utils as a
  dependency should now start using "mkfontdir", "mkfontscale" virtual
  dependencies et al. to remain compatibile across implementations and
  with different packaging.
- Added "Provides: bdftopcf" virtual provide to font-utils subpackage.
- Removed conditional building of X supplied fontconfig, as external fontconfig
  should always be used.  Removd with_fontconfig macro also.

Broken deps for i386
----------------------------------------------------------
	hplip - 0.9.6-4.i386 requires libnetsnmp.so.5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.i386 requires XFree86-devel
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	synaptics - 0.14.3-3.i386 requires XFree86-libs
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.i386 requires libnetsnmp.so.5



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.ppc64 requires XFree86-devel
	hplip - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.ppc64 requires libnetsnmp.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc
----------------------------------------------------------
	libsane-hpaio - 0.9.6-4.ppc requires libnetsnmp.so.5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	synaptics - 0.14.3-3.ppc requires XFree86-libs
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.ppc requires libnetsnmp.so.5
	SDL-devel - 1.2.8-3.2.ppc requires XFree86-devel



Broken deps for x86_64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	synaptics - 0.14.3-3.x86_64 requires XFree86-libs
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	SDL-devel - 1.2.8-3.2.x86_64 requires XFree86-devel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	libsane-hpaio - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	hplip - 0.9.6-4.x86_64 requires libnetsnmp.so.5()(64bit)



Broken deps for s390
----------------------------------------------------------
	nut - 2.0.0-4.s390 requires libnetsnmp.so.5
	SDL-devel - 1.2.8-3.2.s390 requires XFree86-devel



Broken deps for ia64
----------------------------------------------------------
	SDL-devel - 1.2.8-3.2.ia64 requires XFree86-devel
	libsane-hpaio - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	hplip - 0.9.6-4.ia64 requires libnetsnmp.so.5()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for s390x
----------------------------------------------------------
	nut - 2.0.0-4.s390x requires libnetsnmp.so.5()(64bit)
	SDL-devel - 1.2.8-3.2.s390x requires XFree86-devel





From jakub at redhat.com  Mon Nov  7 12:45:09 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Mon, 7 Nov 2005 07:45:09 -0500
Subject: moin / bugzilla / qemu
In-Reply-To: <87acggljs5.fsf@kosh.bigo.ensc.de>
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
	<87acggljs5.fsf@kosh.bigo.ensc.de>
Message-ID: <20051107124508.GU16034@devserv.devel.redhat.com>

On Mon, Nov 07, 2005 at 01:33:30PM +0100, Enrico Scholz wrote:
> laroche at redhat.com (Florian La Roche) writes:
> 
> > I've briefly tested a nearly current FC-development install
> > and have put together the following rpm packages to be installed
> > pretty easy:
> > ...
> > - qemu: this package builds together with the kqemu kernel modul. You have
> >   to download it from the http://qemu.org/ website and then compile the
> >   src.rpm)
> 
> Which version are you using? Here, 0.7.2 fails to build on FC4 due to
> gcc-4 issues (which are not trivial to fix).

If you are talking about abusing register variables on i?86, then that's
just qemu's fault.  On a so much register starved arch as i?86 is,
reserving 4 registers as global register variables is very unwise
thing to do, even if it had a small chance of compiling, the resulting
code will be terrible (4 reserved by app, %esp reserved for stack pointer,
%ebx reserved in PIC code and %ebp reserved when not omitting frame pointer
or when using alloca/VLAs means 1 to 3 registers left for all the rest, plus
i?86 is CISCy, so some instructions require certain fixed registers).

	Jakub



From mail-lists at karan.org  Mon Nov  7 12:45:20 2005
From: mail-lists at karan.org (Karanbir Singh)
Date: Mon, 07 Nov 2005 12:45:20 +0000
Subject: moin / bugzilla / qemu
In-Reply-To: <87acggljs5.fsf@kosh.bigo.ensc.de>
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
	<87acggljs5.fsf@kosh.bigo.ensc.de>
Message-ID: <436F4C60.8050807@karan.org>

Enrico Scholz wrote:
> laroche at redhat.com (Florian La Roche) writes:
> 
> 
>>I've briefly tested a nearly current FC-development install
>>and have put together the following rpm packages to be installed
>>pretty easy:
>>...
>>- qemu: this package builds together with the kqemu kernel modul. You have
>>  to download it from the http://qemu.org/ website and then compile the
>>  src.rpm)
> 
> 
> Which version are you using? Here, 0.7.2 fails to build on FC4 due to
> gcc-4 issues (which are not trivial to fix).
> 

[kbsingh at localhost ~]$ rpm -qf `which qemu`
qemu-0.7.2-2.fc4.kb
[kbsingh at localhost ~]$ uname -a
Linux localhost.localdomain 2.6.12-1.1456_FC4 #1 SMP Thu Sep 22 02:18:46 
EDT 2005 ppc64 ppc64 ppc64 GNU/Linux
[kbsingh at localhost ~]$ gcc --version
gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

========
builds and works fine - this is from the RPMForge.net packaging

-- 
Karanbir Singh : http://www.karan.org/ : 2522219 at icq



From alan at redhat.com  Mon Nov  7 12:59:52 2005
From: alan at redhat.com (Alan Cox)
Date: Mon, 7 Nov 2005 07:59:52 -0500
Subject: Sabayon Screencast
In-Reply-To: <436F4AB6.3040106@redhat.com>
References: <436F4AB6.3040106@redhat.com>
Message-ID: <20051107125952.GA16671@devserv.devel.redhat.com>

On Mon, Nov 07, 2005 at 06:08:14PM +0530, Rahul Sundaram wrote:
> http://www.gnome.org/~alexl/sabayon-screencast.html

Seems to be a link to a proprietary plugin object. 



From sundaram at redhat.com  Mon Nov  7 13:04:26 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 18:34:26 +0530
Subject: Sabayon Screencast
In-Reply-To: <20051107125952.GA16671@devserv.devel.redhat.com>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
Message-ID: <436F50DA.2080606@redhat.com>

Alan Cox wrote:

>On Mon, Nov 07, 2005 at 06:08:14PM +0530, Rahul Sundaram wrote:
>  
>
>>http://www.gnome.org/~alexl/sabayon-screencast.html
>>    
>>
>
>Seems to be a link to a proprietary plugin object. 
>
>  
>
Yes. Flash. Someone can make Ogg theora movies. Istanbul in Fedora 
Extras is useful for that

regards
Rahul



From alexl at redhat.com  Mon Nov  7 13:17:13 2005
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 07 Nov 2005 14:17:13 +0100
Subject: Sabayon Screencast
In-Reply-To: <436F50DA.2080606@redhat.com>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com>
Message-ID: <1131369433.17339.34.camel@greebo>

On Mon, 2005-11-07 at 18:34 +0530, Rahul Sundaram wrote:
> Alan Cox wrote:
> 
> >On Mon, Nov 07, 2005 at 06:08:14PM +0530, Rahul Sundaram wrote:
> >  
> >
> >>http://www.gnome.org/~alexl/sabayon-screencast.html
> >>    
> >>
> >
> >Seems to be a link to a proprietary plugin object. 
> >
> >  
> >
> Yes. Flash. Someone can make Ogg theora movies. Istanbul in Fedora 
> Extras is useful for that

I used vnc2swf, which is very nice for doing screencasts, does Istanbul
work similarly? If someone could recode the file as ogg that would be
very nice.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a time-tossed Amish cyborg trapped in a world he never made. She's a 
time-travelling impetuous queen of the dead prone to fits of savage, 
blood-crazed rage. They fight crime! 



From enrico.scholz at informatik.tu-chemnitz.de  Mon Nov  7 13:20:42 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 07 Nov 2005 14:20:42 +0100
Subject: moin / bugzilla / qemu
In-Reply-To: <20051107124508.GU16034@devserv.devel.redhat.com> (Jakub
	Jelinek's message of "Mon, 7 Nov 2005 07:45:09 -0500")
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
	<87acggljs5.fsf@kosh.bigo.ensc.de>
	<20051107124508.GU16034@devserv.devel.redhat.com>
Message-ID: <8764r4lhlh.fsf@kosh.bigo.ensc.de>

jakub at redhat.com (Jakub Jelinek) writes:

>> > - qemu: this package builds together with the kqemu kernel modul. You
>> >   have to download it from the http://qemu.org/ website and then
>> >   compile the src.rpm)
>> 
>> Which version are you using? Here, 0.7.2 fails to build on FC4 due to
>> gcc-4 issues (which are not trivial to fix).
>
> If you are talking about abusing register variables on i?86, then
> that's just qemu's fault.

That's one part. The other one is the detection (and replacement) of
the 'ret' in emulated functions. There, gcc-4 optimizes things so that
the 'ret' happens in the middle of the function followed by some less
probable (but required) branches.

My comment was not a complain about gcc4, just a question how qemu can
be built with gcc4... ;)



Enrico



From sundaram at redhat.com  Mon Nov  7 13:23:29 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 18:53:29 +0530
Subject: Sabayon Screencast
In-Reply-To: <1131369433.17339.34.camel@greebo>
References: <436F4AB6.3040106@redhat.com>	<20051107125952.GA16671@devserv.devel.redhat.com>	<436F50DA.2080606@redhat.com>
	<1131369433.17339.34.camel@greebo>
Message-ID: <436F5551.7060405@redhat.com>

Hi

>>Extras is useful for that
>>    
>>
>
>I used vnc2swf, which is very nice for doing screencasts, does Istanbul
>work similarly? If someone could recode the file as ogg that would be
>very nice.
>  
>
It doesnt work in a similar fashion but essentially does the same thing. 
If you can check this out from extras and do this one and future 
screencasts in the Ogg Theora format,  it would probably reach a wider 
audience not wanting to deal with proprietary formats and works out of 
the box on Fedora

regards
Rahul

Ps: I installed a seperate browser and flash in it just to view this 
screencast



From laroche at redhat.com  Mon Nov  7 13:24:24 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 7 Nov 2005 14:24:24 +0100
Subject: moin / bugzilla / qemu
In-Reply-To: <87acggljs5.fsf@kosh.bigo.ensc.de>
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
	<87acggljs5.fsf@kosh.bigo.ensc.de>
Message-ID: <20051107132424.GB6893@dudweiler.stuttgart.redhat.com>

On Mon, Nov 07, 2005 at 01:33:30PM +0100, Enrico Scholz wrote:
> laroche at redhat.com (Florian La Roche) writes:
> 
> > I've briefly tested a nearly current FC-development install
> > and have put together the following rpm packages to be installed
> > pretty easy:
> > ...
> > - qemu: this package builds together with the kqemu kernel modul. You have
> >   to download it from the http://qemu.org/ website and then compile the
> >   src.rpm)
> 
> Which version are you using? Here, 0.7.2 fails to build on FC4 due to
> gcc-4 issues (which are not trivial to fix).

We do have compat-gcc-32 in the distribution which I used. I haven't tried
the gcc4 unofficial/experimental patches since they are said to slow
things down quite a bit.

regards,

Florian La Roche



From laroche at redhat.com  Mon Nov  7 13:28:05 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 7 Nov 2005 14:28:05 +0100
Subject: moin / bugzilla / qemu
In-Reply-To: <8764r4lhlh.fsf@kosh.bigo.ensc.de>
References: <20051107113012.GA3171@dudweiler.stuttgart.redhat.com>
	<87acggljs5.fsf@kosh.bigo.ensc.de>
	<20051107124508.GU16034@devserv.devel.redhat.com>
	<8764r4lhlh.fsf@kosh.bigo.ensc.de>
Message-ID: <20051107132805.GC6893@dudweiler.stuttgart.redhat.com>

> My comment was not a complain about gcc4, just a question how qemu can
> be built with gcc4... ;)

I've started with dag's version of qemu. That one already has a few gcc4
patches included and I've seen a good reference from the wiki FAQ for
qemu to point at even more gcc4/qemu patches floating around:

    http://lilly.csoft.net/~jeffryj/cgi-bin/moin.cgi/FrequentlyAskedQuestions

regards,

Florian La Roche



From hughsient at gmail.com  Mon Nov  7 13:32:26 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 13:32:26 +0000
Subject: disappointment over default acpid config
In-Reply-To: <1131355242.10354.15.camel@rousalka.dyndns.org>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
Message-ID: <1131370346.4058.14.camel@localhost.localdomain>

On Mon, 2005-11-07 at 10:20 +0100, Nicolas Mailhot wrote:
> Le lundi 07 novembre 2005 ? 09:04 +0000, Richard Hughes a ?crit :
> > On Mon, 2005-11-07 at 09:30 +0100, Nicolas Mailhot wrote:
> > > Le dimanche 06 novembre 2005 ? 23:13 +0000, Richard Hughes a ?crit :
> > > 
> > > > I'm not sure the "without X" argument is that important (flame retardant
> > > > suit ON..) as the typical laptop isn't booting for very long. If we load
> > > > a headless g-p-m when gdm loads, then we have 99.999% of the time
> > > > covered.
> > > 
> > > Good power management is very important for set-top like HTPC boxes,
> > > where you may have a GUI running but it's certainly not the Gnome one
> > > (ie it's a desktop-less setup)
> > > So you're cutting yourself from new market segments, not only old ones.
> > 
> > So you would be using gnome-power-manager and gnome-power-preferences on
> > a set top box? Would you use NetworkManager also? STB's are a very
> > specialised niche, not something that gnome-power-manager is focused on.
> 
> If you put all the "niches" you've decided to ignore together that's a
> sizeable part of the market. Moreover this "niche" is very concerned
> about power management, much more than your average desktop user,
> because HTPCs are supposed to be always-on, at worst hibernating.

But do they run HAL, GNOME, glib, gconf and all the required deps for
all of these?

> > There's nothing wrong with creating a stripped down g-p-m (to interact
> > with HAL) as an optional initscript. But I really don't think this is
> > required -- feel free to jump on the g-p-m m/l if you require this
> > functionality.
> 
> I personaly don't. But if you've ever jumped on a HTPC forum, I doubt
> you could miss the long threads about Cool'n Quiet vs Mobile intel, best
> ways to control system fans, etc.

I'm guessing the way to do this would be to write a *very small* daemon
in pure C to control these devices directly. This is not what g-p-m was
envisioned to do -- it should work on a modern GUI on top of HAL.

> Actually I'm astonished you choose to ignore HTPCs. If someone is going
> to sort power management on desktop systems that's HTPC users. And even
> it's a niche it's a growing one - much like sound-card enabled PCs where
> one a niche and are now the norm.

I don't see the parallel. 

I've not had one user of a HTPC wanting to use g-p-m (that I know about)
as it's designed primarily for laptops and PC's.

Richard.



From pekkas at netcore.fi  Mon Nov  7 14:06:14 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Mon, 7 Nov 2005 16:06:14 +0200 (EET)
Subject: disappointment over default acpid config
In-Reply-To: <1131370346.4058.14.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0511071601230.25121@netcore.fi>

On Mon, 7 Nov 2005, Richard Hughes wrote:
> I've not had one user of a HTPC wanting to use g-p-m (that I know about)
> as it's designed primarily for laptops and PC's.

But that's the point.  Are we heading towards a situation where ACPI 
power management would only be feasible for those folks which run 
Gnome?

That prospect does not seem convincing to me.  The best thing would 
possibly be creating something like 'acpid' (if necessary) to act as a 
layer for power management on top of HAL, the layer which could also 
provide command-line tools to get and manipulate the state.

Gnome-power-manager could then interface that daemon/those tools for 
its GUI interface.  The code is already probably in g-p-m (or getting 
there), but the issue might be just moving it to a non-gnome, pure-C 
(and whatever attributes you want here) project which could be 
leveraged by all the distros and even non-X, non-interactive, etc. 
users.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From nicolas.mailhot at laposte.net  Mon Nov  7 14:22:04 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 15:22:04 +0100
Subject: Sabayon Screencast
In-Reply-To: <436F50DA.2080606@redhat.com>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com>
Message-ID: <1131373325.2996.4.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 18:34 +0530, Rahul Sundaram a ?crit :
> Alan Cox wrote:
> 
> >On Mon, Nov 07, 2005 at 06:08:14PM +0530, Rahul Sundaram wrote:
> >  
> >
> >>http://www.gnome.org/~alexl/sabayon-screencast.html

> >Seems to be a link to a proprietary plugin object. 

> Yes. Flash. Someone can make Ogg theora movies. Istanbul in Fedora 
> Extras is useful for that

BTW I know it's not really Fedora's problem, but I don't think it's
possible to install a flash-enabled i386 Firefox on x86_64 anymore

This promises to be fun at FC5 time

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/20051107/da139362/attachment.sig>

From sundaram at redhat.com  Mon Nov  7 14:24:20 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 19:54:20 +0530
Subject: disappointment over default acpid config
In-Reply-To: <Pine.LNX.4.64.0511071601230.25121@netcore.fi>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>
Message-ID: <436F6394.4080001@redhat.com>

Pekka Savola wrote:

> On Mon, 7 Nov 2005, Richard Hughes wrote:
>
>> I've not had one user of a HTPC wanting to use g-p-m (that I know about)
>> as it's designed primarily for laptops and PC's.
>
>
> But that's the point.  Are we heading towards a situation where ACPI 
> power management would only be feasible for those folks which run Gnome?

g-p-m is obviously intended for GNOME but would work on other desktop 
enviroments. Underlying framework like hal, dbus etc can be used by any 
other desktop environment to write their own frontends. a console only 
policy in plain C is possible too.

regards
Rahul



From dwmw2 at infradead.org  Mon Nov  7 14:27:21 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 07 Nov 2005 14:27:21 +0000
Subject: Sabayon Screencast
In-Reply-To: <1131373325.2996.4.camel@rousalka.dyndns.org>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com>
	<1131373325.2996.4.camel@rousalka.dyndns.org>
Message-ID: <1131373641.27347.57.camel@baythorne.infradead.org>

On Mon, 2005-11-07 at 15:22 +0100, Nicolas Mailhot wrote:
> BTW I know it's not really Fedora's problem, but I don't think it's
> possible to install a flash-enabled i386 Firefox on x86_64 anymore
> 
> This promises to be fun at FC5 time

Then we should make sure one of the GPL'd plugins is in FC5.

-- 
dwmw2




From nicolas.mailhot at laposte.net  Mon Nov  7 14:27:24 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 15:27:24 +0100
Subject: disappointment over default acpid config
In-Reply-To: <1131370346.4058.14.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
Message-ID: <1131373644.2996.10.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 13:32 +0000, Richard Hughes a ?crit :
> On Mon, 2005-11-07 at 10:20 +0100, Nicolas Mailhot wrote:
> > Le lundi 07 novembre 2005 ? 09:04 +0000, Richard Hughes a ?crit :
> > > On Mon, 2005-11-07 at 09:30 +0100, Nicolas Mailhot wrote:
> > > > Le dimanche 06 novembre 2005 ? 23:13 +0000, Richard Hughes a ?crit :
> > > > 
> > > > > I'm not sure the "without X" argument is that important (flame retardant
> > > > > suit ON..) as the typical laptop isn't booting for very long. If we load
> > > > > a headless g-p-m when gdm loads, then we have 99.999% of the time
> > > > > covered.
> > > > 
> > > > Good power management is very important for set-top like HTPC boxes,
> > > > where you may have a GUI running but it's certainly not the Gnome one
> > > > (ie it's a desktop-less setup)
> > > > So you're cutting yourself from new market segments, not only old ones.
> > > 
> > > So you would be using gnome-power-manager and gnome-power-preferences on
> > > a set top box? Would you use NetworkManager also? STB's are a very
> > > specialised niche, not something that gnome-power-manager is focused on.
> > 
> > If you put all the "niches" you've decided to ignore together that's a
> > sizeable part of the market. Moreover this "niche" is very concerned
> > about power management, much more than your average desktop user,
> > because HTPCs are supposed to be always-on, at worst hibernating.
> 
> But do they run HAL, GNOME, glib, gconf and all the required deps for
> all of these?

They run HAL and X. The rest is HTPC-specific UI's (with big buttons so
it's useable on a TV with a remote)

> I don't see the parallel. 
> 
> I've not had one user of a HTPC wanting to use g-p-m (that I know about)
> as it's designed primarily for laptops and PC's.

Because g-p-m is unfit for HTPC maybe ? Which doesn't mean there isn't a
HUGE interest in power management among HTPC people. Go visit
http://htpcnews.com/ or http://silentpcreview.com/ if you don't believe
me. 

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/20051107/888b10e5/attachment.sig>

From hughsient at gmail.com  Mon Nov  7 14:32:37 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 14:32:37 +0000
Subject: disappointment over default acpid config
In-Reply-To: <436F6394.4080001@redhat.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>
	<436F6394.4080001@redhat.com>
Message-ID: <1131373958.4058.25.camel@localhost.localdomain>

On Mon, 2005-11-07 at 19:54 +0530, Rahul Sundaram wrote:
> Pekka Savola wrote:
> 
> > On Mon, 7 Nov 2005, Richard Hughes wrote:
> >
> >> I've not had one user of a HTPC wanting to use g-p-m (that I know about)
> >> as it's designed primarily for laptops and PC's.
> >
> >
> > But that's the point.  Are we heading towards a situation where ACPI 
> > power management would only be feasible for those folks which run Gnome?
> 
> g-p-m is obviously intended for GNOME but would work on other desktop 
> enviroments. Underlying framework like hal, dbus etc can be used by any 
> other desktop environment to write their own frontends. a console only 
> policy in plain C is possible too.

Agreed.

Richard.



From jspaleta at gmail.com  Mon Nov  7 14:39:42 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 7 Nov 2005 09:39:42 -0500
Subject: disappointment over default acpid config
In-Reply-To: <1131370346.4058.14.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
Message-ID: <604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>

On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> I'm guessing the way to do this would be to write a *very small* daemon
> in pure C to control these devices directly. This is not what g-p-m was
> envisioned to do -- it should work on a modern GUI on top of HAL.

just to clarify for my own sake.. right now in rawhide... g-p-m is the
provided power management facility. But g-p-m needs a user to be
logged in to X before power management is active..including power
saving features for displays?

>From my own personally experience, certaintly anyone running a network
of thin clients is going to want at a minimum power saving features to
be active on the thin client moniters when no one is logged in...and
for the cpu if the thinclient allows for that.  It doesn't sound like
g-p-m provides for that right now.

There are 2 questions worth asking.
1)Should g-p-m be designed to handle the no user case or should there
different management program for the no user case? The g-p-m
developers need to answer this with authority.

2)And how the frell do you transition from one managing entity to the
other when a user does log in? Or to keep g-p-m from running if the
admin doesn't want per-user power settings and would prefer to keep
the systemwide "no user" logged in settings.


Whatever g-p-m project decides is its scope in terms of handling the
no user case... the rest of us need to be made aware..sooner rather
than later...so a second codebase can be spun up if needed.  I'd
rather see a second implimentation instead of extended  back and forth
over whether or not g-p-m should be handling these cases..getting us
nowhere.
If g-p-m has decided to punt these no user cases as a design
goal...then we need to make room for a no user solution and just as
importantly g-p-m needs to provide a facility by which another daemon
can transition control..or refuse to transition control. Don't
half-ass support for some no user cases. Either make the general no
user case part of the design or punt it completely and make room for a
transition from a no user daemon to the per-user g-p-m. Half-assing it
and only providing for "typical" no user situations is a mockery. You
might be able to claim "typical" desktop situations now..but no user
situations are going to be vastly more variable. Tying this into gdm
specifically..would be an example of a half-ass approach.
Whatever the no user solution is needs to be able to support beyond
the default dm... it needs to be a general solution.

-jef



From nicu_fedora at nicubunu.ro  Mon Nov  7 14:47:25 2005
From: nicu_fedora at nicubunu.ro (Nicu Buculei)
Date: Mon, 07 Nov 2005 16:47:25 +0200
Subject: Sabayon Screencast
In-Reply-To: <1131373641.27347.57.camel@baythorne.infradead.org>
References: <436F4AB6.3040106@redhat.com>	<20051107125952.GA16671@devserv.devel.redhat.com>	<436F50DA.2080606@redhat.com>	<1131373325.2996.4.camel@rousalka.dyndns.org>
	<1131373641.27347.57.camel@baythorne.infradead.org>
Message-ID: <436F68FD.7060601@nicubunu.ro>

David Woodhouse wrote:
> On Mon, 2005-11-07 at 15:22 +0100, Nicolas Mailhot wrote:
> 
>>BTW I know it's not really Fedora's problem, but I don't think it's
>>possible to install a flash-enabled i386 Firefox on x86_64 anymore
>>
>>This promises to be fun at FC5 time
> 
> 
> Then we should make sure one of the GPL'd plugins is in FC5.

the problem is neither swfdec nor gplflash does look good enough as 
features and performance, even for those simple screencasts.

-- 
nicu
my hats collection: http://fedora.nicubunu.ro/hats
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro



From jspaleta at gmail.com  Mon Nov  7 14:53:20 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 7 Nov 2005 09:53:20 -0500
Subject: Sabayon Screencast
In-Reply-To: <1131369433.17339.34.camel@greebo>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com> <1131369433.17339.34.camel@greebo>
Message-ID: <604aa7910511070653i7765a485l17ae6b19f014bc75@mail.gmail.com>

On 11/7/05, Alexander Larsson <alexl at redhat.com> wrote:
> I used vnc2swf, which is very nice for doing screencasts, does Istanbul
> work similarly? If someone could recode the file as ogg that would be
> very nice.

http://www.fedoraproject.org/wiki/ScreenCasting

as the page says you need the gst-plugins from rawhide. The magic that
makes this possible was introduced in gst-plugins post fc4. There are
of course performance caveats. I've packaged this up in
extras-development specifically with the hopes that people will start
using this and feel inspired to contribute back to upstream gst to
make the performance better.

You can skip using istanbul entirely and use a gst pipeline in a
terminal if you want to be super geeky about it.

-jef



From hughsient at gmail.com  Mon Nov  7 14:54:44 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 14:54:44 +0000
Subject: disappointment over default acpid config
In-Reply-To: <604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
Message-ID: <1131375284.4058.47.camel@localhost.localdomain>

On Mon, 2005-11-07 at 09:39 -0500, Jeff Spaleta wrote:
> On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> > I'm guessing the way to do this would be to write a *very small* daemon
> > in pure C to control these devices directly. This is not what g-p-m was
> > envisioned to do -- it should work on a modern GUI on top of HAL.
> 
> just to clarify for my own sake.. right now in rawhide... g-p-m is the
> provided power management facility.

It is one "option" :-)

>  But g-p-m needs a user to be
> logged in to X before power management is active..including power
> saving features for displays?

I don't know about displays. g-p-m just sets the timeout value for
gnome-screensaver, so it doesn't really get involved with the details.
Does gnome-screensaver run at the login screen?

> >From my own personally experience, certaintly anyone running a network
> of thin clients is going to want at a minimum power saving features to
> be active on the thin client moniters when no one is logged in...and
> for the cpu if the thinclient allows for that.  It doesn't sound like
> g-p-m provides for that right now.

Ohh, I agree. I'm not sure how the screenblanking is handled at the
login screen... anyone?

> There are 2 questions worth asking.
> 1)Should g-p-m be designed to handle the no user case or should there
> different management program for the no user case? The g-p-m
> developers need to answer this with authority.

Well, I guess I'm the main developer -- but I need more information to
answer this question fully. Can we run an arbitrary program (little
daemon) at gdmlogin time? In that case I could produce a "little-g-p-m"
daemon that has no gui but does the same stuff, which quits as soon as a
session g-p-m takes over. I think dbus connection management could be
used quite cleverly here too.

> 2)And how the frell do you transition from one managing entity to the
> other when a user does log in? Or to keep g-p-m from running if the
> admin doesn't want per-user power settings and would prefer to keep
> the systemwide "no user" logged in settings.

g-p-m just uses dbus permissions to talk to HAL, so the admin can
certainly lock this down per user, or per group. By default, anyone
"at_console" can do any "powersaving" action.

> Whatever g-p-m project decides is its scope in terms of handling the
> no user case... the rest of us need to be made aware..sooner rather
> than later...so a second codebase can be spun up if needed.  I'd
> rather see a second implimentation instead of extended  back and forth
> over whether or not g-p-m should be handling these cases..getting us
> nowhere.

Agreed. I'll have a bit of a hack this afternoon and see how quickly I
can knock up a said daemon.

> If g-p-m has decided to punt these no user cases as a design
> goal...then we need to make room for a no user solution and just as
> importantly g-p-m needs to provide a facility by which another daemon
> can transition control..or refuse to transition control. Don't
> half-ass support for some no user cases. Either make the general no
> user case part of the design or punt it completely and make room for a
> transition from a no user daemon to the per-user g-p-m. Half-assing it
> and only providing for "typical" no user situations is a mockery. You
> might be able to claim "typical" desktop situations now..but no user
> situations are going to be vastly more variable. Tying this into gdm
> specifically..would be an example of a half-ass approach.

Oops. Why half-assed?

> Whatever the no user solution is needs to be able to support beyond
> the default dm... it needs to be a general solution.

What about an optional system initscript that just runs this mini-g-p-m,
and then once the session g-p-m kicks in, it unloads? The whole system
initscript things gets very messy, very fast. I've tried this in the
past (early in the g-p-m archives) and it was horrid.

Richard.



From enrico.scholz at informatik.tu-chemnitz.de  Mon Nov  7 14:55:12 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 07 Nov 2005 15:55:12 +0100
Subject: disappointment over default acpid config
In-Reply-To: <436F6394.4080001@redhat.com> (Rahul Sundaram's message of
	"Mon, 07 Nov 2005 19:54:20 +0530")
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>
	<436F6394.4080001@redhat.com>
Message-ID: <871x1sld7z.fsf@kosh.bigo.ensc.de>

sundaram at redhat.com (Rahul Sundaram) writes:

> g-p-m is obviously intended for GNOME but would work on other desktop
> enviroments.

GNOME2 apps are usually not running properly in non-GNOME2 environments.
E.g. their fontsize can not be configured (running
'gnome-settings-daemon' is not possible because it *enforces* its ideas
about e.g. the keyboard layout or .Xresources which were configured in
other ways already).



Enrico



From sundaram at redhat.com  Mon Nov  7 15:03:19 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 20:33:19 +0530
Subject: disappointment over default acpid config
In-Reply-To: <871x1sld7z.fsf@kosh.bigo.ensc.de>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>	<436F6394.4080001@redhat.com>
	<871x1sld7z.fsf@kosh.bigo.ensc.de>
Message-ID: <436F6CB7.5000407@redhat.com>

Enrico Scholz wrote:

>sundaram at redhat.com (Rahul Sundaram) writes:
>
>  
>
>>g-p-m is obviously intended for GNOME but would work on other desktop
>>enviroments.
>>    
>>
>
>GNOME2 apps are usually not running properly in non-GNOME2 environments.
>E.g. their fontsize can not be configured (running
>'gnome-settings-daemon' is not possible because it *enforces* its ideas
>about e.g. the keyboard layout or .Xresources which were configured in
>other ways already).
>
>  
>
I never had any reason to configure font sizes while running GNOME apps 
on KDE. For my limited use GNOME apps worked fine on KDE and viceversa 
excepts for things like applets which didnt have a freedesktop 
specification. Might want to file some bug reports against GNOME 
bugzilla for specific use cases like configuring resources.

regards
Rahul



From jspaleta at gmail.com  Mon Nov  7 15:14:40 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 7 Nov 2005 10:14:40 -0500
Subject: disappointment over default acpid config
In-Reply-To: <1131375284.4058.47.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
	<1131375284.4058.47.camel@localhost.localdomain>
Message-ID: <604aa7910511070714p62124374o4a270fe04a19e1d0@mail.gmail.com>

On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> Oops. Why half-assed?

because... there are "no user logged-in" situations that never see gdm
or any dm running.
If this solution is a script that gdm's default PreSession runs thats
fine... the point is it can't be tied into the guts of gdm... it needs
to be a general solution for the no user case. Something
shellscriptable works as a general solution. Looking around here for
example... the thinclients at this facility aren't actually running
gdm in the no login case.

-jef



From alexl at redhat.com  Mon Nov  7 15:17:23 2005
From: alexl at redhat.com (Alexander Larsson)
Date: Mon, 07 Nov 2005 16:17:23 +0100
Subject: Sabayon Screencast
In-Reply-To: <604aa7910511070653i7765a485l17ae6b19f014bc75@mail.gmail.com>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com> <1131369433.17339.34.camel@greebo>
	<604aa7910511070653i7765a485l17ae6b19f014bc75@mail.gmail.com>
Message-ID: <1131376643.17339.37.camel@greebo>

On Mon, 2005-11-07 at 09:53 -0500, Jeff Spaleta wrote:
> On 11/7/05, Alexander Larsson <alexl at redhat.com> wrote:
> > I used vnc2swf, which is very nice for doing screencasts, does Istanbul
> > work similarly? If someone could recode the file as ogg that would be
> > very nice.
> 
> http://www.fedoraproject.org/wiki/ScreenCasting
> 
> as the page says you need the gst-plugins from rawhide. The magic that
> makes this possible was introduced in gst-plugins post fc4. There are
> of course performance caveats. I've packaged this up in
> extras-development specifically with the hopes that people will start
> using this and feel inspired to contribute back to upstream gst to
> make the performance better.
> 
> You can skip using istanbul entirely and use a gst pipeline in a
> terminal if you want to be super geeky about it.

It seems like istanbul is doing a full screengrab for each frame. That
can never compete with an XDamage based system like e.g. the gnome vnc
server that I use with vnc2swf.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a suave devious cowboy haunted by an iconic dead American confidante 
She's a mistrustful streetsmart museum curator who dreams of becoming Elvis. 
They fight crime! 



From nicolas.mailhot at laposte.net  Mon Nov  7 15:17:04 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 16:17:04 +0100
Subject: disappointment over default acpid config
In-Reply-To: <436F6CB7.5000407@redhat.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>
	<436F6394.4080001@redhat.com> <871x1sld7z.fsf@kosh.bigo.ensc.de>
	<436F6CB7.5000407@redhat.com>
Message-ID: <1131376626.2996.12.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 20:33 +0530, Rahul Sundaram a ?crit :
> Enrico Scholz wrote:
> 
> >sundaram at redhat.com (Rahul Sundaram) writes:
> >
> >  
> >
> >>g-p-m is obviously intended for GNOME but would work on other desktop
> >>enviroments.

Depends on your definition of "desktop"

Is a Mythtv interface a "desktop" ?

-- 
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/20051107/c7dd6c67/attachment.sig>

From hughsient at gmail.com  Mon Nov  7 15:20:12 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 15:20:12 +0000
Subject: disappointment over default acpid config
In-Reply-To: <604aa7910511070714p62124374o4a270fe04a19e1d0@mail.gmail.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
	<1131375284.4058.47.camel@localhost.localdomain>
	<604aa7910511070714p62124374o4a270fe04a19e1d0@mail.gmail.com>
Message-ID: <1131376812.4058.50.camel@localhost.localdomain>

On Mon, 2005-11-07 at 10:14 -0500, Jeff Spaleta wrote:
> On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> > Oops. Why half-assed?
> 
> because... there are "no user logged-in" situations that never see gdm
> or any dm running.
> If this solution is a script that gdm's default PreSession runs thats
> fine... the point is it can't be tied into the guts of gdm... it needs
> to be a general solution for the no user case. Something
> shellscriptable works as a general solution. Looking around here for
> example... the thinclients at this facility aren't actually running
> gdm in the no login case.

So a small non-gui, shellscriptable version of g-p-m would do the trick?

Can you jump on the g-p-m m/l [1] and I'll see what I can do:

Richard

[1] http://lists.sourceforge.net/lists/listinfo/gnome-power-devel



From sundaram at redhat.com  Mon Nov  7 15:27:42 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 20:57:42 +0530
Subject: Sabayon Screencast
In-Reply-To: <1131376643.17339.37.camel@greebo>
References: <436F4AB6.3040106@redhat.com>	<20051107125952.GA16671@devserv.devel.redhat.com>	<436F50DA.2080606@redhat.com>
	<1131369433.17339.34.camel@greebo>	<604aa7910511070653i7765a485l17ae6b19f014bc75@mail.gmail.com>
	<1131376643.17339.37.camel@greebo>
Message-ID: <436F726E.5090300@redhat.com>

Hi

>
>It seems like istanbul is doing a full screengrab for each frame. That
>can never compete with an XDamage based system like e.g. the gnome vnc
>server that I use with vnc2swf.
>  
>
Perhaps not but it would probably suffice to do a screencast. One quick 
grab I did a few months back on a rawhide system. Not a comprehensive 
test by any means but it did work well except for being serious 
demanding on resources.

http://people.redhat.com/sundaram/desktop-recording.ogg

The developer might be open to suggestions on use a different efficient 
framework

http://live.gnome.org/Istanbul

regards
Rahul



From jspaleta at gmail.com  Mon Nov  7 15:28:30 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 7 Nov 2005 10:28:30 -0500
Subject: Sabayon Screencast
In-Reply-To: <1131376643.17339.37.camel@greebo>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com> <1131369433.17339.34.camel@greebo>
	<604aa7910511070653i7765a485l17ae6b19f014bc75@mail.gmail.com>
	<1131376643.17339.37.camel@greebo>
Message-ID: <604aa7910511070728jef0dc52j4a4a23372af88d2e@mail.gmail.com>

On 11/7/05, Alexander Larsson <alexl at redhat.com> wrote:
> It seems like istanbul is doing a full screengrab for each frame. That
> can never compete with an XDamage based system like e.g. the gnome vnc
> server that I use with vnc2swf.

I could have sworn the gst coders were working on xdamage support for
the ximagesrc gst-plugin.  Instabul is a very thin layer over gst
really. The real magic is the gst pipeline. I wonder if anyone with
first hand gst development experience could comment on this more
accurately.

I never claimed the performance was the best, but this is the best
open solution we have right now. Since we can not ship a
flashplayer...yet... this community needs theora solutions... not
flash ones. Regardless of the present performance problems there are
certaintly benefits to working with this technology now.

-jef"wouldn't it be great if gst gained support for vnc session
capture directly to theora"spaleta



From linux at pilot.org.ua  Mon Nov  7 16:02:38 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Mon, 7 Nov 2005 18:02:38 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
Message-ID: <20051107180238.680525a3.linux@pilot.org.ua>

> Basically, you are advocating a rewrite of /etc/sysconfig/networking and
> /etc/sysconfig/network-scripts. You may start with a detailed explanation as
> to why the setup, that Redhat has provided, is not up to task.

I advocate an alternative, that can be installed and switched into.
I know that people are used to initscripts and don't want to throw it away.
But some people (not only me) are not satisfied with initscripts-way,
see bugzilla.redhat.com for details. I look at that bugs from time to time
and some are seen for several years yet. Being net-scripts maintainer in
ALTLinux, I can't blame Bill Nottingham for that, some things are unfixable
with current design.

A working solution, that was done is ALTLinux, is to:
1. Split initscripts so that network-related part goes to net-scripts package.
net-scripts will provide network-config-subsystem.
2. Find all dependencies on initscripts, change some to
network-config-subsystem. Patch packages that depend on
network-config-subsystem.
3. Pack /etc/net, which will provide network-config-subsystem. Now we have 2
conflicting packages, only one of which will be installed at once. The whole
system should work independently of which one is installed, so it's up to
user which one to use.

Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it.
But those who need more than current initscripts (Ok, network part of
initscripts) can provide, are left with rc.local and an editor. Here is a
list of what currently /etc/net can do but initscripts can't:
- QoS
- inter-interface dependencies
- configuration profiles
- multi-host configuration
- routing rules
- ifrename support
- ifplugd support
[...]
- EXTENSIBLE DESIGN

I (and other people) find solutions of everyday tasks with /etc/net. I don't
want to make others think the way I do, but I need a way to give people choice
freedom within FC. This freedom is demanded.

-- 
    DO4-UANIC



From dedourek at unb.ca  Mon Nov  7 15:37:27 2005
From: dedourek at unb.ca (John DeDourek)
Date: Mon, 07 Nov 2005 11:37:27 -0400
Subject: disappointment over default acpid config
In-Reply-To: <1131375284.4058.47.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
	<1131375284.4058.47.camel@localhost.localdomain>
Message-ID: <436F74B7.7040502@unb.ca>

>>If g-p-m has decided to punt these no user cases as a design
>>goal...then we need to make room for a no user solution and just as
>>importantly g-p-m needs to provide a facility by which another daemon
>>can transition control..or refuse to transition control. Don't
>>half-ass support for some no user cases. Either make the general no
>>user case part of the design or punt it completely and make room for a
>>transition from a no user daemon to the per-user g-p-m. Half-assing it
>>and only providing for "typical" no user situations is a mockery. You
>>might be able to claim "typical" desktop situations now..but no user
>>situations are going to be vastly more variable. Tying this into gdm
>>specifically..would be an example of a half-ass approach.

My laptop boots to command line.  I go into and out of X (using
"startx" depending on whether I need an agile machine with minimum
software running or a pretty desktop.

It is essential that power management run regardless of whether I
am in the desktop or not.  Therefore I will use a non-Gnome solution
for power control

Therefore it is essential that I be able to easily prevent the
Gnome power management from interferring with my preferred power
management, and that this be supported by the configureation
of the Gnome power manager and that this be documented as part
of the Fedora install procedure.



From dedourek at unb.ca  Mon Nov  7 15:40:10 2005
From: dedourek at unb.ca (John DeDourek)
Date: Mon, 07 Nov 2005 11:40:10 -0400
Subject: disappointment over default acpid config
In-Reply-To: <436F74B7.7040502@unb.ca>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>	<1131375284.4058.47.camel@localhost.localdomain>
	<436F74B7.7040502@unb.ca>
Message-ID: <436F755A.8080402@unb.ca>



John DeDourek wrote:

>>> If g-p-m has decided to punt these no user cases as a design
>>> goal...then we need to make room for a no user solution and just as
>>> importantly g-p-m needs to provide a facility by which another daemon
>>> can transition control..or refuse to transition control. Don't
>>> half-ass support for some no user cases. Either make the general no
>>> user case part of the design or punt it completely and make room for a
>>> transition from a no user daemon to the per-user g-p-m. Half-assing it
>>> and only providing for "typical" no user situations is a mockery. You
>>> might be able to claim "typical" desktop situations now..but no user
>>> situations are going to be vastly more variable. Tying this into gdm
>>> specifically..would be an example of a half-ass approach.
> 
> 
> My laptop boots to command line.  I go into and out of X (using
> "startx" depending on whether I need an agile machine with minimum
> software running or a pretty desktop.
> 
> It is essential that power management run regardless of whether I
> am in the desktop or not.  Therefore I will use a non-Gnome solution
> for power control
> 
> Therefore it is essential that I be able to easily prevent the
> Gnome power management from interferring with my preferred power
> management, and that this be supported by the configureation
> of the Gnome power manager and that this be documented as part
> of the Fedora install procedure.
> 

I should have added that lack of this feature would be a "show-stopper"
for me for FC5 and would require that I move to another distribution.



From sundaram at redhat.com  Mon Nov  7 15:43:45 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 21:13:45 +0530
Subject: disappointment over default acpid config
In-Reply-To: <436F755A.8080402@unb.ca>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>	<1131375284.4058.47.camel@localhost.localdomain>	<436F74B7.7040502@unb.ca>
	<436F755A.8080402@unb.ca>
Message-ID: <436F7631.7080005@redhat.com>

Hi

>
> I should have added that lack of this feature would be a "show-stopper"
> for me for FC5 and would require that I move to another distribution.
>
Wow. Thats a terrific demand but seriously which software provides such 
console mode power management already?. If you dont want g-p-m, removing 
the package is a easy thing to do.

regards
Rahul



From hughsient at gmail.com  Mon Nov  7 15:47:12 2005
From: hughsient at gmail.com (Richard Hughes)
Date: Mon, 07 Nov 2005 15:47:12 +0000
Subject: disappointment over default acpid config
In-Reply-To: <436F7631.7080005@redhat.com>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
	<1131375284.4058.47.camel@localhost.localdomain>	<436F74B7.7040502@unb.ca>
	<436F755A.8080402@unb.ca>  <436F7631.7080005@redhat.com>
Message-ID: <1131378432.2490.1.camel@study>

On Mon, 2005-11-07 at 21:13 +0530, Rahul Sundaram wrote:
> Hi
> 
> >
> > I should have added that lack of this feature would be a "show-stopper"
> > for me for FC5 and would require that I move to another distribution.
> >
> Wow. Thats a terrific demand but seriously which software provides such 
> console mode power management already?. If you dont want g-p-m, removing 
> the package is a easy thing to do.

Or just disable the dbus powermanagement permissions for HAL
in /etc/dbus-1/system.d/hal.conf

Richard.



From enrico.scholz at informatik.tu-chemnitz.de  Mon Nov  7 15:56:22 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 07 Nov 2005 16:56:22 +0100
Subject: disappointment over default acpid config
In-Reply-To: <436F6CB7.5000407@redhat.com> (Rahul Sundaram's message of
	"Mon, 07 Nov 2005 20:33:19 +0530")
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131303014.17044.4.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>
	<1131317853.17044.21.camel@localhost.localdomain>
	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>
	<436F6394.4080001@redhat.com> <871x1sld7z.fsf@kosh.bigo.ensc.de>
	<436F6CB7.5000407@redhat.com>
Message-ID: <87wtjkjvtl.fsf@kosh.bigo.ensc.de>

sundaram at redhat.com (Rahul Sundaram) writes:

>>>g-p-m is obviously intended for GNOME but would work on other desktop
>>>enviroments.
>> ...
>>GNOME2 apps are usually not running properly in non-GNOME2 environments.
>>E.g. their fontsize can not be configured (running 'gnome-settings-daemon'
>>is not possible because it *enforces* its ideas about e.g. the keyboard
>>layout or .Xresources which were configured in other ways already).
>>
> I never had any reason to configure font sizes while running GNOME apps on
> KDE.

My grandpa requires large fonts, I do not like the default Gnome2 fonts
and specialized environments like VDR/TV need larger/other fonts too.


> For my limited use GNOME apps worked fine on KDE and viceversa
> excepts for things like applets which didnt have a freedesktop
> specification. Might want to file some bug reports against GNOME
> bugzilla for specific use cases like configuring resources.

Such requests exist, but it does not make much sense to ask Gnome2
developers for additional configurability :(



Enrico



From ph18 at cornell.edu  Mon Nov  7 15:59:53 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Mon, 07 Nov 2005 10:59:53 -0500
Subject: Sabayon Screencast
In-Reply-To: <1131373325.2996.4.camel@rousalka.dyndns.org>
References: <436F4AB6.3040106@redhat.com>	<20051107125952.GA16671@devserv.devel.redhat.com>	<436F50DA.2080606@redhat.com>
	<1131373325.2996.4.camel@rousalka.dyndns.org>
Message-ID: <436F79F9.6060900@cornell.edu>


>BTW I know it's not really Fedora's problem, but I don't think it's
>possible to install a flash-enabled i386 Firefox on x86_64 anymore
>
>This promises to be fun at FC5 time
>  
>
    Hey,  rpm --erase and use the installer from mozilla.org to install 
a 32-bit Mozilla,  then install flash.  Morality aside,  32-bit mplayer 
can still link Windows DLL's...  My main frustration is that the 
joystick ioctls changed going to 64-bit and that breaks most 32-bit games.

    Other operating systems install 32-bit applications under a 64-bit 
kernel.  For instance,  Solaris 10 installs a largely 32-bit userspace 
on both Sparc64 and AMD64.  This has the nice effect that the same 
Solaris 10 disk installs on both x86-32 and x86-64.  This is probably a 
good choice for SPARC,  but AMD64 gets a performance boost from the 
extra registers.

    64-bit Windows ships with a 32-bit IE,  largely for compatibility 
with Active X controls.

    The proprietary nature of flash burns me up too,  but it's highly 
effective and widely used...  Pretty much a requirement for any machine 
I use for serious web browsing.  The worst thing is that a lot of sites 
use broken "flash detection" algorithms that assume a Linux browser will 
never support flash.



From linux at pilot.org.ua  Mon Nov  7 16:36:45 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Mon, 7 Nov 2005 18:36:45 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <W8379431175319541131083997@nocme1bl6.telenet-ops.be>
References: <W8379431175319541131083997@nocme1bl6.telenet-ops.be>
Message-ID: <20051107183645.3b19bc36.linux@pilot.org.ua>

> Wireless WPA support is a glaring omission, for one. The
> wpa_supplicant software doesn't integrate well with the current RedHat
> scripts.
I was tols that WPA support in /etc/net does work. I personally don't use it though.

-- 
    DO4-UANIC



From sundaram at redhat.com  Mon Nov  7 16:13:31 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 07 Nov 2005 21:43:31 +0530
Subject: disappointment over default acpid config
In-Reply-To: <87wtjkjvtl.fsf@kosh.bigo.ensc.de>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>	<1131303014.17044.4.camel@localhost.localdomain>	<Pine.LNX.4.64.0511070048001.8420@netcore.fi>	<1131317853.17044.21.camel@localhost.localdomain>	<604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com>	<1131318839.9308.5.camel@localhost.localdomain>	<1131352221.10354.6.camel@rousalka.dyndns.org>	<1131354261.2490.5.camel@localhost.localdomain>	<1131355242.10354.15.camel@rousalka.dyndns.org>	<1131370346.4058.14.camel@localhost.localdomain>	<Pine.LNX.4.64.0511071601230.25121@netcore.fi>	<436F6394.4080001@redhat.com>
	<871x1sld7z.fsf@kosh.bigo.ensc.de>	<436F6CB7.5000407@redhat.com>
	<87wtjkjvtl.fsf@kosh.bigo.ensc.de>
Message-ID: <436F7D2B.4060705@redhat.com>

Hi

>Such requests exist, but it does not make much sense to ask Gnome2
>developers for additional configurability :(
>  
>
Depends.  Generalizing that would be difficult.  Everything that adds 
configurability has a associated cost. Some such things can be provided 
as extensions or plugins. Do we have specific bug reports already filed 
about this?.  It would be good to have a desktop neutral way to define 
such preferences which then probably implies sharing configuration 
details and formats. Freedesktop material I guess.

regards
Rahul



From dwmw2 at infradead.org  Mon Nov  7 16:13:48 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 07 Nov 2005 16:13:48 +0000
Subject: Sabayon Screencast
In-Reply-To: <436F79F9.6060900@cornell.edu>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com>
	<1131373325.2996.4.camel@rousalka.dyndns.org>
	<436F79F9.6060900@cornell.edu>
Message-ID: <1131380028.27347.67.camel@baythorne.infradead.org>

On Mon, 2005-11-07 at 10:59 -0500, Paul A Houle wrote:
>     Other operating systems install 32-bit applications under a 64-bit 
> kernel.  For instance,  Solaris 10 installs a largely 32-bit userspace 
> on both Sparc64 and AMD64.  This has the nice effect that the same 
> Solaris 10 disk installs on both x86-32 and x86-64.  This is probably a 
> good choice for SPARC,  but AMD64 gets a performance boost from the 
> extra registers.

Fedora does the same on ppc64 -- most userspace is ppc32.

-- 
dwmw2




From nicolas.mailhot at laposte.net  Mon Nov  7 16:18:56 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 07 Nov 2005 17:18:56 +0100
Subject: Sabayon Screencast
In-Reply-To: <436F79F9.6060900@cornell.edu>
References: <436F4AB6.3040106@redhat.com>
	<20051107125952.GA16671@devserv.devel.redhat.com>
	<436F50DA.2080606@redhat.com>
	<1131373325.2996.4.camel@rousalka.dyndns.org>
	<436F79F9.6060900@cornell.edu>
Message-ID: <1131380336.2996.17.camel@rousalka.dyndns.org>

Le lundi 07 novembre 2005 ? 10:59 -0500, Paul A Houle a ?crit :
> >BTW I know it's not really Fedora's problem, but I don't think it's
> >possible to install a flash-enabled i386 Firefox on x86_64 anymore
> >
> >This promises to be fun at FC5 time
> >  
> >
>     Hey,  rpm --erase and use the installer from mozilla.org to install 
> a 32-bit Mozilla,  then install flash.  Morality aside,  32-bit mplayer 
> can still link Windows DLL's...  My main frustration is that the 
> joystick ioctls changed going to 64-bit and that breaks most 32-bit games.

The problem is not you can't install a 32bit firefox
The problem is the flash rpm does not like the 32 bit firefox in
rawhide.

[root at rousalka nim]# /usr/lib/flash-plugin/setup

Registering flashplayer as a XPCOM component in
/usr/lib/firefox-1.5
ERROR: /usr/lib/firefox-1.5/ failed XPCOM xpti.dat generation.
ERROR!  SCRIPT SHOULD NEVER REACH HERE!
http://videl.ics.hawaii.edu/mailman/listinfo/linuxflash
Please send a list of files within /usr/lib/firefox-1.5 to the
linuxflash
mailing list along with your Linux distribution and what
browsers are installed.  Please include any error messages
that resulted from this package.
Type the following command in order to create a file list.

    find /usr/lib/firefox-1.5 > /root/filelist.txt
Setup is complete.

Again, not Fedora's problem, except for all the users that will scream
at FC5 release

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/20051107/674a445c/attachment.sig>

From jon.nettleton at gmail.com  Mon Nov  7 16:24:41 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Mon, 07 Nov 2005 11:24:41 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051107180238.680525a3.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
Message-ID: <1131380681.2588.3.camel@averatec>

On Mon, 2005-11-07 at 18:02 +0200, Denis Ovsienko wrote:
> > Basically, you are advocating a rewrite of /etc/sysconfig/networking and
> > /etc/sysconfig/network-scripts. You may start with a detailed explanation as
> > to why the setup, that Redhat has provided, is not up to task.
> 
> I advocate an alternative, that can be installed and switched into.
> I know that people are used to initscripts and don't want to throw it away.
> But some people (not only me) are not satisfied with initscripts-way,
> see bugzilla.redhat.com for details. I look at that bugs from time to time
> and some are seen for several years yet. Being net-scripts maintainer in
> ALTLinux, I can't blame Bill Nottingham for that, some things are unfixable
> with current design.
> 
> A working solution, that was done is ALTLinux, is to:
> 1. Split initscripts so that network-related part goes to net-scripts package.
> net-scripts will provide network-config-subsystem.
> 2. Find all dependencies on initscripts, change some to
> network-config-subsystem. Patch packages that depend on
> network-config-subsystem.
> 3. Pack /etc/net, which will provide network-config-subsystem. Now we have 2
> conflicting packages, only one of which will be installed at once. The whole
> system should work independently of which one is installed, so it's up to
> user which one to use.
> 
> Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it.
> But those who need more than current initscripts (Ok, network part of
> initscripts) can provide, are left with rc.local and an editor. Here is a
> list of what currently /etc/net can do but initscripts can't:
> - QoS
> - inter-interface dependencies
> - configuration profiles
> - multi-host configuration
> - routing rules
> - ifrename support
> - ifplugd support
> [...]
> - EXTENSIBLE DESIGN
> 
> I (and other people) find solutions of everyday tasks with /etc/net. I don't
> want to make others think the way I do, but I need a way to give people choice
> freedom within FC. This freedom is demanded.
> 
> -- 
>     DO4-UANIC
> 

Are you going to add support for all this in to system-config-network as
well?  :-)

Jon



From jspaleta at gmail.com  Mon Nov  7 16:44:10 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 7 Nov 2005 11:44:10 -0500
Subject: disappointment over default acpid config
In-Reply-To: <1131376812.4058.50.camel@localhost.localdomain>
References: <Pine.LNX.4.64.0511062029400.2871@netcore.fi>
	<1131318839.9308.5.camel@localhost.localdomain>
	<1131352221.10354.6.camel@rousalka.dyndns.org>
	<1131354261.2490.5.camel@localhost.localdomain>
	<1131355242.10354.15.camel@rousalka.dyndns.org>
	<1131370346.4058.14.camel@localhost.localdomain>
	<604aa7910511070639v71bb8cc5qc600d98b858e12aa@mail.gmail.com>
	<1131375284.4058.47.camel@localhost.localdomain>
	<604aa7910511070714p62124374o4a270fe04a19e1d0@mail.gmail.com>
	<1131376812.4058.50.camel@localhost.localdomain>
Message-ID: <604aa7910511070844n6205c07et27b0466c6d10fb24@mail.gmail.com>

On 11/7/05, Richard Hughes <hughsient at gmail.com> wrote:
> So a small non-gui, shellscriptable version of g-p-m would do the trick?

It might do the trick... I don't screw around with things like mythtv
setups so I don't know specifically what those sort of dedicated boxes
would need at a minimum.  Want you want to avoid is having non-desktop
users having to re-invent the whole stack. Clearly dedicated usage
like HTPC systems will need to re-invent UI elements that integrate
with that non-desktop UI.. but the deeper bits that interact dbus and
hal you'd want as a reusable codebase that people can layer other UI
over.

A deamon that runs with or without X, and uses some systemwide
settings would seem to be the bare minimum. Above that, having a
cli/scriptable tool to change the system wide settings would be a
plus, or enough documentation about available settings to make using
gconftool reasonably straight forward after some reading. Above that a
library interface that anyone could hook into via their narrowly
purposed user interface... I think HTPC would probably be an example
that would benefit from a library interface...instead of hacking up a
cli script solution underneath their non-desktop ui.

Essentially... there needs to be a way to provide "traditional"
systemwide configuration similar to what /etc/acpi attempted to do,
that does not conflict with the g-p-m that may get started with a user
logins in. And of course you'd like any solution here to leverage hal
and dbus (a reason why just letting acpid be the default solution
isn't the best long term option)  This "traditional" systemwide model
will run until the "desktop" g-p-m is started and you transition to a
per-user management scenario.  The key idea here is that power
management is a "from bootup" issue, not a "from login" issue and
there needs to be a way to make some set of defaults active from the
moment the system boots up and continue to be active even if the per
user g-m-p never starts.

-jef



>
> Can you jump on the g-p-m m/l [1] and I'll see what I can do:

I'm on the list now.

-jef



From mharris at redhat.com  Mon Nov  7 19:02:55 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Mon, 07 Nov 2005 14:02:55 -0500
Subject: X.Org modularization status page for Fedora Core 5
Message-ID: <436FA4DF.4070301@redhat.com>

I have created a craptastic web page to keep track of the status of
X.Org X11R7 modularization with my mad w3b sk1llz.  This is an informal
page only, and isn't always 100% up to date, however since many people
have been asking how things are progressing, I wanted to make something
publically available for people to watch.

So, please bookmark the following page and refer to it any time you
would like to know what the current status of modular X.Org is for
Fedora Core 5.

If anyone notices any mistakes or omissions, please bring them to my
attention in IRC or email, and I'll try to correct the page.

Also, if anyone feels they're l33t enough to challenge my web skillz,
and wants to restructure the page to look more pretty or improve
the overall layout in any way, feel free to snarf the data and send
me back a tarball demonstrating how badly your web page hacking skillz
trounce mine.

;o)

X.Org modularization status page:
http://mharris.ca/xorg-modular/xorg-modularization.html



From notting at redhat.com  Mon Nov  7 19:48:55 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 7 Nov 2005 14:48:55 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051107180238.680525a3.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
Message-ID: <20051107194854.GC22799@devserv.devel.redhat.com>

Denis Ovsienko (linux at pilot.org.ua) said: 
> Those who edit ifcfg-eth0 once a year will not want to learn a new way to do it.
> But those who need more than current initscripts (Ok, network part of
> initscripts) can provide, are left with rc.local and an editor. Here is a
> list of what currently /etc/net can do but initscripts can't:
> - QoS
> - inter-interface dependencies
> - configuration profiles
> - multi-host configuration
> - routing rules
> - ifrename support
> - ifplugd support
> [...]
> - EXTENSIBLE DESIGN
> 
> I (and other people) find solutions of everyday tasks with /etc/net. I don't
> want to make others think the way I do, but I need a way to give people choice
> freedom within FC. This freedom is demanded.

Generally... network-scripts will eventually go away - things will 
be moved to a framework involving NetworkManager. Hence, I don't
believe pulling in an entirely different framework in the interim
is really worth it.

Bill



From roland at redhat.com  Mon Nov  7 20:09:19 2005
From: roland at redhat.com (Roland McGrath)
Date: Mon,  7 Nov 2005 12:09:19 -0800 (PST)
Subject: resolving symbols with FORTIFY_SOURCE?
In-Reply-To: Pekka Savola's message of  Monday, 7 November 2005 01:20:28 +0200
	<Pine.LNX.4.64.0511070051040.8420@netcore.fi>
Message-ID: <20051107200919.D639A1809DC@magilla.sf.frob.com>

Try eu-addr2line.



From jkeating at j2solutions.net  Mon Nov  7 21:06:37 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 07 Nov 2005 13:06:37 -0800
Subject: X.Org modularization status page for Fedora Core 5
In-Reply-To: <436FA4DF.4070301@redhat.com>
References: <436FA4DF.4070301@redhat.com>
Message-ID: <1131397597.2929.54.camel@prometheus.gamehouse.com>

On Mon, 2005-11-07 at 14:02 -0500, Mike A. Harris wrote:
> Also, if anyone feels they're l33t enough to challenge my web skillz,
> and wants to restructure the page to look more pretty or improve
> the overall layout in any way, feel free to snarf the data and send
> me back a tarball demonstrating how badly your web page hacking skillz
> trounce mine.

Wouldn't this be prudent content for the Fedora wiki?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From goeran at uddeborg.se  Mon Nov  7 21:28:25 2005
From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=)
Date: Mon, 7 Nov 2005 22:28:25 +0100
Subject: Requirements with modular X
In-Reply-To: <436E3058.1030302@redhat.com>
References: <436A82AB.9070701@redhat.com>
	<17261.12338.475077.52511@mimmi.uddeborg.se>
	<436E3058.1030302@redhat.com>
Message-ID: <17263.50937.912226.253261@freddi.uddeborg.se>

Mike A. Harris writes:
> Provides: luxi-truetype-fonts
> Provides: luxi-Type1-fonts
> 
> Does this sound reasonable?

It does to me.  Since there is nothing that will work with current
packages in old systems, something that will work after some erratum
is released would be second best.

> The other alternative, is to conditionalize the spec file with
> build_fc1 build_fc2 build_fc3 build_fc4 build_fc5 macros,

If possible, I would avoid that.



From bbbush.yuan at gmail.com  Tue Nov  8 01:22:35 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Tue, 8 Nov 2005 09:22:35 +0800
Subject: How to simplify the process of adding multilingual %descriptions to
	rpm spec?
Message-ID: <76e72f800511071722h7841b6e2t@mail.gmail.com>

Greetings,

I believe that non-English speakers will be more happy to see
localized package %descriptions, when they are using a GUI package
management program. Most of users play Linux for fun, and they are
willing to search software in the huge packages list, looking for
interesting packages to install. But this fun only belongs to English
speakers. To Chinese, there is no way for an software package to
introduce itself.

Then how can these %descriptions be localized? If someone translate
them and commit patches to rpm spec files, that seems a bit funny and
boring. (Sorry for my bad vocabulary, though the single filed rpm spec
does have its cons and pros.) How to simplify this and reduce the
amount of work?

(There are too many excellent programs in both Core and Extras, while
I'm trying to introduce them to other Chinese users, I believe this
problem is essential.)

--
bbbush ^_^



From linux at pilot.org.ua  Tue Nov  8 05:54:40 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Tue, 8 Nov 2005 07:54:40 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <1131380681.2588.3.camel@averatec>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<1131380681.2588.3.camel@averatec>
Message-ID: <20051108075440.24cc7bda.linux@pilot.org.ua>

> Are you going to add support for all this in to system-config-network as
> well?  :-)
I develop /etc/net configurator from scratch, so its interface reflects
tricks awailable.

-- 
    DO4-UANIC



From linux at pilot.org.ua  Tue Nov  8 06:25:00 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Tue, 8 Nov 2005 08:25:00 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051107194854.GC22799@devserv.devel.redhat.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
Message-ID: <20051108082500.4cc7d549.linux@pilot.org.ua>

> Generally... network-scripts will eventually go away - things will 
> be moved to a framework involving NetworkManager. Hence, I don't
> believe pulling in an entirely different framework in the interim
> is really worth it.
It is worth. The problem is that other distributions borrow(ed) from FC(RH) and
most often borrowed thing is initscripts. Sometimes it's the only thing
they do to allow configure networking. If there is no straight way to switch
from net-scripts, people will continue to use it.
I want modern Linux systems to make use of modern network features independently
of distribution they were installed from.

-- 
    DO4-UANIC



From sundaram at redhat.com  Tue Nov  8 06:03:19 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 08 Nov 2005 11:33:19 +0530
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051108082500.4cc7d549.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>	<20051107180238.680525a3.linux@pilot.org.ua>	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20051108082500.4cc7d549.linux@pilot.org.ua>
Message-ID: <43703FA7.60906@redhat.com>

Denis Ovsienko wrote:

>>Generally... network-scripts will eventually go away - things will 
>>be moved to a framework involving NetworkManager. Hence, I don't
>>believe pulling in an entirely different framework in the interim
>>is really worth it.
>>    
>>
>It is worth. The problem is that other distributions borrow(ed) from FC(RH) and
>most often borrowed thing is initscripts. Sometimes it's the only thing
>they do to allow configure networking. If there is no straight way to switch
>from net-scripts, people will continue to use it.
>I want modern Linux systems to make use of modern network features independently
>of distribution they were installed from.
>
>  
>
Sure. NetworkManager is not specific to Fedora. It is already being used 
by several distributions. So instead of switching to net-scripts they 
can switch over to NeworkManager when it becomes capable of replacing 
everything else.

regards
Rahul



From linux at pilot.org.ua  Tue Nov  8 08:26:39 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Tue, 8 Nov 2005 10:26:39 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <43703FA7.60906@redhat.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20051108082500.4cc7d549.linux@pilot.org.ua>
	<43703FA7.60906@redhat.com>
Message-ID: <20051108102639.7c0d45dc.linux@pilot.org.ua>

> Sure. NetworkManager is not specific to Fedora. It is already being used 
> by several distributions. So instead of switching to net-scripts they 
> can switch over to NeworkManager when it becomes capable of replacing 
> everything else.
I have nothing against NetworkManager and those who want to use or develop it,
but my vision of how things should happen is different. I don't request anyting
except ability to use community member's right to participate in Fedora Core
development.

"The Fedora Project is an open source project sponsored by Red Hat and
supported by the Fedora community. It is also a proving ground for new
technology that may eventually make its way into Red Hat products. It is
not a supported product of Red Hat, Inc."
(c) http://fedora.redhat.com/

"The Fedora Project is a Red Hat sponsored and community-supported open
source project. It is not a supported product of Red Hat, Inc. The goal?
Work with the Linux community to build a complete, general purpose
operating system exclusively from free software. Public forum. Open
processes. A proving ground for new technology that may eventually make
its way into Red Hat products."
(c) http://www.redhat.com/en_us/USA/fedora/

I want to add extra functionality to FC, which has been demanded for years.
Why do you try to stop me? I want to start.

-- 
    DO4-UANIC



From sundaram at redhat.com  Tue Nov  8 09:05:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 08 Nov 2005 14:35:58 +0530
Subject: X.Org modularization status page for Fedora Core 5
In-Reply-To: <1131397597.2929.54.camel@prometheus.gamehouse.com>
References: <436FA4DF.4070301@redhat.com>
	<1131397597.2929.54.camel@prometheus.gamehouse.com>
Message-ID: <43706A76.40302@redhat.com>

Jesse Keating wrote:

>On Mon, 2005-11-07 at 14:02 -0500, Mike A. Harris wrote:
>  
>
>>Also, if anyone feels they're l33t enough to challenge my web skillz,
>>and wants to restructure the page to look more pretty or improve
>>the overall layout in any way, feel free to snarf the data and send
>>me back a tarball demonstrating how badly your web page hacking skillz
>>trounce mine.
>>    
>>
>
>Wouldn't this be prudent content for the Fedora wiki?
>
>  
>
Done. http://fedoraproject.org/wiki/Xorg/Modularization

regards
Rahul



From buildsys at redhat.com  Tue Nov  8 13:25:14 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 8 Nov 2005 08:25:14 -0500
Subject: rawhide report: 20051108 changes
Message-ID: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>

 
Updated Packages:

SDL-1.2.9-1
-----------
* Mon Nov 07 2005 Thomas Woerner <twoerner at redhat.com> 1.2.9-1
- new version 1.2.9 with additional gcc4 fixes
- using xorg-x11-devel instead of XFree86-devel

anaconda-10.89.7-1
------------------
* Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 10.89.7-1
- More detailed error logging (pnasrat)
- Add bnx2 driver (pjones)
- Various kickstart fixes (clumens, #172356)
- Fix shadow password convert (clumens)

* Fri Oct 28 2005 Jeremy Katz <katzj at redhat.com> - 10.89.6-1
- Make char devices slightly later to avoid tracebacks during tree compose
- Extract kernel-xen-guest for vmlinuz and initrd in images/xen
- Kickstart fix (clumens)
- Add some support for xen xvd blockdevs
- Select kernel-xen-guest as appropriate
- Ensure proper arch of glibc is selected (#171997)
- Select all proper multilib parts of a package (#171026)

* Thu Oct 27 2005 Jeremy Katz <katzj at redhat.com> - 10.89.5-1
- Another fix for kickstart + help hiding
- Fix finding of kernel type
- Make synaptics device nodes before X starts (clumens)
- Use nofb by default
- Add pycairo stuff (clumens)
- Set minimum displayed log level to WARNING, everything is still in 
  the logfiles (clumens)
- Try to clean up syslog (clumens)
- Allow installation of hypervisor + xen host kernel by booing with 'xen0' on 
  the installer command line
- Fix x86_64 traceback

audit-1.0.12-1
--------------
* Mon Nov 07 2005 Steve Grubb <sgrubb at redhat.com> 1.0.12-1
- Add 2 more summary reports
- Add 2 more message types

authconfig-5.0.3-1
------------------
* Mon Nov 07 2005 Tomas Mraz <tmraz at redhat.com> - 5.0.3-1
- add symlinks to python scripts in sbindir
- don't override nullok setting from system-auth (#96996)

autofs-1:4.1.4-13
-----------------
* Mon Nov 07 2005 Jeff Moyer <jmoyer at redhat.com> - 1:4.1.4-13
- Changed to sort -k 1, since that should be the same as +0.

checkpolicy-1.27.17-5
---------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-5
- Rebuild to get latest libsepol

cracklib-2.8.6-1
----------------
* Mon Nov 07 2005 Nalin Dahyabhai <nalin at redhat.com> 2.8.6-1
- update to 2.8.6
- remove .la file (#172632)

file-4.16-3
-----------
* Tue Nov 08 2005 Radek Vokal <rvokal at redhat.com> - 4.16-3
- remove .la files (#172633)

* Mon Oct 31 2005 Radek Vokal <rvokal at redhat.com> - 4.16-2
- fix core files output, show "from" (#172015)

* Tue Oct 18 2005 Radek Vokal <rvokal at redhat.com> - 4.16-1
- upgrade to upstream

fonts-ISO8859-2-1.0-16
----------------------
* Mon Nov 07 2005 Caolan McNamara <caolanm at redhat.com> - 1.0-16
- modular X

fonts-KOI8-R-1.0-9
------------------
* Mon Nov 07 2005 Caolan McNamara <caolanm at redhat.com> 1.0-9
fonts-chinese-3.01-1
--------------------
* Mon Nov 07 2005 Leon Ho <llch at redhat.com> - 3.01-1
- update uming and ukai to 0.1-0.dot.3

fonts-japanese-0.20050222-8
---------------------------
* Mon Nov 07 2005 Akira TAGOH <tagoh at redhat.com> - 0.20050222-8
- rely on PATH to find mkfontdir instead of /usr/X11R6/bin hardcoded.
- replace Requires: mkfontdir instead of /usr/X11R6/bin/mkfontdir.

glib-1:1.2.10-17
----------------
* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-17
- Remove .la files and static libs from the -devel package.

* Wed Mar 02 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-16
- Rebuild with gcc4

* Mon Aug 09 2004 Tim Waugh <twaugh at redhat.com> 1:1.2.10-15
- Fixed underquoted m4 definitions.

gphoto2-2.1.6-3
---------------
* Mon Nov 07 2005 Radek Vokal <rvokal at redhat.com> 2.1.6-3
- become self-hosting, don't depend on installed libs (#106442,#172519)

gtk+-1:1.2.10-47
----------------
* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-47
- Remove .la files and static libs

* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-46
- Rebuilt

hardlink-1:1.0-1.17
-------------------
* Mon Nov 07 2005 Jindrich Novy <jnovy at redhat.com>
- add hardlink man page
- add -h option
- use _sbindir instead of /usr/sbin directly
- don't warn because of uninitialized variable
- spec cleanup

hplip-0.9.6-5
-------------
* Mon Nov 07 2005 Tim Waugh <twaugh at redhat.com> 0.9.6-5
- Rebuilt.

imlib-1:1.9.13-26
-----------------
* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 1:1.9.13-26
- Remove static libs from the -devel package

kernel-2.6.14-1.1654_FC5
------------------------

less-393-1
----------
* Mon Nov 07 2005 Jindrich Novy <jnovy at redhat.com> 393-1
- update to less-393
- groom Foption patch a bit
- remove obsolete ncursesw and utf8detect patches

libIDL-0.8.6-2
--------------
* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 0.8.6-2
- Remove .la files and static libraries from the 
  -devel package

libselinux-1.27.19-1
--------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.19-1
- Update to latest from NSA
	* Merged seusers parser changes from Ivan Gyurdiev.
	* Merged setsebool to libsemanage patch from Ivan Gyurdiev.
	* Changed seusers parser to reject empty fields.

libsemanage-1.3.43-1
--------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.3.43-1
- Upgrade to latest from NSA
	* Merged seuser parser resync, dbase tracking and cleanup, strtol
	  bug, copyright, and assert space patches from Ivan Gyurdiev.
	* Added src/*_internal.h in preparation for other changes.
 	* Added hidden/hidden_proto/hidden_def to src/debug.[hc] and
          src/seusers.[hc].

* Thu Nov 03 2005 Dan Walsh <dwalsh at redhat.com> 1.3.41-1
- Upgrade to latest from NSA
	* Merged interface parse/print, context_to_string interface change,
	  move assert_noeof, and order preserving patches from Ivan Gyurdiev.
        * Added src/dso.h in preparation for other changes.
	* Merged install seusers, handle/error messages, MLS parsing,
	  and seusers validation patches from Ivan Gyurdiev.

libsepol-1.9.37-1
-----------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.9.37-1
- Upgrade to latest from NSA
	* Merged context destroy cleanup patch from Ivan Gyurdiev.

logrotate-3.7.2-11
------------------
* Mon Nov 07 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.2-11
- man description for "nodateext" option (#171577)
- remove not working "pattern" option (#171577)

net-snmp-5.2.2-0.rc4.1
----------------------
* Mon Nov 07 2005 Radek Vokal <rvokal at redhat.com> - 5.2.2-0.rc4.1
- update to release candidate 4

nut-2.0.2-3
-----------
* Mon Nov 07 2005 Than Ngo <than at redhat.com> 2.0.2-3 
- rebuilt

openhpi-2.0.3-4
---------------
* Mon Nov 07 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.3-4
- Added the openhpi config file
- Added missing /var/lib/openhpi dir with proper rights
- Added a few missing BuildPreReqs

php-5.0.5-5
-----------
* Mon Nov 07 2005 Joe Orton <jorton at redhat.com> 5.0.5-5
- pear: update to XML_RPC 1.4.4, XML_Parser 1.2.7, Mail 1.1.9 (#172528)

policycoreutils-1.27.20-1
-------------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.20-1
- Update to match NSA
	* Merged setsebool patch from Ivan Gyurdiev.
	  This moves setsebool from libselinux/utils to policycoreutils,
	  and rewrites it to use libsemanage for permanent boolean changes.

postgresql-8.1.0-1
------------------
* Mon Nov 07 2005 Tom Lane <tgl at redhat.com> 8.1.0-1
- Update to PostgreSQL 8.1.0, PyGreSQL 3.7, and jdbc driver build 404
- Fix PAM config file (must have account not only auth) (bug #167040)
- Add BuildPrereq: libxslt-devel (bug #170141)
- Sync with PGDG SRPM as much as feasible

* Fri Oct 14 2005 Tomas Mraz <tmraz at redhat.com>
- use include instead of pam_stack in pam config

postgresql-odbc-08.01.0100-1
----------------------------
* Mon Nov 07 2005 Tom Lane <tgl at redhat.com> 08.01.0100-1
- Update to version 08.01.0100.

pup-0.1.5-1
-----------
* Tue Nov 08 2005 Jeremy Katz <katzj at redhat.com> - 0.1.5-1
- show a 'no updates' screen if there aren't any available
- fix some tracebacks
- change the updates view to be slightly more user friendly

selinux-policy-mls-1.27.2-16
----------------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-16
- Allow scanimage to work with hplip
- Fix multiple definititions in file context
- Fix missing launch

selinux-policy-strict-1.27.2-16
-------------------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-16
- Allow scanimage to work with hplip
- Fix multiple definititions in file context
- Fix missing launch

selinux-policy-targeted-1.27.2-16
---------------------------------
* Mon Nov 07 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-16
- Allow scanimage to work with hplip
- Fix multiple definititions in file context
- Fix missing launch

synaptics-0:0.14.4-1
--------------------
* Mon Nov 07 2005 Paul Nasrat <pnasrat at redhat.com> - 0:0.14.4-1
- Modular X.org
- New upstream version

system-config-securitylevel-1.6.9-1
-----------------------------------
* Tue Nov 08 2005 Chris Lumens <clumens at redhat.com> 1.6.9-1
- Open the tcp IPP port as well (#90946).
- SELinux policy directory grab fix (dwalsh).

unixODBC-2.2.11-5
-----------------
* Mon Nov 07 2005 Tom Lane <tgl at redhat.com> 2.2.11-5
- Adjust BuildPrereq for modular X.

* Sun Oct 16 2005 Florian La Roche <laroche at redhat.com> 2.2.11-4
- link against dependent libs
- fix some bugs to resolve unknown symbols ;-(

* Thu Sep 29 2005 Tom Lane <tgl at redhat.com> 2.2.11-3
- Force update of yac.h because the copy in the distributed tarball does not
  match bison 2.0's numbering of symbols (bz #162676)
- Include documentation of text-file driver
- Use private libltdl so we can omit RTLD_GLOBAL from dlopen flags (bz #161399)

urw-fonts-2.3-2
---------------
* Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.3-2
- require (virtual) mkfontscale instead of path to handle 
  modular xorg (#172562)

util-linux-2.13-0.10.pre5
-------------------------
* Mon Nov 07 2005 Karel Zak <kzak at redhat.com> 2.13-0.10.pre5
- fix #171337 - mkfs.cramfs doesn't work correctly with empty files

* Fri Oct 28 2005 Karel Zak <kzak at redhat.com> 2.13-0.9.pre5
- rebuild

* Wed Oct 26 2005 Karel Zak <kzak at redhat.com> 2.13-0.8.pre5
- updated version of the patch for hwclock audit

xorg-x11-6.8.2-61
-----------------
* Mon Nov 07 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-61
- Added "Provides: xorg-x11-server-sdk" to sdk subpackage to provide forward
  compatibility with modular X for driver packages.
- Added versioning to "Provides: Xorg = 6.8.2-61" for things that
  require a specific version or newer of the X.Org server.  This should *only*
  be used by config tools.  Things like xdm/kdm/gdm should "Requires: Xserver".

yum-2.4.0-9
-----------
* Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-9
- enable plugins by default
- add installyonlyn plugin so that we only keep two kernels around by default

Broken deps for i386
----------------------------------------------------------
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.i586 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i586 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.i686 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.i686 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.i586 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc64
----------------------------------------------------------
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4






Broken deps for s390x
----------------------------------------------------------
	libglade2 - 2.5.1-3.s390 requires libcairo.so.2
	ImageMagick - 6.2.5.4-1.s390 requires libgs.so.8
	elfutils - 0.116-1.s390 requires libdw.so.1(ELFUTILS_0.116)
	elfutils - 0.116-1.s390 requires libdw.so.1
	GConf2 - 2.12.1-1.s390 requires libcairo.so.2
	gtk2-engines - 2.6.5-1.s390 requires libcairo.so.2
	vte - 0.11.15-1.fc5.s390 requires libcairo.so.2
	gail - 1.8.5-1.s390 requires libcairo.so.2
	gtk-engines - 1:0.12-7.s390 requires libgdk_imlib.so.1
	libwnck - 2.12.1-1.s390 requires libcairo.so.2
	libgnomeprintui22 - 2.12.1-1.s390 requires libcairo.so.2
	libgnomecanvas - 2.12.0-1.s390 requires libcairo.so.2
	gtk2 - 2.8.6-5.s390 requires libcairo.so.2
	kdebase - 6:3.4.92-1.s390 requires libdbus-qt-1.so.1
	gnome-keyring - 0.4.5-1.s390 requires libcairo.so.2
	pango - 1.10.1-5.s390 requires libcairo.so.2
	gtksourceview - 1.4.2-1.s390 requires libcairo.so.2



Broken deps for x86_64
----------------------------------------------------------
	gtksourceview - 1.4.2-1.i386 requires libcairo.so.2
	GConf2 - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libvos3gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libj680li_g.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-langpack-bg_BG - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-xsltfilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-eu_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gail - 1.8.5-1.i386 requires libcairo.so.2
	openoffice.org-langpack-ru - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-th_TH - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	glibc-debuginfo - 2.3.90-15.i386 requires glibc-debuginfo-common = 0:2.3.90-15
	openoffice.org-langpack-nn_NO - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-pa_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-hi_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-he_IL - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-de - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-fi_FI - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	vte - 0.11.15-1.fc5.i386 requires libcairo.so.2
	openoffice.org-langpack-cy_GB - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	elfutils - 0.116-1.i386 requires libdw.so.1(ELFUTILS_0.116)
	elfutils - 0.116-1.i386 requires libdw.so.1
	openoffice.org-langpack-sl_SI - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gtk-engines - 1:0.12-7.i386 requires libgdk_imlib.so.1
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libwpd-0.8.so.8
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsw680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-langpack-zu_ZA - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-pt_PT - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-ms_MY - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-base - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-af_ZA - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-ca_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-fr - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	openoffice.org-javafilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gtk2-engines - 2.6.5-1.i386 requires libcairo.so.2
	openoffice.org-langpack-ko_KR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	glibc-debuginfo - 2.3.90-15.i686 requires glibc-debuginfo-common = 0:2.3.90-15
	openoffice.org-langpack-sv - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libgnomeprintui22 - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-langpack-et_EE - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-zh_CN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.1)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-langpack-hr_HR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gtk2 - 2.8.6-5.i386 requires libcairo.so.2
	openoffice.org-langpack-ja_JP - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-nl - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libglade2 - 2.5.1-3.i386 requires libcairo.so.2
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-es - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-hu_HU - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-cs_CZ - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-bn_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	pango - 1.10.1-5.i386 requires libcairo.so.2
	kdebase - 6:3.4.92-1.i386 requires libdbus-qt-1.so.1
	gnome-keyring - 0.4.5-1.i386 requires libcairo.so.2
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-tr_TR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-pt_BR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_xo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_ofa680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires liblegacy_binfilters680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_svx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires liblegacy_binfilters680li.so(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.1)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libgo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libavmedia680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libfile680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libdbtools680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libvos3gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3.1)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libgo680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3(UDK_3.1)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3(UDK_3_0_0)
	openoffice.org-langpack-da_DK - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	ImageMagick - 6.2.5.4-1.i386 requires libgs.so.8
	openoffice.org-langpack-el_GR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-it - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-nb_NO - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsd680li.so
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsd680li.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-langpack-ga_IE - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libwnck - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-langpack-gl_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-zh_TW - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-lt_LT - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-ar - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-sk_SK - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libgnomecanvas - 2.12.0-1.i386 requires libcairo.so.2
	openoffice.org-langpack-gu_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-ta_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-pl_PL - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2





From ed at eh3.com  Tue Nov  8 13:36:57 2005
From: ed at eh3.com (Ed Hill)
Date: Tue, 08 Nov 2005 08:36:57 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051108102639.7c0d45dc.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20051108082500.4cc7d549.linux@pilot.org.ua>
	<43703FA7.60906@redhat.com>
	<20051108102639.7c0d45dc.linux@pilot.org.ua>
Message-ID: <1131457017.8901.355.camel@ernie>

On Tue, 2005-11-08 at 10:26 +0200, Denis Ovsienko wrote:
> > Sure. NetworkManager is not specific to Fedora. It is already being used 
> > by several distributions. So instead of switching to net-scripts they 
> > can switch over to NeworkManager when it becomes capable of replacing 
> > everything else.
> I have nothing against NetworkManager and those who want to use or develop it,
> but my vision of how things should happen is different. I don't request anyting
> except ability to use community member's right to participate in Fedora Core
> development.

> I want to add extra functionality to FC, which has been demanded for years.
> Why do you try to stop me? I want to start.

Hi Denis,

I could be wrong, but I don't think anyone is trying to stop you.  There
is, however, a procedure to be followed to get things in.  Currently,
the way to get your packages "into" Fedora is through Extras which has a
well-defined package submittal and maintenance process documented at:

  http://fedoraproject.org/wiki/Extras

So, is there some way that you could package your networking scripts as
an "add on" that would work alongside the existing scripts?  If so, it
would be relatively easy to get them into Fedora Extras where they could
be tested (including comparisons with the existing scripts!), used by
folks so that people become familiar with them, and perhaps eventually
added to Core.

Does that sound reasonable?

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464



From bmillett at gmail.com  Tue Nov  8 14:56:12 2005
From: bmillett at gmail.com (Brian Millett)
Date: Tue, 08 Nov 2005 08:56:12 -0600
Subject: rawhide report: 20051108 changes
In-Reply-To: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>
References: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>
Message-ID: <1131461772.3642.7.camel@localhost.localdomain>

On Tue, 2005-11-08 at 08:25 -0500, Build System wrote:
>  Updated Packages:
> yum-2.4.0-9
> -----------
> * Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-9
> - enable plugins by default
> - add installyonlyn plugin so that we only keep two kernels around by default

So after looking at the code in /usr/lib/yum-plugins/installonlyn.py, 

def config_hook(conduit):
    global num_tokeep
    num_tokeep = conduit.confInt('main', 'tokeep', default=2)

am I correct in that the correct place to change the default (2) is in
the /etc/yum.conf file with a 

tokeep=3

if I want to keep 3 kernels?

Thanks.
-- 
Brian Millett - [ Dr. Kyle (re: Vorlon Ambassador Kosh), "The
Gathering"]
"Even for an alien, this one is pretty alien."




From sundaram at redhat.com  Tue Nov  8 15:04:26 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 08 Nov 2005 20:34:26 +0530
Subject: rawhide report: 20051108 changes
In-Reply-To: <1131461772.3642.7.camel@localhost.localdomain>
References: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>
	<1131461772.3642.7.camel@localhost.localdomain>
Message-ID: <4370BE7A.1000204@redhat.com>

Brian Millett wrote:

>On Tue, 2005-11-08 at 08:25 -0500, Build System wrote:
>  
>
>> Updated Packages:
>>yum-2.4.0-9
>>-----------
>>* Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-9
>>- enable plugins by default
>>- add installyonlyn plugin so that we only keep two kernels around by default
>>    
>>
>
>So after looking at the code in /usr/lib/yum-plugins/installonlyn.py, 
>
>def config_hook(conduit):
>    global num_tokeep
>    num_tokeep = conduit.confInt('main', 'tokeep', default=2)
>
>am I correct in that the correct place to change the default (2) is in
>the /etc/yum.conf file with a 
>
>tokeep=3
>
>if I want to keep 3 kernels?
>
>Thanks.
>  
>
That probably wont be retained through package updates. The plugin 
should offering some specific configuration file to change this value if 
you want to do it a maintainable fashion

regards
Rahul



From linux at pilot.org.ua  Tue Nov  8 15:55:19 2005
From: linux at pilot.org.ua (Denis Ovsienko)
Date: Tue, 8 Nov 2005 17:55:19 +0200
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <1131457017.8901.355.camel@ernie>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20051108082500.4cc7d549.linux@pilot.org.ua>
	<43703FA7.60906@redhat.com>
	<20051108102639.7c0d45dc.linux@pilot.org.ua>
	<1131457017.8901.355.camel@ernie>
Message-ID: <20051108175519.1a9140e8.linux@pilot.org.ua>

> I could be wrong, but I don't think anyone is trying to stop you.  There
> is, however, a procedure to be followed to get things in.  Currently,
> the way to get your packages "into" Fedora is through Extras which has a
> well-defined package submittal and maintenance process documented at:
> 
>   http://fedoraproject.org/wiki/Extras
Thank you for the hint, I will follow the procedure.

> So, is there some way that you could package your networking scripts as
> an "add on" that would work alongside the existing scripts?  If so, it
> would be relatively easy to get them into Fedora Extras where they could
> be tested (including comparisons with the existing scripts!), used by
> folks so that people become familiar with them, and perhaps eventually
> added to Core.
/etc/net can't do it's job without integration into system init, but I hope
we will return to it when I am finifhed with Extras.

-- 
    DO4-UANIC



From pjones at redhat.com  Tue Nov  8 15:40:05 2005
From: pjones at redhat.com (Peter Jones)
Date: Tue, 08 Nov 2005 10:40:05 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051108102639.7c0d45dc.linux@pilot.org.ua>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
	<20051108082500.4cc7d549.linux@pilot.org.ua>
	<43703FA7.60906@redhat.com>
	<20051108102639.7c0d45dc.linux@pilot.org.ua>
Message-ID: <1131464406.2066.2.camel@localhost.localdomain>

On Tue, 2005-11-08 at 10:26 +0200, Denis Ovsienko wrote:
> > Sure. NetworkManager is not specific to Fedora. It is already being used 
> > by several distributions. So instead of switching to net-scripts they 
> > can switch over to NeworkManager when it becomes capable of replacing 
> > everything else.
> I have nothing against NetworkManager and those who want to use or develop it,
> but my vision of how things should happen is different. I don't request anyting
> except ability to use community member's right to participate in Fedora Core
> development.

So package your stuff for Fedora Extras.  That'd be the first step,
whether the rest of us agree that it should (later) go in Core or not.

-- 
  Peter



From katzj at redhat.com  Tue Nov  8 15:55:25 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Tue, 08 Nov 2005 10:55:25 -0500
Subject: rawhide report: 20051108 changes
In-Reply-To: <1131461772.3642.7.camel@localhost.localdomain>
References: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>
	<1131461772.3642.7.camel@localhost.localdomain>
Message-ID: <1131465326.3533.6.camel@bree.local.net>

On Tue, 2005-11-08 at 08:56 -0600, Brian Millett wrote:
> On Tue, 2005-11-08 at 08:25 -0500, Build System wrote:
> >  Updated Packages:
> > yum-2.4.0-9
> > -----------
> > * Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-9
> > - enable plugins by default
> > - add installyonlyn plugin so that we only keep two kernels around by default
> 
> So after looking at the code in /usr/lib/yum-plugins/installonlyn.py, 
> 
> def config_hook(conduit):
>     global num_tokeep
>     num_tokeep = conduit.confInt('main', 'tokeep', default=2)
> 
> am I correct in that the correct place to change the default (2) is in
> the /etc/yum.conf file with a 

You want to set it in the [main] section
of /etc/yum/pluginconf.d/installonlyn.conf, but that's the basic idea

Jeremy



From bmillett at gmail.com  Tue Nov  8 16:13:17 2005
From: bmillett at gmail.com (Brian Millett)
Date: Tue, 08 Nov 2005 10:13:17 -0600
Subject: rawhide report: 20051108 changes
In-Reply-To: <1131465326.3533.6.camel@bree.local.net>
References: <200511081325.jA8DPEQI016972@porkchop.devel.redhat.com>
	<1131461772.3642.7.camel@localhost.localdomain>
	<1131465326.3533.6.camel@bree.local.net>
Message-ID: <1131466397.3611.0.camel@localhost.localdomain>

On Tue, 2005-11-08 at 10:55 -0500, Jeremy Katz wrote:
> On Tue, 2005-11-08 at 08:56 -0600, Brian Millett wrote:
> > On Tue, 2005-11-08 at 08:25 -0500, Build System wrote:
> > >  Updated Packages:
> > > yum-2.4.0-9
> > > -----------
> > > * Mon Nov 07 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-9
> > > - enable plugins by default
> > > - add installyonlyn plugin so that we only keep two kernels around by default
> > 
> > So after looking at the code in /usr/lib/yum-plugins/installonlyn.py, 
> > 
> > def config_hook(conduit):
> >     global num_tokeep
> >     num_tokeep = conduit.confInt('main', 'tokeep', default=2)
> > 
> > am I correct in that the correct place to change the default (2) is in
> > the /etc/yum.conf file with a 
> 
> You want to set it in the [main] section
> of /etc/yum/pluginconf.d/installonlyn.conf, but that's the basic idea

Right!  That make much more since.
Thanks.
-- 
Brian Millett - [ Knight Two, "And the Sky Full of Stars"]
"Maybe you're asleep. Maybe you're insane. Maybe you're dead. Maybe
you're in Hell! Not that it matters much, Commander Sinclair, because
wherever you are, wherever you go, you're mine."




From notting at redhat.com  Tue Nov  8 20:06:15 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 8 Nov 2005 15:06:15 -0500
Subject: Self-Introduction: Denis Ovsienko and /etc/net project
In-Reply-To: <20051107194854.GC22799@devserv.devel.redhat.com>
References: <20051103203538.10167c4a.linux@pilot.org.ua>
	<6b9c17630511031216g537b079ch3057d1babf4ddc4b@mail.gmail.com>
	<20051107180238.680525a3.linux@pilot.org.ua>
	<20051107194854.GC22799@devserv.devel.redhat.com>
Message-ID: <20051108200615.GB32646@devserv.devel.redhat.com>

Bill Nottingham (notting at redhat.com) said: 
> > - QoS
> > - inter-interface dependencies
> > - configuration profiles
> > - multi-host configuration
> > - routing rules
> > - ifrename support
> > - ifplugd support
> > [...]
> > - EXTENSIBLE DESIGN
> > 
> > I (and other people) find solutions of everyday tasks with /etc/net. I don't
> > want to make others think the way I do, but I need a way to give people choice
> > freedom within FC. This freedom is demanded.
> 
> Generally... network-scripts will eventually go away - things will 
> be moved to a framework involving NetworkManager. Hence, I don't
> believe pulling in an entirely different framework in the interim
> is really worth it.

Moreover, some of the things you mention above are either:

a) supported in the scripts already (ifrename)
b) supported via NetworkManager (ifplugd, configuration profiles)
c) not really as important in a long term view (ifrename, again :) )

Bill



From hballal at gmail.com  Tue Nov  8 21:20:21 2005
From: hballal at gmail.com (Hrishikesh Ballal)
Date: Tue, 08 Nov 2005 16:20:21 -0500
Subject: Help Wanted: Icon / Graphic Designer Needed
Message-ID: <1131484821.2999.96.camel@localhost.localdomain>

Hello All, 
We have been working at Yumex we need a little bit of help. The newest
version of Yumex has a group browsing feature and we don't really have a
icon for that. I am not a artist or familiar with making icons. I have a
idea for a icon:
http://www.hrishikeshballal.net/other/fedora/group_inst.png 

Can someone direct me to a graphic in bluecurve or help me out in
refining this concept and making a icon. It has to be a 48x48 graphic
that user can click on the yumex window.
Also attached is a yumex window:
http://www.hrishikeshballal.net/other/fedora/yumex_first.png 

This will be placed on the left column above where it says "Groups".
Thank you for your help. 

Hrishi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051108/7f224805/attachment.sig>

From rodd at clarkson.id.au  Wed Nov  9 02:30:05 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 09 Nov 2005 13:30:05 +1100
Subject: rawhide report: 20051104 changes
In-Reply-To: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
Message-ID: <1131503405.2926.34.camel@localhost.localdomain>

On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:

> ImageMagick-6.2.5.4-1
> ---------------------
> * Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 6.2.5.4-1
> - Switch requires to modular X
> - Update to 6.2.5
> 
> * Tue Sep 20 2005 Matthias Clasen <mclasen at redhat.com> 6.2.4.6-1
> - Update to 6.2.4-6
> - Drop upstreamed patches
> - Disable DPS (#158984)
> - Add missing requires (#165931)

After updating I'm seeing this in the logs (and the site no longer
works)

[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so: undefined symbol: __stack_chk_fail_local at /usr/lib/perl5/5.8.7/i386-linux-thread-multi/DynaLoader.pm line 230.
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1]  at ../PartsImage.pm line 25
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Compilation failed in require at ../PartsImage.pm line 25.
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at ../PartsImage.pm line 25.
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Compilation failed in require at index.cgi line 41.
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at index.cgi line 41.
[Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Premature end of script headers: index.cgi

Should I bugzilla this?


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From rodd at clarkson.id.au  Wed Nov  9 04:24:00 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 09 Nov 2005 15:24:00 +1100
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131503405.2926.34.camel@localhost.localdomain>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131503405.2926.34.camel@localhost.localdomain>
Message-ID: <1131510240.2926.37.camel@localhost.localdomain>

On Wed, 2005-11-09 at 13:30 +1100, Rodd Clarkson wrote:
> On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> 
> > ImageMagick-6.2.5.4-1
> > ---------------------
> > * Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 6.2.5.4-1
> > - Switch requires to modular X
> > - Update to 6.2.5
> > 
> > * Tue Sep 20 2005 Matthias Clasen <mclasen at redhat.com> 6.2.4.6-1
> > - Update to 6.2.4-6
> > - Drop upstreamed patches
> > - Disable DPS (#158984)
> > - Add missing requires (#165931)
> 
> After updating I'm seeing this in the logs (and the site no longer
> works)
> 
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so: undefined symbol: __stack_chk_fail_local at /usr/lib/perl5/5.8.7/i386-linux-thread-multi/DynaLoader.pm line 230.
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1]  at ../PartsImage.pm line 25
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Compilation failed in require at ../PartsImage.pm line 25.
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at ../PartsImage.pm line 25.
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Compilation failed in require at index.cgi line 41.
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at index.cgi line 41.
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Premature end of script headers: index.cgi
> 
> Should I bugzilla this?

I've bugzilla'd it.

	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172754

Turns out you can trigger this by just running:

	perl -e "use Image::Magick;"

from the terminal.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From arjanv at redhat.com  Wed Nov  9 07:01:49 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Wed, 09 Nov 2005 08:01:49 +0100
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131503405.2926.34.camel@localhost.localdomain>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131503405.2926.34.camel@localhost.localdomain>
Message-ID: <1131519710.2875.1.camel@laptopd505.fenrus.org>

On Wed, 2005-11-09 at 13:30 +1100, Rodd Clarkson wrote:
> On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> 
> > ImageMagick-6.2.5.4-1
> > ---------------------
> > * Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 6.2.5.4-1
> > - Switch requires to modular X
> > - Update to 6.2.5
> > 
> > * Tue Sep 20 2005 Matthias Clasen <mclasen at redhat.com> 6.2.4.6-1
> > - Update to 6.2.4-6
> > - Drop upstreamed patches
> > - Disable DPS (#158984)
> > - Add missing requires (#165931)
> 
> After updating I'm seeing this in the logs (and the site no longer
> works)
> 
> [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so: 

> undefined symbol: __stack_chk_fail_local at /usr/lib/perl5/5.8.7/i386-linux-thread-multi/DynaLoader.pm line 230.

are you using a rawhide glibc (and a new enough one at that)?




From gilboada at netvision.net.il  Wed Nov  9 10:53:30 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Wed, 09 Nov 2005 12:53:30 +0200
Subject: Yes! lm_sensors/FC4 finally works on my Tyan s2895!
Message-ID: <1131533610.8244.120.camel@gilboa-work-dev>

Kudos to the lm_sensors team and the Fedora team for fixing the problem
(and pushing the fix down-stream).

Thank you!
Gilboa



From pknirsch at redhat.com  Wed Nov  9 11:11:29 2005
From: pknirsch at redhat.com (Phil Knirsch)
Date: Wed, 09 Nov 2005 12:11:29 +0100
Subject: Yes! lm_sensors/FC4 finally works on my Tyan s2895!
In-Reply-To: <1131533610.8244.120.camel@gilboa-work-dev>
References: <1131533610.8244.120.camel@gilboa-work-dev>
Message-ID: <4371D961.3090704@redhat.com>

Gilboa Davara wrote:
> Kudos to the lm_sensors team and the Fedora team for fixing the problem
> (and pushing the fix down-stream).
> 
> Thank you!
> Gilboa
> 

:) Well, as part of the security fix i though it would be nice to 
include that fix as well.

Have fun,

Read ya, Phil

-- 
Philipp Knirsch      | Tel.:  +49-711-96437-470
Development          | Fax.:  +49-711-96437-111
Red Hat GmbH         | Email: Phil Knirsch <phil at redhat.de>
Hauptstaetterstr. 58 | Web:   http://www.redhat.de/
D-70178 Stuttgart
Motd:  You're only jealous cos the little penguins are talking to me.



From rodd at clarkson.id.au  Wed Nov  9 11:32:33 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 09 Nov 2005 22:32:33 +1100
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131519710.2875.1.camel@laptopd505.fenrus.org>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131503405.2926.34.camel@localhost.localdomain>
	<1131519710.2875.1.camel@laptopd505.fenrus.org>
Message-ID: <1131535953.2878.4.camel@localhost.localdomain>

On Wed, 2005-11-09 at 08:01 +0100, Arjan van de Ven wrote:
> On Wed, 2005-11-09 at 13:30 +1100, Rodd Clarkson wrote:
> > On Fri, 2005-11-04 at 12:42 -0500, Build System wrote:
> > 
> > > ImageMagick-6.2.5.4-1
> > > ---------------------
> > > * Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 6.2.5.4-1
> > > - Switch requires to modular X
> > > - Update to 6.2.5
> > > 
> > > * Tue Sep 20 2005 Matthias Clasen <mclasen at redhat.com> 6.2.4.6-1
> > > - Update to 6.2.4-6
> > > - Drop upstreamed patches
> > > - Disable DPS (#158984)
> > > - Add missing requires (#165931)
> > 
> > After updating I'm seeing this in the logs (and the site no longer
> > works)
> > 
> > [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so: 
> 
> > undefined symbol: __stack_chk_fail_local at /usr/lib/perl5/5.8.7/i386-linux-thread-multi/DynaLoader.pm line 230.
> 
> are you using a rawhide glibc (and a new enough one at that)?

I'm current with all of rawhide (I ran yum update for this update and
installed everything offered (and it worked ;-]))


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From jakub at redhat.com  Wed Nov  9 12:41:44 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Wed, 9 Nov 2005 07:41:44 -0500
Subject: rawhide report: 20051104 changes
In-Reply-To: <1131519710.2875.1.camel@laptopd505.fenrus.org>
References: <200511041742.jA4HgDNx017880@porkchop.devel.redhat.com>
	<1131503405.2926.34.camel@localhost.localdomain>
	<1131519710.2875.1.camel@laptopd505.fenrus.org>
Message-ID: <20051109124144.GP16034@devserv.devel.redhat.com>

On Wed, Nov 09, 2005 at 08:01:49AM +0100, Arjan van de Ven wrote:
> > [Wed Nov 09 13:28:30 2005] [error] [client 127.0.0.1] Can't load '/usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi/auto/Image/Magick/Magick.so: 
> 
> > undefined symbol: __stack_chk_fail_local at /usr/lib/perl5/5.8.7/i386-linux-thread-multi/DynaLoader.pm line 230.
> 
> are you using a rawhide glibc (and a new enough one at that)?

Actually, undefined __stack_chk_fail_local (as opposed to undefined
__stack_chk_fail) means busted shared library.
My guess is that it has been linked with ld -shared as opposed
to gcc -shared or some similarly common error.

	Jakub



From howe.steven at gmail.com  Wed Nov  9 13:06:55 2005
From: howe.steven at gmail.com (Steven Howe)
Date: Wed, 09 Nov 2005 05:06:55 -0800
Subject: XEN Rawhide problems
Message-ID: <1131541616.4426.3.camel@pillage.home>

         kernel-xen-guest-2.6.12-1.9_FC5.root
         xen-3.0-0.20051021.fc5
         kernel-xen-hypervisor-2.6.12-1.9_FC5.root
    Two issues.
    One is networking. I've yet to get networking working between the
guest
    and the host. Some examples of a working networking addresses (via
    ifconfig and dmesg host/guest) would be nice. 
    At least I could feel certain I wasn't missing anything. In fact,
the
    whole XEN network documentation seems pretty week. It's just suppose
to
    "work" (very Microsoftish thinking). I will note the "getting
started
    wiki" at Redhat was useful, but needs to be updated. Redhat RPM's
    ability to install in a specific root is nice. I used that feature
to
    get the kernel-xen-guest installed in my LVM guest root. 
    Second, these version of xen have locked up my system  while
accessing
    the net from dom0 (dom1, was still not able to see the net).
    So what trace logs should I submit?
        Steven Howe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051109/2ae67ed4/attachment.htm>

From veillard at redhat.com  Wed Nov  9 14:23:12 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Wed, 9 Nov 2005 09:23:12 -0500
Subject: XEN Rawhide problems
In-Reply-To: <1131541616.4426.3.camel@pillage.home>
References: <1131541616.4426.3.camel@pillage.home>
Message-ID: <20051109142312.GF12160@redhat.com>

On Wed, Nov 09, 2005 at 05:06:55AM -0800, Steven Howe wrote:
>     Second, these version of xen have locked up my system  while
> accessing
>     the net from dom0 (dom1, was still not able to see the net).

  It's likely to be the DMA problem we reported upstream and which is fixed
there, hopefully it will be fixed in the next version of kernel-xen,

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/



From katzj at redhat.com  Wed Nov  9 15:02:43 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 09 Nov 2005 10:02:43 -0500
Subject: XEN Rawhide problems
In-Reply-To: <1131541616.4426.3.camel@pillage.home>
References: <1131541616.4426.3.camel@pillage.home>
Message-ID: <1131548563.3533.56.camel@bree.local.net>

On Wed, 2005-11-09 at 05:06 -0800, Steven Howe wrote:
>     Two issues.
>     One is networking. I've yet to get networking working between the
> guest
>     and the host. Some examples of a working networking addresses (via
>     ifconfig and dmesg host/guest) would be nice. 

The network config in the current package isn't quite working correctly
-- there's been a lot of churn upstream on this, so I'm hoping updating
will fix it.  If not, then I'll be looking closer at it.

> In fact, the
>     whole XEN network documentation seems pretty week. It's just
> suppose to
>     "work" (very Microsoftish thinking). I will note the "getting
> started
>     wiki" at Redhat was useful, but needs to be updated. 

It will be, but a lot of the stuff is being actively worked on and it's
going to be better to get to closer to a final state instead of spending
time updating for every iterative step

Jeremy



From maxer1 at xmission.com  Wed Nov  9 18:06:17 2005
From: maxer1 at xmission.com (RaXeT)
Date: Wed, 09 Nov 2005 11:06:17 -0700
Subject: Missing openssl.so.5 from 0.9.7f-11
Message-ID: <43723A99.50600@xmission.com>

I'm missing libssl.so.5 and I can't run rpm or yum anymore.

Can someone kindly send me openssl 0.9.7f-11 in tar format so I can get 
this fixed?

Thanks,

RaXeT
Here below is the output after trying to run yum this am.
------------------------------------------------------------------------------------
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   libssl.so.5: cannot open shared object file: No such file or directory

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.4.1 (#1, Oct  6 2005, 15:06:23)
[GCC 4.0.2 20050928 (Red Hat 4.0.2-1)]

If you cannot solve this problem yourself, please send this
message to <yum at lists.linux.duke.edu>.



From tmraz at redhat.com  Wed Nov  9 19:30:17 2005
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 09 Nov 2005 20:30:17 +0100
Subject: Missing openssl.so.5 from 0.9.7f-11
In-Reply-To: <43723A99.50600@xmission.com>
References: <43723A99.50600@xmission.com>
Message-ID: <1131564617.3035.11.camel@perun.redhat.usu>

On Wed, 2005-11-09 at 11:06 -0700, RaXeT wrote:
> I'm missing libssl.so.5 and I can't run rpm or yum anymore.
> 
> Can someone kindly send me openssl 0.9.7f-11 in tar format so I can get 
> this fixed?

You could probably temporarily 
ln -s libssl.so.6 libssl.so.5 && ln -s libcrypto.so.6 libcrypto.so.5

Then it should be possible to upgrade rpm and python packages.

-- 
Tomas Mraz <tmraz at redhat.com>



From mharris at redhat.com  Wed Nov  9 22:34:30 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 09 Nov 2005 17:34:30 -0500
Subject: How to simplify the process of adding multilingual %descriptions
 to	rpm spec?
In-Reply-To: <76e72f800511071722h7841b6e2t@mail.gmail.com>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>
Message-ID: <43727976.7020400@redhat.com>

Yuan Yijun wrote:
> Greetings,
> 
> I believe that non-English speakers will be more happy to see
> localized package %descriptions, when they are using a GUI package
> management program. Most of users play Linux for fun, and they are
> willing to search software in the huge packages list, looking for
> interesting packages to install. But this fun only belongs to English
> speakers. To Chinese, there is no way for an software package to
> introduce itself.
> 
> Then how can these %descriptions be localized? If someone translate
> them and commit patches to rpm spec files, that seems a bit funny and
> boring. (Sorry for my bad vocabulary, though the single filed rpm spec
> does have its cons and pros.) How to simplify this and reduce the
> amount of work?
> 
> (There are too many excellent programs in both Core and Extras, while
> I'm trying to introduce them to other Chinese users, I believe this
> problem is essential.)

This is a rather IMHO complex problem to solve in an a way that
ends up "good" for the package maintainer, the user, and from
a software perspective too.

One solution, is to put translated descriptions into each
spec file.  That centralizes everything, but when the English
description changes, the translations are instantly out of date.
Plus, since the spec files are centrally controlled, translators
do not have CVS access to them.  There are other problems with
this method as well, and I think everyone more or less agrees
that this soluton is unacceptable overall.

Another solution, which was used in Red Hat Linux days, was a
separate package named "specspo", which contained the translations
for every package's descriptions, etc.  This was maintained in
a separate CVS repository which was publically accessible, and
so translators around the world could update the specspo
translations as necessary, without the main rpm package having
to be touched.  The disadvantages of this approach, were that
it was the responsibility of every rpm packager to update the
english entries of their packages "%description" fields and
whatnot, every single time they changed, or whenever a new
one was added or removed, or a new rpm added.  This meant double
the work for every engineer any time a package description needed
to be changed/etc.  The process of updating specspo was also
very cryptic and non-friendly, and involved hand editing a cryptic
file that was incredibly lengthy.  Very unweildy and time consuming
in general.  Also, this solution was bad because it relied on
human intervention to actually remember to do these specspo
updates, and not forget or make mistakes.  If a human mistake
was made, then the English description and translated description
would be out of sync.

In short - specspo sucks.

IMHO, the best way for this problem to be solved is for there to
be a new solution/process to be created to solve this problem,
and for there to be real software tools that automate every step
of the process on both the engineering side, and the translator
side.  Ultimately, a package maintainer really should only ever
have to edit the spec file, and from there, automated software
tools should do the rest.

I don't have a specific proposal for how we might implement this
solution, but I think the idea is worthy at least, so I thought
I'd offer it as a suggestion.

Whatever is chosen as a solution, I believe it only stands a
chance of succeeding, if it is given sufficient resources and
manpower to see it completed with an eye towards making this a
total breeze in the long term, with computers doing most of
the work, and humans doing as close to nothing as is possible.

It shouldn't be that hard for a tool to pull the spec file out
of CVS on checkin, diff it for changes to descriptions, etc.
and pull them into something visible by translators.

Just a thought...



From mharris at redhat.com  Thu Nov 10 01:30:04 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 09 Nov 2005 20:30:04 -0500
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist
 very soon.
Message-ID: <4372A29C.3080809@redhat.com>

This is another friendly reminder to all developers and package
maintainers that "XFree86-devel" and "xorg-x11-devel" will no
longer exist in Fedora Core 5.

The current rawhide monolithic xorg-x11 build has had the virtual
"Provides: XFree86-devel" removed to both find out what all packages
were still using it, and also as a heads up to developers and
package maintainers to update their packages, as this is no longer
a valid BuildRequires.

All packages which "BuildRequires: XFree86-devel" or
"BuildRequires: xorg-x11-devel" must be updated to remove this
dependency and replace it with individual BuildRequires for
each library that is needed.

For example:

BuildRequires: libX11-devel
BuildRequires: libXinerama-devel

etc..

When updating packages for rawhide, be sure to not use xorg-x11-devel
either, because it only exists temporarily for a week or less.  Once
modular X goes into rawhide, packages depending on either of these
dependencies will need to be updated in order to build properly, so
it is best to make the change now if possible.

I'd like to thank everyone who has helped update packages so far,
as this helps to minimize the amount of work needed later.

Thanks in advance!


P.S.  This email has been sent to fedora-devel-list, however please
       feel free to forward this to other developmental mailing lists
       which I might not be subscribed to if you think the information
       is useful to a wider audience who might not read
       fedora-devel-list.



From mharris at redhat.com  Thu Nov 10 01:47:22 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 09 Nov 2005 20:47:22 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <200511060849.00109.jbarnes@virtuousgeek.org>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>	<436E2F19.6030902@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>
Message-ID: <4372A6AA.70906@redhat.com>

Jesse Barnes wrote:
> On Sunday, November 06, 2005 8:28 am, Mike A. Harris wrote:
> 
>>I believe Owen, or whoever set up our default fonts.conf
>>configuration, intentionally selected only the above specific
>>/usr/X11R6 font directories, in order to pick up the scaleable Type1
>>and OTF fonts that come with X, intentionally excluding all of the
>>ugly bitmap fonts and other weirdo fonts from being seen by
>>fontconfig.
> 
> 
> But don't you *want* to see all your fonts?  I.e. if you chose to 
> install xorg-ugly-fonts, you don't want them mysteriously missing from 
> your font listings, do you?

There are 2 individual font subsystems in X:

1) server side "core fonts" via xfs or the X server
2) client side fonts via fontconfig/Xft

These two font systems are independent of each other, and individually
configured.

The "core fonts" system is for legacy X applications, in particular
applications that use the Xt, Xaw, and Motif toolkits, as well as other
legacy toolkits.

The majority of the fonts supplied by the X Window system are hideous
bitmap fonts, of which many of these "legacy" applications rely on being
installed and available.  Many legacy X applications hard code specific
fonts as well, and wont even start if the font is not available.  It is
for this reason, which many of the fonts are still supplied - more or
less for legacy compatibility.

However, while many of these "hideous" fonts are required for legacy
compatibility purposes with the core fonts subsystem, they are not
required by the modern fontconfig/Xft subsystem which modern
applications and GUI toolkits use.

It is intentional, that the "ugly" X fonts supplied for legacy
compatibility are installed and only configured to be used in the
"core" fonts subsystem.  They are intentionally excluded from being
visible from the fontconfig subsystem.

Users are of course free to edit /etc/fonts/local.conf and configure
fontconfig to use all of the ugly bitmap fonts supplied by X, however
I can assure everyone that the results are greatly undesireable.

You do have that option however, but it definitely wont be the
default in Fedora Core.

> I think as long as the ugly fonts are in separate packages, putting them 
> all in /usr/share/fonts will be ok based on the principle of least 
> surprise (though you bring up a good point that this is a change in 
> behavior wrt current FC).

Except that there are 2 font systems in the system used by X
applications, and there are fonts we only want visible to one
of those 2 systems.  fontconfig sees all fonts under
/usr/share/fonts unless you reconfigure fontconfig to blacklist
unwanted fonts.

I believe it is safe to say that the majority of fonts supplied by
X, can be considered to be fonts intended for use by X core fonts
only, rather than for general purpose use that /usr/share/fonts
is intended for.  In other words, they can be considered application
specific data IMHO.

The new xorg-x11-fonts package installs all of the fonts into
/usr/share/X11/fonts currently, however this location is not
finalized yet.

Also, I want to avoid xfs config file skew, as that causes a lot of
mayhem on upgrades.  We need to rip out old paths that are no longer
used.

I'll be providing updates on the Xorg modularization status page
soon:  http://mharris.ca/xorg-modular/xorg-modularization.html




From jbarnes at virtuousgeek.org  Thu Nov 10 04:35:26 2005
From: jbarnes at virtuousgeek.org (Jesse Barnes)
Date: Wed, 9 Nov 2005 20:35:26 -0800
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <4372A6AA.70906@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>
	<4372A6AA.70906@redhat.com>
Message-ID: <200511092035.26758.jbarnes@virtuousgeek.org>

On Wednesday, November 09, 2005 5:47 pm, Mike A. Harris wrote:
> I believe it is safe to say that the majority of fonts supplied by
> X, can be considered to be fonts intended for use by X core fonts
> only, rather than for general purpose use that /usr/share/fonts
> is intended for.  In other words, they can be considered application
> specific data IMHO.

I hadn't thought about it in the context of the two different font 
systems.  Put that way, what you say above makes a lot of sense and I'm 
inclined to agree.

Are there any legacy applications required for a proper X installation?  
If not, then on most systems the xorg-x11-fonts package may not be 
needed (as long as the X server itself supplies the infamous 'fixed' 
font I guess).

> The new xorg-x11-fonts package installs all of the fonts into
> /usr/share/X11/fonts currently, however this location is not
> finalized yet.
>
> Also, I want to avoid xfs config file skew, as that causes a lot of
> mayhem on upgrades.  We need to rip out old paths that are no longer
> used.
>
> I'll be providing updates on the Xorg modularization status page
> soon:  http://mharris.ca/xorg-modular/xorg-modularization.html

Cool, thanks.

Jesse



From petersen at redhat.com  Thu Nov 10 08:58:05 2005
From: petersen at redhat.com (Jens Petersen)
Date: Thu, 10 Nov 2005 17:58:05 +0900
Subject: [announce] Fedora community SCIM input survey
Message-ID: <43730B9D.7090200@redhat.com>

The Fedora I18N Team invites you kindly to participate in a survey
to provide feedback on the SCIM (Simple Common Input Method [1])
platform for Asian language input.  Packages are available in Fedora Core
Development and Fedora Extras, and also for RHEL 4.

The survey is available now at

	https://www.keysurvey.com/survey/80474/2da7/ [2]

where more details can be found including package installation instructions.
The survey has been translated into the following languages: Bengali, Chinese,
Gujarati, Hindi, Japanese, Korean, and Punjabi.

The goal of the survey is to find out what users see as the main strengths
and weaknesses of SCIM to help provide focus on the most important
improvements needed from the point of view of users.

The survey will run until the end of Friday 25th November, UTC.
We hope to receive lots of responses from a wide part of the community.
A summary of the results will be made available publicly later.

Thank you for your time.  And special thanks to the SCIM developers
and community for creating SCIM.

Jens Petersen on behalf of the Fedora I18N and Translation Teams


[1] http://www.scim-im.org/

[2] http://tinyurl.com/9n4qb



From tjarls at iee.lu  Thu Nov 10 09:22:49 2005
From: tjarls at iee.lu (Charles Lopes)
Date: Thu, 10 Nov 2005 10:22:49 +0100
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist
 very soon.
In-Reply-To: <4372A29C.3080809@redhat.com>
References: <4372A29C.3080809@redhat.com>
Message-ID: <43731169.2000003@iee.lu>

Would it be a bad idea to have an update for FC3 and FC4 of their 
current xorg-x11-devel with additional provides (libX11-devel,
libXinerama-devel)? This would make it easier to recompile FC5 SRPMs on 
these older systems.



From nicolas.mailhot at laposte.net  Thu Nov 10 09:51:45 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 10 Nov 2005 10:51:45 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <4372A6AA.70906@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>	<436E2F19.6030902@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>
	<4372A6AA.70906@redhat.com>
Message-ID: <1131616306.10039.43.camel@rousalka.dyndns.org>

Le mercredi 09 novembre 2005 ? 20:47 -0500, Mike A. Harris a ?crit :

> The "core fonts" system is for legacy X applications, in particular
> applications that use the Xt, Xaw, and Motif toolkits, as well as other
> legacy toolkits.

And commercial JVMs.
Making core font support optional would probably be enough for Sun to
get a clue and port Java to fontconfig.

Oh well the future is gcj anyway. As soon as it's stable enough for use,
_many_ people will discover the shortcuts Sun took in its X11 reference
implementation and wonder why they had to live with them so long.

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/20051110/8605e15c/attachment.sig>

From igorm5 at vip.hr  Thu Nov 10 10:59:30 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 10 Nov 2005 11:59:30 +0100
Subject: missing dependency on FC4 Rawhide
Message-ID: <43732812.6010700@vip.hr>

# yum update
...
--> Running transaction check
--> Processing Dependency: libcrypto.so.5 for package: libwvstreams
--> Processing Dependency: libcrypto.so.5 for package: openssh-clients
--> Processing Dependency: libssl.so.5 for package: xchat
--> Processing Dependency: libssl.so.5 for package: ghostscript
--> Processing Dependency: libssl.so.5 for package: openldap
--> Processing Dependency: libssl.so.5 for package: libgnomecups
--> Processing Dependency: libssl.so.5 for package: kdelibs
--> Processing Dependency: libcrypto.so.5 for package: ipsec-tools
--> Processing Dependency: libssl.so.5 for package: libwvstreams
--> Processing Dependency: libssl.so.5 for package: slrn
--> Processing Dependency: libcrypto.so.5 for package: sendmail
--> Processing Dependency: libssl.so.5 for package: libgnomeprint22
--> Processing Dependency: libcrypto.so.5 for package: mutt
--> Processing Dependency: libcrypto.so.5 for package: xchat
--> Processing Dependency: libcrypto.so.5 for package: ghostscript
--> Processing Dependency: libcrypto.so.5 for package: vorbis-tools
--> Processing Dependency: libcrypto.so.5 for package: fetchmail
--> Processing Dependency: libssl.so.5 for package: iiimf-libs
--> Processing Dependency: libssl.so.5 for package: sendmail
--> Processing Dependency: libcrypto.so.5 for package: libgnomeprint22
--> Processing Dependency: libssl.so.5 for package: pyOpenSSL
--> Processing Dependency: libcrypto.so.5 for package: ntp
--> Processing Dependency: libssl.so.5 for package: elinks
--> Processing Dependency: libssl.so.5 for package: stunnel
--> Processing Dependency: libssl.so.5 for package: fetchmail
--> Processing Dependency: libssl.so.5 for package: perl-Crypt-SSLeay
--> Processing Dependency: libcrypto.so.5 for package: stunnel
--> Processing Dependency: libcrypto.so.5 for package: python
--> Processing Dependency: libcrypto.so.5 for package: openssh
--> Processing Dependency: libcrypto.so.5 for package: openldap
--> Processing Dependency: libcrypto.so.5 for package: pam_ccreds
--> Processing Dependency: libcrypto.so.5 for package: wget
--> Processing Dependency: libcrypto.so.5 for package: mysql
--> Processing Dependency: libssl.so.5 for package: postgresql-libs
--> Processing Dependency: libcrypto.so.5 for package: iiimf-libs
--> Processing Dependency: libssl.so.5 for package: mutt
--> Processing Dependency: libcrypto.so.5 for package: nmap
--> Processing Dependency: libcrypto.so.5 for package: kdelibs
--> Processing Dependency: libssl.so.5 for package: wget
--> Processing Dependency: libcrypto.so.5 for package: openssh-server
--> Processing Dependency: libcrypto.so.5 for package: pyOpenSSL
--> Processing Dependency: libssl.so.5 for package: mysql
--> Processing Dependency: libcrypto.so.5 for package: postgresql-libs
--> Processing Dependency: libcrypto.so.5 for package: tcpdump
--> Processing Dependency: libssl.so.5 for package: nmap
--> Processing Dependency: libcrypto.so.5 for package: perl-Crypt-SSLeay
--> Processing Dependency: libcrypto.so.5 for package: gnome-vfs2
--> Processing Dependency: libssl.so.5 for package: python
--> Processing Dependency: libcrypto.so.5 for package: elinks
--> Processing Dependency: libcrypto.so.5 for package: slrn
--> Processing Dependency: libssl.so.5 for package: gnome-vfs2
--> Processing Dependency: libcrypto.so.5 for package: libgnomecups
--> Processing Dependency: libssl.so.5 for package: vorbis-tools
--> Finished Dependency Resolution
Error: Missing Dependency: libcrypto.so.5 is needed by package
libwvstreams
Error: Missing Dependency: libcrypto.so.5 is needed by package
openssh-clients
Error: Missing Dependency: libssl.so.5 is needed by package xchat
Error: Missing Dependency: libssl.so.5 is needed by package ghostscript
Error: Missing Dependency: libssl.so.5 is needed by package openldap
Error: Missing Dependency: libssl.so.5 is needed by package libgnomecups
Error: Missing Dependency: libssl.so.5 is needed by package kdelibs
Error: Missing Dependency: libcrypto.so.5 is needed by package
ipsec-tools
Error: Missing Dependency: libssl.so.5 is needed by package libwvstreams
Error: Missing Dependency: libssl.so.5 is needed by package slrn
Error: Missing Dependency: libcrypto.so.5 is needed by package sendmail
Error: Missing Dependency: libssl.so.5 is needed by package
libgnomeprint22
Error: Missing Dependency: libcrypto.so.5 is needed by package mutt
Error: Missing Dependency: libcrypto.so.5 is needed by package xchat
Error: Missing Dependency: libcrypto.so.5 is needed by package
ghostscript
Error: Missing Dependency: libcrypto.so.5 is needed by package
vorbis-tools
Error: Missing Dependency: libcrypto.so.5 is needed by package fetchmail
Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
Error: Missing Dependency: libssl.so.5 is needed by package sendmail
Error: Missing Dependency: libcrypto.so.5 is needed by package
libgnomeprint22
Error: Missing Dependency: libssl.so.5 is needed by package pyOpenSSL
Error: Missing Dependency: libcrypto.so.5 is needed by package ntp
Error: Missing Dependency: libssl.so.5 is needed by package elinks
Error: Missing Dependency: libssl.so.5 is needed by package stunnel
Error: Missing Dependency: libssl.so.5 is needed by package fetchmail
Error: Missing Dependency: libssl.so.5 is needed by package
perl-Crypt-SSLeay
Error: Missing Dependency: libcrypto.so.5 is needed by package stunnel
Error: Missing Dependency: libcrypto.so.5 is needed by package python
Error: Missing Dependency: libcrypto.so.5 is needed by package openssh
Error: Missing Dependency: libcrypto.so.5 is needed by package openldap
Error: Missing Dependency: libcrypto.so.5 is needed by package
pam_ccreds
Error: Missing Dependency: libcrypto.so.5 is needed by package wget
Error: Missing Dependency: libcrypto.so.5 is needed by package mysql
Error: Missing Dependency: libssl.so.5 is needed by package
postgresql-libs
Error: Missing Dependency: libcrypto.so.5 is needed by package
iiimf-libs
Error: Missing Dependency: libssl.so.5 is needed by package mutt
Error: Missing Dependency: libcrypto.so.5 is needed by package nmap
Error: Missing Dependency: libcrypto.so.5 is needed by package kdelibs
Error: Missing Dependency: libssl.so.5 is needed by package wget
Error: Missing Dependency: libcrypto.so.5 is needed by package
openssh-server
Error: Missing Dependency: libcrypto.so.5 is needed by package pyOpenSSL
Error: Missing Dependency: libssl.so.5 is needed by package mysql
Error: Missing Dependency: libcrypto.so.5 is needed by package
postgresql-libs
Error: Missing Dependency: libcrypto.so.5 is needed by package tcpdump
Error: Missing Dependency: libssl.so.5 is needed by package nmap
Error: Missing Dependency: libcrypto.so.5 is needed by package
perl-Crypt-SSLeayError: Missing Dependency: libcrypto.so.5 is needed by
package gnome-vfs2
Error: Missing Dependency: libssl.so.5 is needed by package python
Error: Missing Dependency: libcrypto.so.5 is needed by package elinks
Error: Missing Dependency: libcrypto.so.5 is needed by package slrn
Error: Missing Dependency: libssl.so.5 is needed by package gnome-vfs2
Error: Missing Dependency: libcrypto.so.5 is needed by package
libgnomecups
Error: Missing Dependency: libssl.so.5 is needed by package vorbis-tools

-- 
Igor Jagec



From danfr at matrix.co.il  Thu Nov 10 11:57:16 2005
From: danfr at matrix.co.il (Dan Fruehauf)
Date: Thu, 10 Nov 2005 13:57:16 +0200
Subject: missing dependency on FC4 Rawhide
In-Reply-To: <43732812.6010700@vip.hr>
References: <43732812.6010700@vip.hr>
Message-ID: <1131623836.3728.4.camel@isz>

Yes,
There was a thread about it before.

Just create the appropriate links and continue - should be fixed next
time...

Dan.

On Thu, 2005-11-10 at 11:59 +0100, Igor Jagec wrote:
> # yum update
> ...
> --> Running transaction check
> --> Processing Dependency: libcrypto.so.5 for package: libwvstreams
> --> Processing Dependency: libcrypto.so.5 for package: openssh-clients
> --> Processing Dependency: libssl.so.5 for package: xchat
> --> Processing Dependency: libssl.so.5 for package: ghostscript
> --> Processing Dependency: libssl.so.5 for package: openldap
> --> Processing Dependency: libssl.so.5 for package: libgnomecups
> --> Processing Dependency: libssl.so.5 for package: kdelibs
> --> Processing Dependency: libcrypto.so.5 for package: ipsec-tools
> --> Processing Dependency: libssl.so.5 for package: libwvstreams
> --> Processing Dependency: libssl.so.5 for package: slrn
> --> Processing Dependency: libcrypto.so.5 for package: sendmail
> --> Processing Dependency: libssl.so.5 for package: libgnomeprint22
> --> Processing Dependency: libcrypto.so.5 for package: mutt
> --> Processing Dependency: libcrypto.so.5 for package: xchat
> --> Processing Dependency: libcrypto.so.5 for package: ghostscript
> --> Processing Dependency: libcrypto.so.5 for package: vorbis-tools
> --> Processing Dependency: libcrypto.so.5 for package: fetchmail
> --> Processing Dependency: libssl.so.5 for package: iiimf-libs
> --> Processing Dependency: libssl.so.5 for package: sendmail
> --> Processing Dependency: libcrypto.so.5 for package: libgnomeprint22
> --> Processing Dependency: libssl.so.5 for package: pyOpenSSL
> --> Processing Dependency: libcrypto.so.5 for package: ntp
> --> Processing Dependency: libssl.so.5 for package: elinks
> --> Processing Dependency: libssl.so.5 for package: stunnel
> --> Processing Dependency: libssl.so.5 for package: fetchmail
> --> Processing Dependency: libssl.so.5 for package: perl-Crypt-SSLeay
> --> Processing Dependency: libcrypto.so.5 for package: stunnel
> --> Processing Dependency: libcrypto.so.5 for package: python
> --> Processing Dependency: libcrypto.so.5 for package: openssh
> --> Processing Dependency: libcrypto.so.5 for package: openldap
> --> Processing Dependency: libcrypto.so.5 for package: pam_ccreds
> --> Processing Dependency: libcrypto.so.5 for package: wget
> --> Processing Dependency: libcrypto.so.5 for package: mysql
> --> Processing Dependency: libssl.so.5 for package: postgresql-libs
> --> Processing Dependency: libcrypto.so.5 for package: iiimf-libs
> --> Processing Dependency: libssl.so.5 for package: mutt
> --> Processing Dependency: libcrypto.so.5 for package: nmap
> --> Processing Dependency: libcrypto.so.5 for package: kdelibs
> --> Processing Dependency: libssl.so.5 for package: wget
> --> Processing Dependency: libcrypto.so.5 for package: openssh-server
> --> Processing Dependency: libcrypto.so.5 for package: pyOpenSSL
> --> Processing Dependency: libssl.so.5 for package: mysql
> --> Processing Dependency: libcrypto.so.5 for package: postgresql-libs
> --> Processing Dependency: libcrypto.so.5 for package: tcpdump
> --> Processing Dependency: libssl.so.5 for package: nmap
> --> Processing Dependency: libcrypto.so.5 for package: perl-Crypt-SSLeay
> --> Processing Dependency: libcrypto.so.5 for package: gnome-vfs2
> --> Processing Dependency: libssl.so.5 for package: python
> --> Processing Dependency: libcrypto.so.5 for package: elinks
> --> Processing Dependency: libcrypto.so.5 for package: slrn
> --> Processing Dependency: libssl.so.5 for package: gnome-vfs2
> --> Processing Dependency: libcrypto.so.5 for package: libgnomecups
> --> Processing Dependency: libssl.so.5 for package: vorbis-tools
> --> Finished Dependency Resolution
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> libwvstreams
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> openssh-clients
> Error: Missing Dependency: libssl.so.5 is needed by package xchat
> Error: Missing Dependency: libssl.so.5 is needed by package ghostscript
> Error: Missing Dependency: libssl.so.5 is needed by package openldap
> Error: Missing Dependency: libssl.so.5 is needed by package libgnomecups
> Error: Missing Dependency: libssl.so.5 is needed by package kdelibs
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> ipsec-tools
> Error: Missing Dependency: libssl.so.5 is needed by package libwvstreams
> Error: Missing Dependency: libssl.so.5 is needed by package slrn
> Error: Missing Dependency: libcrypto.so.5 is needed by package sendmail
> Error: Missing Dependency: libssl.so.5 is needed by package
> libgnomeprint22
> Error: Missing Dependency: libcrypto.so.5 is needed by package mutt
> Error: Missing Dependency: libcrypto.so.5 is needed by package xchat
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> ghostscript
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> vorbis-tools
> Error: Missing Dependency: libcrypto.so.5 is needed by package fetchmail
> Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
> Error: Missing Dependency: libssl.so.5 is needed by package sendmail
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> libgnomeprint22
> Error: Missing Dependency: libssl.so.5 is needed by package pyOpenSSL
> Error: Missing Dependency: libcrypto.so.5 is needed by package ntp
> Error: Missing Dependency: libssl.so.5 is needed by package elinks
> Error: Missing Dependency: libssl.so.5 is needed by package stunnel
> Error: Missing Dependency: libssl.so.5 is needed by package fetchmail
> Error: Missing Dependency: libssl.so.5 is needed by package
> perl-Crypt-SSLeay
> Error: Missing Dependency: libcrypto.so.5 is needed by package stunnel
> Error: Missing Dependency: libcrypto.so.5 is needed by package python
> Error: Missing Dependency: libcrypto.so.5 is needed by package openssh
> Error: Missing Dependency: libcrypto.so.5 is needed by package openldap
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> pam_ccreds
> Error: Missing Dependency: libcrypto.so.5 is needed by package wget
> Error: Missing Dependency: libcrypto.so.5 is needed by package mysql
> Error: Missing Dependency: libssl.so.5 is needed by package
> postgresql-libs
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> iiimf-libs
> Error: Missing Dependency: libssl.so.5 is needed by package mutt
> Error: Missing Dependency: libcrypto.so.5 is needed by package nmap
> Error: Missing Dependency: libcrypto.so.5 is needed by package kdelibs
> Error: Missing Dependency: libssl.so.5 is needed by package wget
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> openssh-server
> Error: Missing Dependency: libcrypto.so.5 is needed by package pyOpenSSL
> Error: Missing Dependency: libssl.so.5 is needed by package mysql
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> postgresql-libs
> Error: Missing Dependency: libcrypto.so.5 is needed by package tcpdump
> Error: Missing Dependency: libssl.so.5 is needed by package nmap
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> perl-Crypt-SSLeayError: Missing Dependency: libcrypto.so.5 is needed by
> package gnome-vfs2
> Error: Missing Dependency: libssl.so.5 is needed by package python
> Error: Missing Dependency: libcrypto.so.5 is needed by package elinks
> Error: Missing Dependency: libcrypto.so.5 is needed by package slrn
> Error: Missing Dependency: libssl.so.5 is needed by package gnome-vfs2
> Error: Missing Dependency: libcrypto.so.5 is needed by package
> libgnomecups
> Error: Missing Dependency: libssl.so.5 is needed by package vorbis-tools
> 
> -- 
> Igor Jagec
> 



From igorm5 at vip.hr  Thu Nov 10 11:36:41 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Thu, 10 Nov 2005 12:36:41 +0100
Subject: missing dependency on FC4 Rawhide
In-Reply-To: <1131623836.3728.4.camel@isz>
References: <43732812.6010700@vip.hr> <1131623836.3728.4.camel@isz>
Message-ID: <437330C9.5040900@vip.hr>

Dan Fruehauf wrote:

> Yes,
> There was a thread about it before.
> Just create the appropriate links and continue - should be fixed next
> time...

I did the following:

# ln -s libssl.so.6 libssl.so.5 && ln -s libcrypto.so.6 libcrypto.so.5

And it didn't help. Those required files are in my rpm database (?) as
you can see:

[root at munja lib]# rpm -ql openssl | grep lib
/lib/libcrypto.so.0.9.7f
/lib/libcrypto.so.5
/lib/libssl.so.0.9.7f
/lib/libssl.so.5
[root at munja lib]# rpm -q openssl
openssl-0.9.7f-11

-- 
Igor Jagec



From sundaram at redhat.com  Thu Nov 10 14:02:14 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 10 Nov 2005 19:32:14 +0530
Subject: missing dependency on FC4 Rawhide
In-Reply-To: <437330C9.5040900@vip.hr>
References: <43732812.6010700@vip.hr> <1131623836.3728.4.camel@isz>
	<437330C9.5040900@vip.hr>
Message-ID: <437352E6.2070902@redhat.com>

Igor Jagec wrote:

>Dan Fruehauf wrote:
>
>  
>
>>Yes,
>>There was a thread about it before.
>>Just create the appropriate links and continue - should be fixed next
>>time...
>>    
>>
>
>I did the following:
>
># ln -s libssl.so.6 libssl.so.5 && ln -s libcrypto.so.6 libcrypto.so.5
>
>And it didn't help. Those required files are in my rpm database (?) as
>you can see:
>  
>
Might want to check this package instead of symlinks
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803

regards
Rahul



From buildsys at redhat.com  Wed Nov  9 16:10:48 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 9 Nov 2005 11:10:48 -0500
Subject: rawhide report: 20051109 changes
Message-ID: <200511091610.jA9GAmV1023124@porkchop.devel.redhat.com>

 

 
Updated Packages:

GFS-kernel-2.6.14.0-20051108.134753.FC5.1
-----------------------------------------

anaconda-10.89.8-1
------------------
* Tue Nov 08 2005 Jeremy Katz <katzj at redhat.com> - 10.89.8-1
- Fix backwards message on upgrade (#172030)
- New chinese fonts (#172163)
- Don't try to update a progress window that's already popped (clumens, #172232)
- Fix snack deprecation warnings (clumens, #172232)
- Get rid of some cruft in traceback dumps (clumens)
- Add a method to check for "real" consoles, add xen console to the list 
  of weird stuff
- Basic support for transaction errors other than tracebacks...
- Fix a kickstart traceback for authconfig
- Add xenblk and xennet to module-info

authd-1.4.3-6.devel
-------------------
* Tue Nov 08 2005 Martin Stransky <stransky at redhat.com>
- rebuilt

bind-24:9.3.1-21
----------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> - 24:9.3.1-21
- rebuilt with new openssl

cadaver-0.22.2-3
----------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 0.22.2-3
- rebuilt with new openssl

checkpolicy-1.27.17-6
---------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-6
- Rebuild to get latest libsepol

* Tue Oct 25 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-1
- Latest upgrade from NSA
	* Merged dismod fix from Joshua Brindle.

* Thu Oct 20 2005 Dan Walsh <dwalsh at redhat.com> 1.27.16-1
- Latest upgrade from NSA
	* Removed obsolete cond_check_type_rules() function and call and 
	  cond_optimize_lists() call from checkpolicy.c; these are handled
	  during parsing and expansion now.
	* Updated calls to expand_module for interface change.
	* Changed checkmodule to verify that expand_module succeeds 
	  when building base modules.
	* Merged module compiler fixes from Joshua Brindle.
	* Removed direct calls to hierarchy_check_constraints() and 
	  check_assertions() from checkpolicy since they are now called 
	  internally by expand_module().

chkconfig-1.3.21-1
------------------
* Tue Nov 08 2005 Bill Nottingham <notting at redhat.com>
- for LSB scripts, use any chkconfig: priorities as a basis,
  instead of 50/50 (#172599)
- fix LSB script dependency setting when no chkconfig: line
  is present (#161870, <jean-francois.larvoire at hp.com>)
- fix LSB script dependency setting when one of Required-Stop
  or Required-Start: is missing (#168457)

* Fri Oct 07 2005 Bill Nottingham <notting at redhat.com>
- fix segfault on directories in /etc/xinetd.d (#166385)
- don't needlessly rewrite xinetd files (#81008)

* Thu May 05 2005 Bill Nottingham <notting at redhat.com> 1.3.20-1
- fix deletion of orphaned slave links (#131496, <mitr at redhat.com>)

ckermit-8.0.211-4
-----------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 8.0.211-4
- rebuilt with new openssl

cman-kernel-2.6.14.0-20051108.134753.FC5.2
------------------------------------------
* Sun Jul 31 2005 Florian La Roche <laroche at redhat.com>
- no package should BR fake-build-provides

coreutils-5.93-1
----------------
* Tue Nov 08 2005 Tim Waugh <twaugh at redhat.com> 5.93-1
- 5.93.
- No longer need alt-md5sum-binary, dircolors, mkdir, mkdir2 or tac patches.

crypto-utils-2.2-8
------------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> - 2.2-8
- rebuilt with new openssl

cups-1:1.1.23-25
----------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 1:1.1.23-25
- rebuilt with new openssl

curl-7.15.0-2
-------------
* Wed Nov 09 2005 Ivana Varekova <varekova at redhat.com> 7.15.0-2
- rebuilt

cyrus-sasl-2.1.21-6
-------------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 2.1.21-6
- rebuilt with new openssl

ddd-3.3.11-3
------------
* Tue Nov 08 2005 Than Ngo <than at redhat.com> 3.3.11-3 
- get rid of xorg-x11-devel, fix for modular X

desktop-printing-0.19-3
-----------------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> - 0.19-3
- rebuilt with new openssl

dhcpv6-0.10-15
--------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 0.10-15
- rebuilt with new openssl

distcache-1.4.5-12
------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 1.4.5-12
- rebuilt with new openssl

dlm-kernel-2.6.14.0-20051108.134753.FC5.2
-----------------------------------------

dovecot-0.99.14-9.fc5
---------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 0.99.14-9.fc5
- rebuilt with new openssl

evolution-connector-2.4.1-2
---------------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 2.4.1-2
- rebuilt with new openssl

fonts-chinese-3.01-2
--------------------
* Wed Nov 09 2005 Leon Ho <llch at redhat.com> - 3.01-2
- updated to use which to search for mkfontdir
- update to Requires: mkfontdir.

gimp-2:2.2.9-2
--------------
* Tue Nov 08 2005 Nils Philippsen <nphilipp at redhat.com>
- don't include .la files (#172626)
- require findutils for building

* Wed Nov 02 2005 Nils Philippsen <nphilipp at redhat.com> - 2.2.9
- version 2.2.9
- first attempt at dealing with modular X

* Tue Aug 16 2005 Nils Philippsen <nphilipp at redhat.com>
- rebuild

gnbd-kernel-2.6.14.0-20051108.134753.FC5.4
------------------------------------------

gnome-volume-manager-1.5.3-2
----------------------------
* Tue Nov 08 2005 Matthias Clasen <mclasen at redhat.com> - 1.5.3-2
- disable debug spew

gtk2-2.8.6-6
------------
* Tue Nov 08 2005 Matthias Clasen <mclasen at redhat.com> 2.8.6-6
- Clean up spec file a bit

hal-0.5.4-4
-----------
* Tue Nov 08 2005 John (J5) Palmieri <johnp at redhat.com> - 0.5.4-4
- Add patch to fix storage policy fdi to match on the storage
  capability and not category.

* Mon Oct 03 2005 Matthias Clasen <mclasen at redhat.com>
- Fix a typo in description

iputils-20020927-30
-------------------
* Tue Nov 08 2005 Radek Vokal <rvokal at redhat.com> 20020927-30
- don't ship traceroute6, now part of traceroute package

jpilot-0.99.8-2
---------------
* Wed Nov 09 2005 Ivana Varekova <varekova at redhat.com> 0.99.8-2
- rebuilt

kernel-2.6.14-1.1656_FC5
------------------------
* Tue Nov 08 2005 Dave Jones <davej at redhat.com>
- Update patch to write protect read-only kernel data.

* Tue Nov 08 2005 David Woodhouse <dwmw2 at redhat.com>
- 2.6.14-git11

* Mon Nov 07 2005 Dave Jones <davej at redhat.com>
- 2.6.14-git10

krb5-auth-dialog-0.5-1
----------------------
* Tue Nov 08 2005 Christopher Aillon <caillon at redhat.com> 0.5-1
- Update to 0.5

libgnomeui-2.12.0-4
-------------------
* Tue Nov 08 2005 Matthias Clasen <mclasen at redhat.com> - 2.12.0-5
- Remove static libs

* Sun Nov 06 2005 Matthias Clasen <mclasen at redhat.com> - 2.12.0-4
- Switch requires to modular X

* Mon Sep 12 2005 Jeremy Katz <katzj at redhat.com> - 2.12.0-2
- devel subpackage requires gnome-keyring-devel (noticed by Marc Maurer)

libselinux-1.27.21-1
--------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.21-1
- Update to latest from NSA
	* Added MATCHPATHCON_NOTRANS flag for set_matchpathcon_flags()
	  and modified matchpathcon_init() to skip context translation
	  if it is set by the caller.

* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.20-1
- Update to latest from NSA
	* Added security_canonicalize_context() interface and
	  set_matchpathcon_canoncon() interface for obtaining
	  canonical contexts.  Changed matchpathcon internals
	  to obtain canonical contexts by default.  Provided
	  fallback for kernels that lack extended selinuxfs context
	  interface.
- Patch to not translate mls when calling setfiles

libsemanage-1.3.51-1
--------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.3.51-1
- Upgrade to latest from NSA
	* Clear modules modified flag upon disconnect and commit.
        * Added tracking of module modifications and use it to
	  determine whether expand-time checks should be applied
	  on commit.
	* Reverted semanage_set_reload_bools() interface.

* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.3.48-1
- Upgrade to latest from NSA
	* Disabled calls to port dbase for merge and commit and stubbed
	  out calls to sepol_port interfaces since they are not exported.
	* Merged rename instead of copy patch from Joshua Brindle (Tresys).
	* Added hidden_def/hidden_proto for exported symbols used within 
	  libsemanage to eliminate relocations.  Wrapped type definitions
	  in exported headers as needed to avoid conflicts.  Added
	  src/context_internal.h and src/iface_internal.h.
	* Added semanage_is_managed() interface to allow detection of whether
	  the policy is managed via libsemanage.  This enables proper handling
	  in setsebool for non-managed systems.
	* Merged semanage_set_reload_bools() interface from Ivan Gyurdiev,
	  to enable runtime control over preserving active boolean values
	  versus reloading their saved settings upon commit.

libsepol-1.9.38-1
-----------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.9.38-1
- Upgrade to latest from NSA
	* Removed sepol_port_* from libsepol.map, as the port interfaces
	  are not yet stable.

linuxwacom-0:0.6.6-6
--------------------
* Tue Nov 08 2005 Kristian H??gsberg <krh at redhat.com> 0:0.6.6-6
- Update X11 library dependencies.
- Change back _x11libdir definition.
- Change udev rule to match on vendor id instead of manufacturer name,
  since that's seems to be more reliable.
- Test for libX11.so instead of X11 subdir in X11 libdir test.

lvm2-2.01.14-4
--------------
* Tue Nov 08 2005 Jeremy Katz <katzj at redhat.com> - 2.01.14-4
- add patch for xen block devices

magma-1.0.2-1
-------------

mc-1:4.6.1a-0.21
----------------
* Sat Nov 05 2005 Jindrich Novy <jnovy at redhat.com> 4.6.1a-0.21
- add vertical scrollbars to main panels and listboxes
- fix memleak in menu.c caused by UTF-8 patch
- display UTF-8 characters corectly in mcview (#172571)
- fix extensions patch

mozplugger-1.7.3-2
------------------
* Tue Nov 08 2005 Than Ngo <than at redhat.com> 1.7.3-2 
- get rid of xorg-x11-devel, fix for modular X

neon-0.24.7-9
-------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 0.24.7-9
- rebuilt with new openssl

openssl-0.9.8a-1
----------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> 0.9.8a-1
- new upstream version
- patches partially renumbered

policycoreutils-1.27.26-1
-------------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.26-1
* Added -B (--build) option to semodule to force a rebuild.
	* Reverted setsebool patch to call semanage_set_reload_bools().
	* Changed setsebool to disable policy reload and to call
	  security_set_boolean_list to update the runtime booleans.
	* Changed setfiles -c to use new flag to set_matchpathcon_flags()
	  to disable context translation by matchpathcon_init().

* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.23-1
- Update to match NSA
	* Changed setfiles for the context canonicalization support.
	* Changed setsebool to call semanage_is_managed() interface
	  and fall back to security_set_boolean_list() if policy is
	  not managed.
	* Merged setsebool memory leak fix from Ivan Gyurdiev.
	* Merged setsebool patch to call semanage_set_reload_bools()
	  interface from Ivan Gyurdiev.

procps-3.2.6-2
--------------
* Tue Nov 08 2005 Karel Zak <kzak at redhat.com> 3.2.6-2
- fix #157725 - sysctl -A returns an error

python-ldap-0:2.0.6-5
---------------------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> - 2.0.6-5
- rebuilt with new openssl

qt-1:3.3.5-8
------------
* Tue Nov 08 2005 Than Ngo <than at redhat.com> 1:3.3.5-8
- get rid of xorg-x11-devel, fix for modular X

rpm-4.4.2-7
-----------
* Tue Nov 08 2005 Tomas Mraz <tmraz at redhat.com> - 4.4.2-7
- rebuilt with new openssl

selinux-policy-mls-1.27.2-18
----------------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-18
- Fix dhcpc and dhcpd state handling
- Add controlchan to innd_exec_t

selinux-policy-strict-1.27.2-18
-------------------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-18
- Fix dhcpc and dhcpd state handling
- Add controlchan to innd_exec_t

selinux-policy-targeted-1.27.2-18
---------------------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-18
- Fix dhcpc and dhcpd state handling
- Add controlchan to innd_exec_t

star-1.5a69-1
-------------
* Tue Nov 08 2005 Peter Vrabec <pvrabec at redhat.com> 1.5a69-1
- upgrade

* Mon Oct 10 2005 Peter Vrabec <pvrabec at redhat.com> 1.5a68-1
- upgrade

* Thu Sep 22 2005 Peter Vrabec <pvrabec at redhat.com> 1.5a67-1
- upgrade

sudo-1.6.8p11-1
---------------
* Tue Nov 08 2005 Karel Zak <kzak at redhat.com> 1.6.8p11-1
- new upstream version 1.6.8p11

traceroute-2:1.0.3-4
--------------------
* Tue Nov 08 2005 Radek Vokal <rvokal at redhat.com> 1.0.3-4
- comaptibility patch, use -s and -i options

* Thu Nov 03 2005 Robert Scheck <redhat at linuxnetz.de> 1.0.3-3
- enable working IPv6 support in traceroute
- removed old compatibility links, nothing has SUID/SGID
- added some documentation files
- don't expand rpm macros in %changelog

* Wed Nov 02 2005 Xose Vazquez Perez <xose.vazquez at gmail.com> 1.0.3-2
- license is GPL
- remove S_ISUID from /bin/traceroute
- description of this implementation
- s/$RPM_BUILD_ROOT/%{buildroot}
- man page needs 0644
- link it agains relative paths, it works over NFS

xpdf-1:3.01-4
-------------
* Tue Nov 08 2005 Than Ngo <than at redhat.com> 3.01-4
- get rid of XFree86-devel

yum-2.4.0-10
------------
* Tue Nov 08 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-10
- fix problem in installonlyn that caillon hit where removing kernels 
  would trigger instead of only happening on update/install of kernels
- make plugin config files noreplace

Broken deps for i386
----------------------------------------------------------
	openssh-clients - 4.2p1-5.i386 requires libcrypto.so.5
	postfix - 2:2.2.5-1.i386 requires libcrypto.so.5
	postfix - 2:2.2.5-1.i386 requires libssl.so.5
	kdelibs - 6:3.4.92-2.i386 requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.i386 requires libssl.so.5
	python - 2.4.1-14.i386 requires libssl.so.5
	python - 2.4.1-14.i386 requires libcrypto.so.5
	kdeutils - 6:3.4.92-3.i386 requires libcrypto.so.5
	httpd - 2.0.54-15.i386 requires libssl.so.5
	httpd - 2.0.54-15.i386 requires libcrypto.so.5
	hplip - 0.9.6-5.i386 requires libcrypto.so.5
	glibc-debuginfo - 2.3.90-15.i386 requires glibc-debuginfo-common = 0:2.3.90-15
	libgnomecups - 0.2.2-1.i386 requires libssl.so.5
	libgnomecups - 0.2.2-1.i386 requires libcrypto.so.5
	nmap - 2:3.93-1.i386 requires libcrypto.so.5
	nmap - 2:3.93-1.i386 requires libssl.so.5
	netatalk - 4:2.0.3-3.i386 requires libcrypto.so.5
	netatalk - 4:2.0.3-3.i386 requires libssl.so.5
	postgresql-contrib - 8.1.0-1.i386 requires libcrypto.so.5
	postgresql-contrib - 8.1.0-1.i386 requires libssl.so.5
	gkrellm - 2.2.7-3.i386 requires libcrypto.so.5
	gkrellm - 2.2.7-3.i386 requires libssl.so.5
	OpenIPMI - 1.4.14-11.i386 requires libcrypto.so.5
	gwenhywfar - 1.7.2-2.i386 requires libssl.so.5
	gwenhywfar - 1.7.2-2.i386 requires libcrypto.so.5
	net-snmp-libs - 5.2.2-0.rc4.1.i386 requires libcrypto.so.5
	ethereal - 0.10.13-3.i386 requires libcrypto.so.5
	gimp-print-cups - 4.2.7-12.i386 requires libcrypto.so.5
	gimp-print-cups - 4.2.7-12.i386 requires libssl.so.5
	net-snmp - 5.2.2-0.rc4.1.i386 requires libcrypto.so.5
	net-snmp - 5.2.2-0.rc4.1.i386 requires libssl.so.5
	freeradius - 1.0.4-3.i386 requires libcrypto.so.5
	freeradius - 1.0.4-3.i386 requires libssl.so.5
	libc-client - 2002e-11.i386 requires libssl.so.5
	libc-client - 2002e-11.i386 requires libcrypto.so.5
	sendmail - 8.13.5-1.i386 requires libcrypto.so.5
	sendmail - 8.13.5-1.i386 requires libssl.so.5
	perl-Crypt-SSLeay - 0.51-8.i386 requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.i386 requires libssl.so.5
	php-snmp - 5.0.5-5.i386 requires libcrypto.so.5
	subversion-javahl - 1.2.3-3.i386 requires libcrypto.so.5
	subversion-javahl - 1.2.3-3.i386 requires libssl.so.5
	php - 5.0.5-5.i386 requires libcrypto.so.5
	php - 5.0.5-5.i386 requires libssl.so.5
	tcpdump - 14:3.9.3-3.i386 requires libcrypto.so.5
	xchat - 1:2.4.5-1.i386 requires libcrypto.so.5
	xchat - 1:2.4.5-1.i386 requires libssl.so.5
	net-snmp-utils - 5.2.2-0.rc4.1.i386 requires libcrypto.so.5
	postgresql-server - 8.1.0-1.i386 requires libssl.so.5
	postgresql-server - 8.1.0-1.i386 requires libcrypto.so.5
	vsftpd - 2.0.3-11.i386 requires libcrypto.so.5
	vsftpd - 2.0.3-11.i386 requires libssl.so.5
	slrn - 0.9.8.1-5.i386 requires libssl.so.5
	slrn - 0.9.8.1-5.i386 requires libcrypto.so.5
	squid - 7:2.5.STABLE11-6.i386 requires libcrypto.so.5
	squid - 7:2.5.STABLE11-6.i386 requires libssl.so.5
	fetchmail - 6.2.5.2-1.i386 requires libssl.so.5
	fetchmail - 6.2.5.2-1.i386 requires libcrypto.so.5
	ipsec-tools - 0.6.1-1.i386 requires libcrypto.so.5
	rdesktop - 1.4.1-1.fc5.i386 requires libcrypto.so.5
	glibc-debuginfo - 2.3.90-15.i686 requires glibc-debuginfo-common = 0:2.3.90-15
	libgnomeprint22 - 2.12.1-2.i386 requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.i386 requires libssl.so.5
	slrn-pull - 0.9.8.1-5.i386 requires libcrypto.so.5
	slrn-pull - 0.9.8.1-5.i386 requires libssl.so.5
	php-mysql - 5.0.5-5.i386 requires libcrypto.so.5
	php-mysql - 5.0.5-5.i386 requires libssl.so.5
	openssh-server - 4.2p1-5.i386 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.i386 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.i386 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.i386 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.i386 requires libcrypto.so.5
	ntp - 4.2.0.a.20050816-9.i386 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.i386 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libcrypto.so.5
	mysql-server - 4.1.14-1.i386 requires libcrypto.so.5
	mysql-server - 4.1.14-1.i386 requires libssl.so.5
	kdebase - 6:3.4.92-1.i386 requires libssl.so.5
	kdebase - 6:3.4.92-1.i386 requires libcrypto.so.5
	openldap-servers - 2.2.29-2.i386 requires libssl.so.5
	openldap-servers - 2.2.29-2.i386 requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.i386 requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.i386 requires libssl.so.5
	vorbis-tools - 1:1.0.1-6.i386 requires libcrypto.so.5
	vorbis-tools - 1:1.0.1-6.i386 requires libssl.so.5
	spamassassin - 3.1.0-1.fc5.i386 requires libssl.so.5
	spamassassin - 3.1.0-1.fc5.i386 requires libcrypto.so.5
	kdenetwork - 7:3.4.92-1.i386 requires libssl.so.5
	kdenetwork - 7:3.4.92-1.i386 requires libcrypto.so.5
	postgresql-devel - 8.1.0-1.i386 requires libcrypto.so.5
	postgresql-devel - 8.1.0-1.i386 requires libssl.so.5
	mutt - 5:1.4.2.1-5.i386 requires libssl.so.5
	mutt - 5:1.4.2.1-5.i386 requires libcrypto.so.5
	kdesdk - 3.4.92-1.i386 requires libcrypto.so.5
	kdesdk - 3.4.92-1.i386 requires libssl.so.5
	freeradius-mysql - 1.0.4-3.i386 requires libcrypto.so.5
	freeradius-mysql - 1.0.4-3.i386 requires libssl.so.5
	postgresql - 8.1.0-1.i386 requires libcrypto.so.5
	postgresql - 8.1.0-1.i386 requires libssl.so.5
	nut - 2.0.2-3.i386 requires libcrypto.so.5
	m2crypto - 0.15-1.i386 requires libcrypto.so.5
	m2crypto - 0.15-1.i386 requires libssl.so.5
	mysql - 4.1.14-1.i386 requires libcrypto.so.5
	mysql - 4.1.14-1.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libcrypto.so.5
	mod_authz_ldap - 0.26-3.i386 requires libcrypto.so.5
	mod_authz_ldap - 0.26-3.i386 requires libssl.so.5
	openhpi - 2.0.3-4.i386 requires libcrypto.so.5
	openhpi - 2.0.3-4.i386 requires libssl.so.5
	pam_ccreds - 1-7.i386 requires libcrypto.so.5
	ghostscript - 8.15.1-1.i386 requires libcrypto.so.5
	ghostscript - 8.15.1-1.i386 requires libssl.so.5
	MySQL-python - 1.2.0-2.i386 requires libcrypto.so.5
	MySQL-python - 1.2.0-2.i386 requires libssl.so.5
	ethereal-gnome - 0.10.13-3.i386 requires libcrypto.so.5
	gnome-vfs2 - 2.12.1.1-4.i386 requires libssl.so.5
	gnome-vfs2 - 2.12.1.1-4.i386 requires libcrypto.so.5
	subversion - 1.2.3-3.i386 requires libcrypto.so.5
	subversion - 1.2.3-3.i386 requires libssl.so.5
	php-imap - 5.0.5-5.i386 requires libcrypto.so.5
	php-imap - 5.0.5-5.i386 requires libssl.so.5
	tog-pegasus - 2:2.5-2.i386 requires libssl.so.5
	tog-pegasus - 2:2.5-2.i386 requires libcrypto.so.5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.1.i686 requires kernel = 0:2.6.14-1.1655_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.1.i686 requires /lib/modules/2.6.14-1.1655_FC5
	wget - 1.10.2-2.i386 requires libcrypto.so.5
	wget - 1.10.2-2.i386 requires libssl.so.5
	ruby-libs - 1.8.4-0.2.preview1.i386 requires libcrypto.so.5
	ruby-libs - 1.8.4-0.2.preview1.i386 requires libssl.so.5
	w3m - 0.5.1-10.i386 requires libcrypto.so.5
	w3m - 0.5.1-10.i386 requires libssl.so.5
	magma - 1.0.2-1.i386 requires libmagmamsg.so
	magma - 1.0.2-1.i386 requires libmagma.so
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libssl.so.5
	tn5250 - 0.16.5-6.i386 requires libcrypto.so.5
	tn5250 - 0.16.5-6.i386 requires libssl.so.5
	openssh - 4.2p1-5.i386 requires libcrypto.so.5
	libwvstreams - 3.75.0-5.i386 requires libssl.so.5
	libwvstreams - 3.75.0-5.i386 requires libcrypto.so.5
	gwenhywfar-devel - 1.7.2-2.i386 requires libcrypto.so.5
	gwenhywfar-devel - 1.7.2-2.i386 requires libssl.so.5
	freeradius-unixODBC - 1.0.4-3.i386 requires libcrypto.so.5
	freeradius-unixODBC - 1.0.4-3.i386 requires libssl.so.5
	perl-RPM2 - 0.66-9.i386 requires libcrypto.so.5
	perl-RPM2 - 0.66-9.i386 requires libssl.so.5
	elinks - 0.10.6-1.i386 requires libcrypto.so.5
	elinks - 0.10.6-1.i386 requires libssl.so.5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.1.i686 requires /lib/modules/2.6.14-1.1655_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.1.i686 requires kernel-smp = 0:2.6.14-1.1655_FC5
	xmlsec1-openssl - 1.2.9-1.i386 requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.i386 requires libssl.so.5
	libsane-hpaio - 0.9.6-5.i386 requires libcrypto.so.5
	stunnel - 4.14-1.i386 requires libcrypto.so.5
	stunnel - 4.14-1.i386 requires libssl.so.5
	openldap - 2.2.29-2.i386 requires libcrypto.so.5
	openldap - 2.2.29-2.i386 requires libssl.so.5
	gftp - 1:2.0.18-2.i386 requires libssl.so.5
	gftp - 1:2.0.18-2.i386 requires libcrypto.so.5
	lynx - 2.8.5-24.i386 requires libcrypto.so.5
	lynx - 2.8.5-24.i386 requires libssl.so.5
	net-snmp-perl - 5.2.2-0.rc4.1.i386 requires libcrypto.so.5
	OpenIPMI-tools - 1.4.14-11.i386 requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.i386 requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.i386 requires libssl.so.5



Broken deps for ia64
----------------------------------------------------------
	ghostscript - 8.15.1-1.ia64 requires libssl.so.5()(64bit)
	ghostscript - 8.15.1-1.ia64 requires libcrypto.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.ia64 requires libssl.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.ia64 requires libcrypto.so.5()(64bit)
	lynx - 2.8.5-24.ia64 requires libssl.so.5()(64bit)
	lynx - 2.8.5-24.ia64 requires libcrypto.so.5()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	vsftpd - 2.0.3-11.ia64 requires libssl.so.5()(64bit)
	vsftpd - 2.0.3-11.ia64 requires libcrypto.so.5()(64bit)
	gwenhywfar - 1.7.2-2.ia64 requires libssl.so.5()(64bit)
	gwenhywfar - 1.7.2-2.ia64 requires libcrypto.so.5()(64bit)
	kdeutils - 6:3.4.92-3.ia64 requires libcrypto.so.5()(64bit)
	subversion - 1.2.3-3.ia64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.ia64 requires libcrypto.so.5()(64bit)
	libsane-hpaio - 0.9.6-5.ia64 requires libcrypto.so.5()(64bit)
	net-snmp-libs - 5.2.2-0.rc4.1.ia64 requires libcrypto.so.5()(64bit)
	postgresql - 8.1.0-1.ia64 requires libssl.so.5()(64bit)
	postgresql - 8.1.0-1.ia64 requires libcrypto.so.5()(64bit)
	python - 2.4.1-14.ia64 requires libcrypto.so.5()(64bit)
	python - 2.4.1-14.ia64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	php-snmp - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	tcpdump - 14:3.9.3-3.ia64 requires libcrypto.so.5()(64bit)
	mutt - 5:1.4.2.1-5.ia64 requires libssl.so.5()(64bit)
	mutt - 5:1.4.2.1-5.ia64 requires libcrypto.so.5()(64bit)
	pam_ccreds - 1-7.ia64 requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ia64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ia64 requires libcrypto.so.5()(64bit)
	w3m - 0.5.1-10.ia64 requires libssl.so.5()(64bit)
	w3m - 0.5.1-10.ia64 requires libcrypto.so.5()(64bit)
	slrn - 0.9.8.1-5.ia64 requires libssl.so.5()(64bit)
	slrn - 0.9.8.1-5.ia64 requires libcrypto.so.5()(64bit)
	xchat - 1:2.4.5-1.ia64 requires libssl.so.5()(64bit)
	xchat - 1:2.4.5-1.ia64 requires libcrypto.so.5()(64bit)
	elinks - 0.10.6-1.ia64 requires libssl.so.5()(64bit)
	elinks - 0.10.6-1.ia64 requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.ia64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	gftp - 1:2.0.18-2.ia64 requires libssl.so.5()(64bit)
	gftp - 1:2.0.18-2.ia64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.ia64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.ia64 requires libcrypto.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.ia64 requires libssl.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.ia64 requires libcrypto.so.5()(64bit)
	httpd - 2.0.54-15.ia64 requires libssl.so.5()(64bit)
	httpd - 2.0.54-15.ia64 requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.ia64 requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.ia64 requires libssl.so.5()(64bit)
	postgresql-server - 8.1.0-1.ia64 requires libcrypto.so.5()(64bit)
	postgresql-server - 8.1.0-1.ia64 requires libssl.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.ia64 requires libssl.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.ia64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.ia64 requires libssl.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.ia64 requires libcrypto.so.5()(64bit)
	tog-pegasus - 2:2.5-2.ia64 requires libssl.so.5()(64bit)
	tog-pegasus - 2:2.5-2.ia64 requires libcrypto.so.5()(64bit)
	kdebase - 6:3.4.92-1.ia64 requires libssl.so.5()(64bit)
	kdebase - 6:3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	hplip - 0.9.6-5.ia64 requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ia64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ia64 requires libcrypto.so.5()(64bit)
	postgresql-devel - 8.1.0-1.ia64 requires libssl.so.5()(64bit)
	postgresql-devel - 8.1.0-1.ia64 requires libcrypto.so.5()(64bit)
	ntp - 4.2.0.a.20050816-9.ia64 requires libcrypto.so.5()(64bit)
	OpenIPMI-tools - 1.4.14-11.ia64 requires libcrypto.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.ia64 requires libssl.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.ia64 requires libcrypto.so.5()(64bit)
	OpenIPMI - 1.4.14-11.ia64 requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.ia64 requires libssl.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.ia64 requires libcrypto.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.ia64 requires libssl.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.ia64 requires libcrypto.so.5()(64bit)
	freeradius - 1.0.4-3.ia64 requires libssl.so.5()(64bit)
	freeradius - 1.0.4-3.ia64 requires libcrypto.so.5()(64bit)
	gkrellm - 2.2.7-3.ia64 requires libssl.so.5()(64bit)
	gkrellm - 2.2.7-3.ia64 requires libcrypto.so.5()(64bit)
	net-snmp-perl - 5.2.2-0.rc4.1.ia64 requires libcrypto.so.5()(64bit)
	openssh-server - 4.2p1-5.ia64 requires libcrypto.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.ia64 requires libssl.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.ia64 requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ia64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	php-mysql - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	ethereal-gnome - 0.10.13-3.ia64 requires libcrypto.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.ia64 requires libssl.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.ia64 requires libcrypto.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.ia64 requires libssl.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.ia64 requires libcrypto.so.5()(64bit)
	ipsec-tools - 0.6.1-1.ia64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.ia64 requires libcrypto.so.5()(64bit)
	MySQL-python - 1.2.0-2.ia64 requires libssl.so.5()(64bit)
	MySQL-python - 1.2.0-2.ia64 requires libcrypto.so.5()(64bit)
	stunnel - 4.14-1.ia64 requires libssl.so.5()(64bit)
	stunnel - 4.14-1.ia64 requires libcrypto.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.ia64 requires libssl.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.ia64 requires libcrypto.so.5()(64bit)
	openssh-clients - 4.2p1-5.ia64 requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ia64 requires libssl.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ia64 requires libcrypto.so.5()(64bit)
	nut - 2.0.2-3.ia64 requires libcrypto.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.ia64 requires libssl.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.ia64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.ia64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.ia64 requires libssl.so.5()(64bit)
	postgresql-libs - 8.1.0-1.ia64 requires libssl.so.5()(64bit)
	postgresql-libs - 8.1.0-1.ia64 requires libcrypto.so.5()(64bit)
	fetchmail - 6.2.5.2-1.ia64 requires libssl.so.5()(64bit)
	fetchmail - 6.2.5.2-1.ia64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ia64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ia64 requires libcrypto.so.5()(64bit)
	net-snmp-utils - 5.2.2-0.rc4.1.ia64 requires libcrypto.so.5()(64bit)
	libgnomecups - 0.2.2-1.ia64 requires libssl.so.5()(64bit)
	libgnomecups - 0.2.2-1.ia64 requires libcrypto.so.5()(64bit)
	netatalk - 4:2.0.3-3.ia64 requires libcrypto.so.5()(64bit)
	netatalk - 4:2.0.3-3.ia64 requires libssl.so.5()(64bit)
	ethereal - 0.10.13-3.ia64 requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.ia64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.ia64 requires libcrypto.so.5()(64bit)
	mod_authz_ldap - 0.26-3.ia64 requires libssl.so.5()(64bit)
	mod_authz_ldap - 0.26-3.ia64 requires libcrypto.so.5()(64bit)
	openssh - 4.2p1-5.ia64 requires libcrypto.so.5()(64bit)
	libwvstreams - 3.75.0-5.ia64 requires libssl.so.5()(64bit)
	libwvstreams - 3.75.0-5.ia64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ia64 requires libssl.so.5()(64bit)
	sendmail - 8.13.5-1.ia64 requires libcrypto.so.5()(64bit)
	m2crypto - 0.15-1.ia64 requires libssl.so.5()(64bit)
	m2crypto - 0.15-1.ia64 requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.ia64 requires libssl.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.ia64 requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.ia64 requires libssl.so.5()(64bit)
	mysql-server - 4.1.14-1.ia64 requires libcrypto.so.5()(64bit)
	libc-client - 2002e-11.ia64 requires libssl.so.5()(64bit)
	libc-client - 2002e-11.ia64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.ia64 requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.ia64 requires libcrypto.so.5()(64bit)
	mod_ssl - 1:2.0.54-15.ia64 requires libssl.so.5()(64bit)
	mod_ssl - 1:2.0.54-15.ia64 requires libcrypto.so.5()(64bit)
	postfix - 2:2.2.5-1.ia64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.ia64 requires libcrypto.so.5()(64bit)
	mysql - 4.1.14-1.ia64 requires libssl.so.5()(64bit)
	mysql - 4.1.14-1.ia64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ia64 requires libmagmamsg.so()(64bit)



Broken deps for ppc
----------------------------------------------------------
	perl-DBD-MySQL - 3.0002-1.ppc requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.ppc requires libcrypto.so.5
	mysql-server - 4.1.14-1.ppc requires libcrypto.so.5
	mysql-server - 4.1.14-1.ppc requires libssl.so.5
	openssh - 4.2p1-5.ppc requires libcrypto.so.5
	gwenhywfar - 1.7.2-2.ppc requires libssl.so.5
	gwenhywfar - 1.7.2-2.ppc requires libcrypto.so.5
	gimp-print-cups - 4.2.7-12.ppc requires libcrypto.so.5
	gimp-print-cups - 4.2.7-12.ppc requires libssl.so.5
	slrn - 0.9.8.1-5.ppc requires libssl.so.5
	slrn - 0.9.8.1-5.ppc requires libcrypto.so.5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	OpenIPMI-tools - 1.4.14-11.ppc requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.ppc requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.ppc requires libssl.so.5
	openldap-servers - 2.2.29-2.ppc requires libssl.so.5
	openldap-servers - 2.2.29-2.ppc requires libcrypto.so.5
	libc-client - 2002e-11.ppc requires libssl.so.5
	libc-client - 2002e-11.ppc requires libcrypto.so.5
	sendmail - 8.13.5-1.ppc requires libcrypto.so.5
	sendmail - 8.13.5-1.ppc requires libssl.so.5
	libsane-hpaio - 0.9.6-5.ppc requires libcrypto.so.5
	squid - 7:2.5.STABLE11-6.ppc requires libcrypto.so.5
	squid - 7:2.5.STABLE11-6.ppc requires libssl.so.5
	slrn-pull - 0.9.8.1-5.ppc requires libcrypto.so.5
	slrn-pull - 0.9.8.1-5.ppc requires libssl.so.5
	tcpdump - 14:3.9.3-3.ppc requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.ppc requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.ppc requires libssl.so.5
	python - 2.4.1-14.ppc requires libssl.so.5
	python - 2.4.1-14.ppc requires libcrypto.so.5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	mutt - 5:1.4.2.1-5.ppc requires libssl.so.5
	mutt - 5:1.4.2.1-5.ppc requires libcrypto.so.5
	openhpi - 2.0.3-4.ppc requires libcrypto.so.5
	openhpi - 2.0.3-4.ppc requires libssl.so.5
	net-snmp-utils - 5.2.2-0.rc4.1.ppc requires libcrypto.so.5
	net-snmp-libs - 5.2.2-0.rc4.1.ppc requires libcrypto.so.5
	hplip - 0.9.6-5.ppc requires libcrypto.so.5
	OpenIPMI - 1.4.14-11.ppc requires libcrypto.so.5
	php-snmp - 5.0.5-5.ppc requires libcrypto.so.5
	ntp - 4.2.0.a.20050816-9.ppc requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.ppc requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.ppc requires libssl.so.5
	lynx - 2.8.5-24.ppc requires libcrypto.so.5
	lynx - 2.8.5-24.ppc requires libssl.so.5
	pyOpenSSL - 0.6-1.p24.6.ppc requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.ppc requires libssl.so.5
	postgresql - 8.1.0-1.ppc requires libcrypto.so.5
	postgresql - 8.1.0-1.ppc requires libssl.so.5
	libwvstreams - 3.75.0-5.ppc requires libssl.so.5
	libwvstreams - 3.75.0-5.ppc requires libcrypto.so.5
	netatalk - 4:2.0.3-3.ppc requires libcrypto.so.5
	netatalk - 4:2.0.3-3.ppc requires libssl.so.5
	wget - 1.10.2-2.ppc requires libcrypto.so.5
	wget - 1.10.2-2.ppc requires libssl.so.5
	kdenetwork - 7:3.4.92-1.ppc requires libssl.so.5
	kdenetwork - 7:3.4.92-1.ppc requires libcrypto.so.5
	m2crypto - 0.15-1.ppc requires libcrypto.so.5
	m2crypto - 0.15-1.ppc requires libssl.so.5
	kdesdk - 3.4.92-1.ppc requires libcrypto.so.5
	kdesdk - 3.4.92-1.ppc requires libssl.so.5
	vorbis-tools - 1:1.0.1-6.ppc requires libcrypto.so.5
	vorbis-tools - 1:1.0.1-6.ppc requires libssl.so.5
	kdebase - 6:3.4.92-1.ppc requires libssl.so.5
	kdebase - 6:3.4.92-1.ppc requires libcrypto.so.5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	tn5250 - 0.16.5-6.ppc requires libcrypto.so.5
	tn5250 - 0.16.5-6.ppc requires libssl.so.5
	compat-openldap - 2.2.29_2.1.30-2.ppc requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.ppc requires libssl.so.5
	nmap - 2:3.93-1.ppc requires libcrypto.so.5
	nmap - 2:3.93-1.ppc requires libssl.so.5
	magma - 1.0.2-1.ppc requires libmagmamsg.so
	magma - 1.0.2-1.ppc requires libmagma.so
	net-snmp - 5.2.2-0.rc4.1.ppc requires libcrypto.so.5
	net-snmp - 5.2.2-0.rc4.1.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libcrypto.so.5
	openldap - 2.2.29-2.ppc requires libcrypto.so.5
	openldap - 2.2.29-2.ppc requires libssl.so.5
	postfix - 2:2.2.5-1.ppc requires libcrypto.so.5
	postfix - 2:2.2.5-1.ppc requires libssl.so.5
	openldap-clients - 2.2.29-2.ppc requires libcrypto.so.5
	openldap-clients - 2.2.29-2.ppc requires libssl.so.5
	ruby-libs - 1.8.4-0.2.preview1.ppc requires libcrypto.so.5
	ruby-libs - 1.8.4-0.2.preview1.ppc requires libssl.so.5
	subversion-javahl - 1.2.3-3.ppc requires libcrypto.so.5
	subversion-javahl - 1.2.3-3.ppc requires libssl.so.5
	xmlsec1-openssl - 1.2.9-1.ppc requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.ppc requires libssl.so.5
	mod_authz_ldap - 0.26-3.ppc requires libcrypto.so.5
	mod_authz_ldap - 0.26-3.ppc requires libssl.so.5
	gkrellm - 2.2.7-3.ppc requires libcrypto.so.5
	gkrellm - 2.2.7-3.ppc requires libssl.so.5
	ghostscript - 8.15.1-1.ppc requires libcrypto.so.5
	ghostscript - 8.15.1-1.ppc requires libssl.so.5
	elinks - 0.10.6-1.ppc requires libcrypto.so.5
	elinks - 0.10.6-1.ppc requires libssl.so.5
	gnome-vfs2 - 2.12.1.1-4.ppc requires libssl.so.5
	gnome-vfs2 - 2.12.1.1-4.ppc requires libcrypto.so.5
	samba-swat - 3.0.20-2.ppc requires libssl.so.5
	samba-swat - 3.0.20-2.ppc requires libcrypto.so.5
	gftp - 1:2.0.18-2.ppc requires libssl.so.5
	gftp - 1:2.0.18-2.ppc requires libcrypto.so.5
	xchat - 1:2.4.5-1.ppc requires libcrypto.so.5
	xchat - 1:2.4.5-1.ppc requires libssl.so.5
	openssh-clients - 4.2p1-5.ppc requires libcrypto.so.5
	tog-pegasus - 2:2.5-2.ppc requires libssl.so.5
	tog-pegasus - 2:2.5-2.ppc requires libcrypto.so.5
	php-imap - 5.0.5-5.ppc requires libcrypto.so.5
	php-imap - 5.0.5-5.ppc requires libssl.so.5
	MySQL-python - 1.2.0-2.ppc requires libcrypto.so.5
	MySQL-python - 1.2.0-2.ppc requires libssl.so.5
	mysql - 4.1.14-1.ppc requires libcrypto.so.5
	mysql - 4.1.14-1.ppc requires libssl.so.5
	pam_ccreds - 1-7.ppc requires libcrypto.so.5
	stunnel - 4.14-1.ppc requires libcrypto.so.5
	stunnel - 4.14-1.ppc requires libssl.so.5
	php - 5.0.5-5.ppc requires libcrypto.so.5
	php - 5.0.5-5.ppc requires libssl.so.5
	ethereal - 0.10.13-3.ppc requires libcrypto.so.5
	ipsec-tools - 0.6.1-1.ppc requires libcrypto.so.5
	freeradius - 1.0.4-3.ppc requires libcrypto.so.5
	freeradius - 1.0.4-3.ppc requires libssl.so.5
	httpd - 2.0.54-15.ppc requires libssl.so.5
	httpd - 2.0.54-15.ppc requires libcrypto.so.5
	gwenhywfar-devel - 1.7.2-2.ppc requires libcrypto.so.5
	gwenhywfar-devel - 1.7.2-2.ppc requires libssl.so.5
	rdesktop - 1.4.1-1.fc5.ppc requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.ppc requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.ppc requires libssl.so.5
	postgresql-devel - 8.1.0-1.ppc requires libcrypto.so.5
	postgresql-devel - 8.1.0-1.ppc requires libssl.so.5
	mod_ssl - 1:2.0.54-15.ppc requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.ppc requires libssl.so.5
	openssh-server - 4.2p1-5.ppc requires libcrypto.so.5
	postgresql-server - 8.1.0-1.ppc requires libssl.so.5
	postgresql-server - 8.1.0-1.ppc requires libcrypto.so.5
	libgnomecups - 0.2.2-1.ppc requires libssl.so.5
	libgnomecups - 0.2.2-1.ppc requires libcrypto.so.5
	perl-RPM2 - 0.66-9.ppc requires libcrypto.so.5
	perl-RPM2 - 0.66-9.ppc requires libssl.so.5
	nut - 2.0.2-3.ppc requires libcrypto.so.5
	fetchmail - 6.2.5.2-1.ppc requires libssl.so.5
	fetchmail - 6.2.5.2-1.ppc requires libcrypto.so.5
	php-mysql - 5.0.5-5.ppc requires libcrypto.so.5
	php-mysql - 5.0.5-5.ppc requires libssl.so.5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	w3m - 0.5.1-10.ppc requires libcrypto.so.5
	w3m - 0.5.1-10.ppc requires libssl.so.5
	vsftpd - 2.0.3-11.ppc requires libcrypto.so.5
	vsftpd - 2.0.3-11.ppc requires libssl.so.5
	net-snmp-perl - 5.2.2-0.rc4.1.ppc requires libcrypto.so.5
	spamassassin - 3.1.0-1.fc5.ppc requires libssl.so.5
	spamassassin - 3.1.0-1.fc5.ppc requires libcrypto.so.5
	postgresql-contrib - 8.1.0-1.ppc requires libcrypto.so.5
	postgresql-contrib - 8.1.0-1.ppc requires libssl.so.5
	subversion - 1.2.3-3.ppc requires libcrypto.so.5
	subversion - 1.2.3-3.ppc requires libssl.so.5
	freeradius-unixODBC - 1.0.4-3.ppc requires libcrypto.so.5
	freeradius-unixODBC - 1.0.4-3.ppc requires libssl.so.5
	kdeutils - 6:3.4.92-3.ppc requires libcrypto.so.5
	ethereal-gnome - 0.10.13-3.ppc requires libcrypto.so.5
	freeradius-mysql - 1.0.4-3.ppc requires libcrypto.so.5
	freeradius-mysql - 1.0.4-3.ppc requires libssl.so.5



Broken deps for ppc64
----------------------------------------------------------
	perl-Crypt-SSLeay - 0.51-8.ppc64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ppc64 requires libcrypto.so.5()(64bit)
	vsftpd - 2.0.3-11.ppc64 requires libssl.so.5()(64bit)
	vsftpd - 2.0.3-11.ppc64 requires libcrypto.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.ppc64 requires libssl.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.ppc64 requires libcrypto.so.5()(64bit)
	gftp - 1:2.0.18-2.ppc64 requires libssl.so.5()(64bit)
	gftp - 1:2.0.18-2.ppc64 requires libcrypto.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.ppc64 requires libssl.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.ppc64 requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	pam_ccreds - 1-7.ppc64 requires libcrypto.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	postgresql - 8.1.0-1.ppc64 requires libssl.so.5()(64bit)
	postgresql - 8.1.0-1.ppc64 requires libcrypto.so.5()(64bit)
	postgresql-devel - 8.1.0-1.ppc64 requires libssl.so.5()(64bit)
	postgresql-devel - 8.1.0-1.ppc64 requires libcrypto.so.5()(64bit)
	postgresql-server - 8.1.0-1.ppc64 requires libssl.so.5()(64bit)
	postgresql-server - 8.1.0-1.ppc64 requires libcrypto.so.5()(64bit)
	php-snmp - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	netatalk - 4:2.0.3-3.ppc64 requires libssl.so.5()(64bit)
	netatalk - 4:2.0.3-3.ppc64 requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.ppc64 requires libssl.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.ppc64 requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.ppc64 requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.ppc64 requires libssl.so.5()(64bit)
	stunnel - 4.14-1.ppc64 requires libssl.so.5()(64bit)
	stunnel - 4.14-1.ppc64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.ppc64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.ppc64 requires libcrypto.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.ppc64 requires libssl.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.ppc64 requires libcrypto.so.5()(64bit)
	mod_authz_ldap - 0.26-3.ppc64 requires libssl.so.5()(64bit)
	mod_authz_ldap - 0.26-3.ppc64 requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.ppc64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.ppc64 requires libcrypto.so.5()(64bit)
	libsane-hpaio - 0.9.6-5.ppc64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ppc64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ppc64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.ppc64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.ppc64 requires libssl.so.5()(64bit)
	libc-client - 2002e-11.ppc64 requires libssl.so.5()(64bit)
	libc-client - 2002e-11.ppc64 requires libcrypto.so.5()(64bit)
	ghostscript - 8.15.1-1.ppc64 requires libssl.so.5()(64bit)
	ghostscript - 8.15.1-1.ppc64 requires libcrypto.so.5()(64bit)
	httpd - 2.0.54-15.ppc64 requires libssl.so.5()(64bit)
	httpd - 2.0.54-15.ppc64 requires libcrypto.so.5()(64bit)
	mutt - 5:1.4.2.1-5.ppc64 requires libssl.so.5()(64bit)
	mutt - 5:1.4.2.1-5.ppc64 requires libcrypto.so.5()(64bit)
	php-mysql - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.ppc64 requires libssl.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.ppc64 requires libcrypto.so.5()(64bit)
	xchat - 1:2.4.5-1.ppc64 requires libssl.so.5()(64bit)
	xchat - 1:2.4.5-1.ppc64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagmamsg.so()(64bit)
	mod_ssl - 1:2.0.54-15.ppc64 requires libssl.so.5()(64bit)
	mod_ssl - 1:2.0.54-15.ppc64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ppc64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ppc64 requires libssl.so.5()(64bit)
	python - 2.4.1-14.ppc64 requires libssl.so.5()(64bit)
	python - 2.4.1-14.ppc64 requires libcrypto.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.ppc64 requires libssl.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.ppc64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.ppc64 requires libcrypto.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.ppc64 requires libssl.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.ppc64 requires libcrypto.so.5()(64bit)
	postfix - 2:2.2.5-1.ppc64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.ppc64 requires libcrypto.so.5()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	openssh-server - 4.2p1-5.ppc64 requires libcrypto.so.5()(64bit)
	kdeutils - 6:3.4.92-3.ppc64 requires libcrypto.so.5()(64bit)
	gwenhywfar - 1.7.2-2.ppc64 requires libssl.so.5()(64bit)
	gwenhywfar - 1.7.2-2.ppc64 requires libcrypto.so.5()(64bit)
	ntp - 4.2.0.a.20050816-9.ppc64 requires libcrypto.so.5()(64bit)
	hplip - 0.9.6-5.ppc64 requires libcrypto.so.5()(64bit)
	nut - 2.0.2-3.ppc64 requires libcrypto.so.5()(64bit)
	libgnomecups - 0.2.2-1.ppc64 requires libssl.so.5()(64bit)
	libgnomecups - 0.2.2-1.ppc64 requires libcrypto.so.5()(64bit)
	tog-pegasus - 2:2.5-2.ppc64 requires libcrypto.so.5()(64bit)
	tog-pegasus - 2:2.5-2.ppc64 requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.ppc64 requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.ppc64 requires libcrypto.so.5()(64bit)
	openssh-clients - 4.2p1-5.ppc64 requires libcrypto.so.5()(64bit)
	ipsec-tools - 0.6.1-1.ppc64 requires libcrypto.so.5()(64bit)
	subversion - 1.2.3-3.ppc64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.ppc64 requires libcrypto.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.ppc64 requires libssl.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.ppc64 requires libcrypto.so.5()(64bit)
	OpenIPMI-tools - 1.4.14-11.ppc64 requires libcrypto.so.5()(64bit)
	postgresql-libs - 8.1.0-1.ppc64 requires libssl.so.5()(64bit)
	postgresql-libs - 8.1.0-1.ppc64 requires libcrypto.so.5()(64bit)
	libwvstreams - 3.75.0-5.ppc64 requires libssl.so.5()(64bit)
	libwvstreams - 3.75.0-5.ppc64 requires libcrypto.so.5()(64bit)
	slrn - 0.9.8.1-5.ppc64 requires libssl.so.5()(64bit)
	slrn - 0.9.8.1-5.ppc64 requires libcrypto.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.ppc64 requires libssl.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.ppc64 requires libcrypto.so.5()(64bit)
	kdebase - 6:3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdebase - 6:3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	ethereal-gnome - 0.10.13-3.ppc64 requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap-servers - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.ppc64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.ppc64 requires libcrypto.so.5()(64bit)
	fetchmail - 6.2.5.2-1.ppc64 requires libssl.so.5()(64bit)
	fetchmail - 6.2.5.2-1.ppc64 requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ppc64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ppc64 requires libcrypto.so.5()(64bit)
	freeradius - 1.0.4-3.ppc64 requires libssl.so.5()(64bit)
	freeradius - 1.0.4-3.ppc64 requires libcrypto.so.5()(64bit)
	ethereal - 0.10.13-3.ppc64 requires libcrypto.so.5()(64bit)
	gkrellm - 2.2.7-3.ppc64 requires libssl.so.5()(64bit)
	gkrellm - 2.2.7-3.ppc64 requires libcrypto.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	openssh - 4.2p1-5.ppc64 requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.ppc64 requires libssl.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.ppc64 requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.ppc64 requires libssl.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.ppc64 requires libcrypto.so.5()(64bit)
	elinks - 0.10.6-1.ppc64 requires libssl.so.5()(64bit)
	elinks - 0.10.6-1.ppc64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	MySQL-python - 1.2.0-2.ppc64 requires libssl.so.5()(64bit)
	MySQL-python - 1.2.0-2.ppc64 requires libcrypto.so.5()(64bit)
	openhpi - 2.0.3-4.ppc64 requires libcrypto.so.5()(64bit)
	openhpi - 2.0.3-4.ppc64 requires libssl.so.5()(64bit)
	m2crypto - 0.15-1.ppc64 requires libssl.so.5()(64bit)
	m2crypto - 0.15-1.ppc64 requires libcrypto.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.ppc64 requires libssl.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.ppc64 requires libcrypto.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.ppc64 requires libssl.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.ppc64 requires libcrypto.so.5()(64bit)
	mysql - 4.1.14-1.ppc64 requires libssl.so.5()(64bit)
	mysql - 4.1.14-1.ppc64 requires libcrypto.so.5()(64bit)
	net-snmp-utils - 5.2.2-0.rc4.1.ppc64 requires libcrypto.so.5()(64bit)
	net-snmp-perl - 5.2.2-0.rc4.1.ppc64 requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ppc64 requires libssl.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ppc64 requires libcrypto.so.5()(64bit)
	lynx - 2.8.5-24.ppc64 requires libssl.so.5()(64bit)
	lynx - 2.8.5-24.ppc64 requires libcrypto.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.ppc64 requires libssl.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.ppc64 requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	w3m - 0.5.1-10.ppc64 requires libssl.so.5()(64bit)
	w3m - 0.5.1-10.ppc64 requires libcrypto.so.5()(64bit)
	net-snmp-libs - 5.2.2-0.rc4.1.ppc64 requires libcrypto.so.5()(64bit)



Broken deps for s390
----------------------------------------------------------
	samba - 3.0.20-2.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libcrypto.so.5
	nmap - 2:3.93-1.s390 requires libcrypto.so.5
	nmap - 2:3.93-1.s390 requires libssl.so.5
	ruby-libs - 1.8.4-0.2.preview1.s390 requires libcrypto.so.5
	ruby-libs - 1.8.4-0.2.preview1.s390 requires libssl.so.5
	tog-pegasus - 2:2.5-2.s390 requires libssl.so.5
	tog-pegasus - 2:2.5-2.s390 requires libcrypto.so.5
	gftp - 1:2.0.18-2.s390 requires libssl.so.5
	gftp - 1:2.0.18-2.s390 requires libcrypto.so.5
	stunnel - 4.14-1.s390 requires libcrypto.so.5
	stunnel - 4.14-1.s390 requires libssl.so.5
	kdeutils - 6:3.4.92-3.s390 requires libcrypto.so.5
	postgresql-devel - 8.1.0-1.s390 requires libcrypto.so.5
	postgresql-devel - 8.1.0-1.s390 requires libssl.so.5
	MySQL-python - 1.2.0-2.s390 requires libcrypto.so.5
	MySQL-python - 1.2.0-2.s390 requires libssl.so.5
	ethereal-gnome - 0.10.13-3.s390 requires libcrypto.so.5
	freeradius - 1.0.4-3.s390 requires libcrypto.so.5
	freeradius - 1.0.4-3.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libcrypto.so.5
	perl-DBD-MySQL - 3.0002-1.s390 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.s390 requires libcrypto.so.5
	openssh-clients - 4.2p1-5.s390 requires libcrypto.so.5
	httpd - 2.0.54-15.s390 requires libssl.so.5
	httpd - 2.0.54-15.s390 requires libcrypto.so.5
	openldap-servers - 2.2.29-2.s390 requires libssl.so.5
	openldap-servers - 2.2.29-2.s390 requires libcrypto.so.5
	python - 2.4.1-14.s390 requires libssl.so.5
	python - 2.4.1-14.s390 requires libcrypto.so.5
	wget - 1.10.2-2.s390 requires libcrypto.so.5
	wget - 1.10.2-2.s390 requires libssl.so.5
	openCryptoki - 2.1.6-1.s390 requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.s390 requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.s390 requires libssl.so.5
	gwenhywfar - 1.7.2-2.s390 requires libssl.so.5
	gwenhywfar - 1.7.2-2.s390 requires libcrypto.so.5
	net-snmp-libs - 5.2.2-0.rc4.1.s390 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.s390 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.s390 requires libssl.so.5
	php-imap - 5.0.5-5.s390 requires libcrypto.so.5
	php-imap - 5.0.5-5.s390 requires libssl.so.5
	postgresql-server - 8.1.0-1.s390 requires libssl.so.5
	postgresql-server - 8.1.0-1.s390 requires libcrypto.so.5
	perl-RPM2 - 0.66-9.s390 requires libcrypto.so.5
	perl-RPM2 - 0.66-9.s390 requires libssl.so.5
	OpenIPMI-tools - 1.4.14-11.s390 requires libcrypto.so.5
	w3m - 0.5.1-10.s390 requires libcrypto.so.5
	w3m - 0.5.1-10.s390 requires libssl.so.5
	gwenhywfar-devel - 1.7.2-2.s390 requires libcrypto.so.5
	gwenhywfar-devel - 1.7.2-2.s390 requires libssl.so.5
	php - 5.0.5-5.s390 requires libcrypto.so.5
	php - 5.0.5-5.s390 requires libssl.so.5
	openssh - 4.2p1-5.s390 requires libcrypto.so.5
	openhpi - 2.0.3-4.s390 requires libcrypto.so.5
	openhpi - 2.0.3-4.s390 requires libssl.so.5
	vsftpd - 2.0.3-11.s390 requires libcrypto.so.5
	vsftpd - 2.0.3-11.s390 requires libssl.so.5
	libgnomecups - 0.2.2-1.s390 requires libssl.so.5
	libgnomecups - 0.2.2-1.s390 requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.s390 requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.s390 requires libssl.so.5
	tcpdump - 14:3.9.3-3.s390 requires libcrypto.so.5
	slrn - 0.9.8.1-5.s390 requires libssl.so.5
	slrn - 0.9.8.1-5.s390 requires libcrypto.so.5
	m2crypto - 0.15-1.s390 requires libcrypto.so.5
	m2crypto - 0.15-1.s390 requires libssl.so.5
	openldap-clients - 2.2.29-2.s390 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.s390 requires libssl.so.5
	net-snmp - 5.2.2-0.rc4.1.s390 requires libcrypto.so.5
	net-snmp - 5.2.2-0.rc4.1.s390 requires libssl.so.5
	gnome-vfs2 - 2.12.1.1-4.s390 requires libssl.so.5
	gnome-vfs2 - 2.12.1.1-4.s390 requires libcrypto.so.5
	postfix - 2:2.2.5-1.s390 requires libcrypto.so.5
	postfix - 2:2.2.5-1.s390 requires libssl.so.5
	elinks - 0.10.6-1.s390 requires libcrypto.so.5
	elinks - 0.10.6-1.s390 requires libssl.so.5
	subversion - 1.2.3-3.s390 requires libcrypto.so.5
	subversion - 1.2.3-3.s390 requires libssl.so.5
	sendmail - 8.13.5-1.s390 requires libcrypto.so.5
	sendmail - 8.13.5-1.s390 requires libssl.so.5
	libc-client - 2002e-11.s390 requires libssl.so.5
	libc-client - 2002e-11.s390 requires libcrypto.so.5
	ipsec-tools - 0.6.1-1.s390 requires libcrypto.so.5
	vorbis-tools - 1:1.0.1-6.s390 requires libcrypto.so.5
	vorbis-tools - 1:1.0.1-6.s390 requires libssl.so.5
	kdebase - 6:3.4.92-1.s390 requires libssl.so.5
	kdebase - 6:3.4.92-1.s390 requires libcrypto.so.5
	ghostscript - 8.15.1-1.s390 requires libcrypto.so.5
	ghostscript - 8.15.1-1.s390 requires libssl.so.5
	xchat - 1:2.4.5-1.s390 requires libcrypto.so.5
	xchat - 1:2.4.5-1.s390 requires libssl.so.5
	libwvstreams - 3.75.0-5.s390 requires libssl.so.5
	libwvstreams - 3.75.0-5.s390 requires libcrypto.so.5
	rdesktop - 1.4.1-1.fc5.s390 requires libcrypto.so.5
	postgresql-contrib - 8.1.0-1.s390 requires libcrypto.so.5
	postgresql-contrib - 8.1.0-1.s390 requires libssl.so.5
	pam_ccreds - 1-7.s390 requires libcrypto.so.5
	lynx - 2.8.5-24.s390 requires libcrypto.so.5
	lynx - 2.8.5-24.s390 requires libssl.so.5
	libgnomeprint22 - 2.12.1-2.s390 requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.s390 requires libssl.so.5
	postgresql-libs - 8.1.0-1.s390 requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.s390 requires libssl.so.5
	tn5250 - 0.16.5-6.s390 requires libcrypto.so.5
	tn5250 - 0.16.5-6.s390 requires libssl.so.5
	kdelibs - 6:3.4.92-2.s390 requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.s390 requires libssl.so.5
	squid - 7:2.5.STABLE11-6.s390 requires libcrypto.so.5
	squid - 7:2.5.STABLE11-6.s390 requires libssl.so.5
	gkrellm - 2.2.7-3.s390 requires libcrypto.so.5
	gkrellm - 2.2.7-3.s390 requires libssl.so.5
	gimp-print-cups - 4.2.7-12.s390 requires libcrypto.so.5
	gimp-print-cups - 4.2.7-12.s390 requires libssl.so.5
	net-snmp-utils - 5.2.2-0.rc4.1.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libssl.so.5
	openldap - 2.2.29-2.s390 requires libcrypto.so.5
	openldap - 2.2.29-2.s390 requires libssl.so.5
	ntp - 4.2.0.a.20050816-9.s390 requires libcrypto.so.5
	fetchmail - 6.2.5.2-1.s390 requires libssl.so.5
	fetchmail - 6.2.5.2-1.s390 requires libcrypto.so.5
	freeradius-mysql - 1.0.4-3.s390 requires libcrypto.so.5
	freeradius-mysql - 1.0.4-3.s390 requires libssl.so.5
	mutt - 5:1.4.2.1-5.s390 requires libssl.so.5
	mutt - 5:1.4.2.1-5.s390 requires libcrypto.so.5
	postgresql - 8.1.0-1.s390 requires libcrypto.so.5
	postgresql - 8.1.0-1.s390 requires libssl.so.5
	mysql - 4.1.14-1.s390 requires libcrypto.so.5
	mysql - 4.1.14-1.s390 requires libssl.so.5
	openssh-server - 4.2p1-5.s390 requires libcrypto.so.5
	freeradius-unixODBC - 1.0.4-3.s390 requires libcrypto.so.5
	freeradius-unixODBC - 1.0.4-3.s390 requires libssl.so.5
	mod_authz_ldap - 0.26-3.s390 requires libcrypto.so.5
	mod_authz_ldap - 0.26-3.s390 requires libssl.so.5
	php-mysql - 5.0.5-5.s390 requires libcrypto.so.5
	php-mysql - 5.0.5-5.s390 requires libssl.so.5
	spamassassin - 3.1.0-1.fc5.s390 requires libssl.so.5
	spamassassin - 3.1.0-1.fc5.s390 requires libcrypto.so.5
	net-snmp-perl - 5.2.2-0.rc4.1.s390 requires libcrypto.so.5
	OpenIPMI - 1.4.14-11.s390 requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.s390 requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.s390 requires libssl.so.5
	php-snmp - 5.0.5-5.s390 requires libcrypto.so.5
	ethereal - 0.10.13-3.s390 requires libcrypto.so.5
	kdenetwork - 7:3.4.92-1.s390 requires libssl.so.5
	kdenetwork - 7:3.4.92-1.s390 requires libcrypto.so.5
	slrn-pull - 0.9.8.1-5.s390 requires libcrypto.so.5
	slrn-pull - 0.9.8.1-5.s390 requires libssl.so.5
	kdesdk - 3.4.92-1.s390 requires libcrypto.so.5
	kdesdk - 3.4.92-1.s390 requires libssl.so.5
	mysql-server - 4.1.14-1.s390 requires libcrypto.so.5
	mysql-server - 4.1.14-1.s390 requires libssl.so.5
	netatalk - 4:2.0.3-3.s390 requires libcrypto.so.5
	netatalk - 4:2.0.3-3.s390 requires libssl.so.5



Broken deps for s390x
----------------------------------------------------------
	httpd - 2.0.54-15.s390x requires libssl.so.5()(64bit)
	httpd - 2.0.54-15.s390x requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.s390x requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.s390x requires libcrypto.so.5()(64bit)
	openssh-server - 4.2p1-5.s390x requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	gtksourceview - 1.4.2-1.s390 requires libcairo.so.2
	gwenhywfar-devel - 1.7.2-2.s390x requires libssl.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.s390x requires libcrypto.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.s390x requires libssl.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.s390x requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.s390 requires libcrypto.so.5
	openldap - 2.2.29-2.s390 requires libssl.so.5
	subversion - 1.2.3-3.s390x requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.s390x requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.s390x requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.s390x requires libcrypto.so.5()(64bit)
	gtk2 - 2.8.6-6.s390 requires libcairo.so.2
	pyOpenSSL - 0.6-1.p24.6.s390x requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.s390x requires libcrypto.so.5()(64bit)
	kdebase - 6:3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdebase - 6:3.4.92-1.s390x requires libcrypto.so.5()(64bit)
	gkrellm - 2.2.7-3.s390x requires libssl.so.5()(64bit)
	gkrellm - 2.2.7-3.s390x requires libcrypto.so.5()(64bit)
	ImageMagick - 6.2.5.4-1.s390 requires libgs.so.8
	openCryptoki - 2.1.6-1.s390x requires libcrypto.so.5()(64bit)
	pam_ccreds - 1-7.s390 requires libcrypto.so.5
	pango - 1.10.1-5.s390 requires libcairo.so.2
	vte - 0.11.15-1.fc5.s390 requires libcairo.so.2
	openssh-clients - 4.2p1-5.s390x requires libcrypto.so.5()(64bit)
	libwnck - 2.12.1-1.s390 requires libcairo.so.2
	GConf2 - 2.12.1-1.s390 requires libcairo.so.2
	gnome-vfs2 - 2.12.1.1-4.s390x requires libssl.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.s390x requires libcrypto.so.5()(64bit)
	libgnomeprintui22 - 2.12.1-1.s390 requires libcairo.so.2
	OpenIPMI - 1.4.14-11.s390x requires libcrypto.so.5()(64bit)
	libgnomecups - 0.2.2-1.s390 requires libssl.so.5
	libgnomecups - 0.2.2-1.s390 requires libcrypto.so.5
	net-snmp-libs - 5.2.2-0.rc4.1.s390 requires libcrypto.so.5
	ghostscript - 8.15.1-1.s390x requires libssl.so.5()(64bit)
	ghostscript - 8.15.1-1.s390x requires libcrypto.so.5()(64bit)
	mysql - 4.1.14-1.s390 requires libcrypto.so.5
	mysql - 4.1.14-1.s390 requires libssl.so.5
	postgresql-contrib - 8.1.0-1.s390x requires libssl.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.s390x requires libcrypto.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.s390 requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.s390 requires libssl.so.5
	vsftpd - 2.0.3-11.s390x requires libssl.so.5()(64bit)
	vsftpd - 2.0.3-11.s390x requires libcrypto.so.5()(64bit)
	MySQL-python - 1.2.0-2.s390x requires libssl.so.5()(64bit)
	MySQL-python - 1.2.0-2.s390x requires libcrypto.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.s390x requires libssl.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.s390x requires libcrypto.so.5()(64bit)
	postgresql-devel - 8.1.0-1.s390x requires libssl.so.5()(64bit)
	postgresql-devel - 8.1.0-1.s390x requires libcrypto.so.5()(64bit)
	gnome-keyring - 0.4.5-1.s390 requires libcairo.so.2
	sendmail - 8.13.5-1.s390x requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.s390x requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.s390x requires libssl.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.s390x requires libcrypto.so.5()(64bit)
	openhpi - 2.0.3-4.s390x requires libssl.so.5()(64bit)
	openhpi - 2.0.3-4.s390x requires libcrypto.so.5()(64bit)
	libwvstreams - 3.75.0-5.s390x requires libssl.so.5()(64bit)
	libwvstreams - 3.75.0-5.s390x requires libcrypto.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.s390x requires libssl.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.s390x requires libcrypto.so.5()(64bit)
	libc-client - 2002e-11.s390 requires libssl.so.5
	libc-client - 2002e-11.s390 requires libcrypto.so.5
	kdebase - 6:3.4.92-1.s390 requires libdbus-qt-1.so.1
	kdebase - 6:3.4.92-1.s390 requires libssl.so.5
	kdebase - 6:3.4.92-1.s390 requires libcrypto.so.5
	postgresql-server - 8.1.0-1.s390x requires libssl.so.5()(64bit)
	postgresql-server - 8.1.0-1.s390x requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.s390x requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.s390x requires libssl.so.5()(64bit)
	openCryptoki - 2.1.6-1.s390 requires libcrypto.so.5
	mod_ssl - 1:2.0.54-15.s390x requires libssl.so.5()(64bit)
	mod_ssl - 1:2.0.54-15.s390x requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.s390x requires libcrypto.so.5()(64bit)
	gtk2-engines - 2.6.5-1.s390 requires libcairo.so.2
	freeradius - 1.0.4-3.s390x requires libssl.so.5()(64bit)
	freeradius - 1.0.4-3.s390x requires libcrypto.so.5()(64bit)
	mutt - 5:1.4.2.1-5.s390x requires libssl.so.5()(64bit)
	mutt - 5:1.4.2.1-5.s390x requires libcrypto.so.5()(64bit)
	postgresql - 8.1.0-1.s390x requires libssl.so.5()(64bit)
	postgresql - 8.1.0-1.s390x requires libcrypto.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.s390 requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.s390 requires libssl.so.5
	slrn - 0.9.8.1-5.s390x requires libssl.so.5()(64bit)
	slrn - 0.9.8.1-5.s390x requires libcrypto.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.s390x requires libssl.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.s390x requires libcrypto.so.5()(64bit)
	python - 2.4.1-14.s390x requires libssl.so.5()(64bit)
	python - 2.4.1-14.s390x requires libcrypto.so.5()(64bit)
	elinks - 0.10.6-1.s390x requires libssl.so.5()(64bit)
	elinks - 0.10.6-1.s390x requires libcrypto.so.5()(64bit)
	ipsec-tools - 0.6.1-1.s390x requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.s390x requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.s390x requires libcrypto.so.5()(64bit)
	postgresql-libs - 8.1.0-1.s390x requires libssl.so.5()(64bit)
	postgresql-libs - 8.1.0-1.s390x requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libssl.so.5
	ruby-libs - 1.8.4-0.2.preview1.s390 requires libcrypto.so.5
	ruby-libs - 1.8.4-0.2.preview1.s390 requires libssl.so.5
	libc-client - 2002e-11.s390x requires libssl.so.5()(64bit)
	libc-client - 2002e-11.s390x requires libcrypto.so.5()(64bit)
	elfutils - 0.116-1.s390 requires libdw.so.1(ELFUTILS_0.116)
	elfutils - 0.116-1.s390 requires libdw.so.1
	postgresql-libs - 8.1.0-1.s390 requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.s390 requires libssl.so.5
	gimp-print-cups - 4.2.7-12.s390x requires libssl.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.s390x requires libcrypto.so.5()(64bit)
	lynx - 2.8.5-24.s390x requires libssl.so.5()(64bit)
	lynx - 2.8.5-24.s390x requires libcrypto.so.5()(64bit)
	gtk-engines - 1:0.12-7.s390 requires libgdk_imlib.so.1
	php-mysql - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	mysql - 4.1.14-1.s390x requires libssl.so.5()(64bit)
	mysql - 4.1.14-1.s390x requires libcrypto.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.s390x requires libssl.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.s390x requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.s390x requires libcrypto.so.5()(64bit)
	openssh - 4.2p1-5.s390x requires libcrypto.so.5()(64bit)
	xchat - 1:2.4.5-1.s390x requires libssl.so.5()(64bit)
	xchat - 1:2.4.5-1.s390x requires libcrypto.so.5()(64bit)
	libgnomecups - 0.2.2-1.s390x requires libssl.so.5()(64bit)
	libgnomecups - 0.2.2-1.s390x requires libcrypto.so.5()(64bit)
	OpenIPMI-tools - 1.4.14-11.s390x requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.s390x requires libssl.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.s390x requires libcrypto.so.5()(64bit)
	libglade2 - 2.5.1-3.s390 requires libcairo.so.2
	vorbis-tools - 1:1.0.1-6.s390x requires libssl.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.s390x requires libcrypto.so.5()(64bit)
	ethereal - 0.10.13-3.s390x requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.s390x requires libssl.so.5()(64bit)
	wget - 1.10.2-2.s390x requires libcrypto.so.5()(64bit)
	ethereal-gnome - 0.10.13-3.s390x requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.s390x requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.s390x requires libcrypto.so.5()(64bit)
	nmap - 2:3.93-1.s390x requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.s390x requires libcrypto.so.5()(64bit)
	stunnel - 4.14-1.s390x requires libssl.so.5()(64bit)
	stunnel - 4.14-1.s390x requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.s390 requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.s390 requires libssl.so.5
	tog-pegasus - 2:2.5-2.s390x requires libssl.so.5()(64bit)
	tog-pegasus - 2:2.5-2.s390x requires libcrypto.so.5()(64bit)
	w3m - 0.5.1-10.s390x requires libssl.so.5()(64bit)
	w3m - 0.5.1-10.s390x requires libcrypto.so.5()(64bit)
	mod_authz_ldap - 0.26-3.s390x requires libssl.so.5()(64bit)
	mod_authz_ldap - 0.26-3.s390x requires libcrypto.so.5()(64bit)
	netatalk - 4:2.0.3-3.s390x requires libssl.so.5()(64bit)
	netatalk - 4:2.0.3-3.s390x requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.s390x requires libcrypto.so.5()(64bit)
	php-snmp - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.s390x requires libssl.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.s390x requires libcrypto.so.5()(64bit)
	libwvstreams - 3.75.0-5.s390 requires libssl.so.5
	libwvstreams - 3.75.0-5.s390 requires libcrypto.so.5
	samba - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	gwenhywfar - 1.7.2-2.s390x requires libssl.so.5()(64bit)
	gwenhywfar - 1.7.2-2.s390x requires libcrypto.so.5()(64bit)
	libgnomecanvas - 2.12.0-1.s390 requires libcairo.so.2
	samba-swat - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	pam_ccreds - 1-7.s390x requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	gftp - 1:2.0.18-2.s390x requires libssl.so.5()(64bit)
	gftp - 1:2.0.18-2.s390x requires libcrypto.so.5()(64bit)
	kdeutils - 6:3.4.92-3.s390x requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.s390x requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.s390x requires libssl.so.5()(64bit)
	ntp - 4.2.0.a.20050816-9.s390x requires libcrypto.so.5()(64bit)
	net-snmp-perl - 5.2.2-0.rc4.1.s390x requires libcrypto.so.5()(64bit)
	postfix - 2:2.2.5-1.s390x requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.s390x requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap-servers - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	gail - 1.8.5-1.s390 requires libcairo.so.2
	fetchmail - 6.2.5.2-1.s390x requires libssl.so.5()(64bit)
	fetchmail - 6.2.5.2-1.s390x requires libcrypto.so.5()(64bit)
	m2crypto - 0.15-1.s390x requires libssl.so.5()(64bit)
	m2crypto - 0.15-1.s390x requires libcrypto.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.s390x requires libssl.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.s390x requires libcrypto.so.5()(64bit)
	net-snmp-utils - 5.2.2-0.rc4.1.s390x requires libcrypto.so.5()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	slrn-pull - 0.9.8.1-5.x86_64 requires libssl.so.5()(64bit)
	slrn-pull - 0.9.8.1-5.x86_64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.i386 requires libcrypto.so.5
	kdelibs - 6:3.4.92-2.i386 requires libssl.so.5
	MySQL-python - 1.2.0-2.x86_64 requires libssl.so.5()(64bit)
	MySQL-python - 1.2.0-2.x86_64 requires libcrypto.so.5()(64bit)
	php-snmp - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-he_IL - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-lt_LT - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	kdebase - 6:3.4.92-1.i386 requires libdbus-qt-1.so.1
	kdebase - 6:3.4.92-1.i386 requires libssl.so.5
	kdebase - 6:3.4.92-1.i386 requires libcrypto.so.5
	php-mysql - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	tog-pegasus - 2:2.5-2.x86_64 requires libcrypto.so.5()(64bit)
	tog-pegasus - 2:2.5-2.x86_64 requires libssl.so.5()(64bit)
	ethereal - 0.10.13-3.x86_64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.x86_64 requires libcrypto.so.5()(64bit)
	kdelibs - 6:3.4.92-2.x86_64 requires libssl.so.5()(64bit)
	hplip - 0.9.6-5.x86_64 requires libcrypto.so.5()(64bit)
	glibc-debuginfo - 2.3.90-15.i686 requires glibc-debuginfo-common = 0:2.3.90-15
	openoffice.org-langpack-pa_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	ethereal-gnome - 0.10.13-3.x86_64 requires libcrypto.so.5()(64bit)
	vsftpd - 2.0.3-11.x86_64 requires libssl.so.5()(64bit)
	vsftpd - 2.0.3-11.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-eu_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	OpenIPMI-tools - 1.4.14-11.x86_64 requires libcrypto.so.5()(64bit)
	gtk-engines - 1:0.12-7.i386 requires libgdk_imlib.so.1
	mod_ssl - 1:2.0.54-15.x86_64 requires libssl.so.5()(64bit)
	mod_ssl - 1:2.0.54-15.x86_64 requires libcrypto.so.5()(64bit)
	postgresql - 8.1.0-1.x86_64 requires libssl.so.5()(64bit)
	postgresql - 8.1.0-1.x86_64 requires libcrypto.so.5()(64bit)
	freeradius - 1.0.4-3.x86_64 requires libssl.so.5()(64bit)
	freeradius - 1.0.4-3.x86_64 requires libcrypto.so.5()(64bit)
	w3m - 0.5.1-10.x86_64 requires libssl.so.5()(64bit)
	w3m - 0.5.1-10.x86_64 requires libcrypto.so.5()(64bit)
	vte - 0.11.15-1.fc5.i386 requires libcairo.so.2
	openoffice.org-langpack-gu_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	samba-swat - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.x86_64 requires libssl.so.5()(64bit)
	gnome-vfs2 - 2.12.1.1-4.x86_64 requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.i386 requires libcrypto.so.5
	ruby-libs - 1.8.4-0.2.preview1.i386 requires libssl.so.5
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	vorbis-tools - 1:1.0.1-6.x86_64 requires libssl.so.5()(64bit)
	vorbis-tools - 1:1.0.1-6.x86_64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.x86_64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.x86_64 requires libcrypto.so.5()(64bit)
	kdeutils - 6:3.4.92-3.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-javafilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	lynx - 2.8.5-24.x86_64 requires libssl.so.5()(64bit)
	lynx - 2.8.5-24.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-pl_PL - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-ca_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	perl-DBD-MySQL - 3.0002-1.x86_64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-af_ZA - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-fr - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gtk2-engines - 2.6.5-1.i386 requires libcairo.so.2
	openssh - 4.2p1-5.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-es - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	postgresql-libs - 8.1.0-1.i386 requires libcrypto.so.5
	postgresql-libs - 8.1.0-1.i386 requires libssl.so.5
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libvos3gcc3.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libj680li_g.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-testtools - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	magma - 1.0.2-1.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagmamsg.so()(64bit)
	openoffice.org-langpack-tr_TR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-nn_NO - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libwvstreams - 3.75.0-5.x86_64 requires libssl.so.5()(64bit)
	libwvstreams - 3.75.0-5.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-da_DK - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-fi_FI - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	httpd - 2.0.54-15.x86_64 requires libssl.so.5()(64bit)
	httpd - 2.0.54-15.x86_64 requires libcrypto.so.5()(64bit)
	elfutils - 0.116-1.i386 requires libdw.so.1(ELFUTILS_0.116)
	elfutils - 0.116-1.i386 requires libdw.so.1
	subversion - 1.2.3-3.x86_64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.x86_64 requires libcrypto.so.5()(64bit)
	openssh-clients - 4.2p1-5.x86_64 requires libcrypto.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.x86_64 requires libssl.so.5()(64bit)
	gimp-print-cups - 4.2.7-12.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libgo680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3(UDK_3.1)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-graphicfilter - 1:2.0.0-3.7.2.i386 requires libjvmaccessgcc3.so.3(UDK_3_0_0)
	ipsec-tools - 0.6.1-1.x86_64 requires libcrypto.so.5()(64bit)
	nmap - 2:3.93-1.x86_64 requires libssl.so.5()(64bit)
	nmap - 2:3.93-1.x86_64 requires libcrypto.so.5()(64bit)
	fetchmail - 6.2.5.2-1.x86_64 requires libssl.so.5()(64bit)
	fetchmail - 6.2.5.2-1.x86_64 requires libcrypto.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.i386 requires libcrypto.so.5
	xmlsec1-openssl - 1.2.9-1.i386 requires libssl.so.5
	elinks - 0.10.6-1.x86_64 requires libssl.so.5()(64bit)
	elinks - 0.10.6-1.x86_64 requires libcrypto.so.5()(64bit)
	libwvstreams - 3.75.0-5.i386 requires libssl.so.5
	libwvstreams - 3.75.0-5.i386 requires libcrypto.so.5
	kdenetwork - 7:3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.x86_64 requires libssl.so.5()(64bit)
	libgnomeprint22 - 2.12.1-2.x86_64 requires libcrypto.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.x86_64 requires libssl.so.5()(64bit)
	ruby-libs - 1.8.4-0.2.preview1.x86_64 requires libcrypto.so.5()(64bit)
	ghostscript - 8.15.1-1.x86_64 requires libssl.so.5()(64bit)
	ghostscript - 8.15.1-1.x86_64 requires libcrypto.so.5()(64bit)
	libgnomecups - 0.2.2-1.i386 requires libssl.so.5
	libgnomecups - 0.2.2-1.i386 requires libcrypto.so.5
	pam_ccreds - 1-7.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-ru - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	postgresql-devel - 8.1.0-1.x86_64 requires libssl.so.5()(64bit)
	postgresql-devel - 8.1.0-1.x86_64 requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-th_TH - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	perl-RPM2 - 0.66-9.x86_64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libsd680li.so
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-impress - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	sendmail - 8.13.5-1.x86_64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.x86_64 requires libssl.so.5()(64bit)
	openoffice.org-langpack-bg_BG - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libc-client - 2002e-11.x86_64 requires libssl.so.5()(64bit)
	libc-client - 2002e-11.x86_64 requires libcrypto.so.5()(64bit)
	libsane-hpaio - 0.9.6-5.x86_64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-cy_GB - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	mysql-server - 4.1.14-1.x86_64 requires libcrypto.so.5()(64bit)
	mysql-server - 4.1.14-1.x86_64 requires libssl.so.5()(64bit)
	gwenhywfar - 1.7.2-2.x86_64 requires libssl.so.5()(64bit)
	gwenhywfar - 1.7.2-2.x86_64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.x86_64 requires libcrypto.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.x86_64 requires libssl.so.5()(64bit)
	spamassassin - 3.1.0-1.fc5.x86_64 requires libcrypto.so.5()(64bit)
	xchat - 1:2.4.5-1.x86_64 requires libssl.so.5()(64bit)
	xchat - 1:2.4.5-1.x86_64 requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-draw - 1:2.0.0-3.7.2.i386 requires libsd680li.so
	openoffice.org-langpack-hu_HU - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	freeradius-unixODBC - 1.0.4-3.x86_64 requires libssl.so.5()(64bit)
	freeradius-unixODBC - 1.0.4-3.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-cs_CZ - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	python - 2.4.1-14.x86_64 requires libssl.so.5()(64bit)
	python - 2.4.1-14.x86_64 requires libcrypto.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.x86_64 requires libssl.so.5()(64bit)
	freeradius-mysql - 1.0.4-3.x86_64 requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libssl.so.5
	libc-client - 2002e-11.i386 requires libssl.so.5
	libc-client - 2002e-11.i386 requires libcrypto.so.5
	openoffice.org-langpack-nb_NO - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	postgresql-libs - 8.1.0-1.x86_64 requires libssl.so.5()(64bit)
	postgresql-libs - 8.1.0-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-hi_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	net-snmp-perl - 5.2.2-0.rc4.1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-ja_JP - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-ga_IE - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	libgnomecanvas - 2.12.0-1.i386 requires libcairo.so.2
	libgnomeprint22 - 2.12.1-2.i386 requires libcrypto.so.5
	libgnomeprint22 - 2.12.1-2.i386 requires libssl.so.5
	libwnck - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-langpack-ms_MY - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	glibc-debuginfo - 2.3.90-15.i386 requires glibc-debuginfo-common = 0:2.3.90-15
	net-snmp-utils - 5.2.2-0.rc4.1.x86_64 requires libcrypto.so.5()(64bit)
	nut - 2.0.2-3.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-et_EE - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-zh_TW - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-el_GR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-it - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	pam_ccreds - 1-7.i386 requires libcrypto.so.5
	stunnel - 4.14-1.x86_64 requires libssl.so.5()(64bit)
	stunnel - 4.14-1.x86_64 requires libcrypto.so.5()(64bit)
	mutt - 5:1.4.2.1-5.x86_64 requires libssl.so.5()(64bit)
	mutt - 5:1.4.2.1-5.x86_64 requires libcrypto.so.5()(64bit)
	kdebase - 6:3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdebase - 6:3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-pt_BR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-sv - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gail - 1.8.5-1.i386 requires libcairo.so.2
	openssh-server - 4.2p1-5.x86_64 requires libcrypto.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.x86_64 requires libssl.so.5()(64bit)
	net-snmp - 5.2.2-0.rc4.1.x86_64 requires libcrypto.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	libgnomecups - 0.2.2-1.x86_64 requires libssl.so.5()(64bit)
	libgnomecups - 0.2.2-1.x86_64 requires libcrypto.so.5()(64bit)
	m2crypto - 0.15-1.x86_64 requires libssl.so.5()(64bit)
	m2crypto - 0.15-1.x86_64 requires libcrypto.so.5()(64bit)
	gtk2 - 2.8.6-6.i386 requires libcairo.so.2
	libglade2 - 2.5.1-3.i386 requires libcairo.so.2
	gftp - 1:2.0.18-2.x86_64 requires libssl.so.5()(64bit)
	gftp - 1:2.0.18-2.x86_64 requires libcrypto.so.5()(64bit)
	net-snmp-libs - 5.2.2-0.rc4.1.i386 requires libcrypto.so.5
	postgresql-server - 8.1.0-1.x86_64 requires libssl.so.5()(64bit)
	postgresql-server - 8.1.0-1.x86_64 requires libcrypto.so.5()(64bit)
	GConf2 - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-langpack-ko_KR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gtksourceview - 1.4.2-1.i386 requires libcairo.so.2
	pango - 1.10.1-5.i386 requires libcairo.so.2
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	mod_authz_ldap - 0.26-3.x86_64 requires libssl.so.5()(64bit)
	mod_authz_ldap - 0.26-3.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-gl_ES - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	netatalk - 4:2.0.3-3.x86_64 requires libcrypto.so.5()(64bit)
	netatalk - 4:2.0.3-3.x86_64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.i386 requires libcrypto.so.5
	openldap - 2.2.29-2.i386 requires libssl.so.5
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	tn5250 - 0.16.5-6.x86_64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.x86_64 requires libcrypto.so.5()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gwenhywfar-devel - 1.7.2-2.x86_64 requires libssl.so.5()(64bit)
	gwenhywfar-devel - 1.7.2-2.x86_64 requires libcrypto.so.5()(64bit)
	gkrellm - 2.2.7-3.x86_64 requires libcrypto.so.5()(64bit)
	gkrellm - 2.2.7-3.x86_64 requires libssl.so.5()(64bit)
	openoffice.org-langpack-zu_ZA - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-pt_PT - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	ntp - 4.2.0.a.20050816-9.x86_64 requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.x86_64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.x86_64 requires libcrypto.so.5()(64bit)
	openhpi - 2.0.3-4.x86_64 requires libcrypto.so.5()(64bit)
	openhpi - 2.0.3-4.x86_64 requires libssl.so.5()(64bit)
	openoffice.org-langpack-nl - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	slrn - 0.9.8.1-5.x86_64 requires libssl.so.5()(64bit)
	slrn - 0.9.8.1-5.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-zh_CN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.1)
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-math - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	mysql - 4.1.14-1.x86_64 requires libssl.so.5()(64bit)
	mysql - 4.1.14-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-ar - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-sk_SK - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	xmlsec1-openssl - 1.2.9-1.x86_64 requires libssl.so.5()(64bit)
	xmlsec1-openssl - 1.2.9-1.x86_64 requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	libgnomeprintui22 - 2.12.1-1.i386 requires libcairo.so.2
	openoffice.org-langpack-bn_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-base - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	ImageMagick - 6.2.5.4-1.i386 requires libgs.so.8
	subversion-javahl - 1.2.3-3.x86_64 requires libssl.so.5()(64bit)
	subversion-javahl - 1.2.3-3.x86_64 requires libcrypto.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	openoffice.org-langpack-sl_SI - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-langpack-de - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	postgresql-contrib - 8.1.0-1.x86_64 requires libssl.so.5()(64bit)
	postgresql-contrib - 8.1.0-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-langpack-hr_HR - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	gnome-keyring - 0.4.5-1.i386 requires libcairo.so.2
	postfix - 2:2.2.5-1.x86_64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libwpd-0.8.so.8
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsw680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-writer - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_xo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libtl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvt680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_ofa680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libxo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libso680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires liblegacy_binfilters680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libutl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libbf_svx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsoffice.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libcomphelp4gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppuhelpergcc3.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires liblegacy_binfilters680li.so(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.1)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libtk680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libgo680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsfx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libucbhelper3gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libavmedia680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libfile680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3_0_0)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvx680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libdbtools680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsb680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsvl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libvos3gcc3.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libvcl680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libsot680li.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libstlport_gcc.so
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_sal.so.3(UDK_3.3)
	openoffice.org-calc - 1:2.0.0-3.7.2.i386 requires libuno_cppu.so.3(UDK_3.1)
	openoffice.org-langpack-ta_IN - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2
	squid - 7:2.5.STABLE11-6.x86_64 requires libssl.so.5()(64bit)
	squid - 7:2.5.STABLE11-6.x86_64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.x86_64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.x86_64 requires libcrypto.so.5()(64bit)
	mysql - 4.1.14-1.i386 requires libcrypto.so.5
	mysql - 4.1.14-1.i386 requires libssl.so.5
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	OpenIPMI - 1.4.14-11.x86_64 requires libcrypto.so.5()(64bit)
	openoffice.org-xsltfilter - 1:2.0.0-3.7.2.i386 requires openoffice.org-core = 1:2.0.0-3.7.2





From buildsys at redhat.com  Thu Nov 10 13:29:00 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 10 Nov 2005 08:29:00 -0500
Subject: rawhide report: 20051110 changes
Message-ID: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>

New package librtas
	Libraries to provide access to RTAS calls and RTAS events.

New package mysqlclient14
	Backlevel MySQL shared libraries.


 
Updated Packages:

GFS-6.1.3-1.FC5
---------------
* Tue May 17 2005 Chris Feist <cfeist at redhat.com>
- Synced to upstream sources.

* Fri May 06 2005 Chris Feist <cfeist at redhat.com>
- Cleaned up .spec file and %files section.

* Thu May 05 2005 Chris Feist <cfeist at redhat.com>
- Added patch to disable starting up the init scripts.

GFS-kernel-2.6.14.0-20051108.134753.FC5.2
-----------------------------------------

MySQL-python-1.2.0-3
--------------------
* Wed Nov 09 2005 Tom Lane <tgl at redhat.com> 1.2.0-3
- Rebuild due to mysql 5.0 update and openssl library update.

OpenIPMI-1.4.14-13
------------------
* Wed Nov 09 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-13
- Rebuilt to link against latest openssl libs.
- Fixed ipmitool not setting session privilege level (#172312)

alsa-utils-1.0.10rc1-2
----------------------
* Wed Nov 09 2005 Martin Stransky <stransky at redhat.com> 1.0.10rc1-2
- fix for #169292 - RHEL4U2 xw4300 IntelHD internal speakers muted by default

anaconda-10.89.9-1
------------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 10.89.9-1
- Create interface earlier to prevent kickstart traceback (clumens)
- Logging fixes, everything should be in the logfile (clumens)
- Get rid of help which is irrelevant
- Clean up loader log levels

anthy-7100b-2
-------------
* Thu Nov 10 2005 Akira TAGOH <tagoh at redhat.com> - 7100b-2
- run ldconfig in %post and %postun. (#172768)

audit-1.1-1
-----------

bash-3.0-36
-----------
* Wed Nov 09 2005 Tim Waugh <twaugh at redhat.com> 3.0-36
- Added Url: tag (bug #172770).
- Do not explicitly gzip info pages (bug #172770).
- Fix permissions on bashbug (bug #172770).

bitmap-fonts-0.3-5
------------------
* Tue Nov 09 2004 Caolan McNamara <caolanm at redhat.com> - 0.3-5
- build fixfont .pcfs from source .bdfs

carol-0:1.8.9.3-1jpp_6fc
------------------------
* Thu Nov 10 2005 Archit Shah <ashah at redhat.com> 0:1.8.9.3-1jpp_6fc
- Reduce bz133180 patch to a patch that removes iiop rmic.

ccs-1.0.2-3
-----------
* Wed Jul 06 2005 Karsten Hopp <karsten at redhat.de> 0.25-0.18
- BuildRequires libxml2-devel for xml2-config and libxml/parser.h

checkpolicy-1.27.17-7
---------------------
* Tue Nov 08 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-7
- Rebuild to get latest libsepol

* Tue Oct 25 2005 Dan Walsh <dwalsh at redhat.com> 1.27.17-1
- Latest upgrade from NSA
	* Merged dismod fix from Joshua Brindle.

* Thu Oct 20 2005 Dan Walsh <dwalsh at redhat.com> 1.27.16-1
- Latest upgrade from NSA
	* Removed obsolete cond_check_type_rules() function and call and 
	  cond_optimize_lists() call from checkpolicy.c; these are handled
	  during parsing and expansion now.
	* Updated calls to expand_module for interface change.
	* Changed checkmodule to verify that expand_module succeeds 
	  when building base modules.
	* Merged module compiler fixes from Joshua Brindle.
	* Removed direct calls to hierarchy_check_constraints() and 
	  check_assertions() from checkpolicy since they are now called 
	  internally by expand_module().

chkconfig-1.3.22-1
------------------
* Wed Nov 09 2005 Bill Nottingham <notting at redhat.com>
- fix doSetService call in frobOneDependencies

cman-1.0.3-5.FC5
----------------
* Tue Jul 05 2005 Chris Feist <cfeist at redhat.com>
- Added libraries and cman-devel package

* Tue May 17 2005 Chris Feist <cfeist at redhat.com>
- Require cman-kernel-modules.

* Thu May 05 2005 Chris Feist <cfeist at redhat.com>
- Added patch to disable starting up the init scripts.

dlm-1.0.0-7.FC5
---------------
* Tue May 17 2005 Chris Feist <cfeist at redhat.com>
- Requires dlm-kernel-modules.

* Sun May 08 2005 Florian La Roche <laroche at redhat.com>
- fix -devel requires

* Fri May 06 2005 Chris Feist <cfeist at redhat.com>
- Cleaned up .spec file.

e2fsprogs-1.38-2
----------------
* Wed Nov 09 2005 Thomas Woerner <twoerner at redhat.com> 1.38-2
- splitted up libs from main package, into a new e2fsprogs-libs package
- fixed requires and prereqs

ethereal-0.10.13-4
------------------
* Wed Nov 09 2005 Radek Vokal <rvokal at redhat.com> 0.10.13-4
- grab new source
- rebuilt against new openssl

fence-1.32.7-2.FC5
------------------

fetchmail-6.2.5.2-2
-------------------
* Wed Nov 09 2005 Miloslav Trmac <mitr at redhat.com> - 6.2.5.2-2
- Rebuild with new openssl
- Ship README.SSL, drop html documentation copies

fontconfig-2.3.92-2
-------------------
* Wed Nov 09 2005 Carl Worth <cworth at redhat.com> - 2.3.92-2
- Remove inadvertent rejection of Luxi Mono from 40-blacklist-fonts.conf.
  Fixes #172437

gcc-4.0.2-4
-----------
* Wed Nov 09 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.2-4
- update from SVN (-r105083:106678)
  - PRs ada/21937, ada/22328, ada/22381, ada/22383, ada/22418, ada/22419,
	ada/22420, bootstrap/18939, c++/17796, c++/17964, c++/19253,
	c++/19964, c++/19989, c++/20721, c++/21089, c++/21117, c++/21347,
	c++/21353, c++/21369, c++/21383, c++/21592, c++/21627, c++/21908,
	c++/22147, c++/22153, c++/22180, c++/22293, c++/22352, c++/22405,
	c++/22434, c++/22464, c++/22551, c++/22603, c++/22604, c++/22618,
	c++/23118, c++/23229, c++/23293, c++/23307, c++/23426, c++/23437,
	c++/23440, c++/23694, c++/23730, c++/23797, c++/23959, c++/23984,
	c++/24052, c++/24139, c++/24260, c++/24275, c++/24277, c++/24302,
	c++/24386, c++/24389, c++/24560, c++/24569, c++/24582, c/23103,
	c/24101, c/24329, c/24599, driver/22544, driver/24473, fortran/14994,
	fortran/15975, fortran/16404, fortran/17737, fortran/18022,
	fortran/18082, fortran/18157, fortran/18452, fortran/18737,
	fortran/19929, fortran/20786, fortran/20835, fortran/20837,
	fortran/20838, fortran/20840, fortran/20847, fortran/20849,
	fortran/20853, fortran/20856, fortran/20866, fortran/20890,
	fortran/20899, fortran/20900, fortran/20901, fortran/20902,
	fortran/21459, fortran/21565, fortran/21625, fortran/22273,
	fortran/22290, fortran/23446, fortran/23635, fortran/23843,
	fortran/24092, fortran/24158, fortran/24207, fortran/24245,
	fortran/24416, fortran/24426, fortran/24440, fortran/24534,
	fortran/24545, fortran/24636, java/13788, java/20993, java/21540,
	java/23617, java/23620, java/24251, libfortran/22298, libgcj/14358,
	libgcj/23763, libgcj/24552, libstdc++/13583, libstdc++/18174,
	libstdc++/23953, libstdc++/24244, libstdc++/24450, libstdc++/24559,
	libstdc++/24595, middle-end/23155, middle-end/23199,
	middle-end/23522, middle-end/24135, middle-end/24362,
	preprocessor/15220, preprocessor/21250, preprocessor/22042,
	preprocessor/24202, rtl-opt/23324, rtl-optimization/23567,
	rtl-optimization/23585, rtl-optimization/24683, target/19340,
	target/19672, target/21518, target/22432, target/23644, target/24178,
	target/24284, target/24315, target/24428, target/24465, treelang/23072
- fix multiple_reg_loc_descriptor on i?86 (#172652)
- fix __thread on C++ class static members (PR c++/19450)

ghostscript-8.15.1-3
--------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 8.15.1-3
- Build does not explicitly require xorg-x11-devel.

* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 8.15.1-2
- rebuilt with new openssl

gimp-print-4.2.7-13
-------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 4.2.7-13
- rebuilt with new openssl

gkrellm-2.2.7-4
---------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 2.2.7-4
- rebuilt with new openssl

gnbd-1.0.1-2
------------
* Tue May 17 2005 Chris Feist <cfeist at redhat.com>
- Require cman-kernel-modules.

* Fri May 06 2005 Chris Feist <cfeist at redhat.com>
- Cleanup .spec file, don't glob /usr/share/man.

* Mon Dec 20 2004 Chris Feist <cfeist at redhat.com>
- Rebuild with new sources.

gnome-python2-2.12.1-1
----------------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> - 2.12.1-1
- Update to 2.12.1

* Thu Aug 18 2005 John (J5) Palmieri <johnp at redhat.com> - 2.11.3-2
- Bump and rebuild for cairo ABI change

* Mon Jul 18 2005 John (J5) Palmieri <johnp at redhat.com> - 2.11.3
- update to upstream 2.11.3

gnome-python2-extras-2.12.1-6
-----------------------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> - 2.12.1-6
- Don't delete the mozembed docs

* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> - 2.12.1-5
- Try this again

* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> - 2.12.1-4
- Remove ifarch directives around mozembed since it is now built on
  ppc64. Bump release again and retag

gnome-vfs2-2.12.1.1-5
---------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 2.12.1.1-5
- rebuilt with new openssl

gulm-1.0.4-2.FC5
----------------

gwenhywfar-1.7.2-3
------------------

hplip-0.9.6-6
-------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 0.9.6-6
- rebuilt against new openssl

httpd-2.0.54-16
---------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 2.0.54-16
- rebuilt against new openssl

iddev-2.0.0-4.FC5
-----------------

iproute-2.6.14-8
----------------
* Thu Nov 10 2005 Radek Vokal <rvokal at redhat.com> 2.6.14-8
- new upstream source

ipsec-tools-0.6.1-2
-------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 0.6.1-2
- rebuilt against new openssl

kdebase-6:3.4.92-4
------------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 6:3.4.92-4 
- rebuilt against new openssl

* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 6:3.4.92-3
- rebuilt against new openssl

* Mon Oct 24 2005 Than Ngo <than at redhat.com> 6:3.4.92-2
- add separate PAM configuration for kscreensaver #66902

kdelibs-6:3.4.92-3
------------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 6:3.4.92-3 
- rebuilt against new libcrypto, libssl
- requires iceauth

kdeutils-6:3.4.92-4
-------------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 6:3.4.92-4 
- rebuilt against new openssl

* Thu Nov 03 2005 Than Ngo <than at redhat.com> 6:3.4.92-3 
- rebuilt against new net-snmp

* Fri Oct 28 2005 Than Ngo <than at redhat.com> 6:3.4.92-2
- apply patch to initialize correctly the variables

kernel-2.6.14-1.1657_FC5
------------------------
* Wed Nov 09 2005 Dave Jones <davej at redhat.com>
- 2.6.14-git12

kernel-xen-2.6.12-1.13_FC5
--------------------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> 
- disable the tls warning (which isn't relevant with the nosegneg glibc)

* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com>
- Provide: kernel-drm
- Run new-kernel-pkg on guest kernel install
- resync to current, has my modular driver fixes
- also resync hypervisor to current mercurial snapshot

* Tue Nov 08 2005 Jeremy Katz <katzj at redhat.com>
- change netfront driver to be modular so that anaconda can find netdev
- resync to current mercurial snapshot for various fixes
- add my patches so that xennet and xenblk can be built as modules

kudzu-1.2.11-1
--------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 1.2.11-1
- fix xen driver names

libao-0.8.6-1
-------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> 0.8.6-1
- update to 0.8.6

libc-client-2002e-12
--------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 2002e-12
- rebuilt against new openssl

libgnomecups-0.2.2-2
--------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 0.2.2-2
- rebuilt against new openssl

libgnomeprint22-2.12.1-3
------------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 2.12.1-3
- rebuilt against new openssl

libsemanage-1.3.52-1
--------------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.3.52-1
- Upgrade to latest from NSA
	* Merged cleanup patch from Ivan Gyurdiev.
	  This renames semanage_module_conn to semanage_direct_handle,
	  and moves sepol handle create/destroy into semanage handle
	  create/destroy to allow use even when disconnected (for the
	  record interfaces).

libsepol-1.9.39-1
-----------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.9.39-1
- Upgrade to latest from NSA
	Prepare for removal of booleans* and *.users files.
	* Cleaned up sepol_genbools to not regenerate the image if
	  there were no changes in the boolean values, including the
	  degenerate case where there are no booleans or booleans.local
	  files.
	* Cleaned up sepol_genusers to not warn on missing local.users.

libtheora-0:1.0alpha5-1
-----------------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhar.com> - 1.0alpha5-1
- Update to 1.0alpha5

libvorbis-1:1.1.1-1
-------------------
* Wed Mar 02 2005 John (J5) Palmieri <johnp at redhat.com> 1:1.1.1-1
- Update to 1.1.1

libwvstreams-3.75.0-6
---------------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 3.75.0-6
- rebuilt against new openssl
- the gcc4 patch shouldn't be used anymore

lucene-0:1.4.3-1jpp_6fc
-----------------------
* Tue Nov 08 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:1.4.3-1jpp_6fc
- Converted the spec file from ISO-8859-1 to UTF-8

* Mon Oct 31 2005 Andrew Overholt <overholt at redhat.com> 1.4.3-1jpp_6fc
- Bump release.

* Thu Oct 27 2005 Andrew Overholt <overholt at redhat.com> 1.4.3-1jpp_5fc
- Remove ExclusiveArch.
- Use aot-compile-rpm.
- Remove now-unnecessary patches.

lynx-2.8.5-26
-------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 2.8.5-26
- rebuilt against new openssl

* Wed Nov 09 2005 Tim Waugh <twaugh at redhat.com> 2.8.5-25
- Rebuild for new openssl.

m2crypto-0.15-2
---------------
* Wed Nov 09 2005 Miloslav Trmac <mitr at redhat.com> - 0.15-2
- Rebuild with newer openssl

magma-plugins-1.0.3-1.FC5
-------------------------

man-pages-2.13-1
----------------
* Thu Nov 10 2005 Ivana Varekova <varekova at redhat.com> 2.13-1
- update to 2.13

* Mon Oct 10 2005 Ivana Varekova <varekova at redhat.com> 2.08-1
- update to 2.08

* Thu Sep 29 2005 Ivana Varekova <varekova at redhat.com> 2.07-7
- fix typo in nsswitch.conf man page (bug 169309)

mikmod-3.1.6-36
---------------
* Wed Nov 09 2005 Martin Stransky <stransky at redhat.com> 3.1.6-36
- remove .la file (#172620)

mod_authz_ldap-0.26-4
---------------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 0.26-4
- rebuilt against new openssl

mutt-5:1.4.2.1-6
----------------
* Wed Nov 09 2005 Bill Nottingham <notting at redhat.com> 5:1.4.2.1-6
- rebuild against new ssl libs

mysql-5.0.15-2
--------------
* Wed Nov 09 2005 Tom Lane <tgl at redhat.com> 5.0.15-2
- Rebuild due to openssl library update.

* Thu Nov 03 2005 Tom Lane <tgl at redhat.com> 5.0.15-1
- Update to MySQL 5.0.15 (scratch build for now)

netatalk-4:2.0.3-4
------------------
* Wed Nov 09 2005 Jason Vas Dias <jvdias at redhat.com>
- Rebuild for new openssl dependencies

nmap-2:3.93-2
-------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> - 2:3.93-2
- rebuilt against new openssl

ntp-4.2.0.a.20050816-10
-----------------------
* Wed Nov 09 2005 Petr Raszyk <praszyk at redhat.com> 4.2.0.a.20050816-10
- ntpd does not submit his local clock (if there is no peer).
  ntpdate->ntpd #163862 , Patch13: ntp-stable-4.2.0a-20050816-loconly.patch

nut-2.0.2-4
-----------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 2.0.2-4
- rebuilt

openCryptoki-2.1.6-2
--------------------
* Wed Nov 09 2005 Phil Knirsch <pknirsch at redhat.com> 2.1.6-rc2.2
- Rebuilt to link against latest openssl lib

openhpi-2.0.3-5
---------------
* Wed Nov 09 2005 Phil Knirsch <pknirsch at redhat.com> 2.0.3-5
- Rebuilt to link against latest openssl lib.

openoffice.org-1:2.0.1-0.138.3.2
--------------------------------
* Tue Nov 08 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.138.3
- fix problem with icu rule searching with null locale

* Fri Nov 04 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.138.1
- drop integrated openoffice.org-1.9.74.ooo41875.mktemp.patch
- drop integrated openoffice.org-1.9.89.ooo35627.parallel.cppumaker.patch
- drop integrated openoffice.org-1.9.97.ooo48610.searchalltemplates.wizards.patch
- drop integrated openoffice.org-1.9.106.ooo50172.icu.tamilvowelslikepango.patch
- drop integrated workspace.vcl39.patch
	- CACHE_MAGIC of rh2 changed back to default 2. No broken caches of "2" 
        should exist to cause ambiguity
- drop integrated openoffice.org-1.9.108.ooo48814.solenv.nostripwithsimpleinstall.patch
- drop integrated openoffice.org-1.9.122.ooo52626.workspacerestore.vcl.patch
- drop integrated workspace.impress57.patch
- drop integrated workspace.gslpatches6.patch
- drop integrated workspace.emblock1.patch
- drop integrated workspace.cmcfixes18.patch
- drop integrated workspace.cmcfixes19.patch
- add workspace.systemlibxmlfix.patch
- additional hungarian help

* Fri Oct 28 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.0-3.8
- ooo#53397# SEGV signal installation needs to be extended to include 
  custom application launcher names
- reenable faster helpcontent2 building

openssh-4.2p1-6
---------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 4.2p1-6
- rebuild against new openssl

pam_ccreds-1-8
--------------
* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> - 1-8
- rebuilt against new openssl

parted-1.6.25-1
---------------
* Wed Nov 09 2005 Chris Lumens <clumens at redhat.com> 1.6.25-1
- Updated to 1.6.25.
- Update DASD, iseries, and SX8 patches.

policycoreutils-1.27.27-1
-------------------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.27.27-1
- Update to match NSA
	* Merged setsebool cleanup patch from Ivan Gyurdiev.

* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.27.26-4
- Fix genhomedircon to use seusers file, temporary fix until swigified semanage

postgresql-8.1.0-3
------------------
* Wed Nov 09 2005 Tom Lane <tgl at redhat.com> 8.1.0-3
- Rebuild due to openssl library update.

* Wed Nov 09 2005 Tom Lane <tgl at redhat.com> 8.1.0-2
- Rebuild due to openssl library update.

* Mon Nov 07 2005 Tom Lane <tgl at redhat.com> 8.1.0-1
- Update to PostgreSQL 8.1.0, PyGreSQL 3.7, and jdbc driver build 404
- Fix PAM config file (must have account not only auth) (bug #167040)
- Add BuildPrereq: libxslt-devel (bug #170141)
- Sync with PGDG SRPM as much as feasible

pyparted-1.6.9-5
----------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 1.6.9-5
- rebuild for new parted

python-2.4.1-16
---------------
* Wed Nov 09 2005 Mihai Ibanescu <misa at redhat.com> 2.4.1-16
- Rebuilding against newer openssl.
- XFree86-devel no longer exists

* Mon Sep 26 2005 Peter Jones <pjones at redhat.com> 2.4.1-14
- Once more -- this time, to fix -EPERM when you run it in a directory
  you can't read from.

* Mon Sep 26 2005 Peter Jones <pjones at redhat.com> 2.4.1-13
- So, 5 or 6 people have said it works for them with this patch...

qt-1:3.3.5-9
------------
* Tue Nov 08 2005 Than Ngo <than at redhat.com> 1:3.3.5-9 
- fix for modular X

rgmanager-1.9.40-3.FC5
----------------------

ruby-1.8.4-0.3.preview1
-----------------------
* Thu Nov 10 2005 Akira TAGOH <tagoh at redhat.com> - 1.8.4-0.3.preview1
- rebuilt against the latest openssl.

selinux-policy-mls-1.27.2-19
----------------------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-19
- Add /dev/xvd
- Add disable trans for init_core apps
- Allow unconfined_t to rpm_script_t process transition

selinux-policy-strict-1.27.2-19
-------------------------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-19
- Add /dev/xvd
- Add disable trans for init_core apps
- Allow unconfined_t to rpm_script_t process transition

selinux-policy-targeted-1.27.2-19
---------------------------------
* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.27.2-19
- Add /dev/xvd
- Add disable trans for init_core apps
- Allow unconfined_t to rpm_script_t process transition

slrn-0.9.8.1-6
--------------
* Wed Nov 09 2005 Jindrich Novy <jnovy at redhat.com> 0.9.8.1-6
- rebuild to fix broken dependencies to libssl and libcrypto

spamassassin-3.1.0-2.fc5
------------------------
* Tue Nov 08 2005 Warren Togami <wtogami at redhat.com> - 3.1.0-2
- #161785 ensure that service restart works

speex-1.0.5-1
-------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> -1.0.5-1
- Update to 1.0.5

squid-7:2.5.STABLE12-1
----------------------
* Wed Nov 09 2005 Martin Stransky <stransky at redhat.com> 7:2.5.STABLE12-1
- update to STABLE12
- setenv patch

stunnel-4.14-2
--------------
* Wed Nov 09 2005 Miloslav Trmac <mitr at redhat.com> - 4.14-2
- Rebuild with newer openssl

sysreport-1.4.2-4
-----------------
* Mon Nov 07 2005 Than Ngo <than at redhat.com> 1.4.2-4
- collect current registers and flags (sysrq-p) #170845 
- collect list of current tasks and their information (sysrq-t) #170845

* Tue Oct 04 2005 Than Ngo <than at redhat.com> 1.4.2-3
- collect /etc/cluster #168353
- collect /etc/securetty #169800 
- omit collecting device nodes #159428
- add -help option #165621

system-config-date-1.7.99.4-1
-----------------------------
* Wed Nov 09 2005 Nils Philippsen <nphilipp at redhat.com> 1.7.99.4
- implement simple timezone zooming

tcpdump-14:3.9.3-4
------------------
* Wed Nov 09 2005 Martin Stransky <stransky at redhat.com> - 14:3.9.3-4
- rebuilt

tetex-3.0-9
-----------
* Wed Nov 09 2005 Jindrich Novy <jnovy at redhat.com> 3.0-9
- always cleanup temporary directories for texconfig, updmap and fmtutil
  scripts - Michal Jaegermann (#172534)
- remove .la files (#172619)

tog-pegasus-2:2.5-3
-------------------
* Wed Nov 09 2005 Jason Vas Dias <jvdias at redhat.com> - 2:tog-pegasus-2.5-3
- Rebuild for new openssl dependencies
- Enable CMPI support for sblim-cmpi-base with ENABLE_CQL=true

* Mon Oct 31 2005 Jason Vas Dias <jvdias at redhat.com> - 2:tog-pegasus-2.5-2
- Add /usr/lib/cmpi alternate providerLibDir for sblim-cmpi-base Fedora Extras pkg
- Fix bug 171124: use numeric ids for pegasus user/group
- guidelines: do not remove pegasus user/group in %postun.

* Fri Oct 14 2005 Tomas Mraz <tmraz at redhat.com>
- use include instead of pam_stack in pam config

vorbis-tools-1:1.1.1-1
----------------------
* Wed Nov 09 2005 John (J5) Palmieri <johnp at redhat.com> 1:1.1.1-1
- Update to version 1.1.1

w3m-0.5.1-12
------------
* Wed Nov 09 2005 Akira TAGOH <tagoh at redhat.com> 0.5.1-12
- rebuilt against the latest openssl.
- gc6.2-fix-prelink.patch: removed.
- w3m-fix-vi-prec-num.patch: applied to get the vi-like prefix working.

* Tue May 10 2005 Joe Orton <jorton at redhat.com> 0.5.1-11
- point at certs directory in /etc/pki

xchat-1:2.4.5-2
---------------
* Wed Nov 09 2005 Christopher Aillon <caillon at redhat.com> 1:2.4.5-2
- Rebuild against newer openssl

xen-3.0-0.20051109.fc5.1
------------------------
* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 3.0-0.20051109.fc5.1
- udev rules moved

* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 3.0-0.20051109.fc5
- update to current -unstable
- add patches to fix pygrub

* Wed Nov 09 2005 Jeremy Katz <katzj at redhat.com> - 3.0-0.20051108.fc5
- update to current -unstable

xmlsec1-1.2.9-2
---------------
* Wed Nov 09 2005 <veillard at redhat.com> 1.2.9-2
- rebuilt due to openssl library revision

xpdf-1:3.01-5
-------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 3.01-5
- add correct Simplified/Traditional Chinese fonts #170989

yum-2.4.0-11
------------
* Wed Nov 09 2005 Paul Nasrat <pnasrat at redhat.com> - 2.4.0-11
- Expose location base from metadata


Broken deps for i386
----------------------------------------------------------
	php-snmp - 5.0.5-5.i386 requires libcrypto.so.5
	postfix - 2:2.2.5-1.i386 requires libcrypto.so.5
	postfix - 2:2.2.5-1.i386 requires libssl.so.5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	samba - 3.0.20-2.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libcrypto.so.5
	tcpdump - 14:3.9.3-4.i386 requires libcrypto.so.5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	slrn - 0.9.8.1-6.i386 requires libssl.so.5
	slrn - 0.9.8.1-6.i386 requires libcrypto.so.5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	sendmail - 8.13.5-1.i386 requires libcrypto.so.5
	sendmail - 8.13.5-1.i386 requires libssl.so.5
	subversion-javahl - 1.2.3-3.i386 requires libcrypto.so.5
	subversion-javahl - 1.2.3-3.i386 requires libssl.so.5
	php - 5.0.5-5.i386 requires libcrypto.so.5
	php - 5.0.5-5.i386 requires libssl.so.5
	rdesktop - 1.4.1-1.fc5.i386 requires libcrypto.so.5
	php-mysql - 5.0.5-5.i386 requires libcrypto.so.5
	php-mysql - 5.0.5-5.i386 requires libssl.so.5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	perl-DBD-MySQL - 3.0002-1.i386 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.i386 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.i386 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.i386 requires libssl.so.5
	slrn-pull - 0.9.8.1-6.i386 requires libcrypto.so.5
	slrn-pull - 0.9.8.1-6.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libcrypto.so.5
	openldap-servers - 2.2.29-2.i386 requires libssl.so.5
	openldap-servers - 2.2.29-2.i386 requires libcrypto.so.5
	kdenetwork - 7:3.4.92-1.i386 requires libssl.so.5
	kdenetwork - 7:3.4.92-1.i386 requires libcrypto.so.5
	kdesdk - 3.4.92-1.i386 requires libcrypto.so.5
	kdesdk - 3.4.92-1.i386 requires libssl.so.5
	openldap - 2.2.29-2.i386 requires libcrypto.so.5
	openldap - 2.2.29-2.i386 requires libssl.so.5
	subversion - 1.2.3-3.i386 requires libcrypto.so.5
	subversion - 1.2.3-3.i386 requires libssl.so.5
	php-imap - 5.0.5-5.i386 requires libcrypto.so.5
	php-imap - 5.0.5-5.i386 requires libssl.so.5
	wget - 1.10.2-2.i386 requires libcrypto.so.5
	wget - 1.10.2-2.i386 requires libssl.so.5
	perl-Crypt-SSLeay - 0.51-8.i386 requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.i386 requires libssl.so.5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	magma - 1.0.2-1.i386 requires libmagmamsg.so
	magma - 1.0.2-1.i386 requires libmagma.so
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libssl.so.5
	tn5250 - 0.16.5-6.i386 requires libcrypto.so.5
	tn5250 - 0.16.5-6.i386 requires libssl.so.5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	perl-RPM2 - 0.66-9.i386 requires libcrypto.so.5
	perl-RPM2 - 0.66-9.i386 requires libssl.so.5
	pyOpenSSL - 0.6-1.p24.6.i386 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.i386 requires libssl.so.5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5



Broken deps for ppc
----------------------------------------------------------
	samba-swat - 3.0.20-2.ppc requires libssl.so.5
	samba-swat - 3.0.20-2.ppc requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.ppc requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.ppc requires libssl.so.5
	perl-RPM2 - 0.66-9.ppc requires libcrypto.so.5
	perl-RPM2 - 0.66-9.ppc requires libssl.so.5
	perl-Crypt-SSLeay - 0.51-8.ppc requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.ppc requires libssl.so.5
	php - 5.0.5-5.ppc requires libcrypto.so.5
	php - 5.0.5-5.ppc requires libssl.so.5
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	openldap-servers - 2.2.29-2.ppc requires libssl.so.5
	openldap-servers - 2.2.29-2.ppc requires libcrypto.so.5
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	subversion - 1.2.3-3.ppc requires libcrypto.so.5
	subversion - 1.2.3-3.ppc requires libssl.so.5
	openldap - 2.2.29-2.ppc requires libcrypto.so.5
	openldap - 2.2.29-2.ppc requires libssl.so.5
	kdenetwork - 7:3.4.92-1.ppc requires libssl.so.5
	kdenetwork - 7:3.4.92-1.ppc requires libcrypto.so.5
	openldap-clients - 2.2.29-2.ppc requires libcrypto.so.5
	openldap-clients - 2.2.29-2.ppc requires libssl.so.5
	postfix - 2:2.2.5-1.ppc requires libcrypto.so.5
	postfix - 2:2.2.5-1.ppc requires libssl.so.5
	rdesktop - 1.4.1-1.fc5.ppc requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.ppc requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.ppc requires libssl.so.5
	magma - 1.0.2-1.ppc requires libmagmamsg.so
	magma - 1.0.2-1.ppc requires libmagma.so
	php-mysql - 5.0.5-5.ppc requires libcrypto.so.5
	php-mysql - 5.0.5-5.ppc requires libssl.so.5
	php-snmp - 5.0.5-5.ppc requires libcrypto.so.5
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	subversion-javahl - 1.2.3-3.ppc requires libcrypto.so.5
	subversion-javahl - 1.2.3-3.ppc requires libssl.so.5
	tn5250 - 0.16.5-6.ppc requires libcrypto.so.5
	tn5250 - 0.16.5-6.ppc requires libssl.so.5
	php-imap - 5.0.5-5.ppc requires libcrypto.so.5
	php-imap - 5.0.5-5.ppc requires libssl.so.5
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	kdesdk - 3.4.92-1.ppc requires libcrypto.so.5
	kdesdk - 3.4.92-1.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libcrypto.so.5
	sendmail - 8.13.5-1.ppc requires libcrypto.so.5
	sendmail - 8.13.5-1.ppc requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.ppc requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.ppc requires libcrypto.so.5
	wget - 1.10.2-2.ppc requires libcrypto.so.5
	wget - 1.10.2-2.ppc requires libssl.so.5



Broken deps for x86_64
----------------------------------------------------------
	perl-RPM2 - 0.66-9.x86_64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.x86_64 requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.x86_64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.x86_64 requires libcrypto.so.5()(64bit)
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	php-mysql - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.x86_64 requires libcrypto.so.5()(64bit)
	php-snmp - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.x86_64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.x86_64 requires libcrypto.so.5()(64bit)
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	kdenetwork - 7:3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	samba-swat - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.x86_64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.x86_64 requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	subversion-javahl - 1.2.3-3.x86_64 requires libssl.so.5()(64bit)
	subversion-javahl - 1.2.3-3.x86_64 requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.x86_64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.x86_64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.x86_64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.x86_64 requires libcrypto.so.5()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.i386 requires libssl.so.5
	postfix - 2:2.2.5-1.x86_64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.x86_64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagmamsg.so()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.x86_64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.x86_64 requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.i386 requires libcrypto.so.5
	openldap - 2.2.29-2.i386 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.x86_64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.x86_64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.x86_64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.x86_64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.x86_64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.x86_64 requires libcrypto.so.5()(64bit)



Broken deps for ia64
----------------------------------------------------------
	php-snmp - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ia64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ia64 requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ia64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ia64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ia64 requires libssl.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ia64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ia64 requires libssl.so.5()(64bit)
	sendmail - 8.13.5-1.ia64 requires libcrypto.so.5()(64bit)
	php-mysql - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.ia64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.ia64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.ia64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.ia64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.ia64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.ia64 requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.ia64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.ia64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.ia64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ia64 requires libmagmamsg.so()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ia64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ia64 requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ia64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.ia64 requires libcrypto.so.5()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	samba - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	postfix - 2:2.2.5-1.ia64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.ia64 requires libcrypto.so.5()(64bit)
	subversion - 1.2.3-3.ia64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.ia64 requires libcrypto.so.5()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	postfix - 2:2.2.5-1.ppc64 requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.ppc64 requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ppc64 requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.ppc64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.ppc64 requires libcrypto.so.5()(64bit)
	php-imap - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ppc64 requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.ppc64 requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap-servers - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.ppc64 requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.ppc64 requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.ppc64 requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.ppc64 requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.ppc64 requires libssl.so.5()(64bit)
	wget - 1.10.2-2.ppc64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	openldap - 2.2.29-2.ppc64 requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.ppc64 requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ppc64 requires libssl.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.ppc64 requires libcrypto.so.5()(64bit)
	subversion - 1.2.3-3.ppc64 requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.ppc64 requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagmamsg.so()(64bit)
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	php-snmp - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ppc64 requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.ppc64 requires libcrypto.so.5()(64bit)
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	php-mysql - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	php - 5.0.5-5.ppc64 requires libssl.so.5()(64bit)
	php - 5.0.5-5.ppc64 requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ppc64 requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.ppc64 requires libcrypto.so.5()(64bit)



Broken deps for s390x
----------------------------------------------------------
	php - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.s390x requires libssl.so.5()(64bit)
	perl-Crypt-SSLeay - 0.51-8.s390x requires libcrypto.so.5()(64bit)
	openldap-servers - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap-servers - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	wget - 1.10.2-2.s390x requires libssl.so.5()(64bit)
	wget - 1.10.2-2.s390x requires libcrypto.so.5()(64bit)
	perl-RPM2 - 0.66-9.s390x requires libssl.so.5()(64bit)
	perl-RPM2 - 0.66-9.s390x requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	postfix - 2:2.2.5-1.s390x requires libssl.so.5()(64bit)
	postfix - 2:2.2.5-1.s390x requires libcrypto.so.5()(64bit)
	subversion - 1.2.3-3.s390x requires libssl.so.5()(64bit)
	subversion - 1.2.3-3.s390x requires libcrypto.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.s390x requires libssl.so.5()(64bit)
	perl-DBD-MySQL - 3.0002-1.s390x requires libcrypto.so.5()(64bit)
	tn5250 - 0.16.5-6.s390x requires libssl.so.5()(64bit)
	tn5250 - 0.16.5-6.s390x requires libcrypto.so.5()(64bit)
	rdesktop - 1.4.1-1.fc5.s390x requires libcrypto.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdenetwork - 7:3.4.92-1.s390x requires libcrypto.so.5()(64bit)
	openldap - 2.2.29-2.s390 requires libcrypto.so.5
	openldap - 2.2.29-2.s390 requires libssl.so.5
	php-imap - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php-imap - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.s390x requires libssl.so.5()(64bit)
	pyOpenSSL - 0.6-1.p24.6.s390x requires libcrypto.so.5()(64bit)
	php-mysql - 5.0.5-5.s390x requires libssl.so.5()(64bit)
	php-mysql - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	openldap-clients - 2.2.29-2.s390x requires libssl.so.5()(64bit)
	openldap-clients - 2.2.29-2.s390x requires libcrypto.so.5()(64bit)
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libssl.so.5
	php-snmp - 5.0.5-5.s390x requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.s390x requires libcrypto.so.5()(64bit)
	sendmail - 8.13.5-1.s390x requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.s390x requires libcrypto.so.5()(64bit)



Broken deps for s390
----------------------------------------------------------
	php-snmp - 5.0.5-5.s390 requires libcrypto.so.5
	kdesdk - 3.4.92-1.s390 requires libcrypto.so.5
	kdesdk - 3.4.92-1.s390 requires libssl.so.5
	perl-Crypt-SSLeay - 0.51-8.s390 requires libcrypto.so.5
	perl-Crypt-SSLeay - 0.51-8.s390 requires libssl.so.5
	perl-RPM2 - 0.66-9.s390 requires libcrypto.so.5
	perl-RPM2 - 0.66-9.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libcrypto.so.5
	compat-openldap - 2.2.29_2.1.30-2.s390 requires libssl.so.5
	php - 5.0.5-5.s390 requires libcrypto.so.5
	php - 5.0.5-5.s390 requires libssl.so.5
	postfix - 2:2.2.5-1.s390 requires libcrypto.so.5
	postfix - 2:2.2.5-1.s390 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.s390 requires libssl.so.5
	perl-DBD-MySQL - 3.0002-1.s390 requires libcrypto.so.5
	tn5250 - 0.16.5-6.s390 requires libcrypto.so.5
	tn5250 - 0.16.5-6.s390 requires libssl.so.5
	wget - 1.10.2-2.s390 requires libcrypto.so.5
	wget - 1.10.2-2.s390 requires libssl.so.5
	openldap-clients - 2.2.29-2.s390 requires libcrypto.so.5
	openldap-clients - 2.2.29-2.s390 requires libssl.so.5
	kdenetwork - 7:3.4.92-1.s390 requires libssl.so.5
	kdenetwork - 7:3.4.92-1.s390 requires libcrypto.so.5
	subversion - 1.2.3-3.s390 requires libcrypto.so.5
	subversion - 1.2.3-3.s390 requires libssl.so.5
	pyOpenSSL - 0.6-1.p24.6.s390 requires libcrypto.so.5
	pyOpenSSL - 0.6-1.p24.6.s390 requires libssl.so.5
	openldap-servers - 2.2.29-2.s390 requires libssl.so.5
	openldap-servers - 2.2.29-2.s390 requires libcrypto.so.5
	samba-swat - 3.0.20-2.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libcrypto.so.5
	openldap - 2.2.29-2.s390 requires libcrypto.so.5
	openldap - 2.2.29-2.s390 requires libssl.so.5
	sendmail - 8.13.5-1.s390 requires libcrypto.so.5
	sendmail - 8.13.5-1.s390 requires libssl.so.5
	php-imap - 5.0.5-5.s390 requires libcrypto.so.5
	php-imap - 5.0.5-5.s390 requires libssl.so.5
	rdesktop - 1.4.1-1.fc5.s390 requires libcrypto.so.5
	php-mysql - 5.0.5-5.s390 requires libcrypto.so.5
	php-mysql - 5.0.5-5.s390 requires libssl.so.5




From dravet at hotmail.com  Thu Nov 10 16:12:19 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Thu, 10 Nov 2005 10:12:19 -0600
Subject: yum crashes with traceback
Message-ID: <BAY103-F21394379F3014E34A4F031DF660@phx.gbl>

I updated to yum-2.4.0-11 and now if I do a yum update kernel I get the 
following:

Loading "installonlyn" plugin
Setting up Update Process
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.0 MB    00:03
developmen: ################################################## 3838/3838
Added 552 new packages, deleted 518 old in 25.99 seconds
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package kernel-devel.i686 0:2.6.14-1.1657_FC5 set to be installed
---> Package kernel.i686 0:2.6.14-1.1657_FC5 set to be installed
--> Running transaction check
Traceback (most recent call last):
  File "/usr/bin/yum", line 27, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum-cli/yummain.py", line 133, in main
    (result, resultmsgs) = base.buildTransaction()
  File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 340, in 
buildTransaction
    self.plugins.run('postresolve', rescode=rescode, restring=restring)
  File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 159, in run
    func(conduitcls(self, self.base, conf, **kwargs))
  File "/usr/lib/yum-plugins/installonlyn.py", line 58, in postresolve_hook
    (curv, curr) = get_running_kernel_version_release()
  File "/usr/lib/yum-plugins/installonlyn.py", line 39, in 
get_running_kernel_version_release
    (v, r) = ver.split("-", 1)
ValueError: need more than 1 value to unpack

I know their a lot of broken dependencies in todays rawhide so I am only 
trying to update the kernel at this time.

Thanks,
Jason




From jspaleta at gmail.com  Thu Nov 10 16:20:39 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 10 Nov 2005 11:20:39 -0500
Subject: yum crashes with traceback
In-Reply-To: <BAY103-F21394379F3014E34A4F031DF660@phx.gbl>
References: <BAY103-F21394379F3014E34A4F031DF660@phx.gbl>
Message-ID: <604aa7910511100820l68e92861j3ef038c618f76dcd@mail.gmail.com>

On 11/10/05, Jason Dravet <dravet at hotmail.com> wrote:
> Loading "installonlyn" plugin
...
>   File "/usr/lib/yum-plugins/installonlyn.py", line 39, in
> get_running_kernel_version_release
>     (v, r) = ver.split("-", 1)
> ValueError: need more than 1 value to unpack

this looks like a problem with the new installonlyn plugin.

edit  /etc/yum/pluginconf.d/installonlyn.conf
change to enabled=0

try to do the yum update kernel again
if it succeeds.. file a bug against the rawhide yum package in
bugzilla with the traceback
and include the information from uname -a

-jef



From wtogami at redhat.com  Thu Nov 10 16:29:10 2005
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 10 Nov 2005 11:29:10 -0500
Subject: Help Needed: Upgrade IEEE1394 (Firewire) Libraries
Message-ID: <43737556.5000105@redhat.com>

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105

I don't have time to upgrade the Firewire related libraries and test 
them before the FC5test1 devel freeze.  If you care about these packages 
(and actually have hardwarew to test it), your assistance would be 
appreciated.  Please attach spec and source patches to this bug report.

Thanks,
Warren Togami
wtogami at redhat.com



From dravet at hotmail.com  Thu Nov 10 16:32:49 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Thu, 10 Nov 2005 10:32:49 -0600
Subject: yum crashes with traceback
Message-ID: <BAY103-F23D55BAD9470494D3F6D73DF660@phx.gbl>

>this looks like a problem with the new installonlyn plugin.
>
>edit  /etc/yum/pluginconf.d/installonlyn.conf
>change to enabled=0
>
>try to do the yum update kernel again
>if it succeeds.. file a bug against the rawhide yum package in
>bugzilla with the traceback
>and include the information from uname -a
>
>-jef

Your suggestion works great.  Thanks.  Here is the bugzilla entry: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172855

Thanks again,
Jason




From Axel.Thimm at ATrpms.net  Thu Nov 10 17:12:32 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Thu, 10 Nov 2005 18:12:32 +0100
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer
	exist very soon.
In-Reply-To: <4372A29C.3080809@redhat.com>
References: <4372A29C.3080809@redhat.com>
Message-ID: <20051110171232.GD8480@neu.nirvana>

On Wed, Nov 09, 2005 at 08:30:04PM -0500, Mike A. Harris wrote:
> This is another friendly reminder to all developers and package
> maintainers that "XFree86-devel" and "xorg-x11-devel" will no
> longer exist in Fedora Core 5.

> All packages which "BuildRequires: XFree86-devel" or
> "BuildRequires: xorg-x11-devel" must be updated to remove this
> dependency and replace it with individual BuildRequires for
> each library that is needed.
> 
> For example:
> 
> BuildRequires: libX11-devel
> BuildRequires: libXinerama-devel
> 
> etc..

Is there a list for the new *-devel packages? It would make it easier
to packagers to identify the missing BuildRequires, perhaps even by
trial-and-error :)

Will the modular xorg-x11 packages be built from one spec file (the
retrieving the *-devel is trivial) or several?
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051110/32c42dde/attachment.sig>

From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Thu Nov 10 18:37:10 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 10 Nov 2005 19:37:10 +0100
Subject: Help Needed: Upgrade IEEE1394 (Firewire) Libraries
In-Reply-To: <43737556.5000105@redhat.com>
References: <43737556.5000105@redhat.com>
Message-ID: <20051110193710.1d02d4ea@python2>

Warren Togami wrote :

> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172105
> 
> I don't have time to upgrade the Firewire related libraries and test 
> them before the FC5test1 devel freeze.  If you care about these packages 
> (and actually have hardwarew to test it), your assistance would be 
> appreciated.  Please attach spec and source patches to this bug report.

I've added everything I could possibly think of, I'm just finishing off the dvgrab 2.0 update, sneaking in my usual useless spec file cleanups along the way ;-)

As I wrote, I even have the hardware to test this (Sony DV camera), so throwing all of the updates into Rawhide should be enough to get me (and others) to test all of it. Last I tried with a default FC4 install, the /dev nodes weren't even properly created, so that kind of "full test" is what would be best (with Test1?).

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.13-1.1532_FC4
Load : 2.37 2.35 2.07



From avi at argo.co.il  Thu Nov 10 18:52:55 2005
From: avi at argo.co.il (Avi Kivity)
Date: Thu, 10 Nov 2005 20:52:55 +0200
Subject: rawhide report: 20051110 changes
In-Reply-To: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
Message-ID: <43739707.8020006@argo.co.il>

Build System wrote:

>- Rebuild due to mysql 5.0 update and openssl library update.
>
>  
>
we see rebuilds very often due to library updates. are they strictly 
necessary (i.e., do the libraries break binary compatbility so often?)

much of the advantages of shared libraries are lost this way. we have to 
update a ton of packages, and those which are forgotten (or locally 
built) break.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From rdieter at math.unl.edu  Thu Nov 10 19:36:21 2005
From: rdieter at math.unl.edu (Rex Dieter)
Date: Thu, 10 Nov 2005 13:36:21 -0600
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer  
 exist very soon.
In-Reply-To: <20051110171232.GD8480@neu.nirvana>
References: <4372A29C.3080809@redhat.com> <20051110171232.GD8480@neu.nirvana>
Message-ID: <dl07hf$c3a$1@sea.gmane.org>

Axel Thimm wrote:

> Will the modular xorg-x11 packages be built from one spec file (the
> retrieving the *-devel is trivial) or several?

Several/lots.

-- Rex



From tmus at tmus.dk  Thu Nov 10 20:01:45 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Thu, 10 Nov 2005 21:01:45 +0100
Subject: rawhide report: 20051110 changes
In-Reply-To: <43739707.8020006@argo.co.il>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
	<43739707.8020006@argo.co.il>
Message-ID: <dl08vb$gtp$1@sea.gmane.org>

Avi Kivity wrote:
> Build System wrote:
> 
>> - Rebuild due to mysql 5.0 update and openssl library update.
>>
>>  
>>
> we see rebuilds very often due to library updates. are they strictly 
> necessary (i.e., do the libraries break binary compatbility so often?)
> 
> much of the advantages of shared libraries are lost this way. we have to 
> update a ton of packages, and those which are forgotten (or locally 
> built) break.
> 

sometimes updating a shared library breaks the interface or possibly 
even adds new features that we want. In these cases rebuild is required. 
Most times, it's when updating to a new version of a lib, openssl 0.9.7 
- 0.9.8 which i believe is what has happened here. (haven't checked though)

/Thomas



From avi at argo.co.il  Thu Nov 10 20:35:28 2005
From: avi at argo.co.il (Avi Kivity)
Date: Thu, 10 Nov 2005 22:35:28 +0200
Subject: rawhide report: 20051110 changes
In-Reply-To: <dl08vb$gtp$1@sea.gmane.org>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>	<43739707.8020006@argo.co.il>
	<dl08vb$gtp$1@sea.gmane.org>
Message-ID: <4373AF10.7050605@argo.co.il>

Thomas M Steenholdt wrote:

> Avi Kivity wrote:
>
>> Build System wrote:
>>
>>> - Rebuild due to mysql 5.0 update and openssl library update.
>>>
>>>  
>>>
>> we see rebuilds very often due to library updates. are they strictly 
>> necessary (i.e., do the libraries break binary compatbility so often?)
>>
>> much of the advantages of shared libraries are lost this way. we have 
>> to update a ton of packages, and those which are forgotten (or 
>> locally built) break.
>>
>
> sometimes updating a shared library breaks the interface 

if the interface was broken. surly more than a rebuild would be 
required. the application using the library would need to be updated.

> or possibly even adds new features that we want. 

if we use the new feaures we need to update the code in the library's 
users. if we don't, why is a rebuild required?

> In these cases rebuild is required. Most times, it's when updating to 
> a new version of a lib, openssl 0.9.7 - 0.9.8 which i believe is what 
> has happened here. (haven't checked though)
>
seems a lot of churn for a minor release. library authors should care 
more. designing binary compatible capable interfaces is not that hard.

just consider what would happen if glibc didn't care about backward 
compatibility. every glibc update would require rebuilding and updating 
the entire distribution.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From tmraz at redhat.com  Thu Nov 10 20:42:47 2005
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 10 Nov 2005 21:42:47 +0100
Subject: rawhide report: 20051110 changes
In-Reply-To: <43739707.8020006@argo.co.il>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
	<43739707.8020006@argo.co.il>
Message-ID: <1131655367.3087.13.camel@perun.redhat.usu>

On Thu, 2005-11-10 at 20:52 +0200, Avi Kivity wrote:
> Build System wrote:
> 
> >- Rebuild due to mysql 5.0 update and openssl library update.
> >
> >  
> >
> we see rebuilds very often due to library updates. are they strictly 
> necessary (i.e., do the libraries break binary compatbility so often?)
The openssl doesn't keep ABI stable between versions (sometimes even
between the patch levels). So bumping the soname and rebuilding
dependencies was necessary. There is other problem that some of the
dependencies are not necessary (they are pulled only through pkgconfig).

-- 
Tomas Mraz <tmraz at redhat.com>



From tmraz at redhat.com  Thu Nov 10 20:50:00 2005
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 10 Nov 2005 21:50:00 +0100
Subject: rawhide report: 20051110 changes
In-Reply-To: <4373AF10.7050605@argo.co.il>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
	<43739707.8020006@argo.co.il> <dl08vb$gtp$1@sea.gmane.org>
	<4373AF10.7050605@argo.co.il>
Message-ID: <1131655800.3087.22.camel@perun.redhat.usu>

On Thu, 2005-11-10 at 22:35 +0200, Avi Kivity wrote:
> Thomas M Steenholdt wrote:
> 
> > Avi Kivity wrote:
> >
> >> Build System wrote:
> >>
> >>> - Rebuild due to mysql 5.0 update and openssl library update.
> >>>
> >>>  
> >>>
> >> we see rebuilds very often due to library updates. are they strictly 
> >> necessary (i.e., do the libraries break binary compatbility so often?)
> >>
> >> much of the advantages of shared libraries are lost this way. we have 
> >> to update a ton of packages, and those which are forgotten (or 
> >> locally built) break.
> >>
> >
> > sometimes updating a shared library breaks the interface 
> 
> if the interface was broken. surly more than a rebuild would be 
> required. the application using the library would need to be updated.
No, there is difference between breaking source code compatibility and binary
compatibility. For example in a new version of a library some #defined
macro names can be changed -> source code isn't compilable anymore, but
ABI isn't broken. OTOH when some member (which is optional and so
behaviour doesn't change if it isn't set) is added to a struct which is
allocated by the caller of the library API -> ABI is broken but source
code can be recompiled and no problem appears.

> > or possibly even adds new features that we want. 
> 
> if we use the new feaures we need to update the code in the library's 
> users. if we don't, why is a rebuild required?
> 
> > In these cases rebuild is required. Most times, it's when updating to 
> > a new version of a lib, openssl 0.9.7 - 0.9.8 which i believe is what 
> > has happened here. (haven't checked though)
> >
> seems a lot of churn for a minor release. library authors should care 
> more. designing binary compatible capable interfaces is not that hard.
Please report that to openssl upstream.

-- 
Tomas Mraz <tmraz at redhat.com>



From avi at argo.co.il  Thu Nov 10 20:53:32 2005
From: avi at argo.co.il (Avi Kivity)
Date: Thu, 10 Nov 2005 22:53:32 +0200
Subject: rawhide report: 20051110 changes
In-Reply-To: <1131655367.3087.13.camel@perun.redhat.usu>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>	<43739707.8020006@argo.co.il>
	<1131655367.3087.13.camel@perun.redhat.usu>
Message-ID: <4373B34C.6040706@argo.co.il>

Tomas Mraz wrote:

>On Thu, 2005-11-10 at 20:52 +0200, Avi Kivity wrote:
>  
>
>>Build System wrote:
>>
>>    
>>
>>>- Rebuild due to mysql 5.0 update and openssl library update.
>>>
>>> 
>>>
>>>      
>>>
>>we see rebuilds very often due to library updates. are they strictly 
>>necessary (i.e., do the libraries break binary compatbility so often?)
>>    
>>
>The openssl doesn't keep ABI stable between versions (sometimes even
>between the patch levels). So bumping the soname and rebuilding
>dependencies was necessary. 
>
okay.

>There is other problem that some of the
>dependencies are not necessary (they are pulled only through pkgconfig).
>  
>
aha. I guess this adds to the churn.

my question wasn't about openssl specifically (though it did generate a 
lot of rebuilds)

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From cmadams at hiwaay.net  Thu Nov 10 21:10:06 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 10 Nov 2005 15:10:06 -0600
Subject: rawhide report: 20051110 changes
In-Reply-To: <4373AF10.7050605@argo.co.il>
References: <200511101329.jAADT0gD010327@porkchop.devel.redhat.com>
	<43739707.8020006@argo.co.il> <dl08vb$gtp$1@sea.gmane.org>
	<4373AF10.7050605@argo.co.il>
Message-ID: <20051110211006.GC1009282@hiwaay.net>

Once upon a time, Avi Kivity <avi at argo.co.il> said:
> Thomas M Steenholdt wrote:
> >sometimes updating a shared library breaks the interface 
> 
> if the interface was broken. surly more than a rebuild would be 
> required. the application using the library would need to be updated.

API != ABI (like kernel modules).

> >or possibly even adds new features that we want. 
> 
> if we use the new feaures we need to update the code in the library's 
> users. if we don't, why is a rebuild required?

Some programs will have support for new library versions before Fedora
lands the new version (maybe the new library was in testing for a while
for example).  A rebuild will automatically pick up the new features and
use them.

> seems a lot of churn for a minor release. library authors should care 
> more. designing binary compatible capable interfaces is not that hard.

The OpenSSL project doesn't really support shared libraries or seem to
care about an ABI at all; every minor version (and some patch levels)
break the ABI.

-- 
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 katzj at redhat.com  Thu Nov 10 21:42:39 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 10 Nov 2005 16:42:39 -0500
Subject: yum crashes with traceback
In-Reply-To: <BAY103-F23D55BAD9470494D3F6D73DF660@phx.gbl>
References: <BAY103-F23D55BAD9470494D3F6D73DF660@phx.gbl>
Message-ID: <1131658960.18529.0.camel@bree.local.net>

On Thu, 2005-11-10 at 10:32 -0600, Jason Dravet wrote:
> >this looks like a problem with the new installonlyn plugin.
> >
> >edit  /etc/yum/pluginconf.d/installonlyn.conf
> >change to enabled=0
> >
> >try to do the yum update kernel again
> >if it succeeds.. file a bug against the rawhide yum package in
> >bugzilla with the traceback
> >and include the information from uname -a

> Your suggestion works great.  Thanks.  Here is the bugzilla entry: 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172855

Yep, simple stupid bug.  Fixed it and building a new package now.

Thanks

Jeremy



From lamont at gurulabs.com  Fri Nov 11 03:43:12 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Thu, 10 Nov 2005 20:43:12 -0700
Subject: python-numeric SRPM ??
Message-ID: <200511102043.16838.lamont@gurulabs.com>

All,

I can't seem to find the SRPM for python-numeric in the extras repository (I 
checked on download.fedora.redhat.com even).  Anyone know where that one is?
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051110/87cccfca/attachment.sig>

From lamont at gurulabs.com  Fri Nov 11 03:46:21 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Thu, 10 Nov 2005 20:46:21 -0700
Subject: python-numeric SRPM ??
In-Reply-To: <200511102043.16838.lamont@gurulabs.com>
References: <200511102043.16838.lamont@gurulabs.com>
Message-ID: <200511102046.25675.lamont@gurulabs.com>

On Thursday 10 November 2005 08:43pm, Lamont R. Peterson wrote:
> All,
>
> I can't seem to find the SRPM for python-numeric in the extras repository
> (I checked on download.fedora.redhat.com even).  Anyone know where that one
> is?

Oops...nevermind...it's in core not extras.  Sorry for the noise :( .
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051110/862d9d8a/attachment.sig>

From mharris at redhat.com  Fri Nov 11 05:47:02 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 11 Nov 2005 00:47:02 -0500
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer exist
 very soon.
In-Reply-To: <43731169.2000003@iee.lu>
References: <4372A29C.3080809@redhat.com> <43731169.2000003@iee.lu>
Message-ID: <43743056.60601@redhat.com>

Charles Lopes wrote:
> Would it be a bad idea to have an update for FC3 and FC4 of their 
> current xorg-x11-devel with additional provides (libX11-devel,
> libXinerama-devel)? This would make it easier to recompile FC5 SRPMs on 
> these older systems.

I plan on doing that in the next FC3/FC4 updates, but that will wait
until there is a good enough reason to do another FC3/FC4 update.  There
are a few bug fixes and driver updates that could potentially be a part
of that too.  Current priorities are aligned with getting modular X into
rawhide however, so an FC3/FC4 update isn't on the radar currently,
but it will happen at some point.



From mharris at redhat.com  Fri Nov 11 05:49:45 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 11 Nov 2005 00:49:45 -0500
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <1131616306.10039.43.camel@rousalka.dyndns.org>
References: <436E1D82.6040708@redhat.com>	<20051106155733.GA14817@jadzia.bu.edu>	<436E2F19.6030902@redhat.com>	<200511060849.00109.jbarnes@virtuousgeek.org>	<4372A6AA.70906@redhat.com>
	<1131616306.10039.43.camel@rousalka.dyndns.org>
Message-ID: <437430F9.5050507@redhat.com>

Nicolas Mailhot wrote:
> Le mercredi 09 novembre 2005 ? 20:47 -0500, Mike A. Harris a ?crit :
> 
> 
>>The "core fonts" system is for legacy X applications, in particular
>>applications that use the Xt, Xaw, and Motif toolkits, as well as other
>>legacy toolkits.
> 
> 
> And commercial JVMs.
> Making core font support optional would probably be enough for Sun to
> get a clue and port Java to fontconfig.

Things of this nature take a lot of time to transition.  While we
want that transition to happen, moving too fast can end up just
upsetting users and customers unreasonably, which would just make
Fedora and thus future RHEL releases less attractive to many
deployments.

Proper timing is key.



From mharris at redhat.com  Fri Nov 11 05:55:44 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 11 Nov 2005 00:55:44 -0500
Subject: ATTENTION: XFree86-devel and xorg-x11-devel will no longer	exist
 very soon.
In-Reply-To: <20051110171232.GD8480@neu.nirvana>
References: <4372A29C.3080809@redhat.com> <20051110171232.GD8480@neu.nirvana>
Message-ID: <43743260.4070506@redhat.com>

Axel Thimm wrote:
> On Wed, Nov 09, 2005 at 08:30:04PM -0500, Mike A. Harris wrote:
> 
>>This is another friendly reminder to all developers and package
>>maintainers that "XFree86-devel" and "xorg-x11-devel" will no
>>longer exist in Fedora Core 5.
> 
> 
>>All packages which "BuildRequires: XFree86-devel" or
>>"BuildRequires: xorg-x11-devel" must be updated to remove this
>>dependency and replace it with individual BuildRequires for
>>each library that is needed.
>>
>>For example:
>>
>>BuildRequires: libX11-devel
>>BuildRequires: libXinerama-devel
>>
>>etc..
> 
> 
> Is there a list for the new *-devel packages? It would make it easier
> to packagers to identify the missing BuildRequires, perhaps even by
> trial-and-error :)

Yep, please visit the FC5 X.Org modularization page at:

     http://mharris.ca/xorg-modular/xorg-modularization.html

It has hyperlinks to the ftp directory in which you can download
the src and binary rpms that have been built so far, as well as
links to 4 text files which document the order in which everything
needs to be built.  The xorg-all-libs.txt file contains a list of
all of the modular X library package names, of which each has a
-devel subpackage.

In general, if an application links to libXfoo, then you just need
to put "BuildRequires: libXfoo-devel" for each X library it uses.

The one exception, is the screensaver library.  It is the only
package out of 40 libraries, in which the name of the package and
the name of the library are not the same.  The library is libXss,
and the package name is libXScrnSaver.  Yes this is silly, but it
is how upstream X.Org decided to name things.



> Will the modular xorg-x11 packages be built from one spec file (the
> retrieving the *-devel is trivial) or several?

If it was all in one spec file, then it wouldn't be "modular".





From igorm5 at vip.hr  Fri Nov 11 08:03:38 2005
From: igorm5 at vip.hr (Igor Jagec)
Date: Fri, 11 Nov 2005 09:03:38 +0100
Subject: missing dependency on FC4 Rawhide
In-Reply-To: <437352E6.2070902@redhat.com>
References: <43732812.6010700@vip.hr>
	<1131623836.3728.4.camel@isz>	<437330C9.5040900@vip.hr>
	<437352E6.2070902@redhat.com>
Message-ID: <4374505A.7070002@vip.hr>

Rahul Sundaram wrote:

> Might want to check this package instead of symlinks
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172803

Thanks a lot, I download it and recompile it. But in the meantime the
Fedora developers fix the problem :)

-- 
Igor Jagec



From nicolas.mailhot at laposte.net  Fri Nov 11 11:27:57 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 11 Nov 2005 12:27:57 +0100
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <437430F9.5050507@redhat.com>
References: <436E1D82.6040708@redhat.com>
	<20051106155733.GA14817@jadzia.bu.edu>	<436E2F19.6030902@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>	<4372A6AA.70906@redhat.com>
	<1131616306.10039.43.camel@rousalka.dyndns.org>
	<437430F9.5050507@redhat.com>
Message-ID: <1131708477.3342.18.camel@rousalka.dyndns.org>

Le vendredi 11 novembre 2005 ? 00:49 -0500, Mike A. Harris a ?crit :
> Nicolas Mailhot wrote:
> > Le mercredi 09 novembre 2005 ? 20:47 -0500, Mike A. Harris a ?crit :
> > 
> > 
> >>The "core fonts" system is for legacy X applications, in particular
> >>applications that use the Xt, Xaw, and Motif toolkits, as well as other
> >>legacy toolkits.
> > 
> > 
> > And commercial JVMs.
> > Making core font support optional would probably be enough for Sun to
> > get a clue and port Java to fontconfig.
> 
> Things of this nature take a lot of time to transition.  While we
> want that transition to happen, moving too fast can end up just
> upsetting users and customers unreasonably, which would just make
> Fedora and thus future RHEL releases less attractive to many
> deployments.
> 
> Proper timing is key.

In this case there it's more vendor cluelessness than timing issues. I
doubt Sun will even look at fontconfig before lack of support breaks
jvms on some distros. And they're not alone. If you want the transition
to happen you have to break stuff in FC else some people won't ever look
at the problem and let you happily bear the burden of dual font system
till hell freezes over.

And note I didn't write "remove core font support" but "make it
optional" ie things will still work after installing the optional part.
Which will hopefully annoy enough people they start looking at
fontconfig support.

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/20051111/d9f9576c/attachment.sig>

From laroche at redhat.com  Fri Nov 11 12:26:40 2005
From: laroche at redhat.com (Florian La Roche)
Date: Fri, 11 Nov 2005 13:26:40 +0100
Subject: packages to remove from Fedora Extra 4
Message-ID: <20051111122640.GA5981@dudweiler.stuttgart.redhat.com>

The following rpms can be removed from Fedora Extra 4. Sometimes they
are obsoleted sub-rpms not anymore in newer packages, completely renamed
packages or similar stuff.

Warning: GiNaC-1.3.1-6.fc4.i386.rpm is obsoleted by ginac-1.3.3-1.fc4.i386.rpm
Warning: GiNaC-devel-1.3.1-6.fc4.i386.rpm is obsoleted by ginac-devel-1.3.3-1.fc4.i386.rpm
Warning: GiNaC-utils-1.3.1-6.fc4.i386.rpm is obsoleted by ginac-utils-1.3.3-1.fc4.i386.rpm
Warning: anthy-libs-6700-1.fc4.i386.rpm is obsoleted by anthy-7100b-1.fc4.i386.rpm
Warning: fillets-ng-data-cs-0.6.0-2.noarch.rpm is obsoleted by fillets-ng-data-0.7.1-1.noarch.rpm
Warning: nethack-falconseye-1.9.4-6.a.i386.rpm is obsoleted by nethack-3.4.3-3.fc4.i386.rpm
Warning: perl-Locale-gettext-1.05-3.fc4.i386.rpm is obsoleted by perl-gettext-1.05-7.fc4.i386.rpm
Warning: scribus-templates-1.2.1-2.noarch.rpm is obsoleted by scribus-1.2.2.1-2.fc4.i386.rpm
Warning: smeg-0.7.5-3.fc4.noarch.rpm is obsoleted by alacarte-0.8-1.fc4.noarch.rpm
Warning: python-reportlab-1.19-2.i386.rpm did not find a package for: python < 0:2.4

Above output comes from pyrpm available on http://people.redhat.com/laroche/pyrpm/ and the
following call:
./pyrpm.py --checkdeps --small --nodigest --nopayload --noverify --arch=i686 \
    /mirror/fedora/4/i386/os/Fedora/RPMS \
    /mirror/fedora/updates/4/i386 \
    /mirror/fedora-extras/4/i386

regards,

Florian La Roche



From buildsys at redhat.com  Fri Nov 11 13:16:30 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 11 Nov 2005 08:16:30 -0500
Subject: rawhide report: 20051111 changes
Message-ID: <200511111316.jABDGUus020223@porkchop.devel.redhat.com>

New package gnome-user-share
	Gnome user file sharing

New package mlocate
	An utility for finding files by name

New package python-pyblock
	Python modules for dealing with block devices


 
Updated Packages:

Guppi-0.40.3-24
---------------
* Thu Nov 10 2005 Nalin Dahyabhai <nalin at redhat.com> 0.40.3-24
- rebuild because gtk+-devel lost its .la files

anaconda-10.89.11-1
-------------------
* Thu Nov 10 2005 Jeremy Katz <katzj at redhat.com> - 10.89.11-1
- Fix stdout logging to print stuff (clumens)
- Start of some sorting/splitting stuff for CDs (pnasrat) 
- Make missing modules lower priority
- Look for xen devices
- Add some of the necessary requirements to try to get dogtail working (#172891)

* Thu Nov 10 2005 Chris Lumens <clumens at redhat.com> 10.89.10-1
- Add e2fsprogs-libs to the install images.

antlr-0:2.7.4-2jpp_3fc
----------------------
* Mon Nov 07 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:2.7.4-2jpp_3fc
- BZ 172456: Added /usr/lib/libantlr.a and /usr/include/antlr/*.hpp

cvs-1.11.21-1
-------------
* Thu Nov 10 2005 Martin Stransky <stransky at redhat.com> 1.11.21-1
- new upstream

dmraid-1.0.0.rc9-FC5_2
----------------------
* Thu Nov 10 2005 Peter Jones <pjones at redhat.com> 1.0.0.rc9-FC5_2
- update to 1.0.0.rc9
- make "make install" do the right thing with the DSO
- eliminate duplicate definitions in the headers
- export more symbols in the DSO
- add api calls to retrieve dm tables
- fix DESTDIR for 'make install' 
- add api calls to identify degraded devices
- remove several arch excludes

docbook-style-dsssl-1.79-2
--------------------------
* Thu Nov 10 2005 Tim Waugh <twaugh at redhat.com> 1.79-2
- Ship olink.dsl (bug #172523).

e2fsprogs-1.38-2.1
------------------
* Thu Nov 10 2005 Thomas Woerner <twoerner at redhat.com> 1.38-2.1
- fixed file conflicts between 32bit and 64bit packages (#168815)
- fixed mklost+found crashes with buffer overflow (#157773)
  Thanks to Arjan van de Ven for the patch

ethereal-0.10.13-5
------------------
* Fri Nov 11 2005 Radek Vokal <rvokal at redhat.com> 0.10.13-5
- rebuilt against new lipcap

fedora-logos-1.1.33-1
---------------------
* Thu Nov 10 2005 John (J5) Palmieri <johnp at redhat.com> - 1.1.33-1
- Add symlinks for the panel icons to be the fedora logos

* Thu Nov 10 2005 John (J5) Palmieri <johnp at redhat.com> - 1.1.32-1
- Add new fedora logos to pixmap and icons/hicolor

* Mon May 23 2005 Jeremy Katz <katzj at redhat.com> - 1.1.31-1
- copyright date on anaconda splash (#153964)

gaim-1:1.5.0-9.fc5
------------------
* Thu Nov 10 2005 Warren Togami <wtogami at redhat.com> - 1:1.5.0-9
- Ensure that security opt flags are used (#165795)
- Many bug fixes from Peter Lawler (#171350)
  156: Fix Yahoo chatroom ignore on join
  157: Fix Italian yahoo profiles
  158: Strip HTML from status
  159: xmlnode cleanup
  160: Fix crash on non-terminated strings
  161: silc-close-gaim_request-window-prpl-disconnect-p1
  162: silc-close-gaim_request-window-prpl-disconnect-p2
  163: silc-close-gaim_request-window-prpl-disconnect-p3
  164: silc-close-gaim_request-window-prpl-disconnect-p4
  165: silc-close-gaim_request-window-prpl-disconnect-p5
  166: silc-close-gaim_request-window-prpl-disconnect-p6
  167: MSN data corruption fix
  168: msn-kill-convo-close-timeout-notices-p1
  169: msn-kill-convo-close-timeout-notices-p2
  170: msn-kill-convo-close-timeout-notices-p3
  171: forceful-connection_disconnect-not-wipe-password
  172: Clipboard leak and history scrolling fix
  173: smileys-logtype-p1
  174: smileys-logtype-p2
  175: Allow Italics in IRC
  176: Add more authors
  177: Update copyright
  178: Update HACKING doc
  179: Fix doc creation
  180: Fix AIM/ICQ Rate Limiting issue

* Thu Oct 13 2005 Ray Strode <rstrode at redhat.com> - 1:1.5.0-7
- use upstream desktop file (except use generic name, because 
  this is our default instant messaging client)

* Tue Sep 27 2005 Warren Togami <wtogami at redhat.com> - 1:1.5.0-6
- remove -Wno-pointer-sign, not sure why it was needed earlier
- fix FORTIFY_SOURCE on FC3

gdk-pixbuf-1:0.22.0-19
----------------------
* Thu Nov 10 2005 Nalin Dahyabhai <nalin at redhat.com> - 1:0.22.0-19
- Rebuild because gtk+-devel lost its .la files, and our .la files want them.

gnome-screensaver-0.0.18-2
--------------------------
* Thu Nov 10 2005 Ray Strode <rstrode at redhat.com> 0.0.18-2
- make screensaver background window override redirect (bug 172889).

* Thu Nov 03 2005 Ray Strode <rstrode at redhat.com> 0.0.18-1
- Update to 0.0.18

* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 0.0.17-4
- Use /proc/interrupts

gnome-session-2.12.0-4
----------------------
* Wed Nov 09 2005 Alexander Larsson <alexl at redhat.com> - 2.12.0-4
- Add gnome-user-share patch

* Tue Nov 08 2005 Ray Strode <rstrode at redhat.com> - 2.12.0-3
- fix up the dummy client ids to match the id passed initially
  passed to the programs in the default session 
  (broke in last update).

gsl-1.7-1
---------
* Thu Nov 10 2005 Ivana Varekova <varekova at redhat.com> 1.7-1
- update to 1.7

kdelibs-6:3.4.92-4
------------------
* Thu Nov 10 2005 Than Ngo <than at redhat.com> 6:3.4.92-4
- apply patch to fix gcc4 compilation

kdenetwork-7:3.4.92-3
---------------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 7:3.4.92-3 
- get rid of XFree86-devel requires
- fix gcc4 compilation

* Wed Nov 09 2005 Tomas Mraz <tmraz at redhat.com> 7:3.4.92-2
- rebuilt against new openssl

kernel-2.6.14-1.1660_FC5
------------------------
* Fri Nov 11 2005 Bill Nottingham <notting at redhat.com>
- ipw2200 requires a new firmware version, tweak conflict

* Thu Nov 10 2005 Dave Jones <davej at redhat.com>
- 2.6.14-git13

* Wed Nov 09 2005 Dave Jones <davej at redhat.com>
- 2.6.14-git12

lucene-0:1.4.3-1jpp_7fc
-----------------------
* Wed Nov 09 2005 Andrew Overholt <overholt at redhat.com> 1.4.3-1jpp_7fc
- Bump release.
- Re-add patch to not link to external javadocs.

mailman-3:2.1.6-2
-----------------
* Thu Nov 10 2005 Harald Hoyer <harald at redhat.com> - 3:2.1.6-2
- added help to the initscript (bug #162724)

* Wed Jun 08 2005 John Dennis <jdennis at redhat.com> - 3:2.1.6-1.fc4
- initial port of 2.1.6
  remove mailman-2.1.5-moderator-request.patch, present in new release
  remove mailman-2.1-CAN-2005-0202.patch,       present in new release
  remove mailman-2.1-CAN-2004-1177.patch,       present in new release

* Thu Apr 28 2005 John Dennis <jdennis at redhat.com> - 3:2.1.5-36.fc4
- fix bug #156159 insecure location of restart flag file

man-1.6b-1
----------
* Thu Nov 10 2005 Ivana Varekova <varekova at redhat.com> 1.6b-1
- update to 1.6b

* Mon Oct 31 2005 Ivana Varekova <varekova at redhat.com> 1.5p-7
- add ?x sections to MANSECT variable (bug 172002)

* Tue May 17 2005 Ivana Varekova <varekova at redhat.com> 1.5p-6
- change patch 18 (less hard solution) and 
  patch 13 (don't change exit number in one case)

openldap-2.3.11-2
-----------------
* Thu Nov 10 2005 Jay Fenlason <fenlason at redhat.com> 2.3.11-2
- Upgrade to 2.3.11, which upstream now considers stable.
- Switch compat-openldap to 2.2.29
- remove references to nss_ldap_build from the spec file
- remove references to 2.0 and 2.1 from the spec file.
- reorganize the build() function slightly in the spec file to limit the
  number of redundant and conflicting options passedto configure.
- Remove the attempt to hardlink ldapmodify and ldapadd together, since
  the current make install make ldapadd a symlink to ldapmodify.
- Include the -ads patches to allow SASL binds to an Active Directory
  server to work.  Nalin <nalin at redhat.com> wrote the patch, based on my
  broken first attempt.

* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 2.2.29-3
- rebuilt against new openssl

perl-Crypt-SSLeay-0.51-9
------------------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 0.51-9
- rebuilt against new openssl
- added missing SSL_library_init()

perl-DBD-MySQL-3.0002-2
-----------------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> - 3.0002-2
- rebuilt against new openssl

perl-RPM2-0.66-11
-----------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 0.66-11
- rebuilt against new openssl
- fixed filelist for compressed man page

* Wed Mar 30 2005 Warren Togami <wtogami at redhat.com>
- remove brp-compress

php-5.0.5-6
-----------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 5.0.5-6
- rebuilt against new openssl

pm-utils-0.06-1
---------------
* Thu Nov 10 2005 Peter Jones <pjones at redhat.com> - 0.06-1
- kill acpi_video_cmd calls in functions-ati
- fix lcd_on in functions-ati

postfix-2:2.2.5-2
-----------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 2:2.2.5-2
- rebuilt against new openssl

* Fri Oct 07 2005 Tomas Mraz <tmraz at redhat.com>
- use include instead of pam_stack in pam config

pyOpenSSL-0.6-1.p24.7
---------------------
* Wed Nov 09 2005 Mihai Ibanescu <misa at redhat.com> - 0.6-1.p24.7
- rebuilt against newer openssl

rdesktop-1.4.1-3
----------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> - 1.4.1-3
- rebuilt against new openssl

* Tue Nov 01 2005 Carl Worth <cworth at redhat.com> - 1.4.1-2
- Require modular libX11-devel instead of monolithic xorg-x11-devel

redhat-artwork-0.130-1
----------------------
* Thu Nov 10 2005 John (J5) Palmieri <johnp at redhat.com> 0.130-1
- Roll a bunch of new icons into the upstream source tarball

* Thu Nov 03 2005 John (J5) Palmieri <johnp at redhat.com> 0.129-4
- Add fedora logo instead of the redhat hat

rhgb-0.16.2-10
--------------
* Thu Nov 10 2005 Ray Strode <rstrode at redhat.com> 0.16.2-10
- Don't switch out of details view if the user switched into
  it intially.  Patch from Mary Ellen Foster <mefoster at gmail.com>
  (bug 151239).

sendmail-8.13.5-2
-----------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 8.13.5-2
- rebuilt against new openssl

* Mon Oct 10 2005 Tomas Mraz <tmraz at redhat.com>
- use include instead of pam_stack in pam config

slrn-0.9.8.1-7
--------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 0.9.8.1-7
- rebuilt against new openssl (again)

subversion-1.2.3-4
------------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 1.2.3-4
- rebuilt against new openssl

system-config-date-1.7.99.5-1
-----------------------------
* Thu Nov 10 2005 Nils Philippsen <nphilipp at redhat.com> 1.7.99.5
- when choosing a region, shade off the rest of the map when hovering over a
  region

system-config-printer-0.6.145-1
-------------------------------
* Thu Nov 10 2005 Tim Waugh <twaugh at redhat.com> 0.6.145-1
- 0.6.145:
  - Select Generic PS for locally-connected PS-capable printers (bug #169121).

tcpdump-14:3.9.4-1
------------------
* Thu Nov 10 2005 Martin Stransky <stransky at redhat.com> - 14:3.9.4-1
- new upstream

* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> - 14:3.9.3-5
- rebuilt against new openssl

tn5250-0.16.5-7
---------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 0.16.5-7
- rebuilt against new openssl

wget-1.10.2-3
-------------
* Thu Nov 10 2005 Tomas Mraz <tmraz at redhat.com> 1.10.2-3
- rebuilt against new openssl

xchat-1:2.6.0-1
---------------
* Thu Nov 10 2005 Christopher Aillon <caillon at redhat.com> 1:2.6.0-1
- Update to 2.6.0

xen-3.0-0.20051109.fc5.2
------------------------
* Thu Nov 10 2005 Jeremy Katz <katzj at redhat.com> - 3.0-0.20051109.fc5.2
- actually enable the initscripts

xorg-x11-6.8.2-62
-----------------
* Tue Nov 08 2005 Mike A. Harris <mharris at redhat.com> 6.8.2-62
- Enable the xorg-x11-6.8.2-add-i945-support.patch in the spec file, as it
  got committed to CVS in 6.8.2-46, but the spec file did not get updated.
- Merged xorg-x11-6.8.2-shadow-framebuffer-leak.patch from FC-4 branch, which
  seems to have gotten forgotten for 'devel' branch.
- Merged XFree86-4.3.0-security-CAN-2005-2495.patch from FC-4 which also seems
  to have gotten left out.

yum-2.4.0-12
------------
* Thu Nov 10 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-12
- fix problem with custom kernel names in installonlyn (#172855)
- make it more obvious how to add more tokeep with installonlyn

zip-2.31-1
----------
* Thu Nov 10 2005 Ivana Varekova <varekova at redhat.com> 2.31-1
- update to 2.31

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	isdn4k-utils - 3.2-32.i386 requires libpcap.so.0.9.3
	kdesdk - 3.4.92-1.i386 requires libcrypto.so.5
	kdesdk - 3.4.92-1.i386 requires libssl.so.5
	magma - 1.0.2-1.i386 requires libmagmamsg.so
	magma - 1.0.2-1.i386 requires libmagma.so
	ppp - 2.4.3-5.i386 requires libpcap.so.0.9.3
	samba - 3.0.20-2.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libcrypto.so.5
	samba-swat - 3.0.20-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libcrypto.so.5



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc64 requires libpcap.so.0.9.3()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.ppc64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.ppc64 requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc requires libpcap.so.0.9.3
	kdesdk - 3.4.92-1.ppc requires libcrypto.so.5
	kdesdk - 3.4.92-1.ppc requires libssl.so.5
	magma - 1.0.2-1.ppc requires libmagmamsg.so
	magma - 1.0.2-1.ppc requires libmagma.so
	ppp - 2.4.3-5.ppc requires libpcap.so.0.9.3
	samba - 3.0.20-2.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libcrypto.so.5
	samba-swat - 3.0.20-2.ppc requires libssl.so.5
	samba-swat - 3.0.20-2.ppc requires libcrypto.so.5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.x86_64 requires libpcap.so.0.9.3()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.x86_64 requires libcrypto.so.5()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.x86_64 requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)



Broken deps for ia64
----------------------------------------------------------
	isdn4k-utils - 3.2-32.ia64 requires libpcap.so.0.9.3()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libcrypto.so.5()(64bit)
	kdesdk - 3.4.92-1.ia64 requires libssl.so.5()(64bit)
	magma - 1.0.2-1.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ia64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.ia64 requires libpcap.so.0.9.3()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	samba - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libssl.so.5()(64bit)



Broken deps for s390x
----------------------------------------------------------
	kdesdk - 3.4.92-1.s390x requires libssl.so.5()(64bit)
	kdesdk - 3.4.92-1.s390x requires libcrypto.so.5()(64bit)
	ppp - 2.4.3-5.s390x requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)



Broken deps for s390
----------------------------------------------------------
	kdesdk - 3.4.92-1.s390 requires libcrypto.so.5
	kdesdk - 3.4.92-1.s390 requires libssl.so.5
	ppp - 2.4.3-5.s390 requires libpcap.so.0.9.3
	samba - 3.0.20-2.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libcrypto.so.5
	samba-swat - 3.0.20-2.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libcrypto.so.5





From czar at czarc.net  Fri Nov 11 15:33:32 2005
From: czar at czarc.net (Gene C.)
Date: Fri, 11 Nov 2005 10:33:32 -0500
Subject: installonlyn feature?
Message-ID: <200511111033.32795.czar@czarc.net>

OK, I have updated yum and then updated the kernel packages on my fc5dev 
system.  I notice that the old kernel-smp packages are removed so I only have 
a couple of kernels install but the corresponding kernel-smp-devel packages 
are NOT removed.

Is this a bug (or a feature)?
-- 
Gene



From jspaleta at gmail.com  Fri Nov 11 15:47:45 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 11 Nov 2005 10:47:45 -0500
Subject: installonlyn feature?
In-Reply-To: <200511111033.32795.czar@czarc.net>
References: <200511111033.32795.czar@czarc.net>
Message-ID: <604aa7910511110747s4129df1cu55f5fe29d38faa4f@mail.gmail.com>

On 11/11/05, Gene C. <czar at czarc.net> wrote:
> Is this a bug (or a feature)?

that one is touchy. Anyone building modules for distribution might
want to keep the -devel packages around even if the kernels themselves
go away. But thats sort of a special case compared to the 90% usage
case.

As a user,even a user who occasionally needs to rebuild modules
locally i dont need the kernel-devel packages on the system if the
kernel is no longer there, so I'd want the -devel packages and any
associated module packages to disappear with the old kernels.

But there might be a need for a blacklist/whitelist for this plugin so
people can set specific wildcard lists to be ignored   
ignore=kernel*-devel     for example if you need to keep the devel
packages around without the kernels.

-jef



From dravet at hotmail.com  Fri Nov 11 16:07:46 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Fri, 11 Nov 2005 10:07:46 -0600
Subject: xorg-x11-twm error cannot rewrite files
Message-ID: <BAY103-F113CC953CEBD760124F556DF590@phx.gbl>

I am updateing to todays rawhide and when yum was cleaning up the 
xorg-x11-twm install I saw the following messages:

Cleanup   : xorg-x11-twm                 ##################### [173/266]
groupdel: cannot rewrite group file
groupdel: cannot rewrite shadow group file

Why is xorg-x11-twm trying to rewrite my group and shadow files?  Does this 
have something to do with the new modular x packages that will be available 
soon?

Thanks,
Jason




From katzj at redhat.com  Fri Nov 11 16:09:14 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 11 Nov 2005 11:09:14 -0500
Subject: installonlyn feature?
In-Reply-To: <200511111033.32795.czar@czarc.net>
References: <200511111033.32795.czar@czarc.net>
Message-ID: <1131725354.4161.2.camel@bree.local.net>

On Fri, 2005-11-11 at 10:33 -0500, Gene C. wrote:
> OK, I have updated yum and then updated the kernel packages on my fc5dev 
> system.  I notice that the old kernel-smp packages are removed so I only have 
> a couple of kernels install but the corresponding kernel-smp-devel packages 
> are NOT removed.
> 
> Is this a bug (or a feature)?

Hrmm.. the corresponding kernel-smp-devel should be getting removed as
well.  Could you file in bugzilla so that I don't forget to look if I
don't get to it today?

Thanks,

Jeremy



From dravet at hotmail.com  Fri Nov 11 16:22:52 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Fri, 11 Nov 2005 10:22:52 -0600
Subject: Failed to load image gnome-main-menu
Message-ID: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>

After updating to todays rawhide I get the following message when I startx.

Failed to load image gnome-main-menu

Details: Failed to open file 
'/usr/share/icons/Bluecurve/48x48/apps/gnome-main-menu.png': No such file or 
directory

What do I need to do to fix the problem?

Thanks,
Jason




From jkeating at j2solutions.net  Fri Nov 11 16:30:56 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 11 Nov 2005 08:30:56 -0800
Subject: Failed to load image gnome-main-menu
In-Reply-To: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>
References: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>
Message-ID: <1131726656.16402.0.camel@yoda.loki.me>

On Fri, 2005-11-11 at 10:22 -0600, Jason Dravet wrote:
> 
> Failed to load image gnome-main-menu
> 
> Details: Failed to open file 
> '/usr/share/icons/Bluecurve/48x48/apps/gnome-main-menu.png': No such
> file or 
> directory
> 
> What do I need to do to fix the problem?

That file should be a symlink to the new fedora logo.  Perhaps you
didn't update the package that has the logo, or that package hasn't hit
your rawhide mirror yet?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From darrellpf at gmail.com  Fri Nov 11 16:34:29 2005
From: darrellpf at gmail.com (darrell pfeifer)
Date: Fri, 11 Nov 2005 08:34:29 -0800
Subject: installonlyn feature?
In-Reply-To: <1131725354.4161.2.camel@bree.local.net>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
Message-ID: <f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>

The installonlyn plugin is a bit too naive when (test) kernels are failing.

If I install a kernel that doesn't boot then the next kernel update will
wipe out my working kernel in favor of a newer kernel that may also not
work.

The simple solution would be to change the default number kept to be at
least one more but this is also likely to be a problem in the case of
failing test kernels.

A better solution would be to for installonlyn to only take action in the
case where the currently booted kernel (via uname -r) is the latest version.

darrell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051111/0346f100/attachment.htm>

From fedora at camperquake.de  Fri Nov 11 16:41:23 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 11 Nov 2005 17:41:23 +0100
Subject: installonlyn feature?
In-Reply-To: <f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
	<f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
Message-ID: <20051111164123.GA9051@ryoko.camperquake.de>

On Fri, Nov 11, 2005 at 08:34:29AM -0800, darrell pfeifer wrote:

> A better solution would be to for installonlyn to only take action in the
> case where the currently booted kernel (via uname -r) is the latest version.

Or just to keep track of your kernels yourself, if you insist on using
rawhide.



From katzj at redhat.com  Fri Nov 11 16:40:56 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 11 Nov 2005 11:40:56 -0500
Subject: installonlyn feature?
In-Reply-To: <f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
	<f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
Message-ID: <1131727256.4161.5.camel@bree.local.net>

On Fri, 2005-11-11 at 08:34 -0800, darrell pfeifer wrote:
> The installonlyn plugin is a bit too naive when (test) kernels are
> failing.
> 
> If I install a kernel that doesn't boot then the next kernel update
> will wipe out my working kernel in favor of a newer kernel that may
> also not work. 

The kernel you're booted into won't be removed.  If the kernel is good
enough to install _new_ kernels then it should be reasonable to keep.

> The simple solution would be to change the default number kept to be
> at least one more but this is also likely to be a problem in the case
> of failing test kernels.
> 
> A better solution would be to for installonlyn to only take action in
> the case where the currently booted kernel (via uname -r) is the
> latest version. 

This is actually a very poor solution as it's very common for people
using the development tree to _not_ reboot every day.  I generally ended
up with about 10 kernels of which I had maybe booted into 3 before
having to remove some to make space for more.  This way, we're not
spending space on things that you haven't booted into

Jeremy



From jspaleta at gmail.com  Fri Nov 11 16:42:37 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 11 Nov 2005 11:42:37 -0500
Subject: installonlyn feature?
In-Reply-To: <f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
	<f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
Message-ID: <604aa7910511110842v2bc49188n117a591696422e96@mail.gmail.com>

On 11/11/05, darrell pfeifer <darrellpf at gmail.com> wrote:
> The installonlyn plugin is a bit too naive when (test) kernels are failing.
>
> If I install a kernel that doesn't boot then the next kernel update will
> wipe out my working kernel in favor of a newer kernel that may also not
> work.

It keeps 2 verions older than the "running" kernel by default right now.

-jef



From ellson at research.att.com  Fri Nov 11 16:50:16 2005
From: ellson at research.att.com (John Ellson)
Date: Fri, 11 Nov 2005 11:50:16 -0500
Subject: Failed to load image gnome-main-menu
In-Reply-To: <1131726656.16402.0.camel@yoda.loki.me>
References: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>
	<1131726656.16402.0.camel@yoda.loki.me>
Message-ID: <4374CBC8.4060001@research.att.com>

Jesse Keating wrote:
> On Fri, 2005-11-11 at 10:22 -0600, Jason Dravet wrote:
>   
>> Failed to load image gnome-main-menu
>>
>> Details: Failed to open file 
>> '/usr/share/icons/Bluecurve/48x48/apps/gnome-main-menu.png': No such
>> file or 
>> directory
>>
>> What do I need to do to fix the problem?
>>     
>
> That file should be a symlink to the new fedora logo.  Perhaps you
> didn't update the package that has the logo, or that package hasn't hit
> your rawhide mirror yet?
>
>   
Today's fedora-logos package fails to install:

# rpm -Uvh fedora-logos-1.1.33-1.noarch.rpm
Preparing...                ########################################### 
[100%]
        file /usr/share/icons/hicolor/48x48/apps/gnome-main-menu.png 
from install of fedora-logos-1.1.33-1 conflicts with file from package 
gnome-panel-2.12.1-4




From sundaram at redhat.com  Fri Nov 11 17:01:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 11 Nov 2005 22:31:21 +0530
Subject: Failed to load image gnome-main-menu
In-Reply-To: <4374CBC8.4060001@research.att.com>
References: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>	<1131726656.16402.0.camel@yoda.loki.me>
	<4374CBC8.4060001@research.att.com>
Message-ID: <4374CE61.8060401@redhat.com>

Hi

>>  
>
> Today's fedora-logos package fails to install:
>
> # rpm -Uvh fedora-logos-1.1.33-1.noarch.rpm
> Preparing...                
> ########################################### [100%]
>        file /usr/share/icons/hicolor/48x48/apps/gnome-main-menu.png 
> from install of fedora-logos-1.1.33-1 conflicts with file from package 
> gnome-panel-2.12.1-4
>
>
That looks a packaging bug. Can you file a report on this in 
http://bugzilla.redhat.com against fedora-logos?

regards
Rahul



From ellson at research.att.com  Fri Nov 11 17:23:51 2005
From: ellson at research.att.com (John Ellson)
Date: Fri, 11 Nov 2005 12:23:51 -0500
Subject: Failed to load image gnome-main-menu
In-Reply-To: <4374CE61.8060401@redhat.com>
References: <BAY103-F31E07874FBFB3FAF35B245DF590@phx.gbl>	<1131726656.16402.0.camel@yoda.loki.me>	<4374CBC8.4060001@research.att.com>
	<4374CE61.8060401@redhat.com>
Message-ID: <4374D3A7.5030505@research.att.com>

Rahul Sundaram wrote:
> Hi
>
>>>  
>>
>> Today's fedora-logos package fails to install:
>>
>> # rpm -Uvh fedora-logos-1.1.33-1.noarch.rpm
>> Preparing...                
>> ########################################### [100%]
>>        file /usr/share/icons/hicolor/48x48/apps/gnome-main-menu.png 
>> from install of fedora-logos-1.1.33-1 conflicts with file from 
>> package gnome-panel-2.12.1-4
>>
>>
> That looks a packaging bug. Can you file a report on this in 
> http://bugzilla.redhat.com against fedora-logos?
>
> regards
> Rahul
>
Sure.   bug #172965

John



From jspaleta at gmail.com  Fri Nov 11 17:29:26 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 11 Nov 2005 12:29:26 -0500
Subject: xorg-x11-twm error cannot rewrite files
In-Reply-To: <BAY103-F113CC953CEBD760124F556DF590@phx.gbl>
References: <BAY103-F113CC953CEBD760124F556DF590@phx.gbl>
Message-ID: <604aa7910511110929r56581837r9190af5440b5faa1@mail.gmail.com>

On 11/11/05, Jason Dravet <dravet at hotmail.com> wrote:
> I am updateing to todays rawhide and when yum was cleaning up the
> xorg-x11-twm install I saw the following messages:
>
> Cleanup   : xorg-x11-twm                 ##################### [173/266]
> groupdel: cannot rewrite group file
> groupdel: cannot rewrite shadow group file

My understanding is that during cleanup the pre/post-uninstall
scriptlets of the version you are removing are being processed.
Without knowing what the uninstall scriptlets were in the version of
xorg-x11-twm that you removed as part of the cleanup actually was...
its going to be difficult to diagnose that message.  The latest
xorg-x11-twm package  xorg-x11-twm-6.8.2-62 doesn't have any
scriptlets as far as I can tell so we can't look there for any clues.

-jef



From rodd at clarkson.id.au  Sat Nov 12 03:13:30 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Sat, 12 Nov 2005 14:13:30 +1100
Subject: installonlyn feature?
In-Reply-To: <604aa7910511110842v2bc49188n117a591696422e96@mail.gmail.com>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
	<f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
	<604aa7910511110842v2bc49188n117a591696422e96@mail.gmail.com>
Message-ID: <1131765210.5793.0.camel@localhost.localdomain>

On Fri, 2005-11-11 at 11:42 -0500, Jeff Spaleta wrote:
> On 11/11/05, darrell pfeifer <darrellpf at gmail.com> wrote:
> > The installonlyn plugin is a bit too naive when (test) kernels are failing.
> >
> > If I install a kernel that doesn't boot then the next kernel update will
> > wipe out my working kernel in favor of a newer kernel that may also not
> > work.
> 
> It keeps 2 verions older than the "running" kernel by default right now.

It's only keeping one (plus the current) for me.


R.
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From dravet at hotmail.com  Sat Nov 12 03:39:08 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Fri, 11 Nov 2005 21:39:08 -0600
Subject: xorg-x11-twm error cannot rewrite files
Message-ID: <BAY103-F12F32B8934CF76639D2B0DF580@phx.gbl>

>My understanding is that during cleanup the pre/post-uninstall
>scriptlets of the version you are removing are being processed.
>Without knowing what the uninstall scriptlets were in the version of
>xorg-x11-twm that you removed as part of the cleanup actually was...
>its going to be difficult to diagnose that message.  The latest
>xorg-x11-twm package  xorg-x11-twm-6.8.2-62 doesn't have any
>scriptlets as far as I can tell so we can't look there for any clues.
>
>-jef

I had xorg-x11-twm-6.8.2-61 installed, I ran yum update today and 
xorg-x11-6.8.2-62 was downloaded and installed.

Thanks,
Jason




From mharris at redhat.com  Sat Nov 12 03:41:10 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 11 Nov 2005 22:41:10 -0500
Subject: xorg-x11-twm error cannot rewrite files
In-Reply-To: <BAY103-F113CC953CEBD760124F556DF590@phx.gbl>
References: <BAY103-F113CC953CEBD760124F556DF590@phx.gbl>
Message-ID: <43756456.6060908@redhat.com>

Jason Dravet wrote:
> I am updateing to todays rawhide and when yum was cleaning up the 
> xorg-x11-twm install I saw the following messages:
> 
> Cleanup   : xorg-x11-twm                 ##################### [173/266]
> groupdel: cannot rewrite group file
> groupdel: cannot rewrite shadow group file
> 
> Why is xorg-x11-twm trying to rewrite my group and shadow files?  Does 
> this have something to do with the new modular x packages that will be 
> available soon?

Something else is causing this problem, because twm does not have any
rpm scriptlets.  The only thing in xorg-x11 packaging that has
'groupdel', is a very old script line in xfs scripts, which has been
commented out forever, but left there for documentive purposes.

Something else you were installing at the same time must have invoked
groupdel.



From dravet at hotmail.com  Sat Nov 12 04:45:14 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Fri, 11 Nov 2005 22:45:14 -0600
Subject: xorg-x11-twm error cannot rewrite files
Message-ID: <BAY103-F20B08F037B51AFD9DE9E1EDF580@phx.gbl>

>Something else is causing this problem, because twm does not have any
>rpm scriptlets.  The only thing in xorg-x11 packaging that has
>'groupdel', is a very old script line in xfs scripts, which has been
>commented out forever, but left there for documentive purposes.
>
>Something else you were installing at the same time must have invoked
>groupdel.

Thank you for the response.  I am not sure what package caused the message 
other than the fact the error messages occurred after yum printed the 
cleanup statement for xorg-11-twm.  I looked in my /var/log/yum.log file and 
these are some of the packages that yum installed immediately before 
xorg-x11-twm.

Nov 11 09:43:33 Updated: openldap-clients.i386 2.3.11-2
Nov 11 09:43:34 Updated: krb5-auth-dialog.i386 0.5-1
Nov 11 09:43:35 Updated: cyrus-sasl-plain.i386 2.1.21-6
Nov 11 09:43:36 Updated: cyrus-sasl-md5.i386 2.1.21-6
Nov 11 09:43:37 Updated: gnome-python2-gtkhtml2.i386 2.12.1-6
Nov 11 09:43:38 Updated: gnome-python2-bonobo.i386 2.12.1-1
Nov 11 09:43:39 Updated: gnome-python2-canvas.i386 2.12.1-1

Should I put in a RFE for yum to add the ability to track package 
installs/removals/updates/cleanups and any associated error messages so if 
yum does encounter an error we can be 100% sure what package caused said 
error?

Thanks,
Jason




From paul at cypherpunks.ca  Sat Nov 12 05:33:10 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Sat, 12 Nov 2005 06:33:10 +0100 (CET)
Subject: lndir and modular x, could this be a seperate package?
In-Reply-To: <BAY103-F20B08F037B51AFD9DE9E1EDF580@phx.gbl>
References: <BAY103-F20B08F037B51AFD9DE9E1EDF580@phx.gbl>
Message-ID: <Pine.LNX.4.63.0511120628480.25161@tla.xelerance.com>


Hi,

I am using the very useful tool "lndir" regularly in much the same way
as the new hardlink package is used (though I am not sure if hardlinks
can fully replace lndir, since I have managed to wipe out my trees
in /usr/src/kernels by just adding/removing kernel packages, but that
is another issue).

I would like lndir to be installable without pulling in a lot of X,
since it has no X windows dependancy at all. It just happened to come
with X:

[root at uml ~]# rpm -qf /usr/X11R6/bin/lndir
xorg-x11-6.8.2-37.FC4.49.2

In fact, I am not even sure why X requires lndir :)

Paul



From laroche at redhat.com  Sat Nov 12 09:04:07 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 12 Nov 2005 10:04:07 +0100
Subject: installonlyn feature?
In-Reply-To: <1131727256.4161.5.camel@bree.local.net>
References: <200511111033.32795.czar@czarc.net>
	<1131725354.4161.2.camel@bree.local.net>
	<f6e5806f0511110834t4ab77cc8rd28cd8b6eb23cb49@mail.gmail.com>
	<1131727256.4161.5.camel@bree.local.net>
Message-ID: <20051112090407.GA13346@dudweiler.stuttgart.redhat.com>

> This is actually a very poor solution as it's very common for people
> using the development tree to _not_ reboot every day.  I generally ended
> up with about 10 kernels of which I had maybe booted into 3 before
> having to remove some to make space for more.  This way, we're not
> spending space on things that you haven't booted into

This should probably be different for the release compared to FC-devel?

regards,

Florian La Roche



From gbiczo at freestart.hu  Sat Nov 12 11:34:57 2005
From: gbiczo at freestart.hu (Giovanni =?iso-8859-1?q?Bicz=F3?=)
Date: Sat, 12 Nov 2005 11:34:57 +0000
Subject: FC5 and new init system
Message-ID: <200511121134.57787.gbiczo@freestart.hu>

Hi all,

There has been a long discussion about the need of a new init system, in order 
to replace SysVinit. A wiki page and preliminary code has been written. Now 
the development seems to have stopped.
Are there any chances for the new init system (systemservices) to be included 
in FC5? If not: why?

regards
Giovanni

PS: what is the "status" of early login? seems a very similar story...



From buildsys at redhat.com  Sat Nov 12 12:15:14 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 12 Nov 2005 07:15:14 -0500
Subject: rawhide report: 20051112 changes
Message-ID: <200511121215.jACCFEhs020467@porkchop.devel.redhat.com>

New package nautilus-sendto
	Nautilus context menu for sending files


 
Updated Packages:

anaconda-10.89.12-1
-------------------
* Fri Nov 11 2005 Chris Lumens <clumens at redhat.com> 10.89.12-1
- Add buildreq for yum (katzj)
- Fix loader log levels (katzj)
- Add more libraries for dogtail (katzj)

binutils-2.16.91.0.3-1
----------------------
* Fri Nov 11 2005 Jakub Jelinek <jakub at redhat.com> 2.16.91.0.3-1
- update to 2.16.91.0.3
- add .weakref support (Alexandre Oliva, #115157, #165728)

chkconfig-1.3.23-1
------------------
* Fri Nov 11 2005 Bill Nottingham <notting at redhat.com> 1.3.23-1
- fix ntsysv (#172996)

classpathx-mail-0:1.0-4jpp_3fc
------------------------------
* Fri Nov 11 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:1.0-4jpp_3fc
- BZ 157685

ddd-3.3.11-4
------------
* Fri Nov 11 2005 Than Ngo <than at redhat.com> 3.3.11-4
- cleanup specfile, thanks to Matthias Saou

* Tue Nov 08 2005 Than Ngo <than at redhat.com> 3.3.11-3
- get rid of xorg-x11-devel, fix for modular X

* Wed Oct 12 2005 Than Ngo <than at redhat.com> 3.3.11-2
- install icon in correct place #170512

dvgrab-2.0-1
------------
* Thu Nov 10 2005 Matthias Saou <http://freshrpms.net/> 2.0-1
- Update to 2.0.

fedora-logos-1.1.34-1
---------------------
* Thu Nov 10 2005 John (J5) Palmieri <johnp at redhat.com> - 1.1.34-1
- Symlink fedora-logo-icon into Bluecurve instead of hicolor
  to avoid conflicts with other packages

gcc-4.0.2-6
-----------
* Fri Nov 11 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.2-6
- fix tiny problems in the weakref patch (Alexandre Oliva)
- rebuild against binutils 2.16.91.0.3-1 (and require it) to use
  the newly added .weakref support in gas

* Thu Nov 10 2005 Jakub Jelinek  <jakub at redhat.com> 4.0.2-5
- add weakref attribute support (Alexandre Oliva, #165728)

gphoto2-2.1.6-6
---------------
* Fri Nov 11 2005 John (J5) Palmieri <johnp at redhat.com> 2.1.6-5
- Fix typo in fdi file to point to the correct script
- Install the fdi file to the policy directory instead of information

* Fri Nov 11 2005 John (J5) Palmieri <johnp at redhat.com> 2.1.6-5
- Fix to not install scripts as directories

* Fri Nov 11 2005 John (J5) Palmieri <johnp at redhat.com> 2.1.6-4
- Add gphoto-set-procperm and 90-gphoto-camera-policy.fdi to
  have HAL set permissions on the usb cameras
- Remove hotplug support since we don't use it anymore (udev takes care
  of devices and HAL takes care of permissions)

gtkhtml3-3.8.1-2
----------------
* Thu Nov 10 2005 David Malcolm <dmalcolm at redhat.com> - 3.8.1-2
- Remove static libraries; rewrite specfile to be more explicit about the
  package payload (#172883)

hal-0.5.4.cvs20051111-1
-----------------------
* Fri Nov 11 2005 John (J5) Palmieri <johnp at redhat.com> - 0.5.4.cvs2005111-1
- Update to CVS HEAD

iproute-2.6.14-9
----------------
* Fri Nov 11 2005 Radek Vokal <rvokal at redhat.com> 2.6.14-9
- use tc manpages and cbq.init from source tarball (#172851)

jwhois-3.2.3-3
--------------
* Fri Nov 11 2005 Miloslav Trmac <mitr at redhat.com> - 3.2.3-3
- Ship ChangeLog

kbd-1.12-11
-----------
* Fri Nov 11 2005 Miloslav Trmac <mitr at redhat.com> - 1.12-11
- Don't ship character set lists (they are already in glibc-common) and an
  obsolete copy of kbd.FAQ

kdeedu-3.4.92-2
---------------
* Fri Nov 11 2005 Than Ngo <than at redhat.com> 3.4.92-2
- fix #172887

kdesdk-3.4.92-2
---------------
* Wed Nov 09 2005 Than Ngo <than at redhat.com> 2:3.4.92-2 
- get rid of xorg-x11-devel require

kernel-2.6.14-1.1663_FC5
------------------------
* Fri Nov 11 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc1
  - iseries broken, so disabled for now.
- 2.6.14-git14

lftp-3.3.3-1
------------
* Fri Nov 11 2005 Jason Vas Dias <jvdias at redhat.com> - 3.3.3-1
- Upgrade to upstream 3.3.3 release, fixing bug 171884 .

libavc1394-0.5.1-1
------------------
* Thu Nov 10 2005 Matthias Saou <http://freshrpms.net/> 0.5.1-1
- Update to 0.5.1.
- Update librom patch to still apply cleanly.

libiec61883-1.0.0-9.fc5
-----------------------
* Fri Nov 11 2005 Warren Togami <wtogami at redhat.com> 1.0.0-9
- incorporate some spec improvements from Matthias (#172105)

libraw1394-1.2.0-2.fc5
----------------------
* Fri Nov 11 2005 Warren Togami <wtogami at redhat.com> - 1.2.0-2
- spec fixes from Matthias (#172105)

libsemanage-1.3.53-2
--------------------
* Fri Nov 11 2005 Dan Walsh <dwalsh at redhat.com> 1.3.53-2
- Add swigify patch from Joshua Brindle

* Fri Nov 11 2005 Dan Walsh <dwalsh at redhat.com> 1.3.53-1
- Upgrade to latest from NSA
	* Merged move seuser validation patch from Ivan Gyurdiev.
	* Merged hidden declaration fixes from Ivan Gyurdiev,
	  with minor corrections.

libuser-0.54.2-1
----------------
* Fri Nov 11 2005 Miloslav Trmac <mitr at redhat.com> - 0.54.2-1
- Avoid using deprecated openldap functions

* Fri Nov 11 2005 Miloslav Trmac <mitr at redhat.com> - 0.54.1-2
- Rebuild with newer openldap

logrotate-3.7.2-12
------------------
* Fri Nov 11 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.2-12
- fix_free_segfaults (#172918)

* Tue Oct 25 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.2-10
- some more clean up (#171587)

* Thu Oct 20 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.2-9
- fix_free_segfaults (#171093)

openhpi-2.2.1-1
---------------
* Fri Nov 11 2005 Phil Knirsch <pknirsch at redhat.com> 2.2.1-1
- Update to stable openhpi-2.2.1

oprofile-0.9.1-3
----------------
* Fri Nov 11 2005 Will Cohen <wcohen at redhat.com>
- Add alpha and sparcs to exclusivearch.

pam_krb5-2.2.0-2
----------------
* Fri Nov 11 2005 Nalin Dahyabhai <nalin at redhat.com> - 2.2.0-2
- rebuild

* Fri Nov 11 2005 Nalin Dahyabhai <nalin at redhat.com> - 2.2.0-1
- update to 2.2.0

* Wed Oct 05 2005 Nalin Dahyabhai <nalin at redhat.com> - 2.1.95-0
- update to 2.1.95

perl-3:5.8.7-0.7.fc5
--------------------
* Wed Nov 09 2005 Jason Vas Dias <jvdias at redhat.com> - 3:5.8.7-0.7
- fix bug 136009: restore MakeMaker support for LD_RUN_PATH, 
  while removing empty LD_RUN_PATH

* Tue Nov 08 2005 Jason Vas Dias <jvdias at redhat.com> - 3:5.8.7-0.7
- fix bug 172739: upstream bug 36521 : deep recursion and segfault
  in CGI::Carp::warn with 'use diagnostics' : applied patch 25160.
- fix CAN-2004-0976: insecure use of temp files (ala Debian)

* Mon Nov 07 2005 Jason Vas Dias <jvdias at redhat.com> - 3:5.8.7-0.7
- fix bug 172587: apply upstream patches 26009, 26011

policycoreutils-1.27.27-3
-------------------------
* Fri Nov 11 2005 Dan Walsh <dwalsh at redhat.com> 1.27.27-3
- Patch genhomedircon to use libsemanage.py stuff

postfix-2:2.2.5-2.1
-------------------
* Fri Nov 11 2005 Thomas Woerner <twoerner at redhat.com> 2:2.2.5-2.1
- replaced postconf and postalias call in initscript with newaliases (#156358)
- fixed initscripts messages (#155774)
- fixed build problems when sasl is disabled (#164773)
- fixed pre-definition of mailbox_transport lmtp socket path (#122910)

tmpwatch-2.9.5-1
----------------
* Fri Nov 11 2005 Miloslav Trmac <mitr at redhat.com> - 2.9.5-1
- Fix GPL reference in usage message (#163531, patch by Ville Skytt??)
- Convert changelog to UTF-8

udev-075-1
----------
* Fri Nov 11 2005 Harald Hoyer <harald at redhat.com> - 075-1
- version 075

yum-2.4.0-13
------------
* Fri Nov 11 2005 Jeremy Katz <katzj at redhat.com> - 2.4.0-13
- handle installonlypkgs in provides too to handle, eg, 
  kernel-smp-devel (#172981)

Broken deps for ia64
----------------------------------------------------------
	isdn4k-utils - 3.2-32.ia64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-1.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ia64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.ia64 requires libpcap.so.0.9.3()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	samba - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libssl.so.5()(64bit)



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	isdn4k-utils - 3.2-32.i386 requires libpcap.so.0.9.3
	magma - 1.0.2-1.i386 requires libmagmamsg.so
	magma - 1.0.2-1.i386 requires libmagma.so
	ppp - 2.4.3-5.i386 requires libpcap.so.0.9.3
	samba - 3.0.20-2.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libcrypto.so.5
	samba-swat - 3.0.20-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libcrypto.so.5



Broken deps for s390
----------------------------------------------------------
	ppp - 2.4.3-5.s390 requires libpcap.so.0.9.3
	samba - 3.0.20-2.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libcrypto.so.5
	samba-swat - 3.0.20-2.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libcrypto.so.5



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc requires libpcap.so.0.9.3
	magma - 1.0.2-1.ppc requires libmagmamsg.so
	magma - 1.0.2-1.ppc requires libmagma.so
	ppp - 2.4.3-5.ppc requires libpcap.so.0.9.3
	samba - 3.0.20-2.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libcrypto.so.5
	samba-swat - 3.0.20-2.ppc requires libssl.so.5
	samba-swat - 3.0.20-2.ppc requires libcrypto.so.5



Broken deps for s390x
----------------------------------------------------------
	ppp - 2.4.3-5.s390x requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.x86_64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.x86_64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.x86_64 requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-1.ppc64 requires libmagmamsg.so()(64bit)
	ppp - 2.4.3-5.ppc64 requires libpcap.so.0.9.3()(64bit)
	samba - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)





From rmo at sunnmore.net  Sat Nov 12 22:38:41 2005
From: rmo at sunnmore.net (Roy-Magne Mo)
Date: Sat, 12 Nov 2005 23:38:41 +0100
Subject: traceroute replacement
In-Reply-To: <1131009410.3368.83.camel@localhost.localdomain>
References: <1131009410.3368.83.camel@localhost.localdomain>
Message-ID: <43766EF1.5010305@sunnmore.net>

Radek Vok?l wrote:
> Hi,
> 
>  there's a new package suggested as traceroute replacement. It works
> without requiring a setuid bit. 
> 
> <snip>
> This traceroute implementation relies on a number of features of the
> 2.4 Linux kernel. It works pretty much like ANK's tracepath, but 
> tries to be command line compatible with the original traceroute.
> I also has IPv6 support, and does parallel probes, which makes it
> a little faster.
> </snip>
> 
> The replacement is missing some options on which some scripts might
> depend on. Please test the package 
> 
> http://people.redhat.com/rvokal/traceroute/traceroute-1.0.3-3.src.rpm
> 
> and report any problems to this bugzilla
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172198


Any chance that the ICMP option can be reintroduced or the -P (protocol) 
option as in *BSD.

It's quite nice to see what windows-people are seeing with their tracert.

-- 
Roy-Magne Mo



From mharris at redhat.com  Sun Nov 13 06:06:12 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 13 Nov 2005 01:06:12 -0500
Subject: lndir and modular x, could this be a seperate package?
In-Reply-To: <Pine.LNX.4.63.0511120628480.25161@tla.xelerance.com>
References: <BAY103-F20B08F037B51AFD9DE9E1EDF580@phx.gbl>
	<Pine.LNX.4.63.0511120628480.25161@tla.xelerance.com>
Message-ID: <4376D7D4.9080805@redhat.com>

Paul Wouters wrote:
> Hi,
> 
> I am using the very useful tool "lndir" regularly in much the same way
> as the new hardlink package is used (though I am not sure if hardlinks
> can fully replace lndir, since I have managed to wipe out my trees
> in /usr/src/kernels by just adding/removing kernel packages, but that
> is another issue).

The "lndir" and "hardlinks" tools serve completely different purposes.
They are not interchangeable, nor intended to be.

> I would like lndir to be installable without pulling in a lot of X,
> since it has no X windows dependancy at all. It just happened to come
> with X:
> 
> [root at uml ~]# rpm -qf /usr/X11R6/bin/lndir
> xorg-x11-6.8.2-37.FC4.49.2

lndir is used by X developers during development.  It may or may not
be used during the monolithic build of X as well.  It's a utility
that probably should be in GNU coreutils IMHO, but isn't.

X11R7 currently does not contain lndir.  I'm not sure if there are
plans to keep it for X11R7 final release or not.

> In fact, I am not even sure why X requires lndir :)

To the best of my knowledge, it doesn't.  xorg at lists.freedesktop.org
would probably be the best place to ask about lndir though. ;)



From dragoran at feuerpokemon.de  Sun Nov 13 12:21:57 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Sun, 13 Nov 2005 13:21:57 +0100
Subject: FC5 and new init system
In-Reply-To: <200511121134.57787.gbiczo@freestart.hu>
References: <200511121134.57787.gbiczo@freestart.hu>
Message-ID: <43772FE5.1030304@feuerpokemon.de>

Giovanni Bicz? wrote:

>Hi all,
>
>There has been a long discussion about the need of a new init system, in order 
>to replace SysVinit. A wiki page and preliminary code has been written. Now 
>the development seems to have stopped.
>Are there any chances for the new init system (systemservices) to be included 
>in FC5? If not: why?
>
>regards
>Giovanni
>
>PS: what is the "status" of early login? seems a very similar story...
>
>  
>
interessting question...
also will early-login be back in test1 ?
in fc4 this improved the boot time (until you see the desktop) by 30-40% 
on my box



From buildsys at redhat.com  Sun Nov 13 12:22:25 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 13 Nov 2005 07:22:25 -0500
Subject: rawhide report: 20051113 changes
Message-ID: <200511131222.jADCMPeC006399@porkchop.devel.redhat.com>

 

 
Updated Packages:

dovecot-0.99.14-10.fc5
----------------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> - 0.99.14-10.fc5
- Rebuild due to mysql update.

freeradius-1.0.4-5
------------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> - 1.0.4-5
- Rebuild due to mysql update.

gnome-panel-2.12.1-5
--------------------
* Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
- remove gnome-main-menu.png as this is part of fedora-logos

libdbi-0.8.1-1
--------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> 0.8.1-1
- Update to version 0.8.1.
libdbi-drivers-0.8.1a-1
-----------------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> 0.8.1a-1
- Update to version 0.8.1a.
logrotate-3.7.3-1
-----------------
* Sat Nov 12 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.3-1
- new upstream release
- indent sources

magma-1.0.2-3
-------------
* Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
- added Provides: to solve dep issues, maybe sonames should be
  added to the shared libs

mod_auth_mysql-1:2.9.0-2
------------------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> 1:2.9.0-2
- Rebuild due to mysql update.

postgresql-8.1.0-4
------------------
* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> 8.1.0-4
- Update included PDF-format manual to 8.1.

ppp-2.4.3-6
-----------
* Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
- rebuild

pyparted-1.6.10-1
-----------------
* Fri Nov 11 2005 Peter Jones <pjones at redhat.com> - 1.6.10-1
- rebuild for new parted.
- add debugging options for make so debuginfo isn't useless

Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ppc64 requires libmagmamsg.so()(64bit)
	samba - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.ppc64 requires libcrypto.so.5()(64bit)



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	isdn4k-utils - 3.2-32.i386 requires libpcap.so.0.9.3
	samba - 3.0.20-2.i386 requires libssl.so.5
	samba - 3.0.20-2.i386 requires libcrypto.so.5
	samba-swat - 3.0.20-2.i386 requires libssl.so.5
	samba-swat - 3.0.20-2.i386 requires libcrypto.so.5



Broken deps for ia64
----------------------------------------------------------
	isdn4k-utils - 3.2-32.ia64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ia64 requires libmagmamsg.so()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	samba - 3.0.20-2.ia64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.ia64 requires libssl.so.5()(64bit)



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc requires libpcap.so.0.9.3
	samba - 3.0.20-2.ppc requires libssl.so.5
	samba - 3.0.20-2.ppc requires libcrypto.so.5
	samba-swat - 3.0.20-2.ppc requires libssl.so.5
	samba-swat - 3.0.20-2.ppc requires libcrypto.so.5



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.x86_64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.x86_64 requires libmagmamsg.so()(64bit)
	samba - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.x86_64 requires libcrypto.so.5()(64bit)



Broken deps for s390x
----------------------------------------------------------
	samba - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libssl.so.5()(64bit)
	samba-swat - 3.0.20-2.s390x requires libcrypto.so.5()(64bit)



Broken deps for s390
----------------------------------------------------------
	samba - 3.0.20-2.s390 requires libssl.so.5
	samba - 3.0.20-2.s390 requires libcrypto.so.5
	samba-swat - 3.0.20-2.s390 requires libssl.so.5
	samba-swat - 3.0.20-2.s390 requires libcrypto.so.5





From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Sun Nov 13 13:23:01 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Sun, 13 Nov 2005 14:23:01 +0100
Subject: rawhide report: 20051113 changes
In-Reply-To: <200511131222.jADCMPeC006399@porkchop.devel.redhat.com>
References: <200511131222.jADCMPeC006399@porkchop.devel.redhat.com>
Message-ID: <20051113142301.47e372cb@python2>

Build System wrote :

> magma-1.0.2-3
> -------------
> * Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
> - added Provides: to solve dep issues, maybe sonames should be
>   added to the shared libs

I'd say they should indeed : That "workaround" doesn't work for 64bit archs... and doing something like "test %{_lib} = lib64" or enumerating all known 64bit archs is oh so ugly :-)

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1637_FC4
Load : 0.60 0.39 0.15



From ivazquez at ivazquez.net  Mon Nov 14 03:35:38 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Sun, 13 Nov 2005 22:35:38 -0500
Subject: rawhide report: 20051113 changes
In-Reply-To: <20051113142301.47e372cb@python2>
References: <200511131222.jADCMPeC006399@porkchop.devel.redhat.com>
	<20051113142301.47e372cb@python2>
Message-ID: <1131939338.23974.11.camel@ignacio.lan>

On Sun, 2005-11-13 at 14:23 +0100, Matthias Saou wrote:
> Build System wrote :
> 
> > magma-1.0.2-3
> > -------------
> > * Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
> > - added Provides: to solve dep issues, maybe sonames should be
> >   added to the shared libs
> 
> I'd say they should indeed : That "workaround" doesn't work for 64bit
> archs... and doing something like "test %{_lib} = lib64" or
> enumerating all known 64bit archs is oh so ugly :-)

I was taking a look at magma for someone, and the problem isn't with the
libraries, it's with the test apps. For some reason they're requiring
the libraries with .so even though the .so.SONAME libraries are there. I
suspect that the build process might be copying the built libraries
instead of linking them.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051113/fc948af5/attachment.sig>

From bgerst at didntduck.org  Mon Nov 14 05:08:03 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Mon, 14 Nov 2005 00:08:03 -0500
Subject: lndir and modular x, could this be a seperate package?
In-Reply-To: <Pine.LNX.4.63.0511120628480.25161@tla.xelerance.com>
References: <BAY103-F20B08F037B51AFD9DE9E1EDF580@phx.gbl>
	<Pine.LNX.4.63.0511120628480.25161@tla.xelerance.com>
Message-ID: <43781BB3.8030407@didntduck.org>

Paul Wouters wrote:
> Hi,
> 
> I am using the very useful tool "lndir" regularly in much the same way
> as the new hardlink package is used (though I am not sure if hardlinks
> can fully replace lndir, since I have managed to wipe out my trees
> in /usr/src/kernels by just adding/removing kernel packages, but that
> is another issue).
> 
> I would like lndir to be installable without pulling in a lot of X,
> since it has no X windows dependancy at all. It just happened to come
> with X:
> 
> [root at uml ~]# rpm -qf /usr/X11R6/bin/lndir
> xorg-x11-6.8.2-37.FC4.49.2
> 
> In fact, I am not even sure why X requires lndir :)
> 
> Paul
> 

cp -rs should do the same thing as lndir.

--
				Brian Gerst



From harald at redhat.com  Mon Nov 14 11:18:38 2005
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 14 Nov 2005 12:18:38 +0100
Subject: FC5 and new init system
In-Reply-To: <200511121134.57787.gbiczo@freestart.hu>
References: <200511121134.57787.gbiczo@freestart.hu>
Message-ID: <4378728E.8050609@redhat.com>

Giovanni Bicz? wrote:
> Hi all,
> 
> There has been a long discussion about the need of a new init system, in order 
> to replace SysVinit. A wiki page and preliminary code has been written. Now 
> the development seems to have stopped.
> Are there any chances for the new init system (systemservices) to be included 
> in FC5? If not: why?

Lack of response, noone seemed to be interested in systemservices.. so I stopped.



From sundaram at redhat.com  Mon Nov 14 11:46:15 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 14 Nov 2005 17:16:15 +0530
Subject: FC5 and new init system
In-Reply-To: <4378728E.8050609@redhat.com>
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com>
Message-ID: <43787907.6060504@redhat.com>

Hi

>>
>> There has been a long discussion about the need of a new init system, 
>> in order to replace SysVinit. A wiki page and preliminary code has 
>> been written. Now the development seems to have stopped.
>> Are there any chances for the new init system (systemservices) to be 
>> included in FC5? If not: why?
>
>
> Lack of response, noone seemed to be interested in systemservices.. so 
> I stopped.
>   

There is definitely a lot of interest from users as visible from 
repeated queries in this list. If the work you have done is packaged and 
pushed into rawhide or Fedora Extras,  we can get more feedback.

regards
Rahul



From radekvokal at gmail.com  Mon Nov 14 11:50:47 2005
From: radekvokal at gmail.com (Radek =?ISO-8859-1?Q?Vok=E1l?=)
Date: Mon, 14 Nov 2005 12:50:47 +0100
Subject: yum reoprts - package Installed - but it wasn't
Message-ID: <1131969048.3414.97.camel@localhost.localdomain>

Hi

This is not very nice yum behavior. On my FC3 box, yum reports that
packages were successfully installed but due to problems with
transaction lock they actually weren't. It's confusing and yum should
report something more meaningful. I guess this is already fixed in
rawhide, but would be great to have it fixed in FC3 also. Here's my
output 

Dependencies Resolved
Transaction Listing:
   Install: beecrypt-devel.i386 0:3.1.0-6 - base
   Install: elfutils-devel.i386 0:0.96-1 - base
   Install: elfutils-libelf-devel.i386 0:0.96-1 - base
Total download size: 437 k
Is this ok [y/N]: y
Downloading Packages:
(1/3): elfutils-libelf-de 100% |=========================|  50 kB
00:01
(2/3): beecrypt-devel-3.1 100% |=========================| 358 kB
00:02
(3/3): elfutils-devel-0.9 100% |=========================|  29 kB
00:00
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
error: can't create transaction lock

Installed: beecrypt-devel.i386 0:3.1.0-6 elfutils-devel.i386 0:0.96-1 
elfutils-libelf-devel.i386 0:0.96-1
Complete!
root at taz ~# echo $?
0
root at taz ~# rpm -q beecrypt-devel
package beecrypt-devel is not installed

root at taz ~# rpm -q yum
yum-2.2.2-0.fc3


-- 
Radek Vok?l <radekvokal at gmail.com>



From buildsys at redhat.com  Mon Nov 14 12:17:48 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 14 Nov 2005 07:17:48 -0500
Subject: rawhide report: 20051114 changes
Message-ID: <200511141217.jAECHmhc001746@porkchop.devel.redhat.com>

 

 
Updated Packages:

bind-24:9.3.1-22
----------------
* Sun Nov 13 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-22
- fix bug 172632 - remove .la files
- ship namedGetForwarders and namedSetForwarders scripts
- fix detection of -D option in chroot

createrepo-0.4.3-2
------------------
* Sun Nov 13 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-2
- Sync upto HEAD 
- Split media support

gnome-panel-2.12.1-7
--------------------
* Sun Nov 13 2005 John (J5) Palmieri <johnp at redhat.com> 2.12.1-7
- Fix patch to refrence about-fedora.desktop and not fedora-about.desktop

* Sun Nov 13 2005 John (J5) Palmieri <johnp at redhat.com> 2.12.1-6
- add about fedora menu item
- readd gnome-main-menu.png as fedora-logo now installs it to
  the Bluecurve theme

gphoto2-2.1.6-7
---------------
* Sun Nov 13 2005 John (J5) Palmieri <johnp at redhat.com> 2.1.6-7
- Add callout to cameras with ptp access methods

* Fri Nov 11 2005 John (J5) Palmieri <johnp at redhat.com> 2.1.6-6
- Fix typo in fdi file to point to the correct script
- Install the fdi file to the policy directory instead of information

gthumb-2.7.1-1
--------------
* Sun Nov 13 2005 Matthias Clasen <mclasen at redhat.com> - 2.7.1-1
- Update to 2.7.1

hardlink-1:1.0-1.18
-------------------
* Mon Nov 14 2005 Jindrich Novy <jnovy at redhat.com>
- more spec cleanup - thanks to Matthias Saou (#172968)
- use UTF-8 encoding in the source

kernel-2.6.14-1.1665_FC5
------------------------
* Mon Nov 14 2005 David Woodhouse <dwmw2 at redhat.com>
- PPC vDSO fixes from BenH

* Sun Nov 13 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc1-git1

logrotate-3.7.3-2
-----------------
* Sun Nov 13 2005 Peter Vrabec <pvrabec at redhat.com> 3.7.3-2
- fix_free_segfaults (#172918)

lynx-2.8.5-27
-------------
* Sun Nov 13 2005 Tim Waugh <twaugh at redhat.com> 2.8.5-27
- Apply patch to fix CVE-2005-2929 (bug #172973).

qt-1:3.3.5-10
-------------
* Sun Nov 13 2005 Than Ngo <than at redhat.com> 1:3.3.5-10
- workaround for keyboard input action in KHotKeys

redhat-artwork-0.131-1
----------------------
* Thu Nov 10 2005 John (J5) Palmieri <johnp at redhat.com> 0.131-1
- Upstream fix for volume icons

samba-0:3.0.20-3
----------------
* Sun Nov 13 2005 Warren Togami <wtogami at redhat.com> 3.0.20-3
- epochs from deps, req exact release
- rebuild against new openssl

vixie-cron-4:4.1-41.FC5
-----------------------
* Sun Nov 13 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-41-FC5
- patches for IBM LSPP testing:
- Steve Grubb's patch to emit audit log message on crontab denial
- Use of sendmail unacceptable for LSPP: provide -m <mail command> option

* Tue Oct 18 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-40-FC5
- *** NOTE : please do not modify vixie-cron without contacting ***
  *** the package maintainer (me at the moment).                ***
  *** Or at least test it first!                                ***
- fix bug 170830: it was not the pam_stack change - the setuid
  mode of crontab was dropped for some reason.
- apply Dan's new getseuserbyname patch
- somehow build_env() invocation was dropped - use pam_env settings.

* Fri Oct 14 2005 Jason Vas Dias <jvdias at redhat.com> - 4.1-39-FC5
- fix bug 170830: the last PAM change disabled all cron jobs.
  backing out the new PAM configuration file until I've had a
  chance to test it with replacement of pam_stack.so.

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	isdn4k-utils - 3.2-32.i386 requires libpcap.so.0.9.3



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc requires libpcap.so.0.9.3






Broken deps for ia64
----------------------------------------------------------
	isdn4k-utils - 3.2-32.ia64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ia64 requires libmagmamsg.so()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs






Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.x86_64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.x86_64 requires libmagmamsg.so()(64bit)



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	isdn4k-utils - 3.2-32.ppc64 requires libpcap.so.0.9.3()(64bit)
	magma - 1.0.2-3.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ppc64 requires libmagmamsg.so()(64bit)





From dimi at lattica.com  Mon Nov 14 16:45:07 2005
From: dimi at lattica.com (Dimi Paun)
Date: Mon, 14 Nov 2005 11:45:07 -0500
Subject: FC5 and new init system
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com>
Message-ID: <07ff01c5e93a$c72cbca0$b6491b31@td612671>

From: "Harald Hoyer" <harald at redhat.com>
> Lack of response, noone seemed to be interested in systemservices.. so I
stopped.

This is too bad -- I was pretty excited to see this development.
As for the lack of response, at least on my side, simply comes
from the avoidance of sending a "Yay!" to the list :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From shiva at sewingwitch.com  Mon Nov 14 16:55:25 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Mon, 14 Nov 2005 08:55:25 -0800
Subject: FC5 and new init system
In-Reply-To: <07ff01c5e93a$c72cbca0$b6491b31@td612671>
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com> <07ff01c5e93a$c72cbca0$b6491b31@td612671>
Message-ID: <C38355C4688FED32366696D4@[10.169.6.233]>

--On Monday, November 14, 2005 11:45 AM -0500 Dimi Paun <dimi at lattica.com> 
wrote:

> This is too bad -- I was pretty excited to see this development.
> As for the lack of response, at least on my side, simply comes
> from the avoidance of sending a "Yay!" to the list :)

Same here. I figured the development went off-list and I didn't want to do 
an AOL "me-too". But if that's what it takes.... ;)




From dragoran at feuerpokemon.de  Mon Nov 14 17:30:49 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Mon, 14 Nov 2005 18:30:49 +0100
Subject: FC5 and new init system
In-Reply-To: <07ff01c5e93a$c72cbca0$b6491b31@td612671>
References: <200511121134.57787.gbiczo@freestart.hu>	<4378728E.8050609@redhat.com>
	<07ff01c5e93a$c72cbca0$b6491b31@td612671>
Message-ID: <4378C9C9.6050102@feuerpokemon.de>

Dimi Paun wrote:

>From: "Harald Hoyer" <harald at redhat.com>
>  
>
>>Lack of response, noone seemed to be interested in systemservices.. so I
>>    
>>
>stopped.
>
>This is too bad -- I was pretty excited to see this development.
>As for the lack of response, at least on my side, simply comes
>from the avoidance of sending a "Yay!" to the list :)
>
>  
>
same here....
can it be still be done before fc5 ?



From lmacken at redhat.com  Mon Nov 14 18:08:50 2005
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 14 Nov 2005 13:08:50 -0500
Subject: FC5 and new init system
In-Reply-To: <200511121134.57787.gbiczo@freestart.hu>
References: <200511121134.57787.gbiczo@freestart.hu>
Message-ID: <20051114180850.GA14563@lewk.org>

On Sat, Nov 12, 2005 at 11:34:57AM +0000, Giovanni Bicz? wrote:
| Hi all,
| 
| There has been a long discussion about the need of a new init system, in order 
| to replace SysVinit. A wiki page and preliminary code has been written. Now 
| the development seems to have stopped.
| Are there any chances for the new init system (systemservices) to be included 
| in FC5? If not: why?

The discussions for Fedora's SysVinit replacement are currently off-list,
but not for much longer.  Any inclusion of a new init system in FC5 isn't
going to happen considering today is the test1 devel freeze, but Fedora
Extras will most likely serve to be a good testbed for any init replacements
that we plan on testing in the near future.

luke



From chris at allset.nl  Mon Nov 14 18:06:47 2005
From: chris at allset.nl (Chris Chabot)
Date: Mon, 14 Nov 2005 19:06:47 +0100 (CET)
Subject: FC5 and new init system
In-Reply-To: <4378C9C9.6050102@feuerpokemon.de>
References: <200511121134.57787.gbiczo@freestart.hu>	<4378728E.8050609@redhat.com>
	<07ff01c5e93a$c72cbca0$b6491b31@td612671>
	<4378C9C9.6050102@feuerpokemon.de>
Message-ID: <40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>

Umm yes please, would love to see this in place and moving forward!


<quote who="dragoran">
> Dimi Paun wrote:
>
>>From: "Harald Hoyer" <harald at redhat.com>
>>
>>
>>>Lack of response, noone seemed to be interested in systemservices.. so I
>>>
>>>
>>stopped.
>>
>>This is too bad -- I was pretty excited to see this development.
>>As for the lack of response, at least on my side, simply comes
>>from the avoidance of sending a "Yay!" to the list :)
>>
>>
>>
> same here....
> can it be still be done before fc5 ?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>






From jkeating at j2solutions.net  Mon Nov 14 19:39:07 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 14 Nov 2005 11:39:07 -0800
Subject: FC5 and new init system
In-Reply-To: <20051114180850.GA14563@lewk.org>
References: <200511121134.57787.gbiczo@freestart.hu>
	<20051114180850.GA14563@lewk.org>
Message-ID: <1131997147.6192.54.camel@prometheus.gamehouse.com>

On Mon, 2005-11-14 at 13:08 -0500, Luke Macken wrote:
> The discussions for Fedora's SysVinit replacement are currently off-list,
> but not for much longer.  Any inclusion of a new init system in FC5 isn't
> going to happen considering today is the test1 devel freeze, but Fedora
> Extras will most likely serve to be a good testbed for any init replacements
> that we plan on testing in the near future.

Unfortunately Extras may not be the best place.  One of the rules of
Extras is that it doesn't replace something in Core.

Would the new init system require the SysV init stuff be
disabled/removed?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From skvidal at phy.duke.edu  Mon Nov 14 19:43:49 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 14 Nov 2005 14:43:49 -0500
Subject: FC5 and new init system
In-Reply-To: <1131997147.6192.54.camel@prometheus.gamehouse.com>
References: <200511121134.57787.gbiczo@freestart.hu>
	<20051114180850.GA14563@lewk.org>
	<1131997147.6192.54.camel@prometheus.gamehouse.com>
Message-ID: <1131997429.655.17.camel@cutter>

On Mon, 2005-11-14 at 11:39 -0800, Jesse Keating wrote:
> On Mon, 2005-11-14 at 13:08 -0500, Luke Macken wrote:
> > The discussions for Fedora's SysVinit replacement are currently off-list,
> > but not for much longer.  Any inclusion of a new init system in FC5 isn't
> > going to happen considering today is the test1 devel freeze, but Fedora
> > Extras will most likely serve to be a good testbed for any init replacements
> > that we plan on testing in the near future.
> 
> Unfortunately Extras may not be the best place.  One of the rules of
> Extras is that it doesn't replace something in Core.
> 
> Would the new init system require the SysV init stuff be
> disabled/removed?

well things in extras can be replacements for core but they cannot:
 - explicitly conflict or file-conflict
 - explicitly obsolete

but syslog-ng is in extras and it can serve as a replacement for syslogd

-sv




From sopwith at redhat.com  Mon Nov 14 20:04:14 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Mon, 14 Nov 2005 15:04:14 -0500 (EST)
Subject: How to simplify the process of adding multilingual %descriptions
 to rpm spec?
In-Reply-To: <76e72f800511071722h7841b6e2t@mail.gmail.com>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>

On Tue, 8 Nov 2005, Yuan Yijun wrote:

> Greetings,
> 
> I believe that non-English speakers will be more happy to see
> localized package %descriptions, when they are using a GUI package
> management program. Most of users play Linux for fun, and they are
> willing to search software in the huge packages list, looking for
> interesting packages to install. But this fun only belongs to English
> speakers. To Chinese, there is no way for an software package to
> introduce itself.
> 
> Then how can these %descriptions be localized? If someone translate
> them and commit patches to rpm spec files, that seems a bit funny and
> boring. (Sorry for my bad vocabulary, though the single filed rpm spec
> does have its cons and pros.) How to simplify this and reduce the
> amount of work?
>
> (There are too many excellent programs in both Core and Extras, while
> I'm trying to introduce them to other Chinese users, I believe this
> problem is essential.)

Currently, specspo is meant to be the means by which package strings are
translated. However, specspo has not been maintained in a long time and
could use a lot of love. If someone wants to pick it back up, the work
that needs to be done is a fairly well understood problem. It's just a LOT 
OF WORK. :)

Best,
-- Elliot



From linville at redhat.com  Mon Nov 14 20:51:10 2005
From: linville at redhat.com (John W. Linville)
Date: Mon, 14 Nov 2005 15:51:10 -0500
Subject: [ANNOUNCE] fedora-netdev kernel repository
Message-ID: <20051114205110.GK25755@redhat.com>

Fedora-netdev!

This message is to announce the availability of a new Fedora-based
kernel repository.  The kernels available there are based upon
the standard Fedora kernels, with the addition of current upstream
networking patches which are more recent than the Fedora kernel's
upstream base.  More information is available here:

	http://people.redhat.com/linville/kernels/fedora-netdev/

The purpose of this repository is two-fold: 1) to make bleeding-edge
linux kernel networking developments available to Fedora users who
need or want access to them; and, 2) to open-up the Fedora user
base as a better testing resource for the kernel netdev community.
I hope this will prove to be a win-win situation for both camps.

If you are a Fedora user with an interest or need for the latest
developments in Linux kernel networking, then _please_ try the
kernels from this repository.  Your testing and feedback is greatly
appreciated, desperately requested, and graciously accepted.
Thanks in advance!

Please feel free to contact me at this address regarding these
kernels or other Fedora-related issues (especially networking).
If your interest is coming from the netdev/upstream side of the house,
you may want to contact me as linville at tuxdriver.com instead.

Thanks,

John

P.S.  For those who just want to cut to the chase, do this (as root):

   cd /etc/yum.repos.d
   wget http://people.redhat.com/linville/kernels/fedora-netdev/fedora-netdev.repo
   yum update

-- 
John W. Linville
linville at redhat.com



From nicolas.mailhot at laposte.net  Mon Nov 14 21:24:36 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 14 Nov 2005 22:24:36 +0100
Subject: FC5 and new init system
In-Reply-To: <40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com> <07ff01c5e93a$c72cbca0$b6491b31@td612671>
	<4378C9C9.6050102@feuerpokemon.de>
	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
Message-ID: <1132003477.3092.2.camel@rousalka.dyndns.org>

Same here. A lot of people were holding their breath for this, trying
not to scare you off - seems it didn't have the intended effect.

Will go AOL from now on ;)

-- 
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/20051114/3d5651b4/attachment.sig>

From mike at miketc.com  Mon Nov 14 21:33:04 2005
From: mike at miketc.com (Mike Chambers)
Date: Mon, 14 Nov 2005 15:33:04 -0600
Subject: [ANNOUNCE] fedora-netdev kernel repository
In-Reply-To: <20051114205110.GK25755@redhat.com>
References: <20051114205110.GK25755@redhat.com>
Message-ID: <1132003984.2594.1.camel@scrappy.miketc.com>

On Mon, 2005-11-14 at 15:51 -0500, John W. Linville wrote:
> Fedora-netdev!
> 
> This message is to announce the availability of a new Fedora-based
> kernel repository.  The kernels available there are based upon
> the standard Fedora kernels, with the addition of current upstream
> networking patches which are more recent than the Fedora kernel's
> upstream base.  More information is available here:
> 
> 	http://people.redhat.com/linville/kernels/fedora-netdev/
> 

Do the rawhide kernels already have this?  As I did run a yum update but
no packages available, so not sure if just the naming/versioning is
showing lower and should just install instead or if rawhide kernels
already have the patches?

-- 
Mike Chambers
Madisonville, KY

"It's better to hurt a little now, than to hurt a lot later!"



From linville at redhat.com  Mon Nov 14 21:54:36 2005
From: linville at redhat.com (John W. Linville)
Date: Mon, 14 Nov 2005 16:54:36 -0500
Subject: [ANNOUNCE] fedora-netdev kernel repository
In-Reply-To: <1132003984.2594.1.camel@scrappy.miketc.com>
References: <20051114205110.GK25755@redhat.com>
	<1132003984.2594.1.camel@scrappy.miketc.com>
Message-ID: <20051114215436.GQ25755@redhat.com>

On Mon, Nov 14, 2005 at 03:33:04PM -0600, Mike Chambers wrote:
> On Mon, 2005-11-14 at 15:51 -0500, John W. Linville wrote:
> > Fedora-netdev!

> Do the rawhide kernels already have this?  As I did run a yum update but
> no packages available, so not sure if just the naming/versioning is
> showing lower and should just install instead or if rawhide kernels
> already have the patches?

I only have FC4 at the moment.  I intend to get FC5/rawhide RSN.

Thanks!

John
-- 
John W. Linville
linville at redhat.com



From lamont at gurulabs.com  Mon Nov 14 21:56:53 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Mon, 14 Nov 2005 14:56:53 -0700
Subject: FC5 and new init system
In-Reply-To: <1132003477.3092.2.camel@rousalka.dyndns.org>
References: <200511121134.57787.gbiczo@freestart.hu>
	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
	<1132003477.3092.2.camel@rousalka.dyndns.org>
Message-ID: <200511141456.58917.lamont@gurulabs.com>

On Monday 14 November 2005 02:24pm, Nicolas Mailhot wrote:
> Same here. A lot of people were holding their breath for this, trying
> not to scare you off - seems it didn't have the intended effect.
>
> Will go AOL from now on ;)

Or we could all just hit Harald's <harald at redhat.com> email directly with our 
AOL "Me too"'s and spare the list. ;)

You'll get at least 7 votes from us at Guru Labs; as long as there is no XML 
in it.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051114/43af4e43/attachment.sig>

From dhollis at davehollis.com  Mon Nov 14 21:56:46 2005
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 14 Nov 2005 16:56:46 -0500
Subject: [ANNOUNCE] fedora-netdev kernel repository
In-Reply-To: <1132003984.2594.1.camel@scrappy.miketc.com>
References: <20051114205110.GK25755@redhat.com>
	<1132003984.2594.1.camel@scrappy.miketc.com>
Message-ID: <1132005406.23535.12.camel@dhollis-lnx.sunera.com>

On Mon, 2005-11-14 at 15:33 -0600, Mike Chambers wrote:

> Do the rawhide kernels already have this?  As I did run a yum update but
> no packages available, so not sure if just the naming/versioning is
> showing lower and should just install instead or if rawhide kernels
> already have the patches?
> 

Rawhide kernels may have some bits from the netdev git repos, but not
all.  As the repos are pulled into Linus' kernel, they'll wind up in
rawhide kernels.  It's probably around a 1-4 week turnaround (depending
on what state the patch window is in at the time) for patches to get
into mainline, and thus rawhide.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051114/9c80b8b4/attachment.sig>

From paul at cypherpunks.ca  Mon Nov 14 22:14:49 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 14 Nov 2005 23:14:49 +0100 (CET)
Subject: [ANNOUNCE] fedora-netdev kernel repository
In-Reply-To: <1132005406.23535.12.camel@dhollis-lnx.sunera.com>
References: <20051114205110.GK25755@redhat.com>
	<1132003984.2594.1.camel@scrappy.miketc.com>
	<1132005406.23535.12.camel@dhollis-lnx.sunera.com>
Message-ID: <Pine.LNX.4.63.0511142308490.26008@tla.xelerance.com>

On Mon, 14 Nov 2005, David Hollis wrote:

> Rawhide kernels may have some bits from the netdev git repos, but not
> all.  As the repos are pulled into Linus' kernel, they'll wind up in
> rawhide kernels.  It's probably around a 1-4 week turnaround (depending
> on what state the patch window is in at the time) for patches to get
> into mainline, and thus rawhide.

Atually, our problem is more with Fedora kernels and LinuS kernels having
dfferent version numbers for different features. Eg, when sk_alloc changed
argument order and they swapped a bool for an address location, in LinuS
trees that happened in 2.6.12, while that wasn't the case for fedra kernels.
We are now seeing similar issues with the many changes in networking, and
we can only put in one version check.

examples:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,8)
#define NEED_INET_PROTOCOL
#endif

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
#define HAVE_SOCK_ZAPPED
#define NET_26_12_SKALLOC
#endif

/* see <linux/security.h> */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
#define HAVE_SOCK_SECURITY

/* skb->nf_debug disappared completely in 2.6.13 */
#define HAVE_SKB_NF_DEBUG
#endif

/* skb->stamp changed to skb->tstamp in 2.6.14 */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,14)
#define HAVE_TSTAMP
#define HAVE_INET_SK_SPORT
#else
#else
#define HAVE_SKB_LIST
#endif

/* it seems 2.6.14 accidentally removed sysctl_ip_default_ttl */
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,14)
#define HAVE_MISSING_IP_DEFAULT_TTL
#endif

Making all of this build on Fedora kernels is reall becoming too big
of a task. But I don't really have a solution for this either :(

Paul



From ivazquez at ivazquez.net  Mon Nov 14 22:19:26 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Mon, 14 Nov 2005 17:19:26 -0500
Subject: FC5 and new init system
In-Reply-To: <1132003477.3092.2.camel@rousalka.dyndns.org>
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com> <07ff01c5e93a$c72cbca0$b6491b31@td612671>
	<4378C9C9.6050102@feuerpokemon.de>
	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
	<1132003477.3092.2.camel@rousalka.dyndns.org>
Message-ID: <1132006766.13770.4.camel@ignacio.lan>

On Mon, 2005-11-14 at 22:24 +0100, Nicolas Mailhot wrote:
> Same here. A lot of people were holding their breath for this, trying
> not to scare you off - seems it didn't have the intended effect.
> 
> Will go AOL from now on ;)

I'll throw my vote on as well, not because I have a (large) problem with
initscripts, but just for the coolness factor.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051114/e590a117/attachment.sig>

From lmacken at redhat.com  Mon Nov 14 22:34:35 2005
From: lmacken at redhat.com (Luke Macken)
Date: Mon, 14 Nov 2005 17:34:35 -0500
Subject: FC5 and new init system
In-Reply-To: <1131997147.6192.54.camel@prometheus.gamehouse.com>
References: <200511121134.57787.gbiczo@freestart.hu>
	<20051114180850.GA14563@lewk.org>
	<1131997147.6192.54.camel@prometheus.gamehouse.com>
Message-ID: <20051114223435.GB15026@lewk.org>

On Mon, Nov 14, 2005 at 11:39:07AM -0800, Jesse Keating wrote:
| On Mon, 2005-11-14 at 13:08 -0500, Luke Macken wrote:
| > The discussions for Fedora's SysVinit replacement are currently off-list,
| > but not for much longer.  Any inclusion of a new init system in FC5 isn't
| > going to happen considering today is the test1 devel freeze, but Fedora
| > Extras will most likely serve to be a good testbed for any init replacements
| > that we plan on testing in the near future.
| 
| Unfortunately Extras may not be the best place.  One of the rules of
| Extras is that it doesn't replace something in Core.
| 
| Would the new init system require the SysV init stuff be
| disabled/removed?

That all depends on what we plan to implement.  Harald's SystemManager
is an /etc/rc replacement, and works along side of our SysVinit (iirc);
but something like initng[0] is a full out replacement, but has no
file conflicts and should work with SysVinit installed.  I originally
thought FE would be ideal because it would give anyone a chance to test
things out (although, SystemManager seems to be more transparent and
easier to toss in to core right away), and we wouldn't have to have
it obsolete anything until it gets into core.

luke

[0]: http://initng.thinktux.net



From dax at gurulabs.com  Tue Nov 15 08:13:18 2005
From: dax at gurulabs.com (Dax Kelson)
Date: Tue, 15 Nov 2005 01:13:18 -0700
Subject: FC5 and new init system
In-Reply-To: <200511141456.58917.lamont@gurulabs.com>
References: <200511121134.57787.gbiczo@freestart.hu>
	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
	<1132003477.3092.2.camel@rousalka.dyndns.org>
	<200511141456.58917.lamont@gurulabs.com>
Message-ID: <1132042399.3461.3.camel@mentorng.gurulabs.com>

On Mon, 2005-11-14 at 14:56 -0700, Lamont R. Peterson wrote:
> On Monday 14 November 2005 02:24pm, Nicolas Mailhot wrote:
> > Same here. A lot of people were holding their breath for this, trying
> > not to scare you off - seems it didn't have the intended effect.
> >
> > Will go AOL from now on ;)
> 
> Or we could all just hit Harald's <harald at redhat.com> email directly with our 
> AOL "Me too"'s and spare the list. ;)
> 
> You'll get at least 7 votes from us at Guru Labs; as long as there is no XML 
> in it.

Well, more accurately, as long as it doesn't suck. :)

The devil is in the design and implementation details ... yadda yadda.

Dax Kelson



From gauret at free.fr  Tue Nov 15 09:42:13 2005
From: gauret at free.fr (Aurelien Bompard)
Date: Tue, 15 Nov 2005 10:42:13 +0100
Subject: FC5 and new init system
References: <200511121134.57787.gbiczo@freestart.hu>
	<4378728E.8050609@redhat.com>
	<07ff01c5e93a$c72cbca0$b6491b31@td612671>
	<4378C9C9.6050102@feuerpokemon.de>
	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>
	<1132003477.3092.2.camel@rousalka.dyndns.org>
	<1132006766.13770.4.camel@ignacio.lan>
Message-ID: <dlcahl$cj4$1@sea.gmane.org>

>> Will go AOL from now on ;)
> 
> I'll throw my vote on as well, not because I have a (large) problem with
> initscripts, but just for the coolness factor.

Should we setup a wiki page where everybody could vote ? ;o)
Or a simple slashdot-like web poll system ? (that could actually be useful)

Anyway, you have my vote too.

Aur?lien
-- 
http://aurelien.bompard.org  ~~~~  Jabber : abompard at jabber.fr
No, I coded it crappily on purpose, just so that I could say "There's
plenty of room for optimization."




From sundaram at redhat.com  Tue Nov 15 10:17:36 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 15:47:36 +0530
Subject: FC5 and new init system
In-Reply-To: <dlcahl$cj4$1@sea.gmane.org>
References: <200511121134.57787.gbiczo@freestart.hu>	<4378728E.8050609@redhat.com>	<07ff01c5e93a$c72cbca0$b6491b31@td612671>	<4378C9C9.6050102@feuerpokemon.de>	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>	<1132003477.3092.2.camel@rousalka.dyndns.org>	<1132006766.13770.4.camel@ignacio.lan>
	<dlcahl$cj4$1@sea.gmane.org>
Message-ID: <4379B5C0.5030505@redhat.com>

Aurelien Bompard wrote:

>>>Will go AOL from now on ;)
>>>      
>>>
>>I'll throw my vote on as well, not because I have a (large) problem with
>>initscripts, but just for the coolness factor.
>>    
>>
>
>Should we setup a wiki page where everybody could vote ? ;o)
>Or a simple slashdot-like web poll system ? (that could actually be useful)
>
Helping in coding, testing, documentation and feedback helps drive the 
changes much more than merely voting for such changes.


regards
Rahul



From daner964 at student.liu.se  Tue Nov 15 10:26:26 2005
From: daner964 at student.liu.se (Daniel Malmgren)
Date: Tue, 15 Nov 2005 11:26:26 +0100
Subject: FC5 and new init system
Message-ID: <f993df631f23d.1f23df993df63@liu.se>

Hi all.
I'm responsible for rpm packaging of InitNG. I've followed this
discussion and just wanted to notice a few things.

I can't really see why everybody wants Harald to continue the efforts on
SystemManager. I don't know much about the project, but I can't really
see why time should be spent making competing init replacements when
there are good alternatives out there.

This is where I'd like to say a word for InitNG. InitNG it just half a
year old, but it's been progressing very fast. With the latest releases
it's starting to work very good out-of-the-box. I think you should take
a look at it. It installs just fine alongside with SysVinit, you've just
gotta choose in the Grub screen which init to use.

What the InitNG project really needs right now is a wider testing base!

/Daniel



From gauret at free.fr  Tue Nov 15 11:11:18 2005
From: gauret at free.fr (Aurelien Bompard)
Date: Tue, 15 Nov 2005 12:11:18 +0100
Subject: FC5 and new init system
References: <200511121134.57787.gbiczo@freestart.hu>	<4378728E.8050609@redhat.com>	<07ff01c5e93a$c72cbca0$b6491b31@td612671>	<4378C9C9.6050102@feuerpokemon.de>	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>	<1132003477.3092.2.camel@rousalka.dyndns.org>	<1132006766.13770.4.camel@ignacio.lan>
	<dlcahl$cj4$1@sea.gmane.org> <4379B5C0.5030505@redhat.com>
Message-ID: <dlcfom$sv1$1@sea.gmane.org>

Rahul Sundaram wrote:
> Helping in coding, testing, documentation and feedback helps drive the
> changes much more than merely voting for such changes.

Agreed, but this thread proves that letting people express their
support/enthusiasm for a project can be useful too.

Aur?lien.
-- 
http://aurelien.bompard.org  ~~~~  Jabber : abompard at jabber.fr
A Black Hole is where God divided by zero.




From sundaram at redhat.com  Tue Nov 15 11:22:12 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 16:52:12 +0530
Subject: FC5 and new init system
In-Reply-To: <f993df631f23d.1f23df993df63@liu.se>
References: <f993df631f23d.1f23df993df63@liu.se>
Message-ID: <4379C4E4.80605@redhat.com>

Daniel Malmgren wrote:

>Hi all.
>I'm responsible for rpm packaging of InitNG. I've followed this
>discussion and just wanted to notice a few things.
>
>I can't really see why everybody wants Harald to continue the efforts on
>SystemManager. I don't know much about the project, but I can't really
>see why time should be spent making competing init replacements when
>there are good alternatives out there.
>
>This is where I'd like to say a word for InitNG. InitNG it just half a
>year old, but it's been progressing very fast. With the latest releases
>it's starting to work very good out-of-the-box. I think you should take
>a look at it. It installs just fine alongside with SysVinit, you've just
>gotta choose in the Grub screen which init to use.
>
>What the InitNG project really needs right now is a wider testing base!
>
>/Daniel
>
>  
>
Would you or anyone else be interested in packaging InitNG in Fedora 
Extras? . Fedora does have a good amount of enthusiastic users who could 
provide feedback on this if this was just a matter of installing a few 
packages with yum in parallel to the current init system and making sure 
stuff doesnt  break.

regards
Rahul



From daner964 at student.liu.se  Tue Nov 15 11:27:07 2005
From: daner964 at student.liu.se (Daniel Malmgren)
Date: Tue, 15 Nov 2005 12:27:07 +0100
Subject: FC5 and new init system
In-Reply-To: <4379C4E4.80605@redhat.com>
References: <f993df631f23d.1f23df993df63@liu.se>
 <4379C4E4.80605@redhat.com>
Message-ID: <fa2a096919b7e.19b7efa2a0969@liu.se>


----- Original Message -----
From: Rahul Sundaram <sundaram at redhat.com>
Date: Tuesday, November 15, 2005 12:22 pm
Subject: Re: FC5 and new init system
To: Development discussions related to Fedora Core
<fedora-devel-list at redhat.com>
> Would you or anyone else be interested in packaging InitNG in 
> Fedora 
> Extras? . Fedora does have a good amount of enthusiastic users who 
> could 
> provide feedback on this if this was just a matter of installing a 
> few 
> packages with yum in parallel to the current init system and making 
> sure 
> stuff doesnt  break.

As a matter of fact I did some serious trying to get the initng rpm's
pretty enough for Fedora Extras a while ago (according to the guidelines
at http://fedoraproject.org/wiki/Extras/NewPackageProcess). I never got
rpmlint to like my rpm's though. I don't have much spare time, but if
anyone that is good at rpm building would just give me a hand with
fixing up the spec file, I'd be happy to maintain the package.

/Daniel



From sundaram at redhat.com  Tue Nov 15 11:36:11 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 17:06:11 +0530
Subject: FC5 and new init system
In-Reply-To: <fa2a096919b7e.19b7efa2a0969@liu.se>
References: <f993df631f23d.1f23df993df63@liu.se> <4379C4E4.80605@redhat.com>
	<fa2a096919b7e.19b7efa2a0969@liu.se>
Message-ID: <4379C82B.1060007@redhat.com>

Hi

>As a matter of fact I did some serious trying to get the initng rpm's
>pretty enough for Fedora Extras a while ago (according to the guidelines
>at http://fedoraproject.org/wiki/Extras/NewPackageProcess). I never got
>rpmlint to like my rpm's though. I don't have much spare time, but if
>anyone that is good at rpm building would just give me a hand with
>fixing up the spec file, I'd be happy to maintain the package.
>
>/Daniel
>  
>
Sure. Just submit the package to bugzilla or post in the extras list 
with the spec file for peer reviews. Not all rpmlint complaints are 
valid so dont let that put you off.

regards
Rahul



From buildsys at redhat.com  Tue Nov 15 12:33:51 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 15 Nov 2005 07:33:51 -0500
Subject: rawhide report: 20051115 changes
Message-ID: <200511151233.jAFCXpav012011@porkchop.devel.redhat.com>

New package libvte-java
	Wrapper library for GNOME VTE

New package mysql-connector-odbc
	ODBC driver for MySQL


Removed package perl-RPM2

Removed package selinux-policy-targeted

Removed package MyODBC

Removed package cdicconf

Removed package perl-XML-Encoding

Removed package perl-Parse-Yapp

Removed package taipeifonts

Updated Packages:

anaconda-10.89.15-1
-------------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 10.89.15-1
- fix up for new selinux policy

* Mon Nov 14 2005 Paul Nasrat <pnasrat at redhat.com> 10.89.14-1
- Move sorter for CD/pkgorder into yuminstall
- Add support for ub devices (katzj)

* Mon Nov 14 2005 Paul Nasrat <pnasrat at redhat.com> 10.89.13-1
- Reinstate image based install methods (excluding hd for now)
- Clean up install method classes
- device-mapper support (pjones)
- Log warning on no network link (katzj)
- Clean up error handling for pkgorder (clumens)

avahi-0.5.2-7
-------------
* Mon Nov 14 2005 Jason Vas Dias<jvdias at redhat.com> - 0.5.2-7
- fix bug 172034: fix ownership of /var/run/avahi-daemon/
- fix bug 172772: .spec file improvements from matthias at rpmforge.net

cman-kernel-2.6.14.0-20051108.134753.FC5.3
------------------------------------------

coreutils-5.93-2
----------------
* Mon Nov 14 2005 Tim Waugh <twaugh at redhat.com> 5.93-2
- Call setsid() in su under some circumstances (bug #173008).
- Prevent runuser operating when setuid (bug #173113).

cpuspeed-1:1.2.1-1.24
---------------------
* Mon Nov 14 2005 Dave Jones <davej at redhat.com>
- Don't try and load acpi-cpufreq if we have no throttling states.

cyrus-sasl-2.1.21-8
-------------------
* Mon Nov 14 2005 Nalin Dahyabhai <nalin at redhat.com> 2.1.21-8
- rebuild with new OpenLDAP, overriding the version checks to assume that
  2.3.11 is acceptable
- remove a lingering patch for 1.x which we no longer use

* Sat Nov 12 2005 Tom Lane <tgl at redhat.com> 2.1.21-7
- Rebuild due to mysql update.

device-mapper-multipath-0.4.4-2.4
---------------------------------
* Tue Nov 15 2005 Peter Jones <pjones at redhat.com> - 0.4.4-2.4
- split kpartx out into its own package

dump-0.4b40-5
-------------
* Mon Nov 14 2005 Jindrich Novy <jnovy at redhat.com> 0.4b40-5
- spec file cleanup - thanks to Matthias Saou (#172961)
- convert spec to UTF-8

fonts-chinese-3.02-1
--------------------
* Tue Nov 15 2005 Leon Ho <llch at redhat.com> - 3.02-1
- migrate taipeifonts to this package

* Mon Nov 14 2005 Warren Togami <wtogami at redhat.com> - 3.01-3
- rebuild against modular X

fonts-japanese-0.20050222-9
---------------------------
* Mon Nov 14 2005 Warren Togami <wtogami at redhat.com> - 0.20050222-9
- rebuild against modular X

fonts-korean-1.0.11-7
---------------------
* Mon Nov 14 2005 Warren Togami <wtogami at redhat.com> - 1.0.11-7
- mkfontdir for modular X

gnome-applets-1:2.12.1-3
------------------------
* Mon Nov 14 2005 Ray Strode <rstrode at redhat.com> - 1:2.12.1-3
- build correct command string for cpufreq-selection. Fix
  spotted by Ingo Schaefer <ingo at ingo-shaefer.de> (Bug 164147).

gnome-user-share-0.8-1
----------------------
* Mon Nov 14 2005 Alexander Larsson <alexl at redhat.com> - 0.8-1
- update to 0.8

isdn4k-utils-3.2-35
-------------------
* Mon Nov 14 2005 Than Ngo <than at redhat.com> 3.2-35
- fix for modular X

* Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
- rebuild

* Tue Sep 13 2005 Than Ngo <than at redhat.com> 3.2-33
- cleanup %post

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_53rh
------------------------------------------
* Mon Nov 14 2005 Thomas Fitzsimmons <fitzsim at redhat.com> 0:1.4.2.0-40jpp_53rh
- Bump release number.

* Mon Nov 14 2005 Thomas Fitzsimmons <fitzsim at redhat.com> - 0:1.4.2.0-40jpp_52rh
- Import java-gcj-compat 1.0.44.
- Make aot-compile-rpm and rebuild-gcj-db real scripts, not
  alternatives symlinks.
- Put rebuild-gcj-db in base package.

jonas-0:4.3.3-1jpp_15fc
-----------------------
* Fri Nov 11 2005 Gary Benson <gbenson at redhat.com> - 4.3.3-1jpp_15fc
- Allow clean shutdowns (from Andrew Haley).

kernel-2.6.14-1.1674_FC5
------------------------
* Tue Nov 15 2005 David Woodhouse <dwmw2 at redhat.com>
- More PPC vDSO fixes

* Mon Nov 14 2005 Dave Jones <davej at redhat.com>
- Enable USB storage,UB & libusual magick.
- Disable busted HFC-S USB based HiSAX ISDN driver.

libsemanage-1.3.53-3
--------------------
* Mon Nov 14 2005 Dan Walsh <dwalsh at redhat.com> 1.3.53-3
- Add genhomedircon patch from Joshua Brindle

linuxwacom-0:0.6.6-7
--------------------
* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 0:0.6.6-7
- require implementation independent Xserver instead of xorg-x11

microcode_ctl-1:1.12-1.24
-------------------------
* Mon Nov 14 2005 Dave Jones <davej at redhat.com>
- initscript tweaks.

mysql-5.0.15-3
--------------
* Mon Nov 14 2005 Tom Lane <tgl at redhat.com> 5.0.15-3
- Make stop script wait for daemon process to disappear (bz#172426)

ncpfs-2.2.6-1
-------------
* Fri Nov 11 2005 Martin Stransky <stransky at redhat.com> 2.2.6-1
- new upstream

net-snmp-5.2.2-0.rc5.1
----------------------
* Tue Nov 15 2005 Radek Vokal <rvokal at redhat.com> - 5.2.2-0.rc5.1
- another release candidate

nmap-2:3.93-3
-------------
* Fri Nov 11 2005 Harald Hoyer <harald at redhat.com> - 2:3.93-3
- fixed wrong __attribute__ test

openoffice.org-1:2.0.1-0.139.1.2
--------------------------------
* Tue Nov 08 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.139.1
- drop integrated openoffice.org-1.9.108.ooo47323.binfilter.stupiddetect.patch
- openoffice.org-1.9.97.ooo48600.rtfparseerror.svx.patch -> javapatch
- drop integrated openoffice.org-1.9.112.ooo53025.exception.package.patch
- gcc#22132# fixed
	+ drop openoffice.org-1.9.84.ooo44843.sdcasting.patch
	+ drop openoffice.org-1.9.84.ooo44846.svxcasting.patch
	+ drop openoffice.org-1.9.84.ooo45162.svxcasting2.patch
- workaround deprecated openldap api usage
- add industrial set of icons

policycoreutils-1.27.27-5
-------------------------
* Mon Nov 14 2005 Dan Walsh <dwalsh at redhat.com> 1.27.27-5
- Fix genhomedircon to work with non libsemanage systems

python-pyblock-0.5-1
--------------------
* Fri Nov 11 2005 Peter Jones <pjones at redhat.com> - 0.5-1
- make it possible to easily build dm maps from dmraid tables
- support for partition table scanning

rhpl-0.177-1
------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 0.177-1
- call setxkbmap by searching path instead of exact location since it moves 
  with modular X

samba-0:3.0.20b-2
-----------------
* Sun Nov 13 2005 Jay Fenlason <fenlason at redhat.com> 3.0.20b-2
- turn on -DLDAP_DEPRECATED to allow access to ldap functions that have
  been depricated in 2.3.11, but which don't have well-documented
  replacements (ldap_simple_bind_s(), for example).
- Upgrade to 3.0.20b, which includes all the previous upstream patches.
- Updated the -warnings patch for 3.0.20a.
- Include  --with-shared-modules=idmap_ad,idmap_rid to close
  bz#156810 --with-shared-modules=idmap_ad,idmap_rid
- Include the new samba.pamd from Tomas Mraz (tmraz at redhat.com) to close
  bz#170259 pam_stack is deprecated

scim-1.4.2-7
------------
* Mon Nov 14 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-7
- make "reload config" reload IMEs with scim-reload-engines-165655.patch
  (Qian Shen, #165655)
- add iiimf obsoletes for upgrading

* Tue Nov 01 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-6
- avoid errors in postun script when uninstalling

* Thu Oct 06 2005 Jens Petersen <petersen at redhat.com> - 1.4.2-5
- fixing quoting in scim-restart
- make post and postun scripts for scim-libs

scim-anthy-0.7.1-2.fc5
----------------------
* Mon Nov 14 2005 Akira TAGOH <tagoh at redhat.com> - 0.7.1-2
- added Obsoletes: iiimf-le-canna <= 12.2 to ensure the upgrade path.

scim-chewing-0.2.1-3
--------------------
* Mon Nov 14 2005 Jens Petersen <petersen at redhat.com> - 0.2.1-3
- obsoletes iiimf-le-xcin for upgrades

scim-hangul-0.2.1-2.fc5
-----------------------
* Mon Nov 14 2005 Akira TAGOH <tagoh at redhat.com> - 0.2.1-2
- added Obsoletes: iiimf-le-hangul <= 12.2 to ensure the upgrade path.

scim-pinyin-0.5.91-3
--------------------
* Mon Nov 14 2005 Jens Petersen <petersen at redhat.com> - 0.5.91-3
- add obsoletes iiimf-le-chinput for upgrades

scim-qtimm-0.9.4-2
------------------
* Mon Nov 14 2005 Jens Petersen <petersen at redhat.com> - 0.9.4-2
- add obsoletes iiimf-qt for upgrades (#173071)

scim-tables-0.5.4-2
-------------------
* Mon Nov 14 2005 Jens Petersen <petersen at redhat.com> - 0.5.4-2
- add obsoletes iiimf-le-unit for upgrades (#173071)

selinux-policy-2.0.0-1
----------------------

system-config-cluster-1.0.17-1.0
--------------------------------
* Mon Nov 14 2005 Jim Parsons <jparsons at redhat.com> 1.0.17-1
-  Fix for bz169139, and Version Bump - Build for Fedora.

* Mon Sep 12 2005 Jim Parsons <jparsons at redhat.com> 1.0.16-1
-  Fix for bz167476.

* Mon Sep 12 2005 Stanko Kupcevic <kupcevic at redhat.com> 1.0.16-1
-  Fix for bz159965, 167742, 161784, 167739, 159781.

system-config-lvm-1.0.8-1.0
---------------------------
* Mon Nov 14 2005 Jim Parsons <jparsons at redhat.com> 1.0.8-1.0
- Fixes for bz171744,171746,171747,171751,171753,171754,171755,171758,159457

xchat-1:2.6.0-2
---------------
* Tue Nov 15 2005 Florian La Roche <laroche at redhat.com> 1:2.6.0-2
- Require(post): GConf2

xen-3.0-0.20051109.fc5.3
------------------------
* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 3.0-0.20051109.fc5.3
- change default dom0 min-mem to 256M so that dom0 will try to balloon down

* Sat Nov 12 2005 Jeremy Katz <katzj at redhat.com>
- buildrequire ncurses-devel (reported by Justin Dearing)

Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	magma - 1.0.2-3.ppc64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ppc64 requires libmagmamsg.so()(64bit)



Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.3.i686 requires /lib/modules/2.6.14-1.1665_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.3.i686 requires kernel = 0:2.6.14-1.1665_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1665_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.3.i686 requires /lib/modules/2.6.14-1.1665_FC5smp
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5



Broken deps for ia64
----------------------------------------------------------
	magma - 1.0.2-3.ia64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.ia64 requires libmagmamsg.so()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	magma - 1.0.2-3.x86_64 requires libmagma.so()(64bit)
	magma - 1.0.2-3.x86_64 requires libmagmamsg.so()(64bit)











From dimi at lattica.com  Tue Nov 15 14:38:27 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 15 Nov 2005 09:38:27 -0500
Subject: rawhide report: 20051115 changes
References: <200511151233.jAFCXpav012011@porkchop.devel.redhat.com>
Message-ID: <00c201c5e9f2$46eafd50$b6491b31@td612671>

From: "Build System" <buildsys at redhat.com>
> Removed package selinux-policy-targeted

OK, I'll bite: what happened to this policy?
Any docs on the new direction?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc. 



From selinux at gmail.com  Tue Nov 15 14:42:40 2005
From: selinux at gmail.com (Tom London)
Date: Tue, 15 Nov 2005 06:42:40 -0800
Subject: rawhide report: 20051115 changes
In-Reply-To: <00c201c5e9f2$46eafd50$b6491b31@td612671>
References: <200511151233.jAFCXpav012011@porkchop.devel.redhat.com>
	<00c201c5e9f2$46eafd50$b6491b31@td612671>
Message-ID: <4c4ba1530511150642n4b2c326dn9b61b8ab281a881a@mail.gmail.com>

On 11/15/05, Dimi Paun <dimi at lattica.com> wrote:
> From: "Build System" <buildsys at redhat.com>
> > Removed package selinux-policy-targeted
>
> OK, I'll bite: what happened to this policy?
> Any docs on the new direction?
>
> --
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
>
When you do the 'yum', it says that selinux-policy-targeted-sources
gets 'replaced' by the new package. Nothing sinister, except the
source package appears to be gone.

tom
--
Tom London



From johnp at redhat.com  Tue Nov 15 14:43:41 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Tue, 15 Nov 2005 09:43:41 -0500
Subject: FC5 and new init system
In-Reply-To: <4379C82B.1060007@redhat.com>
References: <f993df631f23d.1f23df993df63@liu.se> <4379C4E4.80605@redhat.com>
	<fa2a096919b7e.19b7efa2a0969@liu.se>  <4379C82B.1060007@redhat.com>
Message-ID: <1132065821.8333.81.camel@remedyz.boston.redhat.com>

Cool.  I'll be the first on the bus to start testing these if they get
into extras.

On Tue, 2005-11-15 at 17:06 +0530, Rahul Sundaram wrote:
> Hi
> 
> >As a matter of fact I did some serious trying to get the initng rpm's
> >pretty enough for Fedora Extras a while ago (according to the guidelines
> >at http://fedoraproject.org/wiki/Extras/NewPackageProcess). I never got
> >rpmlint to like my rpm's though. I don't have much spare time, but if
> >anyone that is good at rpm building would just give me a hand with
> >fixing up the spec file, I'd be happy to maintain the package.
> >
> >/Daniel
> >  
> >
> Sure. Just submit the package to bugzilla or post in the extras list 
> with the spec file for peer reviews. Not all rpmlint complaints are 
> valid so dont let that put you off.
> 
> regards
> Rahul

-- 
John (J5) Palmieri <johnp at redhat.com>



From sundaram at redhat.com  Tue Nov 15 14:43:45 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 20:13:45 +0530
Subject: rawhide report: 20051115 changes
In-Reply-To: <00c201c5e9f2$46eafd50$b6491b31@td612671>
References: <200511151233.jAFCXpav012011@porkchop.devel.redhat.com>
	<00c201c5e9f2$46eafd50$b6491b31@td612671>
Message-ID: <4379F421.50302@redhat.com>

Dimi Paun wrote:

>From: "Build System" <buildsys at redhat.com>
>  
>
>>Removed package selinux-policy-targeted
>>    
>>
>
>OK, I'll bite: what happened to this policy?
>Any docs on the new direction?
>
>  
>
Selinux-policy SRPM generates both the targeted, strict, mcs and mls 
binary RPMS now. Other than that, there isnt a new direction. In a 
similar way other packages like taipeifonts has been renamed into 
fonts-chinese.

regards
Rahul



From ph18 at cornell.edu  Tue Nov 15 14:45:22 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 15 Nov 2005 09:45:22 -0500
Subject: FC5 and new init system
In-Reply-To: <1132006766.13770.4.camel@ignacio.lan>
References: <200511121134.57787.gbiczo@freestart.hu>	<4378728E.8050609@redhat.com>
	<07ff01c5e93a$c72cbca0$b6491b31@td612671>	<4378C9C9.6050102@feuerpokemon.de>	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>	<1132003477.3092.2.camel@rousalka.dyndns.org>
	<1132006766.13770.4.camel@ignacio.lan>
Message-ID: <4379F482.8060501@cornell.edu>

Ignacio Vazquez-Abrams wrote:

>
>I'll throw my vote on as well, not because I have a (large) problem with
>initscripts, but just for the coolness factor.
>  
>
    I'd love to see an init system that can do parallel boot and service 
monitoring.

    At some point,  I often end up installing djb's daemontools on 
machines that I administer.  Sometimes this is because I install other 
djb software,  sometimes because I need the service monitoring.

    On the other hand,  a bad init system could make my life miserable,  
so I'd move carefully in this department.  I've been hearing bad things 
about the system in Solaris 10,  for instance.  I'd hate to have to 
write new init scripts for all the software I run -- even though 
dependency awareness is necessary for parallel boot,  I'd want the 
ability to break the dependency rules when I want to break them.



From linux_4ever at yahoo.com  Tue Nov 15 15:10:45 2005
From: linux_4ever at yahoo.com (Steve G)
Date: Tue, 15 Nov 2005 07:10:45 -0800 (PST)
Subject: rawhide report: 20051115 changes
In-Reply-To: <4379F421.50302@redhat.com>
Message-ID: <20051115151045.25656.qmail@web51504.mail.yahoo.com>


>Selinux-policy SRPM generates both the targeted, strict, mcs and mls 
>binary RPMS now. Other than that, there isnt a new direction.

Actually, there is. This package is different in that its now using the
(standard) reference policy that's been under development during the summer.
Theoretically, everything should just work. But the new policy does have new
macros, tightens things slightly differently in some places, and is designed to
be a little more secure. More info here: http://serefpolicy.sourceforge.net/

-Steve


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



From jwboyer at jdub.homelinux.org  Tue Nov 15 15:17:22 2005
From: jwboyer at jdub.homelinux.org (Josh Boyer)
Date: Tue, 15 Nov 2005 09:17:22 -0600
Subject: Mono, not in fedora / extra's yet?
In-Reply-To: <10068.194.109.162.8.1132067559.squirrel@webmail.xs4all.nl>
References: <10068.194.109.162.8.1132067559.squirrel@webmail.xs4all.nl>
Message-ID: <1132067842.2893.0.camel@windu.rchland.ibm.com>

On Tue, 2005-11-15 at 16:12 +0100, Chris Chabot wrote:
> Hey guys,
> 
> Has there ever been a discussion about including Mono and its related
> tools in fedora extra's?
> 
> Novell has some fedora&rh packages, though they do not function on FC5,
> and aren't a part of fedora-*, nor are the src.rpm's available.
> Novell's packages for rh/suse/fedora can be found here: 
> http://www.mono-project.com/Downloads
> 
> Would it be an idea to create packages for fedora-extras for mono and
> related packages? I'd be happy to volunteer if so
> 
> This would allow us to use some wonderful tools out there like F-Spot (
> http://www.gnome.org/projects/f-spot/ ) and Beagle (
> http://www.beagle-project.org/Main_Page )
> 
> I'd love to get some feedback before i go packaging crazy

http://fedoraproject.org/wiki/ForbiddenItems

josh



From toshio at tiki-lounge.com  Tue Nov 15 16:00:34 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 15 Nov 2005 08:00:34 -0800
Subject: How to simplify the process of adding multilingual
	%descriptions to rpm spec?
In-Reply-To: <Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>
	<Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>
Message-ID: <1132070434.10457.54.camel@localhost>

On Mon, 2005-11-14 at 15:04 -0500, Elliot Lee wrote:
> On Tue, 8 Nov 2005, Yuan Yijun wrote:
> 
> > Greetings,
> > 
> > I believe that non-English speakers will be more happy to see
> > localized package %descriptions, when they are using a GUI package
> > management program. Most of users play Linux for fun, and they are
> > willing to search software in the huge packages list, looking for
> > interesting packages to install. But this fun only belongs to English
> > speakers. To Chinese, there is no way for an software package to
> > introduce itself.
> > 
> > Then how can these %descriptions be localized? If someone translate
> > them and commit patches to rpm spec files, that seems a bit funny and
> > boring. (Sorry for my bad vocabulary, though the single filed rpm spec
> > does have its cons and pros.) How to simplify this and reduce the
> > amount of work?
> >
> > (There are too many excellent programs in both Core and Extras, while
> > I'm trying to introduce them to other Chinese users, I believe this
> > problem is essential.)
> 
> Currently, specspo is meant to be the means by which package strings are
> translated. However, specspo has not been maintained in a long time and
> could use a lot of love. If someone wants to pick it back up, the work
> that needs to be done is a fairly well understood problem. It's just a LOT 
> OF WORK. :)

For Extras (with it's rolling release), specspo's issues are more
pronounced than in Core.  Core has a string freeze before release that
Extras (which doesn't have a "release") lacks so translations would get
out of sync.

End-user Goals:
1) See package descriptions in the user's native language.
2) End-users don't end up downloading an update just because the
translations change.
3) End-users don't end up downloading updated specspo because
translations for a language/package they don't use is updated.

Packager Goals:
1) Transparent.  The packager does not have to think about translations.
They just happen.

Translator Goals:
1) Notification of package string changes.
2) Ability to own a package-translation similar to how other packagers
own a package.

Packager and translator goals seem like they could be solved with good
infrastructure.  Add a check for string changes into make build or make
tag that extracts necessary information and hands them off to a
translation system that emails translators of changes, updates websites,
etc.

The end-user goals point at the drawbacks of both in-package
translations and the specspo centralized translations.  Alternatives
that spring to mind: 

perpackage-perlanguage specspo.  No more downloading of unnecessary
files but it seems pretty darn unattractive.  Lots of rpm metadata
overhead, multiple new packages for each existing package...  Just say
ick.

Auto-merging of translations at make build if the description hasn't
changed:  translations are kept separate from the spec file.  When make
build is run, if the spec %description has been updated, a message is
sent to the responsible translator to update.  Otherwise the translation
is merged with the spec file and the build started.  Translations will
always lag packaging changes, but this works when %description doesn't
change too often.  Could be annoying to end-users who read a description
of one version of a package in their native language but when they go to
install on another machine, the description is in English (because the
English description was updated.)

perlanguage specspo.  The end user still has to keep it updated anytime
a description changes.  The package could be rebuilt on a time/change
basis (ie: once a month when changes occured in that month.)

Talk with Seth about pushing the issue out to rpm-metadata.  End-users
are already downloading new versions of the metadata anytime a string
changes.  rpm-metadata aware applications (yum, yumex, smart) will be
the most frequent interfaces to the packages and could see the
translations (but rpm would not).  Would localized versions of the
metadata (in separate language files) cause issues?  Currently
createrepo creates the rpm-metadata by parsing the packages.  If the
translations weren't in the packages then this is a significant
departure....

Any other ideas?

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051115/62f48ac2/attachment.sig>

From fedora-devel at tlarson.com  Tue Nov 15 16:20:07 2005
From: fedora-devel at tlarson.com (Tyler Larson)
Date: Tue, 15 Nov 2005 09:20:07 -0700
Subject: FC5 and new init system
In-Reply-To: <1132042399.3461.3.camel@mentorng.gurulabs.com>
References: <200511121134.57787.gbiczo@freestart.hu>	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>	<1132003477.3092.2.camel@rousalka.dyndns.org>	<200511141456.58917.lamont@gurulabs.com>
	<1132042399.3461.3.camel@mentorng.gurulabs.com>
Message-ID: <437A0AB7.7070701@tlarson.com>

Dax Kelson wrote:
> On Mon, 2005-11-14 at 14:56 -0700, Lamont R. Peterson wrote:
>> On Monday 14 November 2005 02:24pm, Nicolas Mailhot wrote:
>>> Same here. A lot of people were holding their breath for this, trying
>>> not to scare you off - seems it didn't have the intended effect.
>>>
>>> Will go AOL from now on ;)
>> Or we could all just hit Harald's <harald at redhat.com> email directly with our 
>> AOL "Me too"'s and spare the list. ;)
>>
>> You'll get at least 7 votes from us at Guru Labs; as long as there is no XML 
>> in it.
> 
> Well, more accurately, as long as it doesn't suck. :)
> 
> The devil is in the design and implementation details ... yadda yadda.
> 
> Dax Kelson
> 

Which, of course, brings up the question of what the details actually are.
When we say, "replace SysVinit", is everyone actually talking about replacing
init, or do we think we're talking about replacing initscripts (which is an
entirely different beast altogether).

I would vote for leaving init alone, but doing a more dependency-based startup
procedure, kind of like *ahem* gentoo.

When its all said and done, however this is accomplished, I would really like
to see services start up in parallel. It would really help our boot-up time.
Even Windows does this... why not Fedora?



From sundaram at redhat.com  Tue Nov 15 16:26:55 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 21:56:55 +0530
Subject: FC5 and new init system
In-Reply-To: <437A0AB7.7070701@tlarson.com>
References: <200511121134.57787.gbiczo@freestart.hu>	<40235.82.93.41.202.1131991607.squirrel@secure.allset.nl>	<1132003477.3092.2.camel@rousalka.dyndns.org>	<200511141456.58917.lamont@gurulabs.com>	<1132042399.3461.3.camel@mentorng.gurulabs.com>
	<437A0AB7.7070701@tlarson.com>
Message-ID: <437A0C4F.2050106@redhat.com>

Hi

>Which, of course, brings up the question of what the details actually are.
>When we say, "replace SysVinit", is everyone actually talking about replacing
>init, or do we think we're talking about replacing initscripts (which is an
>entirely different beast altogether).
>
>I would vote for leaving init alone, but doing a more dependency-based startup
>procedure, kind of like *ahem* gentoo.
>
The earlier discussion that happened in this list listed out the 
details. Check the archives. Also this page
http://fedoraproject.org/wiki/FCNewInit

regards
Rahul



From sundaram at redhat.com  Tue Nov 15 16:27:38 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 15 Nov 2005 21:57:38 +0530
Subject: rawhide report: 20051115 changes
In-Reply-To: <20051115151045.25656.qmail@web51504.mail.yahoo.com>
References: <20051115151045.25656.qmail@web51504.mail.yahoo.com>
Message-ID: <437A0C7A.9020209@redhat.com>

Steve G wrote:

>>Selinux-policy SRPM generates both the targeted, strict, mcs and mls 
>>binary RPMS now. Other than that, there isnt a new direction.
>>    
>>
>
>Actually, there is. This package is different in that its now using the
>(standard) reference policy that's been under development during the summer.
>Theoretically, everything should just work. But the new policy does have new
>macros, tightens things slightly differently in some places, and is designed to
>be a little more secure. More info here: http://serefpolicy.sourceforge.net/
>
>-Steve
>  
>
Right. I was aware of those changes. Should have been more specific.

regards
Rahul



From nicolas.mailhot at laposte.net  Tue Nov 15 16:55:24 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 15 Nov 2005 17:55:24 +0100 (CET)
Subject: How to simplify the process of adding multilingual 
 %descriptions to rpm spec?
In-Reply-To: <1132070434.10457.54.camel@localhost>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>
	<Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>
	<1132070434.10457.54.camel@localhost>
Message-ID: <60311.192.54.193.35.1132073724.squirrel@rousalka.dyndns.org>

I honestly think the only scalable solution is in-package translation. It
does not have to be in the spec file, could be in another set of files in
the package, but it can not be pushed out of the package.

All the solutions that push this info out of packages rely on some central
authority, either at the distribution level (specspo) or at the repository
level (yum metadata). These approaches try very hard to ignore the
reality. The reality is people download and assemble packages by all the
ways imaginable, burn them on CDs, create package archive/mirrors, rebuild
tweaked SRPMS, sometimes index them with createrepo at last but the basic
unit is the package and anything not included in the package itself is
bound to be lost.

I know it's an unpalatable reality since life would be so much easier for
translators if they could ignore the distribution problem. Ignore it
however and you'll hit the same dead-end as specspo

What would be possible for example would be to attach a translation to an
existing package like you do for signatures. However great care should be
taken so when you rebuild the package the translation is not lost (ie rpm
-Uvh x.src.rpm adds the translation to SOURCES). This would permit
incremental translation, without breaking the package unit distribution
paradigm.

Regards,

-- 
Nicolas Mailhot



From mitr at volny.cz  Tue Nov 15 17:36:09 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Tue, 15 Nov 2005 18:36:09 +0100
Subject: How to simplify the process of adding multilingual	%descriptions
 to rpm spec?
In-Reply-To: <1132070434.10457.54.camel@localhost>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>	<Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>
	<1132070434.10457.54.camel@localhost>
Message-ID: <437A1C89.4000605@volny.cz>

Toshio Kuratomi wrote:
> Translator Goals:
> 1) Notification of package string changes.
> 2) Ability to own a package-translation similar to how other packagers
> own a package.
As a translator, I don't think this is what I want.
1) We already have infrastructure to show translation status, without
   explicit notification.  Explicit notification would just result in
   a lot of daily emails.
All that is necessary is regular (daily/weekly) rebuild of the list of
strings to translate, and a regular incorrporation of translated
messages to the repository (in whatever form).

2) No, I certainly don't want to handle 1237 separate "translation
   packages" in 1237 separate files.
The specspo model of a single file actually suits translators quite well
(e.g. it allows automated translation matching on package renames).
Maybe we could split the large .po file to allow better collaboration,
e.g. to 26 .po files, selecting packages by the first letter of their name.
	Mirek



From cfeist at redhat.com  Tue Nov 15 17:42:52 2005
From: cfeist at redhat.com (Chris Feist)
Date: Tue, 15 Nov 2005 11:42:52 -0600
Subject: rawhide report: 20051113 changes
In-Reply-To: <1131939338.23974.11.camel@ignacio.lan>
References: <200511131222.jADCMPeC006399@porkchop.devel.redhat.com>	<20051113142301.47e372cb@python2>
	<1131939338.23974.11.camel@ignacio.lan>
Message-ID: <437A1E1C.8040107@redhat.com>

Changes were made in the build (upstream) that caused the soname to be 
libmagma.1.0.0 instead of libmagma.1.0 (this should be fixed in magma-1.0.3).

Thanks,
Chris

Ignacio Vazquez-Abrams wrote:
> On Sun, 2005-11-13 at 14:23 +0100, Matthias Saou wrote:
> 
>>Build System wrote :
>>
>>
>>>magma-1.0.2-3
>>>-------------
>>>* Sat Nov 12 2005 Florian La Roche <laroche at redhat.com>
>>>- added Provides: to solve dep issues, maybe sonames should be
>>>  added to the shared libs
>>
>>I'd say they should indeed : That "workaround" doesn't work for 64bit
>>archs... and doing something like "test %{_lib} = lib64" or
>>enumerating all known 64bit archs is oh so ugly :-)
> 
> 
> I was taking a look at magma for someone, and the problem isn't with the
> libraries, it's with the test apps. For some reason they're requiring
> the libraries with .so even though the .so.SONAME libraries are there. I
> suspect that the build process might be copying the built libraries
> instead of linking them.
> 
> 



From lmacken at redhat.com  Tue Nov 15 20:44:05 2005
From: lmacken at redhat.com (Luke Macken)
Date: Tue, 15 Nov 2005 15:44:05 -0500
Subject: init observations
Message-ID: <20051115204405.GA18220@lewk.org>

I've been playing around with initng quite a bit lately and have had a
good amount of luck getting it running successfully on my rawhide laptop, a
VMWare test environment, and my FC4 desktop.  Had a few issues right off the
bat, but eventually worked most of them out (thanks to the help of
Daniel Malmgren).  I believe fedora related patches even hit their repos
as well.

Here's what I've seen so far...

initng - http://initng.thinktux.net
======
Pros
 o Dynamic service dependencies
 o Service monitoring
 o Automatic respawning of services
 o Parallelized service startup
 o Plugin support
 o Very active and helpful community
   - Extremely open to getting initng working by default in Fedora
 o Supports /etc/rc.* scripts via a plugin, but uses it's own format by
   default (also supports xml init scripts via plugin)
 o FAST AS HELL[0]

Cons
 o Gentoo look-and-feel (brings back old memories)
   - Having such an open-minded community, giving initng a more
     unified/professional feel would hopefully be accepted
 o No inherent D-BUS support
   - initng's plugin support would allow this to be accomplished (but I
     would bring it up to the developers; who knows, they might want it
     upstream?)

- - -

After talking with Harald about his SystemManager, apparently he hasn't
actually gotten it complete enough to successfully start a system with
it yet, but he kindly answered all of the questions I had.

SystemManager - :pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS servicemanager
=============
Pros
 o /etc/rc replacement; so integration into our current SysVinit setup
   would be close to trivial
 o Will work with our current init scripts without modification
 o Automatic/On-demand respawing of services
 o Exporting of services as D-BUS objects
 o Dynamic service dependencies

Cons
 o Not complete/tested
 o Still supports the /etc/rc.d/rc$i.d framework (which is horrible by
   design)

- - -

I'm sure I missed many aspects of the init/bootup procedure in the above
observations, as this is far from a complete analysis.  Please jump in if
you have any additional observations/questions/comments/corrections.

So.. our first step ?

Getting initng into extras definitely won't hurt.  It will give everyone
a chance to play it with, and hopefully will help work most of the kinks out.
As far as SystemManager goes; it's definitely a project with lots of
potential, and if the demand is there, I'm ready to start hacking.

What does everyone else think ?


luke

[0]: I generated bootcharts for a default FC4 install with minimal
tweaking (removed a few unnecessary services) and FC4 with a
default initng install.  These are in no way supposed to be an accurate
measurement of the true speeds of either of these versions of init
(they are also both running different init scripts).

http://people.redhat.com/lmacken/initng-bootchart.png
http://people.redhat.com/lmacken/SysVinit-bootchart.png



From notting at redhat.com  Tue Nov 15 20:51:56 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 15 Nov 2005 15:51:56 -0500
Subject: init observations
In-Reply-To: <20051115204405.GA18220@lewk.org>
References: <20051115204405.GA18220@lewk.org>
Message-ID: <20051115205156.GA3978@devserv.devel.redhat.com>

Luke Macken (lmacken at redhat.com) said: 
> I've been playing around with initng quite a bit lately and have had a
> good amount of luck getting it running successfully on my rawhide laptop, a
> VMWare test environment, and my FC4 desktop.  Had a few issues right off the
> bat, but eventually worked most of them out (thanks to the help of
> Daniel Malmgren).  I believe fedora related patches even hit their repos
> as well.
> 
> Here's what I've seen so far...
> 
> initng - http://initng.thinktux.net
> ======
> Pros
>  o Dynamic service dependencies
>  o Service monitoring
>  o Automatic respawning of services
>  o Parallelized service startup
>  o Plugin support
>  o Very active and helpful community
>    - Extremely open to getting initng working by default in Fedora
>  o Supports /etc/rc.* scripts via a plugin, but uses it's own format by
>    default (also supports xml init scripts via plugin)
>  o FAST AS HELL[0]
> 
> Cons
>  o Gentoo look-and-feel (brings back old memories)
>    - Having such an open-minded community, giving initng a more
>      unified/professional feel would hopefully be accepted
>  o No inherent D-BUS support
>    - initng's plugin support would allow this to be accomplished (but I
>      would bring it up to the developers; who knows, they might want it
>      upstream?)

One of the ideas was that eventually services would expose
*themselves* over d-bus without wrappers, and that would be the
native management framework. I'm not sure how that would fit into
this model. It could be something to look at, though.

> [0]: I generated bootcharts for a default FC4 install with minimal
> tweaking (removed a few unnecessary services) and FC4 with a
> default initng install.  These are in no way supposed to be an accurate
> measurement of the true speeds of either of these versions of init
> (they are also both running different init scripts).
> 
> http://people.redhat.com/lmacken/initng-bootchart.png
> http://people.redhat.com/lmacken/SysVinit-bootchart.png

Hm, comparing against a SysVinit bootup *without* rhgb might
be interesting, as it's known that that adds to the startup time.

Bill



From dimi at lattica.com  Tue Nov 15 21:11:06 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 15 Nov 2005 16:11:06 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org>
Message-ID: <028301c5ea29$18a2d350$b6491b31@td612671>

From: "Luke Macken" <lmacken at redhat.com>
> I'm sure I missed many aspects of the init/bootup procedure in the above
> observations, as this is far from a complete analysis.  Please jump in if
> you have any additional observations/questions/comments/corrections.
> 
> So.. our first step ?

I think we need to make a choice and go with it. Encouraging multiple
solutions at this point will only dilute the focus, and confuse users. 

What do we need to do to pick something and go with it? It looks like
initng is 'close enough', how about approaching the developers and see
how willing they are to integrate D-BUS in it? What about Bill's 
suggestion? It looks like SystemManager does that, no?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From dimi at lattica.com  Tue Nov 15 21:12:13 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 15 Nov 2005 16:12:13 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org>
Message-ID: <028701c5ea29$404130a0$b6491b31@td612671>

From: "Luke Macken" <lmacken at redhat.com>
>  o FAST AS HELL[0]


Fast, but can we do better? Why do we need to bring up
the networking before we start X? Also, is it feasible
to probe for just some hardware (disk, video), start x,
then continue with the hardware probing? Will it be any
faster if we get rid of the wrappers? Would readahead
help here at all?

Basically, can we have X up in 10s? :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From notting at redhat.com  Tue Nov 15 21:14:19 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 15 Nov 2005 16:14:19 -0500
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <20051115211419.GB13874@devserv.devel.redhat.com>

Dimi Paun (dimi at lattica.com) said: 
> From: "Luke Macken" <lmacken at redhat.com>
> >  o FAST AS HELL[0]
> 
> 
> Fast, but can we do better? Why do we need to bring up
> the networking before we start X? Also, is it feasible
> to probe for just some hardware (disk, video), start x,
> then continue with the hardware probing?

What 'hardware probing' are you talking about here? We
just load all relevant modules, splitting it up will
probably just cause more complication and slow things
down.

Bill



From mike at miketc.com  Tue Nov 15 21:15:57 2005
From: mike at miketc.com (Mike Chambers)
Date: Tue, 15 Nov 2005 15:15:57 -0600
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <1132089357.3042.0.camel@scrappy.miketc.com>

On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:

> Fast, but can we do better? Why do we need to bring up
> the networking before we start X? Also, is it feasible
> to probe for just some hardware (disk, video), start x,
> then continue with the hardware probing? Will it be any
> faster if we get rid of the wrappers? Would readahead
> help here at all?
> 
> Basically, can we have X up in 10s? :)

Not a developer or programmer, but what about those systems that use
x/fonts from a server and not on the workstation?  How would X start
without networking capabilities?

-- 
Mike Chambers
Madisonville, KY

"It's better to hurt a little now, than to hurt a lot later!"



From shiva at sewingwitch.com  Tue Nov 15 21:19:24 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 15 Nov 2005 13:19:24 -0800
Subject: init observations
In-Reply-To: <1132089357.3042.0.camel@scrappy.miketc.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132089357.3042.0.camel@scrappy.miketc.com>
Message-ID: <1ABFFCC1CF72F107BABFBB04@[10.169.6.233]>

--On Tuesday, November 15, 2005 3:15 PM -0600 Mike Chambers 
<mike at miketc.com> wrote:

> Not a developer or programmer, but what about those systems that use
> x/fonts from a server and not on the workstation?  How would X start
> without networking capabilities?

What does it currently do if your font server is unreachable? Does it wait, 
or fall back to local fonts until it can reach the server? Or just fall 
over?




From shiva at sewingwitch.com  Tue Nov 15 21:22:55 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Tue, 15 Nov 2005 13:22:55 -0800
Subject: init observations
In-Reply-To: <20051115204405.GA18220@lewk.org>
References: <20051115204405.GA18220@lewk.org>
Message-ID: <2599004567060172327E6DED@[10.169.6.233]>

--On Tuesday, November 15, 2005 3:44 PM -0500 Luke Macken 
<lmacken at redhat.com> wrote:

>  o Still supports the /etc/rc.d/rc$i.d framework (which is horrible by
>    design)

What do packagers of services need to do to natively support the 
alternatives? Presumably they need to supply the native equivalent to the 
init.d script.



From jspaleta at gmail.com  Tue Nov 15 21:23:56 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 16:23:56 -0500
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>

On 11/15/05, Dimi Paun <dimi at lattica.com> wrote:
> Basically, can we have X up in 10s? :)

I still don't understand exactly why this is the important goal.
Explain to me why the 10second to X goal on "reboot" is more important
than getting a robust suspend/hibernate working that doesn't require a
full boot up process at all? I can see why the fist 4 items in Luke's
list are technical wins for a less grotesque init process... but i
still don't get why getting to a login screen in under 10 seconds on a
full boot is noteworthy or highly desirable compared to a
suspend/hibernate that actually works across desktops and laptop
hardware.

And until we see bootchart output that shows a comparison of initrd to
SysVinit for the default Fedora Core service set... the jury is out on
how big a difference this actually makes for the default case.

-jef



From ivazquez at ivazquez.net  Tue Nov 15 21:29:17 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Tue, 15 Nov 2005 16:29:17 -0500
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <1132090158.13770.7.camel@ignacio.lan>

On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
> Why do we need to bring up
> the networking before we start X?

NFS-mounted /home. No point in being able to log in if you don't have a
home directory yet.

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051115/f06dcd31/attachment.sig>

From avi at argo.co.il  Tue Nov 15 21:33:13 2005
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 15 Nov 2005 23:33:13 +0200
Subject: init observations
In-Reply-To: <2599004567060172327E6DED@[10.169.6.233]>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
Message-ID: <437A5419.8000204@argo.co.il>

Kenneth Porter wrote:

> --On Tuesday, November 15, 2005 3:44 PM -0500 Luke Macken 
> <lmacken at redhat.com> wrote:
>
>>  o Still supports the /etc/rc.d/rc$i.d framework (which is horrible by
>>    design)
>
>
> What do packagers of services need to do to natively support the 
> alternatives? Presumably they need to supply the native equivalent to 
> the init.d script.
>
It would be excellent if the glue code could be done in python:
- fast compared to shell scripts since there is no need to continually 
fork/exec utilities
- non-intrusive: less patches to packages
- easy to write and maintain

I imagine an initng plugin should be feasible.

[there might be opposition to linking init with /usr/, but I consider it 
outdated. we have initrd to mount our filesystems today]

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From kms at passback.co.uk  Tue Nov 15 21:35:40 2005
From: kms at passback.co.uk (Keith Sharp)
Date: Tue, 15 Nov 2005 21:35:40 +0000
Subject: init observations
In-Reply-To: <604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
Message-ID: <1132090540.31151.26.camel@animal.passback.co.uk>

On Tue, 2005-11-15 at 16:23 -0500, Jeff Spaleta wrote:
> On 11/15/05, Dimi Paun <dimi at lattica.com> wrote:
> > Basically, can we have X up in 10s? :)
> 
> I still don't understand exactly why this is the important goal.
> Explain to me why the 10second to X goal on "reboot" is more important
> than getting a robust suspend/hibernate working that doesn't require a
> full boot up process at all? I can see why the fist 4 items in Luke's
> list are technical wins for a less grotesque init process... but i
> still don't get why getting to a login screen in under 10 seconds on a
> full boot is noteworthy or highly desirable compared to a
> suspend/hibernate that actually works across desktops and laptop
> hardware.

I agree.  I have recently installed Rawhide on my laptop (IBM T40) and
got gnome-power-manager with suspend to disk working (the only problem
was the non-support for swap partitions identified by label, already in
bugzilla but I can't remember the number) and it is superb.  I now plan
on pretty much never rebooting again.

Kudos to all those who worked so hard to make the bits join up - kernel,
hal, dbus, g-p-m!

Keith.



From cmadams at hiwaay.net  Tue Nov 15 21:36:38 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 15 Nov 2005 15:36:38 -0600
Subject: init observations
In-Reply-To: <1132090158.13770.7.camel@ignacio.lan>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
Message-ID: <20051115213638.GC1003315@hiwaay.net>

Once upon a time, Ignacio Vazquez-Abrams <ivazquez at ivazquez.net> said:
> On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:
> > Why do we need to bring up
> > the networking before we start X?
> 
> NFS-mounted /home. No point in being able to log in if you don't have a
> home directory yet.

LDAP or NIS authentication require network for that matter.

Also IIRC, GNOME tries to do a hostname lookup during login (I get an
error sometimes on my notebook).

I think instead of trying to replace the init system wholesale, it would
be better to make a few improvements to the current system.  For
example, it should be possible to mark a service as "background startup"
so boot doesn't wait on it (one candidate is nut; right now I have to
wait a bit while it thinks about talking to my UPS).  Many of the
network services (SMTP, SSH, FTP, etc.) don't need to be available
before local login.

I'm not convinced that parallel startup is such a great idea.  A lot of
work will be required to get (and keep) dependencies straight.  Also, is
it really a win?  Firing off a dozen things at once does not make them
finish 12 times faster; it can make them take longer.

How often do people reboot their system?  Most of mine are typically up
for weeks at a time.  If power management worked better on my notebook,
I'd probably never do a full shutdown.
-- 
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 cmadams at hiwaay.net  Tue Nov 15 21:38:39 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 15 Nov 2005 15:38:39 -0600
Subject: init observations
In-Reply-To: <437A5419.8000204@argo.co.il>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
	<437A5419.8000204@argo.co.il>
Message-ID: <20051115213838.GD1003315@hiwaay.net>

Once upon a time, Avi Kivity <avi at argo.co.il> said:
> It would be excellent if the glue code could be done in python:

Requiring /usr be available before starting anything is not going to
work.

> [there might be opposition to linking init with /usr/, but I consider it 
> outdated. we have initrd to mount our filesystems today]

I don't really want to have to rebuild initrd anytime I change network
settings and such (think network shared /usr).
-- 
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 notting at redhat.com  Tue Nov 15 21:40:59 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 15 Nov 2005 16:40:59 -0500
Subject: init observations
In-Reply-To: <20051115213838.GD1003315@hiwaay.net>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
	<437A5419.8000204@argo.co.il> <20051115213838.GD1003315@hiwaay.net>
Message-ID: <20051115214059.GA325@devserv.devel.redhat.com>

Chris Adams (cmadams at hiwaay.net) said: 
> Once upon a time, Avi Kivity <avi at argo.co.il> said:
> > It would be excellent if the glue code could be done in python:
> 
> Requiring /usr be available before starting anything is not going to
> work.
> 
> > [there might be opposition to linking init with /usr/, but I consider it 
> > outdated. we have initrd to mount our filesystems today]
> 
> I don't really want to have to rebuild initrd anytime I change network
> settings and such (think network shared /usr).

OK, this is something I've been meaning to ask about - who
still uses network /usr, and why do you use that instead of
network /  ?

Bill



From skvidal at phy.duke.edu  Tue Nov 15 21:43:49 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 15 Nov 2005 16:43:49 -0500
Subject: init observations
In-Reply-To: <20051115214059.GA325@devserv.devel.redhat.com>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]> <437A5419.8000204@argo.co.il>
	<20051115213838.GD1003315@hiwaay.net>
	<20051115214059.GA325@devserv.devel.redhat.com>
Message-ID: <1132091029.8361.51.camel@cutter>

On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
> Chris Adams (cmadams at hiwaay.net) said: 
> > Once upon a time, Avi Kivity <avi at argo.co.il> said:
> > > It would be excellent if the glue code could be done in python:
> > 
> > Requiring /usr be available before starting anything is not going to
> > work.
> > 
> > > [there might be opposition to linking init with /usr/, but I consider it 
> > > outdated. we have initrd to mount our filesystems today]
> > 
> > I don't really want to have to rebuild initrd anytime I change network
> > settings and such (think network shared /usr).
> 
> OK, this is something I've been meaning to ask about - who
> still uses network /usr, and why do you use that instead of
> network /  ?

And how do you get hard drives that are smaller than 40GB :)

-sv




From jspaleta at gmail.com  Tue Nov 15 21:44:49 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 16:44:49 -0500
Subject: init observations
In-Reply-To: <20051115213638.GC1003315@hiwaay.net>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
Message-ID: <604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>

On 11/15/05, Chris Adams <cmadams at hiwaay.net> wrote:
> I'm not convinced that parallel startup is such a great idea.  A lot of
> work will be required to get (and keep) dependencies straight.  Also, is
> it really a win?  Firing off a dozen things at once does not make them
> finish 12 times faster; it can make them take longer.

This is why we need to see initng booting a default set of services
side-by-side with a SysVinit.
Its very much an open question as to whether there is much win at all
here... and exactly which segment would be expected to benefit. Luke's
images don't  come close to telling a real comparitive story about
boottime. Out of all the potential benefits I see the boottime
argument as least compelling, and most speculative... so its probably
best not to focus on this item at all.

-jef



From nicolas.mailhot at laposte.net  Tue Nov 15 21:49:51 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 15 Nov 2005 22:49:51 +0100
Subject: init observations
In-Reply-To: <20051115213638.GC1003315@hiwaay.net>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
Message-ID: <1132091392.3329.2.camel@rousalka.dyndns.org>

Le mardi 15 novembre 2005 ? 15:36 -0600, Chris Adams a ?crit :

> I'm not convinced that parallel startup is such a great idea.  A lot of
> work will be required to get (and keep) dependencies straight.  Also, is
> it really a win?  Firing off a dozen things at once does not make them
> finish 12 times faster; it can make them take longer.

Honestly, I don't care a little bit about the parallel part, but smarter
service ordering (*not* hardcoded startup numbers) wouldn't be luxury.
Anyone who tried to allocate a meaningful startup number to a service
taking into account all its deps permutations knows what I'm talking
about

-- 
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/20051115/386f091e/attachment.sig>

From avi at argo.co.il  Tue Nov 15 21:54:07 2005
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 15 Nov 2005 23:54:07 +0200
Subject: init observations
In-Reply-To: <20051115213838.GD1003315@hiwaay.net>
References: <20051115204405.GA18220@lewk.org>	<2599004567060172327E6DED@[10.169.6.233]>	<437A5419.8000204@argo.co.il>
	<20051115213838.GD1003315@hiwaay.net>
Message-ID: <437A58FF.5050709@argo.co.il>

Chris Adams wrote:

>Once upon a time, Avi Kivity <avi at argo.co.il> said:
>  
>
>>It would be excellent if the glue code could be done in python:
>>    
>>
>
>Requiring /usr be available before starting anything is not going to
>work.
>
>  
>
We require /. We require initrd.

>>[there might be opposition to linking init with /usr/, but I consider it 
>>outdated. we have initrd to mount our filesystems today]
>>    
>>
>
>I don't really want to have to rebuild initrd anytime I change network
>settings and such (think network shared /usr).
>  
>
I'm sure we can arrange initrd to look at the command line. For example:

  mount=/=server1:/path/to/root,/usr=server2:/path/to/usr

IP can already be configured this way.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From jkeating at j2solutions.net  Tue Nov 15 21:56:22 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 15 Nov 2005 13:56:22 -0800
Subject: init observations
In-Reply-To: <20051115214059.GA325@devserv.devel.redhat.com>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]> <437A5419.8000204@argo.co.il>
	<20051115213838.GD1003315@hiwaay.net>
	<20051115214059.GA325@devserv.devel.redhat.com>
Message-ID: <1132091782.10592.19.camel@localhost.localdomain>

On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
> 
> OK, this is something I've been meaning to ask about - who
> still uses network /usr, and why do you use that instead of
> network /  ?

What about LTSP?  They do some such over network.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051115/5bcd760b/attachment.sig>

From ph18 at cornell.edu  Tue Nov 15 22:11:40 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 15 Nov 2005 17:11:40 -0500
Subject: init observations
In-Reply-To: <604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>	<028701c5ea29$404130a0$b6491b31@td612671>	<1132090158.13770.7.camel@ignacio.lan>	<20051115213638.GC1003315@hiwaay.net>
	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
Message-ID: <437A5D1C.3040101@cornell.edu>

Jeff Spaleta wrote:

>This is why we need to see initng booting a default set of services
>side-by-side with a SysVinit.
>Its very much an open question as to whether there is much win at all
>here... and exactly which segment would be expected to benefit. Luke's
>images don't  come close to telling a real comparitive story about
>boottime. Out of all the potential benefits I see the boottime
>argument as least compelling, and most speculative... so its probably
>best not to focus on this item at all.
>  
>
    In the past,  boot times have been a major complaint of ordinary 
consumers.

    A few years back,  we bought a computer for my sister-in-law.  It 
came with Windows XP at about the time Win XP first came out.  In six 
months they installed a huge amount of junkware on it,  which finally 
made the machine inoperable.  The last straw was a keyboard driver for a 
keyboard with idiot buttons (connect to AOL...) that put up a modal 
dialog box that asked if I wanted to upgrade the keyboard driver that 
stopped me from fixing another serious problem with the start sequence.

    So,  we think,  they want to browse the web,  let's set them up with 
Linux -- I think it was RH 9.  At least they're not going to trash the 
machine by installing junkware.

    Laura's first complaint about the machine was that it took forever 
to boot,  and I realized she was right.  I took about 2/3 of the stuff 
out of the boot sequence (HP laserjet drivers,  asian language input 
methods...),  and things got a lot better.

    FC3 and RHEL 4 made a great leap forward.  When I installed RHEL 4 
on an old 400 MhZ machine,  I booted the machine for the first time,  
turned my back on it,  expected it to still be grinding,  and was amazed 
to see that it was already up!

    The starting and stopping experience makes a big difference in the 
experience of a computer.  If it takes forever to boot your computer,  
you leave it on all the time,  wasting electricity and being a bigger 
target for hackers.  My pet peeve with Windows and MacOS X right now is 
that these operating systems usually don't shut down when I hit the 
shutdown button.  They mollycoddle bad-behaving applications,  so often 
I have to hang around for 5 minutes after a shutdown to make sure I 
haven't missed any dialog boxes.  My wife often leaves our Mac on all 
night because she hits "shutdown" and doesn't hang around to close all 
my terminal windows,  and I often find that my Windows machine at the 
office is still on in the morning after I thought I shut it down at 
night and took off in a hurry to catch the bus.




From cmadams at hiwaay.net  Tue Nov 15 22:13:27 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 15 Nov 2005 16:13:27 -0600
Subject: init observations
In-Reply-To: <20051115214059.GA325@devserv.devel.redhat.com>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
	<437A5419.8000204@argo.co.il> <20051115213838.GD1003315@hiwaay.net>
	<20051115214059.GA325@devserv.devel.redhat.com>
Message-ID: <20051115221327.GE1003315@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> OK, this is something I've been meaning to ask about - who
> still uses network /usr, and why do you use that instead of
> network /  ?

I don't currently use network /usr, but I typically have /usr on a
separate fs from / (at least on servers).  I then can mount /usr
read-only which means:

- no writes - less chance of an "oops" (either due to kernel fs error or
  user admin error)
- in the case someone does break into the system somehow, less chance of
  them doing anything meaningful (since they'd have to know to remount
  /usr read-write)
- / is smaller - less to go wrong/get screwed up that would keep the
  system from at least booting in emergency mode

Network / would only be useful between identical systems using DHCP,
since /etc contains users/passwords, network config, hardware config,
etc., unless you want to make /etc a separate fs (which has the same
problems as trying to mount /usr from initrd).

Other problems with /usr being mounted from initrd are handling fsck,
/usr on different device from / that requires additional init, etc.
Look at what happens in rc.sysinit before other filesystems are mounted.

-- 
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 cmadams at hiwaay.net  Tue Nov 15 22:16:30 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Tue, 15 Nov 2005 16:16:30 -0600
Subject: init observations
In-Reply-To: <437A58FF.5050709@argo.co.il>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
	<437A5419.8000204@argo.co.il> <20051115213838.GD1003315@hiwaay.net>
	<437A58FF.5050709@argo.co.il>
Message-ID: <20051115221629.GF1003315@hiwaay.net>

Once upon a time, Avi Kivity <avi at argo.co.il> said:
> We require /. We require initrd.

initrd is not currently required.  It is for out-of-the-box setups, but
you can:

a) not use LVM for root
b) not use ext3 for root or rebuild kernel with ext3 included
c) use hardware that doesn't require modules for root device or rebuild
   kernel with drivers included

> I'm sure we can arrange initrd to look at the command line. For example:
> 
>  mount=/=server1:/path/to/root,/usr=server2:/path/to/usr
> 
> IP can already be configured this way.

That's a pretty ugly hack just to get python support for startup.  Also,
that is limited; the kernel command line has a limit that isn't all that
big.  You also then need to handle fsck and such in initrd for
non-network filesystems.

-- 
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 toshio at tiki-lounge.com  Tue Nov 15 22:26:01 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Tue, 15 Nov 2005 14:26:01 -0800
Subject: init observations
In-Reply-To: <1132091782.10592.19.camel@localhost.localdomain>
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]> <437A5419.8000204@argo.co.il>
	<20051115213838.GD1003315@hiwaay.net>
	<20051115214059.GA325@devserv.devel.redhat.com>
	<1132091782.10592.19.camel@localhost.localdomain>
Message-ID: <1132093561.2965.9.camel@localhost>

On Tue, 2005-11-15 at 13:56 -0800, Jesse Keating wrote:
> On Tue, 2005-11-15 at 16:40 -0500, Bill Nottingham wrote:
> > 
> > OK, this is something I've been meaning to ask about - who
> > still uses network /usr, and why do you use that instead of
> > network /  ?
> 
> What about LTSP?  They do some such over network.
> 
LTSP in its current incarnation does Network / rather than /usr.

-Tos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051115/1f4a6b44/attachment.sig>

From jspaleta at gmail.com  Tue Nov 15 22:26:43 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 17:26:43 -0500
Subject: init observations
In-Reply-To: <437A5D1C.3040101@cornell.edu>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
	<437A5D1C.3040101@cornell.edu>
Message-ID: <604aa7910511151426y1b1bfd91l8351e7881ccadc8d@mail.gmail.com>

On 11/15/05, Paul A Houle <ph18 at cornell.edu> wrote:
>     In the past,  boot times have been a major complaint of ordinary
> consumers.

You missed my point entirely.
Why are we considering all "start up" situations as "full boot" scenarios?
Why isn't focusing on suspend to disk scenarios a better win?

>     Laura's first complaint about the machine was that it took forever
> to boot,  and I realized she was right.  I took about 2/3 of the stuff
> out of the boot sequence (HP laserjet drivers,  asian language input
> methods...),  and things got a lot better.

And if we focused instead on a robust suspend that most users could
use... how often would such a system need to do a full reboot instead
of a suspend? Every kernel update?

>
>     FC3 and RHEL 4 made a great leap forward.  When I installed RHEL 4
> on an old 400 MhZ machine,  I booted the machine for the first time,
> turned my back on it,  expected it to still be grinding,  and was amazed
> to see that it was already up!

Right.. improvement without having to reach for parallelzation. We
still don't have a direct side by side comparison of a "default" set
of services that shows that paralization is going to be a worthwile
win on average hardware..let alone legacy hardware like a 400 Mhz
machine with what I imagine is below average ram compared to desktops
shipping now.  You want to see a bootup process slowdown..have it
start swapping out memory because of competing processess.  I have not
seen a convincing argument that parallelization can get to a boot time
much lower than continued optimization of the default init process we
have right now.
The big win, is suspend to disk, so that you can avoid doing the full
boot on day to day shutdown and restarts.

>     The starting and stopping experience makes a big difference in the
> experience of a computer.  If it takes forever to boot your computer,
> you leave it on all the time,  wasting electricity and being a bigger
> target for hackers.

I'm not arguing that.. I'm arguing that most day to day startup
situations do not have to be "full boot" situations they could be
"recover from suspend" and avoid service startup completely.

-jef



From enrico.scholz at informatik.tu-chemnitz.de  Tue Nov 15 22:37:28 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Tue, 15 Nov 2005 23:37:28 +0100
Subject: init observations
In-Reply-To: <20051115214059.GA325@devserv.devel.redhat.com> (Bill
	Nottingham's message of "Tue, 15 Nov 2005 16:40:59 -0500")
References: <20051115204405.GA18220@lewk.org>
	<2599004567060172327E6DED@[10.169.6.233]>
	<437A5419.8000204@argo.co.il> <20051115213838.GD1003315@hiwaay.net>
	<20051115214059.GA325@devserv.devel.redhat.com>
Message-ID: <87oe4ly1uf.fsf@kosh.bigo.ensc.de>

notting at redhat.com (Bill Nottingham) writes:

>> > [there might be opposition to linking init with /usr/, but I
>> > consider it outdated. we have initrd to mount our filesystems
>> > today]
>> 
>> I don't really want to have to rebuild initrd anytime I change network
>> settings and such (think network shared /usr).
>
> OK, this is something I've been meaning to ask about - who
> still uses network /usr, and why do you use that instead of
> network /  ?

It's not only a network /usr. It is an issue with the traditional
splitting of /, /usr and /var too.  These filesystems can not be used
by init but must be made available by it (which is a non-trivial task
because it requires e.g. module-loading, fsck or lvm setup).



Enrico




From nicolas.mailhot at laposte.net  Tue Nov 15 22:36:56 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 15 Nov 2005 23:36:56 +0100
Subject: init observations
In-Reply-To: <604aa7910511151426y1b1bfd91l8351e7881ccadc8d@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
	<437A5D1C.3040101@cornell.edu>
	<604aa7910511151426y1b1bfd91l8351e7881ccadc8d@mail.gmail.com>
Message-ID: <1132094217.2924.10.camel@rousalka.dyndns.org>

Le mardi 15 novembre 2005 ? 17:26 -0500, Jeff Spaleta a ?crit :
> On 11/15/05, Paul A Houle <ph18 at cornell.edu> wrote:
> >     In the past,  boot times have been a major complaint of ordinary
> > consumers.
> 
> You missed my point entirely.
> Why are we considering all "start up" situations as "full boot" scenarios?
> Why isn't focusing on suspend to disk scenarios a better win?
> 
> >     Laura's first complaint about the machine was that it took forever
> > to boot,  and I realized she was right.  I took about 2/3 of the stuff
> > out of the boot sequence (HP laserjet drivers,  asian language input
> > methods...),  and things got a lot better.
> 
> And if we focused instead on a robust suspend that most users could
> use... how often would such a system need to do a full reboot instead
> of a suspend? Every kernel update?

The problem is not so much in boot time but in service interdependencies
Just try to activate a service you didn't use before (or a new service)
- trying to locate all the other services it needs and to activate them
in the right order is power user stuff right now.

It gets worse with all the cool avahi/dbus/etc new services that do
nothing by themselves but are used by other stuff. The spaguetti plate
is growing

-- 
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/20051115/50cc19fa/attachment.sig>

From davej at redhat.com  Tue Nov 15 22:46:52 2005
From: davej at redhat.com (Dave Jones)
Date: Tue, 15 Nov 2005 17:46:52 -0500
Subject: init observations
In-Reply-To: <604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
Message-ID: <20051115224652.GG17023@redhat.com>

On Tue, Nov 15, 2005 at 04:23:56PM -0500, Jeff Spaleta wrote:
 > On 11/15/05, Dimi Paun <dimi at lattica.com> wrote:
 > > Basically, can we have X up in 10s? :)
 > 
 > I still don't understand exactly why this is the important goal.
 > Explain to me why the 10second to X goal on "reboot" is more important
 > than getting a robust suspend/hibernate working that doesn't require a
 > full boot up process at all?

If suspend was 100% reliable, I'd agree.  For a lot of systems,
we may never get them working due to lack of hardware specifications
to wake the drivers up on resume. (Video drivers are particularly
bad in this area).

Even for the hardware we *do* have docs for, we're likely to be
playing bug-whack-a-mole for quite some time yet.  For FC4 and
earlier, any suspend/resume bugs that have been filed have
frankly been 'best effort'. If it was a simple fix, I merged it.
Anything else is stuff that we've inherited from upstream.

With swsusp being enabled in FC5, I'm expecting to see a lot
more suspend/resume bugs being filed after its release.

		Dave



From dimi at lattica.com  Tue Nov 15 22:49:29 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 15 Nov 2005 17:49:29 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org><028701c5ea29$404130a0$b6491b31@td612671>
	<20051115211419.GB13874@devserv.devel.redhat.com>
Message-ID: <031901c5ea36$d6d8c070$b6491b31@td612671>

From: "Bill Nottingham" <notting at redhat.com>
> What 'hardware probing' are you talking about here? We
> just load all relevant modules, splitting it up will
> probably just cause more complication and slow things
> down.

I'm talking about modprobe. I agree, not a bit problem
(~2.5s), but I was wondering if we can start X before it.
I mean, things should work out correctly in face of
hotplug events anyhow, so why don't we delay modprobing
until after we start X, and treat them as hotplug events?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From sopwith at redhat.com  Tue Nov 15 22:50:33 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Tue, 15 Nov 2005 17:50:33 -0500 (EST)
Subject: Shell access to fedora.redhat.com machines
Message-ID: <Pine.LNX.4.58.0511151736160.24825@devserv.devel.redhat.com>

Hi all,

I've set things up so we can start to allow shell accounts on
*.fedora.redhat.com (and hopefully *.fedoraproject.org, RSN), enabling
more people to create and enhance Fedora infrastructure. There are now
three groups in the account system - sysadmin-build (for people
maintaining the build systems), sysadmin-web (for people hacking on web
infrastructure) and sysadmin (for people doing general infrastructure
maintenance).

These shell accounts are only to be used for Fedora project-related stuff
- please don't put any personal materials or services or 'stuff' in them.

For fedora.redhat.com, things are set up with bastion.fedora.redhat.com as 
the 'bastion' host. Once you ssh into that host, you have a wide variety 
of systems that you can ssh to:
	sysadmin-web and sysadmin: app[12], proxy[1-4]
	sysadmin-build and sysadmin: hammer[1-3], ppc1
	sysadmin: db1 and cvs-int

You can login with the ssh key listed in the account system, the same one
you may already use for CVS access. You may also have sudo access on some
of the machines relevant to your area of expertise (the password will the
same as the one you use in the Fedora Account System). WARNING: Do not
change system configurations or settings. Right now that has to happen
through a separate mechanism that isn't yet external. I will also
personally get on your case if you start changing systems without working
with the rest of the 'team'.

I would love to get more people helping enhance our infrastructure, so if
you believe it would help for you to have login access and I left you out,
please let me know!

Best,
-- Elliot



From davej at redhat.com  Tue Nov 15 22:54:08 2005
From: davej at redhat.com (Dave Jones)
Date: Tue, 15 Nov 2005 17:54:08 -0500
Subject: init observations
In-Reply-To: <20051115204405.GA18220@lewk.org>
References: <20051115204405.GA18220@lewk.org>
Message-ID: <20051115225408.GH17023@redhat.com>

On Tue, Nov 15, 2005 at 03:44:05PM -0500, Luke Macken wrote:
 >  o FAST AS HELL[0]

Perhaps that because the comparison is comparing
different things. Ie, the faster of the two
isn't running cups, firewire, alsa, usb etc
(In fact, none of the stuff forked from udev)

Without that scanning, aiui, we'll fail to pick
up for eg, USB keys left inserted at boot,
requiring an unplug-replug action before they
get seen.

		Dave



From dimi at lattica.com  Tue Nov 15 23:10:26 2005
From: dimi at lattica.com (Dimi Paun)
Date: Tue, 15 Nov 2005 18:10:26 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org>
	<20051115225408.GH17023@redhat.com>
Message-ID: <033701c5ea39$c44cf360$b6491b31@td612671>

From: "Dave Jones" <davej at redhat.com>
> Without that scanning, aiui, we'll fail to pick
> up for eg, USB keys left inserted at boot,
> requiring an unplug-replug action before they
> get seen.

Shouldn't we get a plug event when we do detect it?
This way there would be no difference between the
initial scan and any subsequent unplug/plug events.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From davej at redhat.com  Tue Nov 15 23:13:41 2005
From: davej at redhat.com (Dave Jones)
Date: Tue, 15 Nov 2005 18:13:41 -0500
Subject: init observations
In-Reply-To: <033701c5ea39$c44cf360$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<20051115225408.GH17023@redhat.com>
	<033701c5ea39$c44cf360$b6491b31@td612671>
Message-ID: <20051115231341.GM17023@redhat.com>

On Tue, Nov 15, 2005 at 06:10:26PM -0500, Dimi Paun wrote:
 > From: "Dave Jones" <davej at redhat.com>
 > > Without that scanning, aiui, we'll fail to pick
 > > up for eg, USB keys left inserted at boot,
 > > requiring an unplug-replug action before they
 > > get seen.
 > 
 > Shouldn't we get a plug event when we do detect it?
 > This way there would be no difference between the
 > initial scan and any subsequent unplug/plug events.

That's what I'm saying. Looking at the chart,
it looks like the plug events never happen, as
udev doesn't seem to be scanning anything any more.

		Dave



From mharris at redhat.com  Tue Nov 15 23:47:13 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Tue, 15 Nov 2005 18:47:13 -0500
Subject: ANNOUNCEMENT: Modular X.Org X11R7 RC2 coming to a theatre near you.
Message-ID: <437A7381.2030908@redhat.com>

Overview:
~~~~~~~~
Modular X.Org X11R7 RC2 rpm packaging has now been whipped mostly
into shape enough for rawhide testing to begin soon.  As such,
modular X could appear in rawhide as soon as tomorrow, however if
we discover any major issues in between now and then, we might
delay it a day or so if necessary.

Most if not all of the rest of Fedora Core has been updated to build
against modular X, and work with it, however there are likely still
some packages with broken dependencies that will turn up over time.

Third party packages out there will also likely need to be updated
still too.

Since this is the first time we'll be putting modular X out there for
the testerbase at large, we expect that a number of problems will be
discovered which have not been noticed with internal testing.

Bug reporting:
~~~~~~~~~~~~~
If you encounter a video driver bug, or other software bug with
modular X, please report it directly to X.Org bugzilla, so that it
will get fixed before X11R7 is finalized.  When filing a bug to
X.org bugzilla, be sure to mark it as blocking bug "1690", which
is the X11R7 release blocker bug.  Bugs that are not blocking bug
1690 will get much lower priority and may fall between the cracks.

     http://bugs.freedesktop.org in the "xorg" component

If experiencing any video driver bugs, or system lockups, it is also
recommended to join the xorg at lists.freedesktop.org mailing list,
and discuss the problem there with upstream X.Org developers and other
users, as this is generally the fastest way to see bugs get fixed.


If you would like Red Hat to track a particular X.Org bug report
that you've filed upstream as requested above, please file
a tracking bug in Red Hat bugzilla, which has a brief description
of the problem, and a URL linking to the upstream X.Org bug, and
we will track the issue as well.

If you discover an rpm packaging bug, or an upgrade/downgrade related
bug that is likely specific to our packaging of modular X, rather
than being a general upstream modular X bug, then please file it in
Red Hat bugzilla against the "xorg-x11" component for now.


Important notes:
~~~~~~~~~~~~~~~
When upgrading from monolithic xorg-x11 6.8.2 or older releases
using 'yum' from the commandline inside a terminal in X, you need to
restart the X server, or applications that use core fonts, will fail,
being unable to see any fonts.  The reason for this is that the
upgrade process must restart the xfs font server to ensure the new
xfs server is running after the upgrade, which causes the
xfs<->X server connection to be detached.  Alternatively,
users may want to try using "xset +fp "unix:/7100" ; xset fp rehash"
to attempt to reattach xfs to the running X server.  Restarting
the X server is the recommended method however, as you'll want to
be running/testing the new X server as well, and there are likely
to be other unexpected problems to not restarting the X server.




From mharris at redhat.com  Tue Nov 15 23:53:12 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Tue, 15 Nov 2005 18:53:12 -0500
Subject: init observations
In-Reply-To: <1ABFFCC1CF72F107BABFBB04@[10.169.6.233]>
References: <20051115204405.GA18220@lewk.org>	<028701c5ea29$404130a0$b6491b31@td612671>	<1132089357.3042.0.camel@scrappy.miketc.com>
	<1ABFFCC1CF72F107BABFBB04@[10.169.6.233]>
Message-ID: <437A74E8.3030001@redhat.com>

Kenneth Porter wrote:
> --On Tuesday, November 15, 2005 3:15 PM -0600 Mike Chambers 
> <mike at miketc.com> wrote:
> 
>> Not a developer or programmer, but what about those systems that use
>> x/fonts from a server and not on the workstation?  How would X start
>> without networking capabilities?
> 
> What does it currently do if your font server is unreachable? Does it 
> wait, or fall back to local fonts until it can reach the server? Or just 
> fall over?

Our out of the box supported default configuration of the X server,
is that it requires a properly configured xfs font server to be
running on the same machine.  If xfs is not running, the X server
will not start, as it will be unable to find the 'fixed' and
'cursor' fonts.

The X server and font server are highly configureable however, and
various people use them in various non-default setups.  Some people
might have their X server manually configured to not use xfs, or to
use xfs over the network via TCP being enabled.  Some people may
have /usr mounted over NFS, possibly read-only, and the X server
binary and other X applications in /usr/bin et al. aren't available
until /usr is mounted, which requires networking to be started.

There are as many other custom setups likely, as there are users
out there. ;o)

On a side note:
When modular X hits rawhide over the next few days, it is highly
recommended that people using customized configurations that are
not the default, test their setups with the new modular X, and
see if they need to adjust their configuration.

HTH.



From mharris at redhat.com  Tue Nov 15 23:58:06 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Tue, 15 Nov 2005 18:58:06 -0500
Subject: init observations
In-Reply-To: <604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>	<028701c5ea29$404130a0$b6491b31@td612671>
	<604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
Message-ID: <437A760E.1000102@redhat.com>

Jeff Spaleta wrote:
> On 11/15/05, Dimi Paun <dimi at lattica.com> wrote:
> 
>>Basically, can we have X up in 10s? :)
> 
> 
> I still don't understand exactly why this is the important goal.
> Explain to me why the 10second to X goal on "reboot" is more important
> than getting a robust suspend/hibernate working that doesn't require a
> full boot up process at all? I can see why the fist 4 items in Luke's
> list are technical wins for a less grotesque init process... but i
> still don't get why getting to a login screen in under 10 seconds on a
> full boot is noteworthy or highly desirable compared to a
> suspend/hibernate that actually works across desktops and laptop
> hardware.
> 
> And until we see bootchart output that shows a comparison of initrd to
> SysVinit for the default Fedora Core service set... the jury is out on
> how big a difference this actually makes for the default case.

"X" starts in less than 5 seconds on most systems and has for years.
However, if what is meant is "Have a fully working graphical GNOME or
KDE desktop started up in X in less than 10 seconds" is the goal, then
my opinion is thus:

Getting a full desktop started up in less than 10 seconds is a
completely orthagonal problem than having working suspend/hibernate
support.  Most likely the people who would be working on either
project, would be different developers working in parallel on
different problems.  So it isn't IMHO about allocation of resources
per se.

I personally think that getting a full desktop running in less than
10 seconds is more important than working hibernate support, simply
because there are probably one ore more orders of magnitude more
"desktop users" than there are "laptop users" out there.  Both
features are important to have for their respective userbases of
course, but the "desktop users" group generally is a superset of the
"laptop users" group.



From jspaleta at gmail.com  Wed Nov 16 00:04:15 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 19:04:15 -0500
Subject: init observations
In-Reply-To: <20051115224652.GG17023@redhat.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
	<20051115224652.GG17023@redhat.com>
Message-ID: <604aa7910511151604v5aec56fdo57d17e13eb268aeb@mail.gmail.com>

On 11/15/05, Dave Jones <davej at redhat.com> wrote:
> If suspend was 100% reliable, I'd agree.  For a lot of systems,
> we may never get them working due to lack of hardware specifications
> to wake the drivers up on resume. (Video drivers are particularly
> bad in this area).

I'm sure its going to be the hard thing to do... but who said the
right thing to do was the easy one?  I'm sure the difficulties in
hardware coverage are real, but I still haven't seen a smoking gun
that init parallelization is going to be an instant win for boottime
for the default case, the average case, the worst case or anything
else worth noting.  The introduction of the bootchart and the
resulting optimization of the init process we have now and I don't see
why parallelization is garunteed to improve on that. Considering all
the other technical benefits to moving to a more sophisticated init, I
just don't think boottime is a strong argument.. I don't think we
really know what the impact on boottime is going to be.

-jef"I thought the mark was 80% reliable"spaleta



From jspaleta at gmail.com  Wed Nov 16 00:13:37 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 19:13:37 -0500
Subject: init observations
In-Reply-To: <437A760E.1000102@redhat.com>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<604aa7910511151323o1fcd2378mf6a9ec5e05a6a84d@mail.gmail.com>
	<437A760E.1000102@redhat.com>
Message-ID: <604aa7910511151613u14f3ee8cr6a98a2965d3d31cd@mail.gmail.com>

On 11/15/05, Mike A. Harris <mharris at redhat.com> wrote:
> I personally think that getting a full desktop running in less than
> 10 seconds is more important than working hibernate support, simply
> because there are probably one ore more orders of magnitude more
> "desktop users" than there are "laptop users" out there.  Both
> features are important to have for their respective userbases of
> course, but the "desktop users" group generally is a superset of the
> "laptop users" group.

why can't "desktop" or "thin clients" or "home theature settop boxes"
or "router appliance" benefit from a robust suspend? Just because
"laptop" users are the traditional group who feel a need for this,
doesn't mean its not the right solution for a broader range of users. 
Don't desktop bioses that are being sold right now claim to support to
suspend?

-jef"this discussion is moot anyways, neural interfaces will be here
in a decade and i doubt rebooting your brain will be an option"spaleta



From lamont at gurulabs.com  Wed Nov 16 00:21:30 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Tue, 15 Nov 2005 17:21:30 -0700
Subject: init observations
In-Reply-To: <604aa7910511151613u14f3ee8cr6a98a2965d3d31cd@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org> <437A760E.1000102@redhat.com>
	<604aa7910511151613u14f3ee8cr6a98a2965d3d31cd@mail.gmail.com>
Message-ID: <200511151721.36965.lamont@gurulabs.com>

On Tuesday 15 November 2005 05:13pm, Jeff Spaleta wrote:
> On 11/15/05, Mike A. Harris <mharris at redhat.com> wrote:
> > I personally think that getting a full desktop running in less than
> > 10 seconds is more important than working hibernate support, simply
> > because there are probably one ore more orders of magnitude more
> > "desktop users" than there are "laptop users" out there.  Both
> > features are important to have for their respective userbases of
> > course, but the "desktop users" group generally is a superset of the
> > "laptop users" group.

The moment I read that, I knew this was coming.

> why can't "desktop" or "thin clients" or "home theature settop boxes"
> or "router appliance" benefit from a robust suspend? Just because
> "laptop" users are the traditional group who feel a need for this,
> doesn't mean its not the right solution for a broader range of users.
> Don't desktop bioses that are being sold right now claim to support to
> suspend?

I think that what he meant by laptop userbase vs. desktop userbase is valid 
because *most* "desktop" users don't care about suspend.  Even if they see it 
available, they probably won't use it.

I think you are right, though, Jef; desktop systems, set-top boxes, and so on 
and so on, would definitely benefit, too.  But I have to wonder, since the 
developers who are going to work on both possible solutions are probably not 
the same people, why not just do both?

Also, since it is unlikely that broad suspend, et. al. support is going to 
come along too quickly, I think faster boot and shutdown times are a great 
idea.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051115/3b121d57/attachment.sig>

From jspaleta at gmail.com  Wed Nov 16 00:35:52 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 15 Nov 2005 19:35:52 -0500
Subject: init observations
In-Reply-To: <200511151721.36965.lamont@gurulabs.com>
References: <20051115204405.GA18220@lewk.org> <437A760E.1000102@redhat.com>
	<604aa7910511151613u14f3ee8cr6a98a2965d3d31cd@mail.gmail.com>
	<200511151721.36965.lamont@gurulabs.com>
Message-ID: <604aa7910511151635j47d06e9dn76a75ff88c898f2d@mail.gmail.com>

On 11/15/05, Lamont R. Peterson <lamont at gurulabs.com> wrote:
> I think that what he meant by laptop userbase vs. desktop userbase is valid
> because *most* "desktop" users don't care about suspend.  Even if they see it
> available, they probably won't use it.

User education problem.... which only serves to re-enforce the status-quo.

> I think you are right, though, Jef; desktop systems, set-top boxes, and so on
> and so on, would definitely benefit, too.  But I have to wonder, since the
> developers who are going to work on both possible solutions are probably not
> the same people, why not just do both?

The context in this discussion is.... does the parallelization that
initng provides actually improve boottime or does it not. My argument
is.. compared to the other technical "wins" with changing init systems
the boottime "benefit" is speculative and should not be the focus of
the decision at hand. Hell, initng might actually cause a boottime
increase for the default case.

I'm all for continued optmization of the boot process, the creation of
the bootchart tool and the optmization built on the use of that tool
has been a good thing{tm} and I'm sure more progress will be made on
that front regardless of which init system is in use. But, I think its
ill-advised to make the focus of the discussion of changing the init
system  centered around boottime enhancements which may or may not
materialize. As a matter of priorities  associated with the specific
issue of changing the init system... boottime ehancement should be the
last concern.

-jef"most desktop users dont care about linux.. even if they see it
available they won't use it.... but here we are anyways.. attempting
to educate and to make better solutions "spaleta



From bojan at rexursive.com  Wed Nov 16 01:51:09 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 16 Nov 2005 12:51:09 +1100
Subject: libesmtp rebuild
Message-ID: <20051116125109.e86b91i82sw00ksg@imp.rexursive.com>

Not sure if this is the correct place to ask this... Anyway, this 
package from extras seems to want the old crypto libs. Anyone with 
access that can rebuild it against the currant Rawhide?

-- 
Bojan



From dcbw at redhat.com  Wed Nov 16 04:31:23 2005
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 15 Nov 2005 23:31:23 -0500
Subject: libesmtp rebuild
In-Reply-To: <20051116125109.e86b91i82sw00ksg@imp.rexursive.com>
References: <20051116125109.e86b91i82sw00ksg@imp.rexursive.com>
Message-ID: <1132115483.2898.0.camel@localhost.localdomain>

On Wed, 2005-11-16 at 12:51 +1100, Bojan Smojver wrote:
> Not sure if this is the correct place to ask this... Anyway, this 
> package from extras seems to want the old crypto libs. Anyone with 
> access that can rebuild it against the currant Rawhide?

Done.

Dan



From bojan at rexursive.com  Wed Nov 16 05:45:20 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Wed, 16 Nov 2005 16:45:20 +1100
Subject: libesmtp rebuild
In-Reply-To: <1132115483.2898.0.camel@localhost.localdomain>
References: <20051116125109.e86b91i82sw00ksg@imp.rexursive.com>
	<1132115483.2898.0.camel@localhost.localdomain>
Message-ID: <20051116164520.w2tnrbwrc0cwg8ks@imp.rexursive.com>

Quoting Dan Williams <dcbw at redhat.com>:

> Done.

Excellent, thanks!

-- 
Bojan



From rodd at clarkson.id.au  Wed Nov 16 06:05:15 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Wed, 16 Nov 2005 17:05:15 +1100
Subject: init observations
In-Reply-To: <437A5D1C.3040101@cornell.edu>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
	<437A5D1C.3040101@cornell.edu>
Message-ID: <1132121115.3445.14.camel@localhost.localdomain>

On Tue, 2005-11-15 at 17:11 -0500, Paul A Houle wrote:

>     Laura's first complaint about the machine was that it took forever 
> to boot,  and I realized she was right.  I took about 2/3 of the stuff 
> out of the boot sequence (HP laserjet drivers,  asian language input 
> methods...),  and things got a lot better.

In my experience, the faster boot of Windows is just a bit of slight of
hand.  Sure, you get to a graphical desktop faster, but everything is
still loading once you're there.  This would be fine, except that you
can't even look through the start menu and have another service start
(or the start menu disappears - WTF?).

Of course, this situation on Linux would be a lot nice (the application
menu for starters doesn't close because another application starts (or
puts a window on the screen).

Of course, the biggest funny is why Windows starts so quickly.  Users
got sick of having to reboot because Windows was so unstable, so to
address the problem, Microsoft made Windows reboot faster (instead of
fixing the crashes - Again, WTF?)

He he he.


Rodd
-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From dimi at lattica.com  Wed Nov 16 06:36:22 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 01:36:22 -0500
Subject: init observations
In-Reply-To: <1132121115.3445.14.camel@localhost.localdomain>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
	<1132090158.13770.7.camel@ignacio.lan>
	<20051115213638.GC1003315@hiwaay.net>
	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>
	<437A5D1C.3040101@cornell.edu>
	<1132121115.3445.14.camel@localhost.localdomain>
Message-ID: <1132122982.9749.90.camel@dimi.lattica.com>

On Wed, 2005-11-16 at 17:05 +1100, Rodd Clarkson wrote:
> In my experience, the faster boot of Windows is just a bit of slight
> of hand.

That's fine -- users (for whatever reasons that are not worth
debating), like that behavior. I think we'd do better if we
could start X faster, while other things are going on in the
background. (For fun, look at the first item on this page that
I have just stumbled across: http://kegel.com/linux/comfort/ ).

Going back to X, for a normal Linux install (no networked /home),
what do we _really_ need to start X? We need:
  * The files. These we typically have on the HD that the
    kernel booted from, so no additional time is needed.
  * Video card. This is mostly there.

Everything else (including mouse and keyboard) can come later.
We should be able to bring X up well within 5 seconds. And if
we do bring it up fast enough, we can also drop the rhgb and
speed it up even more.

To do this right we need a proper API for services, one that
can be called from code to start/stop/wait_for/... a service.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From pekkas at netcore.fi  Wed Nov 16 10:46:53 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 16 Nov 2005 12:46:53 +0200 (EET)
Subject: fedora-netdev.1 IPv6 freeze [Re: [ANNOUNCE] fedora-netdev kernel
 repository]
In-Reply-To: <20051114205110.GK25755@redhat.com>
References: <20051114205110.GK25755@redhat.com>
Message-ID: <Pine.LNX.4.64.0511161242260.26498@netcore.fi>

On Mon, 14 Nov 2005, John W. Linville wrote:
> 	http://people.redhat.com/linville/kernels/fedora-netdev/

I guess the test can be termed a 'success' because after updating from 
2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 100% 
reproducible kernel hang (everything just freezes as it is, no message 
to /var/log/messages or anywhere) after I run '/sbin/ip -6 r l' or try 
to use IPv6 in basically any other way on my ThinkPad laptop with 
external orinoco_cs WLAN card.

Any thoughts for the next steps?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From buildsys at redhat.com  Wed Nov 16 12:59:25 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 16 Nov 2005 07:59:25 -0500
Subject: rawhide report: 20051116 changes
Message-ID: <200511161259.jAGCxPNS004872@porkchop.devel.redhat.com>

New package imake
	imake source code configuration and build system

New package libFS
	X.Org X11 libFS runtime library

New package libICE
	X.Org X11 libICE runtime library

New package libSM
	X.Org X11 libSM runtime library

New package libX11
	X.Org X11 libX11 runtime library

New package libXScrnSaver
	X.Org X11 libXss runtime library

New package libXTrap
	X.Org X11 libXTrap runtime library

New package libXau
	X.Org X11 libXau runtime library

New package libXaw
	X.Org X11 libXaw runtime library

New package libXcomposite
	X.Org X11 libXcomposite runtime library

New package libXcursor
	X.Org X11 libXcursor runtime library

New package libXdamage
	X.Org X11 libXdamage runtime library

New package libXdmcp
	X.Org X11 libXdmcp runtime library

New package libXevie
	X.Org X11 libXevie runtime library

New package libXext
	X.Org X11 libXext runtime library

New package libXfixes
	X.Org X11 libXfixes runtime library

New package libXfont
	X.Org X11 libXfont runtime library

New package libXfontcache
	X.Org X11 libXfontcache runtime library

New package libXft
	X.Org X11 libXft runtime library

New package libXi
	X.Org X11 libXi runtime library

New package libXinerama
	X.Org X11 libXinerama runtime library

New package libXmu
	X.Org X11 libXmu/libXmuu runtime libraries

New package libXp
	X.Org X11 libXp runtime library

New package libXpm
	X.Org X11 libXpm runtime library

New package libXrandr
	X.Org X11 libXrandr runtime library

New package libXrender
	X.Org X11 libXrender runtime library

New package libXres
	X.Org X11 libXres runtime library

New package libXt
	X.Org X11 libXt runtime library

New package libXtst
	X.Org X11 libXtst runtime library

New package libXv
	X.Org X11 libXv runtime library

New package libXvMC
	X.Org X11 libXvMC runtime library

New package libXxf86dga
	X.Org X11 libXxf86dga runtime library

New package libXxf86misc
	X.Org X11 libXxf86misc runtime library

New package libXxf86vm
	X.Org X11 libXxf86vm runtime library

New package libdmx
	X.Org X11 libdmx runtime library

New package libdrm
	Digital Rights Managment library

New package libfontenc
	X.Org X11 libfontenc runtime library

New package libibverbs
	A library for direct userspace use of InfiniBand

New package liblbxutil
	X.Org X11 liblbxutil runtime library

New package liboldX
	X.Org X11 liboldX runtime library

New package libxkbfile
	X.Org X11 libxkbfile runtime library

New package libxkbui
	X.Org X11 libxkbui runtime library

New package mesa
	Mesa graphics libraries

New package selinux-policy-targeted
	SELinux targeted policy configuration

New package xorg-x11-apps
	X.Org X11 applications

New package xorg-x11-drivers
	X.Org X11 driver installation package

New package xorg-x11-drv-acecad
	Xorg X11 acecad input driver

New package xorg-x11-drv-aiptek
	Xorg X11 aiptek input driver

New package xorg-x11-drv-apm
	Xorg X11 apm video driver

New package xorg-x11-drv-ark
	Xorg X11 ark video driver

New package xorg-x11-drv-ati
	Xorg X11 ati video driver

New package xorg-x11-drv-calcomp
	Xorg X11 calcomp input driver

New package xorg-x11-drv-chips
	Xorg X11 chips video driver

New package xorg-x11-drv-cirrus
	Xorg X11 cirrus video driver

New package xorg-x11-drv-citron
	Xorg X11 citron input driver

New package xorg-x11-drv-cyrix
	Xorg X11 cyrix video driver

New package xorg-x11-drv-digitaledge
	Xorg X11 digitaledge input driver

New package xorg-x11-drv-dmc
	Xorg X11 dmc input driver

New package xorg-x11-drv-dummy
	Xorg X11 dummy video driver

New package xorg-x11-drv-dynapro
	Xorg X11 dynapro input driver

New package xorg-x11-drv-elo2300
	Xorg X11 elo2300 input driver

New package xorg-x11-drv-elographics
	Xorg X11 elographics input driver

New package xorg-x11-drv-evdev
	Xorg X11 evdev input driver

New package xorg-x11-drv-fbdev
	Xorg X11 fbdev video driver

New package xorg-x11-drv-fpit
	Xorg X11 fpit input driver

New package xorg-x11-drv-glint
	Xorg X11 glint video driver

New package xorg-x11-drv-hyperpen
	Xorg X11 hyperpen input driver

New package xorg-x11-drv-i128
	Xorg X11 i128 video driver

New package xorg-x11-drv-i740
	Xorg X11 i740 video driver

New package xorg-x11-drv-i810
	Xorg X11 i810 video driver

New package xorg-x11-drv-jamstudio
	Xorg X11 jamstudio input driver

New package xorg-x11-drv-joystick
	Xorg X11 joystick input driver

New package xorg-x11-drv-keyboard
	Xorg X11 keyboard input driver

New package xorg-x11-drv-magellan
	Xorg X11 magellan input driver

New package xorg-x11-drv-magictouch
	Xorg X11 magictouch input driver

New package xorg-x11-drv-mga
	Xorg X11 mga video driver

New package xorg-x11-drv-microtouch
	Xorg X11 microtouch input driver

New package xorg-x11-drv-mouse
	Xorg X11 mouse input driver

New package xorg-x11-drv-mutouch
	Xorg X11 mutouch input driver

New package xorg-x11-drv-neomagic
	Xorg X11 neomagic video driver

New package xorg-x11-drv-nsc
	Xorg X11 nsc video driver

New package xorg-x11-drv-nv
	Xorg X11 nv video driver

New package xorg-x11-drv-palmax
	Xorg X11 palmax input driver

New package xorg-x11-drv-penmount
	Xorg X11 penmount input driver

New package xorg-x11-drv-rendition
	Xorg X11 rendition video driver

New package xorg-x11-drv-s3
	Xorg X11 s3 video driver

New package xorg-x11-drv-s3virge
	Xorg X11 s3virge video driver

New package xorg-x11-drv-savage
	Xorg X11 savage video driver

New package xorg-x11-drv-siliconmotion
	Xorg X11 siliconmotion video driver

New package xorg-x11-drv-sis
	Xorg X11 sis video driver

New package xorg-x11-drv-sisusb
	Xorg X11 sisusb video driver

New package xorg-x11-drv-spaceorb
	Xorg X11 spaceorb input driver

New package xorg-x11-drv-summa
	Xorg X11 summa input driver

New package xorg-x11-drv-tdfx
	Xorg X11 tdfx video driver

New package xorg-x11-drv-tek4957
	Xorg X11 tek4957 input driver

New package xorg-x11-drv-trident
	Xorg X11 trident video driver

New package xorg-x11-drv-tseng
	Xorg X11 tseng video driver

New package xorg-x11-drv-v4l
	Xorg X11 v4l video driver

New package xorg-x11-drv-vesa
	Xorg X11 vesa video driver

New package xorg-x11-drv-vga
	Xorg X11 vga video driver

New package xorg-x11-drv-via
	Xorg X11 via video driver

New package xorg-x11-drv-vmware
	Xorg X11 vmware video driver

New package xorg-x11-drv-void
	Xorg X11 void input driver

New package xorg-x11-drv-voodoo
	Xorg X11 voodoo video driver

New package xorg-x11-font-utils
	X.Org X11 font utilities

New package xorg-x11-fonts
	X.Org X11 fonts

New package xorg-x11-proto-devel
	X.Org X11 Protocol headers

New package xorg-x11-resutils
	X.Org X11 X resource utilities

New package xorg-x11-server
	X.Org X11 X server

New package xorg-x11-server-utils
	X.Org X11 X server utilities

New package xorg-x11-twm
	X.Org X11 twm window manager

New package xorg-x11-util-macros
	X.Org X11 Autotools macros

New package xorg-x11-utils
	X.Org X11 X client utilities

New package xorg-x11-xauth
	X.Org X11 X authority utilities

New package xorg-x11-xbitmaps
	X.Org X11 application bitmaps

New package xorg-x11-xdm
	X.Org X11 xdm - X Display Manager

New package xorg-x11-xfs
	X.Org X11 xfs font server

New package xorg-x11-xfwp
	X.Org X11 X firewall proxy

New package xorg-x11-xinit
	X.Org X11 X Window System xinit startup scripts

New package xorg-x11-xkb-utils
	X.Org X11 xkb utilities

New package xorg-x11-xkbdata
	xkb data files for the X.Org X11 X server

New package xorg-x11-xsm
	X.Org X11 X Session Manager

New package xorg-x11-xtrans-devel
	X.Org X11 developmental X transport library


Removed package slocate

Removed package xinitrc

Removed package fonts-xorg

Removed package usbview

Updated Packages:

SDL-1.2.9-2
-----------
* Tue Nov 15 2005 Warren Togami <wtogami at redhat.com> 1.2.9-2
- -devel req actual X libs

anaconda-10.89.16-1
-------------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 10.89.16-1
- lots of updates for modular X
- allow a shell on tty1 if using vnc
- various fixes for cd/install method stuff (pnasrat, clumens, katzj)
- install smp kernel if NX present (#172345)
- work with multiple videoaliases files (notting)

dhcp-11:3.0.3-11
----------------
* Tue Nov 15 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-11
- Rebuild for FC-5
- fix bug 167028 - test IBM's unicast bootp patch (from xma at us.ibm.com)
- fix bug 171312 - silence chkconfig error message if ypbind not installed
- fix dhcpd.init when -cf arg given to dhcpd
- make dhcpd init touch /var/lib/dhcpd/dhcpd.leases, not /var/lib/dhcp/dhcpd.leases

* Tue Oct 18 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-10
- Allow dhclient route metrics to be specified with DHCP options:
  The dhcp-options(5) man-page states:
  'option routers ... Routers should be listed in order of preference' 
  and
  'option static-routes ... are listed in descending order of priority' .
  No preference / priority could be set with previous dhclient-script .
  Now, dhclient-script provides: 
  Default Gateway (option 'routers') metrics:
    Instead of allowing only one default gateway, if more than one router 
    is specified in the routers option, routers following the first router
    will have a 'metric' of their position in the list (1,...N>1).
  Option static-routes metrics:
    If a target appears in the list more than once, routes for duplicate
    targets will have successively greater metrics, starting at 1.

* Mon Oct 17 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-8
- further fix for bug 160655 / ISC bug 15293 - upstream patch:
  do NOT always strip trailing nulls in the dhcpd server
- handle static-routes option properly in dhclient-script :
  trailing 0 octets in the 'target' IP specify the class -
  ie '172.16.0.0 w.x.y.z' specifies '172.16/16 via w.x.y.z'.

eclipse-1:3.1.1-1jpp_7fc
------------------------
* Tue Nov 15 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_7fc
- Disable ia64 and ppc64 for now (these seem to be upstream issues).

* Thu Nov 10 2005 Andrew Overholt <overholt at redhat.com> 3.1.1-1jpp_7fc
- Build on ppc64 and ia64.
- Add patch for mozilla code with gcc 4:
http://debian-ppc64.alioth.debian.org/gcc4/patches-old/swt-gtk_3.1-1.0.0.1.gcc4.patch

eclipse-cdt-1:3.0.1-1jpp_1fc
----------------------------
* Mon Nov 14 2005 Andrew Overholt <overholt at redhat.com> 3.0.1-1jpp_1fc
- 3.0.1.

emacs-21.4-8
------------
* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 21.4-8
- update dep for new xorg fonts packages

* Wed Aug 24 2005 Jens Petersen <petersen at redhat.com>
- fix name of aspell-es dictionary (#147964)
  - update emacs-21.3-lisp-textmodes-ispell-languages.patch

filesystem-2.3.6-1
------------------
* Mon Nov 07 2005 Bill Nottingham <notting at redhat.com> - 2.3.6-1
- don't package /usr/lib/X11 or /usr/bin/X11

fonts-chinese-3.02-3
--------------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 3.02-3
- fix mkfontdir call

* Tue Nov 15 2005 Warren Togami <wtogami at redhat.com> - 3.02-2
- use less fragile way to call mkfontdir

fonts-japanese-0.20050222-10
----------------------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 0.20050222-10
- better mkfontdir

fonts-korean-1.0.11-8
---------------------
* Tue Nov 15 2005 Jeremy Katz <katzj at redhat.com> - 1.0.11-8
- better mkfontdir call

freetype-2.1.10-4
-----------------
* Tue Nov 01 2005 Matthias Clasen  <mclasen at redhat.com> 2.1.10-4
- Switch requires to modular X

* Fri Oct 21 2005 Matthias Clasen  <mclasen at redhat.com> 2.1.10-3
- BuildRequire gettext

* Wed Oct 12 2005 Jason Vas Dias <jvdias at redhat.com> 2.1.10-2
- fix 'without_bytecode_interpreter 0' build: freetype-2.1.10-enable-ft2-bci.patch

gdm-1:2.8.0.4-12
----------------
* Mon Nov 14 2005 Ray Strode <rstrode at redhat.com> - 1:2.8.0.4-12
- Make sure that dbus-launch gets called if available

* Mon Nov 14 2005 Ray Strode <rstrode at redhat.com> - 1:2.8.0.4-11
- Don't use X session / setup files anymore.
- Don't install early login init scripts
- remove xsri dependency
- don't prune language lists anymore

* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 1:2.8.0.4-10
- also fix default xsession for where its moved in modular X

giflib-4.1.3-6
--------------
* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 4.1.3-6
- Switch requires to modular X
glib2-2.8.4-1
-------------
* Tue Nov 15 2005 Matthias Clasen <mclasen at redhat.com> - 2.8.4-1
- New upstream version

glibc-2.3.90-16
---------------
* Tue Nov 15 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-16
- update from CVS
- make sure waitid syscall is used on ppc*/s390*

* Thu Oct 20 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-15
- update from CVS
  - be permissive in %n check because of kernel bug #165351 (#171240)
  - don't misalign stack in pthread_once on x86_64 (#170786, IT#81521)
  - many locale fixes

* Mon Oct 10 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-14
- update from CVS
  - fix malloc bug after fork introduced in the last update
  - fix getent hosts IP for IPv4 IPs (#169831)

gnome-mag-0.12.2-2
------------------
* Tue Nov 01 2005 Matthias Clasen <mclasen at redhat.com> 0.12.2-2
- Switch requires to modular X

gob2-2.0.12-1
-------------
* Wed Nov 16 2005 Harald Hoyer <harald at redhat.com>
- version 2.0.12

gtk2-2.8.7-1
------------
* Tue Nov 15 2005 Matthias Clasen <mclasen at redhat.com> 2.8.7-1
- Update to 2.8.7

java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_54rh
------------------------------------------
* Tue Nov 15 2005 Archit Shah <ashah at redhat.com> 0:1.4.2.0-40jpp_54rh
- Import java-gcj-compat 1.0.45.

kdbg-1:2.0.0-2
--------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 1:2.0.0-2 
- fix for modular X

kdeadmin-7:3.4.92-2
-------------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 7:3.4.92-2 
- get rid of redundant buildrequires

kdegames-6:3.4.92-2
-------------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 6:3.4.92-2
- apply patch to fix build problem with gcc4

kdemultimedia-6:3.4.92-2
------------------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 6:3.4.92-2 
- get rid of redundant buildrequires

kudzu-1.2.12-1
--------------
* Tue Nov 15 2005 Bill Nottingham <notting at redhat.com> - 1.2.12-1
- allow multiple files for video aliases under /usr/share/hwdata/videoaliases

lam-2:7.1.1-8.FC5
-----------------
* Tue Nov 15 2005 Jason Vas Dias <jvdias at redhat.com> - 2:7.1.1-8
- Rebuild for FC-5

libselinux-1.27.21-2
--------------------
* Tue Nov 15 2005 Dan Walsh <dwalsh at redhat.com> 1.27.21-2
- Remove requirement for libsetrans

magma-1.0.3-3
-------------
* Tue Nov 15 2005 Chris Feist <cfeist at redhat.com>
- used new upstream source to fix dep/soname issues.

mgetty-1.1.33-6.FC5
-------------------
* Mon Aug 01 2005 Jason Vas Dias <jvdias at redhat.com> 1.1.33-4_FC5
- fix bug 63848

* Fri Jul 22 2005 Jason Vas Dias <jvdias at redhat.com> 1.1.33-3_FC5
- fix bug 162174: prevent uninterruptable hang on exit() when
                  direct line disconnected (kernel bug 164002)
		  do tcflush(1,TCOFLUSH) before exit() in sig_goodbye()
	  	  block signals before entering syslog()
  workaround build system 'buffer overflow checks' bug:
                  use memcpy instead of sprintf in record.c, line 53

* Mon Apr 25 2005 Jason Vas Dias <jvdias at redhat.com> 1.1.33-1
- Upgrade to new upstream version 1.1.33

pam-0.80-14
-----------
* Tue Nov 15 2005 Tomas Mraz <tmraz at redhat.com> 0.80-14
- pam_stack is deprecated - log its usage

* Wed Oct 26 2005 Tomas Mraz <tmraz at redhat.com> 0.80-13
- fixed CAN-2005-2977 unix_chkpwd should skip user verification only if
  run as root (#168181)
- link pam_loginuid to libaudit
- support no tty in pam_access (#170467)
- updated audit patch (by Steve Grubb)
- the previous pam_selinux change was not applied properly
- pam_xauth: look for the xauth binary in multiple directories (#171164)

* Wed Oct 26 2005 Dan Walsh <dwalsh at redhat.com> 0.80-12
- Eliminate multiple in pam_selinux

pam_krb5-2.2.1-1
----------------
* Tue Nov 15 2005 Nalin Dahyabhai <nalin at redhat.com> - 2.2.1-1
- update to 2.2.1

pango-1.10.1-6
--------------
* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 1.10.1-6
- switch prereqs to modular X

parted-1.6.25-2
---------------
* Tue Nov 15 2005 Peter Jones <pjones at redhat.com> 1.6.25-2
- add support for partitions on dm devices

pvm-3.4.5-6
-----------
* Tue Nov 15 2005 Jason Vas Dias<jvdias at redhat.com> 3.4.5-6
- Rebuild for FC-5

pwlib-1.8.7-2
-------------
* Tue Nov 15 2005 Harald Hoyer <harald at redhat.com> 1.8.6-2
- make pwlib compile with new ldap and openssl
- -DLDAP_DEPRECATED should be removed ASAP

python-2.4.2-1
--------------
* Tue Nov 15 2005 Mihai Ibanescu <misa at redhat.com> 2.4.2-1
- Upgraded to 2.4.2
- BuildRequires autoconf

* Wed Nov 09 2005 Mihai Ibanescu <misa at redhat.com> 2.4.1-16
- Rebuilding against newer openssl.
- XFree86-devel no longer exists

* Mon Sep 26 2005 Peter Jones <pjones at redhat.com> 2.4.1-14
- Once more -- this time, to fix -EPERM when you run it in a directory
  you can't read from.

pyxf86config-0.3.22-1
---------------------
* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 0.3.20-1
- the X server compiles in the path for rgb.txt, so don't explicitly list 
  (fixes for the path move with modular X)
- get rid of no longer needed %preun
- modular X buildrequires changes

rhgb-0.16.2-12
--------------
* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 0.16.2-12
- fix fontpath for modular x

* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 0.16.2-11
- switch paths to work with modular X

rhpxl-0.6-1
-----------
* Tue Nov 15 2005 Chris Lumens <clumens at redhat.com> 0.6
- Remove xhwstate from path on object creation (#173229).

* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 0.5.2-1
- drivers now end in .so, not .o

* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 0.5.1-1
- unscaled bitmap fonts fixed in libXfont so change our fontpaths back

system-config-display-1.0.33-1
------------------------------
* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 1.0.33-1
- minor changes needed for modular X

tk-8.4.11-2
-----------
* Tue Nov 15 2005 Warren Togami <wtogami at redhat.com> - 8.4.11-2
- xorg-x11-devel -> libX11-devel

transfig-1:3.2.4-12
-------------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 1:3.2.4-12
- fix for modular X

tvtime-1.0.1-2
--------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 1.0.1-2 
- fix for modular X

udev-075-2
----------
* Fri Nov 11 2005 Harald Hoyer <harald at redhat.com> - 075-2
- moved /etc/udev/scripts to /lib/udev
- moved /etc/udev/devices to /lib/udev/devices
- added new event replay for kernel >= 2.6.15
- added usb devices
- renamed cpu device to cpuid (bug #161538)
- changed vendor string "Onstream" to "On[sS]tream" (bug #173043)
- compiled all *_id programs statically

usermode-1.83-1
---------------
* Tue Nov 15 2005 Jindrich Novy <jnovy at redhat.com> 1.83-1
- accept gecos information on commandline for userinfo,
  patch by mclasen at redhat.com (#173232)
- update translations

vnc-4.1.1-18
------------
* Tue Nov 15 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-18
- Build requires xorg-x11-devel not XFree86-devel.

xfig-3.2.4-15
-------------
* Tue Nov 15 2005 Than Ngo <than at redhat.com> 3.2.4-15
- fix for modular X

xterm-207-1
-----------
* Mon Nov 14 2005 Jason Vas Dias<jvdias at redhat.com> - 207-1
- Upgrade to upstream version 207
- Fix app-defaults directory for modular X11

* Sun Nov 13 2005 Jeremy Katz <katzj at redhat.com> - 206-4
- rebuild for newer modular X

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	Xaw3d-devel - 1.5E-4.i386 requires xorg-x11-devel
	cman-kernel - 2.6.14.0-20051108.134753.FC5.3.i686 requires kernel = 0:2.6.14-1.1665_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.3.i686 requires /lib/modules/2.6.14-1.1665_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.3.i686 requires /lib/modules/2.6.14-1.1665_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1665_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel = 0:2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.2.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel = 0:2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1656_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.4.i686 requires /lib/modules/2.6.14-1.1656_FC5smp
	openmotif - 2.2.3-11.i386 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.i386 requires xorg-x11-deprecated-libs-devel
	openmotif-devel - 2.2.3-11.i386 requires xorg-x11-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.i386 requires /etc/init.d/functions



Broken deps for ia64
----------------------------------------------------------
	Xaw3d-devel - 1.5E-4.ia64 requires xorg-x11-devel
	openmotif - 2.2.3-11.ia64 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.ia64 requires xorg-x11-devel
	openmotif-devel - 2.2.3-11.ia64 requires xorg-x11-deprecated-libs-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	rgmanager - 1.9.31-3.ia64 requires ccs
	xorg-x11-xfs - 1:0.99.2-2.ia64 requires /etc/init.d/functions



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	Xaw3d-devel - 1.5E-4.ppc requires xorg-x11-devel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4
	openmotif - 2.2.3-11.ppc requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.ppc requires xorg-x11-deprecated-libs-devel
	openmotif-devel - 2.2.3-11.ppc requires xorg-x11-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.ppc requires /etc/init.d/functions



Broken deps for ppc64
----------------------------------------------------------
	Xaw3d-devel - 1.5E-4.ppc64 requires xorg-x11-devel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	openmotif - 2.2.3-11.ppc64 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.ppc64 requires xorg-x11-devel
	openmotif-devel - 2.2.3-11.ppc64 requires xorg-x11-deprecated-libs-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.ppc64 requires /etc/init.d/functions



Broken deps for s390
----------------------------------------------------------
	Xaw3d-devel - 1.5E-4.s390 requires xorg-x11-devel
	openmotif - 2.2.3-11.s390 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.s390 requires xorg-x11-deprecated-libs-devel
	openmotif-devel - 2.2.3-11.s390 requires xorg-x11-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.s390 requires /etc/init.d/functions



Broken deps for s390x
----------------------------------------------------------
	Xaw3d-devel - 1.5E-4.s390x requires xorg-x11-devel
	openmotif - 2.2.3-11.s390 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif - 2.2.3-11.s390x requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.s390x requires xorg-x11-devel
	openmotif-devel - 2.2.3-11.s390x requires xorg-x11-deprecated-libs-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.s390x requires /etc/init.d/functions



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	GFS-kernel-smp - 2.6.11.8-20050601.152643.FC4.18.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	Xaw3d-devel - 1.5E-4.x86_64 requires xorg-x11-devel
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	cman-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	dlm-kernel-smp - 2.6.11.5-20050601.152643.FC4.15.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires kernel-smp = 0:2.6.13-1.1532_FC4
	gnbd-kernel-smp - 2.6.11.2-20050420.133124.FC4.51.x86_64 requires /lib/modules/2.6.13-1.1532_FC4smp
	openmotif - 2.2.3-11.x86_64 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif - 2.2.3-11.i386 requires /usr/X11R6/lib/X11/XKeysymDB
	openmotif-devel - 2.2.3-11.x86_64 requires xorg-x11-devel
	openmotif-devel - 2.2.3-11.x86_64 requires xorg-x11-deprecated-libs-devel
	python-docs - 2.4.1-1.noarch requires python = 0:2.4.1
	xorg-x11-xfs - 1:0.99.2-2.x86_64 requires /etc/init.d/functions





From shiva at sewingwitch.com  Wed Nov 16 13:30:42 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Wed, 16 Nov 2005 05:30:42 -0800
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <88E7ED75E2E9618B698764FA@[10.0.0.14]>

--On Tuesday, November 15, 2005 4:12 PM -0500 Dimi Paun <dimi at lattica.com> 
wrote:

> From: "Luke Macken" <lmacken at redhat.com>
>>  o FAST AS HELL[0]
> Fast, but can we do better?

It's funny how the discussion gets lost in a focus on speed, and the other 
benefits that are more important to servers seem to get ignored (at least 
for discussion).

To me the big wins are explicit expression of dependencies instead of 
numbered start/stop order, and better integration with hot-plugging.

The speed is nice, but to me it's the ability of the system to describe the 
desired relationships clearly that makes the admin's life more bearable.



From linux_4ever at yahoo.com  Wed Nov 16 13:37:30 2005
From: linux_4ever at yahoo.com (Steve G)
Date: Wed, 16 Nov 2005 05:37:30 -0800 (PST)
Subject: Dependency problems not reported
Message-ID: <20051116133730.95035.qmail@web51515.mail.yahoo.com>

Hi,

Ever since the openssl upgrade last week, I have not been able to run "yum
update" and have it actually update the system. I looked at it and I see
dependency problems that are not being reported by the rawhide report:

--> Finished Dependency Resolution
Error: Missing Dependency: xorg-x11-devel is needed by package openmotif-devel
Error: Missing Dependency: libcrypto.so.5 is needed by package iiimf-libs
Error: Missing Dependency: libssl.so.5()(64bit) is needed by package iiimf-libs
Error: Missing Dependency: /usr/X11R6/lib/X11/XKeysymDB is needed by package
openmotif
Error: Missing Dependency: libXv.so.1 is needed by package HelixPlayer
Error: Missing Dependency: xorg-x11-devel is needed by package Xaw3d-devel
Error: Missing Dependency: xorg-x11-devel = 6.8.2-62 is needed by package
xorg-x11-deprecated-libs-devel
Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
Error: Missing Dependency: libssl.so.5 is needed by package w3c-libwww
Error: Missing Dependency: libcrypto.so.5 is needed by package w3c-libwww
Error: Missing Dependency: libcrypto.so.5()(64bit) is needed by package iiimf-libs


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



From mharris at redhat.com  Wed Nov 16 13:48:55 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 08:48:55 -0500
Subject: Dependency problems not reported
In-Reply-To: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
References: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
Message-ID: <437B38C7.6040705@redhat.com>

Steve G wrote:
> Hi,
> 
> Ever since the openssl upgrade last week, I have not been able to run "yum
> update" and have it actually update the system. I looked at it and I see
> dependency problems that are not being reported by the rawhide report:
> 
> --> Finished Dependency Resolution
> Error: Missing Dependency: xorg-x11-devel is needed by package openmotif-devel

Bug in openmotif packaging.

> Error: Missing Dependency: libcrypto.so.5 is needed by package iiimf-libs
> Error: Missing Dependency: libssl.so.5()(64bit) is needed by package iiimf-libs
> Error: Missing Dependency: /usr/X11R6/lib/X11/XKeysymDB is needed by package
> openmotif

Bug in openmotif packaging.

> Error: Missing Dependency: libXv.so.1 is needed by package HelixPlayer

$ rpm -qp --provides libXv-0.99.1-2.i386.rpm
libXv.so.1
libXv = 0.99.1-2

Looks like a bug in HelixPlayer.  Perhaps it is using -rpath?

> Error: Missing Dependency: xorg-x11-devel is needed by package Xaw3d-devel

Bug in Xaw3d.

> Error: Missing Dependency: xorg-x11-devel = 6.8.2-62 is needed by package
> xorg-x11-deprecated-libs-devel

Doh, bug in libXp packaging.  I just fixed it in 2 milliseconds though.

Did I ever mention how much I love modular X, because it is so simple to
fix a small bug in one tiny package now, and not have to wait 6 hours
for the package to build on every architecture known to man?  If not, I
guess I just did. ;o)



From mharris at redhat.com  Wed Nov 16 14:03:21 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 09:03:21 -0500
Subject: Dependency problems not reported
In-Reply-To: <437B38C7.6040705@redhat.com>
References: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
	<437B38C7.6040705@redhat.com>
Message-ID: <437B3C29.5060303@redhat.com>

Mike A. Harris wrote:

>> Error: Missing Dependency: xorg-x11-devel = 6.8.2-62 is needed by package
>> xorg-x11-deprecated-libs-devel
> 
> 
> Doh, bug in libXp packaging.  I just fixed it in 2 milliseconds though.
> 
> Did I ever mention how much I love modular X, because it is so simple to
> fix a small bug in one tiny package now, and not have to wait 6 hours
> for the package to build on every architecture known to man?  If not, I
> guess I just did. ;o)


libXp-0.99.1-3 is now available for download via ftp at the following 
URL:  ftp://people.redhat.com/mharris/testing/unstable



From fedora at camperquake.de  Wed Nov 16 14:08:49 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 16 Nov 2005 15:08:49 +0100
Subject: Dependency problems not reported
In-Reply-To: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
References: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
Message-ID: <20051116140849.GA23405@ryoko.camperquake.de>

On Wed, Nov 16, 2005 at 05:37:30AM -0800, Steve G wrote:

> Ever since the openssl upgrade last week, I have not been able to run "yum
> update" and have it actually update the system. I looked at it and I see
> dependency problems that are not being reported by the rawhide report:

> Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs

iiimf* has been removed from FC some time ago.



From mharris at redhat.com  Wed Nov 16 14:09:27 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 09:09:27 -0500
Subject: MODULAR X updates:  new drivers available
Message-ID: <437B3D97.8050604@redhat.com>

I updated the modular X drivers, but didn't beat the morning rawhide
sync scripts, so they didn't get into the tree today, or at least
not all of them.  The older drivers should work too, but the new ones
are the X11R7 RC2 drivers.

If you experience X video problems today, please update to these new
drivers:

	ftp://people.redhat.com/mharris/testing/unstable


If you still have problems, be sure to file a bug report in X.Org
bugzilla at http://bugs.freedesktop.org in the "xorg" component, and
attach your X server log and config file.

Happy testing.



From sundaram at redhat.com  Wed Nov 16 14:11:04 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 16 Nov 2005 19:41:04 +0530
Subject: Dependency problems not reported
In-Reply-To: <20051116140849.GA23405@ryoko.camperquake.de>
References: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
	<20051116140849.GA23405@ryoko.camperquake.de>
Message-ID: <437B3DF8.9040406@redhat.com>

Ralf Ertzinger wrote:

>On Wed, Nov 16, 2005 at 05:37:30AM -0800, Steve G wrote:
>
>  
>
>>Ever since the openssl upgrade last week, I have not been able to run "yum
>>update" and have it actually update the system. I looked at it and I see
>>dependency problems that are not being reported by the rawhide report:
>>    
>>
>
>  
>
>>Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
>>    
>>
>
>iiimf* has been removed from FC some time ago.
>
>  
>
SCIM packages should have been obsoleting all the IIMF ones. Looks like 
this one was left out. Kindly file a bug report

regards
Rahul



From linville at redhat.com  Wed Nov 16 14:25:18 2005
From: linville at redhat.com (John W. Linville)
Date: Wed, 16 Nov 2005 09:25:18 -0500
Subject: fedora-netdev.1 IPv6 freeze [Re: [ANNOUNCE] fedora-netdev
	kernel repository]
In-Reply-To: <20051116114224.GB20395@postel.suug.ch>
References: <20051114205110.GK25755@redhat.com>
	<Pine.LNX.4.64.0511161242260.26498@netcore.fi>
	<20051116114224.GB20395@postel.suug.ch>
Message-ID: <20051116142518.GE8356@redhat.com>

On Wed, Nov 16, 2005 at 12:42:24PM +0100, Thomas Graf wrote:
> * Pekka Savola <pekkas at netcore.fi> 2005-11-16 12:46
> > On Mon, 14 Nov 2005, John W. Linville wrote:
> > >	http://people.redhat.com/linville/kernels/fedora-netdev/
> > 
> > I guess the test can be termed a 'success' because after updating from 
> > 2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 100% 
> > reproducible kernel hang (everything just freezes as it is, no message 
> > to /var/log/messages or anywhere) after I run '/sbin/ip -6 r l' or try 
> > to use IPv6 in basically any other way on my ThinkPad laptop with 
> > external orinoco_cs WLAN card.
> > 
> > Any thoughts for the next steps?
> 
> It's probably missing this patch:

It was...

Pekka, I have included the patch Thomas identified as part of the
FC4.netdev.2 build.  You may want to do a 'yum update' and try it out.

Thanks!

John
-- 
John W. Linville
linville at redhat.com



From jspaleta at gmail.com  Wed Nov 16 14:25:34 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 09:25:34 -0500
Subject: Dependency problems not reported
In-Reply-To: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
References: <20051116133730.95035.qmail@web51515.mail.yahoo.com>
Message-ID: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>

On 11/16/05, Steve G <linux_4ever at yahoo.com> wrote:
> Hi,
>
> Ever since the openssl upgrade last week, I have not been able to run "yum
> update" and have it actually update the system. I looked at it and I see
> dependency problems that are not being reported by the rawhide report:

You have to be careful and know how to distinquish errors on your
system that result when a package is removed from rawhide and is no
longer recieving development updates.

> Error: Missing Dependency: xorg-x11-devel is needed by package openmotif-devel
reported in rawhide report: 20051116 changes

> Error: Missing Dependency: libcrypto.so.5 is needed by package iiimf-libs
iiimf-libs is no longer in the rawhide tree, so that would explain a
lack of report

> Error: Missing Dependency: libssl.so.5()(64bit) is needed by package iiimf-libs
> Error: Missing Dependency: /usr/X11R6/lib/X11/XKeysymDB is needed by package
> openmotif
reported in rawhide report: 20051116 changes

> Error: Missing Dependency: libXv.so.1 is needed by package HelixPlayer
I don't understand why you have this error.
libXv-0:0.99.1-2.i386  in today's tree provides  libXv.so.1 so
HelixPlayer package doesn't appear to be missing any deps at the
moment
And considering that gstreamer-plugins also requires libXv.so.1 i find
it odd that you wouldn't get an error about gstreamer-plugins as well.
I can't seem to reproduce the Helix error.

> Error: Missing Dependency: xorg-x11-devel is needed by package Xaw3d-devel
reported in rawhide report: 20051116 changes

> Error: Missing Dependency: xorg-x11-devel = 6.8.2-62 is needed by package
> xorg-x11-deprecated-libs-devel
xorg-x11-deprecated-libs-devel was removed from the tree so hence no
rawhide report about its missing deps

> Error: Missing Dependency: libssl.so.5 is needed by package iiimf-libs
iiimf-libs is no longer in the tree

> Error: Missing Dependency: libssl.so.5 is needed by package w3c-libwww
> Error: Missing Dependency: libcrypto.so.5 is needed by package w3c-libwww
w3c-libwww removed from the tree

> Error: Missing Dependency: libcrypto.so.5()(64bit) is needed by package iiimf-libs
iiimf-libs removed from the tree


-jef



From linville at redhat.com  Wed Nov 16 14:33:56 2005
From: linville at redhat.com (John W. Linville)
Date: Wed, 16 Nov 2005 09:33:56 -0500
Subject: kernel-2.6.14-1.1637_FC4.netdev.2 now available
In-Reply-To: <20051114205110.GK25755@redhat.com>
References: <20051114205110.GK25755@redhat.com>
Message-ID: <20051116143356.GF8356@redhat.com>

The second FC4 fedora-netdev kernel is now available.  If you are
already a fedora-netdev user, a simple 'yum update' should retrieve
the new kernels for you.

I now have a fedora-netdev-release package available.  This simplifies
the process of configuring yum for the fedora-netdev repository.
The FC4 fedora-netdev-release package is available here:

	http://people.redhat.com/linville/kernels/fedora-netdev/4/fedora-netdev-release-4-0.noarch.rpm

Download and install that, then you will be able to use yum to get
the FC4 fedora-netdev kernels.

Thanks, and good luck! :-)

John

P.S.  What is fedora-netdev?

The purpose of this repository is two-fold: 1) to make bleeding-edge
linux kernel networking developments available to Fedora users who
need or want access to them; and, 2) to open-up the Fedora user
base as a better testing resource for the kernel netdev community.
I hope this will prove to be a win-win situation for both camps.

If you are a Fedora user with an interest or need for the latest
developments in Linux kernel networking, then _please_ try the
kernels from this repository.  Your testing and feedback is greatly
appreciated, desperately requested, and graciously accepted.
Thanks in advance!

P.P.S.  What netdev patches are in it?

- sky2: new experimental Marvell Yukon2 driver
- 8139cp: support ETHTOOL_GPERMADDR
- 8139too: support ETHTOOL_GPERMADDR
- b44: support ETHTOOL_GPERMADDR
- e1000: support ETHTOOL_GPERMADDR
- e100: support ETHTOOL_GPERMADDR
- forcedeth: support ETHTOOL_GPERMADDR
- ixgb: support ETHTOOL_GPERMADDR
- ne2k-pci: support ETHTOOL_GPERMADDR
- pcnet32: support ETHTOOL_GPERMADDR
- r8169: support ETHTOOL_GPERMADDR
- skge: support ETHTOOL_GPERMADDR
- sundance: support ETHTOOL_GPERMADDR
- via-rhine: support ETHTOOL_GPERMADDR
- drivers/net: fix-up schedule_timeout() usage
- Replace drivers/net/wan custom ctype macros with standard ones
- drivers/net/wan/: possible cleanups
- lne390 bogus casts
- C99 initializers in ray_cs.c
- mii: Add test for GigE support
- Add rapidio net driver
- pcnet32: set_ringparam implementation
- pcnet32: set min ring size to 4
- sky2: driver update.
- orinoco: Remove conditionals that are useless in the kernel drivers.
- orinoco: Don't include <net/ieee80211.h> twice.
- orinoco: Update PCMCIA ID's.
- Fixed some endian issues with 802.11 header usage in ieee80211_rx.c
- ieee80211 quality scaling algorithm extension handler
- ieee80211 Added wireless spy support
- Changed 802.11 headers to use ieee80211_info_element[0]
- ieee80211 Removed ieee80211_info_element_hdr
- ieee80211 Cleanup memcpy parameters.
- ieee80211 Switched to sscanf in store_debug_level
- ieee80211 Fixed type-o of abg_ture -> abg_true
- Updated ipw2200 to compile with ieee80211 abg_ture to abg_true change
- sky2: fix FIFO DMA alignment problems
- sky2: allow ethtool debug access to all of PCI space
- sky2: version 0.5
- ieee80211: Updated ipw2100 to be compatible with ieee80211_hdr changes
- ieee80211: Updated ipw2100 to be compatible with ieee80211's hard_start_xmit change
- ieee80211: Updated ipw2200 to be compatible with ieee80211_hdr changes
- ieee80211: Updated ipw2200 to be compatible with ieee80211's hard_start_xmit change.
- ieee80211: Updated atmel to be compatible with ieee80211_hdr changes
- ieee80211: Fixed a kernel oops on module unload
- ieee80211: Hardware crypto and fragmentation offload support
- ieee80211: Fix time calculation, switching to use jiffies_to_msecs
- ieee80211: Fix kernel Oops when module unload
- ieee80211: Allow drivers to fix an issue when using wpa_supplicant with WEP
- ieee82011: Added WE-18 support to default wireless extension handler
- ieee80211: Renamed ieee80211_hdr to ieee80211_hdr_3addr
- ieee80211: adds support for the creation of RTS packets
- ieee82011: Added ieee80211_tx_frame to convert generic 802.11 data frames, and callbacks
- ieee80211: Fix TKIP, repeated fragmentation problem, and payload_size reporting
- ieee80211: Return NETDEV_TX_BUSY when QoS buffer full
- ieee80211: Add QoS (WME) support to the ieee80211 subsystem
- ieee80211: Added ieee80211_geo to provide helper functions
- ieee80211: Added ieee80211_radiotap.h
- ieee80211: Additional fixes for endian-aware types
- ieee80211: "extern inline" to "static inline"
- ieee80211: Type-o, capbility definition for QoS, and ERP parsing
- ieee80211: Mixed PTK/GTK CCMP/TKIP support
- ieee80211: Keep auth mode unchanged after iwconfig key off/on cycle
- ieee80211: Updated copyright dates
- ieee80211: Updated hostap to be compatible with ieee80211_hdr changes
- ieee80211: Updated hostap to be compatible with extra_prefix_len changes
- ieee82011: Remove WIRELESS_EXT ifdefs
- forcedeth: add hardware tx checksumming
- ieee80211: Added subsystem version string and reporting via MODULE_VERSION
- ieee80211: Added handle_deauth() callback, enhanced tkip/ccmp support of varying hw/sw offload
- ieee80211: added IE comments, reason_code to reason, removed info_element from ieee80211_disassoc
- ieee80211: in-tree driver updates to sync with latest ieee80211 series
- ieee80211: update orinoco, wl3501 drivers for latest struct naming
- orinoco: Remove inneeded system includes.
- orinoco: Make nortel_pci_hw_init() static.
- orinoco: Fix memory leak and unneeded unlock in orinoco_join_ap()
- orinoco: orinoco_send_wevents() could return without unlocking.
- orinoco: Remove unneeded forward declarations.
- orinoco: Annotate endianess of variables and structure members.
- orinoco: Read only needed data in __orinoco_ev_txexc().
- orinoco: Bump version to 0.15rc3.
- RPC: Report connection errors properly when mounting with "soft"
- RPC: proper soft timeout behavior for rpcbind
- NFS: use a constant value for TCP retransmit timeouts
- RPC: portmapper doesn't need a reserved port
- RPC: extract socket logic common to both client and server
- RPC: introduce client-side transport switch
- RPC: transport switch function naming
- RPC: Reduce stack utilization in xs_sendpages
- RPC: Rename sock_lock
- RPC: Rename xprt_lock
- RPC: rename the sockstate field
- RPC: Eliminate socket.h includes in RPC client
- RPC: Add helper for waking tasks pending on a transport
- RPC: client-side transport switch cleanup
- RPC: separate TCP and UDP write space callbacks
- RPC: separate TCP and UDP transport connection logic
- RPC: separate TCP and UDP socket write paths
- RPC: skip over transport-specific heads automatically
- RPC: get rid of xprt->stream
- RPC: add API to set transport-specific timeouts
- RPC: expose API for serializing access to RPC transports
- RPC: expose API for serializing access to RPC transports
- RPC: separate xprt_timer implementations
- RPC: add generic interface for adjusting the congestion window
- RPC: add a release_rqst callout to the RPC transport switch
- RPC: remove xprt->nocong
- RPC: clean up after nocong was removed
- RPC: allow RPC client's port range to be adjustable
- RPC: make sure to get the same local port number when reconnecting
- RPC: parametrize various transport connect timeouts
- RPC: rationalize set_buffer_size
- RPC,NFS: new rpc_pipefs patch
- Revert "[PATCH] RPC,NFS: new rpc_pipefs patch"
- SUNRPC: fix bug in patch "portmapper doesn't need a reserved port"
- [netdrvr gianfar] use new phy layer
- [netdrvr] delete CONFIG_PHYCONTROL
- hostap: Fix pci_driver name for hostap_plx and hostap_pci
- hostap: Add support for WE-19
- hostap: Use GFP_ATOMIC to get rid of weird might_sleep issue
- hostap: Remove iwe_stream_add_event kludge
- Remove WIRELESS_EXT ifdefs from several wireless drivers.
- [wireless airo] remove needed dma_addr_t obfuscation
- sky2: changing mtu doesn't have to reset link
- sky2: cleanup interrupt processing
- sky2: add hardware VLAN acceleration support
- sky2: explicit set power state
- sky2: version 0.6
- sky2: nway reset (BONUS FEATURE)
- This patch fixes a typo in ieee80211.h: ieee82011_deauth -> ieee80211_deauth
- This will move the ieee80211_is_ofdm_rate function to the ieee80211.h
- Currently the info_element is parsed by 2 seperate functions, this
- When an assoc_resp is received the network structure is not completely
- Lindent and trailing whitespace script executed ieee80211 subsystem
- hostap: Remove hw specific dev_open/close handlers
- hostap: Fix hostap_pci build with PRISM2_IO_DEBUG
- hostap: Do not free local->hw_priv before unregistering netdev
- hostap: Unregister netdevs before freeing local data
- S2io: MSI/MSI-X support (runtime configurable)
- e1000: Support for 82571 and 82572 controllers
- e1000: multi-queue defines/modification to data structures
- e1000: implementation of the multi-queue feature
- e1000: Enable custom configuration bits for 82571/2 controllers
- e1000: Fixes for packet split related issues
- e1000: Added msleep_interruptible delay
- e1000: Flush shadow RAM
- e1000: fix warnings
- AX.25: Delete debug printk from mkiss driver
- AX.25: Convert mkiss.c to DEFINE_RWLOCK
- airo: fix resume
- s2io: change strncpy length arg to use size of target
- [netdrvr s2io] Add a MODULE_VERSION entry
- bonding: replicate IGMP traffic in activebackup mode
- sky2: add permanent address support.
- [wireless ipw2200] remove redundant return statement
- S2io: Offline diagnostics fixes
- rcu in bpqether driver.
- SMACK support for mkiss
- Initialize the .owner field the tty_ldisc structure.
- SUNRPC: Retry rpcbind requests if the server's portmapper isn't up
- RPC: allow call_encode() to delay transmission of an RPC call.
- ieee80211: division by zero fix
- sb1250-mac: Check the actual setting for reporting hw checksumming.
- sb1250-mac: Ensure 16-byte alignment of the descriptor ring.
- au1000_eth: Misc Au1000 net driver fixes.
- de2104x: Resurrect Cobalt support for 2.6.
- sgiseeq: Fix resource handling.
- sgiseeq: Configure PIO and DMA timing requests.
- declance: Convert to irqreturn_t.
- declance: Fix mapping of device.
- declance: Deal with the bloody KSEG vs CKSEG horror...
- declance: Use physical addresses at the interface level.
- ne: Support for RBHMA4500 eval board.
- mipsnet: Virtual ethernet driver for MIPSsim.
- e1000_intr build fix
- s2io build fix
- via-rhine: change mdelay to msleep and remove from ISR path
- epic100: fix counting of work_done in epic_poll
- bonding: cleanup comment for mode 1 IGMP xmit hack
- b44: alternate allocation option for DMA descriptors
- orinoco: remove redundance skb length check before padding
- sundance: remove if (1) { ... } block in sundance_probe1
- sundance: expand reset mask
- e1000 build fix
- RPC: stops the release_pipe() funtion from being called twice
- SUNRPC: Add support for privacy to generic gss-api code.
- SUNRPC: Provide a callback to allow free pages allocated during xdr encoding
- SUNRPC: Retry wrap in case of memory allocation failure.
- RPCSEC_GSS: cleanup au_rslack calculation
- RPCSEC_GSS: client-side privacy support
- RPCSEC_GSS: Simplify rpcsec_gss crypto code
- RPCSEC_GSS: krb5 pre-privacy cleanup
- RPCSEC_GSS: Add support for privacy to krb5 rpcsec_gss mechanism.
- RPCSEC_GSS remove all qop parameters
- RPCSEC_GSS: krb5 cleanup
- Fixed problem with not being able to decrypt/encrypt broadcast packets.
- sb1250-mac: Get rid of all the funny SBMAC_WRITECSR and SBMAC_READCSR macros.
- sb1250-mac: Whitespace cleanup.
- sundance: include MII address 0 in PHY probe
- e1000: Driver version, white space, comments, device id & other
- Fixed oops if an uninitialized key is used for encryption.
- sb1250-mac: PHY probing fixes.
- ieee80211 subsystem:
- Update version ieee80211 stamp to 1.1.6
- [PARISC] Change the driver names so /sys/bus/parisc/drivers/ looks better
- [PARISC] Convert parisc_device to use struct resource for hpa
- [PARISC] Add NETPOLL support to lasi_82596
- [DECNET]: Remove some redundant ifdeffed code
- [NET]: Wider use of for_each_*cpu()
- [PKTGEN]: Sleeping function called under lock
- [PKTGEN]: Use kzalloc
- [PKTGEN]: Spelling and white space
- [PKTGEN]: proc interface revision
- [NETFILTER] ip_conntrack: Make "hashsize" conntrack parameter writable
- [IPV4]: Kill redundant rcu_dereference on fa_info
- [IPSEC]: Kill obsolete get_mss function
- [NETLINK]: Remove dead code in af_netlink.c
- [IPV4]: Remove dead code from ip_output.c
- [SK_BUFF] kernel-doc: fix skbuff warnings
- [AX.25]: Use constant instead of magic number
- [IPV4]: Fix setting broadcast for SIOCSIFNETMASK
- [netdrvr forcedeth] scatter gather and segmentation offload support
- ieee80211 build fix
- Revert "RPC: stops the release_pipe() funtion from being called twice"
- RPC: Ensure that nobody can queue up new upcalls after rpc_close_pipes()
- gfp_t: net/*
- gfp_t: drivers/net
- [ARM] 2919/1: CS8900A ethernet driver modifications for the Comdial MP1000
- [ARM] 2897/2: PXA2xx IRDA support
- sky2: remove unused definitions
- sky2: use kzalloc
- sky2: spelling fixes
- sky2: fix NAPI and receive handling
- sky2: version 0.7
- DRIVER MODEL: Get rid of the obsolete tri-level suspend/resume callbacks
- [Bluetooth] Make more functions static
- [Bluetooth] Update security filter for Extended Inquiry Response
- [IPv4/IPv6]: UFO Scatter-gather approach
- [MCAST] IPv6: Fix algorithm to compute Querier's Query Interval
- tg3: add 5714/5715 support
- tg3: fix ASF heartbeat
- tg3: update version and minor fixes
- ibmveth fix bonding
- ibmveth fix buffer pool management
- ibmveth fix buffer replenishing
- ibmveth lockless TX
- ibmveth fix failed addbuf
- pcnet_cs: fix mii init code for older DL10019 based cards
- s2io: kconfig help fix
- b44 reports wrong advertised flags
- sis190.c: fix multicast MAC filter
- smc91x: shut down power after probing
- starfire: free_irq() on error path of netdev_open()
- [netdrvr b44] include linux/dma-mapping.h to eliminate warning
- sundance: fix DFE-580TX Tx Underrun
- New PowerPC 4xx on-chip ethernet controller driver
- sis900: come alive after temporary memory shortage
- Add Wake on LAN support to sis900 (2)
- drivers/net: Remove pointless checks for NULL prior to calling kfree()
- [netdrvr] ne2k-pci based card does not support bus-mastering.
- ipw2200: Missing kmalloc check
- [SCTP] Rename SCTP specific control message flags.
- [SCTP] Fix SCTP_SETADAPTION sockopt to use the correct structure.
- [SCTP] Allow SCTP_MAXSEG to revert to default frag point with a '0' value.
- [SCTP] Do not allow unprivileged programs initiating new associations on
- e1000: remove warning about e1000_suspend
- eepro.c: module_param_array cleanup
- b44: fix suspend/resume
- e1000: use vmalloc_node()
- revert "orinoco: Information leakage due to incorrect padding"
- Better fixup for the orinoco driver
- e1000: Fixes e1000_suspend warning when CONFIG_PM is not enabled
- [ETH]: ether address compare
- Add modalias for pmac network drivers
- mv643xx_eth_showsram: Added information message when using the SRAM
- [IPV4]: Fix issue reported by Coverity in ipv4/fib_frontend.c
- s2io iomem annotations
- bluetooth hidp is broken on s390
- drivers/net/tg3: Use the DMA_{32,64}BIT_MASK constants
- prism54: Free skb after disabling interrupts
- [DRIVER MODEL] Add missing platform_device.h header.
- PPC 44x EMAC driver: add 440SPe support
- PPC 44x EMAC driver: add 440GR support
- PPC 4xx EMAC driver: fix VSC8201 PHY initialization
- fec_8xx: Remove dependency on NETTA & NETPHONE
- fec_8xx: Add support for Intel PHY LX971
- vmalloc_node
- [ARM] 3066/1: Fix PXA irda driver suspend/resume functions
- m32r: SMC91x driver update
- smsc-ircc2: PM cleanup - do not close device when suspending
- remove some more check_region stuff
- Typo fix: dot after newline in printk strings
- sparse cleanups: NULL pointers, C99 struct init.
- [netdrvr 8139too] replace hand-crafted kernel thread with workqueue
- [BRIDGE]: Use ether_compare
- [NETFILTER]: Add "revision" support to arp_tables and ip6_tables
- [ROSE]: rose_heartbeat_expiry() locking fix
- [IPV6]: Fix behavior of ip6_route_input() for link local address
- [DCCP]: Simplify skb_set_owner_w semantics
- [DCCP]: Set socket owner iff packet is not data
- [MCAST] IPv6: Check packet size when process Multicast
- ibmveth fix panic in initial replenish cycle
- [MCAST]: ip[6]_mc_add_src should be called when number of sources is zero
- [IPV6]: inet6_ifinfo_notify should use RTM_DELLINK in addrconf_ifdown
- [PKT_SCHED]: Rework QoS and/or fair queueing configuration
- ARM: Reverted 2919/1: CS8900A ethernet driver modifications for the Comdial MP1000
- SUNRPC: allow sunrpc.o to link when CONFIG_SYSCTL is disabled
- NFS,SUNRPC,NLM: fix unused variable warnings when CONFIG_SYSCTL is disabled
- [NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
- [NETFILTER] PPTP helper: Fix endianness bug in GRE key / CallID NAT
- [NETFILTER] NAT: Fix module refcount dropping too far
- [netdrvr 8139too] use cancel_rearming_delayed_work() to cancel thread
- [netdrvr 8139too] use rtnl_shlock_nowait() rather than rtnl_lock_interruptible()
- [NETFILTER]: Fix double free after netlink_unicast() in ctnetlink
- [NETFILTER] nfnetlink: Use kzalloc
- [NETFILTER]: CONNMARK target needs ip_conntrack
- [NETFILTER] nf_queue: Fix Ooops when no queue handler registered
- [NETEM]: use PSCHED_LESS
- drivers/net/wireless/airo.c unsigned comparason
- S2io: Multi buffer mode support
- pcnet32: show name of failing device
- pcnet32: AT2700/2701 and Bugzilla 2699 & 4551
- pcnet32: Prevent hang with 79c976
- phy address mask support for generic phy layer
- [PKT_SCHED]: Generic RED layer
- [NET]: Introduce INET_ECN_set_ce() function
- [PKT_SCHED]: RED: Use new generic red interface
- [PKT_SCHED]: RED: Use generic queue management interface
- [PKT_SCHED]: RED: Dont start idle periods while already idling
- [PKT_SCHED]: RED: Cleanup and remove unnecessary code
- [PKT_SCHED]: GRED: Cleanup equalize flag and add new WRED mode detection
- [PKT_SCHED]: GRED: Transform grio to GRED_RIO_MODE
- [PKT_SCHED]: GRED: Cleanup dumping
- [PKT_SCHED]: GRED: Dump table definition
- [PKT_SCHED]: GRED: Use a central table definition change procedure
- [PKT_SCHED]: GRED: Report out-of-bound DPs as illegal
- [PKT_SCHED]: GRED: Use central VQ change procedure
- [PKT_SCHED]: GRED: Use new generic red interface
- [PKT_SCHED]: GRED: Do not reset statistics in gred_reset/gred_change
- [PKT_SCHED]: GRED: Report congestion related drops as NET_XMIT_CN
- [PKT_SCHED]: GRED: Use generic queue management interface
- [PKT_SCHED]: GRED: Introduce tc_index_to_dp()
- [PKT_SCHED]: GRED: Improve error handling and messages
- [PKT_SCHED]: GRED: Remove initd flag
- [PKT_SCHED]: GRED: Dont abuse default VQ for equalizing
- [PKT_SCHED]: GRED: Remove auto-creation of default VQ
- [PKT_SCHED]: GRED: Cleanup and remove unnecessary code
- [PKT_SCHED]: GRED: Fix restart of idle period in WRED mode upon dequeue and drop
- [PKT_SCHED]: GRED: Support ECN marking
- [PKT_SCHED]: (G)RED: Introduce hard dropping
- [DRIVER MODEL] Improved dynamically allocated platform_device interface
- [DRIVER MODEL] Fix depca
- [DRIVER MODEL] Fix jazzsonic
- [DRIVER MODEL] Fix macsonic
- [NETEM]: Support time based reordering
- [NETEM]: Add version string
- [NET]: Fix race condition in sk_stream_wait_connect
- [TCP/DCCP]: Randomize port selection
- drivers/net/ixgb/: make some code static
- drivers/net/e1000/: possible cleanups
- drivers/net/hamradio/dmascc.c: remove dmascc_setup()
- prism54: Remove redundant assignment
- bnx2: add 5708 support
- bnx2: update firmware for 5708
- bnx2: update nvram code for 5708
- bnx2: update firmware handshake for 5708
- bnx2: refine bnx2_poll
- bnx2: update version and minor fixes
- Remove linux/version.h include from drivers/net/phy/* and net/ieee80211/*.
- [netdrvr] fac_8xx build fix
- [netdrvr s2io] warning fixes
- b44: b44_start_xmit returns with a lock held when it fails allocating
- b44: miscellaneous cleanup
- b44: expose counters through ethtool
- b44: s/spin_lock_irqsave/spin_lock/ in b44_interrupt
- b44: late request_irq in b44_open
- 3c59x: convert to use of pci_iomap API
- 3c59x: cleanup of mdio_read routines to use MII_* macros
- 3c59x: avoid blindly reading link status twice
- 3c59x: bounds checking for hw_checksums
- 3c59x: cleanup init of module parameter arrays
- 3c59x: fix some grammar in module parameter descriptions
- 3c59x: support ETHTOOL_GPERMADDR
- 3c59x: correct rx_dropped counting
- 3c59x: enable use of memory-mapped PCI I/O
- 3c59x: don't enable scatter/gather w/o checksum support
- knfsd: make sure svc_process call the correct pg_authenticate for multi-service port
- kernel-doc: fix warnings in vmalloc.c
- m68knommu: FEC ethernet header support for the ColdFire 5208
- m68knommu: FEC ethernet support for the ColdFire 5208
- scripts/Lindent on ieee80211 subsystem.
- Fix problem with WEP unicast key > index 0
- Update version ieee80211 stamp to 1.1.7
- Ran scripts/Lindent on drivers/net/wireless/ipw2{1,2}00.{c,h}
- IPW_DEBUG has already included DRV_NAME, remove double prefix print.
- Catch ipw2200 up to equivelancy with v1.0.1
- Catch ipw2200 up to equivelancy with v1.0.2
- Catch ipw2200 up to equivelancy with v1.0.3
- Catch ipw2200 up to equivelancy with v1.0.4
- Catch ipw2100 up to equivelancy with v1.1.1
- Fixed WEP on ipw2100 (priv->sec was being used instead of
- [Bug 339] Fix ipw2100 iwconfig set/get txpower.
- Move code from ipw2100_wpa_enable to IPW2100_PARAM_DROP_UNENCRYPTED to
- Catch ipw2200 up to equivelancy with v1.0.5
- Fix hardware encryption (both WEP and AES) doesn't work with fragmentation.
- Fix is_duplicate_packet() bug for fragmentation number setting.
- [bug 667] Fix the notorious "No space for Tx" bug.
- [Bug 637] Set tx power for A band.
- Changed default # of missed beacons to miss before disassociation to 24
- Updated to support ieee80211 callback to is_queue_full for 802.11e
- Fixed some compiler issues if CONFIG_IPW2200_QOS is enabled.
- Added more useful geography encoding so people's experience with
- Workaround kernel BUG_ON panic caused by unexpected duplicate packets.
- Disable host fragmentation in open mode since IPW2200/2915 hardware
- [Bug 792] Fix WPA-PSK AES both for -Dipw and -Dwext.
- Fixes the ad-hoc network WEP key list issue.
- [Bug 701] Fix a misuse of ieee->mode with ieee->iw_mode.
- Fix ipw_wx_get_txpow shows wrong disabled value.
- Fix firmware error when setting tx_power.
- Modified ipw_config and STATUS_INIT setting to correct race condition
- Switched firmware error dumping so that it will capture a log available
- Changed all of the ipw_send_cmd() calls to return any ipw_send_cmd error
- Added cmdlog in non-debug systems.
- Migrated some of the channel verification code back into the driver to
- Updated ipw2200 to use the new ieee80211 callbacks
- Added wait_state wakeup on scan completion.
- [Bug 455] Fix frequent channel change generates firmware fatal error.
- [Bug 760] Fix setting WEP key in monitor mode causes IV lost.
- Don't set hardware WEP if we are actually using TKIP/AES.
- Make all the places the firmware fails to load showerrors (in decimal,
- Adds radiotap support to ipw2200 in monitor mode..
- Fixed is_network_packet() to include checking for broadcast packets.
- Mixed PTK/GTK CCMP/TKIP support.
- Card with WEP enabled and using shared-key auth will have firmware
- Fixed problem with get_cmd_string not existing if CONFIG_IPW_DEBUG disabled.
- Removed PF_SYNCTHREAD legacy.
- Fixes problem with WEP not working (association succeeds, but no Tx/Rx)
- [Fix bug# 771] Too many (8) bytes recieved when using AES/hwcrypto
- Fixes WEP firmware error condition.
- Updated driver version stamps for ipw2100 (1.1.3) and ipw2200 (1.0.7)
- Pulled out a stray KERNEL_VERSION check around the suspend handler.
- Fix 'Driver using old /proc/net/wireless support, please fix driver !' message.
- Removed legacy WIRELESS_EXT checks from ipw2200.c
- Fixes missed beacon logic in relation to on-network AP roaming.
- Removed warning about TKIP not being configured if countermeasures are
- Added channel support for ipw2200 cards identified as 'ZZR'
- Fixed problem with not being able to send broadcast packets.
- Fixed parameter reordering in firmware log routine.
- Updated firmware version stamp to 2.4 from 2.3 so it will use the latest firmware.
- Update version ipw2200 stamp to 1.0.8
- fix NET_RADIO=n, IEEE80211=y compile
- bonding: fix feature consolidation
- kill include/linux/eeprom.h
- drivers/net/s2io.c: make functions static
- prism54 : Unused variable / extraneous udelay
- prism54 : Transmit stats updated in wrong place
- Fix sparse warning in e100 driver.
- atmel: memset correct range
- [IPV6]: Put addr_diff() into common header for future use.
- [IPV6]: Make ipv6_addr_type() more generic so that we can use it for source address selection.
- [IPV6]: RFC3484 compliant source address selection
- [PKT_SCHED]: Correctly handle empty ematch trees
- [NET]: sk_add_backlog convert from macro to inline
- [PPP]: handle misaligned accesses
- [PPP]: add PPP MPPE encryption module
- [IRDA] donauboe: locking fix
- [NET]: kfree cleanup
- [IPV4]: Fix ip_queue_xmit identity increment for TSO packets
- [Bluetooth]: Add endian annotations to the core
- [Bluetooth]: Remove the usage of /proc completely
- [SERIAL] IOC3: Update 8250 driver bits
- skge: clear PCI PHY COMA mode on boot
- skge: use kzalloc
- skge: add mii ioctl support
- skge: goto low power mode on shutdown
- skge: use prefetch on receive
- skge: spelling fixes
- skge: increase version number
- [wireless ipw2100] kill unused-var warnings for debug-disabled code
- ieee80211: cleanup crypto list handling, other minor cleanups.
- b44: replace B44_FLAG_INIT_COMPLETE with netif_running()
- b44: race on device closing
- b44: increase version number
- dgrs: fix warnings when CONFIG_ISA and CONFIG_PCI are not enabled
- IOC: And don't mark the things as broken Cowboy.
- add a vfs_permission helper
- sanitize lookup_hash prototype
- [NETFILTER]: packet counter of conntrack is 32bits
- [NETFILTER]: refcount leak of proto when ctnetlink dumping tuple
- [NETFILTER] nfnetlink: nfattr_parse() can never fail, make it void
- [NETFILTER] ctnetlink: check if protoinfo is present
- [NETFILTER] ctnetlink: add marking support from userspace
- [NETFILTER] ctnetlink: add module alias to fix autoloading
- [NETFILTER] ctnetlink: kill unused includes
- [NETFILTER] ctnetlink: get_conntrack can use GFP_KERNEL
- [NETFILTER] PPTP helper: fix PNS-PAC expectation call id
- [NETFILTER] nfnetlink: only load subsystems if CAP_NET_ADMIN is set
- [NETFILTER]: stop tracking ICMP error at early point
- [NETFILTER] ctnetlink: return -EINVAL if size is wrong
- [NETFILTER] ctnetlink: propagate error instaed of returning -EPERM
- [NETFILTER] ctnetlink: Add support to identify expectations by ID's
- [NETFILTER] ctnetlink: Fix oops when no ICMP ID info in message
- [NETFILTER] ctnetlink: ICMP_ID is u_int16_t not u_int8_t.
- [IPV6]: Fix fallout from CONFIG_IPV6_PRIVACY
- [IPV6]: ip6ip6_lock is not unlocked in error path.
- [NETFILTER]: Add nf_conntrack subsystem.
- [NETLINK]: Type-safe netlink messages/attributes interface
- [NETLINK]: Make netlink_callback->done() optional
- [NETLINK]: Generic netlink receive queue processor
- [XFRM]: Use generic netlink receive queue processor
- [RTNETLINK]: Use generic netlink receive queue processor
- [NETLINK]: Generic netlink family
- SUNRPC: don't reencode when looping in call transmit.
- [netdrvr 8139too] fast poll for thread, if an unlikely race occurs
- [BNX2]: output driver name as prefix in error message
- [BNX2]: check return of dev_alloc_skb in bnx2_test_loopback
- [BNX2]: simplify parameter checks in bnx2_{get,set}_eeprom
- [NET]: Detect hardware rx checksum faults correctly
- [TCP]: fix congestion window update when using TSO deferal
- [TCP]: simplify microsecond rtt sampling
- [TCP]: add tcp_slow_start helper
- [TCP]: Appropriate Byte Count support
- [TCP]: receive buffer growth limiting with mixed MTU
- [TCP]: spelling fixes
- [TCP]: speed up SACK processing
- disable DEBUG in ibmveth
- sky2 needs dma_mapping.h
- gianfar mii needs to zero out the mii_bus structure
- [netdrvr forcedeth] remove superfluous rx engine stop/start
- [netdrvr forcedeth] support for irq mitigation
- [netdrvr forcedeth] phy address scan range
- SAA9730: Whitespace cleanup.
- SAA9730: Driver overhaul
- smc91x: DB1200 support.
- gt96100eth.c: Don't concatenate __FUNCTION__ with strings.
- TCP: fix vegas build
- [DECNET]: fix SIGPIPE
- [IPV6]: Fix inet6_init missing unregister.
- [SCTP]: Fix potential NULL pointer dereference in sctp_v4_get_saddr
- [SCTP]: Remove timeouts[] array from sctp_endpoint.
- [SCTP]: Fix ia64 NaT consumption fault with sctp_sideffect commands.
- [SCTP]: Include ulpevents in socket receive buffer accounting.
-- 
John W. Linville
linville at redhat.com



From ph18 at cornell.edu  Wed Nov 16 14:34:41 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 16 Nov 2005 09:34:41 -0500
Subject: init observations
In-Reply-To: <604aa7910511151426y1b1bfd91l8351e7881ccadc8d@mail.gmail.com>
References: <20051115204405.GA18220@lewk.org>	<028701c5ea29$404130a0$b6491b31@td612671>	<1132090158.13770.7.camel@ignacio.lan>	<20051115213638.GC1003315@hiwaay.net>	<604aa7910511151344pdd8ffdbw3a2032c8da1000c9@mail.gmail.com>	<437A5D1C.3040101@cornell.edu>
	<604aa7910511151426y1b1bfd91l8351e7881ccadc8d@mail.gmail.com>
Message-ID: <437B4381.6010706@cornell.edu>

Jeff Spaleta wrote:

>
>You missed my point entirely.
>Why are we considering all "start up" situations as "full boot" scenarios?
>Why isn't focusing on suspend to disk scenarios a better win?
>
>  
>
    Software suspend seems to work well.  I wouldn't be suprised if it 
has problems at the 1-in-20 level.

    A major reason for rebooting is to put the machine into a clear 
state.  I have some Linux desktops that are trouble-free (reboot for 
kernel upgrades,  power failures) but I've got some that have problems.  
For instance,  I've got one machine that sometimes loses the USB mouse 
after I unplug the USB speakers -- maybe it's a hardware problem or 
maybe a software problem...  It doesn't happen all that often,  but when 
I do,  a reboot fixes it.

    It would be horrible to suspend the machine in a bad state and then 
bring it back up in a bad state.  I suppose that you could work out an 
emacs-like scheme where we boot the machine,  then dump an image of the 
machine that lets us bring the machine back to a clean-boot state.

>I'm not arguing that.. I'm arguing that most day to day startup
>situations do not have to be "full boot" situations they could be
>"recover from suspend" and avoid service startup completely.
>
>  
>
    I won't argue with that.  My guess is that the problems in getting 
that working at the 1-in-1000 level are worse than getting parallel boot 
to work at 1-in-10000.  A next-gen init should be flexible enough that 
it can support software suspend scenarios.

    Another concern I'd have for ordinary users is the UI -- as I've 
said,  I find myself baffled by commercial OSes that make it hard to 
turn off the machine (for instance,  "Log Out" is the easy menu item to 
hit on my Mac,  despite the fact that we've got one account that people 
actually log into and about 15 Unix accounts for various daemons the 
machine runs.)  Would ordinary users understand the difference between 
shutting down,  suspending and such?  I,  for one,  have learned to 
avoid all the "Suspend" and "Hibernate" options on Windows laptops,  
since these often wedge the machine,  forcing me to take the battery 
out...  I think we can do better with software suspend,  but confusion 
and bad UI could make a good feature into a curse.

   



From linux_4ever at yahoo.com  Wed Nov 16 14:45:34 2005
From: linux_4ever at yahoo.com (Steve G)
Date: Wed, 16 Nov 2005 06:45:34 -0800 (PST)
Subject: Dependency problems not reported
In-Reply-To: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
Message-ID: <20051116144535.37615.qmail@web51503.mail.yahoo.com>


>You have to be careful and know how to distinquish errors on your
>system that result when a package is removed from rawhide and is no
>longer recieving development updates.

There are packaging problems not being reported by the automatic rawhide report.
The Obsoletes tag is supposed to take care of this removal or upgrades may not
work correctly. Not sure if there's a way to automatically detect that Obsolete
tags are not covering everything they need to.

>I don't understand why you have this error.
>libXv-0:0.99.1-2.i386  in today's tree provides  libXv.so.1 so
>HelixPlayer package doesn't appear to be missing any deps at the
>moment

I'm using x86_64, not sure if that makes a difference.

>> Error: Missing Dependency: libssl.so.5 is needed by package w3c-libwww
>> Error: Missing Dependency: libcrypto.so.5 is needed by package
>> w3c-libwww
> w3c-libwww removed from the tree

So...what Obsoleted it?

-Steve


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



From bmillett at gmail.com  Wed Nov 16 15:02:24 2005
From: bmillett at gmail.com (Brian Millett)
Date: Wed, 16 Nov 2005 09:02:24 -0600
Subject: rawhide report: 20051116 changes
In-Reply-To: <200511161259.jAGCxPNS004872@porkchop.devel.redhat.com>
References: <200511161259.jAGCxPNS004872@porkchop.devel.redhat.com>
Message-ID: <1132153344.6066.2.camel@localhost.localdomain>

On Wed, 2005-11-16 at 07:59 -0500, Build System wrote:

> emacs-21.4-8
> ------------
> * Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> - 21.4-8
> - update dep for new xorg fonts packages
> 
> * Wed Aug 24 2005 Jens Petersen <petersen at redhat.com>
> - fix name of aspell-es dictionary (#147964)
>   - update emacs-21.3-lisp-textmodes-ispell-languages.patch

After the nice updates today, this is what happens with emacs:

[bpm]$ emacs
emacs: error while loading shared libraries: libXaw3d.so.7: cannot open
shared object file: No such file or directory
[bpm]$ locate libXaw3d
/usr/X11R6/lib/libXaw3d.so.7
/usr/X11R6/lib/libXaw3d.so.7.0
[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7
lrwxrwxrwx 1 root root 15 Mar  4  2005 /usr/X11R6/lib/libXaw3d.so.7 ->
libXaw3d.so.7.0
[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7.0
-rwxr-xr-x 1 root root 296308 Mar  3
2005 /usr/X11R6/lib/libXaw3d.so.7.0

Looks like it is there and readable, so..

Any ideas?
-- 
Brian Millett - [ Lennier (re: hiding Deathwalker), "Deathwalker"]
"Like all secrets long kept, we cannot bear the shame of admitting it
now."




From sundaram at redhat.com  Wed Nov 16 15:05:35 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 16 Nov 2005 20:35:35 +0530
Subject: rawhide report: 20051116 changes
In-Reply-To: <1132153344.6066.2.camel@localhost.localdomain>
References: <200511161259.jAGCxPNS004872@porkchop.devel.redhat.com>
	<1132153344.6066.2.camel@localhost.localdomain>
Message-ID: <437B4ABF.60901@redhat.com>

Hi

>After the nice updates today, this is what happens with emacs:
>
>[bpm]$ emacs
>emacs: error while loading shared libraries: libXaw3d.so.7: cannot open
>shared object file: No such file or directory
>[bpm]$ locate libXaw3d
>/usr/X11R6/lib/libXaw3d.so.7
>/usr/X11R6/lib/libXaw3d.so.7.0
>[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7
>lrwxrwxrwx 1 root root 15 Mar  4  2005 /usr/X11R6/lib/libXaw3d.so.7 ->
>libXaw3d.so.7.0
>[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7.0
>-rwxr-xr-x 1 root root 296308 Mar  3
>2005 /usr/X11R6/lib/libXaw3d.so.7.0
>
>Looks like it is there and readable, so..
>  
>
As usual, file bug reports of course.

regards
Rahul



From dimi at lattica.com  Wed Nov 16 15:07:55 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 10:07:55 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org><028701c5ea29$404130a0$b6491b31@td612671>
	<88E7ED75E2E9618B698764FA@[10.0.0.14]>
Message-ID: <039c01c5eabf$8686c700$b6491b31@td612671>

From: "Kenneth Porter" <shiva at sewingwitch.com>
> It's funny how the discussion gets lost in a focus on speed, and the other
> benefits that are more important to servers seem to get ignored (at least
> for discussion).

I don't understand why people think these topics are mutually exclusive.
There are clearly a number of different aspects when we discuss about
init replacement, all important to some group of people:
  * dynamic dependencies
  * hot plugging
  * D-BUS integration
  * speed
  * parallel startup
  * graphical boot
  * proper API
  * service monitoring
  * automatic respawning of services
  * on-demand startup of services
  * backwards compatibility

They are all important, and each should be addressed. But we can not
do it all at once. If you want to discuss about a different aspect,
we should start a different thread.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From bmillett at gmail.com  Wed Nov 16 15:16:24 2005
From: bmillett at gmail.com (Brian Millett)
Date: Wed, 16 Nov 2005 09:16:24 -0600
Subject: rawhide report: 20051116 changes
In-Reply-To: <437B4ABF.60901@redhat.com>
References: <200511161259.jAGCxPNS004872@porkchop.devel.redhat.com>
	<1132153344.6066.2.camel@localhost.localdomain>
	<437B4ABF.60901@redhat.com>
Message-ID: <1132154185.6066.4.camel@localhost.localdomain>

On Wed, 2005-11-16 at 20:35 +0530, Rahul Sundaram wrote:
> Hi
> 
> >After the nice updates today, this is what happens with emacs:
> >
> >[bpm]$ emacs
> >emacs: error while loading shared libraries: libXaw3d.so.7: cannot open
> >shared object file: No such file or directory
> >[bpm]$ locate libXaw3d
> >/usr/X11R6/lib/libXaw3d.so.7
> >/usr/X11R6/lib/libXaw3d.so.7.0
> >[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7
> >lrwxrwxrwx 1 root root 15 Mar  4  2005 /usr/X11R6/lib/libXaw3d.so.7 ->
> >libXaw3d.so.7.0
> >[bpm]$ ls -l /usr/X11R6/lib/libXaw3d.so.7.0
> >-rwxr-xr-x 1 root root 296308 Mar  3
> >2005 /usr/X11R6/lib/libXaw3d.so.7.0
> >
> >Looks like it is there and readable, so..
> >  
> >
> As usual, file bug reports of course.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173348

-- 
Brian Millett - [ Businessman and Lyta Alexander, "The Gathering"]
"Someday I'm going to find the guy that thought up the idea of renting
telepaths to businessman and I'm going to kill him."
'Funny, I just knew you were going to say that.'




From selinux at gmail.com  Wed Nov 16 15:21:09 2005
From: selinux at gmail.com (Tom London)
Date: Wed, 16 Nov 2005 07:21:09 -0800
Subject: new hal?
Message-ID: <4c4ba1530511160721x15de22e0td8ed756deeba2064@mail.gmail.com>

Any chance for a refresh of hal?

Current package (hal-0.5.4.cvs20051111-1) has a FPE/zero-divide
problem that kills it within a few minutes of boot or restart.  Makes
testing of USB plugging/unplugging difficult ;)

[Believe it has something to do with very rapid battery notifications
on my dumb (but current) laptop.]

Believe its fixed upstream.  Bugzilla'ed here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173233

Thanks,
   tom
--
Tom London



From laroche at redhat.com  Wed Nov 16 15:27:44 2005
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 16 Nov 2005 16:27:44 +0100
Subject: Dependency problems not reported
In-Reply-To: <20051116144535.37615.qmail@web51503.mail.yahoo.com>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
Message-ID: <20051116152744.GA19105@dudweiler.stuttgart.redhat.com>

> There are packaging problems not being reported by the automatic rawhide report.
> The Obsoletes tag is supposed to take care of this removal or upgrades may not
> work correctly. Not sure if there's a way to automatically detect that Obsolete
> tags are not covering everything they need to.

pyrpm can list those "left-over rpms" if you compare to previous
releases/trees.

regards,

Florian La Roche



From cmadams at hiwaay.net  Wed Nov 16 15:36:31 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 16 Nov 2005 09:36:31 -0600
Subject: init observations
In-Reply-To: <031901c5ea36$d6d8c070$b6491b31@td612671>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
Message-ID: <20051116153631.GA1497776@hiwaay.net>

Once upon a time, Dimi Paun <dimi at lattica.com> said:
> I'm talking about modprobe. I agree, not a bit problem
> (~2.5s), but I was wondering if we can start X before it.

X yes.  GNOME, probably not.  GNOME likes to see the network and many of
the applets only check for things on start-up (like sensors, sound,
etc.).  For example, system sensors are not hot-swap on any system that
I'm aware of, so the applets are not typically written to handle that.

-- 
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 sundaram at redhat.com  Wed Nov 16 15:40:05 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Wed, 16 Nov 2005 21:10:05 +0530
Subject: init observations
In-Reply-To: <20051116153631.GA1497776@hiwaay.net>
References: <20051115211419.GB13874@devserv.devel.redhat.com>	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116153631.GA1497776@hiwaay.net>
Message-ID: <437B52D5.5060905@redhat.com>

Chris Adams wrote:

>Once upon a time, Dimi Paun <dimi at lattica.com> said:
>  
>
>>I'm talking about modprobe. I agree, not a bit problem
>>(~2.5s), but I was wondering if we can start X before it.
>>    
>>
>
>X yes.  GNOME, probably not.  GNOME likes to see the network and many of
>the applets only check for things on start-up (like sensors, sound,
>etc.).  For example, system sensors are not hot-swap on any system that
>I'm aware of, so the applets are not typically written to handle that.
>
>  
>
Those are probably bugs/RFE's to report then. GNOME should work in a 
non-networked system without any complaints whatsoever.

regards
Rahul



From jspaleta at gmail.com  Wed Nov 16 15:41:02 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 10:41:02 -0500
Subject: Dependency problems not reported
In-Reply-To: <20051116144535.37615.qmail@web51503.mail.yahoo.com>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
Message-ID: <604aa7910511160741g5dac9bd0ya1ca13b6fbfa612a@mail.gmail.com>

On 11/16/05, Steve G <linux_4ever at yahoo.com> wrote:
> There are packaging problems not being reported by the automatic rawhide report.
> The Obsoletes tag is supposed to take care of this removal or upgrades may not
> work correctly. Not sure if there's a way to automatically detect that Obsolete
> tags are not covering everything they need to.

The rawhide report doesn't make any attempt to look at Obsoletes. The
rawhide reporting script checks for self-consistency and makes an
effort to record removed packages, new packages and updated packages
incrementally between runs.  But you can not rely on this report to be
an exhaustive list of removals or additions..simply because the report
itself might not be generated every day.

Once a package is removed from rawhide.. if it remains on client
systems it WILL cause dependance resolution problems on the client at
some point in the future that cannot be seen by any reporting tool
that looks solely at the self-consistency of the rawhide tree. 
Testers should be aware of that eventuality and be able to check to
see if the package is still in the tree.  The question as to whether
or not the package was suppose to be obsoleted by something else is
impossible to answer without talking to the package maintainer. Some
packages are meant to be dropped and not obsoleted by anything.

> I'm using x86_64, not sure if that makes a difference.
shrug... HelixPlayer is not in the 64bit tree.. and it is
self-consitently packaged in the 32bit tree. Perhaps you have a client
side configuration problem and don't have the 32bit tree enabled to
retrive the 32bit version of the new libXp package to fill the 32 bit
dep. If thats the case.. its a client configuration error and not a
packaging one.

>
> >> Error: Missing Dependency: libssl.so.5 is needed by package w3c-libwww
> >> Error: Missing Dependency: libcrypto.so.5 is needed by package
> >> w3c-libwww
> > w3c-libwww removed from the tree
>
> So...what Obsoleted it?

Who said it was obsoleted or was suppose to be obsoleted?   Packages
can be flat out dropped. This one was dropped in June according to the
rawhide reports....packages don't have to be obsoleted to leave
rawhide.   w3c-libwww-* is yet another example of items that have left
Core and may or may not be re-published in Extras based on community
interest to maintain it.  I don't think there is any sane way to
automate scripted checks to look for "out of tree" dependancy issues
that take 4 months to show up on rawhide boxes because of removed
packages.

-jef



From jspaleta at gmail.com  Wed Nov 16 15:46:18 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 10:46:18 -0500
Subject: init observations
In-Reply-To: <437B52D5.5060905@redhat.com>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116153631.GA1497776@hiwaay.net> <437B52D5.5060905@redhat.com>
Message-ID: <604aa7910511160746n36e90a68g45cf97e388a00cbd@mail.gmail.com>

On 11/16/05, Rahul Sundaram <sundaram at redhat.com> wrote:
> Those are probably bugs/RFE's to report then. GNOME should work in a
> non-networked system without any complaints whatsoever.

non-networked... meaning no local loopback?  The network service
doesn't just handle external route  it starts up 127.0.0.1 as well.
I'm not sure requiring 127.0.0.1 to be available is unreasonable

-jef



From jspaleta at gmail.com  Wed Nov 16 15:50:00 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 10:50:00 -0500
Subject: Dependency problems not reported
In-Reply-To: <20051116152744.GA19105@dudweiler.stuttgart.redhat.com>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
	<20051116152744.GA19105@dudweiler.stuttgart.redhat.com>
Message-ID: <604aa7910511160750i267ac021w44385b94b0da3231@mail.gmail.com>

On 11/16/05, Florian La Roche <laroche at redhat.com> wrote:
> > There are packaging problems not being reported by the automatic rawhide report.
> > The Obsoletes tag is supposed to take care of this removal or upgrades may not
> > work correctly. Not sure if there's a way to automatically detect that Obsolete
> > tags are not covering everything they need to.
>
> pyrpm can list those "left-over rpms" if you compare to previous
> releases/trees.

Does it just confirm that the package is no longer available? I don't
see how you can script a tool that answers the question "Should have
this been obsoleted"  Not everything that drops out of rawhide gets
obsoleted by something.. it can just disappear...without there being a
packaging problem that needs to be addressed.

-jef



From dimi at lattica.com  Wed Nov 16 15:57:51 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 10:57:51 -0500
Subject: init observations
References: <20051115211419.GB13874@devserv.devel.redhat.com><031901c5ea36$d6d8c070$b6491b31@td612671><20051116153631.GA1497776@hiwaay.net>
	<437B52D5.5060905@redhat.com>
	<604aa7910511160746n36e90a68g45cf97e388a00cbd@mail.gmail.com>
Message-ID: <03fa01c5eac6$805fe6c0$b6491b31@td612671>

From: "Jeff Spaleta" <jspaleta at gmail.com>
> non-networked... meaning no local loopback?  The network service
> doesn't just handle external route  it starts up 127.0.0.1 as well.
> I'm not sure requiring 127.0.0.1 to be available is unreasonable

It would be nice to not depend on localhost, but I agree, it's reasonable
to assume its there. In any case, bringing localhost up should be
a lot faster then up the others, no?

BTW, it would be an interesting experiment to see what happens if
127.0.0.1 is not up. There will be a time when it's needed, I agree.
At which point we would need a clean way of waiting on networking
to be brought up. Hopefully this is after the user enters their
username and password.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From katzj at redhat.com  Wed Nov 16 16:01:33 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 16 Nov 2005 11:01:33 -0500
Subject: Dependency problems not reported
In-Reply-To: <604aa7910511160741g5dac9bd0ya1ca13b6fbfa612a@mail.gmail.com>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
	<604aa7910511160741g5dac9bd0ya1ca13b6fbfa612a@mail.gmail.com>
Message-ID: <1132156894.21127.26.camel@bree.local.net>

On Wed, 2005-11-16 at 10:41 -0500, Jeff Spaleta wrote:
> On 11/16/05, Steve G <linux_4ever at yahoo.com> wrote:
> > I'm using x86_64, not sure if that makes a difference.
> shrug... HelixPlayer is not in the 64bit tree.. and it is
> self-consitently packaged in the 32bit tree. Perhaps you have a client
> side configuration problem and don't have the 32bit tree enabled to
> retrive the 32bit version of the new libXp package to fill the 32 bit
> dep. If thats the case.. its a client configuration error and not a
> packaging one.

While somewhat true in general, in specific, I need to make sure all of
the new modular X libs are in the list of "multilib libs" properly.
Todo++ for today

Jeremy



From jspaleta at gmail.com  Wed Nov 16 16:03:37 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 11:03:37 -0500
Subject: init observations
In-Reply-To: <03fa01c5eac6$805fe6c0$b6491b31@td612671>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116153631.GA1497776@hiwaay.net> <437B52D5.5060905@redhat.com>
	<604aa7910511160746n36e90a68g45cf97e388a00cbd@mail.gmail.com>
	<03fa01c5eac6$805fe6c0$b6491b31@td612671>
Message-ID: <604aa7910511160803o26285174oe9c1c13238234f57@mail.gmail.com>

On 11/16/05, Dimi Paun <dimi at lattica.com> wrote:
> It would be nice to not depend on localhost, but I agree, it's reasonable
> to assume its there. In any case, bringing localhost up should be
> a lot faster then up the others, no?

You are talking to the wrong person.. I don't think its worth the
extras complexity of seperating out the network startup into  lo and
other. I'm sure its technically possible to seperate out lo startup
into its own service.


-jef



From jspaleta at gmail.com  Wed Nov 16 16:08:22 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 11:08:22 -0500
Subject: Dependency problems not reported
In-Reply-To: <1132156894.21127.26.camel@bree.local.net>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
	<604aa7910511160741g5dac9bd0ya1ca13b6fbfa612a@mail.gmail.com>
	<1132156894.21127.26.camel@bree.local.net>
Message-ID: <604aa7910511160808k622c029cm93a45beee339fc04@mail.gmail.com>

On 11/16/05, Jeremy Katz <katzj at redhat.com> wrote:
> While somewhat true in general, in specific, I need to make sure all of
> the new modular X libs are in the list of "multilib libs" properly.
> Todo++ for today

Is there a way to script a check for such.. cross contamination..
problems in the rawhide reports?  To reduce the amount of legwork the
3 people running 64bit fedora have to do to determine if there is a
multilib problem?

-jef



From pekkas at netcore.fi  Wed Nov 16 16:33:28 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Wed, 16 Nov 2005 18:33:28 +0200 (EET)
Subject: fedora-netdev.1 IPv6 freeze [Re: [ANNOUNCE] fedora-netdev kernel
 repository]
In-Reply-To: <20051116142518.GE8356@redhat.com>
References: <20051114205110.GK25755@redhat.com>
	<Pine.LNX.4.64.0511161242260.26498@netcore.fi>
	<20051116114224.GB20395@postel.suug.ch>
	<20051116142518.GE8356@redhat.com>
Message-ID: <Pine.LNX.4.64.0511161832480.1703@netcore.fi>

On Wed, 16 Nov 2005, John W. Linville wrote:
> On Wed, Nov 16, 2005 at 12:42:24PM +0100, Thomas Graf wrote:
>> * Pekka Savola <pekkas at netcore.fi> 2005-11-16 12:46
>>> On Mon, 14 Nov 2005, John W. Linville wrote:
>>>> 	http://people.redhat.com/linville/kernels/fedora-netdev/
>>>
>>> I guess the test can be termed a 'success' because after updating from
>>> 2.6.14-1.1637_FC4 to 2.6.14-1.1637_FC4.netdev.1, I get 100%
>>> reproducible kernel hang (everything just freezes as it is, no message
>>> to /var/log/messages or anywhere) after I run '/sbin/ip -6 r l' or try
>>> to use IPv6 in basically any other way on my ThinkPad laptop with
>>> external orinoco_cs WLAN card.
>>>
>>> Any thoughts for the next steps?
>>
>> It's probably missing this patch:
>
> It was...
>
> Pekka, I have included the patch Thomas identified as part of the
> FC4.netdev.2 build.  You may want to do a 'yum update' and try it out.

Indeed, that fixed at least the 'ip -6 r l' problem.  I'll try whether 
there are any remaining issues with the wireless and v6 when I get 
back to the office.
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From toshio at tiki-lounge.com  Wed Nov 16 16:35:07 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Wed, 16 Nov 2005 08:35:07 -0800
Subject: How to simplify the process of adding
	multilingual	%descriptions to rpm spec?
In-Reply-To: <437A1C89.4000605@volny.cz>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>
	<Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>
	<1132070434.10457.54.camel@localhost>  <437A1C89.4000605@volny.cz>
Message-ID: <1132158907.2965.5.camel@localhost>

On Tue, 2005-11-15 at 18:36 +0100, Miloslav Trmac wrote:
> Toshio Kuratomi wrote:
> > Translator Goals:
> > 1) Notification of package string changes.
> > 2) Ability to own a package-translation similar to how other packagers
> > own a package.
> As a translator, I don't think this is what I want.
> 1) We already have infrastructure to show translation status, without
>    explicit notification.  Explicit notification would just result in
>    a lot of daily emails.
> All that is necessary is regular (daily/weekly) rebuild of the list of
> strings to translate, and a regular incorrporation of translated
> messages to the repository (in whatever form).
> 
Amendment to #1:
1) Listing of package string changes (As translators often work on a
large number of packages, email notification is going to overwhelm
INBOXes.)


> 2) No, I certainly don't want to handle 1237 separate "translation
>    packages" in 1237 separate files.you don't want me
> The specspo model of a single file actually suits translators quite well
> (e.g. it allows automated translation matching on package renames).
> Maybe we could split the large .po file to allow better collaboration,
> e.g. to 26 .po files, selecting packages by the first letter of their name.

#2 doesn't specify the backend.  #2 specifies that if you are
translating package foo for language hungarian, then you don't want me
to come in and retranslate it.  Do you disagree with this?

But we can add:
3) Ability to edit translations in a single file/location that can be
parsed (if necessary) by the builder into a final form.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051116/6f13386a/attachment.sig>

From ph18 at cornell.edu  Wed Nov 16 16:42:17 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 16 Nov 2005 11:42:17 -0500
Subject: init observations
In-Reply-To: <88E7ED75E2E9618B698764FA@[10.0.0.14]>
References: <20051115204405.GA18220@lewk.org>	<028701c5ea29$404130a0$b6491b31@td612671>
	<88E7ED75E2E9618B698764FA@[10.0.0.14]>
Message-ID: <437B6169.7000508@cornell.edu>

Kenneth Porter wrote:

>
> It's funny how the discussion gets lost in a focus on speed, and the 
> other benefits that are more important to servers seem to get ignored 
> (at least for discussion).
>
> To me the big wins are explicit expression of dependencies instead of 
> numbered start/stop order, and better integration with hot-plugging.
>
> The speed is nice, but to me it's the ability of the system to 
> describe the desired relationships clearly that makes the admin's life 
> more bearable.
>
    I'd like to see a system that's smart about dependencies,  but I've 
got some fear that the cure could be worse than the disease.  I'd want 
the ability to break the rules if I want to.

    Another problem is that dependencies aren't always so clear:  does 
Apache depend upon Tomcat or does Tomcat depend on Apache?

* Apache can't handle .jsp files w/o Tomcat,  but
* A Java application runs just fine in Tomcat,  except that you need 
Apache for the outside world to see it.

    Tomcat gets wedged often,  and needs a kick.  I don't need to 
restart the web server in this case.  I often kick Apache because I 
changed the configuration files...  I don't need to trash the 
application state in Tomcat when I do this.  Although I want these 
services to start together,  things would go smoother if I could kick 
them independently.

    On the other hand,  if you're using Oracle from PHP,  you'll lose 
your connection to the Listener if you kick Oracle and don't kick Apache.

    I'm not completely happy with dependencies being represented in the 
'init file' (or generalization thereof) because a dependency is a 
function of two software systems,  not a product of one.  For instance,  
imagine that I'm running the Apache that comes with Fedora/RH,  and I'm 
using it in a 'web services' or 'application server' mode where it 
depends on some other daemons such as Tomcat,  mcached,  etc that I've 
installed myself.  Well,  if I hacked the init script for Apache to add 
the new dependencies,  that may cause problems for rpm management.

    (I've got this problem with the .desktop file system for creating 
the Gnome menu -- I might want to attach my own categories such as 
"Favorite" or "Available in Kiosk Mode",  but hacking 100 .desktop files 
would be a disaster)

    It might be easy to create 'virtual' services that are a bundle of 
other services,  and this might even be a replacement for numbered 
runlevels...  A 'desktop' service,  for instance,  brings up X Windows,  
Xft,  input method daemons and all that.

----

    I think it's good that we're having a free-wheeling discussion of 
all aspects of a new init system because it's important that it has a 
design that embraces all of the things we're going to want to do with 
it.  A new init system ought to facilitate fast boot and it ought to be 
flexible enough to support software suspend -- if we pick bad data 
structures,  we'll have a system that we'll be cursing for years to come.

    I'm particularly concerned about customizability.  Different shops 
have different ideas about the 'right' way to manage systems,  and there 
are many questions that have no conclusive answer.  It's one thing for 
Gnome to be tough to customize (if I hate the panel,  I can install a 
different panel) but I'd hate to have to do surgery on initd for every 
FC5 or RHEL 5 box I maintain.

   






From johnp at redhat.com  Wed Nov 16 16:50:53 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Wed, 16 Nov 2005 11:50:53 -0500
Subject: new hal?
In-Reply-To: <4c4ba1530511160721x15de22e0td8ed756deeba2064@mail.gmail.com>
References: <4c4ba1530511160721x15de22e0td8ed756deeba2064@mail.gmail.com>
Message-ID: <1132159853.8333.97.camel@remedyz.boston.redhat.com>

Yep, I'm getting around to it.  At the latest tomorrow as I am chock
full of things I need to get done for tomorrow.  If I find some downtime
I might be able to get it in today.

On Wed, 2005-11-16 at 07:21 -0800, Tom London wrote:
> Any chance for a refresh of hal?
> 
> Current package (hal-0.5.4.cvs20051111-1) has a FPE/zero-divide
> problem that kills it within a few minutes of boot or restart.  Makes
> testing of USB plugging/unplugging difficult ;)
> 
> [Believe it has something to do with very rapid battery notifications
> on my dumb (but current) laptop.]
> 
> Believe its fixed upstream.  Bugzilla'ed here:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173233
> 
> Thanks,
>    tom
> --
> Tom London

-- 
John (J5) Palmieri <johnp at redhat.com>



From mitr at volny.cz  Wed Nov 16 16:57:23 2005
From: mitr at volny.cz (Miloslav Trmac)
Date: Wed, 16 Nov 2005 17:57:23 +0100
Subject: How to simplify the process of adding	multilingual	%descriptions
 to rpm spec?
In-Reply-To: <1132158907.2965.5.camel@localhost>
References: <76e72f800511071722h7841b6e2t@mail.gmail.com>	<Pine.LNX.4.58.0511072025000.22486@devserv.devel.redhat.com>	<1132070434.10457.54.camel@localhost>
	<437A1C89.4000605@volny.cz> <1132158907.2965.5.camel@localhost>
Message-ID: <437B64F3.2040106@volny.cz>

Toshio Kuratomi wrote:
> On Tue, 2005-11-15 at 18:36 +0100, Miloslav Trmac wrote:
> 
>>Toshio Kuratomi wrote:
>>
>>>Translator Goals:
>>>1) Notification of package string changes.
>>>2) Ability to own a package-translation similar to how other packagers
>>>own a package.
>>

>>2) No, I certainly don't want to handle 1237 separate "translation
>>   packages" in 1237 separate files.you don't want me
>>The specspo model of a single file actually suits translators quite well
>>(e.g. it allows automated translation matching on package renames).
>>Maybe we could split the large .po file to allow better collaboration,
>>e.g. to 26 .po files, selecting packages by the first letter of their name.
> 
> #2 doesn't specify the backend.  #2 specifies that if you are
> translating package foo for language hungarian, then you don't want me
> to come in and retranslate it.  Do you disagree with this?
The general idea of "owning" the translation is correct, but separating
work per-package is really too much overhead.  "Owning" a block of
packages (on the order of 100 packages, or even more) would be OK.
	Mirek



From dimi at lattica.com  Wed Nov 16 17:04:50 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 12:04:50 -0500
Subject: init: API
Message-ID: <043301c5eacf$dbba0ba0$b6491b31@td612671>

Folks,

Since we are discussing a new init replacement, I think
we should consider a good API for it too, so that it services
can be controlled programmatically. At the very least, we
need to be able to:
  * start/stop/reload/restart a service
  * query its status
  * wait for a service to start/stop
  * a way for services to interact with the administrators
    (for example to ask for passphrases, etc.)
  * a way to signal problems (probably D-BUS bases)

I know this is blasphemy, but how about we start (at least
for inspiration) with the Services API from Win32:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_functions.asp

For more info about Win32 services:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/services.asp

At the very least looking at other APIs will tell us:
  * what we need to cover
  * what we should avoid

What other APIs are out there? Does Sun have one?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From notting at redhat.com  Wed Nov 16 17:17:12 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 16 Nov 2005 12:17:12 -0500
Subject: init observations
In-Reply-To: <031901c5ea36$d6d8c070$b6491b31@td612671>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
Message-ID: <20051116171711.GI4989@devserv.devel.redhat.com>

Dimi Paun (dimi at lattica.com) said: 
> I'm talking about modprobe. I agree, not a bit problem
> (~2.5s), but I was wondering if we can start X before it.
> I mean, things should work out correctly in face of
> hotplug events anyhow, so why don't we delay modprobing
> until after we start X, and treat them as hotplug events?

a) because X is dumb, and doesn't handle hotplug devices
b) becuase it really shouldn't take *that* long

Bill



From dimi at lattica.com  Wed Nov 16 17:28:05 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 12:28:05 -0500
Subject: init observations
References: <20051115211419.GB13874@devserv.devel.redhat.com><031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116171711.GI4989@devserv.devel.redhat.com>
Message-ID: <045a01c5ead3$1b041aa0$b6491b31@td612671>

From: "Bill Nottingham" <notting at redhat.com>
> a) because X is dumb, and doesn't handle hotplug devices

You mean mouse & keyboard? I'd consider it a bug, really.
I think X should handle it if I change the keyboard and
or the mouse.

> b) becuase it really shouldn't take *that* long

True, 3s is not *that* long, just wanted to see what
it would take to get rid of it. Problem is that nothing
is *that* long (most things take less then 3 sec), but
they do add up. And 40s is too much.

This is offtopic, but I think in general we have a problem
with startup times. For example, starting gedit (which is
marketed as a fast and simple text editor) on my fairly
decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
should be instantaneous (<300ms). I think we're about 100
slower then we should be. And this is in an area that people
care about startup times more than for boot. I wouldn't
be surprised to have similar inefficiencies during init.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From notting at redhat.com  Wed Nov 16 17:30:33 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 16 Nov 2005 12:30:33 -0500
Subject: init observations
In-Reply-To: <045a01c5ead3$1b041aa0$b6491b31@td612671>
References: <20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
Message-ID: <20051116173033.GA26662@devserv.devel.redhat.com>

Dimi Paun (dimi at lattica.com) said: 
> This is offtopic, but I think in general we have a problem
> with startup times. For example, starting gedit (which is
> marketed as a fast and simple text editor) on my fairly
> decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
> should be instantaneous (<300ms). I think we're about 100
> slower then we should be. And this is in an area that people
> care about startup times more than for boot. I wouldn't
> be surprised to have similar inefficiencies during init.

Disk seek.

Bill



From laroche at redhat.com  Wed Nov 16 17:34:10 2005
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 16 Nov 2005 18:34:10 +0100
Subject: Dependency problems not reported
In-Reply-To: <604aa7910511160750i267ac021w44385b94b0da3231@mail.gmail.com>
References: <604aa7910511160625ka4f2e8bnbd3f57f27fc5a2f7@mail.gmail.com>
	<20051116144535.37615.qmail@web51503.mail.yahoo.com>
	<20051116152744.GA19105@dudweiler.stuttgart.redhat.com>
	<604aa7910511160750i267ac021w44385b94b0da3231@mail.gmail.com>
Message-ID: <20051116173410.GA19568@dudweiler.stuttgart.redhat.com>

On Wed, Nov 16, 2005 at 10:50:00AM -0500, Jeff Spaleta wrote:
> On 11/16/05, Florian La Roche <laroche at redhat.com> wrote:
> > > There are packaging problems not being reported by the automatic rawhide report.
> > > The Obsoletes tag is supposed to take care of this removal or upgrades may not
> > > work correctly. Not sure if there's a way to automatically detect that Obsolete
> > > tags are not covering everything they need to.
> >
> > pyrpm can list those "left-over rpms" if you compare to previous
> > releases/trees.
> 
> Does it just confirm that the package is no longer available? I don't
> see how you can script a tool that answers the question "Should have
> this been obsoleted"  Not everything that drops out of rawhide gets
> obsoleted by something.. it can just disappear...without there being a
> packaging problem that needs to be addressed.

Steve is right that obsoletes handling is the only missing thing.
You list the packages that have been dropped and not obsoleted. You
then have to rethink those if they are correct or an additional
Obsoletes: would make sense.

regards,

Florian La Roche



From jspaleta at gmail.com  Wed Nov 16 17:50:19 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 12:50:19 -0500
Subject: init observations
In-Reply-To: <045a01c5ead3$1b041aa0$b6491b31@td612671>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
Message-ID: <604aa7910511160950v17c22dfex32a9c2bc7a6b8c5c@mail.gmail.com>

On 11/16/05, Dimi Paun <dimi at lattica.com> wrote:
> This is offtopic, but I think in general we have a problem
> with startup times. For example, starting gedit (which is
> marketed as a fast and simple text editor) on my fairly
> decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
> should be instantaneous (<300ms). I think we're about 100
> slower then we should be.

How do you time this?

According to my wristwatch with second hand resolution, getting a
gedit window on my 1 GHz athlon with 512Meg ram... takes under a
second from the moment I click on the gedit menu item on the
accessories menu on this fc4 system... right after a fresh reboot and
login to my gnome session.  I really don't think ancedotal
conversations about application window appearence time are worthwhile.

-jef



From smooge at gmail.com  Wed Nov 16 17:56:20 2005
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Wed, 16 Nov 2005 10:56:20 -0700
Subject: init observations
In-Reply-To: <20051116173033.GA26662@devserv.devel.redhat.com>
References: <20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
	<20051116173033.GA26662@devserv.devel.redhat.com>
Message-ID: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>

On 11/16/05, Bill Nottingham <notting at redhat.com> wrote:
> Dimi Paun (dimi at lattica.com) said:
> > This is offtopic, but I think in general we have a problem
> > with startup times. For example, starting gedit (which is
> > marketed as a fast and simple text editor) on my fairly
> > decent 3GHz CPU/1GB RAM box takes a *few* seconds. This
> > should be instantaneous (<300ms). I think we're about 100
> > slower then we should be. And this is in an area that people
> > care about startup times more than for boot. I wouldn't
> > be surprised to have similar inefficiencies during init.
>
> Disk seek.

To elaborate.. there are factors beyond your CPU/memory. What kind of
diskdrive do you have? What is its transfer rates? What are it
hit/miss rates? How is the layout of the disk optimized for disk-seek?

A lot of commodity disk-drives are sub-par on these areas. This means
that programs will slow down because you are spending a lot of time
waiting for the disk-drive to give you bits because it keeps plugging
up its cache or not able to get various items off disk as fast as
advertised.

--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From dmalcolm at redhat.com  Wed Nov 16 18:03:07 2005
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 16 Nov 2005 13:03:07 -0500
Subject: init: API
In-Reply-To: <043301c5eacf$dbba0ba0$b6491b31@td612671>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
Message-ID: <1132164187.26095.48.camel@cassandra.boston.redhat.com>

On Wed, 2005-11-16 at 12:04 -0500, Dimi Paun wrote:

[snip]

>   * a way for services to interact with the administrators
>     (for example to ask for passphrases, etc.)

Youch!  :-)  Writing it that way makes me think of some nightmare world
where the httpd service is restarting _me_

I guess one viewpoint on all of this is to think of the various users of
Fedora (enthusiast at home, manager of a small to medium-sized network
etc) and think about the sorts of interaction they ought to be having
with this layer: what should their experience be like?  What kind of
user input do the services need?  I'm coming at this from a "make
everything just work" perspective.  Maybe the split here is:
- services that make this computer work (which a non-technical end-user
hopefully never has to think of, but if they do e.g. when
troubleshooting they can think of it as part of the central nervous
system); examples might be the Avahi daemon, the nightly yum update,
etc.  With my end-user hat on, I never want to have to care about any of
this stuff.
- services that are useful to the rest of the network and/or the
internet (which a non-technical end-user might think of as a "service");
an example might be httpd.

[snip]

Hope that's helpful




From pemboa at gmail.com  Wed Nov 16 18:22:00 2005
From: pemboa at gmail.com (Arthur Pemberton)
Date: Wed, 16 Nov 2005 12:22:00 -0600
Subject: init: API
In-Reply-To: <043301c5eacf$dbba0ba0$b6491b31@td612671>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
Message-ID: <16de708d0511161022r6c40377ep44c60a3d99af310e@mail.gmail.com>

Just to add to the pool of ideas, here are some discussions on the topic:
http://ask.slashdot.org/article.pl?sid=04/02/05/2331259&tid=156&tid=130&tid=4
http://developers.slashdot.org/article.pl?sid=03/10/02/1553253&tid=8&tid=106


On 11/16/05, Dimi Paun <dimi at lattica.com> wrote:
>
> Folks,
>
> Since we are discussing a new init replacement, I think
> we should consider a good API for it too, so that it services
> can be controlled programmatically. At the very least, we
> need to be able to:
> * start/stop/reload/restart a service
> * query its status
> * wait for a service to start/stop
> * a way for services to interact with the administrators
> (for example to ask for passphrases, etc.)
> * a way to signal problems (probably D-BUS bases)
>
> I know this is blasphemy, but how about we start (at least
> for inspiration) with the Services API from Win32:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_functions.asp
>
> For more info about Win32 services:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/services.asp
>
> At the very least looking at other APIs will tell us:
> * what we need to cover
> * what we should avoid
>
> What other APIs are out there? Does Sun have one?
>
> --
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051116/a60d911b/attachment.htm>

From jspaleta at gmail.com  Wed Nov 16 18:22:02 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 13:22:02 -0500
Subject: init observations
In-Reply-To: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
References: <20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
	<20051116173033.GA26662@devserv.devel.redhat.com>
	<80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
Message-ID: <604aa7910511161022m7e179d57h68e71a341c7e263b@mail.gmail.com>

On 11/16/05, Stephen J. Smoogen <smooge at gmail.com> wrote:
> A lot of commodity disk-drives are sub-par on these areas. This means
> that programs will slow down because you are spending a lot of time
> waiting for the disk-drive to give you bits because it keeps plugging
> up its cache or not able to get various items off disk as fast as
> advertised.

Is there some reasonably valid understanding of how big an impact this
makes in the average and worst case? Sort of a measure of the spread
of disk-drive performance out in the wild.
Say for example...a typical christmas special home desktop from
Dell... does the disk-seek performance on a system like that make an
order of magnitude faster bootup or application startup times a
pipedream?

-jef



From smooge at gmail.com  Wed Nov 16 18:32:33 2005
From: smooge at gmail.com (Stephen J. Smoogen)
Date: Wed, 16 Nov 2005 11:32:33 -0700
Subject: init observations
In-Reply-To: <604aa7910511161022m7e179d57h68e71a341c7e263b@mail.gmail.com>
References: <20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
	<20051116173033.GA26662@devserv.devel.redhat.com>
	<80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<604aa7910511161022m7e179d57h68e71a341c7e263b@mail.gmail.com>
Message-ID: <80d7e4090511161032m3c7791f0lbbcc1b0a2056da57@mail.gmail.com>

On 11/16/05, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 11/16/05, Stephen J. Smoogen <smooge at gmail.com> wrote:
> > A lot of commodity disk-drives are sub-par on these areas. This means
> > that programs will slow down because you are spending a lot of time
> > waiting for the disk-drive to give you bits because it keeps plugging
> > up its cache or not able to get various items off disk as fast as
> > advertised.
>
> Is there some reasonably valid understanding of how big an impact this
> makes in the average and worst case? Sort of a measure of the spread
> of disk-drive performance out in the wild.

Not that I know of.. I am guessing the proper methodology would be to get
3 disks of the same model (to check for divergence inside a model)
1 set of 5000 RPM ???
1 set of 7200 RPM
1 set of 10000 RPM
1 set of 15000 RPM

and sets depending on disk cache sizes and such.

And then plug them into the same hardware system so that one should be
just testing the diskdrive. Once that divergence testing has been
done.. it would next to see what changing controllers do [that is the
second thing we subjectively saw as a bigger improvement than getting
someone a faster CPU.]




--
Stephen J Smoogen.
CSIRT/Linux System Administrator



From ph18 at cornell.edu  Wed Nov 16 18:44:11 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Wed, 16 Nov 2005 13:44:11 -0500
Subject: init observations
In-Reply-To: <604aa7910511161022m7e179d57h68e71a341c7e263b@mail.gmail.com>
References: <20051116171711.GI4989@devserv.devel.redhat.com>	<045a01c5ead3$1b041aa0$b6491b31@td612671>	<20051116173033.GA26662@devserv.devel.redhat.com>	<80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<604aa7910511161022m7e179d57h68e71a341c7e263b@mail.gmail.com>
Message-ID: <437B7DFB.9070205@cornell.edu>

Jeff Spaleta wrote:

>Is there some reasonably valid understanding of how big an impact this
>makes in the average and worst case? Sort of a measure of the spread
>of disk-drive performance out in the wild.
>Say for example...a typical christmas special home desktop from
>Dell... does the disk-seek performance on a system like that make an
>order of magnitude faster bootup or application startup times a
>pipedream?
>  
>
    My back-of-the-envelope number is 3x better performance in Ultra 320 
drives vs PATA for seek-heavy workloads (database apps,  make -j4,  cp a 
50 GB directory.)  A big part of the advantage comes from tagged command 
queueing -- recent SATA drives support Native Command Queueing (NCQ) but 
benchmarks I've seen of NCQ drives aren't impressive.



From dimi at lattica.com  Wed Nov 16 18:48:03 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 13:48:03 -0500
Subject: init observations
References: <20051116171711.GI4989@devserv.devel.redhat.com><045a01c5ead3$1b041aa0$b6491b31@td612671><20051116173033.GA26662@devserv.devel.redhat.com>
	<80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
Message-ID: <049701c5eade$47441290$b6491b31@td612671>

From: "Stephen J. Smoogen" <smooge at gmail.com>
> To elaborate.. there are factors beyond your CPU/memory. What kind of
> diskdrive do you have? What is its transfer rates? What are it
> hit/miss rates? How is the layout of the disk optimized for disk-seek?
> 
> A lot of commodity disk-drives are sub-par on these areas. This means
> that programs will slow down because you are spending a lot of time
> waiting for the disk-drive to give you bits because it keeps plugging
> up its cache or not able to get various items off disk as fast as
> advertised.

I think this is missing the point -- we are not talking about some
big database intensive application that needs special handling to
work optimally. We are talking about the simplest application on
the desktop, on a fairly beefy machine, running the most stock FC4
out there.

If I need to do _anything_ special to get gedit to start in a decent
manner, something is clearly wrong. And BTW, try to start notepad
in Windows. It's fast.

I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
Granted, part of the problem may be in the application, but the user
doesn't know (and frankly, doesn't care).

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dravet at hotmail.com  Wed Nov 16 18:53:37 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Wed, 16 Nov 2005 12:53:37 -0600
Subject: questions and issues about the modular X updates
Message-ID: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>

I just updated my rawhide system to the new modular x.  I have been reading 
some of the threads discussing this and I have a couple of questions:

1.  With modular X (when released) have support for automatically turning on 
numlock when I start X?

2.  When I did the yum update all of the xorg-x11-drv rpms downloaded.  This 
is 56 files several of which I don't need.  I have a Number nine Revolution 
IV video supported by the i128 package.  I don't need the cirrus, trident, 
s3, nv, etc packages, but I can't uninstall them.  I get
rpm -e xorg-x11-drv-trident
error: Failed dependencies:
        xorg-x11-drv-trident is needed by (installed) 
xorg-x11-drivers-0.99.2-3.i386
Will I be able to uninstall unnecessary drivers?

3.  My Microsoft Intellimouse explorer (usb) no longer functions as 
expected.  I still have
        Option "Protocol" "ExplorerPS/2"
        Option "Device" "/dev/input/mice"
        Option "Buttons" "7"
        Option "ZAxisMapping" "6 7"
in my xorg.conf.  I also have the mouse.sh file in /etc/X11/xinit/xinitrc.d
#!/bin/sh
# /etc/X11/xinit/xinitrc.d/mouse.sh
# Required for the configuration of a 5-button mouse
xmodmap -e "pointer = 1 2 3 6 7 4 5"
In short the back and forward buttons work as a scroll.  How can I fix this?

If I need to open bugzilla tickets I will be happy to do so.  A quick guess 
would be to file #1 and #3 will bugzilla.freedesktop.org, and #2 should 
probably goto bugzilla.redhat.com.  Would this be correct?

Thanks,
Jason




From dimi at lattica.com  Wed Nov 16 18:53:54 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 13:53:54 -0500
Subject: init: API
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132164187.26095.48.camel@cassandra.boston.redhat.com>
Message-ID: <04b701c5eadf$18165310$b6491b31@td612671>

From: "David Malcolm" <dmalcolm at redhat.com>
> >   * a way for services to interact with the administrators
> >     (for example to ask for passphrases, etc.)
> 
> Youch!  :-)  Writing it that way makes me think of some nightmare world
> where the httpd service is restarting _me_

I know, we should avoid as much as possible any such interaction.
But in certain cases it is inevitable, and since we're talking 
about API, I think we should consider it. From an API perspective
it doesn't really matter that it is a rare use case.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.




From notting at redhat.com  Wed Nov 16 18:58:11 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 16 Nov 2005 13:58:11 -0500
Subject: init observations
In-Reply-To: <049701c5eade$47441290$b6491b31@td612671>
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<049701c5eade$47441290$b6491b31@td612671>
Message-ID: <20051116185811.GB20555@devserv.devel.redhat.com>

Dimi Paun (dimi at lattica.com) said: 
> I think this is missing the point -- we are not talking about some
> big database intensive application that needs special handling to
> work optimally. We are talking about the simplest application on
> the desktop, on a fairly beefy machine, running the most stock FC4
> out there.
> 
> If I need to do _anything_ special to get gedit to start in a decent
> manner, something is clearly wrong. And BTW, try to start notepad
> in Windows. It's fast.
> 
> I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
> Granted, part of the problem may be in the application, but the user
> doesn't know (and frankly, doesn't care).

It's disk seek on shared libraries, almost certianly. It's the majority
of lag time on *any* startup these days, including the OS itself.

Bill



From cmadams at hiwaay.net  Wed Nov 16 19:11:45 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 16 Nov 2005 13:11:45 -0600
Subject: init observations
In-Reply-To: <20051116185811.GB20555@devserv.devel.redhat.com>
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<049701c5eade$47441290$b6491b31@td612671>
	<20051116185811.GB20555@devserv.devel.redhat.com>
Message-ID: <20051116191145.GC1497776@hiwaay.net>

Once upon a time, Bill Nottingham <notting at redhat.com> said:
> It's disk seek on shared libraries, almost certianly. It's the majority
> of lag time on *any* startup these days, including the OS itself.

I know we have prelink, but has someone considered a defrag-like thing
that could work with prelink to re-arrange the libraries on the disk for
better performance?  IIRC Windows has the ability to do this and it is
supposed to really help.
-- 
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 dimi at lattica.com  Wed Nov 16 19:12:57 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 14:12:57 -0500
Subject: init observations
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com><049701c5eade$47441290$b6491b31@td612671>
	<20051116185811.GB20555@devserv.devel.redhat.com>
Message-ID: <04d601c5eae1$c116b840$b6491b31@td612671>

From: "Bill Nottingham" <notting at redhat.com>
> It's disk seek on shared libraries, almost certianly. It's the majority
> of lag time on *any* startup these days, including the OS itself.

OK, that's reasonable. However, I'm not sure we should just accept that.
How come notepad starts up fast on Windows? They don't have seeks?
And besides, what libs does gedit need on a fully loaded GNOME desktop
that are not already loaded?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From dragoran at feuerpokemon.de  Wed Nov 16 19:30:42 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 16 Nov 2005 20:30:42 +0100
Subject: init observations
In-Reply-To: <04d601c5eae1$c116b840$b6491b31@td612671>
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com><049701c5eade$47441290$b6491b31@td612671>	<20051116185811.GB20555@devserv.devel.redhat.com>
	<04d601c5eae1$c116b840$b6491b31@td612671>
Message-ID: <437B88E2.9070907@feuerpokemon.de>

Dimi Paun wrote:

>From: "Bill Nottingham" <notting at redhat.com>
>  
>
>>It's disk seek on shared libraries, almost certianly. It's the majority
>>of lag time on *any* startup these days, including the OS itself.
>>    
>>
>
>OK, that's reasonable. However, I'm not sure we should just accept that.
>How come notepad starts up fast on Windows? They don't have seeks?
>And besides, what libs does gedit need on a fully loaded GNOME desktop
>that are not already loaded?
>
>  
>
I had some startup issues with gedit too. But it wasn't a disk seek 
issue. (noticed that it takes longer if there is heavy network load ex: 
bittorent) . (its *much* fast when hostname=localhost=no network up)
I have set up a local dns server using bind and now the issues are gone.
Local apps should always use localhost as hostname which would have 
avoided this problem.



From jspaleta at gmail.com  Wed Nov 16 19:50:37 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 16 Nov 2005 14:50:37 -0500
Subject: init observations
In-Reply-To: <437B88E2.9070907@feuerpokemon.de>
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<049701c5eade$47441290$b6491b31@td612671>
	<20051116185811.GB20555@devserv.devel.redhat.com>
	<04d601c5eae1$c116b840$b6491b31@td612671>
	<437B88E2.9070907@feuerpokemon.de>
Message-ID: <604aa7910511161150q1bbbe30dm16c177bddcd40992@mail.gmail.com>

On 11/16/05, dragoran <dragoran at feuerpokemon.de> wrote:
> I had some startup issues with gedit too. But it wasn't a disk seek
> issue. (noticed that it takes longer if there is heavy network load ex:
> bittorent) . (its *much* fast when hostname=localhost=no network up)
> I have set up a local dns server using bind and now the issues are gone.
> Local apps should always use localhost as hostname which would have
> avoided this problem.

Can you explain why my system which has hostname!=localhost with an
active network
using a remote dns server has gedit start in under 1 second?

-jef



From petro at mail.ru  Wed Nov 16 21:05:23 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Thu, 17 Nov 2005 00:05:23 +0300
Subject: Whart happened with Mesa-libGL?
Message-ID: <Pine.LNX.4.64.0511170004390.30672@lemenkov.com>

Hello, All!


=======================================

[root at Petro temp]# yum upgrade
Setting up Upgrade Process
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
extras                    100% |=========================| 1.1 kB    00:00
livna                     100% |=========================|  951 B    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
primary.xml.gz            100% |=========================| 1.2 MB    00:14
Excluding Packages in global exclude list
Finished
Resolving Dependencies

[sorry, skipped]


mesa-libGL            i386       6.4-4            development        53M
       replacing  xorg-x11-Mesa-libGL.i386 6.8.2-62

=======================================

54 mbytes!

-- 
With best regards, Peter Lemenkov.




From katzj at redhat.com  Wed Nov 16 21:11:08 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 16 Nov 2005 16:11:08 -0500
Subject: Whart happened with Mesa-libGL?
In-Reply-To: <Pine.LNX.4.64.0511170004390.30672@lemenkov.com>
References: <Pine.LNX.4.64.0511170004390.30672@lemenkov.com>
Message-ID: <1132175468.21127.39.camel@bree.local.net>

On Thu, 2005-11-17 at 00:05 +0300, Peter Lemenkov wrote:
> mesa-libGL            i386       6.4-4            development        53M
>        replacing  xorg-x11-Mesa-libGL.i386 6.8.2-62
> 
> =======================================
> 
> 54 mbytes!

Shared libs aren't marked executable and so aren't getting stripped -- I
filed it last night (don't remember the bug # offhand)

Jeremy



From katzj at redhat.com  Wed Nov 16 21:12:53 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 16 Nov 2005 16:12:53 -0500
Subject: questions and issues about the modular X updates
In-Reply-To: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>
References: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>
Message-ID: <1132175573.21127.42.camel@bree.local.net>

On Wed, 2005-11-16 at 12:53 -0600, Jason Dravet wrote:
> 2.  When I did the yum update all of the xorg-x11-drv rpms downloaded.  This 
> is 56 files several of which I don't need.  I have a Number nine Revolution 
> IV video supported by the i128 package.  I don't need the cirrus, trident, 
> s3, nv, etc packages, but I can't uninstall them.  I get
> rpm -e xorg-x11-drv-trident
> error: Failed dependencies:
>         xorg-x11-drv-trident is needed by (installed) 
> xorg-x11-drivers-0.99.2-3.i386
> Will I be able to uninstall unnecessary drivers?

You previously had all the drivers installed.  By default, we're going
to be installing all of the drivers as that keeps things easier for
people to change hardware, etc.  Although not recommended, you can (at
least currently) remove the xorg-x11-drivers package and then remove
individual driver packages that you don't need.  This could cause
problems down the road if drivers get split or some other reason for
needing a new driver package.

Jeremy



From bojan at rexursive.com  Wed Nov 16 21:41:14 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 08:41:14 +1100
Subject: libesmtp rebuild
In-Reply-To: <20051116164520.w2tnrbwrc0cwg8ks@imp.rexursive.com>
References: <20051116125109.e86b91i82sw00ksg@imp.rexursive.com>
	<1132115483.2898.0.camel@localhost.localdomain>
	<20051116164520.w2tnrbwrc0cwg8ks@imp.rexursive.com>
Message-ID: <20051117084114.uo2qoo0428884c08@imp.rexursive.com>

Quoting Bojan Smojver <bojan at rexursive.com>:

> Excellent, thanks!

I think I spoke too soon. New binary RPM is not yet in the extras 
repository...

-- 
Bojan



From bojan at rexursive.com  Wed Nov 16 21:50:22 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 08:50:22 +1100
Subject: Another modular X11 report
Message-ID: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>

The switch to modular X on my notebook (HP ZE4201, hardware specs here: 
http://www.rexursive.com/articles/linuxonhpze4201.html) was a success, 
with a few minor details going wrong. This is what I checked:

- DRI works
- switching between X and text consoles works
- suspend/resume (with suspend2 patched 2.6.14-1.1674_FC5 kernel) works

This is what needs slight attention:

- synaptics module is in the wrong place (probably just needs a 
rebuild); symlinking the module from the old location to the new works 
around the problem
- as reported by the build system, openmotif is missing deps, which 
breaks Xpdf and third party software like Citrix ICA; I guess this will 
be rebuilt and fixed

Overall, top marks to people delivering modular X11!

-- 
Bojan



From davem at iabyn.com  Wed Nov 16 21:54:23 2005
From: davem at iabyn.com (Dave Mitchell)
Date: Wed, 16 Nov 2005 21:54:23 +0000
Subject: init observations
In-Reply-To: <04d601c5eae1$c116b840$b6491b31@td612671>
References: <20051116185811.GB20555@devserv.devel.redhat.com>
	<04d601c5eae1$c116b840$b6491b31@td612671>
Message-ID: <20051116215423.GJ4498@iabyn.com>

On Wed, Nov 16, 2005 at 02:12:57PM -0500, Dimi Paun wrote:
> OK, that's reasonable. However, I'm not sure we should just accept that.
> How come notepad starts up fast on Windows? They don't have seeks?
> And besides, what libs does gedit need on a fully loaded GNOME desktop
> that are not already loaded?

A quick strace of gedit startup on a FC3 system shows it doing over 3000
opens, which break down as:

1980 .icon files
1265 miscellaneous
  76 .so files


-- 
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
    -- old farmers' sayings #14



From sundaram at redhat.com  Wed Nov 16 21:57:07 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 17 Nov 2005 03:27:07 +0530
Subject: init observations
In-Reply-To: <20051116215423.GJ4498@iabyn.com>
References: <20051116185811.GB20555@devserv.devel.redhat.com>	<04d601c5eae1$c116b840$b6491b31@td612671>
	<20051116215423.GJ4498@iabyn.com>
Message-ID: <437BAB33.7040204@redhat.com>

Dave Mitchell wrote:

>On Wed, Nov 16, 2005 at 02:12:57PM -0500, Dimi Paun wrote:
>  
>
>>OK, that's reasonable. However, I'm not sure we should just accept that.
>>How come notepad starts up fast on Windows? They don't have seeks?
>>And besides, what libs does gedit need on a fully loaded GNOME desktop
>>that are not already loaded?
>>    
>>
>
>A quick strace of gedit startup on a FC3 system shows it doing over 3000
>opens, which break down as:
>
>1980 .icon files
>1265 miscellaneous
>  76 .so files
>  
>
Perhaps the gedit or GNOME performance lists would be a better place to 
analyse and provide such feedback.

regards
Rahul



From bojan at rexursive.com  Wed Nov 16 22:01:35 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 09:01:35 +1100
Subject: udev 0.75-2 slow?
Message-ID: <20051117090135.1lties5ba0c8cgc0@imp.rexursive.com>

Not sure if this is just my system, but the new version of udev appears 
to be taking a few minutes to do its bit on boot. Did anyone else 
notice this kind of behaviour?

-- 
Bojan



From d.jacobfeuerborn at conversis.de  Wed Nov 16 22:29:02 2005
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Wed, 16 Nov 2005 23:29:02 +0100
Subject: udev 0.75-2 slow?
In-Reply-To: <20051117090135.1lties5ba0c8cgc0@imp.rexursive.com>
References: <20051117090135.1lties5ba0c8cgc0@imp.rexursive.com>
Message-ID: <437BB2AE.1020803@conversis.de>

udev hangs for me too on boot but only for about 10 seconds. What is more 
of a problem though is the fact my "eth1" device apparently now is called 
"dev18685". Here is what systool has to say about the device:

   Class Device = "dev18685"
   Class Device path = "/sys/class/net/dev18685"
     addr_len            = "6"
     address             = "00:04:61:4a:12:1f"
     broadcast           = "ff:ff:ff:ff:ff:ff"
     features            = "0x0"
     flags               = "0x1002"
     ifindex             = "2"
     iflink              = "2"
     mtu                 = "1500"
     tx_queue_len        = "1000"
     type                = "1"
     uevent              = <store method only>
     weight              = "0"

     Device = "0000:00:04.0"
     Device path = "/sys/devices/pci0000:00/0000:00:04.0"
       class               = "0x020000"
       config              =  de 10 66 00 07 00 b0 00  a1 00 00 02 00 00 00 00
                              00 00 00 ec 01 ec 00 00  00 00 00 00 00 00 00 00
                              00 00 00 00 00 00 00 00  00 00 00 00 95 16 00 10
                              00 00 00 00 44 00 00 00  00 00 00 00 0a 01 01 14
       device              = "0x0066"
       irq                 = "10"
       local_cpus          = "1"
       modalias            = 
"pci:v000010DEd00000066sv00001695sd00001000bc02sc00i00"
       resource            = "0x00000000ec000000 0x00000000ec000fff 
0x0000000000000200
0x000000000000ec00 0x000000000000ec07 0x0000000000000101
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000"
       subsystem_device    = "0x1000"
       subsystem_vendor    = "0x1695"
       uevent              = <store method only>
       vendor              = "0x10de"

Regards,
   Dennis

Bojan Smojver wrote:
> Not sure if this is just my system, but the new version of udev appears 
> to be taking a few minutes to do its bit on boot. Did anyone else notice 
> this kind of behaviour?
> 



From d.jacobfeuerborn at conversis.de  Wed Nov 16 22:39:39 2005
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Wed, 16 Nov 2005 23:39:39 +0100
Subject: Modular X installation results
Message-ID: <437BB52B.8030200@conversis.de>

The upgrade to modular X went pretty well for me except for the fact that I 
had to install the package "xorg-x11-xauth" manually because the yum update 
apparently didn't pick that up.

What I immediately after reboot though was how slow my desktop has become. 
Moving around a window on the desktop is now very jerky. Before I saw the 
usual gtk refresh artifacts but the movement of the window itself was 
smooth. I have DRI disabled because I don't care about 3D and here is the 
device config I'm running right now:

Section "Device"
         Identifier  "Videocard0"
         Driver      "radeon"
         VendorName  "Videocard vendor"
         BoardName   "ATI Radeon 9500 Pro"
#       Option      "RenderAccel" "on"
#       Option      "EnablePageFlip" "on"
#       Option      "BackingStore" "on"
EndSection

According to the log XAA is enabled:

...
(II) RADEON(0): Render acceleration unsupported on Radeon 9500/9700 and newer.
(II) RADEON(0): Render acceleration disabled
(II) RADEON(0): Using XFree86 Acceleration Architecture (XAA)
         Screen to screen bit blits
         Solid filled rectangles
         8x8 mono pattern filled rectangles
         Indirect CPU to Screen color expansion
         Solid Lines
         Scanline Image Writes
         Offscreen Pixmaps
         Setting up tile and stipple cache:
                 32 128x128 slots
                 32 256x256 slots
                 16 512x512 slots
(II) RADEON(0): Acceleration enabled
...

Regards,
   Dennis



From selinux at gmail.com  Wed Nov 16 22:43:21 2005
From: selinux at gmail.com (Tom London)
Date: Wed, 16 Nov 2005 14:43:21 -0800
Subject: udev 0.75-2 slow?
In-Reply-To: <437BB2AE.1020803@conversis.de>
References: <20051117090135.1lties5ba0c8cgc0@imp.rexursive.com>
	<437BB2AE.1020803@conversis.de>
Message-ID: <4c4ba1530511161443q72aac35l790781569a98c319@mail.gmail.com>

On 11/16/05, Dennis Jacobfeuerborn <d.jacobfeuerborn at conversis.de> wrote:
> udev hangs for me too on boot but only for about 10 seconds. What is more
> of a problem though is the fact my "eth1" device apparently now is called
> "dev18685". Here is what systool has to say about the device:
>
>    Class Device = "dev18685"
>    Class Device path = "/sys/class/net/dev18685"
>      addr_len            = "6"
>      address             = "00:04:61:4a:12:1f"
>      broadcast           = "ff:ff:ff:ff:ff:ff"
>      features            = "0x0"
>      flags               = "0x1002"
>      ifindex             = "2"
>      iflink              = "2"
>      mtu                 = "1500"
>      tx_queue_len        = "1000"
>      type                = "1"
>      uevent              = <store method only>
>      weight              = "0"
>
>      Device = "0000:00:04.0"
>      Device path = "/sys/devices/pci0000:00/0000:00:04.0"
>        class               = "0x020000"
>        config              =  de 10 66 00 07 00 b0 00  a1 00 00 02 00 00 00 00
>                               00 00 00 ec 01 ec 00 00  00 00 00 00 00 00 00 00
>                               00 00 00 00 00 00 00 00  00 00 00 00 95 16 00 10
>                               00 00 00 00 44 00 00 00  00 00 00 00 0a 01 01 14
>        device              = "0x0066"
>        irq                 = "10"
>        local_cpus          = "1"
>        modalias            =
> "pci:v000010DEd00000066sv00001695sd00001000bc02sc00i00"
>        resource            = "0x00000000ec000000 0x00000000ec000fff
> 0x0000000000000200
> 0x000000000000ec00 0x000000000000ec07 0x0000000000000101
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000"
>        subsystem_device    = "0x1000"
>        subsystem_vendor    = "0x1695"
>        uevent              = <store method only>
>        vendor              = "0x10de"
>
> Regards,
>    Dennis
>
> Bojan Smojver wrote:
> > Not sure if this is just my system, but the new version of udev appears
> > to be taking a few minutes to do its bit on boot. Did anyone else notice
> > this kind of behaviour?
> >
>

Hmm, I hadn't noticed, but udev apparently renamed my NICs.
Prior to today: wired NIC was eth0, wireless NIC was eth1,
now
wired NIC is eth1, wireless is eth0.

tom
--
Tom London



From pp at ee.oulu.fi  Wed Nov 16 23:14:07 2005
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Thu, 17 Nov 2005 01:14:07 +0200
Subject: Another modular X11 report
In-Reply-To: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
Message-ID: <20051116231407.GA9993@ee.oulu.fi>

And yet another report. Near-total failure :-(

startx doesn't work, I hit https://bugs.freedesktop.org/show_bug.cgi?id=5068

gdm starts up nicely (-nolisten tcp is a workaround for the bug),
but logins don't work, "gdm-binary[3141]:
Couldn't authenticate user" in the logs. Some pam-stack complaints too.
Haven't had the timen to fully debug that, maybe tomorrow...

startx -- -nolisten tcp gets things up and running, fortunately.

And some XKB errors after X is up.

Otherwise it's happy! For such a major change, not bad at all! :D

-- 
Pekka Pietikainen



From pp at ee.oulu.fi  Wed Nov 16 23:33:18 2005
From: pp at ee.oulu.fi (Pekka Pietikainen)
Date: Thu, 17 Nov 2005 01:33:18 +0200
Subject: Another modular X11 report
In-Reply-To: <20051116231407.GA9993@ee.oulu.fi>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
	<20051116231407.GA9993@ee.oulu.fi>
Message-ID: <20051116233318.GA10437@ee.oulu.fi>

On Thu, Nov 17, 2005 at 01:14:07AM +0200, Pekka Pietikainen wrote:
> And yet another report. Near-total failure :-(
> 
> startx doesn't work, I hit https://bugs.freedesktop.org/show_bug.cgi?id=5068
> 
> gdm starts up nicely (-nolisten tcp is a workaround for the bug),
> but logins don't work, "gdm-binary[3141]:
> Couldn't authenticate user" in the logs. Some pam-stack complaints too.
> Haven't had the timen to fully debug that, maybe tomorrow...
rpm -Uvh --force gdm-2.8.0.4-12.x86_64.rpm cleared things up. *shrug*

> And some XKB errors after X is up.
This was probably since I redid my xorg.conf, and it had us instead of fi
keyboard mapping afterwards. system-config-keyboard, select fi, and
everything was happy again.

So, only https://bugs.freedesktop.org/show_bug.cgi?id=5068 left as a real
bug, everything else was just package upgrade hiccups. And since all bugs
have been filed, I can just happily go to sleep. Good night y'all!  

-- 
Pekka Pietikainen



From bojan at rexursive.com  Wed Nov 16 23:54:53 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 10:54:53 +1100
Subject: Another modular X11 report
In-Reply-To: <20051116233318.GA10437@ee.oulu.fi>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
	<20051116231407.GA9993@ee.oulu.fi> <20051116233318.GA10437@ee.oulu.fi>
Message-ID: <20051117105453.4icaewgtogwwkw0w@imp.rexursive.com>

Quoting Pekka Pietikainen <pp at ee.oulu.fi>:


>> Haven't had the timen to fully debug that, maybe tomorrow...
> rpm -Uvh --force gdm-2.8.0.4-12.x86_64.rpm cleared things up. *shrug*

Actually, even if you upgrade gdm but keep gdm.conf file from the old 
install (e.g. new gdm installs gdm.conf.rpmnew instaed), you'll have a 
problem. I think it is a must to use the new configuration for gdm as 
well, as the old stuff does not work at all.

-- 
Bojan



From dmalcolm at redhat.com  Thu Nov 17 00:49:37 2005
From: dmalcolm at redhat.com (David Malcolm)
Date: Wed, 16 Nov 2005 19:49:37 -0500
Subject: Improving desktop application performance WAS Re: init observations
In-Reply-To: <049701c5eade$47441290$b6491b31@td612671>
References: <20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
	<20051116173033.GA26662@devserv.devel.redhat.com>
	<80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<049701c5eade$47441290$b6491b31@td612671>
Message-ID: <1132188578.17314.26.camel@cassandra.boston.redhat.com>

On Wed, 2005-11-16 at 13:48 -0500, Dimi Paun wrote:
> From: "Stephen J. Smoogen" <smooge at gmail.com>
> > To elaborate.. there are factors beyond your CPU/memory. What kind of
> > diskdrive do you have? What is its transfer rates? What are it
> > hit/miss rates? How is the layout of the disk optimized for disk-seek?
> > 
> > A lot of commodity disk-drives are sub-par on these areas. This means
> > that programs will slow down because you are spending a lot of time
> > waiting for the disk-drive to give you bits because it keeps plugging
> > up its cache or not able to get various items off disk as fast as
> > advertised.
> 
> I think this is missing the point -- we are not talking about some
> big database intensive application that needs special handling to
> work optimally. We are talking about the simplest application on
> the desktop, on a fairly beefy machine, running the most stock FC4
> out there.
> 
> If I need to do _anything_ special to get gedit to start in a decent
> manner, something is clearly wrong. And BTW, try to start notepad
> in Windows. It's fast.
> 
> I think that anything over 500ms for gedit is bad. Even on a 500MHz box.
> Granted, part of the problem may be in the application, but the user
> doesn't know (and frankly, doesn't care).
> 

[changing Subject to better reflect this part of the thread]

There's lots of good work on improving exactly this kind of thing going
on at the moment in the upstream GNOME community (e.g. optimizing Pango,
the filechooser, session startup time etc).

If anyone with C coding skills is interested in helping out with this
effort, it'd be great if you could help out there, and we'll see the
improvements landing in FC5

The relevant mailing list is performance-list at gnome.org, where there's a
strong focus on good methodology i.e. measuring to determine exactly
what's really causing a problem, then trying a change, then measuring
the effects.  Sometimes the proposed optimizations have turned out to
actually slow things down...

Some great resources are Lorenzo's Colitti's analysis page on speeding
up gnome:
http://www.gnome.org/~lcolitti/gnome-startup/analysis/  [1]


See also Federico's blog:
http://primates.ximian.com/~federico/news.html

Plus this page on the GNOME wiki:
http://live.gnome.org/Performance

Hope this helps

Dave

[1] with plenty of help from the #fedora-desktop gang :-)



From dimi at lattica.com  Thu Nov 17 01:17:32 2005
From: dimi at lattica.com (Dimi Paun)
Date: Wed, 16 Nov 2005 20:17:32 -0500
Subject: init observations
In-Reply-To: <604aa7910511160950v17c22dfex32a9c2bc7a6b8c5c@mail.gmail.com>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116171711.GI4989@devserv.devel.redhat.com>
	<045a01c5ead3$1b041aa0$b6491b31@td612671>
	<604aa7910511160950v17c22dfex32a9c2bc7a6b8c5c@mail.gmail.com>
Message-ID: <1132190253.9749.106.camel@dimi.lattica.com>

On Wed, 2005-11-16 at 12:50 -0500, Jeff Spaleta wrote:
> How do you time this?

Stopwatch. I just did it again, and it's just shy of 3s
(maybe 2.9s). And since people asked about HD, here are
some numbers:

[root at dimi ~]# hdparm -Tt /dev/hda

/dev/hda:
 Timing cached reads:   3704 MB in  2.00 seconds = 1851.36 MB/sec
 Timing buffered disk reads:  170 MB in  3.03 seconds =  56.17 MB/sec

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From mharris at redhat.com  Thu Nov 17 01:45:06 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 20:45:06 -0500
Subject: questions and issues about the modular X updates
In-Reply-To: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>
References: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>
Message-ID: <437BE0A2.5050205@redhat.com>

Jason Dravet wrote:
> I just updated my rawhide system to the new modular x.  I have been 
> reading some of the threads discussing this and I have a couple of 
> questions:
> 
> 1.  With modular X (when released) have support for automatically 
> turning on numlock when I start X?

You can do that with any version of X, by calling xset from
~/.Xclients or ~/.xinitrc, or one of the systemwide locations.

> 2.  When I did the yum update all of the xorg-x11-drv rpms downloaded.  
> This is 56 files several of which I don't need.  I have a Number nine 
> Revolution IV video supported by the i128 package.  I don't need the 
> cirrus, trident, s3, nv, etc packages, but I can't uninstall them.  I get
> rpm -e xorg-x11-drv-trident
> error: Failed dependencies:
>        xorg-x11-drv-trident is needed by (installed) 
> xorg-x11-drivers-0.99.2-3.i386

Yes, this is intentional.  The reasons for splitting the drivers out
into individual packages, was to:

- make it very easy for us to release single driver updates

- to drastically reduce the amount of downloading necessary to update
   a single driver

- drastically reduce the disk space consumption and network bandwidth
   consumption for mirror sites as well as internal build machines

- to make it easy to add new video drivers to a release without
   having to release a whole new 150Mb of X packages.


However, the system is designed intentionally to still install all of
the X drivers all of the time, and to expect that they are all there.

The disk space usage of the entire set of drivers is very minimal with
today's hard disk sizes, so saving disk space by being able to remove
the drivers one does not need (or does not think they need), is not an
intended "feature".  In fact removing individual driver packages is
very strongly discouraged, as it can break upgrades.

At a minimum, if someone uninstalls a driver, and later switches
or adds hardware that needs that hardware, the config tools will detect
the new hardware, and configure X to use the driver that is not there.
The X server will fail to start, complaining that there is no such
driver, and the user may file a bug report to us about a missing
driver, that is not missing, it's just been uninstalled.

Please note that this is just a short term thing.  In the long term,
perhaps in FC6 or FC7 depending on various factors, I would like to
see the config tools updated with the capability to know about all
of the drivers shipped in the OS, and be able to ask for the Fedora
CDROM or use yum to download them if you have uninstalled a driver
that you now have hardware for.  However if you do that now, things
_WILL_ break.  If not right away, then when you do your next OS
upgrade.

So, for FC5, make no mistake:  Do not uninstall individual X drivers
unless you want to end up in a whole world of pain, just to save
the equivalent of about 5 cents worth of disk space.

The xorg-x11-drivers package is a meta-package that does nothing
other than "Require: <driver>" all of the drivers, in order to
ensure that they are all installed - like almost every modern
operating system does nowadays because disk space is cheap and
drivers are small comparatively.

The X server package is probably going to pick up a new dependency
soon of "Requires: xorg-x11-drivers" to further enforce that all
drivers are always installed.

This is entirely a support decision, to minimize end user technical
problems that could potentially happen, until we have improved the
rest of the OS to be more dynamically friendly WRT drivers.


> Will I be able to uninstall unnecessary drivers?

In theory, you could force them to uninstall, breaking the dependency
chain, but then you take all risks of the OS not working on upgrades.

People who force things to be uninstalled, and then experience problems
and file bug reports, will generally not get any pity, and will
see CLOSED->NOTABUG likely.  ;o)


> 3.  My Microsoft Intellimouse explorer (usb) no longer functions as 
> expected.  I still have
>        Option "Protocol" "ExplorerPS/2"
>        Option "Device" "/dev/input/mice"
>        Option "Buttons" "7"
>        Option "ZAxisMapping" "6 7"
> in my xorg.conf.  I also have the mouse.sh file in /etc/X11/xinit/xinitrc.d
> #!/bin/sh
> # /etc/X11/xinit/xinitrc.d/mouse.sh
> # Required for the configuration of a 5-button mouse
> xmodmap -e "pointer = 1 2 3 6 7 4 5"
> In short the back and forward buttons work as a scroll.  How can I fix 
> this?

I believe they've been playing with this part of the code in Xorg CVS
lately, and that it might have gotten broken.  I think I saw some CVS
commits go in in the last few days related to button ordering, but I
don't remember the details.  My recommendation, is to post a message to
xorg at lists.freedesktop.org about it for now, and see what feedback you
get back.  If it turns out it is a bug, and is not fixed in CVS, query
xorg bugzilla to see if someone has already reported it or not, and if
not, file a bug, and attach your X server config and log, and your
script to the report, and mark it blocking the release blocker
bug #1690



> If I need to open bugzilla tickets I will be happy to do so.  A quick 
> guess would be to file #1 and #3 will bugzilla.freedesktop.org, and #2 
> should probably goto bugzilla.redhat.com.  Would this be correct?

#1 isn't a bug, you can already do that in every X release
#2 isn't a bug, it is an intended support/engineering feature designed
    to minimize end user problems and unnecessary bug reports.
#3 might be an Xorg bug as mentioned above.

Hope this helps!

Take care,
TTYL



From dravet at hotmail.com  Thu Nov 17 01:49:58 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Wed, 16 Nov 2005 19:49:58 -0600
Subject: custom kernels always panic since monday
Message-ID: <BAY103-F34A85F70DCF20F4B7793FBDF5F0@phx.gbl>

I have been trying to boot a custom kernel I made last week but since monday 
it and every kernel I have compiled since then panics during boot.  I have 
tried vanilla kernels and fedora kernel SRPMS and both panic.  The only 
kernels that run are fedora kernel rpms.

Here is what shows on the screen:

trying to resume from /dev/VolGroup00/LogVol01
unable to access resume device
creating root device
mounting root filesystems
mount: error No such device or address mounting /dev/root on /sysroot as 
ext3
setting up other filesystems
setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fdtab.sys, mounting internal defaults
setuproot error mount /proc No such file or directory
setuproot error mount /sys No such file or directory
switching to new root and running init
unmounting old /dev
unmounting old /proc
unmounting old /sys
switch root: mount failed No such file or directory
kernel panic -not syncing attempted to kill init
[<c0120a96>] panic+0x46/0x1c0
[<c0121f3d>] profile_task_exit+0x3d/0x60
[<c0123d01>] do_exit+0x351/0x3b0
[<c015e06a>] do_munmap+0xea/0x120
[<c0123d17>] do_group_exit+0x37/0xa0
[<c0103269>] syscall_call+0x7/0xb

What is going on?  Should I open a bugzilla ticket?  If so, what component 
should I say is the problem?

Thanks,
Jason




From bart.vanbrabant at zoeloelip.be  Thu Nov 17 01:12:59 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Thu, 17 Nov 2005 02:12:59 +0100
Subject: Modular X
Message-ID: <437BD91B.3050404@zoeloelip.be>

Hello,

I just installed the new modular X from rawhide. Everything went quite
good except for two problems:

1) The nvidia driver doesn't handle modular X yet. But I solved it by
manually moving all libraries to their new places. This isn't something
that should be handled by fedora.

2) There were two paths in my xorg.conf that pointed to the old /usr/X11
places. Those where ModulePath and RgbPath. I changed them like this:
        RgbPath      "/usr/share/X11/rgb"
        ModulePath   "/usr/lib/xorg/modules"
It this something that other users could have problems with to? Because
then a postinstall script should check for this. Do I need to file a
bugreport?

cheers,

Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/82fbdd6b/attachment.sig>

From dravet at hotmail.com  Thu Nov 17 02:41:44 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Wed, 16 Nov 2005 20:41:44 -0600
Subject: questions and issues about the modular X updates
Message-ID: <BAY103-F22BB9245FC4EB24BCCCA24DF5F0@phx.gbl>

>>Jason Dravet wrote:
>>
>>    I just updated my rawhide system to the new modular x. I have been 
>>reading some of the >>threads discussing this and I have a couple of 
>>questions:
>>
>>    1. With modular X (when released) have support for 
>>automaticahttp://by103fd.bay103.hotmail.msn.com/cgi-bin/compose?curmbox=00000000-0000-0000-0000-000000000002&a=61346a0e9f29bc7b56547fd59892ba60758e39c15a561453426ebfa90047dd1f&mailto=1&to=fedora-devel-list at redhat.com&msg=C60E54F8-83B5-41AA-ACB8-6813CC6DEA7A&start=0&len=26350&src=&type=x#
Sendlly turning on numlock when I >>start X?
>
>You can do that with any version of X, by calling xset from
>~/.Xclients or ~/.xinitrc, or one of the systemwide locations.
>
I saw the saw the setup for xset.  I was hoping for a cleaner solution.  For 
example IMO having a line in the xorg.conf file to control the caps lock, 
scroll lock, and num lock would be the best solution.  It keeps all of the 
configuration data together.  When I move to new version of Fedora I format 
my hard drive and copy the data back from a usb thumb drive.  Right now I 
have to copy back approximately 20 configuration files and alot of odds and 
ends to get the system back to where it was before I updated.  If there was 
a line in xorg to control the lock keys then to get X back up and running I 
would only have to put the xorg.conf back.  Right now I have put xorg.conf 
back, copy my mouse.sh file back, and copy the numlock.sh file back.  Am I 
crazy for thinking 1 file is better than 3?
>
>>    2. When I did the yum update all of the xorg-x11-drv rpms downloaded. 
>>This is 56 files several >>of which I don't need. I have a Number nine 
>>Revolution IV video supported by the i128 package. >>I don't need the 
>>cirrus, trident, s3, nv, etc packages, but I can't uninstall them. I get
>>
>>
>Yes, this is intentional.  The reasons for splitting the drivers out
>into individual packages, was to:
>
>- make it very easy for us to release single driver updates
>
>- to drastically reduce the amount of downloading necessary to update
>  a single driver
>
>- drastically reduce the disk space consumption and network bandwidth
>  consumption for mirror sites as well as internal build machines
>
>- to make it easy to add new video drivers to a release without
>  having to release a whole new 150Mb of X packages.
>
I agree this is a good thing.  Being able to release new drivers as soon as 
they come out without having to respwan all of X is great.  My concern is 
for bandwidth.  Looking at the xorg-x11-drv files there are about 2.3MB of 
drivers.  This number is only going to go up as time goes on and drivers are 
added and updated. The idea about installing new hardware and having yum or 
some other application go and download the driver is good.  I agree that 
such functionality will not be here for FC5.  If this is where things are 
going then I will shut up and download everything.

>>    3. My Microsoft Intellimouse explorer (usb) no longer functions as 
>>expected. I still have
>>
>>       Option "Protocol" "ExplorerPS/2"
>>       Option "Device" "/dev/input/mice"
>>       Option "Buttons" "7"
>>       Option "ZAxisMapping" "6 7"
>>in my xorg.conf.  I also have the mouse.sh file in 
>>/etc/X11/xinit/xinitrc.d
>>#!/bin/sh
>># /etc/X11/xinit/xinitrc.d/mouse.sh
>># Required for the configuration of a 5-button mouse
>>xmodmap -e "pointer = 1 2 3 6 7 4 5"
>>
>>    In short the back and forward buttons work as a scroll. How can I fix 
>>this?
>
>I believe they've been playing with this part of the code in Xorg CVS
>lately, and that it might have gotten broken.  I think I saw some CVS
>commits go in in the last few days related to button ordering, but I
>don't remember the details.  My recommendation, is to post a message to
>xorg lists freedesktop org about it for now, and see what feedback you
>get back.  If it turns out it is a bug, and is not fixed in CVS, query
>xorg bugzilla to see if someone has already reported it or not, and if
>not, file a bug, and attach your X server config and log, and your
>script to the report, and mark it blocking the release blocker
>bug #1690

You are correct there is a thread called ZAxisMapping causing trouble at 
http://lists.freedesktop.org/archives/xorg/2005-November/date.html.  I will 
keep checking the list for updates.

Thank you for the reply the information was very helpful.
Jason




From mharris at redhat.com  Thu Nov 17 02:52:18 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 21:52:18 -0500
Subject: Whart happened with Mesa-libGL?
In-Reply-To: <Pine.LNX.4.64.0511170004390.30672@lemenkov.com>
References: <Pine.LNX.4.64.0511170004390.30672@lemenkov.com>
Message-ID: <437BF062.9020303@redhat.com>

Peter Lemenkov wrote:
> Hello, All!
> 
> 
> =======================================
> 
> [root at Petro temp]# yum upgrade
> Setting up Upgrade Process
> Setting up repositories
> development               100% |=========================| 1.1 kB    00:00
> extras                    100% |=========================| 1.1 kB    00:00
> livna                     100% |=========================|  951 B    00:00
> extras-development        100% |=========================| 1.1 kB    00:00
> Reading repository metadata in from local files
> primary.xml.gz            100% |=========================| 1.2 MB    00:14
> Excluding Packages in global exclude list
> Finished
> Resolving Dependencies
> 
> [sorry, skipped]
> 
> 
> mesa-libGL            i386       6.4-4            development        53M
>       replacing  xorg-x11-Mesa-libGL.i386 6.8.2-62
> 
> =======================================
> 
> 54 mbytes!

The new and improved Mesa, is so dramatically improved, that it takes
up a lot more space now, but provides a never ending experience of
stunning graphics quality and performance that has never before been
seen.

Ok, that might not be completely true. ;o)

The mesa stuff isn't getting stripped properly.  There's a bug on it
in bugzilla already.



From mharris at redhat.com  Thu Nov 17 02:53:17 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 21:53:17 -0500
Subject: questions and issues about the modular X updates
In-Reply-To: <1132175573.21127.42.camel@bree.local.net>
References: <BAY103-F1948DA23E19AAEAA9D233DF5C0@phx.gbl>
	<1132175573.21127.42.camel@bree.local.net>
Message-ID: <437BF09D.9090809@redhat.com>

Jeremy Katz wrote:
> On Wed, 2005-11-16 at 12:53 -0600, Jason Dravet wrote:
> 
>>2.  When I did the yum update all of the xorg-x11-drv rpms downloaded.  This 
>>is 56 files several of which I don't need.  I have a Number nine Revolution 
>>IV video supported by the i128 package.  I don't need the cirrus, trident, 
>>s3, nv, etc packages, but I can't uninstall them.  I get
>>rpm -e xorg-x11-drv-trident
>>error: Failed dependencies:
>>        xorg-x11-drv-trident is needed by (installed) 
>>xorg-x11-drivers-0.99.2-3.i386
>>Will I be able to uninstall unnecessary drivers?
> 
> 
> You previously had all the drivers installed.  By default, we're going
> to be installing all of the drivers as that keeps things easier for
> people to change hardware, etc.  Although not recommended, you can (at
> least currently) remove the xorg-x11-drivers package and then remove
> individual driver packages that you don't need.  This could cause
> problems down the road if drivers get split or some other reason for
> needing a new driver package.

Except that that wont work when I make the X server depend on the
xorg-x11-drivers package to be present, to stop people from
uninstalling drivers.  ;o)




From mharris at redhat.com  Thu Nov 17 02:55:22 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 21:55:22 -0500
Subject: Another modular X11 report
In-Reply-To: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
Message-ID: <437BF11A.40007@redhat.com>

Bojan Smojver wrote:
> The switch to modular X on my notebook (HP ZE4201, hardware specs here: 
> http://www.rexursive.com/articles/linuxonhpze4201.html) was a success, 
> with a few minor details going wrong. This is what I checked:
> 
> - DRI works
> - switching between X and text consoles works
> - suspend/resume (with suspend2 patched 2.6.14-1.1674_FC5 kernel) works
> 
> This is what needs slight attention:
> 
> - synaptics module is in the wrong place (probably just needs a 
> rebuild); symlinking the module from the old location to the new works 
> around the problem

Upgrade to the latest synaptics driver, and if the problem is still
there, please file a bug report against "synaptics".  The rpm should
be changed to use pkg-config to query where the X server's module
directory is, and then install into %{moduledir}/input.

> - as reported by the build system, openmotif is missing deps, which 
> breaks Xpdf and third party software like Citrix ICA; I guess this will 
> be rebuilt and fixed

Yep, openmotif needs some love. ;o)

> Overall, top marks to people delivering modular X11!

Thanks, much appreciated.




From mharris at redhat.com  Thu Nov 17 03:01:33 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 22:01:33 -0500
Subject: Modular X installation results
In-Reply-To: <437BB52B.8030200@conversis.de>
References: <437BB52B.8030200@conversis.de>
Message-ID: <437BF28D.60004@redhat.com>

Dennis Jacobfeuerborn wrote:
> The upgrade to modular X went pretty well for me except for the fact 
> that I had to install the package "xorg-x11-xauth" manually because the 
> yum update apparently didn't pick that up.

Hmm, that's odd.  Both monolithic and modular X have an xorg-x11-xauth
package, so it should have gotten updated.

Current xauth is: xorg-x11-xauth-0.99.2-1

Does yum honour rpm Epoch tags properly I wonder?  If yum ignores the
epoch on the package, then it would consider the new 0.99.2 version
to be lower than the old version of 6.8.2.


$ rpm -qp --qf '%{name}-%{epoch}:%{version}-%{release}\n' \
                xorg-x11-xauth-0.99.2-1.src.rpm
xorg-x11-xauth-1:0.99.2-1

The epoch is showing up in query, so I'd suspect a possible yum bug
perhaps.


> What I immediately after reboot though was how slow my desktop has 
> become. Moving around a window on the desktop is now very jerky. Before 
> I saw the usual gtk refresh artifacts but the movement of the window 
> itself was smooth. I have DRI disabled because I don't care about 3D and 
> here is the device config I'm running right now:

Please report any driver performance or stability problems to X.Org
bugzilla at http://bugs.freedesktop.org in the "xorg" component.  Be
sure to use bugzilla file attachment feature to attach your complete
X server log and config file as individual file attachments, then
mark the bug as blocking bug #1690, to ensure it gets looked at for
X11R7.

Hope this helps.



From mharris at redhat.com  Thu Nov 17 03:06:24 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 22:06:24 -0500
Subject: Another modular X11 report
In-Reply-To: <20051116231407.GA9993@ee.oulu.fi>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
	<20051116231407.GA9993@ee.oulu.fi>
Message-ID: <437BF3B0.1090306@redhat.com>

Pekka Pietikainen wrote:
> And yet another report. Near-total failure :-(
> 
> startx doesn't work, I hit https://bugs.freedesktop.org/show_bug.cgi?id=5068

I've CC'd myself on that one to keep an eye on it.

> gdm starts up nicely (-nolisten tcp is a workaround for the bug),
> but logins don't work, "gdm-binary[3141]:
> Couldn't authenticate user" in the logs. Some pam-stack complaints too.
> Haven't had the timen to fully debug that, maybe tomorrow...

Hmm, that could be due to recent pam changes.  gdm might need to update
it's pam config files.  I think xdm needs to have them updated too.

> startx -- -nolisten tcp gets things up and running, fortunately.

Cool.

> And some XKB errors after X is up.

What are the errors?

> Otherwise it's happy! For such a major change, not bad at all! :D

Good to hear!  With any major change like this, I usually get fairly
paranoid as the "goes into rawhide" date approaches, as there are
always a million possible problems that can occur, and it's hard to
predict all of the possiblities.  We've hit some issues already, but
so far things seem to be going remarkably smooth, which surprises
me.  I'm biting my nails wondering "when is the big surprise
coming?".  ;o)



From mharris at redhat.com  Thu Nov 17 03:09:43 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 22:09:43 -0500
Subject: Modular X
In-Reply-To: <437BD91B.3050404@zoeloelip.be>
References: <437BD91B.3050404@zoeloelip.be>
Message-ID: <437BF477.6000607@redhat.com>

Bart Vanbrabant wrote:
> Hello,
> 
> I just installed the new modular X from rawhide. Everything went quite
> good except for two problems:
> 
> 1) The nvidia driver doesn't handle modular X yet. But I solved it by
> manually moving all libraries to their new places. This isn't something
> that should be handled by fedora.

I believe Nvidia provides a driver that works with the dlopen loader
used in modular X.  I'm not sure how it is provided exactly, but
hopefully the livna.org nvidia rpms will update to using the new
driver, and move things to the new locations.

> 2) There were two paths in my xorg.conf that pointed to the old /usr/X11
> places. Those where ModulePath and RgbPath. I changed them like this:
>         RgbPath      "/usr/share/X11/rgb"
>         ModulePath   "/usr/lib/xorg/modules"

Aha!  Good catch!  Please file these in bugzilla.  I'll have to massage
our X server installation to remove these lines from the config, and get
our config tools changed to stop writing out unnecessary lines to the
config file as it ends up breaking future X changes down the line.

> It this something that other users could have problems with to? Because
> then a postinstall script should check for this. Do I need to file a
> bugreport?

Yes definitely, please do!  Thanks very much for testing, and for the
reports too!



From bgerst at didntduck.org  Thu Nov 17 03:52:48 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Wed, 16 Nov 2005 22:52:48 -0500
Subject: glxgears / glxinfo
Message-ID: <437BFE90.8070302@didntduck.org>

Which package are glxgears/glxinfo hiding in now?  They used to be in 
xorg-x11-tools.

--
				Brian Gerst



From bojan at rexursive.com  Thu Nov 17 03:51:42 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 14:51:42 +1100
Subject: Another modular X11 report
In-Reply-To: <437BF11A.40007@redhat.com>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
	<437BF11A.40007@redhat.com>
Message-ID: <20051117145142.irrxqq03k080okk4@imp.rexursive.com>

Quoting "Mike A. Harris" <mharris at redhat.com>:

> Upgrade to the latest synaptics driver, and if the problem is still
> there, please file a bug report against "synaptics".

The latest synaptics driver in Rawhide, version 0.14.4-1 is the one 
with the wrong paths. I'm guessing another version is going to hit 
Rawhide tomorrow and I should check that. Right?

-- 
Bojan



From bojan at rexursive.com  Thu Nov 17 03:57:00 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 14:57:00 +1100
Subject: Another modular X11 report
In-Reply-To: <437BF11A.40007@redhat.com>
References: <20051117085022.zrp83tclysc8gg8c@imp.rexursive.com>
	<437BF11A.40007@redhat.com>
Message-ID: <20051117145700.rysqda3zzy84osco@imp.rexursive.com>

Quoting "Mike A. Harris" <mharris at redhat.com>:

> please file a bug report against "synaptics".

Too late, somebody already did:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172576

-- 
Bojan



From mharris at redhat.com  Thu Nov 17 03:59:05 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 16 Nov 2005 22:59:05 -0500
Subject: questions and issues about the modular X updates
In-Reply-To: <BAY103-F22BB9245FC4EB24BCCCA24DF5F0@phx.gbl>
References: <BAY103-F22BB9245FC4EB24BCCCA24DF5F0@phx.gbl>
Message-ID: <437C0009.4060807@redhat.com>

Jason Dravet wrote:

>> You can do that with any version of X, by calling xset from
>> ~/.Xclients or ~/.xinitrc, or one of the systemwide locations.
>>
> I saw the saw the setup for xset.  I was hoping for a cleaner solution.  
> For example IMO having a line in the xorg.conf file to control the caps 
> lock, scroll lock, and num lock would be the best solution.  It keeps 
> all of the configuration data together.  When I move to new version of 
> Fedora I format my hard drive and copy the data back from a usb thumb 
> drive.  Right now I have to copy back approximately 20 configuration 
> files and alot of odds and ends to get the system back to where it was 
> before I updated.  If there was a line in xorg to control the lock keys 
> then to get X back up and running I would only have to put the xorg.conf 
> back.  Right now I have put xorg.conf back, copy my mouse.sh file back, 
> and copy the numlock.sh file back.  Am I crazy for thinking 1 file is 
> better than 3?

If you would like to see future Xorg X server releases have such a
feature, please feel free to file a feature request into X.Org
bugzilla:

     http://bugs.freedesktop.org

You might also want to explore the existing options available in
the config file, as there might (or might not) be a way to do it
already.

Either way, it's an upstream X.Org issue, rather than an operating
system specific one.

>>>    2. When I did the yum update all of the xorg-x11-drv rpms 
>>> downloaded. This is 56 files several >>of which I don't need. I have 
>>> a Number nine Revolution IV video supported by the i128 package. >>I 
>>> don't need the cirrus, trident, s3, nv, etc packages, but I can't 
>>> uninstall them. I get
>>>
>>>
>> Yes, this is intentional.  The reasons for splitting the drivers out
>> into individual packages, was to:
>>
>> - make it very easy for us to release single driver updates
>>
>> - to drastically reduce the amount of downloading necessary to update
>>  a single driver
>>
>> - drastically reduce the disk space consumption and network bandwidth
>>  consumption for mirror sites as well as internal build machines
>>
>> - to make it easy to add new video drivers to a release without
>>  having to release a whole new 150Mb of X packages.
>>
> I agree this is a good thing.  Being able to release new drivers as soon 
> as they come out without having to respwan all of X is great.  My 
> concern is for bandwidth.  Looking at the xorg-x11-drv files there are 
> about 2.3MB of drivers.  This number is only going to go up as time goes 
> on and drivers are added and updated.

New drivers are a scarce commodity, as more and more hardware vendors
go the route of proprietary drivers.  There are about 70 driver
packages in total right now, with smaller numbers of them on a specific
architecture, because some are only shipped on a subset of all of the
architectures.  New drivers do not come forth very often, and at any
rate, we're talking about extremely small numbers here.  I don't think
it is fair to complain about really.  It's so insignificantly small that
it really doesn't matter.  You don't have to download 150Mb of
monolithic X anymore, be happy about it.  ;o)

If this is the biggest complaint about the new modular X, then I must
say I'm rather impressed.  Maybe I should go break something in the
next update, just to keep people on their toes. ;o)


> The idea about installing new 
> hardware and having yum or some other application go and download the 
> driver is good.  I agree that such functionality will not be here for 
> FC5.  If this is where things are going then I will shut up and download 
> everything.

/me whistles innocently


>> I believe they've been playing with this part of the code in Xorg CVS
>> lately, and that it might have gotten broken.  I think I saw some CVS
>> commits go in in the last few days related to button ordering, but I
>> don't remember the details.  My recommendation, is to post a message to
>> xorg lists freedesktop org about it for now, and see what feedback you
>> get back.  If it turns out it is a bug, and is not fixed in CVS, query
>> xorg bugzilla to see if someone has already reported it or not, and if
>> not, file a bug, and attach your X server config and log, and your
>> script to the report, and mark it blocking the release blocker
>> bug #1690
> 
> 
> You are correct there is a thread called ZAxisMapping causing trouble at 
> http://lists.freedesktop.org/archives/xorg/2005-November/date.html.  I 
> will keep checking the list for updates.
> 
> Thank you for the reply the information was very helpful.

Glad I could help. ;o)



From bojan at rexursive.com  Thu Nov 17 04:01:11 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 15:01:11 +1100
Subject: glxgears / glxinfo
In-Reply-To: <437BFE90.8070302@didntduck.org>
References: <437BFE90.8070302@didntduck.org>
Message-ID: <20051117150111.gohvzisuwysws0w8@imp.rexursive.com>

Quoting Brian Gerst <bgerst at didntduck.org>:

> Which package are glxgears/glxinfo hiding in now?  They used to be in 
> xorg-x11-tools.

I was wondering too. According to filelists.xml.gz, it is no longer there...

-- 
Bojan



From bgerst at didntduck.org  Thu Nov 17 04:22:51 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Wed, 16 Nov 2005 23:22:51 -0500
Subject: Modular X ramblings
Message-ID: <437C059B.8030001@didntduck.org>

- XFS didn't automatically restart, I had to manually start it.

- had to hand edit some paths in xorg.conf.  Still getting error on rgb 
file:
Couldn't open RGB_DB '/usr/lib/X11/rgb'

- scroll wheel on mouse wasn't working.  I had to comment out this from 
xorg.conf:
#       Option      "ZAxisMapping" "6 7"
#       Option      "Buttons" "7"
   wheel works now but thumb button does not.

- Nvidia driver works fine after putting files in the new locations

- glxinfo and glxgears are MIA.

- libXxf86dga.i386 doesn't exist in the x86_64 tree, had to grab it from 
i386.

- cedega / World of Warcraft is working.  Life is good again. =)

--
				Brian Gerst



From katzj at redhat.com  Thu Nov 17 04:28:17 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 16 Nov 2005 23:28:17 -0500
Subject: Modular X ramblings
In-Reply-To: <437C059B.8030001@didntduck.org>
References: <437C059B.8030001@didntduck.org>
Message-ID: <1132201697.23115.2.camel@orodruin.boston.redhat.com>

On Wed, 2005-11-16 at 23:22 -0500, Brian Gerst wrote:
> - XFS didn't automatically restart, I had to manually start it.

There's a change to attempt to handle this automatically that should be
in tomorrow's tree (not that it will help you now ;-)

> - libXxf86dga.i386 doesn't exist in the x86_64 tree, had to grab it from 
> i386.

This should be there tomorrow

Jeremy



From bojan at rexursive.com  Thu Nov 17 04:40:07 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 15:40:07 +1100
Subject: nv (open source) driver v. two heads on one card
Message-ID: <20051117154007.5k8ykx8b7oo8w8ko@imp.rexursive.com>

Just out of curiosity, I went through the:

http://wiki.x.org/wiki/ChangesSince68

and it mentions:

- Updates to nv(4) driver from XFree86 and nVIDIA

I went through the source of the driver briefly (not that I would 
understand any of it :-) and there is a mention of twoHeads in heaps of 
places, so I'm hoping...

Does anyone know if this open source driver now supports two heads on 
one card (e.g. Quadro 280 PCI and similar) like its close source 
counterpart does?

-- 
Bojan



From mharris at redhat.com  Thu Nov 17 06:32:43 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 01:32:43 -0500
Subject: glxgears / glxinfo
In-Reply-To: <437BFE90.8070302@didntduck.org>
References: <437BFE90.8070302@didntduck.org>
Message-ID: <437C240B.1010107@redhat.com>

Brian Gerst wrote:
> Which package are glxgears/glxinfo hiding in now?  They used to be in 
> xorg-x11-tools.

They um...   don't exist. ;)

They are part of Mesa, but not part of MesaLib.  I think they're in
Mesa-demos, which we don't ship.

File a bug in RH bugzilla, and we'll make sure to add those back.

TIA



From rc040203 at freenet.de  Thu Nov 17 06:35:56 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 17 Nov 2005 07:35:56 +0100
Subject: Modular X: libXext headers missing
Message-ID: <1132209357.5616.25.camel@mccallum.corsepiu.local>

Hi,

What has happened to libXext's headers in "modular X"?

libXext-devel-0.99.2-1.i386.rpm doesn't contain any headers, nor can't I
find them elsewhere.

Ralf






From ivazquez at ivazquez.net  Thu Nov 17 06:44:15 2005
From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams)
Date: Thu, 17 Nov 2005 01:44:15 -0500
Subject: Modular X: libXext headers missing
In-Reply-To: <1132209357.5616.25.camel@mccallum.corsepiu.local>
References: <1132209357.5616.25.camel@mccallum.corsepiu.local>
Message-ID: <1132209855.20398.6.camel@ignacio.lan>

On Thu, 2005-11-17 at 07:35 +0100, Ralf Corsepius wrote:
> What has happened to libXext's headers in "modular X"?
> 
> libXext-devel-0.99.2-1.i386.rpm doesn't contain any headers, nor can't I
> find them elsewhere.

Did you try xorg-x11-proto-devel?

-- 
Ignacio Vazquez-Abrams <ivazquez at ivazquez.net>
http://fedora.ivazquez.net/

gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/5792533b/attachment.sig>

From mharris at redhat.com  Thu Nov 17 06:55:06 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 01:55:06 -0500
Subject: Modular X ramblings
In-Reply-To: <437C059B.8030001@didntduck.org>
References: <437C059B.8030001@didntduck.org>
Message-ID: <437C294A.1020903@redhat.com>

Brian Gerst wrote:
> - XFS didn't automatically restart, I had to manually start it.

The xfs rpm scripts have been updated recently with many changes.  One
of the changes, was to have it check to see if it is upgrading from
monolithic X to modular X or not, and if it is, to force a "restart"
in the initscript.  If it is just modular to modular, then it does
a "reload" instead.

It's possible the script is buggy though. It hasn't had a lot of testing
yet.  Also, I'm open to suggestions for how to improve the "upgrade
xfs package" situation.  Here are some concerns to consider:

1) When xfs is restarted, the connection with the X server is broken,
    so apps using core fonts can no longer find fonts.  While xset can
    be used theoretically to re-establish a link to the X server, the
    initscript has no idea wether the X server is :0, :1, :8, or all 3.
    There is no "clean" way to have the connection re-established.

2) Using "reload" causes it to reload the config file instead of
    restarting, but then you are still using the old xfs server, not
    the new one.  Also, the old one is unable to find it's config file
    after upgrade, so must be restarted anyway.

3) If an xfs security update goes out, the way things are now, you have
    to manually restart xfs, as it wont get restarted otherwise.  That is
    kindof bad, but it's the way it is right now to avoid disconnecting
    xfs from the X server.

I'm open to hear suggestions if anyone has some for how we can solve
these problems.

One thing I'd like to address before anyone does respond with
suggestions though ...

When these type of problems arise with xfs, inevitably someone will
eventually say "get rid of xfs, and just use the X server to serve
the fonts directly and the problem is solved".  While that sounds
very attractive in a once sentence email or IRC statement, in the
real world, there are hundreds of thousands of deployed systems out
there, and migrating away from xfs to using the X server would have
to be performed rather smoothly on OS upgrades.  Getting the
nuances of that correct is more complicated than one might think.

Also, chkfontpath currently configures the fontpaths into the xfs
font server, and does not have any logic to do this with the X
server.  We would _have_ to update chkfontpath to be able to handle
the X server as well, yet still be able to do it with xfs for
systems out there that _do_ want to still use xfs.  So ultimately,
we still end up supporting xfs, only we now have to re-engineer
a bunch of legacy code (chkfontpath) which is rather fragile to
begin with, and make everything work without breaking systems
out there beyond recognition.

Even if we were to do this, we do not really gain any new
functionality at all, despite how much effort would be put into
implementing and testing it all.  Also, we would be changing
something that more or less "just works" most of the time, and
has been done this way for 8 years or more.  Making such a change
with no real visible gains is a big waste of time, energy and
manpower that would be taken away from other possible projects
that could have been done instead, which have real world benefits.

The reason I'm going into this level of detail in this email, is
more or less to cut the conversation off before it starts, as it
comes up every time xfs problems are mentioned, and the bottom
line never changes.  xfs is a necessity that we have to live with,
so we have to fix it if it breaks, as that is the least costly
way to keep core fonts support working.

</diatribe> ;o)


> - had to hand edit some paths in xorg.conf.  Still getting error on rgb 
> file:
> Couldn't open RGB_DB '/usr/lib/X11/rgb'

Already in bugzilla.

> - scroll wheel on mouse wasn't working.  I had to comment out this from 
> xorg.conf:
> #       Option      "ZAxisMapping" "6 7"
> #       Option      "Buttons" "7"
>   wheel works now but thumb button does not.

Known bug upstream, will be fixed probably in RC3.

> - Nvidia driver works fine after putting files in the new locations

Crap, I'll have to try to break it some other way then.  ;o)

> - glxinfo and glxgears are MIA.

Someone else mentioned already, but not in bugzilla yet.

> - libXxf86dga.i386 doesn't exist in the x86_64 tree, had to grab it from 
> i386.

Hmm. Sounds like a release engineering issue.  Not sure what to
recommend, other than screaming and shouting until someone fixes it. ;)

> - cedega / World of Warcraft is working.  Life is good again. =)

_wow_

I'm surprised that level of functionality is working.  I'm not giving
you guys enough broken stuff to test I guess.  ;o)

/me goes to find something to break



From rc040203 at freenet.de  Thu Nov 17 06:58:12 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Thu, 17 Nov 2005 07:58:12 +0100
Subject: Modular X: libXext headers missing
In-Reply-To: <1132209855.20398.6.camel@ignacio.lan>
References: <1132209357.5616.25.camel@mccallum.corsepiu.local>
	<1132209855.20398.6.camel@ignacio.lan>
Message-ID: <1132210692.5616.29.camel@mccallum.corsepiu.local>

On Thu, 2005-11-17 at 01:44 -0500, Ignacio Vazquez-Abrams wrote:
> On Thu, 2005-11-17 at 07:35 +0100, Ralf Corsepius wrote:
> > What has happened to libXext's headers in "modular X"?
> > 
> > libXext-devel-0.99.2-1.i386.rpm doesn't contain any headers, nor can't I
> > find them elsewhere.
> 
> Did you try xorg-x11-proto-devel?

It's not in libXext-devel "Requires:"

# rpm -q --requires -p libXext-devel-0.99.2-1.i386.rpm
libXext = 0.99.2-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1

nor are Xdbe.h, multibuf.h, shape.h (some random headers from libXext)
provided by it.

Ralf




From mharris at redhat.com  Thu Nov 17 06:58:34 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 01:58:34 -0500
Subject: nv (open source) driver v. two heads on one card
In-Reply-To: <20051117154007.5k8ykx8b7oo8w8ko@imp.rexursive.com>
References: <20051117154007.5k8ykx8b7oo8w8ko@imp.rexursive.com>
Message-ID: <437C2A1A.20303@redhat.com>

Bojan Smojver wrote:
> Just out of curiosity, I went through the:
> 
> http://wiki.x.org/wiki/ChangesSince68
> 
> and it mentions:
> 
> - Updates to nv(4) driver from XFree86 and nVIDIA
> 
> I went through the source of the driver briefly (not that I would 
> understand any of it :-) and there is a mention of twoHeads in heaps of 
> places, so I'm hoping...
> 
> Does anyone know if this open source driver now supports two heads on 
> one card (e.g. Quadro 280 PCI and similar) like its close source 
> counterpart does?

The "nv" driver does not support both heads of multihead cards, however
you can use an nvidia card in conjunction with another video card
(which can also be an nvidia card) to do dualhead over multiple
cards.

On the upside of things, there is a new developer from Nvidia who is
now working on the "nv" driver directly in the X.Org source tree, and
he has CVS write access, so hopefully the driver will be kept fairly
up to date.  Maybe if we're really lucky they might improve the
driver to support things like dualhead on one card, but I wouldn't
hold your breath. ;o)

Baby steps!



From avi at argo.co.il  Thu Nov 17 07:02:08 2005
From: avi at argo.co.il (Avi Kivity)
Date: Thu, 17 Nov 2005 09:02:08 +0200
Subject: init observations
In-Reply-To: <20051115221629.GF1003315@hiwaay.net>
References: <20051115204405.GA18220@lewk.org>	<2599004567060172327E6DED@[10.169.6.233]>	<437A5419.8000204@argo.co.il>
	<20051115213838.GD1003315@hiwaay.net>	<437A58FF.5050709@argo.co.il>
	<20051115221629.GF1003315@hiwaay.net>
Message-ID: <437C2AF0.5040301@argo.co.il>

Chris Adams wrote:

>Once upon a time, Avi Kivity <avi at argo.co.il> said:
>  
>
>>We require /. We require initrd.
>>    
>>
>
>initrd is not currently required.  It is for out-of-the-box setups, but
>you can:
>
>a) not use LVM for root
>b) not use ext3 for root or rebuild kernel with ext3 included
>c) use hardware that doesn't require modules for root device or rebuild
>   kernel with drivers included
>
>  
>
seems very close to "required" to me.

>>I'm sure we can arrange initrd to look at the command line. For example:
>>
>> mount=/=server1:/path/to/root,/usr=server2:/path/to/usr
>>
>>IP can already be configured this way.
>>    
>>
>
>That's a pretty ugly hack just to get python support for startup.
>
It's not just for python; it's to avoid dependency on a very small 
subset of functionaly present in /bin and /sbin. For flexibility.

>  Also,
>that is limited; the kernel command line has a limit that isn't all that
>big.
>
This limit is going away.

>  You also then need to handle fsck and such in initrd for
>non-network filesystems.
>
>  
>
This can be handled in the same way that fsck / is done.

The point is that we have two (well, more, but in this context just two) 
bootstrap sequences: initrd -> / and / -> rest of world. the first 
bootstrap does not leave permanent effects, but the second does, and 
these hurt. Eliminating the second stage would simplify the system and 
open the door for many improvements.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From ellson at research.att.com  Thu Nov 17 06:16:35 2005
From: ellson at research.att.com (John Ellson)
Date: Thu, 17 Nov 2005 01:16:35 -0500
Subject: Modular X
In-Reply-To: <437BD91B.3050404@zoeloelip.be>
References: <437BD91B.3050404@zoeloelip.be>
Message-ID: <437C2043.1090302@research.att.com>

Bart Vanbrabant wrote:
> Hello,
> 
> I just installed the new modular X from rawhide. Everything went quite
> good except for two problems:
> 
> 1) The nvidia driver doesn't handle modular X yet. But I solved it by
> manually moving all libraries to their new places. This isn't something
> that should be handled by fedora.

Could you provide more details please?       I tried a few mv's too but 
mine didn't work.

John



From daner964 at student.liu.se  Thu Nov 17 07:23:05 2005
From: daner964 at student.liu.se (Daniel Malmgren)
Date: Thu, 17 Nov 2005 08:23:05 +0100
Subject: Initng rpm in Fedora extras
Message-ID: <f8ea87aa1ebba.1ebbaf8ea87aa@liu.se>

Hi.
Rahul hinted me about it being a good idea to post a bugzilla bug to get
help getting initng rpm into Fedora extras. I'm sorry for the delay
(I've been away), but now the bug is there, and I hope it's in the right
place ;-)

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459

/Daniel



From sundaram at redhat.com  Thu Nov 17 07:26:08 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Thu, 17 Nov 2005 12:56:08 +0530
Subject: Initng rpm in Fedora extras
In-Reply-To: <f8ea87aa1ebba.1ebbaf8ea87aa@liu.se>
References: <f8ea87aa1ebba.1ebbaf8ea87aa@liu.se>
Message-ID: <437C3090.7090700@redhat.com>

Daniel Malmgren wrote:

>Hi.
>Rahul hinted me about it being a good idea to post a bugzilla bug to get
>help getting initng rpm into Fedora extras. I'm sorry for the delay
>(I've been away), but now the bug is there, and I hope it's in the right
>place ;-)
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459
>
>/Daniel
>  
>
Great. If you need more information on the process, see 
http://fedoraproject.org/wiki/Extras. If you require any clarifications, 
kindly post to the fedora-extras list or ask in #fedora-extras.


regards
Rahul



From petro at mail.ru  Thu Nov 17 07:49:24 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Thu, 17 Nov 2005 10:49:24 +0300
Subject: Xaw3d needs rebuild due to modular X
Message-ID: <Pine.LNX.4.64.0511171048390.2971@lemenkov.com>

Hello, All!

=====================

[root at Petro lib]# rpm -ql Xaw3d
/usr/X11R6/lib/libXaw3d.so.7
/usr/X11R6/lib/libXaw3d.so.7.0

=====================

-- 
With best regards, Peter Lemenkov.




From bojan at rexursive.com  Thu Nov 17 08:13:16 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 19:13:16 +1100
Subject: Modular X
In-Reply-To: <437BD91B.3050404@zoeloelip.be>
References: <437BD91B.3050404@zoeloelip.be>
Message-ID: <1132215196.27296.0.camel@coyote.rexursive.com>

On Thu, 2005-11-17 at 02:12 +0100, Bart Vanbrabant wrote:

>         RgbPath      "/usr/share/X11/rgb"

Shouldn't this be /usr/lib/X11/rgb?

-- 
Bojan



From mharris at redhat.com  Thu Nov 17 09:00:40 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 04:00:40 -0500
Subject: Modular X 101 : Debugging modular X
Message-ID: <437C46B8.6060409@redhat.com>

Did you know, that all of the modular X packages now come with
full debuginfo packages, including the X server and driver modules?

The X server uses dlopen now also, so it can be debugged using
the stock gdb that comes with Fedora.

In order to debug the running X server, install the debuginfo
packages for it, and any drivers you are loading.  You then
need to have 2 computers[1] networked together, or using a serial
port or some other remote access method.

Edit the xorg.conf file, and enable the option:

     Option "NoTrapSignals"

Then, enable coredumps on the system, if you have not done so
already, by using "ulimit -c unlimited" in a script dropped into
/etc/profile.d/enable-coredumps.sh  or whatever.  Be sure to run
the script or log out and back in.

As the X server is a setuid root process, and the kernel will not
allow coredumps of SUID processes by default, you have 2 choices.

You can tweak the kernel to permit SUID coredumps by doing:

     echo 1 > /proc/sys/kernel/core_setuid_ok

or you can run the X server as root.  If you enable the kernel to
allow SUID coredumps as per above, just be sure to disable it
afterwards by echoing '0' to the same file, to avoid potential
security issues.

Now you are ready to break things and debug them.  I prefer to
start the X server with "startx" all the time, but particularly
when debugging.  I recommend doing the same, unless the problem
you are debugging only occurs when using gdm/kdm/xdm, as it tends
to be much simpler to debug with startx.  YMMV however.

If the server crashes, you can gdb the coredump now.  Assuming
you installed debuginfo packages for the server (make sure the
debuginfo package is the same version-release as the server that
is installed), you should get useful backtraces, etc.

If you want to debug the running server, single step it, etc.,
you need the second computer[1] mentioned above.  Do all the same
steps as above, but this time, ssh in from the remote computer
(or use minicom on serial port or whatever), and get the PID
of the X server with 'pidof X'.  Then attach gdb to the X server:

     gdb --pid=$(pidof X)

Now go to town!  Find the bug, install the X server/driver sources,
fix the bug, generate a patch with gendiff, and attach it to a bug
report.  It's really that simple!!!  ;oP

This informative message has been brought to you by the Red Hat
X Development team, and Frank's Red Hot Chile & Lime Hot Sauce.

Have fun!


[1] The reason that 2 computers are required, is that if you start
the X server, open an xterm and run gdb on the running X server,
gdb will stop the X server, and try to print to stdout.  Since
stdout is your xterm, and xterm is displaying to the X server which
is now no longer responding because gdb stopped it, you are screwed.
It's kindof like trying to stand on a carpet, and then pull it out
from under yourself.  You can't really do it.  This is why you
need[2] 2 computers.

[2] Ok, it is technically possible to do it with one computer too,
but it is complex enough to not really bother trying to do, so
don't even waste time thinking of it.  If you don't have 2
computers, go dumpster diving at 3am in the garbage dumpster of
a computer store.  They throw out good stuff I'm told, and you
can have a "X server debugging terminal" in no time, like everyone
else on the block.  Alternatively, surf ebay.com for a bargain, or
hang out at a computer recycling shop.


Note: Please feel free to forward this message on to other people
or mailing lists, or to copy or paraphrase into wiki pages or other
helpful resources if you think other formats or people would
benefit from this info.



From mharris at redhat.com  Thu Nov 17 09:15:13 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 04:15:13 -0500
Subject: Modular X
In-Reply-To: <1132215196.27296.0.camel@coyote.rexursive.com>
References: <437BD91B.3050404@zoeloelip.be>
	<1132215196.27296.0.camel@coyote.rexursive.com>
Message-ID: <437C4A21.10505@redhat.com>

Bojan Smojver wrote:
> On Thu, 2005-11-17 at 02:12 +0100, Bart Vanbrabant wrote:
> 
> 
>>        RgbPath      "/usr/share/X11/rgb"
> 
> 
> Shouldn't this be /usr/lib/X11/rgb?

rgb.txt is an architecture independent ASCII text data file.

/usr/share is for architecture independent data files, so the
proper location would be /usr/share/X11.  This change will
happen in a future update sometime soon.



From billcrawford1970 at gmail.com  Thu Nov 17 09:31:30 2005
From: billcrawford1970 at gmail.com (Bill Crawford)
Date: Thu, 17 Nov 2005 09:31:30 +0000
Subject: Modular X: libXext headers missing
In-Reply-To: <1132210692.5616.29.camel@mccallum.corsepiu.local>
References: <1132209357.5616.25.camel@mccallum.corsepiu.local>	<1132209855.20398.6.camel@ignacio.lan>
	<1132210692.5616.29.camel@mccallum.corsepiu.local>
Message-ID: <437C4DF2.3000209@googlemail.com>

Ralf Corsepius wrote:
> It's not in libXext-devel "Requires:"
>
> # rpm -q --requires -p libXext-devel-0.99.2-1.i386.rpm
> libXext = 0.99.2-1
> rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>
> nor are Xdbe.h, multibuf.h, shape.h (some random headers from libXext)
> provided by it.
>
>
>   
 They're all in xorg-x11-proto-devel as already mentioned.

http://bugzilla.redhat.com/



From chris at allset.nl  Thu Nov 17 09:32:17 2005
From: chris at allset.nl (Chris Chabot)
Date: Thu, 17 Nov 2005 10:32:17 +0100
Subject: Modular X
In-Reply-To: <437C4A21.10505@redhat.com>
References: <437BD91B.3050404@zoeloelip.be>
	<1132215196.27296.0.camel@coyote.rexursive.com>
	<437C4A21.10505@redhat.com>
Message-ID: <1132219937.516.4.camel@cch>

Odd behaviour i had on my laptop (which is fully up to date, or should i
say yummed :-)). When the RgbPath is "broken" (pointing
to /usr/X11R6/....) my xterm works perfectly, however if i 'fix' the rgb
path to point to /usr/share/X11/rgb, xterm gets white borders and the
text is invisible..

I do have something of a custom XTerm / XTerm-color in app-defaults
with:
*VT100*colorMode: on
*VT100*boldColors: on
*VT100*dynamicColors: on
*VT100*color0: black
*VT100*color1: red3
*VT100*color2: green3
*VT100*color3: yellow3
*VT100*color4: blue3
*VT100*color5: magenta3
*VT100*color6: cyan3
*VT100*color7: gray90
*VT100*color8: gray30
*VT100*color9: red
*VT100*color10: green
*VT100*color11: yellow
*VT100*color12: blue
*VT100*color13: magenta
*VT100*color14: cyan
*VT100*color15: white
*VT100*colorUL: green4
*VT100*colorBD: blue3

But that shouldn't break it should it? Worked well with xorg 6.8.x.. And
when i comment out the Rgb path it works well again. Odd behaviour :-)

On Thu, 2005-11-17 at 04:15 -0500, Mike A. Harris wrote:

> Bojan Smojver wrote:
> > On Thu, 2005-11-17 at 02:12 +0100, Bart Vanbrabant wrote:
> > 
> > 
> >>        RgbPath      "/usr/share/X11/rgb"
> > 
> > 
> > Shouldn't this be /usr/lib/X11/rgb?
> 
> rgb.txt is an architecture independent ASCII text data file.
> 
> /usr/share is for architecture independent data files, so the
> proper location would be /usr/share/X11.  This change will
> happen in a future update sometime soon.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/2141c20c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-3.png
Type: image/png
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/2141c20c/attachment.png>

From bart.vanbrabant at zoeloelip.be  Thu Nov 17 09:41:10 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Thu, 17 Nov 2005 10:41:10 +0100
Subject: Modular X
In-Reply-To: <437BF477.6000607@redhat.com>
References: <437BD91B.3050404@zoeloelip.be> <437BF477.6000607@redhat.com>
Message-ID: <437C5036.30002@zoeloelip.be>

Mike A. Harris wrote:
> Bart Vanbrabant wrote:
>> Hello,
>>
>> I just installed the new modular X from rawhide. Everything went quite
>> good except for two problems:
>>
>> 1) The nvidia driver doesn't handle modular X yet. But I solved it by
>> manually moving all libraries to their new places. This isn't something
>> that should be handled by fedora.
>
> I believe Nvidia provides a driver that works with the dlopen loader
> used in modular X.  I'm not sure how it is provided exactly, but
> hopefully the livna.org nvidia rpms will update to using the new
> driver, and move things to the new locations.
>
>> 2) There were two paths in my xorg.conf that pointed to the old /usr/X11
>> places. Those where ModulePath and RgbPath. I changed them like this:
>>         RgbPath      "/usr/share/X11/rgb"
>>         ModulePath   "/usr/lib/xorg/modules"
>
> Aha!  Good catch!  Please file these in bugzilla.  I'll have to massage
> our X server installation to remove these lines from the config, and get
> our config tools changed to stop writing out unnecessary lines to the
> config file as it ends up breaking future X changes down the line.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173465
>
>> It this something that other users could have problems with to? Because
>> then a postinstall script should check for this. Do I need to file a
>> bugreport?
>
> Yes definitely, please do!  Thanks very much for testing, and for the
> reports too!
>
No problem.

Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/3b89d33c/attachment.sig>

From gilboada at netvision.net.il  Thu Nov 17 09:52:21 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Thu, 17 Nov 2005 11:52:21 +0200
Subject: init: API
In-Reply-To: <043301c5eacf$dbba0ba0$b6491b31@td612671>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
Message-ID: <1132221141.29504.9.camel@gilboa-work-dev>

On Wed, 2005-11-16 at 12:04 -0500, Dimi Paun wrote:
> Folks,
> 
> Since we are discussing a new init replacement, I think
> we should consider a good API for it too, so that it services
> can be controlled programmatically. At the very least, we
> need to be able to:
>   * start/stop/reload/restart a service
>   * query its status
>   * wait for a service to start/stop
>   * a way for services to interact with the administrators
>     (for example to ask for passphrases, etc.)
>   * a way to signal problems (probably D-BUS bases)
> 
> I know this is blasphemy, but how about we start (at least
> for inspiration) with the Services API from Win32:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/service_functions.asp
> 
> For more info about Win32 services:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/services.asp
> 
> At the very least looking at other APIs will tell us:
>   * what we need to cover
>   * what we should avoid
> 
> What other APIs are out there? Does Sun have one?
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 

Just to add my 2c worth.
I wrote a large number of WinNT/2K services and from my experience, it's
the last system we'd want to duplicate.
Here's why:
A. ServiceManager needs a separate Main and Signal handling code.
(Forcing us to modify each and every service we want to run.)
B. If you decided not to modify the service itself, and use the generic
service system (AKA svchost.exe), you lose the ability to monitor the
health of the services. (Or heck, even know what service runs behind
srvhost.exe)
C. Non-integrated event-logging mechanism. (In Windows you're forced to
use the event-log; it doesn't capture the stdio/stderr output, again
forcing you to add code to the service itself.)
D. No built-in support for automated auto-service-restart.
E. *Very* limited service dependency management. 

And last, more important then all.
F. All ServiceManager interaction must be done using the service
code; /Very/ limited shell support. (net start/stop service_name).

In short, I'd stay clear of Windows ServiceManager as a reference.
Gilboa



From clovis at agr.unicamp.br  Thu Nov 17 10:02:07 2005
From: clovis at agr.unicamp.br (Clovis Tristao)
Date: Thu, 17 Nov 2005 08:02:07 -0200
Subject: Mplayer and Kaffeine install
Message-ID: <437C551F.1030708@agr.unicamp.br>

Hi,

I am trying to install the Mplayer and Kaffeine, using command "yum 
install", but it appears the message below: 

# yum install mplayer
Setting up Update Process
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
livna                     100% |=========================|  951 B    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
--> Processing Dependency: libdirectfb-0.9.so.22 for package: mplayer
--> Finished Dependency Resolution
Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
mplayer

# yum install kaffeine
Setting up Update Process
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
livna                     100% |=========================|  951 B    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
--> Finished Dependency Resolution
Error: Missing Dependency: libMagick.so.6 is needed by package xine-lib
Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
xine-lib
Error: Missing Dependency: libgs.so.7 is needed by package xine-lib
Error: Missing Dependency: libfusion-0.9.so.22 is needed by package xine-lib
Error: Missing Dependency: libdirect-0.9.so.22 is needed by package xine-lib
Error: Missing Dependency: libWand.so.6 is needed by package xine-lib

What it can be happening? 
I am using Fedora Core with kernel 2.6.14-1.1651_FC5

Cl?vis

-- 
Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola
Administrador de Redes - Secao de Informatica (SINFO)
E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br
Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010



From bojan at rexursive.com  Thu Nov 17 10:40:28 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 21:40:28 +1100
Subject: Modular X
In-Reply-To: <437C4A21.10505@redhat.com>
References: <437BD91B.3050404@zoeloelip.be>
	<1132215196.27296.0.camel@coyote.rexursive.com>
	<437C4A21.10505@redhat.com>
Message-ID: <1132224028.27296.2.camel@coyote.rexursive.com>

On Thu, 2005-11-17 at 04:15 -0500, Mike A. Harris wrote:

> rgb.txt is an architecture independent ASCII text data file.
> 
> /usr/share is for architecture independent data files, so the
> proper location would be /usr/share/X11.  This change will
> happen in a future update sometime soon.

That's cool, thanks. I was just referring to the current situation.

-- 
Bojan



From bojan at rexursive.com  Thu Nov 17 10:43:26 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 21:43:26 +1100
Subject: nv (open source) driver v. two heads on one card
In-Reply-To: <437C2A1A.20303@redhat.com>
References: <20051117154007.5k8ykx8b7oo8w8ko@imp.rexursive.com>
	<437C2A1A.20303@redhat.com>
Message-ID: <1132224207.27296.5.camel@coyote.rexursive.com>

On Thu, 2005-11-17 at 01:58 -0500, Mike A. Harris wrote:

> On the upside of things, there is a new developer from Nvidia who is
> now working on the "nv" driver directly in the X.Org source tree, and
> he has CVS write access, so hopefully the driver will be kept fairly
> up to date.  Maybe if we're really lucky they might improve the
> driver to support things like dualhead on one card, but I wouldn't
> hold your breath. ;o)

Or, if we are really, really, _really_ lucky, they may actually release
the proprietary driver under an open source licence ;-)

-- 
Bojan



From bojan at rexursive.com  Thu Nov 17 10:58:41 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 17 Nov 2005 21:58:41 +1100
Subject: xmkmf in modular X
Message-ID: <1132225121.27296.13.camel@coyote.rexursive.com>

Just a quick one related to generation of files with xmkmf. It seems to
want to run imake like this:

-------------------------
imake -DUseInstalled -I/usr/lib/X11/config
Imakefile.c:34: error: Imake.tmpl: No such file or directory
imake: Exit code 1.
-------------------------

The file in question is actually here: /usr/share/X11/config/Imake.tmpl

The Imakefile looks like this:

-------------------------
        DEPLIBS = $(DEPXXF86VMLIB) XawClientDepLibs
LOCAL_LIBRARIES = $(XXF86VMLIB) XawClientLibs
           SRCS = xbrightness.c
           OBJS = xbrightness.o

ComplexProgramTarget(xbrightness)
-------------------------

Not exactly sure what went wrong...

PS. I'm trying to build xbrightness RPM. If you need the spec file, I
can shoot that over too.

-- 
Bojan



From rodd at clarkson.id.au  Thu Nov 17 11:41:14 2005
From: rodd at clarkson.id.au (Rodd Clarkson)
Date: Thu, 17 Nov 2005 22:41:14 +1100
Subject: Modular X
In-Reply-To: <437BD91B.3050404@zoeloelip.be>
References: <437BD91B.3050404@zoeloelip.be>
Message-ID: <1132227675.3539.5.camel@localhost.localdomain>

On Thu, 2005-11-17 at 02:12 +0100, Bart Vanbrabant wrote:
> Hello,
> 
> I just installed the new modular X from rawhide. Everything went quite
> good except for two problems:
> 
> 1) The nvidia driver doesn't handle modular X yet. But I solved it by
> manually moving all libraries to their new places. This isn't something
> that should be handled by fedora.
> 
> 2) There were two paths in my xorg.conf that pointed to the old /usr/X11
> places. Those where ModulePath and RgbPath. I changed them like this:
>         RgbPath      "/usr/share/X11/rgb"
>         ModulePath   "/usr/lib/xorg/modules"
> It this something that other users could have problems with to? Because
> then a postinstall script should check for this. Do I need to file a
> bugreport?

As an nvidia user I've followed Bart's suggestions after having no luck
getting my card to work with the nv driver.  (I've been using nvidia
anyway (from livna) but was willing to accept that the nvidia drivers
might be buggered for some time).

Anyhoo, I've got my desktop running at something better than 640x480
(the best I could get with the nv drivers) which is great since I've got
an 1920x1200 screen.

It now appears that I'm running 1920x1200, but my gnome desktop is only
using 1600x1200 and this is the best resolution it will give me using
System > Preferences > Screen Resolution.

Options avaiable include:

1600x1200
1400x1050
1280x960
1280x1024
1024x768
800x600
640x480

In my xorg.conf file I have:

Section "Monitor"
        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "LCD Panel 1920x1200"
        HorizSync    31.5 - 90.0
        VertRefresh  60.0 - 60.0
        Option      "dpms"
EndSection

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        VendorName  "Videocard vendor"
        BoardName   "NVIDIA Unknown (generic)"
EndSection

Section "Screen"
        Identifier "Screen0"
        Device     "Videocard0"
        Monitor    "Monitor0"
        DefaultDepth     16
        SubSection "Display"
                Viewport   0 0
                Depth     16
                Modes    "1920x1200" "1920x1440" "1680x1050" "1600x1200"
"1400x1050" "1280x960" "1280x800" "1280x1024" "1152x864" "1024x768"
"800x600" "640x480"        EndSubSection
EndSection

Why isn't 1920x1200 (and other resolutions) showing in the list?


Rodd

-- 
"It's a fine line between denial and faith.
 It's much better on my side"



From mrsam at courier-mta.com  Thu Nov 17 11:53:58 2005
From: mrsam at courier-mta.com (Sam Varshavchik)
Date: Thu, 17 Nov 2005 06:53:58 -0500
Subject: xmkmf in modular X
References: <1132225121.27296.13.camel@coyote.rexursive.com>
Message-ID: <cone.1132228438.643301.31469.500@commodore.email-scan.com>

Bojan Smojver writes:

> Just a quick one related to generation of files with xmkmf. It seems to
> want to run imake like this:

I doubt that anyone really wants to waste time on xmkmf anymore.  The rest 
of the world moved to autoconf and automake.

> PS. I'm trying to build xbrightness RPM. If you need the spec file, I
> can shoot that over too.

Sounds like "xbrightness" is ancient code that nobody's maintaining any 
more.

If you can't find a more recent version, based on autoconf and automake, 
you'll just have to write one up yourself, I suppose.

-------------- 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/20051117/cec4d8e5/attachment.sig>

From j.w.r.degoede at hhs.nl  Thu Nov 17 12:44:44 2005
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Thu, 17 Nov 2005 13:44:44 +0100
Subject: Mplayer and Kaffeine install
In-Reply-To: <437C551F.1030708@agr.unicamp.br>
References: <437C551F.1030708@agr.unicamp.br>
Message-ID: <437C7B3C.8060603@hhs.nl>

Clovis Tristao wrote:
> Hi,
> 
> I am trying to install the Mplayer and Kaffeine, using command "yum 
> install", but it appears the message below:
> # yum install mplayer
> Setting up Update Process
> Setting up repositories
> development               100% |=========================| 1.1 kB    00:00
> livna                     100% |=========================|  951 B    00:00
> extras-development        100% |=========================| 1.1 kB    00:00
> Reading repository metadata in from local files
> --> Processing Dependency: libdirectfb-0.9.so.22 for package: mplayer
> --> Finished Dependency Resolution
> Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
> mplayer
> 
> # yum install kaffeine
> Setting up Update Process
> Setting up repositories
> development               100% |=========================| 1.1 kB    00:00
> livna                     100% |=========================|  951 B    00:00
> extras-development        100% |=========================| 1.1 kB    00:00
> Reading repository metadata in from local files
> --> Finished Dependency Resolution
> Error: Missing Dependency: libMagick.so.6 is needed by package xine-lib
> Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
> xine-lib
> Error: Missing Dependency: libgs.so.7 is needed by package xine-lib
> Error: Missing Dependency: libfusion-0.9.so.22 is needed by package 
> xine-lib
> Error: Missing Dependency: libdirect-0.9.so.22 is needed by package 
> xine-lib
> Error: Missing Dependency: libWand.so.6 is needed by package xine-lib
> 
> What it can be happening? I am using Fedora Core with kernel 
> 2.6.14-1.1651_FC5
> 
> Cl?vis
> 

Assuming you're running rawhide, the fbdirect problem is because of:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168343

I'm working on this, but the fix uses directfb-0.9.24 which will provide 
.so.24, so this will require a rebuild of the livna packages, a local 
one sinc elivna doesn't support rawhide.

Regards,

Hans




From mharris at redhat.com  Thu Nov 17 12:49:40 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 07:49:40 -0500
Subject: xmkmf in modular X
In-Reply-To: <1132225121.27296.13.camel@coyote.rexursive.com>
References: <1132225121.27296.13.camel@coyote.rexursive.com>
Message-ID: <437C7C64.6080207@redhat.com>

Bojan Smojver wrote:
> Just a quick one related to generation of files with xmkmf. It seems to
> want to run imake like this:
> 
> -------------------------
> imake -DUseInstalled -I/usr/lib/X11/config
> Imakefile.c:34: error: Imake.tmpl: No such file or directory
> imake: Exit code 1.
> -------------------------
> 
> The file in question is actually here: /usr/share/X11/config/Imake.tmpl
> 
> The Imakefile looks like this:
> 
> -------------------------
>         DEPLIBS = $(DEPXXF86VMLIB) XawClientDepLibs
> LOCAL_LIBRARIES = $(XXF86VMLIB) XawClientLibs
>            SRCS = xbrightness.c
>            OBJS = xbrightness.o
> 
> ComplexProgramTarget(xbrightness)
> -------------------------
> 
> Not exactly sure what went wrong...
> 
> PS. I'm trying to build xbrightness RPM. If you need the spec file, I
> can shoot that over too.

General advice for imake related problems:

Small apps like that, in general should be easy to transition over from
Imake to GNU autotools.  That is my own personal strong recommendation
to upstream projects, as the imake build system is going to die a quick
death most likely, since X no longer uses it.

For the time being however, X does still provide imake, but that will
probably change in another release or two, since it is just dead code
no longer used by X itself.


For this specific problem:

It is probably a glitch in the new imake package.  If you can confirm
that, please file a bug in Red Hat bugzilla, and we'll investigate it.
Keep in mind though, that imake is on the path to oblivion, and thus
low priority.  I can't stress enough that people should stop using
imake for software projects out there, as it is pretty close to not
having an upstream maintainer in another 6 months or so.


tick tock,
tick tock,
goes the sound of the imake clock...

;oP



From bgerst at didntduck.org  Thu Nov 17 13:21:43 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Thu, 17 Nov 2005 08:21:43 -0500
Subject: glxgears / glxinfo
In-Reply-To: <437C240B.1010107@redhat.com>
References: <437BFE90.8070302@didntduck.org> <437C240B.1010107@redhat.com>
Message-ID: <437C83E7.2020807@didntduck.org>

Mike A. Harris wrote:
> Brian Gerst wrote:
>> Which package are glxgears/glxinfo hiding in now?  They used to be in 
>> xorg-x11-tools.
> 
> They um...   don't exist. ;)
> 
> They are part of Mesa, but not part of MesaLib.  I think they're in
> Mesa-demos, which we don't ship.
> 
> File a bug in RH bugzilla, and we'll make sure to add those back.
> 
> TIA
> 

Against what package?



From dimi at lattica.com  Thu Nov 17 13:35:27 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 17 Nov 2005 08:35:27 -0500
Subject: init: API
In-Reply-To: <1132221141.29504.9.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
Message-ID: <1132234527.9749.120.camel@dimi.lattica.com>

On Thu, 2005-11-17 at 11:52 +0200, Gilboa Davara wrote:
> I wrote a large number of WinNT/2K services and from my experience,
> it's the last system we'd want to duplicate.

Thanks for your input. Those are implementation issues that we'd
want to avoid. What about the API though? Is the API a good starting
point? What did you like/dislike about it?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From tibbs at math.uh.edu  Thu Nov 17 14:36:50 2005
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Thu, 17 Nov 2005 08:36:50 -0600
Subject: Modular X ramblings
In-Reply-To: <437C294A.1020903@redhat.com> (Mike A. Harris's message of
	"Thu, 17 Nov 2005 01:55:06 -0500")
References: <437C059B.8030001@didntduck.org> <437C294A.1020903@redhat.com>
Message-ID: <ufar79f733x.fsf@epithumia.math.uh.edu>

>>>>> "MAH" == Mike A Harris <mharris at redhat.com> writes:

MAH> I'm open to hear suggestions if anyone has some for how we can
MAH> solve these problems.

Is it possible to fix/hack X to simply attempt a reconnection to the
font server?

 - J<



From gilboada at netvision.net.il  Thu Nov 17 14:55:25 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Thu, 17 Nov 2005 16:55:25 +0200
Subject: init: API
In-Reply-To: <1132234527.9749.120.camel@dimi.lattica.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
Message-ID: <1132239325.31499.48.camel@gilboa-work-dev>

On Thu, 2005-11-17 at 08:35 -0500, Dimi Paun wrote:
> On Thu, 2005-11-17 at 11:52 +0200, Gilboa Davara wrote:
> > I wrote a large number of WinNT/2K services and from my experience,
> > it's the last system we'd want to duplicate.
> 
> Thanks for your input. Those are implementation issues that we'd
> want to avoid. What about the API though? Is the API a good starting
> point? What did you like/dislike about it?
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 

The API itself... is well, a OS2/Windows API. 
(Translation: Very ordered with meaningful names and a lot of
extra-useless options.)
I believe that we should first decide on what-we-need, before looking at
the API itself.

Don't forget that unlike Microsoft Windows, most the services we would
be running are normal daemonized binaries. 
IMHO, out service manager should:

A. Handle normal daemonized binaries. (Duh!)
B. Start/stop/reload services (Double duh).
C. Handle multiple /dynamic/ dependencies . (One of the services I wrote
actually replaced the MS dependency system due to the rather limited
build-in SCM dependencies support)
D. Handle auto restart, messaging on failure, etc.

How the API will look in the end, is less important at this point.
Gilboa



From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net  Thu Nov 17 15:46:19 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 17 Nov 2005 16:46:19 +0100
Subject: Xaw3d needs rebuild due to modular X
In-Reply-To: <Pine.LNX.4.64.0511171048390.2971@lemenkov.com>
References: <Pine.LNX.4.64.0511171048390.2971@lemenkov.com>
Message-ID: <20051117164619.73526ef2@python2>

Peter Lemenkov wrote :

> [root at Petro lib]# rpm -ql Xaw3d
> /usr/X11R6/lib/libXaw3d.so.7
> /usr/X11R6/lib/libXaw3d.so.7.0

Yeah, and it's not alone :-)

$ for file in *.rpm; do rpm -qpl $file 2>/dev/null | grep "/usr/X11R6/lib"
&& echo $file; done
/usr/X11R6/lib
/usr/X11R6/lib/tls
filesystem-2.3.6-1.i386.rpm
/usr/X11R6/lib/X11/app-defaults/GXditview
groff-gxditview-1.18.1.1-5.i386.rpm
/usr/X11R6/lib/modules/input/wacom_drv.o
linuxwacom-0.6.6-7.i386.rpm
/usr/X11R6/lib/libMrm.so.2
/usr/X11R6/lib/libMrm.so.2.1
/usr/X11R6/lib/libUil.so.2
/usr/X11R6/lib/libUil.so.2.1
/usr/X11R6/lib/libXm.so.2
/usr/X11R6/lib/libXm.so.2.1
openmotif21-2.1.30-17.1.i386.rpm
/usr/X11R6/lib/X11/bindings
/usr/X11R6/lib/X11/bindings/acorn
/usr/X11R6/lib/X11/bindings/apollo
/usr/X11R6/lib/X11/bindings/dec
/usr/X11R6/lib/X11/bindings/dg_AViiON
/usr/X11R6/lib/X11/bindings/doubleclick
/usr/X11R6/lib/X11/bindings/hal
/usr/X11R6/lib/X11/bindings/hitachi
/usr/X11R6/lib/X11/bindings/hp
/usr/X11R6/lib/X11/bindings/ibm
/usr/X11R6/lib/X11/bindings/intergraph
/usr/X11R6/lib/X11/bindings/intergraph17
/usr/X11R6/lib/X11/bindings/megatek
/usr/X11R6/lib/X11/bindings/motorola
/usr/X11R6/lib/X11/bindings/ncr_at
/usr/X11R6/lib/X11/bindings/ncr_vt
/usr/X11R6/lib/X11/bindings/pc
/usr/X11R6/lib/X11/bindings/sgi
/usr/X11R6/lib/X11/bindings/siemens_9733
/usr/X11R6/lib/X11/bindings/siemens_wx200
/usr/X11R6/lib/X11/bindings/sni
/usr/X11R6/lib/X11/bindings/sni_97801
/usr/X11R6/lib/X11/bindings/sony
/usr/X11R6/lib/X11/bindings/sun
/usr/X11R6/lib/X11/bindings/sun_at
/usr/X11R6/lib/X11/bindings/tek
/usr/X11R6/lib/X11/bindings/xmbind.alias
/usr/X11R6/lib/X11/system.mwmrc
/usr/X11R6/lib/libMrm.so.3
/usr/X11R6/lib/libMrm.so.3.0.2
/usr/X11R6/lib/libUil.so.3
/usr/X11R6/lib/libUil.so.3.0.2
/usr/X11R6/lib/libXm.so.3
/usr/X11R6/lib/libXm.so.3.0.2
openmotif-2.2.3-11.i386.rpm
/usr/X11R6/lib/libMrm.a
/usr/X11R6/lib/libMrm.so
/usr/X11R6/lib/libUil.a
/usr/X11R6/lib/libUil.so
/usr/X11R6/lib/libXm.a
/usr/X11R6/lib/libXm.so
openmotif-devel-2.2.3-11.i386.rpm
/usr/X11R6/lib/modules/input/synaptics_drv.o
synaptics-0.14.4-1.i386.rpm
/usr/X11R6/lib
/usr/X11R6/lib/modules
/usr/X11R6/lib/modules/extensions
/usr/X11R6/lib/modules/extensions/vnc.so
vnc-server-4.1.1-18.i386.rpm
/usr/X11R6/lib
/usr/X11R6/lib/modules
/usr/X11R6/lib/modules/extensions
/usr/X11R6/lib/modules/extensions/vnc.so
vnc-server-4.1.1-19.i386.rpm
/usr/X11R6/lib/libXaw3d.so.7
/usr/X11R6/lib/libXaw3d.so.7.0
Xaw3d-1.5E-4.i386.rpm
/usr/X11R6/lib/libXaw3d.so
Xaw3d-devel-1.5E-4.i386.rpm
/usr/X11R6/lib/X11/app-defaults/XISDNLoad
xisdnload-3.2-35.i386.rpm
/usr/X11R6/lib/X11/app-defaults/XScreenSaver
xscreensaver-base-4.22-19.i386.rpm

Feel free to check if bugzilla entries have already been filed, and submit
some when still needed.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1637_FC4
Load : 2.23 1.09 1.04



From bgerst at didntduck.org  Thu Nov 17 17:04:40 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Thu, 17 Nov 2005 12:04:40 -0500
Subject: Modular X ramblings
In-Reply-To: <437C294A.1020903@redhat.com>
References: <437C059B.8030001@didntduck.org> <437C294A.1020903@redhat.com>
Message-ID: <437CB828.1020505@didntduck.org>

Mike A. Harris wrote:
> Brian Gerst wrote:
>> - XFS didn't automatically restart, I had to manually start it.
> 
> The xfs rpm scripts have been updated recently with many changes.  One
> of the changes, was to have it check to see if it is upgrading from
> monolithic X to modular X or not, and if it is, to force a "restart"
> in the initscript.  If it is just modular to modular, then it does
> a "reload" instead.
> 
> It's possible the script is buggy though. It hasn't had a lot of testing
> yet.  Also, I'm open to suggestions for how to improve the "upgrade
> xfs package" situation.  Here are some concerns to consider:
> 
> 1) When xfs is restarted, the connection with the X server is broken,
>    so apps using core fonts can no longer find fonts.  While xset can
>    be used theoretically to re-establish a link to the X server, the
>    initscript has no idea wether the X server is :0, :1, :8, or all 3.
>    There is no "clean" way to have the connection re-established.
> 
> 2) Using "reload" causes it to reload the config file instead of
>    restarting, but then you are still using the old xfs server, not
>    the new one.  Also, the old one is unable to find it's config file
>    after upgrade, so must be restarted anyway.
> 
> 3) If an xfs security update goes out, the way things are now, you have
>    to manually restart xfs, as it wont get restarted otherwise.  That is
>    kindof bad, but it's the way it is right now to avoid disconnecting
>    xfs from the X server.
> 
> I'm open to hear suggestions if anyone has some for how we can solve
> these problems.
> 
> One thing I'd like to address before anyone does respond with
> suggestions though ...
> 
> When these type of problems arise with xfs, inevitably someone will
> eventually say "get rid of xfs, and just use the X server to serve
> the fonts directly and the problem is solved".  While that sounds
> very attractive in a once sentence email or IRC statement, in the
> real world, there are hundreds of thousands of deployed systems out
> there, and migrating away from xfs to using the X server would have
> to be performed rather smoothly on OS upgrades.  Getting the
> nuances of that correct is more complicated than one might think.
> 
> Also, chkfontpath currently configures the fontpaths into the xfs
> font server, and does not have any logic to do this with the X
> server.  We would _have_ to update chkfontpath to be able to handle
> the X server as well, yet still be able to do it with xfs for
> systems out there that _do_ want to still use xfs.  So ultimately,
> we still end up supporting xfs, only we now have to re-engineer
> a bunch of legacy code (chkfontpath) which is rather fragile to
> begin with, and make everything work without breaking systems
> out there beyond recognition.
> 
> Even if we were to do this, we do not really gain any new
> functionality at all, despite how much effort would be put into
> implementing and testing it all.  Also, we would be changing
> something that more or less "just works" most of the time, and
> has been done this way for 8 years or more.  Making such a change
> with no real visible gains is a big waste of time, energy and
> manpower that would be taken away from other possible projects
> that could have been done instead, which have real world benefits.
> 
> The reason I'm going into this level of detail in this email, is
> more or less to cut the conversation off before it starts, as it
> comes up every time xfs problems are mentioned, and the bottom
> line never changes.  xfs is a necessity that we have to live with,
> so we have to fix it if it breaks, as that is the least costly
> way to keep core fonts support working.
> 
> </diatribe> ;o)

In my case, I had shut down X and did all the upgrades from text 
console, so reconnecting xfs and the X server was not the issue.  The 
scripts simply failed to "service start xfs".

--
				Brian Gerst



From dimi at lattica.com  Thu Nov 17 15:11:05 2005
From: dimi at lattica.com (Dimi Paun)
Date: Thu, 17 Nov 2005 10:11:05 -0500
Subject: init: API
References: <043301c5eacf$dbba0ba0$b6491b31@td612671><1132221141.29504.9.camel@gilboa-work-dev><1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
Message-ID: <005401c5eb89$2ceacf00$b6491b31@td612671>

From: "Gilboa Davara" <gilboada at netvision.net.il>
> How the API will look in the end, is less important at this point.
> Gilboa

Sure, but that's the topic of this thread :) I'm not claiming
it's the most important aspect, but it's important and it doesn't
seem to be addressed by any of the current proposals.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From gilboada at netvision.net.il  Thu Nov 17 17:28:33 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Thu, 17 Nov 2005 19:28:33 +0200
Subject: init: API
In-Reply-To: <005401c5eb89$2ceacf00$b6491b31@td612671>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
Message-ID: <1132248513.8647.16.camel@gilboa-work-dev>

On Thu, 2005-11-17 at 10:11 -0500, Dimi Paun wrote:
> From: "Gilboa Davara" <gilboada at netvision.net.il>
> > How the API will look in the end, is less important at this point.
> > Gilboa
> 
> Sure, but that's the topic of this thread :) I'm not claiming
> it's the most important aspect, but it's important and it doesn't
> seem to be addressed by any of the current proposals.
> 
> -- 
> Dimi Paun <dimi at lattica.com>
> Lattica, Inc.
> 

Agreed.
However, there seem to be bigger discussion (in the "init observation"
thread) about whether there's a need to replace the init system to begin
with.
I agree that the init.d system is very old and slow.
However, I rather not have a C/CPP based system that I cannot edit in 3
seconds, which I want to change something.

Gilboa



From mharris at redhat.com  Thu Nov 17 18:31:15 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 17 Nov 2005 13:31:15 -0500
Subject: glxgears / glxinfo
In-Reply-To: <437C83E7.2020807@didntduck.org>
References: <437BFE90.8070302@didntduck.org> <437C240B.1010107@redhat.com>
	<437C83E7.2020807@didntduck.org>
Message-ID: <437CCC73.7060204@redhat.com>

Brian Gerst wrote:
> Mike A. Harris wrote:
> 
>> Brian Gerst wrote:
>>
>>> Which package are glxgears/glxinfo hiding in now?  They used to be in 
>>> xorg-x11-tools.
>>
>>
>> They um...   don't exist. ;)
>>
>> They are part of Mesa, but not part of MesaLib.  I think they're in
>> Mesa-demos, which we don't ship.
>>
>> File a bug in RH bugzilla, and we'll make sure to add those back.
>>
>> TIA
>>
> 
> Against what package?

xorg-x11 is fine for now



From link at pobox.com  Thu Nov 17 18:43:22 2005
From: link at pobox.com (Terje Bless)
Date: Thu, 17 Nov 2005 19:43:22 +0100
Subject: Modular X ramblings
In-Reply-To: <437C294A.1020903@redhat.com>
Message-ID: <A02020006-1043-B59174FC88F7431881B502E79261F5E5@pounder.tj.unn.no>

Mike A. Harris <mharris at redhat.com> wrote:

>>- Nvidia driver works fine after putting files in the new locations
>
>Crap, I'll have to try to break it some other way then.  ;o)

Assuming that actually was a joke ? something which I wouldn't put money on, but
I digress :-) ? is Modular X required to break the nvidia driver to achieve its
goals or is it possible on this end to facilitate it?

I would have expected the Modular X to break it for other reasons, but if it's
simply a matter of some paths being outdated perhaps the annoyance of cobbling
together something to make it work is within reasonable limits?


-link; asking, of course, since he's stuck in nvidia land for reasons
       irrelevant to this issue.

-- 
If you believe that will stop spammers, you're sadly misled. Rusty hooks,
rectally administered fuel oil enemas, and the gutting of their machines,
*that* stops spammers!                                         -- Saundo



From bojan at rexursive.com  Thu Nov 17 18:52:37 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 05:52:37 +1100
Subject: xmkmf in modular X
In-Reply-To: <437C7C64.6080207@redhat.com>
References: <1132225121.27296.13.camel@coyote.rexursive.com>
	<437C7C64.6080207@redhat.com>
Message-ID: <1132253558.27296.15.camel@coyote.rexursive.com>

On Thu, 2005-11-17 at 07:49 -0500, Mike A. Harris wrote:

> It is probably a glitch in the new imake package.  If you can confirm
> that, please file a bug in Red Hat bugzilla, and we'll investigate it.

OK. I'll have a bit better look today.

-- 
Bojan



From bojan at rexursive.com  Thu Nov 17 18:55:49 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 05:55:49 +1100
Subject: repodata not updated
Message-ID: <1132253749.27296.19.camel@coyote.rexursive.com>

Anyone knows why repodata wasn't updated in Rawhide? It is still dated
16 Nov, although there are binary packages that are dated 17 Nov.

-- 
Bojan



From jdesbonnet at gmail.com  Thu Nov 17 19:18:23 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Thu, 17 Nov 2005 19:18:23 +0000
Subject: init: API
In-Reply-To: <1132248513.8647.16.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
Message-ID: <1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>

Slightly related to this thread -- is there any policy regarding the
format of configuration files for new software or re-writes of
existing software.

XML would be the obvious choice (it is both human and machine
readable), but I did see a recent post here that requested "anything
but XML". I can understand why someone would not like XML (not easy to
read, difficult to edit with vi without breaking the file). But one of
the things I hate about unix like OSes is that every application has a
different config file format, making writing admin tools very
difficult.

If not XML then what? Obviously the project owner gets to choose, but
in the absence of personal preferences I think it make sense for
Fedora Core project to make a recommendation so as to make the
development of admin tools easier.

Joe.


On 11/17/05, Gilboa Davara <gilboada at netvision.net.il> wrote:
> On Thu, 2005-11-17 at 10:11 -0500, Dimi Paun wrote:
> > From: "Gilboa Davara" <gilboada at netvision.net.il>
> > > How the API will look in the end, is less important at this point.
> > > Gilboa
> >
> > Sure, but that's the topic of this thread :) I'm not claiming
> > it's the most important aspect, but it's important and it doesn't
> > seem to be addressed by any of the current proposals.
> >
> > --
> > Dimi Paun <dimi at lattica.com>
> > Lattica, Inc.
> >
>
> Agreed.
> However, there seem to be bigger discussion (in the "init observation"
> thread) about whether there's a need to replace the init system to begin
> with.
> I agree that the init.d system is very old and slow.
> However, I rather not have a C/CPP based system that I cannot edit in 3
> seconds, which I want to change something.
>
> Gilboa
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From petro at mail.ru  Thu Nov 17 18:31:57 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Thu, 17 Nov 2005 21:31:57 +0300
Subject: Bug in modular xorg-x11-server-Xorg-0.99.3-5
Message-ID: <Pine.LNX.4.64.0511172129530.26872@lemenkov.com>

Hello, All!

==================================

(II) LoadModule: "GLcore"
(II) Loading /usr/lib/xorg/modules/libGLcore.so
dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
(EE) Failed to load /usr/lib/xorg/modules/libGLcore.so
(II) UnloadModule: "GLcore"
(EE) Failed to load module "GLcore" (loader failed, 7)

==================================

-- 
With best regards, Peter Lemenkov.




From nicolas.mailhot at laposte.net  Thu Nov 17 19:46:20 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Thu, 17 Nov 2005 20:46:20 +0100
Subject: init: API
In-Reply-To: <1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
Message-ID: <1132256781.3299.28.camel@rousalka.dyndns.org>

Le jeudi 17 novembre 2005 ? 19:18 +0000, Joe Desbonnet a ?crit :
> Slightly related to this thread -- is there any policy regarding the
> format of configuration files for new software or re-writes of
> existing software.
> 
> XML would be the obvious choice (it is both human and machine
> readable), but I did see a recent post here that requested "anything
> but XML". 

I think a lot of people would reformulate it as "anything but the XML
style gconf uses". OTOH has anyone a real beef with for
example /etc/fonts/fonts.conf?

XML is no worse than any other text file format, OTOH *many* people have
been abusing it. So you just need some strong style conventions. XML by
itself is no silver bullet.

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/20051117/81d7f7db/attachment.sig>

From arjanv at redhat.com  Thu Nov 17 20:24:44 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Thu, 17 Nov 2005 21:24:44 +0100
Subject: Bug in modular xorg-x11-server-Xorg-0.99.3-5
In-Reply-To: <Pine.LNX.4.64.0511172129530.26872@lemenkov.com>
References: <Pine.LNX.4.64.0511172129530.26872@lemenkov.com>
Message-ID: <1132259085.5324.7.camel@laptopd505.fenrus.org>

On Thu, 2005-11-17 at 21:31 +0300, Peter Lemenkov wrote:
> Hello, All!
> 
> ==================================
> 
> (II) LoadModule: "GLcore"
> (II) Loading /usr/lib/xorg/modules/libGLcore.so
> dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
> (EE) Failed to load /usr/lib/xorg/modules/libGLcore.so
> (II) UnloadModule: "GLcore"
> (EE) Failed to load module "GLcore" (loader failed, 7)

using nvidia ? ati?




From ph18 at cornell.edu  Thu Nov 17 20:39:14 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Thu, 17 Nov 2005 15:39:14 -0500
Subject: init: API
In-Reply-To: <1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
Message-ID: <437CEA72.1040201@cornell.edu>

Joe Desbonnet wrote:

>XML would be the obvious choice (it is both human and machine
>readable), but I did see a recent post here that requested "anything
>but XML". I can understand why someone would not like XML (not easy to
>read, difficult to edit with vi without breaking the file). But one of
>the things I hate about unix like OSes is that every application has a
>different config file format, making writing admin tools very
>difficult.
>
>  
>
    I second "everything but XML",  for the most part.

    Some people I work with developed a library that works with a 
commercial CMS,  that hooks up sites in the CMS with a campus-wide 
authentication system.  This has an XML configuration file -- when we 
add a new site,  we only need to change one parameter...  which is 
entered twice into a 50-line block of XML.  We continuously have 
problems when somebody edits the file,  doesn't respect tag nesting,  
and the system breaks.

    Contrast this to Apache configuration files,  where I can write a 
script that (i) creates a new configuration file for a virtual host,  
and (ii) adds something at the end of the main conf file to activate the 
vhost,  and (iii) kicks the server...  You don't even need perl to do 
this,  I can do this in bash without looking at the man page.

    I suppose that Boy Wonder and Data Dog can spend three days to write 
a 3000 line program that does the same thing with libxml,  or you could 
bring in a consultant to do it with XSLT,  but I'm left feeling that 
this is a step back.  If I'm going to do that,  I might as well program 
for Windows -- I hear Visual Basic has a better visual app builder than 
anything that runs on Linux...

>If not XML then what? Obviously the project owner gets to choose, but
>in the absence of personal preferences I think it make sense for
>Fedora Core project to make a recommendation so as to make the
>development of admin tools easier.
>
>  
>
    It's not just a matter of XML -- XML answers a lot of tough 
questions (foreign character coding,  quoting,  container relationships) 
but it doesn't answer all of them.  You'd have to create an XML dialect 
(schema) for encoding configuration information,  which is probably 
going to be key-value pairs.  You also need some system for describing 
the ontology of your conf files....  It ends up sound a lot like the 
Windows Registry or...  gconf!

    (Stated more positively,  people who want a system where it's easy 
to configure things graphically ought to bark up the gconf tree)

    RH/Fedora could certainly change the conf files for things they are 
responsible for (XML /etc/sysconfig,  for instance,)   but they can't do 
much to change the behavior of other developers.  Just try getting the 
Apache team to change the organization,  never mind the format,  of the 
default configuration files...



From steved at redhat.com  Thu Nov 17 20:45:55 2005
From: steved at redhat.com (Steve Dickson)
Date: Thu, 17 Nov 2005 20:45:55 -0000
Subject: rawhide report: 20051011 changes
In-Reply-To: <mailman.342.1129166002.1911.fedora-devel-list@redhat.com>
References: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com>
	<mailman.342.1129166002.1911.fedora-devel-list@redhat.com>
Message-ID: <dilghl$s7$1@stan.redhat.com>

Bernardo Innocenti wrote:
> Build System wrote:
> 
>> system-config-nfs-1.3.12-1
>> --------------------------
>> * Tue Oct 11 2005 Nils Philippsen <nphilipp at redhat.com> 1.3.12
>> - allow user to set networking ports to be used (#151166)
>> - separate code concerning the NFS server, its settings and NFS exports
>> - some code cleanup
> 
> 
> Some files are missing in this package:
> 
> # system-config-nfs
> Traceback (most recent call last):
>  File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ?
>    import mainWindow
>  File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ?
>    import nfsServer
> ImportError: No module named nfsServer
> 
> 
> BTW, is NFSv4 officially supported in Fedora now?  With gss-api
> authentication too?
> 
Yes... and Yes...

steved.


From steved at redhat.com  Thu Nov 17 20:45:55 2005
From: steved at redhat.com (Steve Dickson)
Date: Thu, 17 Nov 2005 20:45:55 -0000
Subject: rawhide report: 20051011 changes
In-Reply-To: <mailman.342.1129166002.1911.fedora-devel-list@redhat.com>
References: <200510111115.j9BBFRmr009853@porkchop.devel.redhat.com>
	<mailman.342.1129166002.1911.fedora-devel-list@redhat.com>
Message-ID: <434E3B3A.1000903@redhat.com>

Bernardo Innocenti wrote:
> Build System wrote:
> 
>> system-config-nfs-1.3.12-1
>> --------------------------
>> * Tue Oct 11 2005 Nils Philippsen <nphilipp at redhat.com> 1.3.12
>> - allow user to set networking ports to be used (#151166)
>> - separate code concerning the NFS server, its settings and NFS exports
>> - some code cleanup
> 
> 
> Some files are missing in this package:
> 
> # system-config-nfs
> Traceback (most recent call last):
>  File "/usr/share/system-config-nfs/system-config-nfs.py", line 40, in ?
>    import mainWindow
>  File "/usr/share/system-config-nfs/mainWindow.py", line 22, in ?
>    import nfsServer
> ImportError: No module named nfsServer
> 
> 
> BTW, is NFSv4 officially supported in Fedora now?  With gss-api
> authentication too?
yes... and yes... Actually FC2 was the first distro that NFSv4
appeared in... But I would highly suggest using the NFSv4
FC4... ;-)

steved.



From bojan at rexursive.com  Thu Nov 17 21:46:26 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 08:46:26 +1100
Subject: repodata not updated
In-Reply-To: <1132253749.27296.19.camel@coyote.rexursive.com>
References: <1132253749.27296.19.camel@coyote.rexursive.com>
Message-ID: <20051118084626.yxxuxpb5wk84c4w4@imp.rexursive.com>

Quoting Bojan Smojver <bojan at rexursive.com>:

> Anyone knows why repodata wasn't updated in Rawhide? It is still dated
> 16 Nov, although there are binary packages that are dated 17 Nov.

Patience, my young apprentice, patience :-)

-- 
Bojan



From petro at mail.ru  Thu Nov 17 21:34:01 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 00:34:01 +0300
Subject: Current kernel & saa7134
Message-ID: <Pine.LNX.4.64.0511180031430.4311@lemenkov.com>


Hello, All!
Maybe, it would be useful:

==============================
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: found at 0000:00:0b.0, rev: 1, irq: 5, latency: 32, mmio: 0xdfffbc00
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: subsystem: 4e42:0138, board: LifeView FlyVIDEO3000 [card=2,autodetected]
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: board init: gpio is 39000
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: there are different flyvideo cards with different tuners
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: out there, you might have to use the tuner=<nr> insmod
Nov 18 00:11:43 lemenkov kernel: saa7134[0]: option to override the default value.
Nov 18 00:11:43 lemenkov kernel: Unable to handle kernel NULL pointer dereference at virtual address 000006e0
Nov 18 00:11:43 lemenkov kernel:  printing eip:
Nov 18 00:11:43 lemenkov kernel: c02b5115
Nov 18 00:11:43 lemenkov kernel: *pde = 4f5b4067
Nov 18 00:11:43 lemenkov kernel: Oops: 0000 [#1]
Nov 18 00:11:43 lemenkov kernel: Modules linked in: saa7134 video_buf v4l2_common v4l1_compat snd_timer ir_kbd_i2c snd_page_alloc snd_mpu40
Nov 18 00:11:43 lemenkov kernel: CPU:    0
Nov 18 00:11:43 lemenkov kernel: EIP:    0060:[<c02b5115>]    Not tainted VLI
Nov 18 00:11:43 lemenkov kernel: EFLAGS: 00010246   (2.6.14-1.1682_FC5)
Nov 18 00:11:43 lemenkov kernel: EIP is at input_register_device+0x5/0x1a0
Nov 18 00:11:43 lemenkov kernel: eax: 00000000   ebx: f7022840   ecx: f896e660   edx: c1b7e894
Nov 18 00:11:43 lemenkov kernel: esi: 00000000   edi: f7071000   ebp: f7022608   esp: f7640ec8
Nov 18 00:11:43 lemenkov kernel: ds: 007b   es: 007b   ss: 0068
Nov 18 00:11:43 lemenkov kernel: Process modprobe (pid: 585, threadinfo=f7640000 task=f763bab0)
Nov 18 00:11:43 lemenkov kernel: Stack: f706616c f7022840 f706616c f895d2b5 f7022820 f896e660 0ec00000 00040000
Nov 18 00:11:43 lemenkov kernel:        00000000 f7071000 c1b7e894 00000000 f7071118 f8955255 00000001 00000001
Nov 18 00:11:43 lemenkov kernel:        f7071000 f8955808 f896c59c f896d180 f896d180 c1b7e8d8 c0275ce0 c01f5e6a
Nov 18 00:11:43 lemenkov kernel: Call Trace:
Nov 18 00:11:43 lemenkov kernel:  [<f895d2b5>] saa7134_input_init1+0x195/0x400 [saa7134]
Nov 18 00:11:43 lemenkov kernel:  [<f8955255>] saa7134_hwinit1+0xd5/0x140 [saa7134]
Nov 18 00:11:43 lemenkov kernel:  [<f8955808>] saa7134_initdev+0x278/0x6a0 [saa7134]
Nov 18 00:11:43 lemenkov kernel:  [<c0275ce0>] __driver_attach+0x0/0x50
Nov 18 00:11:43 lemenkov kernel:  [<c01f5e6a>] pci_call_probe+0xa/0x10
Nov 18 00:11:43 lemenkov kernel:  [<c01f5ea6>] __pci_device_probe+0x36/0x50
Nov 18 00:11:43 lemenkov kernel:  [<c01f5ede>] pci_device_probe+0x1e/0x40
Nov 18 00:11:43 lemenkov kernel:  [<c0275c02>] driver_probe_device+0x32/0x90
Nov 18 00:11:43 lemenkov kernel:  [<c0275d2a>] __driver_attach+0x4a/0x50
Nov 18 00:11:43 lemenkov kernel:  [<c02753f8>] bus_for_each_dev+0x38/0x60
Nov 18 00:11:43 lemenkov kernel:  [<c0275d41>] driver_attach+0x11/0x20
Nov 18 00:11:43 lemenkov kernel:  [<c0275ce0>] __driver_attach+0x0/0x50
Nov 18 00:11:43 lemenkov kernel:  [<c027580a>] bus_add_driver+0x5a/0xa0
Nov 18 00:11:43 lemenkov kernel:  [<c01f60d4>] __pci_register_driver+0x94/0xc0
Nov 18 00:11:43 lemenkov kernel:  [<c01394ed>] sys_init_module+0xbd/0x1c0
Nov 18 00:11:43 lemenkov kernel:  [<c0103039>] syscall_call+0x7/0xb
Nov 18 00:11:43 lemenkov kernel: Code: 05 3c c0 5b 5e 5f e9 bb d6 ee ff 8b 43 04 ba dd bd 34 c0 85 c0 75 a5 b8 8e a9 36 c0 eb 9e 90 8d b4 2

==============================

[petro at Petro projects]$ uname -a
Linux Petro 2.6.14-1.1682_FC5 #1 Wed Nov 16 00:31:25 EST 2005 i686 athlon i386 GNU/Linux

-- 
With best regards, Peter Lemenkov.




From petro at mail.ru  Thu Nov 17 21:29:08 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 00:29:08 +0300
Subject: Bug in modular xorg-x11-server-Xorg-0.99.3-5
In-Reply-To: <1132259085.5324.7.camel@laptopd505.fenrus.org>
References: <Pine.LNX.4.64.0511172129530.26872@lemenkov.com>
	<1132259085.5324.7.camel@laptopd505.fenrus.org>
Message-ID: <Pine.LNX.4.64.0511180027290.4311@lemenkov.com>

On Thu, 17 Nov 2005, Arjan van de Ven wrote:

>> Hello, All!
>>
>> ==================================
>>
>> (II) LoadModule: "GLcore"
>> (II) Loading /usr/lib/xorg/modules/libGLcore.so
>> dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
>> (EE) Failed to load /usr/lib/xorg/modules/libGLcore.so
>> (II) UnloadModule: "GLcore"
>> (EE) Failed to load module "GLcore" (loader failed, 7)

> using nvidia ? ati?

xorg-x11-drv-nv-1.0.1.2-1

-- 
With best regards, Peter Lemenkov.




From gilboada at netvision.net.il  Thu Nov 17 22:20:25 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Fri, 18 Nov 2005 00:20:25 +0200
Subject: init: API
In-Reply-To: <1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
Message-ID: <1132266025.9736.3.camel@gilboa-home-dev.localhost>

On Thu, 2005-11-17 at 19:18 +0000, Joe Desbonnet wrote:
> Slightly related to this thread -- is there any policy regarding the
> format of configuration files for new software or re-writes of
> existing software.
> 
> XML would be the obvious choice (it is both human and machine
> readable), but I did see a recent post here that requested "anything
> but XML". I can understand why someone would not like XML (not easy to
> read, difficult to edit with vi without breaking the file). But one of
> the things I hate about unix like OSes is that every application has a
> different config file format, making writing admin tools very
> difficult.
> 
> If not XML then what? Obviously the project owner gets to choose, but
> in the absence of personal preferences I think it make sense for
> Fedora Core project to make a recommendation so as to make the
> development of admin tools easier.
> 
> Joe.

I, too, second the "anything but XML" statement.
A. Hard to read.
B. Hard to edit using non-XML editors. (vim in my case)
C. Tends to create needlessly-complex data structures.
D. While can be accessed using shell scripts, it requires very complex
and unreadable code.

On the other hand, what does XML offer in return?

Gilboa




From mike at mommabears.com  Thu Nov 17 22:32:13 2005
From: mike at mommabears.com (MJang)
Date: Thu, 17 Nov 2005 14:32:13 -0800
Subject: FC5 devel question
Message-ID: <1132266733.3842.16.camel@localhost>

Folks, 

Just tried to install what I thought would be equivalent to FC5 beta 1
from the Devel repositories (assuming the freeze is in effect). 

I ended up with a fatal Anaconda fault, not sure where to report it. The
traceback is a 1.3MB text file. The first key error seems to be:

DepError: Unresolvable dependancy /etc/init.d/functions in xorg-x11-xfs

I remember reading something similar yesterday, but can't find it in the
archives of this list. Is this a known issue?

If I should put this in Bugzilla, I'm guessing it should be under
Anaconda, in the Fedora Core / Devel version - or should it be
elsewhere?

Thanks,
Mike



From sopwith at redhat.com  Thu Nov 17 22:52:44 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Thu, 17 Nov 2005 17:52:44 -0500 (EST)
Subject: Rawhide of Docs
Message-ID: <Pine.LNX.4.58.0511171716410.4305@devserv.devel.redhat.com>

If you'd like to see the latest and greatest docs that that the Fedora
Documentation team has been working on, you can now visit
http://webtest.fedora.redhat.com/docs/

Join the fun!
-- Elliot



From bojan at rexursive.com  Thu Nov 17 23:08:02 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 10:08:02 +1100
Subject: Another modular X11 report (#2 from me)
Message-ID: <20051118100802.4k3dhcmfk8kskkk8@imp.rexursive.com>

This is for Compaq Evo D510 machine, which has an Intel based graphics 
chip (i845 or something like that). Today's Rawhide went up to the box 
fine. The following works on the box:

- flicking between X11 and text consoles
- direct rendering
- VMWare 5.5.0 (RC2)
- suspend/resume to disk using built in kernel code

Again, top marks!

-- 
Bojan



From nman64 at n-man.com  Thu Nov 17 23:09:06 2005
From: nman64 at n-man.com (Patrick Barnes)
Date: Thu, 17 Nov 2005 17:09:06 -0600
Subject: Rawhide of Docs
In-Reply-To: <Pine.LNX.4.58.0511171716410.4305@devserv.devel.redhat.com>
References: <Pine.LNX.4.58.0511171716410.4305@devserv.devel.redhat.com>
Message-ID: <437D0D92.7080901@n-man.com>

Elliot Lee wrote:
> If you'd like to see the latest and greatest docs that that the Fedora
> Documentation team has been working on, you can now visit
> http://webtest.fedora.redhat.com/docs/
>
> Join the fun!
> -- Elliot
>
>   
Remember: This is _Rawhide_ and should be treated accordingly.  Don't go
about linking to it or requiring it at this time.  It will change, it
will evolve, it may eat all the cheese in your house.  :-)

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

www.n-man.com
-- 



-------------- 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/20051117/aa16affc/attachment.sig>

From jspaleta at gmail.com  Thu Nov 17 23:16:55 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 17 Nov 2005 18:16:55 -0500
Subject: Rawhide of Docs
In-Reply-To: <437D0D92.7080901@n-man.com>
References: <Pine.LNX.4.58.0511171716410.4305@devserv.devel.redhat.com>
	<437D0D92.7080901@n-man.com>
Message-ID: <604aa7910511171516qe5e60b5nd232e185f36204c5@mail.gmail.com>

On 11/17/05, Patrick Barnes <nman64 at n-man.com> wrote:
> Remember: This is _Rawhide_ and should be treated accordingly.  Don't go
> about linking to it or requiring it at this time.  It will change, it
> will evolve, it may eat all the cheese in your house.  :-)

Is there anyway to "stamp" the html with a nice big "not be trusted"
watermark or equivalent?
Just in case people stumble on this material through some other means?

-jef"please tell me those pages are using a robots.txt or whatever is
needed nowadays to prevent commonly used web search engines from
archiving those packages"spaleta



From bojan at rexursive.com  Fri Nov 18 00:10:23 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 11:10:23 +1100
Subject: Suspend to disk with 2.6.14-1.1682_FC5
Message-ID: <20051118111023.bfa9qbl9wc8w8csw@imp.rexursive.com>

Just an FYI, on HP ZE-4201 notebook, this still locks up X on resume 
(i.e. it is unusable).

-- 
Bojan



From jdesbonnet at gmail.com  Fri Nov 18 00:28:23 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Fri, 18 Nov 2005 00:28:23 +0000
Subject: init: API
In-Reply-To: <1132266025.9736.3.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
Message-ID: <1cef3e950511171628p41c88bedpae550203a9d43f5e@mail.gmail.com>

On 11/17/05, Gilboa Davara <gilboada at netvision.net.il> wrote:
Agreed on A+B. C depends on implementation.
There is some truth to D, but I suspect that many simple scripts make
assumptions about the state of the file and can often fail (eg if the
file is hand edited).

There are many benefits: As mentioned earlier, handling international
characters becomes transparent. Schemas can be used to perform
validation. Manipulation by software is potentially much easier. If
there is a standard schema for representing common elements such as
users, permissions, access control lists etc then a standard library
can be written to translate these objects into Python, Java or C++
objects and vice versa.

I'm not necessarily advocating the use of XML. I think it is not
practical to force people to use this (or any other) format if they do
not want to. So instead of stick... some carrot :-)

Pick two or three common formats. Define them precisely (make them an
official standard -- like the Sun/Java JSR idea).  Write an access
library for the most popular application languages (C/C++, Python,
Java etc) and include those libraries in the Core.

In conjunction with this a "best practices" document can make
recommendations on how to best implement configuration files (eg
pointing out things which some people might forget: i18n issues,
time/date issues, handling different config for different machine
states / runlevels), and point out common mistakes.

If you have time, please take a look at /etc/*.conf.  Most files there
key-value pairs grouped into sections. But almost every file has a
slightly different syntax!

Joe.

> A. Hard to read.
> B. Hard to edit using non-XML editors. (vim in my case)
> C. Tends to create needlessly-complex data structures.
> D. While can be accessed using shell scripts, it requires very complex
> and unreadable code.
>
> On the other hand, what does XML offer in return?

Quiet a lot if implemented properly.

>
> Gilboa
>
>
>



From dravet at hotmail.com  Fri Nov 18 01:56:12 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Thu, 17 Nov 2005 19:56:12 -0600
Subject: what is going on with udev?
Message-ID: <BAY103-F25B6F253D368D7DFAF0697DF5E0@phx.gbl>

Hello everyone,

I have been pulling my hair out for the last several days trying to figure 
out why my usb thumb drive is not being mounted.  It was /dev/sdc1 (I have 
two scsi hard drives).  I read all of the usb related threads in the 
fedora-test-list but none quite matched my problem.  Long story short my 
thumb drive is now at /dev/uba1.  Why did this change?  Since udev-075-2 the 
starting udev process takes over 1 minute, before it took about 10 seconds.  
Some other people where also inquering about the slowest of udev.

A quick look in /dev shows I have 64 tty nodes (tty0 - tty63) and 32 ttyS 
nodes (ttyS0 - ttyS31).  I have two serial ports, both of which are disabled 
in the bios.  Why are these nodes showing up?  These extra nodes have been 
around since FC4 so udev-075-2 is not the blame for this.

Thanks,
Jason




From denis at poolshark.org  Fri Nov 18 01:57:46 2005
From: denis at poolshark.org (Denis Leroy)
Date: Thu, 17 Nov 2005 17:57:46 -0800
Subject: Another modular X11 report (#2 from me)
In-Reply-To: <20051118100802.4k3dhcmfk8kskkk8@imp.rexursive.com>
References: <20051118100802.4k3dhcmfk8kskkk8@imp.rexursive.com>
Message-ID: <437D351A.2080802@poolshark.org>

Bojan Smojver wrote:
> This is for Compaq Evo D510 machine, which has an Intel based graphics 
> chip (i845 or something like that). Today's Rawhide went up to the box 
> fine. The following works on the box:
> 
> - flicking between X11 and text consoles
> - direct rendering
> - VMWare 5.5.0 (RC2)

OTOH, VMWare 5.5.0 RC2 isn't happy with Rawhide as guest OS. In one VM i'm 
having problem with gcc crashing (bug 173440). It works on another VM but it 
can't compile its Xorg driver... I'll file a bug with them too...

-denis



From tburke at redhat.com  Fri Nov 18 02:23:25 2005
From: tburke at redhat.com (Tim Burke)
Date: Thu, 17 Nov 2005 21:23:25 -0500
Subject: Fedora general improvements input survey invitation
Message-ID: <437D3B1D.7050007@redhat.com>

The Fedora Core team invites you to participate in a survey to help 
identify the major ways in which Fedora can be improved for the benefit 
of the community.  The survey consists of 10 questions involving Fedora 
Core and Fedora Extras.  We are greatly interested in your views and 
hope you can share your thoughts with us.  The survey is available at:

http://www.keysurvey.com/survey/85928/1078/

The survey is enabled now and will remain open for input until 
Wednesday, November 30.

Thanks in advance for helping us to make Fedora better for all 
involved.  Upon conclusion of the survey, a summary of the results will 
be shared.




From bojan at rexursive.com  Fri Nov 18 02:52:40 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 13:52:40 +1100
Subject: Suspend to disk with 2.6.14-1.1682_FC5
In-Reply-To: <437D3559.3040409@speakeasy.net>
References: <437D3559.3040409@speakeasy.net>
Message-ID: <20051118135240.l2wo3ag5c4cw8k80@imp.rexursive.com>

Quoting Andrew Duggan <cmkrnl at speakeasy.net>:

> Have you tried booting with pci=routeirq ? I have found that works 
> around it. Let me know if you can resume with that...

Same thing - hung X.

-- 
Bojan



From wangxw at ict.ac.cn  Fri Nov 18 03:05:36 2005
From: wangxw at ict.ac.cn (=?gb2312?B?zfXQ487E?=)
Date: Fri, 18 Nov 2005 11:05:36 +0800
Subject: Is there any tool that can understand the format of
	comps.xml?Thanks in advance!
Message-ID: <200511180357.jAI3vhCj032747@mx3.redhat.com>

everyone,
  hello!
  I am customizing the installing CDs of FC4 into only one
CD.Must i  manually edit the file comps.xml and remove the
unnecessary groups and rpms.
  I am wondering if there is a tool that can understand the 
format of comps.xml.All i need to do is to select the group(s)
and rpm(s) needed.And when i commit i get the workable 
comps.xml.
  Or is there any tool that can make the job easier to do?

  Thanks!^-^

  mosquite



From naoki at valuecommerce.com  Fri Nov 18 03:58:19 2005
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 18 Nov 2005 12:58:19 +0900
Subject: ZFS.
Message-ID: <1132286299.19636.11.camel@dragon.sys.intra>

Seems ZFS is out in the wild under the CDDL ( implications of that
license I have no idea of though ).

http://www.opensolaris.org/os/community/zfs/source/


And the linux port is underway? :
http://www.sun.com/emrkt/campaign_docs/expertexchange/knowledge/solaris_zfs_gen.html#10


So does anybody know if the CDDL restricts the ability for it reaching
the main kernel?   And anybody else think it would be a really cool
addition?



From jspaleta at gmail.com  Fri Nov 18 04:04:13 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 17 Nov 2005 23:04:13 -0500
Subject: ZFS.
In-Reply-To: <1132286299.19636.11.camel@dragon.sys.intra>
References: <1132286299.19636.11.camel@dragon.sys.intra>
Message-ID: <604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>

On 11/17/05, Naoki <naoki at valuecommerce.com> wrote:
> So does anybody know if the CDDL restricts the ability for it reaching
> the main kernel?   And anybody else think it would be a really cool
> addition?

9 out of 10 Helen's agree... the CDDL is GPL incompatible.

-jef"i should really by the kids in the hall on dvd"spaleta



From loony at loonybin.org  Fri Nov 18 04:08:02 2005
From: loony at loonybin.org (Peter Arremann)
Date: Thu, 17 Nov 2005 23:08:02 -0500
Subject: ZFS.
In-Reply-To: <1132286299.19636.11.camel@dragon.sys.intra>
References: <1132286299.19636.11.camel@dragon.sys.intra>
Message-ID: <200511172308.02919.loony@loonybin.org>

On Thursday 17 November 2005 22:58, Naoki wrote:
> Seems ZFS is out in the wild under the CDDL ( implications of that
> license I have no idea of though ).
>
> http://www.opensolaris.org/os/community/zfs/source/
>
>
> And the linux port is underway? :
> http://www.sun.com/emrkt/campaign_docs/expertexchange/knowledge/solaris_zfs
>_gen.html#10

Q: When is the Solaris 10 OS slated for full release?

A: The current schedule is to ship the Solaris 10 OS at the end of calendar 
year 2004. 

Hmmm - might be slightly outdated... And I couldn't find any newer linux 
references since then... So I guess, that means no port any time soon...

Peter.



From jkeating at j2solutions.net  Fri Nov 18 04:09:14 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 17 Nov 2005 20:09:14 -0800
Subject: ZFS.
In-Reply-To: <1132286299.19636.11.camel@dragon.sys.intra>
References: <1132286299.19636.11.camel@dragon.sys.intra>
Message-ID: <1132286954.10592.29.camel@localhost.localdomain>

On Fri, 2005-11-18 at 12:58 +0900, Naoki wrote:
> 
> So does anybody know if the CDDL restricts the ability for it reaching
> the main kernel?   And anybody else think it would be a really cool
> addition?
> 

CDDL is incompatible with the GPL.  Highly doubtful it would end up in
mainline kernel, and thus in Fedora's kernel.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/b053d3eb/attachment.sig>

From nman64 at n-man.com  Fri Nov 18 04:11:20 2005
From: nman64 at n-man.com (Patrick Barnes)
Date: Thu, 17 Nov 2005 22:11:20 -0600
Subject: ZFS.
In-Reply-To: <1132286299.19636.11.camel@dragon.sys.intra>
References: <1132286299.19636.11.camel@dragon.sys.intra>
Message-ID: <437D5468.8010006@n-man.com>

Naoki wrote:
> Seems ZFS is out in the wild under the CDDL ( implications of that
> license I have no idea of though ).
>
> http://www.opensolaris.org/os/community/zfs/source/
>
>
> And the linux port is underway? :
> http://www.sun.com/emrkt/campaign_docs/expertexchange/knowledge/solaris_zfs_gen.html#10
>
>
> So does anybody know if the CDDL restricts the ability for it reaching
> the main kernel?   And anybody else think it would be a really cool
> addition?
>
>   
IIRC, the CDDL is not GPL compatible.  Unless it is licensed under the
GPL, it will not be placed in the kernel.  I believe the CDDL also
prevents it from being added to Fedora Core or Fedora Extras.

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

www.n-man.com
-- 



-------------- 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/20051117/b784722d/attachment.sig>

From naoki at valuecommerce.com  Fri Nov 18 05:14:43 2005
From: naoki at valuecommerce.com (Naoki)
Date: Fri, 18 Nov 2005 14:14:43 +0900
Subject: ZFS.
In-Reply-To: <437D5468.8010006@n-man.com>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<437D5468.8010006@n-man.com>
Message-ID: <1132290883.19636.19.camel@dragon.sys.intra>


On Thu, 2005-11-17 at 22:11 -0600, Patrick Barnes wrote:
> Naoki wrote:
> > Seems ZFS is out in the wild under the CDDL ( implications of that
> > license I have no idea of though ).
> >
> > http://www.opensolaris.org/os/community/zfs/source/
> >
> >
> > And the linux port is underway? :
> > http://www.sun.com/emrkt/campaign_docs/expertexchange/knowledge/solaris_zfs_gen.html#10
> >
> >
> > So does anybody know if the CDDL restricts the ability for it reaching
> > the main kernel?   And anybody else think it would be a really cool
> > addition?
> >
> >   
> IIRC, the CDDL is not GPL compatible.  Unless it is licensed under the
> GPL, it will not be placed in the kernel.  I believe the CDDL also
> prevents it from being added to Fedora Core or Fedora Extras.


Well N-Man, that's unfortunate.  I propose a new file system called
"NFS" with the same features :)



From toshio at tiki-lounge.com  Fri Nov 18 05:20:00 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Thu, 17 Nov 2005 21:20:00 -0800
Subject: ZFS.
In-Reply-To: <437D5468.8010006@n-man.com>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<437D5468.8010006@n-man.com>
Message-ID: <1132291200.3409.6.camel@localhost>

On Thu, 2005-11-17 at 22:11 -0600, Patrick Barnes wrote:
> >   
> IIRC, the CDDL is not GPL compatible.  Unless it is licensed under the
> GPL, it will not be placed in the kernel.  


> I believe the CDDL also
> prevents it from being added to Fedora Core or Fedora Extras.

Hmmm... The CDDL appears to be listed on http://www.opensource.org/
which IIRC was the criteria for licenses of software going into Extras
at one time.  Is this incorrect (or incorrect now)?

OTOH, if it cannot go into the kernel, that would be because it's
classified as a derivative work.  If it's classified as a derivative
work then it's in violation of the GPL whether or not it's distributed
in the kernel, right?  IANAL and I am very tired at the moment so my
chain of reasoning here could be totally specious.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051117/e0a8e8df/attachment.sig>

From bojan at rexursive.com  Fri Nov 18 05:28:24 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 18 Nov 2005 16:28:24 +1100
Subject: ZFS.
In-Reply-To: <1132286299.19636.11.camel@dragon.sys.intra>
References: <1132286299.19636.11.camel@dragon.sys.intra>
Message-ID: <20051118162824.dbwrqxwiok08o0k8@imp.rexursive.com>

Quoting Naoki <naoki at valuecommerce.com>:

> So does anybody know if the CDDL restricts the ability for it reaching
> the main kernel?

Absolutely. CDDL is incompatible with the GPL (as a copyright licence), 
because it puts additional restrictions on the code that don't exist in 
the GPL. Also, ZFS may include Sun patents that are licensed through 
the CDDL for that code _only_ (i.e. Sun ZFS code, most likely in its 
unmodified form). Meaning, even creating a "clone" (i.e. a different, 
functionally equivalent implementation) may be a problem (depending on 
the existence of Sun patents inside ZFS).

> And anybody else think it would be a really cool
> addition?

Sure. But don't keep you hopes up. Unless Sun release ZFS under the GPL 
(fat chance, pigs flying etc.), it won't be part of Linux any time 
soon. The other option is that Linux gets relicensed under, say GPL3 
(which doesn't exist yet and may not be compatible with CDDL anyway). 
This is close to impossible, because not all copyright holders in the 
Linux kernel can (or would) give their permission for such a change.

-- 
Bojan



From zaitcev at redhat.com  Fri Nov 18 05:29:43 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 17 Nov 2005 21:29:43 -0800
Subject: what is going on with udev?
In-Reply-To: <BAY103-F25B6F253D368D7DFAF0697DF5E0@phx.gbl>
References: <BAY103-F25B6F253D368D7DFAF0697DF5E0@phx.gbl>
Message-ID: <20051117212943.30187940.zaitcev@redhat.com>

On Thu, 17 Nov 2005 19:56:12 -0600, "Jason Dravet" <dravet at hotmail.com> wrote:

> I have been pulling my hair out for the last several days trying to figure 
> out why my usb thumb drive is not being mounted.  It was /dev/sdc1 (I have 
> two scsi hard drives).  I read all of the usb related threads in the 
> fedora-test-list but none quite matched my problem.  Long story short my 
> thumb drive is now at /dev/uba1.  Why did this change?  Since udev-075-2 the 
> starting udev process takes over 1 minute, before it took about 10 seconds.  
> Some other people where also inquering about the slowest of udev.

I do not think the slowness of udev has anything to do with ub, but
I am not willing to bet. Lemme look...

-- Pete



From sundaram at redhat.com  Fri Nov 18 08:27:55 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 18 Nov 2005 13:57:55 +0530
Subject: FC5 devel question
In-Reply-To: <1132266733.3842.16.camel@localhost>
References: <1132266733.3842.16.camel@localhost>
Message-ID: <437D908B.6000907@redhat.com>

MJang wrote:

>Folks, 
>
>Just tried to install what I thought would be equivalent to FC5 beta 1
>from the Devel repositories (assuming the freeze is in effect). 
>  
>
Fedora doesnt have beta releases.  Fedora Core 5 test 1 devel freeze has 
slightly been delayed.

>I ended up with a fatal Anaconda fault, not sure where to report it. The
>traceback is a 1.3MB text file. The first key error seems to be:
>
>DepError: Unresolvable dependancy /etc/init.d/functions in xorg-x11-xfs
>
>I remember reading something similar yesterday, but can't find it in the
>archives of this list. Is this a known issue?
>  
>
Its a known issue.  It was discussed in fedora-test list.  For further 
bug reports, look in http://bugzilla.redhat.com.

regards
Rahul



From clovis at agr.unicamp.br  Fri Nov 18 10:47:55 2005
From: clovis at agr.unicamp.br (Clovis Tristao)
Date: Fri, 18 Nov 2005 08:47:55 -0200
Subject: Mplayer and Kaffeine install
In-Reply-To: <437C7B3C.8060603@hhs.nl>
References: <437C551F.1030708@agr.unicamp.br> <437C7B3C.8060603@hhs.nl>
Message-ID: <437DB15B.90703@agr.unicamp.br>

Hans de Goede wrote:
> Clovis Tristao wrote:
>> Hi,
>>
>> I am trying to install the Mplayer and Kaffeine, using command "yum 
>> install", but it appears the message below:
>> # yum install mplayer
>> Setting up Update Process
>> Setting up repositories
>> development               100% |=========================| 1.1 kB    
>> 00:00
>> livna                     100% |=========================|  951 B    
>> 00:00
>> extras-development        100% |=========================| 1.1 kB    
>> 00:00
>> Reading repository metadata in from local files
>> --> Processing Dependency: libdirectfb-0.9.so.22 for package: mplayer
>> --> Finished Dependency Resolution
>> Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
>> mplayer
>>
>> # yum install kaffeine
>> Setting up Update Process
>> Setting up repositories
>> development               100% |=========================| 1.1 kB    
>> 00:00
>> livna                     100% |=========================|  951 B    
>> 00:00
>> extras-development        100% |=========================| 1.1 kB    
>> 00:00
>> Reading repository metadata in from local files
>> --> Finished Dependency Resolution
>> Error: Missing Dependency: libMagick.so.6 is needed by package xine-lib
>> Error: Missing Dependency: libdirectfb-0.9.so.22 is needed by package 
>> xine-lib
>> Error: Missing Dependency: libgs.so.7 is needed by package xine-lib
>> Error: Missing Dependency: libfusion-0.9.so.22 is needed by package 
>> xine-lib
>> Error: Missing Dependency: libdirect-0.9.so.22 is needed by package 
>> xine-lib
>> Error: Missing Dependency: libWand.so.6 is needed by package xine-lib
>>
>> What it can be happening? I am using Fedora Core with kernel 
>> 2.6.14-1.1651_FC5
>>
>> Cl?vis
>>
>
> Assuming you're running rawhide, the fbdirect problem is because of:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168343
>
> I'm working on this, but the fix uses directfb-0.9.24 which will 
> provide .so.24, so this will require a rebuild of the livna packages, 
> a local one sinc elivna doesn't support rawhide.
>
> Regards,
>
> Hans
>
>
Hi Hans,

Thanks for your info.
I would try the install directfb-0.9.24 rpm package, and wait the livna 
rebuild packages..
I use the Fedora Core Rawhide
Regards,

Cl?vis

-- 
Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola
Administrador de Redes - Secao de Informatica (SINFO)
E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br
Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010



From petro at mail.ru  Fri Nov 18 10:18:51 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 13:18:51 +0300
Subject: X11-forwarding over SSH didn't work!
Message-ID: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>

Hello, All!

Subj, until i symlinked /usr to usr/X11R6

Looks like someone hardcoded xauth to

/usr/X11R6/bin/xauth

Frankly speaking I think that's a good idea to make this symlink, until 
all issues, concerned with modular Xorg, will be resolved.

-- 
With best regards, Peter Lemenkov.




From fedora at camperquake.de  Fri Nov 18 11:15:25 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 18 Nov 2005 12:15:25 +0100
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
Message-ID: <20051118111525.GA6287@ryoko.camperquake.de>

On Fri, Nov 18, 2005 at 01:18:51PM +0300, Peter Lemenkov wrote:

> Looks like someone hardcoded xauth to
> 
> /usr/X11R6/bin/xauth
> 
> Frankly speaking I think that's a good idea to make this symlink, until 
> all issues, concerned with modular Xorg, will be resolved.

Bug in openssh. Want to file a bug?



From arjanv at redhat.com  Fri Nov 18 11:20:28 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 18 Nov 2005 12:20:28 +0100
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
Message-ID: <1132312828.2830.56.camel@laptopd505.fenrus.org>

On Fri, 2005-11-18 at 13:18 +0300, Peter Lemenkov wrote:
> Hello, All!
> 
> Subj, until i symlinked /usr to usr/X11R6
> 
> Looks like someone hardcoded xauth to
> 
> /usr/X11R6/bin/xauth
> 
> Frankly speaking I think that's a good idea to make this symlink, until 
> all issues, concerned with modular Xorg, will be resolved.

problem is.. if compat symlinks are made.. the issues will never get
reported and thus not resolved....




From obi at unixkiste.org  Fri Nov 18 12:08:25 2005
From: obi at unixkiste.org (Stefan Held)
Date: Fri, 18 Nov 2005 13:08:25 +0100
Subject: ZFS.
In-Reply-To: <604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
Message-ID: <1132315705.24792.18.camel@pc-sh.intern.pcservice.de>

Am Donnerstag, den 17.11.2005, 23:04 -0500 schrieb Jeff Spaleta:

> 9 out of 10 Helen's agree... the CDDL is GPL incompatible.

I did not get the point where the CDDL is GPL incompatible.
Maybe you mean the GPL does not allow to have other licenses.

AFAIK the CDDL is a BSD Style License. So where exactly do you come to
the conclusion that Software written under this license can't be used in
a GPL'ed environment?


-- 
 Stefan Held                    VI has only 2 Modes:
 obi at unixkiste org           The first one is for beeping all the time, 
 IRCNet: Obi_Wan                the second destroys the text.   
---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------
    GPG-Keyprint = EAF2 6A65 D102 F2DB 4970  2A67 455B 98F2 572C 3FA9


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051118/f41633b0/attachment.sig>

From arjanv at redhat.com  Fri Nov 18 12:15:49 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Fri, 18 Nov 2005 13:15:49 +0100
Subject: ZFS.
In-Reply-To: <1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
	<1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
Message-ID: <1132316150.2830.64.camel@laptopd505.fenrus.org>

On Fri, 2005-11-18 at 13:08 +0100, Stefan Held wrote:
> 
> AFAIK the CDDL is a BSD Style License. 

More MPL like.

> So where exactly do you come to
> the conclusion that Software written under this license can't be used
> in a GPL'ed environment?

(compiled) kernel modules are generally seen as a derived work of the
kernel, especially when integrated with the kernel. The GPL requires
derived works to be GPL licensed; not "compatible" like BSD, but GPL
licensed. The GPL also requires that when you ship 2 pieces of software
together that are highly interdependent as one whole (even when they're
not derived works), that the entire whole is GPL licensed.

Yes the GPL is quite viral....


> 
> 



From buildsys at redhat.com  Fri Nov 18 12:35:00 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 18 Nov 2005 07:35:00 -0500
Subject: rawhide report: 20051118 changes
Message-ID: <200511181235.jAICZ0Qv010753@porkchop.devel.redhat.com>

 

 
Updated Packages:

GFS-kernel-2.6.14.0-20051108.134753.FC5.9
-----------------------------------------

anaconda-10.90.4-1
------------------
* Thu Nov 17 2005 Jeremy Katz <katzj at redhat.com> - 10.90.4-1
- don't traceback on unresolvable deps (#173508)
- fix pkg.arch for %packages
- another hack for vnc
- debug prints to log.debug (#173533)

* Thu Nov 17 2005 Paul Nasrat <pnasrat at redhat.com> - 10.90.3-1
- Add group processing to buildinstall
- Add createrepo requires

* Thu Nov 17 2005 Jeremy Katz <katzj at redhat.com> - 10.90.2-1
- more pkgorder fixing (clumens)
- fix cd installs to not fall into the "not a real install method" case :)

cman-kernel-2.6.14.0-20051108.134753.FC5.7
------------------------------------------

createrepo-0.4.3-3.1
--------------------
* Thu Nov 17 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-3.1
- really fix them

* Thu Nov 17 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-3
- Fix regressions for absolute/relative paths

dlm-kernel-2.6.14.0-20051108.134753.FC5.9
-----------------------------------------

filesystem-2.3.7-1
------------------
* Thu Nov 17 2005 Bill Nottingham <notting at redhat.com> - 2.3.7-1
- actually, *do* package /usr/lib/X11 and /usr/bin/X11, but as
  directories (#173384)
- remove /usr/X11R6 heirarchy

fontconfig-2.3.92-3
-------------------
* Wed Nov 16 2005 Bill Nottingham <notting at redhat.com> - 2.3.93-3
- modular X moved fonts from /usr/X11R6/lib/X11/fonts to
  /usr/share/X11/fonts, adjust %configure accordingly and 
  conflict with older font packages

fonts-chinese-3.02-4
--------------------
* Thu Nov 17 2005 Warren Togami <wtogami at redhat.com> - 3.02-4
- req(foo,bar) syntax breaks erasure ordering

fonts-japanese-0.20050222-11
----------------------------
* Thu Nov 17 2005 Warren Togami <wtogami at redhat.com> - 0.20050222-11
- split req(foo,bar) for erasure ordering

fonts-korean-1.0.11-9
---------------------
* Thu Nov 17 2005 Warren Togami <wtogami at redhat.com> - 1.0.11-9
- split req(foo,bar) for erasure ordering

gnbd-kernel-2.6.14.0-20051108.134753.FC5.11
-------------------------------------------

kernel-2.6.14-1.1688_FC5
------------------------
* Thu Nov 17 2005 David Woodhouse <dwmw2 at redhat.com>
- Disable HFC USB again since it's not fixed in -git3

* Thu Nov 17 2005 Stephen Tweedie <sct at redhat.com>
- 2.6.15-rc1-git3

* Thu Nov 17 2005 David Woodhouse <dwmw2 at redhat.com>
- Disable CONFIG_RTC on ppc64. It's CONFIG_GEN_RTC now
- Use anticipatory I/O scheduler by default. CFQ appears broken.

krb5-1.4.3-1
------------
* Thu Nov 17 2005 Nalin Dahyabhai <nalin at redhat.com> 1.4.3-1
- update to 1.4.3
- make ksu setuid again (#137934, others)

python-pyblock-0.6-1
--------------------
* Thu Nov 17 2005 Peter Jones <pjones at redhat.com> - 0.6-1
- fix RaidSets/getRaidSets

* Wed Nov 16 2005 Peter Jones <pjones at redhat.com> - 0.5-2
- rebuild for newer libdevmapper.a

* Fri Nov 11 2005 Peter Jones <pjones at redhat.com> - 0.5-1
- make it possible to easily build dm maps from dmraid tables
- support for partition table scanning

urw-fonts-2.3-5
---------------
* Thu Nov 17 2005 Than Ngo <than at redhat.com> 2.3-5
- fix the mkfontdir issue for modular X
- remove unneeded -e option from mkfontdir
- add Prereq on mkfontdir

* Thu Nov 17 2005 Warren Togami <wtogami at redhat.com> 2.3-4
- req mkfontdir
- better way to run mkfontdir

* Thu Nov 17 2005 Than Ngo <than at redhat.com> 2.3-3 
- fix mkfontdir macro for modular X

xorg-x11-proto-devel-0.99.2-2
-----------------------------
* Thu Nov 17 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-2
- Change Conflicts to "Obsoletes: XFree86-devel, xorg-x11-devel"

xorg-x11-server-0.99.3-6
------------------------
* Thu Nov 17 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-6
- Add the missing rpm pre script from monolithic xorg-x11 packaging,
  clean it up a bit, reorder it for slight performance gain.
- Add some perl magic to pre script to remove RgbPath from xorg.conf,
  in order to fix bug (#173036, 173435, 173453, 173428)
- Add more perl magic to pre script to update ModulePath to the new
  location if it is specified in xorg.conf.
- Added xorg-x11-server-0.99.3-init-origins-fix.patch ported from monolithic
  xorg-x11 package to fix Xinerama bug.
- Added xorg-redhat-die-ugly-pattern-die-die-die.patch to kill the ugly grey
  stipple once again for bug (#173423).
- Added "BuildRequires: libdrm-devel" for DRI enabled builds.

xterm-207-2
-----------




Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires /lib/modules/2.6.13-1.1532_FC4
	GFS-kernel - 2.6.11.8-20050601.152643.FC4.18.ppc requires kernel = 0:2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc requires kernel = 0:2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for ppc64
----------------------------------------------------------
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	cman-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	dlm-kernel - 2.6.11.5-20050601.152643.FC4.15.ppc64 requires kernel = 0:2.6.13-1.1532_FC4
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires /lib/modules/2.6.13-1.1532_FC4
	gnbd-kernel - 2.6.11.2-20050420.133124.FC4.51.ppc64 requires kernel = 0:2.6.13-1.1532_FC4



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390x requires dmraid



From ellson at research.att.com  Fri Nov 18 12:43:53 2005
From: ellson at research.att.com (John Ellson)
Date: Fri, 18 Nov 2005 07:43:53 -0500
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <20051118111525.GA6287@ryoko.camperquake.de>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<20051118111525.GA6287@ryoko.camperquake.de>
Message-ID: <437DCC89.2080004@research.att.com>

Ralf Ertzinger wrote:
> On Fri, Nov 18, 2005 at 01:18:51PM +0300, Peter Lemenkov wrote:
>
>   
>> Looks like someone hardcoded xauth to
>>
>> /usr/X11R6/bin/xauth
>>
>> Frankly speaking I think that's a good idea to make this symlink, until 
>> all issues, concerned with modular Xorg, will be resolved.
>>     
>
> Bug in openssh. Want to file a bug?
>
>   
Already reported.  Bug # 173414



From alan at redhat.com  Fri Nov 18 13:02:00 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 08:02:00 -0500
Subject: ZFS.
In-Reply-To: <1132316150.2830.64.camel@laptopd505.fenrus.org>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
	<1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
	<1132316150.2830.64.camel@laptopd505.fenrus.org>
Message-ID: <20051118130200.GD21553@devserv.devel.redhat.com>

On Fri, Nov 18, 2005 at 01:15:49PM +0100, Arjan van de Ven wrote:
> kernel, especially when integrated with the kernel. The GPL requires
> derived works to be GPL licensed; not "compatible" like BSD, but GPL
> licensed. The GPL also requires that when you ship 2 pieces of software

Common confusion.

The GPL requires the work as a whole must meet the GPL license.

| These requirements apply to the modified work as a whole.  If
| identifiable sections of that work are not derived from the Program,
| and can be reasonably considered independent and separate works in
| themselves, then this License, and its terms, do not apply to those
| sections when you distribute them as separate works.  But when you
| distribute the same sections as part of a whole which is a work based
| on the Program, the distribution of the whole must be on the terms of
| this License, whose permissions for other licensees extend to the
| entire whole, and thus to each and every part regardless of who wrote it.

You can do that combining non advertising clause BSD and GPL code. In doing
so you create a work that must now be used according to the terms of the GPL.
Equally you have no effect on the case where one can reasonably be a seperate
work and distributed seperately - which is what most legal systems enforce
anyway.

The kernel contains large amounts of code that has come legally from BSD
licensed sources and is now part of the kernel and thus must be treated in
GPL manner.


I've not looked in detail at the CDDL itself but there are many problems with
BSD like licenses (such as the lack of patent grant guarantees) and I would
suggest discussing the matter with US lawyers or the FSF



From petro at mail.ru  Fri Nov 18 12:48:20 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 15:48:20 +0300
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <1132312828.2830.56.camel@laptopd505.fenrus.org>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<1132312828.2830.56.camel@laptopd505.fenrus.org>
Message-ID: <Pine.LNX.4.64.0511181528500.6294@lemenkov.com>

On Fri, 18 Nov 2005, Arjan van de Ven wrote:

>> Frankly speaking I think that's a good idea to make this symlink, until
>> all issues, concerned with modular Xorg, will be resolved.

> problem is.. if compat symlinks are made.. the issues will never get
> reported and thus not resolved....

Understand your concerns, but still think that this symlink is necesary.

Please note, that *all* openssh-clients at the whole Planet use hardcoded 
path to xauth, and only Fedora Core switches to the modular X. Can we 
enforce all of 'em to use new, patched ssh-client? Even theoretically?

And one more: of course end-users never found this bug (and some others, 
no doubts), if we allow such workaround, so what? That's a good news for 
average Joe, that he will never discovers such issue using its good old 
software.

-- 
With best regards, Peter Lemenkov.




From fedora at camperquake.de  Fri Nov 18 13:14:46 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 18 Nov 2005 14:14:46 +0100
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181528500.6294@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<1132312828.2830.56.camel@laptopd505.fenrus.org>
	<Pine.LNX.4.64.0511181528500.6294@lemenkov.com>
Message-ID: <20051118131446.GB6287@ryoko.camperquake.de>

On Fri, Nov 18, 2005 at 03:48:20PM +0300, Peter Lemenkov wrote:

> Please note, that *all* openssh-clients at the whole Planet use hardcoded 
> path to xauth, and only Fedora Core switches to the modular X. Can we 
> enforce all of 'em to use new, patched ssh-client? Even theoretically?

I *think* (not having looked at the code) that xauth is being called by
the ssh daemon.



From tmus at tmus.dk  Fri Nov 18 13:30:01 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 18 Nov 2005 14:30:01 +0100
Subject: some artwork needs to be replaced...?
Message-ID: <dlkl13$oik$1@sea.gmane.org>

Hi all...

before going any further, let me just say that I'm not out to start a 
flame war or put hard working people down. I want to bring this forward 
to ensure everybody's favorite distro is appealing as it deserves "out 
of the box".


Am I alone in thinking that some of the icons and the default mouse 
cursors appearing in rawhide could really use a redesign or should just 
be replaced with something else?

Perhaps these are only temporarily, which i really hope, but just in 
case they are not, i wanted to see if perhaps it's just me.

The two main things that have come to my attention (mainly because it 
pretty much hits you on login) are the new fedora logos and the new 
default mouse cursor theme.


This is my opinion on the mouse cursor theme:

** the default mouse cursor theme should be neutral (no colors, subtle 
animation), good looking and functional.

Although used by some other distributions, Jimmac's jimmac0 (if that's 
indeed the right name) mouse cursors makes for a very nice choice for 
the default mouse cursor theme.


This is my opinion regarding the icons

** all the icons appearing on the default desktop, should be 
informational, good looking and in a consistent design - Just like all 
of the icons in the bluecurve theme.

The new fedora-logo does not fit in with the rest and IMHO should be 
either reconsidered or redesigned.


I hope I'm not the only one feeling like this.
And I hope we will be able to have all this sorted out before FC5 is 
released.

Thanks

/Thomas



From j.w.r.degoede at hhs.nl  Fri Nov 18 13:48:15 2005
From: j.w.r.degoede at hhs.nl (Hans de Goede)
Date: Fri, 18 Nov 2005 14:48:15 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlkl13$oik$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org>
Message-ID: <437DDB9F.9050405@hhs.nl>

+1

Thomas M Steenholdt wrote:
> Hi all...
> 
> before going any further, let me just say that I'm not out to start a 
> flame war or put hard working people down. I want to bring this forward 
> to ensure everybody's favorite distro is appealing as it deserves "out 
> of the box".
> 
> 
> Am I alone in thinking that some of the icons and the default mouse 
> cursors appearing in rawhide could really use a redesign or should just 
> be replaced with something else?
> 
> Perhaps these are only temporarily, which i really hope, but just in 
> case they are not, i wanted to see if perhaps it's just me.
> 
> The two main things that have come to my attention (mainly because it 
> pretty much hits you on login) are the new fedora logos and the new 
> default mouse cursor theme.
> 
> 
> This is my opinion on the mouse cursor theme:
> 
> ** the default mouse cursor theme should be neutral (no colors, subtle 
> animation), good looking and functional.
> 
> Although used by some other distributions, Jimmac's jimmac0 (if that's 
> indeed the right name) mouse cursors makes for a very nice choice for 
> the default mouse cursor theme.
> 
> 
> This is my opinion regarding the icons
> 
> ** all the icons appearing on the default desktop, should be 
> informational, good looking and in a consistent design - Just like all 
> of the icons in the bluecurve theme.
> 
> The new fedora-logo does not fit in with the rest and IMHO should be 
> either reconsidered or redesigned.
> 
> 
> I hope I'm not the only one feeling like this.
> And I hope we will be able to have all this sorted out before FC5 is 
> released.
> 
> Thanks
> 
> /Thomas
> 



From jspaleta at gmail.com  Fri Nov 18 13:42:42 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 18 Nov 2005 08:42:42 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <437DDB9F.9050405@hhs.nl>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
Message-ID: <604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>

On 11/18/05, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> +1

-5

-jef"I have an opinion! And its different! News at 11!"spaleta



From alan at redhat.com  Fri Nov 18 13:48:21 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 08:48:21 -0500
Subject: ZFS.
In-Reply-To: <1132291200.3409.6.camel@localhost>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<437D5468.8010006@n-man.com> <1132291200.3409.6.camel@localhost>
Message-ID: <20051118134821.GE21553@devserv.devel.redhat.com>

On Thu, Nov 17, 2005 at 09:20:00PM -0800, Toshio Kuratomi wrote:
> classified as a derivative work.  If it's classified as a derivative
> work then it's in violation of the GPL whether or not it's distributed
> in the kernel, right?  IANAL and I am very tired at the moment so my
> chain of reasoning here could be totally specious.

Basically for a derivative work you must meet all the requirements of all
the licenses simultaneously. 

eg if you combine a work that is 'non commercial use' and a work that is
licensed 'for stage performance only' you end up with a work that is licensed
for non commercial stage performance only.



From tmus at tmus.dk  Fri Nov 18 14:07:25 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 18 Nov 2005 15:07:25 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
Message-ID: <dlkn6u$v8a$1@sea.gmane.org>

Jeff Spaleta wrote:
> On 11/18/05, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
>> +1
> 
> -5
> 
> -jef"I have an opinion! And its different! News at 11!"spaleta
> 

would you care to explain your opinion?

what makes the current rawhide versions of these things better that what 
we had in FC4 or something else?

/Thomas



From alan at redhat.com  Fri Nov 18 14:17:59 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 09:17:59 -0500
Subject: init: API
In-Reply-To: <1132266025.9736.3.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
Message-ID: <20051118141759.GF21553@devserv.devel.redhat.com>

On Fri, Nov 18, 2005 at 12:20:25AM +0200, Gilboa Davara wrote:
> C. Tends to create needlessly-complex data structures.

Its a tree. Nothing more than that.

> D. While can be accessed using shell scripts, it requires very complex
> and unreadable code.

or appropriate tools

> On the other hand, what does XML offer in return?

Rigorous syntax, no need to write another buggy config file parser for
each application, ability to merge configurations in a structured and
meaningful manner, common tools across configuration files, easy manipulation
by programs, expandability without invalidating old formats.

And a wide variety of other things.



From alan at redhat.com  Fri Nov 18 14:19:36 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 09:19:36 -0500
Subject: init: API
In-Reply-To: <437CEA72.1040201@cornell.edu>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<437CEA72.1040201@cornell.edu>
Message-ID: <20051118141936.GG21553@devserv.devel.redhat.com>

On Thu, Nov 17, 2005 at 03:39:14PM -0500, Paul A Houle wrote:
> authentication system.  This has an XML configuration file -- when we 
> add a new site,  we only need to change one parameter...  which is 
> entered twice into a 50-line block of XML.  We continuously have 
> problems when somebody edits the file,  doesn't respect tag nesting,  
> and the system breaks.

Hint. You are using the wrong tools

Use an xml editor and on saving use an xml verify tool before allowing the
change to be committed.



From fedora at camperquake.de  Fri Nov 18 14:25:57 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Fri, 18 Nov 2005 15:25:57 +0100
Subject: init: API
In-Reply-To: <20051118141936.GG21553@devserv.devel.redhat.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<437CEA72.1040201@cornell.edu>
	<20051118141936.GG21553@devserv.devel.redhat.com>
Message-ID: <20051118142557.GC6287@ryoko.camperquake.de>

On Fri, Nov 18, 2005 at 09:19:36AM -0500, Alan Cox wrote:

> Hint. You are using the wrong tools
> 
> Use an xml editor and on saving use an xml verify tool before allowing the
> change to be committed.

That may be right, but I still prefer being able to change basic system
settings using nothing more than a simple text editor, and without having
to count XML nesting levels each time I do so.



From cmadams at hiwaay.net  Fri Nov 18 14:41:30 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 18 Nov 2005 08:41:30 -0600
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
Message-ID: <20051118144130.GA1410190@hiwaay.net>

Once upon a time, Peter Lemenkov <petro at mail.ru> said:
> Looks like someone hardcoded xauth to
> 
> /usr/X11R6/bin/xauth

It isn't "hardcoded" exactly; it is found there by configure and the
path compiled in.

A rebuild of OpenSSH should fix this.
-- 
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 sundaram at redhat.com  Fri Nov 18 14:52:21 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 18 Nov 2005 20:22:21 +0530
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlkn6u$v8a$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org>
	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
	<dlkn6u$v8a$1@sea.gmane.org>
Message-ID: <437DEAA5.3000509@redhat.com>

Hi

>
> would you care to explain your opinion?
>
> what makes the current rawhide versions of these things better that 
> what we had in FC4 or something else?

Artwork is really subjective taste. I am not sure convincing everyone to 
use what you prefer as default would work. If you are into design, 
submit suggestions or mockups

http://fedoraproject.org/wiki/FedoraArt

regards
Rahul



From alan at redhat.com  Fri Nov 18 14:59:59 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 09:59:59 -0500
Subject: init observations
In-Reply-To: <20051116185811.GB20555@devserv.devel.redhat.com>
References: <80d7e4090511160956u1ab54623h95e6060bd62d13be@mail.gmail.com>
	<049701c5eade$47441290$b6491b31@td612671>
	<20051116185811.GB20555@devserv.devel.redhat.com>
Message-ID: <20051118145959.GP21553@devserv.devel.redhat.com>

On Wed, Nov 16, 2005 at 01:58:11PM -0500, Bill Nottingham wrote:
> It's disk seek on shared libraries, almost certianly. It's the majority
> of lag time on *any* startup these days, including the OS itself.

I doubt its the shared libraries that dominate. Not unless gnome has much
improved. The older traces I studied were dominated by the poorly designed
gconf system and the even more badly designed theme code. Simply packing
the themes using a trivial library I wrote reduced the cost of theme loading
to almost zero and reduced gnome memory usage by about 2MB/app

Perhaps Havoc can update on the state of the themes and gconf code

Alan



From alan at redhat.com  Fri Nov 18 15:02:26 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 10:02:26 -0500
Subject: init observations
In-Reply-To: <20051116171711.GI4989@devserv.devel.redhat.com>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116171711.GI4989@devserv.devel.redhat.com>
Message-ID: <20051118150226.GQ21553@devserv.devel.redhat.com>

On Wed, Nov 16, 2005 at 12:17:12PM -0500, Bill Nottingham wrote:
> > hotplug events anyhow, so why don't we delay modprobing
> > until after we start X, and treat them as hotplug events?
> 
> a) because X is dumb, and doesn't handle hotplug devices

a) if X is using /dev/input/* it doesnt need to know about the 
base keyboard/mouse



From jspaleta at gmail.com  Fri Nov 18 15:10:08 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 18 Nov 2005 10:10:08 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlkn6u$v8a$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
	<dlkn6u$v8a$1@sea.gmane.org>
Message-ID: <604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>

On 11/18/05, Thomas M Steenholdt <tmus at tmus.dk> wrote:
> would you care to explain your opinion?

I find them functional "enough" and good looking "enough" (except for
some minor defects that I have already filed bugs for but do not
require the cursors to be replaced with a different concept). I don't
see why colorless mouse icons are automatically better than colored
icons. We don't use the high constrast black&white menu/desktop icons
by default.  I didn't read anything in your opinion that was could not
be summarized as "personal taste". And with all matters of personal
taste...opinions differ and there will be no right answer.

And i certainly do not think that the red hat logo on the desktop that
we have enjoyed for so long, is any more appropriate or even more
informational than a separate fedora project logo. I think its very
important and very informational to be able to distinguish which
distribution you are using at a glance at the default desktop even
with windows open obscuring the wallpaper. The fedora logo on the
gnome panel finally makes a clearly visible distinction that someone
is on a fedora desktop and not on a rhel system.  As a matter of
function and informative content.. any fedora specific logo is a
change for the better.  And there is absolutely no point in arguing
about the style of the logo.. matters of style have no right answer
and the style of the logo isn't going to change.

-jef"suckered into yet another logo thread.... I should be forcible
removed from the mailinglists to prevent responding to another logo
thread"spaleta



From dravet at hotmail.com  Fri Nov 18 15:25:26 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Fri, 18 Nov 2005 09:25:26 -0600
Subject: large number of scriptlet errors from todays rawhide
Message-ID: <BAY103-F3115ACF3CAECBF192CA255DF5E0@phx.gbl>

I did a yum update this morning and there are several scriptlet errors.  
Should I put these errors in bugzilla?

Thanks,
Jason

Running Transaction
  Updating  : redhat-menus                 ##################### [  1/202]
error: %post(redhat-menus-5.0.6-1.noarch) scriptlet failed, exit status 255
  Updating  : glibc-common                 ##################### [  3/202]
error: %post(glibc-common-2.3.90-17.i386) scriptlet failed, exit status 255
  Updating  : glibc                        ##################### [  4/202]
error: %post(glibc-2.3.90-17.i686) scriptlet failed, exit status 255
  Updating  : fontconfig                   ##################### [  5/202]
error: %post(fontconfig-2.3.92-3.i386) scriptlet failed, exit status 255
  Updating  : libsepol                     ##################### [  6/202]
error: %post(libsepol-1.9.40-1.i386) scriptlet failed, exit status 255
  Updating  : libselinux                   ##################### [  7/202]
error: %post(libselinux-1.27.22-1.i386) scriptlet failed, exit status 255
  Updating  : gtk+                         ##################### [ 14/202]
error: %pre(glibc-headers-2.3.90-17.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping 
glibc-headers-2.3.90-17
  Updating  : parted                       ##################### [ 17/202]
error: %post(parted-1.6.25-3.i386) scriptlet failed, exit status 255
  Updating  : control-center               ##################### [ 18/202]
error: %post(control-center-2.12.1-4.i386) scriptlet failed, exit status 255
  Updating  : glibc-devel                  ##################### [ 21/202]
error: %post(glibc-devel-2.3.90-17.i386) scriptlet failed, exit status 255
error: %pre(xorg-x11-xfs-0.99.2-4.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping xorg-x11-xfs-0.99.2-4
  Updating  : krb5-workstation             ##################### [ 23/202]
error: %post(krb5-workstation-1.4.3-1.i386) scriptlet failed, exit status 
255
  Updating  : krb5-devel                   ##################### [ 24/202]
error: %pre(nscd-2.3.90-17.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping nscd-2.3.90-17
error: %pre(gdm-2.8.0.4-13.i386) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping gdm-2.8.0.4-13
  Updating  : urw-fonts                    ##################### [ 28/202]
error: %post(urw-fonts-2.3-5.noarch) scriptlet failed, exit status 255
  Updating  : kudzu                        ##################### [ 32/202]
error: %post(kudzu-1.2.13-1.i386) scriptlet failed, exit status 255
  Updating  : dhcdbd                       ##################### [ 36/202]
error: %post(dhcdbd-1.10-1.FC5.i386) scriptlet failed, exit status 255
  Updating  : filesystem                   ##################### [ 38/202]
error: %pre(kernel-2.6.14-1.1688_FC5.i686) scriptlet failed, exit status 255
error:   install: %pre scriptlet failed (2), skipping 
kernel-2.6.14-1.1688_FC5
  Installing: kernel-devel                 ##################### [ 40/202]
error: %post(kernel-devel-2.6.14-1.1688_FC5.i686) scriptlet failed, exit 
status 255
  Updating  : xorg-x11-drv-mouse           ##################### [ 44/202]
error: %pre(xorg-x11-server-Xorg-0.99.3-6.i386) scriptlet failed, exit 
status 255
error:   install: %pre scriptlet failed (2), skipping 
xorg-x11-server-Xorg-0.99.3-6
  Updating  : java-1.4.2-gcj-compat        ##################### [ 98/202]
error: %post(java-1.4.2-gcj-compat-1.4.2.0-40jpp_55rh.i386) scriptlet 
failed, exit status 255
  Updating  : gnu-crypto-sasl-jdk1.4       ##################### [ 99/202]
error: %post(gnu-crypto-sasl-jdk1.4-2.0.1-1jpp_8fc.i386) scriptlet failed, 
exit status 255
  Updating  : gnu-crypto-jce-jdk1.4        ##################### [100/202]
error: %post(gnu-crypto-jce-jdk1.4-2.0.1-1jpp_8fc.i386) scriptlet failed, 
exit status 255
  Updating  : gnu-crypto                   ##################### [101/202]
error: %post(gnu-crypto-2.0.1-1jpp_8fc.i386) scriptlet failed, exit status 
255
  Updating  : jessie                       ##################### [102/202]
error: %post(jessie-1.0.0-9.noarch) scriptlet failed, exit status 255




From brilong at cisco.com  Fri Nov 18 15:34:02 2005
From: brilong at cisco.com (Brian Long)
Date: Fri, 18 Nov 2005 10:34:02 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
	<dlkn6u$v8a$1@sea.gmane.org>
	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
Message-ID: <1132328043.4121.51.camel@brilong-lnx>

On Fri, 2005-11-18 at 10:10 -0500, Jeff Spaleta wrote:


How about a left-handed mouse theme?  Does one exist that I don't know
about?  Logitech includes a decent one in their Mouseware program for
Windoze.  I use left-handed mouse on various hosts and it sure would be
nice to have the arrow pointing from bottom-left to upper-right  :)

/Brian/
-- 
       Brian Long                      |         |           |
       IT Data Center Systems          |       .|||.       .|||.
       Cisco Linux Developer           |   ..:|||||||:...:|||||||:..
       Phone: (919) 392-7363           |   C i s c o   S y s t e m s



From stickster at gmail.com  Fri Nov 18 16:09:44 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Fri, 18 Nov 2005 11:09:44 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
	<dlkn6u$v8a$1@sea.gmane.org>
	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
Message-ID: <1132330184.5672.4.camel@localhost.localdomain>

On Fri, 2005-11-18 at 10:10 -0500, Jeff Spaleta wrote:
> And i certainly do not think that the red hat logo on the desktop that
> we have enjoyed for so long, is any more appropriate or even more
> informational than a separate fedora project logo. I think its very
> important and very informational to be able to distinguish which
> distribution you are using at a glance at the default desktop even
> with windows open obscuring the wallpaper. The fedora logo on the
> gnome panel finally makes a clearly visible distinction that someone
> is on a fedora desktop and not on a rhel system.  As a matter of
> function and informative content.. any fedora specific logo is a
> change for the better.  And there is absolutely no point in arguing
> about the style of the logo.. matters of style have no right answer
> and the style of the logo isn't going to change.

Agreed, FWIW, and I for one would like to see the new logo appear in the
FC4 branch (i.e. an update) to get everyone used to it... or at least
get the inevitable deluge of complaints out of the way to make way for
more appropriate traffic subsequent to the FC5 test releases.

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051118/fab622ff/attachment.sig>

From petro at mail.ru  Fri Nov 18 14:15:08 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 17:15:08 +0300
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <20051118131446.GB6287@ryoko.camperquake.de>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<1132312828.2830.56.camel@laptopd505.fenrus.org>
	<Pine.LNX.4.64.0511181528500.6294@lemenkov.com>
	<20051118131446.GB6287@ryoko.camperquake.de>
Message-ID: <Pine.LNX.4.64.0511181711580.18152@lemenkov.com>

On Fri, 18 Nov 2005, Ralf Ertzinger wrote:

>> Please note, that *all* openssh-clients at the whole Planet use hardcoded
>> path to xauth, and only Fedora Core switches to the modular X. Can we
>> enforce all of 'em to use new, patched ssh-client? Even theoretically?

> I *think* (not having looked at the code) that xauth is being called by
> the ssh daemon.

"Mea culpa!"
Sure, it's called by the sshd.

[petro at Petro ~]$ strings /usr/sbin/sshd | grep X11R6
/usr/X11R6/bin/xauth
[petro at Petro ~]$


-- 
With best regards, Peter Lemenkov.




From sundaram at redhat.com  Fri Nov 18 16:10:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 18 Nov 2005 21:40:58 +0530
Subject: some artwork needs to be replaced...?
In-Reply-To: <1132328043.4121.51.camel@brilong-lnx>
References: <dlkl13$oik$1@sea.gmane.org>
	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>	<dlkn6u$v8a$1@sea.gmane.org>	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
	<1132328043.4121.51.camel@brilong-lnx>
Message-ID: <437DFD12.50904@redhat.com>

Brian Long wrote:

>On Fri, 2005-11-18 at 10:10 -0500, Jeff Spaleta wrote:
>
>
>How about a left-handed mouse theme?  Does one exist that I don't know
>about?  Logitech includes a decent one in their Mouseware program for
>Windoze.  I use left-handed mouse on various hosts and it sure would be
>nice to have the arrow pointing from bottom-left to upper-right  :)
>  
>
Filed a enhancement request. 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173603

Thanks,

regards
Rahul



From wtogami at redhat.com  Fri Nov 18 16:21:39 2005
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 18 Nov 2005 11:21:39 -0500
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181711580.18152@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>	<1132312828.2830.56.camel@laptopd505.fenrus.org>	<Pine.LNX.4.64.0511181528500.6294@lemenkov.com>	<20051118131446.GB6287@ryoko.camperquake.de>
	<Pine.LNX.4.64.0511181711580.18152@lemenkov.com>
Message-ID: <437DFF93.90108@redhat.com>

Peter Lemenkov wrote:
> On Fri, 18 Nov 2005, Ralf Ertzinger wrote:
> 
>>> Please note, that *all* openssh-clients at the whole Planet use 
>>> hardcoded
>>> path to xauth, and only Fedora Core switches to the modular X. Can we
>>> enforce all of 'em to use new, patched ssh-client? Even theoretically?
> 
> 
>> I *think* (not having looked at the code) that xauth is being called by
>> the ssh daemon.
> 
> 
> "Mea culpa!"
> Sure, it's called by the sshd.
> 
> [petro at Petro ~]$ strings /usr/sbin/sshd | grep X11R6
> /usr/X11R6/bin/xauth
> [petro at Petro ~]$

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173568
I tried to fix openssh last night, but it fails to build because modular 
X seems to be missing gccmakedep that previously was in xorg-x11-devel. 
  I am attempting to get gccmakedep back, but we may have run out of time.

Warren Togami
wtogami at redhat.com



From razvan.vilt at linux360.ro  Fri Nov 18 16:46:09 2005
From: razvan.vilt at linux360.ro (=?iso-8859-2?Q?R=E3zvan?= Corneliu C.R. "d3vi1" VILT)
Date: Fri, 18 Nov 2005 18:46:09 +0200
Subject: init: API
In-Reply-To: <1132266025.9736.3.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
Message-ID: <1132332369.4597.27.camel@ns1.htpassport.ro>

On Fri, 2005-11-18 at 00:20 +0200, Gilboa Davara wrote: 

> I, too, second the "anything but XML" statement.
> A. Hard to read.
> B. Hard to edit using non-XML editors. (vim in my case)
> C. Tends to create needlessly-complex data structures.
> D. While can be accessed using shell scripts, it requires very complex
> and unreadable code.
> 
> On the other hand, what does XML offer in return?
> 
> Gilboa
> 

I don't second that. Today XML is the format everybody uses. Why?
Because it's a standardised way to put any kind of information in a
text-file.
A. Depends on how the schema is created. XML files can be easy to read
or dificult. Identing the xml code always helps.
B. Colored syntax always helps. That's all you usually need. At least
it's enough for me. I must say that Midnight Commander seems to work
with XML a little better.
C. Depends on the schema.
D. It does not require complex code, it requires well designed tools. In
a XML based init world, you would need chkconfig and other tools. XML
authoring should be done only by the package maintainers. The rest
should be doable by external tools which share a common API.

XML could help major projects such as the directory server bypass the
limitations of the current sysvinit. Check the problems with the
currently proposed init scripts in the fedora-ds wiki.
I've included in this email a demo of a service configuration file for
Sun SMF. Don't worry, it's not CDDL-ed. You are not contaminated if you
read this.
The interesting stuff this file brings:
1) Internationalize the service descriptions (the xml:lang attribute is
a dream for i18n in this case).
2) Include information about the documentation.
3) Include dependency information.
4) Include the start-up and shutdown commands.
There are a lot of other things that can be done using this XML file.
These are just a few of the ones that I consider important. I've added
gEdit style syntax color in the HTML version ;-).

Cheers,
Razvan

<service name='system/coreadm' type='service' version='1'>
   <create_default_instance enabled='false' />
    <single_instance />
    <dependency name='usr' grouping='require_all' restart_on='none'
type='service'>
        <service_fmri value='svc:/system/filesystem/minimal'/>
    </dependency>
    <exec_method type='method' name='start' exec='/usr/bin/coreadm -u'
timeout_seconds='3' />
    <exec_method type='method' name='stop' exec=':true'
timeout_seconds='0' />
    <property_group name='startd' type='framework'>
        <propval name='duration' type='astring' value='transient' />
    </property_group>
    <stability value='Unstable' />
    <template>
        <common_name><loctext xml:lang='C'>
            System-wide core file configuration service.
        </loctext></common_name>
        <documentation>
            <manpage title='coreadm' section='1M'
manpath='/usr/share/man' />
        </documentation>
    </template>
</service>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051118/45ed327f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-4.png
Type: image/png
Size: 822 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051118/45ed327f/attachment.png>

From razvan.vilt at linux360.ro  Fri Nov 18 17:06:26 2005
From: razvan.vilt at linux360.ro (=?iso-8859-2?Q?R=E3zvan?= Corneliu C.R. "d3vi1" VILT)
Date: Fri, 18 Nov 2005 19:06:26 +0200
Subject: init observations
In-Reply-To: <028701c5ea29$404130a0$b6491b31@td612671>
References: <20051115204405.GA18220@lewk.org>
	<028701c5ea29$404130a0$b6491b31@td612671>
Message-ID: <1132333586.4597.37.camel@ns1.htpassport.ro>

On Tue, 2005-11-15 at 16:12 -0500, Dimi Paun wrote:

> From: "Luke Macken" <lmacken at redhat.com>
> >  o FAST AS HELL[0]
> 
> 
> Fast, but can we do better? Why do we need to bring up
> the networking before we start X? Also, is it feasible
> to probe for just some hardware (disk, video), start x,
> then continue with the hardware probing? Will it be any
> faster if we get rid of the wrappers? Would readahead
> help here at all?
> 
> Basically, can we have X up in 10s? :)

We sometimes need X to have network connectivity. The reason is a simple
one:
X is a network protocol and X is used to login remotely to other hosts.
GDM can query these hosts using XDM Broadcast iirc.
We also might need the authentication system to be up and running. That
can be LDAP or Kerberos or Samba or something else, which might require
network support.
There are many reasons I can think of that require network to be started
first. But it's mainly for the ones that I can't think of right now that
I hope we can get Network Support before X.
I doubt that we can have X up in 10s in some cases.
In my case I have to start 2 ethernet interfaces and 10 vlans and 4 vpn
and one pppoe connection before I get network support. Load the firewall
and start the quagga-bgp daemon. This will always take more than 10
seconds. After that the LDAP support must come up. And only then I am
willing to talk about GDM.
Then again, one that does not have all these to worry about, would be
fine having X start before network and LDAP.

Cheers,
Razvan

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

From notting at redhat.com  Fri Nov 18 17:29:47 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 18 Nov 2005 12:29:47 -0500
Subject: init observations
In-Reply-To: <20051118150226.GQ21553@devserv.devel.redhat.com>
References: <20051115211419.GB13874@devserv.devel.redhat.com>
	<031901c5ea36$d6d8c070$b6491b31@td612671>
	<20051116171711.GI4989@devserv.devel.redhat.com>
	<20051118150226.GQ21553@devserv.devel.redhat.com>
Message-ID: <20051118172947.GB3720@devserv.devel.redhat.com>

Alan Cox (alan at redhat.com) said: 
> On Wed, Nov 16, 2005 at 12:17:12PM -0500, Bill Nottingham wrote:
> > > hotplug events anyhow, so why don't we delay modprobing
> > > until after we start X, and treat them as hotplug events?
> > 
> > a) because X is dumb, and doesn't handle hotplug devices
> 
> a) if X is using /dev/input/* it doesnt need to know about the 
> base keyboard/mouse

Until the upstream input developers have their way and remove
the /dev/input/mice multiplexor. I think they've been convinced
to wait for now...

Bill



From dimi at lattica.com  Fri Nov 18 17:33:39 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 18 Nov 2005 12:33:39 -0500
Subject: init observations
References: <20051115204405.GA18220@lewk.org><028701c5ea29$404130a0$b6491b31@td612671>
	<1132333586.4597.37.camel@ns1.htpassport.ro>
Message-ID: <02a801c5ec66$36ebf5a0$b6491b31@td612671>

From: "R?zvan Corneliu C.R. "d3vi1" VILT" <razvan.vilt at linux360.ro>
> Then again, one that does not have all these to worry about, would be
> fine having X start before network and LDAP.

And this is the point, one should not pay for something they don't use.
We have two alternatives to get that:
  1. Have the init be flexible enough so that it can easily start X before
      the network if at all possible.

  2. Have an API so that software can wait for things. This way you can
      start X, and if it reaches some code that needs networking (for XDMCP
      for example), it can just say "wait for networking to be up".

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From lamont at gurulabs.com  Fri Nov 18 17:44:19 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 18 Nov 2005 10:44:19 -0700
Subject: init: API
In-Reply-To: <1132332369.4597.27.camel@ns1.htpassport.ro>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
Message-ID: <200511181044.24125.lamont@gurulabs.com>

On Friday 18 November 2005 09:46am, R?zvan Corneliu C.R. "d3vi1" VILT wrote:
> On Fri, 2005-11-18 at 00:20 +0200, Gilboa Davara wrote:
> > I, too, second the "anything but XML" statement.
> > A. Hard to read.
> > B. Hard to edit using non-XML editors. (vim in my case)
> > C. Tends to create needlessly-complex data structures.
> > D. While can be accessed using shell scripts, it requires very complex
> > and unreadable code.
> >
> > On the other hand, what does XML offer in return?
> >
> > Gilboa
>
> I don't second that. Today XML is the format everybody uses. Why?
> Because it's a standardised way to put any kind of information in a
> text-file.

No.  Everybody uses it because product managers come along and say we have to 
have XML on "the box" or because programmers are too lazy to write a parser.

Don't get me wrong...XML is *wonderful* for certain things.  Configuration 
files for UNIX/Linux daemons is not one of them.

> A. Depends on how the schema is created. XML files can be easy to read
> or dificult. Identing the xml code always helps.

Exactly right.  Unfortunately, 99% of it seems to go to the "difficult" end of 
the scale.

> B. Colored syntax always helps. That's all you usually need. At least
> it's enough for me. I must say that Midnight Commander seems to work
> with XML a little better.

I haven't tried it with mc, but I agree...chromacoding is (almost) always 
helpful for any kind of text file; shell scripts, C/C++, perl, XML, 
httpd.conf, /etc/fstab, DNS zone files, etc., etc., etc.  XML is not special 
in this regard.

Also, I will reiterate what others have pointed out, properly indenting (using 
tabs/indents and NOT spaces) is extremely helpful.  Yeah, I know; in some 
groups of users, good luck defining "properly" in that statement.

> C. Depends on the schema.

Right; unfortunately, people tend to simply extend the schema at any whim.  
For a project with such far reaching implications as 

> D. It does not require complex code, it requires well designed tools. In
> a XML based init world, you would need chkconfig and other tools. XML
> authoring should be done only by the package maintainers. The rest
> should be doable by external tools which share a common API.

Basic UNIX Philosophy:  All configuration is in plain-text; all you need is a 
plain text editor to configure anything.

I use vi/vim for almost all my text editing (Kdevelop & kate for some of my 
programming stuff), but someone should be able to whip out joe or pico/nano 
or (gasp!) notepad over SMB and be able to easily 

This is not always 100% true (mostly commercial apps, like an RDBMS).  You 
might say XML is plain-text...well, I would say that XML is text, but not 
plain.  Look at some of the other respondents comments in this thread; XML is 
not easy.  It CAN be but almost never is.

> XML could help major projects such as the directory server bypass the
> limitations of the current sysvinit. Check the problems with the
> currently proposed init scripts in the fedora-ds wiki.

I haven't had time to look at any of that, yet.  If I find some spare time 
laying around, I will.  Until then, I can not intelligently comment.  Of 
course, I could just unintelligently comment now, but I'm not sure how to 
blow raspberries in email (just kidding).

> I've included in this email a demo of a service configuration file for
> Sun SMF. Don't worry, it's not CDDL-ed. You are not contaminated if you
> read this.

Funny that you included this example.  Though I have not yet had any direct 
experience with this, you are the first person (outside of Sun) from whom I 
have read anything positive about this.  It seems clear that the vast 
majority (of the email vocal component, of course) of the UNIX/Linux 
sys-admin world thinks Sun *way* screwed this up.

> The interesting stuff this file brings:
> 1) Internationalize the service descriptions (the xml:lang attribute is
> a dream for i18n in this case).
> 2) Include information about the documentation.
> 3) Include dependency information.
> 4) Include the start-up and shutdown commands.

We can accomplish all of this already today without XML.

> There are a lot of other things that can be done using this XML file.
> These are just a few of the ones that I consider important. I've added
> gEdit style syntax color in the HTML version ;-).

To sum up my viewpoint:  XML is appropriate, but not necessarily the best 
choice, when the data to be encoded naturally falls into a tree structure.  
There are other "corner" cases where XML could also be appropriate.

The perceived and real complexities in editing XML without breaking stuff 
would be enough to put sys-admins off over it.  Although any 
new-way-of-doing-things will cause growing pains as everybody learns the new 
way, in this case the negative effects are going to be amplified to everyone 
who uses FC & RHEL.

A SysV Init replacement is not an appropriate application for XML...outside of 
dependency relationships, there is nothing that is even close to a tree 
structure.  Also, it would be very difficult with XML to represent some of 
the odd dependency relationships; see the Apache & Tomcat example earlier in 
this thread, for one.  IMHO, XML would be a big mistake in this instance.

Whatever system we do come up with should use plain text, shell scripts and 
have tools like chkconfig ported to "just work".

Here's a really simple idea: change the rc?.d/S## & K## numbers to all be the 
same for those things that can be started or stopped in parallel (so all the 
S11* 's go together) and have an init or rc (even better) that can decide 
about dependencies amongst all the "S11*" services by looking at the LSB info 
in the SysV Init scripts.  Yeah, I know not the best way to represent the 
dependencies, but this solution has the advantage of only needing to modify 
either rc or init a little bit and still being "LSB compliant".  Go ahead; 
shoot holes in this idea, it's just off-the-cuff anyway.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051118/19e56a9a/attachment.sig>

From lamont at gurulabs.com  Fri Nov 18 17:49:42 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Fri, 18 Nov 2005 10:49:42 -0700
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
Message-ID: <200511181049.46383.lamont@gurulabs.com>

On Friday 18 November 2005 03:18am, Peter Lemenkov wrote:
> Hello, All!
[snip]
> Frankly speaking I think that's a good idea to make this symlink, until
> all issues, concerned with modular Xorg, will be resolved.

I would be concerned about opening that floodgate.  If we do, then there is no 
reason for people to care to fix their code.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051118/35691bfe/attachment.sig>

From jkeating at j2solutions.net  Fri Nov 18 17:57:19 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 18 Nov 2005 09:57:19 -0800
Subject: ZFS.
In-Reply-To: <1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
	<1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
Message-ID: <1132336639.6192.167.camel@prometheus.gamehouse.com>

On Fri, 2005-11-18 at 13:08 +0100, Stefan Held wrote:
> I did not get the point where the CDDL is GPL incompatible.
> Maybe you mean the GPL does not allow to have other licenses.

As found at http://www.gnu.org/philosophy/license-list.html


Common Development and Distribution License (CDDL)
        
        This is a free software license which is not a strong copyleft;
        it has some complex restrictions that make it incompatible with
        the GNU GPL. It requires that all attribution notices be
        maintained, while the GPL only requires certain types of
        notices. Also, it terminates in retaliation for certain
        aggressive uses of patents. So, a module covered by the GPL and
        a module covered by the CDDL cannot legally be linked together.
        We urge you not to use the CDDL for this reason.
        
        Also unfortunate in the CDDL is its use of the term
        "intellectual property"
        

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From ph18 at cornell.edu  Fri Nov 18 18:04:53 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Fri, 18 Nov 2005 13:04:53 -0500
Subject: init: API
In-Reply-To: <200511181044.24125.lamont@gurulabs.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<200511181044.24125.lamont@gurulabs.com>
Message-ID: <437E17C5.2040102@cornell.edu>


>No.  Everybody uses it because product managers come along and say we have to 
>have XML on "the box" or because programmers are too lazy to write a parser.
>
>Don't get me wrong...XML is *wonderful* for certain things.  Configuration 
>files for UNIX/Linux daemons is not one of them.
>  
>
    Just to add to the general bitch session,  I've seen XML add to 
mindless bloat in applications.

    I've recently had the misfortune of trying to get a modern GUI 
application running on Solaris 8,  which meant compiling about 20 packages.

    GTK depends on pango which depends on fontconfig which depends on expat.

    Other Gnome software depends on libxml.  So I end up having to load 
at least two XML parsers when I load my application.  I can easily see 
cases where I might end up loading three or four different XML parsers 
to support an application.

    Even people like Tim Bray have complained about the awkwardness of 
working with XML  APIs.

    When I wake up in a particularly evil mood,  I think about writing 
up an RFC for a proposal to reformulate Java in XML.  It would be as 
damaging as a worm that crashes the whole net -- I just see the armies 
of CEOs,  project managers,  computer book authors all marching to their 
doom...



From alan at redhat.com  Fri Nov 18 18:08:08 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 13:08:08 -0500
Subject: init: API
In-Reply-To: <437E17C5.2040102@cornell.edu>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<200511181044.24125.lamont@gurulabs.com>
	<437E17C5.2040102@cornell.edu>
Message-ID: <20051118180808.GA15703@devserv.devel.redhat.com>

On Fri, Nov 18, 2005 at 01:04:53PM -0500, Paul A Houle wrote:
>    Just to add to the general bitch session,  I've seen XML add to 
> mindless bloat in applications.

Not generally. The library is shared (unlike all those thousands of
homebrew config parsers)

>    Other Gnome software depends on libxml.  So I end up having to load 
> at least two XML parsers when I load my application.  I can easily see 

Thats not an XML problem but a GNOME problem (or an X one.. )

>    Even people like Tim Bray have complained about the awkwardness of 
> working with XML  APIs.

Some of them are disgusting, but that isnt an XML problem either.



From nphilipp at redhat.com  Fri Nov 18 19:23:01 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 18 Nov 2005 20:23:01 +0100
Subject: How to move package from extras to core ?
In-Reply-To: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
Message-ID: <1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>

On Wed, 2005-11-16 at 21:02 -0800, Ankit Patel wrote:

> I think almost 90% of people are satisfied with the default
> installation of Fedora core. Nobody wants to try new stuffs. So, it's
> good to provide them directly, then only they realize the importance
> of the application. That's the only reason i want it to move from
> extras to core.

I'd really like to abuse people of the notion that Extras were somehow
inferior to Core. I think this stems from that Extras packages are only
installable once the system is running -- if my memory doesn't betray
me, getting Extras installable directly from anaconda has been
discussed, have these discussions born any fruit?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From sundaram at redhat.com  Fri Nov 18 19:26:29 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 19 Nov 2005 00:56:29 +0530
Subject: Services enabled by default 
Message-ID: <437E2AE5.3080502@redhat.com>

Hi

There has been several services enabled by default in Fedora on the 
basic assumption that whoever doesnt need it can disable it by default 
while in many cases users who need it may not be aware of the 
requirements. Many services that are enabled by that are being done so 
for really non obvious reasons and has been the source of complaints. We 
should be documenting the rationale for each and every services thats 
being enabled for the different classes of installation. So here is what 
we need to work out, which of the services are enabled by default for 
the following installation options

* Personal Desktop
* Workstation
* Server
* Custom

If you are doing a new installation, development or one of the test 
releases, check this out and post to the list. If you dont see a good 
reason why a service needs to be enabled by default, question that. If 
we decide its not useful for the usual scenarios, file bug reports 
against the specific components in http://bugzilla.redhat.com to disable 
them and post the bug numbers to the list.

All of the discussion will be kept track in 
http://fedoraproject.org/wiki/DefaultServices

regards
Rahul



From dmalcolm at redhat.com  Fri Nov 18 19:28:20 2005
From: dmalcolm at redhat.com (David Malcolm)
Date: Fri, 18 Nov 2005 14:28:20 -0500
Subject: How to move package from extras to core ?
In-Reply-To: <1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
	<1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <1132342101.28651.22.camel@cassandra.boston.redhat.com>

On Fri, 2005-11-18 at 20:23 +0100, Nils Philippsen wrote:
> On Wed, 2005-11-16 at 21:02 -0800, Ankit Patel wrote:
> 
> > I think almost 90% of people are satisfied with the default
> > installation of Fedora core. Nobody wants to try new stuffs. So, it's
> > good to provide them directly, then only they realize the importance
> > of the application. That's the only reason i want it to move from
> > extras to core.
> 
> I'd really like to abuse people of the notion that Extras were somehow
> inferior to Core. I think this stems from that Extras packages are only
> installable once the system is running -- if my memory doesn't betray
> me, getting Extras installable directly from anaconda has been
> discussed, have these discussions born any fruit?


Errr....  being overly pedantic here, perhaps, but don't you mean
"disabuse", rather than "abuse" here?

Totally agree with your point though

Dave



From jkeating at j2solutions.net  Fri Nov 18 19:30:57 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 18 Nov 2005 11:30:57 -0800
Subject: How to move package from extras to core ?
In-Reply-To: <1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
	<1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <1132342257.6192.180.camel@prometheus.gamehouse.com>

On Fri, 2005-11-18 at 20:23 +0100, Nils Philippsen wrote:
> 
> I'd really like to abuse people of the notion that Extras were somehow
> inferior to Core. I think this stems from that Extras packages are only
> installable once the system is running -- if my memory doesn't betray
> me, getting Extras installable directly from anaconda has been
> discussed, have these discussions born any fruit?

The first step in this process is pretty much done, that is using yum in
anaconda instead of rpm.  For FC5 I do believe we are not going to allow
plugging into external repos for package installations at install time,
however that is I believe an expressed goal for FC6.  I'm sure somebody
will correct me if I'm wrong (:

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From sundaram at redhat.com  Fri Nov 18 19:33:49 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 19 Nov 2005 01:03:49 +0530
Subject: How to move package from extras to core ?
In-Reply-To: <1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
	<1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
Message-ID: <437E2C9D.6070306@redhat.com>

Nils Philippsen wrote:

>On Wed, 2005-11-16 at 21:02 -0800, Ankit Patel wrote:
>
>  
>
>>I think almost 90% of people are satisfied with the default
>>installation of Fedora core. Nobody wants to try new stuffs. 
>>
This is a interesting claim. How do we know which of the packages are 
being used in extras or core repository?. It would be curious to know 
the details. Even the download numbers from main would provide a good 
idea though its probably skewed by yum choosing a random mirror.

regards
Rahul



From katzj at redhat.com  Fri Nov 18 19:38:01 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 18 Nov 2005 14:38:01 -0500
Subject: Services enabled by default
In-Reply-To: <437E2AE5.3080502@redhat.com>
References: <437E2AE5.3080502@redhat.com>
Message-ID: <1132342681.4591.23.camel@bree.local.net>

On Sat, 2005-11-19 at 00:56 +0530, Rahul Sundaram wrote:
> We 
> should be documenting the rationale for each and every services thats 
> being enabled for the different classes of installation. So here is what 
> we need to work out, which of the services are enabled by default for 
> the following installation options
> 
> * Personal Desktop
> * Workstation
> * Server
> * Custom

Note that the install classes like this are no more.  The only
difference they made was package selection and so it'll be far better to
have something more descriptive than just vague terms in which 90% of
the users pick Custom because they think they know better ;-)

Jeremy



From nphilipp at redhat.com  Fri Nov 18 20:08:26 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Fri, 18 Nov 2005 21:08:26 +0100
Subject: How to move package from extras to core ?
In-Reply-To: <1132342101.28651.22.camel@cassandra.boston.redhat.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
	<1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
	<1132342101.28651.22.camel@cassandra.boston.redhat.com>
Message-ID: <1132344507.3624.46.camel@gibraltar.stuttgart.redhat.com>

On Fri, 2005-11-18 at 14:28 -0500, David Malcolm wrote:
> On Fri, 2005-11-18 at 20:23 +0100, Nils Philippsen wrote:
> > On Wed, 2005-11-16 at 21:02 -0800, Ankit Patel wrote:
> > 
> > > I think almost 90% of people are satisfied with the default
> > > installation of Fedora core. Nobody wants to try new stuffs. So, it's
> > > good to provide them directly, then only they realize the importance
> > > of the application. That's the only reason i want it to move from
> > > extras to core.
> > 
> > I'd really like to abuse people of the notion that Extras were somehow
> > inferior to Core. I think this stems from that Extras packages are only
> > installable once the system is running -- if my memory doesn't betray
> > me, getting Extras installable directly from anaconda has been
> > discussed, have these discussions born any fruit?
> 
> 
> Errr....  being overly pedantic here, perhaps, but don't you mean
> "disabuse", rather than "abuse" here?

Of course I mean disabuse. Thanks for pointing this out (really),
otherwise I'd be abusing people when I don't mean to ;-).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



From paul at cypherpunks.ca  Fri Nov 18 20:22:14 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Fri, 18 Nov 2005 21:22:14 +0100 (CET)
Subject: Services enabled by default
In-Reply-To: <1132342681.4591.23.camel@bree.local.net>
References: <437E2AE5.3080502@redhat.com>
	<1132342681.4591.23.camel@bree.local.net>
Message-ID: <Pine.LNX.4.63.0511182115330.16308@tla.xelerance.com>

On Fri, 18 Nov 2005, Jeremy Katz wrote:

> > * Personal Desktop
> > * Workstation
> > * Server
> > * Custom
>
> Note that the install classes like this are no more.  The only
> difference they made was package selection and so it'll be far better to
> have something more descriptive than just vague terms in which 90% of
> the users pick Custom because they think they know better ;-)

Custom was the only choice for "I only burned the first CD" :)

Seriously, I think a lot of people now only use the media to kickstart
the network install. Some "minimum" install I could take on a USB frob
and pull hte rest from the network would be ideal.
And with yum doing dependancies, the above categories also become mostly
only useful for people who do not know what there is or what they want.

Paul
-- 

"Happiness is never grand"

	--- Mustapha Mond, World Controller (Brave New World)



From andy.grover at gmail.com  Fri Nov 18 21:11:14 2005
From: andy.grover at gmail.com (Andrew Grover)
Date: Fri, 18 Nov 2005 13:11:14 -0800
Subject: How to move package from extras to core ?
In-Reply-To: <437E2C9D.6070306@redhat.com>
References: <20051117050247.75282.qmail@web34605.mail.mud.yahoo.com>
	<1132341782.3624.43.camel@gibraltar.stuttgart.redhat.com>
	<437E2C9D.6070306@redhat.com>
Message-ID: <c0a09e5c0511181311u57039d37j3dfec1ccb0c659d1@mail.gmail.com>

On 11/18/05, Rahul Sundaram <sundaram at redhat.com> wrote:
>
> >>I think almost 90% of people are satisfied with the default
> >>installation of Fedora core. Nobody wants to try new stuffs.
> >>
> This is a interesting claim. How do we know which of the packages are
> being used in extras or core repository?. It would be curious to know
> the details. Even the download numbers from main would provide a good
> idea though its probably skewed by yum choosing a random mirror.
>

Well Debian has popcon. http://popcon.debian.org/

If you really wanted to know, something like this would probably be the way
to do it. Or you could just look at Debian's results, being aware that
Fedora will not be exactly identical.

-- Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051118/fa54a56f/attachment.htm>

From jfrieben at freesurf.fr  Fri Nov 18 21:24:19 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Fri, 18 Nov 2005 22:24:19 +0100 (CET)
Subject: Savage DRI broken in modular X
Message-ID: <23315.194.94.224.254.1132349059.squirrel@jose.freesurf.fr>

There seems to be a problem with "mesa-libGL-6.4-4": Before
reinstalling my system today from "rawhide", I had used my
homebrewn, monolithic Xorg 6.9RC1 RPMs. Here, 3D acceleration
was excellent even for the latest rawhide tree before the
move to modular X. "(II) SAVAGE(0): Direct rendering enabled"
looks ok. However, it seems, that the Mesa tree has not been
adapted accordingly. Enabling verbose output, one obtains
for a rebuilt "ppracer" package the following output:

[test]$ env LIBGL_DEBUG=verbose /usr/bin/ppracer
PPRacer 0.3.1 --  http://racer.planetpenguin.de
(c) 2004-2005 The PPRacer team
(c) 1999-2001 Jasmin F. Patry<jfpatry at sunspirestudios.com>
PPRacer comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to redistribute it under certain conditions.
See http://www.gnu.org/copyleft/gpl.html for details.

libGL: XF86DRIGetClientDriverName: 2.0.2 savage (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed
(/usr/X11R6/lib/modules/dri/savage_dri.so: cannot open shared object file:
No such file or directory)
libGL error: unable to find driver: savage_dri.so

Why does it still look for "/usr/X11R6/lib/modules/dri/savage_dri.so"?
I have posted a bug report, see

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173679

Does anybody have some information on this issue?




From michel.salim at gmail.com  Fri Nov 18 23:12:26 2005
From: michel.salim at gmail.com (Michel Salim)
Date: Fri, 18 Nov 2005 18:12:26 -0500
Subject: Build error on devel: libSM dependency
In-Reply-To: <883cfe6d0511181455n393603ecs@mail.gmail.com>
References: <883cfe6d0511181455n393603ecs@mail.gmail.com>
Message-ID: <883cfe6d0511181512g6fe59860u@mail.gmail.com>

One of my package, grhino, fails to compile on devel because libSM has
been split from xorg into its own package, and none of the current
build dependencies include it.

The package (grhino) currently pulls its build dependencies from
desktop-file-utils (to handle the .desktop file), libgnomeui-devel and
scrollkeeper ; libgnomeui-devel depends on gtk2-devel, which in turns
(as of FC-4) depends on XFree86-devel.

So which package should I file a bug against - how are the X.org
dependencies supposed to be handled in the upcoming, modularized X
packaging?

Thanks,


--
Michel Salim ???
http://www.cs.indiana.edu/~msalim


--
Michel Salim ???
http://www.cs.indiana.edu/~msalim



From katzj at redhat.com  Fri Nov 18 23:22:52 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Fri, 18 Nov 2005 18:22:52 -0500
Subject: Build error on devel: libSM dependency
In-Reply-To: <883cfe6d0511181455n393603ecs@mail.gmail.com>
References: <883cfe6d0511181455n393603ecs@mail.gmail.com>
Message-ID: <1132356172.4591.41.camel@bree.local.net>

On Fri, 2005-11-18 at 17:55 -0500, Michel Salim wrote:
> One of my package, grhino, fails to compile on devel because libSM has
> been split from xorg into its own package, and none of the current
> build dependencies include it.
> 
> The package (grhino) currently pulls its build dependencies from
> desktop-file-utils (to handle the .desktop file), libgnomeui-devel and
> scrollkeeper ; libgnomeui-devel depends on gtk2-devel, which in turns
> (as of FC-4) depends on XFree86-devel.
> 
> So which package should I file a bug against - how are the X.org
> dependencies supposed to be handled in the upcoming, modularized X
> packaging?

libSM is almost certainly being pulled in for libgnomeui -- so that's
where the bug belongs

Jeremy



From suckfish at ihug.co.nz  Sat Nov 19 02:04:13 2005
From: suckfish at ihug.co.nz (Ralph Loader)
Date: Sat, 19 Nov 2005 15:04:13 +1300
Subject: 15 packages needing updates for modular X.
Message-ID: <1132365854.4266.6.camel@i.geek.nz>

Hi,

I ran the following to look for programs & libraries referencing the
old /usr/X11R6/ directories:


  find /usr/bin /usr/lib /usr/libexec -type f |
  while read X
  do
     strings "$X" | grep /X11R6 && echo -e "**** $X\n\n"
  done | tee X11R6.log


and then went through the output by hand looking for things that
actually need fixing (lots of things, e.g., search paths, are harmless
to still contain /usr/X11R6).

I came up with the following list.  I don't have every Fedora RPM
installed, so there are probably others.


   a2ps ghostscript htmlview openoffice libxklavier mesa ncurses openssh
   pyxf86config-0.3.22-1 SDL ttmkfdir valgrind xorg-x11-drv-ati-6.5.7-1
   xscreensaver


Details on the individual files are below.

Cheers,
Ralph.


a2ps:

$IBMFONTS="/usr/X11R6/lib/X11/fonts/Type1/cour*.pfa";
**** /usr/bin/ogonkify



ghostscript:

X11HOME=/usr/X11R6
**** /usr/bin/unix-lpr.sh


htmlview:

TERMS_GENERIC="/usr/bin/rxvt /usr/X11R6/bin/xterm /usr/bin/Eterm"
**** /usr/bin/htmlview


openoffice:

/usr/X11R6/lib/X11/fonts/truetype
/usr/X11R6/lib/X11/fonts/Type1
**** /usr/lib/openoffice.org2.0/program/libpsp680li.so


libxklavier:

-I/usr/X11R6/lib/X11/xkb
/usr/X11R6/lib/X11/xkb/rules/%s.xml
/usr/X11R6/lib/X11/xkb/rules/%s
/usr/X11R6/lib/X11/xkb/xkbcomp
**** /usr/lib/libxklavier.so.10.0.0


mesa:

/usr/X11R6/lib/modules/dri
**** /usr/lib/libGL.so.1.2


ncurses:

if [ -f /usr/X11R6/bin/resize ]; then
**** /usr/bin/resetall


openssh:

/usr/X11R6/bin/xauth
**** /usr/bin/ssh


pyxf86config-0.3.22-1:

/usr/X11R6
**** /usr/lib/python2.4/site-packages/ixf86configmodule.so


SDL:

/usr/X11R6/lib/X11/Metro/.version
**** /usr/lib/libSDL-1.2.so.0.7.2


ttmkfdir:

-e, --encoding		name of the encoding directory file, default is
"/usr/X11R6/lib/X11/fonts/encodings/encodings.dir"
/usr/X11R6/lib/X11/fonts/encodings/encodings.dir
**** /usr/bin/ttmkfdir


valgrind:

   obj:/usr/X11R6/lib*/libX11.so.6.2
   obj:/usr/X11R6/lib*/libXt.so.6.0
   obj:/usr/X11R6/lib*/libXaw.so.7.0
**** /usr/lib/valgrind/default.supp  (& heaps more).


xorg-x11-drv-ati-6.5.7-1:

/usr/X11R6/lib/modules/multimedia/rt2_pmem.bin
**** /usr/lib/xorg/modules/multimedia/theatre200_drv.so


xscreensaver:

*textFile:		/usr/X11R6/README
**** /usr/bin/xscreensaver  (and others)


xterm:

/usr/X11R6/bin/luit
filename of locale converter (/usr/X11R6/bin/luit)
**** /usr/bin/xterm




From jspaleta at gmail.com  Sat Nov 19 02:27:47 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 18 Nov 2005 21:27:47 -0500
Subject: 15 packages needing updates for modular X.
In-Reply-To: <1132365854.4266.6.camel@i.geek.nz>
References: <1132365854.4266.6.camel@i.geek.nz>
Message-ID: <604aa7910511181827v178bc0c4r6f61dbc7c10c3ccc@mail.gmail.com>

On 11/18/05, Ralph Loader <suckfish at ihug.co.nz> wrote:
> Hi,
>
> I ran the following to look for programs & libraries referencing the
> old /usr/X11R6/ directories:

It would be most helpful if you provided the exact package version for
each package you list.  I want to be sure I know exactly which
packages you ran this check against.

-jef



From gilboada at netvision.net.il  Sat Nov 19 02:58:01 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sat, 19 Nov 2005 04:58:01 +0200
Subject: init: API
In-Reply-To: <1132332369.4597.27.camel@ns1.htpassport.ro>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
Message-ID: <1132369081.9736.46.camel@gilboa-home-dev.localhost>

On Fri, 2005-11-18 at 18:46 +0200, R?zvan Corneliu C.R. "d3vi1" VILT
wrote:
> 
> [Text block]

First, please don't HTML post. It drives my Evolution crazy. (I cannot
insert my answers into your text...)

"A. Depends on how the schema is created. XML files can be easy to read
or dificult. Identing the xml code always helps."

True. /But/ by design, but I've yet to see an XML configuration, that
isn't 4 times the size of its clear text source. I'd suggest you compare
GNOME configuration files to their KDE counter-parts.

"B. Colored syntax always helps. That's all you usually need. At least
it's enough for me. I must say that Midnight Commander seems to work
with XML a little better."

Might be true; but I use VIM; and while being able to color XML file
does work, navigating inside a 6000 lines XML file is far from being
fun. More-ever, I use automated scripts to generate/modify/patch my
configuration files once I install FC. I doubt that it'll work under
XML.

"C. Depends on the schema."

Which means: as complex as the schema; and if you decide to create a
single catch-all schema for all services, you'll end-up with huge
complex XML files that makes it almost impossible to recover a dead
machine using a single text editor. (vim/pico/etc)

"D. It does not require complex code, it requires well designed tools.
In a XML based init world, you would need chkconfig and other tools. XML
authoring should be done only by the package maintainers. The rest
should be doable by external tools which share a common API."

/Far/ from it.
Beside having my own init.d services (For instance, I have my own
iptables generator service, vpn, etc) which automatically breaks that
"only package maintainers do init.d scripts", I also tend to edit
scripts by hand. 
You cannot assume that something as basic as service management be be
handles by package maintainers only.

"XML could help major projects such as the directory server bypass the
limitations of the current sysvinit. Check the problems with the
currently proposed init scripts in the fedora-ds wiki.
I've included in this email a demo of a service configuration file for
Sun SMF. Don't worry, it's not CDDL-ed. You are not contaminated if you
read this.
The interesting stuff this file brings:
1) Internationalize the service descriptions (the xml:lang attribute is
a dream for i18n in this case).2) Include information about the
documentation.
3) Include dependency information.
4) Include the start-up and shutdown commands.
There are a lot of other things that can be done using this XML file.
These are just a few of the ones that I consider important. I've added
gEdit style syntax color in the HTML version 

<service name='system/coreadm' type='service' version='1'>
   <create_default_instance enabled='false' />
    <single_instance />
    <dependency name='usr' grouping='require_all' restart_on='none'
type='service'>
        <service_fmri value='svc:/system/filesystem/minimal'/>
    </dependency>
    <exec_method type='method' name='start' exec='/usr/bin/coreadm -u'
timeout_seconds='3' />
    <exec_method type='method' name='stop' exec=':true'
timeout_seconds='0' />
    <property_group name='startd' type='framework'>
        <propval name='duration' type='astring' value='transient' />
    </property_group>
    <stability value='Unstable' />
    <template>
        <common_name><loctext xml:lang='C'>
            System-wide core file configuration service.
        </loctext></common_name>
        <documentation>
            <manpage title='coreadm' section='1M'
manpath='/usr/share/man' />
        </documentation>
    </template>
</service>"

Let me do the text version of this.

#This is my version of things.

# General.
SERVICENAME=NFS_main
SERVICEGROUP=NFS
SERVICETYPE=fs_service
SERVICEVERSION=1
SERVICEDESCRIPTION_EN="NFS Service"
SERVICEDESCRIPTION_IL="NFS ????"

# Dependencies.
DEPENDENCIES="mount_root mount_user network NFS_mountd NFS_quotas
RPC_portmap"

# Binary, configuration.
CONFIGURATION=/etc/exports
BINARY=/usr/sbin/rpc.nfsd

SERVICE_START_TIMEOUT=10s
SERVICE_START_PARAMETERS=""

SERVICE_STOP_TIMEOUT=5s
SERVICE_START_PARAMETERS=""

SERVICE_QUERY_TIMEOUT=1s
SERVICE_QUERY_PARAMETERS=""

Just compare the complexity of your XML files against mine and you'll
see why I find XML to be a lousy solution.

Cheers,
Gilboa



From alan at redhat.com  Sat Nov 19 03:06:35 2005
From: alan at redhat.com (Alan Cox)
Date: Fri, 18 Nov 2005 22:06:35 -0500
Subject: init: API
In-Reply-To: <1132369081.9736.46.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
Message-ID: <20051119030635.GA25132@devserv.devel.redhat.com>

On Sat, Nov 19, 2005 at 04:58:01AM +0200, Gilboa Davara wrote:
> True. /But/ by design, but I've yet to see an XML configuration, that
> isn't 4 times the size of its clear text source. I'd suggest you compare
> GNOME configuration files to their KDE counter-parts.

For the sake of 4K who cares

> "only package maintainers do init.d scripts", I also tend to edit
> scripts by hand. 

Use an XML editor. If its got the DTD/schema/etc then it won't let you
make a mistake and it can present the document in a sane manner. Any 
document..



From zaitcev at redhat.com  Sat Nov 19 03:16:22 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Fri, 18 Nov 2005 19:16:22 -0800
Subject: init: API
In-Reply-To: <20051119030635.GA25132@devserv.devel.redhat.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
Message-ID: <20051118191622.4b9338cb.zaitcev@redhat.com>

On Fri, 18 Nov 2005 22:06:35 -0500, Alan Cox <alan at redhat.com> wrote:

> > "only package maintainers do init.d scripts", I also tend to edit
> > scripts by hand. 
> 
> Use an XML editor. If its got the DTD/schema/etc then it won't let you
> make a mistake and it can present the document in a sane manner. Any 
> document..

Any suggestions for one which actually works and is not emacs?

-- Pete



From bojan at rexursive.com  Sat Nov 19 03:30:54 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 19 Nov 2005 14:30:54 +1100
Subject: ZFS.
In-Reply-To: <1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
References: <1132286299.19636.11.camel@dragon.sys.intra>
	<604aa7910511172004t65937897gaea02df0e8c160a4@mail.gmail.com>
	<1132315705.24792.18.camel@pc-sh.intern.pcservice.de>
Message-ID: <1132371055.5266.20.camel@coyote.rexursive.com>

On Fri, 2005-11-18 at 13:08 +0100, Stefan Held wrote:

> AFAIK the CDDL is a BSD Style License. So where exactly do you come to
> the conclusion that Software written under this license can't be used in
> a GPL'ed environment?

Not only is it not compatible (as others pointed out quite eloquently),
but is not compatible on purpose, IMNSHO.

Sun absolutely need to distribute OpenSolaris code under CDDL, in order
to prevent exactly what was asked here - an outflow of technology from
Solaris to Linux (and that's where those patents licensed to CDDL code
only come in even more handy). That's why they picked that licence and
not the GPL in the first place. People that contribute to OpenSolaris
are always going to be at Sun's mercy to keep releasing the closed
binaries (remember, half of "Open"Solaris is closed binaries). If Sun
goes bust tomorrow, who's going to give those people an up-to-date copy
of the binaries? Exactly!

Furthermore, Sun are in the unique position here, not only because they
control those binaries, but because they can ship a binary only Solaris
distro with bits that others don't have access to at all (though their
long standing relationships with various proprietary software vendors).
So, people that are working on OpenSolaris effectively become free of
charge Sun employees. Really nice touch. IMNSHO, that part was also
designed on purpose, because Sun realised that they cannot maintain
Solaris as a proprietary Unix forever (it was evident for a while that
Linux gets new stuff way faster), so they went on to recruit open source
community to work for them for free. Thanks, but no thanks.

Contrast this with true open source companies like Red Hat (note: I am
not a RH employee). If Red Hat went bust today, anyone could take all
Red Hat code (including Fedora, RHEL, GFS etc.) and continue at exactly
the same point where Red Hat left off (in fact, people like CentOS are
doing exactly that already). It is simply not possible to do that with
"Open"Solaris, because Sun controls vital binary bits and reserves the
right to release "slightly different" binaries in their proprietary
version, thus shifting the balance of power from the community to
themselves.

So, unless Sun change their mind, I don't think we'll see ZFS in Linux
at all. They may as well do that if the OpenSolaris thing doesn't pan
out the way they expected. Only future will tell.

PS. I know that I will now forever be labelled as a "nut-case" by Sun
lovers, but I like to call is as see it.

-- 
Bojan



From bojan at rexursive.com  Sat Nov 19 03:41:18 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 19 Nov 2005 14:41:18 +1100
Subject: xmkmf in modular X
In-Reply-To: <1132253558.27296.15.camel@coyote.rexursive.com>
References: <1132225121.27296.13.camel@coyote.rexursive.com>
	<437C7C64.6080207@redhat.com>
	<1132253558.27296.15.camel@coyote.rexursive.com>
Message-ID: <1132371678.5266.23.camel@coyote.rexursive.com>

On Fri, 2005-11-18 at 05:52 +1100, Bojan Smojver wrote:
> On Thu, 2005-11-17 at 07:49 -0500, Mike A. Harris wrote:
> 
> > It is probably a glitch in the new imake package.  If you can confirm
> > that, please file a bug in Red Hat bugzilla, and we'll investigate it.
> 
> OK. I'll have a bit better look today.

Current imake is fixed and the build goes OK. However, the whole thing
is still configured to drop everything off in /usr/X11R6 directory (and
its sub-directories) and not in /usr/bin etc. Not sure if that's on
purpose or not...

Anyway, I'll have a look at a few Makefile.am examples in order to port
to the new build system...

-- 
Bojan



From jdesbonnet at gmail.com  Sat Nov 19 03:55:36 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sat, 19 Nov 2005 03:55:36 +0000
Subject: init: API
In-Reply-To: <1132369081.9736.46.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
Message-ID: <1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>

On 11/19/05, Gilboa Davara <gilboada at netvision.net.il> wrote
>
> Which means: as complex as the schema; and if you decide to create a
> single catch-all schema for all services, you'll end-up with huge
> complex XML files that makes it almost impossible to recover a dead
> machine using a single text editor. (vim/pico/etc)

No, a single catch all schema would be stupid. Combine several schemas
as needed. Eg a schema can define basic system constants such as
usernames, lists of usernames, groups, permissions, access control
lists etc.

> Let me do the text version of this.
>
> #This is my version of things.
>
> # General.
> SERVICENAME=NFS_main
> SERVICEGROUP=NFS

Ok, is that encoded as UTF-8, ISO-8859-1 or what?. How do I encode a
CR or LF in the values? How are double quotes handled?  Are equal
signs escaped?

My point -- when writing parsers the devil is in the details. Config
file parsing is something that the application developer should not
concern themselves with. They should be able to rely on a standard
library to return the config file in a object/structure that the
software can consume.

Joe.



From notting at redhat.com  Sat Nov 19 04:01:11 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 18 Nov 2005 23:01:11 -0500
Subject: X move - app-defaults?
Message-ID: <20051119040111.GA2909@devserv.devel.redhat.com>

app-defaults used to be in /usr/X11R6/lib/X11/app-defaults, for all
arches.

Now, with the directory move, they are in *either*
/usr/lib/X11/app-defaults, or /usr/lib64/X11/app-defaults. Shouldn't
they continue to be in a constant directory (and really, shouldn't
that be under /usr/share?)

Bill



From dakingun at gmail.com  Sat Nov 19 04:30:03 2005
From: dakingun at gmail.com (Deji Akingunola)
Date: Fri, 18 Nov 2005 23:30:03 -0500
Subject: X move - app-defaults?
In-Reply-To: <20051119040111.GA2909@devserv.devel.redhat.com>
References: <20051119040111.GA2909@devserv.devel.redhat.com>
Message-ID: <b80014de0511182030g1ff95fe2rdb78e4471251184a@mail.gmail.com>

On 11/18/05, Bill Nottingham <notting at redhat.com> wrote:
> app-defaults used to be in /usr/X11R6/lib/X11/app-defaults, for all
> arches.
>
> Now, with the directory move, they are in *either*
> /usr/lib/X11/app-defaults, or /usr/lib64/X11/app-defaults. Shouldn't
> they continue to be in a constant directory (and really, shouldn't
> that be under /usr/share?)

A short while ago, I came by a web page
(http://mharris.ca/xorg/xorg-modularization.html) put up by Mike
Harris addressing this very issue.

Deji



From notting at redhat.com  Sat Nov 19 04:32:40 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 18 Nov 2005 23:32:40 -0500
Subject: X move - app-defaults?
In-Reply-To: <b80014de0511182030g1ff95fe2rdb78e4471251184a@mail.gmail.com>
References: <20051119040111.GA2909@devserv.devel.redhat.com>
	<b80014de0511182030g1ff95fe2rdb78e4471251184a@mail.gmail.com>
Message-ID: <20051119043239.GA9704@devserv.devel.redhat.com>

Deji Akingunola (dakingun at gmail.com) said: 
> On 11/18/05, Bill Nottingham <notting at redhat.com> wrote:
> > app-defaults used to be in /usr/X11R6/lib/X11/app-defaults, for all
> > arches.
> >
> > Now, with the directory move, they are in *either*
> > /usr/lib/X11/app-defaults, or /usr/lib64/X11/app-defaults. Shouldn't
> > they continue to be in a constant directory (and really, shouldn't
> > that be under /usr/share?)
> 
> A short while ago, I came by a web page
> (http://mharris.ca/xorg/xorg-modularization.html) put up by Mike
> Harris addressing this very issue.

Well, then he should actually build packages that *reflect* this. :P

Bill



From gilboada at netvision.net.il  Sat Nov 19 04:49:28 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sat, 19 Nov 2005 06:49:28 +0200
Subject: init: API
In-Reply-To: <20051119030635.GA25132@devserv.devel.redhat.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
Message-ID: <1132375768.9736.58.camel@gilboa-home-dev.localhost>

On Fri, 2005-11-18 at 22:06 -0500, Alan Cox wrote:
> On Sat, Nov 19, 2005 at 04:58:01AM +0200, Gilboa Davara wrote:
> > True. /But/ by design, but I've yet to see an XML configuration, that
> > isn't 4 times the size of its clear text source. I'd suggest you compare
> > GNOME configuration files to their KDE counter-parts.
> 
> For the sake of 4K who cares
> 
> > "only package maintainers do init.d scripts", I also tend to edit
> > scripts by hand. 
> 
> Use an XML editor. If its got the DTD/schema/etc then it won't let you
> make a mistake and it can present the document in a sane manner. Any 
> document..
> 

Ummm... which brings us back to square 1.
Linux is build around Unix philosophy:  You can fix a dead machine from
a serial console over a 9600 bps line using a 2K editor.
You can fix a machine by issuing a cat /etc/temp.conf | sed
's/HOSTNAME/NEW_NAME/g' > /etc/temp2.conf;
mv /etc/temp2.conf /etc/temp.conf; reboot.
You don't need special tools or editors. You just need to touch a couple
of text lines inside a configuration file. (Be that initab, lilo.conf or
grub.conf)

Windows is build around the concept of "We know better; we have an uber
smart configuration manager (registry) which is build (in most cases)
around a schema and uses special tools to manipulate (registry editor)".
The idea is all nice and dandy, that, until you have a machine that died
due to botched driver upgrade or a minor registry corruption. 

While using XML is still a couple of steps short of having huge useless
registry hives, it is a step in the wrong direction.

Gilboa



From gilboada at netvision.net.il  Sat Nov 19 04:53:21 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sat, 19 Nov 2005 06:53:21 +0200
Subject: init: API
In-Reply-To: <1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
Message-ID: <1132376001.9736.63.camel@gilboa-home-dev.localhost>

On Sat, 2005-11-19 at 03:55 +0000, Joe Desbonnet wrote:
> On 11/19/05, Gilboa Davara <gilboada at netvision.net.il> wrote
> >
> > Which means: as complex as the schema; and if you decide to create a
> > single catch-all schema for all services, you'll end-up with huge
> > complex XML files that makes it almost impossible to recover a dead
> > machine using a single text editor. (vim/pico/etc)
> 
> No, a single catch all schema would be stupid. Combine several schemas
> as needed. Eg a schema can define basic system constants such as
> usernames, lists of usernames, groups, permissions, access control
> lists etc.
> 
> > Let me do the text version of this.
> >
> > #This is my version of things.
> >
> > # General.
> > SERVICENAME=NFS_main
> > SERVICEGROUP=NFS
> 
> Ok, is that encoded as UTF-8, ISO-8859-1 or what?. How do I encode a
> CR or LF in the values? How are double quotes handled?  Are equal
> signs escaped?
> 
> My point -- when writing parsers the devil is in the details. Config
> file parsing is something that the application developer should not
> concern themselves with. They should be able to rely on a standard
> library to return the config file in a object/structure that the
> software can consume.

Ummm... I can agree to most of the above, however,
A. I've yet to be convinced that there's /a need/ for international text
support within a service manager.
B. There are dozens of project that do config parsing; why not find a
good text parser and use it code? 

> 
> Joe.



From cmadams at hiwaay.net  Sat Nov 19 05:12:58 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 18 Nov 2005 23:12:58 -0600
Subject: init: API
In-Reply-To: <20051119030635.GA25132@devserv.devel.redhat.com>
References: <1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
Message-ID: <20051119051258.GC1126723@hiwaay.net>

Once upon a time, Alan Cox <alan at redhat.com> said:
> Use an XML editor. If its got the DTD/schema/etc then it won't let you
> make a mistake and it can present the document in a sane manner. Any 
> document..

This is the init system.  When it doesn't work, I'll have to fix it on a
VT510 hooked up to the serial console.  I don't want to have to jump
through a lot of hoops to have to fix the system (so /usr may not be
available for example); how do I use an XML editor?  The only editor
currently in /bin is vi (not vim with 10,000 optional pieces but
stripped down).  I guess you can count awk/sed/grep and maybe even ed as
"editors", but they certainly don't know XML, DTDs, schemas, etc.

-- 
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 jfrieben at freesurf.fr  Sat Nov 19 08:38:13 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 19 Nov 2005 09:38:13 +0100 (CET)
Subject: Savage DRI broken in modular X
In-Reply-To: <23315.194.94.224.254.1132349059.squirrel@jose.freesurf.fr>
References: <23315.194.94.224.254.1132349059.squirrel@jose.freesurf.fr>
Message-ID: <37910.194.94.224.254.1132389493.squirrel@jose.freesurf.fr>

Running "strings /usr/lib/libGL.so.1.2 | grep X11R6"
yields "/usr/X11R6/lib/modules/dri" which seems to confirm
my earlier conjecture.




From petro at mail.ru  Sat Nov 19 10:01:36 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 19 Nov 2005 13:01:36 +0300
Subject: More modularization.
Message-ID: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>

Hello, All!

Just my simple proposal. If we look into mesa-libGL package, we'll see a 
number of dri-modules:

[petro at Petro ~]$ rpm -ql mesa-libGL
/usr/lib
/usr/lib/dri
/usr/lib/dri/i810_dri.so
/usr/lib/dri/i830_dri.so
/usr/lib/dri/i915_dri.so
/usr/lib/dri/mga_dri.so
/usr/lib/dri/r128_dri.so
/usr/lib/dri/r200_dri.so
/usr/lib/dri/radeon_dri.so
/usr/lib/dri/savage_dri.so
/usr/lib/dri/sis_dri.so
/usr/lib/dri/unichrome_dri.so
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.2

I (and many others, definitely) haven't neither i810-based cars, nor 
others from this list. So question is - why I enforced to install all of 
these dri-modules? We can simply split this package into a bunch of little 
packages, for example mesa-libGL, mesa-dri-i810, mesa-dri-i830, etc. It''s 
not a hard work, IMO.

The same thing with kernel. Not all of kernel-modules are needed actually. 
Why don't repack kernel into kernel, kernel-modules-all (which contains 
nothing, actually, but installs a huge number of small packages with 
modules itself - the way xorg-x11-drivers does).

Any ideas?
-- 
With best regards, Peter Lemenkov.




From nicolas.mailhot at laposte.net  Sat Nov 19 10:08:12 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 19 Nov 2005 11:08:12 +0100
Subject: init: API
In-Reply-To: <1132376001.9736.63.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
	<1132376001.9736.63.camel@gilboa-home-dev.localhost>
Message-ID: <1132394893.9723.8.camel@rousalka.dyndns.org>

Le samedi 19 novembre 2005 ? 06:53 +0200, Gilboa Davara a ?crit :

> B. There are dozens of project that do config parsing; why not find a
> good text parser and use it code? 

This parser exists it's called libxml

-- 
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/20051119/7183ea88/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Nov 19 10:16:24 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 19 Nov 2005 11:16:24 +0100
Subject: init: API
In-Reply-To: <1132375768.9736.58.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
Message-ID: <1132395384.9723.17.camel@rousalka.dyndns.org>

Le samedi 19 novembre 2005 ? 06:49 +0200, Gilboa Davara a ?crit :

> While using XML is still a couple of steps short of having huge useless
> registry hives, it is a step in the wrong direction.

Accusing XML to be wrong just because gconf made a mess of it is just as
silly as accusing traditional conf files to be hopeless because of
sendmail.

There is *nothing* wrong with XML itself, if fact there are lots of very
good built-in properties in XML, the only thing a service description in
XML would need is strong style guidelines.

And BTW without strong style guidelines flatfiles are just as bad, so
the only thing you people are saying is "I've seen good flat-file style,
but no good xml-file style". And considering you've all read perhaps 100
? as many flat-files as XML files, this is not exactly a damning
statement.

Once again, what is wrong with /etc/fonts/fonts.conf ?

-- 
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/20051119/eb7e57e9/attachment.sig>

From nicolas.mailhot at laposte.net  Sat Nov 19 10:18:13 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 19 Nov 2005 11:18:13 +0100
Subject: init: API
In-Reply-To: <20051118191622.4b9338cb.zaitcev@redhat.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
Message-ID: <1132395494.9723.20.camel@rousalka.dyndns.org>

Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
> On Fri, 18 Nov 2005 22:06:35 -0500, Alan Cox <alan at redhat.com> wrote:
> 
> > > "only package maintainers do init.d scripts", I also tend to edit
> > > scripts by hand. 
> > 
> > Use an XML editor. If its got the DTD/schema/etc then it won't let you
> > make a mistake and it can present the document in a sane manner. Any 
> > document..
> 
> Any suggestions for one which actually works and is not emacs?

Just use vim for syntax highlighting and xmllint to check the result.

100% light-weight CLI solution.

-- 
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/20051119/1ed0558f/attachment.sig>

From jdesbonnet at gmail.com  Sat Nov 19 10:51:14 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Sat, 19 Nov 2005 10:51:14 +0000
Subject: init: API
In-Reply-To: <1132395384.9723.17.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
Message-ID: <1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>

On 11/19/05, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> There is *nothing* wrong with XML itself, if fact there are lots of very
> good built-in properties in XML, the only thing a service description in
> XML would need is strong style guidelines.
>
> And BTW without strong style guidelines flatfiles are just as bad, so
> the only thing you people are saying is "I've seen good flat-file style,
> but no good xml-file style". And considering you've all read perhaps 100
>

Guidelines is the key. As far as I can tell there has been no effort
in the past to try to standardize config file syntax. Of course any
effort to force a standard on application developers is doomed, but if
two configuration file standards were developed (like an RFC
document): one a simple key-value, one record per line text file
format; the other a XML schema for more complex configuration files
then I believe developers will be tempted to adopt whichever standard
suits their need. A standard parsing library in the major application
languages will provide further incentive.

This should also help in the common scenario where a separate
developer is responsible the admin GUI for an application (probably in
another application language). If a standard configuration file is
used, the GUI admin tool developer does not have to worry about
changing syntax and bugs in the parser.

Is developing these standards worth while? Is it in the remit of the
Fedora project?

Joe.



From ankit644 at yahoo.com  Sat Nov 19 11:21:43 2005
From: ankit644 at yahoo.com (Ankit Patel)
Date: Sat, 19 Nov 2005 03:21:43 -0800 (PST)
Subject: How to move package from extras to core ?
In-Reply-To: <c0a09e5c0511181311u57039d37j3dfec1ccb0c659d1@mail.gmail.com>
Message-ID: <20051119112143.93021.qmail@web34615.mail.mud.yahoo.com>

So, finally isn't there any possibility of moving system-config-control from Extras to Core ?
 

		
---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051119/ce20cdb0/attachment.htm>

From mharris at redhat.com  Sat Nov 19 11:39:35 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 06:39:35 -0500
Subject: X move - app-defaults?
In-Reply-To: <20051119040111.GA2909@devserv.devel.redhat.com>
References: <20051119040111.GA2909@devserv.devel.redhat.com>
Message-ID: <437F0EF7.50405@redhat.com>

Bill Nottingham wrote:
> app-defaults used to be in /usr/X11R6/lib/X11/app-defaults, for all
> arches.
> 
> Now, with the directory move, they are in *either*
> /usr/lib/X11/app-defaults, or /usr/lib64/X11/app-defaults.

Yes, the rpm packages are all currently using the insane upstream
defaults.  Unfortunately, some folks upstream have expressed
complete disinterest with maintaining any sort of FHS compatibility
in the standard X distribution.  What's worse, is that passing the
normal flags to ./configure to get things where you expect them,
has no effect, because they don't bother using $(datadir) to plant
the data files where they belong.  Instead they use $(libdir)/X11
or some other custom hack, which varies from tarball to tarball,
etc.

The upstream goal, is that if you just type ./configure with no
options, when you build and install X, all of the files go where
upstream wants them to go by default - rather than going to
/usr/local/* which is the normal place for autotooled packages
to put things unless you override the defaults.

I think this is a disastrous short sighted decision personally,
and it will make things much more complicated for all OS vendors
out there that require FHS compliance.

I am going to do what I can do to try to patch things to go where
they should go, and to try to get my patches accepted upstream,
but it's hard to say wether they'll go for this or not.  I was met
with a strong resistance to mentioning "FHS", however I did explain
that they don't need to know or care about FHS, so long as the
defaults are set sanely, as our configure options ensure that
we get FHS so long as the upstream autotooling uses the right
variables in dir paths.

No response so far.

> Shouldn't they continue to be in a constant directory (and
 > really, shouldn't that be under /usr/share?)

Yes, and yes.  :)  I am currently in the process of changing
all of the packages to use /usr/share for all architecture
independent data files, which so far involves hacking up
Makefile.am and/or configure.in, then running aclocal,
automake and/or autoconf, with a dash of salt, baking in
an oven preheated to 500F for 30 minutes, and then serving
with a side order of coconut shrimp, and garnished with
a sprig of parseley.

Keep checking the menu every few hours to monitor progress.
;)



From mharris at redhat.com  Sat Nov 19 11:40:37 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 06:40:37 -0500
Subject: X move - app-defaults?
In-Reply-To: <20051119043239.GA9704@devserv.devel.redhat.com>
References: <20051119040111.GA2909@devserv.devel.redhat.com>	<b80014de0511182030g1ff95fe2rdb78e4471251184a@mail.gmail.com>
	<20051119043239.GA9704@devserv.devel.redhat.com>
Message-ID: <437F0F35.7060900@redhat.com>

Bill Nottingham wrote:
> Deji Akingunola (dakingun at gmail.com) said: 
> 
>>On 11/18/05, Bill Nottingham <notting at redhat.com> wrote:
>>
>>>app-defaults used to be in /usr/X11R6/lib/X11/app-defaults, for all
>>>arches.
>>>
>>>Now, with the directory move, they are in *either*
>>>/usr/lib/X11/app-defaults, or /usr/lib64/X11/app-defaults. Shouldn't
>>>they continue to be in a constant directory (and really, shouldn't
>>>that be under /usr/share?)
>>
>>A short while ago, I came by a web page
>>(http://mharris.ca/xorg/xorg-modularization.html) put up by Mike
>>Harris addressing this very issue.
> 
> 
> Well, then he should actually build packages that *reflect* this. :P

He's working on it.  <carlin>Calm down, and have some dip.</carlin>

;oP



From mharris at redhat.com  Sat Nov 19 11:47:16 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 06:47:16 -0500
Subject: Savage DRI broken in modular X
In-Reply-To: <37910.194.94.224.254.1132389493.squirrel@jose.freesurf.fr>
References: <23315.194.94.224.254.1132349059.squirrel@jose.freesurf.fr>
	<37910.194.94.224.254.1132389493.squirrel@jose.freesurf.fr>
Message-ID: <437F10C4.1070702@redhat.com>

Joachim Frieben wrote:
> Running "strings /usr/lib/libGL.so.1.2 | grep X11R6"
> yields "/usr/X11R6/lib/modules/dri" which seems to confirm
> my earlier conjecture.

Mesa is broken right now due to this, so DRI is also broken.  Getting
all of the X junk out of /usr/lib/X11 and into /usr/share/X11 is
currently one of my highest priorities however.  Second to that are
a number of other 'foo is nonfunctional' issues without reasonable
workarounds.

If someone would like to investigate this problem, and send me a patch
however, that might help get it fixed in time for test1, as it might
wait until test2 otherwise.  I assume it is probably something as
simple as passing a flag to the build script, or patching a file
or two, so it shouldn't be hard to fix.  Just not as high a priority
as other matters on the table currently.

Whatever you do though, do NOT point a symlink from the one directory
to another, or RPM will have a total fit when you upgrade, and
your system will be busted.

/me is already trying hard to dig modular X out of legitimate
dir/symlink packaging hell, and encourages users to not dig
themselves into it deeper.

Many thanks in advance to whomever fixes it first. ;o)



From mharris at redhat.com  Sat Nov 19 12:11:04 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:11:04 -0500
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
Message-ID: <437F1658.5090000@redhat.com>

Peter Lemenkov wrote:
> Hello, All!
> 
> Just my simple proposal. If we look into mesa-libGL package, we'll see a 
> number of dri-modules:
> 
> [petro at Petro ~]$ rpm -ql mesa-libGL
> /usr/lib
> /usr/lib/dri
> /usr/lib/dri/i810_dri.so
> /usr/lib/dri/i830_dri.so
> /usr/lib/dri/i915_dri.so
> /usr/lib/dri/mga_dri.so
> /usr/lib/dri/r128_dri.so
> /usr/lib/dri/r200_dri.so
> /usr/lib/dri/radeon_dri.so
> /usr/lib/dri/savage_dri.so
> /usr/lib/dri/sis_dri.so
> /usr/lib/dri/unichrome_dri.so
> /usr/lib/libGL.so.1
> /usr/lib/libGL.so.1.2
> 
> I (and many others, definitely) haven't neither i810-based cars, nor 
> others from this list. So question is - why I enforced to install all of 
> these dri-modules? We can simply split this package into a bunch of 
> little packages, for example mesa-libGL, mesa-dri-i810, mesa-dri-i830, 
> etc. It''s not a hard work, IMO.

This is a long term possible feature.  In order for this to happen, here
is what needs to be done:

1) The upstream Mesa project needs to be autotooled, so that it has a
    sane buildsystem that works like everything else that is a part of
    modular X.  Adam Jackson has expressed interest in possibly taking
    this task on once X11R7 ships.

2) The upstream Mesa project needs to be enhanced to provide a driver
    development kit of sorts, similar in vein to the Xorg SDK which we
    currently use to build all of the 2D drivers in their own individual
    rpm packages.  Once this is provided by the Mesa project, it then
    becomes easy to split the driver sources out of the project if
    desired, and build them separately.

3) The 3D drivers need to have metadata files included with them of
    some sort to indicate what hardware they support based on PCI ID
    information, similar to what we need for the 2D drivers.  That
    information needs to be coupled with the driver source, or generated
    dynamically from data contained in the drivers.

4) The Fedora Core installation and X configuration tools need to be
    updated to have the ability to ask for the Fedora CD and/or to
    be able to download uninstalled drivers for the hardware, should you
    put in a card that a driver exists for, but which you have either
    chosen not to install, or have intentionally uninstalled, thinking
    you will not need it or do not want it for whatever other reason.


In all previous operating system releases, all of the drivers (both
2D and 3D) were all built from one giant monolithic tarball.  They
were installed from a single giant tarball for multiple reasons.  One,
was to ensure that all of the drivers were always installed, so that
the installation and configuration tools could be simple.  You don't
want the config tools to configure X to use a driver that is part of
the operating system, but is not currently installed.

Allowing people to choose to not install drivers, or to uninstall
individual drivers, without having support in the operating system
for easily downloading drivers or getting them from the CD when they
are needed, would be a terrible mistake, and a massive support
nightmare from hell.  Bugzilla would overflow with "you didn't ship
my driver" bug reports by the dozens.

Having said all of this, I hope this helps to understand what is needed
in order for this feature request to become a reality.  If someone
is interested in hacking on anaconda and/or system-config-display to
add the support needed for downloading drivers with yum, and asking
for CDROM/URL/harddisk or whatever like Windows does, that would be
a step in the right direction for seeing such a feature exist in
Fedora Core sooner.


> The same thing with kernel. Not all of kernel-modules are needed 
> actually. Why don't repack kernel into kernel, kernel-modules-all (which 
> contains nothing, actually, but installs a huge number of small packages 
> with modules itself - the way xorg-x11-drivers does).

The X server has a stable Xserver<->driver ABI in one direction.  This
means that from one bugfix release of a driver to the next, the driver
will work with the same X server.  And new X servers generally will
work with the drivers they shipped with, as well as drivers from the
previous release or two.  Every few releases of the X server, something
sometimes changes which breaks the ABI however, but it is generally
quite stable for 1-2 years or so.

The kernel on the other hand, very intentionally does not have a
kernel<->module ABI at all whatsoever.  Last I heard, Linus had no
interest in giving the kernel a stable module ABI.  Having the
kernel broken up into a bunch of individual per-driver modules
would probably be a massive nightmare.  I wouldn't hold your breath
waiting for that to happen.  ;o)



From mharris at redhat.com  Sat Nov 19 12:13:12 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:13:12 -0500
Subject: Another modular X11 report (#2 from me)
In-Reply-To: <437D351A.2080802@poolshark.org>
References: <20051118100802.4k3dhcmfk8kskkk8@imp.rexursive.com>
	<437D351A.2080802@poolshark.org>
Message-ID: <437F16D8.1070800@redhat.com>

Denis Leroy wrote:
> Bojan Smojver wrote:
> 
>> This is for Compaq Evo D510 machine, which has an Intel based graphics 
>> chip (i845 or something like that). Today's Rawhide went up to the box 
>> fine. The following works on the box:
>>
>> - flicking between X11 and text consoles
>> - direct rendering
>> - VMWare 5.5.0 (RC2)
> 
> 
> OTOH, VMWare 5.5.0 RC2 isn't happy with Rawhide as guest OS. In one VM 
> i'm having problem with gcc crashing (bug 173440). It works on another 
> VM but it can't compile its Xorg driver... I'll file a bug with them too...

The Xorg we ship, comes with its own vmware driver, which is maintained
by the folks at VMware.  It's in the xorg-x11-drv-vmware package.

Hope this helps.



From mharris at redhat.com  Sat Nov 19 12:19:56 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:19:56 -0500
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
Message-ID: <437F186C.5080409@redhat.com>

Peter Lemenkov wrote:
> Hello, All!
> 
> Subj, until i symlinked /usr to usr/X11R6
> 
> Looks like someone hardcoded xauth to
> 
> /usr/X11R6/bin/xauth
> 
> Frankly speaking I think that's a good idea to make this symlink, until 
> all issues, concerned with modular Xorg, will be resolved.

Symlinks to directories can cause a lot of problems when future packages
reverse directions.  I am currently facing a big dir/symlink problem in
the modular X packages which is going to be difficult to resolve.

Rawhide may have changed its name to "Fedora Developement", but it is
still very much "raw" hide.  Expect that some things will break from
time to time, and that some things will stay broken until they are
fixed.

Feel free to hack around problems on your own system if you desire,
until a problem is fixed properly, but you will not see this type
of hack come from my X packages.  There are a lot of software out
there that put their files into /usr/X11R6 that are not a part
of X, and while we've fixed most of the ones that come with the OS,
we have no control over the various 3rd party packages out there
that violate the directory structure.

Consider the fact that various packages on people's systems do have
files installed by rpm in /usr/X11R6.  Ignoring the fact that rpm
will not allow you to replace a directory (/usr/X11R6) with a
symbolic link for the minute - what would happen to all of the
applications that were installed via rpm, which have files in
/usr/X11R6, if all of a sudden, /usr/X11R6 became a symlink that
pointed to /usr?

How would you implement this?

rm -rf /usr/X11R6 ; ln -s /usr /usr/X11R6

Like that?  That would make a lot of happy users I'm sure.  ;o)

If you require a stable OS, use Fedora Core 4 please, and wait until
rawhide has had some of the "raw" shaken out of it.  That is generally
around test3 or so.  Alternatively, wait until Fedora Core 5 final
is released.



From mharris at redhat.com  Sat Nov 19 12:32:44 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:32:44 -0500
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <200511181049.46383.lamont@gurulabs.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<200511181049.46383.lamont@gurulabs.com>
Message-ID: <437F1B6C.50801@redhat.com>

Lamont R. Peterson wrote:
> On Friday 18 November 2005 03:18am, Peter Lemenkov wrote:
> 
>>Hello, All!
> 
> [snip]
> 
>>Frankly speaking I think that's a good idea to make this symlink, until
>>all issues, concerned with modular Xorg, will be resolved.
> 
> 
> I would be concerned about opening that floodgate.  If we do, then there is no 
> reason for people to care to fix their code.

Correct.  Just prior to the release of Fedora Core 5, I plan on doing
a sweep through bugzilla looking for various compatibility issues with
respect to hard coded paths to things.  There are likely to be some
areas where we do need to provide optional backward compatibility, and
at that time, I will likely be creating some compatibility mechanisms,
however the details of exactly what, and how it will work, will be
determined late in the Fedora development cycle.

Right now, the focus is on getting modular X cleaned up and stabilized,
and on getting as much of the rest of the OS as possible, as well as
Fedora Extras, and other 3rd party software out there - all fixed up
to work with modular X too.  There are a number of things out there
right now that may very well be broken by modular X, due to paths
moving.  That is good.  I want to see those applications fixed by
people, and fixed sooner rather than later.

If people know of software that is broken by having hard coded paths
to X binaries, config files, libraries, or X data files, please report
bugs to the upstream developers of those packages, and to the
package maintainers who own the packages.  Where possible, please
submit patches to help fix the software to work with modular X.
If you're unsure about how best to fix something in particular, please
ask directly on this mailing list and/or on the main xorg list
upstream.  If I see your question and have time to offer an answer,
I will gladly try to help.

Having said that, I want to emphasize that I am not in a rush to
provide backward compatibility symbolic links for anything at this
early point in the Fedora development cycle, as that just allows
broken applications to stay broken indefinitely, or until we
remove the symlink in an OS release or 2 or 3.

Also, when we do decide late in the development cycle what compat
links we should provide for the final OS release, I plan on disabling
them again in rawhide as soon as FC6 development starts up, to
further "encourage" people to fix broken applications that are
still out there.

By contributing to reporting bugs, and/or fixing the broken
applications, people will help to get rid of such compatibility
problems much sooner, and the whole community will benefit from
it.




From fedora at leemhuis.info  Sat Nov 19 12:24:28 2005
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 19 Nov 2005 13:24:28 +0100
Subject: Build error on devel: libSM dependency
In-Reply-To: <1132356172.4591.41.camel@bree.local.net>
References: <883cfe6d0511181455n393603ecs@mail.gmail.com>
	<1132356172.4591.41.camel@bree.local.net>
Message-ID: <1132403068.2614.2.camel@localhost.localdomain>

Am Freitag, den 18.11.2005, 18:22 -0500 schrieb Jeremy Katz:
> On Fri, 2005-11-18 at 17:55 -0500, Michel Salim wrote:
> > One of my package, grhino, fails to compile on devel because libSM has
> > been split from xorg into its own package, and none of the current
> > build dependencies include it.
> > 
> > The package (grhino) currently pulls its build dependencies from
> > desktop-file-utils (to handle the .desktop file), libgnomeui-devel and
> > scrollkeeper ; libgnomeui-devel depends on gtk2-devel, which in turns
> > (as of FC-4) depends on XFree86-devel.
> > 
> > So which package should I file a bug against - how are the X.org
> > dependencies supposed to be handled in the upcoming, modularized X
> > packaging?
> 
> libSM is almost certainly being pulled in for libgnomeui -- so that's
> where the bug belongs

That bug was filed already some hours before this discussion ;)

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173610
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From mharris at redhat.com  Sat Nov 19 12:38:13 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:38:13 -0500
Subject: Build error on devel: libSM dependency
In-Reply-To: <883cfe6d0511181512g6fe59860u@mail.gmail.com>
References: <883cfe6d0511181455n393603ecs@mail.gmail.com>
	<883cfe6d0511181512g6fe59860u@mail.gmail.com>
Message-ID: <437F1CB5.5040204@redhat.com>

Michel Salim wrote:
> One of my package, grhino, fails to compile on devel because libSM has
> been split from xorg into its own package, and none of the current
> build dependencies include it.
> 
> The package (grhino) currently pulls its build dependencies from
> desktop-file-utils (to handle the .desktop file), libgnomeui-devel and
> scrollkeeper ; libgnomeui-devel depends on gtk2-devel, which in turns
> (as of FC-4) depends on XFree86-devel.

If you find a package depending on XFree86-devel, or on
xorg-x11-devel, please file a bug report against that package
in the relevent bugzilla, or if i is an upstream package from
some software project, please report the bug to them.

XFree86-devel and xorg-x11-devel no longer exist in Fedora Core.
Software that links to X libraries, must now have a separate
BuildRequires added for each individual X library that the package
uses, in the form:

BuildRequires: libSM-devel
BuildRequires: libX11-devel
...

> So which package should I file a bug against - how are the X.org
> dependencies supposed to be handled in the upcoming, modularized X
> packaging?

Each library is in it's own package, which has the same name as the
library itself (except for libXss, which is package "libXScrnSaver"
as upstream decided to name one library tarball different just to
make things confusing).

So, you need to BuildRequires: lib<name>-devel for each library
you need.

Hope this helps.



From mharris at redhat.com  Sat Nov 19 12:44:37 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 07:44:37 -0500
Subject: 15 packages needing updates for modular X.
In-Reply-To: <1132365854.4266.6.camel@i.geek.nz>
References: <1132365854.4266.6.camel@i.geek.nz>
Message-ID: <437F1E35.5060007@redhat.com>

Ralph Loader wrote:
> Hi,
> 
> I ran the following to look for programs & libraries referencing the
> old /usr/X11R6/ directories:
> 
> 
>   find /usr/bin /usr/lib /usr/libexec -type f |
>   while read X
>   do
>      strings "$X" | grep /X11R6 && echo -e "**** $X\n\n"
>   done | tee X11R6.log
> 
> 
> and then went through the output by hand looking for things that
> actually need fixing (lots of things, e.g., search paths, are harmless
> to still contain /usr/X11R6).
> 
> I came up with the following list.  I don't have every Fedora RPM
> installed, so there are probably others.
> 
> 
>    a2ps ghostscript htmlview openoffice libxklavier mesa ncurses openssh
>    pyxf86config-0.3.22-1 SDL ttmkfdir valgrind xorg-x11-drv-ati-6.5.7-1
>    xscreensaver
[SNIP]
> libxklavier:
> 
> -I/usr/X11R6/lib/X11/xkb
> /usr/X11R6/lib/X11/xkb/rules/%s.xml
> /usr/X11R6/lib/X11/xkb/rules/%s
> /usr/X11R6/lib/X11/xkb/xkbcomp
> **** /usr/lib/libxklavier.so.10.0.0
[SNIP]

This one is actually quite funny.  It seems that libxklavier people seem
hell bent on hard coding the name and location of the xkb rules file
directly into the library, despite the fact that this causes things to
break so often.

What's funnier, is that when we transitioned from XFree86 to X.Org, and
libxklavier broke, I wrote and supplied the code to have libxklavier
query the X server directly using the xkb extension to get this
information, instead of hard coding it in the library, however it seems
nobody cared to use my patch to permanently fix it to work with
every X server that supports xkb.

I totally feel no sympathy for this broken library.  ;o)  Maybe I'll
move the xkb data files around randomly every OS release just to
watch libxklavier keep breaking.  Oh wait, I do that already.  ;o)

I very strongly recommend that libxklavier be updated _upstream_ this
time to query the xkbrules file from the X server using the xkb
extension.  Very.

Very very.



From jfrieben at freesurf.fr  Sat Nov 19 13:06:07 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 19 Nov 2005 14:06:07 +0100 (CET)
Subject: Savage DRI broken in modular X
In-Reply-To: <437F10C4.1070702@redhat.com>
References: <437F10C4.1070702@redhat.com>
Message-ID: <50734.194.94.224.254.1132405567.squirrel@jose.freesurf.fr>

A manual symlink "/usr/lib/dri" -> "/usr/X11R6/lib/modules/dri"
actually saved my day ;o)
"DRI" is working again. Now, one can have a relaxed look at the
bug itself. Btw, the monolithic X.org RC2 package contains a
"Mesa" version which is more recent, tagged as version "6.4.1".
This update should be cheap to incorporate into "rawhide".
Finally, one might also consider a sort of "compat-xorg-x11"
package to accomodate the needs of older packages, which
might only exist in binary form, e.g. "Mathematica".
This approach has been adopted in comparable cases, as a look
at the "rawhide" tree confirms.

PS: "X/OpenGL Maintainence List (xgl-maint at redhat.com)"
                   ^^^^

     Ouch! Could somebody have a look at this? I am not a native
     speaker, but this appears to be quite exotic. This usually
     writes "Maintenance", doesn't it?




From mharris at redhat.com  Sat Nov 19 13:19:19 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 08:19:19 -0500
Subject: Savage DRI broken in modular X
In-Reply-To: <50734.194.94.224.254.1132405567.squirrel@jose.freesurf.fr>
References: <437F10C4.1070702@redhat.com>
	<50734.194.94.224.254.1132405567.squirrel@jose.freesurf.fr>
Message-ID: <437F2657.4060109@redhat.com>

Joachim Frieben wrote:
> A manual symlink "/usr/lib/dri" -> "/usr/X11R6/lib/modules/dri"
> actually saved my day ;o)
> "DRI" is working again. Now, one can have a relaxed look at the
> bug itself. Btw, the monolithic X.org RC2 package contains a
> "Mesa" version which is more recent, tagged as version "6.4.1".
> This update should be cheap to incorporate into "rawhide".

There's a neat surprise in store for you.  ;o)  Whenever I fix
the mesa package, and you upgrade to the new package, your
system will probably break due to that symlink.  ;o)

If I were you, I would flag your yum.conf to exclude the
mesa-libGL package from the list of updates, and then watch
the lists for indication that mesa is fixed, then remove the
symlink, tweak your yum config, and update.

Just an idea. ;o)


> Finally, one might also consider a sort of "compat-xorg-x11"
> package to accomodate the needs of older packages, which
> might only exist in binary form, e.g. "Mathematica".

Bwahahahahaha!  ;oP

> PS: "X/OpenGL Maintainence List (xgl-maint at redhat.com)"
>                    ^^^^
> 
>      Ouch! Could somebody have a look at this? I am not a native
>      speaker, but this appears to be quite exotic. This usually
>      writes "Maintenance", doesn't it?

Illiteracy runs rampant, even at Red Hat!  ;o)  Fortunately,
it wasn't I who created this internal mailing list, so I get
to laugh and point fingers with the rest of you at whoever it
was.   ;oP



From davem at iabyn.com  Sat Nov 19 13:43:07 2005
From: davem at iabyn.com (Dave Mitchell)
Date: Sat, 19 Nov 2005 13:43:07 +0000
Subject: init: API
In-Reply-To: <1132395384.9723.17.camel@rousalka.dyndns.org>
References: <1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
Message-ID: <20051119134307.GX4498@iabyn.com>

On Sat, Nov 19, 2005 at 11:16:24AM +0100, Nicolas Mailhot wrote:
> Once again, what is wrong with /etc/fonts/fonts.conf ?

Because my brain can't parse XML. I'm speaking as someone who recently
spent a lot of time messing with Ant files (XML/java based replacement for
make). A simple example from /etc/fonts/fonts.conf:

<!--
  Accept deprecated 'mono' alias, replacing it with 'monospace'
-->
        <match target="pattern">
                <test qual="any" name="family">
                        <string>mono</string>
                </test>
                <edit name="family" mode="assign">
                        <string>monospace</string>
                </edit>
        </match>

There are 22 words in that chunk, of which 3 are the important ones
(family/mono/monospace).  You can stare at that for minutes and what its
doing still doesn't leap out at you.

XML (like postscript) is good for situations where it isn't expected to
be handled by humans, and lousy where it is.

It's a bit like replacing the following C declaration:

    const char *s = "abc";

with

    <declaration-list>
	<declaration>
	    <name>s</name>
	    <type>char *</type>
	    <attribute-list>
		<attribute>const</attribute>
	    </attribute-list>
	    <initializer>"abc"</initializer>
	>
	</declaration>
    </declaration-list>

-- 
Little fly, thy summer's play my thoughtless hand
has terminated with extreme prejudice.
        (with apologies to William Blake)



From nicolas.mailhot at laposte.net  Sat Nov 19 13:51:25 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 19 Nov 2005 14:51:25 +0100
Subject: init: API
In-Reply-To: <20051119134307.GX4498@iabyn.com>
References: <1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<20051119134307.GX4498@iabyn.com>
Message-ID: <1132408286.3133.5.camel@rousalka.dyndns.org>

Le samedi 19 novembre 2005 ? 13:43 +0000, Dave Mitchell a ?crit :
> On Sat, Nov 19, 2005 at 11:16:24AM +0100, Nicolas Mailhot wrote:
> > Once again, what is wrong with /etc/fonts/fonts.conf ?
> 
> Because my brain can't parse XML. I'm speaking as someone who recently
> spent a lot of time messing with Ant files (XML/java based replacement for
> make). A simple example from /etc/fonts/fonts.conf:
> 
> <!--
>   Accept deprecated 'mono' alias, replacing it with 'monospace'
> -->
>         <match target="pattern">
>                 <test qual="any" name="family">
>                         <string>mono</string>
>                 </test>
>                 <edit name="family" mode="assign">
>                         <string>monospace</string>
>                 </edit>
>         </match>
> 
> There are 22 words in that chunk, of which 3 are the important ones
> (family/mono/monospace).  You can stare at that for minutes and what its
> doing still doesn't leap out at you.

And how would you express this in so its doings would leap at you ? What
is described here is not a simple operation, a more traditional syntax
would probably have used regexpes and other "simple" stuff which
requires 2 hours of man-page reading to be understood (let alone
modified). But sure, it would probably have been more compact.

-- 
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/20051119/7d533cf8/attachment.sig>

From gilboada at netvision.net.il  Sat Nov 19 14:35:14 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sat, 19 Nov 2005 16:35:14 +0200
Subject: init: API
In-Reply-To: <1132394893.9723.8.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
	<1132376001.9736.63.camel@gilboa-home-dev.localhost>
	<1132394893.9723.8.camel@rousalka.dyndns.org>
Message-ID: <1132410914.9736.66.camel@gilboa-home-dev.localhost>

On Sat, 2005-11-19 at 11:08 +0100, Nicolas Mailhot wrote:
> Le samedi 19 novembre 2005 ? 06:53 +0200, Gilboa Davara a ?crit :
> 
> > B. There are dozens of project that do config parsing; why not find a
> > good text parser and use it code? 
> 
> This parser exists it's called libxml
> 

I was talking about /simple text/ parsers, no XML one.

Gilboa



From dwmw2 at infradead.org  Sat Nov 19 15:23:30 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sat, 19 Nov 2005 15:23:30 +0000
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <200511181049.46383.lamont@gurulabs.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<200511181049.46383.lamont@gurulabs.com>
Message-ID: <1132413810.3642.120.camel@baythorne.infradead.org>

On Fri, 2005-11-18 at 10:49 -0700, Lamont R. Peterson wrote:
> > Frankly speaking I think that's a good idea to make this symlink, until
> > all issues, concerned with modular Xorg, will be resolved.
> 
> I would be concerned about opening that floodgate.  If we do, then there is no 
> reason for people to care to fix their code.

Perhaps we could make the symlink, but configure the selinux policy to
bitch if it's ever actually used?

-- 
dwmw2




From petro at mail.ru  Sat Nov 19 15:47:50 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 19 Nov 2005 18:47:50 +0300
Subject: More modularization.
In-Reply-To: <437F1658.5090000@redhat.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
	<437F1658.5090000@redhat.com>
Message-ID: <Pine.LNX.4.64.0511191835211.13882@lemenkov.com>

On Sat, 19 Nov 2005, Mike A. Harris wrote:

>> I (and many others, definitely) haven't neither i810-based cars, nor others 
>> from this list. So question is - why I enforced to install all of these 
>> dri-modules? We can simply split this package into a bunch of little 
>> packages, for example mesa-libGL, mesa-dri-i810, mesa-dri-i830, etc. It''s 
>> not a hard work, IMO.

> This is a long term possible feature.  In order for this to happen, here
> is what needs to be done:

Looks like we are talking abount different things, Mike.
For splitting Mesa-package, we don't need to submit even single line of 
code into mainstream Mesa-sourcetree. All we need is to provide additional 
subpackages in the SPEC-file (look at attachment, where I provide a patch 
to the mesa.spec, used for building FC's mesa* rpm's).

All we need is to properly patch SPEC-file.

>> The same thing with kernel. Not all of kernel-modules are needed actually. 
>> Why don't repack kernel into kernel, kernel-modules-all (which contains 
>> nothing, actually, but installs a huge number of small packages with 
>> modules itself - the way xorg-x11-drivers does).

> The X server has a stable Xserver<->driver ABI in one direction.  This
> means that from one bugfix release of a driver to the next, the driver
> will work with the same X server.  And new X servers generally will
> work with the drivers they shipped with, as well as drivers from the
> previous release or two.  Every few releases of the X server, something
> sometimes changes which breaks the ABI however, but it is generally
> quite stable for 1-2 years or so.
>
> The kernel on the other hand, very intentionally does not have a
> kernel<->module ABI at all whatsoever.  Last I heard, Linus had no
> interest in giving the kernel a stable module ABI.  Having the
> kernel broken up into a bunch of individual per-driver modules
> would probably be a massive nightmare.  I wouldn't hold your breath
> waiting for that to happen.  ;o)

Who tolds about stable ABI-interface? I just suggest to split kernel into 
a number of packages and add "virtual" one, that install all of them. Of 
course, then someone will upgrade the kernel *all* installed packages 
would be upgraded.

-- 
With best regards, Peter Lemenkov.
-------------- next part --------------
--- mesa-orig.spec	2005-11-04 03:53:39.000000000 +0300
+++ mesa.spec	2005-11-19 16:41:43.000000000 +0300
@@ -175,6 +175,79 @@
 
 %description libGLw-devel
 Mesa libGLw development package
+
+#-- DRI    -----------------------------------------------------------
+%package dri-i810
+Summary: Mesa DRI module for i810 videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-i810
+Mesa DRI module for i810 videocard
+
+%package dri-i830
+Summary: Mesa DRI module for i830 videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-i830
+Mesa DRI module for i830 videocard
+
+%package dri-i915
+Summary: Mesa DRI module for i915 videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-i915
+Mesa DRI module for i915 videocard
+
+%package dri-mga
+Summary: Mesa DRI module for MGA videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-mga
+Mesa DRI module for MGA videocard
+
+%package dri-r128
+Summary: Mesa DRI module for r128 videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-r128
+Mesa DRI module for r128 videocard
+
+%package dri-r200
+Summary: Mesa DRI module for videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-r200
+Mesa DRI module for r200 videocard
+
+%package dri-radeon
+Summary: Mesa DRI module for Radeon videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-radeon
+Mesa DRI module for Radeon videocard
+
+%package dri-savage
+Summary: Mesa DRI module for Savage videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-savage
+Mesa DRI module for Savage videocard
+
+%package dri-sis
+Summary: Mesa DRI module for SIS videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-sis
+Mesa DRI module for SIS videocard
+
+%package dri-unichrome
+Summary: Mesa DRI module for Unichrome videocard.
+Group: Development/Libraries
+Requires: libGL = %{version}-%{release}
+%description dri-unichrome
+Mesa DRI module for Unichrome videocard
+#-- DRI    -----------------------------------------------------------
+
 #-- source -----------------------------------------------------------
 %package source
 Summary: Mesa source code required to build X server
@@ -288,13 +361,13 @@
 # builds, although it isn't clear what the rationale for this is to me yet,
 # nonetheless, I'm conditionalizing it to get it to build.
 #%{_libdir}/libGL.so.1.2
-%dir %{_libdir}/dri
+#%dir %{_libdir}/dri
 # NOTE: This is a glob for now, as we explicitly determine and limit the DRI
 # drivers that are installed on a given OS/arch combo in our custom DRI
 # driver install script.  If the upstream install script improves enough to
 # make our script unnecessary, we might want to change to an explicit file
 # manifest here in the future.
-%{_libdir}/dri/*_dri.so
+#%{_libdir}/dri/*_dri.so
 # NOTE: Documentive list of all DRI drivers built by default in Mesa 6.3.2
 #%{_libdir}/dri/ffb_dri.so
 #%{_libdir}/dri/i810_dri.so
@@ -372,6 +445,37 @@
 %files source -f mesa-source-rpm-filelist.lst
 %defattr(-,root,root,-)
 
+%files dri-i810
+%defattr(-,root,root,-)
+%{_libdir}/dri/i810_dri.so
+%files dri-i830
+%defattr(-,root,root,-)
+%{_libdir}/dri/i830_dri.so
+%files dri-i915
+%defattr(-,root,root,-)
+%{_libdir}/dri/i915_dri.so
+%files dri-mga
+%defattr(-,root,root,-)
+%{_libdir}/dri/mga_dri.so
+%files dri-r128
+%defattr(-,root,root,-)
+%{_libdir}/dri/r128_dri.so
+%files dri-r200
+%defattr(-,root,root,-)
+%{_libdir}/dri/r200_dri.so
+%files dri-radeon
+%defattr(-,root,root,-)
+%{_libdir}/dri/radeon_dri.so
+%files dri-savage
+%defattr(-,root,root,-)
+%{_libdir}/dri/savage_dri.so
+%files dri-sis
+%defattr(-,root,root,-)
+%{_libdir}/dri/sis_dri.so
+%files dri-unichrome
+%defattr(-,root,root,-)
+%{_libdir}/dri/unichrome_dri.so
+
 %changelog
 * Thu Nov 3 2005 Mike A. Harris <mharris at redhat.com> 6.4-4
 - Wrote redhat-mesa-source-filelist-generator to dynamically generate the

From mharris at redhat.com  Sat Nov 19 16:09:40 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 11:09:40 -0500
Subject: Simple content management systems.
Message-ID: <437F4E44.4000807@redhat.com>

I'm investigating content management systems for maintaining Fedora
related pages on my site, and looking for something that does not
require mysql or any other database backend.  Something very simple
and self contained within the web root, with as few web server
configuration requirements, and as few software requirements as
necessary.  It's also rather important to me that the software
be 100% true open source software, licensed under the GPLv2 or
BSD license or something, with no advertising clauses or other
garbage to restrict freedom.

It was recommended that I have a look at "Limbo", and while perusing
their site, I found it was GPL licensed.  After taking a closer look
at the license however:

http://www.limbo-cms.com/index.php/option/content/pcontent/1/task/view/id/29/Itemid/67

It is GPL licensed, but they also force you to include a link to their
website, or they will contact your ISP to have the site removed unless
you purchase a commercial license.

Um.  Hello?  How exactly is that "open source" or "GPL"?  I'm not
quite sure.  Maybe a good slashdotting would get the situation
corrected...

Anyhow, does anyone have any suggestions to something simple which
might be of use to my Fedora documentive purposes?

TIA.



From mharris at redhat.com  Sat Nov 19 16:23:08 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sat, 19 Nov 2005 11:23:08 -0500
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>	<437F1658.5090000@redhat.com>
	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
Message-ID: <437F516C.1050502@redhat.com>

Peter Lemenkov wrote:
> On Sat, 19 Nov 2005, Mike A. Harris wrote:
> 
>>> I (and many others, definitely) haven't neither i810-based cars, nor 
>>> others from this list. So question is - why I enforced to install all 
>>> of these dri-modules? We can simply split this package into a bunch 
>>> of little packages, for example mesa-libGL, mesa-dri-i810, 
>>> mesa-dri-i830, etc. It''s not a hard work, IMO.
> 
> 
>> This is a long term possible feature.  In order for this to happen, here
>> is what needs to be done:
> 
> 
> Looks like we are talking abount different things, Mike.
> For splitting Mesa-package, we don't need to submit even single line of 
> code into mainstream Mesa-sourcetree. All we need is to provide 
> additional subpackages in the SPEC-file (look at attachment, where I 
> provide a patch to the mesa.spec, used for building FC's mesa* rpm's).
> 
> All we need is to properly patch SPEC-file.

In short: No. Absolutely not.  ;o)

For the longer version, please reread my first email.  As I stated
therein, this is not due to it being technically impossible to do.
It is a concious and intentional choice that all Mesa drivers are
provided in one package right now, and I plan on keeping it that way
at least until all of the items I outlined in the first email are
met.

Hope that clarifies things.  ;o)



From shiva at sewingwitch.com  Sat Nov 19 16:24:26 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sat, 19 Nov 2005 08:24:26 -0800
Subject: init: API
In-Reply-To: <1132410914.9736.66.camel@gilboa-home-dev.localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
	<1132376001.9736.63.camel@gilboa-home-dev.localhost>
	<1132394893.9723.8.camel@rousalka.dyndns.org>
	<1132410914.9736.66.camel@gilboa-home-dev.localhost>
Message-ID: <A4DC1847910252EC9880A006@[10.0.0.14]>

--On Saturday, November 19, 2005 4:35 PM +0200 Gilboa Davara 
<gilboada at netvision.net.il> wrote:

> I was talking about /simple text/ parsers, no XML one.

How simple? Set the bar too low and you cripple some uses of it. XML's 
value is in generality. You don't actually have to use all of it. Simple 
applications can use very simple styles, and yet still be able to leverage 
the advanced features for corner cases like unusual characters and 
character sets. There's no requirement that your config file has to be 
complex. Package developers will have to support what they define, and 
won't want to spend all their time explaining a complex schema, unless 
their application is equally complex.

For those who love var=value pairs, one could always use m4 to expand that 
into equivalent XML, the way sendmail does to create its legacy cf file 
from the much simpler mc file.



From arjanv at redhat.com  Sat Nov 19 16:27:16 2005
From: arjanv at redhat.com (Arjan van de Ven)
Date: Sat, 19 Nov 2005 17:27:16 +0100
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
	<437F1658.5090000@redhat.com>
	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
Message-ID: <1132417637.2671.4.camel@laptopd505.fenrus.org>

On Sat, 2005-11-19 at 18:47 +0300, Peter Lemenkov wrote:
> 
> Who tolds about stable ABI-interface? I just suggest to split kernel
> into 
> a number of packages and add "virtual" one, that install all of them.
> Of 
> course, then someone will upgrade the kernel *all* installed packages 
> would be upgraded.

and the gain of that is.... ?

abi matters a lot in this really. If you don't have a stable ABI, the
version dependencies get *really* messy, and the user experience goes
down the drain unless.. you make all drivers mandatory again. At which
point you have to ask yourself: "Why do this again"




From bmillett at gmail.com  Sat Nov 19 16:31:30 2005
From: bmillett at gmail.com (Brian Millett)
Date: Sat, 19 Nov 2005 10:31:30 -0600
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <1132417891.4049.18.camel@localhost.localdomain>

On Sat, 2005-11-19 at 11:09 -0500, Mike A. Harris wrote:
> I'm investigating content management systems for maintaining Fedora
> related pages on my site, and looking for something that does not
> require mysql or any other database backend.  Something very simple
> and self contained within the web root, with as few web server
> configuration requirements, and as few software requirements as
> necessary.  It's also rather important to me that the software
> be 100% true open source software, licensed under the GPLv2 or
> BSD license or something, with no advertising clauses or other
> garbage to restrict freedom.

I've seen many apache projects use http://moinmoin.wikiwikiweb.de/ for
their documentation.

-- 
Brian Millett - [ Dr. Franklin and Ivanova, "Soul Hunter"]
"You're a pessimist."
'I am *Russian*, Doctor. We understand these things."




From alan at redhat.com  Sat Nov 19 16:48:16 2005
From: alan at redhat.com (Alan Cox)
Date: Sat, 19 Nov 2005 11:48:16 -0500
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <20051119164816.GA7401@devserv.devel.redhat.com>

On Sat, Nov 19, 2005 at 11:09:40AM -0500, Mike A. Harris wrote:
> It was recommended that I have a look at "Limbo", and while perusing
> their site, I found it was GPL licensed.  After taking a closer look
> at the license however:
> 
> http://www.limbo-cms.com/index.php/option/content/pcontent/1/task/view/id/29/Itemid/67

If its GPL then their license is a GPL violation. I'd contact the original
mambo authors as it contains original mambo code (see "about"). Or just use
it and if they contact your ISP sue them for defamation 8)

I wouldn't recommend mambo based stuff btw, its performance under load is
dreadfully poor.

Alan



From shiva at sewingwitch.com  Sat Nov 19 16:18:06 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sat, 19 Nov 2005 08:18:06 -0800
Subject: init: API
In-Reply-To: <20051119051258.GC1126723@hiwaay.net>
References: <1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051119051258.GC1126723@hiwaay.net>
Message-ID: <76520FB0EF98BD23AC3CC34D@[10.0.0.14]>

--On Friday, November 18, 2005 11:12 PM -0600 Chris Adams 
<cmadams at hiwaay.net> wrote:

> This is the init system.  When it doesn't work, I'll have to fix it on a
> VT510 hooked up to the serial console.  I don't want to have to jump
> through a lot of hoops to have to fix the system (so /usr may not be
> available for example); how do I use an XML editor?

Luxury these kids have today. In my day we had TECO on a printing terminal, 
and *liked it*. And before me, the old guys had to edit their config files 
with the toggle switches on the front panel. And sneered at me for being 
such a wuss to need that fancy ASCII terminal. ;)




From buildsys at redhat.com  Sat Nov 19 17:07:57 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 19 Nov 2005 12:07:57 -0500
Subject: rawhide report: 20051119 changes
Message-ID: <200511191707.jAJH7vK9018383@porkchop.devel.redhat.com>

 

Removed package openmotif21

Updated Packages:

anaconda-10.90.5-1.1
--------------------
* Fri Nov 18 2005 Paul Nasrat <pnasrat at redhat.com> - 10.90.5-1.1
- Disable sqlite cache for pkgorder
- Fix for new selinux context types (katzj)
- vnc parameter handling (clumens)
- Add ellipsis (notting)

* Thu Nov 17 2005 Jeremy Katz <katzj at redhat.com> - 10.90.4-1
- don't traceback on unresolvable deps (#173508)
- fix pkg.arch for %packages
- another hack for vnc
- debug prints to log.debug (#173533)

* Thu Nov 17 2005 Paul Nasrat <pnasrat at redhat.com> - 10.90.3-1
- Add group processing to buildinstall
- Add createrepo requires

autofs-1:4.1.4-14
-----------------
* Thu Nov 17 2005 Jeff Moyer <jmoyer at redhat.com> - 1:4.1.4-14
- Removed the /misc entry from the default auto.master.  auto.misc has
  an entry for the cdrom device, and the preferred method of mounting the
  cd is via udev/hal.

booty-0.60-2
------------
* Fri Nov 18 2005 Peter Jones <pjones at redhat.com> 0.60-2
- fix raid on ppc

createrepo-0.4.3-5
------------------
* Fri Nov 18 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-5
- Fix split with normalised directories

* Fri Nov 18 2005 Paul Nasrat <pnasrat at redhat.com> - 0.4.3-4
- Another typo fix
- Normalise directories

firefox-1.5-0.5.0.rc3
---------------------
* Fri Nov 18 2005 Christopher Aillon <caillon at redhat.com> - 1.5-0.5.0.rc3
- Update to 1.5 rc3

hwdata-0.172-1
--------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> - 0.172-1
- ditto for radeon

* Fri Nov 18 2005 Jeremy Katz <katzj at redhat.com> - 0.171-1
- r128 -> ati.  should fix the unresolved symbol and kem says its more 
  generally the "right" thing to do

linuxwacom-0:0.6.6-8
--------------------
* Fri Nov 18 2005 Kristian H??gsberg <krh at redhat.com> 0:0.6.6-8
- Update to work with new X11 paths.
- Patch build system to work with modular X sdk.

openssh-4.2p1-8
---------------
* Fri Nov 18 2005 Nalin Dahyabhai <nalin at redhat.com> - 4.2p1-8
- work around missing gccmakedep by wrapping makedepend in a local script
- remove now-obsolete build dependency on "xauth"

* Thu Nov 17 2005 Warren Togami <wtogami at redhat.com> - 4.2p1-7
- xorg-x11-devel -> libXt-devel
- rebuild for new xauth location so X forwarding works
- buildreq audit-libs-devel
- buildreq automake for aclocal
- buildreq imake for xmkmf
-  -D_GNU_SOURCE in flags in order to get it to build
   Ugly hack to workaround openssh defining __USE_GNU which is
   not allowed and causes problems according to Ulrich Drepper
   fix this the correct way after FC5test1

pm-utils-0.06-3
---------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> - 0.06-3
- nix that, wait for the kernel to settle down

synaptics-0:0.14.4-4
--------------------
* Fri Nov 18 2005 Jeremy Katz <katzj at redhat.com> - 0:0.14.4-4
- fix install destination too

* Fri Nov 18 2005 Jeremy Katz <katzj at redhat.com> - 0:0.14.4-3
- patch for modular X include paths

* Fri Nov 18 2005 Kristian H??gsberg <krh at redhat.com> - 0:0.14.4-2
- Remove last bits of monolithic X paths.

vnc-4.1.1-22
------------
* Fri Nov 18 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-22
- Extension module is not available on all architectures.

* Fri Nov 18 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-21
- Install extension module into the correct directory.

* Fri Nov 18 2005 Tim Waugh <twaugh at redhat.com> 4.1.1-20
- Fix font path correctly (bug #173160).




Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390x requires dmraid








From toshio at tiki-lounge.com  Sat Nov 19 17:17:41 2005
From: toshio at tiki-lounge.com (Toshio Kuratomi)
Date: Sat, 19 Nov 2005 09:17:41 -0800
Subject: init: API
In-Reply-To: <1132395494.9723.20.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
Message-ID: <1132420661.6042.25.camel@localhost>

On Sat, 2005-11-19 at 11:18 +0100, Nicolas Mailhot wrote:
> Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
> > On Fri, 18 Nov 2005 22:06:35 -0500, Alan Cox <alan at redhat.com> wrote:
> > 
> > > > "only package maintainers do init.d scripts", I also tend to edit
> > > > scripts by hand. 
> > > 
> > > Use an XML editor. If its got the DTD/schema/etc then it won't let you
> > > make a mistake and it can present the document in a sane manner. Any 
> > > document..
> > 
> > Any suggestions for one which actually works and is not emacs?
> 
> Just use vim for syntax highlighting and xmllint to check the result.
> 
> 100% light-weight CLI solution.

Not in a recovery situation where /usr is unavailable, though.  We could
move libxml2, zlib, and xmllint to / to make it available.  I don't
think that moving /usr/share/vim to / is advisable, though, so syntax
highlighting probably won't work....

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051119/da4fd708/attachment.sig>

From skvidal at phy.duke.edu  Sat Nov 19 17:25:22 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 19 Nov 2005 12:25:22 -0500
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <1132421123.31873.15.camel@cutter>

On Sat, 2005-11-19 at 11:09 -0500, Mike A. Harris wrote:
> I'm investigating content management systems for maintaining Fedora
> related pages on my site, and looking for something that does not
> require mysql or any other database backend.  Something very simple
> and self contained within the web root, with as few web server
> configuration requirements, and as few software requirements as
> necessary.  It's also rather important to me that the software
> be 100% true open source software, licensed under the GPLv2 or
> BSD license or something, with no advertising clauses or other
> garbage to restrict freedom.
> 
> It was recommended that I have a look at "Limbo", and while perusing
> their site, I found it was GPL licensed.  After taking a closer look
> at the license however:
> 
> http://www.limbo-cms.com/index.php/option/content/pcontent/1/task/view/id/29/Itemid/67
> 
> It is GPL licensed, but they also force you to include a link to their
> website, or they will contact your ISP to have the site removed unless
> you purchase a commercial license.
> 
> Um.  Hello?  How exactly is that "open source" or "GPL"?  I'm not
> quite sure.  Maybe a good slashdotting would get the situation
> corrected...
> 
> Anyhow, does anyone have any suggestions to something simple which
> might be of use to my Fedora documentive purposes?

How about using the fedoraproject.org/wiki page.

It's a simple wiki and it's GOT a lot of docs there already.

-sv




From skvidal at phy.duke.edu  Sat Nov 19 17:25:50 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 19 Nov 2005 12:25:50 -0500
Subject: Simple content management systems.
In-Reply-To: <1132417891.4049.18.camel@localhost.localdomain>
References: <437F4E44.4000807@redhat.com>
	<1132417891.4049.18.camel@localhost.localdomain>
Message-ID: <1132421150.31873.17.camel@cutter>

> I've seen many apache projects use http://moinmoin.wikiwikiweb.de/ for
> their documentation.
> 

Which is, in fact, what we're using at fedoraproject.org. I'm positive
he can get write access. :)

-sv




From michael.favia at insitesinc.com  Sat Nov 19 17:56:57 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Sat, 19 Nov 2005 11:56:57 -0600
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <437F6769.40903@insitesinc.com>

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

Mike A. Harris wrote:

> Anyhow, does anyone have any suggestions to something simple which
> might be of use to my Fedora documentive purposes?

I use drupal (pronounced dru-puhl). And have found it able to easily
adapt itself to a variety of projects with the use of user contrib
modules. Most anything your heart desires has been written up as a
module but creating one of your own is actually very painless if needed
(polls, profiles, hierarchicay taxonomy, etc already exist). With
caching properly enabled it seems to run fairly well for me under heay
load. Let me know if you need a hand setting it up or just generally
understanding the purpose and usability of the platform.

http://drupal.org/ <-- main site
http://drupal.org/project/Modules <-- modules
http://drupal.org/handbooks <-- docs

- --
Michael Favia          michael.favia at insitesinc.com
Insites Incorporated  http://michael.insitesinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDf2dpBVsNYjF2rDYRArUoAKCGtmBpz8AxTcAeZCR1tlkLAQ43XQCfU61B
TEqPiZSmyk+t4rZ6kqTefLQ=
=oH49
-----END PGP SIGNATURE-----



From nman64 at n-man.com  Sat Nov 19 18:35:18 2005
From: nman64 at n-man.com (Patrick Barnes)
Date: Sat, 19 Nov 2005 12:35:18 -0600
Subject: Simple content management systems.
In-Reply-To: <437F6769.40903@insitesinc.com>
References: <437F4E44.4000807@redhat.com> <437F6769.40903@insitesinc.com>
Message-ID: <437F7066.9090509@n-man.com>

I second Seth's recommendation.  You can contribute documents to the
general public anywhere in the wiki.  Documents you want under your own
namespace can be placed under
http://fedoraproject.org/wiki/MikeAHarris.  If you really want something
on your own site, MoinMoin really is good.  It is written in Python. 
It's easy to set up.  It is very robust and flexible.  If you run into
problems, you'll find others in this community who can assist you.  I
also use MoinMoin for my personal site at http://www.n-man.com/.

-- 
Patrick "The N-Man" Barnes
nman64 at n-man.com

www.n-man.com
-- 



-------------- 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/20051119/76a3d3d4/attachment.sig>

From laroche at redhat.com  Sat Nov 19 19:14:16 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 19 Nov 2005 20:14:16 +0100
Subject: X11-forwarding over SSH didn't work!
In-Reply-To: <437F1B6C.50801@redhat.com>
References: <Pine.LNX.4.64.0511181313580.5566@lemenkov.com>
	<200511181049.46383.lamont@gurulabs.com>
	<437F1B6C.50801@redhat.com>
Message-ID: <20051119191416.GA7591@dudweiler.stuttgart.redhat.com>

> By contributing to reporting bugs, and/or fixing the broken
> applications, people will help to get rid of such compatibility
> problems much sooner, and the whole community will benefit from
> it.

On the other side keeping things compatibel should be a goal
for all necessary changes we do.

regards,

Florian La Roche



From gilboada at netvision.net.il  Sat Nov 19 19:23:22 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sat, 19 Nov 2005 21:23:22 +0200
Subject: init: API
In-Reply-To: <A4DC1847910252EC9880A006@[10.0.0.14]>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<1cef3e950511181955w1fac2549r346dcaf80bb61091@mail.gmail.com>
	<1132376001.9736.63.camel@gilboa-home-dev.localhost>
	<1132394893.9723.8.camel@rousalka.dyndns.org>
	<1132410914.9736.66.camel@gilboa-home-dev.localhost>
	<A4DC1847910252EC9880A006@[10.0.0.14]>
Message-ID: <1132428202.8579.10.camel@gilboa-home-dev.localhost>

On Sat, 2005-11-19 at 08:24 -0800, Kenneth Porter wrote:
> --On Saturday, November 19, 2005 4:35 PM +0200 Gilboa Davara 
> <gilboada at netvision.net.il> wrote:
> 
> > I was talking about /simple text/ parsers, no XML one.
> 
> How simple? Set the bar too low and you cripple some uses of it. XML's 
> value is in generality. You don't actually have to use all of it. Simple 
> applications can use very simple styles, and yet still be able to leverage 
> the advanced features for corner cases like unusual characters and 
> character sets. There's no requirement that your config file has to be 
> complex. Package developers will have to support what they define, and 
> won't want to spend all their time explaining a complex schema, unless 
> their application is equally complex.

Again, I fail to see why we need complex text inside the package
manager.
Even if you must, you can always shove the translation strings
into /usr/share/locale. (Or /etc/scm/locale if you which to load it from
within initrd.)
It seems the people tend to confuse the application configuration
(AKA /etc/samba/smb.conf) and the service configuration (/etc/init.d/smb
or /etc/scm/samba.conf).
The service manager (scm) configuration should be as simple as it gets.
Same goes, in my eyes, with the service manager itself.


> 
> For those who love var=value pairs, one could always use m4 to expand that 
> into equivalent XML, the way sendmail does to create its legacy cf file 
> from the much simpler mc file.
> 

Adding yet another step of complexity just to fix a dead service.

Gilboa



From kwade at redhat.com  Sat Nov 19 20:35:58 2005
From: kwade at redhat.com (Karsten Wade)
Date: Sat, 19 Nov 2005 12:35:58 -0800
Subject: Simple content management systems.
In-Reply-To: <1132421123.31873.15.camel@cutter>
References: <437F4E44.4000807@redhat.com> <1132421123.31873.15.camel@cutter>
Message-ID: <1132432558.3572.281.camel@erato.phig.org>

On Sat, 2005-11-19 at 12:25 -0500, seth vidal wrote:
> On Sat, 2005-11-19 at 11:09 -0500, Mike A. Harris wrote:
> > 
> > Anyhow, does anyone have any suggestions to something simple which
> > might be of use to my Fedora documentive purposes?
> 
> How about using the fedoraproject.org/wiki page.
> 
> It's a simple wiki and it's GOT a lot of docs there already.

In addition, we are already looking into a CMS that plugs into that site
and existing systems.  This would like Mike (and others) share in the
work and reward.

- Karsten
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
Content Services                          Fedora Documentation Project
http://www.redhat.com/docs   http://fedoraproject.org/wiki/DocsProject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051119/1b2d3211/attachment.sig>

From petro at mail.ru  Sat Nov 19 21:03:14 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sun, 20 Nov 2005 00:03:14 +0300
Subject: More modularization.
In-Reply-To: <437F516C.1050502@redhat.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
	<437F1658.5090000@redhat.com>
	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
	<437F516C.1050502@redhat.com>
Message-ID: <Pine.LNX.4.64.0511192355390.10662@lemenkov.com>

On Sat, 19 Nov 2005, Mike A. Harris wrote:

>> All we need is to properly patch SPEC-file.

> In short: No. Absolutely not.  ;o)
> For the longer version, please reread my first email.  As I stated
> therein, this is not due to it being technically impossible to do.
> It is a concious and intentional choice that all Mesa drivers are
> provided in one package right now, and I plan on keeping it that way
> at least until all of the items I outlined in the first email are
> met.

Look. I haven't any of old, good videocard listed in mesa-libGL package.
So why I haven't a way to properly strip down the package, instead of 
manually remove never used dri-modules?

I don't concern a way of maintaining the source of Mesa (in one package, 
in two packages, even in one tarball per file), I do concern the result of 
building from %{_tmppath}/%{name}-%{version}-%{release}-buildroot. After 
the successful compilation mesa packs into a number of packages, so why 
just don't increase its number? :)

If someone rejects installing of particular dri-modules, everything will 
be OK, 'cause if user don't have some mesa-dri-supported videocard, the 
apropriate *.so-module wouldn't be used. So why take care?

Ok, maybe it's a kinda of religion/ideology to keep *all* modules 
simultaneously?

-- 
With best regards, Peter Lemenkov.




From petro at mail.ru  Sat Nov 19 20:49:20 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 19 Nov 2005 23:49:20 +0300
Subject: More modularization.
In-Reply-To: <1132417637.2671.4.camel@laptopd505.fenrus.org>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
	<437F1658.5090000@redhat.com>
	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
	<1132417637.2671.4.camel@laptopd505.fenrus.org>
Message-ID: <Pine.LNX.4.64.0511192334490.10662@lemenkov.com>

On Sat, 19 Nov 2005, Arjan van de Ven wrote:

>> Who tolds about stable ABI-interface? I just suggest to split kernel 
>> into a number of packages and add "virtual" one, that install all of 
>> them. Of course, then someone will upgrade the kernel *all* installed 
>> packages would be upgraded.

> abi matters a lot in this really. If you don't have a stable ABI, the
> version dependencies get *really* messy, and the user experience goes
> down the drain unless.. you make all drivers mandatory again. At which
> point you have to ask yourself: "Why do this again"

Who told about ABI at all? I told about splitting kernel-package within 
the particular version, *not* about partial upgrade (say, kernel will be 
2.6.14-1.1700, although video-driver is still from some previous kernel - 
that's a situation there ABI do matter!). User will be forced to upgrade 
all its modules, then he changes its kernel.

Everything will be ok, if every little package with kernel module inside 
will have

> Requires: kernel = 2.6.14-1.1688

or something of that kind.

Look - we got livna's kernel modules. They're all installs and runs w/o 
troubles. Guess why? Look at "requires" :).

Ok, summarizing - i suggest a way to strip down the kernel package, thus 
reducing its weight (my handmade kernel for my PC weights about 2 mbytes - 
compare with 40+ mbytes of FC's generic kernel). If every module would 
have proper "requires"-field, all would be OK. :)

Of course, when upgrading, yum must upgrading only those modules, which 
user choosed before (the way xorg-x11-drivers do, - note! I don't say 
about ABI - aii things are done within particular kernel, w/o mixing 
modules).

-- 
With best regards, Peter Lemenkov.




From shiva at sewingwitch.com  Sat Nov 19 21:32:14 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sat, 19 Nov 2005 13:32:14 -0800
Subject: init: API
In-Reply-To: <1132420661.6042.25.camel@localhost>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
Message-ID: <F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>

--On Saturday, November 19, 2005 9:17 AM -0800 Toshio Kuratomi 
<toshio at tiki-lounge.com> wrote:

> Not in a recovery situation where /usr is unavailable, though.

You can boot a fairly full-featured rescue system from a USB key. A GB key 
costs about $80. I'd hope libxml takes less space than that!

<http://featherlinux.berlios.de/usb-instructions.htm>

<http://openfacts.berlios.de/index-en.phtml?title=Linux_bootable_USB_key_HOWTO>



From mpeters at mac.com  Sat Nov 19 21:43:17 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Sat, 19 Nov 2005 13:43:17 -0800
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
Message-ID: <1132436597.16728.4.camel@locolhost.localdomain>

On Sat, 2005-11-19 at 13:01 +0300, Peter Lemenkov wrote:
> Hello, All!
> 
> Just my simple proposal. If we look into mesa-libGL package, we'll see a 
> number of dri-modules:
> 
> [petro at Petro ~]$ rpm -ql mesa-libGL

*snip*

> 
> I (and many others, definitely) haven't neither i810-based cars, nor 
> others from this list. So question is - why I enforced to install all of 
> these dri-modules? We can simply split this package into a bunch of little 
> packages, for example mesa-libGL, mesa-dri-i810, mesa-dri-i830, etc. It''s 
> not a hard work, IMO.
> 
> The same thing with kernel. Not all of kernel-modules are needed actually. 
> Why don't repack kernel into kernel, kernel-modules-all (which contains 
> nothing, actually, but installs a huge number of small packages with 
> modules itself - the way xorg-x11-drivers does).
> 
> Any ideas?

It doesn't save much space, the modules are not loaded if not used - and
one thing I really like about RH/Fedora - CPU fries? no problem.

Slap in a new board - which may be different chipset, may require a
completely different video card, etc. - kudzu just figures it out - and
I'm good to go.

When my Athlon 900 system w/ VIA chipset and voodoo3 died - and I
switched to an nforce2 system which required a new video card, I went
nvidia - first booting, it took a few extra seconds as it had to change
the hardware settings and migrate my NIC settings etc. - but it just
worked.

Can this still be accomplished if you go modular with that stuff? Only
way I see possible, since it is hardware specific stuff, is if they all
are installed anyway - in which case, do they need to be split up?



From cmadams at hiwaay.net  Sat Nov 19 22:30:16 2005
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 19 Nov 2005 16:30:16 -0600
Subject: init: API
In-Reply-To: <F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
References: <1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
Message-ID: <20051119223016.GA1480245@hiwaay.net>

Once upon a time, Kenneth Porter <shiva at sewingwitch.com> said:
> --On Saturday, November 19, 2005 9:17 AM -0800 Toshio Kuratomi 
> <toshio at tiki-lounge.com> wrote:
> >Not in a recovery situation where /usr is unavailable, though.
> 
> You can boot a fairly full-featured rescue system from a USB key. A GB key 
> costs about $80. I'd hope libxml takes less space than that!

That also requires physical access to the system.
-- 
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 jfrieben at freesurf.fr  Sat Nov 19 22:35:52 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 19 Nov 2005 23:35:52 +0100 (CET)
Subject: Savage DRI broken in modular X
In-Reply-To: <437F2657.4060109@redhat.com>
References: <437F2657.4060109@redhat.com>
Message-ID: <9157.194.94.224.254.1132439752.squirrel@jose.freesurf.fr>

>
> Whenever I fix the mesa package, and you upgrade to the new
> package, your system will probably break due to that
> symlink.  ;o)
>

I can't follow here. The worst thing to happen is that the symlink
might not be used anymore, once the "Mesa" library gets fixed to
look up in "/usr/lib/dri". The directory "/usr/lib/dri" is unlikely
to change some time soon, and even if it did, the orphaned link
could hardly cause any problem. Given "DRI" up and running today,
this is an acceptable trade-off and allowed furthermore to
successfully identify the bug. Anyway, thanks for your advice.

>
>> Finally, one might also consider a sort of "compat-xorg-x11"
>> package to accomodate the needs of older packages, which
>> might only exist in binary form, e.g. "Mathematica".
>
> Bwahahahahaha!  ;oP
>

It's not that ridiculous. "Mathematica" for example has "Open
Motif 2.1.30" compiled in statically. After fixing the font
problem - the new ISO 10646 fonts lead to empty buttons what I
fixed by installing the ISO 8859 fonts afterwards - I am now
facing error messages of the kind:

"Warning: translation table syntax error: Unknown keysym name:
osfBeginLine Warning: translation table syntax error: %s" ...

For backwards compatibility, Red Hat still provides packages
like: "compat-libstdc++-296-2.96", "compat-openldap-2.3.11"
and many others. This made me think of the possible need to
provide older applications with some legacy stuff.

>> PS: "X/OpenGL Maintainence List (xgl-maint at redhat.com)"
>>                    ^^^^
>>
>>      Ouch! Could somebody have a look at this? I am not a native
>>      speaker, but this appears to be quite exotic. This usually
>>      writes "Maintenance", doesn't it?
>
> Illiteracy runs rampant, even at Red Hat!  ;o)  Fortunately,
> it wasn't I who created this internal mailing list, so I get
> to laugh and point fingers with the rest of you at whoever it
> was.   ;oP
>

Maybe you could also inform your post/web master in order to fix this
stupid mistake? Thanks.




From davem at iabyn.com  Sat Nov 19 22:59:33 2005
From: davem at iabyn.com (Dave Mitchell)
Date: Sat, 19 Nov 2005 22:59:33 +0000
Subject: init: API
In-Reply-To: <1132408286.3133.5.camel@rousalka.dyndns.org>
References: <1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<20051119134307.GX4498@iabyn.com>
	<1132408286.3133.5.camel@rousalka.dyndns.org>
Message-ID: <20051119225933.GZ4498@iabyn.com>

On Sat, Nov 19, 2005 at 02:51:25PM +0100, Nicolas Mailhot wrote:
> Le samedi 19 novembre 2005 ? 13:43 +0000, Dave Mitchell a ?crit :
> > <!--
> >   Accept deprecated 'mono' alias, replacing it with 'monospace'
> > -->
> >         <match target="pattern">
> >                 <test qual="any" name="family">
> >                         <string>mono</string>
> >                 </test>
> >                 <edit name="family" mode="assign">
> >                         <string>monospace</string>
> >                 </edit>
> >         </match>
> > 
> > There are 22 words in that chunk, of which 3 are the important ones
> > (family/mono/monospace).  You can stare at that for minutes and what its
> > doing still doesn't leap out at you.
> 
> And how would you express this in so its doings would leap at you ? What
> is described here is not a simple operation, a more traditional syntax
> would probably have used regexpes and other "simple" stuff which
> requires 2 hours of man-page reading to be understood (let alone
> modified). But sure, it would probably have been more compact.

This is a bit hand-wavy because I'm not familiar with the font.conf
schema, but for example

    substitute name=family /mono/ "monospace"

-- 
The optimist believes that he lives in the best of all possible worlds.
As does the pessimist.



From shane at geeklords.org  Sat Nov 19 23:09:17 2005
From: shane at geeklords.org (Shane Stixrud)
Date: Sat, 19 Nov 2005 15:09:17 -0800 (PST)
Subject: init: API
In-Reply-To: <20051119223016.GA1480245@hiwaay.net>
References: <1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<20051119223016.GA1480245@hiwaay.net>
Message-ID: <Pine.LNX.4.62.0511191507420.2020@master.geeklords.org>

On Sat, 19 Nov 2005, Chris Adams wrote:

> That also requires physical access to the system.
>

Or it requires having an data center OPS person insert a USB drive when
failure occurs.  Or setting up a pxe recovery system that u can enable and
disable on a per device basis when needed.



From nicolas.mailhot at laposte.net  Sun Nov 20 00:55:47 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 20 Nov 2005 01:55:47 +0100
Subject: init: API
In-Reply-To: <20051119225933.GZ4498@iabyn.com>
References: <1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<20051119134307.GX4498@iabyn.com>
	<1132408286.3133.5.camel@rousalka.dyndns.org>
	<20051119225933.GZ4498@iabyn.com>
Message-ID: <1132448147.3141.8.camel@rousalka.dyndns.org>

Le samedi 19 novembre 2005 ? 22:59 +0000, Dave Mitchell a ?crit :

> This is a bit hand-wavy because I'm not familiar with the font.conf
> schema, but for example
> 
>     substitute name=family /mono/ "monospace"

Perfect example of subtle flat-file syntax no one can understand without
the man page under its eyes. Push a few more lines like this, each with
its own rules hidden in magic characters like /, and you get something
pretty much impossible to administer (let alone write a robust parser
for)

Though I do admit if you have the rulebook in your head you can edit it
with basic tools.

-- 
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/20051120/18e88ffa/attachment.sig>

From davem at iabyn.com  Sun Nov 20 01:11:37 2005
From: davem at iabyn.com (Dave Mitchell)
Date: Sun, 20 Nov 2005 01:11:37 +0000
Subject: init: API
In-Reply-To: <1132448147.3141.8.camel@rousalka.dyndns.org>
References: <1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<20051119134307.GX4498@iabyn.com>
	<1132408286.3133.5.camel@rousalka.dyndns.org>
	<20051119225933.GZ4498@iabyn.com>
	<1132448147.3141.8.camel@rousalka.dyndns.org>
Message-ID: <20051120011137.GB4498@iabyn.com>

On Sun, Nov 20, 2005 at 01:55:47AM +0100, Nicolas Mailhot wrote:
> Le samedi 19 novembre 2005 ? 22:59 +0000, Dave Mitchell a ?crit :
> 
> > This is a bit hand-wavy because I'm not familiar with the font.conf
> > schema, but for example
> > 
> >     substitute name=family /mono/ "monospace"
> 
> Perfect example of subtle flat-file syntax no one can understand without
> the man page under its eyes. Push a few more lines like this, each with
> its own rules hidden in magic characters like /, and you get something
> pretty much impossible to administer (let alone write a robust parser
> for)

And you'd be able to understand the XML version without having the
"part of the schema for font name substitutions within font.conf" manual
in front of you?

XML is good for text markup. It's really crap for anything else.
(IMHO of course).

-- 
In my day, we used to edit the inodes by hand.  With magnets.



From bojan at rexursive.com  Sun Nov 20 02:46:00 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sun, 20 Nov 2005 13:46:00 +1100
Subject: Savage DRI broken in modular X
In-Reply-To: <437F2657.4060109@redhat.com>
References: <437F10C4.1070702@redhat.com>
	<50734.194.94.224.254.1132405567.squirrel@jose.freesurf.fr>
	<437F2657.4060109@redhat.com>
Message-ID: <1132454760.3379.1.camel@coyote.rexursive.com>

On Sat, 2005-11-19 at 08:19 -0500, Mike A. Harris wrote:

> There's a neat surprise in store for you.  ;o)  Whenever I fix
> the mesa package, and you upgrade to the new package, your
> system will probably break due to that symlink.  ;o)

Unless, of course, he builds an RPM package with a trigger, that plonks
the right symlink in place every time broken mesa gets updated ;-)

-- 
Bojan



From bojan at rexursive.com  Sun Nov 20 02:50:47 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sun, 20 Nov 2005 13:50:47 +1100
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <1132455047.3379.5.camel@coyote.rexursive.com>

On Sat, 2005-11-19 at 11:09 -0500, Mike A. Harris wrote:

> Um.  Hello?  How exactly is that "open source" or "GPL"?  I'm not
> quite sure.

It's not. It is GPL with the advertising clause, which isn't the GPL at
all. Actually, I don't know what that is, as per GPL you aren't allowed
to put any additional restrictions on the code, apart from ones
specified in the text of the GPL. They probably think they are "oh, so
smart" :-(

-- 
Bojan



From lamont at gurulabs.com  Sun Nov 20 06:25:42 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Sat, 19 Nov 2005 23:25:42 -0700
Subject: init: API
In-Reply-To: <1132395494.9723.20.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
Message-ID: <200511192325.46781.lamont@gurulabs.com>

On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote:
> Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
[snip]
> Just use vim for syntax highlighting and xmllint to check the result.

xmllint?  Have you ever used it for any serious XML work?  It isn't very 
accurate.  With all the XML I've done (which is not huge amounts, but a fair 
bit), xmllint is flat out wrong about 1/3 to 1/2 of the time; usually it says 
something is wrong when it fact, it is right.  When it is "correct" about 
there being something wrong 4/5 times it give error messages that are not 
even close to where the problem is actually occurring.

> 100% light-weight CLI solution.

Not really, given the problems with xmllint.
-----
BTW:  It's interesting how this part of the thread has developed into a 
conversation about XML in general.  Just to bring some focus back, we *were* 
talking about SysV Init scripts and the need to represent service 
inter-relationships in order to better facilitate intelligent, "automated" 
parallelized startup/shutdown of the system.

On that note, I believe that XML would be a grave mistake for this 
application.  We need to stick with shell scripts, there is just too much 
that would be thrown away with any other choice.

What about having a separate file from the Init script for dependency 
information?  Bad idea...keeping each services' critical data in one file 
makes life much easier.

Yes, we already have /etc/sysconfig/* files, which allows the *local* 
administrator to make customization decisions about how the services are 
started (i.e. daemon command line options).  You might, therefore, think that 
we could put service dependency information into these /etc/sysconfig/* 
files, but those files are for "local customization*, not global/general 
configuration.  Better to put that data into the /etc/init.d/* file.

How should it be formated?  Well, the LSB already says, "like this:".  So 
let's make this really simple and make it easier for people to test the new 
system while still working with the old.  Yes, the LSB SysV Init dependency 
format has it's limitations, but we do not need much complexity; quite the 
opposite, in fact.  So here's my idea:

1.  Service inter-dependency data in SysV Init scripts...either (A) in the LSB 
format, or (B) by adding "# depends:" and "# sibling:" fields for chkconfig.

2.  The "new" Init process can be configured to scan all /etc/init.d/* files 
and provide monitoring and alerting support (kind of like it already has 
respawn).  Another custom chkconfig-like field could be used to indicate that 
this service "wants" to be monitored.  Could that line go 
into /etc/sysconfig/* files?  I guess that depends on whether the decision to 
have init watch the service should be made by the local administrator or 
"not".  Does this need to be decided on a service by service basis?

3.  A "new-and-improved" rc that can use the LSB and/or new chkconfig-like 
entries to "do the right thing".  Part of that would be parallel startup.

4.  Select S and K numbers for the /etc/rc?.d/ files that place all services 
that can be started "in parallel" at the same number.

5.  Benchmark.

As others have pointed out, we do not have numbers to back up the assertion 
that this will work.  I am already highly certain that it will.  Have any of 
you tried turning on SUSE's parallel start-up in their newer releases?  
Theirs is based on make + some very "deep voodoo" shell scripts.  The 
advantage of their system is that you can flip it on and still use the same 
LSB meta-data in the SysV Init scripts basically in the way we've all been 
doing things for years.  Flip the switch, and the shell-voodoo + make 
combination comes into play and the boot up process is nearly 3 times faster, 
in the cases where I have played with it; sorry, no hard numbers for you.

The point is...these suggestions take the simple approach; they let us stop 
guessing and actually do something conclusive.  It also requires only a few 
relatively minor changes to init & rc.

OK.  Let the comments start rolling in :) .
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051119/1007eab8/attachment.sig>

From ankit644 at yahoo.com  Sun Nov 20 07:18:47 2005
From: ankit644 at yahoo.com (Ankit Patel)
Date: Sat, 19 Nov 2005 23:18:47 -0800 (PST)
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
Message-ID: <20051120071847.62474.qmail@web34609.mail.mud.yahoo.com>

I like xoops (www.xoops.org) ! 

"Mike A. Harris" <mharris at redhat.com> wrote: I'm investigating content management systems for maintaining Fedora
related pages on my site, and looking for something that does not
require mysql or any other database backend.  Something very simple
and self contained within the web root, with as few web server
configuration requirements, and as few software requirements as
necessary.  It's also rather important to me that the software
be 100% true open source software, licensed under the GPLv2 or
BSD license or something, with no advertising clauses or other
garbage to restrict freedom.

It was recommended that I have a look at "Limbo", and while perusing
their site, I found it was GPL licensed.  After taking a closer look
at the license however:

http://www.limbo-cms.com/index.php/option/content/pcontent/1/task/view/id/29/Itemid/67

It is GPL licensed, but they also force you to include a link to their
website, or they will contact your ISP to have the site removed unless
you purchase a commercial license.

Um.  Hello?  How exactly is that "open source" or "GPL"?  I'm not
quite sure.  Maybe a good slashdotting would get the situation
corrected...

Anyhow, does anyone have any suggestions to something simple which
might be of use to my Fedora documentive purposes?

TIA.

-- 
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list



		
---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051119/d7959da4/attachment.htm>

From giallu at gmail.com  Sun Nov 20 09:03:19 2005
From: giallu at gmail.com (Gianluca Sforna)
Date: Sun, 20 Nov 2005 10:03:19 +0100
Subject: Simple content management systems.
In-Reply-To: <437F4E44.4000807@redhat.com>
References: <437F4E44.4000807@redhat.com>
Message-ID: <d5ad21470511200103x5e0b41eck6a624483cc769dcf@mail.gmail.com>

On 11/19/05, Mike A. Harris <mharris at redhat.com> wrote:
>
> I'm investigating content management systems for maintaining Fedora
> related pages on my site, and looking for something that does not
> require mysql or any other database backend. Something very simple
> and self contained within the web root, with as few web server
> configuration requirements, and as few software requirements as
> necessary. It's also rather important to me that the software
> be 100% true open source software, licensed under the GPLv2 or
> BSD license or something, with no advertising clauses or other
> garbage to restrict freedom.


Well, I have to agree with others in the thread, a moinmoin solution (and
the one in fedoraproject.org <http://fedoraproject.org> in particular) could
be right for your needs.
Otherwise, if you want a complete CMS with everything but the kitchen sink,
you can give a try to plone, GPL, based on zope and written in python.
It should be in extras.

Cheers

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051120/e9673fc6/attachment.htm>

From gilboada at netvision.net.il  Sun Nov 20 09:28:21 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 11:28:21 +0200
Subject: init: API
In-Reply-To: <F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
Message-ID: <1132478901.8015.8.camel@gilboa-work-dev>

On Sat, 2005-11-19 at 13:32 -0800, Kenneth Porter wrote:
> --On Saturday, November 19, 2005 9:17 AM -0800 Toshio Kuratomi 
> <toshio at tiki-lounge.com> wrote:
> 
> > Not in a recovery situation where /usr is unavailable, though.
> 
> You can boot a fairly full-featured rescue system from a USB key. A GB key 
> costs about $80. I'd hope libxml takes less space than that!
> 
> <http://featherlinux.berlios.de/usb-instructions.htm>
> 
> <http://openfacts.berlios.de/index-en.phtml?title=Linux_bootable_USB_key_HOWTO>
> 

Let me see if got you base idea.
In order to get better looking (!!!) configuration for the service
manager you are essentially forcing Fedora core user, who wish to
recover a dead OS to:
A. Buy a USB disk.
B. Replace old machine with no vacant/non-existing USB sockets.
C. Create a special recovery version of said Linux.
D. Stop using serial and/or remote access tools to the machine and/or
get someone with access to said machine to stick the USB key into the
said machine.

Seriously., please tell me, did you bother to read what you wrote,
before pressing that send button, or did the need to win this argument
derailed you completely?

If you are so sold on the intent of having a XML configuration, find
ways to integrate them into the FC recovery system and them post your
solution. 

Gilboa






From mharris at redhat.com  Sun Nov 20 09:29:08 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 20 Nov 2005 04:29:08 -0500
Subject: Simple content management systems.
In-Reply-To: <437F7066.9090509@n-man.com>
References: <437F4E44.4000807@redhat.com> <437F6769.40903@insitesinc.com>
	<437F7066.9090509@n-man.com>
Message-ID: <438041E4.3070208@redhat.com>

Patrick Barnes wrote:
> I second Seth's recommendation.  You can contribute documents to the
> general public anywhere in the wiki.  Documents you want under your own
> namespace can be placed under
> http://fedoraproject.org/wiki/MikeAHarris.  If you really want something
> on your own site, MoinMoin really is good.  It is written in Python. 
> It's easy to set up.  It is very robust and flexible.  If you run into
> problems, you'll find others in this community who can assist you.  I
> also use MoinMoin for my personal site at http://www.n-man.com/.

Thanks for the suggestions guys.

What I am looking for, is something that is simple XHTML/CSS, not wiki
based, which I can personally run on my own website. Something simple is 
prefered with as few external dependencies as possible.

I'd like something that is completely self contained, does not use
a database, and does not require root priveledges to install and
set up.

I have a number of things I'd like to put together with some framework,
of which some Fedora pages are a part of.  I will have some scripts
which run locally on my own machine, some which will run on Red Hat
internal machines via cron or something, which will push various data
to a common area.

I'd then like to take that data, massage it with perl scripts to spit
out some data that can be used as compliant XHTML content.

I'm looking for complete automation, and prefer to stay away from any
solutions that would be considered overkill, or require root perms to
set up, or custom webserver configuration.  I've looked at a number
of CMS systems so far, and they mostly seem overkill to me, or require
more work to set up than I prefer.

I'm leaning towards doing the templating myself with raw perl.  The
HTML::Template looks possibly useful, but still exploring ideas...

Thanks again.



From gilboada at netvision.net.il  Sun Nov 20 09:43:22 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 11:43:22 +0200
Subject: init: API
In-Reply-To: <200511192325.46781.lamont@gurulabs.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<200511192325.46781.lamont@gurulabs.com>
Message-ID: <1132479802.8015.23.camel@gilboa-work-dev>

On Sat, 2005-11-19 at 23:25 -0700, Lamont R. Peterson wrote:
> On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote:
> > Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
> [snip]
> BTW:  It's interesting how this part of the thread has developed into a 
> conversation about XML in general.  Just to bring some focus back, we *were* 
> talking about SysV Init scripts and the need to represent service 
> inter-relationships in order to better facilitate intelligent, "automated" 
> parallelized startup/shutdown of the system.
> On that note, I believe that XML would be a grave mistake for this 
> application.  We need to stick with shell scripts, there is just too much 
> that would be thrown away with any other choice.

I fully agree.

> 
> What about having a separate file from the Init script for dependency 
> information?  Bad idea...keeping each services' critical data in one file 
> makes life much easier.

I second that.
Create a main service manager scripts, that loads each configuration
file (by . /etc/smc/smb.conf), and then calls the predefined service
start/stop functions.
I wrote similar system for a certain embedded Linux I worked on, and
managed to get a fully running Linux, BIOS to PostgreSQL in around 30
seconds. (~35 with DHCP).
While the system was no-where near as complex as Fedora's SysV init
(though it did include dependencies, priorities and a watchdog), it was
lightening fast and fairly flexible.
Better yet, it is fairly easy to create a bash based service watchdog
that eats minimal amount of CPU time.

> 
> Yes, we already have /etc/sysconfig/* files, which allows the *local* 
> administrator to make customization decisions about how the services are 
> started (i.e. daemon command line options).  You might, therefore, think that 
> we could put service dependency information into these /etc/sysconfig/* 
> files, but those files are for "local customization*, not global/general 
> configuration.  Better to put that data into the /etc/init.d/* file.
> 
> How should it be formated?  Well, the LSB already says, "like this:".  So 
> let's make this really simple and make it easier for people to test the new 
> system while still working with the old.  Yes, the LSB SysV Init dependency 
> format has it's limitations, but we do not need much complexity; quite the 
> opposite, in fact.  So here's my idea:
> 
> 1.  Service inter-dependency data in SysV Init scripts...either (A) in the LSB 
> format, or (B) by adding "# depends:" and "# sibling:" fields for chkconfig.

I understand depend.
But why do we need sibling? To force restart of all sibling processes in
case of single process crash?

> 
> 2.  The "new" Init process can be configured to scan all /etc/init.d/* files 
> and provide monitoring and alerting support (kind of like it already has 
> respawn).  Another custom chkconfig-like field could be used to indicate that 
> this service "wants" to be monitored.  Could that line go 
> into /etc/sysconfig/* files?  I guess that depends on whether the decision to 
> have init watch the service should be made by the local administrator or 
> "not".  Does this need to be decided on a service by service basis?
> 
> 3.  A "new-and-improved" rc that can use the LSB and/or new chkconfig-like 
> entries to "do the right thing".  Part of that would be parallel startup.
> 
> 4.  Select S and K numbers for the /etc/rc?.d/ files that place all services 
> that can be started "in parallel" at the same number.

I'm still doubtful that parallel start will be beneficial on single CPU
machines.

> 
> 5.  Benchmark.
> 
> As others have pointed out, we do not have numbers to back up the assertion 
> that this will work.  I am already highly certain that it will.  Have any of 
> you tried turning on SUSE's parallel start-up in their newer releases?  
> Theirs is based on make + some very "deep voodoo" shell scripts.  The 
> advantage of their system is that you can flip it on and still use the same 
> LSB meta-data in the SysV Init scripts basically in the way we've all been 
> doing things for years.  Flip the switch, and the shell-voodoo + make 
> combination comes into play and the boot up process is nearly 3 times faster, 
> in the cases where I have played with it; sorry, no hard numbers for you.

It'll be nice if we could see numbers.

> 
> The point is...these suggestions take the simple approach; they let us stop 
> guessing and actually do something conclusive.  It also requires only a few 
> relatively minor changes to init & rc.
> 
> OK.  Let the comments start rolling in :) .

Gilboa



From mharris at redhat.com  Sun Nov 20 09:45:09 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 20 Nov 2005 04:45:09 -0500
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511192355390.10662@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>	<437F1658.5090000@redhat.com>	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>	<437F516C.1050502@redhat.com>
	<Pine.LNX.4.64.0511192355390.10662@lemenkov.com>
Message-ID: <438045A5.8060001@redhat.com>

Peter Lemenkov wrote:
> On Sat, 19 Nov 2005, Mike A. Harris wrote:
> 
>>> All we need is to properly patch SPEC-file.
> 
> 
>> In short: No. Absolutely not.  ;o)
>> For the longer version, please reread my first email.  As I stated
>> therein, this is not due to it being technically impossible to do.
>> It is a concious and intentional choice that all Mesa drivers are
>> provided in one package right now, and I plan on keeping it that way
>> at least until all of the items I outlined in the first email are
>> met.
> 
> 
> Look. I haven't any of old, good videocard listed in mesa-libGL package.
> So why I haven't a way to properly strip down the package, instead of 
> manually remove never used dri-modules?

The src.rpm is available, and can be customized as desired of course.


> I don't concern a way of maintaining the source of Mesa (in one package, 
> in two packages, even in one tarball per file), I do concern the result 
> of building from %{_tmppath}/%{name}-%{version}-%{release}-buildroot. 
> After the successful compilation mesa packs into a number of packages, 
> so why just don't increase its number? :)
> 
> If someone rejects installing of particular dri-modules, everything will 
> be OK, 'cause if user don't have some mesa-dri-supported videocard, the 
> apropriate *.so-module wouldn't be used. So why take care?
> 
> Ok, maybe it's a kinda of religion/ideology to keep *all* modules 
> simultaneously?

As stated twice now, this is done intentionally to ensure that all
drivers are always installed on all systems, in order to ensure that
they are present and avoid support calls and bug reports due to missing
drivers.

Some users out there are more on the ball than others, and are capable
of uninstalling things, and knowing if and when they might need to
reinstall them, and how to go find them.  Other users may not be so
gifted, and if they have the option to uninstall things that they
"think" they do not want or need, for _whatever_ reason, they may do
so, and later find themselves in a bind.  If we allowed individual
drivers to be uninstalled, then we _WOULD_ get bug reports and RHN
customer support requests from people who have uninstalled (or not
installed to begin with) the drivers for their card.  This might
not be the card the OS was originally installed with, but rather some
board that was bought as a replacement.

ie: Install OS on a system with an Intel onboard, but don't install
anything but Intel video to "save space because I don't need it".
4 months later, purchase a Radeon 9200, and install it, then file
a bug report in bugzilla claiming you can't get 3D to work at all.

This is a "support" problem that I am not willing to endure.  The
OS has always shipped and installed _all_ video drivers forever, and
now more than ever, drive space is cheap.  There is not very much
to be gained by removing drivers that might not be needed, except
for a very small number of free megabytes.  There are a lot of
_problems_ to be gained by permitting people to uninstall individual
drivers on a whim in the land of technical support.

If you really want to remove unneeded drivers, delete them with "rm",
and you'll free up a couple megabytes.  RPM upgrades will still work,
and I can close bug reports with "I just verified the package we
shipped, contained that driver, NOTABUG".  This makes it a very
explicit action, that by removing it, you are entering into the
dark land of "not supported".

I've talked with some upstream Mesa developers since this thread
started, and it seems very unlikely that Mesa will be implementing
the items I mentioned in previous posts any time soon.  The
Mesa modules in a sense are like the kernel - they do not have a
stable module ABI that has compatibility with newer or older Mesa
releases.  This means that the Mesa modules must be used with the
exact specific Mesa release they were shipped with.  That is another
reason why the Mesa modules will remain in one single src.rpm
in Fedora Core.

The bottom line is:  Disk space is cheap.  Saving negligible space
at the expense of technical support nightmares is not a reasonable
solution.

Feel free to disagree, but there are really much more important
matters we should be spending our attention on right now.



From mharris at redhat.com  Sun Nov 20 09:56:52 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 20 Nov 2005 04:56:52 -0500
Subject: Savage DRI broken in modular X
In-Reply-To: <9157.194.94.224.254.1132439752.squirrel@jose.freesurf.fr>
References: <437F2657.4060109@redhat.com>
	<9157.194.94.224.254.1132439752.squirrel@jose.freesurf.fr>
Message-ID: <43804864.3000308@redhat.com>

Joachim Frieben wrote:

> I can't follow here. The worst thing to happen is that the symlink
> might not be used anymore, once the "Mesa" library gets fixed to
> look up in "/usr/lib/dri". The directory "/usr/lib/dri" is unlikely
> to change some time soon, and even if it did, the orphaned link
> could hardly cause any problem. Given "DRI" up and running today,
> this is an acceptable trade-off and allowed furthermore to
> successfully identify the bug. Anyway, thanks for your advice.

The new packages will be installed *into* the symlink that is present,
however rpm does not store where they are _actually_ going to land,
but rather the paths where they were supposed to land if the
symlink wasn't there.  This can end up with a race condition in
rpm transaction sort potentially.

The whole /usr/lib/X11 symlink problem is caused by this same issue,
and we're still working out how to solve that.  In that instance
however, we're responsible for the symlink, so need/want to fix
it.  For symlinks that were smashed into the system by someone else,
if it causes the system to break - you get to keep both pieces.  ;o)


> It's not that ridiculous. "Mathematica" for example has "Open
> Motif 2.1.30" compiled in statically. After fixing the font
> problem - the new ISO 10646 fonts lead to empty buttons what I
> fixed by installing the ISO 8859 fonts afterwards - I am now
> facing error messages of the kind:
> 
> "Warning: translation table syntax error: Unknown keysym name:
> osfBeginLine Warning: translation table syntax error: %s" ...
> 
> For backwards compatibility, Red Hat still provides packages
> like: "compat-libstdc++-296-2.96", "compat-openldap-2.3.11"
> and many others. This made me think of the possible need to
> provide older applications with some legacy stuff.

In a previous email I mentioned we would provide some backward
compatibility where it is deemed needed.  I hope I wasn't unclear
about that.  What I am saying right now however, is that such
backward compatibility is _intentionally_ not going into rawhide
right /now/, because we want to _know_ what is broken both inside
Fedora Core and Extras so they can be fixed properly, and to know
what else is broken out in the wild, and give 3rd parties both
the knowledge that their software needs to be updated, as well
as a large enough amount of incentive to fix it during the
FC5 development timeframe.

The longer something is "broken" for somebody, I've found it acts
as a really good motivator to get things fixed properly in the
correct location.  The long term results (which is what I am
most interested in), is that people end up fixing /more/ things,
and fixing them /sooner/ when they have no choice if they want
to use the stuff.  Since this is a developmental time period,
that is perfectly acceptable.  Rawhide is and always has been
a roaming landmine of randomly breaking things that eventually
get fixed.

As people are discovering broken items, I'm keeping track of them
in bugzilla and other places, where I know we'll need to come
back and add some backward compatibility later on for the "final"
OS.  That will happen eventually, but with focus on the "later
on" part.

Short term pain for long term gain.

>>Illiteracy runs rampant, even at Red Hat!  ;o)  Fortunately,
>>it wasn't I who created this internal mailing list, so I get
>>to laugh and point fingers with the rest of you at whoever it
>>was.   ;oP
> 
> Maybe you could also inform your post/web master in order to fix this
> stupid mistake? Thanks.

It doesn't really bother me.  The world isn't a perfect place,
and I'm ok with that.  ;o)




From mharris at redhat.com  Sun Nov 20 10:00:03 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Sun, 20 Nov 2005 05:00:03 -0500
Subject: Simple content management systems.
In-Reply-To: <1132455047.3379.5.camel@coyote.rexursive.com>
References: <437F4E44.4000807@redhat.com>
	<1132455047.3379.5.camel@coyote.rexursive.com>
Message-ID: <43804923.1010708@redhat.com>

Bojan Smojver wrote:
> On Sat, 2005-11-19 at 11:09 -0500, Mike A. Harris wrote:
> 
> 
>>Um.  Hello?  How exactly is that "open source" or "GPL"?  I'm not
>>quite sure.
> 
> 
> It's not. It is GPL with the advertising clause, which isn't the GPL at
> all. Actually, I don't know what that is, as per GPL you aren't allowed
> to put any additional restrictions on the code, apart from ones
> specified in the text of the GPL. They probably think they are "oh, so
> smart" :-(

Indeed.  I dunno about the rest of you, but it infuriates me when
I see people put out software as "GPL licensed" and then invalidate
the license by putting additional restriction clauses.  In this case,
the invalid additional restriction clauses are extreme enough to
indicate these people have no clue whatsoever about what the GPL
actually states (or they don't care).

"Limbo" is a trademark of Lucent Technologies.  Anyone happen to know
who runs the legal team at Lucent? ;o)



From rmo at sunnmore.net  Sun Nov 20 10:36:19 2005
From: rmo at sunnmore.net (Roy-Magne Mo)
Date: Sun, 20 Nov 2005 11:36:19 +0100
Subject: Simple content management systems.
In-Reply-To: <438041E4.3070208@redhat.com>
References: <437F4E44.4000807@redhat.com>
	<437F6769.40903@insitesinc.com>	<437F7066.9090509@n-man.com>
	<438041E4.3070208@redhat.com>
Message-ID: <438051A3.7010208@sunnmore.net>

Mike A. Harris wrote:
> I'm leaning towards doing the templating myself with raw perl.  The
> HTML::Template looks possibly useful, but still exploring ideas...

If you are looking in to HTML::Template, I would rather take a closer 
look at Template::Toolkit - it's in extras too.

-- 
Roy-Magne Mo



From link at pobox.com  Sun Nov 20 11:08:27 2005
From: link at pobox.com (Terje Bless)
Date: Sun, 20 Nov 2005 12:08:27 +0100
Subject: Simple content management systems.
In-Reply-To: <438051A3.7010208@sunnmore.net>
Message-ID: <A02020006-1043-B188C2170C4B4C33B29F4F8BD619F830@pounder.tj.unn.no>

Roy-Magne Mo <rmo at sunnmore.net> wrote:

>Mike A. Harris wrote:
>>I'm leaning towards doing the templating myself with raw perl.  The
>>HTML::Template looks possibly useful, but still exploring ideas...
>
>If you are looking in to HTML::Template, I would rather take a closer
>look at Template::Toolkit - it's in extras too.

Since we were speaking of ?overkill? you mean? :-)


Mike; after reading this far in the thread I still don't have a real good idea
of what your actual requirements are. The ones you've mentioned ? non-root,
lightweight, etc. ? are very generic and not really specific to a ?CMS? (gods
how I hate that term).


If you have ?data?, and of which the most convenient form for you to manipulate
is a Perl data structure, then HTML::Template (or Template::Toolkit, I'm sure)
is a decent way to serialize it into various forms of markup (HTML::Template
isn't really specific to HTML).


If you want to edit your web pages directly from the browser, a home-brew CGI
giving you a text field or an FCK Editor[0] and some dead simple path/category
management (store files in the filesystem, not a DB, etc.), may be the way to
go.


If you're after some way to avoid the repetitive HTML code and just want to
write the meat of the page by hand, you could use Apache SSI.

Similarly, I'm currently looking at Blosxom (blog thingy) and it looks like it'd
work perfectly for something like that (without any actual blog bits involved);
edit pages as plain text, freely embed any markup you want, webspace paths
reflect filesystem paths, resulting output is fully templated, and you can
generate static pages from cron (or manually) instead of feeding every access
through a CGI. It's for blogging, but looks like it's sufficiently generic and
flexible to be adaptable to almost any task you want.

It's written in Perl, and seems essentially self-contained apart from templates
and such. No MySQL in sight. Blosxom's license[2] is...unusual though.


If you want to store data inside finished (X)HTML pages but still want to
manipulate that data, then using an XML Processor or an SGML Parser[1] to treat
the ?page? as a structured data format should get you what you want.


And, you know, there's always the Red Hat CMS[3]. :-)



[0] ? <http://www.fckeditor.net/>.
[1] ? e.g. SGML::Parser::OpenSP, <http://spo.sf.net/>.
[2] ? <http://www.blosxom.com/license.html>
[3] ? <http://www.redhat.com/docs/manuals/cms/>

-- 
  ?If at first you don't succeed, keep shooting.?  -- monk



From nicolas.mailhot at laposte.net  Sun Nov 20 11:57:47 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 20 Nov 2005 12:57:47 +0100
Subject: init: API
In-Reply-To: <200511192325.46781.lamont@gurulabs.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<200511192325.46781.lamont@gurulabs.com>
Message-ID: <1132487867.26111.18.camel@rousalka.dyndns.org>

Le samedi 19 novembre 2005 ? 23:25 -0700, Lamont R. Peterson a ?crit :
> On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote:
> > Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
> [snip]
> > Just use vim for syntax highlighting and xmllint to check the result.
> 
> xmllint?  Have you ever used it for any serious XML work? 

Yes. Serious x-thousand-lines XML files processing

>  It isn't very accurate.

It *is* accurate. What you may have is applications which accept things
their XML schema forbids, which is an app problem, not an xmllint one.
In fact in my experience xmllint is one of the most accurate checkers,
and any deviation from the specs is fixed as soon as it's reported. 90%
of "xmllint" problems are apps which do not follow the XML spec and them
blame xmllint for pointing out their files are buggy.

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/20051120/89ea256a/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov 20 12:29:15 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 20 Nov 2005 13:29:15 +0100
Subject: init: API
In-Reply-To: <1132487867.26111.18.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<200511192325.46781.lamont@gurulabs.com>
	<1132487867.26111.18.camel@rousalka.dyndns.org>
Message-ID: <1132489755.26809.1.camel@rousalka.dyndns.org>

BTW in my experience the problem with flat-files is they are
under-specified (lots of text file examples given on this thread are
"loose" syntax which a human will grok but an application won't).

So as long as you have a single app parsing the file all's well, because
the quirks of its built-in parser pretty much define the syntax (and a
custom parser *always* got quirks). But put a second app in the system
(for example a GUI frontend to manipulate the files, written in another
language so it can not share the parser lib) and all Hell breaks lose,
because the gui writer and the cli writer can not agree on the exact
syntax to use.

The *big* advantage of XML files is they have strong syntax rules, in
fact files can be checked using third-party tools like xmllint, so there
is a lot less room for applications bickering about the same file.

-- 
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/20051120/ce28ee78/attachment.sig>

From nicolas.mailhot at laposte.net  Sun Nov 20 11:52:07 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sun, 20 Nov 2005 12:52:07 +0100
Subject: init: API
In-Reply-To: <20051120011137.GB4498@iabyn.com>
References: <1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<20051119134307.GX4498@iabyn.com>
	<1132408286.3133.5.camel@rousalka.dyndns.org>
	<20051119225933.GZ4498@iabyn.com>
	<1132448147.3141.8.camel@rousalka.dyndns.org>
	<20051120011137.GB4498@iabyn.com>
Message-ID: <1132487527.26111.12.camel@rousalka.dyndns.org>

Le dimanche 20 novembre 2005 ? 01:11 +0000, Dave Mitchell a ?crit :
> On Sun, Nov 20, 2005 at 01:55:47AM +0100, Nicolas Mailhot wrote:
> > Le samedi 19 novembre 2005 ? 22:59 +0000, Dave Mitchell a ?crit :
> > 
> > > This is a bit hand-wavy because I'm not familiar with the font.conf
> > > schema, but for example
> > > 
> > >     substitute name=family /mono/ "monospace"
> > 
> > Perfect example of subtle flat-file syntax no one can understand without
> > the man page under its eyes. Push a few more lines like this, each with
> > its own rules hidden in magic characters like /, and you get something
> > pretty much impossible to administer (let alone write a robust parser
> > for)
> 
> And you'd be able to understand the XML version without having the
> "part of the schema for font name substitutions within font.conf" manual
> in front of you?

Yes, I can understand that :

        <match target="pattern">
                <test qual="any" name="family">
                        <string>mono</string>
                </test>
                <edit name="family" mode="assign">
                        <string>monospace</string>
                </edit>
        </match>

means

? For a font which got the string mono in its family metadata field
(qual="any" is not defined but I'd guess any means as global as you can)
assign the string monospace as the family field ?

And this is only by reading the xml tags (pattern with test + associated
action), without going into the schema or anywhere else. Of course you
need to know beforehand fonts declare metadata, which include "family". 

In your example I have to guess the second field is a pattern, the third
is the substitution, it does not permit changing one field based on
another, you've used space as separator which will bite you later, etc
etc.

> XML is good for text markup. It's really crap for anything else.
> (IMHO of course).

Except configuration files need to be readable and explicit tags are way
better than magic "//" expressions for this (or implicit arguments based
on ordering)

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/20051120/e6f78d45/attachment.sig>

From tmus at tmus.dk  Sun Nov 20 13:12:47 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Sun, 20 Nov 2005 14:12:47 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlkl13$oik$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org>
Message-ID: <dlpsoc$aam$1@sea.gmane.org>

Somehow a lot of my previous posts never mad it to the list, but let me 
just recap...

For anyone interested, here's the story of the logo!

http://www.capstrat.com/development/fedora/index.php

...and let's make a few things clear.

- I love the idea of fedora having it's own logo.
- I think the logo in question has all the right parts, all the elements 
are just right.

Also, I think the logo actually has something going for it - it still 
needs a refresh in a few ways, but it's probably not as far off as i 
thought initially. It could be be made very decent if given a little 
more work.

perhaps something like tinting the whole logo for extras etc. instead of 
only replacing some of the arches in the logo with other colors.

And again, if it's just me, I can replace it!

/Thomas



From arjan at fenrus.demon.nl  Sun Nov 20 07:40:05 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 20 Nov 2005 08:40:05 +0100
Subject: More modularization.
In-Reply-To: <Pine.LNX.4.64.0511192334490.10662@lemenkov.com>
References: <Pine.LNX.4.64.0511191232210.2812@lemenkov.com>
	<437F1658.5090000@redhat.com>
	<Pine.LNX.4.64.0511191835211.13882@lemenkov.com>
	<1132417637.2671.4.camel@laptopd505.fenrus.org>
	<Pine.LNX.4.64.0511192334490.10662@lemenkov.com>
Message-ID: <1132472405.2865.9.camel@laptopd505.fenrus.org>

On Sat, 2005-11-19 at 23:49 +0300, Peter Lemenkov wrote:
> On Sat, 19 Nov 2005, Arjan van de Ven wrote:
> 
> >> Who tolds about stable ABI-interface? I just suggest to split kernel 
> >> into a number of packages and add "virtual" one, that install all of 
> >> them. Of course, then someone will upgrade the kernel *all* installed 
> >> packages would be upgraded.
> 
> > abi matters a lot in this really. If you don't have a stable ABI, the
> > version dependencies get *really* messy, and the user experience goes
> > down the drain unless.. you make all drivers mandatory again. At which
> > point you have to ask yourself: "Why do this again"
> 
> Who told about ABI at all? I told about splitting kernel-package within 
> the particular version, *not* about partial upgrade (say, kernel will be 
> 2.6.14-1.1700, although video-driver is still from some previous kernel - 
> that's a situation there ABI do matter!). User will be forced to upgrade 
> all its modules, then he changes its kernel.

if you do that.. then what again is the gain you're trying to achieve?

> 
> Everything will be ok, if every little package with kernel module inside 
> will have
> 
> > Requires: kernel = 2.6.14-1.1688

> or something of that kind.

that is not enough; while it makes the module require the kernel, it
won't make depsolvers install a new version of the module on a new
kernel.


> Ok, summarizing - i suggest a way to strip down the kernel package, thus 
> reducing its weight (my handmade kernel for my PC weights about 2 mbytes - 
> compare with 40+ mbytes of FC's generic kernel). If every module would 
> have proper "requires"-field, all would be OK. :)

however if you then make all of them installed, you have MORE weight,
because now you have rpm package overhead times 1000. This could only
every be a gain if you would go to a "install minimum set" kind of
thing, which is also increasingly getting harder due to hotplug.. eg you
need all drivers of hotplugable hardware (USB and stuff, but
increasingly PCI too) installed always, as well as anything they use
(scsi, filesystems etc etc).

you could say "so split uncommon stuff out". Well that was done for
RHEL3, and customers absolutely hated it, and as a result our support
folks did too because they got an incredible amount of support calls
about it.

So for me you still haven't said what the gain was you were trying to
achieve: either you install everything anyway, and then there are only
downsides, or you start doing selective installs, but those are tricky
and generally upset slightly less technical people and the user
experience is just nasty.



From petro at mail.ru  Sun Nov 20 14:17:19 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sun, 20 Nov 2005 17:17:19 +0300
Subject: Current kernel & saa7134
In-Reply-To: <Pine.LNX.4.64.0511180031430.4311@lemenkov.com>
References: <Pine.LNX.4.64.0511180031430.4311@lemenkov.com>
Message-ID: <Pine.LNX.4.64.0511201715390.2537@lemenkov.com>

On Fri, 18 Nov 2005, Peter Lemenkov wrote:

> [petro at Petro projects]$ uname -a
> Linux Petro 2.6.14-1.1682_FC5 #1 Wed Nov 16 00:31:25 EST 2005 i686 athlon 
> i386 GNU/Linux

And another one thing. With this kernel, sound via snd-via82xx was also 
disabled, until I remove all saa7134-modules.
-- 
With best regards, Peter Lemenkov.




From shiva at sewingwitch.com  Sun Nov 20 15:20:28 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 20 Nov 2005 07:20:28 -0800
Subject: init: API
In-Reply-To: <1132478901.8015.8.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
Message-ID: <FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>

--On Sunday, November 20, 2005 11:28 AM +0200 Gilboa Davara 
<gilboada at netvision.net.il> wrote:

> Let me see if got you base idea.

Nope. You were complaining that XML was too heavyweight and you needed to 
mount /usr to do anything with it. I simply pointed out that an entire 
distro, with GUI, fits in a small space. Sorry that I wasn't more clear.




From jfrieben at freesurf.fr  Sun Nov 20 15:27:22 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sun, 20 Nov 2005 16:27:22 +0100 (CET)
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlpsoc$aam$1@sea.gmane.org>
References: <dlpsoc$aam$1@sea.gmane.org>
Message-ID: <31696.194.94.224.254.1132500442.squirrel@arlette.freesurf.fr>

Unlike the previous Red Hat logo, this one does not at all fit
the typical Bluecurve style with distinct outlining and the
simple cartoon-like appearance. It looks rather fuzzy, and the
color hues are barely distinguishable at 24x24 pixels.
The Fedora site "F" icon appearing left to the web site address
in your browser is better suited in this respect. Ask Diana
to fedoradize your draft. The idea of having a distinct logo
is a good one though.

>
> - I love the idea of fedora having it's own logo.
> - I think the logo in question has all the right parts, all the
> elements  are just right.
>




From gilboada at netvision.net.il  Sun Nov 20 16:21:11 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 18:21:11 +0200
Subject: init: API
In-Reply-To: <FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
Message-ID: <1132503671.8015.50.camel@gilboa-work-dev>

On Sun, 2005-11-20 at 07:20 -0800, Kenneth Porter wrote:
> --On Sunday, November 20, 2005 11:28 AM +0200 Gilboa Davara 
> <gilboada at netvision.net.il> wrote:
> 
> > Let me see if got you base idea.
> 
> Nope. You were complaining that XML was too heavyweight and you needed to 
> mount /usr to do anything with it. I simply pointed out that an entire 
> distro, with GUI, fits in a small space. Sorry that I wasn't more clear.
> 
> 

I wasn't the one complaining about missing /usr. (though the original
poster did have some valid points.)
Never the less, your solution is less then ideal.
In most cases, I don't have physical access to the target machine.
I access both Grub and the machine console over a serial link.
The service manager must be allowed to operate with /bin only. Nothing
else.
(Let alone fixing it if things go terribly wrong.)

So, again, if you are going the XML route, you you must find a solution
for an initrd and/or /usr-less machine.

Gilboa



From avi at argo.co.il  Sun Nov 20 16:32:12 2005
From: avi at argo.co.il (Avi Kivity)
Date: Sun, 20 Nov 2005 18:32:12 +0200
Subject: init: API
In-Reply-To: <1132503671.8015.50.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<20051118191622.4b9338cb.zaitcev@redhat.com>	<1132395494.9723.20.camel@rousalka.dyndns.org>	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>	<1132478901.8015.8.camel@gilboa-work-dev>	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
Message-ID: <4380A50C.1020308@argo.co.il>

Gilboa Davara wrote:

>The service manager must be allowed to operate with /bin only. Nothing
>else.
>(Let alone fixing it if things go terribly wrong.)
>  
>
I object. This requirement will keep us in the 1970s forever. It has 
already inflicted enough damage in forcing untold millions to learn vi.

This distinction between /bin and /usr/bin is completely artificial. If 
initrd (or whatever) was able to find our /, it should be able to find 
our /usr.



From gilboada at netvision.net.il  Sun Nov 20 16:52:39 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 18:52:39 +0200
Subject: init: API
In-Reply-To: <4380A50C.1020308@argo.co.il>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
Message-ID: <1132505559.8015.68.camel@gilboa-work-dev>

On Sun, 2005-11-20 at 18:32 +0200, Avi Kivity wrote:
> Gilboa Davara wrote:
> 
> >The service manager must be allowed to operate with /bin only. Nothing
> >else.
> >(Let alone fixing it if things go terribly wrong.)
> >  
> >
> I object. This requirement will keep us in the 1970s forever. It has 
> already inflicted enough damage in forcing untold millions to learn vi.

Don't want to lean VI?
Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
Nobody is forcing you.
I am asking that you don't blow thing up just so you can enjoy that
GUI-editors of your more.

> 
> This distinction between /bin and /usr/bin is completely artificial. If 
> initrd (or whatever) was able to find our /, it should be able to find 
> our /usr.
> 

Umm?
A. Who said that both / and /usr are on the same partition? (Or on the
same machine for that matter?)
B. I usually create a backup of /bin and /sbin inside my /boot which
usually sits on the separate software RAID1 partition, while my main
root is partition(s) are on a RAID5 software raid with LVM. I assume
that I'm now forced to create a full backup of my /usr just so I can get
the service manager to work in case of disaster?

There's more at stake here then the configuration file itself.
In my view, the service manager should be simple, bash-based (if
possible), and fully contained within /bin (initrd-able is even better).
You (as in "XML-people") want to create a monster, with XML parsing
libraries, GUI, and god-knows-what, that may (or-may-not) improve
performance. In essence, you are about to create a Windows like service
manager.
I'd suggest you re-read my first statement on why Microsoft's service
manager sucks.

Gilboa



From avi at argo.co.il  Sun Nov 20 17:17:49 2005
From: avi at argo.co.il (Avi Kivity)
Date: Sun, 20 Nov 2005 19:17:49 +0200
Subject: init: API
In-Reply-To: <1132505559.8015.68.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<20051118191622.4b9338cb.zaitcev@redhat.com>	<1132395494.9723.20.camel@rousalka.dyndns.org>	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>	<1132478901.8015.8.camel@gilboa-work-dev>	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>	<1132503671.8015.50.camel@gilboa-work-dev>	<4380A50C.1020308@argo.co.il>
	<1132505559.8015.68.camel@gilboa-work-dev>
Message-ID: <4380AFBD.7010302@argo.co.il>

Gilboa Davara wrote:

>On Sun, 2005-11-20 at 18:32 +0200, Avi Kivity wrote:
>  
>
>>I object. This requirement will keep us in the 1970s forever. It has 
>>already inflicted enough damage in forcing untold millions to learn vi.
>>    
>>
>
>Don't want to lean VI?
>Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
>Nobody is forcing you.
>  
>
You're forcing me to /bin during the boot process. I already wasted some 
of my dwindling neuron supply on that excuse for an editor.

>I am asking that you don't blow thing up just so you can enjoy that
>GUI-editors of your more.
>  
>
What about the other gazillion of thing in /usr? I want to use them in 
my boot process, so I don't have to write it in C or bash (what a pair: 
one runs fast bu produces buggy code and is slow to develop, the other 
is fast to develop but is very slow, and is even more buggy).

>  
>
>>This distinction between /bin and /usr/bin is completely artificial. If 
>>initrd (or whatever) was able to find our /, it should be able to find 
>>our /usr.
>>
>>    
>>
>
>Umm?
>A. Who said that both / and /usr are on the same partition? (Or on the
>same machine for that matter?)
>  
>
I sure didn't.

initrd can mount / from local disk and from the network. Surely it can 
be extended to mount /usr from another partition or from another server.

>B. I usually create a backup of /bin and /sbin inside my /boot which
>usually sits on the separate software RAID1 partition, while my main
>root is partition(s) are on a RAID5 software raid with LVM. I assume
>that I'm now forced to create a full backup of my /usr just so I can get
>the service manager to work in case of disaster?
>  
>
Put the rescue image into some partition. It's a bit more space, sure, 
but still very small compared to disk sizes.

Hey, that might be a good idea for the installer.

>There's more at stake here then the configuration file itself.
>In my view, the service manager should be simple, bash-based (if
>possible), and fully contained within /bin (initrd-able is even better).
>  
>
The problem is that this type of solution is development-intensive, 
which leads to fewer features and more bugs. C isn't very suitable for 
this sort of thing.

>You (as in "XML-people")
>
Actually I'm python-people. I don't have a strong preference for XML.

> want to create a monster, with XML parsing
>libraries, GUI, and god-knows-what, that may (or-may-not) improve
>performance. In essence, you are about to create a Windows like service
>manager.
>I'd suggest you re-read my first statement on why Microsoft's service
>manager sucks.
>  
>
Learning from their mistakes in fine, but that has nothing to do with 
restricting boot to /bin.



From mike at plan99.net  Sun Nov 20 17:24:12 2005
From: mike at plan99.net (Mike Hearn)
Date: Sun, 20 Nov 2005 17:24:12 +0000
Subject: Python incompatibility
Message-ID: <pan.2005.11.20.17.24.12.868051@plan99.net>

Hi,

The copy of Python 2.4 shipped with Fedora Core 4 is configured to use
4-byte unicode instead of 2-byte, which is the upstream default. Modifying
this changes the exported API of libpython and breaks compatibility with
other distributions which is, needless to say, a Very Bad Thing.

Does anybody know why this is done? Is there any chance of fixing this
with a future version of the Python packages?

thanks -mike



From shiva at sewingwitch.com  Sun Nov 20 17:48:25 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 20 Nov 2005 09:48:25 -0800
Subject: init: API
In-Reply-To: <1132505559.8015.68.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>	<4380A50C.1020308@argo.co.il>
	<1132505559.8015.68.camel@gilboa-work-dev>
Message-ID: <2BC272055D013A4CD812B69E@[10.0.0.14]>

--On Sunday, November 20, 2005 6:52 PM +0200 Gilboa Davara 
<gilboada at netvision.net.il> wrote:

> A. Who said that both / and /usr are on the same partition? (Or on the
> same machine for that matter?)

Yep, this is a separate issue. Mounting /usr read-only is desirable, so 
putting it on a separate partition is nice.

Ignoring XML specifically as the configuration language, what's important 
is that the language have a common parser, so that every service doesn't 
have to provide its own. If not XML, do we invent a new language, or codify 
an existing one? If an existing one, someone needs to extract the parser 
from some single implementation and declare it the one that all others will 
be rewritten to use, so that there's no ambiguity in the syntax.

So far all init scripts are written in Bash, and the ones I'm familiar with 
use simple variable=value pairs, using Bash syntax. Is that sufficient? 
What can't be expressed in that way?

The hierarchical configuration I've seen has been in the networking 
scripts, and is encoded in the filesystem, using filenames or directory 
trees to represent configuration nodes. What's the drawback of that, if any?




From gilboada at netvision.net.il  Sun Nov 20 17:52:26 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 19:52:26 +0200
Subject: init: API
In-Reply-To: <4380AFBD.7010302@argo.co.il>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
	<1132505559.8015.68.camel@gilboa-work-dev>
	<4380AFBD.7010302@argo.co.il>
Message-ID: <1132509147.8015.85.camel@gilboa-work-dev>

On Sun, 2005-11-20 at 19:17 +0200, Avi Kivity wrote:
> >Don't want to lean VI?
> >Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
> >Nobody is forcing you.
> >  
> >
> You're forcing me to /bin during the boot process. I already wasted some 
> of my dwindling neuron supply on that excuse for an editor.

My heart goes to your dwindling supply of neurons, but you-yourself
suggest I use a rescue CD to save my precious Linux.
I just followed suit.

I say: Use rescue CD if you want to, but don't force me to dump my
network-based BootPXE rescue image for that.
You say: If I must use a rescue CD, that everybody else must do it also.

> 
> What about the other gazillion of thing in /usr? I want to use them in 
> my boot process, so I don't have to write it in C or bash (what a pair: 
> one runs fast bu produces buggy code and is slow to develop, the other 
> is fast to develop but is very slow, and is even more buggy).
> 

Should I remind you that your kernel and most libraries on that Python
coding machine of yours are build written in C, and most of your boot
process is in bash.
Somehow, I don't see Cpp project such as Mozilla, KDE and OO to show
better stability then the kernel that boots my machine.

I will accept that writing a kernel module in C is much more difficult
then writing a user-land application in Python. (But, on that other
hand, nothing beats spending your nights looking at meaning less oops
with trashed calling stack... Pure joy!)

But we are going way-OT here.

> >
> >Umm?
> >A. Who said that both / and /usr are on the same partition? (Or on the
> >same machine for that matter?)
> >  
> >
> I sure didn't.
> 
> initrd can mount / from local disk and from the network. Surely it can 
> be extended to mount /usr from another partition or from another server.

... And all of this just to add python with its 100,000 libraries to the
boot processes?

> 
> >B. I usually create a backup of /bin and /sbin inside my /boot which
> >usually sits on the separate software RAID1 partition, while my main
> >root is partition(s) are on a RAID5 software raid with LVM. I assume
> >that I'm now forced to create a full backup of my /usr just so I can get
> >the service manager to work in case of disaster?
> >  
> >
> Put the rescue image into some partition. It's a bit more space, sure, 
> but still very small compared to disk sizes.

On my machine Python alone, is around 100MB, let alone required
libraries and dependencies.
How could I possibly stick that in my rescue image and/or BootPXE image?

> 
> Hey, that might be a good idea for the installer.

I second that.
Actually, it'll be a good idea to create a RFE in the bugzilla.
Nice catch!

> 
> >There's more at stake here then the configuration file itself.
> >In my view, the service manager should be simple, bash-based (if
> >possible), and fully contained within /bin (initrd-able is even better).
> >  
> >
> The problem is that this type of solution is development-intensive, 
> which leads to fewer features and more bugs. C isn't very suitable for 
> this sort of thing.
> 
> >You (as in "XML-people")
> >
> Actually I'm python-people. I don't have a strong preference for XML.
>
> > want to create a monster, with XML parsing
> >libraries, GUI, and god-knows-what, that may (or-may-not) improve
> >performance. In essence, you are about to create a Windows like service
> >manager.
> >I'd suggest you re-read my first statement on why Microsoft's service
> >manager sucks.
> >  
> >
> Learning from their mistakes in fine, but that has nothing to do with 
> restricting boot to /bin.
> 

I'm not trying to restrict boot  to bin.
I am trying to persuade against creating a GUI-only monster, that will
end up slower and 100 times more complex (and 100,000 times bigger) then
our current solution.

Speaking of performance, yum is dog slow, even on my dual Opteron
FC4/x86-64 workstation.
Compare that to apt-rpm, and you'll see why I consider a python based
service manager to be a /bad-idea/.

Gilboa




From gilboada at netvision.net.il  Sun Nov 20 17:55:58 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Sun, 20 Nov 2005 19:55:58 +0200
Subject: init: API
In-Reply-To: <2BC272055D013A4CD812B69E@[10.0.0.14]>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
	<1132505559.8015.68.camel@gilboa-work-dev>
	<2BC272055D013A4CD812B69E@[10.0.0.14]>
Message-ID: <1132509358.8015.90.camel@gilboa-work-dev>

On Sun, 2005-11-20 at 09:48 -0800, Kenneth Porter wrote:
> --On Sunday, November 20, 2005 6:52 PM +0200 Gilboa Davara 
> <gilboada at netvision.net.il> wrote:
> 
> > A. Who said that both / and /usr are on the same partition? (Or on the
> > same machine for that matter?)
> 
> Yep, this is a separate issue. Mounting /usr read-only is desirable, so 
> putting it on a separate partition is nice.
> 
> Ignoring XML specifically as the configuration language, what's important 
> is that the language have a common parser, so that every service doesn't 
> have to provide its own. If not XML, do we invent a new language, or codify 
> an existing one? If an existing one, someone needs to extract the parser 
> from some single implementation and declare it the one that all others will 
> be rewritten to use, so that there's no ambiguity in the syntax.

Even if you don't use a bash based solution (that does the parsing for
you), you can create a service manager library that can used by the
executable (to execute the services) and the CLI and GUI tools (to
manage the service manager).

I'm no against shared code....

> 
> So far all init scripts are written in Bash, and the ones I'm familiar with 
> use simple variable=value pairs, using Bash syntax. Is that sufficient? 
> What can't be expressed in that way?
> 
> The hierarchical configuration I've seen has been in the networking 
> scripts, and is encoded in the filesystem, using filenames or directory 
> trees to represent configuration nodes. What's the drawback of that, if any?
> 
> 

I fully second the above.

The main question should be: Can we voodoo-magic the current scripting
engine to improve performance considerably.
In my experience, if the said service manager is designed correctly (and
I'm willing to pitch in, design, coding and all), yes.

Gilboa



From gmaxwell at gmail.com  Sun Nov 20 19:14:16 2005
From: gmaxwell at gmail.com (Gregory Maxwell)
Date: Sun, 20 Nov 2005 14:14:16 -0500
Subject: Python incompatibility
In-Reply-To: <pan.2005.11.20.17.24.12.868051@plan99.net>
References: <pan.2005.11.20.17.24.12.868051@plan99.net>
Message-ID: <e692861c0511201114j524ee164sc84be958ec3660bb@mail.gmail.com>

On 11/20/05, Mike Hearn <mike at plan99.net> wrote:
> The copy of Python 2.4 shipped with Fedora Core 4 is configured to use
> 4-byte unicode instead of 2-byte, which is the upstream default. Modifying
> this changes the exported API of libpython and breaks compatibility with
> other distributions which is, needless to say, a Very Bad Thing.
>
> Does anybody know why this is done? Is there any chance of fixing this
> with a future version of the Python packages?

It's a binary incompatible change, not a source incompatible one, right?
There is no promise that you can run binaries made on another distro.

The use of 4byte UTF has come in handy for me a number of times,
without it you can't handle characters outside of the BMP, this really
should be the default upstream.



From majid.elidrissi at etu.univ-tours.fr  Sun Nov 20 18:27:20 2005
From: majid.elidrissi at etu.univ-tours.fr (El Idrissi Majid)
Date: Sun, 20 Nov 2005 19:27:20 +0100
Subject: kernel/initrd.img for network installation
Message-ID: <200511201927.20688.majid.elidrissi@etu.univ-tours.fr>

Hello

I want make a customize kernel for my network installation.

But now, after the PXE boot, the installer correct starting , I obtain this :

modules XXXXX not found

(in the third log Window) and the automatic installation hangs on.
I think that the problem is in my modules.cgz file, but I tried to follow 
docs, e.g. :

https://www.redhat.com/archives/fedora-devel-list/2005-February/msg01195.html
http://wwwcache.ja.net/dev/kickstart/KickStart-HOWTO-9.html
and so on

( I copied modules files without paths and with paths, then stored them in a 
cpio archive :modules.cgz [

But no results.

Somebody have an idea ?

PS : I already posted a mail to fedora-user list, but nobody answered to me 
PPS : Sorry, I'm not a native speaker



From lamont at gurulabs.com  Sun Nov 20 19:55:20 2005
From: lamont at gurulabs.com (Lamont R. Peterson)
Date: Sun, 20 Nov 2005 12:55:20 -0700
Subject: init: API
In-Reply-To: <1132487867.26111.18.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<200511192325.46781.lamont@gurulabs.com>
	<1132487867.26111.18.camel@rousalka.dyndns.org>
Message-ID: <200511201255.26665.lamont@gurulabs.com>

On Sunday 20 November 2005 04:57am, Nicolas Mailhot wrote:
> Le samedi 19 novembre 2005 ? 23:25 -0700, Lamont R. Peterson a ?crit :
> > On Saturday 19 November 2005 03:18am, Nicolas Mailhot wrote:
> > > Le vendredi 18 novembre 2005 ? 19:16 -0800, Pete Zaitcev a ?crit :
> >
> > [snip]
> >
> > > Just use vim for syntax highlighting and xmllint to check the result.
> >
> > xmllint?  Have you ever used it for any serious XML work?
>
> Yes. Serious x-thousand-lines XML files processing
>
> >  It isn't very accurate.
>
> It *is* accurate. What you may have is applications which accept things
> their XML schema forbids, which is an app problem, not an xmllint one.
> In fact in my experience xmllint is one of the most accurate checkers,
> and any deviation from the specs is fixed as soon as it's reported. 90%
> of "xmllint" problems are apps which do not follow the XML spec and them
> blame xmllint for pointing out their files are buggy.

No.  The applications that I am talking about use very simple XML schemas.  
Simple enough, in fact, that us "bio-parsers" can identify that the XML is 
good in some cases where xmllint fails.

But I'm glad it works for you.

My main problem with xmllint is not that it is wrong sometimes (hey, this is 
software we're talking about, right :) ), but that when it is right about my 
XML being wrong it produces error messages that, at best, lead you the wrong 
way and, at worst, tell you *nothing* (or no error messages at all to help 
you figure out which of your 1,000,000 lines of XML is at fault).

When I compile C or C++ (among others) many times I get error messages about a 
line that is not wrong...thr problem is that the line above is missing the 
semi-colon or the braces are in the wrong spot.  But at least it's in the 
right area, usually within 1 line of the real culprit.

BTW:  I am most certainly NOT suggesting that we replace SysV Init scripts 
with C.
-- 
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- 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/20051120/44bc85f1/attachment.sig>

From avi at argo.co.il  Sun Nov 20 20:17:57 2005
From: avi at argo.co.il (Avi Kivity)
Date: Sun, 20 Nov 2005 22:17:57 +0200
Subject: init: API
In-Reply-To: <2BC272055D013A4CD812B69E@[10.0.0.14]>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<20051118191622.4b9338cb.zaitcev@redhat.com>	<1132395494.9723.20.camel@rousalka.dyndns.org>	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>	<1132478901.8015.8.camel@gilboa-work-dev>	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>	<1132503671.8015.50.camel@gilboa-work-dev>	<4380A50C.1020308@argo.co.il>	<1132505559.8015.68.camel@gilboa-work-dev>
	<2BC272055D013A4CD812B69E@[10.0.0.14]>
Message-ID: <4380D9F5.5040402@argo.co.il>

Kenneth Porter wrote:

>
> So far all init scripts are written in Bash, and the ones I'm familiar 
> with use simple variable=value pairs, using Bash syntax. Is that 
> sufficient? What can't be expressed in that way?

hierarchical configuration. multiple instances of the same service. most 
complex services have their own config files so the complexity is pushed 
there.

>
> The hierarchical configuration I've seen has been in the networking 
> scripts, and is encoded in the filesystem, using filenames or 
> directory trees to represent configuration nodes. What's the drawback 
> of that, if any?
>
dependencies not expressed explicitly, messy config files.

for example, my ppp0 depends on eth0, and a potential vpn would depend 
on ppp0. there is no way to express that with the current syntax. there 
is special support for bonding, etc.

also it's horribly slow:

[root at blast ~]# time /sbin/service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:
Determining IP information for eth0... done.

                                                           [  OK  ]

real    0m11.043s
user    0m0.656s
sys     0m0.776s

1.4 seconds of cpu time to issue a few ioctls and send a couple of 
packets (2.4GHz Athlon64).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From avi at argo.co.il  Sun Nov 20 20:46:35 2005
From: avi at argo.co.il (Avi Kivity)
Date: Sun, 20 Nov 2005 22:46:35 +0200
Subject: init: API
In-Reply-To: <1132509147.8015.85.camel@gilboa-work-dev>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<20051118191622.4b9338cb.zaitcev@redhat.com>	<1132395494.9723.20.camel@rousalka.dyndns.org>	<1132420661.6042.25.camel@localhost>	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>	<1132478901.8015.8.camel@gilboa-work-dev>	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>	<1132503671.8015.50.camel@gilboa-work-dev>	<4380A50C.1020308@argo.co.il>	<1132505559.8015.68.camel@gilboa-work-dev>	<4380AFBD.7010302@argo.co.il>
	<1132509147.8015.85.camel@gilboa-work-dev>
Message-ID: <4380E0AB.70205@argo.co.il>

Gilboa Davara wrote:

>On Sun, 2005-11-20 at 19:17 +0200, Avi Kivity wrote:
>  
>
>>>Don't want to lean VI?
>>>Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
>>>Nobody is forcing you.
>>> 
>>>
>>>      
>>>
>>You're forcing me to /bin during the boot process. I already wasted some 
>>of my dwindling neuron supply on that excuse for an editor.
>>    
>>
>
>My heart goes to your dwindling supply of neurons, but you-yourself
>suggest I use a rescue CD to save my precious Linux.
>I just followed suit.
>
>I say: Use rescue CD if you want to, but don't force me to dump my
>network-based BootPXE rescue image for that.
>  
>
Please, keep your pxe rescue. Just add /usr to it.

>You say: If I must use a rescue CD, that everybody else must do it also.
>  
>
Not at all. I'm all for flexibility, except when it encourages stagnation.

I'm saying we should move boot-time flexibility from /bin to initrd. 
initrd is a fact of life in module-based kernels. By making it a little 
smarter and more flexible, we remove a development bottleneck: the ban 
on /usr (and C++, python, and a zillion other goodies) during boot.

>  
>
>>What about the other gazillion of thing in /usr? I want to use them in 
>>my boot process, so I don't have to write it in C or bash (what a pair: 
>>one runs fast bu produces buggy code and is slow to develop, the other 
>>is fast to develop but is very slow, and is even more buggy).
>>
>>    
>>
>
>Should I remind you that your kernel and most libraries on that Python
>coding machine of yours are build written in C,
>
I want to reuse that effort. By writing in python I can concentrate on 
the application, not the plumbing. The boot process is an excellent 
candidate for python since it requires flexibility.

> and most of your boot
>process is in bash.
>  
>
bash sucks as a programming language. it is impossible to write a 
correct program with it.

even a simple

  if proggy | grep -q something; then echo boo; fi

has three bugs in it.

and it's horribly slow. not bash itself, but forking/execing a new 
binary every other line.

>Somehow, I don't see Cpp project such as Mozilla, KDE and OO to show
>better stability then the kernel that boots my machine.
>  
>
Writing something like OO or KDE in C is masochism.

>I will accept that writing a kernel module in C is much more difficult
>then writing a user-land application in Python. (But, on that other
>hand, nothing beats spending your nights looking at meaning less oops
>with trashed calling stack... Pure joy!)
>
>  
>
I guess python tracebacks with "your bug here" in the end aren't for you.

>But we are going way-OT here.
>
>>initrd can mount / from local disk and from the network. Surely it can 
>>be extended to mount /usr from another partition or from another server.
>>    
>>
>
>... And all of this just to add python with its 100,000 libraries to the
>boot processes?
>
>  
>
[root at blast ~]# time python -c 'print 1'
1

real    0m0.029s
user    0m0.016s
sys     0m0.012s

.028 sec overhead, and you can complete the entire boot process with a 
single python instance (/sbin/init.py :) which stays around and monitors 
your services.

I measured 'service network restart' at 1.4 sec cpu time. I'm sure it 
can be reduces to 50ms or less in readable python.

>>Put the rescue image into some partition. It's a bit more space, sure, 
>>but still very small compared to disk sizes.
>>    
>>
>
>On my machine Python alone, is around 100MB, let alone required
>libraries and dependencies.
>How could I possibly stick that in my rescue image and/or BootPXE image?
>
>  
>
Most CDs are 700MB in size. Most networks have gigabytes or terabytes of 
storage.

(And I'm sure it can fit into  50MB compressed image - the binary RPM is 
20MB)

>>Hey, that might be a good idea for the installer.
>>    
>>
>
>I second that.
>Actually, it'll be a good idea to create a RFE in the bugzilla.
>Nice catch!
>
>  
>
You are ruining a perfect record of disagreement here.

>>Learning from their mistakes in fine, but that has nothing to do with 
>>restricting boot to /bin.
>>    
>>
>
>I'm not trying to restrict boot  to bin.
>  
>
Well, you did say some words to that effect.

>I am trying to persuade against creating a GUI-only monster, that will
>end up slower and 100 times more complex (and 100,000 times bigger) then
>our current solution.
>
>Speaking of performance, yum is dog slow, even on my dual Opteron
>FC4/x86-64 workstation.
>Compare that to apt-rpm, and you'll see why I consider a python based
>service manager to be a /bad-idea/.
>  
>
It's possible to write slow programs in any language. Usually the 
problem lies with the algorithms, not the language. Writing in C makes 
the algorithms more difficult to improve.

Consider that the boot sequence is really just a few hundred steps. All 
that is needed (performance wise) is to hide I/O latencies and not 
fork/exec every binary under /bin and /sbin. But there is a lot that is 
needed in terms of features, and a high-level language is the easiest 
way to achieve that.

(and of course boot should have text output, gui, and blinkenlights 
plugins so every one of us can enjoy it in their own way)

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.



From tmus at tmus.dk  Fri Nov 18 20:13:39 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 18 Nov 2005 21:13:39 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
References: <dlkl13$oik$1@sea.gmane.org>
	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>	<dlkn6u$v8a$1@sea.gmane.org>
	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
Message-ID: <dllcli$41i$1@sea.gmane.org>

Jeff Spaleta wrote:
> On 11/18/05, Thomas M Steenholdt <tmus at tmus.dk> wrote:
> 
> I find them functional "enough" and good looking "enough" (except for
> some minor defects that I have already filed bugs for but do not
> require the cursors to be replaced with a different concept). I don't
> see why colorless mouse icons are automatically better than colored

well, first of all, the chance that a b/w mouse cursor theme will blend 
well with your background of choice is better that with the blue cursors.
I realize that I can just change it, but that's slightly beside my point 
that we should make sure Fedora looks as appealing as possible by default.

> opinions differ and there will be no right answer.

Very true! But that should still mean that we should aim at having 
something that most people would like by default - How about a fedora 
logo competition! That would be a fair way to find the best logo 
suitable for fedora.

> And i certainly do not think that the red hat logo on the desktop that
> we have enjoyed for so long, is any more appropriate or even more
> informational than a separate fedora project logo. I think its very
> important and very informational to be able to distinguish which
> distribution you are using at a glance at the default desktop even
> with windows open obscuring the wallpaper. The fedora logo on the
> gnome panel finally makes a clearly visible distinction that someone
> is on a fedora desktop and not on a rhel system.  As a matter of
> function and informative content.. any fedora specific logo is a
> change for the better.  And there is absolutely no point in arguing
> about the style of the logo.. matters of style have no right answer
> and the style of the logo isn't going to change.

I am all for Fedora having a distict logo. I'm also for Fedora looking 
as appealing as possible by default. I believe that the logo should have 
the same high-quality look that the rest of the default icons have.

And remember - I'm not interested in just having things my-way(tm) - 
Thats not the point of this thread.

/Thomas



From sundaram at redhat.com  Sun Nov 20 21:32:50 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 21 Nov 2005 03:02:50 +0530
Subject: some artwork needs to be replaced...?
In-Reply-To: <dllcli$41i$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org>	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>	<dlkn6u$v8a$1@sea.gmane.org>	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
	<dllcli$41i$1@sea.gmane.org>
Message-ID: <4380EB82.3080109@redhat.com>

Hi

>
> Very true! But that should still mean that we should aim at having 
> something that most people would like by default - How about a fedora 
> logo competition! That would be a fair way to find the best logo 
> suitable for fedora.

see http://fedoraproject.org/wiki/Marketing/LogoIdeas.  Several logos 
were proposed. Discussion has been going on from June 2005 onwards in 
fedora-marketing list. Updates has been provided several times in Fedora 
News. Discussions have been going on in Fedora Forum. Posts in Fedora 
people blogs etc.

regards
Rahul



From petro at mail.ru  Fri Nov 18 20:55:27 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Fri, 18 Nov 2005 23:55:27 +0300
Subject: No sound! 2.6.14-1.1688_FC5
Message-ID: <Pine.LNX.4.64.0511182341010.2590@lemenkov.com>

Hello, All!

If we look ad lsmod output, we see that modules exists:

===========================

[root at Petro ~]# lsmod
Module                  Size  Used by

[sorry, skipped]

snd_via82xx            28136  1
gameport               16073  1 snd_via82xx
snd_ac97_codec         90337  1 snd_via82xx
snd_ac97_bus            2369  1 snd_ac97_codec
snd_seq_dummy           3781  0
snd_seq_oss            32810  1
snd_seq_midi_event      7233  1 snd_seq_oss
snd_seq                50513  3 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_pcm_oss            51953  0
snd_mixer_oss          17985  1 snd_pcm_oss
snd_pcm                87365  3 snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_timer              25413  2 snd_seq,snd_pcm
snd_page_alloc         10825  2 snd_via82xx,snd_pcm
snd_mpu401_uart         7873  1 snd_via82xx
snd_rawmidi            25313  1 snd_mpu401_uart
snd_seq_device          9165  4 snd_seq_dummy,snd_seq_oss,snd_seq,snd_rawmidi
snd                    55077  11 snd_via82xx,snd_ac97_codec,snd_seq_oss,snd_seq,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
soundcore               9633  1 snd

[sorry, skipped]

================================

But if we look at /proc/asound:

================================

[petro at Petro ~]$ cat /proc/asound/cards
--- no soundcards ---
===============================

We can't see any card.
I've found possibly something interesting in process list:

==============================

   598 ?        S<     0:00 /sbin/modprobe pci:v00001106d00003059sv00001458sd0000A002bc04sc01i00
   955 ?        S<     0:00  \_ sh -c /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device
   984 ?        D<     0:00      \_ /sbin/modprobe snd_seq_oss

==============================

Only couple of days ago sound was working (using 2.6.14 generic kernel 
from kernel.org, - unfortunately, I loose my old config).

What should I do with FC-kernel for quick fix?

-- 
With best regards, Peter Lemenkov.




From tmus at tmus.dk  Fri Nov 18 20:37:15 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 18 Nov 2005 21:37:15 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <1132330184.5672.4.camel@localhost.localdomain>
References: <dlkl13$oik$1@sea.gmane.org>
	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>	<dlkn6u$v8a$1@sea.gmane.org>	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
	<1132330184.5672.4.camel@localhost.localdomain>
Message-ID: <dlle1r$7vv$1@sea.gmane.org>

Paul W. Frields wrote:
> Agreed, FWIW, and I for one would like to see the new logo appear in the
> FC4 branch (i.e. an update) to get everyone used to it... or at least
> get the inevitable deluge of complaints out of the way to make way for
> more appropriate traffic subsequent to the FC5 test releases.

Let's make Fedora stand out with a new logo, but let us at least have a 
few to choose from and then a contest!

/Thomas



From mike at plan99.net  Sun Nov 20 21:32:22 2005
From: mike at plan99.net (Mike Hearn)
Date: Sun, 20 Nov 2005 21:32:22 +0000
Subject: Python incompatibility
References: <pan.2005.11.20.17.24.12.868051@plan99.net>
	<e692861c0511201114j524ee164sc84be958ec3660bb@mail.gmail.com>
Message-ID: <pan.2005.11.20.21.32.21.852959@plan99.net>

> The use of 4byte UTF has come in handy for me a number of times,
> without it you can't handle characters outside of the BMP, this really
> should be the default upstream.

Possibly this should be taken upstream instead of simply changed in Fedora
then, so the change is synchronised?



From stickster at gmail.com  Sun Nov 20 21:34:34 2005
From: stickster at gmail.com (Paul W. Frields)
Date: Sun, 20 Nov 2005 16:34:34 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <dllcli$41i$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org> <437DDB9F.9050405@hhs.nl>
	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>
	<dlkn6u$v8a$1@sea.gmane.org>
	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>
	<dllcli$41i$1@sea.gmane.org>
Message-ID: <1132522474.23150.39.camel@localhost.localdomain>

On Fri, 2005-11-18 at 21:13 +0100, Thomas M Steenholdt wrote:
> Jeff Spaleta wrote:
> > opinions differ and there will be no right answer.
> 
> Very true! But that should still mean that we should aim at having 
> something that most people would like by default - How about a fedora 
> logo competition! That would be a fair way to find the best logo 
> suitable for fedora.

Don't do it, Jeff!  Back away from the keyboard...  :-D

-- 
Paul W. Frields, RHCE                          http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051120/467c96b4/attachment.sig>

From tmus at tmus.dk  Fri Nov 18 22:02:38 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Fri, 18 Nov 2005 23:02:38 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <dlkl13$oik$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org>
Message-ID: <dllj1s$lug$1@sea.gmane.org>

For anyone interested, here's the story of the logo!

http://www.capstrat.com/development/fedora/index.php

...and let's make a few things clear.

- I love the idea of fedora having it's own logo.
- I think the logo in question has all the right parts, all the elements 
are just right.

still, IMHO it's the actual logo/wordmark does not look good enough in 
my opinion.

But hey, if it's just me, I can replace it!

/Thomas




From bojan at rexursive.com  Sun Nov 20 21:48:47 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Mon, 21 Nov 2005 08:48:47 +1100
Subject: xmkmf in modular X
In-Reply-To: <1132371678.5266.23.camel@coyote.rexursive.com>
References: <1132225121.27296.13.camel@coyote.rexursive.com>
	<437C7C64.6080207@redhat.com>
	<1132253558.27296.15.camel@coyote.rexursive.com>
	<1132371678.5266.23.camel@coyote.rexursive.com>
Message-ID: <20051121084847.uaork9b0g0004wc8@imp.rexursive.com>

Quoting Bojan Smojver <bojan at rexursive.com>:

> Anyway, I'll have a look at a few Makefile.am examples in order to port
> to the new build system...

After shamelessly cannibalizing some of the Makefile.am/configure.ac 
files from X11 apps package, it looks like xbrightness builds with the 
autotools  and puts itself in /usr/bin and /usr/share/man directories. 
Nice ;-)

I tried contacting the author of xbrightness before, in order to 
clarify licensing issues, but I got no reply. So, don't count on the 
package being submitted to Extras any time soon :-(

-- 
Bojan



From davej at redhat.com  Sun Nov 20 21:50:44 2005
From: davej at redhat.com (Dave Jones)
Date: Sun, 20 Nov 2005 16:50:44 -0500
Subject: No sound! 2.6.14-1.1688_FC5
In-Reply-To: <Pine.LNX.4.64.0511182341010.2590@lemenkov.com>
References: <Pine.LNX.4.64.0511182341010.2590@lemenkov.com>
Message-ID: <20051120215044.GD28918@redhat.com>

On Fri, Nov 18, 2005 at 11:55:27PM +0300, Peter Lemenkov wrote:


 > I've found possibly something interesting in process list:
 > 
 > ==============================
 > 
 >   598 ?        S<     0:00 /sbin/modprobe 
 >   pci:v00001106d00003059sv00001458sd0000A002bc04sc01i00
 >   955 ?        S<     0:00  \_ sh -c /sbin/modprobe --ignore-install 
 >   snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device
 >   984 ?        D<     0:00      \_ /sbin/modprobe snd_seq_oss
 > 

modprobe hung. It's possibly oopsed the kernel
(see dmesg for more)

 > Only couple of days ago sound was working (using 2.6.14 generic kernel 
 > from kernel.org, - unfortunately, I loose my old config).
 > 
 > What should I do with FC-kernel for quick fix?

It's possibly related to the mmap changes upstream in 2.6.15rc
(which is what that FC5 kernel is based upon).
It'll work itself out over time, but it's looking like post-test1 material
right now.

(I'm dreading the test1 bug reports already)

		Dave



From jspaleta at gmail.com  Sun Nov 20 21:53:20 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 20 Nov 2005 16:53:20 -0500
Subject: some artwork needs to be replaced...?
In-Reply-To: <dllj1s$lug$1@sea.gmane.org>
References: <dlkl13$oik$1@sea.gmane.org> <dllj1s$lug$1@sea.gmane.org>
Message-ID: <604aa7910511201353l174e0b65y6c78e40f70926060@mail.gmail.com>

On 11/18/05, Thomas M Steenholdt <tmus at tmus.dk> wrote:
> still, IMHO it's the actual logo/wordmark does not look good enough in
> my opinion.

opinion noted... time to move on.

-jef



From bojan at rexursive.com  Sun Nov 20 22:21:03 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Mon, 21 Nov 2005 09:21:03 +1100
Subject: init: API
In-Reply-To: <4380A50C.1020308@argo.co.il>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
Message-ID: <20051121092103.uqlpdun9mosccgwk@imp.rexursive.com>

Quoting Avi Kivity <avi at argo.co.il>:

> I object. This requirement will keep us in the 1970s forever. It has 
> already inflicted enough damage in forcing untold millions to learn 
> vi.
>
> This distinction between /bin and /usr/bin is completely artificial. 
> If initrd (or whatever) was able to find our /, it should be able to 
> find our /usr.

At present, FHS 2.3 states:

-------------------------
3.4. /bin : Essential user command binaries (for use by all users)

3.4.1. Purpose
/bin contains commands that may be used by both the system 
administrator and by users, but which are required when no other 
filesystems are mounted (e.g. in single user mode). It may also contain 
commands which are used indirectly by scripts. 1

[snip]

1. Command binaries that are not essential enough to place into /bin 
must be placed in /usr/bin, instead. Items that are required only by 
non-root users (the X Window System, chsh, etc.) are generally not 
essential enough to be placed into the root partition.
-------------------------

I would appear that system init is one of those things that should rely 
on "essential" things only (because it is itself in charge of mounting 
those unmounted file systems). At least IMHO.

Basically, you should submit such a change request to FHS folks, given 
that Fedora strives to implement that standard as close as possible. 
Systems like Solaris stopped making the /bin /usr/bin distinction a 
while ago, but that doesn't necessarily mean Linux (or Fedora) should 
do the same.

Note that I'm not necessarily disagreeing with your proposal (nor am I 
necessarily agreeing :-), but merely pointing out the state of 
standards Fedora is attempting to implement at present.

-- 
Bojan



From skvidal at phy.duke.edu  Sun Nov 20 22:41:18 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 20 Nov 2005 17:41:18 -0500
Subject: init: API
In-Reply-To: <20051121092103.uqlpdun9mosccgwk@imp.rexursive.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
	<20051121092103.uqlpdun9mosccgwk@imp.rexursive.com>
Message-ID: <1132526478.4340.19.camel@cutter>

If I ask EXTREMELY nicely could we please get the init api discussion
taken off to another list? Yes, I know it affects fedora devel but it's
been going on the last N days and I have almost zero-interest in it and
I know I'm not alone.

So if you want a fedora-init-devel-list at redhat.com  to discuss this in
painstaking detail I bet we can get that created for you. Or if you want
to discuss it on the mailing list of the initng project (if they have
one, etc) then that'd also be great but we've kinda gone down every
possible discussion area in the past couple of days and I hope we can
stop now.


Thank You,
-sv




From jeff.pitman at gmail.com  Mon Nov 21 01:05:51 2005
From: jeff.pitman at gmail.com (Jeff Pitman)
Date: Mon, 21 Nov 2005 01:05:51 +0000
Subject: Python incompatibility
In-Reply-To: <pan.2005.11.20.21.32.21.852959@plan99.net>
References: <pan.2005.11.20.17.24.12.868051@plan99.net>
	<e692861c0511201114j524ee164sc84be958ec3660bb@mail.gmail.com>
	<pan.2005.11.20.21.32.21.852959@plan99.net>
Message-ID: <6b9c17630511201705l34b4b95dibfb7708c83257d11@mail.gmail.com>

On 11/20/05, Mike Hearn <mike at plan99.net> wrote:
>
> > The use of 4byte UTF has come in handy for me a number of times,
> > without it you can't handle characters outside of the BMP, this really
> > should be the default upstream.
>
> Possibly this should be taken upstream instead of simply changed in Fedora
> then, so the change is synchronised?
>

I'm not sure what change you're looking for, but, going forward it's ucs4.
Some cursory searches about the issue show that Tcl/Tk needs it and xml
processing stuff recommend it. If you want to provide binary extensions,
notice that the mx folks provide an RPM for the UCS2 build and one for the
UCS4 build. Not sure if Mihai will see this thread, but, I do remember
discussing this in length with him at one point. IIRC, it's not fixed
upstream because of some serious performance hits dealing with it and the
BDFL, et al. didn't want to go there. More searches required to dig this
up...

--
-jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/74db0983/attachment.htm>

From tmus at tmus.dk  Mon Nov 21 02:35:14 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 21 Nov 2005 03:35:14 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <604aa7910511201353l174e0b65y6c78e40f70926060@mail.gmail.com>
References: <dlkl13$oik$1@sea.gmane.org> <dllj1s$lug$1@sea.gmane.org>
	<604aa7910511201353l174e0b65y6c78e40f70926060@mail.gmail.com>
Message-ID: <dlrbok$1st$2@sea.gmane.org>

Jeff Spaleta wrote:
> On 11/18/05, Thomas M Steenholdt <tmus at tmus.dk> wrote:
>> still, IMHO it's the actual logo/wordmark does not look good enough in
>> my opinion.
> 
> opinion noted... time to move on.
> 
> -jef
> 

right!

/Thomas



From tmus at tmus.dk  Mon Nov 21 02:34:41 2005
From: tmus at tmus.dk (Thomas M Steenholdt)
Date: Mon, 21 Nov 2005 03:34:41 +0100
Subject: some artwork needs to be replaced...?
In-Reply-To: <1132522474.23150.39.camel@localhost.localdomain>
References: <dlkl13$oik$1@sea.gmane.org>
	<437DDB9F.9050405@hhs.nl>	<604aa7910511180542w95f2ed7q47b7ad20a342c0d3@mail.gmail.com>	<dlkn6u$v8a$1@sea.gmane.org>	<604aa7910511180710o195d4111u39836d6e89696d6a@mail.gmail.com>	<dllcli$41i$1@sea.gmane.org>
	<1132522474.23150.39.camel@localhost.localdomain>
Message-ID: <dlrbnj$1st$1@sea.gmane.org>

Paul W. Frields wrote:
> On Fri, 2005-11-18 at 21:13 +0100, Thomas M Steenholdt wrote:
>> Jeff Spaleta wrote:
>>> opinions differ and there will be no right answer.
>> Very true! But that should still mean that we should aim at having 
>> something that most people would like by default - How about a fedora 
>> logo competition! That would be a fair way to find the best logo 
>> suitable for fedora.
> 
> Don't do it, Jeff!  Back away from the keyboard...  :-D
> 
> 

Yeah, I realized several ideas has been processed and I should keep up, 
sorry about that!

/Thomas



From saddateh at gmail.com  Mon Nov 21 07:44:08 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Mon, 21 Nov 2005 02:44:08 -0500
Subject: Broken video drivers in new modular X
Message-ID: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>

Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest
BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do not
work properly. When X is configured to use the vesa driver it comes up, but
the picture is distorted (looks like 2 vertical desktops overlapping one
another at various points, also colors are messed up). As for trying to use
the r128 driver, X cannot even load when configured this way, it fails with
an error along the lines of the r128_drv.so could not be opened. Has anyone
else seen issues like this with the new modular X packages? Should I file
bugs for these in x.org <http://x.org>'s bugzilla? Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/06cf08d2/attachment.htm>

From mailinglists at erwinrol.com  Mon Nov 21 09:22:12 2005
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Mon, 21 Nov 2005 10:22:12 +0100
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
Message-ID: <1132564932.8267.20.camel@xpc.home.erwinrol.com>

On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote:
> Hi all, just writing to say that on my Dell Inspiron 8000 laptop
> (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128
> drivers do not work properly. 

My Radeon locks the machine hard, meaning no network, no nothing, only
can press the reset/power switch. I have seen previous reports here with
the same problem, but there was talk about that AGP might be the
problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI
Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). 
That card worked fine with the old Xorg before the switch to mod-X.

> When X is configured to use the vesa driver it comes up, but the
> picture is distorted (looks like 2 vertical desktops overlapping one
> another at various points, also colors are messed up). 

When i use the vesa driver i see things like that too. The icons of
applications have the wrong colors (looks like R and G and B are
switched) and they are also at the wrong place (shifted 20 pixels or
so).

I am now running with the fbdev driver on top of the radeonfb this works
but is of course not optimal. 

> As for trying to use the r128 driver, X cannot even load when
> configured this way, it fails with an error along the lines of the
> r128_drv.so could not be opened. Has anyone else seen issues like this
> with the new modular X packages? Should I file bugs for these in
> x.org's bugzilla? Thanks.

Well if it are really the same issues i dunno, but i sure have issues
with mod X.

- Erwin




From seg at haxxed.com  Mon Nov 21 10:25:55 2005
From: seg at haxxed.com (Callum Lerwick)
Date: Mon, 21 Nov 2005 04:25:55 -0600
Subject: Where should the modular X11R7 fonts get installed to?
In-Reply-To: <200511092035.26758.jbarnes@virtuousgeek.org>
References: <436E1D82.6040708@redhat.com>
	<200511060849.00109.jbarnes@virtuousgeek.org>
	<4372A6AA.70906@redhat.com>
	<200511092035.26758.jbarnes@virtuousgeek.org>
Message-ID: <1132568756.5330.13.camel@localhost.localdomain>

> Are there any legacy applications required for a proper X installation?  
> If not, then on most systems the xorg-x11-fonts package may not be 
> needed (as long as the X server itself supplies the infamous 'fixed' 
> font I guess).

Well, one glaring example is xscreensaver. Even though xscreensaver has
been a core part of Gnome for a while now, it uses its own internal
password dialog, apparently due to paranoia about security. This
internal GUI uses core fonts. jwz has some talk about using a toolkit
like GTK via a seperate process here:
http://www.jwz.org/xscreensaver/toolkits.html

The other option is to just patch xscreensaver's internal dialog to use
xft, which will at least get rid of the dependency on the core font
system.

There's also vncviewer, I can't figure out what toolkit its using if
any, but it uses core fonts for its GUI. I find it annoying that vino is
a part of Gnome, but there's no Gnome VNC viewer. vncviewer's UI is
terrible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/f287074f/attachment.sig>

From wrrhdev at riede.org  Mon Nov 21 11:42:38 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Mon, 21 Nov 2005 11:42:38 +0000
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	(from saddateh@gmail.com on Mon Nov 21 02:44:08 2005)
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
Message-ID: <1132573358l.11959l.14l@serve.riede.org>

On 11/21/2005 02:44:08 AM, Sadda Teh wrote:
> Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest
> BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do not
> work properly. When X is configured to use the vesa driver it comes up, but
> the picture is distorted (looks like 2 vertical desktops overlapping one
> another at various points, also colors are messed up). As for trying to use
> the r128 driver, X cannot even load when configured this way, it fails with
> an error along the lines of the r128_drv.so could not be opened. Has anyone
> else seen issues like this with the new modular X packages? Should I file
> bugs for these in x.org <http://x.org>'s bugzilla? Thanks.

That might be similar to the bug I submitted:
https://bugs.freedesktop.org/show_bug.cgi?id=5108

Willem Riede.



From dhollis at davehollis.com  Mon Nov 21 11:47:04 2005
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 21 Nov 2005 06:47:04 -0500
Subject: Broken video drivers in new modular X
In-Reply-To: <1132564932.8267.20.camel@xpc.home.erwinrol.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	<1132564932.8267.20.camel@xpc.home.erwinrol.com>
Message-ID: <1132573624.18206.1.camel@dhollis-lnx.sunera.com>

On Mon, 2005-11-21 at 10:22 +0100, Erwin Rol wrote:
> On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote:
> > Hi all, just writing to say that on my Dell Inspiron 8000 laptop
> > (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128
> > drivers do not work properly. 
> 
> My Radeon locks the machine hard, meaning no network, no nothing, only
> can press the reset/power switch. I have seen previous reports here with
> the same problem, but there was talk about that AGP might be the
> problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI
> Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). 
> That card worked fine with the old Xorg before the switch to mod-X.

For what it's worth, the ATI Radeon R250 on my Thinkpad T42 works just fine using the xorg ati driver in modular X.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/a4f2bbfe/attachment.sig>

From harald at redhat.com  Mon Nov 21 13:09:06 2005
From: harald at redhat.com (Harald Hoyer)
Date: Mon, 21 Nov 2005 14:09:06 +0100
Subject: what is going on with udev?
In-Reply-To: <BAY103-F25B6F253D368D7DFAF0697DF5E0@phx.gbl>
References: <BAY103-F25B6F253D368D7DFAF0697DF5E0@phx.gbl>
Message-ID: <4381C6F2.4050802@redhat.com>

Jason Dravet wrote:
> Hello everyone,
> 
> I have been pulling my hair out for the last several days trying to 
> figure out why my usb thumb drive is not being mounted.  It was 
> /dev/sdc1 (I have two scsi hard drives).  I read all of the usb related 
> threads in the fedora-test-list but none quite matched my problem.  Long 
> story short my thumb drive is now at /dev/uba1.  Why did this change?  
> Since udev-075-2 the starting udev process takes over 1 minute, before 
> it took about 10 seconds.  Some other people where also inquering about 
> the slowest of udev.
> 
> A quick look in /dev shows I have 64 tty nodes (tty0 - tty63) and 32 
> ttyS nodes (ttyS0 - ttyS31).  I have two serial ports, both of which are 
> disabled in the bios.  Why are these nodes showing up?  These extra 
> nodes have been around since FC4 so udev-075-2 is not the blame for this.
> 
> Thanks,
> Jason
> 
> 


Could you please try the version from ftp://people.redhat.com/harald/udev/075-4/



From buildsys at redhat.com  Mon Nov 21 13:13:02 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 21 Nov 2005 08:13:02 -0500
Subject: rawhide report: 20051121 changes
Message-ID: <200511211313.jALDD2TU011151@porkchop.devel.redhat.com>

 

 
Updated Packages:

GFS-kernel-2.6.14.0-20051108.134753.FC5.10
------------------------------------------

NetworkManager-0.5.1-4
----------------------
* Fri Nov 18 2005 Peter Jones <pjones at redhat.com> - 0.5.1-4
- Don't kill the network connection when you upgrade the package.

anaconda-10.90.7-1
------------------
* Sun Nov 20 2005 Jeremy Katz <katzj at redhat.com> - 10.90.7-1
- fix backwards whiteout handling (#173738)
- fix bug in depsolver which would bring in a package for an already 
  satisfied dep

* Sat Nov 19 2005 Jeremy Katz <katzj at redhat.com> - 10.90.6-1
- fix removal of packages to not traceback
- fix anaconda.dmraid logging (clumens)

* Fri Nov 18 2005 Paul Nasrat <pnasrat at redhat.com> - 10.90.5-1
- Disable sqlite cache for pkgorder
- Fix for new selinux context types (katzj)
- vnc parameter handling (clumens)
- Add ellipsis (notting)

booty-0.60-3
------------
* Fri Nov 18 2005 Peter Jones <pjones at redhat.com> 0.60-3
- fix raid on ppc
- fix partition numbering on pegasos

* Fri Oct 28 2005 Jeremy Katz <katzj at redhat.com> - 0.59-1
- support serial console for xen

* Thu Oct 27 2005 Jeremy Katz <katzj at redhat.com> - 0.58-1
- quick version of getting xen dom0 kernel setup properly in grub.conf

chkconfig-1.3.24-1
------------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 1.3.24-1
- when removing alternatives links, check to make sure they're
  actually links (#173685)

cman-kernel-2.6.14.0-20051108.134753.FC5.8
------------------------------------------

dlm-kernel-2.6.14.0-20051108.134753.FC5.10
------------------------------------------

freetype-2.1.10-5
-----------------
* Fri Nov 18 2005 Bill Nottingham  <notting at redhat.com> 2.1.10-5
- Remove references to obsolete /usr/X11R6 paths

glibc-2.3.90-18
---------------
* Sat Nov 19 2005 Jakub Jelinek <jakub at redhat.com> 2.3.90-18
- update from CVS
  - change <sys/stat.h> for broken apps that #define const /**/,
    handle non-GCC compilers
  - fix ppc{32,64} strncmp (BZ#1877, #173643, IT#83510)
  - provide shmatt_t typedef in ia64 <sys/shm.h (#173680)
  - support 2nd arg to futimesat being NULL (#173581)

gnbd-kernel-2.6.14.0-20051108.134753.FC5.12
-------------------------------------------

htmlview-3.0.0-13
-----------------
* Sat Nov 19 2005 Warren Togami <wtogami at redhat.com> - 3.0.0-13
- xterm no longer in X11R6 dir

kernel-2.6.14-1.1696_FC5
------------------------
* Sat Nov 19 2005 David Woodhouse <dwmw2 at redhat.com>
- Make kernel-devel packages work again for ppc/ppc64
- Fix oops with MGA on root PCI bus

* Fri Nov 18 2005 David Woodhouse <dwmw2 at redhat.com>
- Fix ppc64 sparsemem with memory holes.

* Fri Nov 18 2005 Dave Jones <davej at redhat.com>
- Write protect kernel space rodata on x86-32 too.
- Fix up the placement of Obsolete: on x86-64

libxklavier-2.0-2
-----------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 2.0-2
- Fix references to obsolete X11R6 paths

mesa-6.4-5
----------
* Sun Nov 20 2005 Jeremy Katz <katzj at redhat.com> - 6.4-5
- fix directory used for loading dri modules (#173679)
- install dri drivers as executable so they get stripped (#173292)

ppc64-utils-0.9-12
------------------
* Fri Nov 18 2005 David Woodhouse <dwmw2 at redhat.com> - 0.9-12
- Update zImage.stub from 2.6.15-rc1 kernel
- Link zImage at 3MiB since the POWER5 doesn't like it at 8MiB

* Tue Oct 25 2005 Paul Nasrat <pnasrat at redhat.com> - 0.9-11
- Bump internal version above rhel4 ver
- Pull in later ppc64-utils (#169035)

* Tue Oct 25 2005 Paul Nasrat <pnasrat at redhat.com> - 0.7-13
- Stop scanning nvram on broken content (#170418)




Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390x requires dmraid



From mike at plan99.net  Mon Nov 21 14:09:49 2005
From: mike at plan99.net (Mike Hearn)
Date: Mon, 21 Nov 2005 14:09:49 +0000
Subject: Python incompatibility
References: <pan.2005.11.20.17.24.12.868051@plan99.net>
	<e692861c0511201114j524ee164sc84be958ec3660bb@mail.gmail.com>
	<pan.2005.11.20.21.32.21.852959@plan99.net>
	<6b9c17630511201705l34b4b95dibfb7708c83257d11@mail.gmail.com>
Message-ID: <pan.2005.11.21.14.09.49.918276@plan99.net>

> If you want to provide binary extensions,
> notice that the mx folks provide an RPM for the UCS2 build and one for the
> UCS4 build.

Ouch ... how are users expected to know which they have?



From linux_4ever at yahoo.com  Mon Nov 21 14:19:02 2005
From: linux_4ever at yahoo.com (Steve G)
Date: Mon, 21 Nov 2005 06:19:02 -0800 (PST)
Subject: Broken video drivers in new modular X
In-Reply-To: <1132564932.8267.20.camel@xpc.home.erwinrol.com>
Message-ID: <20051121141903.69357.qmail@web51504.mail.yahoo.com>


>When i use the vesa driver i see things like that too. The icons of
>applications have the wrong colors (looks like R and G and B are
>switched) and they are also at the wrong place (shifted 20 pixels or
>so).

I'm seeing nearly the same thing. The icons on the top tool bar overlap each
other, Icons on the desktop seem to have a green shadow around them, when you
mouse over them the icon shifts to the right with occasional garbage to the right
of the icon, when you open a window you get a dark shadow to the right of the
terminal, when you drag a window around the screen, it leaves garbage where the
window used to be.

In my opinion, X is now unusable. I truly hope Test1 is not going out with an
unusable X system since that is likely to be the majority of the feedback we will
get.

-Steve


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com



From ph18 at cornell.edu  Mon Nov 21 15:19:40 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Mon, 21 Nov 2005 10:19:40 -0500
Subject: init: API
In-Reply-To: <1132395384.9723.17.camel@rousalka.dyndns.org>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132221141.29504.9.camel@gilboa-work-dev>	<1132234527.9749.120.camel@dimi.lattica.com>	<1132239325.31499.48.camel@gilboa-work-dev>	<005401c5eb89$2ceacf00$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
Message-ID: <4381E58C.7000604@cornell.edu>

Nicolas Mailhot wrote:

>There is *nothing* wrong with XML itself, if fact there are lots of very
>good built-in properties in XML, the only thing a service description in
>XML would need is strong style guidelines.
>  
>
    Yeah,  that's what they always say.  In the end,  however,  you know 
a tree by it's fruit.

    On some level you're right -- Bray's original XML specification is 
one of the most beautiful technical documents I've read.

    Namespaces are conceptually a good idea,  but in real life they 
require programmers to get a PhD in XML before they can use them.

    If people consistenly use a tool incorrectly,  it's a sign of either 
conceptual flaws in the tool or an impeadance mismatch between the tool 
and the applications.  In most cases the second is the case with XML.

    For instance,  Cox says that some XML API's are bad but that someday 
somebody might write a good one.  The trouble is that it's hard to write 
a good API for XML -- there's an impeadance mismatch between the vast 
potentials of what you ~could~ do with XML and the tasks that 
programmers actually need to do.  For instance,  they say you're never 
supposed to write something like

# after outputting XML header

print <<END_XML;
<record>
   <field1>$field1</field1>
   <field2>$field2</field2>
</record>
END_XML

    because you could easily bork it up and get output that isn't valid 
XML.  Now there are a hundred different ways you could do things 
'properly' with the DOM API by creating DOM objects and combining them 
until you've got a DOM tree in RAM,  and then writing it out -- simiarly 
you could do it in a SAX-like case.  The trouble is that all of them are 
much less obvious than the one above,  where it's clear how to add 
<field3> or make any other kind of change in the output text.

    In real life,  I've often spent the greater part of a day figuring 
out how somebody is building an XML document (first figuring out the XML 
API,  and then all the cruft they built on top of it) in order to make a 
simple change in the document that I could have made instantly had they 
done it the way above...  On the other hand,  had they done it the way 
above,  I could have easily blown the system away by having a '<' 
character in $field1.

    On the other hand,  it would be a challenge to create a difficult 
API for

* Windows .ini files
* CSV files
* lisp s-expressions



From dravet at hotmail.com  Mon Nov 21 16:57:21 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Mon, 21 Nov 2005 10:57:21 -0600
Subject: what is going on with udev? 
Message-ID: <BAY103-F31EB0740679E94E7BE51AFDF530@phx.gbl>

>>Hello everyone,
>>    I have been pulling my hair out for the last several days trying to 
>>figure out why my usb thumb drive
>>is not being mounted. It was /dev/sdc1 (I have two scsi hard drives). I 
>>read all of the usb related threads in the fedora-test-list but none quite 
>>matched my problem. Long story short my thumb drive is
>>now at /dev/uba1. Why did this change? Since udev-075-2 the starting udev 
>>process takes over 1 minute, before it took about 10 seconds. Some other 
>>people where also inquering about the slowest of udev.
>>
>>    A quick look in /dev shows I have 64 tty nodes (tty0 - tty63) and 32 
>>ttyS nodes (ttyS0 - ttyS31). I  have two serial ports, both of which are 
>>disabled in the bios. Why are these nodes showing up? These extra nodes 
>>have been around since FC4 so udev-075-2 is not the blame for this.
>>
>>    Thanks,
>>    Jason
>
>Could you please try the version from 
>ftp://people.redhat.com/harald/udev/075-4/

I downloaded 075-4, installed it, rebooted and it is still very slow, but my 
usb thumb drive is back to being /dev/sdc1.  The 64 tty nodes and 32 ttyS 
nodes are still there.  If I remember correctly, tty is for terminal 
sessions and ttyS is for serial ports, right?

Thanks,
Jason




From michael.favia at insitesinc.com  Mon Nov 21 17:37:59 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Mon, 21 Nov 2005 11:37:59 -0600
Subject: Broken video drivers in new modular X
In-Reply-To: <1132564932.8267.20.camel@xpc.home.erwinrol.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	<1132564932.8267.20.camel@xpc.home.erwinrol.com>
Message-ID: <438205F7.7070601@insitesinc.com>

Erwin Rol wrote:
> On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote:
>> Hi all, just writing to say that on my Dell Inspiron 8000 laptop
>> (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128
>> drivers do not work properly. 
> 
> My Radeon locks the machine hard, meaning no network, no nothing, only
> can press the reset/power switch. I have seen previous reports here with
> the same problem, but there was talk about that AGP might be the
> problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI
> Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). 
> That card worked fine with the old Xorg before the switch to mod-X.
> 
>> When X is configured to use the vesa driver it comes up, but the
>> picture is distorted (looks like 2 vertical desktops overlapping one
>> another at various points, also colors are messed up). 
> 
> When i use the vesa driver i see things like that too. The icons of
> applications have the wrong colors (looks like R and G and B are
> switched) and they are also at the wrong place (shifted 20 pixels or
> so).
> 
> I am now running with the fbdev driver on top of the radeonfb this works
> but is of course not optimal. 
> 
>> As for trying to use the r128 driver, X cannot even load when
>> configured this way, it fails with an error along the lines of the
>> r128_drv.so could not be opened. Has anyone else seen issues like this
>> with the new modular X packages? Should I file bugs for these in
>> x.org's bugzilla? Thanks.
> 
> Well if it are really the same issues i dunno, but i sure have issues
> with mod X.

I think these are two separate issues. My ati based laptop showed 
similar symptoms to above while it was trying to load the r128 driver. I 
edited xorg.conf to reflect ati instead of r128 and that was fixed.

The skewed color table and icons are a different problem i think because 
it affects only one of my desktops. Not all windows are skewed but 
anything on the gnome desktop is purple, about 10px skewed to the left 
and overlaying other things. Feels somewhat like im playing a game of 
memory to upen various applications :). -mf



From saddateh at gmail.com  Mon Nov 21 18:16:57 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Mon, 21 Nov 2005 13:16:57 -0500
Subject: Broken video drivers in new modular X
In-Reply-To: <1132573358l.11959l.14l@serve.riede.org>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	<1132573358l.11959l.14l@serve.riede.org>
Message-ID: <fc33c1550511211016w4ad1ff78xa33a4eb97a0caf58@mail.gmail.com>

Willem, the screenshot (https://bugs.freedesktop.org/attachment.cgi?id=3851)
you posted in x.org <http://x.org>'s bugzilla is pretty much exactly what
I'm seeing on my Inspiron 8000 when I use the vesa driver.

On 11/21/05, Willem Riede <wrrhdev at riede.org> wrote:
>
> On 11/21/2005 02:44:08 AM, Sadda Teh wrote:
> > Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest
> > BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do
> not
> > work properly. When X is configured to use the vesa driver it comes up,
> but
> > the picture is distorted (looks like 2 vertical desktops overlapping one
> > another at various points, also colors are messed up). As for trying to
> use
> > the r128 driver, X cannot even load when configured this way, it fails
> with
> > an error along the lines of the r128_drv.so could not be opened. Has
> anyone
> > else seen issues like this with the new modular X packages? Should I
> file
> > bugs for these in x.org <http://x.org> <http://x.org>'s bugzilla?
> Thanks.
>
> That might be similar to the bug I submitted:
> https://bugs.freedesktop.org/show_bug.cgi?id=5108
>
> Willem Riede.
>
> --
> 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/20051121/5b104f5e/attachment.htm>

From alan at redhat.com  Mon Nov 21 18:47:29 2005
From: alan at redhat.com (Alan Cox)
Date: Mon, 21 Nov 2005 13:47:29 -0500
Subject: init: API
In-Reply-To: <4381E58C.7000604@cornell.edu>
References: <005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<4381E58C.7000604@cornell.edu>
Message-ID: <20051121184729.GB5017@devserv.devel.redhat.com>

On Mon, Nov 21, 2005 at 10:19:40AM -0500, Paul A Houle wrote:
>    For instance,  Cox says that some XML API's are bad but that someday 
> somebody might write a good one.  The trouble is that it's hard to write 
> a good API for XML -- there's an impeadance mismatch between the vast 

People have written good ones. The MS C# one is particularly clean and an
equivalent is in libxml



From shane at geeklords.org  Mon Nov 21 21:55:57 2005
From: shane at geeklords.org (Shane Stixrud)
Date: Mon, 21 Nov 2005 13:55:57 -0800 (PST)
Subject: init: API
In-Reply-To: <20051121092103.uqlpdun9mosccgwk@imp.rexursive.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132221141.29504.9.camel@gilboa-work-dev>
	<1132234527.9749.120.camel@dimi.lattica.com>
	<1132239325.31499.48.camel@gilboa-work-dev>
	<005401c5eb89$2ceacf00$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<20051118191622.4b9338cb.zaitcev@redhat.com>
	<1132395494.9723.20.camel@rousalka.dyndns.org>
	<1132420661.6042.25.camel@localhost>
	<F1C0C0EE6E90FA82088B6EC8@[10.0.0.14]>
	<1132478901.8015.8.camel@gilboa-work-dev>
	<FDDF6705D9EADA1A404C7A0E@[10.0.0.14]>
	<1132503671.8015.50.camel@gilboa-work-dev>
	<4380A50C.1020308@argo.co.il>
	<20051121092103.uqlpdun9mosccgwk@imp.rexursive.com>
Message-ID: <Pine.LNX.4.62.0511211351130.31724@master.geeklords.org>

On Mon, 21 Nov 2005, Bojan Smojver wrote:

> At present, FHS 2.3 states:
>
> -------------------------
> 3.4. /bin : Essential user command binaries (for use by all users)
>
> 3.4.1. Purpose
> /bin contains commands that may be used by both the system administrator and 
> by users, but which are required when no other filesystems are mounted (e.g. 
> in single user mode). It may also contain commands which are used indirectly 
> by scripts. 1
>
[snip]
> I would appear that system init is one of those things that should rely on 
> "essential" things only (because it is itself in charge of mounting those 
> unmounted file systems). At least IMHO.

If python became required for basic system functionality at boot it should 
be placed in /bin,/lib.  The same would be true when discussing a "more 
friendly" text editor.  In other words getting /usr mounted from init 
isn't the problem, if there is a problem its that certain applications 
live in /usr when they should live in /sbin,/bin,/lib.

Cheers,
Shane



From orion at cora.nwra.com  Mon Nov 21 22:05:55 2005
From: orion at cora.nwra.com (Orion Poplawski)
Date: Mon, 21 Nov 2005 15:05:55 -0700
Subject: Rawhide kickstart install did not exclude packages
Message-ID: <438244C3.5030700@cora.nwra.com>

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

Just did a kickstart install of rawhide and it did not exclude the
packages I had marked with "-name".  Is this a known issue?

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

iD8DBQFDgkTDORnzrtFC2/sRAk3jAJ4qttAv1PdVoSAPZUb6Ioj1wA9T5gCfWiyB
G3VvHaMm3vVSQwSAP6gQWEo=
=vt6j
-----END PGP SIGNATURE-----



From clumens at redhat.com  Mon Nov 21 22:14:37 2005
From: clumens at redhat.com (Chris Lumens)
Date: Mon, 21 Nov 2005 17:14:37 -0500
Subject: Rawhide kickstart install did not exclude packages
In-Reply-To: <438244C3.5030700@cora.nwra.com>
References: <438244C3.5030700@cora.nwra.com>
Message-ID: <20051121221436.GA5832@exeter.boston.redhat.com>

Orion Poplawski wrote:
> Just did a kickstart install of rawhide and it did not exclude the
> packages I had marked with "-name".  Is this a known issue?

Package selection with kickstart is very much up in the air right now.
We haven't even worked on writing out the %packages section in the
generated ks file after installation yet.  We'll get to work on the
kickstart package selection after test 1 is out of the way.

- Chris



From giallu at gmail.com  Mon Nov 21 22:21:25 2005
From: giallu at gmail.com (Gianluca Sforna)
Date: Mon, 21 Nov 2005 23:21:25 +0100
Subject: talking about the new logo
Message-ID: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>

Can you see any difference between the new fedora logo favicon in
fedoraptoject.org <http://fedoraptoject.org> and the one in
fedoranews.org<http://fedoranews.org>?
In my firefox the latter is far more readable: may I suggest to copy it over
the other site?

cheers

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/ee6b8223/attachment.htm>

From jon.nettleton at gmail.com  Mon Nov 21 22:42:09 2005
From: jon.nettleton at gmail.com (Jon Nettleton)
Date: Mon, 21 Nov 2005 17:42:09 -0500
Subject: talking about the new logo
In-Reply-To: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>
Message-ID: <1132612929.29587.2.camel@averatec>

On Mon, 2005-11-21 at 23:21 +0100, Gianluca Sforna wrote:
> Can you see any difference between the new fedora logo favicon in
> fedoraptoject.org and the one in fedoranews.org? In my firefox the
> latter is far more readable: may I suggest to copy it over the other
> site?
> 
> cheers
> 
> Gianluca
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

I agree. The one in fedoranews.org is much clearer and centered better.

Jon



From wrrhdev at riede.org  Mon Nov 21 22:57:09 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Mon, 21 Nov 2005 22:57:09 +0000
Subject: Simple content management systems.
In-Reply-To: <43804923.1010708@redhat.com> (from mharris@redhat.com on Sun
	Nov 20 05:00:03 2005)
References: <437F4E44.4000807@redhat.com>
	<1132455047.3379.5.camel@coyote.rexursive.com>
	<43804923.1010708@redhat.com>
Message-ID: <1132613829l.11959l.15l@serve.riede.org>

On 11/20/2005 05:00:03 AM, Mike A. Harris wrote:
> 
> "Limbo" is a trademark of Lucent Technologies.

Not any more... The rights to Limbo (and Inferno) were sold in 2000 to Vita  
Nuova, see http://www.vitanuova.com/inferno/

Regards, Willem Riede.



From saddateh at gmail.com  Tue Nov 22 00:52:27 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Mon, 21 Nov 2005 19:52:27 -0500
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
Message-ID: <fc33c1550511211652j616c316cv9d441203f68aaf8b@mail.gmail.com>

It was somewhere suggested to use the "ati" driver and this worked for me.
Apparent the "r128" driver is now a sub-module of the ati driver. All
systems are now go again (except for the vesa driver, which I don't need
anymore).

On 11/21/05, Sadda Teh <saddateh at gmail.com> wrote:
>
> Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest
> BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do
> not work properly. When X is configured to use the vesa driver it comes up,
> but the picture is distorted (looks like 2 vertical desktops overlapping one
> another at various points, also colors are messed up). As for trying to use
> the r128 driver, X cannot even load when configured this way, it fails with
> an error along the lines of the r128_drv.so could not be opened. Has anyone
> else seen issues like this with the new modular X packages? Should I file
> bugs for these in x.org <http://x.org>'s bugzilla? Thanks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051121/67a096d1/attachment.htm>

From jeff.pitman at gmail.com  Tue Nov 22 00:54:09 2005
From: jeff.pitman at gmail.com (Jeff Pitman)
Date: Tue, 22 Nov 2005 08:54:09 +0800
Subject: Python incompatibility
In-Reply-To: <pan.2005.11.21.14.09.49.918276@plan99.net>
References: <pan.2005.11.20.17.24.12.868051@plan99.net>
	<e692861c0511201114j524ee164sc84be958ec3660bb@mail.gmail.com>
	<pan.2005.11.20.21.32.21.852959@plan99.net>
	<6b9c17630511201705l34b4b95dibfb7708c83257d11@mail.gmail.com>
	<pan.2005.11.21.14.09.49.918276@plan99.net>
Message-ID: <6b9c17630511211654j4a8fdf2bqa58e658dfd0b7ab1@mail.gmail.com>

On 11/21/05, Mike Hearn <mike at plan99.net> wrote:
>
> > If you want to provide binary extensions,
> > notice that the mx folks provide an RPM for the UCS2 build and one for
> the
> > UCS4 build.
>
> Ouch ... how are users expected to know which they have?
>

If you are creating an uber-RPM that's supposed to work on 50 different
platforms, then the burden is on you to provide two libs that are compiled
against a UCS2 and a UCS4 build of Python. Then you use a highly unmotivated
trick to determine which Python was configured with during the
installation/configure stage (post package install).

--
-jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051122/130e3746/attachment.htm>

From mharris at redhat.com  Tue Nov 22 01:16:29 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Mon, 21 Nov 2005 20:16:29 -0500
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
Message-ID: <4382716D.4040603@redhat.com>

Sadda Teh wrote:
> Hi all, just writing to say that on my Dell Inspiron 8000 laptop (latest 
> BIOS) with ATI Mobility M4 video the modular X vesa and r128 drivers do 
> not work properly. When X is configured to use the vesa driver it comes 
> up, but the picture is distorted (looks like 2 vertical desktops 
> overlapping one another at various points, also colors are messed up). 
> As for trying to use the r128 driver, X cannot even load when configured 
> this way, it fails with an error along the lines of the r128_drv.so 
> could not be opened. Has anyone else seen issues like this with the new 
> modular X packages? Should I file bugs for these in x.org 
> <http://x.org>'s bugzilla? Thanks.

I think that's a known bug in the r128 driver right now, which can
be worked around by using the "ati" driver wrapper (which should work
for all ATI hardware, by sub-loading the appropriate driver (atimisc,
r128, radeon) after detecting what chip you have.

We normally configure each chip to the specific driver for the chip,
rather than using the 'ati' wrapper, as there were problems with the
wrapper a very long time ago.  Please post back to the list if this
works around the problem for you.

Any video driver lockups/corruption/problems or other core X server
glitches, driver problems, etc. generally should be reported directly
to X.Org, for the driver development team to be made aware of them,
which accelerates bug fixes.

http://bugs.freedesktop.org - in the "xorg" component.


Hope this helps!



From mharris at redhat.com  Tue Nov 22 01:21:32 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Mon, 21 Nov 2005 20:21:32 -0500
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511211652j616c316cv9d441203f68aaf8b@mail.gmail.com>
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	<fc33c1550511211652j616c316cv9d441203f68aaf8b@mail.gmail.com>
Message-ID: <4382729C.20905@redhat.com>

Sadda Teh wrote:
> It was somewhere suggested to use the "ati" driver and this worked for 
> me. Apparent the "r128" driver is now a sub-module of the ati driver. 
> All systems are now go again (except for the vesa driver, which I don't 
> need anymore).

The "ati" driver was always the main one.  It's actually just a wrapper,
which detects which chip you have, and then loads either the "atimisc",
"r128", or "radeon" driver, depending on what it detects present.

It's been that way since XFree86 4.0, however we've just always
done the detection in our installer instead, and specified the specific
driver, rather than using the wrapper.  This worked around some bugs
a very long time ago, so we stuck with it.  It's also less codepaths
to go through, which theoretically at least gives less chance for a
bug to pop up.  Now it seems we're seeing the reverse. ;)

Should be fixed in RC3, or maybe sooner if I spot a patch for it.

TTYL



From pekkas at netcore.fi  Tue Nov 22 06:59:05 2005
From: pekkas at netcore.fi (Pekka Savola)
Date: Tue, 22 Nov 2005 08:59:05 +0200 (EET)
Subject: FC4: gcc update to 4.0.2 requires libtool rebuild
Message-ID: <Pine.LNX.4.64.0511220857390.28608@netcore.fi>

Hi,

When updating gcc from 4.0.1 to 4.0.2, someone forgot to recompile 
libtool against gcc-4.0.2, so update fails :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings



From pemboa at gmail.com  Tue Nov 22 08:06:49 2005
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 22 Nov 2005 02:06:49 -0600
Subject: init: API
In-Reply-To: <1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>
Message-ID: <16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>

On 11/19/05, Joe Desbonnet <jdesbonnet at gmail.com> wrote:
>
>
> Guidelines is the key. As far as I can tell there has been no effort
> in the past to try to standardize config file syntax. Of course any
> effort to force a standard on application developers is doomed, ...
>

Out of curiosity, I would very much like to know why Fedora doesn't setup a
polling system to help make such decisions, especially considering that
Fedora is a community project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051122/07500b10/attachment.htm>

From pemboa at gmail.com  Tue Nov 22 08:08:14 2005
From: pemboa at gmail.com (Arthur Pemberton)
Date: Tue, 22 Nov 2005 02:08:14 -0600
Subject: talking about the new logo
In-Reply-To: <1132612929.29587.2.camel@averatec>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>
	<1132612929.29587.2.camel@averatec>
Message-ID: <16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>

Seconded

On 11/21/05, Jon Nettleton <jon.nettleton at gmail.com> wrote:
>
> On Mon, 2005-11-21 at 23:21 +0100, Gianluca Sforna wrote:
> > Can you see any difference between the new fedora logo favicon in
> > fedoraptoject.org <http://fedoraptoject.org> and the one in
> fedoranews.org <http://fedoranews.org>? In my firefox the
> > latter is far more readable: may I suggest to copy it over the other
> > site?
> >
> > cheers
> >
> > Gianluca
> > --
> > fedora-devel-list mailing list
> > fedora-devel-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
> I agree. The one in fedoranews.org <http://fedoranews.org> is much clearer
> and centered better.
>
> Jon
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051122/26a2ae0b/attachment.htm>

From sundaram at redhat.com  Tue Nov 22 08:14:36 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 22 Nov 2005 13:44:36 +0530
Subject: talking about the new logo
In-Reply-To: <16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>	<1132612929.29587.2.camel@averatec>
	<16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
Message-ID: <4382D36C.9010408@redhat.com>


>
> On 11/21/05, *Jon Nettleton* <jon.nettleton at gmail.com 
> <mailto:jon.nettleton at gmail.com>> wrote:
>
>     On Mon, 2005-11-21 at 23:21 +0100, Gianluca Sforna wrote:
>     > Can you see any difference between the new fedora logo favicon in
>     > fedoraptoject.org <http://fedoraptoject.org> and the one in
>     fedoranews.org <http://fedoranews.org>? In my firefox the
>     > latter is far more readable: may I suggest to copy it over the other
>     > site?
>
File a bug report against the website in http://bugzilla.redhat.com

regards
Rahul



From sundaram at redhat.com  Tue Nov 22 08:23:55 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Tue, 22 Nov 2005 13:53:55 +0530
Subject: init: API
In-Reply-To: <16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<1132375768.9736.58.camel@gilboa-home-dev.localhost>	<1132395384.9723.17.camel@rousalka.dyndns.org>	<1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>
	<16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>
Message-ID: <4382D59B.9010107@redhat.com>

Hi

>
> Out of curiosity, I would very much like to know why Fedora doesn't 
> setup a polling system to help make such decisions, especially 
> considering that Fedora is a community project.

Because developers dont usually implement features by voting.

regards
Rahul



From giallu at gmail.com  Tue Nov 22 08:56:54 2005
From: giallu at gmail.com (Gianluca Sforna)
Date: Tue, 22 Nov 2005 09:56:54 +0100
Subject: talking about the new logo
In-Reply-To: <4382D36C.9010408@redhat.com>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>
	<1132612929.29587.2.camel@averatec>
	<16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
	<4382D36C.9010408@redhat.com>
Message-ID: <d5ad21470511220056w33752f74y1e11baa63a7e6fb1@mail.gmail.com>

On 11/22/05, Rahul Sundaram <sundaram at redhat.com> wrote:
>
> >
> > On 11/21/05, *Jon Nettleton* <jon.nettleton at gmail.com
> > <mailto:jon.nettleton at gmail.com>> wrote:
> >
> >     On Mon, 2005-11-21 at 23:21 +0100, Gianluca Sforna wrote:
> >     > Can you see any difference between the new fedora logo favicon in
> >     > fedoraptoject.org <http://fedoraptoject.org> and the one in
> >     fedoranews.org <http://fedoranews.org>? In my firefox the
> >     > latter is far more readable: may I suggest to copy it over the
> other
> >     > site?
> >
> File a bug report against the website in http://bugzilla.redhat.com



https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173889
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051122/a86f4a2d/attachment.htm>

From buildsys at redhat.com  Tue Nov 22 14:40:57 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 22 Nov 2005 09:40:57 -0500
Subject: rawhide report: 20051122 changes
Message-ID: <200511221440.jAMEev05018803@porkchop.devel.redhat.com>

New package xorg-x11-filesystem
	X.Org X11 filesystem layout


Removed package libibverbs

Updated Packages:

a2ps-4.13b-48
-------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 4.13b-48
- Migrate font paths from /usr/X11R6 to /usr/share/X11

anaconda-10.90.8-1
------------------
* Mon Nov 21 2005 Jeremy Katz <katzj at redhat.com> - 10.90.8-1
- don't load pcspkr on ppc to avoid crashes on the g5

* Sun Nov 20 2005 Jeremy Katz <katzj at redhat.com> - 10.90.7-1
- fix backwards whiteout handling (#173738)
- fix bug in depsolver which would bring in a package for an already 
  satisfied dep

* Sat Nov 19 2005 Jeremy Katz <katzj at redhat.com> - 10.90.6-1
- fix removal of packages to not traceback
- fix anaconda.dmraid logging (clumens)

dhcp-11:3.0.3-14
----------------
* Sat Nov 19 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-12
- fix bug 173619: dhclient-script should reconfig on RENEW if 
                  subnet-mask, broadcast-address, mtu, routers, etc.
		  have changed
- apply upstream improvements to trailing nul options fix of bug 160655

gnome-print-1:0.37-12
---------------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 1:0.37-11
- Fix references to obsolete /usr/X11R6 font paths

ncurses-5.4-20
--------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 5.4-20
- fix location for resize in ncurses-resetall.sh

rhpxl-0.7-1
-----------
* Mon Nov 21 2005 Bill Nottingham <notting at redhat.com> - 0.7-1
- fix rhpl.arch.getBaseArch() vs rhpl.getArch() confusion

udev-075-4
----------
* Mon Nov 21 2005 Harald Hoyer <harald at redhat.com> - 075-4
- speedup udev event replay with udevstart2

* Fri Nov 18 2005 Harald Hoyer <harald at redhat.com> - 075-3
- refined start_udev for old kernels

xorg-x11-xbitmaps-0.99.1-3
--------------------------
* Mon Nov 21 2005 Mike A. Harris <mharris at redhat.com> 0.99.1-3
- Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-1" to attempt to
  workaround bug( #173384).



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.10-1.s390x requires dmraid



From wtogami at redhat.com  Tue Nov 22 15:34:21 2005
From: wtogami at redhat.com (Warren Togami)
Date: Tue, 22 Nov 2005 10:34:21 -0500
Subject: OFF-TOPIC Re: talking about the new logo
In-Reply-To: <16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>	<1132612929.29587.2.camel@averatec>
	<16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
Message-ID: <43833A7D.6090303@redhat.com>

Arthur Pemberton wrote:
> Seconded
> 
> On 11/21/05, *Jon Nettleton* <jon.nettleton at gmail.com 
> <mailto:jon.nettleton at gmail.com>> wrote:
> 
>     On Mon, 2005-11-21 at 23:21 +0100, Gianluca Sforna wrote:
>      > Can you see any difference between the new fedora logo favicon in
>      > fedoraptoject.org <http://fedoraptoject.org> and the one in
>     fedoranews.org <http://fedoranews.org>? In my firefox the
>      > latter is far more readable: may I suggest to copy it over the other
>      > site?
>      >
>      > cheers
>      >
>      > Gianluca
>      > --
>      > fedora-devel-list mailing list
>      > fedora-devel-list at redhat.com <mailto:fedora-devel-list at redhat.com>
>      > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>     <https://www.redhat.com/mailman/listinfo/fedora-devel-list>
> 
>     I agree. The one in fedoranews.org <http://fedoranews.org> is much
>     clearer and centered better.
> 
>     Jon

While I personally am not happy with the chosen Fedora Logo (and 
especially the process used to chose the logo), it is off-topic to 
discuss this on fedora-devel-list.  Please take it elsewhere.

Warren Togami
wtogami at redhat.com



From avi at argo.co.il  Tue Nov 22 16:23:21 2005
From: avi at argo.co.il (Avi Kivity)
Date: Tue, 22 Nov 2005 18:23:21 +0200
Subject: OFF-TOPIC Re: talking about the new logo
In-Reply-To: <43833A7D.6090303@redhat.com>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>	<1132612929.29587.2.camel@averatec>	<16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>
	<43833A7D.6090303@redhat.com>
Message-ID: <438345F9.8080200@argo.co.il>

Warren Togami wrote:

>
> While I personally am not happy with the chosen Fedora Logo (and 
> especially the process used to chose the logo), it is off-topic to 
> discuss this on fedora-devel-list.  Please take it elsewhere.
>
It seems that the only on-topic messages on this list are those telling 
people off for posting off-topic.



From michael.favia at insitesinc.com  Tue Nov 22 18:05:35 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 22 Nov 2005 12:05:35 -0600
Subject: OFF-TOPIC Re: talking about the new logo
In-Reply-To: <438345F9.8080200@argo.co.il>
References: <d5ad21470511211421j1153d1fbo45ac17114f4127a0@mail.gmail.com>	<1132612929.29587.2.camel@averatec>	<16de708d0511220008x1f682deu396d3785d8a509c@mail.gmail.com>	<43833A7D.6090303@redhat.com>
	<438345F9.8080200@argo.co.il>
Message-ID: <43835DEF.1000806@insitesinc.com>

Avi Kivity wrote:
> Warren Togami wrote:
> 
>>
>> While I personally am not happy with the chosen Fedora Logo (and 
>> especially the process used to chose the logo), it is off-topic to 
>> discuss this on fedora-devel-list.  Please take it elsewhere.
>>
> It seems that the only on-topic messages on this list are those telling 
> people off for posting off-topic.

Any development related issues are welcome and addressed quickly. By 
keeping the background noise down people can actually plan on reading 
most of the threads knowing they pertain to the right topic. Fedora logo 
favicons and design sounds like a fedora-marketing-list or 
fedora-websites-list issue to me. -mf



From wrrhdev at riede.org  Tue Nov 22 21:25:23 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Tue, 22 Nov 2005 21:25:23 +0000
Subject: Broken video drivers in new modular X
In-Reply-To: <fc33c1550511211016w4ad1ff78xa33a4eb97a0caf58@mail.gmail.com>
	(from saddateh@gmail.com on Mon Nov 21 13:16:57 2005)
References: <fc33c1550511202344i592decddp4304b3fb2aa1d35b@mail.gmail.com>
	<1132573358l.11959l.14l@serve.riede.org>
	<fc33c1550511211016w4ad1ff78xa33a4eb97a0caf58@mail.gmail.com>
Message-ID: <1132694723l.11959l.17l@serve.riede.org>

On 11/21/2005 01:16:57 PM, Sadda Teh wrote:
> Willem, the screenshot (https://bugs.freedesktop.org/attachment.cgi?id=3851)
> you posted in x.org <http://x.org>'s bugzilla is pretty much exactly what
> I'm seeing on my Inspiron 8000 when I use the vesa driver.

Then it would be good if you added your experience to the bug report, so the  
maintainer understands it is not just one isolated case of trouble.

Thanks, Willem Riede.



From irabinovitch at gmail.com  Wed Nov 23 08:14:57 2005
From: irabinovitch at gmail.com (Ilan Rabinovitch)
Date: Wed, 23 Nov 2005 05:14:57 -0300
Subject: OT: SCALE 4x -- Call For Papers
In-Reply-To: <b1e0ba17050901155217d2719c@mail.gmail.com>
References: <b1e0ba17050901155217d2719c@mail.gmail.com>
Message-ID: <b1e0ba170511230014t7257f1b5qd88334ef3f347e15@mail.gmail.com>

Hello,

The deadline for submitions, to the SCALE 4x Call For Papers, has been
extended through Dec 3rd.  If you are interested in presenting there
is still time to get your proposals in.

Regards,
Ilan

On 9/1/05, Ilan Rabinovitch <irabinovitch at gmail.com> wrote:
> Hello,
>
> The call for papers for SCALE 4x, the 2006 Southern California Linux
> Expo, is now open.  This event will be our fourth annual show.  It
> will be held on Feb 11-12, 2006 at the Los Angeles Airport Westin. We
> are expecting 1,300+ in attendance this year.  We are non-profit,
> community run Linux, open-source and free software conference.
>
> If you are working on something you believe the community
> would be interested in, please consider submitting a presentation to
> our call for papers.  I am including details bellow.
>
> Past presentations are available online (including slides audio in most cases):
> 2005 - http://www.socallinuxexpo.org/past/2005/hours.php
> 2003 - http://www.socallinuxexpo.org/past/2003/presentations.php
> 2002 - http://www.socallinuxexpo.org/past/2002/presentations.php
>
> If you have any questions please feel free to call the Call For Papers
> team at cfp @  socallinuxexp.org
>
> CFP Link: http://www.socallinuxexpo.org/pr/pr_20050620.php
> CFP PDF:  http://www.socallinuxexpo.org/pr/cfp4x.pdf
>
> Best regards,
> Ilan Rabinovitch
> Conference Chair
> Southern California Linux Expo
> http://www.socallinuxexpo.org
>
>
>
> 2006 Southern CAlifornia Linux Expo
>
> The USC, Simi/Conejo, and UCLA Linux User Groups are proud to announce
> the 4th annual Southern California Linux Expo scheduled for February
> 11-12, 2006 at the Westin Hotel near the Los Angeles International
> Airport. Building on the tremendous success of last three years' SCALE,
> we will continue to promote Linux and the Open Source Software
> community.
>
> We invite you to share your work on Linux and Open Source projects with
> the rest of the community as well as exchange ideas with some of the
> leading experts in these field. Details about SCALE 4X as well as
> archives for the last three years can be found at
> http://www.socallinuxexpo.com.
>
> Topics of interest include, but are not limited to:
>
> * Linux kernel
> * Linux Networking
> * Linux for embedded systems
> * Linux for Desktops
> * LAMP
> * Multimedia in Linux
> * Security in Linux
> * VoIP
> * Wireless tools in Linux
> * Linux Games
> * GIMP & other graphics software
> * Administration techniques for specific distributions
> * Custom Configurations
> * Linux Deployments and experiences: Case studies
> * Open source Licensing
> * Government policies with Open Source
> * Other open source projects
>
> The proposals should comprise a 1-page (maximum) description containing
> the following:
>
> 1] Title for the talk.
> 2] Name, Affiliation, Bio, a passport size picture (optional) and
> contact email address of the Presenter.
> 3] What will be covered? A bulleted list of the main points of the
> presentation will be ideal. Please include enough detail as will be
> necessary.
> 4] Any specific requirements needed for the presentation other than an
> overhead projector and a microphone.
>
> Presentations are alloted a time slot of about 45 minutes. All proposals
> are to be sent to kapadia=at=socallinuxexpo.com.
>
> Important Dates:
>
> 20 Jun, 2005: CFP Opens
> 20 Nov, 2005: Last date for abstracts/proposals
> 20 Dec, 2005: Last date for notification of acceptance
> 11 Feb, 2006: Conference starts
>



From mharris at redhat.com  Wed Nov 23 12:51:44 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 23 Nov 2005 07:51:44 -0500
Subject: init: API
In-Reply-To: <16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>	<1132248513.8647.16.camel@gilboa-work-dev>	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>	<1132266025.9736.3.camel@gilboa-home-dev.localhost>	<1132332369.4597.27.camel@ns1.htpassport.ro>	<1132369081.9736.46.camel@gilboa-home-dev.localhost>	<20051119030635.GA25132@devserv.devel.redhat.com>	<1132375768.9736.58.camel@gilboa-home-dev.localhost>	<1132395384.9723.17.camel@rousalka.dyndns.org>	<1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>
	<16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>
Message-ID: <438465E0.1070908@redhat.com>

Arthur Pemberton wrote:

>     Guidelines is the key. As far as I can tell there has been no effort
>     in the past to try to standardize config file syntax. Of course any
>     effort to force a standard on application developers is doomed, ...
> 
> 
> Out of curiosity, I would very much like to know why Fedora doesn't 
> setup a polling system to help make such decisions, especially 
> considering that Fedora is a community project.

First a list of people nominated to be "voters" would have to be
created.  Then, a list of people who are unarguably renowned for
their well reasoned sound technical judgement, leadership, and
decision making skills.  The latter group would vote on which of
the nominees in the former group they consider to also have
"sound technical judgement and good decision making skills".

After the round of voting completes, the people who are considered
unanimously to have sound decision making skills, etc. would then
theoretically be eligible to vote on future technical decisions
for the OS based on the technical merits of the issues at hand, and
the goals and objectives of the Fedora project as a whole.

That would be the basic foundation required to have a useful system
of "voting" on things.

Oh wait, I forgot, such decision making is already made by people
with sound technical judgement, leadership and decision making
skills, only without all of the voting nonesense.  ;oP



From chabotc at xs4all.nl  Wed Nov 23 13:02:47 2005
From: chabotc at xs4all.nl (Chris Chabot)
Date: Wed, 23 Nov 2005 14:02:47 +0100
Subject: init: API
In-Reply-To: <438465E0.1070908@redhat.com>
References: <043301c5eacf$dbba0ba0$b6491b31@td612671>
	<1132248513.8647.16.camel@gilboa-work-dev>
	<1cef3e950511171118x71be3d42saa599d897910c052@mail.gmail.com>
	<1132266025.9736.3.camel@gilboa-home-dev.localhost>
	<1132332369.4597.27.camel@ns1.htpassport.ro>
	<1132369081.9736.46.camel@gilboa-home-dev.localhost>
	<20051119030635.GA25132@devserv.devel.redhat.com>
	<1132375768.9736.58.camel@gilboa-home-dev.localhost>
	<1132395384.9723.17.camel@rousalka.dyndns.org>
	<1cef3e950511190251o3d027ac6v796a1d45e74aa3ca@mail.gmail.com>
	<16de708d0511220006w1a24f2b5qe4bcbdcc28a599ce@mail.gmail.com>
	<438465E0.1070908@redhat.com>
Message-ID: <1132750967.8610.16.camel@cch>

Besides Opensource is very much based on the old system of "Don't talk,
code".

If you believe you have a superior way of doing things, code it, release
it to the public (release early, release often.. all very bazar vs
cathedral right? :-)) and if its any good and more people agree its a
right solution, it will be adopted mainstream. That's a "community" way
of doing things

Not telling redhat how to spend their man hours that they pay for .. We
can only try to give a general feedback 

In other words, if you'd really like to see something in fedora, code
it, and they will come! :-)

On Wed, 2005-11-23 at 07:51 -0500, Mike A. Harris wrote:

> Arthur Pemberton wrote:
> 
> >     Guidelines is the key. As far as I can tell there has been no effort
> >     in the past to try to standardize config file syntax. Of course any
> >     effort to force a standard on application developers is doomed, ...
> > 
> > 
> > Out of curiosity, I would very much like to know why Fedora doesn't 
> > setup a polling system to help make such decisions, especially 
> > considering that Fedora is a community project.
> 
> First a list of people nominated to be "voters" would have to be
> created.  Then, a list of people who are unarguably renowned for
> their well reasoned sound technical judgement, leadership, and
> decision making skills.  The latter group would vote on which of
> the nominees in the former group they consider to also have
> "sound technical judgement and good decision making skills".
> 
> After the round of voting completes, the people who are considered
> unanimously to have sound decision making skills, etc. would then
> theoretically be eligible to vote on future technical decisions
> for the OS based on the technical merits of the issues at hand, and
> the goals and objectives of the Fedora project as a whole.
> 
> That would be the basic foundation required to have a useful system
> of "voting" on things.
> 
> Oh wait, I forgot, such decision making is already made by people
> with sound technical judgement, leadership and decision making
> skills, only without all of the voting nonesense.  ;oP
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051123/48f80a8d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smiley-3.png
Type: image/png
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051123/48f80a8d/attachment.png>

From buildsys at redhat.com  Wed Nov 23 15:02:44 2005
From: buildsys at redhat.com (Build System)
Date: Wed, 23 Nov 2005 10:02:44 -0500
Subject: rawhide report: 20051123 changes
Message-ID: <200511231502.jANF2ikZ015779@porkchop.devel.redhat.com>

New package libibverbs
	A library for direct userspace use of InfiniBand

New package libmthca
	Mellanox InfiniBand HCA Userspace Driver

New package libsdp
	A library for direct userspace use of Sockets Direct Protocol

New package opensm
	OpenIB InfiniBand Subnet Manager and management utilities


Removed package selinux-policy-targeted

Removed package selinux-policy-strict

Removed package selinux-policy-mls

Updated Packages:

avahi-0.6-2
-----------
* Mon Nov 21 2005 Jason Vas Dias<jvdias at redhat.com> - 0.6-1
- Upgrade to upstream version 0.6 - now provides 'avahi-howl-compat'
  libraries / includes.

bash-3.0-37
-----------
* Tue Nov 22 2005 Tim Waugh <twaugh at redhat.com>  3.0-37
- Applied patch from upstream to fix parsing problem (bug #146638).

bc-1.06-19
----------
* Mon Nov 21 2005 Thomas Woerner <twoerner at redhat.com> 1.06-19
- fixed rpm macro usage in chengelog (#137800)

* Wed Jan 12 2005 Tim Waugh <twaugh at redhat.com> 1.06-18
- Rebuilt for new readline.

* Fri Oct 08 2004 Thomas Woerner <twoerner at redhat.com> 1.06-17.1
- added BuildRequires for readline-devel (#134699)

dasher-3.2.18-2
---------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com>
- fix references to /usr/X11R6

dhcp-11:3.0.3-12
----------------
* Sat Nov 19 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-12
- fix bug 173619: dhclient-script should reconfig on RENEW if 
                  subnet-mask, broadcast-address, mtu, routers, etc.
		  have changed
- apply upstream improvements to trailing nul options fix of bug 160655

* Tue Nov 15 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-11
- Rebuild for FC-5
- fix bug 167028 - test IBM's unicast bootp patch (from xma at us.ibm.com)
- fix bug 171312 - silence chkconfig error message if ypbind not installed
- fix dhcpd.init when -cf arg given to dhcpd
- make dhcpd init touch /var/lib/dhcpd/dhcpd.leases, not /var/lib/dhcp/dhcpd.leases

* Tue Oct 18 2005 Jason Vas Dias <jvdias at redhat.com> - 11:3.0.3-10
- Allow dhclient route metrics to be specified with DHCP options:
  The dhcp-options(5) man-page states:
  'option routers ... Routers should be listed in order of preference' 
  and
  'option static-routes ... are listed in descending order of priority' .
  No preference / priority could be set with previous dhclient-script .
  Now, dhclient-script provides: 
  Default Gateway (option 'routers') metrics:
    Instead of allowing only one default gateway, if more than one router 
    is specified in the routers option, routers following the first router
    will have a 'metric' of their position in the list (1,...N>1).
  Option static-routes metrics:
    If a target appears in the list more than once, routes for duplicate
    targets will have successively greater metrics, starting at 1.

doxygen-1:1.4.5-2
-----------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com>
- fix references to /usr/X11R6

fontconfig-2.3.92.cvs20051119-1
-------------------------------
* Sat Nov 19 2005 Matthias Clasen <mclasen at redhat.com> - 2.3.92.cvs20051119-1
- Update to a newer cvs snapshot

freeglut-2.4.0-2
----------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 2.4.0-2
- Remove references to obsolete /usr/X11R6 paths

gkrellm-2.2.7-5
---------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 2.2.7-5
- Fix references to obsolete /usr/X11R6 path

glib-1:1.2.10-18
----------------
* Mon Nov 21 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-18
- Make sure all libraries are stripped

* Mon Nov 07 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-17
- Remove .la files and static libs from the -devel package.

* Wed Mar 02 2005 Matthias Clasen <mclasen at redhat.com> 1:1.2.10-16
- Rebuild with gcc4

gnome-media-2.12.0-2
--------------------
* Tue Nov 22 2005 Matthias Clasen <mclasen at redhat.com> - 2.12.0-2
- Classify volume control as setting, for better menus

gnome-screensaver-0.0.20-1
--------------------------
* Mon Nov 21 2005 Ray Strode <rstrode at redhat.com> 0.0.20-1
- upgrade to 0.0.20

gnome-system-monitor-2.12.1-2
-----------------------------
* Tue Nov 22 2005 Matthias Clasen <mclasen at redhat.com> 2.12.1-2
- Classify gnome-system-monitor as a monitor for better menus

gnome-user-share-0.9-1
----------------------
* Tue Nov 22 2005 Alexander Larsson <alexl at redhat.com> - 0.9-1
- New release with avahi 0.6 support

gnome-utils-1:2.13.1-3
----------------------
* Tue Nov 22 2005 Matthias Clasen <mclasen at redhat.com>
- classify gnome-system-log as Monitor for better menus

gnome-vfs2-2.12.1.1-6
---------------------
* Tue Nov 22 2005 Alexander Larsson <alexl at redhat.com> - 2.12.1.1-6
- Update to use avahi 0.6

gok-1.0.5-6
-----------
* Mon Nov 21 2005 Matthias Clasen <mclasen at redhat.com>
- don't crash when getting unexpected values from gconf

* Mon Nov 21 2005 Matthias Clasen <mclasen at redhat.com>
- fix memory handling errors

* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com>
- with modular X in /usr/lib64, libdir patch isn't needed - remove it

gtk+-1:1.2.10-49
----------------
* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com> 1:1.2.10-49
- Remove references to obsolete X11R6 paths

hplip-0.9.6-7
-------------
* Fri Nov 18 2005 Tim Waugh <twaugh at redhat.com> 0.9.6-7
- Fix compilation.

hwbrowser-0.24-1
----------------
* Tue Nov 22 2005 Matthias Clasen <mclasen at redhat.com> 0.24
- Remove "Browser" from name, classify as monitor for
  better menus

iptables-1.3.4-1
----------------
* Fri Nov 18 2005 Thomas Woerner <twoerner at redhat.com> 1.3.4-1
- new version 1.3.4
- dropped free_opts patch (upstream fixed)
- made libipq PIC (#158623)
- additional configuration options for iptables startup script (#172929)
  Thanks to Jan Gruenwald for the patch
- spec file cleanup (dropped linux_header define and usage)

kernel-2.6.14-1.1707_FC5
------------------------
* Tue Nov 22 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git2
- Add a 'nowprodata' to disable rodata protection during debug.
- Fix NFSD badness warning.
- Enable SATA ATAPI by default.

* Mon Nov 21 2005 David Woodhouse <dwmw2 at redhat.com>
- No pcskpr on ppc64
- Fix IBM Cell sim console output

* Mon Nov 21 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git1
- Shrink the 586 kernel by removing some unnecessary modules.

libX11-0.99.3-4
---------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.3-4
- Added libX11-0.99.3-datadir-locale-dir-fix.patch, to fix build to install
  the locale data files into datadir instead of libdir.

libfontenc-0.99.2-2
-------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-2
- Added libfontenc-0.99.2-use-datadir-for-encodings.patch and invoke aclocal
  and automake to activate the changes.  This fixes a bug reported against
  mkfontscale, in which it looks in _datadir for the font encodings files,
  which was traced back to libfontenc (#173875).
- Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-2" to ensure that
  /usr/include/X11 is a directory rather than a symlink before this package
  gets installed, to avoid bug (#173384).

libselinux-1.27.22-3
--------------------
* Thu Nov 17 2005 Dan Walsh <dwalsh at redhat.com> 1.27.22-3
- Readd libsetrans requirement

* Thu Nov 17 2005 Dan Walsh <dwalsh at redhat.com> 1.27.22-2
- Add python bindings

libwmf-0.2.8.4-2
----------------
* Wed Nov 23 2005 Caolan McNamara <caolanm at redhat.com> 0.2.8.4-2
- rh#173299# modify pre/post requires

libxklavier-2.0-3
-----------------
* Mon Nov 21 2005 Ray Strode <rstrode at redhat.com> 2.0-3
- Don't hard code the xkb data prefix.

lslk-1.29-16
------------
* Mon Nov 21 2005 Karel Zak <kzak at redhat.com> 1.29-16
- rebuilt

metacity-2.13.2-1
-----------------
* Mon Nov 21 2005 Ray Strode <rstrode at redhat.com> 2.13.2-1
- Update to 2.13.2

* Fri Nov 18 2005 Bill Nottingham <notting at redhat.com>
- remove references to obsolete X11R6 paths

mkinitrd-5.0.11-1
-----------------
* Mon Nov 21 2005 Peter Jones <pjones at redhat.com> - 5.0.11-1
- audit for open()s without appropriate closes()
- make new functions coeOpen(), coeFopen(), and coeOpendir().  These behave
  like open(), fopen(), and opendir() except that they set any associated
  file descriptors to close on exec().
- use them everywhere except where we open a console.

nc-1.84-1
---------
* Fri Nov 18 2005 Radek Vokal <rvokal at redhat.com> 1.84-1
- follow upstream

* Fri Oct 21 2005 Radek Vokal <rvokal at redhat.com> 1.82-2
- use SO_REUSEADDR (#171315)

* Tue Sep 27 2005 Tomas Mraz <tmraz at redhat.com> 1.82-1
- update from OpenBSD upstream CVS
- fix pollhup patch so it reads everything before shutdown

net-snmp-5.2.2-0.rc6.1
----------------------
* Mon Nov 21 2005 Radek Vokal <rvokal at redhat.com> - 5.2.2-0.rc6.1
- update to rc6, snmpnetstat changes due to license problems
- persistent files in directory defined by snmp.conf persistentDir are 
  loaded at startup

nss_ldap-244-2
--------------
* Mon Nov 21 2005 Nalin Dahyabhai <nalin at redhat.com> 244-2
- rebuild with new libldap and friends (#173794)

openldap-2.3.11-3
-----------------
* Mon Nov 21 2005 Jay Fenlason <fenlason at redhat.com> 2.3.11-3
- Remove Requires: cyrus-sasl and cyrus-sasl-md5 from openldap- and
  compat-openldap- to close
  bz#173313 Remove exlicit 'Requires: cyrus-sasl" + 'Requires: cyrus-sasl-md5'

openoffice.org-1:2.0.1-0.141.1.2
--------------------------------
* Thu Nov 17 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.141.1
- next version
- hi-IN translations upstreamed
- loads of translated help

* Tue Nov 15 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.140.1
- drop integrated workspace.oooemailmerge.patch
- drop integrated workspace.javapatch.patch
- drop integrated workspace.systemlibxmlfix.patch

openssh-4.2p1-9
---------------
* Tue Nov 22 2005 Tomas Mraz <tmraz at redhat.com> - 4.2p1-9
- drop x11-ssh-askpass from the package
- drop old build_6x ifs from spec file
- improve gnome-ssh-askpass so it doesn't reveal number of passphrase 
  characters to person looking at the display
- less hackish fix for the __USE_GNU problem

openssl-0.9.8a-3
----------------
* Tue Nov 22 2005 Tomas Mraz <tmraz at redhat.com> 0.9.8a-3
- disable builtin compression methods for now until they work
  properly (#173399)

* Wed Nov 16 2005 Tomas Mraz <tmraz at redhat.com> 0.9.8a-2
- don't set -rpath for openssl binary

openswan-2.4.4-1.1
------------------
* Fri Nov 18 2005 Harald Hoyer <harald at redhat.com> - 2.4.4-1.1
- version 2.4.4
- fixes NISCC Vulnerability Advisory 273756/NISCC/ISAKMP
- fixes NISCC Advisory 3756/NISCC/ISAKMP

pam_krb5-2.2.2-1
----------------
* Mon Nov 21 2005 Nalin Dahyabhai <nalin at redhat.com> - 2.2.2-1
- don't leak the keytab descriptor during validation (#173681)

policycoreutils-1.27.28-3
-------------------------
* Thu Nov 17 2005 Dan Walsh <dwalsh at redhat.com> 1.27.28-3
- Audit2allow
	* Add more error checking
	* Add gen policy package
	* Add gen requires

python-2.4.2-2
--------------
* Sat Nov 19 2005 Bill Nottingham <notting at redhat.com> 2.4.2-2
- fix build for modular X, remove X11R6 path references

* Tue Nov 15 2005 Mihai Ibanescu <misa at redhat.com> 2.4.2-1
- Upgraded to 2.4.2
- BuildRequires autoconf

* Wed Nov 09 2005 Mihai Ibanescu <misa at redhat.com> 2.4.1-16
- Rebuilding against newer openssl.
- XFree86-devel no longer exists

redhat-menus-5.0.7-1
--------------------
* Tue Nov 22 2005 Matthias Clasen <mclasen at redhat.com> 5.0.7-1
- Clean up menus

rhdb-utils-8.1.1-1
------------------
* Mon Nov 21 2005 Tom Lane <tgl at redhat.com> 8.1.1-1
- Update pg_filedump to version 8.1.1, to fix a couple of oversights.
- Simplify specfile a bit.

* Mon Nov 21 2005 Tom Lane <tgl at redhat.com> 8.1-1
- Update pg_filedump to version 8.1, to support PostgreSQL 8.1.
- Change version numbering so that major version matches corresponding
  PostgreSQL version.

sane-frontends-1.0.14-1
-----------------------
* Mon Nov 21 2005 Nils Philippsen <nphilipp at redhat.com> 1.0.14-1
- version 1.0.14
- fix build requires
- update badcode patch

selinux-policy-2.0.4-1
----------------------
* Fri Nov 21 2003 Dan Walsh <dwalsh at redhat.com> 2.0.4-1
- Add rules for pegasus and avahi

* Fri Nov 21 2003 Dan Walsh <dwalsh at redhat.com> 2.0.2-2
- Start building MLS Policy

* Tue Nov 18 2003 Dan Walsh <dwalsh at redhat.com> 2.0.2-1
- Update to upstream

slang-2.0.5-4
-------------
* Mon Nov 21 2005 Petr Raszyk <praszyk at redhat.com> - 2.0.5-3
- Rebuild.

* Mon Nov 21 2005 Petr Raszyk <praszyk at redhat.com> - 2.0.5-1
- Upgrade to slang 20005.
- (#161536). slang-nointerlibc2.patch
- slang-makefile.patch

system-config-date-1.7.99.6-1
-----------------------------
* Mon Nov 21 2005 Nils Philippsen <nphilipp at redhat.com>
- fix zooming problems with enlarged window (#172982)
- apply workaround by Alex Larsson to avoid hanging when clicking on Asia
  region (#172977)
- add Middle America region, make Antarctica regions overlapping

tetex-3.0-10
------------
* Mon Nov 21 2005 Jindrich Novy <jnovy at redhat.com> 3.0-10
- update dependencies for modular X
- use @texmf at -var, @texmf at -config trees

traceroute-2:1.0.3-5
--------------------
* Mon Nov 21 2005 Radek Vokal <rvokal at redhat.com> 1.0.3-5
- removed ICMP6_DST_UNREACH_NOTNEIGHBOR (#173762)

unixODBC-2.2.11-6
-----------------
* Mon Nov 21 2005 Tom Lane <tgl at redhat.com> 2.2.11-6
- Patch NO-vs-no discrepancy between aclocal/acinclude and recent autoconf
  versions (not sure if this has been broken for a long time, or was just
  exposed by modular X changeover).
- Apparently need to require libXt-devel too for modular X.

words-3.0-8
-----------
* Mon Nov 21 2005 Karel Zak <kzak at redhat.com> 3-8
- rebuilt

xorg-x11-drv-mouse-1.0.1-2
--------------------------
* Mon Nov 21 2005 Mike A. Harris <mharris at redhat.com> 1.0.1-2
- Added "alpha sparc sparc64" to ExclusiveArch for AlphaCore, CentOS,
  AuroraLinux distributions, to minimize patching for them.
- Added ">= 0.99.3" dependency on Xorg server and sdk, based on CVS log
  message from Daniel Stone on Nov 21, 2005.
xorg-x11-font-utils-1:0.99.1-1
------------------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 1:0.99.1-1
- Changed package version to 0.99.1 to match the upstream font-util tarball
  version, and added "Epoch: 1" to the package for upgrades.
- Added font-util-0.99.1-mapdir-use-datadir-fix.patch to fix the font-util
  mapfiles data to install into datadir instead of libdir (#173943)
- Added "Requires(pre): libfontenc >= 0.99.2-2" to force a version of
  libfontenc to be installed that fixes bug #173453, and to also force it
  to be installed before xorg-x11-font-utils in a multi-package rpm
  transaction, which will ensure that when font packages get installed
  during upgrades via anaconda or yum, that the right libfontenc is being
  used by mkfontscale/mkfontdir.
- Added ">= 0.99.2-2" to BuildRequires for libfontenc, as a convenience to
  people rebuilding xorg-x11-font-utils, as they'll need to install the new
  libfontenc now anyway before they can install the font-utils package.

xorg-x11-proto-devel-0.99.2-3
-----------------------------
* Mon Nov 21 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-3
- Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-1" to attempt to
  workaround bug( #173384).

xorg-x11-xinit-0.99.3-6
-----------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.3-6
- Add "Requires: xauth" for startx, to fix bug (#173684)

* Mon Nov 14 2005 Jeremy Katz <katzj at redhat.com> 0.99.3-5
- Do not provide xinit anymore, gdm has been fixed and that breaks things
  with the obsoletes

* Sat Nov 12 2005 Mike A. Harris <mharris at redhat.com> 0.99.3-4
- Added Xsession script from xinitrc, as it is very similar codebase, which
  shares "xinitrc-common" anyway, and all of the display managers use it.

xterm-207-6
-----------
* Mon Nov 21 2005 Jason Vas Dias<jvdias at redhat.com> - 207-5
- fix bug 173703: remove reference to /usr/X11R6/bin/luit :
  PROJECTROOT should be /usr, not /usr/X11R6

* Fri Nov 18 2005 Jason Vas Dias<jvdias at redhat.com> - 207-4
- fix bug 173541: better fix for freetype configuration problem

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	crypto-utils - 2.2-8.i386 requires libslang-utf8.so.1
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	newt - 0.52.1-0.i386 requires libslang-utf8.so.1
	slrn - 0.9.8.1-7.i386 requires libslang-utf8.so.1
	slrn-pull - 0.9.8.1-7.i386 requires libslang-utf8.so.1
	system-config-securitylevel-tui - 1.6.9-1.i386 requires libslang-utf8.so.1
	timidity++ - 2.13.2-1.i386 requires libslang-utf8.so.1



Broken deps for ia64
----------------------------------------------------------
	crypto-utils - 2.2-8.ia64 requires libslang-utf8.so.1()(64bit)
	newt - 0.52.1-0.ia64 requires libslang-utf8.so.1()(64bit)
	rgmanager - 1.9.31-3.ia64 requires ccs
	slrn - 0.9.8.1-7.ia64 requires libslang-utf8.so.1()(64bit)
	slrn-pull - 0.9.8.1-7.ia64 requires libslang-utf8.so.1()(64bit)
	system-config-securitylevel-tui - 1.6.9-1.ia64 requires libslang-utf8.so.1()(64bit)
	timidity++ - 2.13.2-1.ia64 requires libslang-utf8.so.1()(64bit)



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	crypto-utils - 2.2-8.ppc requires libslang-utf8.so.1
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11
	newt - 0.52.1-0.ppc requires libslang-utf8.so.1
	slrn - 0.9.8.1-7.ppc requires libslang-utf8.so.1
	slrn-pull - 0.9.8.1-7.ppc requires libslang-utf8.so.1
	system-config-securitylevel-tui - 1.6.9-1.ppc requires libslang-utf8.so.1
	timidity++ - 2.13.2-1.ppc requires libslang-utf8.so.1



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	crypto-utils - 2.2-8.ppc64 requires libslang-utf8.so.1()(64bit)
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11
	newt - 0.52.1-0.ppc64 requires libslang-utf8.so.1()(64bit)
	slrn - 0.9.8.1-7.ppc64 requires libslang-utf8.so.1()(64bit)
	slrn-pull - 0.9.8.1-7.ppc64 requires libslang-utf8.so.1()(64bit)
	system-config-securitylevel-tui - 1.6.9-1.ppc64 requires libslang-utf8.so.1()(64bit)
	timidity++ - 2.13.2-1.ppc64 requires libslang-utf8.so.1()(64bit)



Broken deps for s390
----------------------------------------------------------
	crypto-utils - 2.2-8.s390 requires libslang-utf8.so.1
	mkinitrd - 5.0.11-1.s390 requires dmraid
	newt - 0.52.1-0.s390 requires libslang-utf8.so.1
	slrn - 0.9.8.1-7.s390 requires libslang-utf8.so.1
	slrn-pull - 0.9.8.1-7.s390 requires libslang-utf8.so.1
	system-config-securitylevel-tui - 1.6.9-1.s390 requires libslang-utf8.so.1
	timidity++ - 2.13.2-1.s390 requires libslang-utf8.so.1



Broken deps for s390x
----------------------------------------------------------
	crypto-utils - 2.2-8.s390x requires libslang-utf8.so.1()(64bit)
	mkinitrd - 5.0.11-1.s390x requires dmraid
	newt - 0.52.1-0.s390x requires libslang-utf8.so.1()(64bit)
	newt - 0.52.1-0.s390 requires libslang-utf8.so.1
	slrn - 0.9.8.1-7.s390x requires libslang-utf8.so.1()(64bit)
	slrn-pull - 0.9.8.1-7.s390x requires libslang-utf8.so.1()(64bit)
	system-config-securitylevel-tui - 1.6.9-1.s390x requires libslang-utf8.so.1()(64bit)
	timidity++ - 2.13.2-1.s390x requires libslang-utf8.so.1()(64bit)



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	crypto-utils - 2.2-8.x86_64 requires libslang-utf8.so.1()(64bit)
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	newt - 0.52.1-0.x86_64 requires libslang-utf8.so.1()(64bit)
	newt - 0.52.1-0.i386 requires libslang-utf8.so.1
	slrn - 0.9.8.1-7.x86_64 requires libslang-utf8.so.1()(64bit)
	slrn-pull - 0.9.8.1-7.x86_64 requires libslang-utf8.so.1()(64bit)
	system-config-securitylevel-tui - 1.6.9-1.x86_64 requires libslang-utf8.so.1()(64bit)
	timidity++ - 2.13.2-1.x86_64 requires libslang-utf8.so.1()(64bit)





From fedora at camperquake.de  Wed Nov 23 15:08:39 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 23 Nov 2005 16:08:39 +0100
Subject: rawhide report: 20051123 changes
In-Reply-To: <200511231502.jANF2ikZ015779@porkchop.devel.redhat.com>
References: <200511231502.jANF2ikZ015779@porkchop.devel.redhat.com>
Message-ID: <20051123150839.GC7783@ryoko.camperquake.de>

On Wed, Nov 23, 2005 at 10:02:44AM -0500, Build System wrote:

> openssh-4.2p1-9
> ---------------
> * Tue Nov 22 2005 Tomas Mraz <tmraz at redhat.com> - 4.2p1-9
> - drop x11-ssh-askpass from the package

Will it be back?

> xorg-x11-drv-mouse-1.0.1-2
> --------------------------
> * Mon Nov 21 2005 Mike A. Harris <mharris at redhat.com> 1.0.1-2
> - Added "alpha sparc sparc64" to ExclusiveArch for AlphaCore, CentOS,
>   AuroraLinux distributions, to minimize patching for them.

Hey, thanks!



From tmraz at redhat.com  Wed Nov 23 15:14:49 2005
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 23 Nov 2005 16:14:49 +0100
Subject: rawhide report: 20051123 changes
In-Reply-To: <20051123150839.GC7783@ryoko.camperquake.de>
References: <200511231502.jANF2ikZ015779@porkchop.devel.redhat.com>
	<20051123150839.GC7783@ryoko.camperquake.de>
Message-ID: <1132758889.4563.1.camel@perun.redhat.usu>

On Wed, 2005-11-23 at 16:08 +0100, Ralf Ertzinger wrote:
> On Wed, Nov 23, 2005 at 10:02:44AM -0500, Build System wrote:
> 
> > openssh-4.2p1-9
> > ---------------
> > * Tue Nov 22 2005 Tomas Mraz <tmraz at redhat.com> - 4.2p1-9
> > - drop x11-ssh-askpass from the package
> 
> Will it be back?
No, hopefully it won't sneak in anyhow.

-- 
Tomas Mraz <tmraz at redhat.com>



From bojan at rexursive.com  Wed Nov 23 23:16:28 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 24 Nov 2005 10:16:28 +1100
Subject: Missing files in xorg-x11-server-utils and xorg-x11-utils
Message-ID: <20051124101628.6d502inx0koc8og4@imp.rexursive.com>

As of the latest Rawhide updates, xterm is having problems finding 
colours, because the file /usr/lib/X11/rgb.txt isn't there any more and 
the two RPMS from the subject line report missing files.

Also, the xorg-x11-filesystem comes with 
/usr/bin/xorg-x11-filesystem-upgrade script with looks pretty broken at 
first glance. It contains things like:

for dir in /usr/include/X11 /usr/lib/X11; do
    if [ -d "" ]; then                         <---- OOPS!
        mkdir -p -- ""
    fi
done

Maybe some \$ escaping for $dir didn't go quite right?

Related problems? Dunno...

-- 
Bojan



From mharris at redhat.com  Wed Nov 23 23:25:17 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Wed, 23 Nov 2005 18:25:17 -0500
Subject: Missing files in xorg-x11-server-utils and xorg-x11-utils
In-Reply-To: <20051124101628.6d502inx0koc8og4@imp.rexursive.com>
References: <20051124101628.6d502inx0koc8og4@imp.rexursive.com>
Message-ID: <4384FA5D.2090003@redhat.com>

Bojan Smojver wrote:
> As of the latest Rawhide updates, xterm is having problems finding 
> colours, because the file /usr/lib/X11/rgb.txt isn't there any more and 
> the two RPMS from the subject line report missing files.
> 
> Also, the xorg-x11-filesystem comes with 
> /usr/bin/xorg-x11-filesystem-upgrade script with looks pretty broken at 
> first glance. It contains things like:
> 
> for dir in /usr/include/X11 /usr/lib/X11; do
>    if [ -d "" ]; then                         <---- OOPS!
>        mkdir -p -- ""
>    fi
> done
> 
> Maybe some \$ escaping for $dir didn't go quite right?
> 
> Related problems? Dunno...

Already fixed in latest builds.  I forgot by default that
heredocs do variable interpolation unless you disable it
by single quoting the EOF marker.

The rpm scripts in the package also have problems, but that's
also fixed.

Actually, if anyone discovers any bugs in any of the modular
X packages, please wait until the next rawhide push, and
update again, and then again again, and that should pick up
fixes for all sorts of good stuff ;)

Watch for error messages, and please post about any problems
here.

TIA



From bojan at rexursive.com  Wed Nov 23 23:52:59 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 24 Nov 2005 10:52:59 +1100
Subject: Missing files in xorg-x11-server-utils and xorg-x11-utils
In-Reply-To: <4384FA5D.2090003@redhat.com>
References: <20051124101628.6d502inx0koc8og4@imp.rexursive.com>
	<4384FA5D.2090003@redhat.com>
Message-ID: <20051124105259.mwewkxqiruo88480@imp.rexursive.com>

Quoting "Mike A. Harris" <mharris at redhat.com>:

> Actually, if anyone discovers any bugs in any of the modular
> X packages, please wait until the next rawhide push, and
> update again, and then again again, and that should pick up
> fixes for all sorts of good stuff ;)

OK, I'll wait for 3 more updates then ;-)

-- 
Bojan



From bojan at rexursive.com  Thu Nov 24 02:13:11 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 24 Nov 2005 13:13:11 +1100
Subject: Gnome 2.13?
Message-ID: <20051124131311.jpj94s8jy8ko0wsw@imp.rexursive.com>

I noticed that metacity was updated to 2.13.2 in the last batch of 
packages this morning. Is this the sign that we're heading to Gnome 
2.13.x (and therefore 2.14) in FC5 or was this package just a lonely 
accident?

-- 
Bojan



From louisg00 at bellsouth.net  Thu Nov 24 02:28:22 2005
From: louisg00 at bellsouth.net (Louis E Garcia II)
Date: Thu, 24 Nov 2005 02:28:22 +0000
Subject: status of up2date and rhn-applet
Message-ID: <1132799302.7912.4.camel@tiger>

Just noticed the these packages are still present in FC5T1. Since yum is
the preferred way to update what is the future of these? Do they still
work? The applet never worked in FC4 by the way.




From caillon at redhat.com  Thu Nov 24 03:52:17 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 23 Nov 2005 22:52:17 -0500
Subject: Gnome 2.13?
In-Reply-To: <20051124131311.jpj94s8jy8ko0wsw@imp.rexursive.com>
References: <20051124131311.jpj94s8jy8ko0wsw@imp.rexursive.com>
Message-ID: <438538F1.4040200@redhat.com>

On 11/23/2005 09:13 PM, Bojan Smojver wrote:
> I noticed that metacity was updated to 2.13.2 in the last batch of 
> packages this morning. Is this the sign that we're heading to Gnome 
> 2.13.x (and therefore 2.14) in FC5 or was this package just a lonely 
> accident?
No.  The sign that we're heading to Gnome 2.14 has been posted for a 
while already at http://fedoraproject.org/wiki/FC5Future



From bojan at rexursive.com  Thu Nov 24 04:14:30 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Thu, 24 Nov 2005 15:14:30 +1100
Subject: Gnome 2.13?
In-Reply-To: <438538F1.4040200@redhat.com>
References: <20051124131311.jpj94s8jy8ko0wsw@imp.rexursive.com>
	<438538F1.4040200@redhat.com>
Message-ID: <20051124151430.tftyfxbgf4k4s800@imp.rexursive.com>

Quoting Christopher Aillon <caillon at redhat.com>:

> No.  The sign that we're heading to Gnome 2.14 has been posted for a 
> while already at http://fedoraproject.org/wiki/FC5Future

Aha, good. There was a thread on this topic in September and many RH 
folk were opposing the idea, so I thought it was dropped (I get on/off 
list occasionally, so I must have missed the reversal). I'm glad we'll 
have the latest and greatest to break in FC5 :-)

And I'll try to read that page in the future. Thanks for pointing it out.

-- 
Bojan



From russell at coker.com.au  Thu Nov 24 04:43:44 2005
From: russell at coker.com.au (Russell Coker)
Date: Thu, 24 Nov 2005 15:43:44 +1100
Subject: opinions on /etc/security/limits.conf
Message-ID: <200511241543.49186.russell@coker.com.au>

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173902

Currently if you run "su - user" (or several other commands that use pam) then 
the limits for many fields are inherited from the user executing the command.

The main problem I have with this is that it gives inconsistent results, 
particularly in the case of daemons.  I have designed a change to the program 
"runuser" to make it use pam_limits.so so that the limits.conf file will be 
applied to daemons.  But to take advantage of this we need sane values.  
Currently even with my proposed modification to runuser daemons will still 
run inconsistently, a daemon may perform differently dependant on whether it 
was started at system boot or by the action of an administrator.

Also some daemons (such as Oracle) are started by "su" which has the same 
issues.

If a daemon is going to fail then it should fail in every situation so the 
administrator can be aware of the problem and fix it.  Alternately if it 
works in one situation then it should work in others.

To deal with this I believe that the default limits.conf file should have 
entries for every field for every user.  This is a little controversial so 
I'd appreciate feedback on the above bugzilla.  We have two issues to 
resolve, whether to have such a default and what the default should be.  In 
my bug report I have suggested some values taken from default values for 
rawhide and RHEL4.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From jfrieben at freesurf.fr  Thu Nov 24 08:23:07 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Thu, 24 Nov 2005 09:23:07 +0100 (CET)
Subject: status of up2date and rhn-applet
In-Reply-To: <1132799302.7912.4.camel@tiger>
References: <1132799302.7912.4.camel@tiger>
Message-ID: <55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>

"up2date-gnome" is by far the most usable update tool to date.
"pup" is really not on par in any respect. I really have no
idea why people spent time on that one. The best would be to
simply remove it. I do really hope that "up2date-gnome" will
remain in the distro. If it uses "yum" under the hood that's
ok. Concerning "rhn-applet" your right: it is already unusable
in FC4. No reason to drop it though. It should get fixed unless
somebody comes up with an alternative shiny new update notifier.




From andreas.bierfert at lowlatency.de  Thu Nov 24 12:56:34 2005
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Thu, 24 Nov 2005 13:56:34 +0100
Subject: apm in recent rawhide kernels
Message-ID: <20051124135634.576039b9@alkaid.lan>

Hi,

did I miss something or is the apm support missing from the recent devel
kernels? My laptop really is not happy about this ^^

- Andreas

-- 
Andreas Bierfert               | http://awbsworld.de      | GPG: C58CF1CB
andreas.bierfert at lowlatency.de | http://lowlatency.de     | signed/encrypted
phone: +49 2402 102373         | cell: +49 172 9789968    | mail preferred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051124/758b65e2/attachment.sig>

From markmc at redhat.com  Thu Nov 24 13:52:27 2005
From: markmc at redhat.com (Mark McLoughlin)
Date: Thu, 24 Nov 2005 13:52:27 +0000
Subject: .local/mDNS resolving in FC5 [was Re: Zeroconf in FC5?]
In-Reply-To: <42A2458C.4030300@redhat.com>
References: <1117766193.4649.51.camel@ninja>  <42A2458C.4030300@redhat.com>
Message-ID: <1132840347.19458.396.camel@blaa>

Hi Ulrich,

On Sat, 2005-06-04 at 17:21 -0700, Ulrich Drepper wrote:
> Daryll Strauss wrote:
> > So, I'd like to see zeroconf
> > really integrated in to FC5. I think it'll make network setup for a lot
> > of users much easier.
> 
> So get working.  There is a lot to do.  And don't mention these foolish
> attempts of integration done by some other distributions.
> 
> What is needed is another daemon (or an extended and renamed
> mDNSResponder) which monitors the network and caches all entries for the
> appropriate time.  The daemon needs a programming interface so that a
> new NSS module can be used to query the daemon's cache of known
> addresses and probably also to initiate the daemon to send out requests
> for information which isn't in the cache.
> 
> I talked with the author of the current (unusable) nss_mdns module and
> he plans to do something like this after I explained it to him.  But I
> haven't seen any progress.

	It seems like the nss-mdns author has made some progress on this. The
latest version allows queries to be directed through Avahi's mDNS
responder (the responder in FC5), meaning responses are cached directly
etc.

	Any opinions on this implementation and whether or not it would be
appropriate to include in FC5?

	From a quick look at the code, one of my initial concerns is that, for
every query, the module opens a new connection with the daemon and opens
the /etc/mdns.allow file.

	At the very least, though, it looks like progress in the direction you
suggested.

Cheers,
Mark.

P.S. - Bastien points out his packaging of the 0.6 version:

  http://files.hadess.net/redhat/perso/source/nss-mdns-0.6-1.src.rpm

       Might be a useful starting point for anyone wanting to package
the 0.7 version with --enable-avahi



From maxer1 at xmission.com  Thu Nov 24 15:52:48 2005
From: maxer1 at xmission.com (RaXeT)
Date: Thu, 24 Nov 2005 08:52:48 -0700
Subject: Iptables no longer accepts mess - BUG 174014
Message-ID: <4385E1D0.7010309@xmission.com>

Latest dev update from 11-23-05 hiccups on bootup

Version  - iptables-1.3.4-1

Applying iptables firewall rules: iptables-restore v1.3.4: Unknown arg `--icmp-type'
Error occurred at line: 11
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
                                                           [FAILED]

iptables no longer accepts, and won't start with, 
  -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT

Happy Thanksgiving



From jkeating at j2solutions.net  Thu Nov 24 17:15:11 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Thu, 24 Nov 2005 09:15:11 -0800
Subject: status of up2date and rhn-applet
In-Reply-To: <55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
References: <1132799302.7912.4.camel@tiger>
	<55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
Message-ID: <1132852511.3748.7.camel@yoda.loki.me>

On Thu, 2005-11-24 at 09:23 +0100, Joachim Frieben wrote:
> "up2date-gnome" is by far the most usable update tool to date.
> "pup" is really not on par in any respect. I really have no
> idea why people spent time on that one. The best would be to
> simply remove it. I do really hope that "up2date-gnome" will
> remain in the distro. If it uses "yum" under the hood that's
> ok. Concerning "rhn-applet" your right: it is already unusable
> in FC4. No reason to drop it though. It should get fixed unless
> somebody comes up with an alternative shiny new update notifier.
> 

Would you care to give some constructive feed back as to why you find
pup so intolerable in it's first release version?  What about
up2date-gnome did you like and would like to see in the standalone pup? 

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From lmacken at redhat.com  Thu Nov 24 17:58:22 2005
From: lmacken at redhat.com (Luke Macken)
Date: Thu, 24 Nov 2005 12:58:22 -0500
Subject: Iptables no longer accepts mess - BUG 174014
In-Reply-To: <4385E1D0.7010309@xmission.com>
References: <4385E1D0.7010309@xmission.com>
Message-ID: <20051124175821.GA32262@tomservo.boston.redhat.com>

On Thu, Nov 24, 2005 at 08:52:48AM -0700, RaXeT wrote:
| Latest dev update from 11-23-05 hiccups on bootup
| 
| Version  - iptables-1.3.4-1
| 
| Applying iptables firewall rules: iptables-restore v1.3.4: Unknown arg 
| `--icmp-type'
| Error occurred at line: 11
| Try `iptables-restore -h' or 'iptables-restore --help' for more information.
|                                                           [FAILED]
| 
| iptables no longer accepts, and won't start with, 
|  -A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
| 
| Happy Thanksgiving

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174014


luke



From buildsys at redhat.com  Thu Nov 24 18:17:20 2005
From: buildsys at redhat.com (Build System)
Date: Thu, 24 Nov 2005 13:17:20 -0500
Subject: rawhide report: 20051124 changes
Message-ID: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>

 

 
Updated Packages:

OpenIPMI-1.4.14-14
------------------
* Wed Nov 23 2005 Phil Knirsch <pknirsch at redhat.com> 1.4.14-14
- Some more initscript and sysconfig updates from Dell.

alsa-lib-1.0.10rf-1
-------------------
* Thu Nov 24 2005 Martin Stransky <stransky at redhat.com> 1.0.10rf-1
- new upstream version

alsa-utils-1.0.10rf-1
---------------------
* Thu Nov 24 2005 Martin Stransky <stransky at redhat.com> 1.0.10rf-1
- new upstream version
- added alias for snd-azx

arts-8:1.5.0-0.1.rc2
--------------------
* Thu Nov 24 2005 Than Ngo <than at redhat.com> 8:1.5.0-0.1.rc2
- update to 3.5.0 rc2

* Mon Nov 14 2005 Than Ngo <than at redhat.com> 8:1.5.0-0.1.rc1
- update to 3.5.0 rc1
- another patch to fix lnusertemp problem

bind-24:9.3.1-24
----------------
* Wed Nov 23 2005 Jason Vas Dias <jvdias at redhat.com> - 24:9.3.1-24
- allow D-BUS support to work in bind-chroot environment:
  workaround latest selinux policy by mounting /var/run/dbus/
  under chroot instead of /var/run/dbus/system-bus-socket

compat-slang-1.4.9-27
---------------------
* Wed Nov 23 2005 Petr Raszyk <praszyk at redhat.com> - 1.4.9-27
- Rebuild.

* Wed Nov 23 2005 Petr Raszyk <praszyk at redhat.com> - 1.4.9-26
- Rebuild.

* Wed Nov 23 2005 Petr Raszyk <praszyk at redhat.com> - 1.4.9-25
- Rebuild.

cpio-2.6-11
-----------
* Wed Nov 23 2005 Peter Vrabec <pvrabec at redhat.com> 2.6-11
- fix previous patch(writeOutHeaderBufferOverflow)

* Wed Nov 23 2005 Peter Vrabec <pvrabec at redhat.com> 2.6-10
- write_out_header rewritten to fix buffer overflow(#172669)

efax-0.9-26
-----------
* Wed Nov 23 2005 Than Ngo <than at redhat.com> 0.9-26
- fix for modular X #173707

emacs-21.4-9
------------
* Tue Nov 22 2005 Jens Petersen <petersen at redhat.com> - 21.4-9
- fix keyboard-coding-system on console for utf-8 (Dawid Gajownik, #173855)
- update etags to latest cvs (Hideki Iwamoto, #173023)
  - replace etags-14.21-17.11-diff.patch with etags-update-to-cvs.patch
- update smtpmail.el to latest cvs version for better authentication support
  with smtpmail-cvs-update.patch (Alberto Brizio, #167804)

findutils-1:4.2.26-1
--------------------
* Mon Nov 21 2005 Tim Waugh <twaugh at redhat.com> 1:4.2.26-1
- One further arg_max fix for PPC.
- Applied arg_max patch from upstream to fix test suite failures.
- 4.2.26 (fixes bug #173817).

gnutls-1.2.9-1
--------------
* Wed Nov 23 2005 Tomas Mraz <tmraz at redhat.com> 1.2.9-1
- upgrade to newest upstream
- removed .la files (#172635)

hplip-0.9.7-1
-------------
* Thu Nov 24 2005 Tim Waugh <twaugh at redhat.com> 0.9.7-1
- 0.9.7.

hsqldb-0:1.80.1-1jpp_4fc
------------------------
* Wed Nov 23 2005 Archit Shah <ashah at redhat.com> 0:1.80.1-1jpp_4fc
- Change hsqldb user shell to /sbin/nologin.

kernel-2.6.14-1.1709_FC5
------------------------
* Wed Nov 23 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git3

latex2html-2002.2.1-5
---------------------
* Thu Nov 24 2005 Jindrich Novy <jnovy at redhat.com> 2002.2.1-5
- fix path to rgb.txt, thanks to Ville Skytt?? (#174089)

libfontenc-0.99.2-3
-------------------
* Wed Nov 23 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-3
- Bump xorg-x11-filesystem dep to >= 0.99.2-3 as -2 had bugs.

libsemanage-1.3.56-2
--------------------
* Wed Nov 23 2005 Dan Walsh <dwalsh at redhat.com> 1.3.56-2
- Add additional swig objects

logwatch-7.1-2
--------------
* Thu Nov 24 2005 Ivana Varekova <varekova at redhat.com> 7.1-2
- add named script patch (bug 171631)
- change autdated description

* Wed Nov 23 2005 Ivana Varekova <varekova at redhat.com> 7.1-1
- update to 7.1
- added sshd and samba patches

man-pages-ja-20051115-1
-----------------------
* Mon Nov 21 2005 Akira TAGOH <tagoh at redhat.com> - 20051115-1
- updates to 20051115.
- man-pages-ja-20051115-libaio.patch: fixed a misleading of the header file
  required and a typo.
- man-pages-ja-20050215-ls.patch: fixed the -H option's explanation.

newt-0.52.2-0
-------------
* Tue Nov 22 2005 Petr Rockai <prockai at redhat.com> - 0.52.2-0
- new upstream version (minor fixes for the source tarball
  and build system)

* Fri Sep 30 2005 Petr Rockai <prockai at redhat.com> - 0.52.1-0
- revert bidi patch, objections by Jeremy Katz about
  anaconda breaking
- this version still only exists as a "ghastly" upstream tarball;
  the patches are now cleaned up and will be integrated into
  rhlinux cvs unless some more breakage akin to bidi occurs
- the if1close patch is now part of upstream tarball too

* Wed Sep 21 2005 Petr Rockai <prockai at redhat.com> - 0.52.0-0
- new upstream version

nut-2.0.2-5
-----------
* Wed Nov 23 2005 Than Ngo <than at redhat.com> 2.0.2-5
- fix for modular X

rhpl-0.178-1
------------
* Wed Nov 23 2005 Chris Lumens <clumens at redhat.com> 0.178-1
- Update keyboard model dict to match modular X (#173268).

rsh-0.17-32
-----------
* Thu Nov 24 2005 Karel Zak <kzak at redhat.com> 0.17-32
- fix #174045 - rcp outputs negative file size when over 2GB

selinux-policy-2.0.5-3
----------------------
* Sun Nov 23 2003 Dan Walsh <dwalsh at redhat.com> 2.0.5-3
- Cleanup pegasus and named 
- Fix spec file

* Fri Nov 21 2003 Dan Walsh <dwalsh at redhat.com> 2.0.5-1
-Update to latest from upstream

system-config-date-1.7.99.8-1
-----------------------------
* Thu Nov 24 2005 Nils Philippsen <nphilipp at redhat.com> 1.7.99.8
- reshow shaded map when reentering map widget from outside
- clear status line when outside region area in zoomed mode

* Thu Nov 24 2005 Nils Philippsen <nphilipp at redhat.com> 1.7.99.7
- only select region if pointer is inside region
- replace aa-based shading to avoid aa-related deficiencies of GnomeCanvas
- show shaded border around zoomed in region to zoom out without selecting a
  city

* Wed Nov 23 2005 Nils Philippsen <nphilipp at redhat.com>
- don't let cities get miraculously lost (#173944, patch by Chris Lumens)

xmlsec1-1.2.9-3
---------------
* Wed Nov 23 2005 Tomas Mraz <tmraz at redhat.com> 1.2.9-3
- rebuilt due to gnutls library revision

xorg-x11-apps-0.99.2-4
----------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-4
- Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3" to workaround
  (#173384)
- Added the following patches, and invoke aclocal/automake/autoconf on them
  to force app-defaults and other datafiles into _datadir instead of _libdir:
  - oclock-0.99.1-oclock-datadir-cleanups.patch
  - x11perf-0.99.1-x11perf-datadir-cleanups.patch
  - xclipboard-0.99.1-xclipboard-datadir-cleanups.patch
  - xclock-0.99.1-xclock-datadir-cleanups.patch
  - xconsole-0.99.2-xconsole-datadir-cleanups.patch
  - xload-0.99.1-xload-datadir-cleanups.patch
  - xlogo-0.99.1-xlogo-datadir-cleanups.patch
  - xmag-0.99.1-xmag-datadir-cleanups.patch
  - xmessage-0.99.1-xmessage-datadir-cleanups.patch
- Added luit-0.99.1-luit-locale-dir-fix.patch to fix bug (#173702)
xorg-x11-drivers-0.99.2-4
-------------------------
* Wed Nov 23 2005 Mike Harris <mharris at redhat.com> 0.99.2-4
- Add ur98 driver back, as it is part of X11R7 RC2
xorg-x11-filesystem-0.99.2-3
----------------------------

xorg-x11-fonts-0.99.0-7
-----------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.0-7
- Undo the workaround implemented in build 0.99.0-5, and make the misc fonts
  directory ":unscaled" again.
- Invoke chkfontpath to remove the bare 'misc' font path without the :unscaled
  attribute from xfs config.

xorg-x11-server-0.99.3-7
------------------------
* Wed Nov 23 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-7
- Update xorg-x11-server-utils dep to 0.99.2-5 to ensure rgb.txt is installed
  in correct location - _datadir/X11/rgb
- Added --with-rgb-path configure option to specify _datadir/X11/rgb so the
  X server finds the rgb.txt database properly, for bugs (#173453, 173435,
  173428, 173483, 173734, 173737, 173594)
- Added xorg-server-0.99.3-fbmmx-fix-for-non-SSE-cpu.patch to prevent SSE/MMX
  code from being activated on non-capable VIA CPU. (#173384,fdo#5093)

xorg-x11-server-utils-0.99.2-5
------------------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-5
- Bump "filesystem" Requires(pre) to 2.3.7-1.
xorg-x11-xbitmaps-0.99.1-4
--------------------------
* Wed Nov 23 2005 Mike A. Harris <mharris at redhat.com> 0.99.1-4
- Updated dep to "Requires(pre): xorg-x11-filesystem >= 0.99.2-3" for new fix.
- Moved bitmap files back into the upstream default of _includedir (#173665).

xorg-x11-xsm-0.99.2-4
---------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-4
- Add "Requires(pre): xorg-x11-filesystem >= 0.99.2-3" to avoid bug (#173384).
- Added rstart-0.99.1-rstart-installation-location-fixes.patch and
  xsm-0.99.2-xsm-installation-location-fixes.patch to put config files in
 /etc and data files in /usr/share where they belong.
- Added "Requires: xauth, rsh" as rstart invokes xauth, rsh.
xorg-x11-xtrans-devel-0.99.2-2
------------------------------
* Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-2
- Add "Requires(pre): xorg-x11-filesystem >= 0.99.2-3" to avoid bug (#173384).

xterm-207-7
-----------

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390x requires dmraid



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5



From dragoran at feuerpokemon.de  Thu Nov 24 19:02:49 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Thu, 24 Nov 2005 20:02:49 +0100
Subject: rhn-applet replacement?
Message-ID: <43860E59.7080709@feuerpokemon.de>

pup is going to replace up2date in FC5 (already included in test1).
but what about rhn-applet (which was broken in fc4) ? will feature 
releases of pup(in fc5) provide a similiar applet?



From sundaram at redhat.com  Thu Nov 24 19:08:32 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Fri, 25 Nov 2005 00:38:32 +0530
Subject: rhn-applet replacement?
In-Reply-To: <43860E59.7080709@feuerpokemon.de>
References: <43860E59.7080709@feuerpokemon.de>
Message-ID: <43860FB0.5090408@redhat.com>

dragoran wrote:

> pup is going to replace up2date in FC5 (already included in test1).
> but what about rhn-applet (which was broken in fc4) ? will feature 
> releases of pup(in fc5) provide a similiar applet?
>
Yum is a up2date alternative. Pup is the alternative for rhn-applet and 
not all of the planned features are implemented in it yet. So hang on.

regards
Rahul



From andreas.bierfert at lowlatency.de  Thu Nov 24 20:28:27 2005
From: andreas.bierfert at lowlatency.de (Andreas Bierfert)
Date: Thu, 24 Nov 2005 21:28:27 +0100
Subject: apm in recent rawhide kernels
Message-ID: <20051124212827.1571196e@alkaid.lan>

Is it just me or is apm support missing from recent devel kernels? My laptop
sure does not like it =)

- Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051124/036c4727/attachment.sig>

From roland at redhat.com  Thu Nov 24 22:23:14 2005
From: roland at redhat.com (Roland McGrath)
Date: Thu, 24 Nov 2005 14:23:14 -0800 (PST)
Subject: opinions on /etc/security/limits.conf
In-Reply-To: Russell Coker's message of  Thursday,
	24 November 2005 15:43:44 +1100
	<200511241543.49186.russell@coker.com.au>
Message-ID: <20051124222314.382C91809B9@magilla.sf.frob.com>

I don't think it makes sense that this configuration file be the means of
resetting limits to their boot-time defaults, since that is what you really
want.  If what you want is to reset the base limits to those inherited from
init, you should do that explicitly.  i.e. have runuser or su, or SELinux
transition on exec, reset the limits to init's before applying whatever
configuration you want.  What you propose will wind up with drift between
the configuration file and the kernel defaults.  Some of the kernel default
limits are based on the size of RAM and such, so a default value in the
config file will never be right across the board.



From d.jacobfeuerborn at conversis.de  Fri Nov 25 00:21:56 2005
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Fri, 25 Nov 2005 01:21:56 +0100
Subject: rawhide report: 20051124 changes
In-Reply-To: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
References: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
Message-ID: <43865924.7000009@conversis.de>

Build System wrote:
> xorg-x11-fonts-0.99.0-7
> -----------------------
> * Tue Nov 22 2005 Mike A. Harris <mharris at redhat.com> 0.99.0-7
> - Undo the workaround implemented in build 0.99.0-5, and make the misc fonts
>   directory ":unscaled" again.
> - Invoke chkfontpath to remove the bare 'misc' font path without the :unscaled
>   attribute from xfs config.

It seems this has broken X alltogether because the 'misc' font path has 
been completely removed from /etc/X11/fs/config. I had to add it back 
manually in order to make X find the 'fixed' font again.

Also moving windows around in a Composite+xcompmgr scenario isn't as smooth 
anymore as it has been in the last few days.

Regards,
   Dennis



From russell at coker.com.au  Fri Nov 25 00:59:12 2005
From: russell at coker.com.au (Russell Coker)
Date: Fri, 25 Nov 2005 11:59:12 +1100
Subject: opinions on /etc/security/limits.conf
In-Reply-To: <20051124222314.382C91809B9@magilla.sf.frob.com>
References: <20051124222314.382C91809B9@magilla.sf.frob.com>
Message-ID: <200511251159.19335.russell@coker.com.au>

On Friday 25 November 2005 09:23, Roland McGrath <roland at redhat.com> wrote:
> I don't think it makes sense that this configuration file be the means of
> resetting limits to their boot-time defaults, since that is what you really
> want.  If what you want is to reset the base limits to those inherited from
> init, you should do that explicitly.

How would you do this?  As far as I am aware it's not possible to read the 
limits of another process, and even if it was possible it probably wouldn't 
be desirable to permit it in the SE Linux policy.

> i.e. have runuser or su, or SELinux 
> transition on exec, reset the limits to init's before applying whatever
> configuration you want.  What you propose will wind up with drift between
> the configuration file and the kernel defaults.  Some of the kernel default
> limits are based on the size of RAM and such, so a default value in the
> config file will never be right across the board.

The kernel defaults may be based on RAM etc, but my observation is that they 
are not going to help you.

Below is the output of "ulimit -a" on a rawhide system with 768M of RAM and no 
entries in limits.conf:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 12278
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
max rt priority                 (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 12278
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

The only real limits are 1024 open files and 12278 processes.  The 1024 open 
files are per-process and /proc/sys/fs/file-max on that machine is 76660 by 
default.  So if a hostile user (or buggy program) was to fork 77 processes 
that use the maximum number of file handles or the maximum number of 
processes that each use 7 file handles then the system would run out.

It seems to me that setting limits to lower values would do some good.  A 
default of say 500 processes for a non-root user would be useful and 
generally not get in the way of regular operations.  Even a limit of 1000 
processes would be less than the kernel is likely to assign to any machine in 
a supported configuration (minimum supported configuration for RHEL is 256M) 
while still being much larger than anyone is really likely to need.

The only fields that seem to change default values based on RAM are the number 
of pending signals (I don't even know the purpose of this) and the number of 
processes.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



From katzj at redhat.com  Fri Nov 25 02:15:02 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 24 Nov 2005 21:15:02 -0500
Subject: rhn-applet replacement?
In-Reply-To: <43860FB0.5090408@redhat.com>
References: <43860E59.7080709@feuerpokemon.de> <43860FB0.5090408@redhat.com>
Message-ID: <1132884902.12103.8.camel@bree.local.net>

On Fri, 2005-11-25 at 00:38 +0530, Rahul Sundaram wrote:
> dragoran wrote:
> > pup is going to replace up2date in FC5 (already included in test1).
> > but what about rhn-applet (which was broken in fc4) ? will feature 
> > releases of pup(in fc5) provide a similiar applet?
> >
> Yum is a up2date alternative. Pup is the alternative for rhn-applet and 
> not all of the planned features are implemented in it yet. So hang on.

Erm, _huh_?  pup is _NOT_ the replacement for the rhn-applet.
Similarly, yum is not entirely analagous to up2date given that the
primary mode of up2date use is graphical which yum doesn't have.

pup provides a graphical frontend to yum for getting updates and we have
some ideas on notification of updates being available (which is
analagous to the rhn-applet).  This will likely take advantage of pup
much like rhn-applet uses up2date.  The hope is that we'll get there for
FC5, but it's largely dependent on time.

Jeremy



From katzj at redhat.com  Fri Nov 25 02:16:14 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Thu, 24 Nov 2005 21:16:14 -0500
Subject: apm in recent rawhide kernels
In-Reply-To: <20051124212827.1571196e@alkaid.lan>
References: <20051124212827.1571196e@alkaid.lan>
Message-ID: <1132884974.12103.10.camel@bree.local.net>

On Thu, 2005-11-24 at 21:28 +0100, Andreas Bierfert wrote:
> Is it just me or is apm support missing from recent devel kernels? My laptop
> sure does not like it =)

CONFIG_APM is still set.  The main change which could be impacting you
is that we've disabled the old BIOS acpi blacklist.  Which means that
your laptop is probably getting ACPI instead.  If ACPI doesn't work,
please file a bug with details in bugzilla.

Thanks!

Jeremy



From bojan at rexursive.com  Fri Nov 25 03:31:09 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Fri, 25 Nov 2005 14:31:09 +1100
Subject: Initializing hardware... slow
Message-ID: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>

Is that just my box, or did this part of the boot become painfully slow 
as of recent? It takes around half a minute to do "storage hardware 
audio" thingy. Has anyone else noticed something like that?

-- 
Bojan



From ggw at wolves.durham.nc.us  Fri Nov 25 04:12:16 2005
From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury)
Date: Thu, 24 Nov 2005 23:12:16 -0500
Subject: Initializing hardware... slow
In-Reply-To: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
Message-ID: <20051125041216.GA4620@wolves.durham.nc.us>

On Fri, Nov 25, 2005 at 02:31:09PM +1100, Bojan Smojver wrote:
> Is that just my box, or did this part of the boot become painfully slow 
> as of recent? It takes around half a minute to do "storage hardware 
> audio" thingy. Has anyone else noticed something like that?
> 
> -- 
> Bojan

Yes, I've noticed it recently too.

-- 
G.Wolfe Woodbury     `- -'
RHCT                   U
The Line Eater is a boojum!
-------------- 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/20051124/a7396cda/attachment.sig>

From clydekunkel7734 at cox.net  Fri Nov 25 05:50:16 2005
From: clydekunkel7734 at cox.net (Clyde E. Kunkel)
Date: Fri, 25 Nov 2005 00:50:16 -0500
Subject: Initializing hardware... slow
In-Reply-To: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
Message-ID: <4386A618.1070606@cox.net>

Bojan Smojver wrote:
> Is that just my box, or did this part of the boot become painfully slow 
> as of recent? It takes around half a minute to do "storage hardware 
> audio" thingy. Has anyone else noticed something like that?
> 
Yep...very slow.  As is hal (already noted elsewhere).

-- 
Regards,

Old Fart



From i_p_a_u_l at yahoo.com  Fri Nov 25 06:16:54 2005
From: i_p_a_u_l at yahoo.com (Paul Ionescu)
Date: Fri, 25 Nov 2005 08:16:54 +0200
Subject: Initializing hardware... slow
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
Message-ID: <pan.2005.11.25.06.16.54.917122@yahoo.com>

On Fri, 25 Nov 2005 14:31:09 +1100, Bojan Smojver wrote:

> Is that just my box, or did this part of the boot become painfully slow as
> of recent? It takes around half a minute to do "storage hardware audio"
> thingy. Has anyone else noticed something like that?
> 
> -- 
> Bojan

Yeap, slow here too.




From jfrieben at freesurf.fr  Fri Nov 25 09:54:59 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Fri, 25 Nov 2005 10:54:59 +0100 (CET)
Subject: status of up2date and rhn-applet
In-Reply-To: <1132852511.3748.7.camel@yoda.loki.me>
References: <1132852511.3748.7.camel@yoda.loki.me>
Message-ID: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>

"up2date-gnome" has a very clear, informative interface. You start with a
channel windows that allows you review the available channels and to make
your choice. Very nice, indeed. Once the header information is downloaded, a
concise but exhaustive package list is displayed, which from you obtain all
interesting details like package name, previous version, current version,
channel and so on. Furthermore, it's possible to resize the width of the
individual columns. Even for a significant number of available packages, you
keep an oversight of what is going on. After confirming the package
selection you proceed to the clear and informative download window.
Individual package download progress and total progress are displayed
together with some info in the package that is currently downloaded. The
same holds for the package installation step. I also love the summary at the
very end which lets you have a final look on which packages got upgraded.
And do not forget the neat red/grey coulour scheme :)
"pup" with its greyish look and the strange doggy icon that does everything
but fit the genuine Bluecurve icon style looks like the little, poor bother
of big "up2date-gnome". Its interface is cluttered, the package window only
lets you see some packages at once. There is little info on the available
updates. In the main window, there is this boring "Updated ... packages
available" message for every single package. I would call this redundancy at
its best. If you want a bit more information you have to expand the "Update
details" window. It won't make you happy either, because where
"up2ate-gnome" gave you an exhaustive list for all packages in a single
pane, you have to click every single package by hand to obtain at least some
basic onformation in the "Update details" window.
To summarize, "pup" looks like a layman's vain attempt to imitate
"up2ate-gnome". Why reinvent the wheel, when it has already been?
"up2ate-gnome" has been around for a couple of years to my greatest
satisfaction. It cannot be hard to use "yum" as a backend instead of
"up2date", so why start from scratch?

>
> Would you care to give some constructive feed back as to why you find
> pup so intolerable in it's first release version?  What about
> up2date-gnome did you like and would like to see in the standalone pup?
>
>
> --
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>




From paul at city-fan.org  Fri Nov 25 10:13:42 2005
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 25 Nov 2005 10:13:42 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
Message-ID: <4386E3D6.8050007@city-fan.org>

Joachim Frieben wrote:
> It cannot be hard to use "yum" as a backend instead of
> "up2date", so why start from scratch?

Yum is already a backend for up2date, providing support (albeit slightly 
broken, at least in FC4) for repomd metadata. It's a shame rhn-applet is 
completely borked as far as repomd support (the default out-of-the-box 
configuration) is concerned.

Paul.



From che666 at gmail.com  Fri Nov 25 10:29:14 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Fri, 25 Nov 2005 11:29:14 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <1132852511.3748.7.camel@yoda.loki.me>
References: <1132799302.7912.4.camel@tiger>
	<55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
	<1132852511.3748.7.camel@yoda.loki.me>
Message-ID: <e99d27470511250229x50ad26c5j@mail.gmail.com>

2005/11/24, Jesse Keating <jkeating at j2solutions.net>:
> On Thu, 2005-11-24 at 09:23 +0100, Joachim Frieben wrote:
> > "up2date-gnome" is by far the most usable update tool to date.
> > "pup" is really not on par in any respect. I really have no
> > idea why people spent time on that one. The best would be to
> > simply remove it. I do really hope that "up2date-gnome" will
> > remain in the distro. If it uses "yum" under the hood that's
> > ok. Concerning "rhn-applet" your right: it is already unusable
> > in FC4. No reason to drop it though. It should get fixed unless
> > somebody comes up with an alternative shiny new update notifier.
> >
>
> Would you care to give some constructive feed back as to why you find
> pup so intolerable in it's first release version?  What about
> up2date-gnome did you like and would like to see in the standalone pup?
>
> --
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>
> Was I helpful?  Let others know:
>  http://svcs.affero.net/rm.php?r=jkeating
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

Hello Mr Keating,

Feature Requests for pup:

1. Handling of Packagegroups for Groupwise updating
2. Notification applet (maybe as external application may as internal
feature... guess external would be preferred)
3. Repository Handling from UI (i liked the up2date behaviour to
selectively enable and disable repos)
4. selectivly exluding packages by gui (clickable list with checkbox
buttons maybe?)
5. all of the above stuff saveable into yum config files to have a
consistent environment.

while i think that most of above suggestions arent really necassery
for even an 1.0 release of the software and while i additionally think
that some of the above stuff should probably go under an "advanced"
tab, i think that some of the above mentioned stuff can be helpful to
make package updates properly manageable from gui.

regards,
Rudolf Kastl

p.s. opinions welcome



From harald at redhat.com  Fri Nov 25 12:10:32 2005
From: harald at redhat.com (Harald Hoyer)
Date: Fri, 25 Nov 2005 13:10:32 +0100
Subject: Initializing hardware... slow
In-Reply-To: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
Message-ID: <4386FF38.8030104@redhat.com>

Bojan Smojver wrote:
> Is that just my box, or did this part of the boot become painfully slow 
> as of recent? It takes around half a minute to do "storage hardware 
> audio" thingy. Has anyone else noticed something like that?
> 

could you please try:

ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm



From mjc at redhat.com  Fri Nov 25 15:15:16 2005
From: mjc at redhat.com (Mark J Cox)
Date: Fri, 25 Nov 2005 15:15:16 +0000 (GMT)
Subject: Summary of FC5test1 vulnerabilities
Message-ID: <0511251349500.28294@dell1.moose.awe.com>

With the release of FC5test1 we've done an audit of possible (known, 
public) vulnerabilities from 20030101 to date that are in packages part 
of FC5test1.  The aim is to minimise the number of flaws unfixed by FC5 
gold.  Summary:

Total possible vulnerabilities 20030101 to date: 1170
FC5test1 not vulnerable:
      due to upstream version of package shipped: 1079 (92%)
      due to backported security patch: 77 (7%)
FC5test1 vulnerable: 14 (1%)

Bugs have been filed for the vulnerabilities still present in FC5test1 
packages, and we'll continue to track up to release and beyond flaws 
affecting FC5.  The living document with all the details is at:

http://cvs.fedora.redhat.com/viewcvs/*checkout*/fedora-security/audit/fc5?root=fedora

The method behind the audit can be found in the details of our
original FC4 audit: http://people.redhat.com/mjc/20050505-fc4

Questions or corrections to secalert at redhat.com

Thanks, Mark
-- 
Mark J Cox / Red Hat Security Response Team




From buildsys at redhat.com  Fri Nov 25 15:50:18 2005
From: buildsys at redhat.com (Build System)
Date: Fri, 25 Nov 2005 10:50:18 -0500
Subject: rawhide report: 20051125 changes
Message-ID: <200511251550.jAPFoIG1004593@porkchop.devel.redhat.com>

 

 
Updated Packages:

apr-0.9.7-3
-----------
* Thu Nov 24 2005 Joe Orton <jorton at redhat.com> 0.9.7-3
- use RTLD_DEEPBIND in apr_dso_open by default

coreutils-5.93-4
----------------
* Fri Nov 25 2005 Tim Waugh <twaugh at redhat.com> 5.93-4
- Rebuild to pick up new glibc *at functions.
- Apply runuser PAM patch from bug #173807.  Ship runuser PAM file.

* Mon Nov 14 2005 Dan Walsh <dwalsh at redhat.com> 5.93-3
- Remove multiple from su.pamd

crypto-utils-2.2-9
------------------
* Thu Nov 24 2005 Joe Orton <jorton at redhat.com> 2.2-9
- rebuild for new slang

kernel-2.6.14-1.1712_FC5
------------------------
* Fri Nov 25 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git4

* Thu Nov 24 2005 David Woodhouse <dwmw2 at redhat.com>
- Fix non-volatile register saving in ppc32 signal delivery
- Compile mambonet (IBM Cell sim network) as a module

newt-0.52.2-1
-------------
* Thu Nov 24 2005 Jindrich Novy <jnovy at redhat.com> - 0.52.2-1
- rebuild because of the new slang-2.0.5

* Tue Nov 22 2005 Petr Rockai <prockai at redhat.com> - 0.52.2-0
- new upstream version (minor fixes for the source tarball
  and build system)

* Fri Sep 30 2005 Petr Rockai <prockai at redhat.com> - 0.52.1-0
- revert bidi patch, objections by Jeremy Katz about
  anaconda breaking
- this version still only exists as a "ghastly" upstream tarball;
  the patches are now cleaned up and will be integrated into
  rhlinux cvs unless some more breakage akin to bidi occurs
- the if1close patch is now part of upstream tarball too

pup-0.1.7-1
-----------
* Thu Nov 24 2005 Jeremy Katz <katzj at redhat.com> - 0.1.7-1
- add back the details dialog which somehow got lost from the 
  glade file (#174125)

sudo-1.6.8p12-1
---------------
* Fri Nov 25 2005 Karel Zak <kzak at redhat.com> 1.6.8p12-1
- new upstream version 1.6.8p12

util-linux-2.13-0.11.pre6
-------------------------
* Fri Nov 25 2005 Karel Zak <kzak at redhat.com> 2.13-0.11.pre6
- update to upstream version 2.13-pre6
- fix #172203 - mount man page in RHEL4 lacks any info on cifs mount options

xorg-x11-xdm-1:0.99.3-6
-----------------------
* Thu Nov 24 2005 Mike A. Harris <mharris at redhat.com> 1:0.99.3-6
- Updated xdm.pamd to work with recent pam changes, and bumped the minimum
  pam requirement up to 0.78-0 for FC5 builds. (#170661)
- Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", as the xdm package
  puts files into /usr/lib/X11, so we have to make sure it is not a symlink.
- Removed "filesystem" package dependency, as xorg-x11-filesystem carries
  that dependency now, so it can be updated in one spot.
- Added missing "BuildRequires: pkgconfig".
- Added xdm-0.99.3-xdm-app-defaults-in-datadir.patch to force app-defaults
  files to install into _datadir instead of _libdir.
- Added xdm-0.99.3-xdm-scripts-in-configdir.patch to put the xdm scripts in
  _sysconfdir, and removed older xdm-0.99.3-xdm-configdir.patch which hacked
  up Makefile.in.  Fixes a typo that caused Xreset to not get installed
  properly also.

xsane-0.98a-1
-------------
* Thu Nov 24 2005 Nils Philippsen <nphilipp at redhat.com> 0.98a-1
- version 0.98a

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-7.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390x requires dmraid



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5



From jspaleta at gmail.com  Fri Nov 25 15:57:14 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 25 Nov 2005 10:57:14 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <4386E3D6.8050007@city-fan.org>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<4386E3D6.8050007@city-fan.org>
Message-ID: <604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com>

On 11/25/05, Paul Howarth <paul at city-fan.org> wrote:
> Joachim Frieben wrote:
> > It cannot be hard to use "yum" as a backend instead of
> > "up2date", so why start from scratch?
>
> Yum is already a backend for up2date, providing support (albeit slightly
> broken, at least in FC4) for repomd metadata.
uhm.... im pretty sure up2date has its own implementation of repodata parsing.
It's difficult to call yum a "backend" for up2date when up2date
doesn't use any of the yum codepath.  Pup on the other hand actually
uses yum python modules directly and in facts requires yum to be on
the system.  Moving forward as more useful functionality is dropped
into yum plugins its not going to be enough to just parse the
repodata, the gui tools is going to need to hook directly in to yum's
modules just as pup does.

-jef"2 steps forward 1 step back...doing the progress cha-cha"spaleta



From paul at city-fan.org  Fri Nov 25 16:01:09 2005
From: paul at city-fan.org (Paul Howarth)
Date: Fri, 25 Nov 2005 16:01:09 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<4386E3D6.8050007@city-fan.org>
	<604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com>
Message-ID: <43873545.4030403@city-fan.org>

Jeff Spaleta wrote:
> On 11/25/05, Paul Howarth <paul at city-fan.org> wrote:
> 
>>Joachim Frieben wrote:
>>
>>>It cannot be hard to use "yum" as a backend instead of
>>>"up2date", so why start from scratch?
>>
>>Yum is already a backend for up2date, providing support (albeit slightly
>>broken, at least in FC4) for repomd metadata.
> 
> uhm.... im pretty sure up2date has its own implementation of repodata parsing.
> It's difficult to call yum a "backend" for up2date when up2date
> doesn't use any of the yum codepath.

Sure about that?

$ rpm -ql up2date | xargs fgrep "from yum"
fgrep: /etc/sysconfig/rhn/up2date: Permission denied
fgrep: /etc/sysconfig/rhn/up2date-keyring.gpg: Permission denied
fgrep: /etc/sysconfig/rhn/up2date-uuid: Permission denied
/usr/share/rhn/up2date_client/repoBackends/yumRepo.py:        # heck, 
maybe even borrow the one from yum
/usr/share/rhn/up2date_client/repoBackends/yumRepo.py:        # heck, 
maybe even borrow the one from yum
/usr/share/rhn/up2date_client/sourcesConfig.py:        from yum import repos
/usr/share/rhn/up2date_client/up2dateComps.py:# most of this is from 
yum, yumcomps.py, # Copyright 2002 Duke University

"from yum import repos" looks like it's using yum directly to me.

Paul.



From dimi at lattica.com  Fri Nov 25 16:23:25 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 25 Nov 2005 11:23:25 -0500
Subject: status of up2date and rhn-applet
References: <1132852511.3748.7.camel@yoda.loki.me><50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr><4386E3D6.8050007@city-fan.org>
	<604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com>
Message-ID: <03c201c5f1dc$90912e60$b6491b31@td612671>

From: "Jeff Spaleta" <jspaleta at gmail.com>
> -jef"2 steps forward 1 step back...doing the progress cha-cha"spaleta

But we have to make sure we're on time <g>

-- 
Dimi "Software is like Sex^H^H^HDancing" Paun.



From jspaleta at gmail.com  Fri Nov 25 16:33:18 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Fri, 25 Nov 2005 11:33:18 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <43873545.4030403@city-fan.org>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<4386E3D6.8050007@city-fan.org>
	<604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com>
	<43873545.4030403@city-fan.org>
Message-ID: <604aa7910511250833y2ec78b49s20a6ec6669cdf7e9@mail.gmail.com>

On 11/25/05, Paul Howarth <paul at city-fan.org> wrote:
> "from yum import repos" looks like it's using yum directly to me.

thats just to find the definitions of the repositories configured in yum.
That is NOT reusing the metadata parsing codepath that yum has.
Hell, its not even reusing yum's parsing of the repo definitions...
its just grabbing the definitions that yum sees without even doing
yum's variable substitutions..which is a primary unfixed bug that
makes up2date difficult for people to use in fc4 using
fedora-release's default configs for updates.

Marvel at /usr/share/rhn/up2date_client/sourcesConfig.py and find:
 #FIXME:
 releasever = "3"


-jef



From i.pilcher at comcast.net  Fri Nov 25 16:36:29 2005
From: i.pilcher at comcast.net (Ian Pilcher)
Date: Fri, 25 Nov 2005 10:36:29 -0600
Subject: status of up2date and rhn-applet
In-Reply-To: <4386E3D6.8050007@city-fan.org>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<4386E3D6.8050007@city-fan.org>
Message-ID: <dm7eid$pk5$2@sea.gmane.org>

Paul Howarth wrote:
> Yum is already a backend for up2date, providing support (albeit slightly
> broken, at least in FC4) for repomd metadata. It's a shame rhn-applet is
> completely borked as far as repomd support (the default out-of-the-box
> configuration) is concerned.

Much more of a shame, IMO, that no one was ever willing to fix the
applet for FC4.

-- 
========================================================================
Ian Pilcher                                        i.pilcher at comcast.net
========================================================================



From dimi at lattica.com  Fri Nov 25 16:43:01 2005
From: dimi at lattica.com (Dimi Paun)
Date: Fri, 25 Nov 2005 11:43:01 -0500
Subject: status of up2date and rhn-applet
References: <1132852511.3748.7.camel@yoda.loki.me><50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr><4386E3D6.8050007@city-fan.org><604aa7910511250757s738fefe1p818d1562fb6e0b07@mail.gmail.com><43873545.4030403@city-fan.org>
	<604aa7910511250833y2ec78b49s20a6ec6669cdf7e9@mail.gmail.com>
Message-ID: <040201c5f1df$4d60d5c0$b6491b31@td612671>

From: "Jeff Spaleta" <jspaleta at gmail.com>
> Marvel at /usr/share/rhn/up2date_client/sourcesConfig.py and find:
>  #FIXME:
>  releasever = "3"

Thanks for pointing this out, I had a friend the other day
upgrade his box to FC4 (at my recommendation), and had trouble
using up2date. He couldn't figure out where the 3 was coming
from! I didn't look into the problem, I just suggested using
up2date instead. This is rather counterintuitive...

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From jkeating at j2solutions.net  Fri Nov 25 16:55:26 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Fri, 25 Nov 2005 08:55:26 -0800
Subject: Summary of FC5test1 vulnerabilities
In-Reply-To: <0511251349500.28294@dell1.moose.awe.com>
References: <0511251349500.28294@dell1.moose.awe.com>
Message-ID: <1132937726.2888.2.camel@yoda.loki.me>

On Fri, 2005-11-25 at 15:15 +0000, Mark J Cox wrote:
> The method behind the audit can be found in the details of our
> original FC4 audit: http://people.redhat.com/mjc/20050505-fc4
> 
> Questions or corrections to secalert at redhat.com
> 

Wow this is awesome.  Thanks Mark!

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From thomas at apestaart.org  Fri Nov 25 19:02:47 2005
From: thomas at apestaart.org (Thomas Vander Stichele)
Date: Fri, 25 Nov 2005 20:02:47 +0100
Subject: mach 0.4.8 released
Message-ID: <1132945367.29164.78.camel@thomas.amantes>

Hi everyone,

mach 0.4.8 - "More Than One" was just released.

Mach should now correctly handle multiple users in the mach group
doing sequential builds.  It also has a hack for libselinux, to make,
among other things, FC3-on-FC4 work.


WHAT IS IT
----------
mach allows you to set up clean roots from scratch for any distribution or
distribution variation supported.

This clean build root can be used to run jailed services, create disk images,
or build clean packages.

WHERE TO GET IT
---------------
http://thomas.apestaart.org/projects/mach/

Enjoy,
Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Take my hands between your knees
Once inside
I'll only take the things that shine
You always said those things were mine
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/





From chasd at silveroaks.com  Fri Nov 25 19:07:09 2005
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Fri, 25 Nov 2005 13:07:09 -0600
Subject: Summary of FC5test1 vulnerabilities
In-Reply-To: <20051125170004.9CF9872FB9@hormel.redhat.com>
References: <20051125170004.9CF9872FB9@hormel.redhat.com>
Message-ID: <13ead7df45cf1aabfec88c1ef937dcab@silveroaks.com>

> With the release of FC5test1 we've done an audit of possible (known,
> public) vulnerabilities from 20030101 to date that are in packages part
> of FC5test1.

May I assume this has not been done for packages in Extras ?
A quick scan of
<http://cvs.fedora.redhat.com/viewcvs/*checkout*/fedora-security/audit/ 
fc5?root=fedora>
produced no packages in Extras.
I could not find a reference to a security/patch/errata policy relating  
to Extras at
<http://fedoraproject.org/wiki/Extras>

Errata for Extras packages is driven by the ( non-RH ) community and  
the package owner, not by the RH security team?
This is OK, but it means that I ( as a community member ) will need  
make more of an effort to stay on top of security issues in an Extras  
package on my systems. I can rely on established infrastructure to stay  
on top of those issues for packages in Core. Extras packages will seem  
a bit more like applications installed via tarball, or self-packaged.


Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/
824 17th Street, Moline  IL  61265



From nicolas.mailhot at laposte.net  Fri Nov 25 19:25:49 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 25 Nov 2005 20:25:49 +0100
Subject: Initializing hardware... slow
In-Reply-To: <4386FF38.8030104@redhat.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>
Message-ID: <1132946790.3578.1.camel@rousalka.dyndns.org>

Le vendredi 25 novembre 2005 ? 13:10 +0100, Harald Hoyer a ?crit :
> Bojan Smojver wrote:
> > Is that just my box, or did this part of the boot become painfully slow 
> > as of recent? It takes around half a minute to do "storage hardware 
> > audio" thingy. Has anyone else noticed something like that?
> > 
> 
> could you please try:
> 
> ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm

Everything is slow not just boot there. Just like if someone stole the
CPU one night and replaced it with a slower one. And this version of
udev does not change anything.

(sharpest difference in firefox : clicking on any link takes several
seconds instead of being almost instantaneous before)

I suspect the kernel more than anything 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/20051125/ead11119/attachment.sig>

From sundaram at redhat.com  Fri Nov 25 19:33:12 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 01:03:12 +0530
Subject: Initializing hardware... slow
In-Reply-To: <1132946790.3578.1.camel@rousalka.dyndns.org>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>	<4386FF38.8030104@redhat.com>
	<1132946790.3578.1.camel@rousalka.dyndns.org>
Message-ID: <438766F8.5070807@redhat.com>

Hi

>Everything is slow not just boot there. Just like if someone stole the
>CPU one night and replaced it with a slower one. And this version of
>udev does not change anything.
>
>(sharpest difference in firefox : clicking on any link takes several
>seconds instead of being almost instantaneous before)
>
>I suspect the kernel more than anything else.
>
>  
>
Would you try running bootchart on it (http://bootchart.sf.net) and 
produce the output? . That might help

regards
Rahul



From sundaram at redhat.com  Fri Nov 25 19:48:32 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 01:18:32 +0530
Subject: Summary of FC5test1 vulnerabilities
In-Reply-To: <13ead7df45cf1aabfec88c1ef937dcab@silveroaks.com>
References: <20051125170004.9CF9872FB9@hormel.redhat.com>
	<13ead7df45cf1aabfec88c1ef937dcab@silveroaks.com>
Message-ID: <43876A90.6000109@redhat.com>

Hi

>
> May I assume this has not been done for packages in Extras ?

Package maintainers in both Fedora  Core and Extras repository are 
responsible for the security of packages they develop/maintain. However 
Red Hat security response team does not keep track of all security 
issues in Fedora Extras repository unlike Fedora Core to my understanding.

>
> I could not find a reference to a security/patch/errata policy 
> relating  to Extras at
> <http://fedoraproject.org/wiki/Extras>
>
There was a discussion here 
https://www.redhat.com/archives/fedora-extras-list/2005-September/msg00393.html. 


>
> This is OK, but it means that I ( as a community member ) will need  
> make more of an effort to stay on top of security issues in an Extras  
> package on my systems. I can rely on established infrastructure to 
> stay  on top of those issues for packages in core. Extras packages 
> will seem  a bit more like applications installed via tarball, or 
> self-packaged.
>
The package maintainers keep track of the security issues. There is no 
reason not to trust the community packagers to do a less than excellent 
job with it. After all those were the one who volunteered to maintain it 
in the first place. Additional eyes keeping track of potential security 
issues is helpful and you can notify the respective maintainers of any 
vulnerabilities through http://bugzilla.redhat.com,  both for Fedora 
Core and Extras. Details available at 
http://fedoraproject.org/wiki/Security. All of Fedora Extras packages 
takes advantage of various features in Fedora Core including 
Exec-shield, FORTIFY_SOURCE fstack-protector etc in addition to SELinux 
capabilities.  If its a public vulnerability you can also post to either 
the Fedora-devel (Core packages) or Fedora Extras list.

Even setting aside all the security features,  there are several 
advantages to using Fedora Extras in favor of tarballs or self packaged 
RPMS.  Fedora Extras undergoes a package review process to ensure 
consistency and better integration with Fedora according to the 
specified guidelines available http://fedoraproject.org/wiki/Extras. 
The  repository is also enabled by default from Fedora Core 4 onwards. 
Future releases might even offer the capability to install these 
packages using Anaconda and so on. Hope that helps.

regards
Rahul



From nicolas.mailhot at laposte.net  Fri Nov 25 20:37:05 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 25 Nov 2005 21:37:05 +0100
Subject: Initializing hardware... slow
In-Reply-To: <438766F8.5070807@redhat.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>
	<1132946790.3578.1.camel@rousalka.dyndns.org>
	<438766F8.5070807@redhat.com>
Message-ID: <1132951026.11004.0.camel@rousalka.dyndns.org>

Le samedi 26 novembre 2005 ? 01:03 +0530, Rahul Sundaram a ?crit :
> Hi
> 
> >Everything is slow not just boot there. Just like if someone stole the
> >CPU one night and replaced it with a slower one. And this version of
> >udev does not change anything.
> >
> >(sharpest difference in firefox : clicking on any link takes several
> >seconds instead of being almost instantaneous before)
> >
> >I suspect the kernel more than anything else.
> >
> >  
> >
> Would you try running bootchart on it (http://bootchart.sf.net) and 
> produce the output? . That might help

I doubt it would help - the slowdown is not limited to the boot process.
Do you think it will find anything useful ?

-- 
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/20051125/e046c922/attachment.sig>

From sundaram at redhat.com  Fri Nov 25 20:55:58 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 02:25:58 +0530
Subject: Initializing hardware... slow
In-Reply-To: <1132951026.11004.0.camel@rousalka.dyndns.org>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>	<4386FF38.8030104@redhat.com>	<1132946790.3578.1.camel@rousalka.dyndns.org>	<438766F8.5070807@redhat.com>
	<1132951026.11004.0.camel@rousalka.dyndns.org>
Message-ID: <43877A5E.1050006@redhat.com>

Hi

>
>I doubt it would help - the slowdown is not limited to the boot process.
>Do you think it will find anything useful ?
>
>  
>
Its worth trying. Just a suggestion.

regards
Rahul



From nicolas.mailhot at laposte.net  Fri Nov 25 21:13:25 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Fri, 25 Nov 2005 22:13:25 +0100
Subject: Initializing hardware... slow
In-Reply-To: <43877A5E.1050006@redhat.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>	<1132946790.3578.1.camel@rousalka.dyndns.org>
	<438766F8.5070807@redhat.com>
	<1132951026.11004.0.camel@rousalka.dyndns.org>
	<43877A5E.1050006@redhat.com>
Message-ID: <1132953245.3032.6.camel@rousalka.dyndns.org>

Le samedi 26 novembre 2005 ? 02:25 +0530, Rahul Sundaram a ?crit :
> Hi
> 
> >
> >I doubt it would help - the slowdown is not limited to the boot process.
> >Do you think it will find anything useful ?
> >
> >  
> >
> Its worth trying. Just a suggestion.

Seems related to network calls

ntp startup is sloooow
httpd startup -> same
gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
exposes the well-documented stupidity of having gnome sound depend on
kde subsystems)

I'll try bootstart tomorrow - rawhide today is so broken I'm pretty
disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
something else now I'll start writing rude things on the list.

I don't mind a new bug a day but several in a row like this before I've
even finished investigating the first one is too much for me. You got to
love the destabelizing effect of test 1 - every Red Hat packager seems
to have postponed his experimental packages for after test1 was
released.

-- 
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/20051125/fea51044/attachment.sig>

From sundaram at redhat.com  Fri Nov 25 21:48:31 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 03:18:31 +0530
Subject: Initializing hardware... slow
In-Reply-To: <1132953245.3032.6.camel@rousalka.dyndns.org>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>	<4386FF38.8030104@redhat.com>	<1132946790.3578.1.camel@rousalka.dyndns.org>	<438766F8.5070807@redhat.com>	<1132951026.11004.0.camel@rousalka.dyndns.org>	<43877A5E.1050006@redhat.com>
	<1132953245.3032.6.camel@rousalka.dyndns.org>
Message-ID: <438786AF.1080205@redhat.com>

Hi

>I don't mind a new bug a day but several in a row like this before I've
>even finished investigating the first one is too much for me. You got to
>love the destabelizing effect of test 1 - every Red Hat packager seems
>to have postponed his experimental packages for after test1 was
>released.
>  
>
If they did that, I wouldnt be too suprised with it as long as we 
managed to resolve any regressions before the next test release. Anyone 
up for a bug triaging day to ensure that?

http://fedoraproject.org/wiki/BugZappers.

regards
Rahul



From mandreiana.lists at gmail.com  Fri Nov 25 21:56:01 2005
From: mandreiana.lists at gmail.com (Marius Andreiana)
Date: Fri, 25 Nov 2005 23:56:01 +0200
Subject: 'everything' install option in FC5test1
Message-ID: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>

Hi,

Please see bug 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174092

It seems that with Everything install option gone in FC5 test1, one
cannot install all packages from CD. I'm still downloading it so I
cannot test by myself yet, but Jeremy's reply suggests it won't be added
back (how are the package groups handled with multiple repositories?).

In previous Fedora versions, there was also the Details button for a
package group, is this gone too? There one could have manually selected
additional packages, and this is a solution.

If both these options are gone, then should the packages which aren't
installed by default if all groups are selected be moved to Fedora
Extras?

Thanks,
-- 
Marius Andreiana



From petro at mail.ru  Fri Nov 25 21:51:29 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 26 Nov 2005 00:51:29 +0300
Subject: Cannot parse color "black"
In-Reply-To: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
References: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
Message-ID: <Pine.LNX.4.64.0511260048360.10836@lemenkov.com>

On Thu, 24 Nov 2005, Build System wrote:

> xorg-x11-apps-0.99.2-4
> xorg-x11-drivers-0.99.2-4
> xorg-x11-filesystem-0.99.2-3
> xorg-x11-fonts-0.99.0-7
> xorg-x11-server-0.99.3-7
> xorg-x11-server-utils-0.99.2-5
> xorg-x11-xbitmaps-0.99.1-4
> xorg-x11-xsm-0.99.2-4
> xorg-x11-xtrans-devel-0.99.2-2

Hello, All!
After this update, my wm tells that it can't parse colors (see attached 
log).

-- 
With best regards, Peter Lemenkov.
-------------- next part --------------
xauth:  creating new authority file /home/petro/.serverauth.5503


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 CVS repository.
See http://wiki.x.org/wiki/CvsPage for CVS access instructions.

X Window System Version 6.99.99.902 (7.0.0 RC 2)
Release Date: 09 November 2005
X Protocol Version 11, Revision 0, Release 6.99.99.902
Build Operating System:Linux 2.6.9-1.906_ELsmp i686Red Hat, Inc.
Current Operating System: Linux Petro 2.6.14-1.1709_FC5 #1 Wed Nov 23 15:45:19 EST 2005 i686
Build Date: 23 November 2005
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Module Loader present
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: Fri Nov 25 20:36:50 2005
(==) Using config file: "/etc/X11/xorg.conf"
Couldn't open RGB_DB '/usr/lib/X11/rgb'
dlopen: /usr/lib/xorg/modules/libGLcore.so: undefined symbol: __glXLastContext
(EE) Failed to load /usr/lib/xorg/modules/libGLcore.so
(EE) Failed to load module "GLcore" (loader failed, 7)
urxvtd: no process killed
urxvtd: no process killed
xcompmgr: no process killed
xcompmgr: no process killed
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "grey"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "grey"
Cannot parse color "slategrey"
[FVWM][pixmapPath_function]: <<ERROR>> PixmapPath is deprecated since 2.3.0; use ImagePath instead.
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "steelblue"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "steelblue"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "Black"
[FvwmPager][FlocaleGetFontSet]: (5x8) Missing font charsets:
JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
Cannot parse color "black"
Cannot parse color "white"
Cannot parse color "steelblue"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "gray"
Cannot parse color "black"
Cannot parse color "black"
Cannot parse color "royalblue"
Cannot parse color "black"
Cannot parse color "steelblue"
X connection to :0.0 broken (explicit kill or server shutdown).

/usr/bin/xinit:  connection to X server lost.



waiting for X server to shut down FreeFontPath: FPE "unix/:7100" refcount is 2, should be 1; fixing.




From davej at redhat.com  Fri Nov 25 22:42:28 2005
From: davej at redhat.com (Dave Jones)
Date: Fri, 25 Nov 2005 17:42:28 -0500
Subject: apm in recent rawhide kernels
In-Reply-To: <20051124135634.576039b9@alkaid.lan>
References: <20051124135634.576039b9@alkaid.lan>
Message-ID: <20051125224228.GA18959@redhat.com>

On Thu, Nov 24, 2005 at 01:56:34PM +0100, Andreas Bierfert wrote:
 > Hi,
 > 
 > did I miss something or is the apm support missing from the recent devel
 > kernels? My laptop really is not happy about this ^^

No. But if you have an ACPI capable BIOS, then you'll need to 
pass 'acpi=off' in order to use apm.

		Dave



From mattdm at mattdm.org  Fri Nov 25 22:47:57 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 25 Nov 2005 17:47:57 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
Message-ID: <20051125224757.GA2973@jadzia.bu.edu>

On Fri, Nov 25, 2005 at 11:56:01PM +0200, Marius Andreiana wrote:
> In previous Fedora versions, there was also the Details button for a
> package group, is this gone too? There one could have manually selected
> additional packages, and this is a solution.
> If both these options are gone, then should the packages which aren't
> installed by default if all groups are selected be moved to Fedora
> Extras?

Did you notice the big disclaimer? The screen isn't done yet?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From chabotc at xs4all.nl  Fri Nov 25 23:11:40 2005
From: chabotc at xs4all.nl (Chris Chabot)
Date: Sat, 26 Nov 2005 00:11:40 +0100
Subject: Cannot parse color "black"
In-Reply-To: <Pine.LNX.4.64.0511260048360.10836@lemenkov.com>
Message-ID: <000a01c5f215$97f3cee0$9800000a@chabotc>

Yup had the same here, made my xterm go all invisible text on me :-)

-----Original Message-----
From: fedora-devel-list-bounces at redhat.com
[mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Peter Lemenkov
Sent: Friday, November 25, 2005 22:51
To: fedora-devel-list at redhat.com
Cc: fedora-test-list at redhat.com
Subject: Cannot parse color "black"

On Thu, 24 Nov 2005, Build System wrote:

> xorg-x11-apps-0.99.2-4
> xorg-x11-drivers-0.99.2-4
> xorg-x11-filesystem-0.99.2-3
> xorg-x11-fonts-0.99.0-7
> xorg-x11-server-0.99.3-7
> xorg-x11-server-utils-0.99.2-5
> xorg-x11-xbitmaps-0.99.1-4
> xorg-x11-xsm-0.99.2-4
> xorg-x11-xtrans-devel-0.99.2-2

Hello, All!
After this update, my wm tells that it can't parse colors (see attached 
log).

-- 
With best regards, Peter Lemenkov.



From fedora-devel at stefan-neufeind.de  Sat Nov 26 00:21:55 2005
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Sat, 26 Nov 2005 01:21:55 +0100
Subject: About unofficial FC4-ISOs
Message-ID: <4387AAA3.70400@stefan-neufeind.de>

Hi,

I lately remembered the discussion about updated, unofficial FC4-ISOs
(aka "respins") and found the URL again on the mailinglist-archive:

http://fedora.isphuset.no/

Great job Hans did. I wonder if it might be possible to offer them
officially? Especially with FC4 some quite important install-problems
have been fixed, e.g. due to a more recent kernel. If Redhat does not
want to put the burden of additional traffic and disc-space on it's
servers and mirrors then maybe it would be possible to officially
validate the build distributed by Torrent and offer such a torrent
officially?

The service Hans offers is really, really great for the community.
However I see that for some people it might be a problem of trust
(security) to use ISOs from _some_ source. So in case Fedora might see a
chance to either bundle respins from time to time and distribute those
on torrent officially or validate the integrity of Hans' current ISOs
maybe they could declare them official FC4.2?


Kind regards,
 Stefan Neufeind, Germany



From mattdm at mattdm.org  Sat Nov 26 01:13:45 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 25 Nov 2005 20:13:45 -0500
Subject: About unofficial FC4-ISOs
In-Reply-To: <4387AAA3.70400@stefan-neufeind.de>
References: <4387AAA3.70400@stefan-neufeind.de>
Message-ID: <20051126011345.GA9865@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 01:21:55AM +0100, Stefan Neufeind wrote:
> Great job Hans did. I wonder if it might be possible to offer them
> officially? Especially with FC4 some quite important install-problems

With FC having such a short lifecycle, I don't think it's worth the work
it'd take -- FC5 is the updated FC4....

Also, while I'm sure the person doing this is completely good and honest,
Red Hat's lawyers would probably have to be more careful.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fedora-devel at stefan-neufeind.de  Sat Nov 26 01:23:46 2005
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Sat, 26 Nov 2005 02:23:46 +0100
Subject: About unofficial FC4-ISOs
In-Reply-To: <20051126011345.GA9865@jadzia.bu.edu>
References: <4387AAA3.70400@stefan-neufeind.de>
	<20051126011345.GA9865@jadzia.bu.edu>
Message-ID: <4387B922.8040307@stefan-neufeind.de>

Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 01:21:55AM +0100, Stefan Neufeind wrote:
> 
>>Great job Hans did. I wonder if it might be possible to offer them
>>officially? Especially with FC4 some quite important install-problems
> 
> With FC having such a short lifecycle, I don't think it's worth the work
> it'd take -- FC5 is the updated FC4....

I agree about the short lifecycle - I really like that for several
fields of use. But the idea of a respin was not about bundling big, new
releases - but the updates that are already shipped separately. I don't
know how much work Hans puts into bundling the ISOs - but maybe for
people with "inside-knowledge" it's not hard to bundle updated ISOs anyhow?

> Also, while I'm sure the person doing this is completely good and honest,
> Red Hat's lawyers would probably have to be more careful.

About declaring Hans' ISOs offical I agree. That's why I was thinking
about maybe bundling offical updated FC4-ISOs? And if not distributed
the official way, maybe it could be done on torrent.


Regards,
 Stefan



From mattdm at mattdm.org  Sat Nov 26 02:03:36 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Fri, 25 Nov 2005 21:03:36 -0500
Subject: About unofficial FC4-ISOs
In-Reply-To: <4387B922.8040307@stefan-neufeind.de>
References: <4387AAA3.70400@stefan-neufeind.de>
	<20051126011345.GA9865@jadzia.bu.edu>
	<4387B922.8040307@stefan-neufeind.de>
Message-ID: <20051126020336.GA11620@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 02:23:46AM +0100, Stefan Neufeind wrote:
> I agree about the short lifecycle - I really like that for several
> fields of use. But the idea of a respin was not about bundling big, new
> releases - but the updates that are already shipped separately. I don't
> know how much work Hans puts into bundling the ISOs - but maybe for
> people with "inside-knowledge" it's not hard to bundle updated ISOs anyhow?

It's not hard, but the quality control and distribution can add up to a
decent amount of work.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From bojan at rexursive.com  Sat Nov 26 02:31:14 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 26 Nov 2005 13:31:14 +1100
Subject: Cannot parse color "black"
In-Reply-To: <Pine.LNX.4.64.0511260048360.10836@lemenkov.com>
References: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
	<Pine.LNX.4.64.0511260048360.10836@lemenkov.com>
Message-ID: <1132972274.5032.0.camel@coyote.rexursive.com>

On Sat, 2005-11-26 at 00:51 +0300, Peter Lemenkov wrote:

> After this update, my wm tells that it can't parse colors (see attached 
> log).

Try:

RgbPath      "/usr/share/X11/rgb"

in /etc/X11/xorg.conf.

-- 
Bojan




From bojan at rexursive.com  Sat Nov 26 02:33:53 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 26 Nov 2005 13:33:53 +1100
Subject: Initializing hardware... slow
In-Reply-To: <1132953245.3032.6.camel@rousalka.dyndns.org>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>	<1132946790.3578.1.camel@rousalka.dyndns.org>
	<438766F8.5070807@redhat.com>
	<1132951026.11004.0.camel@rousalka.dyndns.org>
	<43877A5E.1050006@redhat.com>
	<1132953245.3032.6.camel@rousalka.dyndns.org>
Message-ID: <1132972433.5032.4.camel@coyote.rexursive.com>

On Fri, 2005-11-25 at 22:13 +0100, Nicolas Mailhot wrote:

> Seems related to network calls
> 
> ntp startup is sloooow
> httpd startup -> same
> gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
> exposes the well-documented stupidity of having gnome sound depend on
> kde subsystems)

How's your DNS? This could all be related to invalid DNS servers
in /etc/resolv.conf.

> I'll try bootstart tomorrow - rawhide today is so broken I'm pretty
> disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
> something else now I'll start writing rude things on the list.
> 
> I don't mind a new bug a day but several in a row like this before I've
> even finished investigating the first one is too much for me. You got to
> love the destabelizing effect of test 1 - every Red Hat packager seems
> to have postponed his experimental packages for after test1 was
> released.

If things like this make you upset, maybe you shouldn't be running
Rawhide. It is (unfortunately) not possible to find bugs without
delivering software to users.

-- 
Bojan



From wtogami at redhat.com  Sat Nov 26 02:45:54 2005
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 25 Nov 2005 21:45:54 -0500
Subject: About unofficial FC4-ISOs
In-Reply-To: <4387AAA3.70400@stefan-neufeind.de>
References: <4387AAA3.70400@stefan-neufeind.de>
Message-ID: <4387CC62.4030906@redhat.com>

Stefan Neufeind wrote:
> Hi,
> 
> I lately remembered the discussion about updated, unofficial FC4-ISOs
> (aka "respins") and found the URL again on the mailinglist-archive:
> 
> http://fedora.isphuset.no/
> 
> Great job Hans did. I wonder if it might be possible to offer them
> officially? Especially with FC4 some quite important install-problems
> have been fixed, e.g. due to a more recent kernel. If Redhat does not
> want to put the burden of additional traffic and disc-space on it's
> servers and mirrors then maybe it would be possible to officially
> validate the build distributed by Torrent and offer such a torrent
> officially?
> 
> The service Hans offers is really, really great for the community.
> However I see that for some people it might be a problem of trust
> (security) to use ISOs from _some_ source. So in case Fedora might see a
> chance to either bundle respins from time to time and distribute those
> on torrent officially or validate the integrity of Hans' current ISOs
> maybe they could declare them official FC4.2?
> 

If someone is going to respin the distro, they should at least fix the 
bug in syslinux that causes the kernel to crash immediately on most 
Pentium4 and higher Intel hardware.  That was probably the biggest 
screwup of the FC4 installer, as the 'garbage' workaround is not obvious 
and people think they simply can't install Fedora.

It is a different matter about making it "official".  I personally think 
we simply don't have time to deal with that and it is the best use of 
Red Hat's resources to work as hard as possible on the next release.  We 
  have barely a month between Test1 and Test2 release by the schedule, 
which is insanely demanding on our workload.

Almost anybody can offer a respin from a bittorrent.  The hard part is 
organizing the community so the right people work together on the right 
problems.  Simply updating the packages should not the primary goal of a 
respin.

Warren Togami
wtogami at redhat.com



From bojan at rexursive.com  Sat Nov 26 03:01:05 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sat, 26 Nov 2005 14:01:05 +1100
Subject: Initializing hardware... slow
In-Reply-To: <4386FF38.8030104@redhat.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>
Message-ID: <1132974065.2285.2.camel@coyote.rexursive.com>

On Fri, 2005-11-25 at 13:10 +0100, Harald Hoyer wrote:

> could you please try:
> 
> ftp://people.redhat.com/harald/udev/udev-075-5.src.rpm

This one is better _and_ worse. The "Initialising hardware" phase is
quick, but "Starting udev" takes about a minute. I'm attaching my dmesg,
lsmod and lspci output, if that helps at all.

This seems a bit worrying (from dmesg):
--------------------------
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
ali mixer 1 creating error.
--------------------------

-- 
Bojan
-------------- next part --------------
Linux version 2.6.14-1.1712_FC5 (bhcompile at tweety.build.redhat.com) (gcc version 4.0.2 20051109 (Red Hat 4.0.2-6)) #1 Fri Nov 25 02:31:02 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000002ef70000 (usable)
 BIOS-e820: 000000002ef70000 - 000000002ef7f000 (ACPI data)
 BIOS-e820: 000000002ef7f000 - 000000002ef80000 (ACPI NVS)
 BIOS-e820: 000000002ef80000 - 000000002f000000 (reserved)
 BIOS-e820: 000000003ef80000 - 000000003f000000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
751MB LOWMEM available.
Using x86 segment limits to approximate NX protection
On node 0 totalpages: 192368
  DMA zone: 4096 pages, LIFO batch:2
  DMA32 zone: 0 pages, LIFO batch:2
  Normal zone: 188272 pages, LIFO batch:64
  HighMem zone: 0 pages, LIFO batch:2
DMI 2.3 present.
ACPI: RSDP (v000 PTLTD                                 ) @ 0x000f6ae0
ACPI: RSDT (v001 PTLTD    RSDT   0x06040000  LTP 0x00000000) @ 0x2ef78e5c
ACPI: FADT (v001 ATI    Salmon   0x06040000 ATI  0x000f4240) @ 0x2ef7ef64
ACPI: BOOT (v001 PTLTD  $SBFTBL$ 0x06040000  LTP 0x00000001) @ 0x2ef7efd8
ACPI: DSDT (v001    ATI MS2_1535 0x06040000 MSFT 0x0100000e) @ 0x00000000
ACPI: PM-Timer IO Port: 0x8008
Allocating PCI resources starting at 40000000 (gap: 3f000000:c0f80000)
Built 1 zonelists
Kernel command line: ro root=LABEL=/ resume2=swap:/dev/hda4
mapped APIC to ffffd000 (015e6000)
Initializing CPU#0
CPU 0 irqstacks, hard=c0427000 soft=c0426000
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 1993.777 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 757416k/769472k available (2213k kernel code, 11512k reserved, 797k data, 188k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3994.26 BogoMIPS (lpj=7988538)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebf9ff 00000000 00000000 00000000 00000400 00000000 00000000
CPU: After vendor identify, caps: bfebf9ff 00000000 00000000 00000000 00000400 00000000 00000000
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 256K
CPU: After all inits, caps: bfebf1ff 00000000 00000000 00000080 00000400 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU0: Thermal monitoring enabled
mtrr: v2.0 (20020519)
CPU: Intel Mobile Intel(R) Celeron(R) CPU 2.00GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0420)
checking if image is initramfs... it is
Freeing initrd memory: 998k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfd89b, last bus=2
PCI: Using configuration type 1
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 8000-803f claimed by ali7101 ACPI
PCI quirk: region 8040-805f claimed by ali7101 SMB
Boot video device is 0000:01:05.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Link [LNK0] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK1] (IRQs 7 *10)
ACPI: PCI Interrupt Link [LNK2] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK3] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK4] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 7 *11)
ACPI: PCI Interrupt Link [LNK6] (IRQs 7 10) *0, disabled.
ACPI: PCI Interrupt Link [LNK7] (IRQs *5)
ACPI: PCI Interrupt Link [LNK8] (IRQs 7 *10)
ACPI: Embedded Controller [EC0] (gpe 24)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:06: ioport range 0x40b-0x40b has been reserved
pnp: 00:06: ioport range 0x480-0x48f has been reserved
pnp: 00:06: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:06: ioport range 0x4d6-0x4d6 has been reserved
pnp: 00:06: ioport range 0x8000-0x807f could not be reserved
PCI: Bridge: 0000:00:01.0
  IO window: 9000-9fff
  MEM window: d4300000-d43fffff
  PREFETCH window: dc000000-dfffffff
PCI: Bus 2, cardbus bridge: 0000:00:0a.0
  IO window: 00001800-000018ff
  IO window: 00001c00-00001cff
  PREFETCH window: 40000000-41ffffff
  MEM window: 42000000-43ffffff
PCI: Enabling device 0000:00:0a.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK5] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNK5] -> GSI 11 (level, low) -> IRQ 11
Simple Boot Flag at 0x37 set to 0x1
audit: initializing netlink socket (disabled)
audit(1132973702.324:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
Initializing Cryptographic API
ksign: Installing public key data
Loading keyring
- Added public key 69B97DAAE40CBD7D
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
Activating ISA DMA hang workarounds.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
usbcore: registered new driver libusual
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
ACPI: Processor [CPU0] (supports 8 throttling states)
ACPI: Thermal Zone [THRM] (49 C)
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected Ati IGP330/340/345/350/M chipset
agpgart: AGP aperture is 64M @ 0xd8000000
PNP: PS/2 Controller [PNP0303:KBC0,PNP0f13:MSE0] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 32 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:0b: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
PCI: Enabling device 0000:00:08.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNK6] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNK6] -> GSI 10 (level, low) -> IRQ 10
0000:00:08.0: ttyS9 at I/O 0x1428 (irq = 10) is a 8250
0000:00:08.0: ttyS12 at I/O 0x1440 (irq = 10) is a 8250
0000:00:08.0: ttyS14 at I/O 0x1450 (irq = 10) is a 8250
0000:00:08.0: ttyS16 at I/O 0x1460 (irq = 10) is a 8250
0000:00:08.0: ttyS18 at I/O 0x1470 (irq = 10) is a 8250
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:00:10.0
ACPI: PCI Interrupt 0000:00:10.0[A]: no GSI
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0x2000-0x2007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0x2008-0x200f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: HITACHI_DK23EA-30, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA CD/DVD-ROM SD-C2612, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 58605120 sectors (30005 MB) w/2048KiB Cache, CHS=58140/16/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 < hda5 hda6 > hda4
hdc: ATAPI 24X DVD-ROM drive, 192kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
ide-floppy driver 0.99.newide
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNK5] -> GSI 11 (level, low) -> IRQ 11
Yenta: CardBus bridge found at 0000:00:0a.0 [103c:002a]
Yenta O2: res at 0x94/0xD4: 00/ea
Yenta O2: enabling read prefetch/write burst
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
mice: PS/2 mouse device common for all mice
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1310720 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
ACPI wakeup devices: 
PCI0 MDEM  LAN COM1  LID 
ACPI: (supports S0 S3 S4 S5)
Freeing unused kernel memory: 188k freed
Write protecting the kernel read-only data: 347k
input: AT Translated Set 2 keyboard as /class/input/input0
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
security:  3 users, 6 roles, 1046 types, 116 bools, 1 sens, 256 cats
security:  55 classes, 31353 rules
SELinux:  Completing initialization.
SELinux:  Setting up existing superblocks.
SELinux: initialized (dev hda2, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs
SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts
SELinux: initialized (dev devpts, type devpts), uses transition SIDs
SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts
SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
SELinux: initialized (dev proc, type proc), uses genfs_contexts
SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts
SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNK8] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNK8] -> GSI 10 (level, low) -> IRQ 10
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 10, io mem 0xd4000000
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
  originally by Donald Becker <becker at scyld.com>
  http://www.scyld.com/network/natsemi.html
  2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
natsemi eth0: NatSemi DP8381[56] at 0xd4004000 (0000:00:12.0), 00:0b:cd:17:ea:ac, IRQ 10, port TP.
ali15x3_smbus 0000:00:11.0: ALI15X3_smb region uninitialized - upgrade BIOS or use force_addr=0xaddr
ali15x3_smbus 0000:00:11.0: ALI15X3 not detected, module not inserted.
PCI: Enabling device 0000:00:06.0 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNK7] -> GSI 5 (level, low) -> IRQ 5
AC'97 1 does not respond - RESET
AC'97 1 access is not valid [0xffffffff], removing mixer.
ali mixer 1 creating error.
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: Lid Switch [LID]
ibm_acpi: IBM ThinkPad ACPI Extras v0.12a
ibm_acpi: http://ibm-acpi.sf.net/
ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel at redhat.com
cdrom: open failed.
EXT3 FS on hda2, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: initialized (dev hda1, type ext3), uses xattr
SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
SELinux: initialized (dev hda5, type ext3), uses xattr
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
SELinux: initialized (dev hda6, type ext3), uses xattr
Adding 947824k swap on /dev/hda4.  Priority:-1 extents:1 across:947824k
SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
eth0: DSPCFG accepted after 0 usec.
eth0: link up.
eth0: Setting full-duplex based on negotiated link capability.
SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
lp0: using parport0 (interrupt-driven).
lp0: console ready
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03a4be0(lo)
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present
serial8250: too much work for irq10
serial8250: too much work for irq10
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt Link [LNK0] enabled at IRQ 10
ACPI: PCI Interrupt 0000:01:05.0[A] -> Link [LNK0] -> GSI 10 (level, low) -> IRQ 10
[drm] Initialized radeon 1.19.0 20050911 on minor 0: 
mtrr: no more MTRRs available
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:05.0 into 4x mode
application mixer_applet2 uses obsolete OSS audio interface
-------------- next part --------------
00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP 340M] (rev 02)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Region 1: Memory at d4005000 (32-bit, prefetchable) [size=4K]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4

00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M] (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 99
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: d4300000-d43fffff
	Prefetchable memory behind bridge: dc000000-dfffffff
	Secondary status: 66Mhz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (20000ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d4000000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR+ <PERR+
	Latency: 64 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at 1000 [size=256]
	Region 1: Memory at d4001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
	Subsystem: ALi Corporation ALI M1533 Aladdin IV ISA Bridge
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [a0] Power Management version 1
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:08.0 Modem: ALi Corporation M5457 AC'97 Modem Controller (prog-if 00 [Generic])
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d4002000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at 1400 [size=256]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0a.0 CardBus bridge: O2 Micro, Inc. OZ601/6912/711E0 CardBus/SmartCardBus Controller
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at d4003000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 40000000-41fff000 (prefetchable)
	Memory window 1: 42000000-43fff000
	I/O window 0: 00001800-000018ff
	I/O window 1: 00001c00-00001cff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if fa)
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 1000ns max)
	Interrupt: pin A routed to IRQ 0
	Region 4: I/O ports at 2000 [size=16]
	Capabilities: [60] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 90 (2750ns min, 13000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at 2400 [size=256]
	Region 1: Memory at d4004000 (32-bit, non-prefetchable) [size=4K]
	[virtual] Expansion ROM at 44000000 [disabled] [size=64K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=320mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M (prog-if 00 [VGA])
	Subsystem: Hewlett-Packard Company: Unknown device 002a
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B+
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 66 (2000ns min), Cache Line Size 08
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at dc000000 (32-bit, prefetchable) [size=64M]
	Region 1: I/O ports at 9000 [size=256]
	Region 2: Memory at d4300000 (32-bit, non-prefetchable) [size=64K]
	[virtual] Expansion ROM at d4320000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=48 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
		Command: RQ=16 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x4
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

-------------- next part --------------
Module                  Size  Used by
radeon                108385  1 
drm                    71637  2 radeon
ipv6                  250785  12 
lp                     12937  0 
sunrpc                145533  1 
p4_clockmod             5321  0 
dm_mirror              22673  0 
dm_mod                 57177  1 dm_mirror
video                  16197  0 
ibm_acpi               25921  0 
button                  6609  0 
battery                 9541  0 
ac                      4933  0 
parport_pc             27781  1 
parport                35465  2 lp,parport_pc
floppy                 62085  0 
snd_ali5451            23885  1 
snd_ac97_codec         88161  1 snd_ali5451
snd_ac97_bus            2369  1 snd_ac97_codec
snd_seq_dummy           3781  0 
snd_seq_oss            31553  0 
snd_seq_midi_event      7105  1 snd_seq_oss
snd_seq                49489  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          9037  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            50417  0 
snd_mixer_oss          18113  1 snd_pcm_oss
snd_pcm                86853  3 snd_ali5451,snd_ac97_codec,snd_pcm_oss
i2c_ali1535             7621  0 
i2c_ali15x3             7877  0 
i2c_core               21697  2 i2c_ali1535,i2c_ali15x3
snd_timer              25029  2 snd_seq,snd_pcm
snd                    54437  11 snd_ali5451,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore               9761  1 snd
natsemi                26785  0 
snd_page_alloc         10825  1 snd_pcm
ohci_hcd               21853  0 
shpchp                 46433  0 
ext3                  130249  4 
jbd                    57941  1 ext3

From katzj at redhat.com  Sat Nov 26 05:28:26 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 00:28:26 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <e99d27470511250229x50ad26c5j@mail.gmail.com>
References: <1132799302.7912.4.camel@tiger>
	<55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
	<1132852511.3748.7.camel@yoda.loki.me>
	<e99d27470511250229x50ad26c5j@mail.gmail.com>
Message-ID: <1132982906.2860.21.camel@bree.local.net>

On Fri, 2005-11-25 at 11:29 +0100, Rudolf Kastl wrote:
> 2005/11/24, Jesse Keating <jkeating at j2solutions.net>:
> > On Thu, 2005-11-24 at 09:23 +0100, Joachim Frieben wrote:
> > > "up2date-gnome" is by far the most usable update tool to date.
> > > "pup" is really not on par in any respect. I really have no
> > > idea why people spent time on that one. The best would be to
> > > simply remove it. I do really hope that "up2date-gnome" will
> > > remain in the distro. If it uses "yum" under the hood that's
> > > ok. Concerning "rhn-applet" your right: it is already unusable
> > > in FC4. No reason to drop it though. It should get fixed unless
> > > somebody comes up with an alternative shiny new update notifier.
> > >
> >
> > Would you care to give some constructive feed back as to why you find
> > pup so intolerable in it's first release version?  What about
> > up2date-gnome did you like and would like to see in the standalone pup?
> Feature Requests for pup:
> 
> 1. Handling of Packagegroups for Groupwise updating

pup is going to be a very simple update UI -- group handling is more of
system-config-package's area and the plan is for it to be enhanced to
sit on top of yum as well.  That's actually my plan of what I'm mostly
working on next week.

> 2. Notification applet (maybe as external application may as internal
> feature... guess external would be preferred)

Yeah, some form of notification on new updates is definitely needed,
although exactly how we want to do that is currently a bit of an open
question.  The big thing is that we want to avoid some of the memory
usage "problems" that people perceived with rhn-applet

> 3. Repository Handling from UI (i liked the up2date behaviour to
> selectively enable and disable repos)

I'm not against this (the glade file actually has the button to bring up
such a dialog, it's just not currently enabled), but I'm mostly curious
what the use case is for it.  Why would you not want to get the
available updates for all configured repositories?  I can see wanting to
configure what repositories you use for getting software when installing
new stuff, but what's the use case for doing it while updating?

> 4. selectivly exluding packages by gui (clickable list with checkbox
> buttons maybe?)

You can currently exclude based on src.rpm -- hopefully we'll get
metadata regarding update advisories available before FC5's release so
that can be used as the granularity instead.  This is far more likely to
allow things to just work than selecting individual subpackages (and/or
architectures) of packages due to the interdependent nature.

> 5. all of the above stuff saveable into yum config files to have a
> consistent environment.

Anything we do as far repository changing will definitely involve just
modifying the existing yum config files, so no worries there.  In fact,
everything done now in pup should be following exactly the configuration
used by yum on the command-line.

> while i think that most of above suggestions arent really necassery
> for even an 1.0 release of the software and while i additionally think
> that some of the above stuff should probably go under an "advanced"
> tab, i think that some of the above mentioned stuff can be helpful to
> make package updates properly manageable from gui.

Hope this helps a bit in giving some idea of where we're going.  I need
to make an effort this weekend to sit down and actually write up at
least some basic stuff to be able to point to as some of these questions
have come up often enough that I want to be able to just point to a web
page with the answers :-)

Jeremy



From katzj at redhat.com  Sat Nov 26 05:39:07 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 00:39:07 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
Message-ID: <1132983547.2860.32.camel@bree.local.net>

On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
> "up2date-gnome" has a very clear, informative interface. You start with a
> channel windows that allows you review the available channels and to make
> your choice. Very nice, indeed. 

Why would you want to not download updates from all repositories you
have configured?  Or at least see what's available.  The fact that the
updates come from multiple repositories is a detail that I don't think
users really want to / should need to care about.

> Once the header information is downloaded, a
> concise but exhaustive package list is displayed, which from you obtain all
> interesting details like package name, previous version, current version,
> channel and so on. Furthermore, it's possible to resize the width of the
> individual columns. Even for a significant number of available packages, you
> keep an oversight of what is going on.

Some of the sizings and spacing still need work with pup, definitely.
That's the sort of modifications that are easy to make once the code is
working and thus it hasn't been high on my todo list.  File bugs and
we'll definitely see about getting to them as soon as we can.  

One thing that's fundamentally different with pup is that we're trying
to get away from the package being (necessarily) the point of
granularity.  The hope is that we can actually get the update
information available via the yum metadata so that we can instead
provide more useful update information such as --
  "New version of apache httpd daemon to fix security vulnerability foo"
and then have all of the packages which are a part of that advisory
grouped together rather than requiring you to know that you need all of
httpd, httpd-devel and mod_ssl as a bunch.  Since we don't have that
metadata currently available (and never will for the development tree
and probably also some other repositories), the fallback is to grouping
packages by source RPM.

>  After confirming the package
> selection you proceed to the clear and informative download window.
> Individual package download progress and total progress are displayed
> together with some info in the package that is currently downloaded. The
> same holds for the package installation step. 

We've been doing some hallway bantering about how to improve the
progress dialogs generally for all of anaconda, pup, and
system-config-packages as they all have the same basic problem.  You
both somewhat want to show the progress of each individual file as well
as the total progress.  I somewhat like the approach taken with nautilus
(try scp'ing a few hundred files with it) but want to do some more
investigation before committing to anything.  I'm sure I've opened it up
to the peanut gallery now :-)

> I also love the summary at the
> very end which lets you have a final look on which packages got upgraded.

I've always personally found this to be a bit of a waste and just
another click which isn't really needed -- I asked for updates, when
they're done, get out of my way :)

> And do not forget the neat red/grey coulour scheme :)
> "pup" with its greyish look and the strange doggy icon that does everything
> but fit the genuine Bluecurve icon style looks like the little, poor bother
> of big "up2date-gnome". 

Yeah, we need some graphic work, but that'll come in time.  I don't want
to have Diana spending a lot of time on graphics as we tweak things over
time.

> Its interface is cluttered, the package window only
> lets you see some packages at once. 

Yeah, the sizing needs to be tweaked some.  Trivial fixes to the glade
file :)

> There is little info on the available
> updates. In the main window, there is this boring "Updated ... packages
> available" message for every single package. I would call this redundancy at
> its best. If you want a bit more information you have to expand the "Update
> details" window. 

As I said above, we're planning to actually have actual update
information here that's even more useful here.  The text is mostly
placeholder for now... I'm open to suggestions for how to word in the
case where update advisories aren't available, because that will always
be a somewhat common occurrence. 

Cheers,

Jeremy



From davej at redhat.com  Sat Nov 26 05:48:31 2005
From: davej at redhat.com (Dave Jones)
Date: Sat, 26 Nov 2005 00:48:31 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1132983547.2860.32.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
Message-ID: <20051126054831.GA1938@redhat.com>

On Sat, Nov 26, 2005 at 12:39:07AM -0500, Jeremy Katz wrote:
 > On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
 > > "up2date-gnome" has a very clear, informative interface. You start with a
 > > channel windows that allows you review the available channels and to make
 > > your choice. Very nice, indeed. 
 > 
 > Why would you want to not download updates from all repositories you
 > have configured?  Or at least see what's available.  The fact that the
 > updates come from multiple repositories is a detail that I don't think
 > users really want to / should need to care about.

The last time it happened to me, when yum fails to contact one repo,
a 'yum update' fails completely. Ie, it fails for every repo, instead
of downloading updates from the repos that it _could_ contact.

If current yum has been fixed to work in the face of adversity,
then I agree, otherwise, the ability to easily disable a broken repo
is useful.

		Dave



From katzj at redhat.com  Sat Nov 26 05:50:26 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 00:50:26 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
Message-ID: <1132984226.2860.39.camel@bree.local.net>

On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
> It seems that with Everything install option gone in FC5 test1, one
> cannot install all packages from CD. I'm still downloading it so I
> cannot test by myself yet, but Jeremy's reply suggests it won't be added
> back (how are the package groups handled with multiple repositories?).

Everything is a bit of a disaster in a lot of ways.  Some people think
that it shouldn't include language-specific packages.  Some people think
it should.  With multiple repositories, should it include all of the
packages from all of the repositories?  What happens if there are
conflicts?  And that's in addition to mattdm's helpful comments in the
bug :)

> In previous Fedora versions, there was also the Details button for a
> package group, is this gone too? There one could have manually selected
> additional packages, and this is a solution.

As the screen says, it's just a temporary placeholder for now :)
Details will be coming back, although not exactly as it was before.

> If both these options are gone, then should the packages which aren't
> installed by default if all groups are selected be moved to Fedora
> Extras?

In a lot of cases, packages which aren't listed in the comps file at all
(or aren't a dependency of something) perhaps _should_ move to Extras.
In addition, I think there probably are packages which should move
somewhere into the comps file.  File bugs against comps for things that
should be listed and aren't.

Jeremy



From katzj at redhat.com  Sat Nov 26 05:54:23 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 00:54:23 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <20051126054831.GA1938@redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<20051126054831.GA1938@redhat.com>
Message-ID: <1132984463.2860.44.camel@bree.local.net>

On Sat, 2005-11-26 at 00:48 -0500, Dave Jones wrote:
> On Sat, Nov 26, 2005 at 12:39:07AM -0500, Jeremy Katz wrote:
>  > On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
>  > > "up2date-gnome" has a very clear, informative interface. You start with a
>  > > channel windows that allows you review the available channels and to make
>  > > your choice. Very nice, indeed. 
>  > 
>  > Why would you want to not download updates from all repositories you
>  > have configured?  Or at least see what's available.  The fact that the
>  > updates come from multiple repositories is a detail that I don't think
>  > users really want to / should need to care about.
> 
> The last time it happened to me, when yum fails to contact one repo,
> a 'yum update' fails completely. Ie, it fails for every repo, instead
> of downloading updates from the repos that it _could_ contact.
> 
> If current yum has been fixed to work in the face of adversity,
> then I agree, otherwise, the ability to easily disable a broken repo
> is useful.

How do you know that updating when a repository is broken is safe,
though?  If you have a local repository which shadows the main repo but
with packages with config changes, going back to base could completely
break your system.  While punt to the user may be sufficient for you or
for me (or pretty much everyone on this list), I don't think that it is
for the "typical" end-user.  

Jeremy



From davej at redhat.com  Sat Nov 26 06:01:24 2005
From: davej at redhat.com (Dave Jones)
Date: Sat, 26 Nov 2005 01:01:24 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1132984463.2860.44.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<20051126054831.GA1938@redhat.com>
	<1132984463.2860.44.camel@bree.local.net>
Message-ID: <20051126060124.GB1938@redhat.com>

On Sat, Nov 26, 2005 at 12:54:23AM -0500, Jeremy Katz wrote:
 > On Sat, 2005-11-26 at 00:48 -0500, Dave Jones wrote:
 > > On Sat, Nov 26, 2005 at 12:39:07AM -0500, Jeremy Katz wrote:
 > >  > On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
 > >  > > "up2date-gnome" has a very clear, informative interface. You start with a
 > >  > > channel windows that allows you review the available channels and to make
 > >  > > your choice. Very nice, indeed. 
 > >  > 
 > >  > Why would you want to not download updates from all repositories you
 > >  > have configured?  Or at least see what's available.  The fact that the
 > >  > updates come from multiple repositories is a detail that I don't think
 > >  > users really want to / should need to care about.
 > > 
 > > The last time it happened to me, when yum fails to contact one repo,
 > > a 'yum update' fails completely. Ie, it fails for every repo, instead
 > > of downloading updates from the repos that it _could_ contact.
 > > 
 > > If current yum has been fixed to work in the face of adversity,
 > > then I agree, otherwise, the ability to easily disable a broken repo
 > > is useful.
 > 
 > How do you know that updating when a repository is broken is safe,
 > though?  If you have a local repository which shadows the main repo but
 > with packages with config changes, going back to base could completely
 > break your system.  While punt to the user may be sufficient for you or
 > for me (or pretty much everyone on this list), I don't think that it is
 > for the "typical" end-user.  

it's arguable that that configuration is also not 'typical end-user' ;-)
Really, I think if someone goes far enough to setup shadow repos, they
should know what their doing enough to figure out what to do when
repo breakage occurs.

		Dave



From katzj at redhat.com  Sat Nov 26 06:09:31 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 01:09:31 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <20051126060124.GB1938@redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<20051126054831.GA1938@redhat.com>
	<1132984463.2860.44.camel@bree.local.net>
	<20051126060124.GB1938@redhat.com>
Message-ID: <1132985371.2860.48.camel@bree.local.net>

On Sat, 2005-11-26 at 01:01 -0500, Dave Jones wrote:
> On Sat, Nov 26, 2005 at 12:54:23AM -0500, Jeremy Katz wrote:
>  > On Sat, 2005-11-26 at 00:48 -0500, Dave Jones wrote:
>  > > On Sat, Nov 26, 2005 at 12:39:07AM -0500, Jeremy Katz wrote:
>  > >  > On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
>  > >  > > "up2date-gnome" has a very clear, informative interface. You start with a
>  > >  > > channel windows that allows you review the available channels and to make
>  > >  > > your choice. Very nice, indeed. 
>  > >  > 
>  > >  > Why would you want to not download updates from all repositories you
>  > >  > have configured?  Or at least see what's available.  The fact that the
>  > >  > updates come from multiple repositories is a detail that I don't think
>  > >  > users really want to / should need to care about.
>  > > 
>  > > The last time it happened to me, when yum fails to contact one repo,
>  > > a 'yum update' fails completely. Ie, it fails for every repo, instead
>  > > of downloading updates from the repos that it _could_ contact.
>  > > 
>  > > If current yum has been fixed to work in the face of adversity,
>  > > then I agree, otherwise, the ability to easily disable a broken repo
>  > > is useful.
>  > 
>  > How do you know that updating when a repository is broken is safe,
>  > though?  If you have a local repository which shadows the main repo but
>  > with packages with config changes, going back to base could completely
>  > break your system.  While punt to the user may be sufficient for you or
>  > for me (or pretty much everyone on this list), I don't think that it is
>  > for the "typical" end-user.  
> 
> it's arguable that that configuration is also not 'typical end-user' ;-)
> Really, I think if someone goes far enough to setup shadow repos, they
> should know what their doing enough to figure out what to do when
> repo breakage occurs.

I also worry about third party repos which change out core
packages :-/  

There are just things a number of things which can go wrong/strange if
you have repositories not available, which is why things do what they do
now[1]

Jeremy

[1] Okay, I'm all but certain that pup needs to give a better error
message when this occurs right now, but that's a side point ;-)



From laroche at redhat.com  Sat Nov 26 06:44:44 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 26 Nov 2005 07:44:44 +0100
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132984226.2860.39.camel@bree.local.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
Message-ID: <20051126064444.GA2987@dudweiler.stuttgart.redhat.com>

> In a lot of cases, packages which aren't listed in the comps file at all
> (or aren't a dependency of something) perhaps _should_ move to Extras.
> In addition, I think there probably are packages which should move
> somewhere into the comps file.  File bugs against comps for things that
> should be listed and aren't.

Shouldn't we start to accept also comps files for addon repositories?
We could also allow newer comps files in the updates repositories.

This would allow some more flexibility...

regards,

Florian La Roche



From petro at mail.ru  Sat Nov 26 08:13:07 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 26 Nov 2005 11:13:07 +0300
Subject: Cannot parse color "black"
In-Reply-To: <1132972274.5032.0.camel@coyote.rexursive.com>
References: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
	<Pine.LNX.4.64.0511260048360.10836@lemenkov.com>
	<1132972274.5032.0.camel@coyote.rexursive.com>
Message-ID: <Pine.LNX.4.64.0511261112190.2627@lemenkov.com>


>> After this update, my wm tells that it can't parse colors (see attached
>> log).

> Try:
>
> RgbPath      "/usr/share/X11/rgb"
>
> in /etc/X11/xorg.conf.


Works!
I added this line in "Files"-section.

-- 
With best regards, Peter Lemenkov.




From buildsys at redhat.com  Sat Nov 26 11:37:09 2005
From: buildsys at redhat.com (Build System)
Date: Sat, 26 Nov 2005 06:37:09 -0500
Subject: rawhide report: 20051126 changes
Message-ID: <200511261137.jAQBb9gO028776@porkchop.devel.redhat.com>

 

 
Updated Packages:

iptables-1.3.4-2
----------------
* Fri Nov 25 2005 Thomas Woerner <twoerner at redhat.com> 1.3.4-2
- fix for plugin problem: link with "gcc -shared" instead of "ld -shared" and 
  replace "_init" with "__attribute((constructor)) my_init"

kernel-2.6.14-1.1713_FC5
------------------------

openoffice.org-1:2.0.1-0.142.1.2
--------------------------------
* Thu Nov 17 2005 Caolan McNamara <caolanm at redhat.com> - 1:2.0.1-0.142.1
- next version
- rh#173775# crash on help under some circumstances

vim-1:6.4.000-4
---------------
* Fri Nov 25 2005 Karsten Hopp <karsten at redhat.de> 6.4.000-4
- enable tmpfile patch

* Thu Oct 27 2005 Karsten Hopp <karsten at redhat.de> 6.4.000-3
- test build

xorg-x11-server-0.99.3-9
------------------------
* Fri Nov 25 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-9
- Added "Requires: xorg-x11-drivers >= 0.99.2-4" as a dependency of the Xorg
  subpackage, to ensure that anaconda installs all of the drivers during OS
  installs and upgrades, as requested by Jeremy Katz.

* Fri Nov 25 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-8
- Added xorg-server-0.99.3-rgb.txt-dix-config-fix.patch which fixes the
  --with-rgb-path option to actually *work*.
- Updated libdrm dep to 1.0.5

* Wed Nov 23 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-7
- Update xorg-x11-server-utils dep to 0.99.2-5 to ensure rgb.txt is installed
  in correct location - _datadir/X11/rgb
- Added --with-rgb-path configure option to specify _datadir/X11/rgb so the
  X server finds the rgb.txt database properly, for bugs (#173453, 173435,
  173428, 173483, 173734, 173737, 173594)
- Added xorg-server-0.99.3-fbmmx-fix-for-non-SSE-cpu.patch to prevent SSE/MMX
  code from being activated on non-capable VIA CPU. (#173384,fdo#5093)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for s390
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390 requires dmraid



Broken deps for s390x
----------------------------------------------------------
	mkinitrd - 5.0.11-1.s390x requires dmraid



Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5




To: pjones at REDHAT.COM
Cc: heinzm at REDHAT.COM
Subject: Broken dependencies: mkinitrd




mkinitrd has broken dependencies in the development tree:
On s390x:
	mkinitrd - 5.0.11-1.s390x requires dmraid
On s390:
	mkinitrd - 5.0.11-1.s390 requires dmraid
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,quintela at REDHAT.COM
Subject: Broken dependencies: cman-kernel




cman-kernel has broken dependencies in the development tree:
On i386:
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
On x86_64:
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
On i386:
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
Please resolve this as soon as possible.



To: petersen at REDHAT.COM
Cc: 
Subject: Broken dependencies: emacs




emacs has broken dependencies in the development tree:
On ppc64:
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: 
Subject: Broken dependencies: dlm




dlm has broken dependencies in the development tree:
On ppc:
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
On ppc64:
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
Please resolve this as soon as possible.



To: devel_orphan at REDHAT.COM
Cc: davej at REDHAT.COM,quintela at REDHAT.COM
Subject: Broken dependencies: gnbd-kernel




gnbd-kernel has broken dependencies in the development tree:
On x86_64:
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
On i386:
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
On i386:
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,quintela at REDHAT.COM
Subject: Broken dependencies: dlm-kernel




dlm-kernel has broken dependencies in the development tree:
On i386:
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
On x86_64:
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
On i386:
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
Please resolve this as soon as possible.



To: devel_orphan at REDHAT.COM
Cc: 
Subject: Broken dependencies: gnbd




gnbd has broken dependencies in the development tree:
On ppc:
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11
On ppc64:
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: 
Subject: Broken dependencies: cman




cman has broken dependencies in the development tree:
On ppc64:
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
On ppc:
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
Please resolve this as soon as possible.



To: jbrassow at REDHAT.COM
Cc: davej at REDHAT.COM,quintela at REDHAT.COM
Subject: Broken dependencies: GFS-kernel




GFS-kernel has broken dependencies in the development tree:
On i386:
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
On i386:
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
On x86_64:
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
Please resolve this as soon as possible.



To: lhh at REDHAT.COM
Cc: jbrassow at REDHAT.COM
Subject: Broken dependencies: rgmanager




rgmanager has broken dependencies in the development tree:
On ia64:
	rgmanager - 1.9.31-3.ia64 requires ccs
Please resolve this as soon as possible.




From jfrieben at freesurf.fr  Sat Nov 26 12:12:51 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 26 Nov 2005 13:12:51 +0100 (CET)
Subject: status of up2date and rhn-applet
In-Reply-To: <1132983547.2860.32.camel@bree.local.net>
References: <1132983547.2860.32.camel@bree.local.net>
Message-ID: <13410.194.94.224.254.1133007171.squirrel@arlette.freesurf.fr>

>
> Why would you want to not download updates from all repositories you
> have configured?  Or at least see what's available.  The fact that the
> updates come from multiple repositories is a detail that I don't think
> users really want to / should need to care about.
>

Because it gives more control to the user as most other issues pointed
out by me. He might use "updates-testing" but only from time to time
and at least want to know that package "xyz" comes from channel "A" and
not from channel "B". The same applies to 3rd party repositories.
With "pup", you feel like driving a car without safety belt.

>
> Some of the sizings and spacing still need work with pup, definitely.
> That's the sort of modifications that are easy to make once the code is
> working and thus it hasn't been high on my todo list.  File bugs and
> we'll definitely see about getting to them as soon as we can.
>

Great, but that's even more than I requested. However, "up2date-gnome"
does an excellent job at all this right now.

>
> Yeah, the sizing needs to be tweaked some. Trivial fixes to the glade
> file :)
>

Ditto.

It seems that you basically agree on most of my complaints. Anyway,
I really still do not understand why you do not want to continue to
use a proven, excellent application that has been around for years
already. Red Hat developers put some brain into its development too.
right now, I do not know about any substantial argument to drop
"up2date-gnome" - that's all. Guess, it's simply a marketing issue
of making a sharper distinction between RHEL and FC.




From bernd.bartmann at gmail.com  Sat Nov 26 13:21:18 2005
From: bernd.bartmann at gmail.com (Bernd Bartmann)
Date: Sat, 26 Nov 2005 14:21:18 +0100
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132984226.2860.39.camel@bree.local.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
Message-ID: <6c18a4f0511260521v3a6bd94x7867f2ac03de432d@mail.gmail.com>

On 11/26/05, Jeremy Katz <katzj at redhat.com> wrote:
> On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
> > It seems that with Everything install option gone in FC5 test1, one
> > cannot install all packages from CD. I'm still downloading it so I
> > cannot test by myself yet, but Jeremy's reply suggests it won't be added
> > back (how are the package groups handled with multiple repositories?).
>
> Everything is a bit of a disaster in a lot of ways.  Some people think
> that it shouldn't include language-specific packages.  Some people think
> it should.  With multiple repositories, should it include all of the
> packages from all of the repositories?  What happens if there are
> conflicts?  And that's in addition to mattdm's helpful comments in the
> bug :)
>
> > In previous Fedora versions, there was also the Details button for a
> > package group, is this gone too? There one could have manually selected
> > additional packages, and this is a solution.
>
> As the screen says, it's just a temporary placeholder for now :)
> Details will be coming back, although not exactly as it was before.
>
> > If both these options are gone, then should the packages which aren't
> > installed by default if all groups are selected be moved to Fedora
> > Extras?
>
> In a lot of cases, packages which aren't listed in the comps file at all
> (or aren't a dependency of something) perhaps _should_ move to Extras.
> In addition, I think there probably are packages which should move
> somewhere into the comps file.  File bugs against comps for things that
> should be listed and aren't.

I've opened bug #174244 on comps and attached a list of all the rpms
that did not get installed. This list contains 999 rpms! Something is
seriously wrong here...

Best regards,
Bernd.



From nicolas.mailhot at laposte.net  Sat Nov 26 13:32:06 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Sat, 26 Nov 2005 14:32:06 +0100
Subject: Initializing hardware... slow
In-Reply-To: <1132972433.5032.4.camel@coyote.rexursive.com>
References: <20051125143109.q7r8zie3kkgsoo0g@imp.rexursive.com>
	<4386FF38.8030104@redhat.com>	<1132946790.3578.1.camel@rousalka.dyndns.org>
	<438766F8.5070807@redhat.com>
	<1132951026.11004.0.camel@rousalka.dyndns.org>
	<43877A5E.1050006@redhat.com>
	<1132953245.3032.6.camel@rousalka.dyndns.org>
	<1132972433.5032.4.camel@coyote.rexursive.com>
Message-ID: <1133011926.3916.30.camel@rousalka.dyndns.org>

Le samedi 26 novembre 2005 ? 13:33 +1100, Bojan Smojver a ?crit :
> On Fri, 2005-11-25 at 22:13 +0100, Nicolas Mailhot wrote:
> 
> > Seems related to network calls
> > 
> > ntp startup is sloooow
> > httpd startup -> same
> > gaim startup -> anemic (btw the latest arts is missing lnusertemp, which
> > exposes the well-documented stupidity of having gnome sound depend on
> > kde subsystems)
> 
> How's your DNS? This could all be related to invalid DNS servers
> in /etc/resolv.conf.

Thanks, should have thought of it, the first entry was dead.
Though nscd was running, and some of the side-effects were distinctly
weird (why should dns slow down gnome-term startup when there is a local
cache on the system ?)

> > I'll try bootstart tomorrow - rawhide today is so broken I'm pretty
> > disgusted (gaim/arts/mcop, gdm, selinux, slow startup) If I don't do
> > something else now I'll start writing rude things on the list.
> > 
> > I don't mind a new bug a day but several in a row like this before I've
> > even finished investigating the first one is too much for me. You got to
> > love the destabelizing effect of test 1 - every Red Hat packager seems
> > to have postponed his experimental packages for after test1 was
> > released.
> 
> If things like this make you upset, maybe you shouldn't be running
> Rawhide. It is (unfortunately) not possible to find bugs without
> delivering software to users.

Things are not black and white. I don't mind new bugs. I do mind hitting
bugs/problems reported since before FC4 (making gnome depends on arts)
or discussed on the list in the days before packages are released (the
long thread about people not wanting core fonts mandatory didn't stop
mharris from releasing a modular X that crashed because of core font
stuff) or obvious checks the maintainer skipped before inflicting
breakage on everyone (arts changelog reads "4 nov fix lnusertemp
problem", "14 nov fix lnusertemp", and on the 24th a new version with
broken lnusertemp is released - how difficult would it have been to
check lnusertemp before puching a new package ?)

So yes it's RawHide. Yes it's not supposed to be perfect and some
breakage is acceptable. But no that does not mean packagers don't have
to check their stuff and make sure it's dogfoodable. If only out of
respect to the scores of poor loosers like me that try do do serious
testing and bug reporting. Because I can say too 'it's rawhide, it's
supposed to be broken, I won't spend time reporting anything' and
complain loudly when the stuff I didn't report appears in FC/RHEL.

So you see this cuts both ways. If Red Hat wants free QA and testing Red
Hat has to deliver something that can be tested. Writing "Raw hide will
eat your brainz" is a bit too easy. Easy and convenient, but false.
Especially when a release is entering its testing phase.

And BTW I don't have any axe to grind with the people who made the
mistakes I listed. Everyone makes mistakes now and then. But I won't let
write that because it's RawHide there is no need to acknowledge any
problem, and testers should not be upset when well-known issues are
pushed to rawhide. There are enough new bugs to find without having to
report the same stuff again and again.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051126/46d52f69/attachment.sig>

From petro at mail.ru  Sat Nov 26 13:52:39 2005
From: petro at mail.ru (Peter Lemenkov)
Date: Sat, 26 Nov 2005 16:52:39 +0300
Subject: OpenOffice.org crashes
Message-ID: <Pine.LNX.4.64.0511261650420.7379@lemenkov.com>

Hello, All!
After one of the latest updates, oofice became unstable.

See attached log for further details.

-- 
With best regards, Peter Lemenkov.
-------------- next part --------------
---start copy and paste here---
Video Driver is probably nvidia nv
OpenOffice.org core rpm version is openoffice.org-core-2.0.1-0.142.1.2
0xff993c: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e93c
0xffa141: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1f141
0x36c420:  + 0x420 (__kernel_sigreturn + 0x0)
0xcf0095: /usr/lib/openoffice.org2.0/program/libfwe680li.so + 0x32095 (framework::LockHelper::~LockHelper() + 0x37)
0xceeacf: /usr/lib/openoffice.org2.0/program/libfwe680li.so + 0x30acf
0xd19928: /usr/lib/openoffice.org2.0/program/libfwe680li.so + 0x5b928 (framework::PreventDuplicateInteraction::~PreventDuplicateInteraction() + 0x74)
0x86bcf2: /usr/lib/openoffice.org2.0/program/libuno_cppuhelpergcc3.so.3 + 0x1ecf2 (cppu::OWeakObject::release() + 0x44)
0xd1a519: /usr/lib/openoffice.org2.0/program/libfwe680li.so + 0x5c519
0x141fd8e: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x88d8e
0xfbddee: /usr/lib/openoffice.org2.0/program/libuno_cppu.so.3 + 0xedee
0xfc66f0: /usr/lib/openoffice.org2.0/program/libuno_cppu.so.3 + 0x176f0 (uno_any_destruct + 0x24)
0x141fdaf: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x88daf
0x150a2ad: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1732ad
0x2a880f: /usr/lib/openoffice.org2.0/program/libsvl680li.so + 0x6c80f (SfxItemPool::Remove(SfxPoolItem const&) + 0x85)
0x2ac00b: /usr/lib/openoffice.org2.0/program/libsvl680li.so + 0x7000b (SfxAllItemSet::Put(SfxPoolItem const&, unsigned short) + 0x233)
0x1435560: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x9e560
0x14c1240: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x12a240
0x14c29ce: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x12b9ce
0x1533fcc: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19cfcc
0x15333b9: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19c3b9
0x15336cd: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19c6cd
0x1533770: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x19c770
0x142fa2c: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x98a2c
0x154c6ad: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1b56ad
0x154c568: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1b5568
0x154c6c2: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1b56c2
0x154c554: /usr/lib/openoffice.org2.0/program/libsfx680li.so + 0x1b5554
0xacd05a: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x7b05a
0xc26ff5: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x1d4ff5
0x1831f36: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x1ef36
0x18583c3: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x453c3 (SalDisplay::DispatchInternalEvent() + 0xad)
0x17f040b: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x1940b
0x170ca6f: /usr/lib/libglib-2.0.so.0 + 0x26a6f
0x170a810: /usr/lib/libglib-2.0.so.0 + 0x24810 (g_main_context_dispatch + 0x1dc)
0x170d816: /usr/lib/libglib-2.0.so.0 + 0x27816
0x170dc9e: /usr/lib/libglib-2.0.so.0 + 0x27c9e (g_main_context_iteration + 0x62)
0x17f003d: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0x1903d
0x1859629: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x46629 (X11SalInstance::Yield(unsigned char) + 0x29)
0xad33ce: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x813ce (Application::Yield() + 0x50)
0xad340c: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8140c (Application::Execute() + 0x26)
0x975dd5: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x24dd5 (desktop::Desktop::Main() + 0x15df)
0xad87fd: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x867fd
0xad88ad: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x868ad (SVMain() + 0x29)
0x96d333: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x1c333 (sal_main + 0x57)
0x96d37f: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x1c37f (main + 0x27)
0xe9462d: /lib/libc.so.6 + 0x1562d (__libc_start_main + 0xc5)
0x80484a5: /usr/lib/openoffice.org2.0/program/soffice.bin + 0x4a5
---end copy and paste here---
paste the above into your bug report


From mattdm at mattdm.org  Sat Nov 26 14:39:49 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 09:39:49 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132984226.2860.39.camel@bree.local.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
Message-ID: <20051126143949.GA2261@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
> In a lot of cases, packages which aren't listed in the comps file at all
> (or aren't a dependency of something) perhaps _should_ move to Extras.
> In addition, I think there probably are packages which should move
> somewhere into the comps file.  File bugs against comps for things that
> should be listed and aren't.

How about making Anaconda always only do a minimal install, and make
firstboot have the option to install other things if you want 'em? :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fedora at leemhuis.info  Sat Nov 26 15:03:34 2005
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Sat, 26 Nov 2005 16:03:34 +0100
Subject: OpenOffice.org crashes
In-Reply-To: <Pine.LNX.4.64.0511261650420.7379@lemenkov.com>
References: <Pine.LNX.4.64.0511261650420.7379@lemenkov.com>
Message-ID: <1133017414.4418.6.camel@localhost.localdomain>

Am Samstag, den 26.11.2005, 16:52 +0300 schrieb Peter Lemenkov:
> Hello, All!

Just FYI, for this sort of thing fedora-test-list would have been the
right place (because it seems it is a update from updates-testing you
use). For other things fedora-list is often the right place. Here it is
off-topic. 

> After one of the latest updates, oofice became unstable.

This is tracked here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171873

CU
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>



From wrrhdev at riede.org  Sat Nov 26 14:32:17 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 26 Nov 2005 14:32:17 +0000
Subject: 'everything' install option in FC5test1
In-Reply-To: <1132984226.2860.39.camel@bree.local.net> (from
	katzj@redhat.com on Sat Nov 26 00:50:26 2005)
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
Message-ID: <1133015537l.3593l.0l@serve.riede.org>

On 11/26/2005 12:50:26 AM, Jeremy Katz wrote:
> On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
> > It seems that with Everything install option gone in FC5 test1, one
> > cannot install all packages from CD. I'm still downloading it so I
> > cannot test by myself yet, but Jeremy's reply suggests it won't be added
> > back (how are the package groups handled with multiple repositories?).
> 
> Everything is a bit of a disaster in a lot of ways.  Some people think
> that it shouldn't include language-specific packages.  Some people think
> it should.  With multiple repositories, should it include all of the
> packages from all of the repositories?  What happens if there are
> conflicts?  And that's in addition to mattdm's helpful comments in the
> bug :)

That one is solvable by calling it "everything from core" and having a
follow-up dialog to select language(s)...

As if you didn't have enough to do :-)

Regards, Willem Riede.



From skvidal at phy.duke.edu  Sat Nov 26 15:35:54 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 10:35:54 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133015537l.3593l.0l@serve.riede.org>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<1133015537l.3593l.0l@serve.riede.org>
Message-ID: <1133019354.17474.18.camel@cutter>

On Sat, 2005-11-26 at 14:32 +0000, Willem Riede wrote:
> On 11/26/2005 12:50:26 AM, Jeremy Katz wrote:
> > On Fri, 2005-11-25 at 23:56 +0200, Marius Andreiana wrote:
> > > It seems that with Everything install option gone in FC5 test1, one
> > > cannot install all packages from CD. I'm still downloading it so I
> > > cannot test by myself yet, but Jeremy's reply suggests it won't be added
> > > back (how are the package groups handled with multiple repositories?).
> > 
> > Everything is a bit of a disaster in a lot of ways.  Some people think
> > that it shouldn't include language-specific packages.  Some people think
> > it should.  With multiple repositories, should it include all of the
> > packages from all of the repositories?  What happens if there are
> > conflicts?  And that's in addition to mattdm's helpful comments in the
> > bug :)
> 
> That one is solvable by calling it "everything from core" and having a
> follow-up dialog to select language(s)...
> 
> As if you didn't have enough to do :-)

here's an idea - rather than having all this stuff in anaconda, why not
just install a 'workstation' or 'minimal' system. boot it up then run:
yum install  '*'

to your little hearts content.

Then you can clutter up your own system as much as you  want w/o having
to add confusing features and useless buttons into anaconda.

-sv




From mattdm at mattdm.org  Sat Nov 26 15:35:27 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 10:35:27 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133015537l.3593l.0l@serve.riede.org>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<1133015537l.3593l.0l@serve.riede.org>
Message-ID: <20051126153527.GA5318@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
> >that it shouldn't include language-specific packages.  Some people think
> >it should.  With multiple repositories, should it include all of the
> >packages from all of the repositories?  What happens if there are
> That one is solvable by calling it "everything from core" and having a
[...]

But if it is just "everything from core", what's the argument for having it,
then? From what I've heard from people who like having Everything, they want
it because they want every possibility pre-installed -- which this wouldn't
be. It'd just be "a bunch of stuff that's useful in a core distribution,
the majority of which isn't ever going to be useful or relevant to any one
specific installation".


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From katzj at redhat.com  Sat Nov 26 15:36:55 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 10:36:55 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126143949.GA2261@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
Message-ID: <1133019415.2860.75.camel@bree.local.net>

On Sat, 2005-11-26 at 09:39 -0500, Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
> > In a lot of cases, packages which aren't listed in the comps file at all
> > (or aren't a dependency of something) perhaps _should_ move to Extras.
> > In addition, I think there probably are packages which should move
> > somewhere into the comps file.  File bugs against comps for things that
> > should be listed and aren't.
> 
> How about making Anaconda always only do a minimal install, and make
> firstboot have the option to install other things if you want 'em? :)

Because that gets into non-fun questions about whether or not to install
X and a desktop as part of "minimal".  And my answer definitely differs
from that of a number of people :)

Jeremy



From skvidal at phy.duke.edu  Sat Nov 26 15:43:08 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 10:43:08 -0500
Subject: suggestion: move all java packages to extras
Message-ID: <1133019788.17474.24.camel@cutter>

B/c of the rapidly evolving nature of the gcj and related java tools,
what if we moved them to extras so that work on those packages could be
both public and move faster?

It would be a big savings on the size of core and it seems like adding
those packages over there would be the most correct as the java packages
don't really have any necessary reason to be in core.

What do you think?

-sv




From mattdm at mattdm.org  Sat Nov 26 15:44:23 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 10:44:23 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133019415.2860.75.camel@bree.local.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
Message-ID: <20051126154423.GA5854@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 10:36:55AM -0500, Jeremy Katz wrote:
> > How about making Anaconda always only do a minimal install, and make
> > firstboot have the option to install other things if you want 'em? :)
> Because that gets into non-fun questions about whether or not to install
> X and a desktop as part of "minimal".  And my answer definitely differs
> from that of a number of people :)

True. Okay, so, minimal + the minimum X required to install firstboot with a
package chooser. With an option to do *just* minimal for experts. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jspaleta at gmail.com  Sat Nov 26 15:34:00 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 10:34:00 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1132983547.2860.32.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
Message-ID: <604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>

On 11/26/05, Jeremy Katz <katzj at redhat.com> wrote:
> Why would you want to not download updates from all repositories you
> have configured?  Or at least see what's available.  The fact that the
> updates come from multiple repositories is a detail that I don't think
> users really want to / should need to care about.

updates-testing
Not being able to pick and choose for updates-testing via the gui is
going to mean
less people in a certain class of user who are not going to use updates-testing.
For a casual user who files a bugreport and then needs to give
feedback on a package in updates-testing or rawhide that claims to fix
the issue...shouldn't there be a way for them to selectively eat from
updates-testing/rawhide... without dropping to the cmdline?

We've already seen Mr. Lee call for more usage of the update-testing,
but this isn't going to happen if casual users can not eat from the
tree selectively with the primary tool presented to them.  Some people
who want to test a gimp update are not going to want to eat a test
kernel update as well.  If you are intent on streamlining the pup
interface to the extent that individual channels/updates can not be
selected/de-deselected please make it impossible for pup to pull
updates from updates-testing at all with it.  If you take away
granular control from pup, updates-testing AND rawhide become much
less safe for the casual user of  a normal release.

> I've always personally found this to be a bit of a waste and just
> another click which isn't really needed -- I asked for updates, when
> they're done, get out of my way :)

Instead of a summary window.. will pup be generating a log with
timestamps that include packagename,version and repository source? 
Once you start adding repos that replace Core or Extras, it becomes
somewhat important for the user to know where to bitch about problems
with certain applications.  Where the package is from very much
matters if there is a problem. And there really needs to be a casual
user oriented way of seeing that information so they can drive bugs
and questions to the correct repo.


On the topic of notifications.... would it be possible for have room
in the notification metadata for a "repo notification"?  When a person
contacts a repo for the first time, a chance to display a short
message as defined by the repo...similar to a short website faq?  A
lot of people in #fedora who end up adding repos do so by following
google'd recipes and never actually read the repository faq or about
page. As a result they get very frustrated when the repository
replaces Core packages or they find they have missing deps because
they didnt include all the repos required.  A first contact dialog on
the client tools like pup could help avoid some of this frustration. 
Such a message could give a short about text and information about
communication channels such as mailinglists and bugzilla for that
repo.


-jef



From bdpepple at ameritech.net  Sat Nov 26 15:48:49 2005
From: bdpepple at ameritech.net (Brian Pepple)
Date: Sat, 26 Nov 2005 10:48:49 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <1133020129.7280.3.camel@shuttle.273piedmont.com>

On Sat, 2005-11-26 at 10:43 -0500, seth vidal wrote:
> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?
> 
> It would be a big savings on the size of core and it seems like adding
> those packages over there would be the most correct as the java packages
> don't really have any necessary reason to be in core.
> 
> What do you think?

+1.

I'm all in favor of reducing the size of core. Hopefully, someday it can
be whittled down to 1 cd.

Though, isn't the openoffice.org packages dependent on several of the
java tools?

/B
-- 
Brian Pepple <bdpepple at ameritech.net>

gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051126/6bf754dc/attachment.sig>

From mattdm at mattdm.org  Sat Nov 26 15:46:09 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 10:46:09 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <20051126154609.GB5854@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 10:43:08AM -0500, seth vidal wrote:
> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?
> It would be a big savings on the size of core and it seems like adding
> those packages over there would be the most correct as the java packages
> don't really have any necessary reason to be in core.
> What do you think?

I think Eclipse is a big feature for RHEL. Does the RHEL<->Core thing still
hold, or are we in the era of RHEL<->Core+Extras?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Sat Nov 26 15:52:47 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 10:52:47 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133020129.7280.3.camel@shuttle.273piedmont.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
Message-ID: <20051126155247.GA6301@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 10:48:49AM -0500, Brian Pepple wrote:
> I'm all in favor of reducing the size of core. Hopefully, someday it can
> be whittled down to 1 cd.
> Though, isn't the openoffice.org packages dependent on several of the
> java tools?

If you want Core down to one CD, OpenOffice.org has got to go anyway. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From sundaram at redhat.com  Sat Nov 26 15:55:23 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 21:25:23 +0530
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051126154609.GB5854@jadzia.bu.edu>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
Message-ID: <4388856B.8040303@redhat.com>

Hi

>I think Eclipse is a big feature for RHEL. Does the RHEL<->Core thing still
>hold, or are we in the era of RHEL<->Core+Extras?
>  
>
I dont think we have to worry about the repository but the maintainer.

regards
Rahul



From skvidal at phy.duke.edu  Sat Nov 26 15:57:04 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 10:57:04 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133020129.7280.3.camel@shuttle.273piedmont.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
Message-ID: <1133020624.17474.30.camel@cutter>


> +1.
> 
> I'm all in favor of reducing the size of core. Hopefully, someday it can
> be whittled down to 1 cd.
> 
> Though, isn't the openoffice.org packages dependent on several of the
> java tools?

I doubt it's dependent on tomcat and jonas or eclipse or any of the
other misc java items.

-sv




From jspaleta at gmail.com  Sat Nov 26 15:48:40 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 10:48:40 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126154423.GA5854@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
	<20051126154423.GA5854@jadzia.bu.edu>
Message-ID: <604aa7910511260748r2d22a685y5e7f4cdb48c62c52@mail.gmail.com>

On 11/26/05, Matthew Miller <mattdm at mattdm.org> wrote:
> True. Okay, so, minimal + the minimum X required to install firstboot with a
> package chooser. With an option to do *just* minimal for experts. :)

How about the "experts" use kickstart files to do pretty much any
pre-install configuration that the dependancy chains allow?

-jef"Could the wiki be used to hold community contributed kickstart
files?"spaleta



From katzj at redhat.com  Sat Nov 26 15:56:33 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 10:56:33 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
Message-ID: <1133020593.2860.86.camel@bree.local.net>

On Sat, 2005-11-26 at 10:34 -0500, Jeff Spaleta wrote:
> On 11/26/05, Jeremy Katz <katzj at redhat.com> wrote:
> > Why would you want to not download updates from all repositories you
> > have configured?  Or at least see what's available.  The fact that the
> > updates come from multiple repositories is a detail that I don't think
> > users really want to / should need to care about.
> 
> updates-testing
> Not being able to pick and choose for updates-testing via the gui is
> going to mean
> less people in a certain class of user who are not going to use updates-testing.
> For a casual user who files a bugreport and then needs to give
> feedback on a package in updates-testing or rawhide that claims to fix
> the issue...shouldn't there be a way for them to selectively eat from
> updates-testing/rawhide... without dropping to the cmdline?

I haven't said anything about repository configuration being
command-line only -- just that it's not in the flow for getting updates.
I don't want the casual user who's not going to understand how to deal
with bugs falling into updates-testing just because they're confronted
with a set of confusing checkboxes.

> We've already seen Mr. Lee call for more usage of the update-testing,
> but this isn't going to happen if casual users can not eat from the
> tree selectively with the primary tool presented to them.  Some people
> who want to test a gimp update are not going to want to eat a test
> kernel update as well.  If you are intent on streamlining the pup
> interface to the extent that individual channels/updates can not be
> selected/de-deselected please make it impossible for pup to pull
> updates from updates-testing at all with it.  If you take away
> granular control from pup, updates-testing AND rawhide become much
> less safe for the casual user of  a normal release.

Frankly, rawhide _isn't_ safe for the casual user and I'm surprised to
see you even insinuate that it could be. :)   updates-testing should be
much safer, but I still think there's a degree of familiarity that's
required to make it actually effective for someone to use it.

> > I've always personally found this to be a bit of a waste and just
> > another click which isn't really needed -- I asked for updates, when
> > they're done, get out of my way :)
> 
> Instead of a summary window.. will pup be generating a log with
> timestamps that include packagename,version and repository source? 
> Once you start adding repos that replace Core or Extras, it becomes
> somewhat important for the user to know where to bitch about problems
> with certain applications.  Where the package is from very much
> matters if there is a problem. And there really needs to be a casual
> user oriented way of seeing that information so they can drive bugs
> and questions to the correct repo.

I actually need to make sure that we're using the same logging here as
yum

> On the topic of notifications.... would it be possible for have room
> in the notification metadata for a "repo notification"?  When a person
> contacts a repo for the first time, a chance to display a short
> message as defined by the repo...similar to a short website faq?  A
> lot of people in #fedora who end up adding repos do so by following
> google'd recipes and never actually read the repository faq or about
> page. As a result they get very frustrated when the repository
> replaces Core packages or they find they have missing deps because
> they didnt include all the repos required.  A first contact dialog on
> the client tools like pup could help avoid some of this frustration. 
> Such a message could give a short about text and information about
> communication channels such as mailinglists and bugzilla for that
> repo.

I think this has more likelihood of being abused than useful.  Also,
doing it in a reasonable fashion is difficult due to the variety of
formatting that's really needed.  As the tools get better and easier to
use, though, I think you'll find less "use this random URL to use bar's
repository" and more "go to bar and add them" when we have the ability
to more easily do "click on repository, get asked about adding it"

Jeremy



From skvidal at phy.duke.edu  Sat Nov 26 15:59:17 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 10:59:17 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <4388856B.8040303@redhat.com>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>  <4388856B.8040303@redhat.com>
Message-ID: <1133020757.17474.35.camel@cutter>

On Sat, 2005-11-26 at 21:25 +0530, Rahul Sundaram wrote:
> Hi
> 
> >I think Eclipse is a big feature for RHEL. Does the RHEL<->Core thing still
> >hold, or are we in the era of RHEL<->Core+Extras?
> >  
> >
> I dont think we have to worry about the repository but the maintainer.
> 

we have maintainers of packages in extras that used to maintain them in
core.

why would anyone complain about that move? It's not like the checkin
system is any more painful.

-sv



From sundaram at redhat.com  Sat Nov 26 15:59:59 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sat, 26 Nov 2005 21:29:59 +0530
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133020757.17474.35.camel@cutter>
References: <1133019788.17474.24.camel@cutter>	<20051126154609.GB5854@jadzia.bu.edu>
	<4388856B.8040303@redhat.com> <1133020757.17474.35.camel@cutter>
Message-ID: <4388867F.30107@redhat.com>

Hi

>we have maintainers of packages in extras that used to maintain them in
>core.
>
>why would anyone complain about that move? It's not like the checkin
>system is any more painful.
>
precisely my point.

regards
Rahul



From skvidal at phy.duke.edu  Sat Nov 26 15:57:45 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 10:57:45 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051126154609.GB5854@jadzia.bu.edu>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
Message-ID: <1133020666.17474.34.camel@cutter>

On Sat, 2005-11-26 at 10:46 -0500, Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 10:43:08AM -0500, seth vidal wrote:
> > B/c of the rapidly evolving nature of the gcj and related java tools,
> > what if we moved them to extras so that work on those packages could be
> > both public and move faster?
> > It would be a big savings on the size of core and it seems like adding
> > those packages over there would be the most correct as the java packages
> > don't really have any necessary reason to be in core.
> > What do you think?
> 
> I think Eclipse is a big feature for RHEL. Does the RHEL<->Core thing still
> hold, or are we in the era of RHEL<->Core+Extras?

Nope. We've moved packages that are in RHEL out to extras already, iirc.
-sv




From wrrhdev at riede.org  Sat Nov 26 16:02:09 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 26 Nov 2005 16:02:09 +0000
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126153527.GA5318@jadzia.bu.edu> (from mattdm@mattdm.org
	on Sat Nov 26 10:35:27 2005)
Message-ID: <1133020929l.3593l.5l@serve.riede.org>

On 11/26/2005 10:35:27 AM, Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
> > >that it shouldn't include language-specific packages.  Some people think
> > >it should.  With multiple repositories, should it include all of the
> > >packages from all of the repositories?  What happens if there are
> > That one is solvable by calling it "everything from core" and having a
> [...]
> 
> But if it is just "everything from core", what's the argument for having it,
> then? From what I've heard from people who like having Everything, they want
> it because they want every possibility pre-installed -- which this wouldn't
> be. It'd just be "a bunch of stuff that's useful in a core distribution,
> the majority of which isn't ever going to be useful or relevant to any one
> specific installation".

Having "everything from every repo that I identified" installed is not a safe  
option to provide. Many repos hold updates to core packages that should not be  
blindly chosen.

And frankly, I'd vote for not having an everything option at all, because your  
qualification of the majority not being useful or relevant to the user  
defenitely holds independant of how wide an everything net you cast.

The only reason users go for it IMHO is that they they don't know what they  
want or need. They end up with stuff installed they don't know they have, even  
though they might use it if they knew. With yum it is so easy and convenient  
to just pull in a package that you want to try once you learn about its  
existance, that I don't see the value of speculatively pre-installing.

But if there is going to be an "everything", again IMHO, it should be limited  
to core.

Regards, Willem Riede.



From katzj at redhat.com  Sat Nov 26 16:01:44 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:01:44 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <13410.194.94.224.254.1133007171.squirrel@arlette.freesurf.fr>
References: <1132983547.2860.32.camel@bree.local.net>
	<13410.194.94.224.254.1133007171.squirrel@arlette.freesurf.fr>
Message-ID: <1133020904.2860.92.camel@bree.local.net>

On Sat, 2005-11-26 at 13:12 +0100, Joachim Frieben wrote:
> > Why would you want to not download updates from all repositories you
> > have configured?  Or at least see what's available.  The fact that the
> > updates come from multiple repositories is a detail that I don't think
> > users really want to / should need to care about.
>
> Because it gives more control to the user as most other issues pointed
> out by me. He might use "updates-testing" but only from time to time
> and at least want to know that package "xyz" comes from channel "A" and
> not from channel "B". The same applies to 3rd party repositories.
> With "pup", you feel like driving a car without safety belt.

And I argue that users don't know or care the difference between
repositories and that by giving them the option of disabling just
certain repositories, you're giving them a quick avenue to breaking
their system.  

> > Some of the sizings and spacing still need work with pup, definitely.
> > That's the sort of modifications that are easy to make once the code is
> > working and thus it hasn't been high on my todo list.  File bugs and
> > we'll definitely see about getting to them as soon as we can.
> >
> 
> Great, but that's even more than I requested. However, "up2date-gnome"
> does an excellent job at all this right now.

But does up2date do an excellent job of providing the user experience
we're trying to provide where things are intentionally not just "here's
a list of packages"?  I don't think so.

up2date also has its own implementation of huge chunks of yum that are
difficult to just abstract out and switch so that we can have one
dependency resolver being used underneath all of the tools we use for
package handling on Fedora.  up2date is just not the code base for doing
that.

Jeremy



From katzj at redhat.com  Sat Nov 26 16:02:59 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:02:59 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126154423.GA5854@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
	<20051126154423.GA5854@jadzia.bu.edu>
Message-ID: <1133020979.2860.95.camel@bree.local.net>

On Sat, 2005-11-26 at 10:44 -0500, Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 10:36:55AM -0500, Jeremy Katz wrote:
> > > How about making Anaconda always only do a minimal install, and make
> > > firstboot have the option to install other things if you want 'em? :)
> > Because that gets into non-fun questions about whether or not to install
> > X and a desktop as part of "minimal".  And my answer definitely differs
> > from that of a number of people :)
> 
> True. Okay, so, minimal + the minimum X required to install firstboot with a
> package chooser. With an option to do *just* minimal for experts. :)

There are also other problems in that CD installs become extremely
annoying as you have to keep switching CDs longer.  Anyway, we've been
down this road of discussion before and it's just not something that
makes sense to me right now and so it's not going to be done ;-)

Jeremy



From skvidal at phy.duke.edu  Sat Nov 26 16:06:02 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:06:02 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133020929l.3593l.5l@serve.riede.org>
References: <1133020929l.3593l.5l@serve.riede.org>
Message-ID: <1133021162.17474.38.camel@cutter>

On Sat, 2005-11-26 at 16:02 +0000, Willem Riede wrote:
> On 11/26/2005 10:35:27 AM, Matthew Miller wrote:
> > On Sat, Nov 26, 2005 at 02:32:17PM +0000, Willem Riede wrote:
> > > >that it shouldn't include language-specific packages.  Some people think
> > > >it should.  With multiple repositories, should it include all of the
> > > >packages from all of the repositories?  What happens if there are
> > > That one is solvable by calling it "everything from core" and having a
> > [...]
> > 
> > But if it is just "everything from core", what's the argument for having it,
> > then? From what I've heard from people who like having Everything, they want
> > it because they want every possibility pre-installed -- which this wouldn't
> > be. It'd just be "a bunch of stuff that's useful in a core distribution,
> > the majority of which isn't ever going to be useful or relevant to any one
> > specific installation".
> 
> Having "everything from every repo that I identified" installed is not a safe  
> option to provide. Many repos hold updates to core packages that should not be  
> blindly chosen.
> 
> And frankly, I'd vote for not having an everything option at all, because your  
> qualification of the majority not being useful or relevant to the user  
> defenitely holds independant of how wide an everything net you cast.
> 
> The only reason users go for it IMHO is that they they don't know what they  
> want or need. They end up with stuff installed they don't know they have, even  
> though they might use it if they knew. With yum it is so easy and convenient  
> to just pull in a package that you want to try once you learn about its  
> existance, that I don't see the value of speculatively pre-installing.
> 
> But if there is going to be an "everything", again IMHO, it should be limited  
> to core.

yum --disablerepo='*' --enablerepo='base'
--enablerepo='updates-released' install '*'


that would be an 'install everything, just from core'

-sv






From katzj at redhat.com  Sat Nov 26 16:04:40 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:04:40 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133020624.17474.30.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
Message-ID: <1133021081.2860.97.camel@bree.local.net>

On Sat, 2005-11-26 at 10:57 -0500, seth vidal wrote:
> > +1.
> > 
> > I'm all in favor of reducing the size of core. Hopefully, someday it can
> > be whittled down to 1 cd.
> > 
> > Though, isn't the openoffice.org packages dependent on several of the
> > java tools?
> 
> I doubt it's dependent on tomcat and jonas or eclipse or any of the
> other misc java items.

It actually is dependent on eclipse to build.  And tomcat is
increasingly a "core" server piece similar to php[1]

Jeremy

[1] Yes, I know the hate that PHP has from you Seth, but quite frankly,
I don't think that taking LAMP out of Core is at all wise.



From fedora-devel at stefan-neufeind.de  Sat Nov 26 16:01:56 2005
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Sat, 26 Nov 2005 17:01:56 +0100
Subject: lm_sensors in FC4-updates for x86_64 twice?
Message-ID: <438886F4.1070607@stefan-neufeind.de>

Hi,

I just saw that a simple "yum install lm_sensors" tried to install the
same versions of lm_sensors for i386 _and_ x86_64 at the same time, when
installing on arch=x86_64. Is there a hidden sense behind that, or does
the i386-package maybe need to be removed?


Kind regards,
 Stefan



From katzj at redhat.com  Sat Nov 26 16:06:13 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:06:13 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <1133021173.2860.100.camel@bree.local.net>

On Sat, 2005-11-26 at 10:43 -0500, seth vidal wrote:
> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?

Well, gcj comes from the same source as gcc.  So gcj can't really move.
And I think that tomcat is Core functionality in the same vein as a
webserver being Core functionality.  And parts of Eclipse are needed for
building OOo, but no, you don't want to know why :)

Jeremy



From wrrhdev at riede.org  Sat Nov 26 14:52:29 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 26 Nov 2005 14:52:29 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <1132983547.2860.32.camel@bree.local.net> (from
	katzj@redhat.com on Sat Nov 26 00:39:07 2005)
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
Message-ID: <1133016749l.3593l.2l@serve.riede.org>

On 11/26/2005 12:39:07 AM, Jeremy Katz wrote:
> 
> One thing that's fundamentally different with pup is that we're trying
> to get away from the package being (necessarily) the point of
> granularity.  The hope is that we can actually get the update
> information available via the yum metadata so that we can instead
> provide more useful update information such as --
>   "New version of apache httpd daemon to fix security vulnerability foo"
> and then have all of the packages which are a part of that advisory
> grouped together rather than requiring you to know that you need all of
> httpd, httpd-devel and mod_ssl as a bunch.  Since we don't have that
> metadata currently available (and never will for the development tree
> and probably also some other repositories), the fallback is to grouping
> packages by source RPM.

That would be very cool. But dependancies already tend to bring in those  
bunches together, don't they?

Regards, Willem Riede.



From skvidal at phy.duke.edu  Sat Nov 26 16:13:19 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:13:19 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021081.2860.97.camel@bree.local.net>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
Message-ID: <1133021599.17474.43.camel@cutter>


> It actually is dependent on eclipse to build.  And tomcat is
> increasingly a "core" server piece similar to php[1]

So why is it that servers have to be in core? Why not move tomcat
outside of core? What's the justification for having it in core? Hell,
same with php. The only thing I can think of that depends on php in core
is squirrelmail. Zope's not in core, it's in extras and its a server. 

> 
> Jeremy
> 
> [1] Yes, I know the hate that PHP has from you Seth, but quite frankly,
> I don't think that taking LAMP out of Core is at all wise.

1. core isn't really feature complete on its own w/o extras. I can't
install a system and finish it off w/o using extras.

2. extras is enabled by default in the final install of fedora core, so
people can easily get to all of those packages.

-sv




From skvidal at phy.duke.edu  Sat Nov 26 16:14:33 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:14:33 -0500
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <438886F4.1070607@stefan-neufeind.de>
References: <438886F4.1070607@stefan-neufeind.de>
Message-ID: <1133021673.17474.46.camel@cutter>

On Sat, 2005-11-26 at 17:01 +0100, Stefan Neufeind wrote:
> Hi,
> 
> I just saw that a simple "yum install lm_sensors" tried to install the
> same versions of lm_sensors for i386 _and_ x86_64 at the same time, when
> installing on arch=x86_64. Is there a hidden sense behind that, or does
> the i386-package maybe need to be removed?
> 

by default if you do not specify an arch yum will install all arches
that _can_ be installed.

no, I don't want to hear any bitching and moaning about this, that's how
it is.

if you want only .x86_64 then install lm_sensors.x86_64

-sv




From jspaleta at gmail.com  Sat Nov 26 16:09:33 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 11:09:33 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133020593.2860.86.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<1133020593.2860.86.camel@bree.local.net>
Message-ID: <604aa7910511260809o747ef727i86a8b88dc5f933ab@mail.gmail.com>

On 11/26/05, Jeremy Katz <katzj at redhat.com> wrote:
> I haven't said anything about repository configuration being
> command-line only -- just that it's not in the flow for getting updates.
> I don't want the casual user who's not going to understand how to deal
> with bugs falling into updates-testing just because they're confronted
> with a set of confusing checkboxes.

If you want to protect the casual user using pup from  updates-testing
then make sure updates-testing is never a part of pup's set of sources
even if updates-testing is enabled in the yum config.

-jef



From icon at fedoraproject.org  Sat Nov 26 16:18:43 2005
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Sat, 26 Nov 2005 11:18:43 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133020666.17474.34.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
Message-ID: <1133021923.4178.14.camel@localhost.localdomain>

On Sat, 2005-26-11 at 10:57 -0500, seth vidal wrote:
> > I think Eclipse is a big feature for RHEL. Does the RHEL<->Core thing still
> > hold, or are we in the era of RHEL<->Core+Extras?
> 
> Nope. We've moved packages that are in RHEL out to extras already, iirc.

I'll add a little more flamage to the conversation and state that native
eclipse is actually not that useful. It doesn't seem to run any faster
than JDK eclipse, even though you'd think it would, and imposes serious
limits on the usability, since you a) can't easily install any of the
third-package plugins that aren't already packaged into RPMs, and b)
can't update the plugins that come from RPMs, so you're stuck with old
versions (e.g. a rather dated version of PyDev). So, unless you write
lots of stuff in gcj-java, Eclipse as provided by Fedora would be of
limited use.

This is not to say that I don't appreciate the importance of gcj -- we
really do need a fully free java implementation that can run any java
app we throw at it. However, installing a natively compiled version of
Eclipse is currently of questionable benefit, especially considering how
much space it eats on the install media, so moving it out of core and
into extras would make excellent sense.

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG
Montr?al, Qu?bec



From mattdm at mattdm.org  Sat Nov 26 16:24:05 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 11:24:05 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
Message-ID: <20051126162405.GB7201@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 11:13:19AM -0500, seth vidal wrote:
> same with php. The only thing I can think of that depends on php in core
> is squirrelmail. Zope's not in core, it's in extras and its a server. 

And speaking of candidates for extras....


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Sat Nov 26 16:24:31 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 11:24:31 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133020979.2860.95.camel@bree.local.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
	<20051126154423.GA5854@jadzia.bu.edu>
	<1133020979.2860.95.camel@bree.local.net>
Message-ID: <20051126162431.GC7201@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 11:02:59AM -0500, Jeremy Katz wrote:
> > True. Okay, so, minimal + the minimum X required to install firstboot with a
> > package chooser. With an option to do *just* minimal for experts. :)
> There are also other problems in that CD installs become extremely
> annoying as you have to keep switching CDs longer.  Anyway, we've been

Bah, CDs. :)

> down this road of discussion before and it's just not something that
> makes sense to me right now and so it's not going to be done ;-)

I know. I just have to bring it up every now and then. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jspaleta at gmail.com  Sat Nov 26 16:14:03 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 11:14:03 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133020593.2860.86.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<1133020593.2860.86.camel@bree.local.net>
Message-ID: <604aa7910511260814r695162bdl193b57da1d8bc0f5@mail.gmail.com>

On 11/26/05, Jeremy Katz <katzj at redhat.com> wrote:
> I think this has more likelihood of being abused than useful.  Also,
> doing it in a reasonable fashion is difficult due to the variety of
> formatting that's really needed.  As the tools get better and easier to
> use, though, I think you'll find less "use this random URL to use bar's
> repository" and more "go to bar and add them" when we have the ability
> to more easily do "click on repository, get asked about adding it"

I think you are absolutely wrong.  The recipe writers are still going
to continue to aggregate multiple repositories into their own "click
here to add the 5 repos I use in one easy to use step."   Unless
Amazon patents that procedure first.  You are too hopeful, you need to
spend more time in meathead-space.

-jef



From mattdm at mattdm.org  Sat Nov 26 16:20:52 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 11:20:52 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <604aa7910511260748r2d22a685y5e7f4cdb48c62c52@mail.gmail.com>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
	<20051126154423.GA5854@jadzia.bu.edu>
	<604aa7910511260748r2d22a685y5e7f4cdb48c62c52@mail.gmail.com>
Message-ID: <20051126162052.GA7201@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 10:48:40AM -0500, Jeff Spaleta wrote:
> On 11/26/05, Matthew Miller <mattdm at mattdm.org> wrote:
> > True. Okay, so, minimal + the minimum X required to install firstboot with a
> > package chooser. With an option to do *just* minimal for experts. :)
> How about the "experts" use kickstart files to do pretty much any
> pre-install configuration that the dependancy chains allow?

'Cause it's a pain to create a kickstart file to install just one server
system.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From tromey at redhat.com  Sat Nov 26 16:15:51 2005
From: tromey at redhat.com (Tom Tromey)
Date: Sat, 26 Nov 2005 09:15:51 -0700
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021923.4178.14.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
Message-ID: <17288.35383.421790.32377@localhost.localdomain>

>>>>> "Konstantin" == Konstantin Ryabitsev <icon at fedoraproject.org> writes:

Konstantin> I'll add a little more flamage to the conversation and
Konstantin> state that native eclipse is actually not that useful. It
Konstantin> doesn't seem to run any faster than JDK eclipse, even
Konstantin> though you'd think it would

There is a common misconception that "AOT compilation == Super Duper Fast".
That isn't true.  Performance is tricky and the current crop of
proprietary JITs are excellent compilers.  I'd expect that you could
see the benefit if you ran two eclipse instances on the same machine
though (eg try developing a plugin and running a second eclipse to
test it), due to the use of shared libraries.

Konstantin> a) can't easily install any of the third-package plugins
Konstantin> that aren't already packaged into RPMs

ATM there is a gcj bug affecting the update manager.  This is fixed in
gcc 4.1.  That said, the RPM-ification of Eclipse doesn't otherwise
affect the update manager.  You just need to make a new update site in
your home directory or the like.


I didn't read all of this thread, but going by the
Subject... segregating by implementation language doesn't make sense.
Instead segregate by functionality.

Tom



From green at redhat.com  Sat Nov 26 16:28:16 2005
From: green at redhat.com (Anthony Green)
Date: Sat, 26 Nov 2005 08:28:16 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <1133022496.3000.36.camel@localhost.localdomain>

On Sat, 2005-11-26 at 10:43 -0500, seth vidal wrote:
> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?

This wouldn't really help anything move faster, since we're limited by
the GCC update cycle.

> It would be a big savings on the size of core and it seems like adding
> those packages over there would be the most correct as the java packages
> don't really have any necessary reason to be in core.

This is about as helpful a statement as saying C++ packages don't really
have any necessary reason to be in core.  I think suggestions like this
should be based on specific applications.

AG




From skadz1 at gmail.com  Sat Nov 26 16:28:24 2005
From: skadz1 at gmail.com (Ryan Skadberg)
Date: Sat, 26 Nov 2005 11:28:24 -0500
Subject: UDEV and SELinux
Message-ID: <8719b8230511260828q635c39x22a39ac8df90942@mail.gmail.com>

I was rather amazed that I had not seen the very slow udev start up other
people were saying, I usually get hit with every little issue :)  Well, this
morning, I was working on my machine and noticed I had turned SELinux off a
while back and never turned it back on.  Well, I turned it back on this
morning and rebooted.  Well, udev start up went from 5 seconds to about 30
seconds once SELinux was on.  Turned if back off, went back down to 5
seconds.  So, it looks like the slow udev issue has something to do with
SELinux.   I have SELinux set up with:

SELINUX=enforcing
SELINUXTYPE=targeted

If I switch enforcing to disabled, startup works much faster.

Skadz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051126/2e80583b/attachment.htm>

From dimi at lattica.com  Sat Nov 26 16:28:30 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sat, 26 Nov 2005 11:28:30 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
Message-ID: <1133022510.9749.374.camel@dimi.lattica.com>

On Sat, 2005-11-26 at 11:13 -0500, seth vidal wrote:
> 1. core isn't really feature complete on its own w/o extras. I can't
> install a system and finish it off w/o using extras.

In that case, maybe we don't have a good definition for core.
I thought it would be a best-of-breed-useful-for-most collection.
If it's not that, what is it?

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From katzj at redhat.com  Sat Nov 26 16:30:38 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:30:38 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133016749l.3593l.2l@serve.riede.org>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133016749l.3593l.2l@serve.riede.org>
Message-ID: <1133022639.2860.114.camel@bree.local.net>

On Sat, 2005-11-26 at 14:52 +0000, Willem Riede wrote:
> On 11/26/2005 12:39:07 AM, Jeremy Katz wrote:
> > One thing that's fundamentally different with pup is that we're trying
> > to get away from the package being (necessarily) the point of
> > granularity.  The hope is that we can actually get the update
> > information available via the yum metadata so that we can instead
> > provide more useful update information such as --
> >   "New version of apache httpd daemon to fix security vulnerability foo"
> > and then have all of the packages which are a part of that advisory
> > grouped together rather than requiring you to know that you need all of
> > httpd, httpd-devel and mod_ssl as a bunch.  Since we don't have that
> > metadata currently available (and never will for the development tree
> > and probably also some other repositories), the fallback is to grouping
> > packages by source RPM.
> 
> That would be very cool. But dependancies already tend to bring in those  
> bunches together, don't they?

Yes, which is why it's somewhat ludicrous that you select them
individually :-)

Why should I care that I'm getting both the i386 and x86_64 version of a
new package.  Or the base package and it's -devel component.  They're
just parts of the whole. 

Jeremy



From katzj at redhat.com  Sat Nov 26 16:30:44 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:30:44 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
Message-ID: <1133022644.2860.116.camel@bree.local.net>

On Sat, 2005-11-26 at 11:13 -0500, seth vidal wrote:
> > It actually is dependent on eclipse to build.  And tomcat is
> > increasingly a "core" server piece similar to php[1]
> 
> So why is it that servers have to be in core? Why not move tomcat
> outside of core? What's the justification for having it in core? Hell,
> same with php. The only thing I can think of that depends on php in core
> is squirrelmail. Zope's not in core, it's in extras and its a server. 

Why is it that the desktop has to be in core?  I think we're moving
towards having _less_ distinction between Core and Extras instead of
more.  Your argument now is CD space, but we're going to want to get to
where we have CDs of Extras and at that point, the distinction between
the two becomes less clear.  

I've been one of the strongest proponents of shrinking Core for a while
now, but I'm starting to wonder if that's really the answer.  But
starting that argument now isn't going to accomplish anything.  It's not
the sort of thing that's going to happen today or tomorrow.  And if I
spend all day replying to mail on threads like this, I'm not going to
get to any of the useful stuff that people want to see done :-/

Jeremy



From skvidal at phy.duke.edu  Sat Nov 26 16:34:13 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:34:13 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133022496.3000.36.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<1133022496.3000.36.camel@localhost.localdomain>
Message-ID: <1133022853.17474.51.camel@cutter>

On Sat, 2005-11-26 at 08:28 -0800, Anthony Green wrote:
> On Sat, 2005-11-26 at 10:43 -0500, seth vidal wrote:
> > B/c of the rapidly evolving nature of the gcj and related java tools,
> > what if we moved them to extras so that work on those packages could be
> > both public and move faster?
> 
> This wouldn't really help anything move faster, since we're limited by
> the GCC update cycle.
> 
> > It would be a big savings on the size of core and it seems like adding
> > those packages over there would be the most correct as the java packages
> > don't really have any necessary reason to be in core.
> 
> This is about as helpful a statement as saying C++ packages don't really
> have any necessary reason to be in core.  I think suggestions like this
> should be based on specific applications.

So let me put this another way - I'm tired of all java applications
being added to core by default.

You said you included jonas in core in your most blog entry. Why didn't
it go to extras by default. What is it about jonas that you thought
meant it deserved to be in core? 

-sv




From katzj at redhat.com  Sat Nov 26 16:31:19 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 11:31:19 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133022496.3000.36.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<1133022496.3000.36.camel@localhost.localdomain>
Message-ID: <1133022679.2860.118.camel@bree.local.net>

On Sat, 2005-11-26 at 08:28 -0800, Anthony Green wrote:
> On Sat, 2005-11-26 at 10:43 -0500, seth vidal wrote:
> > It would be a big savings on the size of core and it seems like adding
> > those packages over there would be the most correct as the java packages
> > don't really have any necessary reason to be in core.
> 
> This is about as helpful a statement as saying C++ packages don't really
> have any necessary reason to be in core.  I think suggestions like this
> should be based on specific applications.

Exactly.

Jeremy



From green at redhat.com  Sat Nov 26 16:35:43 2005
From: green at redhat.com (Anthony Green)
Date: Sat, 26 Nov 2005 08:35:43 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021923.4178.14.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
Message-ID: <1133022944.3000.40.camel@localhost.localdomain>

On Sat, 2005-11-26 at 11:18 -0500, Konstantin Ryabitsev wrote:
> I'll add a little more flamage to the conversation and state that native
> eclipse is actually not that useful.

"native eclipse" is a misnomer.  There's a bug filed to rename it to
"Fedora Eclipse".  The Eclipse in FC will run just fine with a
proprietary Java alternative if you happen to install one.

We also use the Eclipse bytecode compiler to build virtually all of
the .jar files in FC/FE, so it's a critical component of the OS right
now.

AG




From skvidal at phy.duke.edu  Sat Nov 26 16:37:32 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:37:32 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133022644.2860.116.camel@bree.local.net>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<1133022644.2860.116.camel@bree.local.net>
Message-ID: <1133023052.17474.54.camel@cutter>

On Sat, 2005-11-26 at 11:30 -0500, Jeremy Katz wrote:
> On Sat, 2005-11-26 at 11:13 -0500, seth vidal wrote:
> > > It actually is dependent on eclipse to build.  And tomcat is
> > > increasingly a "core" server piece similar to php[1]
> > 
> > So why is it that servers have to be in core? Why not move tomcat
> > outside of core? What's the justification for having it in core? Hell,
> > same with php. The only thing I can think of that depends on php in core
> > is squirrelmail. Zope's not in core, it's in extras and its a server. 
> 
> Why is it that the desktop has to be in core?  I think we're moving
> towards having _less_ distinction between Core and Extras instead of
> more.  Your argument now is CD space, but we're going to want to get to
> where we have CDs of Extras and at that point, the distinction between
> the two becomes less clear.  
> 
> I've been one of the strongest proponents of shrinking Core for a while
> now, but I'm starting to wonder if that's really the answer.  But
> starting that argument now isn't going to accomplish anything.  It's not
> the sort of thing that's going to happen today or tomorrow.  And if I
> spend all day replying to mail on threads like this, I'm not going to
> get to any of the useful stuff that people want to see done :-/
> 

Then how about we approach this from another angle:

new packages[1] go to extras and get moved to core if they are valuable.


That way we don't see lots and lots of packages added to core just b/c
their maintainer happens to work at red hat.


-sv

[1] This excludes packages that are a part of base functionality - in
that I mean dependency packages that anaconda and the like require to do
their jobs.






From green at redhat.com  Sat Nov 26 16:40:06 2005
From: green at redhat.com (Anthony Green)
Date: Sat, 26 Nov 2005 08:40:06 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133022853.17474.51.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133022496.3000.36.camel@localhost.localdomain>
	<1133022853.17474.51.camel@cutter>
Message-ID: <1133023206.3000.44.camel@localhost.localdomain>

On Sat, 2005-11-26 at 11:34 -0500, seth vidal wrote:
> You said you included jonas in core in your most blog entry. Why didn't
> it go to extras by default. What is it about jonas that you thought
> meant it deserved to be in core? 

I really have nothing to do with JOnAS (or anything else in Core).  But
that's a fair question for somebody who does.

AG




From jfrieben at freesurf.fr  Sat Nov 26 16:42:56 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sat, 26 Nov 2005 17:42:56 +0100 (CET)
Subject: status of up2date and rhn-applet
In-Reply-To: <1133020904.2860.92.camel@bree.local.net>
References: <1133020904.2860.92.camel@bree.local.net>
Message-ID: <29411.194.94.224.254.1133023376.squirrel@arlette.freesurf.fr>

>
> And I argue that users don't know or care the difference between
> repositories and that by giving them the option of disabling just
> certain repositories, you're giving them a quick avenue to breaking
> their system.
>

I am a very user myself. So your statement is based on pure speculation.
Btw, this is the first time that I hear about repository interdependencies.
Things get somewhat ridiculous here.




From skvidal at phy.duke.edu  Sat Nov 26 16:45:02 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:45:02 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133023206.3000.44.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<1133022496.3000.36.camel@localhost.localdomain>
	<1133022853.17474.51.camel@cutter>
	<1133023206.3000.44.camel@localhost.localdomain>
Message-ID: <1133023502.17474.59.camel@cutter>

On Sat, 2005-11-26 at 08:40 -0800, Anthony Green wrote:
> On Sat, 2005-11-26 at 11:34 -0500, seth vidal wrote:
> > You said you included jonas in core in your most blog entry. Why didn't
> > it go to extras by default. What is it about jonas that you thought
> > meant it deserved to be in core? 
> 
> I really have nothing to do with JOnAS (or anything else in Core).  But
> that's a fair question for somebody who does.

ah, I inferred from your blog entry that you had included it. Sorry.  If
you are office-range of gary benson maybe you could ask him?

Thanks
-sv




From skvidal at phy.duke.edu  Sat Nov 26 16:40:23 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 11:40:23 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <17288.35383.421790.32377@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
Message-ID: <1133023224.17474.56.camel@cutter>


> ATM there is a gcj bug affecting the update manager.  This is fixed in
> gcc 4.1.  That said, the RPM-ification of Eclipse doesn't otherwise
> affect the update manager.  You just need to make a new update site in
> your home directory or the like.
> 
> 
> I didn't read all of this thread, but going by the
> Subject... segregating by implementation language doesn't make sense.
> Instead segregate by functionality.

actually the gist of the thread is - why do we keep adding new items to
core?

Why not add them to extras?

-sv




From wrrhdev at riede.org  Sat Nov 26 16:47:35 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 26 Nov 2005 16:47:35 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <1132983547.2860.32.camel@bree.local.net> (from
	katzj@redhat.com on Sat Nov 26 00:39:07 2005)
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
Message-ID: <1133023655l.3593l.6l@serve.riede.org>

On 11/26/2005 12:39:07 AM, Jeremy Katz wrote:
> On Fri, 2005-11-25 at 10:54 +0100, Joachim Frieben wrote:
> > "up2date-gnome" has a very clear, informative interface. You start with a
> > channel windows that allows you review the available channels and to make
> > your choice. Very nice, indeed.
> 
> Why would you want to not download updates from all repositories you
> have configured?  Or at least see what's available.  The fact that the
> updates come from multiple repositories is a detail that I don't think
> users really want to / should need to care about.

Maybe I shouldn't care, but I do. As an example, with all due respect to its  
creator, the atrpms repository holds both packages I want (unique  
functionality) and that I don't want (core replacements). Unfortunately that  
means I can never do a blind cross-the-board upgrade from all the sources I've  
identified.

Regards, Willem Riede.



From jspaleta at gmail.com  Sat Nov 26 16:54:50 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 11:54:50 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126162052.GA7201@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<1133019415.2860.75.camel@bree.local.net>
	<20051126154423.GA5854@jadzia.bu.edu>
	<604aa7910511260748r2d22a685y5e7f4cdb48c62c52@mail.gmail.com>
	<20051126162052.GA7201@jadzia.bu.edu>
Message-ID: <604aa7910511260854w306c7cd3kd2c5630f0f119cf5@mail.gmail.com>

On 11/26/05, Matthew Miller <mattdm at mattdm.org> wrote:
> 'Cause it's a pain to create a kickstart file to install just one server
> system.

Its also a pain to create your own distro for one server system.
You missed my point.... can't this community create a variety of
useful kickstart files and SHARE THEM?  Surely there are have to be a
cononical collection  of kickstart files that more than one person in
this community would like to use? Certaintly one example of such a
kickstart file is equilalent to whatever anaconda could provide as a
"minimal" install.

-jef



From green at redhat.com  Sat Nov 26 16:57:06 2005
From: green at redhat.com (Anthony Green)
Date: Sat, 26 Nov 2005 08:57:06 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133023224.17474.56.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
Message-ID: <1133024226.3000.51.camel@localhost.localdomain>

On Sat, 2005-11-26 at 11:40 -0500, seth vidal wrote:
> actually the gist of the thread is - why do we keep adding new items
> to
> core?

I believe that all of the new Java packages in Core are in support of
JOnAS.  It's just that there are a lot of them.

Any other new java packages have only gone in Extras.

AG




From jkeating at j2solutions.net  Sat Nov 26 16:57:09 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 26 Nov 2005 08:57:09 -0800
Subject: status of up2date and rhn-applet
In-Reply-To: <29411.194.94.224.254.1133023376.squirrel@arlette.freesurf.fr>
References: <1133020904.2860.92.camel@bree.local.net>
	<29411.194.94.224.254.1133023376.squirrel@arlette.freesurf.fr>
Message-ID: <1133024229.2812.7.camel@yoda.loki.me>

On Sat, 2005-11-26 at 17:42 +0100, Joachim Frieben wrote:
> I am a very user myself. So your statement is based on pure speculation.
> Btw, this is the first time that I hear about repository interdependencies.
> Things get somewhat ridiculous here.

What a lot of people don't realize is that the users on this list aren't
really the target audience of Fedora.  Fedora is programmed to cater to
the users we don't really hear from.  The ones that aren't beta testers,
aren't deep system hackers, etc..  They're the ones that just use our
software and when something breaks, they're usually the ones that go to
forums or their lug to figure it out, or write a silly slam on some
review site.  Think about the target user for Gnome.  Thats basically
where the UI is going for the tools that Red Hat creates for Fedora.

In this case, I agree with Jeremy.  The users that really would care
about disabling certain repos can easily do it in the conf files,
whereas exposing this to other end users would be confusing and
misleading and could cause real problems.

Inter-repo dependencies do exist.  In particular with Livna and Fedora
Extras.  Now we can talk about Livna being full of forbidden items all
we want, but the fact is that it gets used and used a lot.  Other such
deps happen as well with other popular 3rd party repos.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From mike at mommabears.com  Sat Nov 26 16:55:07 2005
From: mike at mommabears.com (MJang)
Date: Sat, 26 Nov 2005 08:55:07 -0800
Subject: What about smartpm?
Message-ID: <1133024107.4090.14.camel@localhost>

Folks, 

With all the talk about pup replacing up2date on FC5, and lots of people
trying yumex and wondering about upgrades to system-config-packages, I
was wondering about the Smart Package Manager. http://labix.org/smart 

A couple of months ago, I was under the impression that all the distros
were moving in that direction, as Smartpm can handle upgrades to both
RPMs and DEBs and can work from all kinds of repositories (apt, yum,
urpmi, slack, etc.). Is Smartpm still under consideration for FC5?

Thanks,
Mike



From jspaleta at gmail.com  Sat Nov 26 17:02:57 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 12:02:57 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133023224.17474.56.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
Message-ID: <604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>

On 11/26/05, seth vidal <skvidal at phy.duke.edu> wrote:
> actually the gist of the thread is - why do we keep adding new items to
> core?
>
> Why not add them to extras?


There's a corollary to that... does Core need to be self-hosting? Or
is it enough to have Core+Extras build self consistent?

In the future will it be possible for Core to pull buildrequirements
from Extras so that Core applications can exist but some of their
build requirements live in Extras?

-jef



From jkeating at j2solutions.net  Sat Nov 26 17:06:29 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 26 Nov 2005 09:06:29 -0800
Subject: What about smartpm?
In-Reply-To: <1133024107.4090.14.camel@localhost>
References: <1133024107.4090.14.camel@localhost>
Message-ID: <1133024789.2812.9.camel@yoda.loki.me>

On Sat, 2005-11-26 at 08:55 -0800, MJang wrote:
> 
> A couple of months ago, I was under the impression that all the distros
> were moving in that direction, as Smartpm can handle upgrades to both
> RPMs and DEBs and can work from all kinds of repositories (apt, yum,
> urpmi, slack, etc.). Is Smartpm still under consideration for FC5?

As far as I know, no.  Duplicate functionality.  Fedora doesn't use apt,
no need to worry about that from a Fedora standpoint.  Fedora uses yum,
yum cli updates, pup graphically updates.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Sat Nov 26 17:12:43 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 26 Nov 2005 09:12:43 -0800
Subject: What about smartpm?
In-Reply-To: <1133024789.2812.9.camel@yoda.loki.me>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me>
Message-ID: <1133025163.2812.11.camel@yoda.loki.me>

On Sat, 2005-11-26 at 09:06 -0800, Jesse Keating wrote:
> On Sat, 2005-11-26 at 08:55 -0800, MJang wrote:
> > 
> > A couple of months ago, I was under the impression that all the distros
> > were moving in that direction, as Smartpm can handle upgrades to both
> > RPMs and DEBs and can work from all kinds of repositories (apt, yum,
> > urpmi, slack, etc.). Is Smartpm still under consideration for FC5?
> 
> As far as I know, no.  Duplicate functionality.  Fedora doesn't use apt,
> no need to worry about that from a Fedora standpoint.  Fedora uses yum,
> yum cli updates, pup graphically updates.
> 

This said, I don't see much reason why smartrpm couldn't go into extras,
if it isn't already there.  There is just no reason to put it into core.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From skvidal at phy.duke.edu  Sat Nov 26 17:27:41 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 12:27:41 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133024226.3000.51.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<1133024226.3000.51.camel@localhost.localdomain>
Message-ID: <1133026061.17474.61.camel@cutter>

On Sat, 2005-11-26 at 08:57 -0800, Anthony Green wrote:
> On Sat, 2005-11-26 at 11:40 -0500, seth vidal wrote:
> > actually the gist of the thread is - why do we keep adding new items
> > to
> > core?
> 
> I believe that all of the new Java packages in Core are in support of
> JOnAS.  It's just that there are a lot of them.

So then the question is the same - what makes jonas core but zope not
core?

-sv




From skvidal at phy.duke.edu  Sat Nov 26 17:29:23 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 12:29:23 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
Message-ID: <1133026163.17474.63.camel@cutter>

On Sat, 2005-11-26 at 12:02 -0500, Jeff Spaleta wrote:
> On 11/26/05, seth vidal <skvidal at phy.duke.edu> wrote:
> > actually the gist of the thread is - why do we keep adding new items to
> > core?
> >
> > Why not add them to extras?
> 
> 
> There's a corollary to that... does Core need to be self-hosting? Or
> is it enough to have Core+Extras build self consistent?

I think core needs to be self hosting, yes.

otherwise it makes building things from scratch a little bit of a
chicken-egg problem.

-sv




From jspaleta at gmail.com  Sat Nov 26 17:13:41 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 12:13:41 -0500
Subject: What about smartpm?
In-Reply-To: <1133024107.4090.14.camel@localhost>
References: <1133024107.4090.14.camel@localhost>
Message-ID: <604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>

On 11/26/05, MJang <mike at mommabears.com> wrote:
> A couple of months ago, I was under the impression that all the distros
> were moving in that direction, as Smartpm can handle upgrades to both
> RPMs and DEBs and can work from all kinds of repositories (apt, yum,
> urpmi, slack, etc.). Is Smartpm still under consideration for FC5?

smartpm was never under consideration.  The fact that noone in the
community of contributors has yet packaged it as part of Extras should
tell you something important.

-jef



From davej at redhat.com  Sat Nov 26 17:45:27 2005
From: davej at redhat.com (Dave Jones)
Date: Sat, 26 Nov 2005 12:45:27 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133020593.2860.86.camel@bree.local.net>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<1133020593.2860.86.camel@bree.local.net>
Message-ID: <20051126174527.GF4638@redhat.com>

On Sat, Nov 26, 2005 at 10:56:33AM -0500, Jeremy Katz wrote:

 > Frankly, rawhide _isn't_ safe for the casual user and I'm surprised to
 > see you even insinuate that it could be. :)   updates-testing should be
 > much safer, but I still think there's a degree of familiarity that's
 > required to make it actually effective for someone to use it.

Agreed, though at the same time, -testing doesn't get anywhere near
the amount of testing that we'd like it to. A lot of really nasty
bugs only seem to get found after we've moved them to updates-final.
Making it as easy as possible to enable those, whilst displaying
a warning is definitly in our best interest imo.

		Dave



From dakingun at gmail.com  Sat Nov 26 17:56:22 2005
From: dakingun at gmail.com (Deji Akingunola)
Date: Sat, 26 Nov 2005 12:56:22 -0500
Subject: What about smartpm?
In-Reply-To: <604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
Message-ID: <b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>

On 11/26/05, Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> smartpm was never under consideration.  The fact that noone in the
> community of contributors has yet packaged it as part of Extras should
> tell you something important.
>
I remember someone proposed it in the very early days of extras
(before the bugzilla system), but no one ever step up to sponsor it,
and I guess the contributor got discouraged .

Deji



From jspaleta at gmail.com  Sat Nov 26 17:13:41 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 12:13:41 -0500
Subject: What about smartpm?
In-Reply-To: <1133024107.4090.14.camel@localhost>
References: <1133024107.4090.14.camel@localhost>
Message-ID: <604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>

On 11/26/05, MJang <mike at mommabears.com> wrote:
> A couple of months ago, I was under the impression that all the distros
> were moving in that direction, as Smartpm can handle upgrades to both
> RPMs and DEBs and can work from all kinds of repositories (apt, yum,
> urpmi, slack, etc.). Is Smartpm still under consideration for FC5?

smartpm was never under consideration.  The fact that noone in the
community of contributors has yet packaged it as part of Extras should
tell you something important.

-jef



From katzj at redhat.com  Sat Nov 26 18:03:20 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 13:03:20 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
Message-ID: <1133028200.2860.121.camel@bree.local.net>

On Sat, 2005-11-26 at 12:02 -0500, Jeff Spaleta wrote:
> On 11/26/05, seth vidal <skvidal at phy.duke.edu> wrote:
> > actually the gist of the thread is - why do we keep adding new items to
> > core?
> >
> > Why not add them to extras?
> 
> There's a corollary to that... does Core need to be self-hosting? Or
> is it enough to have Core+Extras build self consistent?

Yes.  Core must be self-hosting. 

Jeremy



From katzj at redhat.com  Sat Nov 26 18:04:38 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Sat, 26 Nov 2005 13:04:38 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133026061.17474.61.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<1133024226.3000.51.camel@localhost.localdomain>
	<1133026061.17474.61.camel@cutter>
Message-ID: <1133028278.2860.124.camel@bree.local.net>

On Sat, 2005-11-26 at 12:27 -0500, seth vidal wrote:
> On Sat, 2005-11-26 at 08:57 -0800, Anthony Green wrote:
> > On Sat, 2005-11-26 at 11:40 -0500, seth vidal wrote:
> > > actually the gist of the thread is - why do we keep adding new items
> > > to
> > > core?
> > 
> > I believe that all of the new Java packages in Core are in support of
> > JOnAS.  It's just that there are a lot of them.
> 
> So then the question is the same - what makes jonas core but zope not
> core?

That is a much fairer question.  And one I asked right before test1
release, but actually getting the question to resolution was much lower
on my list of priorities than getting modular X working, getting CD
installs working and just basically making test1 happen :-)

Jeremy



From jspaleta at gmail.com  Sat Nov 26 18:09:04 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 13:09:04 -0500
Subject: What about smartpm?
In-Reply-To: <b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
	<b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>
Message-ID: <604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>

On 11/26/05, Deji Akingunola <dakingun at gmail.com> wrote:
> I remember someone proposed it in the very early days of extras
> (before the bugzilla system), but no one ever step up to sponsor it,
> and I guess the contributor got discouraged .

Please.... find the post me to the post in the fedora-extras-list
archive where the submission request was made, because I certaintly
can't find it.

https://www.redhat.com/archives/fedora-extras-list/

-jef



From jkeating at j2solutions.net  Sat Nov 26 18:26:05 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sat, 26 Nov 2005 10:26:05 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133028278.2860.124.camel@bree.local.net>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<1133024226.3000.51.camel@localhost.localdomain>
	<1133026061.17474.61.camel@cutter>
	<1133028278.2860.124.camel@bree.local.net>
Message-ID: <1133029565.2812.13.camel@yoda.loki.me>

On Sat, 2005-11-26 at 13:04 -0500, Jeremy Katz wrote:
> That is a much fairer question.  And one I asked right before test1
> release, but actually getting the question to resolution was much lower
> on my list of priorities than getting modular X working, getting CD
> installs working and just basically making test1 happen :-)

I can add that to my to-do list.  It's rather empty at the
moment.... /me looks toward Dec 1st.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From cra at WPI.EDU  Sat Nov 26 18:34:19 2005
From: cra at WPI.EDU (Chuck Anderson)
Date: Sat, 26 Nov 2005 13:34:19 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <20051126174527.GF4638@redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<1133020593.2860.86.camel@bree.local.net>
	<20051126174527.GF4638@redhat.com>
Message-ID: <20051126183419.GA20735@angus.ind.WPI.EDU>

On Sat, Nov 26, 2005 at 12:45:27PM -0500, Dave Jones wrote:
> Agreed, though at the same time, -testing doesn't get anywhere near
> the amount of testing that we'd like it to. A lot of really nasty
> bugs only seem to get found after we've moved them to updates-final.
> Making it as easy as possible to enable those, whilst displaying
> a warning is definitly in our best interest imo.

Making sure updates-testing has repo closure may scare fewer people 
away from it.  I keep updates-testing enabled on all my non-critical 
boxes, and saw recently e.g.:

Error: Missing Dependency: gcc = 4.0.1 is needed by package libtool



From wrrhdev at riede.org  Sat Nov 26 18:30:02 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sat, 26 Nov 2005 18:30:02 +0000
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126143949.GA2261@jadzia.bu.edu> (from mattdm@mattdm.org
	on Sat Nov 26 09:39:49 2005)
Message-ID: <1133029802l.3593l.8l@serve.riede.org>

On 11/26/2005 09:39:49 AM, Matthew Miller wrote:
> On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
> > In a lot of cases, packages which aren't listed in the comps file at all
> > (or aren't a dependency of something) perhaps _should_ move to Extras.
> > In addition, I think there probably are packages which should move
> > somewhere into the comps file.  File bugs against comps for things that
> > should be listed and aren't.
> 
> How about making Anaconda always only do a minimal install, and make
> firstboot have the option to install other things if you want 'em? :)

That's not really a solution, because it only moves the problem to a different  
place. We still need to code to make selecting what a user wants to have  
installed easy and ergonomically sound. And if we have that code, I prefer to  
have it run from anaconda, because I believe that makes for the better user  
experience.

Regards, Willem Riede.



From dakingun at gmail.com  Sat Nov 26 18:46:08 2005
From: dakingun at gmail.com (Deji Akingunola)
Date: Sat, 26 Nov 2005 13:46:08 -0500
Subject: What about smartpm?
In-Reply-To: <604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
	<b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>
	<604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
Message-ID: <b80014de0511261046l605f37efl6f6fb45444fe71bd@mail.gmail.com>

On 11/26/05, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 11/26/05, Deji Akingunola <dakingun at gmail.com> wrote:
> > I remember someone proposed it in the very early days of extras
> > (before the bugzilla system), but no one ever step up to sponsor it,
> > and I guess the contributor got discouraged .
>
> Please.... find the post me to the post in the fedora-extras-list
> archive where the submission request was made, because I certaintly
> can't find it.
>
oh, it was even before people started posting to the list. I'm sure it
was submitted for consideration at that time people had to edit the
wiki to request for a sponsor.

Deji



From d.jacobfeuerborn at conversis.de  Sat Nov 26 19:33:57 2005
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Sat, 26 Nov 2005 20:33:57 +0100
Subject: SELinux problems
Message-ID: <4388B8A5.4090800@conversis.de>

I noticed that on bootup the Fedora now shows a ton of messages like these 
on the screen:

inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for 
dev=hda2 ino=20447255

Does anybody know how to fix this? (I'm running selinux set to 
targeted/permissive)

Regards,
   Dennis



From Axel.Thimm at ATrpms.net  Sat Nov 26 20:02:14 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sat, 26 Nov 2005 21:02:14 +0100
Subject: bad alsa versioning (was: rawhide report: 20051124 changes)
In-Reply-To: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
References: <200511241817.jAOIHKWE001104@porkchop.devel.redhat.com>
Message-ID: <20051126200214.GA15947@neu.nirvana>

On Thu, Nov 24, 2005 at 01:17:20PM -0500, Build System wrote:
> alsa-lib-1.0.10rf-1
> * Thu Nov 24 2005 Martin Stransky <stransky at redhat.com> 1.0.10rf-1
> - new upstream version
> 
> alsa-utils-1.0.10rf-1
> * Thu Nov 24 2005 Martin Stransky <stransky at redhat.com> 1.0.10rf-1
> - new upstream version
> - added alias for snd-azx

Please don't use rc, rf etc. in the version field. alsa tradition will
certainly bring an alsa 1.0.10a, and the package of it will be called
1.0.10rfa? Better is

1.0.10rc<N>:  alsa-1.0.10-<anything you like>_rc<N>
1.0.10 final: alsa-1.0.10-<anything you like +1>
1.0.10a:      alsa-1.0.10a-...

"anything you like" can be 0, or anything you like ...

Since this is rawhide/FC5t1 please undo the versioning, thanks!

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158859

-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051126/1fe6ba3d/attachment.sig>

From fedora-devel at stefan-neufeind.de  Sat Nov 26 20:09:45 2005
From: fedora-devel at stefan-neufeind.de (Stefan Neufeind)
Date: Sat, 26 Nov 2005 21:09:45 +0100
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <1133021673.17474.46.camel@cutter>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
Message-ID: <4388C109.10808@stefan-neufeind.de>

seth vidal wrote:
> On Sat, 2005-11-26 at 17:01 +0100, Stefan Neufeind wrote:
> 
>>I just saw that a simple "yum install lm_sensors" tried to install the
>>same versions of lm_sensors for i386 _and_ x86_64 at the same time, when
>>installing on arch=x86_64. Is there a hidden sense behind that, or does
>>the i386-package maybe need to be removed?
> 
> by default if you do not specify an arch yum will install all arches
> that _can_ be installed.
> 
> no, I don't want to hear any bitching and moaning about this, that's how
> it is.
> 
> if you want only .x86_64 then install lm_sensors.x86_64

Okay, but that's the cause that I use the x86_64 arch-directory for my
repo, isn't it? The i386-files are already under i386 to my
understanding ...


Regards,
 Stefan



From mattdm at mattdm.org  Sat Nov 26 20:38:04 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 15:38:04 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
	<17288.35383.421790.32377@localhost.localdomain>
	<1133023224.17474.56.camel@cutter>
	<604aa7910511260902u7d41aa69jecc1071069d2dd48@mail.gmail.com>
Message-ID: <20051126203804.GA13904@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 12:02:57PM -0500, Jeff Spaleta wrote:
> There's a corollary to that... does Core need to be self-hosting? Or
> is it enough to have Core+Extras build self consistent?

I think calling it "Core" implies self-hosting.



-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From zaitcev at redhat.com  Sat Nov 26 21:09:44 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Sat, 26 Nov 2005 13:09:44 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <20051126130944.0b3ed979.zaitcev@redhat.com>

On Sat, 26 Nov 2005 10:43:08 -0500, seth vidal <skvidal at phy.duke.edu> wrote:

> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?

If you can split gcj off gij and Classpath, then sure, why not,
together with g++. They are the same thing, aren't they? Both are
equally optional. And both save about the same amount of space (gcc-c++
is 5.7MB, gcc-java is 5.2MB). The gcc itself may be needed for a few
things in the core.

-- Pete



From skvidal at phy.duke.edu  Sat Nov 26 21:19:29 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 16:19:29 -0500
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <4388C109.10808@stefan-neufeind.de>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter> <4388C109.10808@stefan-neufeind.de>
Message-ID: <1133039969.17474.69.camel@cutter>

On Sat, 2005-11-26 at 21:09 +0100, Stefan Neufeind wrote:
> seth vidal wrote:
> > On Sat, 2005-11-26 at 17:01 +0100, Stefan Neufeind wrote:
> > 
> >>I just saw that a simple "yum install lm_sensors" tried to install the
> >>same versions of lm_sensors for i386 _and_ x86_64 at the same time, when
> >>installing on arch=x86_64. Is there a hidden sense behind that, or does
> >>the i386-package maybe need to be removed?
> > 
> > by default if you do not specify an arch yum will install all arches
> > that _can_ be installed.
> > 
> > no, I don't want to hear any bitching and moaning about this, that's how
> > it is.
> > 
> > if you want only .x86_64 then install lm_sensors.x86_64
> 
> Okay, but that's the cause that I use the x86_64 arch-directory for my
> repo, isn't it? The i386-files are already under i386 to my
> understanding ...

no, not all of them. Some i386 packages are included in the x86_64
repositories for fedora core.

-sv




From wtogami at redhat.com  Sat Nov 26 21:46:11 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 26 Nov 2005 16:46:11 -0500
Subject: What about smartpm?
In-Reply-To: <b80014de0511261046l605f37efl6f6fb45444fe71bd@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>	<b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>	<604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
	<b80014de0511261046l605f37efl6f6fb45444fe71bd@mail.gmail.com>
Message-ID: <4388D7A3.1040801@redhat.com>

Deji Akingunola wrote:
> On 11/26/05, Jeff Spaleta <jspaleta at gmail.com> wrote:
> 
>>On 11/26/05, Deji Akingunola <dakingun at gmail.com> wrote:
>>
>>>I remember someone proposed it in the very early days of extras
>>>(before the bugzilla system), but no one ever step up to sponsor it,
>>>and I guess the contributor got discouraged .
>>
>>Please.... find the post me to the post in the fedora-extras-list
>>archive where the submission request was made, because I certaintly
>>can't find it.
>>
> 
> oh, it was even before people started posting to the list. I'm sure it
> was submitted for consideration at that time people had to edit the
> wiki to request for a sponsor.
> 
> Deji
> 

Extras never worked in this fashion.  It went from fedora.us Bugzilla -> 
  fedora-extras-list -> redhat.com Bugzilla.

Warren Togami
wtogami at redhat.com



From laroche at redhat.com  Sat Nov 26 21:53:13 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sat, 26 Nov 2005 22:53:13 +0100
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <1133021673.17474.46.camel@cutter>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
Message-ID: <20051126215313.GA3920@dudweiler.stuttgart.redhat.com>

> no, I don't want to hear any bitching and moaning about this, that's how
> it is.

At some point we should change this to only pull in as few packages as
really needed, but that also comes with quite some calculation cost.

This should really be something where yum, up2date and smart algorithms
should work together and then implement the best solution available.

regards,

Florian La Roche



From skvidal at phy.duke.edu  Sat Nov 26 22:33:16 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sat, 26 Nov 2005 17:33:16 -0500
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
	<20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
Message-ID: <1133044397.17474.76.camel@cutter>

On Sat, 2005-11-26 at 22:53 +0100, Florian La Roche wrote:
> > no, I don't want to hear any bitching and moaning about this, that's how
> > it is.
> 
> At some point we should change this to only pull in as few packages as
> really needed, but that also comes with quite some calculation cost.

why isn't the way it's currently being done correct? We've gone round
and round on this and its always come down to how to handle globs of
commands.

> This should really be something where yum, up2date and smart algorithms
> should work together and then implement the best solution available.

is up2date much of a concern anymore?

-sv




From ihok at hotmail.com  Sat Nov 26 22:33:56 2005
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 26 Nov 2005 17:33:56 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
Message-ID: <4388E2D4.5050301@hotmail.com>

Jeff Spaleta wrote:
> On the topic of notifications.... would it be possible for have room
> in the notification metadata for a "repo notification"?  When a person

Speaking generally, would it help the user experience if yum/pup could 
warn the user if a package installed from repo A is about to be replaced 
with a package from repo B?

This notification could come up when the user enables a repo for the 
first time, and/or when the replacement is actually about to happen.

The user would ideally then be able to set a pref to be warned a) never, 
b) only if a package from core is replaced, c) every time a cross-repo 
upgrade is about to take place.

So that we don't break the nightly yum update, cross-repo upgrades 
should get logged. If the user chooses to be warned along scenarios B or 
C, the log could contain a message like "We did not upgrade package X to 
version Y from repo FOO, because it was originally installed from repo BAR."

I guess the general idea is that every package gets affiliated to a 
preferred repo at time of first install of that package, and users can 
expect to rely on that behavior.

This would help with both the updates-testing problem that Jeff and 
Jeremy are talking about, also help Willem's poblem, because neither 
atrpms nor updates-testing would override packages when they shouldn't.



From ihok at hotmail.com  Sat Nov 26 22:33:56 2005
From: ihok at hotmail.com (Jack Tanner)
Date: Sat, 26 Nov 2005 17:33:56 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
Message-ID: <4388E2D4.5050301@hotmail.com>

Jeff Spaleta wrote:
> On the topic of notifications.... would it be possible for have room
> in the notification metadata for a "repo notification"?  When a person

Speaking generally, would it help the user experience if yum/pup could 
warn the user if a package installed from repo A is about to be replaced 
with a package from repo B?

This notification could come up when the user enables a repo for the 
first time, and/or when the replacement is actually about to happen.

The user would ideally then be able to set a pref to be warned a) never, 
b) only if a package from core is replaced, c) every time a cross-repo 
upgrade is about to take place.

So that we don't break the nightly yum update, cross-repo upgrades 
should get logged. If the user chooses to be warned along scenarios B or 
C, the log could contain a message like "We did not upgrade package X to 
version Y from repo FOO, because it was originally installed from repo BAR."

I guess the general idea is that every package gets affiliated to a 
preferred repo at time of first install of that package, and users can 
expect to rely on that behavior.

This would help with both the updates-testing problem that Jeff and 
Jeremy are talking about, also help Willem's poblem, because neither 
atrpms nor updates-testing would override packages when they shouldn't.



From jspaleta at gmail.com  Sat Nov 26 22:39:45 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 17:39:45 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <4388E2D4.5050301@hotmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com>
Message-ID: <604aa7910511261439y2cbcf62es7a166b4612539218@mail.gmail.com>

On 11/26/05, Jack Tanner <ihok at hotmail.com> wrote:
> Jeff Spaleta wrote:
> > On the topic of notifications.... would it be possible for have room
> > in the notification metadata for a "repo notification"?  When a person
>
> Speaking generally, would it help the user experience if yum/pup could
> warn the user if a package installed from repo A is about to be replaced
> with a package from repo B?

That's not so easy to determine...  if you have package foo-1 from extras
and then extras pushes foo-2  and cleans out foo-1 from its directory
at some point. And then crappyrpms.org pushes foo-3... how does yum
know the foo-1 package you have installed is from extras?

You could implement a check against a change in signature... but the
worth of that is somewhat limited as well. for example I don't think
packages in updates-testing are signed with a different key than
updates-released so you just checking a change in signature doesn't
catch i change in repo.

-jef



From mail-lists at karan.org  Sat Nov 26 22:43:54 2005
From: mail-lists at karan.org (Karanbir Singh)
Date: Sat, 26 Nov 2005 22:43:54 +0000
Subject: What about smartpm?
In-Reply-To: <604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>	<b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>
	<604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
Message-ID: <4388E52A.5080700@karan.org>

Jeff Spaleta wrote:
> On 11/26/05, Deji Akingunola <dakingun at gmail.com> wrote:
> 
>>I remember someone proposed it in the very early days of extras
>>(before the bugzilla system), but no one ever step up to sponsor it,
>>and I guess the contributor got discouraged .
> 
> 
> Please.... find the post me to the post in the fedora-extras-list
> archive where the submission request was made, because I certaintly
> can't find it.
> 
> https://www.redhat.com/archives/fedora-extras-list/
> 

is this the thread being spoken of :

https://www.redhat.com/archives/fedora-devel-list/2005-June/msg00783.html

while an intent to package seems to have been there, nothing beyond that 
was actually done.

- K



From wrrhdev at riede.org  Sun Nov 27 03:07:20 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 27 Nov 2005 03:07:20 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <4388E2D4.5050301@hotmail.com> (from ihok@hotmail.com on Sat
	Nov 26 17:33:56 2005)
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com>
Message-ID: <1133060840l.22893l.0l@serve.riede.org>

On 11/26/2005 05:33:56 PM, Jack Tanner wrote:
> Jeff Spaleta wrote:
>> On the topic of notifications.... would it be possible for have room
>> in the notification metadata for a "repo notification"?  When a person
> 
> Speaking generally, would it help the user experience if yum/pup could warn  
> the user if a package installed from repo A is about to be replaced with a  
> package from repo B?
> 
> This notification could come up when the user enables a repo for the first  
> time, and/or when the replacement is actually about to happen.
> 
> The user would ideally then be able to set a pref to be warned a) never, b)  
> only if a package from core is replaced, c) every time a cross-repo upgrade  
> is about to take place.
> 
> So that we don't break the nightly yum update, cross-repo upgrades should  
> get logged. If the user chooses to be warned along scenarios B or C, the log  
> could contain a message like "We did not upgrade package X to version Y from  
> repo FOO, because it was originally installed from repo BAR."
> 
> I guess the general idea is that every package gets affiliated to a  
> preferred repo at time of first install of that package, and users can  
> expect to rely on that behavior.
> 
> This would help with both the updates-testing problem that Jeff and Jeremy  
> are talking about, also help Willem's poblem, because neither atrpms nor  
> updates-testing would override packages when they shouldn't.

It would be useful (I have often wished it did) if e.g. yum list x would not  
just tell me some release of x is installed, but also from which repo it came  
when it was installed. But I'm not sure the rpm database contains that  
information, so this may not be possible?

Thanks, Willem Riede.



From bojan at rexursive.com  Sun Nov 27 03:17:53 2005
From: bojan at rexursive.com (Bojan Smojver)
Date: Sun, 27 Nov 2005 14:17:53 +1100
Subject: UDEV and SELinux
In-Reply-To: <8719b8230511260828q635c39x22a39ac8df90942@mail.gmail.com>
References: <8719b8230511260828q635c39x22a39ac8df90942@mail.gmail.com>
Message-ID: <1133061474.2266.3.camel@coyote.rexursive.com>

On Sat, 2005-11-26 at 11:28 -0500, Ryan Skadberg wrote:

> So, it looks like the slow udev issue has something to do with
> SELinux.   I have SELinux set up with: 
> 
> SELINUX=enforcing
> SELINUXTYPE=targeted

Yep, I can verify that to be true on my box as well. Actually, even with
SELINUX=permissive, the "Starting udev" takes about 1 minute. Other
things are noticeably slower with SELinux turned on as well (e.g. X
startup).

> If I switch enforcing to disabled, startup works much faster.

Check. It takes only a few seconds now to do "Starting udev" and
"Initializing hardware" with SELinux disabled. I'm running udev-0.75-5.

-- 
Bojan



From sundaram at redhat.com  Sun Nov 27 03:21:06 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 27 Nov 2005 08:51:06 +0530
Subject: status of up2date and rhn-applet
In-Reply-To: <1133060840l.22893l.0l@serve.riede.org>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<1132983547.2860.32.camel@bree.local.net>	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>	<4388E2D4.5050301@hotmail.com>
	<1133060840l.22893l.0l@serve.riede.org>
Message-ID: <43892622.4070103@redhat.com>

Hi

>
> It would be useful (I have often wished it did) if e.g. yum list x 
> would not  just tell me some release of x is installed, but also from 
> which repo it came  when it was installed. But I'm not sure the rpm 
> database contains that  information, so this may not be possible? 

Umm. It already does that. The last item in the list is the repository 
name. If you are running rawhide, it would development or 
extras-development.

regards
Rahul



From wrrhdev at riede.org  Sun Nov 27 03:26:44 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 27 Nov 2005 03:26:44 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <43892622.4070103@redhat.com> (from sundaram@redhat.com on Sat
	Nov 26 22:21:06 2005)
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<43892622.4070103@redhat.com>
Message-ID: <1133062004l.22893l.1l@serve.riede.org>

On 11/26/2005 10:21:06 PM, Rahul Sundaram wrote:
> Hi
> 
>> 
>> It would be useful (I have often wished it did) if e.g. yum list x would  
>> not  just tell me some release of x is installed, but also from which repo  
>> it came  when it was installed. But I'm not sure the rpm database contains  
>> that  information, so this may not be possible?
> 
> Umm. It already does that. The last item in the list is the repository name.  
> If you are running rawhide, it would development or extras-development.

Really?


[root at athena ~]# yum list gdb
Loading "installonlyn" plugin
Setting up repositories
development               100% |=========================| 1.1 kB    00:00
extras-development        100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Installed Packages
gdb.x86_64                               6.3.0.0-1.81           installed

[root at athena ~]# rpm -q fedora-release
fedora-release-4-99.rawhide

Regards, Willem Riede.



From sundaram at redhat.com  Sun Nov 27 03:30:37 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 27 Nov 2005 09:00:37 +0530
Subject: status of up2date and rhn-applet
In-Reply-To: <1133062004l.22893l.1l@serve.riede.org>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<1132983547.2860.32.camel@bree.local.net>	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>	<4388E2D4.5050301@hotmail.com>
	<1133060840l.22893l.0l@serve.riede.org>	<43892622.4070103@redhat.com>
	<1133062004l.22893l.1l@serve.riede.org>
Message-ID: <4389285D.7080600@redhat.com>

Hi

>
> [root at athena ~]# yum list gdb
> Loading "installonlyn" plugin
> Setting up repositories
> development               100% |=========================| 1.1 kB    
> 00:00
> extras-development        100% |=========================| 1.1 kB    
> 00:00
> Reading repository metadata in from local files
> Installed Packages
> gdb.x86_64                               6.3.0.0-1.81           installed
>
> [root at athena ~]# rpm -q fedora-release
> fedora-release-4-99.rawhide

Try a non installed package ;-)

regards
Rahul



From mattdm at mattdm.org  Sun Nov 27 03:34:57 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sat, 26 Nov 2005 22:34:57 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133062004l.22893l.1l@serve.riede.org>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com>
	<1133060840l.22893l.0l@serve.riede.org>
	<43892622.4070103@redhat.com>
	<1133062004l.22893l.1l@serve.riede.org>
Message-ID: <20051127033457.GA27633@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 03:26:44AM +0000, Willem Riede wrote:
> >Umm. It already does that. The last item in the list is the repository 
> >name.  If you are running rawhide, it would development or 
> >extras-development.
> Really?
[...]
> gdb.x86_64                               6.3.0.0-1.81           installed

Right -- for installed packages, the information is gone and isn't stored in
the RPM database for yum to access. So it says "installed" instead.

If we could all get our act together and make good, useful standard settings
for the Vendor tag (or Group tag, maybe), then maybe this could be
addressed. But that's got all sorts of issues of its own.
-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From admin at ramshacklestudios.com  Sun Nov 27 03:35:28 2005
From: admin at ramshacklestudios.com (Peter Gordon)
Date: Sat, 26 Nov 2005 19:35:28 -0800
Subject: status of up2date and rhn-applet
In-Reply-To: <43892622.4070103@redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<43892622.4070103@redhat.com>
Message-ID: <1133062528.26615.9.camel@tuxhugger>

On Sun, 2005-11-27 at 08:51 +0530, Rahul Sundaram wrote:
> >
> > It would be useful (I have often wished it did) if e.g. yum list x 
> > would not  just tell me some release of x is installed, but also from 
> > which repo it came  when it was installed. But I'm not sure the rpm 
> > database contains that  information, so this may not be possible? 
> 
> Umm. It already does that. The last item in the list is the repository 
> name. If you are running rawhide, it would development or 
> extras-development.
> 
> regards
> Rahul
> 
Rahul, 

Perhaps I'm simply misunderstanding, but I think what Willem's referring
to is that, for installed packages, it simply lists "installed" as the
repository. For example, `yum list totem` returns:

Available Packages
totem.i386	1.0.4-1		installed

What I believe that Willem is trying to explain is that Yum should show
which repo it was installed from, perhaps with output such as:

Available Packages
totem.i386	1.0.4-1		installed (from updates-released)

I've not at all delved into the internals of Yum or RPM's
database handling, so I'm not sure of its plausibility. Hmm. :-/
-- 
Peter Gordon (codergeek42)
GnuPG Public Key: 0xDA3634D7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051126/a311d901/attachment.sig>

From sundaram at redhat.com  Sun Nov 27 03:39:01 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Sun, 27 Nov 2005 09:09:01 +0530
Subject: status of up2date and rhn-applet
In-Reply-To: <1133062528.26615.9.camel@tuxhugger>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<1132983547.2860.32.camel@bree.local.net>	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>	<4388E2D4.5050301@hotmail.com>
	<1133060840l.22893l.0l@serve.riede.org>	<43892622.4070103@redhat.com>
	<1133062528.26615.9.camel@tuxhugger>
Message-ID: <43892A55.9080700@redhat.com>

Hi

>Rahul, 
>
>Perhaps I'm simply misunderstanding, but I think what Willem's referring
>to is that, for installed packages, it simply lists "installed" as the
>repository. For example, `yum list totem` returns:
>
>Available Packages
>totem.i386	1.0.4-1		installed
>
>What I believe that Willem is trying to explain is that Yum should show
>which repo it was installed from, perhaps with output such as:
>
>Available Packages
>totem.i386	1.0.4-1		installed (from updates-released)
>  
>
Yes. Got that now. Thanks for clarifying. 

regards
Rahul



From wrrhdev at riede.org  Sun Nov 27 03:40:36 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 27 Nov 2005 03:40:36 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <4389285D.7080600@redhat.com> (from sundaram@redhat.com on Sat
	Nov 26 22:30:37 2005)
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<43892622.4070103@redhat.com> <1133062004l.22893l.1l@serve.riede.org>
	<4389285D.7080600@redhat.com>
Message-ID: <1133062836l.22893l.2l@serve.riede.org>

On 11/26/2005 10:30:37 PM, Rahul Sundaram wrote:
> Hi
> 
>> 
>> [root at athena ~]# yum list gdb
>> Loading "installonlyn" plugin
>> Setting up repositories
>> development               100% |=========================| 1.1 kB    00:00
>> extras-development        100% |=========================| 1.1 kB    00:00
>> Reading repository metadata in from local files
>> Installed Packages
>> gdb.x86_64                               6.3.0.0-1.81           installed
>> 
>> [root at athena ~]# rpm -q fedora-release
>> fedora-release-4-99.rawhide
> 
> Try a non installed package ;-)

That's not what I wrote - my problem is "where did this package come from when  
I installed it many months ago" and "do I want the update that's available  
from some repo (and yes, that one is identified) to replace it"? If the update  
is in a different repo than I used before, the answer may well be "no".

Regards, Willem Riede.




From jspaleta at gmail.com  Sun Nov 27 03:59:57 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sat, 26 Nov 2005 22:59:57 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133060840l.22893l.0l@serve.riede.org>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
Message-ID: <604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>

On 11/26/05, Willem Riede <wrrhdev at riede.org> wrote:
> It would be useful (I have often wished it did) if e.g. yum list x would not
> just tell me some release of x is installed, but also from which repo it came
> when it was installed. But I'm not sure the rpm database contains that
> information, so this may not be possible?

no that information is not part of the installed rpm database. That
information would have to be encoded in a secondard database that
supplimented the rpm database. I imagine there is a very strong
inertia against doing that sort of supplimenting.

In any event, once a package leaves a repository, there is no way to
know eaactly which repo it came from.  You can't really trust the
reponame as defined in the config, I could rename updates-released 
pooptastic-updates in the yum config and that name would have no
meaning to anyone else. Signing keys you can somewhat trust to be
authorative and unique, but signing keys are not unique per repository
tree. You can't know that a package came from updates-testing versus
updates-released based just on the package signatuire.

-jef



From laroche at redhat.com  Sun Nov 27 05:41:45 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 27 Nov 2005 06:41:45 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
Message-ID: <20051127054145.GA14718@dudweiler.stuttgart.redhat.com>

> 1. core isn't really feature complete on its own w/o extras. I can't
> install a system and finish it off w/o using extras.
> 
> 2. extras is enabled by default in the final install of fedora core, so
> people can easily get to all of those packages.

Many people want to have their system mostly complete by Fedora Core
installations and then only add a few packages from Fedora Extras.

regards,

Florian La Roche



From n0dalus+redhat at gmail.com  Sun Nov 27 07:43:00 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sun, 27 Nov 2005 18:13:00 +1030
Subject: Yum and SRPMs
Message-ID: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>

Hi,

I was wondering if is or ever will be possible to install srpms using
yum. In the yum manpage it says you can specify a package using
'package.arch', so I was wondering if that could be done with
'package.src'. I think this would really be a helpful feature. At the
moment to get a srpm I have to go to one of the ftp mirrors, find the
right folder then search for the right package among hundreds of other
files.

n0dalus.



From saddateh at gmail.com  Sun Nov 27 07:55:49 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Sun, 27 Nov 2005 02:55:49 -0500
Subject: Yum and SRPMs
In-Reply-To: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
Message-ID: <fc33c1550511262355h2f3a3022nfa093a0d600cf4ef@mail.gmail.com>

+1

On 11/27/05, n0dalus <n0dalus+redhat at gmail.com> wrote:
>
> Hi,
>
> I was wondering if is or ever will be possible to install srpms using
> yum. In the yum manpage it says you can specify a package using
> 'package.arch', so I was wondering if that could be done with
> 'package.src'. I think this would really be a helpful feature. At the
> moment to get a srpm I have to go to one of the ftp mirrors, find the
> right folder then search for the right package among hundreds of other
> files.
>
> n0dalus.
>
> --
> 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/20051127/9356cf10/attachment.htm>

From nmiell at comcast.net  Sun Nov 27 08:15:26 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Sun, 27 Nov 2005 00:15:26 -0800
Subject: Yum and SRPMs
In-Reply-To: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
Message-ID: <1133079326.2854.1.camel@entropy>

On Sun, 2005-11-27 at 18:13 +1030, n0dalus wrote:
> Hi,
> 
> I was wondering if is or ever will be possible to install srpms using
> yum. In the yum manpage it says you can specify a package using
> 'package.arch', so I was wondering if that could be done with
> 'package.src'. I think this would really be a helpful feature. At the
> moment to get a srpm I have to go to one of the ftp mirrors, find the
> right folder then search for the right package among hundreds of other
> files.
> 
> n0dalus.

yum install yum-utils
yumdownloader --source package

-- 
Nicholas Miell <nmiell at comcast.net>



From admin at ramshacklestudios.com  Sun Nov 27 08:20:55 2005
From: admin at ramshacklestudios.com (Peter Gordon)
Date: Sun, 27 Nov 2005 00:20:55 -0800
Subject: Yum and SRPMs
In-Reply-To: <1133079326.2854.1.camel@entropy>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
Message-ID: <1133079655.26615.14.camel@tuxhugger>

On Sun, 2005-11-27 at 00:15 -0800, Nicholas Miell wrote:
> yum install yum-utils
> yumdownloader --source package

Nice! 8-)
-- 
Peter Gordon (codergeek42)
GnuPG Public Key: 0xDA3634D7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/100b2348/attachment.sig>

From n0dalus+redhat at gmail.com  Sun Nov 27 08:32:46 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Sun, 27 Nov 2005 19:02:46 +1030
Subject: Yum and SRPMs
In-Reply-To: <1133079326.2854.1.camel@entropy>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
Message-ID: <6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>

On 11/27/05, Nicholas Miell <nmiell at comcast.net> wrote:
>
> yum install yum-utils
> yumdownloader --source package
>

That's useful, thanks.
Might this functionality ever be built into yum though?

n0dalus.



From pemboa at gmail.com  Sun Nov 27 08:32:40 2005
From: pemboa at gmail.com (Arthur Pemberton)
Date: Sun, 27 Nov 2005 02:32:40 -0600
Subject: Slightly OT: Updated RPM building howto?
Message-ID: <16de708d0511270032h2efe44feo18e6739a9a364791@mail.gmail.com>

Are there any recent HOWTOs around on RPM building? I would really like to
contribute to Fedora, at least by maintaing packages to software that I use
regularly on my own FC4 install. However the HOWTOs I've found seem busy and
complicated. I consider myself to be fairly Linux competent, and so I
believe that I have the capabilties to help.

Please advise, thank you.

--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/d37c6726/attachment.htm>

From mwiktowy at gmx.net  Sun Nov 27 08:54:21 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 03:54:21 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
Message-ID: <1133081661.21062.21.camel@localhost>

On Sat, 2005-11-26 at 22:59 -0500, Jeff Spaleta wrote:
> In any event, once a package leaves a repository, there is no way to
> know eaactly which repo it came from.  You can't really trust the
> reponame as defined in the config, I could rename updates-released 
> pooptastic-updates in the yum config and that name would have no
> meaning to anyone else. Signing keys you can somewhat trust to be
> authorative and unique, but signing keys are not unique per repository
> tree. You can't know that a package came from updates-testing versus
> updates-released based just on the package signatuire.

Checking key consistency is a worthwhile check and likely a more
important check than source repo anyways. It doesn't matter to me where
a package comes from so long as I have the repo in my repo.d and it is
signed by someone I trusted for that package previously.

Handling it like the key checking that ssh does (with a warning and an
option to continue) might be the way to go.
It would prevent some widespread trojan installation possible by a
popular third-party repo's key getting compromised, malicious repo
owners and possible future repo slap-fights.

It seems that right now, some owner of pooptastic-updates can offer up
the wonderful superfoo package, convince some users to install their
pooptastic.repo containing a URL to the pooptastic.key. At that point,
they could replace any package on your system at update time with little
indication to the user.

Is this correct?

/Mike



From jfrieben at freesurf.fr  Sun Nov 27 09:53:33 2005
From: jfrieben at freesurf.fr (Joachim Frieben)
Date: Sun, 27 Nov 2005 10:53:33 +0100 (CET)
Subject: status of up2date and rhn-applet
In-Reply-To: <1133024229.2812.7.camel@yoda.loki.me>
References: <1133024229.2812.7.camel@yoda.loki.me>
Message-ID: <53876.194.94.224.254.1133085213.squirrel@jose.freesurf.fr>

>
> Inter-repo dependencies do exist.  In particular with Livna and Fedora
> Extras.  Now we can talk about Livna being full of forbidden items all
> we want, but the fact is that it gets used and used a lot.  Other such
> deps happen as well with other popular 3rd party repos.
>

Thanks for your clarification. I was referring to the use of "pup"
and "up2date-gnome" as pure update tools. Updated add-on packages for
FC <rel> should not depend on updates of the core, that's what I meant.
For example "updates" and "updates-testing" repositories will be mutually
independent. They might of course require the availablity of the release
core repository for satisfying dependencies of updated packages which,
of course, should always be present.
As a matter of fact, there is a fundamental problem of not having the
same structure in Fedora Extras as in Fedora Core where packages are
split between "os", "updates" and "updates-testing".
Finally, I do not see any compelling reason for abandoning "up2date-gnome"
or at least its GUI yet. Any basic user can simply confirm the default
settings without worrying about details. The experienced user will
appreciate the additional information and make customizations at will.




From gauret at free.fr  Sun Nov 27 10:33:15 2005
From: gauret at free.fr (Aurelien Bompard)
Date: Sun, 27 Nov 2005 11:33:15 +0100
Subject: Slightly OT: Updated RPM building howto?
References: <16de708d0511270032h2efe44feo18e6739a9a364791@mail.gmail.com>
Message-ID: <dmc21b$44e$1@sea.gmane.org>

Arthur Pemberton wrote:
> Are there any recent HOWTOs around on RPM building? I would really like to
> contribute to Fedora, at least by maintaing packages to software that I
> use regularly on my own FC4 install. However the HOWTOs I've found seem
> busy and complicated. I consider myself to be fairly Linux competent, and
> so I believe that I have the capabilties to help.

You could have a look at http://fedora.redhat.com/docs/drafts/rpm-guide-en/
When you're comfortable with rpm building, look at the Fedora Guidelines:
http://fedoraproject.org/wiki/PackagingGuidelines


Aur?lien
-- 
http://aurelien.bompard.org  ~~~~  Jabber : abompard at jabber.fr
Programmer: A biological system designed to convert coffee and pizza
into code.




From danfr at matrix.co.il  Sun Nov 27 10:47:55 2005
From: danfr at matrix.co.il (Dan Fruehauf)
Date: Sun, 27 Nov 2005 12:47:55 +0200
Subject: ipt_MIRROR
Message-ID: <CD1F942E2840FA4E9F8CC5A780E94495689F86@EX2K3-HZ.Matrix.IT>

Hi,

I was wondering why there's no ipt_MIRROR in the default kernel configuration...
Any specific reason for this?

Thanks,
Dan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/4b080586/attachment.htm>

From db at zigo.dhs.org  Sun Nov 27 10:52:38 2005
From: db at zigo.dhs.org (Dennis Bjorklund)
Date: Sun, 27 Nov 2005 11:52:38 +0100 (CET)
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
Message-ID: <Pine.LNX.4.44.0511271148250.25251-100000@zigo.dhs.org>

On Sat, 26 Nov 2005, seth vidal wrote:

> 1. core isn't really feature complete on its own w/o extras. I can't
> install a system and finish it off w/o using extras.

What is missing from core to make it feature complete?

-- 
/Dennis Bj?rklund



From Axel.Thimm at ATrpms.net  Sun Nov 27 11:38:28 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 27 Nov 2005 12:38:28 +0100
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <1133044397.17474.76.camel@cutter>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
	<20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
	<1133044397.17474.76.camel@cutter>
Message-ID: <20051127113828.GC15947@neu.nirvana>

On Sat, Nov 26, 2005 at 05:33:16PM -0500, seth vidal wrote:
> On Sat, 2005-11-26 at 22:53 +0100, Florian La Roche wrote:
> > > no, I don't want to hear any bitching and moaning about this, that's how
> > > it is.
> > 
> > At some point we should change this to only pull in as few packages as
> > really needed, but that also comes with quite some calculation cost.
> 
> why isn't the way it's currently being done correct? We've gone round
> and round on this and its always come down to how to handle globs of
> commands.

Sometimes less is more. Why should a system be polluted with i386
packages, if the user does not need them?

> > This should really be something where yum, up2date and smart algorithms
> > should work together and then implement the best solution available.
> 
> is up2date much of a concern anymore?

Is something scheduled as replacement for RHEL or XMLRPC? If there is
no XMLRPC support in any other depsolver up2date cannot die.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/c01eb6d8/attachment.sig>

From buildsys at redhat.com  Sun Nov 27 11:49:47 2005
From: buildsys at redhat.com (Build System)
Date: Sun, 27 Nov 2005 06:49:47 -0500
Subject: rawhide report: 20051127 changes
Message-ID: <200511271149.jARBnlCb029451@porkchop.devel.redhat.com>

 

 
Updated Packages:

kernel-2.6.14-1.1715_FC5
------------------------
* Sun Nov 27 2005 Dave Jones <davej at redhat.com>
- Port change_page_attr fixes from x86-64.
  (Fixes rodata-readonly causes instant reboot)

* Sat Nov 26 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git6

* Fri Nov 25 2005 Dave Jones <davej at redhat.com>
- 2.6.15-rc2-git5

mkinitrd-5.0.12-1
-----------------
* Sat Nov 26 2005 Peter Jones <pjones at redhat.com> - 5.0.12-1
- Fix buildreq/req for dmraid on s390
- Typo fix from Alexandre Oliva

slrn-0.9.8.1pl1-1
-----------------
* Sat Nov 26 2005 Jindrich Novy <jnovy at redhat.com> 0.9.8.1pl1-1
- update to the latest slrn-0.9.8.1pl1 with slang2 support

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11









Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5





From mattdm at mattdm.org  Sun Nov 27 13:19:19 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 08:19:19 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
Message-ID: <20051127131919.GA15238@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 06:41:45AM +0100, Florian La Roche wrote:
> Many people want to have their system mostly complete by Fedora Core
> installations and then only add a few packages from Fedora Extras.

Those people are living in the past.

No, seriously.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From wrrhdev at riede.org  Sun Nov 27 13:24:41 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 27 Nov 2005 13:24:41 +0000
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <20051127113828.GC15947@neu.nirvana> (from
	Axel.Thimm@ATrpms.net on Sun Nov 27 06:38:28 2005)
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
	<20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
	<1133044397.17474.76.camel@cutter> <20051127113828.GC15947@neu.nirvana>
Message-ID: <1133097881l.22893l.3l@serve.riede.org>

On 11/27/2005 06:38:28 AM, Axel Thimm wrote:
> On Sat, Nov 26, 2005 at 05:33:16PM -0500, seth vidal wrote:
> > On Sat, 2005-11-26 at 22:53 +0100, Florian La Roche wrote:
> > > > no, I don't want to hear any bitching and moaning about this, that's
> how
> > > > it is.
> > >
> > > At some point we should change this to only pull in as few packages as
> > > really needed, but that also comes with quite some calculation cost.
> >
> > why isn't the way it's currently being done correct? We've gone round
> > and round on this and its always come down to how to handle globs of
> > commands.
> 
> Sometimes less is more. Why should a system be polluted with i386
> packages, if the user does not need them?

Indeed. But that should be considered by the repo creator. If there is no need  
for a i386 variant of package X then X.i386 should not be in the x86_64 repo.

Regards, Willem Riede.



From mike at plan99.net  Sun Nov 27 13:35:17 2005
From: mike at plan99.net (Mike Hearn)
Date: Sun, 27 Nov 2005 13:35:17 +0000
Subject: What about smartpm?
References: <1133024107.4090.14.camel@localhost>
	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
Message-ID: <pan.2005.11.27.13.35.17.81519@plan99.net>

On Sat, 26 Nov 2005 12:13:41 -0500, Jeff Spaleta wrote:
> smartpm was never under consideration.  The fact that noone in the
> community of contributors has yet packaged it as part of Extras should
> tell you something important.

... like that it's already in a 3rd party repository, so for the "I just
want to install it" crowd there's no motivation to package it for extras?



From Axel.Thimm at ATrpms.net  Sun Nov 27 13:44:33 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Sun, 27 Nov 2005 14:44:33 +0100
Subject: i386 packages sneaking in on x86_64 platform (was: lm_sensors in
	FC4-updates for x86_64 twice?)
In-Reply-To: <1133097881l.22893l.3l@serve.riede.org>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
	<20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
	<1133044397.17474.76.camel@cutter>
	<20051127113828.GC15947@neu.nirvana>
	<1133097881l.22893l.3l@serve.riede.org>
Message-ID: <20051127134433.GF28570@neu.nirvana>

On Sun, Nov 27, 2005 at 01:24:41PM +0000, Willem Riede wrote:
> On 11/27/2005 06:38:28 AM, Axel Thimm wrote:
> >On Sat, Nov 26, 2005 at 05:33:16PM -0500, seth vidal wrote:
> >> On Sat, 2005-11-26 at 22:53 +0100, Florian La Roche wrote:
> >> > > no, I don't want to hear any bitching and moaning about this,
> >> > > that's how it is.
> >> >
> >> > At some point we should change this to only pull in as few
> >> > packages as really needed, but that also comes with quite some
> >> > calculation cost.
> >>
> >> why isn't the way it's currently being done correct? We've gone
> >> round and round on this and its always come down to how to handle
> >> globs of commands.
> >
> >Sometimes less is more. Why should a system be polluted with i386
> >packages, if the user does not need them?
> 
> Indeed. But that should be considered by the repo creator.

IMHO not. The repo creator should be offering choice, thus maximizing
the offered package ensemble, and not enforce a policy. The policy
should be at the user's control, e.g. to prune multilib away from an
x86_64 system and not seeing the i386 packages sneak in by way of the
depsolver.

> If there is no need for a i386 variant of package X then X.i386
> should not be in the x86_64 repo.

If there is a use for some users (even for a non-negligible minority
of users) for a i386 campatibility package then the repo maintainer
needs to add it. But that doesn't mean that every user has to get it
pasted into his system.

Good solutions in dependecy calculations are such that offer the
smallest possible solution. Otherwise "install all" is also a valid
solution for any soluble depsolver problem :)

In fact the end user should not notice what arch he is using. If some
application is i386 only and requires some i386 packages, then the
depsolver should get the compatibility packages, otherwise not.

It's different for a developer, who knows that he wants foo.i386, even
if there is a foo.x86_64. Since developers (should) know how to deal
with selecting packages upon arch, while end users should not need to,
the default should be to not install tuples of packages for all
supported arches, but to find the minimal solution.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051127/6080ff41/attachment.sig>

From tromey at redhat.com  Sun Nov 27 14:37:08 2005
From: tromey at redhat.com (Tom Tromey)
Date: Sun, 27 Nov 2005 07:37:08 -0700
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
Message-ID: <17289.50324.181961.701343@localhost.localdomain>

>>>>> "Florian" == Florian La Roche <laroche at redhat.com> writes:

>> 1. core isn't really feature complete on its own w/o extras. I can't
>> install a system and finish it off w/o using extras.
>> 
>> 2. extras is enabled by default in the final install of fedora core, so
>> people can easily get to all of those packages.

Florian> Many people want to have their system mostly complete by Fedora Core
Florian> installations and then only add a few packages from Fedora Extras.

I don't doubt this.  However implicit in this is some idea of what the
target Fedora Core user looks like -- some kind of user profile.  I
think the goal of this thread is to make this idea explicit.

Are we targeting developers?  Corporate desktop users?  People who
travel a lot?  People setting up LAMP servers?  Some combination?

Tom



From skvidal at phy.duke.edu  Sun Nov 27 15:02:46 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 10:02:46 -0500
Subject: Yum and SRPMs
In-Reply-To: <6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
Message-ID: <1133103767.21208.0.camel@cutter>

On Sun, 2005-11-27 at 19:02 +1030, n0dalus wrote:
> On 11/27/05, Nicholas Miell <nmiell at comcast.net> wrote:
> >
> > yum install yum-utils
> > yumdownloader --source package
> >
> 
> That's useful, thanks.
> Might this functionality ever be built into yum though?
> 

no

-sv




From skvidal at phy.duke.edu  Sun Nov 27 15:05:07 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 10:05:07 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133081661.21062.21.camel@localhost>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost>
Message-ID: <1133103907.21208.3.camel@cutter>


> Handling it like the key checking that ssh does (with a warning and an
> option to continue) might be the way to go.

yum does that now. It asks you if you want to import the key and you
have to press y or n.

> It would prevent some widespread trojan installation possible by a
> popular third-party repo's key getting compromised, malicious repo
> owners and possible future repo slap-fights.

the only thing that will prevent that is if users wisen up about what
they're doing. It's the same thing as what protects them from sending
their CC to a nefarious site or one unprotected by encryption. They have
to be aware of what's going on around them.

> 
> It seems that right now, some owner of pooptastic-updates can offer up
> the wonderful superfoo package, convince some users to install their
> pooptastic.repo containing a URL to the pooptastic.key. At that point,
> they could replace any package on your system at update time with little
> indication to the user.

If they already agreed to import the key, yes.

-sv



From mattdm at mattdm.org  Sun Nov 27 15:10:15 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 10:10:15 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <17289.50324.181961.701343@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
Message-ID: <20051127151015.GA18926@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 07:37:08AM -0700, Tom Tromey wrote:
> I don't doubt this.  However implicit in this is some idea of what the
> target Fedora Core user looks like -- some kind of user profile.  I
> think the goal of this thread is to make this idea explicit.
> Are we targeting developers?  Corporate desktop users?  People who
> travel a lot?  People setting up LAMP servers?  Some combination?

I'm for going all the way -- it should contain no end-user applications,
just the framework for making those applications run. C'mon, let's make Core
be just that.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From ihok at hotmail.com  Sun Nov 27 15:25:11 2005
From: ihok at hotmail.com (Jack Tanner)
Date: Sun, 27 Nov 2005 10:25:11 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511261439y2cbcf62es7a166b4612539218@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>	<1132983547.2860.32.camel@bree.local.net>	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>	<4388E2D4.5050301@hotmail.com>
	<604aa7910511261439y2cbcf62es7a166b4612539218@mail.gmail.com>
Message-ID: <dmcj4o$bvt$1@sea.gmane.org>

Jeff Spaleta wrote:
> That's not so easy to determine...  if you have package foo-1 from extras
> and then extras pushes foo-2  and cleans out foo-1 from its directory
> at some point. And then crappyrpms.org pushes foo-3... how does yum
> know the foo-1 package you have installed is from extras?

It shouldn't matter that foo-1 got cleaned out from the repo, so long as 
  on the user's system foo-1 got upgraded to foo-2.

That is, extras pushes foo-2, it's from the same repo as foo-1, so it's 
a "safe" upgrade. Then pooptastic pushes foo-3, and that triggers a 
conflict (perhaps a conflict of gpg signatures).

> You could implement a check against a change in signature... but the
> worth of that is somewhat limited as well. for example I don't think
> packages in updates-testing are signed with a different key than
> updates-released so you just checking a change in signature doesn't
> catch i change in repo.

Well, it'd be a bit of a hack, but so what. Why not use different keys 
to sign different repos? It's a small (one-time) price, but it buys 
really useful functionality. Would it break anything?

But even if you check against a change in signature /without/ having 
different keys for released vs testing, you've still eliminated the 
pooptastic repo badness. That's a win.



From arjan at fenrus.demon.nl  Sun Nov 27 15:35:52 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 27 Nov 2005 16:35:52 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127151015.GA18926@jadzia.bu.edu>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
Message-ID: <1133105752.2853.14.camel@laptopd505.fenrus.org>

On Sun, 2005-11-27 at 10:10 -0500, Matthew Miller wrote:
> On Sun, Nov 27, 2005 at 07:37:08AM -0700, Tom Tromey wrote:
> > I don't doubt this.  However implicit in this is some idea of what the
> > target Fedora Core user looks like -- some kind of user profile.  I
> > think the goal of this thread is to make this idea explicit.
> > Are we targeting developers?  Corporate desktop users?  People who
> > travel a lot?  People setting up LAMP servers?  Some combination?
> 
> I'm for going all the way -- it should contain no end-user applications,
> just the framework for making those applications run. C'mon, let's make Core
> be just that.

actually I tend to disagree, not sure how much say I should have in this
though.

I think of it as an union model, where each layer is both self-contained
in terms of package dependencies but also in the requirements it
fulfills in terms of user/market.

eg

layer 0 of the union
"base" - minimum set to get the machine booting and operating

layer 1 of the union
"core" - set of functionality people expect from a consumer oriented
linux distro

layer 2 of the union
"extras" - more "obscure" functionality for example because it's a
relatively small userbase but also because it can be new and emerging
things. In addition this can be alternative implementations to core
functionality. An example of this could be wu-ftpd or xfce or ..

layer 3 of the union
"dedicated repos" - very specialist repositories that each target what
is pretty much a niche market and who's requirements are very different
or unique but isolated. Examples could be a beowulf repo, or a "video
montage" repo. 

again, for me it's essential that each layer of the union is
self-contained in terms of packages (eg no dependencies to higher
layers, lower layers is of course ok) and of functionality (eg if a
layer contains a certain functionality, it should contain in a general
useful matter. this doesn't mean that all optional things should be
there, but enough functionality that most people expect should be
there).

For me the difference between layer 2 and 3 is also a "market segment"
one. Some things will be so specialist that it's better to have a few
experts have their own repo that they maintain as a coherent add-on
function than lumping it all in one big repo. 



From skvidal at phy.duke.edu  Sun Nov 27 15:53:11 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 10:53:11 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133105752.2853.14.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
Message-ID: <1133106791.21208.20.camel@cutter>

> I think of it as an union model, where each layer is both self-contained
> in terms of package dependencies but also in the requirements it
> fulfills in terms of user/market.
> 
> eg
> 
> layer 0 of the union
> "base" - minimum set to get the machine booting and operating
> 
> layer 1 of the union
> "core" - set of functionality people expect from a consumer oriented
> linux distro


This is what needs to be defined "what people expect" I'm sure you have
an idea of what you think should be in there but it's not.


> 
> layer 2 of the union
> "extras" - more "obscure" functionality for example because it's a
> relatively small userbase but also because it can be new and emerging
> things. In addition this can be alternative implementations to core
> functionality. An example of this could be wu-ftpd or xfce or ..

So far in extras we have examples of packages with "small" userbases as:
zope and plone
xmms
abiword
bittorrent
cyrus-imapd
inkscape
koffice

and in core we have such mass-market winners as:
GFS
ElectricFence
aqbanking
ccs
iptraf
inn
jonas
magma 
lam
mtr-gtk
xbase
slrn


Now you tell me does that list make sense to you? It doesn't to me.
I figure that people making a beowulf cluster can learn how to yum
install ccs lam magma and friends on their own drawing from extras
instead of having to have them in core.



> layer 3 of the union
> "dedicated repos" - very specialist repositories that each target what
> is pretty much a niche market and who's requirements are very different
> or unique but isolated. Examples could be a beowulf repo, or a "video
> montage" repo. 

but most of the beowulf tools are already IN core.


This is what I'm talking about - right now the distinction b/t what gets
into core and what goes into extras is more or less 'where does the
packager work'

-sv




From dimi at lattica.com  Sun Nov 27 16:00:52 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 27 Nov 2005 11:00:52 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <17289.50324.181961.701343@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
Message-ID: <1133107252.9749.394.camel@dimi.lattica.com>

On Sun, 2005-11-27 at 07:37 -0700, Tom Tromey wrote:
> Are we targeting developers?  Corporate desktop users?  People who
> travel a lot?  People setting up LAMP servers?  Some combination?

AFAICT, there's no particular group of users we target:
  -- FC is mostly for home use
  -- we want to make it useful for laptops
  -- it is the base of RHEL

So it's clearly a combination. For Core to be relevant to people,
it has to be useful out of the box. This rules out the absolute 
minimal Core IMO.

In terms of what goes in, I would think that is should be packages
that are useful to the majority of users in any one segment. This
view would support having in Core apps as diverse as GIMP, Apache,
JOnAS.

One important aspect that seems to be overlooked when we talk about
applications included by default in Core is the message that it sends.
Namely, "a lot of experienced people have looked at alternatives, and
we think that this particular one is the one that's most appropriate
for most people". In other words, we're giving certain applications
more weight then others. 

By moving everything to extras, we lose this message, and that would be
a step back for many people that don't have the time and experience to
decide at every turn between the various options available out there.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From fedora at camperquake.de  Sun Nov 27 16:05:23 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Sun, 27 Nov 2005 17:05:23 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133106791.21208.20.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
Message-ID: <20051127160523.GA2454@ryoko.camperquake.de>

On Sun, Nov 27, 2005 at 10:53:11AM -0500, seth vidal wrote:

> So far in extras we have examples of packages with "small" userbases as:
> xmms

I think this one got kicked because it uses GTK1.

> and in core we have such mass-market winners as:
> slrn

This is (IMVHO) the best text based news reader there is. No flames, please.

For the rest: ACK.



From skvidal at phy.duke.edu  Sun Nov 27 16:12:15 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 11:12:15 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127160523.GA2454@ryoko.camperquake.de>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<20051127160523.GA2454@ryoko.camperquake.de>
Message-ID: <1133107936.21208.27.camel@cutter>


> > and in core we have such mass-market winners as:
> > slrn
> 
> This is (IMVHO) the best text based news reader there is. No flames, please.

no flames - but do we need slrn in core? It's pretty trivial to install
it from extras.

-sv




From arjan at fenrus.demon.nl  Sun Nov 27 16:10:47 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 27 Nov 2005 17:10:47 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133106791.21208.20.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
Message-ID: <1133107847.2853.26.camel@laptopd505.fenrus.org>

> nality people expect from a consumer oriented
> > linux distro
> 
> 
> This is what needs to be defined "what people expect" I'm sure you have
> an idea of what you think should be in there but it's not.

it's also dynamic over time.

LAMP is probably undisputed
a "complete" graphical desktop is more fuzzy (after all, what is
"complete".. and which one)

Note that I very much am talking about functionalities (although LAMP
suggests implementation); the actual packages chosen can vary over time,
and for the most part I think providing 1 is enough. (there are
exceptions, eg gnome/kde politics or cases where the packages are very
different, like vi versus gnome-edit)

>  
> > layer 2 of the union
> > "extras" - more "obscure" functionality for example because it's a
> > relatively small userbase but also because it can be new and emerging
> > things. In addition this can be alternative implementations to core
> > functionality. An example of this could be wu-ftpd or xfce or ..

fwiw I'm not arguing the current split is the right one. It's full of
legacy choices for example. Ideally there'll be a discussion at some
point about which functionalities could/should be in the "core" union
layer. And which are more suitable for higher layers.

> 
> So far in extras we have examples of packages with "small" userbases as:
> xmms
well arguable the gnome desktop has a media player already. In that
sense "xmms" is a "alternative implementation" of "media player". 
> abiword
again, alternative implementation of "office suite"

> bittorrent

given that BT is the main distribution mechanism I think this one
could/should be in core.

> cyrus-imapd
alternative implementation of dovecot

etc


> 
> Now you tell me does that list make sense to you? It doesn't to me.
> I figure that people making a beowulf cluster can learn how to yum
> install ccs lam magma and friends on their own drawing from extras
> instead of having to have them in core.

I'd go further and say that "beowulf" should be a repo on top of extras
given how specialized it is.

> but most of the beowulf tools are already IN core.

and I'm arguing that might be wrong ;)



> This is what I'm talking about - right now the distinction b/t what gets
> into core and what goes into extras is more or less 'where does the
> packager work'

then I don't agree with how that works and would favor and advocate a
more "functionality" way of looking at it.




From skvidal at phy.duke.edu  Sun Nov 27 16:14:33 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 11:14:33 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133107252.9749.394.camel@dimi.lattica.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<1133107252.9749.394.camel@dimi.lattica.com>
Message-ID: <1133108074.21208.32.camel@cutter>

On Sun, 2005-11-27 at 11:00 -0500, Dimi Paun wrote:
> On Sun, 2005-11-27 at 07:37 -0700, Tom Tromey wrote:
> > Are we targeting developers?  Corporate desktop users?  People who
> > travel a lot?  People setting up LAMP servers?  Some combination?
> 
> AFAICT, there's no particular group of users we target:
>   -- FC is mostly for home use
>   -- we want to make it useful for laptops
>   -- it is the base of RHEL
> 
> So it's clearly a combination. For Core to be relevant to people,
> it has to be useful out of the box. This rules out the absolute 
> minimal Core IMO.
> 
> In terms of what goes in, I would think that is should be packages
> that are useful to the majority of users in any one segment. This
> view would support having in Core apps as diverse as GIMP, Apache,
> JOnAS.
> 
> One important aspect that seems to be overlooked when we talk about
> applications included by default in Core is the message that it sends.
> Namely, "a lot of experienced people have looked at alternatives, and
> we think that this particular one is the one that's most appropriate
> for most people". In other words, we're giving certain applications
> more weight then others. 
> 
> By moving everything to extras, we lose this message, and that would be
> a step back for many people that don't have the time and experience to
> decide at every turn between the various options available out there.

and once you can install extras from w/i anaconda during the initial
install? How is that any different?

So we need to break things up intelligently based on groups, I think.

So that new users can select larger groups like 'graphic tools' or 'web
server'

-sv




From nutello at sweetness.com  Sun Nov 27 16:44:59 2005
From: nutello at sweetness.com (Rudi Chiarito)
Date: Sun, 27 Nov 2005 17:44:59 +0100
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126143949.GA2261@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
Message-ID: <20051127164458.GH22555@plain.rackshack.net>

On Sat, Nov 26, 2005 at 09:39:49AM -0500, Matthew Miller wrote:
> How about making Anaconda always only do a minimal install, and make
> firstboot have the option to install other things if you want 'em? :)

That's what I do with kickstart. I install the bare minimum plus
cfengine (and host keys of all sorts... an interesting exercise that
maybe anaconda could tackle once for all). When the system reboots,
cfengine does its regular job of asking yum to install the packages
defined for that machine's profile(s), tweaking configuration files,
copying files from the master, (re)starting services, monitoring mounts
and processes, etc.

Now, why cfengine appeared in Core (Rawhide) only for a brief period...
when, as Seth pointed out, the much larger JOnAS was brought in without
batting an eye. I'd argue that having cfengine in Core is a good idea.
It can perform useful work at install time - without resorting to large
kickstart scripts, which, by definition, are an one-off affair (you need
to rely on something else to make changes after the installation).
Having a bit of integration between cfengine and yum/anaconda would be
even better - unless there are even more suitable alternatives.

-- 
Rudi



From jkeating at j2solutions.net  Sun Nov 27 16:53:42 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 27 Nov 2005 08:53:42 -0800
Subject: status of up2date and rhn-applet
In-Reply-To: <53876.194.94.224.254.1133085213.squirrel@jose.freesurf.fr>
References: <1133024229.2812.7.camel@yoda.loki.me>
	<53876.194.94.224.254.1133085213.squirrel@jose.freesurf.fr>
Message-ID: <1133110422.18465.13.camel@yoda.loki.me>

On Sun, 2005-11-27 at 10:53 +0100, Joachim Frieben wrote:
> Thanks for your clarification. I was referring to the use of "pup"
> and "up2date-gnome" as pure update tools. Updated add-on packages for
> FC <rel> should not depend on updates of the core, that's what I meant.

But it happens.  Extras is an integral part of Fedora.  Extras packages
will be available during the install.  Extras packages do sometimes
depend on Core packages, so the updates have to be coordinated.  If you
turn off extras, and try to do an update, you can get to a state were
the update cannot complete.  The end user shouldn't care about this,
they shouldn't care where the package comes from, they just want to
Update the system.  This is what I think Pup is being designed for.

> For example "updates" and "updates-testing" repositories will be mutually
> independent. They might of course require the availablity of the release
> core repository for satisfying dependencies of updated packages which,
> of course, should always be present.

But updates-testing is what I would call an 'add-on' repository.
Something you said above shouldn't depend on core....

> As a matter of fact, there is a fundamental problem of not having the
> same structure in Fedora Extras as in Fedora Core where packages are
> split between "os", "updates" and "updates-testing".

How so?  What "os" is in Extras?  Extras is rolling, rolls with the FC
punches.  There is no static 'on cd' version of Extras to call
'os' (yet).  It makes no sense to try and group a set of Extras packages
into something called 'os'.  Thats why there is just Extras.

> Finally, I do not see any compelling reason for abandoning "up2date-gnome"
> or at least its GUI yet. Any basic user can simply confirm the default
> settings without worrying about details. The experienced user will
> appreciate the additional information and make customizations at will.

Unfortunately you haven't looked at the code.  This is the main
(technical) reason I've heard for abandoning it.  The code is not
manageable going forward.  It also is not designed the way that Fedora
developers envision the end-user tool set, but this is less of a
technical reason, more of a UI reason.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From jkeating at j2solutions.net  Sun Nov 27 16:55:42 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 27 Nov 2005 08:55:42 -0800
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051127164458.GH22555@plain.rackshack.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<20051127164458.GH22555@plain.rackshack.net>
Message-ID: <1133110542.18465.15.camel@yoda.loki.me>

On Sun, 2005-11-27 at 17:44 +0100, Rudi Chiarito wrote:
> 
> Now, why cfengine appeared in Core (Rawhide) only for a brief period...
> when, as Seth pointed out, the much larger JOnAS was brought in without
> batting an eye. I'd argue that having cfengine in Core is a good idea.
> It can perform useful work at install time - without resorting to large
> kickstart scripts, which, by definition, are an one-off affair (you need
> to rely on something else to make changes after the installation).
> Having a bit of integration between cfengine and yum/anaconda would be
> even better - unless there are even more suitable alternatives.

When Anaconda can look at more repos than just Extras (think FC6)
wouldn't it make more sense to have your own yum repo with group
definitions for each system profile?  Then you can tell anaconda's yum
to group-install <foo>.  After the install, yum update will do the
updating work.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dimi at lattica.com  Sun Nov 27 17:13:46 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 27 Nov 2005 12:13:46 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133106791.21208.20.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
Message-ID: <1133111626.9749.402.camel@dimi.lattica.com>

On Sun, 2005-11-27 at 10:53 -0500, seth vidal wrote:
> This is what I'm talking about - right now the distinction b/t what
> gets into core and what goes into extras is more or less 'where does
> the packager work'

I don't think this is necessarily a problem -- I'd expect that
packages that are in Core be maintained by Red Hat folks.

I do agree with you that Core has some legacy stuff in there that
may have to go. This is to be expected, FC is a working, evolving
project. But this is no reason to argue for moving all useful
functionality into Extras. :)

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From d.jacobfeuerborn at conversis.de  Sun Nov 27 16:56:04 2005
From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn)
Date: Sun, 27 Nov 2005 17:56:04 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133107847.2853.26.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>	<1133020129.7280.3.camel@shuttle.273piedmont.com>	<1133020624.17474.30.camel@cutter>	<1133021081.2860.97.camel@bree.local.net>	<1133021599.17474.43.camel@cutter>	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>	<17289.50324.181961.701343@localhost.localdomain>	<20051127151015.GA18926@jadzia.bu.edu>	<1133105752.2853.14.camel@laptopd505.fenrus.org>	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
Message-ID: <4389E524.4050904@conversis.de>

Arjan van de Ven wrote:
...
...
>> This is what I'm talking about - right now the distinction b/t what gets
>> into core and what goes into extras is more or less 'where does the
>> packager work'
> 
> then I don't agree with how that works and would favor and advocate a
> more "functionality" way of looking at it.

How is looking at the problem in different ways going to solve the (in my 
eyes unsolvable) problem of choosing one specific implementation of a 
"media player" or "office suite" for Core? In order to do that you would 
need an entirely objective argument why dovecot is more entitled to be in 
Core rather than cyrus-imapd and I never see that happen in all the "what 
should be in Core" dicussions that transpired so far.

Right now I see it like this: Core contains whatever those in control deem 
it should contain and the reasons for including a package are mostly 
arbitrary (e.g. "The people *I* know tend to like dovecot/cyrus-imapd 
better"). Fine with me.

The only way to really solve these kinds of disputes is I think by allowing 
people to easily spin their own "Fedora based" distributions.

Regards,
   Dennis



From jspaleta at gmail.com  Sun Nov 27 17:22:12 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 27 Nov 2005 12:22:12 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127151015.GA18926@jadzia.bu.edu>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
Message-ID: <604aa7910511270922p5588fe7y518343a265ed08bd@mail.gmail.com>

On 11/27/05, Matthew Miller <mattdm at mattdm.org> wrote:
> I'm for going all the way -- it should contain no end-user applications,
> just the framework for making those applications run. C'mon, let's make Core
> be just that.

This is a non-starter until Extras has official isos(or a centralized
mechanism to make isos) so vendors and lugs can distribute a set of
media that represents a functional install of some type. A core that
serves no functional description of a user profile is useuless to
anyone who doesn't have reasonable and reliable broadband.

-jef"pass the crackpipe to someone else"spaleta



From dimi at lattica.com  Sun Nov 27 17:26:31 2005
From: dimi at lattica.com (Dimi Paun)
Date: Sun, 27 Nov 2005 12:26:31 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <4389E524.4050904@conversis.de>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
Message-ID: <1133112391.9749.408.camel@dimi.lattica.com>

On Sun, 2005-11-27 at 17:56 +0100, Dennis Jacobfeuerborn wrote:
> Right now I see it like this: Core contains whatever those in control
> deem it should contain and the reasons for including a package are
> mostly arbitrary (e.g. "The people *I* know tend to like
> dovecot/cyrus-imapd better"). Fine with me.

Well, the reasons are not that arbitrary. Thing is, most people
benefit from these choices. They don't have time to investigate
every possible option out there, and this is a way to follow the
advice of people they trust and respect (i.e. the people behind
Fedora). If you think you know better, fetching stuff from extra 
is no big deal.

-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.



From wrrhdev at riede.org  Sun Nov 27 17:38:28 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Sun, 27 Nov 2005 17:38:28 +0000
Subject: i386 packages sneaking in on x86_64 platform (was: lm_sensors
 in FC4-updates for x86_64 twice?)
In-Reply-To: <20051127134433.GF28570@neu.nirvana> (from
	Axel.Thimm@ATrpms.net on Sun Nov 27 08:44:33 2005)
Message-ID: <1133113108l.22893l.4l@serve.riede.org>

On 11/27/2005 08:44:33 AM, Axel Thimm wrote:
> On Sun, Nov 27, 2005 at 01:24:41PM +0000, Willem Riede wrote:
> 
> > If there is no need for a i386 variant of package X then X.i386
> > should not be in the x86_64 repo.
> 
> If there is a use for some users (even for a non-negligible minority
> of users) for a i386 campatibility package then the repo maintainer
> needs to add it. But that doesn't mean that every user has to get it
> pasted into his system.
> 
> Good solutions in dependecy calculations are such that offer the
> smallest possible solution. Otherwise "install all" is also a valid
> solution for any soluble depsolver problem :)
> 
> In fact the end user should not notice what arch he is using. If some
> application is i386 only and requires some i386 packages, then the
> depsolver should get the compatibility packages, otherwise not.

That I totally agree with. But I don't see how with the current implementation  
an i386 package gets on a x86_64 system unless either the user asked for it or  
it was selected due to a dependency.

If you run "yum install libwhatever" you get both architectures if they exist,  
but yum asks you if you mean what you say. If you answer yes, then you get  
both (as the original poster observed), presumably because you need them (how  
should yum know you don't?).

But users shouldn't typically install libraries in isolation, the typical way  
they get on the system is that an application that the user installs pulls  
them in, and then only the matching variant should be installed.

Regards, Willem Riede.



From emmanuel.seyman at club-internet.fr  Sun Nov 27 17:55:23 2005
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Sun, 27 Nov 2005 18:55:23 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <4389E524.4050904@conversis.de>
References: <1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
Message-ID: <20051127175523.GA29093@orient.maison.moi>

On Sun, Nov 27, 2005 at 05:56:04PM +0100, Dennis Jacobfeuerborn wrote:
>
> "media player" or "office suite" for Core? In order to do that you would 
> need an entirely objective argument why dovecot is more entitled to be in 
> Core rather than cyrus-imapd and I never see that happen in all the "what 
> should be in Core" dicussions that transpired so far.

This was covered when the change took place (and was mostly due to security
reasons, IIRC). An appropriate search of the appropriate mailing list's
archives should give more specifics.

> Right now I see it like this: Core contains whatever those in control deem 
> it should contain and the reasons for including a package are mostly 
> arbitrary (e.g. "The people *I* know tend to like dovecot/cyrus-imapd 
> better"). Fine with me.

I hate to say it but this is my opinion as well.

Emmanuel



From laroche at redhat.com  Sun Nov 27 17:56:56 2005
From: laroche at redhat.com (Florian La Roche)
Date: Sun, 27 Nov 2005 18:56:56 +0100
Subject: i386 packages sneaking in on x86_64 platform (was: lm_sensors
	in FC4-updates for x86_64 twice?)
In-Reply-To: <1133113108l.22893l.4l@serve.riede.org>
References: <20051127134433.GF28570@neu.nirvana>
	<1133113108l.22893l.4l@serve.riede.org>
Message-ID: <20051127175656.GA16682@dudweiler.stuttgart.redhat.com>

> But users shouldn't typically install libraries in isolation, the typical 
> way  they get on the system is that an application that the user installs 
> pulls  them in, and then only the matching variant should be installed.

Many dependencies don't specify the arch, so could work with one of them.
There are also a few other things like virtual provides for "webclient"
or "mta", but those are way fewer than multilib packages which can really
make a big difference on x86_64.

regards,

Florian La Roche



From mattdm at mattdm.org  Sun Nov 27 18:09:56 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 13:09:56 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <604aa7910511270922p5588fe7y518343a265ed08bd@mail.gmail.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<604aa7910511270922p5588fe7y518343a265ed08bd@mail.gmail.com>
Message-ID: <20051127180956.GA24936@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 12:22:12PM -0500, Jeff Spaleta wrote:
> > I'm for going all the way -- it should contain no end-user applications,
> > just the framework for making those applications run. C'mon, let's make Core
> > be just that.
> This is a non-starter until Extras has official isos(or a centralized
> mechanism to make isos) so vendors and lugs can distribute a set of
> media that represents a functional install of some type. A core that
> serves no functional description of a user profile is useuless to
> anyone who doesn't have reasonable and reliable broadband.

Ah yes, the "Extras isn't a second class citizen! Except when it is!"
argument. :)

I agree, this isn't feasible until Extras can be installed from Anaconda,
and spinning isos of Extras to go with that seems useful too.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From arjan at fenrus.demon.nl  Sun Nov 27 18:17:52 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 27 Nov 2005 19:17:52 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <4389E524.4050904@conversis.de>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
Message-ID: <1133115473.2853.36.camel@laptopd505.fenrus.org>

On Sun, 2005-11-27 at 17:56 +0100, Dennis Jacobfeuerborn wrote:
> Arjan van de Ven wrote:
> ...
> ...
> >> This is what I'm talking about - right now the distinction b/t what gets
> >> into core and what goes into extras is more or less 'where does the
> >> packager work'
> > 
> > then I don't agree with how that works and would favor and advocate a
> > more "functionality" way of looking at it.
> 
> How is looking at the problem in different ways going to solve the (in my 
> eyes unsolvable) problem of choosing one specific implementation of a 
> "media player" or "office suite" for Core? In order to do that you would 
> need an entirely objective argument why dovecot is more entitled to be in 
> Core rather than cyrus-imapd and I never see that happen in all the "what 
> should be in Core" dicussions that transpired so far.


not chosing however is worse than picking either. Having worked for RH,
I can say that this is hardly done arbitrary, but based on things like
feature set, code quality, security evaluation, customer requests etc.

You can argue hours and hours about "but X has feature Y" or "but we
need X because Y has bug Z" (the later imo is a bad reasoning, fix Z
instead). But at the end of the day, a choice needs to be made for Core.
Sometimes Extras should end up with the "loosing" half. Sometimes not
imo; several of the things dropped in the last years were for security
reasons, putting it into Extra then is not better. 

I'll go a step further. Choices like this need to be made by architects
to ensure consistency etc. Not a community forum where the one with the
loudest voice wins. Don't get me wrong, there is absolutely a role for
the community in this, both in setting the objectives for this
"architect" to base the decisions on (like what the criteria should be,
and what functionality is suitable for core, and even suggestions about
packages) but making the final call between package A and package B is
not something the community is good at, just look at the debian package
list. There will never be agreement, there are too many stakeholders who
care only about package X without considering the big picture, the ones
with the loudest mouths win or force something etc, all leading to not
the best decision. 

So "someone in Red Hat makes a decision" is not the problem. Unclear
criteria, lack of "what is suitable functionality for core" policy etc
is a problem (you can argue how big a problem it is of course).




From jspaleta at gmail.com  Sun Nov 27 18:28:29 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 27 Nov 2005 13:28:29 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051127180956.GA24936@jadzia.bu.edu>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<604aa7910511270922p5588fe7y518343a265ed08bd@mail.gmail.com>
	<20051127180956.GA24936@jadzia.bu.edu>
Message-ID: <604aa7910511271028q3a0308el98ec8c8f25ffeb09@mail.gmail.com>

On 11/27/05, Matthew Miller <mattdm at mattdm.org> wrote:
> Ah yes, the "Extras isn't a second class citizen! Except when it is!"
> argument. :)

I'm not going to let you get away with that.
My argument against your obsessive desire to make Core so small its
inherently useless to any particular group of end-users has nothing to
do with a class war.  It as to do with making sure the media that can
be hand distributed meets a basic level of functionality that can be
marketed or recommended to SOMEONE  What you propose is a collection
of software that serves no distinct role, has no distinct purpose to
any conceivable USER pool.  Its an absolutely brain dead concept which
would kill whatever momentum this community has at reaching more
users.  The media sets that LUGs and vendors can give out to people
MUST implement functionality that some target grouop of people are
thought to desire. Handing a CD of Core that has no end-user facing
functionality does jack for anyone but a TINY group of power users you
are grossly myopic about the power of customization to the detriment
of all else.

-jef



From jspaleta at gmail.com  Sun Nov 27 18:31:06 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 27 Nov 2005 13:31:06 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133115473.2853.36.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
	<1133115473.2853.36.camel@laptopd505.fenrus.org>
Message-ID: <604aa7910511271031k2a7342fal13788bcc8ba9cd32@mail.gmail.com>

On 11/27/05, Arjan van de Ven <arjan at fenrus.demon.nl> wrote:
> not chosing however is worse than picking either. Having worked for RH,
> I can say that this is hardly done arbitrary, but based on things like
> feature set, code quality, security evaluation, customer requests etc.

Too bad people outside the rh fenceline see very little of that
process as it relates to choices made for Fedora, and instead only see
the choices made without the decision -making context.

-jef



From mattdm at mattdm.org  Sun Nov 27 20:07:41 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 15:07:41 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <604aa7910511271028q3a0308el98ec8c8f25ffeb09@mail.gmail.com>
References: <1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<604aa7910511270922p5588fe7y518343a265ed08bd@mail.gmail.com>
	<20051127180956.GA24936@jadzia.bu.edu>
	<604aa7910511271028q3a0308el98ec8c8f25ffeb09@mail.gmail.com>
Message-ID: <20051127200741.GA30622@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 01:28:29PM -0500, Jeff Spaleta wrote:
> > Ah yes, the "Extras isn't a second class citizen! Except when it is!"
> > argument. :)
> I'm not going to let you get away with that.

:)

[...]
> marketed or recommended to SOMEONE  What you propose is a collection
> of software that serves no distinct role, has no distinct purpose to
> any conceivable USER pool.  Its an absolutely brain dead concept which
> would kill whatever momentum this community has at reaching more
> users.  The media sets that LUGs and vendors can give out to people
> MUST implement functionality that some target grouop of people are
> thought to desire. Handing a CD of Core that has no end-user facing

Right now, they have to hand out three or four CDs of Core. How is that
better than handing out one CD of Core plus n CDs containing
of Extras groups the distributing group feels is relevant to their audience?


> functionality does jack for anyone but a TINY group of power users you
> are grossly myopic about the power of customization to the detriment
> of all else.

I'm not horribly opposed to having a good web browser (e.g. Firefox) in
Core -- that covers most computer use these days.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mwiktowy at gmx.net  Sun Nov 27 20:20:36 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 15:20:36 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133103907.21208.3.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
Message-ID: <1133122837.6986.37.camel@localhost>

On Sun, 2005-11-27 at 10:05 -0500, seth vidal wrote:
> > Handling it like the key checking that ssh does (with a warning and an
> > option to continue) might be the way to go.
> 
> yum does that now. It asks you if you want to import the key and you
> have to press y or n.

Not quite what I was referring to. I am talking about long after you
have accepted a key initially and the key is added to your
~/.ssh/known_hosts file. The check that I refer to is the one where the
host presents a key and you have a different one in the known_hosts file
for that host. ssh complains *very* loudly and gives a clear indication
why this is an issue (MITM attack).

> > It would prevent some widespread trojan installation possible by a
> > popular third-party repo's key getting compromised, malicious repo
> > owners and possible future repo slap-fights.
> 
> the only thing that will prevent that is if users wisen up about what
> they're doing. It's the same thing as what protects them from sending
> their CC to a nefarious site or one unprotected by encryption. They have
> to be aware of what's going on around them.

Undoubtedly wise users would be desired (so would money growing on
trees). However, even the wisest user would have to pay very close
attention to prevent a repo from swapping out its yum.repos.d file
(something that might be expected from repos that maintain rpms
containing those config files and are updating their mirrors lists,
etc.) with one that had a [base] or [extras] stanza in it (something
that would be invisible and make future meddling next to invisible).

Security being a multi-layered thing, what I am suggesting is that, on
top of wizening the users as you suggested, giving the foolish users
clear indication that something nasty is amiss is desirable.
 
> > It seems that right now, some owner of pooptastic-updates can offer up
> > the wonderful superfoo package, convince some users to install their
> > pooptastic.repo containing a URL to the pooptastic.key. At that point,
> > they could replace any package on your system at update time with little
> > indication to the user.
> 
> If they already agreed to import the key, yes.

rpm -qai gpg-pubkey*
indicated 10 keys from various repos and developers that I have
installed packages from in the past. You are saying that any one of
those key owners can freely replace any package on your system with
little indication to the user that this is being done. That makes me
want to use rpm -i --nosignature rather than yum for small independent
developers offering yum repos of their stuff to prevent them from
getting inside that wall where no subdivisions exist; which kind of
detracts from the usefulness of yum.

/Mike




From skvidal at phy.duke.edu  Sun Nov 27 20:29:27 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 15:29:27 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133122837.6986.37.camel@localhost>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost>
Message-ID: <1133123367.21208.54.camel@cutter>

On Sun, 2005-11-27 at 15:20 -0500, Michael Wiktowy wrote:
> On Sun, 2005-11-27 at 10:05 -0500, seth vidal wrote:
> > > Handling it like the key checking that ssh does (with a warning and an
> > > option to continue) might be the way to go.
> > 
> > yum does that now. It asks you if you want to import the key and you
> > have to press y or n.
> 
> Not quite what I was referring to. I am talking about long after you
> have accepted a key initially and the key is added to your
> ~/.ssh/known_hosts file. The check that I refer to is the one where the
> host presents a key and you have a different one in the known_hosts file
> for that host. ssh complains *very* loudly and gives a clear indication
> why this is an issue (MITM attack).

and what do most users do if asked how to deal with this problem?

they just accept it and move along, not noticing at all that they
consented to a possible man in the middle attack.

So it defeats the purpose a bit.

Don't get me wrong. I see where you're coming from. You want to make
sure that the key or keys signing any given package is the same key
that's on the package already installed.  I get where you're coming from
- I'm just not sure it makes sense at some point.

Here's an idea for you - implement this as a yum-plugin.
Post-download-package you can check the set of where things are coming
from and compare gpg keys from there.

see how much traction/interest you get from there.

-sv




From mattdm at mattdm.org  Sun Nov 27 20:32:44 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 15:32:44 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133123367.21208.54.camel@cutter>
References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com>
	<1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost>
	<1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost>
	<1133123367.21208.54.camel@cutter>
Message-ID: <20051127203244.GA31934@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 03:29:27PM -0500, seth vidal wrote:
> Here's an idea for you - implement this as a yum-plugin.
> Post-download-package you can check the set of where things are coming
> from and compare gpg keys from there.
> see how much traction/interest you get from there.

FWIW, I'm interested enough to try out a plugin someone else writes. :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From nutello at sweetness.com  Sun Nov 27 20:50:33 2005
From: nutello at sweetness.com (Rudi Chiarito)
Date: Sun, 27 Nov 2005 21:50:33 +0100
Subject: 'everything' install option in FC5test1
In-Reply-To: <1133110542.18465.15.camel@yoda.loki.me>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<20051127164458.GH22555@plain.rackshack.net>
	<1133110542.18465.15.camel@yoda.loki.me>
Message-ID: <20051127205033.GL22555@plain.rackshack.net>

On Sun, Nov 27, 2005 at 08:55:42AM -0800, Jesse Keating wrote:
> When Anaconda can look at more repos than just Extras (think FC6)
> wouldn't it make more sense to have your own yum repo with group
> definitions for each system profile?  Then you can tell anaconda's yum
> to group-install <foo>.  After the install, yum update will do the
> updating work.

I already maintain a local yum repository.

The nice thing about cfengine is that it defines a lot of classes. When
running on x86_64 it will define 64_bit rather than 32_bit, for FC4
systems it will define fedora and fedora_4, plus other classes whose
names are derived from the IPv4/v6 address and subnet, running kernel
version, etc. You can define your own classes, too (e.g.
kickstart_server for your kickstart servers).

You can then apply actions including or excluding any number classes,
using boolean and/or/not/grouping operators. I use that to build a list
of packages that derives from all the classes the system belongs to. 

You could use cfengine to pass a number of group names to be used for
yum's groupinstall/update, but then you need to enforce that the
addition of a new group happens in the yum repository first. Plus,
keeping information in yet another place is inconvenient if, like me,
you keep the cfengine configuration files under revision control (you'd
probably want cfengine to generate the yumgroups.xml file for you in
that case).

If packages are all you want to manage then, yes, yum groups are viable
and cfengine is overkill - just generating and distributing the
cryptographic keys is too much effort for such a small return.

Especially if you have a large number of systems, though, you'll want to
go for something like cfengine and even do as much as possible with it.
I use it to tweak ldap.conf/nsswitch.conf/system-auth, install PPD files
and printers for CUPS, set up the NTP servers and clients, replicate
files, add/mount NFS shares in fstab, turn on init.d services, set up
NAT on cluster masters, manage virtual IPs, etc. This has helped
cut down on the number of permutations of kickstart files I keep. At
some point I realised that Anaconda's kickstart mechanism is never going
to cover all your needs and huge post-install sections were not the
solution (plus I needed something to automate changes that come up after
the system has been installed).

BTW, cfengine is being rewritten for version 3. I also come across
puppet, which looks promising: http://reductivelabs.com/projects/puppet


-- 
Rudi



From mwiktowy at gmx.net  Sun Nov 27 21:07:45 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 16:07:45 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133123367.21208.54.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
Message-ID: <1133125665.6986.57.camel@localhost>

On Sun, 2005-11-27 at 15:29 -0500, seth vidal wrote:
> On Sun, 2005-11-27 at 15:20 -0500, Michael Wiktowy wrote:
> > On Sun, 2005-11-27 at 10:05 -0500, seth vidal wrote:
> > > > Handling it like the key checking that ssh does (with a warning and an
> > > > option to continue) might be the way to go.
> > > 
> > > yum does that now. It asks you if you want to import the key and you
> > > have to press y or n.
> > 
> > Not quite what I was referring to. I am talking about long after you
> > have accepted a key initially and the key is added to your
> > ~/.ssh/known_hosts file. The check that I refer to is the one where the
> > host presents a key and you have a different one in the known_hosts file
> > for that host. ssh complains *very* loudly and gives a clear indication
> > why this is an issue (MITM attack).
> 
> and what do most users do if asked how to deal with this problem?
> 
> they just accept it and move along, not noticing at all that they
> consented to a possible man in the middle attack.
> 
> So it defeats the purpose a bit.

Well ... that is where the wizening of the users comes in :]

This ties in with the concept of Union layers that Arjan van de Ven
presented in the "Re: suggestion: move all java packages to extras"
thread. Do we want layers that are higher up/more specialized have the
ability to:
1) Override lower layer packages automatically
2) Ask to over ride them
3) Never override them

Right now it is option #1.

> Don't get me wrong. I see where you're coming from. You want to make
> sure that the key or keys signing any given package is the same key
> that's on the package already installed.  I get where you're coming from
> - I'm just not sure it makes sense at some point.

I am suggesting the move to option #2 would be better.

> Here's an idea for you - implement this as a yum-plugin.
> Post-download-package you can check the set of where things are coming
> from and compare gpg keys from there.
> 
> see how much traction/interest you get from there.

OK ... I expected a "put some code where you mouth is" response and that
is fair. I am not much of a coder but this will give me some reason to
learn python so I will give it a try. I would appreciate some guidance
to documentation/sites/example code where I could research the yum
plugin structure. For now I will start reading though the yum-devel
list.

/Mike



From skvidal at phy.duke.edu  Sun Nov 27 21:13:50 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 16:13:50 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133125665.6986.57.camel@localhost>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost>
Message-ID: <1133126030.21208.57.camel@cutter>

On Sun, 2005-11-27 at 16:07 -0500, Michael Wiktowy wrote:
> On Sun, 2005-11-27 at 15:29 -0500, seth vidal wrote:
> > On Sun, 2005-11-27 at 15:20 -0500, Michael Wiktowy wrote:
> > > On Sun, 2005-11-27 at 10:05 -0500, seth vidal wrote:
> > > > > Handling it like the key checking that ssh does (with a warning and an
> > > > > option to continue) might be the way to go.
> > > > 
> > > > yum does that now. It asks you if you want to import the key and you
> > > > have to press y or n.
> > > 
> > > Not quite what I was referring to. I am talking about long after you
> > > have accepted a key initially and the key is added to your
> > > ~/.ssh/known_hosts file. The check that I refer to is the one where the
> > > host presents a key and you have a different one in the known_hosts file
> > > for that host. ssh complains *very* loudly and gives a clear indication
> > > why this is an issue (MITM attack).
> > 
> > and what do most users do if asked how to deal with this problem?
> > 
> > they just accept it and move along, not noticing at all that they
> > consented to a possible man in the middle attack.
> > 
> > So it defeats the purpose a bit.
> 
> Well ... that is where the wizening of the users comes in :]
> 
> This ties in with the concept of Union layers that Arjan van de Ven
> presented in the "Re: suggestion: move all java packages to extras"
> thread. Do we want layers that are higher up/more specialized have the
> ability to:
> 1) Override lower layer packages automatically
> 2) Ask to over ride them
> 3) Never override them
> 
> Right now it is option #1.
> 
> > Don't get me wrong. I see where you're coming from. You want to make
> > sure that the key or keys signing any given package is the same key
> > that's on the package already installed.  I get where you're coming from
> > - I'm just not sure it makes sense at some point.
> 
> I am suggesting the move to option #2 would be better.
> 
> > Here's an idea for you - implement this as a yum-plugin.
> > Post-download-package you can check the set of where things are coming
> > from and compare gpg keys from there.
> > 
> > see how much traction/interest you get from there.
> 
> OK ... I expected a "put some code where you mouth is" response and that
> is fair. I am not much of a coder but this will give me some reason to
> learn python so I will give it a try. I would appreciate some guidance
> to documentation/sites/example code where I could research the yum
> plugin structure. For now I will start reading though the yum-devel
> list.
> 


/usr/share/doc/yum-2.4.0/PLUGINS

look in the yum-utils package for example plugins.

and:
http://wiki.linux.duke.edu/YumPlugins

-sv




From mwiktowy at gmx.net  Sun Nov 27 21:46:46 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 16:46:46 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133115473.2853.36.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
	<1133115473.2853.36.camel@laptopd505.fenrus.org>
Message-ID: <1133128006.6986.82.camel@localhost>

On Sun, 2005-11-27 at 19:17 +0100, Arjan van de Ven wrote:
> So "someone in Red Hat makes a decision" is not the problem. Unclear
> criteria, lack of "what is suitable functionality for core" policy etc
> is a problem (you can argue how big a problem it is of course).

In a strictly "functional" sense, all that *needs* to be in Core are:
1) those packages that enable network/Internet access and installation
of more packages
2) those packages that people will likely use on systems that will never
have network/Internet access

Group 1 is fairly defined.
Group 2 is largely subjective as there are so many usage patterns in
that group. Group 2 is largely eliminated by a good infrastructure for
bundling up Extras/third-party repos as CDs that can be used offline.

A consequence of these two rules would be that packages that are only
useful when the target system has Internet access would be more suitably
residing in Extras.

Also, java and friends have a home in Core according to these two
criteria.

/Mike



From mwiktowy at gmx.net  Sun Nov 27 21:57:35 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 16:57:35 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133126030.21208.57.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
Message-ID: <1133128655.6986.91.camel@localhost>

On Sun, 2005-11-27 at 16:13 -0500, seth vidal wrote:
> On Sun, 2005-11-27 at 16:07 -0500, Michael Wiktowy wrote:
> > I would appreciate some guidance
> > to documentation/sites/example code where I could research the yum
> > plugin structure. For now I will start reading though the yum-devel
> > list.
> 
> /usr/share/doc/yum-2.4.0/PLUGINS

That file does not exist on my FC4 system ... is this a FC5-test1 thing?

> look in the yum-utils package for example plugins.

[mwiktowy at localhost ~]$ rpm -ql yum-utils
/usr/bin/package-cleanup
/usr/bin/repo-rss
/usr/bin/repoclosure
/usr/bin/repomanage
/usr/bin/repoquery
/usr/bin/yum-builddep
/usr/bin/yumdownloader
/usr/share/doc/yum-utils-0.3.1
/usr/share/doc/yum-utils-0.3.1/README

All of these seem to be stand-alone apps and not really plugins, per se.
Are there more included in FC5-test1?

> and:
> http://wiki.linux.duke.edu/YumPlugins

Good stuff to be had here ... thanks.

/Mike



From skvidal at phy.duke.edu  Sun Nov 27 22:02:03 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 17:02:03 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133128655.6986.91.camel@localhost>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost>
Message-ID: <1133128923.21208.59.camel@cutter>

On Sun, 2005-11-27 at 16:57 -0500, Michael Wiktowy wrote:
> On Sun, 2005-11-27 at 16:13 -0500, seth vidal wrote:
> > On Sun, 2005-11-27 at 16:07 -0500, Michael Wiktowy wrote:
> > > I would appreciate some guidance
> > > to documentation/sites/example code where I could research the yum
> > > plugin structure. For now I will start reading though the yum-devel
> > > list.
> > 
> > /usr/share/doc/yum-2.4.0/PLUGINS
> 
> That file does not exist on my FC4 system ... is this a FC5-test1 thing?

you updated your version of yum?

What version of yum are you on?

> 
> > look in the yum-utils package for example plugins.
> 
> [mwiktowy at localhost ~]$ rpm -ql yum-utils
> /usr/bin/package-cleanup
> /usr/bin/repo-rss
> /usr/bin/repoclosure
> /usr/bin/repomanage
> /usr/bin/repoquery
> /usr/bin/yum-builddep
> /usr/bin/yumdownloader
> /usr/share/doc/yum-utils-0.3.1
> /usr/share/doc/yum-utils-0.3.1/README
> 
> All of these seem to be stand-alone apps and not really plugins, per se.
> Are there more included in FC5-test1?

hmm
-sv




From jspaleta at gmail.com  Sun Nov 27 22:04:34 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 27 Nov 2005 17:04:34 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133128923.21208.59.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost>
	<1133103907.21208.3.camel@cutter> <1133122837.6986.37.camel@localhost>
	<1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost>
	<1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost>
	<1133128923.21208.59.camel@cutter>
Message-ID: <604aa7910511271404g2aa9a4e3tab7aa1a1e8c604b7@mail.gmail.com>

On 11/27/05, seth vidal <skvidal at phy.duke.edu> wrote:
> On Sun, 2005-11-27 at 16:57 -0500, Michael Wiktowy wrote:
> > On Sun, 2005-11-27 at 16:13 -0500, seth vidal wrote:
> > > On Sun, 2005-11-27 at 16:07 -0500, Michael Wiktowy wrote:
> > > > I would appreciate some guidance
> > > > to documentation/sites/example code where I could research the yum
> > > > plugin structure. For now I will start reading though the yum-devel
> > > > list.
> > >
> > > /usr/share/doc/yum-2.4.0/PLUGINS
> >
> > That file does not exist on my FC4 system ... is this a FC5-test1 thing?
>
> you updated your version of yum?
>
> What version of yum are you on?

this document file is not a part of yum-2.4.0-0.fc4  nor yum-2.4.0-14
from rawhide

none of the items in yum-utils from either extras-fc4 or
extras-development are plugin based. They are all standalone.

The only plugin that I'm aware of that ships as part of a fedora rpm
at the moment is the installonlyn plugin in yum-2.4.0-14  from rawhide

-jef



From skvidal at phy.duke.edu  Sun Nov 27 22:18:37 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 17:18:37 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <604aa7910511271404g2aa9a4e3tab7aa1a1e8c604b7@mail.gmail.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost> <1133128923.21208.59.camel@cutter>
	<604aa7910511271404g2aa9a4e3tab7aa1a1e8c604b7@mail.gmail.com>
Message-ID: <1133129917.21208.70.camel@cutter>

> this document file is not a part of yum-2.4.0-0.fc4  nor yum-2.4.0-14
> from rawhide
> 
> none of the items in yum-utils from either extras-fc4 or
> extras-development are plugin based. They are all standalone.
> 
> The only plugin that I'm aware of that ships as part of a fedora rpm
> at the moment is the installonlyn plugin in yum-2.4.0-14  from rawhide

ah, well that needs to be fixed as the upstream yum spec file includes
the PLUGINS document.

-sv




From mwiktowy at gmx.net  Sun Nov 27 22:20:54 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 17:20:54 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133128923.21208.59.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost> <1133128923.21208.59.camel@cutter>
Message-ID: <1133130054.6986.97.camel@localhost>

On Sun, 2005-11-27 at 17:02 -0500, seth vidal wrote:
> On Sun, 2005-11-27 at 16:57 -0500, Michael Wiktowy wrote:
> > On Sun, 2005-11-27 at 16:13 -0500, seth vidal wrote:
> > > /usr/share/doc/yum-2.4.0/PLUGINS
> > 
> > That file does not exist on my FC4 system ... is this a FC5-test1 thing?
> 
> you updated your version of yum?
> 
> What version of yum are you on?

[mwiktowy at localhost ~]$ rpm -q yum
yum-2.4.0-0.fc4
 
> > > look in the yum-utils package for example plugins.
> > 
> > [mwiktowy at localhost ~]$ rpm -ql yum-utils
> > /usr/bin/package-cleanup
> > /usr/bin/repo-rss
> > /usr/bin/repoclosure
> > /usr/bin/repomanage
> > /usr/bin/repoquery
> > /usr/bin/yum-builddep
> > /usr/bin/yumdownloader
> > /usr/share/doc/yum-utils-0.3.1
> > /usr/share/doc/yum-utils-0.3.1/README
> > 
> > All of these seem to be stand-alone apps and not really plugins, per se.
> > Are there more included in FC5-test1?
> 
> hmm

[mwiktowy at localhost ~]$ rpm -q yum-utils
yum-utils-0.3.1-1.fc4

yum update gives me nothing newer for FC4 for either yum or yum-utils.

/Mike



From skvidal at phy.duke.edu  Sun Nov 27 22:23:55 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 17:23:55 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133130054.6986.97.camel@localhost>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost> <1133128923.21208.59.camel@cutter>
	<1133130054.6986.97.camel@localhost>
Message-ID: <1133130235.21208.74.camel@cutter>


> [mwiktowy at localhost ~]$ rpm -q yum-utils
> yum-utils-0.3.1-1.fc4
> 
> yum update gives me nothing newer for FC4 for either yum or yum-utils.
> 


here you go:
http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum/PLUGINS?rev=1.1&view=auto

and

http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum-utils/plugins/
enjoy

-sv




From arjan at fenrus.demon.nl  Sun Nov 27 22:27:33 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Sun, 27 Nov 2005 23:27:33 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133128006.6986.82.camel@localhost>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
	<1133115473.2853.36.camel@laptopd505.fenrus.org>
	<1133128006.6986.82.camel@localhost>
Message-ID: <1133130453.2853.49.camel@laptopd505.fenrus.org>

On Sun, 2005-11-27 at 16:46 -0500, Michael Wiktowy wrote:
> On Sun, 2005-11-27 at 19:17 +0100, Arjan van de Ven wrote:
> > So "someone in Red Hat makes a decision" is not the problem. Unclear
> > criteria, lack of "what is suitable functionality for core" policy etc
> > is a problem (you can argue how big a problem it is of course).
> 
> In a strictly "functional" sense, all that *needs* to be in Core are:
> 1) those packages that enable network/Internet access and installation
> of more packages
> 2) those packages that people will likely use on systems that will never
> have network/Internet access

I don't agree with you. For me, Core needs to be a Core linux distro.
That includes a desktop, browser, media player, mail client and an
office suite. Eg core needs to satisfy the basic goals a target audience
has with a distro.

In addition I think core needs the basic tools that developers would use
to develop extras like packages. Eg a compiler set for the common
languages, make, patch and other supporting stuff like that. (this also
follows from being self consistent and self-hosting, I think Core needs
to be self hosting as well)



From skvidal at phy.duke.edu  Sun Nov 27 22:33:08 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 17:33:08 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133107847.2853.26.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
Message-ID: <1133130789.21208.81.camel@cutter>


> then I don't agree with how that works and would favor and advocate a
> more "functionality" way of looking at it.

Great! Then see the Core Brainstorm thread on -maintainers and give us
more of your criteria for something going to core or not.

-sv




From mwiktowy at gmx.net  Sun Nov 27 23:01:48 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 18:01:48 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133130453.2853.49.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<4389E524.4050904@conversis.de>
	<1133115473.2853.36.camel@laptopd505.fenrus.org>
	<1133128006.6986.82.camel@localhost>
	<1133130453.2853.49.camel@laptopd505.fenrus.org>
Message-ID: <1133132508.6986.124.camel@localhost>

On Sun, 2005-11-27 at 23:27 +0100, Arjan van de Ven wrote:
> On Sun, 2005-11-27 at 16:46 -0500, Michael Wiktowy wrote:
> > On Sun, 2005-11-27 at 19:17 +0100, Arjan van de Ven wrote:
> > > So "someone in Red Hat makes a decision" is not the problem. Unclear
> > > criteria, lack of "what is suitable functionality for core" policy etc
> > > is a problem (you can argue how big a problem it is of course).
> > 
> > In a strictly "functional" sense, all that *needs* to be in Core are:
> > 1) those packages that enable network/Internet access and installation
> > of more packages
> > 2) those packages that people will likely use on systems that will never
> > have network/Internet access
> 
> I don't agree with you. For me, Core needs to be a Core linux distro.
> That includes a desktop, browser, media player, mail client and an
> office suite. Eg core needs to satisfy the basic goals a target audience
> has with a distro.

Arguably, desktop, media player and office suite falls under group 2).
Browser and mail client could be argues to fall under group 1) as they
enable users to get more packages by providing a convenient fashion by
which to get information about new packages.

> In addition I think core needs the basic tools that developers would use
> to develop extras like packages. Eg a compiler set for the common
> languages, make, patch and other supporting stuff like that. (this also
> follows from being self consistent and self-hosting, I think Core needs
> to be self hosting as well)

Compilers and development tools could be considered to fall into group
2). Perhaps it would be clearer to define group 2) as "those packages
that people will likely use on systems that will never *require*
network/Internet access" as packages that require Internet access but
don't enable Internet access could just as easily be gotten from the
Internet/Extras.

So there is no fundamental disagreement here. I am not pushing to gut
Core. I am just offering some simple "what is suitable functionality for
core" policy guidelines. I think those above draw a fundamental line
without being all inclusive with the right weasel-wording.

But they do just push the question back to "What usage patterns are you
targeting Fedora for?" in order to draw a line around group 2) packages.

By your comments I would guess that those patterns would be:
- self-hosting (those who want to build their Core from scratch using
the tools in Core)
- developers (compilers, languages, IDEs)
- office workers (graphical desktop, office suite, CD burning)
- home users (graphical desktop, media players, CD burning)

There are certainly other patterns and those above could be better
defined but there is a line drawn to have a discussion around.

/Mike



From mwiktowy at gmx.net  Sun Nov 27 23:50:49 2005
From: mwiktowy at gmx.net (Michael Wiktowy)
Date: Sun, 27 Nov 2005 18:50:49 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1133130235.21208.74.camel@cutter>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<604aa7910511260734u547e6fbbi32a5a11fa0df6d8b@mail.gmail.com>
	<4388E2D4.5050301@hotmail.com> <1133060840l.22893l.0l@serve.riede.org>
	<604aa7910511261959q7f692345h7585f9b9da36256e@mail.gmail.com>
	<1133081661.21062.21.camel@localhost> <1133103907.21208.3.camel@cutter>
	<1133122837.6986.37.camel@localhost> <1133123367.21208.54.camel@cutter>
	<1133125665.6986.57.camel@localhost> <1133126030.21208.57.camel@cutter>
	<1133128655.6986.91.camel@localhost> <1133128923.21208.59.camel@cutter>
	<1133130054.6986.97.camel@localhost> <1133130235.21208.74.camel@cutter>
Message-ID: <1133135449.6986.133.camel@localhost>

On Sun, 2005-11-27 at 17:23 -0500, seth vidal wrote:
> > [mwiktowy at localhost ~]$ rpm -q yum-utils
> > yum-utils-0.3.1-1.fc4
> > 
> > yum update gives me nothing newer for FC4 for either yum or yum-utils.
> > 
> 
> 
> here you go:
> http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum/PLUGINS?rev=1.1&view=auto
> 
> and
> 
> http://devel.linux.duke.edu/cgi-bin/viewcvs.cgi/yum-utils/plugins/
> enjoy
> 
> -sv

Thanks.

It looks like what I am shooting for is similar in concept to the plugin
protectbase.py by mjs
Except what that does is protect base from not_base.
What I would like is to protect x from not_x without having to
explicitly configure anything.

/Mike



From paul at cypherpunks.ca  Mon Nov 28 00:40:15 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 28 Nov 2005 01:40:15 +0100 (CET)
Subject: Yum and SRPMs
In-Reply-To: <1133103767.21208.0.camel@cutter>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
Message-ID: <Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>

On Sun, 27 Nov 2005, seth vidal wrote:

> > > yum install yum-utils
> > > yumdownloader --source package
> > >
> >
> > That's useful, thanks.
> > Might this functionality ever be built into yum though?
> >
>
> no

That's a really good answer if you want developrs to feel that they
are being taken seriously.....

Do you think there is a fundamental problem with people being able to get
the sources easilly? Is yum fundamentally flawed for this? Is it too much
work to put in yum?

We might appreciate decisions better if we know why they are made in a
certain way.

Paul



From mattdm at mattdm.org  Mon Nov 28 00:49:35 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 19:49:35 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
Message-ID: <20051128004935.GA7617@jadzia.bu.edu>

On Mon, Nov 28, 2005 at 01:40:15AM +0100, Paul Wouters wrote:
> Do you think there is a fundamental problem with people being able to get
> the sources easilly? Is yum fundamentally flawed for this? Is it too much
> work to put in yum?
> We might appreciate decisions better if we know why they are made in a
> certain way.

It's been discussed over and over; that's why Seth is being so abrupt. The
archives to this list and the yum list are public, so you can certainly find
out why they've been made.

The short answer is that it violates the principle of "do one thing and do
it well". Adding features like this clutters up yum's interface, not to
mention the internal code. Having it separate is cleaner.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From skvidal at phy.duke.edu  Mon Nov 28 00:52:50 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 19:52:50 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
Message-ID: <1133139170.21208.99.camel@cutter>

On Mon, 2005-11-28 at 01:40 +0100, Paul Wouters wrote:
> On Sun, 27 Nov 2005, seth vidal wrote:
> 
> > > > yum install yum-utils
> > > > yumdownloader --source package
> > > >
> > >
> > > That's useful, thanks.
> > > Might this functionality ever be built into yum though?
> > >
> >
> > no
> 
> That's a really good answer if you want developrs to feel that they
> are being taken seriously.....
> 
> Do you think there is a fundamental problem with people being able to get
> the sources easilly? Is yum fundamentally flawed for this? Is it too much
> work to put in yum?
> 
> We might appreciate decisions better if we know why they are made in a
> certain way.

It's really best discussed on appropriate list-  yum-devel.

But to the point  - we've discussed it there before. The reason it
should not be in the yum program itself but in an add-on tool is that it
unnecessarily clutters up the main program.

-sv




From saddateh at gmail.com  Mon Nov 28 01:17:06 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Sun, 27 Nov 2005 20:17:06 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
Message-ID: <fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>

Consider this scenario. A developer is running Fedora rawhide on one of his
spare machines. The developer is not directly involved in the Fedora
process. He just likes to keep track of the latest changes because he is a
hobbyist. Fedora is also his favorite distro, so he likes to know all the
latest news, so he reads mailing lists such as this one every now and then.

Now consider this. He notices that one of his favorite applications has a
bug. He has two choices, fix the bug himself or file a bug report. If he
chooses to file a bug report, he must first find out where the erroneous
software is hosted. This probably involves a Google search or two, not so
bad. Once he finds the site where the package is maintained, he must now
find where to file the bug. He must now search the site for the ubiquitous
Bugzilla. Now he must most likely register an account with that Bugzilla.
Finally, after this whole process he must submit the bug report. Then he
might track the bug by e-mail until it gets fixed (but most likely he will
just forget about it and hope the maintainer gets around to fixing it). The
developer could have just chosen to submit the report to Red Hat's bugzilla,
but he is conscientious and knows the problem will probably be fixed sooner
if he submits it directly to the project owners bug database.

Now consider the scenario where the developer can yum install --source
some-package, and have it install the source along with all the dependent
source packages. Then he would be able to cd to some dir where he can type
make and the source will compile without issues or missing headers. Then he
goes into the source dir with his favorite editor and makes a couple mods to
the source. He re-compiles probably a few times and now the bug is fixed. He
is no longer annoyed by the bug in his favorite app, since he typed make
install and the changes automatically took effect on his machine. After
maybe a day or two of running with the changes, he is sure he hasn't b0rked
anything so he creates a patch and submits it to Red Hat's bugzilla. He
doesn't have to worry about running around willy-nilly finding the master
maintainer because he knows the Fedora maintainer already knows the lead
developers and will submit the patch upstream eventually. The patch then
makes its way into rawhide for more widespread testing. People on the
mailing list thank the person for fixing their most hated bug. The developer
feels great for helping out others who were annoyed by the same problem. The
feeling is addictive and now Fedora has gained a semi-casual code
contributor who most likely fixes little annoying things that the main
developers couldn't be bothered with.

I, as a programmer and a Fedora hobbyist, definitely prefer the latter
scenario as opposed to the former. Such an enhancement in yum would make it
so much easier to hack buggy code. It would also make it easier to fix
critical (or just annoying) bugs faster and perhaps deploy and test the
fixes before rawhide trackers even see them. Plus, being able to fix a bug
and submit a patch for it in one centralized place (RH Bugzilla) is so much
more satisfying than signing up for countless Bugzilla and CVS accounts.
Besides, for those who have the skills to fix the bugs instead of just
reporting them, why not make it easier for these people to actually fix the
bugs? Isn't this what "open source" is all about. It doesn't make sense for
any distro to make it harder to install the source than it is to install
binaries. Doesn't make sense at all.

This type of change would make room for more casual code contributors. Let
the more dedicated Fedora/Red Hat developers worry about the semantics of
getting fixes upstream. I bet even some of the more hardcore developers
would soon find this functionality indispensable too.

On 11/27/05, Paul Wouters <paul at cypherpunks.ca> wrote:
>
> On Sun, 27 Nov 2005, seth vidal wrote:
>
> > > > yum install yum-utils
> > > > yumdownloader --source package
> > > >
> > >
> > > That's useful, thanks.
> > > Might this functionality ever be built into yum though?
> > >
> >
> > no
>
> That's a really good answer if you want developrs to feel that they
> are being taken seriously.....
>
> Do you think there is a fundamental problem with people being able to get
> the sources easilly? Is yum fundamentally flawed for this? Is it too much
> work to put in yum?
>
> We might appreciate decisions better if we know why they are made in a
> certain way.
>
> Paul
>
> --
> 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/20051127/4a3f46d5/attachment.htm>

From paul at cypherpunks.ca  Mon Nov 28 01:22:00 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 28 Nov 2005 02:22:00 +0100 (CET)
Subject: Yum and SRPMs
In-Reply-To: <1133139170.21208.99.camel@cutter>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<1133139170.21208.99.camel@cutter>
Message-ID: <Pine.LNX.4.63.0511280218010.11604@tla.xelerance.com>

On Sun, 27 Nov 2005, seth vidal wrote:

> It's really best discussed on appropriate list-  yum-devel.
>
> But to the point  - we've discussed it there before. The reason it
> should not be in the yum program itself but in an add-on tool is that it
> unnecessarily clutters up the main program.

Okay. Thanks for the information.

Not that agree. The above sounds correct from the yum developers point
of view, but fails to take into account the enduser who will expect to
be able to use "the package manager" for such tasks.

There also seems to be no easy way for the user to figure out an
additional tool is needed. Perhaps "yum install foo.src" and "yum
-source install foo" could return some helpful information on how
people are supposed to obtain the source in a somewhat automatic way.

I'm sure that does not add *that* much complexity to yum :)

Paul



From mattdm at mattdm.org  Mon Nov 28 01:20:12 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 20:20:12 -0500
Subject: Yum and SRPMs
In-Reply-To: <fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
Message-ID: <20051128012012.GA8556@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 08:17:06PM -0500, Sadda Teh wrote:
> Now consider the scenario where the developer can yum install --source
> some-package, and have it install the source along with all the dependent
> source packages. Then he would be able to cd to some dir where he can type
[...]

That's a very long, tragic tale. But what in this story suggests that "yum
install --source" is so much better than "yumdownloader --source"? Or even
slightly better?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From bbbush.yuan at gmail.com  Mon Nov 28 01:26:15 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Mon, 28 Nov 2005 09:26:15 +0800
Subject: Yum and SRPMs
In-Reply-To: <20051128012012.GA8556@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
Message-ID: <76e72f800511271726rb470fd0m@mail.gmail.com>

2005/11/28, Matthew Miller <mattdm at mattdm.org>:
>
> That's a very long, tragic tale. But what in this story suggests that "yum
> install --source" is so much better than "yumdownloader --source"? Or even
> slightly better?
>

What if include rpm-build in yum, like apt-build, or apt-get build
does? Maybe yum could become another emerge or pkg_add or so. :p

--
bbbush ^_^



From skvidal at phy.duke.edu  Mon Nov 28 01:37:14 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 20:37:14 -0500
Subject: Yum and SRPMs
In-Reply-To: <76e72f800511271726rb470fd0m@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
Message-ID: <1133141834.21208.104.camel@cutter>

On Mon, 2005-11-28 at 09:26 +0800, Yuan Yijun wrote:
> 2005/11/28, Matthew Miller <mattdm at mattdm.org>:
> >
> > That's a very long, tragic tale. But what in this story suggests that "yum
> > install --source" is so much better than "yumdownloader --source"? Or even
> > slightly better?
> >
> 
> What if include rpm-build in yum, like apt-build, or apt-get build
> does? Maybe yum could become another emerge or pkg_add or so. :p
> 

2 items:
1. why wouldn't we make a yum-devel that handles that sort of thing so
we don't have one command with 25 thousand options?
2. We wouldn't want all that building going on as root so it'd be better
if that command could do it as a user.

-sv




From jkeating at j2solutions.net  Mon Nov 28 01:37:15 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 27 Nov 2005 17:37:15 -0800
Subject: Yum and SRPMs
In-Reply-To: <76e72f800511271726rb470fd0m@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
Message-ID: <1133141835.2833.10.camel@yoda.loki.me>

On Mon, 2005-11-28 at 09:26 +0800, Yuan Yijun wrote:
> What if include rpm-build in yum, like apt-build, or apt-get build
> does? Maybe yum could become another emerge or pkg_add or so. :p

Danger will robinson.  Feature creep.

Yum downloads packages/updates from configured repositories, resolves
deps, and installs those packages.  Anything else is above and beyond
yum.  Other things can use yum libraries to accomplish that bit of task,
but must provide everything else.

Now, with the new libraries that Seth is cranking out, a python script
can import the yum module, do:

import yum

foo = yum.YumBase()
foo.doGenericSetup()

Then you can setup all kinds of things like

foo.install(name='bar')

and

foo.update()

and when you are done lining up these yum actions, you can

foo.runTransaction()

to run it all.  Yum will be very easy to tie into for doing your grander
than yum actions.

(thanks seth for the examples on IRC that I copied here)

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From mattdm at mattdm.org  Mon Nov 28 01:39:59 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 20:39:59 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280218010.11604@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<1133139170.21208.99.camel@cutter>
	<Pine.LNX.4.63.0511280218010.11604@tla.xelerance.com>
Message-ID: <20051128013959.GB8556@jadzia.bu.edu>

On Mon, Nov 28, 2005 at 02:22:00AM +0100, Paul Wouters wrote:
> Not that agree. The above sounds correct from the yum developers point
> of view, but fails to take into account the enduser who will expect to
> be able to use "the package manager" for such tasks.

I dunno. I expect an end-user savvy enough to use yum on the command line
can figure it out fairly easily. And by extension, anyone savvy enough to
have a use for source.

> There also seems to be no easy way for the user to figure out an
> additional tool is needed. Perhaps "yum install foo.src" and "yum
> -source install foo" could return some helpful information on how
> people are supposed to obtain the source in a somewhat automatic way.

That seems like a bad road to go down -- should every option for every
function people think a program should have return an explanation for why it
actually hasn't? What I someone think "yum sourcedownload foo" would be
the intuitive way? Should that also give a message? :)

But maybe a mention in the man pages is warrented, just to help people out.
And this should probably go in the Yum Faq... Okay, now it is (Q14;
<http://wiki.linux.duke.edu/YumFaq>).


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jspaleta at gmail.com  Mon Nov 28 01:40:13 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Sun, 27 Nov 2005 20:40:13 -0500
Subject: Yum and SRPMs
In-Reply-To: <fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
Message-ID: <604aa7910511271740o6bf6afc2s63cdde0af5829734@mail.gmail.com>

On 11/27/05, Sadda Teh <saddateh at gmail.com> wrote:
>  I, as a programmer and a Fedora hobbyist, definitely prefer the latter
> scenario as opposed to the former. Such an enhancement in yum would make it
> so much easier to hack buggy code.
bah
yumdownloader --source to get the src.rpm
then use mock to build the src.rpm in a consistent build environment.
is that really that hard?

-jef



From mattdm at mattdm.org  Mon Nov 28 01:43:18 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 20:43:18 -0500
Subject: Yum and SRPMs
In-Reply-To: <1133141834.21208.104.camel@cutter>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
	<1133141834.21208.104.camel@cutter>
Message-ID: <20051128014318.GC8556@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
> > What if include rpm-build in yum, like apt-build, or apt-get build
> > does? Maybe yum could become another emerge or pkg_add or so. :p
> 2 items:
> 1. why wouldn't we make a yum-devel that handles that sort of thing so
> we don't have one command with 25 thousand options?
> 2. We wouldn't want all that building going on as root so it'd be better
> if that command could do it as a user.

Hmmm. I'm pretty sure the previous comment was meant as joking actually in
_support_ of your position. :)


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From skvidal at phy.duke.edu  Mon Nov 28 01:48:22 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 27 Nov 2005 20:48:22 -0500
Subject: Yum and SRPMs
In-Reply-To: <20051128014318.GC8556@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
	<1133141834.21208.104.camel@cutter>
	<20051128014318.GC8556@jadzia.bu.edu>
Message-ID: <1133142502.21208.107.camel@cutter>

On Sun, 2005-11-27 at 20:43 -0500, Matthew Miller wrote:
> On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
> > > What if include rpm-build in yum, like apt-build, or apt-get build
> > > does? Maybe yum could become another emerge or pkg_add or so. :p
> > 2 items:
> > 1. why wouldn't we make a yum-devel that handles that sort of thing so
> > we don't have one command with 25 thousand options?
> > 2. We wouldn't want all that building going on as root so it'd be better
> > if that command could do it as a user.
> 
> Hmmm. I'm pretty sure the previous comment was meant as joking actually in
> _support_ of your position. :)

If someone wants to write it - more power to them.

It won't be me, though. :)

-sv




From saddateh at gmail.com  Mon Nov 28 01:48:12 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Sun, 27 Nov 2005 20:48:12 -0500
Subject: Yum and SRPMs
In-Reply-To: <20051128012012.GA8556@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
Message-ID: <fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>

I'm thinking the "yum install --source packagename" would do the following:

1. Download src rpms and dependent libraries required for successfully
rebuilding the requested source download(s)
2. Extract the the source tarball to some standard location so the developer
can cd to that dir and be able to immediately do a ./configure && make
without errors

I agree that having this functionality in yum may not be the best place.
But, since yum already handles dependency resolution, how hard would this
functionality really be to add? I just tried yumdownloader  --source and all
it did was download the src rpm to the current dir and nothing more. This is
one step removed from going to the FTP and downloading the file. I tried
yumdownloader --source yum-utils and it didn't even work. So it's clear
yumdownloader does not have the functionality I desire, nor the
functionality that it probably should have at a bare minimum (that is
finding src equivalents of binary packages).

As for one tool doing one job well (a dogmatic mantra to begin with)...
yum-utils is a 19K RPM. Is this so much code that it couldn't be integrated
into yum? is someone saying the 19K of code is going to destroy yum's
pristine architecture? So beyond actually adding code to yum to download the
src rpm, would adding step 2. be such a conceptual leap for a tool that
probably should have factored in this functionality from its inception?

On 11/27/05, Matthew Miller <mattdm at mattdm.org> wrote:
>
> On Sun, Nov 27, 2005 at 08:17:06PM -0500, Sadda Teh wrote:
> > Now consider the scenario where the developer can yum install --source
> > some-package, and have it install the source along with all the
> dependent
> > source packages. Then he would be able to cd to some dir where he can
> type
> [...]
>
> That's a very long, tragic tale. But what in this story suggests that "yum
> install --source" is so much better than "yumdownloader --source"? Or even
> slightly better?
>
> --
> Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
> Boston University Linux      ------>              <http://linux.bu.edu/>
>
> --
> 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/20051127/ee4e1d42/attachment.htm>

From bbbush.yuan at gmail.com  Mon Nov 28 01:56:39 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Mon, 28 Nov 2005 09:56:39 +0800
Subject: Yum and SRPMs
In-Reply-To: <1133142502.21208.107.camel@cutter>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
	<1133141834.21208.104.camel@cutter>
	<20051128014318.GC8556@jadzia.bu.edu>
	<1133142502.21208.107.camel@cutter>
Message-ID: <76e72f800511271756x5c75c8ceg@mail.gmail.com>

2005/11/28, seth vidal <skvidal at phy.duke.edu>:
> On Sun, 2005-11-27 at 20:43 -0500, Matthew Miller wrote:
> > On Sun, Nov 27, 2005 at 08:37:14PM -0500, seth vidal wrote:
> > > > What if include rpm-build in yum, like apt-build, or apt-get build
> > > > does? Maybe yum could become another emerge or pkg_add or so. :p
> > > 2 items:
> > > 1. why wouldn't we make a yum-devel that handles that sort of thing so
> > > we don't have one command with 25 thousand options?
> > > 2. We wouldn't want all that building going on as root so it'd be better
> > > if that command could do it as a user.
> >
> > Hmmm. I'm pretty sure the previous comment was meant as joking actually in
> > _support_ of your position. :)
>
> If someone wants to write it - more power to them.
>
> It won't be me, though. :)
>
> -sv

not me....

Well what mock can do? I'm going to try that. If the box lacks some
development package that is required by some SRPMS, could mock
download and install them automatically? I think this is more
annoying.

--
bbbush ^_^



From bbbush.yuan at gmail.com  Mon Nov 28 01:58:41 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Mon, 28 Nov 2005 09:58:41 +0800
Subject: Yum and SRPMs
In-Reply-To: <76e72f800511271756x5c75c8ceg@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
	<1133141834.21208.104.camel@cutter>
	<20051128014318.GC8556@jadzia.bu.edu>
	<1133142502.21208.107.camel@cutter>
	<76e72f800511271756x5c75c8ceg@mail.gmail.com>
Message-ID: <76e72f800511271758q15e561a6q@mail.gmail.com>

2005/11/28, Yuan Yijun <bbbush.yuan at gmail.com>:
>
> Well what mock can do? I'm going to try that. If the box lacks some
> development package that is required by some SRPMS, could mock
> download and install them automatically? I think this is more
> annoying.
>

Something like yum localinstall does, but for source rpms.

--
bbbush ^_^



From mattdm at mattdm.org  Mon Nov 28 02:09:08 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 21:09:08 -0500
Subject: Yum and SRPMs
In-Reply-To: <fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
Message-ID: <20051128020908.GA10136@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 08:48:12PM -0500, Sadda Teh wrote:
> 1. Download src rpms and dependent libraries required for successfully
> rebuilding the requested source download(s)
> 2. Extract the the source tarball to some standard location so the developer
> can cd to that dir and be able to immediately do a ./configure && make
> without errors

Why do you assume that there's a source tarball at all? I think if you'll
look at what's inside a lot of source RPMs, you'll find your #2 is a lot
harder than you think.

#1 is also harder than it may appear at first glance. However, there's been
some good work at addressing it. Check out "mock":
<http://fedoraproject.org/wiki/Projects/Mock>

But for #1: what you want is "mock".

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From n0dalus+redhat at gmail.com  Mon Nov 28 02:20:59 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Mon, 28 Nov 2005 12:50:59 +1030
Subject: Yum and SRPMs
In-Reply-To: <20051128004935.GA7617@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<20051128004935.GA7617@jadzia.bu.edu>
Message-ID: <6280325c0511271820i56da1d01kdad2496e9c58d124@mail.gmail.com>

On 11/28/05, Matthew Miller <mattdm at mattdm.org> wrote:
> On Mon, Nov 28, 2005 at 01:40:15AM +0100, Paul Wouters wrote:
> > Do you think there is a fundamental problem with people being able to get
> > the sources easilly? Is yum fundamentally flawed for this? Is it too much
> > work to put in yum?
> > We might appreciate decisions better if we know why they are made in a
> > certain way.
>
> It's been discussed over and over; that's why Seth is being so abrupt. The
> archives to this list and the yum list are public, so you can certainly find
> out why they've been made.
>
> The short answer is that it violates the principle of "do one thing and do
> it well". Adding features like this clutters up yum's interface, not to
> mention the internal code. Having it separate is cleaner.
>

I did several searches in the archives (at gmane) but was unable to
find anything... I guess I should have tried the yum list. I didn't it
existed at the time though.
I would like to add one thing to this discussion, and that is a quote
from the GNU GPL:
"If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code."

Notice "offering equivalent access to copy the source code from the
same place". I'm not trying to say or imply that anything is violating
the GPL here, but I think some users expect this equivalent access to
mean that it's just as easy to get the source rpms. And I think the
designated 'place' here is yum.
In this essence I do not think this is outside of Fedora or yum's goals.

I am happy to accept a 'no' answer though, and thanks for your time.

n0dalus.



From paul at cypherpunks.ca  Mon Nov 28 02:27:26 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 28 Nov 2005 03:27:26 +0100 (CET)
Subject: Yum and SRPMs
In-Reply-To: <76e72f800511271756x5c75c8ceg@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<76e72f800511271726rb470fd0m@mail.gmail.com>
	<1133141834.21208.104.camel@cutter>
	<20051128014318.GC8556@jadzia.bu.edu>
	<1133142502.21208.107.camel@cutter>
	<76e72f800511271756x5c75c8ceg@mail.gmail.com>
Message-ID: <Pine.LNX.4.63.0511280322590.11604@tla.xelerance.com>

On Mon, 28 Nov 2005, Yuan Yijun wrote:

> Well what mock can do? I'm going to try that. If the box lacks some
> development package that is required by some SRPMS, could mock
> download and install them automatically? I think this is more
> annoying.

All I asked for was a simple way to download source package and install
them.

I don't think it should do more. Running rpmbuild will show you the
dependancies misisng, and those can be 'yum install'ed.

I wasn't looking for some IDE. I was looking for a method to install a
source rpm without manually needing to use ftp. It seemed yum would be
a good candidate for that, as people expect it in the package manager,
and not in some additional package.

In fact, I'd say that rpm-build is currently missing a dependancy on
yumdownloader now :)

yum is a package manager and should install packages, nothing more, but
also nothing less. source packages are packages too.

Paul



From saddateh at gmail.com  Mon Nov 28 02:26:41 2005
From: saddateh at gmail.com (Sadda Teh)
Date: Sun, 27 Nov 2005 21:26:41 -0500
Subject: Yum and SRPMs
In-Reply-To: <20051128020908.GA10136@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<20051128020908.GA10136@jadzia.bu.edu>
Message-ID: <fc33c1550511271826g75cc6630j90f00b5d8181172e@mail.gmail.com>

Okay, thanks. So I guess whether or not this functionality goes into yum or
not (to me it seems to be the most intuitive place) is irrelevant. What is
important is that there is a tool available that does my 2 steps. Might mock
be enhanced to be that tool?

Either way, I think it would be great if the tools for src rpms were just as
powerful as those for binary rpms. I understand I'm probably looking over
many factors which prevent simple solutions to some of the problems
mentioned, but I'm sure the problems are worth solving for the reasons I
outlined in my "long, tragic tale" :).

On 11/27/05, Matthew Miller <mattdm at mattdm.org> wrote:
>
> On Sun, Nov 27, 2005 at 08:48:12PM -0500, Sadda Teh wrote:
> > 1. Download src rpms and dependent libraries required for successfully
> > rebuilding the requested source download(s)
> > 2. Extract the the source tarball to some standard location so the
> developer
> > can cd to that dir and be able to immediately do a ./configure && make
> > without errors
>
> Why do you assume that there's a source tarball at all? I think if you'll
> look at what's inside a lot of source RPMs, you'll find your #2 is a lot
> harder than you think.
>
> #1 is also harder than it may appear at first glance. However, there's
> been
> some good work at addressing it. Check out "mock":
> <http://fedoraproject.org/wiki/Projects/Mock>
>
> But for #1: what you want is "mock".
>
> --
> Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
> Boston University Linux      ------>              <http://linux.bu.edu/>
>
> --
> 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/20051127/5640c577/attachment.htm>

From mattdm at mattdm.org  Mon Nov 28 02:29:28 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 21:29:28 -0500
Subject: Yum and SRPMs
In-Reply-To: <6280325c0511271820i56da1d01kdad2496e9c58d124@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<20051128004935.GA7617@jadzia.bu.edu>
	<6280325c0511271820i56da1d01kdad2496e9c58d124@mail.gmail.com>
Message-ID: <20051128022928.GA11356@jadzia.bu.edu>

On Mon, Nov 28, 2005 at 12:50:59PM +1030, n0dalus wrote:
> Notice "offering equivalent access to copy the source code from the
> same place". I'm not trying to say or imply that anything is violating
> the GPL here, but I think some users expect this equivalent access to
> mean that it's just as easy to get the source rpms. And I think the
> designated 'place' here is yum.

I've thought about this too, especially as things like "oh, the repo is
actually provided via HTTP" become near-invisible (which is both inevitable
and good as the infrastructure gets better). But I think having yum-utils
able to do the job satisfies the issue quite nicely. It uses the exact same
infrastructure, after all.

When, in the future, yum GUI tools become so good that most users don't even
consider the command-line version, those GUI tools should consider this too,
not just for the sake of hewing to a particular strong interpretation of the
GPL, but because source access is an important part of the free software /
open source culture, and it shouldn't be a buried secret option.


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Mon Nov 28 02:36:15 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Sun, 27 Nov 2005 21:36:15 -0500
Subject: Yum and SRPMs
In-Reply-To: <fc33c1550511271826g75cc6630j90f00b5d8181172e@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<20051128020908.GA10136@jadzia.bu.edu>
	<fc33c1550511271826g75cc6630j90f00b5d8181172e@mail.gmail.com>
Message-ID: <20051128023615.GB11356@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 09:26:41PM -0500, Sadda Teh wrote:
> Okay, thanks. So I guess whether or not this functionality goes into yum or
> not (to me it seems to be the most intuitive place) is irrelevant. What is
> important is that there is a tool available that does my 2 steps. Might mock
> be enhanced to be that tool?

Its documentation definitely needs to be enhanced. Other than that....

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From shiva at sewingwitch.com  Mon Nov 28 04:32:01 2005
From: shiva at sewingwitch.com (Kenneth Porter)
Date: Sun, 27 Nov 2005 20:32:01 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133107252.9749.394.camel@dimi.lattica.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<1133107252.9749.394.camel@dimi.lattica.com>
Message-ID: <156C4A0E98D77ACC7A318099@[10.0.0.14]>

--On Sunday, November 27, 2005 11:00 AM -0500 Dimi Paun <dimi at lattica.com> 
wrote:

> it is the base of RHEL

This is really the first statement I've seen that looks like a useful 
guideline, albeit an indirect one. If Fedora is to be the next RHEL, then 
we just need to look at the requirements for RHEL to know how Core and 
Extras gets split.




From rc040203 at freenet.de  Mon Nov 28 05:43:39 2005
From: rc040203 at freenet.de (Ralf Corsepius)
Date: Mon, 28 Nov 2005 06:43:39 +0100
Subject: Yum and SRPMs
In-Reply-To: <20051128004935.GA7617@jadzia.bu.edu>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<20051128004935.GA7617@jadzia.bu.edu>
Message-ID: <1133156619.28831.56.camel@mccallum.corsepiu.local>

On Sun, 2005-11-27 at 19:49 -0500, Matthew Miller wrote:

> The short answer is that it violates the principle of "do one thing and do
> it well". Adding features like this clutters up yum's interface, not to
> mention the internal code. Having it separate is cleaner.
I disagree. If being properly implemented, a "get srpms" operation would
be a yum-library feature.

Whether to make such a functionality accessible to users as part of the
"yum"-application or as a separate tool is a matter of taste. The effort
of implementing both cases, would be almost identical.

However, refusing to implement such an (IMO) essential core-feature as
part of yum-libs and wanting to push it to external packages (IMO) is
not a wise decision.

Ralf




From jkeating at j2solutions.net  Mon Nov 28 06:06:52 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Sun, 27 Nov 2005 22:06:52 -0800
Subject: suggestion: move all java packages to extras
In-Reply-To: <156C4A0E98D77ACC7A318099@[10.0.0.14]>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<1133107252.9749.394.camel@dimi.lattica.com>
	<156C4A0E98D77ACC7A318099@[10.0.0.14]>
Message-ID: <1133158012.2833.16.camel@yoda.loki.me>

On Sun, 2005-11-27 at 20:32 -0800, Kenneth Porter wrote:
> This is really the first statement I've seen that looks like a useful 
> guideline, albeit an indirect one. If Fedora is to be the next RHEL, then 
> we just need to look at the requirements for RHEL to know how Core and 
> Extras gets split.

Except for the fact that RHEL can include content from Extras.  The
Fedora -> RHEL used to be a guideline that governs what went into core
and what went into extras.  Now that RHEL can consist of Extras content,
this is no longer a hindrance.  In reality, we could move say... KDE to
extras, and RHEL will still be able to ship KDE with it's next version.

I know i'm not the only one that would like to see KDE in extras, but
there are a lot of people that wouldn't.  So don't start a thread on
this particular subject.  Please use the wiki page that Seth set up.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From sundaram at redhat.com  Mon Nov 28 06:18:48 2005
From: sundaram at redhat.com (Rahul Sundaram)
Date: Mon, 28 Nov 2005 11:48:48 +0530
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133158012.2833.16.camel@yoda.loki.me>
References: <1133019788.17474.24.camel@cutter>	<1133020129.7280.3.camel@shuttle.273piedmont.com>	<1133020624.17474.30.camel@cutter>	<1133021081.2860.97.camel@bree.local.net>	<1133021599.17474.43.camel@cutter>	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>	<17289.50324.181961.701343@localhost.localdomain>	<1133107252.9749.394.camel@dimi.lattica.com>	<156C4A0E98D77ACC7A318099@[10.0.0.14]>
	<1133158012.2833.16.camel@yoda.loki.me>
Message-ID: <438AA148.6040103@redhat.com>

Hi

>I know i'm not the only one that would like to see KDE in extras, but
>there are a lot of people that wouldn't.  So don't start a thread on
>this particular subject.  Please use the wiki page that Seth set up.
>
>  
>
Wiki page: http://fedoraproject.org/wiki/CoreBrainStorm. If you need 
edit group access, ask anyone in it already or join #fedora-websites.

More details at http://fedoraproject.org/wiki/WikiEditing

regards
Rahul



From skvidal at phy.duke.edu  Mon Nov 28 06:36:36 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 28 Nov 2005 01:36:36 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <438AA148.6040103@redhat.com>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<1133107252.9749.394.camel@dimi.lattica.com>
	<156C4A0E98D77ACC7A318099@[10.0.0.14]>
	<1133158012.2833.16.camel@yoda.loki.me> <438AA148.6040103@redhat.com>
Message-ID: <1133159796.21208.110.camel@cutter>

On Mon, 2005-11-28 at 11:48 +0530, Rahul Sundaram wrote:
> Hi
> 
> >I know i'm not the only one that would like to see KDE in extras, but
> >there are a lot of people that wouldn't.  So don't start a thread on
> >this particular subject.  Please use the wiki page that Seth set up.
> >
> >  
> >
> Wiki page: http://fedoraproject.org/wiki/CoreBrainStorm. If you need 
> edit group access, ask anyone in it already or join #fedora-websites.
> 
> More details at http://fedoraproject.org/wiki/WikiEditing
> 

I think it should probably stick to -maintainers.

-sv




From pmatilai at laiskiainen.org  Mon Nov 28 07:11:58 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 27 Nov 2005 23:11:58 -0800 (PST)
Subject: Yum and SRPMs
In-Reply-To: <fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>

On Sun, 27 Nov 2005, Sadda Teh wrote:

> I'm thinking the "yum install --source packagename" would do the following:
>
> 1. Download src rpms and dependent libraries required for successfully
> rebuilding the requested source download(s)

That's two distinct operations, of which one requires root privileges and 
the other one doesn't. And both of them exist already:
1) yumdownloader --source <packagename>
2) yum-builddep <packagename> (or the just downloaded src.rpm file)

> 2. Extract the the source tarball to some standard location so the developer
> can cd to that dir and be able to immediately do a ./configure && make
> without errors

That's not how you work with source rpm's. With the two above steps you 
can however do 'rpmbuild --rebuild <src.rpm-name>'. Or like others have 
mentioned, use mock for the building part.

> I agree that having this functionality in yum may not be the best place.
> But, since yum already handles dependency resolution, how hard would this
> functionality really be to add? I just tried yumdownloader  --source and all
> it did was download the src rpm to the current dir and nothing more. This is
> one step removed from going to the FTP and downloading the file. I tried
> yumdownloader --source yum-utils and it didn't even work. So it's clear
> yumdownloader does not have the functionality I desire, nor the
> functionality that it probably should have at a bare minimum (that is
> finding src equivalents of binary packages).

"yumdownloader --source yum-utils" wont work out of the box, because the 
default yum setup doesn't include the SRPMS repositories for anything but 
initial core packages. You'll need to add a separate entry to yum.repos.d 
that includes extras SRPMS repo.

 	- Panu -



From paul at cypherpunks.ca  Mon Nov 28 07:26:34 2005
From: paul at cypherpunks.ca (Paul Wouters)
Date: Mon, 28 Nov 2005 08:26:34 +0100 (CET)
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
Message-ID: <Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>

On Sun, 27 Nov 2005, Panu Matilainen wrote:

> "yumdownloader --source yum-utils" wont work out of the box, because the
> default yum setup doesn't include the SRPMS repositories for anything but
> initial core packages. You'll need to add a separate entry to yum.repos.d that
> includes extras SRPMS repo.

That's a bug then. Either the source repo listing should come with yum, or
with yumdownloader.

The whole point of this thread (to me at least) is to fix the problem of
not being able to easilly installing source rpms without a need to go hunt
or edit manual files.

Paul
-- 

"Happiness is never grand"

	--- Mustapha Mond, World Controller (Brave New World)



From pmatilai at laiskiainen.org  Mon Nov 28 07:55:40 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Sun, 27 Nov 2005 23:55:40 -0800 (PST)
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
Message-ID: <Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>

On Mon, 28 Nov 2005, Paul Wouters wrote:

> On Sun, 27 Nov 2005, Panu Matilainen wrote:
>
>> "yumdownloader --source yum-utils" wont work out of the box, because the
>> default yum setup doesn't include the SRPMS repositories for anything but
>> initial core packages. You'll need to add a separate entry to yum.repos.d that
>> includes extras SRPMS repo.
>
> That's a bug then. Either the source repo listing should come with yum, or
> with yumdownloader.
>
> The whole point of this thread (to me at least) is to fix the problem of
> not being able to easilly installing source rpms without a need to go hunt
> or edit manual files.

I'm all for adding extras-src etc source repositories to default yum setup 
but we don't want those to be enabled by default - few people of the 
userbase will ever need them so having them enabled will just waste 
bandwidth and make yum slower. A developer who knows he needs that stuff 
can be reasonably expected to flip enabled = 0 -> 1 in a file or two I 
think :)

 	- Panu -



From che666 at gmail.com  Mon Nov 28 09:13:48 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 28 Nov 2005 10:13:48 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <1132982906.2860.21.camel@bree.local.net>
References: <1132799302.7912.4.camel@tiger>
	<55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
	<1132852511.3748.7.camel@yoda.loki.me>
	<e99d27470511250229x50ad26c5j@mail.gmail.com>
	<1132982906.2860.21.camel@bree.local.net>
Message-ID: <e99d27470511280113q7e289402j@mail.gmail.com>

2005/11/26, Jeremy Katz <katzj at redhat.com>:
> On Fri, 2005-11-25 at 11:29 +0100, Rudolf Kastl wrote:
> > 2005/11/24, Jesse Keating <jkeating at j2solutions.net>:
> > > On Thu, 2005-11-24 at 09:23 +0100, Joachim Frieben wrote:
> > > > "up2date-gnome" is by far the most usable update tool to date.
> > > > "pup" is really not on par in any respect. I really have no
> > > > idea why people spent time on that one. The best would be to
> > > > simply remove it. I do really hope that "up2date-gnome" will
> > > > remain in the distro. If it uses "yum" under the hood that's
> > > > ok. Concerning "rhn-applet" your right: it is already unusable
> > > > in FC4. No reason to drop it though. It should get fixed unless
> > > > somebody comes up with an alternative shiny new update notifier.
> > > >
> > >
> > > Would you care to give some constructive feed back as to why you find
> > > pup so intolerable in it's first release version?  What about
> > > up2date-gnome did you like and would like to see in the standalone pup?
> > Feature Requests for pup:
> >
> > 1. Handling of Packagegroups for Groupwise updating
>
> pup is going to be a very simple update UI -- group handling is more of
> system-config-package's area and the plan is for it to be enhanced to
> sit on top of yum as well.  That's actually my plan of what I'm mostly
> working on next week.

hmm. that means that there are 2 different uis regarding package
management? i am not sure if it makes too much sense to split up a
"package installer" and a "package updater" cause both are just uis
for yum. Handling the whole packagemanagement from (maybe even one) UI
would be great.
Question there is how system-config-package will work actually. is it
going to prompt for the cds? what happens if the system is already
updated and installing from cds doesent work really? is there an
option to kinda install "updated packages" ? will groups from extras
or 3rd party repos also be listed? (dynamically reading and merging
groups via yum from repos?!).

>
> > 2. Notification applet (maybe as external application may as internal
> > feature... guess external would be preferred)
>
> Yeah, some form of notification on new updates is definitely needed,
> although exactly how we want to do that is currently a bit of an open
> question.  The big thing is that we want to avoid some of the memory
> usage "problems" that people perceived with rhn-applet
>
> > 3. Repository Handling from UI (i liked the up2date behaviour to
> > selectively enable and disable repos)
>
> I'm not against this (the glade file actually has the button to bring up
> such a dialog, it's just not currently enabled), but I'm mostly curious
> what the use case is for it.  Why would you not want to get the
> available updates for all configured repositories?  I can see wanting to
> configure what repositories you use for getting software when installing
> new stuff, but what's the use case for doing it while updating?

use case: i am working alot with various repositorys, different
configurations etc... its useful for advanced users, including my own
repo. actually yum has this feature aswell because its a cli option.
same use cases basically as for the cli option.

>
> > 4. selectivly exluding packages by gui (clickable list with checkbox
> > buttons maybe?)
>
> You can currently exclude based on src.rpm -- hopefully we'll get
> metadata regarding update advisories available before FC5's release so
> that can be used as the granularity instead.  This is far more likely to
> allow things to just work than selecting individual subpackages (and/or
> architectures) of packages due to the interdependent nature.

use case: broken rawhide installs/updates on x86_64 e.g. ;))

>
> > 5. all of the above stuff saveable into yum config files to have a
> > consistent environment.
>
> Anything we do as far repository changing will definitely involve just
> modifying the existing yum config files, so no worries there.  In fact,
> everything done now in pup should be following exactly the configuration
> used by yum on the command-line.

thats great.

>
> > while i think that most of above suggestions arent really necassery
> > for even an 1.0 release of the software and while i additionally think
> > that some of the above stuff should probably go under an "advanced"
> > tab, i think that some of the above mentioned stuff can be helpful to
> > make package updates properly manageable from gui.
>
> Hope this helps a bit in giving some idea of where we're going.  I need
> to make an effort this weekend to sit down and actually write up at
> least some basic stuff to be able to point to as some of these questions
> have come up often enough that I want to be able to just point to a web
> page with the answers :-)

yup, might be helpful.

>
> Jeremy
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From che666 at gmail.com  Mon Nov 28 10:03:36 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 28 Nov 2005 11:03:36 +0100
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133105752.2853.14.camel@laptopd505.fenrus.org>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
Message-ID: <e99d27470511280203mc33589bs@mail.gmail.com>

2005/11/27, Arjan van de Ven <arjan at fenrus.demon.nl>:
> On Sun, 2005-11-27 at 10:10 -0500, Matthew Miller wrote:
> > On Sun, Nov 27, 2005 at 07:37:08AM -0700, Tom Tromey wrote:
> > > I don't doubt this.  However implicit in this is some idea of what the
> > > target Fedora Core user looks like -- some kind of user profile.  I
> > > think the goal of this thread is to make this idea explicit.
> > > Are we targeting developers?  Corporate desktop users?  People who
> > > travel a lot?  People setting up LAMP servers?  Some combination?
> >
> > I'm for going all the way -- it should contain no end-user applications,
> > just the framework for making those applications run. C'mon, let's make Core
> > be just that.
>
> actually I tend to disagree, not sure how much say I should have in this
> though.
>
> I think of it as an union model, where each layer is both self-contained
> in terms of package dependencies but also in the requirements it
> fulfills in terms of user/market.

interesting thought.

>
> eg
>
> layer 0 of the union
> "base" - minimum set to get the machine booting and operating

thats what we call "minimum install" right? ;)

>
> layer 1 of the union
> "core" - set of functionality people expect from a consumer oriented
> linux distro

i agree here aswell. this should include everything that is needed for
a regular end user to do the daily trivial tasks. from an instant
messaging/irc client to a web browser for adding bugzilla entrys and
find help/info on the net.

>
> layer 2 of the union
> "extras" - more "obscure" functionality for example because it's a
> relatively small userbase but also because it can be new and emerging
> things. In addition this can be alternative implementations to core
> functionality. An example of this could be wu-ftpd or xfce or ..

in my experience before stuff comes there usually its been in a higher
layer before and got some love there already.

>
> layer 3 of the union
> "dedicated repos" - very specialist repositories that each target what
> is pretty much a niche market and who's requirements are very different
> or unique but isolated. Examples could be a beowulf repo, or a "video
> montage" repo.

i see that new stuff can be plain pushed faster with "specialist
repos" also as the name you gave it already implies there are people
dedicated to the certain task working on it, which also implies that
those people really "use" the tools they package. thats not
necasserily true with the lower layers. Its a good way to get stuff
ready for a lower layer if specialists of a certain task help with
getting the upstream work going.

>
> again, for me it's essential that each layer of the union is
> self-contained in terms of packages (eg no dependencies to higher
> layers, lower layers is of course ok) and of functionality (eg if a
> layer contains a certain functionality, it should contain in a general
> useful matter. this doesn't mean that all optional things should be
> there, but enough functionality that most people expect should be
> there).
>
> For me the difference between layer 2 and 3 is also a "market segment"
> one. Some things will be so specialist that it's better to have a few
> experts have their own repo that they maintain as a coherent add-on
> function than lumping it all in one big repo.

Well theres a huge difference in my eyes between plain rolling a
current state to rpm and pushing necassery changes and improvements
upstream while beeing in the process of creating a real good solution
for a task. so yes... "task forces" make definitely sense.

regards,
Rudolf Kastl

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From benny+usenet at amorsen.dk  Mon Nov 28 09:57:48 2005
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: 28 Nov 2005 10:57:48 +0100
Subject: status of up2date and rhn-applet
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
Message-ID: <m364qdw0v7.fsf@ursa.amorsen.dk>

>>>>> "WR" == Willem Riede <wrrhdev at riede.org> writes:

WR> Maybe I shouldn't care, but I do. As an example, with all due
WR> respect to its creator, the atrpms repository holds both packages
WR> I want (unique functionality) and that I don't want (core
WR> replacements). Unfortunately that means I can never do a blind
WR> cross-the-board upgrade from all the sources I've identified.

It would be very nice if one of the update utilities could be set to
ignore updates across repositories. I.e. if I've installed foo from
core and bar from atrpms and atrpms has newer versions of both foo and
bar, only bar gets updated.


/Benny




From laroche at redhat.com  Mon Nov 28 10:54:10 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 28 Nov 2005 11:54:10 +0100
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
Message-ID: <20051128105410.GA5425@dudweiler.stuttgart.redhat.com>

On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
> On Sun, 27 Nov 2005, Panu Matilainen wrote:
> 
> > "yumdownloader --source yum-utils" wont work out of the box, because the
> > default yum setup doesn't include the SRPMS repositories for anything but
> > initial core packages. You'll need to add a separate entry to yum.repos.d that
> > includes extras SRPMS repo.
> 
> That's a bug then. Either the source repo listing should come with yum, or
> with yumdownloader.

Having all src.rpms in the repodata is also adding quite some time to
xml processing. So moving them into separate repos does make some sense.
Also having e.g. one src.rpm repo for all arches is also good.

regards,

Florian La Roche



From fedora at camperquake.de  Mon Nov 28 11:08:28 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 28 Nov 2005 12:08:28 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <m364qdw0v7.fsf@ursa.amorsen.dk>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
Message-ID: <20051128110828.GA16912@ryoko.camperquake.de>

On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote:

> It would be very nice if one of the update utilities could be set to
> ignore updates across repositories. I.e. if I've installed foo from
> core and bar from atrpms and atrpms has newer versions of both foo and
> bar, only bar gets updated.

smart can do exactly that.



From buildsys at redhat.com  Mon Nov 28 11:29:55 2005
From: buildsys at redhat.com (Build System)
Date: Mon, 28 Nov 2005 06:29:55 -0500
Subject: rawhide report: 20051128 changes
Message-ID: <200511281129.jASBTtBB017991@porkchop.devel.redhat.com>

 

 
Updated Packages:

(none)
Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11









Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5





From laroche at redhat.com  Mon Nov 28 11:33:29 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 28 Nov 2005 12:33:29 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128110828.GA16912@ryoko.camperquake.de>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
Message-ID: <20051128113329.GA5698@dudweiler.stuttgart.redhat.com>

On Mon, Nov 28, 2005 at 12:08:28PM +0100, Ralf Ertzinger wrote:
> On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote:
> 
> > It would be very nice if one of the update utilities could be set to
> > ignore updates across repositories. I.e. if I've installed foo from
> > core and bar from atrpms and atrpms has newer versions of both foo and
> > bar, only bar gets updated.
> 
> smart can do exactly that.

You can use the sha/md5sum digest info to match between the rpms
installed in rpmdb (/var/lib/rpm/) and the rpm packages from the
repositories. This will only work if the repos still have the older
rpms listed though.
Is smart storing addon information in its own database?

regards,

Florian La Roche



From fedora at camperquake.de  Mon Nov 28 11:39:22 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 28 Nov 2005 12:39:22 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
Message-ID: <20051128113922.GB16912@ryoko.camperquake.de>

On Mon, Nov 28, 2005 at 12:33:29PM +0100, Florian La Roche wrote:

> You can use the sha/md5sum digest info to match between the rpms
> installed in rpmdb (/var/lib/rpm/) and the rpm packages from the
> repositories. This will only work if the repos still have the older
> rpms listed though.
> Is smart storing addon information in its own database?

smart employs scoring, on a package and on a repository basis. Score
external repositories lower than FC/FE, and you will get no replacements
of Core/Extra packages.

Yes, there are cases where this does not work as intended.



From laroche at redhat.com  Mon Nov 28 11:53:07 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 28 Nov 2005 12:53:07 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128113922.GB16912@ryoko.camperquake.de>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
	<20051128113922.GB16912@ryoko.camperquake.de>
Message-ID: <20051128115307.GA6055@dudweiler.stuttgart.redhat.com>

On Mon, Nov 28, 2005 at 12:39:22PM +0100, Ralf Ertzinger wrote:
> On Mon, Nov 28, 2005 at 12:33:29PM +0100, Florian La Roche wrote:
> 
> > You can use the sha/md5sum digest info to match between the rpms
> > installed in rpmdb (/var/lib/rpm/) and the rpm packages from the
> > repositories. This will only work if the repos still have the older
> > rpms listed though.
> > Is smart storing addon information in its own database?
> 
> smart employs scoring, on a package and on a repository basis. Score
> external repositories lower than FC/FE, and you will get no replacements
> of Core/Extra packages.
> 
> Yes, there are cases where this does not work as intended.

Ok, that should be possible to implement with repodata handling,
but then you don't keep a package within a lower score repo, but
will update it again to FC/FE level if newer packages show up there, right?

Good we now have Fedora Extras, work on the boundaries to Fedora Core
and try to keep the repo sane. Implementing all possible ideas on how
to update systems with (broken) repos is a difficult task. ;-)
I am still for adding a few warnings or giving guidance to users if the
checks are relatively easy todo.

greetings,

Florian La Roche



From fedora at camperquake.de  Mon Nov 28 12:00:38 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 28 Nov 2005 13:00:38 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128115307.GA6055@dudweiler.stuttgart.redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
	<20051128113922.GB16912@ryoko.camperquake.de>
	<20051128115307.GA6055@dudweiler.stuttgart.redhat.com>
Message-ID: <20051128120038.GD16912@ryoko.camperquake.de>

On Mon, Nov 28, 2005 at 12:53:07PM +0100, Florian La Roche wrote:

> Ok, that should be possible to implement with repodata handling,
> but then you don't keep a package within a lower score repo, but
> will update it again to FC/FE level if newer packages show up there, right?

I am very sorry, but my english parser does not get that. Care to rephrase
it a bit?



From che666 at gmail.com  Mon Nov 28 12:36:28 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 28 Nov 2005 13:36:28 +0100
Subject: Yum and SRPMs
In-Reply-To: <20051128105410.GA5425@dudweiler.stuttgart.redhat.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<20051128105410.GA5425@dudweiler.stuttgart.redhat.com>
Message-ID: <e99d27470511280436u557fa383r@mail.gmail.com>

2005/11/28, Florian La Roche <laroche at redhat.com>:
> On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
> > On Sun, 27 Nov 2005, Panu Matilainen wrote:
> >
> > > "yumdownloader --source yum-utils" wont work out of the box, because the
> > > default yum setup doesn't include the SRPMS repositories for anything but
> > > initial core packages. You'll need to add a separate entry to yum.repos.d that
> > > includes extras SRPMS repo.
> >
> > That's a bug then. Either the source repo listing should come with yum, or
> > with yumdownloader.
>
> Having all src.rpms in the repodata is also adding quite some time to
> xml processing. So moving them into separate repos does make some sense.
> Also having e.g. one src.rpm repo for all arches is also good.
>
> regards,
>
> Florian La Roche
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

i am just curious... whats the point of "installing" source rpms?
usually one just wants to fetch em and extract em into the userspace
not systemspace. actually usually packages are built using a
"userbuild environment". the regular way installation of rpms work is
to install em "globally" and therefor encourage the user/developer to
build the stuff as "root user".

regards,
Rudolf Kastl

p.s. id be happy if yumdownloader --source dosbox would work for me.
it doesent see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173322



From fedora at camperquake.de  Mon Nov 28 12:41:30 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 28 Nov 2005 13:41:30 +0100
Subject: Yum and SRPMs
In-Reply-To: <e99d27470511280436u557fa383r@mail.gmail.com>
References: <6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<20051128105410.GA5425@dudweiler.stuttgart.redhat.com>
	<e99d27470511280436u557fa383r@mail.gmail.com>
Message-ID: <20051128124130.GE16912@ryoko.camperquake.de>

On Mon, Nov 28, 2005 at 01:36:28PM +0100, Rudolf Kastl wrote:

> i am just curious... whats the point of "installing" source rpms?
> usually one just wants to fetch em and extract em into the userspace
> not systemspace.

That's installing in my book. I quite often find myself going though
the "find latest version, find suitable mirror, wget srpm, rpm -i" routine
when trying to track down a bug in a package.

This should definitely work from a non-root account, thus is another point
against integrating this in yum directly.



From mattdm at mattdm.org  Mon Nov 28 12:44:43 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 28 Nov 2005 07:44:43 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
References: <6280325c0511262343u27dd23f3h59ce2d3ef1584772@mail.gmail.com>
	<1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
Message-ID: <20051128124443.GA29992@jadzia.bu.edu>

On Mon, Nov 28, 2005 at 08:26:34AM +0100, Paul Wouters wrote:
> > "yumdownloader --source yum-utils" wont work out of the box, because the
> > default yum setup doesn't include the SRPMS repositories for anything
> > but initial core packages. You'll need to add a separate entry to
> > yum.repos.d that includes extras SRPMS repo.
> That's a bug then. Either the source repo listing should come with yum, or
> with yumdownloader.

No. It's a bug, but not in yum or yum-utils -- it's a problem with the
repository config, which belongs to fedora-release.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Mon Nov 28 12:46:49 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 28 Nov 2005 07:46:49 -0500
Subject: Yum and SRPMs
In-Reply-To: <Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
References: <1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
Message-ID: <20051128124649.GB29992@jadzia.bu.edu>

On Sun, Nov 27, 2005 at 11:55:40PM -0800, Panu Matilainen wrote:
> I'm all for adding extras-src etc source repositories to default yum setup 
> but we don't want those to be enabled by default - few people of the 
> userbase will ever need them so having them enabled will just waste 
> bandwidth and make yum slower. A developer who knows he needs that stuff 
> can be reasonably expected to flip enabled = 0 -> 1 in a file or two I 
> think :)

This does raise a good point though -- since core yum can't even deal with
src.rpms, shouldn't there be an easy way to tag source rpm repo config files
so yum ignores them but that they're _all_ yumdownloader --source looks at?


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From laroche at redhat.com  Mon Nov 28 12:55:20 2005
From: laroche at redhat.com (Florian La Roche)
Date: Mon, 28 Nov 2005 13:55:20 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128120038.GD16912@ryoko.camperquake.de>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
	<20051128113922.GB16912@ryoko.camperquake.de>
	<20051128115307.GA6055@dudweiler.stuttgart.redhat.com>
	<20051128120038.GD16912@ryoko.camperquake.de>
Message-ID: <20051128125520.GA6416@dudweiler.stuttgart.redhat.com>

On Mon, Nov 28, 2005 at 01:00:38PM +0100, Ralf Ertzinger wrote:
> On Mon, Nov 28, 2005 at 12:53:07PM +0100, Florian La Roche wrote:
> 
> > Ok, that should be possible to implement with repodata handling,
> > but then you don't keep a package within a lower score repo, but
> > will update it again to FC/FE level if newer packages show up there, right?
> 
> I am very sorry, but my english parser does not get that. Care to rephrase
> it a bit?

Ok to add scoring for repositories, but that does not help at all on how
to keep an installed rpm to be updated only from one specific repository.
You need to store that information somewhere, only scoring for repos is
not enough.

regards,

Florian La Roche



From fedora at camperquake.de  Mon Nov 28 13:09:49 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Mon, 28 Nov 2005 14:09:49 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128125520.GA6416@dudweiler.stuttgart.redhat.com>
References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
	<20051128113922.GB16912@ryoko.camperquake.de>
	<20051128115307.GA6055@dudweiler.stuttgart.redhat.com>
	<20051128120038.GD16912@ryoko.camperquake.de>
	<20051128125520.GA6416@dudweiler.stuttgart.redhat.com>
Message-ID: <20051128130949.GF16912@ryoko.camperquake.de>

On Mon, Nov 28, 2005 at 01:55:20PM +0100, Florian La Roche wrote:

> Ok to add scoring for repositories, but that does not help at all on how
> to keep an installed rpm to be updated only from one specific repository.
> You need to store that information somewhere, only scoring for repos is
> not enough.
 
Yes, that's right.



From che666 at gmail.com  Mon Nov 28 13:12:19 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 28 Nov 2005 14:12:19 +0100
Subject: Yum and SRPMs
In-Reply-To: <20051128124130.GE16912@ryoko.camperquake.de>
References: <6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<20051128105410.GA5425@dudweiler.stuttgart.redhat.com>
	<e99d27470511280436u557fa383r@mail.gmail.com>
	<20051128124130.GE16912@ryoko.camperquake.de>
Message-ID: <e99d27470511280512r9cdda1er@mail.gmail.com>

2005/11/28, Ralf Ertzinger <fedora at camperquake.de>:
> On Mon, Nov 28, 2005 at 01:36:28PM +0100, Rudolf Kastl wrote:
>
> > i am just curious... whats the point of "installing" source rpms?
> > usually one just wants to fetch em and extract em into the userspace
> > not systemspace.
>
> That's installing in my book. I quite often find myself going though
> the "find latest version, find suitable mirror, wget srpm, rpm -i" routine
> when trying to track down a bug in a package.

well ok but i was always against the rpm -i bleh.src.rpm foo ;) in my
eyes it just doesent make sense at all to "install" src rpms. it makes
sense to extract em and ready em for build though. while its the same
in some sense its not in another ;).

you got exactly the same use case as me! *grins*! how come? ;)

>
> This should definitely work from a non-root account, thus is another point
> against integrating this in yum directly.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From skvidal at phy.duke.edu  Mon Nov 28 13:47:34 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 28 Nov 2005 08:47:34 -0500
Subject: Yum and SRPMs
In-Reply-To: <20051128124649.GB29992@jadzia.bu.edu>
References: <1133079326.2854.1.camel@entropy>
	<6280325c0511270032r7a8533f3la7dd53a88c9b344b@mail.gmail.com>
	<1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
Message-ID: <1133185654.21208.124.camel@cutter>

On Mon, 2005-11-28 at 07:46 -0500, Matthew Miller wrote:
> On Sun, Nov 27, 2005 at 11:55:40PM -0800, Panu Matilainen wrote:
> > I'm all for adding extras-src etc source repositories to default yum setup 
> > but we don't want those to be enabled by default - few people of the 
> > userbase will ever need them so having them enabled will just waste 
> > bandwidth and make yum slower. A developer who knows he needs that stuff 
> > can be reasonably expected to flip enabled = 0 -> 1 in a file or two I 
> > think :)
> 
> This does raise a good point though -- since core yum can't even deal with
> src.rpms, shouldn't there be an easy way to tag source rpm repo config files
> so yum ignores them but that they're _all_ yumdownloader --source looks at?
> 

we'd need another config item per repo to distinguish source-only repos
from others. Yes, that's doable but is it worth it?

-sv






From mattdm at mattdm.org  Mon Nov 28 14:01:28 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 28 Nov 2005 09:01:28 -0500
Subject: Yum and SRPMs
In-Reply-To: <1133185654.21208.124.camel@cutter>
References: <1133103767.21208.0.camel@cutter>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
Message-ID: <20051128140128.GA32165@jadzia.bu.edu>

On Mon, Nov 28, 2005 at 08:47:34AM -0500, seth vidal wrote:
> > This does raise a good point though -- since core yum can't even deal
> > with src.rpms, shouldn't there be an easy way to tag source rpm repo
> > config files so yum ignores them but that they're _all_ yumdownloader
> > --source looks at?
> we'd need another config item per repo to distinguish source-only repos
> from others. Yes, that's doable but is it worth it?

Since currently, enabling source rpm repos causes yum to repeatedly do a lot
of work for no reason, it seems like a pretty decent thing.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From n0dalus+redhat at gmail.com  Mon Nov 28 15:03:20 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Tue, 29 Nov 2005 01:33:20 +1030
Subject: Yum and SRPMs
In-Reply-To: <1133185654.21208.124.camel@cutter>
References: <1133079326.2854.1.camel@entropy>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
Message-ID: <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>

On 11/29/05, seth vidal <skvidal at phy.duke.edu> wrote:
>
> we'd need another config item per repo to distinguish source-only repos
> from others. Yes, that's doable but is it worth it?
>
> -sv
>

In the primary.xml files, there is a '<rpm:sourcerpm>' tag; would that
be usable at all to install srouce rpms or do you need the whole
<package> with <arch>src</arch> like in core?

n0dalus.



From skvidal at phy.duke.edu  Mon Nov 28 15:09:40 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 28 Nov 2005 10:09:40 -0500
Subject: Yum and SRPMs
In-Reply-To: <6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
References: <1133079326.2854.1.camel@entropy>
	<Pine.LNX.4.63.0511280138020.11604@tla.xelerance.com>
	<fc33c1550511271717s7ac170f1hf51a3fc289167469@mail.gmail.com>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
Message-ID: <1133190580.6952.0.camel@cutter>

On Tue, 2005-11-29 at 01:33 +1030, n0dalus wrote:
> On 11/29/05, seth vidal <skvidal at phy.duke.edu> wrote:
> >
> > we'd need another config item per repo to distinguish source-only repos
> > from others. Yes, that's doable but is it worth it?
> >
> > -sv
> >
> 
> In the primary.xml files, there is a '<rpm:sourcerpm>' tag; would that
> be usable at all to install srouce rpms or do you need the whole
> <package> with <arch>src</arch> like in core?

we need the whole path to the src.rpm and we need some way of
distinguishing the types of repo BEFORE reading in the metadata.

-sv




From jspaleta at gmail.com  Mon Nov 28 15:19:21 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 28 Nov 2005 10:19:21 -0500
Subject: Yum and SRPMs
In-Reply-To: <1133190580.6952.0.camel@cutter>
References: <1133079326.2854.1.camel@entropy>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
	<1133190580.6952.0.camel@cutter>
Message-ID: <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>

On 11/28/05, seth vidal <skvidal at phy.duke.edu> wrote:
> we need the whole path to the src.rpm and we need some way of
> distinguishing the types of repo BEFORE reading in the metadata.


But I have to wonder...for yumdownloader and repoquery to work
efficiently it still helps to pull in metadata about the srpm repos
during yum runs.  Out-of-date srpm information isn't particularly
useful.

If the magical mirrorlist and metadata caching makes it into the
default yum configuration...how expensive does retrieving the srpm
metadata become?

At the very least I would certaintly want  yum makecache  to cache all
the enabled repos including enabled srpm information.

I personally don't think its worth trying to turn the srpm parsing
off. Once I enable srpm repos, I benefit more by having the srpm
information cached locally in a state that matches the rpm
information.  What I'm more concerned about is seeing the srpm
information and the binary information come from different mirrors
which are out of sync with each other.

-jef



From che666 at gmail.com  Mon Nov 28 15:38:29 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Mon, 28 Nov 2005 16:38:29 +0100
Subject: lm_sensors in FC4-updates for x86_64 twice?
In-Reply-To: <20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
References: <438886F4.1070607@stefan-neufeind.de>
	<1133021673.17474.46.camel@cutter>
	<20051126215313.GA3920@dudweiler.stuttgart.redhat.com>
Message-ID: <e99d27470511280738h43e2a7c9w@mail.gmail.com>

2005/11/26, Florian La Roche <laroche at redhat.com>:
> > no, I don't want to hear any bitching and moaning about this, that's how
> > it is.
>
> At some point we should change this to only pull in as few packages as
> really needed, but that also comes with quite some calculation cost.
>
> This should really be something where yum, up2date and smart algorithms
> should work together and then implement the best solution available.
>
> regards,
>
> Florian La Roche

nice suggestion in my eyes. actually i also think that the number of
compat packages should be reduced as far as possible. is there really
a reason for lm_sensors compat packages?

i see a point in packaging SDL 32 bit libs as compat libs... but
especially in the past there was lots of seriously unnecassery stuff.
maybe seperate that kinda things into "full 32 bit compat" and
"necassery 32 bit compat" installation methods.

its really nice to run every 32 bit rpm there is... but most users
just need a very small subset of common packages (see SDL .. see the
requirements for wine... see 32 bit browsers and 32 bit movie
players).

lets find the "use cases" ;))

regards,
Rudolf Kastl

>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From skvidal at phy.duke.edu  Mon Nov 28 15:25:23 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 28 Nov 2005 10:25:23 -0500
Subject: Yum and SRPMs
In-Reply-To: <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
References: <1133079326.2854.1.camel@entropy>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
	<1133190580.6952.0.camel@cutter>
	<604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
Message-ID: <1133191523.6952.4.camel@cutter>


> But I have to wonder...for yumdownloader and repoquery to work
> efficiently it still helps to pull in metadata about the srpm repos
> during yum runs.  Out-of-date srpm information isn't particularly
> useful.

why? That's like saying - in order to work efficiently it's best if
firefox cache every page you've ever been to and all of those pages
you've NOT been to, too.


> If the magical mirrorlist and metadata caching makes it into the
> default yum configuration...how expensive does retrieving the srpm
> metadata become?

a little less than double the amount of data.


> At the very least I would certaintly want  yum makecache  to cache all
> the enabled repos including enabled srpm information.

If a source repo is not enabled then it's not enabled. The only thing
marking them as source would do is tell yumdownloader which repos to
enable if someone passed --source to it.


> I personally don't think its worth trying to turn the srpm parsing
> off. Once I enable srpm repos, I benefit more by having the srpm
> information cached locally in a state that matches the rpm
> information.  What I'm more concerned about is seeing the srpm
> information and the binary information come from different mirrors
> which are out of sync with each other.

you're really not understanding what I'm talking about.

-sv




From overholt at redhat.com  Mon Nov 28 15:58:18 2005
From: overholt at redhat.com (Andrew Overholt)
Date: Mon, 28 Nov 2005 10:58:18 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021923.4178.14.camel@localhost.localdomain>
References: <1133019788.17474.24.camel@cutter>
	<20051126154609.GB5854@jadzia.bu.edu>
	<1133020666.17474.34.camel@cutter>
	<1133021923.4178.14.camel@localhost.localdomain>
Message-ID: <20051128155818.GB30307@redhat.com>

* Konstantin Ryabitsev <icon at fedoraproject.org> [2005-11-26 11:19]:
> On Sat, 2005-26-11 at 10:57 -0500, seth vidal wrote:
> 
> [...] you a) can't easily install any of the third-package plugins that
> aren't already packaged into RPMs,

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=90630
Tom Tromey already mentioned the library issue that has been fixed.

> b) can't update the plugins that come from RPMs

Again, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=90630 .  There are
many things to consider here and if you have input, it would be great if
you could comment on that bug.

> so you're stuck with old versions (e.g. a rather dated version of PyDev).

We can't include newer version of PyDev because they depend upon 1.5-level
stuff that we can't build.  Before someone says "use retroweaver", we have
to be able to build the code before we can munge the bytecode so if ecj +
Classpath (ecj may be 1.5-level compatible but if Classpath is missing
something) can't built it to begin with, we can't ship it.

> So, unless you write lots of stuff in gcj-java, Eclipse as provided by
> Fedora would be of limited use.

I don't see how you come to this conclusion.

Andrew



From mpeters at mac.com  Mon Nov 28 16:32:45 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Mon, 28 Nov 2005 08:32:45 -0800
Subject: Slightly OT: Updated RPM building howto?
In-Reply-To: <16de708d0511270032h2efe44feo18e6739a9a364791@mail.gmail.com>
References: <16de708d0511270032h2efe44feo18e6739a9a364791@mail.gmail.com>
Message-ID: <1133195565.21926.28.camel@locolhost.localdomain>

On Sun, 2005-11-27 at 02:32 -0600, Arthur Pemberton wrote:
> Are there any recent HOWTOs around on RPM building? I would really
> like to contribute to Fedora, at least by maintaing packages to
> software that I use regularly on my own FC4 install. However the
> HOWTOs I've found seem busy and complicated. I consider myself to be
> fairly Linux competent, and so I believe that I have the capabilties
> to help.
> 
> Please advise, thank you.

As mentioned - the Fedora Packaging Guidelines are an excellent
resource.

You can also read the Fedora Extras list - and look at the spec files
submitted in the Bugzilla (they are on the extras list) and see the
comments packagers make about them.

The "Red Hat RPM Guide" by Eric Foster-Johnson is an excellent book - a
free version of which I believe is what Aurelien Bompard linked to.

It's a good book.

Best thing to do imho - install fedora-rpmdevtools , take the
spectemplate-minimal.spec and use it as a template to package something
and submit it to extras (referencing the packaging guidelines in the
Extras wiki).

You will also want to install mock - so that you can make sure your
package builds cleanly before submitting.



From pmatilai at laiskiainen.org  Mon Nov 28 16:39:15 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 28 Nov 2005 18:39:15 +0200
Subject: Yum and SRPMs
In-Reply-To: <604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
References: <1133079326.2854.1.camel@entropy>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
	<1133190580.6952.0.camel@cutter>
	<604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
Message-ID: <1133195955.16284.1.camel@weasel.turre.laiskiainen.org>

On Mon, 2005-11-28 at 10:19 -0500, Jeff Spaleta wrote:
> On 11/28/05, seth vidal <skvidal at phy.duke.edu> wrote:
> > we need the whole path to the src.rpm and we need some way of
> > distinguishing the types of repo BEFORE reading in the metadata.
> 
> 
> But I have to wonder...for yumdownloader and repoquery to work
> efficiently it still helps to pull in metadata about the srpm repos
> during yum runs.  Out-of-date srpm information isn't particularly
> useful.
> 
> If the magical mirrorlist and metadata caching makes it into the
> default yum configuration...how expensive does retrieving the srpm
> metadata become?
> 
> At the very least I would certaintly want  yum makecache  to cache all
> the enabled repos including enabled srpm information.


Both yumdownlaoder and repoquery can (and do) use a private per-user
cache when running non-root so the information will be up-to-date,
regardless of the system yum cache state.

	- Panu -




From mpeters at mac.com  Mon Nov 28 16:39:36 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Mon, 28 Nov 2005 08:39:36 -0800
Subject: What about smartpm?
In-Reply-To: <604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<604aa7910511260913v4875001dwb996585d26d9b63f@mail.gmail.com>
	<b80014de0511260956y602e25fega75c4c75610eeb0d@mail.gmail.com>
	<604aa7910511261009t8250c28t33e629b92edac5f2@mail.gmail.com>
Message-ID: <1133195976.21926.35.camel@locolhost.localdomain>

On Sat, 2005-11-26 at 13:09 -0500, Jeff Spaleta wrote:
> On 11/26/05, Deji Akingunola <dakingun at gmail.com> wrote:
> > I remember someone proposed it in the very early days of extras
> > (before the bugzilla system), but no one ever step up to sponsor it,
> > and I guess the contributor got discouraged .
> 
> Please.... find the post me to the post in the fedora-extras-list
> archive where the submission request was made, because I certaintly
> can't find it.

I don't think it ever was in the list - but I do remember under the old
old system, someone had added themselves to the wiki as looking for a
sponsor stating that was something they were interested in maintaining.

AFAIK a spec file was never submitted for review though.

-=-
I personally like smartpm - it had a few quirks in it last time I used
it, but it was good.

I personally don't need it though - it's strength is that it makes it a
little easier to mix repositories by allowing you to set different repos
at different priorities (over-riding version and release) while allowing
you to fine tune it with specific packages.

However, I do not mix repositories anymore - if its not in extras,
either I just build it myself for my private use - or I build it and
submit it. So I don't need what smartpm is particularly good at anymore.



From pmatilai at laiskiainen.org  Mon Nov 28 16:55:01 2005
From: pmatilai at laiskiainen.org (Panu Matilainen)
Date: Mon, 28 Nov 2005 18:55:01 +0200
Subject: Yum and SRPMs
In-Reply-To: <1133195955.16284.1.camel@weasel.turre.laiskiainen.org>
References: <1133079326.2854.1.camel@entropy>
	<20051128012012.GA8556@jadzia.bu.edu>
	<fc33c1550511271748s1e2def05w666388b5fc3fed74@mail.gmail.com>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
	<1133190580.6952.0.camel@cutter>
	<604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
	<1133195955.16284.1.camel@weasel.turre.laiskiainen.org>
Message-ID: <1133196901.16284.6.camel@weasel.turre.laiskiainen.org>

On Mon, 2005-11-28 at 18:39 +0200, Panu Matilainen wrote:
> On Mon, 2005-11-28 at 10:19 -0500, Jeff Spaleta wrote:
> > On 11/28/05, seth vidal <skvidal at phy.duke.edu> wrote:
> > > we need the whole path to the src.rpm and we need some way of
> > > distinguishing the types of repo BEFORE reading in the metadata.
> > 
> > 
> > But I have to wonder...for yumdownloader and repoquery to work
> > efficiently it still helps to pull in metadata about the srpm repos
> > during yum runs.  Out-of-date srpm information isn't particularly
> > useful.
> > 
> > If the magical mirrorlist and metadata caching makes it into the
> > default yum configuration...how expensive does retrieving the srpm
> > metadata become?
> > 
> > At the very least I would certaintly want  yum makecache  to cache all
> > the enabled repos including enabled srpm information.
> 
> 
> Both yumdownlaoder and repoquery can (and do) use a private per-user
> cache when running non-root so the information will be up-to-date,
> regardless of the system yum cache state.

Erm, spoke a bit too soon, yumdownloader hadn't been fixed to use a
private cache yet. It's in cvs head now though :)

	- Panu -



From jspaleta at gmail.com  Mon Nov 28 16:56:26 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Mon, 28 Nov 2005 11:56:26 -0500
Subject: Yum and SRPMs
In-Reply-To: <1133195955.16284.1.camel@weasel.turre.laiskiainen.org>
References: <1133079326.2854.1.camel@entropy>
	<Pine.LNX.4.62.0511272303310.11711@gotcha.dreamhost.com>
	<Pine.LNX.4.63.0511280823420.15794@tla.xelerance.com>
	<Pine.LNX.4.62.0511272352570.23760@gotcha.dreamhost.com>
	<20051128124649.GB29992@jadzia.bu.edu>
	<1133185654.21208.124.camel@cutter>
	<6280325c0511280703v2c514df8p63c31ca9cf06def7@mail.gmail.com>
	<1133190580.6952.0.camel@cutter>
	<604aa7910511280719l59f4921bja4c15e160cfb4e77@mail.gmail.com>
	<1133195955.16284.1.camel@weasel.turre.laiskiainen.org>
Message-ID: <604aa7910511280856g3f043934g4c7da09e83ed181a@mail.gmail.com>

On 11/28/05, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
> Both yumdownlaoder and repoquery can (and do) use a private per-user
> cache when running non-root so the information will be up-to-date,
> regardless of the system yum cache state.

then i relent...this time.

-jef



From notting at redhat.com  Mon Nov 28 18:16:26 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 28 Nov 2005 13:16:26 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <1132982906.2860.21.camel@bree.local.net>
References: <1132799302.7912.4.camel@tiger>
	<55053.194.94.224.254.1132820587.squirrel@arlette.freesurf.fr>
	<1132852511.3748.7.camel@yoda.loki.me>
	<e99d27470511250229x50ad26c5j@mail.gmail.com>
	<1132982906.2860.21.camel@bree.local.net>
Message-ID: <20051128181626.GI16533@devserv.devel.redhat.com>

Jeremy Katz (katzj at redhat.com) said: 
> > 3. Repository Handling from UI (i liked the up2date behaviour to
> > selectively enable and disable repos)
> 
> I'm not against this (the glade file actually has the button to bring up
> such a dialog, it's just not currently enabled), but I'm mostly curious
> what the use case is for it.  Why would you not want to get the
> available updates for all configured repositories?  I can see wanting to
> configure what repositories you use for getting software when installing
> new stuff, but what's the use case for doing it while updating?

Where I see something like this being useful is when repositories
aren't in sync yet - for example, you just installed FC5, and
your favorite repo of add-on software isn't built for FC5 yet.

Ergo, you want to temporarily disable that repo.

Bill



From notting at redhat.com  Mon Nov 28 18:27:49 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 28 Nov 2005 13:27:49 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133019788.17474.24.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
Message-ID: <20051128182749.GJ16533@devserv.devel.redhat.com>

seth vidal (skvidal at phy.duke.edu) said: 
> B/c of the rapidly evolving nature of the gcj and related java tools,
> what if we moved them to extras so that work on those packages could be
> both public and move faster?
> 
> It would be a big savings on the size of core and it seems like adding
> those packages over there would be the most correct as the java packages
> don't really have any necessary reason to be in core.
> 
> What do you think?

Splitting GCJ itself off from the complier wouldn't really work well.

Bill



From notting at redhat.com  Mon Nov 28 18:31:38 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 28 Nov 2005 13:31:38 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133021599.17474.43.camel@cutter>
References: <1133019788.17474.24.camel@cutter>
	<1133020129.7280.3.camel@shuttle.273piedmont.com>
	<1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
Message-ID: <20051128183138.GK16533@devserv.devel.redhat.com>

seth vidal (skvidal at phy.duke.edu) said: 
> 1. core isn't really feature complete on its own w/o extras. I can't
> install a system and finish it off w/o using extras.

Well, that's entirely depending on one user's perspective (yours) - you
can't generalize that Core isn't 'feature complete' from that.

Bill



From notting at redhat.com  Mon Nov 28 18:37:27 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 28 Nov 2005 13:37:27 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <1133130789.21208.81.camel@cutter>
References: <1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<1133130789.21208.81.camel@cutter>
Message-ID: <20051128183727.GL16533@devserv.devel.redhat.com>

seth vidal (skvidal at phy.duke.edu) said: 
> 
> > then I don't agree with how that works and would favor and advocate a
> > more "functionality" way of looking at it.
> 
> Great! Then see the Core Brainstorm thread on -maintainers and give us
> more of your criteria for something going to core or not.

http://fedoraproject.org/wiki/Extras/CoreVsExtras

Bill



From skvidal at phy.duke.edu  Mon Nov 28 18:40:39 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 28 Nov 2005 13:40:39 -0500
Subject: suggestion: move all java packages to extras
In-Reply-To: <20051128183727.GL16533@devserv.devel.redhat.com>
References: <1133020624.17474.30.camel@cutter>
	<1133021081.2860.97.camel@bree.local.net>
	<1133021599.17474.43.camel@cutter>
	<20051127054145.GA14718@dudweiler.stuttgart.redhat.com>
	<17289.50324.181961.701343@localhost.localdomain>
	<20051127151015.GA18926@jadzia.bu.edu>
	<1133105752.2853.14.camel@laptopd505.fenrus.org>
	<1133106791.21208.20.camel@cutter>
	<1133107847.2853.26.camel@laptopd505.fenrus.org>
	<1133130789.21208.81.camel@cutter>
	<20051128183727.GL16533@devserv.devel.redhat.com>
Message-ID: <1133203239.6952.17.camel@cutter>

On Mon, 2005-11-28 at 13:37 -0500, Bill Nottingham wrote:
> seth vidal (skvidal at phy.duke.edu) said: 
> > 
> > > then I don't agree with how that works and would favor and advocate a
> > > more "functionality" way of looking at it.
> > 
> > Great! Then see the Core Brainstorm thread on -maintainers and give us
> > more of your criteria for something going to core or not.
> 
> http://fedoraproject.org/wiki/Extras/CoreVsExtras
> 

You'll note that link is on the CoreBrainStorm page in the wiki.

-sv




From Eric.Tanguy at univ-nantes.fr  Mon Nov 28 22:02:56 2005
From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY)
Date: Mon, 28 Nov 2005 23:02:56 +0100 (CET)
Subject: fc5 goals
Message-ID: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>

Le lundi 28 novembre 2005 ?  11:56 -0800, Peter Gordon a ??crit :
> Josh Coffman wrote:
> > Anyone know where to find documentation about the
> > goals and improvements intended for FC5?
>
> You might want to take a look at FC5Future[1] on the Wiki, as well.
>
> [1] http://www.fedoraproject.org/wiki/FC5Future
>
> --Peter
>
Why there is so much java package included in fc5 ?
No news about early login or something like that ?
Why kde is still included in core whereas it could be in extras ?
Why some packages go directly in core and not in extras before ? Because
they were packaged by someone from redhat ? Is it sufficient ???

I saw the long discussion about what to include in or not in fc5 but maybe
the problem will be the goal of fedora ?

Is this product mainly for developpers form redhat ?

yes i know i'm joking but in fact it could be a good question, no ? Thanks

Eric






From jkeating at j2solutions.net  Mon Nov 28 22:15:26 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Nov 2005 14:15:26 -0800
Subject: fc5 goals
In-Reply-To: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
Message-ID: <1133216126.24512.78.camel@prometheus.gamehouse.com>

On Mon, 2005-11-28 at 23:02 +0100, Eric TANGUY wrote:
> Why there is so much java package included in fc5 ?
> No news about early login or something like that ?
> Why kde is still included in core whereas it could be in extras ?
> Why some packages go directly in core and not in extras before ? Because
> they were packaged by someone from redhat ? Is it sufficient ???
> 
> I saw the long discussion about what to include in or not in fc5 but maybe
> the problem will be the goal of fedora ?
> 
> Is this product mainly for developpers form redhat ?
> 
> yes i know i'm joking but in fact it could be a good question, no ? Thanks
> 

The question is why are these pieces of software in Fedora CORE vs
Fedora EXTRAS.  I don't think anybody is complaining that the software
is a part of the Fedora Project itself, just where they should land.
Core or Extras.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From sopwith at redhat.com  Mon Nov 28 22:45:29 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Mon, 28 Nov 2005 17:45:29 -0500 (EST)
Subject: A Fedora-related job opening (QA/testing)
Message-ID: <Pine.LNX.4.58.0511272015470.31391@devserv.devel.redhat.com>

Hi all,

It'd be great to have the opportunity to work with one of you even more
than I currently get to. I won't bore you with a long-winded promo, but if
you're interested in being a "Fedora Test Lead/ Sr Quality Assurance
Engineer", please see:

	http://redhat.hrdpt.com/cgi-bin/a/highlightjob.cgi?jobid=772

Please feel free to send me any additional questions you might have about
the position, and I'll do my best to get answers.

Best,
-- Elliot



From jk at lutty.net  Mon Nov 28 22:00:31 2005
From: jk at lutty.net (Laurent Jacquot)
Date: Mon, 28 Nov 2005 23:00:31 +0100
Subject: custom selinux policy
Message-ID: <1133215231.19778.28.camel@www.lutty.net>

Hello,
I can no longer build my custom selinux policy with recent upgrades (SE
policy source replaced with SE policy).
What is the new way (used to be make reload)?

tx in advance
	jk



From nicolas.mailhot at laposte.net  Mon Nov 28 22:44:15 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Mon, 28 Nov 2005 23:44:15 +0100
Subject: fc5 goals
In-Reply-To: <1133216126.24512.78.camel@prometheus.gamehouse.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
Message-ID: <1133217858.11240.8.camel@rousalka.dyndns.org>

Le lundi 28 novembre 2005 ? 14:15 -0800, Jesse Keating a ?crit :

> The question is why are these pieces of software in Fedora CORE vs
> Fedora EXTRAS.  I don't think anybody is complaining that the software
> is a part of the Fedora Project itself, just where they should land.
> Core or Extras.

Actually I for example don't use KDE, and don't care if it's in core or
extras.

What I do care about is Gnome depending on arts.

I'd rather people spent more time untangling this kind of stupid
cross-dependencies than arguing what needs to be made second-class
citizen.

DVD burners and broadband will be generalized before Core shrinks to a
single CD anyway.

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/659be4e9/attachment.sig>

From benjy.grogan at gmail.com  Tue Nov 29 00:13:02 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Mon, 28 Nov 2005 19:13:02 -0500
Subject: Modern Update System
Message-ID: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>

Hi:

Is there any work being done for a modern update system that would only
download what is needed instead of an entirely new rpm?  I'm sure everyone
has seen the updaet system that Firefox has.  It's beautiful.  How is that
going to work on Fedora Core 5?  Is it disabled?  Eitherway, such an update
system on Linux would be a watershed moment perhaps.  A grand slam.  It is a
bit ridiculous that FC4 updates have possibly mounted up to 10 GB for me..
maybe an exaggeration but you know what I'm getting  at.

So any such project out there?

Benjy,
AWWTF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/07b6488c/attachment.htm>

From jkeating at j2solutions.net  Tue Nov 29 00:46:39 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Nov 2005 16:46:39 -0800
Subject: Modern Update System
In-Reply-To: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
Message-ID: <1133225199.24512.113.camel@prometheus.gamehouse.com>

On Mon, 2005-11-28 at 19:13 -0500, Benjy Grogan wrote:
> Hi:
> 
> Is there any work being done for a modern update system that would
> only download what is needed instead of an entirely new rpm?  I'm sure
> everyone has seen the updaet system that Firefox has.  It's beautiful.
> How is that going to work on Fedora Core 5?  Is it disabled?
> Eitherway, such an update system on Linux would be a watershed moment
> perhaps.  A grand slam.  It is a bit ridiculous that FC4 updates have
> possibly mounted up to 10 GB for me..  maybe an exaggeration but you
> know what I'm getting  at. 
> 
> So any such project out there?

Been discussed ad-nasuem.  (did I spell that right?)

Please look at the archives, I think 'patch' and 'rpm' were both in the
subject line.

Bottom line, mirrors say no as they would have to maintain all sorts of
extra content and tools to figure out what deltas a client would need
for a given state of a particular rpm.  Say one package has 4 updates
available after the install, well a client could be updating from 4
different states.  The install state, and the 3 previous updated states.
Thats 4 different deltas that would have to be available.  We're talking
about a huge amount of wasted space.

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From bernie at develer.com  Tue Nov 29 02:22:38 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 29 Nov 2005 03:22:38 +0100
Subject: fc5 goals
In-Reply-To: <1133217858.11240.8.camel@rousalka.dyndns.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
Message-ID: <438BBB6E.9070505@develer.com>

Nicolas Mailhot wrote:

> Actually I for example don't use KDE, and don't care if it's in core or
> extras.

As a system administrator, I'd much prefer if FC remained neutral
wrt desktop choices.

Some of my users prefer KDE, some Gnome.  I don't want to start
supporting two distributions to satisfy them all, so if FC kicked
KDE out of core, I'd be forced to switch to another distro.


> What I do care about is Gnome depending on arts.

Actually, I dislike both arts and esd.  In the past, I've had to find
lots of workarounds for sound problems caused by them.

Can't these darn desktops just play through ALSA without using
a sound server, like all normal applications do?


> I'd rather people spent more time untangling this kind of stupid
> cross-dependencies than arguing what needs to be made second-class
> citizen.

I'd add that kde depends on esound, which is also unfortunate.
The desktops should be independent of each other, or at least
based on a common infrastructure (which is what freedesktop has
been trying to achieve).


> DVD burners and broadband will be generalized before Core shrinks to a
> single CD anyway.

In my experience, DVD burners and readers are already much
more common than plain CD recorders and readers.  Computers
with no DVD readers are usually too old and slow to run a
full featured Linux desktop comfortably, and if the current
trend of adding features and complexity continues, it will
become more and more true over time.

I'm all in favor of shrinking the core distribution to save
bandwidth, but the main distribution focus should be to fit
everything into a single DVD, not a single CD.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From mattdm at mattdm.org  Tue Nov 29 02:30:48 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Mon, 28 Nov 2005 21:30:48 -0500
Subject: fc5 goals
In-Reply-To: <438BBB6E.9070505@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>
Message-ID: <20051129023048.GA12302@jadzia.bu.edu>

On Tue, Nov 29, 2005 at 03:22:38AM +0100, Bernardo Innocenti wrote:
> > Actually I for example don't use KDE, and don't care if it's in core or
> > extras.
> As a system administrator, I'd much prefer if FC remained neutral
> wrt desktop choices.
> Some of my users prefer KDE, some Gnome.  I don't want to start
> supporting two distributions to satisfy them all, so if FC kicked
> KDE out of core, I'd be forced to switch to another distro.

No you wouldn't. You could just stick with Fedora and install it from
Extras.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From denis at poolshark.org  Tue Nov 29 02:33:34 2005
From: denis at poolshark.org (Denis Leroy)
Date: Mon, 28 Nov 2005 18:33:34 -0800
Subject: fc5 goals
In-Reply-To: <438BBB6E.9070505@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>
Message-ID: <438BBDFE.5090205@poolshark.org>

Bernardo Innocenti wrote:
> Actually, I dislike both arts and esd.  In the past, I've had to find
> lots of workarounds for sound problems caused by them.
> 
> Can't these darn desktops just play through ALSA without using
> a sound server, like all normal applications do?

+100

> I'd add that kde depends on esound, which is also unfortunate.
> The desktops should be independent of each other, or at least
> based on a common infrastructure (which is what freedesktop has
> been trying to achieve).

What if the Fedora Installer was able to install KDE by downloading it from 
Extras rather than from the CD ?

> I'm all in favor of shrinking the core distribution to save
> bandwidth, but the main distribution focus should be to fit
> everything into a single DVD, not a single CD.

+1. While it's important to have a consistent policy on what should or should 
not be part of Fedora Core vs Extras, i do have a feeling that too much time 
and energy is being spent on a non-issue, energy that could probably be better 
spent elsewhere...

-denis



From dhollis at davehollis.com  Tue Nov 29 02:55:11 2005
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 28 Nov 2005 21:55:11 -0500
Subject: Modern Update System
In-Reply-To: <1133225199.24512.113.camel@prometheus.gamehouse.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
Message-ID: <1133232911.5030.16.camel@dhollis-lnx.sunera.com>

On Mon, 2005-11-28 at 16:46 -0800, Jesse Keating wrote:
> On Mon, 2005-11-28 at 19:13 -0500, Benjy Grogan wrote:
> > Hi:
> > 
> > Is there any work being done for a modern update system that would
> > only download what is needed instead of an entirely new rpm?  I'm sure
> > everyone has seen the updaet system that Firefox has.  It's beautiful.
> > How is that going to work on Fedora Core 5?  Is it disabled?
> > Eitherway, such an update system on Linux would be a watershed moment
> > perhaps.  A grand slam.  It is a bit ridiculous that FC4 updates have
> > possibly mounted up to 10 GB for me..  maybe an exaggeration but you
> > know what I'm getting  at. 
> > 
> > So any such project out there?

I think there is a project that does this, and has been doing it for
quite awhile.  It's called Microsoft Windows.  The problem that this
method poses is that it's very easy to get to a point where you have no
idea what the current real state of your system is.  With the
modularization that already exists and is increasing all the time with
Fedora (and all OS Unices out there really), updates are getting smaller
and more 'directed' and bandwidth continues to increase while the price
goes down.  What would really be the best answer to this would be having
anaconda have the ability to pull down updates from a yum repo during
install, so instead of installing package Z only to have it updated to a
patched version right after reboot, it's all done on the first shot.  If
you maintain a large number of systems, just make a mirror of the Fedora
updates to keep the traffic local.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/a5308c17/attachment.sig>

From bernie at develer.com  Tue Nov 29 02:58:05 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 29 Nov 2005 03:58:05 +0100
Subject: fc5 goals
In-Reply-To: <438BBDFE.5090205@poolshark.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<438BBDFE.5090205@poolshark.org>
Message-ID: <438BC3BD.7050407@develer.com>

Denis Leroy wrote:

>> Can't these darn desktops just play through ALSA without using
>> a sound server, like all normal applications do?
> 
> +100

:-)))


>> I'd add that kde depends on esound, which is also unfortunate.
>> The desktops should be independent of each other, or at least
>> based on a common infrastructure (which is what freedesktop has
>> been trying to achieve).
> 
> What if the Fedora Installer was able to install KDE by downloading it
> from Extras rather than from the CD ?

It would be fine for me, as I mirror both core and extras daily.

I think it would be somewhat painful for other users, expecially
those who don't have broadband access or live behind corporate
firewalls.

As of FC5, all extras packages are _still_ second-class citizens:

 - they don't get distributed on CD/DVD media along with FC;
 - sometimes, extras packages are out of sync with core (expecially
   true in rawhide);
 - there seems to be less QC in extras than core;


My feeling is that KDE already gets too little polish and
integration in Fedora, so I'm afraid kicking it to extras
would make KDE as unusable as Gnome was in SuSE over one
year ago.


> +1. While it's important to have a consistent policy on what should or
> should not be part of Fedora Core vs Extras, i do have a feeling that
> too much time and energy is being spent on a non-issue, energy that
> could probably be better spent elsewhere...

IMHO, Fedora badly needs better GUI management tools.  We can all
do without them just fine, but newbies are just scared away and
fly to Mandriva or SuSE just to get something similar to the
familiar Windows or Mac OS X control panels.

We should look at other distros and either adopt their tools
or improve ours until they become as usable and feature-complete
as theirs.

If I was a RedHat manager, I'd ask developers to install and
use a few competing distributions on their desktops just to
get new ideas :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From zaitcev at redhat.com  Tue Nov 29 03:23:40 2005
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Mon, 28 Nov 2005 19:23:40 -0800
Subject: Modern Update System
In-Reply-To: <1133232911.5030.16.camel@dhollis-lnx.sunera.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
Message-ID: <20051128192340.602a02b1.zaitcev@redhat.com>

On Mon, 28 Nov 2005 21:55:11 -0500, David Hollis <dhollis at davehollis.com> wrote:

> I think there is a project that does this, and has been doing it for
> quite awhile.  It's called Microsoft Windows.  The problem that this
> method poses is that it's very easy to get to a point where you have no
> idea what the current real state of your system is. [...]

Solaris used to have a similar system, where they had subpackages or
"patch" packages. IIRC, they got rid of it and switched to essentially
what we have now, for a few reasons.

 - These fragments always grew and congealed together, which only
   worsened the first problem; also the savings disappeared over the
   life of the package. It was called "jumbo" patch. In a couple of
   patch cycles you would be patching whole package anyway. At that
   point, it's better to install update packages.

 - People were making mistakes installing patches and causing all
   sorts of weirdest problems, and it was a living hell for support
   -- Mind though, that was a decade before yum.

I am quite surprised that it works for Microsoft, because Sun gave it
a good try. Maybe they just ignore most problems, like what happens
when you upgrade a well-patched system to the next release.

-- Pete



From pemboa at gmail.com  Tue Nov 29 03:33:54 2005
From: pemboa at gmail.com (Arthur Pemberton)
Date: Mon, 28 Nov 2005 21:33:54 -0600
Subject: Slightly OT: Updated RPM building howto?
In-Reply-To: <1133195565.21926.28.camel@locolhost.localdomain>
References: <16de708d0511270032h2efe44feo18e6739a9a364791@mail.gmail.com>
	<1133195565.21926.28.camel@locolhost.localdomain>
Message-ID: <16de708d0511281933m7289f2caw982b56e8afd571d1@mail.gmail.com>

Thanks for the advice, I will be getting to this as soon as my exams are
over.

Peace

On 11/28/05, Michael A. Peters <mpeters at mac.com> wrote:
>
> On Sun, 2005-11-27 at 02:32 -0600, Arthur Pemberton wrote:
> > Are there any recent HOWTOs around on RPM building? I would really
> > like to contribute to Fedora, at least by maintaing packages to
> > software that I use regularly on my own FC4 install. However the
> > HOWTOs I've found seem busy and complicated. I consider myself to be
> > fairly Linux competent, and so I believe that I have the capabilties
> > to help.
> >
> > Please advise, thank you.
>
> As mentioned - the Fedora Packaging Guidelines are an excellent
> resource.
>
> You can also read the Fedora Extras list - and look at the spec files
> submitted in the Bugzilla (they are on the extras list) and see the
> comments packagers make about them.
>
> The "Red Hat RPM Guide" by Eric Foster-Johnson is an excellent book - a
> free version of which I believe is what Aurelien Bompard linked to.
>
> It's a good book.
>
> Best thing to do imho - install fedora-rpmdevtools , take the
> spectemplate-minimal.spec and use it as a template to package something
> and submit it to extras (referencing the packaging guidelines in the
> Extras wiki).
>
> You will also want to install mock - so that you can make sure your
> package builds cleanly before submitting.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



--
As a boy I jumped through Windows, as a man I play with Penguins.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/18d0858f/attachment.htm>

From dhollis at davehollis.com  Tue Nov 29 03:32:09 2005
From: dhollis at davehollis.com (David Hollis)
Date: Mon, 28 Nov 2005 22:32:09 -0500
Subject: Modern Update System
In-Reply-To: <20051128192340.602a02b1.zaitcev@redhat.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
Message-ID: <1133235130.5030.26.camel@dhollis-lnx.sunera.com>

On Mon, 2005-11-28 at 19:23 -0800, Pete Zaitcev wrote:
> On Mon, 28 Nov 2005 21:55:11 -0500, David Hollis <dhollis at davehollis.com> wrote:
> 
> > I think there is a project that does this, and has been doing it for
> > quite awhile.  It's called Microsoft Windows.  The problem that this
> > method poses is that it's very easy to get to a point where you have no
> > idea what the current real state of your system is. [...]
> 
> Solaris used to have a similar system, where they had subpackages or
> "patch" packages. IIRC, they got rid of it and switched to essentially
> what we have now, for a few reasons.
> 

Oh jeez, I totally forgot about that horrid mess!  It seemed like
Solaris 2.6 was just a patched-to-hell-and-back Solaris 2.5, which was
patched 2.4, etc on down the line!


> I am quite surprised that it works for Microsoft, because Sun gave it
> a good try. Maybe they just ignore most problems, like what happens
> when you upgrade a well-patched system to the next release.
> 

I wouldn't really say that it does work with Windows.  They are going so
long between Service Packs these days that you wind up with somewhere on
the order of half a million patches to install so the only way you can
possibly keep up with it is to use Windows Update.   What if you aren't
on the network (like a secured LAN or just a standalone box)?  You
really can't go and find out all of the patches available and the order
that they should be applied.  It's beyond human comprehension at this
point.  Granted, the patch applier utils are supposed to take the
version of the EXE or DLL into account to avoid overwriting newer ones.
But with Windows' exclusive access issues, if you apply two patches that
happen to update the same file, you can't really be sure which one will
be the one that you wind up with after the next reboot.  It's black
magic and pixie dust and all of that good stuff.  So in the end, you
might have applied a patch and think that you are in good shape, but the
other patch you applied actually downgraded you.  There isn't an easy
way to tell you if you are really honest-to-god up-to-date.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/d875f3b5/attachment.sig>

From jkeating at j2solutions.net  Tue Nov 29 03:53:40 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Nov 2005 19:53:40 -0800
Subject: fc5 goals
In-Reply-To: <438BBB6E.9070505@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>
Message-ID: <1133236420.2833.38.camel@yoda.loki.me>

On Tue, 2005-11-29 at 03:22 +0100, Bernardo Innocenti wrote:
> Can't these darn desktops just play through ALSA without using
> a sound server, like all normal applications do?
> 

And what is ALSA isn't available on the system?  This means that every
gnome application must have it's own sound code to use either OSS or
Alsa, and must have a configuration item for this and so on and so
forth.  By using a sound server, all the gnome apps automatically know
where to send sound.  The sound server then takes these inputs and on
one place has configs for alsa or oss and does what it needs to do.  In
reality this means that some users that have cards that can't handle
multiple sources at once (an audio player may lock the sound device so
no other app can make sound) can now get threaded sounds from
applications.

There are other uses, this is just a couple of them.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From benjy.grogan at gmail.com  Tue Nov 29 04:19:03 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Mon, 28 Nov 2005 23:19:03 -0500
Subject: Modern Update System
In-Reply-To: <1133235130.5030.26.camel@dhollis-lnx.sunera.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
Message-ID: <d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>

Please, this is ridiculous.  Of course it's possible.  You make a decision:
i) will a few patches be small/easy to install ii) should i generate a
unified patch for this user iii) situation is so bad, just send a whole new
rpm...  and there the repository has done some work and come up with the
best solution for you.  ... and yes, there are many more decisions.. such as
cross-package decisions etc...  but this is an absolute must for the next
gen linux distros.

What's Redhat doing?  What's Novell doing?

Microsoft has their solution, and there's a much better solution out there
for Linux.

... and the Anaconda idea.. where it checks to see if there is a new rpm
available before instalingl Fedora is good too.

Benjy,
AWWTF

On 11/28/05, David Hollis <dhollis at davehollis.com> wrote:
>
> On Mon, 2005-11-28 at 19:23 -0800, Pete Zaitcev wrote:
> > On Mon, 28 Nov 2005 21:55:11 -0500, David Hollis <dhollis at davehollis.com>
> wrote:
> >
> > > I think there is a project that does this, and has been doing it for
> > > quite awhile.  It's called Microsoft Windows.  The problem that this
> > > method poses is that it's very easy to get to a point where you have
> no
> > > idea what the current real state of your system is. [...]
> >
> > Solaris used to have a similar system, where they had subpackages or
> > "patch" packages. IIRC, they got rid of it and switched to essentially
> > what we have now, for a few reasons.
> >
>
> Oh jeez, I totally forgot about that horrid mess!  It seemed like
> Solaris 2.6 was just a patched-to-hell-and-back Solaris 2.5, which was
> patched 2.4, etc on down the line!
>
>
> > I am quite surprised that it works for Microsoft, because Sun gave it
> > a good try. Maybe they just ignore most problems, like what happens
> > when you upgrade a well-patched system to the next release.
> >
>
> I wouldn't really say that it does work with Windows.  They are going so
> long between Service Packs these days that you wind up with somewhere on
> the order of half a million patches to install so the only way you can
> possibly keep up with it is to use Windows Update.   What if you aren't
> on the network (like a secured LAN or just a standalone box)?  You
> really can't go and find out all of the patches available and the order
> that they should be applied.  It's beyond human comprehension at this
> point.  Granted, the patch applier utils are supposed to take the
> version of the EXE or DLL into account to avoid overwriting newer ones.
> But with Windows' exclusive access issues, if you apply two patches that
> happen to update the same file, you can't really be sure which one will
> be the one that you wind up with after the next reboot.  It's black
> magic and pixie dust and all of that good stuff.  So in the end, you
> might have applied a patch and think that you are in good shape, but the
> other patch you applied actually downgraded you.  There isn't an easy
> way to tell you if you are really honest-to-god up-to-date.
>
> --
> David Hollis <dhollis at davehollis.com>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQBDi8u5xasLqOyGHncRAldBAKCJndmyzyS0DpQjWNMX14VfvOVwxwCfeCnR
> 5uHxZBjIznSn296ahFEUwvY=
> =9fET
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051128/75e537da/attachment.htm>

From bgerst at didntduck.org  Tue Nov 29 04:40:30 2005
From: bgerst at didntduck.org (Brian Gerst)
Date: Mon, 28 Nov 2005 23:40:30 -0500
Subject: Modern Update System
In-Reply-To: <d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>	<1133225199.24512.113.camel@prometheus.gamehouse.com>	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>	<20051128192340.602a02b1.zaitcev@redhat.com>	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
Message-ID: <438BDBBE.7080005@didntduck.org>

Benjy Grogan wrote:
> Please, this is ridiculous.  Of course it's possible.  You make a 
> decision: i) will a few patches be small/easy to install ii) should i 
> generate a unified patch for this user iii) situation is so bad, just 
> send a whole new rpm...  and there the repository has done some work
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Therein lies the problem: this requires more than a simple web server to 
implement.

 > and
> come up with the best solution for you.  ... and yes, there are many 
> more decisions.. such as cross-package decisions etc...  but this is an 
> absolute must for the next gen linux distros.
> 
> What's Redhat doing?  What's Novell doing?
> 
> Microsoft has their solution

We don't need to repeat their mistakes.  Most RPMs are small enough that 
there is no net gain using this method.

--
				Brian Gerst



From benjy.grogan at gmail.com  Tue Nov 29 04:43:01 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Mon, 28 Nov 2005 23:43:01 -0500
Subject: Modern Update System
In-Reply-To: <438BDBBE.7080005@didntduck.org>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
Message-ID: <d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>

Yes, yes, but if there is no net gain then you revert to simply sending out
the whole rpm.  But when you have some 100 updates or more then you want to
send this Fedora user the smallest possible patch you can.

It should be a crazy challenge to come up with the most minute update, the
modicum of all updates, that can be achieved.

Sure, repositories will have to grow up and embrace a new system.  But with
the Web 2.0 coming out everything is slowly changing anyways.

This must be done.  Who wants to start?  Who could start?

Benjy,
AWWTF


On 11/28/05, Brian Gerst <bgerst at didntduck.org> wrote:
>
> Benjy Grogan wrote:
> > Please, this is ridiculous.  Of course it's possible.  You make a
> > decision: i) will a few patches be small/easy to install ii) should i
> > generate a unified patch for this user iii) situation is so bad, just
> > send a whole new rpm...  and there the repository has done some work
>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Therein lies the problem: this requires more than a simple web server to
> implement.
>
> > and
> > come up with the best solution for you.  ... and yes, there are many
> > more decisions.. such as cross-package decisions etc...  but this is an
> > absolute must for the next gen linux distros.
> >
> > What's Redhat doing?  What's Novell doing?
> >
> > Microsoft has their solution
>
> We don't need to repeat their mistakes.  Most RPMs are small enough that
> there is no net gain using this method.
>
> --
>                                 Brian Gerst
>
> --
> 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/20051128/c872a3e1/attachment.htm>

From nmiell at comcast.net  Tue Nov 29 04:52:49 2005
From: nmiell at comcast.net (Nicholas Miell)
Date: Mon, 28 Nov 2005 20:52:49 -0800
Subject: Modern Update System
In-Reply-To: <438BDBBE.7080005@didntduck.org>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
Message-ID: <1133239969.2937.0.camel@entropy>

On Mon, 2005-11-28 at 23:40 -0500, Brian Gerst wrote:

> We don't need to repeat their mistakes.  Most RPMs are small enough that 
> there is no net gain using this method.
> 

And from time to time, there's a full 300 MB OpenOffice release for a
one-line fix to the shell script that launches the whole thing.

-- 
Nicholas Miell <nmiell at comcast.net>



From jspaleta at gmail.com  Tue Nov 29 05:20:13 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 00:20:13 -0500
Subject: Modern Update System
In-Reply-To: <d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
Message-ID: <604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>

On 11/28/05, Benjy Grogan <benjy.grogan at gmail.com> wrote:
> This must be done.  Who wants to start?  Who could start?
Must? You're mastery of hyperbole takes my breath away.

It's already been suggested to you that you look back into the
archives the the this list and find previous discussions. You seem to
be suffering from the delusion that this is a new idea. This comes up
every release.. and yet it doesn't get much further than a proof of
concept code release that gains absolutely no traction.

Since you seem incapable of searching the archives on your own let me
point out a previous discussion:
https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00344.html

Please, read the whole thread and take the time to figure out the
people in the thread who agree with you as to what is needed, contact
those people and see how far they have gotten with a usable
implementation.

Hell, now that yum's plugin support is exposed there is absolutely no
reason stopping people who are interested in showing this is
worthwhile to support officially from cobbling together a yum plugin
to put into extras and persuading a set of mirrors to keep the daltas.
 With plugin support in yum, the complexity of the proxy server in the
thread i referenced above is problably no longer needed.

Instead of more exaggerated rhetoric, what's need to move this concept
forward is a usable implementation that can go into Extras and a set
mirrors willing to support your delta approach.  And then find a way
to keep metrics as to how popular the delta process is and whether its
worth the upkeep to maintain.

-jef"mother-smurfer"spaleta



From benjy.grogan at gmail.com  Tue Nov 29 05:32:32 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 29 Nov 2005 00:32:32 -0500
Subject: Modern Update System
In-Reply-To: <604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
Message-ID: <d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>

Well, that's fuckin' awesome.  Someone could tag Openoffice to use the yum
plugin if they wanted it to be updated using the deltas approach and save
100 MB just like that.

Implementing the delta updates with the yum plugin is perfect.  I'm going to
follow this up and see what I can learn.  I hope there are others out there
as well that are interested in working on this.  It's not my idea, but
definitely needed your comments below to move this idea forward.

If a few different methods were available for updating rpms then there could
be another level that automates the decision making to look for the most
feasible method to use.

Benjy,
AWWTF



On 11/29/05, Jeff Spaleta <jspaleta at gmail.com> wrote:
>
> On 11/28/05, Benjy Grogan <benjy.grogan at gmail.com> wrote:
> > This must be done.  Who wants to start?  Who could start?
> Must? You're mastery of hyperbole takes my breath away.
>
> It's already been suggested to you that you look back into the
> archives the the this list and find previous discussions. You seem to
> be suffering from the delusion that this is a new idea. This comes up
> every release.. and yet it doesn't get much further than a proof of
> concept code release that gains absolutely no traction.
>
> Since you seem incapable of searching the archives on your own let me
> point out a previous discussion:
> https://www.redhat.com/archives/fedora-devel-list/2005-March/msg00344.html
>
> Please, read the whole thread and take the time to figure out the
> people in the thread who agree with you as to what is needed, contact
> those people and see how far they have gotten with a usable
> implementation.
>
> Hell, now that yum's plugin support is exposed there is absolutely no
> reason stopping people who are interested in showing this is
> worthwhile to support officially from cobbling together a yum plugin
> to put into extras and persuading a set of mirrors to keep the daltas.
> With plugin support in yum, the complexity of the proxy server in the
> thread i referenced above is problably no longer needed.
>
> Instead of more exaggerated rhetoric, what's need to move this concept
> forward is a usable implementation that can go into Extras and a set
> mirrors willing to support your delta approach.  And then find a way
> to keep metrics as to how popular the delta process is and whether its
> worth the upkeep to maintain.
>
> -jef"mother-smurfer"spaleta
>
> --
> 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/20051129/0c5905d0/attachment.htm>

From Eric.Tanguy at univ-nantes.fr  Tue Nov 29 05:32:47 2005
From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY)
Date: Tue, 29 Nov 2005 06:32:47 +0100 (CET)
Subject: Kernel module question
Message-ID: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>

If i remember well the rt5x00 driver would be included in kernel. Someone
could confirm that ? When it will be incuded in fedora kernel ?
Thanks
Eric



From Eric.Tanguy at univ-nantes.fr  Tue Nov 29 05:34:18 2005
From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY)
Date: Tue, 29 Nov 2005 06:34:18 +0100 (CET)
Subject: Early login and ...
Message-ID: <60754.86.199.0.227.1133242458.squirrel@webmail.univ-nantes.fr>

It seems that the early login project is stopped is there something else
to replace it ? And what about its inclusion in FC5 ?
Thanks
Eric




From jkeating at j2solutions.net  Tue Nov 29 05:48:59 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Nov 2005 21:48:59 -0800
Subject: Modern Update System
In-Reply-To: <d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
Message-ID: <1133243339.2833.44.camel@yoda.loki.me>

On Tue, 2005-11-29 at 00:32 -0500, Benjy Grogan wrote:
> Well, that's fuckin' awesome.  Someone could tag Openoffice to use the yum
> plugin if they wanted it to be updated using the deltas approach and save
> 100 MB just like that.

At the cost of how much more disk space needed on the mirrors, and
bandwidth used to sync mirrors?  Do we break rpm all together and just
put raw files out there no longer in rpm format?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From bernie at develer.com  Tue Nov 29 06:09:29 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Tue, 29 Nov 2005 07:09:29 +0100
Subject: fc5 goals
In-Reply-To: <1133236420.2833.38.camel@yoda.loki.me>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<1133236420.2833.38.camel@yoda.loki.me>
Message-ID: <438BF099.1060404@develer.com>

Jesse Keating wrote:

> On Tue, 2005-11-29 at 03:22 +0100, Bernardo Innocenti wrote:
>> Can't these darn desktops just play through ALSA without using
>> a sound server, like all normal applications do?
>>
> 
> And what is ALSA isn't available on the system?

Alsa has been available for a lot of time, but...


> This means that every
> gnome application must have it's own sound code to use either OSS or
> Alsa, and must have a configuration item for this and so on and so
> forth. By using a sound server, all the gnome apps automatically know
> where to send sound. The sound server then takes these inputs and on
> one place has configs for alsa or oss and does what it needs to do.

Using a simple library to abstract sound output would have solved
the problem with no need for an overengineered sound server.
SDL applications, for instance, can play to whatever sound
system you have (several platforms supported).

Keeping the sound configuration global to the desktop would still
be as easy as choosing fonts or the GKT theme.


> In reality this means that some users that have cards that can't handle
> multiple sources at once (an audio player may lock the sound device so
> no other app can make sound) can now get threaded sounds from
> applications.

This used to be a problem with some OSS drivers.  I believe ALSA
can mix audio streams in kernel, regardless of what the underlying
audio driver can do.


> There are other uses, this is just a couple of them.

I do agree someone may need a sound server to broadcast
audio over TCP or UDP... perhaps to support remote desktops.

If needed, the sound abstraction library may be configured
to to connect to something similar to esd or artsd.

Some advanced sound applications may also need to synchronize
and play different audio streams together, but this is something
artsd and esd can't do, as far as I know.  JACK does this, but
it's even more complex and less supported.

If I remember correctly, the BeOS multimedia framework was
natively capable of synchronize audio and video applications
to play together.  It allowed users to build very complex
stuff by combining many simple applications.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From benjy.grogan at gmail.com  Tue Nov 29 06:51:39 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 29 Nov 2005 01:51:39 -0500
Subject: Modern Update System
In-Reply-To: <1133243339.2833.44.camel@yoda.loki.me>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
Message-ID: <d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>

Yeah, that's what I'm starting to think.  Having to have the initial rpm on
your hard drive all the time would be another kind of waste.

It comes down to more fundamental changes.  If the method of keeping rpms on
your hard drive is ditched then you're left with sending pure binary patches
to the actual files.  That's the best way, but a complete reorganization is
then needed.

Sounds like one of these long projects that requires corporate funding to
see it through a few years work.  I think it's an important enough challenge
to tackle that Red Hat, IBM and Novell should work together to do this.

It's alot of work any way it's done.  Best to go for the best solution and
find some backing and then hope everyone interested shows up to help out.

Benjy,
AWWTF


On 11/29/05, Jesse Keating <jkeating at j2solutions.net> wrote:
>
> On Tue, 2005-11-29 at 00:32 -0500, Benjy Grogan wrote:
> > Well, that's fuckin' awesome.  Someone could tag Openoffice to use the
> yum
> > plugin if they wanted it to be updated using the deltas approach and
> save
> > 100 MB just like that.
>
> At the cost of how much more disk space needed on the mirrors, and
> bandwidth used to sync mirrors?  Do we break rpm all together and just
> put raw files out there no longer in rpm format?
>
> --
> Jesse Keating RHCE      (geek.j2solutions.net)
> Fedora Legacy Team      (www.fedoralegacy.org)
> GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
>
> Was I helpful?  Let others know:
> http://svcs.affero.net/rm.php?r=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/20051129/7e27dac5/attachment.htm>

From jkeating at j2solutions.net  Tue Nov 29 07:09:41 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Mon, 28 Nov 2005 23:09:41 -0800
Subject: Modern Update System
In-Reply-To: <d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
Message-ID: <1133248181.2833.53.camel@yoda.loki.me>

On Tue, 2005-11-29 at 01:51 -0500, Benjy Grogan wrote:
> Yeah, that's what I'm starting to think.  Having to have the initial rpm on
> your hard drive all the time would be another kind of waste.
> 
> It comes down to more fundamental changes.  If the method of keeping rpms on
> your hard drive is ditched then you're left with sending pure binary patches
> to the actual files.  That's the best way, but a complete reorganization is
> then needed.
> 
> Sounds like one of these long projects that requires corporate funding to
> see it through a few years work.  I think it's an important enough challenge
> to tackle that Red Hat, IBM and Novell should work together to do this.
> 
> It's alot of work any way it's done.  Best to go for the best solution and
> find some backing and then hope everyone interested shows up to help out.

Now you're talking about something even more different.  Not just
sending single file replacements, but binary diffs?!  Just how much data
do you expect mirrors to keep?

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From n0dalus+redhat at gmail.com  Tue Nov 29 07:21:01 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Tue, 29 Nov 2005 17:51:01 +1030
Subject: Modern Update System
In-Reply-To: <d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
Message-ID: <6280325c0511282321j44b9a5a1l9b36ec918191647c@mail.gmail.com>

On 11/29/05, Benjy Grogan <benjy.grogan at gmail.com> wrote:
> Yeah, that's what I'm starting to think.  Having to have the initial rpm on
> your hard drive all the time would be another kind of waste.
>
> It comes down to more fundamental changes.  If the method of keeping rpms on
> your hard drive is ditched then you're left with sending pure binary patches
> to the actual files.  That's the best way, but a complete reorganization is
> then needed.
>
> Sounds like one of these long projects that requires corporate funding to
> see it through a few years work.  I think it's an important enough challenge
> to tackle that Red Hat, IBM and Novell should work together to do this.
>
> It's alot of work any way it's done.  Best to go for the best solution and
> find some backing and then hope everyone interested shows up to help out.
>
> Benjy,
> AWWTF
>

I wonder if is possible to build a multipart rpm format, so by looking
at it's header you could determine you only need the first x bytes,
which would be the incremental binary patches between it and the last
couple of versions (depending on how much extra space you want to take
up). It might be possible to mark this first part so it will be
ignored by earlier versions of yum/rpm. Can someone with a good
understanding of the rpm format and how it is parsed comment on this
idea?

I am thinking something like this:
[|header|incremental_patch_1|incremental_patch_2|...|]|normal_rpm_data

Where the stuff in [] is (if possible) formatted so the current rpm
system ignores it.
Depending on what percentage of the filesize you want to take up with
binary patches, there will be anywhere from 0 patches (and no header
since it's not needed), to a patch between every previous version (if
they're only a couple of kb each, it shouldn't hurt).
The header would contain the offsets for all the patches, sha1 sums of
each piece, and version numbers so the reader could determine which
ones it needs. If missing one of the patches it would just proceed to
download the whole rpm and update normally.
Each patch should have hashes for each file that needs updating and if
any one of these don't match the files on the disk, it proceeds to
download the rest of the rpm and update normally.

I don't know if I agree that this needs corporate funding and years of
work. I think a system like this could be written in under a year by
volunteers.

n0dalus.



From jamatos at fc.up.pt  Tue Nov 29 07:54:54 2005
From: jamatos at fc.up.pt (Jose' Matos)
Date: Tue, 29 Nov 2005 07:54:54 +0000
Subject: fc5 goals
In-Reply-To: <438BC3BD.7050407@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<438BBDFE.5090205@poolshark.org> <438BC3BD.7050407@develer.com>
Message-ID: <200511290754.54544.jamatos@fc.up.pt>

On Tuesday 29 November 2005 02:58, Bernardo Innocenti wrote:
> As of FC5, all extras packages are _still_ second-class citizens:
>
> ?- they don't get distributed on CD/DVD media along with FC;
> ?- sometimes, extras packages are out of sync with core (expecially
> ? ?true in rawhide);

  I should point to you the obvious, if you are taking rawhide as an example 
then we should conclude that FC is a second-class citizen, after all in the 
end of daily report I always see packages with broken dependencies. :-)

> ?- there seems to be less QC in extras than core;

  Probably some kind of testing ground would not hurt as it happens with 
testing-updates.

-- 
Jos? Ab?lio



From Axel.Thimm at ATrpms.net  Tue Nov 29 07:58:55 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 29 Nov 2005 08:58:55 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <m364qdw0v7.fsf@ursa.amorsen.dk>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
Message-ID: <20051129075855.GB13739@neu.nirvana>

On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote:
> >>>>> "WR" == Willem Riede <wrrhdev at riede.org> writes:
> 
> WR> Maybe I shouldn't care, but I do. As an example, with all due
> WR> respect to its creator, the atrpms repository holds both packages
> WR> I want (unique functionality) and that I don't want (core
> WR> replacements). Unfortunately that means I can never do a blind
> WR> cross-the-board upgrade from all the sources I've identified.
> 
> It would be very nice if one of the update utilities could be set to
> ignore updates across repositories. I.e. if I've installed foo from
> core and bar from atrpms and atrpms has newer versions of both foo and
> bar, only bar gets updated.

Maybe it's better to avoid atrpms at all then, as its bar will
probably assume that you are using foo from the same source? Perhaps
foo in core is being replaced just to add the functionality that bar
needs?

It isn't as black or white as it seems. I've had enough bug reports on
using apt and smart with priorities/weights to strongly advise against
their use (not apt/smart's, but their weighing mechanisms).

And if you don't trust repo X to replace package Y, then why trust it
to offer package Z? Better drop repo X, if you feel uncomfortable.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051129/e21cb476/attachment.sig>

From Axel.Thimm at ATrpms.net  Tue Nov 29 08:01:20 2005
From: Axel.Thimm at ATrpms.net (Axel Thimm)
Date: Tue, 29 Nov 2005 09:01:20 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051128110828.GA16912@ryoko.camperquake.de>
	<20051128113329.GA5698@dudweiler.stuttgart.redhat.com>
Message-ID: <20051129080120.GC13739@neu.nirvana>

On Mon, Nov 28, 2005 at 12:33:29PM +0100, Florian La Roche wrote:
> On Mon, Nov 28, 2005 at 12:08:28PM +0100, Ralf Ertzinger wrote:
> > On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote:
> > 
> > > It would be very nice if one of the update utilities could be set to
> > > ignore updates across repositories. I.e. if I've installed foo from
> > > core and bar from atrpms and atrpms has newer versions of both foo and
> > > bar, only bar gets updated.
> > 
> > smart can do exactly that.
> 
> You can use the sha/md5sum digest info to match between the rpms
> installed in rpmdb (/var/lib/rpm/) and the rpm packages from the
> repositories. This will only work if the repos still have the older
> rpms listed though.

Most repos purge the old rpms, and even updates-released does so every
now and then.

Why not use the signature or other meta- data like vendor to map
packages to origin?

> Is smart storing addon information in its own database?

No, no history information.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051129/d367b584/attachment.sig>

From che666 at gmail.com  Tue Nov 29 08:35:28 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 29 Nov 2005 09:35:28 +0100
Subject: Modern Update System
In-Reply-To: <6280325c0511282321j44b9a5a1l9b36ec918191647c@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<6280325c0511282321j44b9a5a1l9b36ec918191647c@mail.gmail.com>
Message-ID: <e99d27470511290035p41dde051p@mail.gmail.com>

2005/11/29, n0dalus <n0dalus+redhat at gmail.com>:
> On 11/29/05, Benjy Grogan <benjy.grogan at gmail.com> wrote:
> > Yeah, that's what I'm starting to think.  Having to have the initial rpm on
> > your hard drive all the time would be another kind of waste.
> >
> > It comes down to more fundamental changes.  If the method of keeping rpms on
> > your hard drive is ditched then you're left with sending pure binary patches
> > to the actual files.  That's the best way, but a complete reorganization is
> > then needed.
> >
> > Sounds like one of these long projects that requires corporate funding to
> > see it through a few years work.  I think it's an important enough challenge
> > to tackle that Red Hat, IBM and Novell should work together to do this.
> >
> > It's alot of work any way it's done.  Best to go for the best solution and
> > find some backing and then hope everyone interested shows up to help out.
> >
> > Benjy,
> > AWWTF
> >
>
> I wonder if is possible to build a multipart rpm format, so by looking
> at it's header you could determine you only need the first x bytes,
> which would be the incremental binary patches between it and the last
> couple of versions (depending on how much extra space you want to take
> up). It might be possible to mark this first part so it will be
> ignored by earlier versions of yum/rpm. Can someone with a good
> understanding of the rpm format and how it is parsed comment on this
> idea?
>
> I am thinking something like this:
> [|header|incremental_patch_1|incremental_patch_2|...|]|normal_rpm_data
>
> Where the stuff in [] is (if possible) formatted so the current rpm
> system ignores it.
> Depending on what percentage of the filesize you want to take up with
> binary patches, there will be anywhere from 0 patches (and no header
> since it's not needed), to a patch between every previous version (if
> they're only a couple of kb each, it shouldn't hurt).
> The header would contain the offsets for all the patches, sha1 sums of
> each piece, and version numbers so the reader could determine which
> ones it needs. If missing one of the patches it would just proceed to
> download the whole rpm and update normally.
> Each patch should have hashes for each file that needs updating and if
> any one of these don't match the files on the disk, it proceeds to
> download the rest of the rpm and update normally.
>
> I don't know if I agree that this needs corporate funding and years of
> work. I think a system like this could be written in under a year by
> volunteers.
>
> n0dalus.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

hopefully there will be patches for src rpms too then *rolls eyes*,
else i dont know how a regular hobby dev would be able to fix or
enhance stuff.

also take a look at: http://freshmeat.net/projects/rpmdc/. you can
just go ahead and start your delta mirror, no one is holding you back.

while it would be nice to save bandwidth on updates i think that the
potential backdraws are worse than the gain can ever be.

regards,
Rudolf Kastl

p.s. id be alot happier if people were able to really look up stuff on
the net first before kicking off major "must have, must be" or similar
ideas simply cause you are pushing people to do some work without
having done your own work on looking up the alternatives etc...



From knutjbj at online.no  Tue Nov 29 08:35:32 2005
From: knutjbj at online.no (Knut J Bjuland)
Date: Tue, 29 Nov 2005 09:35:32 +0100
Subject: gcc in rawhide.
Message-ID: <438C12D4.4080607@online.no>

When'll gcc in rawhide be update since gcc in update-test in newer than
gcc in rawhide.



From jakub at redhat.com  Tue Nov 29 08:38:11 2005
From: jakub at redhat.com (Jakub Jelinek)
Date: Tue, 29 Nov 2005 03:38:11 -0500
Subject: gcc in rawhide.
In-Reply-To: <438C12D4.4080607@online.no>
References: <438C12D4.4080607@online.no>
Message-ID: <20051129083811.GS31785@devserv.devel.redhat.com>

On Tue, Nov 29, 2005 at 09:35:32AM +0100, Knut J Bjuland wrote:
> When'll gcc in rawhide be update since gcc in update-test in newer than
> gcc in rawhide.

As soon as gcc-4.1.0-0.x is in a usable shape, we are working on it.

	Jakub



From jdesbonnet at gmail.com  Tue Nov 29 08:52:05 2005
From: jdesbonnet at gmail.com (Joe Desbonnet)
Date: Tue, 29 Nov 2005 08:52:05 +0000
Subject: Modern Update System
In-Reply-To: <d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
Message-ID: <1cef3e950511290052pa740b8aoc68b2d91837ab573@mail.gmail.com>

I did a fair bit of work on this earlier on the year. Anything that
involved modifying the existing infrastructure would never work, so
the approach I took was a virtual repository (running on localhost or
on LAN) which worked with a remote delta repository to produce a
virtual repository that delivered full updated RPMs without all the
bandwidth.

See here: http://www.wombat.ie/software/rpmdc/

Contact me off-line if you wish to discuss further.

Joe.


On 11/29/05, Benjy Grogan <benjy.grogan at gmail.com> wrote:

> Implementing the delta updates with the yum plugin is perfect.  I'm going to
> follow this up and see what I can learn.  I hope there are others out there
> as well that are interested in working on this.  It's not my idea, but
> definitely needed your comments below to move this idea forward.
>



From mls at suse.de  Tue Nov 29 09:24:14 2005
From: mls at suse.de (Michael Schroeder)
Date: Tue, 29 Nov 2005 10:24:14 +0100
Subject: Modern Update System
In-Reply-To: <d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
Message-ID: <20051129092414.GA5877@suse.de>

On Mon, Nov 28, 2005 at 11:19:03PM -0500, Benjy Grogan wrote:
> Please, this is ridiculous.  Of course it's possible.  You make a decision:
> i) will a few patches be small/easy to install ii) should i generate a
> unified patch for this user iii) situation is so bad, just send a whole new
> rpm...  and there the repository has done some work and come up with the
> best solution for you.  ... and yes, there are many more decisions.. such as
> cross-package decisions etc...  but this is an absolute must for the next
> gen linux distros.
> 
> What's Redhat doing?  What's Novell doing?

Novell has patchrpms and deltarpms.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From mls at suse.de  Tue Nov 29 09:33:48 2005
From: mls at suse.de (Michael Schroeder)
Date: Tue, 29 Nov 2005 10:33:48 +0100
Subject: Modern Update System
In-Reply-To: <d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
References: <1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
Message-ID: <20051129093348.GB5877@suse.de>

On Tue, Nov 29, 2005 at 01:51:39AM -0500, Benjy Grogan wrote:
> Yeah, that's what I'm starting to think.  Having to have the initial rpm on
> your hard drive all the time would be another kind of waste.
> 
> It comes down to more fundamental changes.  If the method of keeping rpms on
> your hard drive is ditched then you're left with sending pure binary patches
> to the actual files.  That's the best way, but a complete reorganization is
> then needed.
> 
> Sounds like one of these long projects that requires corporate funding to
> see it through a few years work.  I think it's an important enough challenge
> to tackle that Red Hat, IBM and Novell should work together to do this.
> 
> It's alot of work any way it's done.  Best to go for the best solution and
> find some backing and then hope everyone interested shows up to help out.

Guys, the deltarpm package already does all this. It doesn't need
to initial rpm on the harddisk, it can work with the installed files.
The current version even has a 'combinedeltarpm' command, so you
can collapse a chain of deltas into a single one.

Novell uses deltarpms since over a year now, mandriva-2005 has
them as well.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From fedora at iagorubio.com  Tue Nov 29 10:23:06 2005
From: fedora at iagorubio.com (Iago Rubio)
Date: Tue, 29 Nov 2005 11:23:06 +0100
Subject: Modern Update System
In-Reply-To: <1133225199.24512.113.camel@prometheus.gamehouse.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
Message-ID: <1133259787.4802.29.camel@speedy.iagorubio.net>

On Mon, 2005-11-28 at 16:46 -0800, Jesse Keating wrote:
> Been discussed ad-nasuem.  (did I spell that right?)

Nope :) 

That's latin ad-nauseam ... "to nausea/loathing" ... nausea - as in
english - is the word's latin root.

http://dictionary.reference.com/search?q=nausea

You can find ad-nauseum as well.

Cheers
-- 
Iago Rubio



From fedora at iagorubio.com  Tue Nov 29 11:11:34 2005
From: fedora at iagorubio.com (Iago Rubio)
Date: Tue, 29 Nov 2005 12:11:34 +0100
Subject: [OT] Re: Modern Update System
In-Reply-To: <1133259787.4802.29.camel@speedy.iagorubio.net>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133259787.4802.29.camel@speedy.iagorubio.net>
Message-ID: <1133262694.4802.57.camel@speedy.iagorubio.net>

On Tue, 2005-11-29 at 11:23 +0100, Iago Rubio wrote:
> On Mon, 2005-11-28 at 16:46 -0800, Jesse Keating wrote:
> > Been discussed ad-nasuem.  (did I spell that right?)
> 
> Nope :) 
> 
> That's latin ad-nauseam ... "to nausea/loathing" ... nausea - as in
> english - is the word's latin root.
> 
> http://dictionary.reference.com/search?q=nausea
> 
> You can find ad-nauseum as well.
> 
> Cheers

Sorry it was meant to be a private mail to Jesse, but my fingers slipped
badly ...
-- 
Iago Rubio



From dwmw2 at infradead.org  Tue Nov 29 11:18:09 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 29 Nov 2005 11:18:09 +0000
Subject: [OT] Re: Modern Update System
In-Reply-To: <1133262694.4802.57.camel@speedy.iagorubio.net>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133259787.4802.29.camel@speedy.iagorubio.net>
	<1133262694.4802.57.camel@speedy.iagorubio.net>
Message-ID: <1133263089.31573.145.camel@baythorne.infradead.org>

On Tue, 2005-11-29 at 12:11 +0100, Iago Rubio wrote:
> Sorry it was meant to be a private mail to Jesse, but my fingers
> slipped badly ...

No, you were tricked. http://www.unicom.com/pw/reply-to-harmful.html

-- 
dwmw2




From mpeters at mac.com  Tue Nov 29 11:27:54 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 29 Nov 2005 03:27:54 -0800
Subject: Modern Update System
In-Reply-To: <1133232911.5030.16.camel@dhollis-lnx.sunera.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
Message-ID: <1133263674.753.18.camel@locolhost.localdomain>

On Mon, 2005-11-28 at 21:55 -0500, David Hollis wrote:
>  What would really be the best answer to this would be having
> anaconda have the ability to pull down updates from a yum repo during
> install, so instead of installing package Z only to have it updated to a
> patched version right after reboot, it's all done on the first shot.  If
> you maintain a large number of systems, just make a mirror of the Fedora
> updates to keep the traffic local.

I'm working on something like that for myself - what I'm doing though
isn't using anaconda. It's using a "live CD" - well, DVD actually -
boots into a basic gnome desktop environment.

Installer installs (OK - I haven't finished yet) via yum from a local
repository on the DVD. It will have the option to bring up network and
use an updates repository to grab the newest if so desired - though it
would increase install time if you don't have a local mirror (and even
then it probably would too)

Anyway - my goal is for an Mac OS 7/8/9 type installer - simple gui, gui
partition tool if you don't want Linux to be the only OS (or want custom
partitioning), maybe some repair utilities, only two install options -
gnome desktop (no devel packages) and devel (gnome desktop + devel
environment)

But I'm far from done. I'm using a rather neat live CD project called
adios as the base for my live DVD.

Anyway - not really on topic, but what I'm looking to do is to create
something that is easy for OEM's to distribute and modify (IE if they
licensed additional gstreamer plugins from fluendo, or additional fonts,
etc. - they could add the rpm's and update the group list and be done)

There is a potential problem though - if a mirror has not synced, it
could cause an installation failure. So I'm not sure that it would be
appropriate for Anaconda to do it.



From buildsys at redhat.com  Tue Nov 29 11:40:39 2005
From: buildsys at redhat.com (Build System)
Date: Tue, 29 Nov 2005 06:40:39 -0500
Subject: rawhide report: 20051129 changes
Message-ID: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>

 

 
Updated Packages:

adaptx-0:0.9.6-1jpp_2fc
-----------------------
* Tue Nov 22 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:0.9.6-1jpp_2fc
- BZ 162481:
  src/main/org/exolab/adaptx/xslt/util/Configuration.java
  and
  src/main/org/exolab/adaptx/xml/parser/XercesParser.java
  both depend on org.apache.xerces.*
  This change makes this dependency explicit.

antlr-0:2.7.4-2jpp_4fc
----------------------
* Mon Nov 28 2005 Vadim Nasardinov <vadimn at redhat.com> - 0:2.7.4-2jpp_4fc
- Reverted the previous change.

dmidecode-1:2.7-1.19
--------------------
* Mon Nov 28 2005 Dave Jones <davej at redhat.com>
- Integrate several specfile cleanups from Robert Scheck. (#172543)

finger-0.17-30
--------------
* Mon Nov 28 2005 Radek Vokal <rvokal at redhat.com> 0.17-30
- make finger UTF-8 happy (#174352)

gnome-power-manager-0.3.1-1
---------------------------
* Mon Nov 28 2005 Christopher Aillon <caillon at redhat.com> 0.3.1-1
- Update to 0.3.1

* Fri Nov 25 2005 Christopher Aillon <caillon at redhat.com> 0.3.0-1
- Update to 0.3.0

gnome-terminal-2.12.0-2
-----------------------
* Mon Nov 28 2005 Matthias Clasen <mclasen at redhat.com> - 2.12.0-2
- Respect the show_input_method_menu setting.

gtk2-2.8.8-1
------------
* Mon Nov 28 2005 Matthias Clasen <mclasen at redhat.com> 2.8.8-1
- Update to 2.8.8

imake-0.99.2-5
--------------
* Mon Nov 28 2005 Than Ngo <than at redhat.com> 0.99.2-5
- add correct ProjectRoot for modular X

kdebase-6:3.5.0-0.1.rc2
-----------------------
* Mon Nov 28 2005 Than Ngo <than at redhat.com> 3.5.0-0.1.rc2
- 3.5 rc2

* Sat Nov 19 2005 Bill Nottingham <notting at redhat.com>
- fix paths to openmotif

kdelibs-6:3.5.0-0.1.rc2
-----------------------
* Mon Nov 28 2005 Than Ngo <than at redhat.com> 6:3.5.0-0.1.rc2
- 3.5 rc2

* Mon Nov 14 2005 Than Ngo <than at redhat.com> 6:3.5.0-0.1.rc1
- update 3.5.0 rc1
- remove unneeded lnusertemp workaround
- remove references to optional libraries in .la files #170602

kernel-2.6.14-1.1719_FC5
------------------------
* Tue Nov 29 2005 Dave Jones <davej at redhat.com>
- 2.6.15rc3

* Mon Nov 28 2005 Dave Jones <davej at redhat.com>
- Additional ID for Conexant AccessRunner USB driver (#174339)

* Mon Nov 28 2005 David Woodhouse <dwmw2 at redhat.com>
- Fix RX packet alignment and multicast on MV643xx Ethernet

libc-client-2002e-16
--------------------
* Wed Nov 23 2005 Nalin Dahyabhai <nalin at redhat.com> 2002e-16
- rebuild

* Wed Nov 23 2005 Nalin Dahyabhai <nalin at redhat.com> 2002e-15
- rebuild

* Wed Nov 23 2005 Nalin Dahyabhai <nalin at redhat.com> 2002e-14
- rebuild

libgnomeui-2.12.0-6
-------------------
* Mon Nov 28 2005 Ray Strode <rstrode at redhat.com> - 2.12.0-6
- Add libSM-devel/libICE-devel requires for libgnomeui-devel 
  (bug 173610)

libselinux-1.27.23-1
--------------------
* Mon Nov 28 2005 Dan Walsh <dwalsh at redhat.com> 1.27.23-1
* Merged swigify patch from Dan Walsh.

* Mon Nov 28 2005 Dan Walsh <dwalsh at redhat.com> 1.27.22-4
- Separate out libselinux-python bindings into separate rpm

libsemanage-1.3.59-1
--------------------
* Wed Nov 23 2005 Dan Walsh <dwalsh at redhat.com> 1.3.59-1
- Add additional swig objects
	* Merged wrap char*** for user_get_roles patch from Joshua Brindle.
	* Merged remove defrole from sepol patch from Ivan Gyurdiev.
	* Merged swig wrappers for modifying users and seusers from Joshua Brindle.

libsepol-1.9.41-1
-----------------
* Mon Nov 28 2005 Dan Walsh <dwalsh at redhat.com> 1.9.41-1
- Upgrade to latest from NSA
	* Merged remove defrole from sepol patch from Ivan Gyurdiev.

* Wed Nov 16 2005 Dan Walsh <dwalsh at redhat.com> 1.9.40-1
- Upgrade to latest from NSA
	* Merged module function and map file cleanup from Ivan Gyurdiev.
	* Merged MLS and genusers cleanups from Ivan Gyurdiev.

* Wed Nov 09 2005 Dan Walsh <dwalsh at redhat.com> 1.9.39-1
- Upgrade to latest from NSA
	Prepare for removal of booleans* and *.users files.
	* Cleaned up sepol_genbools to not regenerate the image if
	  there were no changes in the boolean values, including the
	  degenerate case where there are no booleans or booleans.local
	  files.
	* Cleaned up sepol_genusers to not warn on missing local.users.

pango-1.10.2-1
--------------
* Tue Nov 29 2005 Matthias Clasen <mclasen at redhat.com> - 1.10.2-1
- Update to 1.10.2

policycoreutils-1.27.29-1
-------------------------
* Mon Nov 28 2005 Dan Walsh <dwalsh at redhat.com> 1.27.29-3
- Update to match NSA
	* Merged audit2allow python script from Dan Walsh.
	  (old script moved to audit2allow.perl, will be removed later).
	* Merged genhomedircon fixes from Dan Walsh.
	* Merged semodule quieting patch from Dan Walsh
	  (inverts default, use -v to restore original behavior).

rsh-0.17-33
-----------
* Mon Nov 28 2005 Karel Zak <kzak at redhat.com> 0.17-33
- fix #174146 - pam_access.so does not work with rexecd

selinux-policy-2.0.6-1
----------------------

system-config-bind-4.0.0-32_FC5
-------------------------------
* Mon Nov 28 2005 Jason Vas Dias <jvdias at redhat.com> - 4.0.0-32
- fix bug 174284: Lookup.py failed when hostname matches IP
		  address regexps and has no DNS record

xorg-x11-server-utils-0.99.2-6
------------------------------
* Mon Nov 28 2005 Mike A. Harris <mharris at redhat.com> 0.99.2-6
- Added "Requires: cpp" as xrdb requires it for proper operation (#174302)

Broken deps for i386
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp
	gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5



Broken deps for ia64
----------------------------------------------------------
	rgmanager - 1.9.31-3.ia64 requires ccs



Broken deps for ppc
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11
	gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11



Broken deps for ppc64
----------------------------------------------------------
	cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11
	dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11
	emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi
	gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11









Broken deps for x86_64
----------------------------------------------------------
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5
	gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5





From mpeters at mac.com  Tue Nov 29 12:47:20 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 29 Nov 2005 04:47:20 -0800
Subject: fc5 goals
In-Reply-To: <1133217858.11240.8.camel@rousalka.dyndns.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
Message-ID: <1133268440.753.24.camel@locolhost.localdomain>

On Mon, 2005-11-28 at 23:44 +0100, Nicolas Mailhot wrote:
> Le lundi 28 novembre 2005 ? 14:15 -0800, Jesse Keating a ?crit :
> 
> > The question is why are these pieces of software in Fedora CORE vs
> > Fedora EXTRAS.  I don't think anybody is complaining that the software
> > is a part of the Fedora Project itself, just where they should land.
> > Core or Extras.
> 
> Actually I for example don't use KDE, and don't care if it's in core or
> extras.
> 
> What I do care about is Gnome depending on arts.

Unless it has changed - the only reason Gnome depends upon arts is one
single gstreamer plugin.

I filed an RFE to have it split into a separate package awhile ago (I
think pre FC3) and was told it wasn't worth it - even though without
that plugin, I wouldn't need either arts or qt (both of which I never
use)

> 
> I'd rather people spent more time untangling this kind of stupid
> cross-dependencies than arguing what needs to be made second-class
> citizen.

Modularization hopefully will fix that - if it is applied to things like
gstreamer plugins (which is where the arts is pulled in)

Some other apps (ie mplayer in livna) also want it - but only because
they are generic onesizefitsall builds, due to a lack of a proper plugin
architecture (like gstreamer provides)

If you really want the qt/arts cross dependency from gnome removed -
file a bug with gstreamer-plugins.



From janina at rednote.net  Tue Nov 29 13:02:52 2005
From: janina at rednote.net (Janina Sajka)
Date: Tue, 29 Nov 2005 08:02:52 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051126143949.GA2261@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
Message-ID: <20051129130252.GF7549@rednote.net>

Matthew Miller writes:
> On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote:
> > In a lot of cases, packages which aren't listed in the comps file at all
> > (or aren't a dependency of something) perhaps _should_ move to Extras.
> > In addition, I think there probably are packages which should move
> > somewhere into the comps file.  File bugs against comps for things that
> > should be listed and aren't.
> 
> How about making Anaconda always only do a minimal install, and make
> firstboot have the option to install other things if you want 'em? :)


Have you forgotten firsboot is inaccessible? You do care about that,
right?

> 
> -- 
> Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
> Boston University Linux      ------>              <http://linux.bu.edu/>
> 
> -- 
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list

-- 

Janina Sajka				Phone: +1.240.715.1272
Partner, Capital Accessibility LLC	http://www.CapitalAccessibility.Com

Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://www.ScreenlessPhone.Com to learn more.

Chair, Accessibility Workgroup		Free Standards Group (FSG)
janina at freestandards.org		http://a11y.org



From mattdm at mattdm.org  Tue Nov 29 13:14:14 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 29 Nov 2005 08:14:14 -0500
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051129130252.GF7549@rednote.net>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<20051129130252.GF7549@rednote.net>
Message-ID: <20051129131414.GA30136@jadzia.bu.edu>

On Tue, Nov 29, 2005 at 08:02:52AM -0500, Janina Sajka wrote:
> > How about making Anaconda always only do a minimal install, and make
> > firstboot have the option to install other things if you want 'em? :)
> Have you forgotten firsboot is inaccessible? You do care about that,
> right?

I *do* care about that. Firstboot should be available in text-only mode for
use with screenreaders.

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66731>


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From khc at pm.waw.pl  Tue Nov 29 13:14:08 2005
From: khc at pm.waw.pl (Krzysztof Halasa)
Date: Tue, 29 Nov 2005 14:14:08 +0100
Subject: Modern Update System
In-Reply-To: <1133232911.5030.16.camel@dhollis-lnx.sunera.com> (David
	Hollis's message of "Mon, 28 Nov 2005 21:55:11 -0500")
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
Message-ID: <m3oe431uff.fsf@defiant.localdomain>

David Hollis <dhollis at davehollis.com> writes:

> If
> you maintain a large number of systems, just make a mirror of the Fedora
> updates to keep the traffic local.

Or one can share /var/spool/yum, especially with extras etc. it's much
smaller.
It would be nice if yum could export a list of needed packages instead
of downloading them (operating with R/O /var/spool/yum). Or maybe it's
already possible?
-- 
Krzysztof Halasa



From che666 at gmail.com  Tue Nov 29 13:24:00 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Tue, 29 Nov 2005 14:24:00 +0100
Subject: fc5 goals
In-Reply-To: <1133268440.753.24.camel@locolhost.localdomain>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<1133268440.753.24.camel@locolhost.localdomain>
Message-ID: <e99d27470511290524m67e0c652h@mail.gmail.com>

2005/11/29, Michael A. Peters <mpeters at mac.com>:
> On Mon, 2005-11-28 at 23:44 +0100, Nicolas Mailhot wrote:
> > Le lundi 28 novembre 2005 ? 14:15 -0800, Jesse Keating a ?crit :
> >
> > > The question is why are these pieces of software in Fedora CORE vs
> > > Fedora EXTRAS.  I don't think anybody is complaining that the software
> > > is a part of the Fedora Project itself, just where they should land.
> > > Core or Extras.
> >
> > Actually I for example don't use KDE, and don't care if it's in core or
> > extras.
> >
> > What I do care about is Gnome depending on arts.
>
> Unless it has changed - the only reason Gnome depends upon arts is one
> single gstreamer plugin.
>
> I filed an RFE to have it split into a separate package awhile ago (I
> think pre FC3) and was told it wasn't worth it - even though without
> that plugin, I wouldn't need either arts or qt (both of which I never
> use)

whats the bugzilla id? this sounds like "definitely worth it" to me.

>
> >
> > I'd rather people spent more time untangling this kind of stupid
> > cross-dependencies than arguing what needs to be made second-class
> > citizen.
>
> Modularization hopefully will fix that - if it is applied to things like
> gstreamer plugins (which is where the arts is pulled in)
>
> Some other apps (ie mplayer in livna) also want it - but only because
> they are generic onesizefitsall builds, due to a lack of a proper plugin
> architecture (like gstreamer provides)
>
> If you really want the qt/arts cross dependency from gnome removed -
> file a bug with gstreamer-plugins.
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From mailinglists at erwinrol.com  Tue Nov 29 13:38:08 2005
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Tue, 29 Nov 2005 14:38:08 +0100
Subject: kernel bad locking
Message-ID: <1133271488.3861.0.camel@xpc.home.erwinrol.com>

Hey all,

Since kernel > 2.6.14-1.1709_FC5 (including 2.6.14-1.1719_FC5) I get the
following kernel panic when booting;

Starting udev: [OK]
Initializing hardware... Kernel panic - not syncing: bad locking

This is on a x86_64 machine in 64bit mode, the last kernel that works OK
is 2.6.14-1.1709_FC5 Any idea what the problem might be ?

- Erwin




From michel.mengis at epfl.ch  Tue Nov 29 12:47:43 2005
From: michel.mengis at epfl.ch (Michel MENGIS)
Date: Tue, 29 Nov 2005 13:47:43 +0100
Subject: RHGB bug when using fr_CH keyboard.
Message-ID: <200511291348.jATDmkSU022989@mx3.redhat.com>

Hi there,

Here in swiss we are using fr_CH keyboards. Each time we are installing a
FC4, firstboot runs in FR keyboard layout. So it's difficult to add user at
firstboot. 

Here is a little patch to allow rhgb to run in fr_CH keyboard layout when
/etc/sysconfig/keyboard KEYTABLE key is set to fr_CH or fr_CH-latin1. 

Why is the "check_for_language" function in main.c splitting by the key "_"?

Best regards,

Michel MENGIS__________________________
POSEIDON Project Manager
EPFL - DIT - DIT-SB
Ecole Polytechnique F?d?rale de Lausanne - EPFL
Tel: (+41) 021 693 2266




-------------- next part --------------
A non-text attachment was scrubbed...
Name: rhgb.patch
Type: text/x-patch
Size: 998 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051129/a17faa54/attachment.bin>

From arjan at fenrus.demon.nl  Tue Nov 29 13:50:55 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 29 Nov 2005 14:50:55 +0100
Subject: kernel bad locking
In-Reply-To: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
Message-ID: <1133272255.2804.39.camel@laptopd505.fenrus.org>

On Tue, 2005-11-29 at 14:38 +0100, Erwin Rol wrote:
> Hey all,
> 
> Since kernel > 2.6.14-1.1709_FC5 (including 2.6.14-1.1719_FC5) I get the
> following kernel panic when booting;
> 
> Starting udev: [OK]
> Initializing hardware... Kernel panic - not syncing: bad locking
> 
> This is on a x86_64 machine in 64bit mode, the last kernel that works OK
> is 2.6.14-1.1709_FC5 Any idea what the problem might be ?

to diagnose this a backtrace is needed... was one on the screen? if not,
try removing "quiet" from the kernel command line...



From dwmw2 at infradead.org  Tue Nov 29 13:57:07 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 29 Nov 2005 13:57:07 +0000
Subject: kernel bad locking
In-Reply-To: <1133272255.2804.39.camel@laptopd505.fenrus.org>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
Message-ID: <1133272627.31573.157.camel@baythorne.infradead.org>

On Tue, 2005-11-29 at 14:50 +0100, Arjan van de Ven wrote:
> to diagnose this a backtrace is needed... was one on the screen? if
> not, try removing "quiet" from the kernel command line...

I think that's our stupid default loglevel hiding it.
It's bug #174438, anyway.

-- 
dwmw2

-------------- next part --------------
An embedded message was scrubbed...
From: David Brownell <david-b at pacbell.net>
Subject: Re: Latest GIT: USB ehci_hcd broken (spinlock corruption)
Date: Mon, 28 Nov 2005 08:40:38 -0800
Size: 6777
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051129/670f28f7/attachment.eml>

From fedora at iagorubio.com  Tue Nov 29 13:57:56 2005
From: fedora at iagorubio.com (Iago Rubio)
Date: Tue, 29 Nov 2005 14:57:56 +0100
Subject: [OT] Re: Modern Update System
In-Reply-To: <1133263089.31573.145.camel@baythorne.infradead.org>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133259787.4802.29.camel@speedy.iagorubio.net>
	<1133262694.4802.57.camel@speedy.iagorubio.net>
	<1133263089.31573.145.camel@baythorne.infradead.org>
Message-ID: <1133272676.4802.80.camel@speedy.iagorubio.net>

On Tue, 2005-11-29 at 11:18 +0000, David Woodhouse wrote:
> On Tue, 2005-11-29 at 12:11 +0100, Iago Rubio wrote:
> > Sorry it was meant to be a private mail to Jesse, but my fingers
> > slipped badly ...
> 
> No, you were tricked. http://www.unicom.com/pw/reply-to-harmful.html

Thanks for the hint, I was wondering how it had happened.

It won't happen anymore. To avoid this ill munging I added to my
~/.procmailrc

:0 fhw
* ^Reply-To: *fedora-devel-list at redhat.com*
| formail -IReply-To: 

List admins have they choices, but we've got ours too :)

Thanks again.
-- 
Iago Rubio



From jspaleta at gmail.com  Tue Nov 29 13:59:30 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 08:59:30 -0500
Subject: kernel bad locking
In-Reply-To: <1133272255.2804.39.camel@laptopd505.fenrus.org>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
Message-ID: <604aa7910511290559j17ee9e1ai7674ca5449c0ce40@mail.gmail.com>

On 11/29/05, Arjan van de Ven <arjan at fenrus.demon.nl> wrote:
> to diagnose this a backtrace is needed... was one on the screen? if not,
> try removing "quiet" from the kernel command line...

Just an FYI, I'm getting the exact same thing on a x86 system using
the smp kernel
the last kernel to work for me was kernel-smp-2.6.14-1.1696_FC5.i686

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174199

-jef



From mailinglists at erwinrol.com  Tue Nov 29 14:22:15 2005
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Tue, 29 Nov 2005 15:22:15 +0100
Subject: kernel bad locking
In-Reply-To: <1133272255.2804.39.camel@laptopd505.fenrus.org>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
Message-ID: <1133274135.3618.3.camel@xpc.home.erwinrol.com>

David Woodhouse is right, it is bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174438
after i added the "dontpanic" option i got about the same trace, into
ehci_hcd : ehci_port_power.
 
- Erwin

On Tue, 2005-11-29 at 14:50 +0100, Arjan van de Ven wrote:
> On Tue, 2005-11-29 at 14:38 +0100, Erwin Rol wrote:
> > Hey all,
> > 
> > Since kernel > 2.6.14-1.1709_FC5 (including 2.6.14-1.1719_FC5) I get the
> > following kernel panic when booting;
> > 
> > Starting udev: [OK]
> > Initializing hardware... Kernel panic - not syncing: bad locking
> > 
> > This is on a x86_64 machine in 64bit mode, the last kernel that works OK
> > is 2.6.14-1.1709_FC5 Any idea what the problem might be ?
> 
> to diagnose this a backtrace is needed... was one on the screen? if not,
> try removing "quiet" from the kernel command line...
> 



From harald at redhat.com  Tue Nov 29 14:27:55 2005
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 29 Nov 2005 15:27:55 +0100
Subject: udev alpha testing
Message-ID: <438C656B.2080701@redhat.com>

I would be glad, if the really brave could compile, install and test:
ftp://people.redhat.com/harald/udev/076-1/

Beware this could end in a non-bootable system.

This version removes the hardware initializing/module loading phase from rc.sysinit. Udev should do most, if 
not all job. I am interested in any missing modules, that were loaded before.

Thx for testing.

--
Harald



From mpeters at mac.com  Tue Nov 29 14:46:59 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 29 Nov 2005 06:46:59 -0800
Subject: fc5 goals
In-Reply-To: <e99d27470511290524m67e0c652h@mail.gmail.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<1133268440.753.24.camel@locolhost.localdomain>
	<e99d27470511290524m67e0c652h@mail.gmail.com>
Message-ID: <1133275619.753.27.camel@locolhost.localdomain>

On Tue, 2005-11-29 at 14:24 +0100, Rudolf Kastl wrote:
> 2005/11/29, Michael A. Peters <mpeters at mac.com>:
> > On Mon, 2005-11-28 at 23:44 +0100, Nicolas Mailhot wrote:
> > > Le lundi 28 novembre 2005 ? 14:15 -0800, Jesse Keating a ?crit :
> > >
> > > > The question is why are these pieces of software in Fedora CORE vs
> > > > Fedora EXTRAS.  I don't think anybody is complaining that the software
> > > > is a part of the Fedora Project itself, just where they should land.
> > > > Core or Extras.
> > >
> > > Actually I for example don't use KDE, and don't care if it's in core or
> > > extras.
> > >
> > > What I do care about is Gnome depending on arts.
> >
> > Unless it has changed - the only reason Gnome depends upon arts is one
> > single gstreamer plugin.
> >
> > I filed an RFE to have it split into a separate package awhile ago (I
> > think pre FC3) and was told it wasn't worth it - even though without
> > that plugin, I wouldn't need either arts or qt (both of which I never
> > use)
> 
> whats the bugzilla id? this sounds like "definitely worth it" to me.

Whoa - first time ever I have found a closed bug I looked for on the
first search.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135841



From dravet at hotmail.com  Tue Nov 29 14:51:17 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Tue, 29 Nov 2005 08:51:17 -0600
Subject: udev alpha testing
Message-ID: <BAY103-F261D29FEFC5C18059CD591DF4B0@phx.gbl>

>I would be glad, if the really brave could compile, install and test:
>ftp://people.redhat.com/harald/udev/076-1/
>
>Beware this could end in a non-bootable system.
>
>This version removes the hardware initializing/module loading phase from 
>rc.sysinit. Udev should do most, if not all job. I am interested in any 
>missing modules, that were loaded before.
>
>Thx for testing.

I will test these for you.  I have downloaded both src.rpm files and I will 
be doing a rpmbuild --rebuild on them shortly.  I have a few other things I 
have to get done today so it might later today or tomorrow before I post any 
results.  Is this alright with you?

If something does go wrong, is there an easy way to get back running without 
a full restore?  Will booting in single user mode and reinstalling 
udev-075-4 get the system running again?
Thanks,
Jason




From bart.vanbrabant at zoeloelip.be  Tue Nov 29 15:01:04 2005
From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant)
Date: Tue, 29 Nov 2005 16:01:04 +0100
Subject: udev alpha testing
In-Reply-To: <438C656B.2080701@redhat.com>
References: <438C656B.2080701@redhat.com>
Message-ID: <438C6D30.1090403@zoeloelip.be>

Harald Hoyer wrote:
> I would be glad, if the really brave could compile, install and test:
> ftp://people.redhat.com/harald/udev/076-1/
>
> Beware this could end in a non-bootable system.
>
> This version removes the hardware initializing/module loading phase
> from rc.sysinit. Udev should do most, if not all job. I am interested
> in any missing modules, that were loaded before.
>
> Thx for testing.
>
> -- 
> Harald
>
The udev srpm doesn't seem to compile on the lastest rawhide. I get this
output when I do $ rpmbuild --rebuild udev-076-1.src.rpm

[root at laptop-bart tmp]# rpmbuild --rebuild udev-076-1.src.rpm
Installing udev-076-1.src.rpm
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
warning: user harald does not exist - using root
warning: group harald does not exist - using root
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.57665
+ umask 022
+ cd /usr/src/redhat/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /usr/src/redhat/BUILD
+ rm -rf udev-076
+ /usr/bin/bzip2 -dc /usr/src/redhat/SOURCES/udev-076.tar.bz2
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd udev-076
++ /usr/bin/id -u
+ '[' 0 = 0 ']'
+ /bin/chown -Rhf root .
++ /usr/bin/id -u
+ '[' 0 = 0 ']'
+ /bin/chgrp -Rhf root .
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #1 (udev-075-daemon.patch):'
Patch #1 (udev-075-daemon.patch):
+ patch -p1 -b --suffix .udevdaemon -s
+ cp /usr/src/redhat/SOURCES/udev.html .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.3874
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd udev-076
+ LANG=C
+ export LANG
+ unset DISPLAY
+ make USE_KLIBC=false USE_SELINUX=true USE_STATIC=true STRIP=/bin/true
udevdir=/dev USE_LOG=false DEBUG=false 'EXTRAS=        
extras/scsi_id          extras/ata_id         extras/usb_id        
extras/edd_id         extras/volume_id    ' all
Creating udev_version.h
Compiling sysfs_class.c:                                              [OK]
Compiling sysfs_device.c:                                             [OK]
Compiling sysfs_dir.c:                                                [OK]
Compiling sysfs_driver.c:                                             [OK]
Compiling sysfs_utils.c:                                              [OK]
Compiling dlist.c:                                                    [OK]
Creating library libsysfs.a:                                          [OK]
Running ranlib:                                                       [OK]
Compiling udev_event.c:                                               [OK]
Compiling udev_device.c:                                              [OK]
Compiling udev_config.c:                                              [OK]
Compiling udev_add.c:                                                 [OK]
Compiling udev_remove.c:                                              [OK]
Compiling udev_db.c:                                                  [OK]
Compiling udev_rules.c:                                               [OK]
Compiling udev_rules_parse.c:                                         [OK]
Compiling udev_utils.c:                                               [OK]
Compiling udev_utils_string.c:                                        [OK]
Compiling udev_utils_file.c:                                          [OK]
Compiling udev_utils_run.c:                                           [OK]
Compiling udev_libc_wrapper.c:                                        [OK]
Compiling udev_selinux.c:                                             [OK]
Creating library libudev.a:                                           [OK]
Running ranlib:                                                       [OK]
Compiling udev.c:                                                     [OK]
Linking udev:                                                        
[ERROR]
  gcc -Wl,-warn-common -static udev.o -o udev libudev.a
libsysfs/libsysfs.a -ls
  elinux -lsepol
  libudev.a(udev_device.o): In function `udev_init_device':
  /usr/src/redhat/BUILD/udev-076/udev_device.c:87: undefined reference
to `__ct
  ype_b at GLIBC_2.0'
  libudev.a(udev_config.o): In function `parse_config_file':
  /usr/src/redhat/BUILD/udev-076/udev_config.c:128: undefined reference
to `__c
  type_b at GLIBC_2.0'
  libudev.a(udev_config.o): In function `get_key':
  /usr/src/redhat/BUILD/udev-076/udev_config.c:56: undefined reference
to `__ct
  ype_b at GLIBC_2.0'
  libudev.a(udev_rules.o): In function `import_keys_into_env':
  /usr/src/redhat/BUILD/udev-076/udev_rules.c:179: undefined reference
to `__ct
  ype_b at GLIBC_2.0'
  libudev.a(udev_rules.o): In function `get_key':
  /usr/src/redhat/BUILD/udev-076/udev_rules.c:98: undefined reference to
`__cty
  pe_b at GLIBC_2.0'
 
libudev.a(udev_rules.o):/usr/src/redhat/BUILD/udev-076/udev_rules.c:280:
more
   undefined references to `__ctype_b at GLIBC_2.0' follow
  collect2: ld returned 1 exit status
make: *** [udev] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.3874 (%build)


Bart

-- 
Bart Vanbrabant <bart.vanbrabant at zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E  FC4F 84E1 FED1 E426 64D1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051129/590ea217/attachment.sig>

From ph18 at cornell.edu  Tue Nov 29 15:06:13 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 29 Nov 2005 10:06:13 -0500
Subject: fc5 goals
In-Reply-To: <438BBB6E.9070505@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>
Message-ID: <438C6E65.9030506@cornell.edu>

Bernardo Innocenti wrote:

>In my experience, DVD burners and readers are already much
>more common than plain CD recorders and readers.  Computers
>with no DVD readers are usually too old and slow to run a
>full featured Linux desktop comfortably, and if the current
>trend of adding features and complexity continues, it will
>become more and more true over time.
>  
>
    Hardly true.

    My Linux desktop at work is a 350 MhZ Pentium II -- an old IBM box 
that could probably survive a few bullets or being thrown down the 
stairs.  It's not an exciting machine,  but it ~never~ screws up.  I 
could get a newer Dell if I asked,  but the Dells have bad IDE 
controllers,  driver problems,  etc.

    I maxxed out the RAM to 388 MB and it runs RHEL 4 like a champ.  
There are probably some GUI apps that will floor it,  but nautilus is 
fine and I can have 50 xterms open,  a subversion server,  a daemon that 
collects SNMP data from 30+ hosts,  and it's just fine.



From dravet at hotmail.com  Tue Nov 29 15:11:15 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Tue, 29 Nov 2005 09:11:15 -0600
Subject: udev alpha testing
Message-ID: <BAY103-F9230265BE7366BC9FBFBADF4B0@phx.gbl>

>The udev srpm doesn't seem to compile on the lastest rawhide. I get this
>output when I do $ rpmbuild --rebuild udev-076-1.src.rpm
>
>[root laptop-bart tmp]# rpmbuild --rebuild udev-076-1.src.rpm
>Installing udev-076-1.src.rpm
>warning: user harald does not exist - using root
>warning: group harald does not exist - using root

I did a rpmbuild --rebuild udev-076-1.src.rpm and it worked for me.  I did 
get the warnings about user harald and group harald not existing.  I have 
installed todays rawhide, but I have not booting into the new kernel yet.  I 
am running kernel 1709 for now.  I will be rebooting shortly.  My system is 
a P3 if that helps.

Thanks,




From pedro.lamarao at mndfck.org  Tue Nov 29 11:37:29 2005
From: pedro.lamarao at mndfck.org (=?UTF-8?B?UGVkcm8gTGFtYXLDo28=?=)
Date: Tue, 29 Nov 2005 09:37:29 -0200
Subject: fc5 goals
In-Reply-To: <438BBB6E.9070505@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>
Message-ID: <dmhehp$oqu$1@sea.gmane.org>

Bernardo Innocenti wrote:

[SNIP]

> In my experience, DVD burners and readers are already much
> more common than plain CD recorders and readers.  Computers
> with no DVD readers are usually too old and slow to run a
> full featured Linux desktop comfortably, and if the current
> trend of adding features and complexity continues, it will
> become more and more true over time.

Please.

This may even be true in the country you live in, but let's keep things
under control for those of us with computers "too old" to have DVD
burners running a Fedora-based desktop just fine.

--
 Pedro Lamar?o



From ph18 at cornell.edu  Tue Nov 29 15:20:35 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 29 Nov 2005 10:20:35 -0500
Subject: Modern Update System
In-Reply-To: <20051128192340.602a02b1.zaitcev@redhat.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>	<1133225199.24512.113.camel@prometheus.gamehouse.com>	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
Message-ID: <438C71C3.5060601@cornell.edu>

Pete Zaitcev wrote:

>I am quite surprised that it works for Microsoft, because Sun gave it
>a good try. Maybe they just ignore most problems, like what happens
>when you upgrade a well-patched system to the next release.
>  
>
    Microsoft ships a lot less software with Windows than Sun ships with 
Solaris or Fedora ships with Linux.  That's why these comparisons that 
RHEL has 44 security bugs and Windows has 43 security bugs are a big 
joke,  because RHEL comes with 4 CD's of software and Windows only one.

    I think the "incremental patches" could be dealt with in a way 
that's mathematically well defined and wouldn't require thinking on 
anyone's part (it's the thinking that gets you in trouble.)  Imagine we 
have a package with the following history

package-1
package-2
package-3
package-4
package-5

Now,  we can generate something like xdiffs, so we have

package-diff-1-2
package-diff-2-3
package-diff-3-4
package-diff-4-5

these are actual diffs against the files in the filesystem.  When 
somebody installs package-1 out of the box,  and then does an update,  
the system can check that ~all~ files in package-1 are unchanged,  then 
it's safe to automatically download the diffs,  which put the system in 
the exact same state it would be in if we'd just installed package-5.  
If any files in package-1 have been touched,  then we have to do 
something different.

I totally understand why this would be a nightmare for the mirrors,  but 
the current status quo is a disaster in terms of user experience.  Every 
time I do a Fedora install,  I usually end up downloading 2 GB worth of 
ISO images,  and then I run "yum update" and it downloads another 1 GB 
worth of updates.

My experience with RHEL is even worse than that with Fedora,  partially 
because "up2date" scales less well than "yum."  Last time I installed 
RHEL 4,  up2date kept crashing,  and I tried different things until I 
realized I had to do updates to up2date and rpm to make up2date stable 
enough to complete.  I expect to have these problems with Rawhide,  but 
it's particularly irksome when the Red Hat Network (the product that I 
perceive I'm paying a significant annual fee for) is the part of the 
distribution which works the worst.



From jspaleta at gmail.com  Tue Nov 29 15:24:32 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 10:24:32 -0500
Subject: fc5 goals
In-Reply-To: <438C6E65.9030506@cornell.edu>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <438C6E65.9030506@cornell.edu>
Message-ID: <604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>

On 11/29/05, Paul A Houle <ph18 at cornell.edu> wrote:
>     Hardly true.

While I think he overstates the current situation by extrapolating his
personal experience, at some point though the ubiquity of dvd drives
will be true. I think we can hold-off on this debate until dell stops
offering models without atleast dvd read support. Dell still offers
dvd-less models in its home and home office value lines. On its N
series "open source friendly" every option in the customize menu has
atleast dvd read support... so the tipping point might be closer than
either you or I would like.

At some point it will make sense to drop the cdrom images and produce
only the dvd image. Just like it made sense to drop the i486 kernel. 
Once Dell makes dvd-read support compulsory for all its shipping
products its probably within 2 years (3~4 Core releases) after that
cdrom install images with be deprecated. I'll have to go out and buy a
$10 dvd burner at that point.

-jef



From dwmw2 at infradead.org  Tue Nov 29 15:30:51 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 29 Nov 2005 15:30:51 +0000
Subject: Modern Update System
In-Reply-To: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
Message-ID: <1133278251.31573.175.camel@baythorne.infradead.org>

On Mon, 2005-11-28 at 19:13 -0500, Benjy Grogan wrote:
> Is there any work being done for a modern update system that would
> only download what is needed instead of an entirely new rpm? 

One trick I've had moderate success with is to extract the RPM payload
(on the remote end) into a cpio file. Then create a cpio file locally
using the contents of the old package, and rsync the new cpio using the
old cpio as seed. Once that's done, recompress (using 'minigzip -9' so
that it precisely matches what RPM does) and then use that as seed for
rsyncing the RPM itself, just to get the header.

#!/bin/sh

export RSYNC_RSH=`which ssh`
REMOTETMPDIR=/tmp/getrpm-`hostname`-$$
LOCALTMPDIR=/tmp/getrpm-$$

REMOTEHOST=$1

if ! minigzip < /dev/null > /dev/null; then
    echo "minigzip not found. We need it to match rpm's compression"
    echo "Get the rpm source, build its minigzip using its zlib."
    echo "Stick it on your PATH somewhere"
    exit 1
fi

if [ -z $REMOTEHOST ]; then
    echo "Usage: $0 <remotehost> <rpm> [<rpm> ...]"
    exit 1
fi

if ! mkdir $LOCALTMPDIR; then
    echo "Cannot create temp directory $LOCALTMPDIR"
    exit 1
fi

if ! pushd $LOCALTMPDIR > /dev/null ; then
    echo "Change to local temporary directory failed";
    exit 1
fi

mkdir rpms

if ! ssh $REMOTEHOST mkdir $REMOTETMPDIR; then
    echo "Failed to create temp directory $REMOTETMPDIR on $REMOTEHOST"
    rmdir $LOCALTMPDIR
    exit 1
fi


shift

for PACKAGE in $* ; do
    if ! ssh $REMOTEHOST rpm -qp --queryformat="%{NAME}" $PACKAGE > packagename; then
        echo "Package listing for $REMOTEHOST:$PACKAGE failed"
        continue;
    fi
    PACKAGENAME=`cat packagename`
    if [ -z $PACKAGENAME ]; then
        echo "Error: No package name although command succeeded"
        continue;
    fi
    if rpm -ql $PACKAGENAME > files 2>/dev/null; then
        echo "Package $PACKAGENAME is currently installed. Using existing files as seed"
        cpio -Hnewc -o < files > $PACKAGENAME.cpio 2>/dev/null

        if ! ssh $REMOTEHOST rpm2cpio $PACKAGE \> $REMOTETMPDIR/$PACKAGENAME.cpio; then
            echo "Error: rpm2cpio of $REMOTEHOST:$PACKAGE failed"
            continue;
        fi

        if ! rsync -vz --progress $REMOTEHOST:$REMOTETMPDIR/$PACKAGENAME.cpio $PACKAGENAME.cpio; then
            echo "rsync of $PACKAGENAME.cpio failed"
            rm $PACKAGENAME.cpio
            continue
        fi
        ssh $REMOTEHOST rm $REMOTETMPDIR/$PACKAGENAME.cpio
        echo -n "Compressing $PACKAGENAME.cpio..."
        minigzip -9 $PACKAGENAME.cpio
        echo "done."
        mv $PACKAGENAME.cpio.gz `basename $PACKAGE`
        if ! rsync -vz --progress $REMOTEHOST:$PACKAGE `basename $PACKAGE` ; then
            echo "rsync failed"
            rm `basename $PACKAGE`
            continue
        fi
        mv `basename $PACKAGE` rpms
    else
        echo "Package $PACKAGENAME not installed. Copying whole package"
        scp $REMOTEHOST:$PACKAGE rpms
    fi
done

rm -f packagename *.cpio files

ssh $REMOTEHOST "rm -f $REMOTETMPDIR/*.cpio ; rmdir $REMOTETMPDIR"
popd
mv $LOCALTMPDIR/rpms/*.rpm .
rmdir $LOCALTMPDIR/rpm

-- 
dwmw2




From jspaleta at gmail.com  Tue Nov 29 15:41:17 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 10:41:17 -0500
Subject: Modern Update System
In-Reply-To: <438C71C3.5060601@cornell.edu>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
	<1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<20051128192340.602a02b1.zaitcev@redhat.com>
	<438C71C3.5060601@cornell.edu>
Message-ID: <604aa7910511290741g4adb2d4h4af7822bae27a343@mail.gmail.com>

On 11/29/05, Paul A Houle <ph18 at cornell.edu> wrote:
> I totally understand why this would be a nightmare for the mirrors,  but
> the current status quo is a disaster in terms of user experience.

If you can't convince the mirrors its worth mirroring this additional
material.. its a non-starter. The argument you are making right now
has been repeatedly made and I don't think you are going to make any
head-way with theoretical cost-savings analysis.

The rate of rawhide churn makes an excellent test case for you to
gather statistics. Keep up a set of sequential patches for a couple of
weeks of updates to rawhide on a private server.. long enough to see
multiple updates for several bugfixes packages and see how much more
space it takes to keep rawhide diffed. Build a toy yum plugin client
to work with your collections and have users report back.  Then
compare against the approach Desbonnet has created which only requires
one delta to be available on the mirrors, instead of a chain.

-jef



From ph18 at cornell.edu  Tue Nov 29 15:42:53 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 29 Nov 2005 10:42:53 -0500
Subject: fc5 goals
In-Reply-To: <604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<438C6E65.9030506@cornell.edu>
	<604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>
Message-ID: <438C76FD.9000002@cornell.edu>

Jeff Spaleta wrote:

>At some point it will make sense to drop the cdrom images and produce
>only the dvd image. Just like it made sense to drop the i486 kernel. 
>Once Dell makes dvd-read support compulsory for all its shipping
>products its probably within 2 years (3~4 Core releases) after that
>cdrom install images with be deprecated. I'll have to go out and buy a
>$10 dvd burner at that point.
>  
>
    And remember that it's still a pain to download files larger than 
2^31 bytes.  The only method I've found that's completely reliable is 
bittorrent.

    I understand that Apache had a large file bug on 32-bit platforms 
that was only fixed this year.  With curl or wget,  I can assume that 
I'll lose my connection at some point and need to resume,  so I end up 
not only using the regular download codepath,  but also the resume 
codepath in both my client and the server.

    Practically I have pretty good luck downloading CD-sized chunks;  
maybe one of those gets corrupted less than one time out of ten.

    Presumably people are going to get better clients over time,  and 
perhaps the clients shipped in RHEL and FC right now handle large files 
OK.  (Do they?)  There's still the matter of making sure that the 
mirrors are all running good server software that doesn't screw up for 
large files.



From harald at redhat.com  Tue Nov 29 15:45:24 2005
From: harald at redhat.com (Harald Hoyer)
Date: Tue, 29 Nov 2005 16:45:24 +0100
Subject: udev alpha testing
In-Reply-To: <BAY103-F261D29FEFC5C18059CD591DF4B0@phx.gbl>
References: <BAY103-F261D29FEFC5C18059CD591DF4B0@phx.gbl>
Message-ID: <438C7794.6020008@redhat.com>

Jason Dravet wrote:
>> I would be glad, if the really brave could compile, install and test:
>> ftp://people.redhat.com/harald/udev/076-1/
>>
>> Beware this could end in a non-bootable system.
>>
>> This version removes the hardware initializing/module loading phase 
>> from rc.sysinit. Udev should do most, if not all job. I am interested 
>> in any missing modules, that were loaded before.
>>
>> Thx for testing.
> 
> 
> I will test these for you.  I have downloaded both src.rpm files and I 
> will be doing a rpmbuild --rebuild on them shortly.  I have a few other 
> things I have to get done today so it might later today or tomorrow 
> before I post any results.  Is this alright with you?

sure :)

> 
> If something does go wrong, is there an easy way to get back running 
> without a full restore?  Will booting in single user mode and 
> reinstalling udev-075-4 get the system running again?

hehe, maybe you can't get to single user mode... and reinstall old udev and old initscripts please, if you can 
and need a restore.


> Thanks,
> Jason
> 
> 



From gilboada at netvision.net.il  Tue Nov 29 15:49:27 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Tue, 29 Nov 2005 17:49:27 +0200
Subject: fc5 goals
In-Reply-To: <604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <438C6E65.9030506@cornell.edu>
	<604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>
Message-ID: <1133279367.3357.12.camel@gilboa-home-dev.localhost>

On Tue, 2005-11-29 at 10:24 -0500, Jeff Spaleta wrote:
> On 11/29/05, Paul A Houle <ph18 at cornell.edu> wrote:
> >     Hardly true.
> 
> While I think he overstates the current situation by extrapolating his
> personal experience, at some point though the ubiquity of dvd drives
> will be true. I think we can hold-off on this debate until dell stops
> offering models without atleast dvd read support. Dell still offers
> dvd-less models in its home and home office value lines. On its N
> series "open source friendly" every option in the customize menu has
> atleast dvd read support... so the tipping point might be closer than
> either you or I would like.
> 
> At some point it will make sense to drop the cdrom images and produce
> only the dvd image. Just like it made sense to drop the i486 kernel. 
> Once Dell makes dvd-read support compulsory for all its shipping
> products its probably within 2 years (3~4 Core releases) after that
> cdrom install images with be deprecated. I'll have to go out and buy a
> $10 dvd burner at that point.

Sorry for being OT, but why do you use Dell as a Milestone?
While Dell is the biggest US desktop supplier, it hold less then 18% of
the global desktop market. In Europe and Asia, Dell is almost
non-existent.
If Dell chooses to produce low-end DVD-less machines, this their
prerogative. Fedora must not make decisions based on a single
manufacturer.

I do agree on not dropping the CD images, just yet, though... 

Gilboa

> 
> -jef
> 



From gilboada at netvision.net.il  Tue Nov 29 15:56:12 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Tue, 29 Nov 2005 17:56:12 +0200
Subject: fc5 goals
In-Reply-To: <438BBDFE.5090205@poolshark.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <438BBDFE.5090205@poolshark.org>
Message-ID: <1133279772.3357.17.camel@gilboa-home-dev.localhost>

On Mon, 2005-11-28 at 18:33 -0800, Denis Leroy wrote:
> What if the Fedora Installer was able to install KDE by downloading it from 
> Extras rather than from the CD ?

Currently, I can't get Extra RPMs on the CD and I can't access Extra
while installing the machine.
Having to download ~70 packages (and well above 100MB) on each machine I
install Fedora on is a royal pain in the back side.

I don't mind having a 5'th CD with KDE on it (Like Slackware does), as
long as I can use it when I NFS install.

Gilboa



From dwalsh at redhat.com  Tue Nov 29 16:01:45 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 29 Nov 2005 11:01:45 -0500
Subject: SELinux problems
In-Reply-To: <4388B8A5.4090800@conversis.de>
References: <4388B8A5.4090800@conversis.de>
Message-ID: <438C7B69.90308@redhat.com>

Dennis Jacobfeuerborn wrote:
> I noticed that on bootup the Fedora now shows a ton of messages like 
> these on the screen:
>
> inode_doinit_with_dentry:  context_to_sid(unlabeled) returned 22 for 
> dev=hda2 ino=20447255
>
> Does anybody know how to fix this? (I'm running selinux set to 
> targeted/permissive)
>
> Regards,
>   Dennis
>
When did this start?  Are you running rawhide?

touch /.autorelabel
reboot

might fix it.

-- 




From nigel.metheringham at dev.intechnology.co.uk  Tue Nov 29 16:01:37 2005
From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham)
Date: Tue, 29 Nov 2005 16:01:37 +0000
Subject: Modern Update System
In-Reply-To: <1133278251.31573.175.camel@baythorne.infradead.org>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133278251.31573.175.camel@baythorne.infradead.org>
Message-ID: <1133280098.8979.34.camel@localhost.localdomain>

On Tue, 2005-11-29 at 15:30 +0000, David Woodhouse wrote:
> On Mon, 2005-11-28 at 19:13 -0500, Benjy Grogan wrote:
> > Is there any work being done for a modern update system that would
> > only download what is needed instead of an entirely new rpm? 
> 
> One trick I've had moderate success with is to extract the RPM payload
> (on the remote end) into a cpio file. Then create a cpio file locally
> using the contents of the old package, and rsync the new cpio using the
> old cpio as seed. Once that's done, recompress (using 'minigzip -9' so
> that it precisely matches what RPM does) and then use that as seed for
> rsyncing the RPM itself, just to get the header.

How well does it work if you pull the rpm header (presumably thats
always needed for an update), build the payload using existing files on
the system (ie from the previous install) via cpio/minigzip, glue the 2
together and rsync that?

Or even *not* pull the current rpm header, but build an rpm on the
system using the old installed package db info (how do database ordering
issues hit us here), and then rsync the new rpm on top of the
reconstructed one.  [If the old rpm is still in yum's cache then you can
just do a copy rather than a reconstruct, but that can not be assumed to
be the normal case].

It does require mirrors to give rsync access - which is probably pretty
wide spread *but* would need the rsync URLs for mirrors to be made
available - you can't just assume that you can do s/^(f|ht)tp:/rsync:/

	Nigel.
-- 
[ Nigel Metheringham           Nigel.Metheringham at InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]




From jspaleta at gmail.com  Tue Nov 29 16:01:50 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 11:01:50 -0500
Subject: fc5 goals
In-Reply-To: <1133279367.3357.12.camel@gilboa-home-dev.localhost>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <438C6E65.9030506@cornell.edu>
	<604aa7910511290724g2366ae0t5982fe173a88d8d@mail.gmail.com>
	<1133279367.3357.12.camel@gilboa-home-dev.localhost>
Message-ID: <604aa7910511290801g452e62aei668aeff9c5a6041a@mail.gmail.com>

On 11/29/05, Gilboa Davara <gilboada at netvision.net.il> wrote:
> Sorry for being OT, but why do you use Dell as a Milestone?
> While Dell is the biggest US desktop supplier, it hold less then 18% of
> the global desktop market. In Europe and Asia, Dell is almost
> non-existent.
> If Dell chooses to produce low-end DVD-less machines, this their
> prerogative. Fedora must not make decisions based on a single
> manufacturer.

Fedora doesn't make decisions on what distributors in Asia do either.
But you'd be absolutely blind to how development for Fedora is done to
not notice that there is a bend towards US-centric experience based
decision making simply because of where the decision making is
happening.   I have to use something as a strawman and that was the
obvious choice.

-jef



From chasd at silveroaks.com  Tue Nov 29 16:03:13 2005
From: chasd at silveroaks.com (chasd at silveroaks.com)
Date: Tue, 29 Nov 2005 10:03:13 -0600
Subject: Summary of FC5test1 vulnerabilities
In-Reply-To: <20051126011353.45231734D9@hormel.redhat.com>
References: <20051126011353.45231734D9@hormel.redhat.com>
Message-ID: <60449c04b30d540bc0fb76813e6b2836@silveroaks.com>

> Package maintainers in both Fedora  Core and Extras repository are
> responsible for the security of packages they develop/maintain. However
> Red Hat security response team does not keep track of all security
> issues in Fedora Extras repository unlike Fedora Core to my  
> understanding.

Thanks for clarifying that.

> There was a discussion here
> https://www.redhat.com/archives/fedora-extras-list/2005-September/ 
> msg00393.html.

Thanks for the link, it looks like the issues involved are being  
discussed.

> The package maintainers keep track of the security issues. There is no
> reason not to trust the community packagers to do a less than excellent
> job with it.

I did not mean to imply that any of the maintainers are not doing a  
good job. As was pointed out in the linked Extras discussion, mistakes  
can be made, or time constraints on a maintainer can effect the the  
release of an update to rectify security issues. Most of us are humans  
;)

> All of Fedora Extras packages
> takes advantage of various features in Fedora Core including
> Exec-shield, FORTIFY_SOURCE fstack-protector etc in addition to SELinux
> capabilities.

I did not mean to imply that using packages in Extras was a security  
risk.

> Even setting aside all the security features,  there are several
> advantages to using Fedora Extras in favor of tarballs or self packaged
> RPMS.

My reference to using packages via tarballs or self-packaged software  
was related to how I internally treat that software. I am personally  
more vigilant of security issues with software that is not installed  
via Fedora because I know I must shoulder that responsibility for that  
software. I don't have a security team to make sure any issues are  
dealt with, I'm the security team for the software I install on a  
system that is not part of the distribution.

 From the above Extras list discussion:
> I believe many such installations and sysadmins do exist, and part of  
> the natural responsibility for such people would be to help the Extras  
> in fixing the packets at source.

That's me. From the above clarification I know I need to take a bit of  
extra ( pun intended ) personal responsibility with packages from  
Extras. Packages from Extras are there because of the community, and  
the community ( me ) needs to put forth the effort to keep those  
packages maintained.

> Fedora Extras undergoes a package review process to ensure
> consistency and better integration with Fedora according to the
> specified guidelines

I in no way intended to bash Extras. However I do think some type of  
written security/errata policy for Extras should appear on the Fedora  
Project Wiki.

Charles Dostale
System Admin - Silver Oaks Communications
http://www.silveroaks.com/
824 17th Street, Moline  IL  61265



From msw at rpath.com  Tue Nov 29 16:13:06 2005
From: msw at rpath.com (Matt Wilson)
Date: Tue, 29 Nov 2005 11:13:06 -0500
Subject: Modern Update System
In-Reply-To: <1133225199.24512.113.camel@prometheus.gamehouse.com>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133225199.24512.113.camel@prometheus.gamehouse.com>
Message-ID: <20051129161306.GA18617@rpath.com>

On Mon, Nov 28, 2005 at 04:46:39PM -0800, Jesse Keating wrote:
> 
> Thats 4 different deltas that would have to be available.  We're
> talking about a huge amount of wasted space.

The huge amount of wasted space comes in having to store tons of RPM
files that have duplicated contents.  A conary[1] repository avoids
this, as each unique file is stored only once in a repository.  Each
changeset request is processed dynamically by the repository server.
The result of the changeset request is cached with the file contents
omitted.  The files are filled in when the client downloads the
changeset.

Of course this means that mirrors have to run a repository server
instead of a simple http/ftp/rsync mirror.  Some mirror sites will be
unwilling to host an application.  Some will value the disk space and
data transfer savings that changeset-based updates can provide.

But there's very little chance that Fedora or Red Hat will move away
from RPM, so this information is fairly irrelevant.

[1] http://wiki.conary.com/

Cheers,

Matt
-- 
Matt Wilson
rPath, Inc.
msw at rpath.com



From dravet at hotmail.com  Tue Nov 29 16:13:59 2005
From: dravet at hotmail.com (Jason Dravet)
Date: Tue, 29 Nov 2005 10:13:59 -0600
Subject: udev alpha testing
In-Reply-To: <438C7794.6020008@redhat.com>
Message-ID: <BAY103-F3C43C79C9E2B8220EE850DF4B0@phx.gbl>




>From: Harald Hoyer <harald at redhat.com>
>To: Jason Dravet <dravet at hotmail.com>
>CC: fedora-devel-list at redhat.com
>Subject: Re: udev alpha testing
>Date: Tue, 29 Nov 2005 16:45:24 +0100
>
>Jason Dravet wrote:
>>>I would be glad, if the really brave could compile, install and test:
>>>ftp://people.redhat.com/harald/udev/076-1/
>>>
>>>Beware this could end in a non-bootable system.
>>>
>>>This version removes the hardware initializing/module loading phase from 
>>>rc.sysinit. Udev should do most, if not all job. I am interested in any 
>>>missing modules, that were loaded before.
>>>
>>>Thx for testing.
>>
>>
>>I will test these for you.  I have downloaded both src.rpm files and I 
>>will be doing a rpmbuild --rebuild on them shortly.  I have a few other 
>>things I have to get done today so it might later today or tomorrow before 
>>I post any results.  Is this alright with you?
>
>sure :)
>
>>
>>If something does go wrong, is there an easy way to get back running 
>>without a full restore?  Will booting in single user mode and reinstalling 
>>udev-075-4 get the system running again?
>
>hehe, maybe you can't get to single user mode... and reinstall old udev and 
>old initscripts please, if you can and need a restore.
>
>
>>Thanks,
>>Jason
>>
>>
>

I found some time this morning so here are the results:
1.  I get an error during boot:  udevd_event[702] udev_db_lookup_name: 
unable to open udev_db `/dev/.udev/db`: No such file or directory.  The 
system still boots.
2.  I ran a lsmod before and after and here are differences:  udev-075-4 
loaded loop, parport, and parport_pc.  Udev-076 does not load those modules.
3.  Udev-076 is still slow during boot, although this has more to do with 
selinux than udev.  Selinux 1.x policies did not cause udev to be slow.  The 
2.x policies have caused udev to be slow.

All in all I say udev 076 is pretty good.

Jason




From sds at tycho.nsa.gov  Tue Nov 29 16:28:50 2005
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Tue, 29 Nov 2005 11:28:50 -0500
Subject: custom selinux policy
In-Reply-To: <1133215231.19778.28.camel@www.lutty.net>
References: <1133215231.19778.28.camel@www.lutty.net>
Message-ID: <1133281730.26593.127.camel@moss-spartans.epoch.ncsc.mil>

On Mon, 2005-11-28 at 23:00 +0100, Laurent Jacquot wrote:
> Hello,
> I can no longer build my custom selinux policy with recent upgrades (SE
> policy source replaced with SE policy).
> What is the new way (used to be make reload)?

Build a policy module, and then insert it into the policy module store.
audit2allow has been updated (by Dan Walsh) to support policy module
generation; see its man page.

-- 
Stephen Smalley
National Security Agency



From seandarcy2 at gmail.com  Tue Nov 29 16:00:19 2005
From: seandarcy2 at gmail.com (sean)
Date: Tue, 29 Nov 2005 11:00:19 -0500
Subject: rawhide report: 20051129 changes
In-Reply-To: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>
Message-ID: <dmhtuj$k1j$1@sea.gmane.org>

Build System wrote:
>  
> 
>  
> Updated Packages:
> 
.................
> 
> selinux-policy-2.0.6-1
> ----------------------
> 

On x86-64:

   Updating  : selinux-policy-targeted      ## 
         [23/59]warning: 
/etc/selinux/targeted/policy/policy.20 created as 
/etc/selinux/targeted/policy/policy.20.rpmnew
   Updating  : selinux-policy-targeted 
####################### [23/59]
libsemanage.parse_assert_space: missing whitespace 
(/etc/selinux/targeted/modules/tmp/seusers: 1):
root:root:s0-s0:c0.c255
libsemanage.seuser_parse: could not parse seuser record
libsemanage.dbase_file_cache: could not cache file database
libsemanage.enter_ro: could not enter read-only section
libsemanage.semanage_base_merge_components: could not merge 
local modifications into policy
Failed!
   Updating  : libselinux-devel 
####################### [24/59]

sean



From michael.favia at insitesinc.com  Tue Nov 29 16:29:01 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 10:29:01 -0600
Subject: rawhide report: 20051129 changes
In-Reply-To: <dmhtuj$k1j$1@sea.gmane.org>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>
	<dmhtuj$k1j$1@sea.gmane.org>
Message-ID: <438C81CD.7080304@insitesinc.com>

sean wrote:
> Build System wrote:
>>  
>>
>>  
>> Updated Packages:
>>
> .................
>>
>> selinux-policy-2.0.6-1
>> ----------------------
>>
> 
> On x86-64:
> 
>   Updating  : selinux-policy-targeted      ##         [23/59]warning: 
> /etc/selinux/targeted/policy/policy.20 created as 
> /etc/selinux/targeted/policy/policy.20.rpmnew
>   Updating  : selinux-policy-targeted ####################### [23/59]
> libsemanage.parse_assert_space: missing whitespace 
> (/etc/selinux/targeted/modules/tmp/seusers: 1):
> root:root:s0-s0:c0.c255
> libsemanage.seuser_parse: could not parse seuser record
> libsemanage.dbase_file_cache: could not cache file database
> libsemanage.enter_ro: could not enter read-only section
> libsemanage.semanage_base_merge_components: could not merge local 
> modifications into policy
> Failed!
>   Updating  : libselinux-devel ####################### [24/59]

+2
-mf



From dwalsh at redhat.com  Tue Nov 29 16:32:41 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 29 Nov 2005 11:32:41 -0500
Subject: custom selinux policy
In-Reply-To: <1133215231.19778.28.camel@www.lutty.net>
References: <1133215231.19778.28.camel@www.lutty.net>
Message-ID: <438C82A9.3060804@redhat.com>

Laurent Jacquot wrote:
> Hello,
> I can no longer build my custom selinux policy with recent upgrades (SE
> policy source replaced with SE policy).
> What is the new way (used to be make reload)?
>
> tx in advance
> 	jk
>
>   
You need to  use loadable modules.  Take a look a the man page for 
audit2allow, for some explanation.  I don't know if we have a good 
description available yet for loadable policy.

The hardest part of converting your local.te into a loadable module will 
be writing the require section.
You need to define all types, class and roles in this section in order 
to get the loadable module.
==================================================================================
       module local 1.0;

       require {
               role system_r;

               class fifo_file {  getattr ioctl };

               type cupsd_config_t;
               type unconfined_t;
        };

       allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
==================================================================================

-- 




From mattdm at mattdm.org  Tue Nov 29 16:34:30 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 29 Nov 2005 11:34:30 -0500
Subject: Summary of FC5test1 vulnerabilities
In-Reply-To: <43876A90.6000109@redhat.com>
References: <20051125170004.9CF9872FB9@hormel.redhat.com>
	<13ead7df45cf1aabfec88c1ef937dcab@silveroaks.com>
	<43876A90.6000109@redhat.com>
Message-ID: <20051129163430.GA6977@jadzia.bu.edu>

On Sat, Nov 26, 2005 at 01:18:32AM +0530, Rahul Sundaram wrote:
> >May I assume this has not been done for packages in Extras ?
> Package maintainers in both Fedora  Core and Extras repository are 
> responsible for the security of packages they develop/maintain. However 
> Red Hat security response team does not keep track of all security 
> issues in Fedora Extras repository unlike Fedora Core to my understanding.

Is it planned that they will? That'd be very helpful.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From dwmw2 at infradead.org  Tue Nov 29 16:36:02 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 29 Nov 2005 16:36:02 +0000
Subject: Modern Update System
In-Reply-To: <1133280098.8979.34.camel@localhost.localdomain>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133278251.31573.175.camel@baythorne.infradead.org>
	<1133280098.8979.34.camel@localhost.localdomain>
Message-ID: <1133282162.31573.190.camel@baythorne.infradead.org>

On Tue, 2005-11-29 at 16:01 +0000, Nigel Metheringham wrote:
> How well does it work if you pull the rpm header (presumably thats
> always needed for an update), build the payload using existing files on
> the system (ie from the previous install) via cpio/minigzip, glue the 2
> together and rsync that?

Badly. The compressed payload doesn't rsync well -- you have to
decompress it if you want rsync to do anything other than just download
it all again.

There were once some zlib patches which made zlib-compressed stuff
slightly more rsync-friendly by deliberately discarding history and
inserting sync points in the data stream, but they're not a patch on
just rsyncing the _uncompressed_ version.

> It does require mirrors to give rsync access - which is probably
> pretty wide spread *but* would need the rsync URLs for mirrors to be
> made available - you can't just assume that you can do 
> s/^(f|ht)tp:/rsync:/

Yeah. Even rsync access to the extracted cpio payload shouldn't be
entirely impossible.

-- 
dwmw2




From jkeating at j2solutions.net  Tue Nov 29 16:54:17 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 29 Nov 2005 08:54:17 -0800
Subject: 'everything' install option in FC5test1
In-Reply-To: <20051129131414.GA30136@jadzia.bu.edu>
References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com>
	<1132984226.2860.39.camel@bree.local.net>
	<20051126143949.GA2261@jadzia.bu.edu>
	<20051129130252.GF7549@rednote.net>
	<20051129131414.GA30136@jadzia.bu.edu>
Message-ID: <1133283257.2833.56.camel@yoda.loki.me>

On Tue, 2005-11-29 at 08:14 -0500, Matthew Miller wrote:
> 
> I *do* care about that. Firstboot should be available in text-only mode for
> use with screenreaders.
> 
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66731>

Add enhancements to init's .unconfigured methodology.  This is why I
usually complain about -gui config tools being created w/out -tui
counterparts.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From ndbecker2 at gmail.com  Tue Nov 29 16:34:36 2005
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 29 Nov 2005 11:34:36 -0500
Subject: What about smartpm?
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me>
Message-ID: <dmhvur$p5m$1@sea.gmane.org>

Jesse Keating wrote:

> On Sat, 2005-11-26 at 08:55 -0800, MJang wrote:
>> 
>> A couple of months ago, I was under the impression that all the distros
>> were moving in that direction, as Smartpm can handle upgrades to both
>> RPMs and DEBs and can work from all kinds of repositories (apt, yum,
>> urpmi, slack, etc.). Is Smartpm still under consideration for FC5?
> 
> As far as I know, no.  Duplicate functionality.  Fedora doesn't use apt,
> no need to worry about that from a Fedora standpoint.  Fedora uses yum,
> yum cli updates, pup graphically updates.
> 

Partially true - but yum is smart, and smart is smarter.

For example, just this morning yum quit updating.  I don't recall the
details, but I had installed videolan-client from dries yum repos, and an
update of one of it's depends (from a different repo) broke it.

yum was stymied.

smart just offered to downgrade the depend, and happily fixed it.




From mls at suse.de  Tue Nov 29 16:57:02 2005
From: mls at suse.de (Michael Schroeder)
Date: Tue, 29 Nov 2005 17:57:02 +0100
Subject: Modern Update System
In-Reply-To: <1133282162.31573.190.camel@baythorne.infradead.org>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133278251.31573.175.camel@baythorne.infradead.org>
	<1133280098.8979.34.camel@localhost.localdomain>
	<1133282162.31573.190.camel@baythorne.infradead.org>
Message-ID: <20051129165702.GA27923@suse.de>

On Tue, Nov 29, 2005 at 04:36:02PM +0000, David Woodhouse wrote:
> On Tue, 2005-11-29 at 16:01 +0000, Nigel Metheringham wrote:
> > How well does it work if you pull the rpm header (presumably thats
> > always needed for an update), build the payload using existing files on
> > the system (ie from the previous install) via cpio/minigzip, glue the 2
> > together and rsync that?
> 
> Badly. The compressed payload doesn't rsync well -- you have to
> decompress it if you want rsync to do anything other than just download
> it all again.
> 
> There were once some zlib patches which made zlib-compressed stuff
> slightly more rsync-friendly by deliberately discarding history and
> inserting sync points in the data stream, but they're not a patch on
> just rsyncing the _uncompressed_ version.

The problem is the rsync block size. To make rsync reuse data
a complete block has to be found in the new rpm. If you have
a rpm with contains lots of small files (like the kernel) that
all are slightly changed (because they contain the version number),
the rsync delta protocol won't help much.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From ndbecker2 at gmail.com  Tue Nov 29 16:41:25 2005
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 29 Nov 2005 11:41:25 -0500
Subject: kde3.5?
Message-ID: <dmi0bl$p5m$2@sea.gmane.org>

kde3.5 is released.  Will this be an update for FC4, or do I have to wait
for FC5?  I'm running on x86_64, so Rex's kde-redhat won't help.



From jkeating at j2solutions.net  Tue Nov 29 17:02:52 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Tue, 29 Nov 2005 09:02:52 -0800
Subject: What about smartpm?
In-Reply-To: <dmhvur$p5m$1@sea.gmane.org>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me>  <dmhvur$p5m$1@sea.gmane.org>
Message-ID: <1133283772.2833.58.camel@yoda.loki.me>

On Tue, 2005-11-29 at 11:34 -0500, Neal Becker wrote:
> 
> Partially true - but yum is smart, and smart is smarter.
> 
> For example, just this morning yum quit updating.  I don't recall the
> details, but I had installed videolan-client from dries yum repos, and an
> update of one of it's depends (from a different repo) broke it.
> 
> yum was stymied.
> 
> smart just offered to downgrade the depend, and happily fixed it.

Sounds to me like user error.  Perhaps your yum config didn't know about
the other repository.

Smart is duplicate functionality for the most part.  See if you can get
it into Extras.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
 
Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From dwmw2 at infradead.org  Tue Nov 29 17:05:44 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 29 Nov 2005 17:05:44 +0000
Subject: Modern Update System
In-Reply-To: <20051129165702.GA27923@suse.de>
References: <d82d6db50511281613t1fefcd9cr47c0294a2207ee8c@mail.gmail.com>
	<1133278251.31573.175.camel@baythorne.infradead.org>
	<1133280098.8979.34.camel@localhost.localdomain>
	<1133282162.31573.190.camel@baythorne.infradead.org>
	<20051129165702.GA27923@suse.de>
Message-ID: <1133283944.31573.193.camel@baythorne.infradead.org>

On Tue, 2005-11-29 at 17:57 +0100, Michael Schroeder wrote:
> The problem is the rsync block size. To make rsync reuse data
> a complete block has to be found in the new rpm. If you have
> a rpm with contains lots of small files (like the kernel) that
> all are slightly changed (because they contain the version number),
> the rsync delta protocol won't help much.

I think at one point I experimented with a global search and replace
from the old version number to the new. The other way in which this
bites is because some versions of cpio insist on having filenames
starting with './' while rpm omits that. Or vice versa -- I don't
recall.

-- 
dwmw2




From michael.favia at insitesinc.com  Tue Nov 29 17:19:57 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 11:19:57 -0600
Subject: kde3.5?
In-Reply-To: <dmi0bl$p5m$2@sea.gmane.org>
References: <dmi0bl$p5m$2@sea.gmane.org>
Message-ID: <438C8DBD.6010103@insitesinc.com>

Neal Becker wrote:
> kde3.5 is released.  Will this be an update for FC4, or do I have to wait
> for FC5?  I'm running on x86_64, so Rex's kde-redhat won't help.
> 
You can track rawhide which released what looked like a 3.5rc today or 
wait for FC5 but i doubt anyone has reason to update FC4 instead of 
moving forward. But thats just my opinion. -mf



From gilboada at netvision.net.il  Tue Nov 29 17:31:46 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Tue, 29 Nov 2005 19:31:46 +0200
Subject: kde3.5?
In-Reply-To: <dmi0bl$p5m$2@sea.gmane.org>
References: <dmi0bl$p5m$2@sea.gmane.org>
Message-ID: <1133285506.3357.36.camel@gilboa-home-dev.localhost>

On Tue, 2005-11-29 at 11:41 -0500, Neal Becker wrote:
> kde3.5 is released.  Will this be an update for FC4, or do I have to wait
> for FC5?  I'm running on x86_64, so Rex's kde-redhat won't help.
> 

I'm waiting for Rex to release his 3.5 RPMs.
When he does, I'll try building 3.5 x86-64 RPMs, and send the updated
spec files upstream.  (And maybe the RPMs, If they test OK, and I can
get someone to host them)

Gilboa



From ndbecker2 at gmail.com  Tue Nov 29 17:29:48 2005
From: ndbecker2 at gmail.com (Neal Becker)
Date: Tue, 29 Nov 2005 12:29:48 -0500
Subject: What about smartpm?
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me>
Message-ID: <dmi36c$7f8$1@sea.gmane.org>

Jesse Keating wrote:

> On Tue, 2005-11-29 at 11:34 -0500, Neal Becker wrote:
>> 
>> Partially true - but yum is smart, and smart is smarter.
>> 
>> For example, just this morning yum quit updating.  I don't recall the
>> details, but I had installed videolan-client from dries yum repos, and an
>> update of one of it's depends (from a different repo) broke it.
>> 
>> yum was stymied.
>> 
>> smart just offered to downgrade the depend, and happily fixed it.
> 
> Sounds to me like user error.  Perhaps your yum config didn't know about
> the other repository.
> 

I don't think so.  It's like this:

I want to install appA.  It has depB.

repoA and repoB both have depB.  repoA has appA.

Installing (via yum, smart, or whatever) picks up appA from repoA, and depB
from repoB.

Now, repoB updates depB.  No reason it shouldn't.

Now, IIUC, yum gives up on this situation.  It wants to update depB, but
appA needs the old version.

IIUC, not only does yum not update depB, but it _stops updating anything
completely_.  Your nightly yum upgrade stops until you notice the problem
and manually repair it.  (Correct me if I'm wrong here).
 



From ivg2 at cornell.edu  Tue Nov 29 18:14:20 2005
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Tue, 29 Nov 2005 13:14:20 -0500
Subject: rawhide report: 20051129 changes
In-Reply-To: <438C81CD.7080304@insitesinc.com>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>	<dmhtuj$k1j$1@sea.gmane.org>
	<438C81CD.7080304@insitesinc.com>
Message-ID: <438C9A7C.1070404@cornell.edu>

>
>>
>>   Updating  : selinux-policy-targeted      ##         [23/59]warning: 
>> /etc/selinux/targeted/policy/policy.20 created as 
>> /etc/selinux/targeted/policy/policy.20.rpmnew
>>   Updating  : selinux-policy-targeted ####################### [23/59]
>> libsemanage.parse_assert_space: missing whitespace 
>> (/etc/selinux/targeted/modules/tmp/seusers: 1):
>> root:root:s0-s0:c0.c255
>> libsemanage.seuser_parse: could not parse seuser record
>> libsemanage.dbase_file_cache: could not cache file database
>> libsemanage.enter_ro: could not enter read-only section
>> libsemanage.semanage_base_merge_components: could not merge local 
>> modifications into policy
>> Failed!
>>   Updating  : libselinux-devel ####################### [24/59]
>
> +2
> -mf

This is a known problem that should be fixed soon (patch by Stephen 
Smalley committed upstream).
Can you describe what you're upgrading from, and to (policy versions?). 
Specifically, what's the
type of the running policy on that machine (strict w/out mcs? targeted 
w/out mcs? mls? strict with mcs? targeted with mcs?).

This problem should only occur if you're upgrading a machine currently 
running with mls disabled to an mls-enabled policy.



From prushinsky at gmail.com  Tue Nov 29 18:18:57 2005
From: prushinsky at gmail.com (Yuri Prushinsky)
Date: Tue, 29 Nov 2005 21:18:57 +0300
Subject: fc5 goals
In-Reply-To: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
Message-ID: <438C9B91.1010907@gmail.com>

desktop manager is not the correct decision for removal, the more 
important is to move typical productivity 3rd party applications to 
Extras. I'm a KDE user, with every new release of Gnome I try to switch 
to it, but it's just not usable for me, sorry guys.
	So, I decided to delete apps that I never use, yum remove mozilla wiped 
out mozilla with a bunch of gnome-related packages. Fine, I don't need 
the beta of OOo, yum remove openoffice removed one and about 100 
gnome-related packages! Rpm-hell is alive, and waits you under yum!
	Okay, now I have my lovely kdm, kde, and 3rd party firefox and the 
latest OOo, which have their own installators.
I really like the kind of Core that freeBSD provides, and it would be 
nice if FC will have the same tool set in its core.

Eric TANGUY wrote:
> Le lundi 28 novembre 2005 ?  11:56 -0800, Peter Gordon a ??crit :
> 
>>Josh Coffman wrote:
>>
>>>Anyone know where to find documentation about the
>>>goals and improvements intended for FC5?
>>
>>You might want to take a look at FC5Future[1] on the Wiki, as well.
>>
>>[1] http://www.fedoraproject.org/wiki/FC5Future
>>
>>--Peter
>>
> 
> Why there is so much java package included in fc5 ?
> No news about early login or something like that ?
> Why kde is still included in core whereas it could be in extras ?
> Why some packages go directly in core and not in extras before ? Because
> they were packaged by someone from redhat ? Is it sufficient ???
> 
> I saw the long discussion about what to include in or not in fc5 but maybe
> the problem will be the goal of fedora ?
> 
> Is this product mainly for developpers form redhat ?
> 
> yes i know i'm joking but in fact it could be a good question, no ? Thanks
> 
> Eric
> 
> 
> 
> 

-- 
Sincerely yours,
  Yura



From icon at fedoraproject.org  Tue Nov 29 18:21:49 2005
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Tue, 29 Nov 2005 13:21:49 -0500
Subject: What about smartpm?
In-Reply-To: <dmi36c$7f8$1@sea.gmane.org>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me>  <dmi36c$7f8$1@sea.gmane.org>
Message-ID: <1133288509.16909.9.camel@rakta.wsg.mcgill.ca>

On Tue, 2005-11-29 at 12:29 -0500, Neal Becker wrote:
> I don't think so.  It's like this:
> 
> I want to install appA.  It has depB.
> 
> repoA and repoB both have depB.  repoA has appA.
> 
> Installing (via yum, smart, or whatever) picks up appA from repoA, and depB
> from repoB.
> 
> Now, repoB updates depB.  No reason it shouldn't.
> 
> Now, IIUC, yum gives up on this situation.  It wants to update depB, but
> appA needs the old version.
> 
> IIUC, not only does yum not update depB, but it _stops updating anything
> completely_.  Your nightly yum upgrade stops until you notice the problem
> and manually repair it.  (Correct me if I'm wrong here).

It's because this is a safer behaviour than guessing around various
errors. You think it's wonderful, but it's far more error-prone than not
doing anything "automagically" until the problem is actually fixed.
Working around brokenness is a very slippery path to far graver and more
obscure brokenness down the line.

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG
Montr?al, Qu?bec



From ph18 at cornell.edu  Tue Nov 29 18:36:39 2005
From: ph18 at cornell.edu (Paul A Houle)
Date: Tue, 29 Nov 2005 13:36:39 -0500
Subject: fc5 goals
In-Reply-To: <438C9B91.1010907@gmail.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<438C9B91.1010907@gmail.com>
Message-ID: <438C9FB7.2060905@cornell.edu>

Yuri Prushinsky wrote:

> desktop manager is not the correct decision for removal, the more 
> important is to move typical productivity 3rd party applications to 
> Extras. I'm a KDE user, with every new release of Gnome I try to 
> switch to it, but it's just not usable for me, sorry guys.
>     So, I decided to delete apps that I never use, yum remove mozilla 
> wiped out mozilla with a bunch of gnome-related packages. Fine, I 
> don't need the beta of OOo, yum remove openoffice removed one and 
> about 100 gnome-related packages! Rpm-hell is alive, and waits you 
> under yum!
>     Okay, now I have my lovely kdm, kde, and 3rd party firefox and the 
> latest OOo, which have their own installators.
> I really like the kind of Core that freeBSD provides, and it would be 
> nice if FC will have the same tool set in its core.
>
    I've said it before,  but...

    If you don't like the package set chosen in Fedora core,  go ahead 
and roll your own "Hard Core" linux.

    Fedora comes with a set of tools that will turn a directory full of 
rpm's into a linux distribution you can burn onto an ISO.  Create a 
.torrent and you can share it with everybody.  If you just want to 
subset Fedora,  this ought to be easy.



From nicolas.mailhot at laposte.net  Tue Nov 29 18:16:06 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 29 Nov 2005 19:16:06 +0100
Subject: fc5 goals
In-Reply-To: <dmhehp$oqu$1@sea.gmane.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com>  <dmhehp$oqu$1@sea.gmane.org>
Message-ID: <1133288168.17843.23.camel@rousalka.dyndns.org>

Le mardi 29 novembre 2005 ? 09:37 -0200, Pedro Lamar?o a ?crit :

> This may even be true in the country you live in, but let's keep things
> under control for those of us with computers "too old" to have DVD
> burners running a Fedora-based desktop just fine.

The problem is not what systems have DVD burners now.
The problem is what systems won't have DVD burners by the time the
single-CD FC ISO goal is achieved.

Based on the current progress rate DVD readers won't even exist anymore
when this is done. So this effort strikes me as rather moot.

Better get network installs working flawlessly, break stupid dependency
links and forget about the CD iso part altogether. Systems without DVD
support will certainly have network access to DVD-enabled servers sooner
than FC manages to shave even one ISO. The only thing we seem to manage
is to slow down the growth, which is a good thing but won't ever solve
the media distribution bit.

OTOH most books/magazines/LUGS would be happier with network CD and/or
FC dvd instead of 4+ CDs like now.

But that's only my opinion.

-- 
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/20051129/d8abc6a8/attachment.sig>

From benny+usenet at amorsen.dk  Tue Nov 29 18:50:40 2005
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: 29 Nov 2005 19:50:40 +0100
Subject: status of up2date and rhn-applet
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051129075855.GB13739@neu.nirvana>
Message-ID: <m31x0zwanz.fsf@ursa.amorsen.dk>

>>>>> "AT" == Axel Thimm <Axel.Thimm at ATrpms.net> writes:

AT> Maybe it's better to avoid atrpms at all then, as its bar will
AT> probably assume that you are using foo from the same source?
AT> Perhaps foo in core is being replaced just to add the
AT> functionality that bar needs?

Possibly. In  my case I need  a few kernel modules  (ipw2200 for one),
and I certainly don't want all  the rest that atrpms tries to replace.
Anyway, package  dependencies are supposed to handle  the issue you're
describing. If not, the package dependencies are wrong.

AT> It isn't as black or white as it seems. I've had enough bug
AT> reports on using apt and smart with priorities/weights to strongly
AT> advise against their use (not apt/smart's, but their weighing
AT> mechanisms).

AT> And if you don't trust repo X to replace package Y, then why trust
AT> it to offer package Z? Better drop repo X, if you feel
AT> uncomfortable.

I would drop atrpms in an instant if anyone else provided those kernel
modules. However, noone else does. Atrpms is only usable for me with a
hefty exclude= line, and I'm seriously considering switching to
include=. However, that would mean never again being able to check
with yum whether atrpms provides a certain package.

Perhaps the real solution is an option to let yum list ignore exlude= and
include=.


/Benny




From skvidal at phy.duke.edu  Tue Nov 29 19:02:27 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 29 Nov 2005 14:02:27 -0500
Subject: status of up2date and rhn-applet
In-Reply-To: <m31x0zwanz.fsf@ursa.amorsen.dk>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org> <m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051129075855.GB13739@neu.nirvana> <m31x0zwanz.fsf@ursa.amorsen.dk>
Message-ID: <1133290947.7585.15.camel@cutter>

> AT> And if you don't trust repo X to replace package Y, then why trust
> AT> it to offer package Z? Better drop repo X, if you feel
> AT> uncomfortable.
> 
> I would drop atrpms in an instant if anyone else provided those kernel
> modules. However, noone else does. Atrpms is only usable for me with a
> hefty exclude= line, and I'm seriously considering switching to
> include=. However, that would mean never again being able to check
> with yum whether atrpms provides a certain package.

livna carries those modules.

Well, to be clear ipw2200 is just firmware - the module is in the kernel
package.

> Perhaps the real solution is an option to let yum list ignore exlude= and
> include=.

no, that's not the answer. Talk about counterintuitive.

-sv





From felipe.alfaro at gmail.com  Tue Nov 29 19:24:19 2005
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Tue, 29 Nov 2005 20:24:19 +0100
Subject: udev alpha testing
In-Reply-To: <438C656B.2080701@redhat.com>
References: <438C656B.2080701@redhat.com>
Message-ID: <6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com>

> I would be glad, if the really brave could compile, install and test:
> ftp://people.redhat.com/harald/udev/076-1/
>
> Beware this could end in a non-bootable system.
>
> This version removes the hardware initializing/module loading phase from rc.sysinit. Udev should do most, if
> not all job. I am interested in any missing modules, that were loaded before.

Impressive. Not only does it boot faster (with selinux=0), but I can't
see any real difference between 076-1 and 075-4: exactly the same
modules get loaded.



From jk at lutty.net  Tue Nov 29 19:27:49 2005
From: jk at lutty.net (Laurent Jacquot)
Date: Tue, 29 Nov 2005 20:27:49 +0100
Subject: custom selinux policy
In-Reply-To: <438C82A9.3060804@redhat.com>
References: <1133215231.19778.28.camel@www.lutty.net>
	<438C82A9.3060804@redhat.com>
Message-ID: <1133292469.19778.41.camel@www.lutty.net>

On mar, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote:
> Laurent Jacquot wrote:
> > Hello,
> > I can no longer build my custom selinux policy with recent upgrades (SE
> > policy source replaced with SE policy).
> > What is the new way (used to be make reload)?
> >
> > tx in advance
> > 	jk
> >
> >   
> You need to  use loadable modules.  Take a look a the man page for 
> audit2allow, for some explanation.  I don't know if we have a good 
> description available yet for loadable policy.
> 
> The hardest part of converting your local.te into a loadable module will 
> be writing the require section.
> You need to define all types, class and roles in this section in order 
> to get the loadable module.
> ==================================================================================
>        module local 1.0;
> 
>        require {
>                role system_r;
> 
>                class fifo_file {  getattr ioctl };
> 
>                type cupsd_config_t;
>                type unconfined_t;
>         };
> 
>        allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
> ==================================================================================
> 
> -- 
Thanks a lot for this info.
BTW the audit2allow (policycoreutils-1.27.29-1) manpage isn't updated
regarding the module stuff. Hopefully, the -M option is verbose

Would you mind shed some light on the new file context definition? (used
to be local.fc)

Laurent





From dragoran at feuerpokemon.de  Tue Nov 29 19:31:15 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Tue, 29 Nov 2005 20:31:15 +0100
Subject: udev alpha testing
In-Reply-To: <6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com>
References: <438C656B.2080701@redhat.com>
	<6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com>
Message-ID: <438CAC83.3010300@feuerpokemon.de>

Felipe Alfaro Solana wrote:

>>I would be glad, if the really brave could compile, install and test:
>>ftp://people.redhat.com/harald/udev/076-1/
>>
>>Beware this could end in a non-bootable system.
>>
>>This version removes the hardware initializing/module loading phase from rc.sysinit. Udev should do most, if
>>not all job. I am interested in any missing modules, that were loaded before.
>>    
>>
>
>Impressive. Not only does it boot faster (with selinux=0), but I can't
>see any real difference between 076-1 and 075-4: exactly the same
>modules get loaded.
>
>  
>
why with selinux=0 ? is it slower with selinux enabled?



From felipe.alfaro at gmail.com  Tue Nov 29 19:32:28 2005
From: felipe.alfaro at gmail.com (Felipe Alfaro Solana)
Date: Tue, 29 Nov 2005 20:32:28 +0100
Subject: udev alpha testing
In-Reply-To: <438CAC83.3010300@feuerpokemon.de>
References: <438C656B.2080701@redhat.com>
	<6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com>
	<438CAC83.3010300@feuerpokemon.de>
Message-ID: <6f6293f10511291132w531fe11cq173bab4464d3299f@mail.gmail.com>

> why with selinux=0 ? is it slower with selinux enabled?

It seems policy 2.X is having some trouble with udev.



From mpeters at mac.com  Tue Nov 29 19:37:14 2005
From: mpeters at mac.com (Michael A. Peters)
Date: Tue, 29 Nov 2005 11:37:14 -0800
Subject: fc5 goals
In-Reply-To: <1133288168.17843.23.camel@rousalka.dyndns.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
Message-ID: <1133293035.753.35.camel@locolhost.localdomain>

On Tue, 2005-11-29 at 19:16 +0100, Nicolas Mailhot wrote:

> 
> The problem is not what systems have DVD burners now.
> The problem is what systems won't have DVD burners by the time the
> single-CD FC ISO goal is achieved.

I don't think it will be achieved.

How much space does OpenOffice.org and all the build requirements for it
take? I'm guessing at least 1/4 of the available space - and I don't
think they are going to push OO.o to extras anytime in the future.

I don't think single CD is a realistic goal. Two CD's is a lot more
realistic - but even that may be difficult.



From arjan at fenrus.demon.nl  Tue Nov 29 19:50:27 2005
From: arjan at fenrus.demon.nl (Arjan van de Ven)
Date: Tue, 29 Nov 2005 20:50:27 +0100
Subject: fc5 goals
In-Reply-To: <1133293035.753.35.camel@locolhost.localdomain>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
Message-ID: <1133293827.2804.69.camel@laptopd505.fenrus.org>

On Tue, 2005-11-29 at 11:37 -0800, Michael A. Peters wrote:
> On Tue, 2005-11-29 at 19:16 +0100, Nicolas Mailhot wrote:
> 
> > 
> > The problem is not what systems have DVD burners now.
> > The problem is what systems won't have DVD burners by the time the
> > single-CD FC ISO goal is achieved.
> 
> I don't think it will be achieved.
> 
> How much space does OpenOffice.org and all the build requirements for it
> take? I'm guessing at least 1/4 of the available space - and I don't
> think they are going to push OO.o to extras anytime in the future.
> 
> I don't think single CD is a realistic goal. Two CD's is a lot more
> realistic - but even that may be difficult.

there's an alternative...
there could be a cd split such that OOo and related all ends up on one
cd, and the installer/firstboot adjusted in a way that it can take such 
"application CDs".

Heck maybe gnome and kde could be such cd's as well over time.





From mattdm at mattdm.org  Tue Nov 29 20:02:07 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Tue, 29 Nov 2005 15:02:07 -0500
Subject: fc5 goals
In-Reply-To: <1133293827.2804.69.camel@laptopd505.fenrus.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
	<1133293827.2804.69.camel@laptopd505.fenrus.org>
Message-ID: <20051129200207.GA17929@jadzia.bu.edu>

On Tue, Nov 29, 2005 at 08:50:27PM +0100, Arjan van de Ven wrote:
> there's an alternative...
> there could be a cd split such that OOo and related all ends up on one
> cd, and the installer/firstboot adjusted in a way that it can take such 
> "application CDs".
> Heck maybe gnome and kde could be such cd's as well over time.

I'm very much for that. In my mind, everything not on the "main" CD would be
Extras, but if people prefer for some of these extra sets to be Core still,
that's cool too.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From fenn at stanford.edu  Tue Nov 29 20:12:21 2005
From: fenn at stanford.edu (Tim Fenn)
Date: Tue, 29 Nov 2005 12:12:21 -0800
Subject: What about smartpm?
In-Reply-To: <1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me>
	<dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
Message-ID: <20051129201221.GC15724@stanford.edu>

On Tue, Nov 29, 2005 at 01:21:49PM -0500, Konstantin Ryabitsev wrote:
> On Tue, 2005-11-29 at 12:29 -0500, Neal Becker wrote:
> > I don't think so.  It's like this:
> > 
> > I want to install appA.  It has depB.
> > 
> > repoA and repoB both have depB.  repoA has appA.
> > 
> > Installing (via yum, smart, or whatever) picks up appA from repoA, and depB
> > from repoB.
> > 
> > Now, repoB updates depB.  No reason it shouldn't.
> > 
> > Now, IIUC, yum gives up on this situation.  It wants to update depB, but
> > appA needs the old version.
> > 
> > IIUC, not only does yum not update depB, but it _stops updating anything
> > completely_.  Your nightly yum upgrade stops until you notice the problem
> > and manually repair it.  (Correct me if I'm wrong here).
> 
> It's because this is a safer behaviour than guessing around various
> errors. You think it's wonderful, but it's far more error-prone than not
> doing anything "automagically" until the problem is actually fixed.
> Working around brokenness is a very slippery path to far graver and more
> obscure brokenness down the line.
> 

Perhaps it was a bad example (I don't think smart will break deps to
perform an upgrade, but I could be wrong).  Some interesting cases
(where indeed both yum and apt fail):

http://zorked.net/smart/doc/README.html#study-cases

Regards,
Tim



From nicolas.mailhot at laposte.net  Tue Nov 29 20:14:45 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Tue, 29 Nov 2005 21:14:45 +0100
Subject: fc5 goals
In-Reply-To: <1133293035.753.35.camel@locolhost.localdomain>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
Message-ID: <1133295288.4061.10.camel@rousalka.dyndns.org>

Le mardi 29 novembre 2005 ? 11:37 -0800, Michael A. Peters a ?crit :
> On Tue, 2005-11-29 at 19:16 +0100, Nicolas Mailhot wrote:
> 
> > 
> > The problem is not what systems have DVD burners now.
> > The problem is what systems won't have DVD burners by the time the
> > single-CD FC ISO goal is achieved.
> 
> I don't think it will be achieved.

I think systems won't have DVD burners by the time the single-CD FC ISO
goal is achieved. Because by the time it's achieved, DVD will be old
news. (should have been more clear in my message)

So my goals would be to :
1. make a kick-ass network boot iso
2. reduce package interdependencies and make network install smarter so
this iso can pull *small* sets of packages from the *large* FC pool.

In the last releases anaconda accrued a deplorable tendency to install
everything available all in the name of simplifying
installation/anaconda coding and reducing the number of possible RHEL
support scenarii. Unfortunately that means network installation bloat
has grown much faster than the FC ISO enveloppe. Focusing on the ISO
number is very wrong - will a two-CD FC that forces you to install
pretty much everything be so much better for small systems than a 4-CD
base from which you can build a 1 CD system ?

-- 
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/20051129/1e50d412/attachment.sig>

From dwalsh at redhat.com  Tue Nov 29 20:16:34 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Tue, 29 Nov 2005 15:16:34 -0500
Subject: custom selinux policy
In-Reply-To: <1133292469.19778.41.camel@www.lutty.net>
References: <1133215231.19778.28.camel@www.lutty.net>	<438C82A9.3060804@redhat.com>
	<1133292469.19778.41.camel@www.lutty.net>
Message-ID: <438CB722.7070100@redhat.com>

Laurent Jacquot wrote:
> On mar, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote:
>   
>> Laurent Jacquot wrote:
>>     
>>> Hello,
>>> I can no longer build my custom selinux policy with recent upgrades (SE
>>> policy source replaced with SE policy).
>>> What is the new way (used to be make reload)?
>>>
>>> tx in advance
>>> 	jk
>>>
>>>   
>>>       
>> You need to  use loadable modules.  Take a look a the man page for 
>> audit2allow, for some explanation.  I don't know if we have a good 
>> description available yet for loadable policy.
>>
>> The hardest part of converting your local.te into a loadable module will 
>> be writing the require section.
>> You need to define all types, class and roles in this section in order 
>> to get the loadable module.
>> ==================================================================================
>>        module local 1.0;
>>
>>        require {
>>                role system_r;
>>
>>                class fifo_file {  getattr ioctl };
>>
>>                type cupsd_config_t;
>>                type unconfined_t;
>>         };
>>
>>        allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
>> ==================================================================================
>>
>> -- 
>>     
> Thanks a lot for this info.
> BTW the audit2allow (policycoreutils-1.27.29-1) manpage isn't updated
> regarding the module stuff. Hopefully, the -M option is verbose
>
> Would you mind shed some light on the new file context definition? (used
> to be local.fc)
>
> Laurent
>
>
>
>   
manpage looks correct on my machine?

File context file should be the same.

 checkmodule -M -m -o /tmp/local.mod /tmp/local.te
semodule_package -o /tmp/local.pp -m /tmp/local.mod -f /tmp/local.fc





-- 




From icon at fedoraproject.org  Tue Nov 29 20:21:22 2005
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Tue, 29 Nov 2005 15:21:22 -0500
Subject: What about smartpm?
In-Reply-To: <20051129201221.GC15724@stanford.edu>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
Message-ID: <1133295682.16909.17.camel@rakta.wsg.mcgill.ca>

On Tue, 2005-11-29 at 12:12 -0800, Tim Fenn wrote:
> > It's because this is a safer behaviour than guessing around various
> > errors. You think it's wonderful, but it's far more error-prone than not
> > doing anything "automagically" until the problem is actually fixed.
> > Working around brokenness is a very slippery path to far graver and more
> > obscure brokenness down the line.
> > 
> 
> Perhaps it was a bad example (I don't think smart will break deps to
> perform an upgrade, but I could be wrong).  Some interesting cases
> (where indeed both yum and apt fail):
> 
> http://zorked.net/smart/doc/README.html#study-cases

Yeah, and this is still unsafe, because downgrading is inherently,
implicitly unsafe.

1. You can downgrade into a vulnerability
2. Downgrading often breaks, since newer version can do things in %post
that make downgrading to a workable state impossible

It's a fine feature, sure, but it's important that people understand --
yum doesn't offer this not because the developers are lazy, but because
safety and consistency is the prime directive as far as yum's feature
roadmap is concerned.

Regards,
-- 
Konstantin Ryabitsev
McGill University WSG
Montr?al, Qu?bec



From notting at redhat.com  Tue Nov 29 20:31:42 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 29 Nov 2005 15:31:42 -0500
Subject: fc5 goals
In-Reply-To: <20051129200207.GA17929@jadzia.bu.edu>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
	<1133293827.2804.69.camel@laptopd505.fenrus.org>
	<20051129200207.GA17929@jadzia.bu.edu>
Message-ID: <20051129203142.GF17795@devserv.devel.redhat.com>

Matthew Miller (mattdm at mattdm.org) said: 
> On Tue, Nov 29, 2005 at 08:50:27PM +0100, Arjan van de Ven wrote:
> > there's an alternative...
> > there could be a cd split such that OOo and related all ends up on one
> > cd, and the installer/firstboot adjusted in a way that it can take such 
> > "application CDs".
> > Heck maybe gnome and kde could be such cd's as well over time.
> 
> I'm very much for that. In my mind, everything not on the "main" CD would be
> Extras, but if people prefer for some of these extra sets to be Core still,
> that's cool too.

Here's something I wrote briefly to explain how some of this *could*
be done. Alas, no time to implement.

Bill

...



Rewrite splitdistro, pkgorder to let you do more fun things
-----------------------------------------------------------

First, you extend comps.

  Each group can have an optional <discid> tag. Multiple groups
  can share a <discid>. No discid for a group makes it 'Base',
  or 'Core', or whatever you want to call it.

  Later in the comps file you have <dischierarchy>, which
  denotes an order for the <discid> tags. (Alternatively, define
  discids to be numbers, and sort that way.) Order such that
  any obvious dependencies between groups are resolved;, i.e.,
  discids are listed below any discids they have deps on.
  
  <discids> are linked to an English string that is the title
  of the group, used in naming the CDs, and put in the discinfo
  file for the CD. It's intltool-ized and all that other good stuff,
  for display in $(YOUR PACKAGE GRABBING TOOL HERE).

Then, you redo how packages are ordered.

  Look at the universe of packages in your tree. Arrange them
  into the following groups based on comps:
  
  A: Packages listed in a comp that doesn't have a discid
  B: Packages listed in comps that have the first discid in the
     dischierarchy
  C: Packages listed in cimps that have the second discid ...
  ...
  #: Packages not in any comp.
  
  Structure things so that A, B, C, etc could be completely separate
  repos from your CD-creation set. For example, A could be Core,
  and B,C,D, etc are all things in Extras.
  
  Depsolve A against B,C, ... and #; move packages from other buckets
  to A to solve deps. If any deps are from B,C, ..., raise warning.
  
  Depsolve B, against A and #, move packages to solve deps. If any deps
  are unresolved, raise a hard error.
  
  Depsolve C, against A, B, and #, ...
  
  Throw everything else from # into A.
  
  Generate pkgorder for A.
  
  Generate pkgorder for B, as an additional transaction on top of A.
  
  Generate pkgorder for C, as an additional transaction on top of A and B.
  
  ...
  
  Split trees based on their separate pkgorders. Optionally, track in
  the pkgorders which packages are added to B, C, D, etc from #; if B,
  C, D... are sllightly over X discs, move those packages to A and
  recompute.

  Label CDs based on A with the standard "Name, Disc 1 ... X". Label
  CDs based on B, C, D... with the discid's name, and discs 1 ... X.
  
  Hence, now anaconda would display:
  
     To complete the install, you need:
     
        Fedora Core 5 disc #1
	Fedora Core 5 disc #2
	Fedora Office disc #1
	Fedora Java disc #1
	



From prushinsky at gmail.com  Tue Nov 29 20:37:53 2005
From: prushinsky at gmail.com (Yuri Prushinsky)
Date: Tue, 29 Nov 2005 23:37:53 +0300
Subject: fc5 goals
In-Reply-To: <438C9FB7.2060905@cornell.edu>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<438C9B91.1010907@gmail.com>
	<438C9FB7.2060905@cornell.edu>
Message-ID: <438CBC21.5000501@gmail.com>



Paul A Houle wrote:
> Yuri Prushinsky wrote:
> 
>> desktop manager is not the correct decision for removal, the more 
>> important is to move typical productivity 3rd party applications to 
>> Extras. I'm a KDE user, with every new release of Gnome I try to 
>> switch to it, but it's just not usable for me, sorry guys.
>>     So, I decided to delete apps that I never use, yum remove mozilla 
>> wiped out mozilla with a bunch of gnome-related packages. Fine, I 
>> don't need the beta of OOo, yum remove openoffice removed one and 
>> about 100 gnome-related packages! Rpm-hell is alive, and waits you 
>> under yum!
>>     Okay, now I have my lovely kdm, kde, and 3rd party firefox and the 
>> latest OOo, which have their own installators.
>> I really like the kind of Core that freeBSD provides, and it would be 
>> nice if FC will have the same tool set in its core.
>>
>    I've said it before,  but...
> 
>    If you don't like the package set chosen in Fedora core,  go ahead 
> and roll your own "Hard Core" linux.
> 
>    Fedora comes with a set of tools that will turn a directory full of 
> rpm's into a linux distribution you can burn onto an ISO.  Create a 
> .torrent and you can share it with everybody.  If you just want to 
> subset Fedora,  this ought to be easy.
> 
sure, but it seems not to be such a trivial solution at the FC4 state..

-- 
Sincerely yours,
  Yura



From eric.tanguy at univ-nantes.fr  Mon Nov 28 21:57:18 2005
From: eric.tanguy at univ-nantes.fr (Eric Tanguy)
Date: Mon, 28 Nov 2005 22:57:18 +0100
Subject: fc5 goals
In-Reply-To: <E1Egp6W-00079U-6a@server.mh-mars.com>
References: <E1Egp6W-00079U-6a@server.mh-mars.com>
Message-ID: <1133215038.3092.21.camel@bureau.maison>

Le lundi 28 novembre 2005 ? 11:56 -0800, Peter Gordon a ?crit :
> Josh Coffman wrote:
> > Anyone know where to find documentation about the
> > goals and improvements intended for FC5?
> 
> You might want to take a look at FC5Future[1] on the Wiki, as well.
> 
> [1] http://www.fedoraproject.org/wiki/FC5Future
> 
> --Peter
> 
Why there is so much java package included in fc5 ?
No news about early login or something like that ?
Why kde is still included in core whereas it could be in extras ?
Why some packages go directly in core and not in extras before ? Because
they were packaged by someone from redhat ? Is it sufficient ???

I saw the long discussion about what to include in or not in fc5 but
maybe the problem will be the goal of fedora ?

Is this product mainly for developpers form redhat ? 

yes i know i'm joking but in fact it could be a good question, no ?
Thanks

Eric





From benjy.grogan at gmail.com  Tue Nov 29 21:07:19 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Tue, 29 Nov 2005 16:07:19 -0500
Subject: Modern Update System
In-Reply-To: <20051129093348.GB5877@suse.de>
References: <1133232911.5030.16.camel@dhollis-lnx.sunera.com>
	<1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
Message-ID: <d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>

Michael,

What would be the size of said deltarpms for Openoffice?  Are there any
drawbacks to the deltarpms?

Benjy,
AWWTF

On 11/29/05, Michael Schroeder <mls at suse.de> wrote:
>
> On Tue, Nov 29, 2005 at 01:51:39AM -0500, Benjy Grogan wrote:
> > Yeah, that's what I'm starting to think.  Having to have the initial rpm
> on
> > your hard drive all the time would be another kind of waste.
> >
> > It comes down to more fundamental changes.  If the method of keeping
> rpms on
> > your hard drive is ditched then you're left with sending pure binary
> patches
> > to the actual files.  That's the best way, but a complete reorganization
> is
> > then needed.
> >
> > Sounds like one of these long projects that requires corporate funding
> to
> > see it through a few years work.  I think it's an important enough
> challenge
> > to tackle that Red Hat, IBM and Novell should work together to do this.
> >
> > It's alot of work any way it's done.  Best to go for the best solution
> and
> > find some backing and then hope everyone interested shows up to help
> out.
>
> Guys, the deltarpm package already does all this. It doesn't need
> to initial rpm on the harddisk, it can work with the installed files.
> The current version even has a 'combinedeltarpm' command, so you
> can collapse a chain of deltas into a single one.
>
> Novell uses deltarpms since over a year now, mandriva-2005 has
> them as well.
>
> Cheers,
>   Michael.
>
> --
> Michael Schroeder                                   mls at suse.de
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
>
> --
> 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/20051129/5554a17b/attachment.htm>

From fenn at stanford.edu  Tue Nov 29 21:27:47 2005
From: fenn at stanford.edu (Tim Fenn)
Date: Tue, 29 Nov 2005 13:27:47 -0800
Subject: What about smartpm?
In-Reply-To: <1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me>
	<dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
Message-ID: <20051129212747.GD15724@stanford.edu>

On Tue, Nov 29, 2005 at 03:21:22PM -0500, Konstantin Ryabitsev wrote:
> On Tue, 2005-11-29 at 12:12 -0800, Tim Fenn wrote:
> > > It's because this is a safer behaviour than guessing around various
> > > errors. You think it's wonderful, but it's far more error-prone than not
> > > doing anything "automagically" until the problem is actually fixed.
> > > Working around brokenness is a very slippery path to far graver and more
> > > obscure brokenness down the line.
> > > 
> > 
> > Perhaps it was a bad example (I don't think smart will break deps to
> > perform an upgrade, but I could be wrong).  Some interesting cases
> > (where indeed both yum and apt fail):
> > 
> > http://zorked.net/smart/doc/README.html#study-cases
> 
> Yeah, and this is still unsafe, because downgrading is inherently,
> implicitly unsafe.
> 
> 1. You can downgrade into a vulnerability
> 2. Downgrading often breaks, since newer version can do things in %post
> that make downgrading to a workable state impossible
> 

Can I not reverse this argument to state:

Yeah, and this is still unsafe, because upgrading is inherently,
implicitly unsafe.

1. you can upgrade into a vulnerability
2. upgrading often breaks, since newer versions can do things in %pre
that make upgrading to a workable state impossible.

And have it be equally valid?  ;)

Regards,
-Tim



From michael.favia at insitesinc.com  Tue Nov 29 21:34:17 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 15:34:17 -0600
Subject: fc5 goals
In-Reply-To: <20051129203142.GF17795@devserv.devel.redhat.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<dmhehp$oqu$1@sea.gmane.org>	<1133288168.17843.23.camel@rousalka.dyndns.org>	<1133293035.753.35.camel@locolhost.localdomain>	<1133293827.2804.69.camel@laptopd505.fenrus.org>	<20051129200207.GA17929@jadzia.bu.edu>
	<20051129203142.GF17795@devserv.devel.redhat.com>
Message-ID: <438CC959.7020600@insitesinc.com>

Bill Nottingham wrote:
> 
> Here's something I wrote briefly to explain how some of this *could*
> be done. Alas, no time to implement.

It is a shame because this is the direction i think this conversation 
really needs to take. Getting "core" down to some arbitrary number of 
CD's is unimportant imo.

I don't have any numbers so i can only go off of the people in #fedora 
and those individuals i know but one of the bigger frustrations poeple 
have is to install fedora from media only to have to update *most* of it 
as soon as they are breathing internet air. I recognize the are 
necessary/beneficial updates and i am not faulting them in the least. 
Additionally, the modularization of many large components (X.org, OOo, 
etc) is reducing the drag this effect has on the userbase. However, the 
modularization of the installation media and the streamlining of the 
application installation/management process would really content a lot 
of users.

I feel the goal should be an attempt to split functionality up so that 
you can have a working networkable computer with a modern desktop and 
place whatever other tools on that cd as fit and stay in line with its 
purpose. By providing the self contained "Basic Networked Desktop" on 
one installation media and the rest on grouped application specific 
media (java + development, office productivity, etc) you content both 
big usecases i hear mentioned every time this discussion comes up.

The individual who doesnt have internet access readily available still 
gets his media in just as usable form and possibly in fewer discs 
depending on their needs. And the user with good internet connection can 
get up and running with minimal predownloading and burning. If their 
network card is supported and they can get the updated versions from the 
repo's (core+extras even) directly out of anaconda even better imo.

Like i said though i don't know who this might hurt because i live in a 
country where you cant walk three feet without a wifi starbucks or like 
coffee shop hitting you in the face (hell even McDonalds now i hear). Is 
there a reason something like BN's idea is a bad one?

-mf



From michael.favia at insitesinc.com  Tue Nov 29 21:37:00 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 15:37:00 -0600
Subject: fc5 goals
In-Reply-To: <1133215038.3092.21.camel@bureau.maison>
References: <E1Egp6W-00079U-6a@server.mh-mars.com>
	<1133215038.3092.21.camel@bureau.maison>
Message-ID: <438CC9FC.4020805@insitesinc.com>

Eric Tanguy wrote:
> Le lundi 28 novembre 2005 ? 11:56 -0800, Peter Gordon a ?crit :
>> Josh Coffman wrote:
>>> Anyone know where to find documentation about the
>>> goals and improvements intended for FC5?
>> You might want to take a look at FC5Future[1] on the Wiki, as well.
>>
>> [1] http://www.fedoraproject.org/wiki/FC5Future
>>
>> --Peter
>>
> Why there is so much java package included in fc5 ?
> No news about early login or something like that ?
> Why kde is still included in core whereas it could be in extras ?
> Why some packages go directly in core and not in extras before ? Because
> they were packaged by someone from redhat ? Is it sufficient ???
> I saw the long discussion about what to include in or not in fc5 but
> maybe the problem will be the goal of fedora ?
> Is this product mainly for developpers form redhat ? 
> yes i know i'm joking but in fact it could be a good question, no ?

That is a lot of questions man. Consult archives and google. Or hire a 
researcher.
-mf



From icon at fedoraproject.org  Tue Nov 29 21:41:24 2005
From: icon at fedoraproject.org (Konstantin Ryabitsev)
Date: Tue, 29 Nov 2005 16:41:24 -0500
Subject: What about smartpm?
In-Reply-To: <20051129212747.GD15724@stanford.edu>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
Message-ID: <1133300484.16909.19.camel@rakta.wsg.mcgill.ca>

On Tue, 2005-11-29 at 13:27 -0800, Tim Fenn wrote:
> > Yeah, and this is still unsafe, because downgrading is inherently,
> > implicitly unsafe.
> > 
> > 1. You can downgrade into a vulnerability
> > 2. Downgrading often breaks, since newer version can do things in %post
> > that make downgrading to a workable state impossible
> > 
> 
> Can I not reverse this argument to state:
> 
> Yeah, and this is still unsafe, because upgrading is inherently,
> implicitly unsafe.
> 
> 1. you can upgrade into a vulnerability
> 2. upgrading often breaks, since newer versions can do things in %pre
> that make upgrading to a workable state impossible.
> 
> And have it be equally valid?  ;)

No.

-- 
Konstantin Ryabitsev
McGill University WSG
Montr?al, Qu?bec



From skvidal at phy.duke.edu  Tue Nov 29 21:50:06 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 29 Nov 2005 16:50:06 -0500
Subject: What about smartpm?
In-Reply-To: <20051129212747.GD15724@stanford.edu>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
Message-ID: <1133301006.7585.28.camel@cutter>


> Can I not reverse this argument to state:
> 
> Yeah, and this is still unsafe, because upgrading is inherently,
> implicitly unsafe.

upgrading isn't inherently unsafe. Especially when there are KNOWN
exploits in older versions.


> 1. you can upgrade into a vulnerability
You are unlikely to upgrade into a KNOWN vulnerability.


> 2. upgrading often breaks, since newer versions can do things in %pre
> that make upgrading to a workable state impossible.

if this is true then it's a problem with:
 1. all pkg managers
 2. all distros

The point Icon was making is about smart's mechanism and it's ability to
downgrade as a solution.


That's why it is not equally valid.

-sv




From jspaleta at gmail.com  Tue Nov 29 22:01:21 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 29 Nov 2005 17:01:21 -0500
Subject: What about smartpm?
In-Reply-To: <20051129212747.GD15724@stanford.edu>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
Message-ID: <604aa7910511291401o5c7cb4a7jf8768c527d1b3a59@mail.gmail.com>

On 11/29/05, Tim Fenn <fenn at stanford.edu> wrote:
> Yeah, and this is still unsafe, because upgrading is inherently,
> implicitly unsafe.
>
> 1. you can upgrade into a vulnerability
> 2. upgrading often breaks, since newer versions can do things in %pre
> that make upgrading to a workable state impossible.
>
> And have it be equally valid?  ;)

Are you here to argue semantics or are you here to have a constructive
conversation?
The issue is about "known" vulnerabilities and "expected" problems
based on how scriplets are designed to work.

Vulnerabilities get fixed with upgrades as they are discovered and
developers respond. Its pretty clear to anyone willing to be rational,
that software updates are inspired to deal with "known"
vulnerabilities. Tools that takes the thought out of downgrading into
a known insecurity from a more security state does those users a
disservice.  This of course is not the strongest argument that can be
made against downgrading, since notification about security issues
could be incorporated either from the changelog difference or from
seperate notification text to inform the users of the risk.

The stronger argument against this behavior is about how rpm packages
are actually designed and tested. How much testing does anyone do with
regard to downgrades? Is there any packager out there that creates
upgrades to fix issues regarding downgrading?
I'll go out on a limb and suggest that the number of maintainers who
do spend any time on making sure downgrades work smoothly is
vanishingly small. We know this situation gets absolutely no testing,
and gets absolutely no maintenance and as a result tools should not be
automating the process when the results are ill-defined.

-jef



From Eric.Tanguy at univ-nantes.fr  Tue Nov 29 22:03:30 2005
From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY)
Date: Tue, 29 Nov 2005 23:03:30 +0100 (CET)
Subject: Kernel module question
In-Reply-To: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>
References: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>
Message-ID: <38183.86.195.205.129.1133301810.squirrel@webmail.univ-nantes.fr>

> If i remember well the rt5x00 driver would be included in kernel. Someone
> could confirm that ? When it will be incuded in fedora kernel ?
> Thanks
> Eric
>
This is not the right place to ask this kind of question ?
Eric




From Eric.Tanguy at univ-nantes.fr  Tue Nov 29 22:04:15 2005
From: Eric.Tanguy at univ-nantes.fr (Eric TANGUY)
Date: Tue, 29 Nov 2005 23:04:15 +0100 (CET)
Subject: Early login and ...
In-Reply-To: <60754.86.199.0.227.1133242458.squirrel@webmail.univ-nantes.fr>
References: <60754.86.199.0.227.1133242458.squirrel@webmail.univ-nantes.fr>
Message-ID: <38183.86.195.205.129.1133301855.squirrel@webmail.univ-nantes.fr>

> It seems that the early login project is stopped is there something else
> to replace it ? And what about its inclusion in FC5 ?
> Thanks
> Eric
>
This is not the right place to ask this kind of question ?
Eric



From wrrhdev at riede.org  Tue Nov 29 22:22:53 2005
From: wrrhdev at riede.org (Willem Riede)
Date: Tue, 29 Nov 2005 22:22:53 +0000
Subject: status of up2date and rhn-applet
In-Reply-To: <20051129075855.GB13739@neu.nirvana> (from
	Axel.Thimm@ATrpms.net on Tue Nov 29 02:58:55 2005)
Message-ID: <1133302973l.22893l.6l@serve.riede.org>

On 11/29/2005 02:58:55 AM, Axel Thimm wrote:
> On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote:
> > >>>>> "WR" == Willem Riede <wrrhdev at riede.org> writes:
> >
> > WR> Maybe I shouldn't care, but I do. As an example, with all due
> > WR> respect to its creator, the atrpms repository holds both packages
> > WR> I want (unique functionality) and that I don't want (core
> > WR> replacements). Unfortunately that means I can never do a blind
> > WR> cross-the-board upgrade from all the sources I've identified.
> >
> > It would be very nice if one of the update utilities could be set to
> > ignore updates across repositories. I.e. if I've installed foo from
> > core and bar from atrpms and atrpms has newer versions of both foo and
> > bar, only bar gets updated.
> 
> Maybe it's better to avoid atrpms at all then, as its bar will
> probably assume that you are using foo from the same source? Perhaps
> foo in core is being replaced just to add the functionality that bar
> needs?

Good point. I would hope that in such cases the bar from add-on repos has an  
explicit Requires: on the foo fromthe same repo...

> It isn't as black or white as it seems. I've had enough bug reports on
> using apt and smart with priorities/weights to strongly advise against
> their use (not apt/smart's, but their weighing mechanisms).
> 
> And if you don't trust repo X to replace package Y, then why trust it
> to offer package Z? Better drop repo X, if you feel uncomfortable.

Well, that aspect is also not black and white :-) Some repo may have several  
clusters of changed or additional rpms, and I may want one of those clusters  
because my desire for that functionality is larger than my concern for the  
system's stability, but I am happy with the base distribution for other  
clusters, so I don't want those replaced.

The way I'd love to be able to do it, is to initially explicitely install new  
rpms and accept upgrades due to dependencies of the rpm that provides the new  
functionality, and later when doing "yum update" have only rpms that originate  
from the same repo as what is already installed (on a package by package  
basis) selected.

Thanks, Willem Riede.



From michael.favia at insitesinc.com  Tue Nov 29 22:23:19 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 16:23:19 -0600
Subject: Kernel module question
In-Reply-To: <38183.86.195.205.129.1133301810.squirrel@webmail.univ-nantes.fr>
References: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>
	<38183.86.195.205.129.1133301810.squirrel@webmail.univ-nantes.fr>
Message-ID: <438CD4D7.7040200@insitesinc.com>

Eric TANGUY wrote:
>> If i remember well the rt5x00 driver would be included in kernel. Someone
>> could confirm that ? When it will be incuded in fedora kernel ?
>> Thanks
>> Eric
>>
> This is not the right place to ask this kind of question ?
> Eric

Dont know what driver you refer to (perhaps you meant rt2x00). Fedora 
tries to ship as close to upstream as possible on their kernels as far 
as driver support goes. This means that your driver will be included 
when it is included upstream. -mf



From dwmw2 at infradead.org  Wed Nov 30 00:02:36 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 30 Nov 2005 00:02:36 +0000
Subject: kernel bad locking
In-Reply-To: <1133274135.3618.3.camel@xpc.home.erwinrol.com>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
	<1133274135.3618.3.camel@xpc.home.erwinrol.com>
Message-ID: <1133308956.4117.1.camel@baythorne.infradead.org>

On Tue, 2005-11-29 at 15:22 +0100, Erwin Rol wrote:
> David Woodhouse is right, it is bug
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174438
> after i added the "dontpanic" option i got about the same trace, into
> ehci_hcd : ehci_port_power.

Should be fixed in tomorrow's 2.6.14-1.1720

-- 
dwmw2




From davej at redhat.com  Wed Nov 30 00:11:34 2005
From: davej at redhat.com (Dave Jones)
Date: Tue, 29 Nov 2005 19:11:34 -0500
Subject: kernel bad locking
In-Reply-To: <1133308956.4117.1.camel@baythorne.infradead.org>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
	<1133274135.3618.3.camel@xpc.home.erwinrol.com>
	<1133308956.4117.1.camel@baythorne.infradead.org>
Message-ID: <20051130001134.GB4555@redhat.com>

On Wed, Nov 30, 2005 at 12:02:36AM +0000, David Woodhouse wrote:
 > On Tue, 2005-11-29 at 15:22 +0100, Erwin Rol wrote:
 > > David Woodhouse is right, it is bug
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174438
 > > after i added the "dontpanic" option i got about the same trace, into
 > > ehci_hcd : ehci_port_power.
 > 
 > Should be fixed in tomorrow's 2.6.14-1.1720

early-adopters as usual can get the build-de-jour from
http://people.redhat.com/davej/kernels/Fedora/devel/

		Dave



From eric.tanguy at univ-nantes.fr  Tue Nov 29 22:38:15 2005
From: eric.tanguy at univ-nantes.fr (Eric Tanguy)
Date: Tue, 29 Nov 2005 23:38:15 +0100
Subject: Kernel module question
In-Reply-To: <438CD4D7.7040200@insitesinc.com>
References: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>
	<38183.86.195.205.129.1133301810.squirrel@webmail.univ-nantes.fr>
	<438CD4D7.7040200@insitesinc.com>
Message-ID: <1133303895.2899.1.camel@bureau.maison>

Le mardi 29 novembre 2005 ? 16:23 -0600, Michael Favia a ?crit :
> Eric TANGUY wrote:
> >> If i remember well the rt5x00 driver would be included in kernel. Someone
> >> could confirm that ? When it will be incuded in fedora kernel ?
> >> Thanks
> >> Eric
> >>
> > This is not the right place to ask this kind of question ?
> > Eric
> 
> Dont know what driver you refer to (perhaps you meant rt2x00). Fedora 
> tries to ship as close to upstream as possible on their kernels as far 
> as driver support goes. This means that your driver will be included 
> when it is included upstream. -mf
> 
Sorry you are right it was rt2x00 but i would like to know if someone
know if this driver will be included upstream and if yes when.
Thanks
Eric





From mailinglists at erwinrol.com  Wed Nov 30 00:42:32 2005
From: mailinglists at erwinrol.com (Erwin Rol)
Date: Wed, 30 Nov 2005 01:42:32 +0100
Subject: kernel bad locking
In-Reply-To: <20051130001134.GB4555@redhat.com>
References: <1133271488.3861.0.camel@xpc.home.erwinrol.com>
	<1133272255.2804.39.camel@laptopd505.fenrus.org>
	<1133274135.3618.3.camel@xpc.home.erwinrol.com>
	<1133308956.4117.1.camel@baythorne.infradead.org>
	<20051130001134.GB4555@redhat.com>
Message-ID: <1133311353.3594.0.camel@xpc.home.erwinrol.com>

On Tue, 2005-11-29 at 19:11 -0500, Dave Jones wrote:
> On Wed, Nov 30, 2005 at 12:02:36AM +0000, David Woodhouse wrote:
>  > On Tue, 2005-11-29 at 15:22 +0100, Erwin Rol wrote:
>  > > David Woodhouse is right, it is bug
>  > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174438
>  > > after i added the "dontpanic" option i got about the same trace, into
>  > > ehci_hcd : ehci_port_power.
>  > 
>  > Should be fixed in tomorrow's 2.6.14-1.1720
> 
> early-adopters as usual can get the build-de-jour from
> http://people.redhat.com/davej/kernels/Fedora/devel/
> 

That kernel works for me.

- Erwin




From michael.favia at insitesinc.com  Wed Nov 30 02:26:40 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Tue, 29 Nov 2005 20:26:40 -0600
Subject: Kernel module question
In-Reply-To: <1133303895.2899.1.camel@bureau.maison>
References: <55980.86.199.0.227.1133242367.squirrel@webmail.univ-nantes.fr>	<38183.86.195.205.129.1133301810.squirrel@webmail.univ-nantes.fr>	<438CD4D7.7040200@insitesinc.com>
	<1133303895.2899.1.camel@bureau.maison>
Message-ID: <438D0DE0.8080905@insitesinc.com>

Eric Tanguy wrote:
> Sorry you are right it was rt2x00 but i would like to know if someone
> know if this driver will be included upstream and if yes when.

Yes it is going upstream but as to when, you might want to take that 
question to Mark Wallis or IvD but im pretty sure their response will be 
"when it is ready". rt2x00 has a nice forum and you can help by beta 
testing the unified driver if you'd like to move things along faster. A 
distro doesn't direct the types of upstream changes you are looking for 
very often. -mf



From bbbush.yuan at gmail.com  Wed Nov 30 03:48:06 2005
From: bbbush.yuan at gmail.com (Yuan Yijun)
Date: Wed, 30 Nov 2005 11:48:06 +0800
Subject: What about smartpm?
In-Reply-To: <604aa7910511291401o5c7cb4a7jf8768c527d1b3a59@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
	<604aa7910511291401o5c7cb4a7jf8768c527d1b3a59@mail.gmail.com>
Message-ID: <76e72f800511291948o2478ae2bs@mail.gmail.com>

2005/11/30, Jeff Spaleta <jspaleta at gmail.com>:
>
> Are you here to argue semantics or are you here to have a constructive
> conversation?
> The issue is about "known" vulnerabilities and "expected" problems
> based on how scriplets are designed to work.
>
> Vulnerabilities get fixed with upgrades as they are discovered and
> developers respond. Its pretty clear to anyone willing to be rational,
> that software updates are inspired to deal with "known"
> vulnerabilities. Tools that takes the thought out of downgrading into
> a known insecurity from a more security state does those users a
> disservice.  This of course is not the strongest argument that can be
> made against downgrading, since notification about security issues
> could be incorporated either from the changelog difference or from
> seperate notification text to inform the users of the risk.
>
> The stronger argument against this behavior is about how rpm packages
> are actually designed and tested. How much testing does anyone do with
> regard to downgrades? Is there any packager out there that creates
> upgrades to fix issues regarding downgrading?
> I'll go out on a limb and suggest that the number of maintainers who
> do spend any time on making sure downgrades work smoothly is
> vanishingly small. We know this situation gets absolutely no testing,
> and gets absolutely no maintenance and as a result tools should not be
> automating the process when the results are ill-defined.
>
> -jef
>

When you say "upgrade", you mean "always upgrade to the newest
version", even if there is one that is not the newest but newer than
none and can satisfy the dependencies of another software? I don't
want to wait for both  becoming newest, I want to use it now. If using
yum, I must disable the repo which contains the newest dependencies
AFAIK. This happens with gstreamer repo, but I cannot remember it
clearly.

--
bbbush ^_^



From bernie at develer.com  Wed Nov 30 04:44:32 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Wed, 30 Nov 2005 05:44:32 +0100
Subject: fc5 goals
In-Reply-To: <1133295288.4061.10.camel@rousalka.dyndns.org>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<dmhehp$oqu$1@sea.gmane.org>	<1133288168.17843.23.camel@rousalka.dyndns.org>	<1133293035.753.35.camel@locolhost.localdomain>
	<1133295288.4061.10.camel@rousalka.dyndns.org>
Message-ID: <438D2E30.5020003@develer.com>

Nicolas Mailhot wrote:

> So my goals would be to :
> 1. make a kick-ass network boot iso

I've been installing clients over NFS quite happily for years.

Usually, I boot from the DVD (but could be CD1) and then select
NFS installation.

I wish I could use pxeboot, but the number of motherboards
capable of network boot is still not good enough.


> 2. reduce package interdependencies and make network install smarter so
> this iso can pull *small* sets of packages from the *large* FC pool.

+1.

This is something that requires some help from upstream developers
(split programs into modules, use plugins, dlopen rarely used
libraries, etc.).

Something that *could* be done now is extending RPM to add the concept
of soft-requirements.  Something along the lines of Debian's "Suggests"
tag.

For example, ssh could suggest kerberos instead of just requiring it.



> In the last releases anaconda accrued a deplorable tendency to install
> everything available all in the name of simplifying
> installation/anaconda coding and reducing the number of possible RHEL
> support scenarii.

I agree on the basic philosophy, but I had irritating experiences with
distros that try to be minimalist and forget to install an ftp client
or development packages.

You end up installing RPMs one by one for weeks before you can
start being productive.  Disk space is cheap and removing unwanted
packages later is easy enough.

Fedora is still a lightweight distribution with respect to SuSE
(~3GB for the default installation) or even Debian and Mandriva.

For special systems where I'm very space constrained, such as
embedded systems, one would not consider a desktop distribution
such as Fedora because you'd have to rebuild packages to remove
big dependencies such as selinux, audit, kerberos and openssl.

Let's not try to shift Fedora to this goal.  Extreme scalability
is an area where distributions focused on binary packages will
never be able to compete with systems like Gentoo, LFS or uClinux.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/




From bernie at develer.com  Wed Nov 30 05:06:14 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Wed, 30 Nov 2005 06:06:14 +0100
Subject: gcc in rawhide.
In-Reply-To: <20051129083811.GS31785@devserv.devel.redhat.com>
References: <438C12D4.4080607@online.no>
	<20051129083811.GS31785@devserv.devel.redhat.com>
Message-ID: <438D3346.9050708@develer.com>

Jakub Jelinek wrote:

> On Tue, Nov 29, 2005 at 09:35:32AM +0100, Knut J Bjuland wrote:
>> When'll gcc in rawhide be update since gcc in update-test in newer than
>> gcc in rawhide.
> 
> As soon as gcc-4.1.0-0.x is in a usable shape, we are working on it.

Great!  Out of curiosity, do you already have some numbers
on the size or performance change of some packages when
built with GCC 4.1?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From tgl at redhat.com  Wed Nov 30 05:09:17 2005
From: tgl at redhat.com (Tom Lane)
Date: Wed, 30 Nov 2005 00:09:17 -0500
Subject: fc5 goals 
In-Reply-To: <438D2E30.5020003@develer.com> 
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133216126.24512.78.camel@prometheus.gamehouse.com>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
	<1133295288.4061.10.camel@rousalka.dyndns.org>
	<438D2E30.5020003@develer.com>
Message-ID: <13160.1133327357@sss.pgh.pa.us>

Bernardo Innocenti <bernie at develer.com> writes:
> I agree on the basic philosophy, but I had irritating experiences with
> distros that try to be minimalist and forget to install an ftp client
> or development packages.
> You end up installing RPMs one by one for weeks before you can
> start being productive.

I just ran into a related issue today.  For quite some time, the
PostgreSQL community has been seeing sporadic reports of database
initialization failures that could only be explained by supposing
that 'setlocale(LC_MESSAGES, "")' returns NULL.  There can hardly
be any doubt that this behavior contravenes the spec:
http://www.opengroup.org/onlinepubs/007908799/xsh/setlocale.html
but we'd seen it reported on more than one platform.  We found out
today that glibc, at least, fails in this way if the underlying
locale definition files are not installed.

Now, no one running Fedora or RHEL will ever see this failure, because
the required files are packaged in glibc-common ... but it seems that
SuSE, for one, puts those files in an optional package glibc-locale.
And glibc isn't able to behave sanely when glibc-locale isn't there.

The moral I draw is that subdividing stuff comes at a nontrivial
cost in making software able to function well in more and more
subtly different environments.  The above-described behavior is
not a bug for Red Hat's version of glibc, but I say that it damn
well is a bug for SuSE.  Do we want to go down that path?

			regards, tom lane



From bernie at develer.com  Wed Nov 30 06:29:00 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Wed, 30 Nov 2005 07:29:00 +0100
Subject: fc5 goals
In-Reply-To: <13160.1133327357@sss.pgh.pa.us>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133216126.24512.78.camel@prometheus.gamehouse.com>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<dmhehp$oqu$1@sea.gmane.org>	<1133288168.17843.23.camel@rousalka.dyndns.org>	<1133293035.753.35.camel@locolhost.localdomain>	<1133295288.4061.10.camel@rousalka.dyndns.org>	<438D2E30.5020003@develer.com>
	<13160.1133327357@sss.pgh.pa.us>
Message-ID: <438D46AC.4030708@develer.com>

Tom Lane wrote:

> The moral I draw is that subdividing stuff comes at a nontrivial
> cost in making software able to function well in more and more
> subtly different environments.  The above-described behavior is
> not a bug for Red Hat's version of glibc, but I say that it damn
> well is a bug for SuSE.  Do we want to go down that path?

I do agree that providing too many configurations would
open the door to several scenarios like the one you depicted.

However, one of my co-workers uses Gentoo and he's used to be
able to compile-in and compile-out core components such as
ldap, audit and even locale support.  He does that using
package options exposed by emerge, similar to "rpmbuild --with foo".
Such changes affect several packages distribution-wise, from
Firefox to bash.

I don't know how much is zealotism and how much is true, but
my mate keeps telling me everything keeps working and even
*building* flawlessly whatever funny option combinations he
chooses.  Some Gentoo scripts I've seen seem to test for
missing features and alternative implementations where
needed.

I'm very impressed.  How do the Gentoo people manage to test
their distro with so many configurations?  I believe they
still have a much smaller user and developer base than ours.
Answering this question would be interesting from a
development process point of view.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From jspaleta at gmail.com  Wed Nov 30 06:44:11 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 30 Nov 2005 01:44:11 -0500
Subject: fc5 goals
In-Reply-To: <438D46AC.4030708@develer.com>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
	<1133295288.4061.10.camel@rousalka.dyndns.org>
	<438D2E30.5020003@develer.com> <13160.1133327357@sss.pgh.pa.us>
	<438D46AC.4030708@develer.com>
Message-ID: <604aa7910511292244v3acc7152i81b96c7343900de6@mail.gmail.com>

On 11/30/05, Bernardo Innocenti <bernie at develer.com> wrote:
> I'm very impressed.  How do the Gentoo people manage to test
> their distro with so many configurations?

simple answer... they don't.

-jef



From tgl at redhat.com  Wed Nov 30 06:54:35 2005
From: tgl at redhat.com (Tom Lane)
Date: Wed, 30 Nov 2005 01:54:35 -0500
Subject: fc5 goals 
In-Reply-To: <604aa7910511292244v3acc7152i81b96c7343900de6@mail.gmail.com> 
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>
	<1133217858.11240.8.camel@rousalka.dyndns.org>
	<438BBB6E.9070505@develer.com> <dmhehp$oqu$1@sea.gmane.org>
	<1133288168.17843.23.camel@rousalka.dyndns.org>
	<1133293035.753.35.camel@locolhost.localdomain>
	<1133295288.4061.10.camel@rousalka.dyndns.org>
	<438D2E30.5020003@develer.com> <13160.1133327357@sss.pgh.pa.us>
	<438D46AC.4030708@develer.com>
	<604aa7910511292244v3acc7152i81b96c7343900de6@mail.gmail.com>
Message-ID: <13907.1133333675@sss.pgh.pa.us>

Jeff Spaleta <jspaleta at gmail.com> writes:
> On 11/30/05, Bernardo Innocenti <bernie at develer.com> wrote:
>> I'm very impressed.  How do the Gentoo people manage to test
>> their distro with so many configurations?

> simple answer... they don't.

Aye.  I've seen plenty of irreproducible failures reported by Gentoo
users.  I don't mind working on a flaky database ... or compiler ...
or operating system ... but please not all at once.

			regards, tom lane



From skvidal at phy.duke.edu  Wed Nov 30 07:11:47 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 02:11:47 -0500
Subject: What about smartpm?
In-Reply-To: <76e72f800511291948o2478ae2bs@mail.gmail.com>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
	<604aa7910511291401o5c7cb4a7jf8768c527d1b3a59@mail.gmail.com>
	<76e72f800511291948o2478ae2bs@mail.gmail.com>
Message-ID: <1133334707.27845.3.camel@cutter>

On Wed, 2005-11-30 at 11:48 +0800, Yuan Yijun wrote:
> 2005/11/30, Jeff Spaleta <jspaleta at gmail.com>:
> >
> > Are you here to argue semantics or are you here to have a constructive
> > conversation?
> > The issue is about "known" vulnerabilities and "expected" problems
> > based on how scriplets are designed to work.
> >
> > Vulnerabilities get fixed with upgrades as they are discovered and
> > developers respond. Its pretty clear to anyone willing to be rational,
> > that software updates are inspired to deal with "known"
> > vulnerabilities. Tools that takes the thought out of downgrading into
> > a known insecurity from a more security state does those users a
> > disservice.  This of course is not the strongest argument that can be
> > made against downgrading, since notification about security issues
> > could be incorporated either from the changelog difference or from
> > seperate notification text to inform the users of the risk.
> >
> > The stronger argument against this behavior is about how rpm packages
> > are actually designed and tested. How much testing does anyone do with
> > regard to downgrades? Is there any packager out there that creates
> > upgrades to fix issues regarding downgrading?
> > I'll go out on a limb and suggest that the number of maintainers who
> > do spend any time on making sure downgrades work smoothly is
> > vanishingly small. We know this situation gets absolutely no testing,
> > and gets absolutely no maintenance and as a result tools should not be
> > automating the process when the results are ill-defined.
> >
> > -jef
> >
> 
> When you say "upgrade", you mean "always upgrade to the newest
> version", even if there is one that is not the newest but newer than
> none and can satisfy the dependencies of another software? I don't
> want to wait for both  becoming newest, I want to use it now. If using
> yum, I must disable the repo which contains the newest dependencies
> AFAIK. This happens with gstreamer repo, but I cannot remember it
> clearly.

but think about that.

So let's say in all the repos you have:

foo-1.0
foo-1.5
foo-2.0

you want to install bar 1.5 which requires foo-1.5

so let's say yum did that and installed bar 1.5 and foo 1.5.
What's going to happen the next time you run yum update?

It's going to put update you do foo-2.0

so why not cut out the intermediate step.

-sv




From skvidal at phy.duke.edu  Wed Nov 30 07:13:04 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 02:13:04 -0500
Subject: What about smartpm?
In-Reply-To: <1133334707.27845.3.camel@cutter>
References: <1133024107.4090.14.camel@localhost>
	<1133024789.2812.9.camel@yoda.loki.me> <dmhvur$p5m$1@sea.gmane.org>
	<1133283772.2833.58.camel@yoda.loki.me> <dmi36c$7f8$1@sea.gmane.org>
	<1133288509.16909.9.camel@rakta.wsg.mcgill.ca>
	<20051129201221.GC15724@stanford.edu>
	<1133295682.16909.17.camel@rakta.wsg.mcgill.ca>
	<20051129212747.GD15724@stanford.edu>
	<604aa7910511291401o5c7cb4a7jf8768c527d1b3a59@mail.gmail.com>
	<76e72f800511291948o2478ae2bs@mail.gmail.com>
	<1133334707.27845.3.camel@cutter>
Message-ID: <1133334784.27845.5.camel@cutter>


> It's going to put update you do foo-2.0

That was NOT english. Many apologies:

That should read:
It's going to update you to foo-2.0

-sv




From bernie at develer.com  Wed Nov 30 07:22:47 2005
From: bernie at develer.com (Bernardo Innocenti)
Date: Wed, 30 Nov 2005 08:22:47 +0100
Subject: fc5 goals
In-Reply-To: <13907.1133333675@sss.pgh.pa.us>
References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr>	<1133217858.11240.8.camel@rousalka.dyndns.org>	<438BBB6E.9070505@develer.com>
	<dmhehp$oqu$1@sea.gmane.org>	<1133288168.17843.23.camel@rousalka.dyndns.org>	<1133293035.753.35.camel@locolhost.localdomain>	<1133295288.4061.10.camel@rousalka.dyndns.org>	<438D2E30.5020003@develer.com>
	<13160.1133327357@sss.pgh.pa.us>	<438D46AC.4030708@develer.com>	<604aa7910511292244v3acc7152i81b96c7343900de6@mail.gmail.com>
	<13907.1133333675@sss.pgh.pa.us>
Message-ID: <438D5347.10002@develer.com>

Tom Lane wrote:

>> simple answer... they don't.
> 
> Aye.  I've seen plenty of irreproducible failures reported by Gentoo
> users.  I don't mind working on a flaky database ... or compiler ...
> or operating system ... but please not all at once.

Hehe.  Those hardcore Gentooists frequently push their CFLAGS to
far and trigger obscure GCC bugs or break assumptions in complex
applications.  I'd say their hated (or laughable) bug reports
make a good service to all us because they help shaking latent
bugs in mainstream distributions too.

Actually, I've been in similar situations with Fedora (and
before that with RedHat) because I've always had the bad
habit of playing too much with betas just for the sake of
seeing what's coming up.

For some time, I even used to run CVS KDE on CVS Xorg built
with a CVS GCC on a reiser4 partition with a git kernel.
I were very surprised the days I could still open a
Konqueror window ;-)

When things go wrong with a distro such as Fedora, you can
always use the B-plan of removing your local installations
and get back to work, so it's nothing to be scared about.
Only, very time consuming as a hobby.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/



From fedora at camperquake.de  Wed Nov 30 08:44:38 2005
From: fedora at camperquake.de (Ralf Ertzinger)
Date: Wed, 30 Nov 2005 09:44:38 +0100
Subject: rawhide report: 20051129 changes
In-Reply-To: <438C9A7C.1070404@cornell.edu>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>
	<dmhtuj$k1j$1@sea.gmane.org> <438C81CD.7080304@insitesinc.com>
	<438C9A7C.1070404@cornell.edu>
Message-ID: <20051130084438.GB29911@ryoko.camperquake.de>

On Tue, Nov 29, 2005 at 01:14:20PM -0500, Ivan Gyurdiev wrote:

> This problem should only occur if you're upgrading a machine currently 
> running with mls disabled to an mls-enabled policy.

For what it is worth, I have seen this on a machine running with selinux
completely disabled.



From mls at suse.de  Wed Nov 30 09:01:47 2005
From: mls at suse.de (Michael Schroeder)
Date: Wed, 30 Nov 2005 10:01:47 +0100
Subject: Modern Update System
In-Reply-To: <d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
References: <1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<d82d6db50511282019h36b73ebfqfac3a769f3abc798@mail.gmail.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
Message-ID: <20051130090146.GA13266@suse.de>

On Tue, Nov 29, 2005 at 04:07:19PM -0500, Benjy Grogan wrote:
> What would be the size of said deltarpms for Openoffice?

That depends on the changes in the Openoffice package.
Lets see...

Update from 1.9.125 to 2.0.0: 10 Mbyte.
Update from 1.99.3  to 2.0.0:  4 Mbyte.

On avarage deltas are about 5%-10% of the rpm size.

> Are there any drawbacks to the deltarpms?

Well, the deltas are between two version. So if you want them to
work with a distribution that changes a lot like fedora (i.e.
if you don't do just maintenance updates) you have two possibilities:

- delete all of th old deltas and create deltas between the old
  versions and the current one. The drawback is that you have to keep
  the old rpms around for delta generation (they don't need to be in
  the repo, though) and the mirrors have to fetch all the new
  deltas.
- create only one delta between the last version and the new one.
  This creates a chain of deltas, so the mirrors only have to pick
  up one delta. The disadvantage is that you have to use a special
  server that combines the deltas on the fly or, if you don't want
  that, clients that have an old version must fetch more than one
  delta and combine them.

In any case, keeping deltas against the last 10 versions roughly
doubles the repo size.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From benjy.grogan at gmail.com  Wed Nov 30 09:55:17 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Wed, 30 Nov 2005 04:55:17 -0500
Subject: Modern Update System
In-Reply-To: <20051130090146.GA13266@suse.de>
References: <1133235130.5030.26.camel@dhollis-lnx.sunera.com>
	<438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
Message-ID: <d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>

You said you have to keep around the old rpms and you meant the repos have
to keep around the old rpms?  Does the user (me) have to store the old rpms
on my hard drive to be combined with the delta rpms?

Thanks for all the info btw,
Benjy

On 11/30/05, Michael Schroeder <mls at suse.de> wrote:
>
> On Tue, Nov 29, 2005 at 04:07:19PM -0500, Benjy Grogan wrote:
> > What would be the size of said deltarpms for Openoffice?
>
> That depends on the changes in the Openoffice package.
> Lets see...
>
> Update from 1.9.125 to 2.0.0: 10 Mbyte.
> Update from 1.99.3  to 2.0.0:  4 Mbyte.
>
> On avarage deltas are about 5%-10% of the rpm size.
>
> > Are there any drawbacks to the deltarpms?
>
> Well, the deltas are between two version. So if you want them to
> work with a distribution that changes a lot like fedora (i.e.
> if you don't do just maintenance updates) you have two possibilities:
>
> - delete all of th old deltas and create deltas between the old
>   versions and the current one. The drawback is that you have to keep
>   the old rpms around for delta generation (they don't need to be in
>   the repo, though) and the mirrors have to fetch all the new
>   deltas.
> - create only one delta between the last version and the new one.
>   This creates a chain of deltas, so the mirrors only have to pick
>   up one delta. The disadvantage is that you have to use a special
>   server that combines the deltas on the fly or, if you don't want
>   that, clients that have an old version must fetch more than one
>   delta and combine them.
>
> In any case, keeping deltas against the last 10 versions roughly
> doubles the repo size.
>
> Cheers,
>   Michael.
>
> --
> Michael Schroeder                                   mls at suse.de
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
>
> --
> 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/20051130/10e5b8e8/attachment.htm>

From mls at suse.de  Wed Nov 30 09:58:22 2005
From: mls at suse.de (Michael Schroeder)
Date: Wed, 30 Nov 2005 10:58:22 +0100
Subject: Modern Update System
In-Reply-To: <d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
References: <438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
Message-ID: <20051130095822.GA26582@suse.de>

On Wed, Nov 30, 2005 at 04:55:17AM -0500, Benjy Grogan wrote:
> You said you have to keep around the old rpms and you meant the repos have
> to keep around the old rpms?

No. I said you have to have the old rpms for delta generation (if you
don't use the chain approach).

> Does the user (me) have to store the old rpms
> on my hard drive to be combined with the delta rpms?

No.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From benny+usenet at amorsen.dk  Wed Nov 30 10:18:03 2005
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: 30 Nov 2005 11:18:03 +0100
Subject: status of up2date and rhn-applet
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk>
	<20051129075855.GB13739@neu.nirvana>
	<m31x0zwanz.fsf@ursa.amorsen.dk> <1133290947.7585.15.camel@cutter>
Message-ID: <m3sltev3qc.fsf@ursa.amorsen.dk>

>>>>> "sv" == seth vidal <skvidal at phy.duke.edu> writes:

sv> Well, to be clear ipw2200 is just firmware - the module is in the
sv> kernel package.

The 1.0.0 module is in the kernel package. No WPA, and horribly buggy.
ATrpms has 1.0.8.


/Benny




From n0dalus+redhat at gmail.com  Wed Nov 30 13:48:23 2005
From: n0dalus+redhat at gmail.com (n0dalus)
Date: Thu, 1 Dec 2005 00:18:23 +1030
Subject: Strange Gnome menu problem
Message-ID: <6280325c0511300548i64700942mb6da5535c71eba81@mail.gmail.com>

Hi,

I wouldn't usually email a list over such a trivial issue, but I have
been pulling my hair out trying to work out why one of the programs in
FC5t1 disappeared from the gnome menu after an update.

/usr/share/applications/gdmflexiserver.desktop exists, but for some
reason it's just being ignored. File permissions on it seem fine, and
there doesn't appear to be anything wrong with the contents.

Copying or moving the file to
/usr/share/applications/gdmflexiserver2.desktop makes it appear in the
menu instantly. Putting it back makes it disappear again. Is there a
config file somewhere with a list of filenames to ignore or something?

Running `strace alacarte` shows that the .desktop file is being opened
and read, but even the menu editor ignores its presence.

I'm sure there's a simple solution. Any ideas would be helpful.

Thanks,
n0dalus.



From dhollis at davehollis.com  Wed Nov 30 14:27:31 2005
From: dhollis at davehollis.com (David Hollis)
Date: Wed, 30 Nov 2005 09:27:31 -0500
Subject: Modern Update System
In-Reply-To: <20051130095822.GA26582@suse.de>
References: <438BDBBE.7080005@didntduck.org>
	<d82d6db50511282043j11cfd825p9aaa87e55022e2e3@mail.gmail.com>
	<604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
	<20051130095822.GA26582@suse.de>
Message-ID: <1133360851.4956.2.camel@dhollis-lnx.sunera.com>

On Wed, 2005-11-30 at 10:58 +0100, Michael Schroeder wrote:
> On Wed, Nov 30, 2005 at 04:55:17AM -0500, Benjy Grogan wrote:
> > You said you have to keep around the old rpms and you meant the repos have
> > to keep around the old rpms?
> 
> No. I said you have to have the old rpms for delta generation (if you
> don't use the chain approach).
> 
> > Does the user (me) have to store the old rpms
> > on my hard drive to be combined with the delta rpms?

It really seems that throughout this thread, OO seems to be one of the
big reasons for even bothering with all of these patch-rpm arrangements.
What if OO could somehow be modularized in a manner similar to X?  I
don't know how much of OO is compiled code vs data files and it may turn
out that even that doesn't provide that much of a win.  It just really
seems that trying to get all of these deltas and such will wind up
providing considerably less gain in the end than all of the effort to
make it happen.  And there would quite possibly be the nasty side effect
of things getting terribly inconsistent and turning straight into a
Windows administration-type nightmare.

-- 
David Hollis <dhollis at davehollis.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20051130/06ae0332/attachment.sig>

From mls at suse.de  Wed Nov 30 14:36:42 2005
From: mls at suse.de (Michael Schroeder)
Date: Wed, 30 Nov 2005 15:36:42 +0100
Subject: Modern Update System
In-Reply-To: <1133360851.4956.2.camel@dhollis-lnx.sunera.com>
References: <604aa7910511282120j1549e6d5jecefebcca7555710@mail.gmail.com>
	<d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
	<20051130095822.GA26582@suse.de>
	<1133360851.4956.2.camel@dhollis-lnx.sunera.com>
Message-ID: <20051130143642.GA7077@suse.de>

On Wed, Nov 30, 2005 at 09:27:31AM -0500, David Hollis wrote:
> It really seems that throughout this thread, OO seems to be one of the
> big reasons for even bothering with all of these patch-rpm arrangements.

No, it's also the kernel and all other big rpms.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From sds at tycho.nsa.gov  Wed Nov 30 15:29:55 2005
From: sds at tycho.nsa.gov (Stephen Smalley)
Date: Wed, 30 Nov 2005 10:29:55 -0500
Subject: custom selinux policy
In-Reply-To: <438C82A9.3060804@redhat.com>
References: <1133215231.19778.28.camel@www.lutty.net>
	<438C82A9.3060804@redhat.com>
Message-ID: <1133364595.26593.320.camel@moss-spartans.epoch.ncsc.mil>

On Tue, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote:
> The hardest part of converting your local.te into a loadable module will 
> be writing the require section.
> You need to define all types, class and roles in this section in order 
> to get the loadable module.

How hard would it be to add an option to audit2allow (or create a
variant script) that takes a .te file as input and generates the
requires statements for it?  You are already doing that from audit
messages, so it shouldn't be difficult to do likewise from an existing
set of allow rules.  Then people could run that to convert over their
existing local.te files into module form, and then use audit2allow -m
for subsequent additions.

That would also be nice for converting over the test policy.

-- 
Stephen Smalley
National Security Agency



From dwalsh at redhat.com  Wed Nov 30 15:43:02 2005
From: dwalsh at redhat.com (Daniel J Walsh)
Date: Wed, 30 Nov 2005 10:43:02 -0500
Subject: custom selinux policy
In-Reply-To: <1133364595.26593.320.camel@moss-spartans.epoch.ncsc.mil>
References: <1133215231.19778.28.camel@www.lutty.net>	
	<438C82A9.3060804@redhat.com>
	<1133364595.26593.320.camel@moss-spartans.epoch.ncsc.mil>
Message-ID: <438DC886.7070309@redhat.com>

Stephen Smalley wrote:
> On Tue, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote:
>   
>> The hardest part of converting your local.te into a loadable module will 
>> be writing the require section.
>> You need to define all types, class and roles in this section in order 
>> to get the loadable module.
>>     
>
> How hard would it be to add an option to audit2allow (or create a
> variant script) that takes a .te file as input and generates the
> requires statements for it?  You are already doing that from audit
> messages, so it shouldn't be difficult to do likewise from an existing
> set of allow rules.  Then people could run that to convert over their
> existing local.te files into module form, and then use audit2allow -m
> for subsequent additions.
>
> That would also be nice for converting over the test policy.
>
>   
Yes I was considering adding a new flag to take an input from a te file.

So we could parse a te file and/or an audit message and combine the 
output into a new te file using reference policy format.

-- 




From che666 at gmail.com  Wed Nov 30 15:44:09 2005
From: che666 at gmail.com (Rudolf Kastl)
Date: Wed, 30 Nov 2005 16:44:09 +0100
Subject: status of up2date and rhn-applet
In-Reply-To: <m3sltev3qc.fsf@ursa.amorsen.dk>
References: <1132852511.3748.7.camel@yoda.loki.me>
	<50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr>
	<1132983547.2860.32.camel@bree.local.net>
	<1133023655l.3593l.6l@serve.riede.org>
	<m364qdw0v7.fsf@ursa.amorsen.dk> <20051129075855.GB13739@neu.nirvana>
	<m31x0zwanz.fsf@ursa.amorsen.dk> <1133290947.7585.15.camel@cutter>
	<m3sltev3qc.fsf@ursa.amorsen.dk>
Message-ID: <e99d27470511300744p1db7df10x@mail.gmail.com>

30 Nov 2005 11:18:03 +0100, Benny Amorsen <benny+usenet at amorsen.dk>:
> >>>>> "sv" == seth vidal <skvidal at phy.duke.edu> writes:
>
> sv> Well, to be clear ipw2200 is just firmware - the module is in the
> sv> kernel package.
>
> The 1.0.0 module is in the kernel package. No WPA, and horribly buggy.
> ATrpms has 1.0.8.

i agree... upgrading the ipw2200 module would make it alot more useable.
actually yet i just rolled my own cause for my laptop the currently
shipped version is unacceptable.

regards,
Rudolf Kastl


>
>
> /Benny
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>



From emmanuel.seyman at club-internet.fr  Wed Nov 30 16:09:31 2005
From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman)
Date: Wed, 30 Nov 2005 17:09:31 +0100
Subject: Modern Update System
In-Reply-To: <20051130143642.GA7077@suse.de>
References: <d82d6db50511282132p312fde24wdd07d0d92cf43682@mail.gmail.com>
	<1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
	<20051130095822.GA26582@suse.de>
	<1133360851.4956.2.camel@dhollis-lnx.sunera.com>
	<20051130143642.GA7077@suse.de>
Message-ID: <20051130160931.GA5788@orient.maison.moi>

On Wed, Nov 30, 2005 at 03:36:42PM +0100, Michael Schroeder wrote:
> 
> No, it's also the kernel and all other big rpms.

What defines "big"?

Running a 'du -am ?/Fedora/RPMS/*.rpm | sort -n' on the FC4 isos, the kernel
finishes at #35 (the i586 version) and #34 (i686).

Looking at all the rpms bigger than the kernel, a whole lot of them are
language packs (KDE, openoffice, aspell) and fonts (asian and tetex). Is this
patch.rpm mechanism going to work on these files?

Eclipse and OOo (system rpms, not the language packs) make up the
rest of the chart.

Emmanuel



From mls at suse.de  Wed Nov 30 16:29:23 2005
From: mls at suse.de (Michael Schroeder)
Date: Wed, 30 Nov 2005 17:29:23 +0100
Subject: Modern Update System
In-Reply-To: <20051130160931.GA5788@orient.maison.moi>
References: <1133243339.2833.44.camel@yoda.loki.me>
	<d82d6db50511282251h3ca5648ewc3ed8b7dead17ba9@mail.gmail.com>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
	<20051130095822.GA26582@suse.de>
	<1133360851.4956.2.camel@dhollis-lnx.sunera.com>
	<20051130143642.GA7077@suse.de>
	<20051130160931.GA5788@orient.maison.moi>
Message-ID: <20051130162923.GB6945@suse.de>

On Wed, Nov 30, 2005 at 05:09:31PM +0100, Emmanuel Seyman wrote:
> Looking at all the rpms bigger than the kernel, a whole lot of them are
> language packs (KDE, openoffice, aspell) and fonts (asian and tetex). Is this
> patch.rpm mechanism going to work on these files?

Sure. Why shouldn't it work? But please don't confuse patch rpms
and delta rpms.

patch rpms are rpms which contain only changed files. They contain
complete files, no binary delta mechanism is used. patch rpms can
be applied to multiple versions.
delta rpms use a binary delta algorithm and can thus be only applied
to a single version of a rpm.

Cheers,
  Michael.

-- 
Michael Schroeder                                   mls at suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}



From gilboada at netvision.net.il  Wed Nov 30 16:31:38 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Wed, 30 Nov 2005 18:31:38 +0200
Subject: Building FireFox 1.5 SRPMs on FC4...
Message-ID: <1133368298.3357.63.camel@gilboa-home-dev.localhost>

Hello all,

Just wondering, I assume that FF 1.5 RPMs will be making their way into
rawhide in the next couple of days.
What are the chances of building their SRPMs on FC4? (x86-64 to be
exact)
Should I just give up and build the vanilla source package?

Gilboa



From michael.favia at insitesinc.com  Wed Nov 30 17:14:08 2005
From: michael.favia at insitesinc.com (Michael Favia)
Date: Wed, 30 Nov 2005 11:14:08 -0600
Subject: rawhide report: 20051129 changes
In-Reply-To: <20051130084438.GB29911@ryoko.camperquake.de>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>	<dmhtuj$k1j$1@sea.gmane.org>
	<438C81CD.7080304@insitesinc.com>	<438C9A7C.1070404@cornell.edu>
	<20051130084438.GB29911@ryoko.camperquake.de>
Message-ID: <438DDDE0.3090803@insitesinc.com>

Ralf Ertzinger wrote:
> On Tue, Nov 29, 2005 at 01:14:20PM -0500, Ivan Gyurdiev wrote:
> 
>> This problem should only occur if you're upgrading a machine currently 
>> running with mls disabled to an mls-enabled policy.
> 
> For what it is worth, I have seen this on a machine running with selinux
> completely disabled.
> 
+2 :)
-mf



From ivg2 at cornell.edu  Wed Nov 30 17:37:25 2005
From: ivg2 at cornell.edu (Ivan Gyurdiev)
Date: Wed, 30 Nov 2005 12:37:25 -0500
Subject: rawhide report: 20051129 changes
In-Reply-To: <438DDDE0.3090803@insitesinc.com>
References: <200511291140.jATBedgW008145@porkchop.devel.redhat.com>	<dmhtuj$k1j$1@sea.gmane.org>	<438C81CD.7080304@insitesinc.com>	<438C9A7C.1070404@cornell.edu>	<20051130084438.GB29911@ryoko.camperquake.de>
	<438DDDE0.3090803@insitesinc.com>
Message-ID: <438DE355.70601@cornell.edu>

Michael Favia wrote:
> Ralf Ertzinger wrote:
>> On Tue, Nov 29, 2005 at 01:14:20PM -0500, Ivan Gyurdiev wrote:
>>
>>> This problem should only occur if you're upgrading a machine 
>>> currently running with mls disabled to an mls-enabled policy.
>>
>> For what it is worth, I have seen this on a machine running with selinux
>> completely disabled.
Right, that could also cause it...

It will fail whenever you're upgrading to an mls-enabled policy (which 
includes newer versions of
targeted and strict). on a machine that currently has selinux disabled,
or mls disabled. I think it is fixed upstream..



From caillon at redhat.com  Wed Nov 30 17:44:15 2005
From: caillon at redhat.com (Christopher Aillon)
Date: Wed, 30 Nov 2005 12:44:15 -0500
Subject: Building FireFox 1.5 SRPMs on FC4...
In-Reply-To: <1133368298.3357.63.camel@gilboa-home-dev.localhost>
References: <1133368298.3357.63.camel@gilboa-home-dev.localhost>
Message-ID: <438DE4EF.9040109@redhat.com>

On 11/30/2005 11:31 AM, Gilboa Davara wrote:
> Hello all,
>
> Just wondering, I assume that FF 1.5 RPMs will be making their way into
> rawhide in the next couple of days.
> What are the chances of building their SRPMs on FC4? (x86-64 to be
> exact)
> Should I just give up and build the vanilla source package?
>   
Once the s390(x) builds finish, it should hit rawhide.  I'd imagine you 
should be able to build it on FC4 without issue, but why not try and 
find out for sure?  :-)



From pbrobinson at gmail.com  Wed Nov 30 17:50:14 2005
From: pbrobinson at gmail.com (Peter Robinson)
Date: Wed, 30 Nov 2005 17:50:14 +0000
Subject: Building FireFox 1.5 SRPMs on FC4...
In-Reply-To: <438DE4EF.9040109@redhat.com>
References: <1133368298.3357.63.camel@gilboa-home-dev.localhost>
	<438DE4EF.9040109@redhat.com>
Message-ID: <5256d0b0511300950i27e13774h846da1c8513f9bb0@mail.gmail.com>

On 11/30/05, Christopher Aillon <caillon at redhat.com> wrote:
> On 11/30/2005 11:31 AM, Gilboa Davara wrote:
> > Hello all,
> >
> > Just wondering, I assume that FF 1.5 RPMs will be making their way into
> > rawhide in the next couple of days.
> > What are the chances of building their SRPMs on FC4? (x86-64 to be
> > exact)
> > Should I just give up and build the vanilla source package?
> >
> Once the s390(x) builds finish, it should hit rawhide.  I'd imagine you
> should be able to build it on FC4 without issue, but why not try and
> find out for sure?  :-)
>

Almost but not quite. Off the top of my head once you've installed the
spec file you need to:

In the spec file you need to change the nspr/nspr-devel to
mozilla-nspr[-devel] with version of 1.7.10 (it will inc greater vers)
and remove the cairo dep.

Then in the firefox-mozconfig remove the lines with system cairo and
pango. You need to remove the pango because it deps on cairo.

Once you've done that you should be able to do a rpmbuild -ba
firefox.spec and then just wait. I've been doing this ever since the
alphas started to appear in rawhide.

Pete



From gilboada at netvision.net.il  Wed Nov 30 18:29:26 2005
From: gilboada at netvision.net.il (Gilboa Davara)
Date: Wed, 30 Nov 2005 20:29:26 +0200
Subject: Building FireFox 1.5 SRPMs on FC4...
In-Reply-To: <5256d0b0511300950i27e13774h846da1c8513f9bb0@mail.gmail.com>
References: <1133368298.3357.63.camel@gilboa-home-dev.localhost>
	<438DE4EF.9040109@redhat.com>
	<5256d0b0511300950i27e13774h846da1c8513f9bb0@mail.gmail.com>
Message-ID: <1133375366.3357.65.camel@gilboa-home-dev.localhost>

On Wed, 2005-11-30 at 17:50 +0000, Peter Robinson wrote:
> On 11/30/05, Christopher Aillon <caillon at redhat.com> wrote:
> > On 11/30/2005 11:31 AM, Gilboa Davara wrote:
> > > Hello all,
> > >
> > > Just wondering, I assume that FF 1.5 RPMs will be making their way into
> > > rawhide in the next couple of days.
> > > What are the chances of building their SRPMs on FC4? (x86-64 to be
> > > exact)
> > > Should I just give up and build the vanilla source package?
> > >
> > Once the s390(x) builds finish, it should hit rawhide.  I'd imagine you
> > should be able to build it on FC4 without issue, but why not try and
> > find out for sure?  :-)
> >
> 
> Almost but not quite. Off the top of my head once you've installed the
> spec file you need to:
> 
> In the spec file you need to change the nspr/nspr-devel to
> mozilla-nspr[-devel] with version of 1.7.10 (it will inc greater vers)
> and remove the cairo dep.
> 
> Then in the firefox-mozconfig remove the lines with system cairo and
> pango. You need to remove the pango because it deps on cairo.
> 
> Once you've done that you should be able to do a rpmbuild -ba
> firefox.spec and then just wait. I've been doing this ever since the
> alphas started to appear in rawhide.
> 
> Pete
> 

Thanks.
I'll give it a try once the rawhide SRPMs hit the servers.

Gilboa



From mattdm at mattdm.org  Wed Nov 30 18:35:20 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 13:35:20 -0500
Subject: Building FireFox 1.5 SRPMs on FC4...
In-Reply-To: <438DE4EF.9040109@redhat.com>
References: <1133368298.3357.63.camel@gilboa-home-dev.localhost>
	<438DE4EF.9040109@redhat.com>
Message-ID: <20051130183520.GA3176@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 12:44:15PM -0500, Christopher Aillon wrote:
> >Just wondering, I assume that FF 1.5 RPMs will be making their way into
> >rawhide in the next couple of days. What are the chances of building
> >their SRPMs on FC4? (x86-64 to be exact) Should I just give up and build
> >the vanilla source package?
> Once the s390(x) builds finish, it should hit rawhide.  I'd imagine you 
> should be able to build it on FC4 without issue, but why not try and 
> find out for sure?  :-)

Any plans to try to make an update for FC3? (Building the rawhide one is a
pain because of cairo and pango and etc.)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From dragoran at feuerpokemon.de  Wed Nov 30 18:49:52 2005
From: dragoran at feuerpokemon.de (dragoran)
Date: Wed, 30 Nov 2005 19:49:52 +0100
Subject: Building FireFox 1.5 SRPMs on FC4...
In-Reply-To: <20051130183520.GA3176@jadzia.bu.edu>
References: <1133368298.3357.63.camel@gilboa-home-dev.localhost>	<438DE4EF.9040109@redhat.com>
	<20051130183520.GA3176@jadzia.bu.edu>
Message-ID: <438DF450.8070803@feuerpokemon.de>

Matthew Miller schrieb:

>On Wed, Nov 30, 2005 at 12:44:15PM -0500, Christopher Aillon wrote:
>  
>
>>>Just wondering, I assume that FF 1.5 RPMs will be making their way into
>>>rawhide in the next couple of days. What are the chances of building
>>>their SRPMs on FC4? (x86-64 to be exact) Should I just give up and build
>>>the vanilla source package?
>>>      
>>>
>>Once the s390(x) builds finish, it should hit rawhide.  I'd imagine you 
>>should be able to build it on FC4 without issue, but why not try and 
>>find out for sure?  :-)
>>    
>>
>
>Any plans to try to make an update for FC3? (Building the rawhide one is a
>pain because of cairo and pango and etc.)
>
>  
>
same for fc4 see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174523



From mattdm at mattdm.org  Wed Nov 30 20:26:05 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:26:05 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based
	upgrades?
Message-ID: <20051130202605.GA7078@jadzia.bu.edu>

So, I noticed while doing my first FC5t1 install the upgrades aren't
currently supported in the reworked anaconda. Fair enough; there's a lot of
changes under the hood. But that got me thinking: hey, maybe this is a great
time to get it so that "yum upgrade" can actually easily bring one from one
FC release to the next. (More realistically, maybe FC6 is a great time. But
now might be a time to start thinking about it.)

I know there's historically been a lot of wacky special-casing in Anaconda,
much of it legacy cruft, and much of it kinda important for, y'know,
actually working upgrades.

With switching to a yum-based backend, I imagine that much of this cruft
must be updated. Maybe Jeremy's doing it this way already, but what about
packaging that special-case knowledge into a "distroupgrade" yum plugin
instead of into Anaconda itself, wherever possible? (Some things are easier
done off-line, of course, but maybe those could be made to happen in
firstboot or so?)

As an experiment in support of this hallucinogen-addled fantasy, I installed
a fresh system FC4 system (Workstation install), used yum to apply all
current updates, and then changed the repo config to point at FC5t1. I first
ran yum upgrade yum and then a full "yum -y upgrade".

After some time, this failed, because iiimf-libs is gone, with no
replacement or nothing to obsolete it but with a chain of dependencies.

Quick fix was to just remove that package and try again.

Now, two things -- initscript and kudzu -- failed because of requirements on
kernel < 2.6.12 and 2.6.13, respectively. After some head-scratching, this
turned out to be caused by Conflicts statements and the previously-installed
2.6.11 kernel. (The newly installed-then-yum-upgraded system had the
original FC4 2.6.11 and the newest FC4 2.6.14 both installed, of course.)

Sort ironically, the installonlyn plugin would have actually corrected this
situation, because the result after the upgrade would be to have the FC4
2.6.14 plus the FC5 2.6.14. Anyway, I worked around this by simply removing
the old 2.6.11 kernel.

After that, the yum upgrade went basically fine, and after Some Time passed,
I have what appears to be a fully functional FC5 system. I haven't poked
around too much to find broken spots, and there were a lot of messages about
.rpmsave and .rpmnew, so looking at those is probably in order. But I can
log in to Gnome, browse the web, run OpenOffice, and so on.

But overall, seemed like a pretty successful experiment. And, given the
super-short lifespan of FC releases, something I'd really be interested in
having as an option.

Thoughts, anyone?

  -- smokin' the good stuff,
          Matthew

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From notting at redhat.com  Wed Nov 30 20:28:56 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 30 Nov 2005 15:28:56 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130202605.GA7078@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
Message-ID: <20051130202856.GA7234@devserv.devel.redhat.com>

Matthew Miller (mattdm at mattdm.org) said: 
> Thoughts, anyone?

I suspect the 'interesting' parts are when your yum 'distroupgrade'
plugin starts doing things that are totally unrelated to package
management.

Bill



From skvidal at phy.duke.edu  Wed Nov 30 20:32:03 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 15:32:03 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130202856.GA7234@devserv.devel.redhat.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
Message-ID: <1133382724.7253.16.camel@cutter>

On Wed, 2005-11-30 at 15:28 -0500, Bill Nottingham wrote:
> Matthew Miller (mattdm at mattdm.org) said: 
> > Thoughts, anyone?
> 
> I suspect the 'interesting' parts are when your yum 'distroupgrade'
> plugin starts doing things that are totally unrelated to package
> management.

+1

The problem isn't packages, not really, it's all the crazy stuff about
relabeling lvm partitions or  migrating major portions of
infrastructure.

-sv




From mattdm at mattdm.org  Wed Nov 30 20:32:05 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:32:05 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130202856.GA7234@devserv.devel.redhat.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
Message-ID: <20051130203205.GA8611@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:28:56PM -0500, Bill Nottingham wrote:
> Matthew Miller (mattdm at mattdm.org) said: 
> > Thoughts, anyone?
> I suspect the 'interesting' parts are when your yum 'distroupgrade'
> plugin starts doing things that are totally unrelated to package
> management.

I dunno -- "package management" can be a pretty big umbrella. You mean,
like, converting LVM, that sort of thing?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From notting at redhat.com  Wed Nov 30 20:33:09 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 30 Nov 2005 15:33:09 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203205.GA8611@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
Message-ID: <20051130203309.GB7234@devserv.devel.redhat.com>

Matthew Miller (mattdm at mattdm.org) said: 
> On Wed, Nov 30, 2005 at 03:28:56PM -0500, Bill Nottingham wrote:
> > Matthew Miller (mattdm at mattdm.org) said: 
> > > Thoughts, anyone?
> > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > plugin starts doing things that are totally unrelated to package
> > management.
> 
> I dunno -- "package management" can be a pretty big umbrella. You mean,
> like, converting LVM, that sort of thing?

Converting LVM, removing references to /dev/psaux from various files, etc.

Bill



From mattdm at mattdm.org  Wed Nov 30 20:35:01 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:35:01 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133382724.7253.16.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
Message-ID: <20051130203501.GB8611@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:32:03PM -0500, seth vidal wrote:
> > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > plugin starts doing things that are totally unrelated to package
> > management.
> +1
> The problem isn't packages, not really, it's all the crazy stuff about
> relabeling lvm partitions or  migrating major portions of
> infrastructure.

Right, that's why I'm not at all suggesting "normal" yum ought to take care
of it. Crack-riddled hacks are why we have yum plugins, right? :)


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Wed Nov 30 20:36:23 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:36:23 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203309.GB7234@devserv.devel.redhat.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
Message-ID: <20051130203623.GC8611@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > plugin starts doing things that are totally unrelated to package
> > > management.
> > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > like, converting LVM, that sort of thing?
> Converting LVM, removing references to /dev/psaux from various files, etc.

So, yeah, "interesting" in the famous chinese curse sense. But given that
that stuff has to happen somewhere, any particular reason why not here?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From skvidal at phy.duke.edu  Wed Nov 30 20:38:03 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 15:38:03 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203501.GB8611@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter> <20051130203501.GB8611@jadzia.bu.edu>
Message-ID: <1133383083.7253.18.camel@cutter>

On Wed, 2005-11-30 at 15:35 -0500, Matthew Miller wrote:
> On Wed, Nov 30, 2005 at 03:32:03PM -0500, seth vidal wrote:
> > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > plugin starts doing things that are totally unrelated to package
> > > management.
> > +1
> > The problem isn't packages, not really, it's all the crazy stuff about
> > relabeling lvm partitions or  migrating major portions of
> > infrastructure.
> 
> Right, that's why I'm not at all suggesting "normal" yum ought to take care
> of it. Crack-riddled hacks are why we have yum plugins, right? :)
> 

you _really_ don't want to do a lot of those things on a running system.

REALLY

-sv




From skvidal at phy.duke.edu  Wed Nov 30 20:38:34 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 15:38:34 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203623.GC8611@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
Message-ID: <1133383114.7253.20.camel@cutter>

On Wed, 2005-11-30 at 15:36 -0500, Matthew Miller wrote:
> On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > plugin starts doing things that are totally unrelated to package
> > > > management.
> > > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > > like, converting LVM, that sort of thing?
> > Converting LVM, removing references to /dev/psaux from various files, etc.
> 
> So, yeah, "interesting" in the famous chinese curse sense. But given that
> that stuff has to happen somewhere, any particular reason why not here?
> 

it's a live system.

much greater risk of losing data and destroying a running process.

-sv




From jspaleta at gmail.com  Wed Nov 30 20:38:40 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 30 Nov 2005 15:38:40 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203501.GB8611@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<20051130203501.GB8611@jadzia.bu.edu>
Message-ID: <604aa7910511301238m42637d29g87d0839295f6ad35@mail.gmail.com>

On 11/30/05, Matthew Miller <mattdm at mattdm.org> wrote:
> Right, that's why I'm not at all suggesting "normal" yum ought to take care
> of it. Crack-riddled hacks are why we have yum plugins, right? :)

How much of that crackrock can you safely do from within an active environment?
And how much of it can only be done from a seperate (ramdisk) environment?
I doubt everything that needs to be done can be dome from inside the
actual mounted environment.

-jef



From mattdm at mattdm.org  Wed Nov 30 20:41:20 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:41:20 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383083.7253.18.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<20051130203501.GB8611@jadzia.bu.edu>
	<1133383083.7253.18.camel@cutter>
Message-ID: <20051130204120.GA9106@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:38:03PM -0500, seth vidal wrote:
> > Right, that's why I'm not at all suggesting "normal" yum ought to take
> > care of it. Crack-riddled hacks are why we have yum plugins, right? :)
> you _really_ don't want to do a lot of those things on a running system.
> REALLY

Yeah; some things would have to be pushed to being done on a reboot. Fair
enough, for a whole-system upgrade.

But how many such cases are there really?

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From notting at redhat.com  Wed Nov 30 20:42:40 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 30 Nov 2005 15:42:40 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383114.7253.20.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
	<1133383114.7253.20.camel@cutter>
Message-ID: <20051130204240.GC7234@devserv.devel.redhat.com>

seth vidal (skvidal at phy.duke.edu) said: 
> > So, yeah, "interesting" in the famous chinese curse sense. But given that
> > that stuff has to happen somewhere, any particular reason why not here?
> 
> it's a live system.
> 
> much greater risk of losing data and destroying a running process.

In fact, that's one of the things that makes an anaconda upgrade easier -
it's always running a kernel vintage similar to what you're going to
end up with on upgrade.

Bill



From nicolas.mailhot at laposte.net  Wed Nov 30 20:44:31 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 21:44:31 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133382724.7253.16.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
Message-ID: <1133383474.10697.24.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:32 -0500, seth vidal a ?crit :
> On Wed, 2005-11-30 at 15:28 -0500, Bill Nottingham wrote:
> > Matthew Miller (mattdm at mattdm.org) said: 
> > > Thoughts, anyone?
> > 
> > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > plugin starts doing things that are totally unrelated to package
> > management.
> 
> +1
> 
> The problem isn't packages, not really, it's all the crazy stuff about
> relabeling lvm partitions or  migrating major portions of
> infrastructure.

Couldn't these bits be moved to a firstboot-like package ?

-- 
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/20051130/45b69d1d/attachment.sig>

From skvidal at phy.duke.edu  Wed Nov 30 20:49:16 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 15:49:16 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383474.10697.24.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<1133383474.10697.24.camel@rousalka.dyndns.org>
Message-ID: <1133383757.7253.29.camel@cutter>

On Wed, 2005-11-30 at 21:44 +0100, Nicolas Mailhot wrote:
> Le mercredi 30 novembre 2005 ? 15:32 -0500, seth vidal a ?crit :
> > On Wed, 2005-11-30 at 15:28 -0500, Bill Nottingham wrote:
> > > Matthew Miller (mattdm at mattdm.org) said: 
> > > > Thoughts, anyone?
> > > 
> > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > plugin starts doing things that are totally unrelated to package
> > > management.
> > 
> > +1
> > 
> > The problem isn't packages, not really, it's all the crazy stuff about
> > relabeling lvm partitions or  migrating major portions of
> > infrastructure.
> 
> Couldn't these bits be moved to a firstboot-like package ?
> 

it's still a live system. Doing that on a live system is scary.

-sv




From nicolas.mailhot at laposte.net  Wed Nov 30 20:47:32 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 21:47:32 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <604aa7910511301238m42637d29g87d0839295f6ad35@mail.gmail.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter> <20051130203501.GB8611@jadzia.bu.edu>
	<604aa7910511301238m42637d29g87d0839295f6ad35@mail.gmail.com>
Message-ID: <1133383655.10697.27.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:38 -0500, Jeff Spaleta a ?crit :
> On 11/30/05, Matthew Miller <mattdm at mattdm.org> wrote:
> > Right, that's why I'm not at all suggesting "normal" yum ought to take care
> > of it. Crack-riddled hacks are why we have yum plugins, right? :)
> 
> How much of that crackrock can you safely do from within an active environment?
> And how much of it can only be done from a seperate (ramdisk) environment?
> I doubt everything that needs to be done can be dome from inside the
> actual mounted environment.

However some of this stuff (managing / lvm...) needs to be done at other
points than distro upgrades, and trying to coax the install cd into a
maintenance CD is a world of pain.

Why should one need to start an installation process to have access to a
decent gfx partitioning utility ?

-- 
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/20051130/8fc42553/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 30 20:48:20 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 21:48:20 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130203623.GC8611@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
Message-ID: <1133383703.10697.29.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:36 -0500, Matthew Miller a ?crit :
> On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > plugin starts doing things that are totally unrelated to package
> > > > management.
> > > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > > like, converting LVM, that sort of thing?
> > Converting LVM, removing references to /dev/psaux from various files, etc.
> 
> So, yeah, "interesting" in the famous chinese curse sense. But given that
> that stuff has to happen somewhere, any particular reason why not here?

Because it's not specific to installation

-- 
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/20051130/e6cda19f/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 30 20:49:12 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 21:49:12 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383114.7253.20.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
Message-ID: <1133383754.10697.31.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:38 -0500, seth vidal a ?crit :
> On Wed, 2005-11-30 at 15:36 -0500, Matthew Miller wrote:
> > On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > > plugin starts doing things that are totally unrelated to package
> > > > > management.
> > > > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > > > like, converting LVM, that sort of thing?
> > > Converting LVM, removing references to /dev/psaux from various files, etc.
> > 
> > So, yeah, "interesting" in the famous chinese curse sense. But given that
> > that stuff has to happen somewhere, any particular reason why not here?
> > 
> 
> it's a live system.
> 
> much greater risk of losing data and destroying a running process.

So what ?
Make a firstboot package which runs at init 1

-- 
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/20051130/e8d7d4d3/attachment.sig>

From skvidal at phy.duke.edu  Wed Nov 30 20:53:06 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Nov 2005 15:53:06 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383754.10697.31.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
Message-ID: <1133383986.7253.31.camel@cutter>

On Wed, 2005-11-30 at 21:49 +0100, Nicolas Mailhot wrote:
> Le mercredi 30 novembre 2005 ? 15:38 -0500, seth vidal a ?crit :
> > On Wed, 2005-11-30 at 15:36 -0500, Matthew Miller wrote:
> > > On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > > > plugin starts doing things that are totally unrelated to package
> > > > > > management.
> > > > > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > > > > like, converting LVM, that sort of thing?
> > > > Converting LVM, removing references to /dev/psaux from various files, etc.
> > > 
> > > So, yeah, "interesting" in the famous chinese curse sense. But given that
> > > that stuff has to happen somewhere, any particular reason why not here?
> > > 
> > 
> > it's a live system.
> > 
> > much greater risk of losing data and destroying a running process.
> 
> So what ?
> Make a firstboot package which runs at init 1

I believe we have that

it's called anaconda

:)

-sv




From mattdm at mattdm.org  Wed Nov 30 20:53:36 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 15:53:36 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383114.7253.20.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
	<1133383114.7253.20.camel@cutter>
Message-ID: <20051130205336.GB9106@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:38:34PM -0500, seth vidal wrote:
> > So, yeah, "interesting" in the famous chinese curse sense. But given that
> > that stuff has to happen somewhere, any particular reason why not here?
> it's a live system.
> much greater risk of losing data and destroying a running process.

Excepting the specific special cases like LVM migration (which, y'know,
we're past already), is it significantly more risky than when yum does any
package updates? 

I'm working on a fresh install of FC3 on another test system, and when
that's done, there's something like a gigabyte of updates in
core/updates/3/i386 to apply via yum -- not much better than my FC4->FC5
update.

Presumably, there's bigger version jumps in various RPMs, but if there's
packaging problems, those'll show up online or off.

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From jspaleta at gmail.com  Wed Nov 30 20:54:19 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 30 Nov 2005 15:54:19 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383655.10697.27.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<20051130203501.GB8611@jadzia.bu.edu>
	<604aa7910511301238m42637d29g87d0839295f6ad35@mail.gmail.com>
	<1133383655.10697.27.camel@rousalka.dyndns.org>
Message-ID: <604aa7910511301254uc1e7a86ma0117b9234295cb2@mail.gmail.com>

On 11/30/05, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> Why should one need to start an installation process to have access to a
> decent gfx partitioning utility ?

was this a discussion about generally useful partitioning utilities to
help you manage unmounted lvm groups? No... I'm pretty sure it wasn't.
Let me go check the top post.
Yep, this discussion is definitely not about a generally useful
partitioning utility to do general paritioning maintenance. It is in
fact a discussion about how to automate upgrades.  Feel free to start
a new thread about the lack of generally useful partitioning
untilities, I promise to ignore it and not talk about my desire for a
pony in that thread.

-jef"i really promise"spaleta



From jk at lutty.net  Wed Nov 30 20:56:48 2005
From: jk at lutty.net (Laurent Jacquot)
Date: Wed, 30 Nov 2005 21:56:48 +0100
Subject: custom selinux policy
In-Reply-To: <438CB722.7070100@redhat.com>
References: <1133215231.19778.28.camel@www.lutty.net>
	<438C82A9.3060804@redhat.com> <1133292469.19778.41.camel@www.lutty.net>
	<438CB722.7070100@redhat.com>
Message-ID: <1133384208.19778.50.camel@www.lutty.net>

On mar, 2005-11-29 at 15:16 -0500, Daniel J Walsh wrote:
> Laurent Jacquot wrote:
> > On mar, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote:
> >   
> >> Laurent Jacquot wrote:
> >>     
> >>> Hello,
> >>> I can no longer build my custom selinux policy with recent upgrades (SE
> >>> policy source replaced with SE policy).
> >>> What is the new way (used to be make reload)?
> >>>
> >>> tx in advance
> >>> 	jk
> >>>
> >>>   
> >>>       
> >> You need to  use loadable modules.  Take a look a the man page for 
> >> audit2allow, for some explanation.  I don't know if we have a good 
> >> description available yet for loadable policy.
> >>
> >> The hardest part of converting your local.te into a loadable module will 
> >> be writing the require section.
> >> You need to define all types, class and roles in this section in order 
> >> to get the loadable module.
> >> ==================================================================================
> >>        module local 1.0;
> >>
> >>        require {
> >>                role system_r;
> >>
> >>                class fifo_file {  getattr ioctl };
> >>
> >>                type cupsd_config_t;
> >>                type unconfined_t;
> >>         };
> >>
> >>        allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl };
> >> ==================================================================================
> >>
> >> -- 
> >>     
> > Thanks a lot for this info.
> > BTW the audit2allow (policycoreutils-1.27.29-1) manpage isn't updated
> > regarding the module stuff. Hopefully, the -M option is verbose
> >
> > Would you mind shed some light on the new file context definition? (used
> > to be local.fc)
> >
> > Laurent
> >
> >
> >
> >   
> manpage looks correct on my machine?
> 
> File context file should be the same.
> 
>  checkmodule -M -m -o /tmp/local.mod /tmp/local.te
> semodule_package -o /tmp/local.pp -m /tmp/local.mod -f /tmp/local.fc

Will try as soon as I find time. Does this semanage thing is to be run
each time a reboot occurs in order to load my custom modules or it
recalls it automagically?

manpage is ok now that I deleted /var/cache/man/cat1/audit2allow.1.bz2.
Is it a bug? - first time I see this behavior..

Anyway, thanks a lot to all the giants managing to transition those
udev, selinux, modular xorg, etc.. so smoothly.

Laurent




From jspaleta at gmail.com  Wed Nov 30 20:57:14 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 30 Nov 2005 15:57:14 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130205336.GB9106@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
	<1133383114.7253.20.camel@cutter>
	<20051130205336.GB9106@jadzia.bu.edu>
Message-ID: <604aa7910511301257t3d371efdofcdb93459b7a2afa@mail.gmail.com>

On 11/30/05, Matthew Miller <mattdm at mattdm.org> wrote:
> Excepting the specific special cases like LVM migration (which, y'know,
> we're past already), is it significantly more risky than when yum does any
> package updates?

Are you saying that this project should officially state that people
still running rhl or fc1 systems should NOT attempt an upgrade to
fc5+? Is that what you are saying?

-jef



From mattdm at mattdm.org  Wed Nov 30 21:00:28 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 16:00:28 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383757.7253.29.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<1133383474.10697.24.camel@rousalka.dyndns.org>
	<1133383757.7253.29.camel@cutter>
Message-ID: <20051130210028.GC9106@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:49:16PM -0500, seth vidal wrote:
> > Couldn't these bits be moved to a firstboot-like package ?
> it's still a live system. Doing that on a live system is scary.

To me, it's less scary than a botnet of un-upgraded FC1 machines all over
the university. :)


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From nicolas.mailhot at laposte.net  Wed Nov 30 21:03:35 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 22:03:35 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383757.7253.29.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<1133383474.10697.24.camel@rousalka.dyndns.org>
	<1133383757.7253.29.camel@cutter>
Message-ID: <1133384618.10697.44.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:49 -0500, seth vidal a ?crit :
> On Wed, 2005-11-30 at 21:44 +0100, Nicolas Mailhot wrote:
> > Le mercredi 30 novembre 2005 ? 15:32 -0500, seth vidal a ?crit :
> > > On Wed, 2005-11-30 at 15:28 -0500, Bill Nottingham wrote:
> > > > Matthew Miller (mattdm at mattdm.org) said: 
> > > > > Thoughts, anyone?
> > > > 
> > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > plugin starts doing things that are totally unrelated to package
> > > > management.
> > > 
> > > +1
> > > 
> > > The problem isn't packages, not really, it's all the crazy stuff about
> > > relabeling lvm partitions or  migrating major portions of
> > > infrastructure.
> > 
> > Couldn't these bits be moved to a firstboot-like package ?
> > 
> 
> it's still a live system. Doing that on a live system is scary.

Then create package with a grub entry that boots on a ramdisk to perform
stuff.

The problem with anaconda is its wizard-like approach. As many wizards,
as soon as you deviate from the road the developper dreamed up for you,
things starts to fall apart.

Many useful anaconda tools are not available unless you tell the system
you're doing an upgrade.

And even when you're really doing an upgrade, if you have a problem at
any step everything fails.

If your bios supports booting on your drive, you can start anaconda,
except it will try to re-load the drive with the linux driver so you can
end up with a funny situation where you booted from a CD that can't find
itself later

Ditto for X11 support.

However when you're upgrading the upgraded system already knows how
boot, or how to drive the X11 system, so there's absolutely no reason
for the upgrade process to pretend it's a new system, try to guess up
everything from scratch, and force the use of a CD drive (a hardisk may
have been installed initially on a full system, then moved to a
CD/DVD/usb-less system)

-- 
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/20051130/e1274ebf/attachment.sig>

From mattdm at mattdm.org  Wed Nov 30 21:05:37 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 16:05:37 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <604aa7910511301257t3d371efdofcdb93459b7a2afa@mail.gmail.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
	<1133383114.7253.20.camel@cutter>
	<20051130205336.GB9106@jadzia.bu.edu>
	<604aa7910511301257t3d371efdofcdb93459b7a2afa@mail.gmail.com>
Message-ID: <20051130210537.GD9106@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 03:57:14PM -0500, Jeff Spaleta wrote:
> On 11/30/05, Matthew Miller <mattdm at mattdm.org> wrote:
> > Excepting the specific special cases like LVM migration (which, y'know,
> > we're past already), is it significantly more risky than when yum does any
> > package updates?
> Are you saying that this project should officially state that people
> still running rhl or fc1 systems should NOT attempt an upgrade to
> fc5+? Is that what you are saying?

Not necessarily; while the bulk of the special-casing could be done in the
theoretical distroupgrade plugin, there could be certain cases where the
online upgrade plugin would bail and say "sorry, I can't help you; you'll
need the full installer".

Or, maybe there comes a point where drawing a line is reasonable. SGI does
that all the time, and look where that's gotten them.... :) :) :)

-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From mattdm at mattdm.org  Wed Nov 30 21:07:10 2005
From: mattdm at mattdm.org (Matthew Miller)
Date: Wed, 30 Nov 2005 16:07:10 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133384618.10697.44.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter>
	<1133383474.10697.24.camel@rousalka.dyndns.org>
	<1133383757.7253.29.camel@cutter>
	<1133384618.10697.44.camel@rousalka.dyndns.org>
Message-ID: <20051130210710.GE9106@jadzia.bu.edu>

On Wed, Nov 30, 2005 at 10:03:35PM +0100, Nicolas Mailhot wrote:
> > it's still a live system. Doing that on a live system is scary.
> Then create package with a grub entry that boots on a ramdisk to perform
> stuff.

Actually, this can probably be done _now_, with anaconda and kickstart. Or
could, if current anaconda supported upgrades. :)


-- 
Matthew Miller           mattdm at mattdm.org          <http://mattdm.org/>
Boston University Linux      ------>              <http://linux.bu.edu/>



From nicolas.mailhot at laposte.net  Wed Nov 30 21:08:53 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 22:08:53 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <604aa7910511301254uc1e7a86ma0117b9234295cb2@mail.gmail.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<1133382724.7253.16.camel@cutter> <20051130203501.GB8611@jadzia.bu.edu>
	<604aa7910511301238m42637d29g87d0839295f6ad35@mail.gmail.com>
	<1133383655.10697.27.camel@rousalka.dyndns.org>
	<604aa7910511301254uc1e7a86ma0117b9234295cb2@mail.gmail.com>
Message-ID: <1133384935.10697.50.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:54 -0500, Jeff Spaleta a ?crit :
> On 11/30/05, Nicolas Mailhot <nicolas.mailhot at laposte.net> wrote:
> > Why should one need to start an installation process to have access to a
> > decent gfx partitioning utility ?
> 
> was this a discussion about generally useful partitioning utilities to
> help you manage unmounted lvm groups? No... I'm pretty sure it wasn't.
> Let me go check the top post.

This discussion was about doing some stuff within anaconda or not.
Some people argued some functions must be kept inside anaconda because
they can't be done on a live system.
I replied these functions are generally useful outside the
installation/upgrade context, so anaconda is not the right place to put
them either. Live/not live is a requirement but this requirement can be
achieved without anaconda, and it is generally useful not to weld these
functions to the installation process like today.

-- 
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/20051130/21245762/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 30 21:10:39 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 22:10:39 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <604aa7910511301257t3d371efdofcdb93459b7a2afa@mail.gmail.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<20051130205336.GB9106@jadzia.bu.edu>
	<604aa7910511301257t3d371efdofcdb93459b7a2afa@mail.gmail.com>
Message-ID: <1133385042.10697.52.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:57 -0500, Jeff Spaleta a ?crit :
> On 11/30/05, Matthew Miller <mattdm at mattdm.org> wrote:
> > Excepting the specific special cases like LVM migration (which, y'know,
> > we're past already), is it significantly more risky than when yum does any
> > package updates?
> 
> Are you saying that this project should officially state that people
> still running rhl or fc1 systems should NOT attempt an upgrade to
> fc5+? Is that what you are saying?

He's also saying you can't move your root lvm to another drive array
outside the installation process, so your drives better only fail around
release time.

-- 
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/20051130/0df5319b/attachment.sig>

From nicolas.mailhot at laposte.net  Wed Nov 30 21:13:59 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 22:13:59 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133383986.7253.31.camel@cutter>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
Message-ID: <1133385242.10697.56.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 15:53 -0500, seth vidal a ?crit :
> On Wed, 2005-11-30 at 21:49 +0100, Nicolas Mailhot wrote:
> > Le mercredi 30 novembre 2005 ? 15:38 -0500, seth vidal a ?crit :
> > > On Wed, 2005-11-30 at 15:36 -0500, Matthew Miller wrote:
> > > > On Wed, Nov 30, 2005 at 03:33:09PM -0500, Bill Nottingham wrote:
> > > > > > > I suspect the 'interesting' parts are when your yum 'distroupgrade'
> > > > > > > plugin starts doing things that are totally unrelated to package
> > > > > > > management.
> > > > > > I dunno -- "package management" can be a pretty big umbrella. You mean,
> > > > > > like, converting LVM, that sort of thing?
> > > > > Converting LVM, removing references to /dev/psaux from various files, etc.
> > > > 
> > > > So, yeah, "interesting" in the famous chinese curse sense. But given that
> > > > that stuff has to happen somewhere, any particular reason why not here?
> > > > 
> > > 
> > > it's a live system.
> > > 
> > > much greater risk of losing data and destroying a running process.
> > 
> > So what ?
> > Make a firstboot package which runs at init 1
> 
> I believe we have that
> 
> it's called anaconda

Nah
Anaconda requires you to get an installation image somewhere and burn it
to a CD/DVD. A firstboot package would just add an entry to the usual
boot menu, and work even on a CD-less system. Plus a firstboot could be
split into "manage partitions" "manage lvms" ... tools, while anaconda
only knows about update process.

-- 
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/20051130/b2c21e67/attachment.sig>

From notting at redhat.com  Wed Nov 30 21:21:10 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 30 Nov 2005 16:21:10 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133385242.10697.56.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu>
	<1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
	<1133385242.10697.56.camel@rousalka.dyndns.org>
Message-ID: <20051130212110.GA7519@devserv.devel.redhat.com>

Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> Anaconda requires you to get an installation image somewhere and burn it
> to a CD/DVD. A firstboot package would just add an entry to the usual
> boot menu, and work even on a CD-less system. Plus a firstboot could be
> split into "manage partitions" "manage lvms" ... tools, while anaconda
> only knows about update process.

On install, anaconda could copy it's own boot image and stage 2 to /boot,
and allow you to boot that later without a CD. 

Bill, not very serious, but....



From pjones at redhat.com  Wed Nov 30 21:32:37 2005
From: pjones at redhat.com (Peter Jones)
Date: Wed, 30 Nov 2005 16:32:37 -0500
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133385242.10697.56.camel@rousalka.dyndns.org>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
	<1133385242.10697.56.camel@rousalka.dyndns.org>
Message-ID: <1133386357.2936.23.camel@localhost.localdomain>

On Wed, 2005-11-30 at 22:13 +0100, Nicolas Mailhot wrote:

> > it's called anaconda
> 
> Nah
> Anaconda requires you to get an installation image somewhere and burn it
> to a CD/DVD. A firstboot package would just add an entry to the usual
> boot menu, and work even on a CD-less system. Plus a firstboot could be
> split into "manage partitions" "manage lvms" ... tools, while anaconda
> only knows about update process.

That's called a "rescue" image.

So what you're saying is you'd like either anaconda to also be a rescue
image, or the rescue image to also do upgrades.

The former, quite a few people have been doing just fine for years.  The
latter is silly -- if we made the rescue image do upgrades, it'd be
duplicating large chunks of anaconda, and then it'd be painful to use as
an actual rescue image.

Now, certainly it'd be better of some parts of anaconda were separate
tools, but that's a separate discussion.
-- 
  Peter



From nicolas.mailhot at laposte.net  Wed Nov 30 21:47:25 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 22:47:25 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130212110.GA7519@devserv.devel.redhat.com>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
	<1133385242.10697.56.camel@rousalka.dyndns.org>
	<20051130212110.GA7519@devserv.devel.redhat.com>
Message-ID: <1133387248.10697.71.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 16:21 -0500, Bill Nottingham a ?crit :
> Nicolas Mailhot (nicolas.mailhot at laposte.net) said: 
> > Anaconda requires you to get an installation image somewhere and burn it
> > to a CD/DVD. A firstboot package would just add an entry to the usual
> > boot menu, and work even on a CD-less system. Plus a firstboot could be
> > split into "manage partitions" "manage lvms" ... tools, while anaconda
> > only knows about update process.
> 
> On install, anaconda could copy it's own boot image and stage 2 to /boot,
> and allow you to boot that later without a CD. 
> 
> Bill, not very serious, but....

You know, at one point anaconda was the only tool which knew how to do a
full system package upgrade. Then dedicated tools appeared, where
generally useful outside anaconda, and as a result anaconda is rewritten
to use yum as a better package upgrade engine.

I claim :
1. most of the remaining anaconda features can be moved to either
general-purpose tools (like yum) or a release-specific function bundle
(hopefully as small as possible)
2. the parts that require a cold system can be accessed easily from a
bootloader entry which removes the need of burning a CD for upgrades, or
even having a separate boot media than the upgraded system altogether

For new installations the same tools would be linked in a CD wizard
install process like today. But for everything else (upgrade or general
system maintenance) there would be no reason to go through the anaconda
bits useful only for fresh installations.

You'll note windows mastered this a long time ago (windows is the reboot
genius). As long as something can be done on a live system FC is quite
superior. But for all the rest windows will just create a new management
boot mode (and ask the user to reboot), while FC will ask the user to
boot on the install CD, and somehow manage manually to run the required
utilities while avoiding to actually follow the install process to its
end.

-- 
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/20051130/a0e605f4/attachment.sig>

From jkeating at j2solutions.net  Wed Nov 30 21:47:57 2005
From: jkeating at j2solutions.net (Jesse Keating)
Date: Wed, 30 Nov 2005 13:47:57 -0800
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133386357.2936.23.camel@localhost.localdomain>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
	<1133385242.10697.56.camel@rousalka.dyndns.org>
	<1133386357.2936.23.camel@localhost.localdomain>
Message-ID: <1133387278.24512.155.camel@prometheus.gamehouse.com>

On Wed, 2005-11-30 at 16:32 -0500, Peter Jones wrote:
> Now, certainly it'd be better of some parts of anaconda were separate
> tools, but that's a separate discussion.

Heh, how many years have people been asking for a standalone version of
diskdruid, back when it was used?

-- 
Jesse Keating RHCE      (http://geek.j2solutions.net)
Fedora Legacy Team      (http://www.fedoralegacy.org)
GPG Public Key
(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating



From benjy.grogan at gmail.com  Wed Nov 30 21:51:18 2005
From: benjy.grogan at gmail.com (Benjy Grogan)
Date: Wed, 30 Nov 2005 16:51:18 -0500
Subject: Modern Update System
In-Reply-To: <20051130162923.GB6945@suse.de>
References: <1133243339.2833.44.camel@yoda.loki.me>
	<20051129093348.GB5877@suse.de>
	<d82d6db50511291307s6893339n48a5ce4c5b276c94@mail.gmail.com>
	<20051130090146.GA13266@suse.de>
	<d82d6db50511300155u21e561aeu8461d2731d93ff37@mail.gmail.com>
	<20051130095822.GA26582@suse.de>
	<1133360851.4956.2.camel@dhollis-lnx.sunera.com>
	<20051130143642.GA7077@suse.de>
	<20051130160931.GA5788@orient.maison.moi>
	<20051130162923.GB6945@suse.de>
Message-ID: <d82d6db50511301351r2b2869dbme4f66ee3b7d46ad1@mail.gmail.com>

You said Mandriva and Novell were using these two methods.  What is
preventing their widespread adoption because they seem to me to be exactly
what is need in Fedora?  Is there continued development in this direction to
creating even better tools and what those better tools would be I don't
know.

Either way, sounds great.  I should probably install Mandriva or SuSE one of
these days and check it out.

Benjy,
AWWTF


On 11/30/05, Michael Schroeder <mls at suse.de> wrote:
>
> On Wed, Nov 30, 2005 at 05:09:31PM +0100, Emmanuel Seyman wrote:
> > Looking at all the rpms bigger than the kernel, a whole lot of them are
> > language packs (KDE, openoffice, aspell) and fonts (asian and tetex). Is
> this
> > patch.rpm mechanism going to work on these files?
>
> Sure. Why shouldn't it work? But please don't confuse patch rpms
> and delta rpms.
>
> patch rpms are rpms which contain only changed files. They contain
> complete files, no binary delta mechanism is used. patch rpms can
> be applied to multiple versions.
> delta rpms use a binary delta algorithm and can thus be only applied
> to a single version of a rpm.
>
> Cheers,
>   Michael.
>
> --
> Michael Schroeder                                   mls at suse.de
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
>
> --
> 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/20051130/c806fa95/attachment.htm>

From nicolas.mailhot at laposte.net  Wed Nov 30 22:00:22 2005
From: nicolas.mailhot at laposte.net (Nicolas Mailhot)
Date: Wed, 30 Nov 2005 23:00:22 +0100
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <1133386357.2936.23.camel@localhost.localdomain>
References: <20051130202605.GA7078@jadzia.bu.edu>
	<20051130202856.GA7234@devserv.devel.redhat.com>
	<20051130203205.GA8611@jadzia.bu.edu>
	<20051130203309.GB7234@devserv.devel.redhat.com>
	<20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter>
	<1133383754.10697.31.camel@rousalka.dyndns.org>
	<1133383986.7253.31.camel@cutter>
	<1133385242.10697.56.camel@rousalka.dyndns.org>
	<1133386357.2936.23.camel@localhost.localdomain>
Message-ID: <1133388025.10697.84.camel@rousalka.dyndns.org>

Le mercredi 30 novembre 2005 ? 16:32 -0500, Peter Jones a ?crit :
> On Wed, 2005-11-30 at 22:13 +0100, Nicolas Mailhot wrote:
> 
> > > it's called anaconda
> > 
> > Nah
> > Anaconda requires you to get an installation image somewhere and burn it
> > to a CD/DVD. A firstboot package would just add an entry to the usual
> > boot menu, and work even on a CD-less system. Plus a firstboot could be
> > split into "manage partitions" "manage lvms" ... tools, while anaconda
> > only knows about update process.
> 
> That's called a "rescue" image.
> 
> So what you're saying is you'd like either anaconda to also be a rescue
> image, or the rescue image to also do upgrades.

What I'm saying is the various anaconda operations could be modularized
into separate tools, which could then be assembled in the current
install CD, the rescue CD, normal distribution tools (for stuff that can
be run on a live system), or bootloader-access tools (for stuff which
can not be safely run on a live system).

And then a full release upgrade would just be 
1. update packages via yum
2. the new fedora-release file depends on one or several firstboot
packages, which are therefore installed during the yum upgrade
3. on installation these packages create a "distro upgrade" bootloader
entry, make it default and ask to reboot
4. user reboots on this entry and the actions which can not be done on a
live system are performed.

No burn new iso stage, no need for a cd drive, upgrade steps are
performed whenever the associated packages are available in the repo not
when an installation iso has been created, general purpose tools (lvm
management, partition management, whatever) can be accessed at any time
just by rebooting on the right bootloader entry or executing the right
command on the system. Cold boot ramdisk can be assembled using the
current system keyboard and X11 settings, removing the need for the dumb
anaconda probing.

Of course if the system is completely hosed you'll need to go back to
the install stage, but that should be the exception not the norm.

-- 
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/20051130/2662f0b4/attachment.sig>

From dwmw2 at infradead.org  Wed Nov 30 22:35:12 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 30 Nov 2005 22:35:12 +0000
Subject: Pipe dreams: yum-based anaconda a step towards on-line
	yum-based upgrades?
In-Reply-To: <20051130202605.GA7078@jadzia.bu.edu>
References: <20051130202605.GA7078@jadzia.bu.edu>
Message-ID: <1133390112.4117.122.camel@baythorne.infradead.org>

On Wed, 2005-11-30 at 15:26 -0500, Matthew Miller wrote:
> But overall, seemed like a pretty successful experiment. And, given the
> super-short lifespan of FC releases, something I'd really be interested in
> having as an option.

I've got plenty of FC4 machines which were upgraded from FC3 or FC2 that
way. It usually takes a little bit of manual assistance (like installing
compat-db and/or compat-openssl packages) but works fine.

-- 
dwmw2