|
Home > Archive > Debian Developers > March 2004 > New NMU of fvwm to experimental
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
New NMU of fvwm to experimental
|
|
| Manoj Srivastava 2004-03-11, 11:34 pm |
| Hi,
The development branch of fvwm is nearing a stable release,
and has had a huge number of new features. The 2.5.8 release is
deemed quite stable; there is a new 2.5.9 release.
The maintainer has been very reluctant to package this branch, even
in a people.debian.org repository, so I decided to package FVWM 2.5.8
for myself; and I have decided to share this with others as well. The
packages are lintian clean, and can be found in Experimental.
There have been significant new features in the 2.5.X series,
and just the GNOME 2 compatibility should be enough to require this
in Sarge.
Also, our packaging, even that of 2.5.6 on people.debian.org
private repository for fvwm, is horribly ancient and outdated, and
upstream is not happy at the "bit rot" in the debian versions. For
example, shipping a systemwide fvwmrc masks the automatic
configurator that otherwise pops up for new users.
These are quotes from the fvwm mailing lists.
> You are welcome to send patches that improve the deb package we
> provide. However if you speak about hooks and other ancient things,
> I see them as a clear deterioration. This will not be applied. The
> configuration in your patch are so ancient (from 5-7 years ago?)
> that it makes no sence to start to fix it. It should be dropped. We
> already provide 2 sets of configurations for a user without any
> fvwm2rc. Maintaining more configurations that are also distribution
> specific is meaningless.
> fvwm is best to be run without any system wide fvwmrc, especially
> the one written 5-7 years ago. The users then gets a menu and a
> choice to setup 2 configurations we maintain. There is also the
> third choice, fvwm-themes.
They have a point; there is a new mechanism in FVWM that
generates a configuration file for a new user if none exists; and
this config is better than the one we ship. Indeed, our packaging is
outdated, and shadows neat new features in the fvwm install, making
the experience for Debian users significantly worse.
> As an example I agree with Mikhael that there shouldn't be a system-wide
> default fvwm config: Dan's excellent work to bring up a configurator for
> new FVWM users shouldn't be hidden by years-old crusty configuration
> files.
I have fixed this as well in the packaging.
These packages were configured as follows (I see no reason not
to allow rplay and xrender compatibility in fvwm). As you can see
below, I have included as many of the features as I could.
The fvwm project also supplies .deb files, but there are no
.dsc files, or debian diffs available, and there were numerous
lintian warnings. I fixed a few errors, and brought the packaging in
compliance with Debian policy. I note that the packages provided do
not integrate well into Debian's menu system, nor do they integrate
with the alternatives system.
I would be happy to co-maintain this package, or take it over
if you prefer. Upstream seems to be willing to cooperate in bringing
the official Debian packages up to speed (they are shipping a non
policy compliant .deb themselves at this point; I think this is bad
for our users. If this is not possible, I am going to create a
fvwm2.5 package, and fork maintainence.
I am uploading my packages to experimental, so people may test
it.
manoj
========================================
==============================
These packages were configured as follows (I see no reason not
to allow rplay and xrender compatibility in fvwm). Even though
gdk-imlib1-dev is in the build-depends, the configuration fails to
configure it in; I'll look into this in the future.
../configure --verbose --prefix=/usr --build i386-linux --host i386-linux \
--sysconfdir=/etc/X11/fvwm --libexecdir=/usr/lib \
--mandir=/usr/share/man --with-stroke-library
FVWM Configuration:
Version: 2.5.8
Executables: /usr/bin
Man pages: /usr/share/man
Modules: /usr/lib/fvwm/2.5.8
Data files: /usr/share/fvwm
Perl lib: /usr/share/fvwm/perllib
Locale msg: /usr/share/locale ar de fr sv_SE
With Asian bi-direct. text support? yes
With Gettext Native Lang Support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? no: Failed on gdk-imlib, see config.log
With GNOME libs support in FvwmGtk? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent? yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support? yes
With Mouse strokes (gestures)? yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
See INSTALL.fvwm for the description of what this may mean.
========================================
==============================
fvwm is a powerful window manager. Version 2.5.8 is an unstable
release that includes improvements over unstable 2.5.7 and stable
2.4.17 versions. You are welcome to upgrade and test the new
features or help stabilizing the code. Please be aware that any
features introduced in the 2.5.x development versions may be
renamed, changed or removed without notice before 2.6.0.
This release is available at the home page: http://www.fvwm.org/.
We are 10 years old now as of July 2003!
Improvements:
-------------
* The Break command can be told the number of nested function
levels to break out of. Break now has a return code of -2
("Break").
* New extended variable $[func.context].
* Directions can be abbreviated with -, _, [, ], <, >, v or ^ like
in key or mouse bindings.
* fvwm now handles what Unicode calls "combining characters" (i.e.
marks drawn on top of other characters).
* FvwmAnimate now supports dynamical commands "pause", "play",
"push", "pop" and "reset" to manipulate the playing state.
New features:
-------------
* New commands WindowStyle and DestroyWindowStyle for individual
(per window) styles.
* fvwm supports tear off menus. See the "Tear Off Menus" section
in the man page or press Backspace on any menu to try them out.
* New Style option MoveByProgramMethod. Tries to autodetect
whether application windows are moved honouring the ICCCM or not
(default). The method can be overridden manually if the
detection does not work.
* New prefix command KeepRc.
* Renamed the Cond command to TestRc, and the On command to Test.
Removed the CondCase command. Use "KeepRc TestRc" instead.
--------------
* Added a nice autohide script to the FAQ.
Bug Fixes:
----------
* The conditions !Current... and !Layer now work as expected.
See ChangeLog and NEWS (the 2.4.x section) files for all details.
--
Once, when the secrets of science were the jealously guarded property
of a small priesthood, the common man had no hope of mastering their
arcane complexities. Years of study in musty classrooms were
prerequisite to obtaining even a dim, incoherent knowledge of
science. Today all that has changed: a dim, incoherent knowledge of
science is available to anyone. Tom Weller, "Science Made Stupid"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2004-03-12, 1:34 am |
| hi manoj,
On Thu, Mar 11, 2004 at 06:49:34PM -0600, Manoj Srivastava wrote:[color=darkred]
> They have a point; there is a new mechanism in FVWM that
> generates a configuration file for a new user if none exists; and
> this config is better than the one we ship. Indeed, our packaging is
> outdated, and shadows neat new features in the fvwm install, making
> the experience for Debian users significantly worse.
>
if we dropped the system-wide configuration file, would it still be
possible to include the debian programs menu?
sean
| |
| Manoj Srivastava 2004-03-13, 3:33 am |
| On Fri, 12 Mar 2004 00:45:01 -0500, sean finney <seanius@seanius.net> said:
> hi manoj,
> On Thu, Mar 11, 2004 at 06:49:34PM -0600, Manoj Srivastava wrote:
[color=darkred]
> if we dropped the system-wide configuration file, would it still be
> possible to include the debian programs menu?
The integration with the menu system is not lost. You may
still have the Debian menu -- and I'll include instructions
prominently in the documentation. I'll see what can be done about
including the menu system in the automatic configuration system.
manoj
--
"The filter has discreting sources." KSC FIDO, 1/28/86
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| sean finney 2004-03-13, 1:34 pm |
| hi manoj,
On Sat, Mar 13, 2004 at 01:13:18AM -0600, Manoj Srivastava wrote:
> The integration with the menu system is not lost. You may
> still have the Debian menu -- and I'll include instructions
> prominently in the documentation. I'll see what can be done about
> including the menu system in the automatic configuration system.
cool. i think the important thing is that the menu is there by
default--i've always found debian's cross-wm handling of program menus
as one of the really neat features of debian on the desktop. it'd be
a shame to see that disappear in my favorite window manager.
you could always instruct the user to go to /usr/share/doc, which
would work for workstations where the administrator is the primary
user, but i could see this being rather annoying if you had a lab
or public area type environment, where you don't want to require the
users to have to do anything (sure, you'd probably give these kind of
users kde in the first place, but...)
if it proves to be impossible to get both, perhaps there could be a
debconf question for whether or not to install a site-wide fvwm2rc,
explaining the pros and cons of each?
sean
|
|
|
|
|