rawhide report: 20050121 changes

[Build System]

Removed package gnuchess

Removed package freeciv

Removed package ytalk

Removed package sylpheed

Removed package aumix

Removed package xboard

Removed package balsa

Removed package grip

Removed package libesmtp

Removed package gv

Removed package diskcheck

Removed package xosview

Removed package pdksh

Removed package comsat

Removed package xsnow

Updated Packages:

Xaw3d-1.5E-3
------------
* Thu Jan 20 2005 Than Ngo <than at redhat.com> 1.5E-3
- bump release

* Thu Jan 20 2005 Than Ngo <than at redhat.com> 1.5E-2
- enable ARROW_SCROLLBARS, MULTIPLANE_PIXMAPS

ant-0:1.6.2-3jpp_2fc
--------------------
* Thu Jan 20 2005 Gary Benson <gbenson at redhat.com> 0:1.6.2-3jpp_2fc
- Use jdtcore.jar instead of ecj.jar when running under libgcj.

bluez-libs-2.14-2
-----------------
* Thu Jan 20 2005 David Woodhouse <dwmw2 at redhat.com> 2.14-2
- Update to bluez-libs 2.14
- Restore hci_remote_name() and hci_local_name() functions

bluez-utils-2.14-1
------------------
* Thu Jan 20 2005 David Woodhouse <dwmw2 at redhat.com> 2.14-1
- Update to bluez-utils 2.14

cups-1:1.1.23-4
---------------
* Thu Jan 20 2005 Tim Waugh <twaugh at redhat.com> 1.1.23-4
- Mark the initscript noreplace (bug #145629).

emacs-21.3-20
-------------
* Fri Jan 14 2005 Jens Petersen <petersen at redhat.com> - 21.3-20
- workaround xorg-x11 modifier key problem with
emacs-21.3-xterm-modifiers-137868.patch (Thomas Woerner, 137868)

* Mon Nov 29 2004 Jens Petersen <petersen at redhat.com> - 21.3-19
- prefer XIM status under-the-window for now to stop xft httx from dying
(125413): add emacs-xim-status-under-window-125413.patch
- default diff to unified format in .emacs

* Thu Nov 04 2004 Jens Petersen <petersen at redhat.com> - 21.3-18
- show emacs again in the desktop menu (132567)
- require fonts-xorg-75dpi to prevent empty boxes at startup due to missing
fonts (Johannes Kaiser, 137060)

gaim-1:1.1.2-1
--------------
* Thu Jan 20 2005 Warren Togami <wtogami at redhat.com. 1:1.1.2-1
- 1.1.2 with more bugfixes

gdb-6.3.0.0-0.7
---------------
* Thu Jan 20 2005 Jeff Johnston <jjohnstn at redhat.com> 6.3.0.0-0.7
- Fix to allow breaking by line in both the in-charge and
not-in-charge ctor/dtor.
- Bugzilla 117826

* Thu Jan 20 2005 Andrew Cagney <cagney at redhat.com> 6.3.0.0-0.6
- Rebuild.

* Thu Jan 20 2005 Andrew Cagney <cagney at redhat.com> 6.3.0.0-0.5
- Use bfd_get_synthetic_symtab to read in any synthetic symbols
such as 64-bit PPC's ".symbol"s.

glibc-kernheaders-2.4-9.1.89
----------------------------
* Thu Jan 20 2005 David Woodhouse <dwmw2 at redhat.com> 2.4-9.1.89
- Revert the tarball update of December 10th; too much was pruned.

* Tue Jan 18 2005 David Woodhouse <dwmw2 at redhat.com> 2.4-9.1.88
- Fix and update and include missing ATM headers (#127098)
- Update MTD headers.

* Fri Dec 10 2004 Roland McGrath <roland at redhat.com>
- update syscall numbers on x86_64, ia64
- removed many files users should not need
- update ia64 ptrace_offsets.h (#117234)
- other misc updates from upstream

gpdf-2.8.2-2.3
--------------
* Wed Jan 19 2005 Marco Pesenti Gritti <mpg at redhat.com> 2.8.2-2.3
- Add patch for CAN-2005-0064

hal-0.4.6-2
-----------
* Thu Jan 20 2005 David Zeuthen <davidz at redhat.com> 0.4.6-2
- Fix parameters to configure

* Thu Jan 20 2005 David Zeuthen <davidz at redhat.com> 0.4.6-1
- New upstream release
- Should close #145099, #144600, #140150, #145223, #137672

* Wed Jan 12 2005 David Zeuthen <davidz at redhat.com> 0.4.5-1
- New upstream release.
- Should close #142834, #141771, #142183

kernel-2.6.10-1.1105_FC4
------------------------
* Thu Jan 20 2005 Dave Jones <davej at redhat.com>
- Rebase to -bk8

libieee1284-0.2.9-1
-------------------
* Thu Jan 20 2005 Tim Waugh <twaugh at redhat.com> 0.2.9-1
- 0.2.9.
- Build requires python-devel.
- Ship Python extension module.

libselinux-1.21.1-1
-------------------
* Thu Jan 20 2005 Dan Walsh <dwalsh at redhat.com> 1.21.1-1
- Update from NSA

* Wed Jan 12 2005 Dan Walsh <dwalsh at redhat.com> 1.20.1-3
- Modify matchpathcon to also process file_contexts.local if it exists

libsepol-1.2.1.1-1
------------------
* Thu Jan 20 2005 Dan Walsh <dwalsh at epoch.ncsc.mil> 1.2.1.1-1
- Update to latest from NSA
* Merged build fix patch from Manoj Srivastava.

mozplugger-1.7.1-1
------------------
* Thu Jan 20 2005 Than Ngo <than at redhat.com> 1.7.1-1
- update to 1.7.1
- remove mozplugger-1.6-2-ia64.patch, it's included in new upstream

policycoreutils-1.21.1-1
------------------------
* Thu Jan 20 2005 Dan Walsh <dwalsh at redhat.com> 1.21.1-1
- Update to latest from NSA

pygtk2-2.5.2-1
--------------
* Thu Jan 20 2005 <jrb at redhat.com> - 2.5.1-1
- New version

rpmdb-fedora-1:4-0.20050121
---------------------------

selinux-policy-strict-1.21.2-5
------------------------------
* Thu Jan 20 2005 Dan Walsh <dwalsh at redhat.com> 1.21.2-5
- More Fixes for rlogind

* Wed Jan 19 2005 Nalin Dahyabhai <nalin at redhat.com> 1.21.2-4
- Add a default_context entry for the remote_login_t domain, for telnet

selinux-policy-targeted-1.21.2-5
--------------------------------
* Thu Jan 20 2005 Dan Walsh <dwalsh at redhat.com> 1.21.2-5
- More Fixes for rlogind

usermode-1.77-1
---------------
* Thu Jan 20 2005 Jindrich Novy <jnovy at redhat.com> 1.77-1
- preserve LANGUAGE environment variable in userhelper (#82300)
- use badge instead of keyring icon for pam-panel-icon (#122487)
- icon is not showed in the panel when logged as root (#75234)
- use new environment variable USERHELPER_UID to identify
an user who executed an application via userhelper (#116186)

wget-1.9.1-18
-------------
* Thu Jan 20 2005 Karsten Hopp <karsten at redhat.de> 1.9.1-18
- add support for --protocol-directories option as documented
in the man page (Ville Skytt?, #145571)

xemacs-sumo-20050118-1
----------------------
* Wed Jan 19 2005 Jens Petersen <petersen at redhat.com> 20050118-1
- update to new sumos
- update auctex-texjp-platex.patch
- auctex-texsite-lisp-dir.patch no longer needed
- auc-tex.info is now correctly auctex.info
- physically remove .el.orig patch backup files

* Tue Dec 14 2004 Jens Petersen <petersen at redhat.com>
- add auctex-texsite-lisp-dir.patch to initialise auctex TeX-lisp-directory
- exclude .orig backup files

xpdf-1:3.00-15
--------------
* Thu Jan 20 2005 Than Ngo <than at redhat.com> 1:3.00-15
- Applied patch to fix CAN-2005-0064 (bug #145050)

[Peter Backlund]

Post by Build System
emacs-21.3-20
-------------
* Fri Jan 14 2005 Jens Petersen <petersen at redhat.com> - 21.3-20
- workaround xorg-x11 modifier key problem with
emacs-21.3-xterm-modifiers-137868.patch (Thomas Woerner, 137868)
* Mon Nov 29 2004 Jens Petersen <petersen at redhat.com> - 21.3-19
- prefer XIM status under-the-window for now to stop xft httx from dying
(125413): add emacs-xim-status-under-window-125413.patch
- default diff to unified format in .emacs
* Thu Nov 04 2004 Jens Petersen <petersen at redhat.com> - 21.3-18
- show emacs again in the desktop menu (132567)
- require fonts-xorg-75dpi to prevent empty boxes at startup due to missing
fonts (Johannes Kaiser, 137060)

Any news on the Gtk Emacs front?

/Peter

[Enrico Scholz]

Post by Peter Backlund

Post by Build System
emacs-21.3-20
-------------

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.



Enrico

[Dan Williams]

Post by Enrico Scholz
I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

Many GTK apps have startup times around 1s. gedit, for example, on a
relatively fast box, and that's pulling some GNOME libs with it... What
about emacs would make it so slow?

Dan

[Rahul Sundaram]

Hi

Post by Dan Williams
Many GTK apps have startup times around 1s. gedit, for example, on a
relatively fast box, and that's pulling some GNOME libs with it... What
about emacs would make it so slow?

gedit is pretty slow compared to leafpad on my box. it would nice to
have that one as an alternative. the gtk file dialog boxes takes
around 5 seconds the first time

[Enrico Scholz]

Post by Dan Williams

Post by Enrico Scholz
I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

Many GTK apps have startup times around 1s. gedit, for example,

not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first
startup it needs yet more as it has to start lots of Gnome programs.



Enrico

[Owen Taylor]

Post by Enrico Scholz

Post by Dan Williams

Post by Enrico Scholz
I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

Many GTK apps have startup times around 1s. gedit, for example,

not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first
startup it needs yet more as it has to start lots of Gnome programs.

I'd like to say that was far too slow, and it sounds a little slow,
but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz)

Some things you can try:

- Make sure that your font caches is up to date (run fc-cache -f
as root). I've seen people have this screwed up somehow before,
though it theoretically should fall back to a homedir cache
if the global caches aren't up-to-date.

- Try using gtk-update-icon-cache

- There's a patch in GTK+ CVS (will be in 2.6.2) that eliminates some
excessive font lookup and loading action:

2005-01-09 Anders Carlsson <andersca at gnome.org>

* gtk/gtkcellrenderertext.c: (get_size):
* gtk/gtklabel.c: (gtk_label_size_request):
* gtk/gtkprogressbar.c: (gtk_progress_bar_size_request):
Don't pass NULL to pango_context_get_metrics. Use
pango_context_get_language instead, which is way faster.

That may make a substantial difference in startup times.

Regards,
Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/b6ac9be3/attachment.bin

[Sean Middleditch]

Post by Owen Taylor
I'd like to say that was far too slow, and it sounds a little slow,
but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz)

It also seems like he's not running GNOME at all, so gedit would pull in
a lot of GNOME stuff that isn't already loaded. gedit should really
only be used by GNOME users. gedit's speed in this case would not
affect GTK emacs, since emacs would be _just_ a GTK program, and not
depend on all the GNOME stuff (like gnome-vfs) that gedit does.

[Rui Miguel Seabra]

Post by Sean Middleditch

Post by Owen Taylor
I'd like to say that was far too slow, and it sounds a little slow,
but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz)

It also seems like he's not running GNOME at all,

I use GNOME all the time, and gedit just took 6s to be usable (counting
from click on 'Text Editor' in the Accessories menu).

This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at
approximately 75%).

Post by Sean Middleditch
so gedit would pull in a lot of GNOME stuff that isn't already loaded.

I don't know if that solves all problems (like disk speed, etc)...

Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/0db1122b/attachment.bin

[Sean Middleditch]

Post by Rui Miguel Seabra
I use GNOME all the time, and gedit just took 6s to be usable (counting
from click on 'Text Editor' in the Accessories menu).
This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at
approximately 75%).

Aside from the stuff Owen suggested, are you perhaps loading certain
plugins that cause the slow down, or loading a very large file? You
might try experimenting with the plugins especially to see if one of
them is causing it. I only have the spell checker enabled and gedit
loaded within 1s cold.

[Rui Miguel Seabra]

Post by Sean Middleditch

Post by Rui Miguel Seabra
I use GNOME all the time, and gedit just took 6s to be usable (counting
from click on 'Text Editor' in the Accessories menu).
This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at

^ should be a G <:)

Post by Sean Middleditch

Post by Rui Miguel Seabra
approximately 75%).

Aside from the stuff Owen suggested, are you perhaps loading certain
plugins that cause the slow down, or loading a very large file? You
might try experimenting with the plugins especially to see if one of
them is causing it. I only have the spell checker enabled and gedit
loaded within 1s cold.

Well, since gedit is too braindead for my uses I never use it, so it
comes as default on Fedora.

Also, notice that I simply clicked on the menu item, so I didn't even
load any file at all!

Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/cf5ef564/attachment.bin

[Felipe Alfaro Solana]

Post by Rui Miguel Seabra

Post by Sean Middleditch

Post by Owen Taylor
I'd like to say that was far too slow, and it sounds a little slow,
but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz)

It also seems like he's not running GNOME at all,

I use GNOME all the time, and gedit just took 6s to be usable (counting
from click on 'Text Editor' in the Accessories menu).
This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at
approximately 75%).

Ah! That explains the slowness... 2.8Mhz is even slower than my old XT
:-)
Now seriously: something is going on wrong, since gedit tooks 2 seconds
to open on my Northwood P4 2Ghz with 512MB running Xen with concurrent
2 domains running.

[Rui Miguel Seabra]

Post by Felipe Alfaro Solana
Ah! That explains the slowness... 2.8Mhz is even slower than my old XT
:-)
Now seriously: something is going on wrong, since gedit tooks 2 seconds
to open on my Northwood P4 2Ghz with 512MB running Xen with concurrent
2 domains running.

LOL yes. G, not M :) my gosh, this would be almost 8 times slower than
my first computer :)))

Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?

Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/bee5930c/attachment.bin

[Enrico Scholz]

Post by Owen Taylor

Post by Enrico Scholz
not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first
startup it needs yet more as it has to start lots of Gnome programs.

I'd like to say that was far too slow, and it sounds a little slow,
but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz)
- Make sure that your font caches is up to date (run fc-cache -f
as root). I've seen people have this screwed up somehow before,
though it theoretically should fall back to a homedir cache
if the global caches aren't up-to-date.
- Try using gtk-update-icon-cache

Thanks, but this does not help. I have two theories:

* Gnome2 application are only in Gnome2 environments fast, and I do
not run Gnome2... KDE has similar effects but after starting one
KDE application, the other ones have reasonable startup-times
(e.g. kghostview needs 10-15s on first start and then around 2s).

* 'strace -eopen ggv' shows that it opens all and every icon which it
can find on the system. As these icons are on /usr/share which are on
an NFS share, this can cause slowdowns. Nevertheless, this is a broken
behavior as only a small subset of the icons will be used by gedit
finally.

Post by Owen Taylor
- There's a patch in GTK+ CVS (will be in 2.6.2) that eliminates some

I will follow rawhide development but do not have time to try this now.





Enrico

[Sean Middleditch]

Post by Enrico Scholz
* 'strace -eopen ggv' shows that it opens all and every icon which it
can find on the system. As these icons are on /usr/share which are on
an NFS share, this can cause slowdowns. Nevertheless, this is a broken
behavior as only a small subset of the icons will be used by gedit
finally.

That's why Owen asked you to run gtk-update-icon-cache. It's a new
feature of GTK 2.6 that attempts to solve the icon loading performance
problems.

[Enrico Scholz]

Post by Sean Middleditch

Post by Enrico Scholz
* 'strace -eopen ggv' shows that it opens all and every icon which it
can find on the system. As these icons are on /usr/share which are on
an NFS share, this can cause slowdowns. Nevertheless, this is a broken
behavior as only a small subset of the icons will be used by gedit
finally.

That's why Owen asked you to run gtk-update-icon-cache.

I executed this command but it did not help. 'strace' showed that it is
nearly a noop: it loads some dynamic libraries and exits then with code
0...


Enrico

[Sean Middleditch]

Post by Enrico Scholz

Post by Sean Middleditch
That's why Owen asked you to run gtk-update-icon-cache.

I executed this command but it did not help. 'strace' showed that it is
nearly a noop: it loads some dynamic libraries and exits then with code
0...

--help is your friend. ;-)

Try gtk-update-icon-cache ~/.icons as your user, or gtk-update-icon-
cache /usr/share/icons as root.

Post by Enrico Scholz
Enrico

[Enrico Scholz]

Post by Sean Middleditch

Post by Enrico Scholz

Post by Sean Middleditch
That's why Owen asked you to run gtk-update-icon-cache.

I executed this command but it did not help. 'strace' showed that it is
nearly a noop: it loads some dynamic libraries and exits then with code
0...

--help is your friend. ;-)
Try gtk-update-icon-cache ~/.icons as your user, or gtk-update-icon-
cache /usr/share/icons as root.

Ah... running on /usr/share/icons alone will not help. But after figuring
out the expected 'icon-theme.cache' files, I executed the command for the
5 requested directories. Then gedit starts significantly faster.

Unfortunately, the cache must be renewed manually when things change
there and I have ugly 'icon-theme.cache' files which are not covered by
the package-management.




Enrico

[Sean Middleditch]

Post by Enrico Scholz
Ah... running on /usr/share/icons alone will not help. But after figuring
out the expected 'icon-theme.cache' files, I executed the command for the
5 requested directories. Then gedit starts significantly faster.

Whoops, right. Sorry.

Post by Enrico Scholz
Unfortunately, the cache must be renewed manually when things change
there and I have ugly 'icon-theme.cache' files which are not covered by
the package-management.

An "ugly" filename buried in /usr or ~/.icons is absolutely nothing bad.
All those weird linux-* files in /boot are pretty ugly, too...

The cache files should be part of any packaged themes. Probably should
be a bug report requesting this if they are not already. The user theme
installer needs to be running this on install as well if it doesn't
already. (Would be more likely to happen if GNOME had a real theme
format so installing icon themes using the theme installer was actually
easier than just unpacking from file-roller... or should all icon themes
come with the icon-theme.cache file pre-generated from now on?)

[Rahul Sundaram]

Hi

... KDE has similar effects but after starting one

Post by Enrico Scholz
KDE application, the other ones have reasonable startup-times
(e.g. kghostview needs 10-15s on first start and then around 2s).

kde apps seem to use a hack called kdeinit to share common base. it
does cause problems with selinux

[Rahul Sundaram]

Hi

Post by Owen Taylor
- Make sure that your font caches is up to date (run fc-cache -f
as root). I've seen people have this screwed up somehow before,
though it theoretically should fall back to a homedir cache
if the global caches aren't up-to-date.

I did this

Post by Owen Taylor
- Try using gtk-update-icon-cache

You mean run it as root or user?. did both anyway


take about 6 seonds on cold and 3 secs on rerun. PIII with 128 MB ram.

even the file dialog boxes take about 3-4 secs to show up

[Jose' Matos]

Post by Enrico Scholz

Post by Peter Backlund

Post by Build System
emacs-21.3-20

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

I am using the packages from http://people.redhat.com/petersen/emacs
without any problems.

Actually it has been a pleasant surprise as it works, it looks nice,
etc...

I don't notice any difference in the startup time from the previous
frontend.

I also feel a little bit guilty since I should have reported this directly
to the packager but since it works there isn't nothing to complain... ;-)

Post by Enrico Scholz
Enrico

[Havoc Pennington]

Post by Enrico Scholz

Post by Peter Backlund

Post by Build System
emacs-21.3-20
-------------

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

GTK port does *not* mean AA fonts. It means using the standard font
system fontconfig, which *can be configured* to have AA fonts (and we do
that by default). But if you open Preferences->Font or edit fonts.conf
you can get whatever aliasing (or font) you like.

Havoc

[Jeremy Katz]

Post by Enrico Scholz

Post by Peter Backlund

Post by Build System
emacs-21.3-20
-------------

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

The last time I tried (and checking again with the current packages Jens
has, it's still true), they're just using gtk for all of the windowing
code. The text widget is still the same old emacs text widget.

Jeremy

[P]

Post by Enrico Scholz

Post by Peter Backlund

Post by Build System
emacs-21.3-20
-------------

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.
Current (X)Emacs have a startup-time <1 second so that it can be used
as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10
seconds.

I agree with you, but you can easily turn off antialiasing:
http://www.pixelbeat.org/docs/fc_fixed.html

[Nicolas Mailhot]

Post by Enrico Scholz

Post by Peter Backlund

Post by Build System
emacs-21.3-20
-------------

...
Any news on the Gtk Emacs front?

I would not spend much energy on such a port. A Gtk port means AA
fonts which are really a bad choice for text based applications.

A gtk port means fontconfig and AA ie all the users that do not use pure
american files on a 75dpi screen can get some mileage out of emacs
without ruining their eyes.

fontconfig support is the single reason several people (including me)
dumped emacs/xemacs altogether for vim/gvim recently. I'm amazed someone
can maintain like you that fontconfig is a bad choice for text apps -
surely an app that's devoted to displaying text is *more* sensitive to
the text rendering tech than your average ogg player.
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050123/6064200c/attachment.bin

[Felipe Alfaro Solana]

Post by Build System
Removed package aumix

Why?

[Féliciano Matias]

Le vendredi 21 janvier 2005 ? 15:12 +0100, Felipe Alfaro Solana a

Post by Build System
Removed package aumix

Why?

Perhaps because OSS is not supported.
Use alsamixer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/cdf8168d/attachment.bin

[Enrico Scholz]

Post by Build System
Removed package gnuchess
Removed package freeciv
Removed package ytalk
Removed package sylpheed
Removed package aumix
Removed package xboard
Removed package balsa
Removed package grip
Removed package libesmtp
Removed package gv

??? I hope that some of these removals happened just because of temporary
issues. I understand that things like sylpheed or balsa can disappear as
there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games
like 'gnuchess' or 'freeciv' are classics which should not be missed on
any system.




Enrico

[Féliciano Matias]

Post by Enrico Scholz

Post by Build System
Removed package gnuchess
Removed package freeciv
Removed package ytalk
Removed package sylpheed
Removed package aumix
Removed package xboard
Removed package balsa
Removed package grip
Removed package libesmtp
Removed package gv

??? I hope that some of these removals happened just because of temporary
issues. I understand that things like sylpheed or balsa can disappear as
there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games
like 'gnuchess' or 'freeciv' are classics which should not be missed on
any system.

Perhaps they will be in Fedora Extra (official).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/e7137c39/attachment.bin

[Dan Williams]

Post by Enrico Scholz

Post by Build System
Removed package gv

there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games

Um, ggv or gpdf? or kpd? or xpdf? I'd personally use ggv, and if that
doesn't work, use xpdf for PDFs.

Furthermore, these are really just leaving Fedora Core, but should still
be in Fedora Extras AFAIK.

Dan

[Jonathan Underwood]

Post by Dan Williams

Post by Enrico Scholz

Post by Build System
Removed package gv

there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games

Um, ggv or gpdf? or kpd? or xpdf? I'd personally use ggv, and if that
doesn't work, use xpdf for PDFs.
Furthermore, these are really just leaving Fedora Core, but should still
be in Fedora Extras AFAIK.
Dan

IMO it is a shame to lose gv - gv works much faster with xforwarding
over ssh than the "ponderous" ggv.

[Rahul Sundaram]

Hi

Post by Jonathan Underwood
IMO it is a shame to lose gv - gv works much faster with xforwarding
over ssh than the "ponderous" ggv.

evince which is available is available as a test yum repo is fast for
pdf and is supposed to be capable for viewing postscript files too.

http://www.gnome.org/projects/evince/

any chance this will be part of fc4?

[Jeremy Katz]

Post by Rahul Sundaram

Post by Jonathan Underwood
IMO it is a shame to lose gv - gv works much faster with xforwarding
over ssh than the "ponderous" ggv.

evince which is available is available as a test yum repo is fast for
pdf and is supposed to be capable for viewing postscript files too.
http://www.gnome.org/projects/evince/
any chance this will be part of fc4?

Magic 8 ball says "Highly likely" :) For now, packages for the devel
tree at http://people.redhat.com/~katzj/evince/ (cvs snap updated last
night)

Jeremy

[Rahul Sundaram]

Hi

Post by Dan Williams
Furthermore, these are really just leaving Fedora Core, but should still
be in Fedora Extras AFAIK.

it would nice to receive a email notice from someone involved in this
to the discussion list before the rawhide changes

[Enrico Scholz]

Post by Dan Williams

Post by Enrico Scholz

Post by Build System
Removed package gv

there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games

Um, ggv or gpdf? or kpd? or xpdf?

*pdf does not display PS files.

Post by Dan Williams
I'd personally use ggv,

This has huge startup times (5 seconds) where gv appears in <1 second,
is dog slow accross ssh tunnels and has unergonomic keyboard bindings
(every viewer can be terminated with pressing 'Q' -- but not ggv which
follows probably a stupid Gnome guide and requires ^W).



Enrico

[Sean Middleditch]

Post by Enrico Scholz

Post by Dan Williams

Post by Enrico Scholz

Post by Build System
Removed package gv

there are enough alternatives. But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games

Um, ggv or gpdf? or kpd? or xpdf?

*pdf does not display PS files.

Post by Dan Williams
I'd personally use ggv,

This has huge startup times (5 seconds) where gv appears in <1 second,
is dog slow accross ssh tunnels and has unergonomic keyboard bindings
(every viewer can be terminated with pressing 'Q' -- but not ggv which
follows probably a stupid Gnome guide and requires ^W).

If you don't like the software in Core, you are fully allowed and
encouraged to install add-ons from Extras or other places. Core cannot
and should not try to meet everyone's personal preferences, and should
not carry six apps that do the same thing. There's a reason it's called
"Core" and not "Everything". ;-)

Between gv and ggv, ggv is entirely the correct app to choose for Core.
While 'q' may be common among certain viewing apps, it is *not* common
among GUI apps in general, and the key bindings should be consistent
across the *entire* desktop. Startup time, while _very_ unfortunate if
slow, takes second seat to user interface concerns. Again, if you
dislike ggv, don't use it, and install something you do like.

In any event, Evince is likely to replace both ggv and gpdf (hopefully
even by Fedora Core 4's release, if we're lucky) so check that out and
see if it's speedy enough for you. (It seems snappy as can possibly be
on my machine.)

http://www.gnome.org/projects/evince/

(FC RPMs available at that site)

[Rahul Sundaram]

Hi

There's a reason it's called

Post by Sean Middleditch
"Core" and not "Everything". ;-)

This is why I wanted non default stuff like KDE etc moved to fedora
extras. it can be handed over to the kde-redhat.sf.net guys since they
are redoing upstream KDE anyway

[Enrico Scholz]

Post by Sean Middleditch
There's a reason it's called

Post by Sean Middleditch
"Core" and not "Everything". ;-)

This is why I wanted non default stuff like KDE etc moved to fedora
extras.

ACK. Same should happen with Gnome.



Enrico

[Sean Middleditch]

Post by Enrico Scholz

Post by Sean Middleditch
There's a reason it's called

Post by Sean Middleditch
"Core" and not "Everything". ;-)

This is why I wanted non default stuff like KDE etc moved to fedora
extras.

ACK. Same should happen with Gnome.

GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

Post by Enrico Scholz
Enrico

[Richard June]

Post by Sean Middleditch
GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

I'm with you, keep GNOME and KDE in core. everything else can go in extras
*especially* after there's a graphical yum client/software manager that's
included in core.
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050121/78b56fb5/attachment.bin

[Toshio Kuratomi]

Post by Richard June

Post by Sean Middleditch
GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

I'm with you, keep GNOME and KDE in core. everything else can go in extras
*especially* after there's a graphical yum client/software manager that's
included in core.

Although KDE and GNOME fill pretty much the same niche while XFCE aims for a
slightly different goal....

Having things in Core means you don't have to download if you can buy the
CDs. XFCE is targetted at people with older hardware. Are they more likely
to be highly technical people rescuing older hardware and therefore going to
have high speed access or poor and therefore more likely to be on dialup?

-Toshio

[Sean Middleditch]

Post by Toshio Kuratomi
Having things in Core means you don't have to download if you can buy the
CDs. XFCE is targetted at people with older hardware. Are they more likely
to be highly technical people rescuing older hardware and therefore going to
have high speed access or poor and therefore more likely to be on dialup?

Personally, I think Extras should be included in most CD sets, and that
it should be supported in the installer. (Obviously not in FC4, maybe
in FC5.)

Especially when DVD distributions are a little more common, it's
entirely realistic to expect a user to have both Core and Extras on
disk.

Post by Toshio Kuratomi
-Toshio

[Josh Boyer]

Post by Richard June

Post by Sean Middleditch
GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

I'm with you, keep GNOME and KDE in core. everything else can go in extras
*especially* after there's a graphical yum client/software manager that's
included in core.

One could argue that Xorg and fvmw2 are all that's needed for Core.
Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as
well.

But like most others said, I'd rather see both GNOME and KDE available
in Core. That allows people that are new to Fedora, and Linux in
general, the ability to play around and choose which they like better
without downloading MiB worth of RPMs.

josh

[Sean Middleditch]

Post by Josh Boyer

Post by Richard June

Post by Sean Middleditch
GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

I'm with you, keep GNOME and KDE in core. everything else can go in extras
*especially* after there's a graphical yum client/software manager that's
included in core.

One could argue that Xorg and fvmw2 are all that's needed for Core.
Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as
well.

It's not "strip down," it's, "only provide one option." GNOME, KDE, and
XFCE are the only actual desktop environments in the system. (Yes,
there is a very big difference between a desktop environment and a
window manager.)

Three desktops environments aren't needed. Of the three, two are very
popular and very politically charged, the third is in fact an extra
provided mostly for low-resource folks.

*If* KDE is removed (and I don't think it will be, or should be at this
time) then that doesn't mean GNOME should be removed. GNOME is the
default, KDE is by definition (by not being the default) provided as an
extra desktop in addition to GNOME.

I certainly wouldn't mind seeing Core become the bare minimum, and then
split Extras into sets like Network Server, GNOME Desktop, KDE Desktop,
Desktop Applications, and so on. That's a fundamentally different
distribution model than the Fedora Core/Extras split, though.

[Josh Boyer]

Post by Sean Middleditch

Post by Josh Boyer
One could argue that Xorg and fvmw2 are all that's needed for Core.
Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as
well.

It's not "strip down," it's, "only provide one option." GNOME, KDE, and
XFCE are the only actual desktop environments in the system. (Yes,
there is a very big difference between a desktop environment and a
window manager.)

Yeah, I know. That's why I don't want either GNOME or KDE to go.

Post by Sean Middleditch
Three desktops environments aren't needed. Of the three, two are very
popular and very politically charged, the third is in fact an extra
provided mostly for low-resource folks.
*If* KDE is removed (and I don't think it will be, or should be at this
time) then that doesn't mean GNOME should be removed. GNOME is the
default, KDE is by definition (by not being the default) provided as an
extra desktop in addition to GNOME.

I'll agree with you there, but with one twist. *If* a desktop
environment is to be moved to Extras, why would it have to be KDE? Or
in other words, why is GNOME the default? Because of historical
reasons?

Like you said, GNOME vs. KDE is hugely political or as others like to
call it, religion. In a community driven distribution, which Fedora is
supposed to be, you'll never get everyone to agree which environment
should be the default.

So instead of having an endless debate over which should be the default
and which should go, I'd just rather see both stay.

josh

[Rahul Sundaram]

Hi

Post by Josh Boyer
I'll agree with you there, but with one twist. *If* a desktop
environment is to be moved to Extras, why would it have to be KDE? Or
in other words, why is GNOME the default? Because of historical
reasons?

No. because redhat has more gnome developers and does all its
integration bits for gnome. its the default desktop environment.

Post by Josh Boyer
Like you said, GNOME vs. KDE is hugely political or as others like to
call it, religion. In a community driven distribution, which Fedora is
supposed to be, you'll never get everyone to agree which environment
should be the default.

so, lets have xfce, fluxbox and the rest of the gang inside core?. why
call it fedora core anymore then. thats going the way of debian

[Alan Cox]

Post by Rahul Sundaram
so, lets have xfce, fluxbox and the rest of the gang inside core?. why
call it fedora core anymore then. thats going the way of debian

I'm nowdays using XFCE a lot but I do believe its a logical candidate for
extras. I'm not so sure personally about KDE being an extras item. If someone
said "you have two CD-ROM images no more" then I'd consider KDE for extras
but not with four.

The politics is unfortunate because its not neccessarily about which is best
(current hypothesis: they serve different user needs so there is no more a
'best' than arguing about two very different cars - it depends what you use
it for and how you use it). Its about building an integrated consistent
environment.

Alan

[Rahul Sundaram]

Hi

Post by Alan Cox
I'm nowdays using XFCE a lot but I do believe its a logical candidate for
extras.

to clarify my stand on this I use KDE and even fluxbox on occasions
depending on my requirements. so I am not asking for KDE to moved to
fedora extras just because I happen to use Gnome or something else


I'm not so sure personally about KDE being an extras item. If someone

Post by Alan Cox
said "you have two CD-ROM images no more" then I'd consider KDE for extras
but not with four.

I was actually hoping that Fedora core 4 would limit itself to just
one CD or at the maximum two. If Fedora project on the whole can
manage to produce more ISO images, having a subset of fedora extras
which includes the more popular packages especially those being moved
into fedora extras ( Making a case for KDE , xfce etc) would be very
useful

[Charles R. Anderson]

Post by Alan Cox
I'm nowdays using XFCE a lot but I do believe its a logical candidate for
extras. I'm not so sure personally about KDE being an extras item. If someone
said "you have two CD-ROM images no more" then I'd consider KDE for extras
but not with four.
The politics is unfortunate because its not neccessarily about which is best
(current hypothesis: they serve different user needs so there is no more a
'best' than arguing about two very different cars - it depends what you use
it for and how you use it). Its about building an integrated consistent
environment.

When people speak of moving KDE to extras, which parts of it do they
mean? The whole DE, applets, applications, libraries? QT? There are
many KDE/QT applications which serve a particular function better than
any GNOME/GTK counterpart, such as k3b. It would be a shame to lose
some of the better applications simply because they are bundled with
KDE or use KDE infrastructure...

[Emmanuel Seyman]

Post by Charles R. Anderson
any GNOME/GTK counterpart, such as k3b. It would be a shame to lose
some of the better applications simply because they are bundled with
KDE or use KDE infrastructure...

I'ld hardly consider apps being moved to Extras as being lost.

Emmanuel

[Rahul Sundaram]

Hi

Post by Josh Boyer
One could argue that Xorg and fvmw2 are all that's needed for Core.
Minimalistic to the bone.

no. fvwm2 is not a typical DE.

. That allows people that are new to Fedora, and Linux in

Post by Josh Boyer
general, the ability to play around and choose which they like better
without downloading MiB worth of RPMs.

extras can be packaged as a ISO image. you need to download the whole
of fedora or buy it from a third party vendor. if fedora extras or a
subset of it is an ISO image, then moving KDE into extras is just
better reorganisation.

the advantage is that fedora core would be limited to the default
stuff in one or two cds

[Ralf Corsepius]

Post by Rahul Sundaram
Hi

Post by Josh Boyer
One could argue that Xorg and fvmw2 are all that's needed for Core.
Minimalistic to the bone.

no. fvwm2 is not a typical DE.

X+fvwm2 had been the Linux standard desktop environment for many, many
years and is still being used by more folks that you might assume.

Some *nix-purists won't use want any other environment.

Post by Rahul Sundaram
extras can be packaged as a ISO image. you need to download the whole
of fedora or buy it from a third party vendor. if fedora extras or a
subset of it is an ISO image, then moving KDE into extras is just
better reorganisation.

Despite some folke here don't seem to get tired to reiterate this idea,
I have to object: That won't be better, It's naive to move KDE out of
Core.

Ralf

[Rahul Sundaram]

Hi

Post by Ralf Corsepius

Post by Rahul Sundaram
no. fvwm2 is not a typical DE.

X+fvwm2 had been the Linux standard desktop environment for many, many
years and is still being used by more folks that you might assume.

its not the default DE nor part of fedora at all now.

Post by Ralf Corsepius
Despite some folke here don't seem to get tired to reiterate this idea,
I have to object: That won't be better, It's naive to move KDE out of
Core.

I dont see any technical objections here

[Josh Boyer]

Post by Rahul Sundaram
Hi

Post by Ralf Corsepius

Post by Rahul Sundaram
no. fvwm2 is not a typical DE.

X+fvwm2 had been the Linux standard desktop environment for many, many
years and is still being used by more folks that you might assume.

its not the default DE nor part of fedora at all now.

No, it's not and I'm not advocating that it should be. It was just a
"devils advocate" type of statement.

Post by Rahul Sundaram

Post by Ralf Corsepius
Despite some folke here don't seem to get tired to reiterate this idea,
I have to object: That won't be better, It's naive to move KDE out of
Core.

I dont see any technical objections here

That's because it's not always a technical issue. It's about choice.
Default does not mean "this has to be installed". It's just a default.
If I don't like the default, I should be given the option of installing
an alternative. And that is without needing to download another large
ISO after the fact because one didn't realize that KDE wasn't included
in Core anymore.

I say KDE is that alternate because it has a very large user base, and
has been included in the "core" ISOs of every Red Hat/Fedora product
since at least RH 7.3.

Now that's not to say that all the non-base KDE packages have to be
included with Core. I could see having kdegames, kdepim, kdemultimedia,
etc all in Extras. Same goes for the non-base GNOME packages as well.

If there isn't a desktop environment choice in the Core ISOs, then
people will either deal with it, or switch to a different distro.
Personally, I'd rather see more people come to Fedora.

On a positive note, I'm glad this discussion is taking place. Even if
it's being completely ignored by the Red Hat folks, at least members of
the Fedora community are speaking up. :)

josh

[Arjan van de Ven]

Post by Josh Boyer
That's because it's not always a technical issue. It's about choice.
Default does not mean "this has to be installed". It's just a default.
If I don't like the default, I should be given the option of installing
an alternative. And that is without needing to download another large
ISO after the fact because one didn't realize that KDE wasn't included
in Core anymore.

ok just to be devils advocate again; how is having an iso labeled
"Extras-KDE" different from having one additional iso in core that has
the kde packages (I'm not sure if kde fills an entire CD but it'll go
quite some way towards that anyway). In the first case you offer the
user the choice to download it or *not* download it if the user isn't
going to use KDE, in the case of KDE-in-core you force downloading that
same ISO on all users, regardless of whether they will install KDE or
not.

Your argument seems to be "but then I have to download an extra iso"....
well you download that iso anyway, and not just you but everyone else
too.



(Note: I guess OpenOffice might deserve the own-iso treatment as well :)

Note to conspiracy theorists: this is NOT a RH official opinion. It's
not even MY opinion per se; it's just food for thought on the "but then
we make people download one more iso" argument which I considered
flawed. There may or may not be other arguments, the discussion is
interesting, but this one I consider mostly a bad argument.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050122/f32220c9/attachment.bin

[Dariusz J. Garbowski]

Post by Arjan van de Ven
Your argument seems to be "but then I have to download an extra iso"....
well you download that iso anyway, and not just you but everyone else
too.
(Note: I guess OpenOffice might deserve the own-iso treatment as well :)

And so might Gnome :-)

Note: I'm Gnome user but I like to have KDE installed on my boxes as well...

Regards,
Dariusz

[Josh Boyer]

Post by Arjan van de Ven
ok just to be devils advocate again; how is having an iso labeled
"Extras-KDE" different from having one additional iso in core that has
the kde packages (I'm not sure if kde fills an entire CD but it'll go
quite some way towards that anyway). In the first case you offer the
user the choice to download it or *not* download it if the user isn't
going to use KDE, in the case of KDE-in-core you force downloading that
same ISO on all users, regardless of whether they will install KDE or
not.
Your argument seems to be "but then I have to download an extra iso"....
well you download that iso anyway, and not just you but everyone else
too.

You're right, the ISO argument is flawed and Rahul pointed this out too.
And that's not really the argument I was trying to make, but I can see
how it comes across like that.

For the record, I have no problem with KDE being on a separate ISO, as
long as the installer gives one the choice of installing from said ISO
at install time. In fact, I think a reorg of the ISOs could be a great
thing.

As I said in the email I just posted, my concern is more of a
maintainership issue of actually officially declaring it an Extras
package. Maybe it's a non-issue, but I still have that concern.

josh

[Rahul Sundaram]

Hi

Post by Arjan van de Ven
Your argument seems to be "but then I have to download an extra iso"....
well you download that iso anyway, and not just you but everyone else
too.

exactly.

Post by Arjan van de Ven
Note to conspiracy theorists: this is NOT a RH official opinion. It's
not even MY opinion per se; it's just food for thought on the "but then
we make people download one more iso" argument which I considered
flawed. There may or may not be other arguments, the discussion is
interesting, but this one I consider mostly a bad argument.

its just sad that developers have to include disclaimers just to add
some random thoughts to this discussion but its good that you clarify
things I guess

[Josh Boyer]

Hi

Putting this back on the list because you make some good points and this
is a good discussion.

Post by Josh Boyer
That's because it's not always a technical issue. It's about choice.
Default does not mean "this has to be installed". It's just a default.
If I don't like the default, I should be given the option of installing
an alternative. And that is without needing to download another large
ISO after the fact because one didn't realize that KDE wasn't included
in Core anymore.

I dont think you read my previous mails completely. Let me explain
this once more
today fedora core is 4+1 cds. if you limit fedora core to the
defaults and have it in 1 or 2 cds, you can have fedora extras or a
subset of it on the rest of the cds. so the totally number of CD's you
have to download as a KDE user still remains the same. Morever by

With you so far, but I have an issue I'll discuss below.

limiting fedora core to the default others who are satisfied with the
defaults and dont want to make choice initially either due to
ignorance or due to lack of knowledge would be happy to stick with
what they get. the rest download what they want and install what they
want from fedora extras and elsewhere
You still have the choice. the choices only increase with the
formation of fedora extras.

If the Core install CDs give you an option to install from the Extras
CDs at _install_ time, and you have the choice to not accept the
default, then I could be OK with that.

However, my main concern with moving KDE to Extras is not ISO
organization. It's more of a maintainership issue. This whole thread
started because some packages were removed from Core, and then the
community found out that quite a few of those packages were orphaned.

KDE is a large package to maintain both because of it's code size and
it's large user base. Someone from the community maybe well be able to
do the job, but right now KDE is released and maintained as a part of
Core. It has a maintainer, it's part of the daily, weekly, whatever
builds and it probably gets at least some QA testing.

I realize that Fedora is officially an unsupported distribution, but the
fact remains that the kind folks at Red Hat still work on this quite a
bit. If it's moved to Extras and needs a new maintainer (which may not
be the case), how quickly will it be picked up? Who knows?

fedora core however has a defined goal. its called "core" for a reason
and all I am asking for is for the fedora project to implement that
goal for FC4. Fedora installer should make it easy for anyone to
install updates or add repositories and manage to have atleast the
same software before the formation of fedora extras

Could you kindly point me to where the "defined goal of including only
defaults" is stated? I can't seem to find it anywhere. In fact, I find
statements all over the Fedora webpage that are contrary to that:

From: http://fedora.redhat.com/about/

"The goal of The Fedora Project is to work with the Linux community to
build a complete, general purpose operating system exclusively from open
source software."

and

"Fedora Core is intended to be a logical upgrade path for previous users
of Red Hat Linux whose needs are consistent with the objectives of the
Fedora Project."

From: http://fedora.redhat.com/about/objectives.html

"Include a range of popular packages, beyond those included in Red Hat's
commercially supported products. (Limited, of course, to packages that
Red Hat can legally provide; also limited to quality packages as defined
by our standards.)"

I see nothing about Core only containing defaults. Maybe I'm missing it
somewhere. Do you have a link to it? I'm not saying it's not a decent
goal to have, but that I just can't find it anywhere.

If all you want is to reorganize the ISOs so that all the default
options can be on 1 or 2 CDs, that's fine with me. As long as the
installer has the option of installing from the "non-default" CDs as
well.

josh

[Rahul Sundaram]

On Sat, 22 Jan 2005 10:23:12 -0600, Josh Boyer

Post by Josh Boyer

Hi

Putting this back on the list because you make some good points and this
is a good discussion.

Ok thanks

Post by Josh Boyer
If the Core install CDs give you an option to install from the Extras
CDs at _install_ time, and you have the choice to not accept the
default, then I could be OK with that.

I would very much want this to be supported in the installer. adding
repositories and selecting packages from the extras and alternatives
repo including the ability to install them from kickstart would
satisfy everyone I believe.

If anyone still has any other problems with fedora core only /only/
the defaults I would like to hear about it

Post by Josh Boyer
However, my main concern with moving KDE to Extras is not ISO
organization. It's more of a maintainership issue.

valid concern. I already answered this one too to a limited extend .
here is a more detailed answer.

You might be well aware that kde-redhat.sf.net project has existed for
quite sometime and is maintained in a active manner. when fedora
extras policy for including packages, redhat or the other members in
the community can ask these people and other upstream KDE developers
to engage themselves with Redhat. one of the previous concerns with
them was that Redhat was making modifications to KDE that was
crippling the user experience for KDE ( I am not making that
accusation. it just already exists). By moving these into extras and
actively inviting the community, it is likely that upstream KDE
developers and others would see this as an oppurtunity to build
packages and provide a better experience for KDE users on fedora.

one of the other benefits of having KDE and other such non default
packages outside fedora core is that the amount of software a typical
end users installs on his/her system is reduced. ideally someone would
step up to make anaconda installer have a minimal setup too. in
essence this improves security and increases maintainability.

Fedora has a stated policy of staying close with upstream. so package
updates dont just include security and bug fixes but also introduces
new features. a typical fedora user usually gigabytes of updates
because there is no easy way to stay conservative and ignore packages
containing new features. I also suggest this capability be introduced
in pup and its command line variants too in FC4.

Post by Josh Boyer
Could you kindly point me to where the "defined goal of including only
defaults" is stated? I can't seem to find it anywhere.

To be honest I did look for this in the website too but couldnt find
it. It seems to be more of a implicit policy from reading through the
previous discussions in this list. feel free to correct me otherwise

[Josh Boyer]

Post by Rahul Sundaram
On Sat, 22 Jan 2005 10:23:12 -0600, Josh Boyer

Post by Josh Boyer
If the Core install CDs give you an option to install from the Extras
CDs at _install_ time, and you have the choice to not accept the
default, then I could be OK with that.

I would very much want this to be supported in the installer. adding
repositories and selecting packages from the extras and alternatives
repo including the ability to install them from kickstart would
satisfy everyone I believe.

Agreed.

Fedora Core and Fedora Extras (maybe even alternatives) could still be
packaged together in a DVD ISO for those that want "one ISO to rule them
all". So maybe given that, we could look at reorganizing the CD ISOs as
you suggested.

Post by Rahul Sundaram

Post by Josh Boyer
However, my main concern with moving KDE to Extras is not ISO
organization. It's more of a maintainership issue.

valid concern. I already answered this one too to a limited extend .
here is a more detailed answer.
You might be well aware that kde-redhat.sf.net project has existed for
quite sometime and is maintained in a active manner. when fedora
extras policy for including packages, redhat or the other members in
the community can ask these people and other upstream KDE developers
to engage themselves with Redhat. one of the previous concerns with
them was that Redhat was making modifications to KDE that was
crippling the user experience for KDE ( I am not making that
accusation. it just already exists). By moving these into extras and
actively inviting the community, it is likely that upstream KDE
developers and others would see this as an oppurtunity to build
packages and provide a better experience for KDE users on fedora.

Hm.. I seemed to have missed where you mentioned the kde-redhat.sf.net
project earlier. That does make me a bit less apprehensive.

I'd still be concerned if KDE was declared as an Extras package, but I
can see some reasoning behind it. Who knows, maybe KDE could be the
"ultimate test" of whether Extras will really work.

Post by Rahul Sundaram
one of the other benefits of having KDE and other such non default
packages outside fedora core is that the amount of software a typical
end users installs on his/her system is reduced. ideally someone would
step up to make anaconda installer have a minimal setup too. in
essence this improves security and increases maintainability.

Agreed.

Post by Rahul Sundaram
Fedora has a stated policy of staying close with upstream. so package
updates dont just include security and bug fixes but also introduces
new features. a typical fedora user usually gigabytes of updates
because there is no easy way to stay conservative and ignore packages
containing new features. I also suggest this capability be introduced
in pup and its command line variants too in FC4.

I personally like the fact that Fedora stays close to upstream. It's
almost necessary given the release cycle that it has. But maybe a
community driven bug-fixes project could fill the gap. Or maybe that's
not realistic. Just theorizing here.

Post by Rahul Sundaram

Post by Josh Boyer
Could you kindly point me to where the "defined goal of including only
defaults" is stated? I can't seem to find it anywhere.

To be honest I did look for this in the website too but couldnt find
it. It seems to be more of a implicit policy from reading through the
previous discussions in this list. feel free to correct me otherwise

No need to correct anyone. It's potentially a good goal. I just
couldn't find it stated anywhere. Apologies if it came off a bit harsh.

josh

[Jeff Pitman]

Post by Josh Boyer
KDE is a large package to maintain both because of it's code size and
it's large user base. ?Someone from the community maybe well be able
to do the job, but right now KDE is released and maintained as a part
of Core. ?It has a maintainer, it's part of the daily, weekly,
whatever builds and it probably gets at least some QA testing.

For what it's worth, I always nuke the KDE packages sent from Core with
the kde-redhat.sf.net packages. I've been an avid KDE user from the
beginning, but still, on occasion use GNOME apps (xchat being the most
used).

I'm not opposed to moving KDE onto another ISO. As a more advanced user
of KDE, I wouldn't be that opposed to just throwing it all out because
I'm just gonna hookup with Rex's packages anyway.

That said, if this is seriously being considered, then I would recommend
that GNOME get fair treatment: put onto its own ISO. Maybe the base
GNOME/Gtk libs to get up2date, anaconda, system-config-*, blah blah
working should be on the first CD. The rest of it (gnobots2, etc.) can
be piled onto another ISO, which one can elect not to install.

Another thing to consider: users with bandwidth. One CD bootstrap,
mainlibs in place, then yum, apt, or smart the rest of it.

have fun,

[Jeff Spaleta]

Post by Jeff Pitman
Another thing to consider: users with bandwidth. One CD bootstrap,
mainlibs in place, then yum, apt, or smart the rest of it.

I think the network install mode of anaconda that is already there
serves a similar enough purpose for anyone who wants to use a network
as part of the install process. And don't forget about the much
maligned mininal install option.

A more advanced one CD bootstrap that gives you a usable desktop is a
tough target to meet. I don't want to see the rescue environment
being ditched to make room for a 1 CD desktop install. I think its
vitally important to keep a usable rescue mode available as part of
every self-contained piece of install media that's going to be
offered.


-jef"the damn weatherman promised me a lull in the snow...wheres my
damn lull..."spaleta

[Sean Middleditch]

Post by Jeff Spaleta
A more advanced one CD bootstrap that gives you a usable desktop is a
tough target to meet. I don't want to see the rescue environment
being ditched to make room for a 1 CD desktop install. I think its
vitally important to keep a usable rescue mode available as part of
every self-contained piece of install media that's going to be
offered.

Not to start a completely different flame war, but... Ubuntu seems to
manage both a single CD install and a usable rescue mode. I have not
actually used Ubuntu, so I don't know exactly *how* usable the rescue
mode is, but the docs indicate it's there and can do a thing or two. ;-)

[Felipe Alfaro Solana]

Post by Sean Middleditch

Post by Jeff Spaleta
A more advanced one CD bootstrap that gives you a usable desktop is a
tough target to meet. I don't want to see the rescue environment
being ditched to make room for a 1 CD desktop install. I think its
vitally important to keep a usable rescue mode available as part of
every self-contained piece of install media that's going to be
offered.

Not to start a completely different flame war, but... Ubuntu seems to
manage both a single CD install and a usable rescue mode. I have not
actually used Ubuntu, so I don't know exactly *how* usable the rescue
mode is, but the docs indicate it's there and can do a thing or two. ;-)

Ubuntu for x86 is two CD's: one is x86 install and the other one is x86
Live CD. I'm not 100% sure, but I think only x86 Live CD can be used as
a rescue CD but x86 install not.

[Sean Middleditch]

Post by Felipe Alfaro Solana
Ubuntu for x86 is two CD's: one is x86 install and the other one is x86
Live CD. I'm not 100% sure, but I think only x86 Live CD can be used as
a rescue CD but x86 install not.

No, I wasn't talking about the Live CD. Further reading indicates that
the rescue mode is only part of the Hoary pre-release CDs, and not part
of the stable Warty release, which is the only CD I have to play with.

That said, I'm pretty sure the secret is to just keep cutting down the
distro enough. Jeff is afraid that a one-CD install disk won't leave
from for a rescue - that would happen only if you can manage to get a
good desktop install into ~650MB but no less. Evidence indicates that
you can in fact get smaller than that with a desktop install.

I suppose one of Ubuntu's tricks is to just not include KDE, though...
(They include it in Universe or Supported, which are similar to Fedora's
Extras, only split between unofficial and official extra packages,
respectively.)

[Jeremy Katz]

Post by Josh Boyer
On a positive note, I'm glad this discussion is taking place. Even if
it's being completely ignored by the Red Hat folks, at least members of
the Fedora community are speaking up. :)

I can pretty safely say it's not being ignored. I'm just trying to
avoid stifling the discussion. Others are probably in a similar boat.

Jeremy

[Josh Boyer]

Post by Jeremy Katz

Post by Josh Boyer
On a positive note, I'm glad this discussion is taking place. Even if
it's being completely ignored by the Red Hat folks, at least members of
the Fedora community are speaking up. :)

I can pretty safely say it's not being ignored. I'm just trying to
avoid stifling the discussion. Others are probably in a similar boat.

Good to know. Thanks :)

josh

[Rahul Sundaram]

Hi

Post by Jeremy Katz
I can pretty safely say it's not being ignored. I'm just trying to
avoid stifling the discussion. Others are probably in a similar boat.

Even if you cannot speak on the behalf of Redhat, I would like to hear
the opinions of the developers working on the fedora project.

[Josh Boyer]

Post by Rahul Sundaram
Hi

Post by Jeremy Katz
I can pretty safely say it's not being ignored. I'm just trying to
avoid stifling the discussion. Others are probably in a similar boat.

Even if you cannot speak on the behalf of Redhat, I would like to hear
the opinions of the developers working on the fedora project.

I agree. A community driven distro should include the ones that spend
the most time on it for sure. :)

josh

[Ralf Corsepius]

Post by Josh Boyer

Post by Rahul Sundaram
Hi

Post by Ralf Corsepius

Post by Rahul Sundaram
no. fvwm2 is not a typical DE.

X+fvwm2 had been the Linux standard desktop environment for many, many
years and is still being used by more folks that you might assume.

its not the default DE nor part of fedora at all now.

No, it's not and I'm not advocating that it should be. It was just a
"devils advocate" type of statement.

Right.

Besides this, those who'll need it will know how to install it.

Post by Josh Boyer

Post by Rahul Sundaram

Post by Ralf Corsepius
Despite some folke here don't seem to get tired to reiterate this idea,
I have to object: That won't be better, It's naive to move KDE out of
Core.

I dont see any technical objections here

That's because it's not always a technical issue. It's about choice.

Partially yes.

But it's also a technical, a management and a political issue.

Whether RH or Gnome folks like it or not, it is a matter of fact that
KDE is a Linux Core technology, which can't be ignored by anybody,
comprising Fedora and RH.

Moving KDE to Extras would mean to close out any KDE application from
Core. From a user's perspective this can't be in anybody's interest.
Technically this would raise a lot of problems, esp. for KDE users (E.g.
there would not be any konqueror, kdm until you get Fedora Extras).

RH wants FE to be the a technology preview platform for their products.
To achieve a better desktop integration they will have to take the lead
in their desktop integration. IMO, until now, they did a pretty good job
on that. Compare RH/Fedora's KDE/Gnome interaction with that of other
distributions, and you'll probably understand what I am referring to.

If RH moves KDE out of Core, this will set a "bad" political signal,
which probably will be interpreted as "RH declaring war on KDE".
This can't be in anybody's interest.

Another aspect I consider to be naive is users believing into the
community being able to provide "better KDE packages" than RH does.
Experience tells, this won't work.

Post by Josh Boyer
Now that's not to say that all the non-base KDE packages have to be
included with Core. I could see having kdegames, kdepim, kdemultimedia,
etc all in Extras. Same goes for the non-base GNOME packages as well.

Fully agreed. One should try to reduce the number of desktop (both KDE
and Gnome) *applications* in Core and move them to Extras.

E.g. I would not be opposed to moving mozilla, thunderbird, evolution,
openoffice, {k,x,g}<sometools> to Extras, but their infrastructure
should remain in Core.

Post by Josh Boyer
If there isn't a desktop environment choice in the Core ISOs, then
people will either deal with it, or switch to a different distro.
Personally, I'd rather see more people come to Fedora.

Exactly. Feeling disattracted from SuSE's Gnome integration was one of
the main reasons, why I decided to switch to using RHL-8.0 after having
used SuSE for ca. 8 years.

Now I don't want to see Fedora falling into the same trap as SuSE did.

Ralf

[Rahul Sundaram]

Hi

Post by Ralf Corsepius
But it's also a technical, a management and a political issue.
Whether RH or Gnome folks like it or not, it is a matter of fact that
KDE is a Linux Core technology, which can't be ignored by anybody,
comprising Fedora and RH.

nobody is proposing to *ignore* KDE. we are talking about moving KDE
into extras. nobody is questioning the importance of KDE nor is
anybody stating that KDE is not good software.

Post by Ralf Corsepius
Moving KDE to Extras would mean to close out any KDE application from
Core. From a user's perspective this can't be in anybody's interest.

its both in the users interest as well as in the interest of fedora
project for having fedora *core* only provide the default stuff

Post by Ralf Corsepius
Technically this would raise a lot of problems, esp. for KDE users (E.g.
there would not be any konqueror, kdm until you get Fedora Extras).

if fedora installer (anaconda) provides a option to install stuff from
extras and if a subset of fedora extras including KDE is provided as
ISO images, would that satisfy you?

Post by Ralf Corsepius
RH wants FE to be the a technology preview platform for their products.
To achieve a better desktop integration they will have to take the lead
in their desktop integration. IMO, until now, they did a pretty good job
on that. Compare RH/Fedora's KDE/Gnome interaction with that of other
distributions, and you'll probably understand what I am referring to.

they also had to suffer a lot of flames for doing this. see
kde-redhat.sf.net for an effort to provide upstream packages removing
the redhat integration bits.

also, one of the integration efforts was moving the gnome panel to the
bottom. this has already been reverted to the upstream default. so
fedora is already moving in the direction of having upstream supply
whatever integration is required. if you are interested then take a
look at freedesktop.org. thats where integration work belongs and
*not* just redhat

Post by Ralf Corsepius
If RH moves KDE out of Core, this will set a "bad" political signal,
which probably will be interpreted as "RH declaring war on KDE".
This can't be in anybody's interest.

you are over dramatising this. again if anaconda and kickstart
provides an easy way to install stuff from fedora extras this point
becomes moot IMO

Post by Ralf Corsepius
Experience tells, this won't work.

why not?.

Post by Ralf Corsepius

Post by Josh Boyer
If there isn't a desktop environment choice in the Core ISOs, then
people will either deal with it, or switch to a different distro.
Personally, I'd rather see more people come to Fedora.

no. they wouldnt switch if making the choice is easy

Post by Ralf Corsepius
Exactly. Feeling disattracted from SuSE's Gnome integration was one of
the main reasons, why I decided to switch to using RHL-8.0 after having
used SuSE for ca. 8 years.

thats because suse allegedly did a poor job. someone else stepped up
to provide upstream gnome packages for GNOME

http://usr-local-bin.org/rpms/usr-local-bin.php

this is similar to the kde-redhat.sf.net effort. so instead of having
two different teams repackaging the same thing, we invite the
kde-redhat.sf.net team and others to step up and maintain the packages
in fedora extras by staying close to upstream

[Rex Dieter]

Post by Rahul Sundaram

Post by Ralf Corsepius
Moving KDE to Extras would mean to close out any KDE application from
Core. From a user's perspective this can't be in anybody's interest.

its both in the users interest as well as in the interest of fedora
project for having fedora *core* only provide the default stuff

Who is saying the the "default stuff" can't include any kde
(or even qt?) applications or integration? Gone will be ooo-kde,
Bluecurve-kde (redhat-artwork), and anything else that uses qt/kdelibs *at
all*.

Post by Rahul Sundaram
they also had to suffer a lot of flames for doing this. see
kde-redhat.sf.net for an effort to provide upstream packages removing
the redhat integration bits.

Correction: kde-redhat is primarily about adding features that redhat
(purposely or not) doesn't include. We're doing our best to get many of
these mods accepted upstream by redhat (see bugzilla.redhat.com's #121769,
#121769, #136533; bugzilla.fedora.us's #1904)

Other goals had included removing the (hard) dependancies on
redhat-artwork and redhat-menus, which could be considerred "removing
redhat integration bits)". These last 2 goals have, for the most part,
been dropped, since
1. it is now pretty much impossible to have a redhat-artwork-free system
(though we still remove the hard
Requires: redhat-artwork
from kdebase, much good that does)
2. redhat-menus has gotten good enough (*), IMO, so providing an
alternative kde-menus isn't worth the extra hassle
(*) except for http://bugzilla.redhat.com/bugzilla/122181

Post by Rahul Sundaram

Post by Ralf Corsepius
If RH moves KDE out of Core, this will set a "bad" political signal,
which probably will be interpreted as "RH declaring war on KDE".
This can't be in anybody's interest.

you are over dramatising this.

IMO, no. The perception from many people will be *exactly* that RH has
declared all-out war on KDE, true or not.

Everyone, please stop the mere suggestion of removing KDE from Core, at
least not in the near future... until there is very tight
integration with Extras. When/If that happens first, only then the
possibility of discussing it is an option.

-- Rex

[Arjan van de Ven]

Post by Rex Dieter
IMO, no. The perception from many people will be *exactly* that RH has
declared all-out war on KDE, true or not.
Everyone, please stop the mere suggestion of removing KDE from Core, at
least not in the near future...

that sounds almost like Fedora is taken hostage...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050123/500b15aa/attachment.bin

[Rex Dieter]

Post by Arjan van de Ven

Post by Rex Dieter
IMO, no. The perception from many people will be *exactly* that RH has
declared all-out war on KDE, true or not.
Everyone, please stop the mere suggestion of removing KDE from Core, at
least not in the near future...

that sounds almost like Fedora is taken hostage...

Huh? You snipped off the part after ... saying "until Fedora Extras is
integrated/ready", does that help?

-- Rex

[Rahul Sundaram]

Hi

Post by Rex Dieter
Huh? You snipped off the part after ... saying "until Fedora Extras is
integrated/ready", does that help?

not really. read my reply

[Rahul Sundaram]

Hi

Post by Rex Dieter
Correction: kde-redhat is primarily about adding features that redhat
(purposely or not) doesn't include.
Other goals had included removing the (hard) dependancies on
redhat-artwork and redhat-menus, which could be considerred "removing
redhat integration bits)".

yes. thats what I was talking about. its not a negative remark on
anyone though. Just emphasising that integration bits are better done
upstream instead of by invidual distributions

Post by Rex Dieter
IMO, no. The perception from many people will be *exactly* that RH has
declared all-out war on KDE, true or not.

I dont think so. it depends on how easy it is to add KDE. has the
perception been that ubuntu has declared war on KDE?.

Post by Rex Dieter
Everyone, please stop the mere suggestion of removing KDE from Core, at
least not in the near future... until there is very tight
integration with Extras.

for your information we are not just discussing moving KDE to extras
but also other packages. we are also discussing how much integration
with extras is necessary and the methodology to do it. so asking
everyone to stop discussing these issues is IMO ill advised

[Rex Dieter]

Post by Rahul Sundaram

Post by Rex Dieter
IMO, no. The perception from many people will be *exactly* that RH has
declared all-out war on KDE, true or not.

I dont think so. it depends on how easy it is to add KDE. has the
perception been that ubuntu has declared war on KDE?.

ubuntu != redhat, nor does it have a history. Apples/Oranges.

Post by Rahul Sundaram

Post by Rex Dieter
Everyone, please stop the mere suggestion of removing KDE from Core, at
least not in the near future... until there is very tight
integration with Extras.

for your information we are not just discussing moving KDE to extras
but also other packages. we are also discussing how much integration
with extras is necessary and the methodology to do it. so asking
everyone to stop discussing these issues is IMO ill advised

I didn't say stop discussing integration with extras, did I? If I even
implied that, I apologize. Please, please keep that part of the
discussion going.

-- Rex

[Rahul Sundaram]

Hi

Post by Sean Middleditch
GNOME is the default desktop, so of course it shouldn't be removed. I'm
wary of moving KDE due to the political issues, but I wouldn't mind
seeing all the other WMs and DEs moved (XFCE, for one).

political reasons are there for xfce and even for the argument of
including something like fluxbox in core. you need clear technical
arguments to retain packages in core. there are some hard decisions to
be made

fedora core has a defined goal of including only defaults and moving
the rest of the stuff to extras and alternatives.

[Kyrre Ness Sjobak]

Post by Rahul Sundaram
http://www.gnome.org/projects/evince/
(FC RPMs available at that site)

Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3.
Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6,
but fc3 only has 2.4 ...

[Jeff Spaleta]

On Sat, 22 Jan 2005 01:41:28 +0100, Kyrre Ness Sjobak

Post by Kyrre Ness Sjobak

Post by Rahul Sundaram
http://www.gnome.org/projects/evince/
(FC RPMs available at that site)

Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3.
Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6,
but fc3 only has 2.4 ...

it works once you get the rawhide gtk2 installed on your system....
and since this is a discussion about the development tree.... that
requirement seems appropriate to me.


-jef

[Jeremy Katz]

Post by Kyrre Ness Sjobak

Post by Rahul Sundaram
http://www.gnome.org/projects/evince/
(FC RPMs available at that site)

Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3.
Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6,
but fc3 only has 2.4 ...

They require gtk+ 2.6. evince is taking advantage of some of the new
functionality provided. And as Jef says, this _is_ the development
list. :-)

Jeremy

[Jeff Spaleta]

Post by Dan Williams
Furthermore, these are really just leaving Fedora Core, but should still
be in Fedora Extras AFAIK.

This is entirely unclear to anyone sitting outside the Red Hat
fenceline. I have no idea if the people who maintain something inside
Core will continue to be required to maintain or volunteer to maintain
the package as part of Extras. I fully expect some packages will have
to change maintainers as part of moving to Extras.

If i had the luxury to demand one thing from Red Hat package
maintainers I would demand to know if for each dropped package out of
Core if the Red Hat maintainer who was maintaining it inside Core is
going to continue maintain it as part of Extras of if a community
member needs to be found to maintain the dropped packages. It is
totally unclear from my perspective whether or not dropped from Core
means the original Core maintainer is no longer going to be the person
maintaining it in Extras.

For every package dropped from Core from now on... i want to know if
its being orphaned by the maintainer and if a new maintainer needs to
be found. And i want to know it ASAP. I want the list of orphaned
packages consolidated into a webpage so that its easily
cross-referenced when questions about why it was totally dropped come
up. As soon as Red Hat makes the decision to drop a package from Core
and its decided if the original Core maintainer is not going to
maintain it as part of Extras.. the community needs to be told.. so
the community can determine a new maintainer and start the
indoctrination of a new maintainer if the person who steps up is a
packaging novice.

For orphaned packages that the original Core maintainer is no longer
going to maintain as part of Extras.. The ealier the community knows
its orphaned... the less time it will be unavailable if a new packager
is the one who steps up out of the community and volunteers to
maintain it. I'm not asking for a garuntee that the package will
always be available. But I am asking that the community be given as
much lead time as possible to start the process of selecting a new
maintainer.

If ANY of these packages are not going to be maintained by the
original Core maintainers as part of Extras... tell the community NOW
so that someone can step up and offer to maintain it.

-jef"Don't make me read your minds... my brain wave laser tends to
cause dandruff"spaleta

[Bill Nottingham]

Post by Jeff Spaleta
If ANY of these packages are not going to be maintained by the
original Core maintainers as part of Extras... tell the community NOW
so that someone can step up and offer to maintain it.

You're absolutely correct. This is how it stands, AFAIK:

Orphaned:
- aumix
- balsa/libesmtp (really, they go together)
- cdp
- comsat
- grip
- gv
- pdksh (then again, it's getting replaced by ksh)
- sylpheed
- xosview
- xsnow
- ytalk

Not sure:
- diskcheck
- freeciv
- gnuchess
- pan
- xboard

Bill

[Jeff Spaleta]

you have fedoraproject.org wiki write access right? right? hint hint

-jef"sharpens his eye-poking stick because its become blunt with over
use"spaleta

[Chris Adams]

- pan

Pan is still in rawhide; I take it it won't be for long? What are we
supposed to use instead of pan? Last time I tried to load a large
binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up
solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I
tried)?

[Bill Nottingham]

Post by Chris Adams

- pan

Pan is still in rawhide; I take it it won't be for long? What are we
supposed to use instead of pan? Last time I tried to load a large
binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up
solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I
tried)?

It's entirely possible I mistyped. But I believe Thunderbird and
Evolution both read news.

Bill

[Dave Jones]

Post by Bill Nottingham

Post by Chris Adams
Pan is still in rawhide; I take it it won't be for long? What are we
supposed to use instead of pan? Last time I tried to load a large
binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up
solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I
tried)?

It's entirely possible I mistyped. But I believe Thunderbird and
Evolution both read news.

Evolution and Thunderbird are also utterly unusable on a machine
with < 256MB, and a slow CPU in my experience, whereas pan seemed
very capable of running comfortably in 128MB.

Dave

[Alan Cox]

Post by Bill Nottingham

Post by Chris Adams
supposed to use instead of pan? Last time I tried to load a large
binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up
solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I
tried)?

It's entirely possible I mistyped. But I believe Thunderbird and
Evolution both read news.

In the same was as "ed" means we don't need to ship an editor IMHO.

Alan

[Farkas Levente]

Post by Bill Nottingham

Post by Jeff Spaleta
If ANY of these packages are not going to be maintained by the
original Core maintainers as part of Extras... tell the community NOW
so that someone can step up and offer to maintain it.

- diskcheck

is there anything which can be used in stead of diskcheck?

[Paul Ionescu]

Hi,

Post by Bill Nottingham

If ANY of these packages are not going to be maintained by the original
Core maintainers as part of Extras... tell the community NOW so that
someone can step up and offer to maintain it.

- diskcheck
- freeciv
- gnuchess
- pan
- xboard

I am using right now PAN to send this message.
Not because I don't want to use something else, but because other news
programs don't have the functionality of pan yet.
And is fast too, compared with other options.

Thx,
Paul

[Hans de Goede]

Post by Paul Ionescu
Hi,
I am using right now PAN to send this message.
Not because I don't want to use something else, but because other news
programs don't have the functionality of pan yet.
And is fast too, compared with other options.
Thx,
Paul

I would like to give a vote for keeping pan in core too, and while we're
at it make it the default news program. pan is the best gui newsreader
for unix, so it deserves to be the default and its gnome, so it fits
well with Fedora's default desktop.

Regards,

Hans

[Nicolas Mailhot]

Post by Hans de Goede

Post by Paul Ionescu
Hi,
I am using right now PAN to send this message.
Not because I don't want to use something else, but because other news
programs don't have the functionality of pan yet.
And is fast too, compared with other options.
Thx,
Paul

I would like to give a vote for keeping pan in core too, and while we're
at it make it the default news program. pan is the best gui newsreader
for unix, so it deserves to be the default and its gnome, so it fits
well with Fedora's default desktop.

+1

Pan was a great app before those alternatives, was one of the first apps
to use GTK2, and is generally great (not that it wouldn't need some UI
love now)
--
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050123/8f411bb1/attachment.bin

[Alan Cox]

Post by Bill Nottingham
- balsa/libesmtp (really, they go together)
- sylpheed

One of these - IMHO sylpheed or slypheed+claws should stay IFF we keep XFCE
in the base distro. The other gui mailers are unusable on low end machines.
If XFCE also goes to extras (sensible perhaps) then fine.

Post by Bill Nottingham
- freeciv
- gnuchess
- xboard

I'd like to see some newer / better games picked up. Another question for
FC4 maybe "bzflag or bzflag2"

Alan

[Michael Schwendt]

Post by Alan Cox

Post by Bill Nottingham
- balsa/libesmtp (really, they go together)
- sylpheed

One of these - IMHO sylpheed or slypheed+claws should stay IFF we keep XFCE
in the base distro. The other gui mailers are unusable on low end machines.
If XFCE also goes to extras (sensible perhaps) then fine.

Both Sylpheed and Sylpheed-claws are crippled if built without GPGME
support.

[Dan Williams]

Post by Jeff Spaleta

Post by Dan Williams
Furthermore, these are really just leaving Fedora Core, but should still
be in Fedora Extras AFAIK.

This is entirely unclear to anyone sitting outside the Red Hat
fenceline. I have no idea if the people who maintain something inside
Core will continue to be required to maintain or volunteer to maintain
the package as part of Extras. I fully expect some packages will have
to change maintainers as part of moving to Extras.

I currently own 'gv', and I don't particularly want to maintain it outside
of Fedora Core. Somebody who knows, likes, and uses gv would be a much
better person for the job, since I also own a bunch of other packages,
some quite large (openoffice.org). If some other person was able to focus
their time on gv, I think that would be a win for users of the package.

This however is my opinion, and isn't necessarily indicative of how
changes to the gv package will play out.

Dan

[Havoc Pennington]

Doesn't debian have some type of "orphaned package" process? We should
have a look at that.

Havoc

[Jeff Spaleta]

Post by Havoc Pennington
Doesn't debian have some type of "orphaned package" process? We should
have a look at that.

debian also has longer timescales between releases....

I'm somewhat concerned about when in the development process Red Hat
makes decisions as to what gets orphaned and whether or not there is
going to be enough time for new community members step up, jump
through whatever legal hoops are in place around Extras, earn access
to the build system and produce an Extras package before the next Core
release. I'd personal rather not have any packages orphaned by Red
Hat maintainers until Extras policy is flushed out. I have a twisted
dark malevolent desire to force Red Hat developers to maintain the the
packages dropped from Core this time around in Extras, as an
experimental group for the Extras process.

I'd really like to have a process with enough lead time so that when
the community learns a package is to be orphaned there is a reasonable
chance that a community member can get a package into Extras before
the next Core is released. While we surely can not gartunee that an
orphaned package will be available in time as an Extras for the next
Core.. i'd hate to see a process where the timescales were such that
we could garunteed that an orphaned package would never be ready in
time. I'd like to make sure that a good-faith effort by a proactive
community member will be rewarded with a package in Extras by the next
Core release.

-jef

[Michael Schwendt]

Post by Enrico Scholz

Post by Build System
Removed package gnuchess
Removed package freeciv
Removed package ytalk
Removed package sylpheed
Removed package aumix
Removed package xboard
Removed package balsa
Removed package grip
Removed package libesmtp
Removed package gv

??? I hope that some of these removals happened just because of temporary
issues. I understand that things like sylpheed or balsa can disappear as
there are enough alternatives.

And Fedora Extras. Sylpheed in Extras could be built with GPGME
support finally as long as GPGME is not part of Core. I'd love to see
that. My old sylpheed-gpg package in fedora.us didn't make it because
it would conflict with Core's sylpheed.

Post by Enrico Scholz
But e.g. viewing postscript files is a
common task and I do not know a program which can replace 'gv'. And games
like 'gnuchess' or 'freeciv' are classics which should not be missed on
any system.

Bigger games should all be moved into Extras. A game like Freeciv should
not be included with a core operating system, IMHO.