That section is new in the forums, and maybe the permissions are not ok or something. I already notified Thomas Adam about that issue. Hopefully it can be fixed soon enough. However, if you want to take a look to the Thomas Adam's patches, you can also take a look at them here:

That patch is included into my patchset, unchanged. The muticoloured borders patch, from Thomas Adam, is also in my patchset, but was modified by me, so, if it screws up in some funny way, don't report the problem to Thomas Adam. The patchset can be found in my site, as always:

From what I see, the souruce compiles nicely, but file fvwm.1 is missing in
/v/tmp/portage/x11-wm/fvwm-live-0.1-r16/image/usr/share/man/man1/directory(there is only fvwm2.1 softlink to the non-existent fvwm.1 file)

I;ve been tryin to emerge last r16 from layman live-ebuild overlay. I'm getting the following error output:

[...]

From what I see, the souruce compiles nicely, but file fvwm.1 is missing in
/v/tmp/portage/x11-wm/fvwm-live-0.1-r16/image/usr/share/man/man1/directory(there is only fvwm2.1 softlink to the non-existent fvwm.1 file)

They are doing a lot of changes related to the documentation in the last few weeks, overall, aimed to get rid of some build dependencies and some funky stuff that's been around for quite some time. So, at times, that part of the cvs might be broken. I don't really know if that's what happened. Just try to re-emerge again and see if some files are updated from cvs. If not, then stop the merge and erase /usr/portage/distfiles/cvs-src/fvwm/, maybe there is something broken in your local copy.

Then emerge again. If the error continues then we will look into it. Right now I can't reproduce it._________________Gentoo Handbook | My website

Lately, the fvwm-workers list has been a bit busy. Today they released 2.5.22 at last. So, if you re-emerge the CVS ebuild you will from now on get version 2.5.23. The .22 release should in short be packaged and available for download from the fvwm home page. I just wanted to drop a note here about it. I think it is a good moment to re-emerge your fvwm builds and get the latest bugfixes.

I just uploaded r16 to the live-ebuilds svn repository. A new patch from Thomas Adam was added:

It's now part of the just-released FVWM 2.5.23 version, so you'll have to remove it from your patchset.

-- Thomas Adam

Yep. I have been waiting for this, since I was seeking the debate about your patch in the fvwm workers list. I knew it was a matter of a few hours. So I had it prepared. I just arrived home and saw it has already been done, so I submitted it to the live-ebuilds overlay svn repository, with a couple of minor fixes about naming of the files. Your patch has been removed from the new patchset since it is already in the fvwm cvs branch.

For everyone, if you want to get 2.5.23, as Thomas Adam kindly pointed out, you are going to have a problem with previous patchsets. So, upgrade to -r17. You first need to sync with "layman -s live-ebuilds" or simply "layman -S".

If someone wants an ebuild in the old format, let me know. For now, I just submited it into live-ebuilds.

Thanks, Thomas Adam, and the rest

EDIT, Bumped to r18. My patch for new test conditions has been removed as well. I don't use anymore, and the last updates broke it. In case anyone is interested, let me know and I will possibly fix it. But if no one is using it, I will simply drop it, since it is no longer of any use for me._________________Gentoo Handbook | My website

Several fixes on the ebuild have been commited to the live-ebuilds overlay while the forum update was taking place. Current is now -r21. Just ebuild stuff like flags, deps and so on. The png and doc flags (that were broken) now actually do something. The xlock patch is just a distro specific patch, so I enabled it unconditionally and removed the flag (it is a trivial patch)._________________Gentoo Handbook | My website

I'll drop this from berkano overlay then, as it's available in live-ebuilds overlay._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

It's been some time since the last update, but nothing was needed during all this time.

Lately there's been some talk on the lists about the locale chartset issue (a thing that has been there since I can remember). That was why the default charset patch was needed. Yes, you read ok: "was". That has been finally addressed by a patch from Olivier Chapuis. I have just updated and uploaded an updated abuild to live-ebuilds right now.

The default-charset (or whatever it was called) used flag, has been removed, since it is no longer required. The ebuild has been corrected. The patch is still in the patchset, in case someone wants it for some odd reason, it will be removed soon, but I am too lazy and don't want to package a new patchset right now.

I just updated fvwm with this ebuild. It break fvwm-crystal. I also think that /etc/X11/Sessions/fvwm2 will not work anymore. The problem is that /usr/bin/fvwm2 is not installed.

The solution for me was to make a symlink /usr/bin/fvwm2 -> /usr/bin/fvwm._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I just updated fvwm with this ebuild. It break fvwm-crystal. I also think that /etc/X11/Sessions/fvwm2 will not work anymore. The problem is that /usr/bin/fvwm2 is not installed.

The solution for me was to make a symlink /usr/bin/fvwm2 -> /usr/bin/fvwm.

FVWM dropped the fvwm2 naming convention of its binaries ages ago. FVWM-Crystal should need only ever look for the presence of the fvwm binary -- *especially* since it is tracking 2.5.X which follows this naming convention anyway.

I just updated fvwm with this ebuild. It break fvwm-crystal. I also think that /etc/X11/Sessions/fvwm2 will not work anymore. The problem is that /usr/bin/fvwm2 is not installed.

The solution for me was to make a symlink /usr/bin/fvwm2 -> /usr/bin/fvwm.

FVWM dropped the fvwm2 naming convention of its binaries ages ago. FVWM-Crystal should need only ever look for the presence of the fvwm binary -- *especially* since it is tracking 2.5.X which follows this naming convention anyway.

-- Thomas Adam

Thank you Thomas for the explanation. The problem here is that gentoo is still using the old naming convention in official portage. So are the official fvwm and fvwm-crystal ebuilds.

Another problem is in the live ebuild: it generate /etc/X11/Sessions/fvwm2 which use /usr/bin/fvwm2 instead of /usr/bin/fvwm._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I could fix it. But since the ebuild does nothing special. I think that this belongs upstream. It's nothing specific to the ebuild itself.

Into src_install():

Code:

echo "#!/bin/bash" > fvwm2
echo "exec /usr/bin/fvwm2" >> fvwm2

exeinto /etc/X11/Sessions
doexe fvwm2

That implies that this is the ebuild that create and install /etc/X11/Sessions/fvvwm2.
A problem is that fvwm exist in ${S}. This is a directory. The following code will work into the ebuild:

Code:

echo "#!/bin/bash" > fvwm/fvwm
echo "exec /usr/bin/fvwm" >> fvwm/fvwm

exeinto /etc/X11/Sessions
doexe fvwm/fvwm

The compilation create fvwm and the ebuild install it in /usr/bin/fvwm. It is no /usr/bin/fvwm2. And that is 100% correct.
A workaround would be to create a symlink /usr/bin/fvwm2 to /usr/bin/fvwm. But it is much better to fix things as to make a workaround.

This fix will break fvwm-crystal. I just checked it, and this is the file in ${FILESDIR} that still use fvwm2. So, portage issue._________________[[[ To any NSA and FBI agents reading that text: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

===================================
missing header for unified diff at line 5 of patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: fvwm/menuitem.c
|===================================================================
|--- fvwm/menuitem.c (revision 4)
|+++ fvwm/menuitem.c (revision 5)
--------------------------
No file to patch. Skipping patch.
6 out of 6 hunks ignored
missing header for unified diff at line 83 of patch
can't find file to patch at input line 83
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: fvwm/menustyle.c
|===================================================================
|--- fvwm/menustyle.c (revision 4)
|+++ fvwm/menustyle.c (revision 5)
--------------------------
No file to patch. Skipping patch.
4 out of 4 hunks ignored
missing header for unified diff at line 125 of patch
can't find file to patch at input line 125
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: fvwm/menus.c
|===================================================================
|--- fvwm/menus.c (revision 4)
|+++ fvwm/menus.c (revision 5)
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
missing header for unified diff at line 140 of patch
can't find file to patch at input line 140
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: fvwm/menustyle.h
|===================================================================
|--- fvwm/menustyle.h (revision 4)
|+++ fvwm/menustyle.h (revision 5)
--------------------------
No file to patch. Skipping patch.
2 out of 2 hunks ignored
===================================

The ebuild has been remade. Since I am now the proxy maintainer for the official portage ebuild, I am porting all the stuff of what will basically be the new ebuild for fvwm in the official portage, to this cvs ebuild.

Some patches have been broken by the VerticalSeparators patch that I made, which has been merged into the official fvwm branch as of 2.5.26, which is the current version of fvwm. I have been busy these last weeks, but I haven't fogotten about this ebuild

Someone in the fvwm forums pm'ed me with a fixed patchset, I haven't done any tests, but I have updated the devnull repository with the new ebuild. You can update it via layman right now. It's completelly untested stuff right now, so, I will make many more commits this evening probably. If you are around, feel free to test it and see if it works or not. It will surely need some polishing.

Cheers, fvwmers

EDITED: Right now, all the patches seem to apply cleanly and the new ebuild seems to work.

I wish also to give credit to:

- David Shakaryan (I hope I spelled it correctly) for giving this ebuild some attention and recruiting me as proxy maintainer
- Warnaud fro the fvwm forums, for the fixed patchset
- Dominik Vogt and Thomas Adam, for helping me to fix some dependency issues and some doubts about gtk and perl in the fvwm-workers mailing list
- The unknown person who did the original patchset
- Tavis Ormandi, because the original ebuilds were from him, as far as I know.
- And of course, to all of you for using this thing and helping to improve it everyday