Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 191638 - x11-wm/fvwm-2.5.25 (version bump + improved ebuild)
Summary: x11-wm/fvwm-2.5.25 (version bump + improved ebuild)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Desktop WM Team (OBSOLETE)
URL:
Whiteboard:
Keywords:
: 190791 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-09-07 23:52 UTC by Jesús Guerrero Botella (RETIRED)
Modified: 2008-05-04 08:45 UTC (History)
12 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Ebuild (fvwm-2.5.23.ebuild,5.57 KB, text/plain)
2007-09-07 23:57 UTC, Jesús Guerrero Botella (RETIRED)
Details
DefaultCharset.patch (DefaultCharset.patch,323 bytes, patch)
2007-09-07 23:58 UTC, Jesús Guerrero Botella (RETIRED)
Details | Diff
fvwm-menu-xlock-xlockmore-compat.patch (fvwm-menu-xlock-xlockmore-compat.patch,550 bytes, patch)
2007-09-07 23:58 UTC, Jesús Guerrero Botella (RETIRED)
Details | Diff
translucent menus patch (fvwm-translucent-menus.patch,15.40 KB, patch)
2007-09-07 23:58 UTC, Jesús Guerrero Botella (RETIRED)
Details | Diff
README.translucency (README.translucency,8.70 KB, text/plain)
2007-09-07 23:58 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.23.ebuild (revised) (fvwm-2.5.23.ebuild,5.33 KB, text/plain)
2007-09-08 02:12 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.23-translucent-menus.diff (fvwm-2.5.23-translucent-menus.diff,15.40 KB, patch)
2007-09-08 02:13 UTC, Jesús Guerrero Botella (RETIRED)
Details | Diff
fvwm-2.5.23.ebuild (fvwm-2.5.23.ebuild,5.35 KB, text/plain)
2007-09-09 15:00 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.23.ebuild (fvwm-2.5.23.ebuild,5.09 KB, text/plain)
2007-09-10 14:34 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.23.ebuild (fvwm-2.5.23.ebuild,5.09 KB, text/plain)
2007-09-13 12:51 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.24.ebuild (fvwm-2.5.24.ebuild,5.01 KB, text/plain)
2007-12-18 09:28 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.24.ebuild (attachment.cgi?id=138805,4.94 KB, text/plain)
2008-01-26 15:49 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.24.ebuild (fvwm-2.5.24.ebuild,5.18 KB, text/plain)
2008-01-29 13:33 UTC, Jesús Guerrero Botella (RETIRED)
Details
charset.patch (charset.patch,4.33 KB, text/plain)
2008-01-29 13:34 UTC, Jesús Guerrero Botella (RETIRED)
Details
fvwm-2.5.25.ebuild (fvwm-2.5.25.ebuild,4.95 KB, text/plain)
2008-02-27 03:03 UTC, Jesús Guerrero Botella (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:52:20 UTC
An "improved" ebuild for fvwm-2.5.23. The improvements are these:

USE flags added:
  xpm, to enable/disable xpm support
  svg, to enable/disable linking againts librsvg
  translucency, (taviso's transparent menus now optional)
    (Patch attached).
  default-charset-fix, solves the problem with strange
    characters for non-english, I can't explain how this work
    since I have not been able nor have had the time to understand
    how it works. (Patch attached)
  doc, enables/disables creation of the new html docs
  session, enables/disables session management support
  shape, enables/disables support for the xshape extension
  xlockcompat, a compatibility patch for xlock

And that's all. Besides that, the only new thing in the ebuild is the version bump to the latest fvwm version: 2.5.23.


Reproducible: Always
Comment 1 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:57:07 UTC
Created attachment 130293 [details]
Ebuild
Comment 2 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:58:07 UTC
Created attachment 130295 [details, diff]
DefaultCharset.patch
Comment 3 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:58:22 UTC
Created attachment 130296 [details, diff]
fvwm-menu-xlock-xlockmore-compat.patch
Comment 4 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:58:37 UTC
Created attachment 130297 [details, diff]
translucent menus patch
Comment 5 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-07 23:58:57 UTC
Created attachment 130298 [details]
README.translucency
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-09-08 00:02:43 UTC
*** Bug 190791 has been marked as a duplicate of this bug. ***
Comment 7 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-08 02:12:32 UTC
Created attachment 130306 [details]
fvwm-2.5.23.ebuild (revised)

I submitted the wrong ebuild the first time
Comment 8 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-08 02:13:16 UTC
Created attachment 130307 [details, diff]
fvwm-2.5.23-translucent-menus.diff
Comment 9 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-08 02:14:33 UTC
Comment on attachment 130298 [details]
README.translucency

fixed typo in filename
Comment 10 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-08 02:15:05 UTC
Comment on attachment 130296 [details, diff]
fvwm-menu-xlock-xlockmore-compat.patch

xlock compatibility patch
Comment 11 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-08 02:15:39 UTC
Comment on attachment 130295 [details, diff]
DefaultCharset.patch

charset fix patch
Comment 12 srrijkers 2007-09-09 14:26:56 UTC
(In reply to comment #7)
> Created an attachment (id=130306) [edit]

Your ebuild is missing a conditional dependency on librsvg for USE="svg"
Comment 13 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-09 15:00:32 UTC
Created attachment 130418 [details]
fvwm-2.5.23.ebuild

fixed dep on libsrvg when USE="svg"
Comment 14 srrijkers 2007-09-09 22:31:31 UTC
A couple of further notes:
1) the ebuild for fvwm-2.5.21 has an error in its configure section; see bug 191914. Your ebuild makes the same mistake.
2) --enable-doc doesn't do anything; it should be --enable-htmldoc instead for building the html documentation. If this flag is set there should be an additional build-time DEPEND on dev-libs/libxslt. To be honest, I don't know the slightest thing about building documentation, so it could very well be that the ebuild would need additional docbook DEPENDS in this case as well.
3) instead of introducing a separate USE-flag for every single possible patch, it would be *much* better form to introduce a "vanilla" USE flag instead. On the other hand, it could just as well be omitted like it has always been. It makes no sense to disable the xlockmore patch for instance. Likewise, it would make no sense to disable the DefaultCharset patch since it seems to simply fix a UTF8 bug in fvwm (http://www.fvwm.org/cgi-bin/fvwm-bug/incoming?id=1647).
4) most of the USE-flags you introduce seem pretty senseless to me. They control pretty small and non-intrusive parts of the package build; besides, all of their dependencies seem to be installed by xorg-x11 anyway. It is not very 'pretty' to introduce a big load of local USE flags which offer few, if any, benefits to the user.
Comment 15 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-09 23:22:13 UTC
(In reply to comment #14)
> A couple of further notes:
> 1) the ebuild for fvwm-2.5.21 has an error in its configure section; see bug
> 191914. Your ebuild makes the same mistake.
> 2) --enable-doc doesn't do anything; it should be --enable-htmldoc instead for
> building the html documentation. If this flag is set there should be an
> additional build-time DEPEND on dev-libs/libxslt. To be honest, I don't know
> the slightest thing about building documentation, so it could very well be that
> the ebuild would need additional docbook DEPENDS in this case as well.

I will look at it tomorrow, it is quite late around here. Thanks for the pointers.

> 3) instead of introducing a separate USE-flag for every single possible patch,
> it would be *much* better form to introduce a "vanilla" USE flag instead. On
> the other hand, it could just as well be omitted like it has always been. It
> makes no sense to disable the xlockmore patch for instance. Likewise, it would
> make no sense to disable the DefaultCharset patch since it seems to simply fix
> a UTF8 bug in fvwm (http://www.fvwm.org/cgi-bin/fvwm-bug/incoming?id=1647).

Well, it all depends. it is not just that simple. On first place, as I said, I can't cofirm that the locale patch works ok on every locale configuration. It is saner to have it as an use flag, as I asked on the fvwm lists and the patch has that is around since long ago, hasn't been included cause no one seems to be sure about that.

I am not smarter than the fvwm devs in which regards fvwm. So I preffer to have a way to easily disable the patch if needed.

About xlockmore, if you don't use it, you definitely don't need/want the patch. That's my view, at least.

To integrate those patches and the translucency one into a "vanilla" use flag might be a good idea, though.

> 4) most of the USE-flags you introduce seem pretty senseless to me. They
> control pretty small and non-intrusive parts of the package build; besides, all
> of their dependencies seem to be installed by xorg-x11 anyway. It is not very
> 'pretty' to introduce a big load of local USE flags which offer few, if any,
> benefits to the user.
> 
Note that fvwm work on old machines. Saving 4 or 5 megabytes of memory on runtime might not be a good reason to introduce these flags for you. But it definitely makes sense for a lot of fvwm users. You can be sure.

Disabling deps you don't only cut functionalities, but also reduce the memory usage, as the relevant libraries are not loaded, and the fvwm binary is also smaller. Definitely, fvwm is the kind of package that needs that fine tuning, since the fvwm users are usually advanced users (that doesn't mean that there are not advanced users on kde or gnome, for example, but it does mean that a regular fvwm user is not the kind of user who gets scared about seeing 20 use flags).

That is just my view of the things, of course. I can make a poll on the forums once they are up, to confirm this or deny it if you agree.

Comment 16 srrijkers 2007-09-10 10:08:35 UTC
(In reply to comment #15)

> Well, it all depends. it is not just that simple. On first place, as I said, I
> can't cofirm that the locale patch works ok on every locale configuration. It
> is saner to have it as an use flag, as I asked on the fvwm lists and the patch
> has that is around since long ago, hasn't been included cause no one seems to
> be sure about that.

If the patch is hackish and leads to unexpected behaviour it shouldn't be included *at all*.

> About xlockmore, if you don't use it, you definitely don't need/want the
> patch. That's my view, at least.

I don't use xlockmore; I couldn't care less about the patch being applied.
Have you looked at the xlockmore patch and how trivial it is? This is the typical 'distribution-specific' patch; making it optional would be complete non-standard behaviour for if it's not applied it would make fvwm *broken* on Gentoo systems.

> Note that fvwm work on old machines. Saving 4 or 5 megabytes of memory on
> runtime might not be a good reason to introduce these flags for you. But it
> definitely makes sense for a lot of fvwm users. You can be sure.

VIM has a gazillion million configure options. Most of them (the ones not pulling in additional dependencies) are enabled by default, unless the "minimal" USE-flag is used. This "minimal" flag seems to be geared towards people using VIM on embedded systems, not for people running low on resources.

By the way, fvwm compiled (-02) with sm, xshape, and xpm support has a binary size of 721 kb. Without all of these, the size is 709 kb. I don't know about memory usage, but the binary size doesn't exactly take a big hit when these features are enabled. I'd say that these USE-flags would therefore be for niche usage. Forcing everybody else to set three local USE-flags just so that some people running fvwm on a 486 can have a smaller binary size seems to be rather excessive.

> Disabling deps you don't only cut functionalities, but also reduce the memory
> usage, as the relevant libraries are not loaded, and the fvwm binary is also
> smaller. Definitely, fvwm is the kind of package that needs that fine tuning,
> since the fvwm users are usually advanced users (that doesn't mean that there
> are not advanced users on kde or gnome, for example, but it does mean that a
> regular fvwm user is not the kind of user who gets scared about seeing 20 use
> flags).

This is not about 'scaring the user', this is about how adding niche USE-flags which almost everybody else will want to set is *extremely* bad form, and would deviate from what seems to be standard Gentoo policy.
Comment 17 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-10 14:02:37 UTC
(In reply to comment #16)
> (In reply to comment #15)
> 
> > Well, it all depends. it is not just that simple. On first place, as I said, I
> > can't cofirm that the locale patch works ok on every locale configuration. It
> > is saner to have it as an use flag, as I asked on the fvwm lists and the patch
> > has that is around since long ago, hasn't been included cause no one seems to
> > be sure about that.
> 
> If the patch is hackish and leads to unexpected behaviour it shouldn't be
> included *at all*.
> 
I did not say it is hackish. I did say that I can't explain the logic behing the patch, because I am not smart about locale stuff (leaving userland tools appart). I will try to explain so you know a bit better what I mean.

In FlocaleCharset.c we have this line:
FLCXOMCharset = FLCXOMCharsetList[0];

The patch just changes it so the used charset will be the last element of the array, instead of being the first. I have no idea what the implications could be, and no one in the fvwm workers list seems to have enough interest to look into this. I wish I could exaplain this, but I can't. For me, to choose the first or the last element is equally hackish, so, I can't say it is hackish, but again, I don't understand the code. So, I can't tell you if it is a good choice or not to enable it by default. Sure for me it would be good, one less use flag to set, but as I said, I don't have actual numbers about people using it.

Anyway, that patch is old, (don't remember that 2004 sings a bell on my head, not sure). and it is true that I NEVER heard any report about this patch breaking anything. That is the only thing I can say.

> > About xlockmore, if you don't use it, you definitely don't need/want the
> > patch. That's my view, at least.
> 
> I don't use xlockmore; I couldn't care less about the patch being applied.
> Have you looked at the xlockmore patch and how trivial it is? This is the
> typical 'distribution-specific' patch; making it optional would be complete
> non-standard behaviour for if it's not applied it would make fvwm *broken* on
> Gentoo systems.
> 

Fair enough, to tell the truth, I think I never saw the contents of the patch. I will clean out that use flag and apply it unconditionally.

> VIM has a gazillion million configure options. Most of them (the ones not
> pulling in additional dependencies) are enabled by default, unless the
> "minimal" USE-flag is used. This "minimal" flag seems to be geared towards
> people using VIM on embedded systems, not for people running low on resources.

Not the case. In fvwm every single option I made an use for, pushes a dependency, even xshape or xpm. Remember: xorg is now modular, not a monolith you install. So, not everyone needs to have that. Anyway, and since I really use my own custom ebuild since always, I really don't care about the use flags on the official tree. So, I will just remove those that you consider useless. People wanting additional features can use the fvwm-live ebuild in the live-ebuilds overlay (via layman, for example).

I will revise your previous messages now and make a new version of the ebuild.

Regards, and thanks for all the pointers.
Comment 18 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-10 14:32:03 UTC
Hello again :)

I have worked a bit more on this. This is the actual thing:

[ebuild  N    ] x11-wm/fvwm-2.5.23  USE="nls perl png readline truetype -bidi -debug -doc -gtk -imlib -rplay -stroke -svg -tk -vanilla -xinerama" 0 kB

I hope this is a bit more adequate. Now, the utf8, xlock and translucency patches are always applied, unless, you USE="vanilla". The htmldoc thing should be fixed, as the png issue. Some other slight fixes have also been applied. I added the libxslt dep, the fvwm doesn't explain any additional thing about how to build the documentation. I will ask in the lists anyway, just in case. I will attach the new ebuild shortly. 

Regards and thanks again for everything.
Comment 19 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-10 14:34:58 UTC
Created attachment 130495 [details]
fvwm-2.5.23.ebuild

simplified use flags, fixed a couple of deps and added the vanilla use
Comment 20 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-11 15:42:25 UTC
(In reply to comment #18)
> I have worked a bit more on this. This is the actual thing:
> 
> [ebuild  N    ] x11-wm/fvwm-2.5.23  USE="nls perl png readline truetype -bidi
> -debug -doc -gtk -imlib -rplay -stroke -svg -tk -vanilla -xinerama" 0 kB
> 
> I hope this is a bit more adequate. Now, the utf8, xlock and translucency
> patches are always applied, unless, you USE="vanilla".

Should I make the xlock patch really unconditional? I mean, to make it independent of the vanilla flag.

Comment 21 Michael Perlov 2007-09-13 06:36:34 UTC
(In reply to comment #19)
> Created an attachment (id=130495) [edit]
> fvwm-2.5.23.ebuild
> 
> simplified use flags, fixed a couple of deps and added the vanilla use
> 

line 48:

if !use vanilla; then

must be:

if ! use vanilla; then
Comment 22 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-13 12:51:51 UTC
Created attachment 130808 [details]
fvwm-2.5.23.ebuild

fixed ! use vanilla
Comment 23 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-09-13 12:52:24 UTC
(In reply to comment #21)
> (In reply to comment #19)
> > Created an attachment (id=130495) [edit]
> > fvwm-2.5.23.ebuild
> > 
> > simplified use flags, fixed a couple of deps and added the vanilla use
> > 
> 
> line 48:
> 
> if !use vanilla; then
> 
> must be:
> 
> if ! use vanilla; then
> 

Fixed. Thanks for reporting.
Comment 24 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-10-01 21:35:36 UTC
Any chance to get this bumped in portage (with or without my "fixes")?
Comment 25 jieryn 2007-10-04 13:39:55 UTC
Please bump to the latest version. The most recent version in portage is 9+ months old now. I'm thankful that everyone is trying to boost our fvwm experience here, but 9 month old code is probably not the best thing to achieve that goal.. especially when you consider the large number of bugfixes applied in the .22 (and thus, the .23) version:

  http://www.fvwm.org/news/#2.5.22
  http://www.fvwm.org/news/#2.5.23

Thanks!!
Comment 26 Tim Harder gentoo-dev 2007-12-11 23:15:01 UTC
The most recent development version is now 2.5.24.
Comment 27 Michael 2007-12-14 17:19:42 UTC
Any chance this is gonna get moved into portage anytime soon.
Comment 28 Hong Hao 2007-12-15 12:53:22 UTC
(In reply to comment #27)
> Any chance this is gonna get moved into portage anytime soon.
> 

Taviso is away. We could use fvwm-9999 in the ebuild-live overlay until he gets back.
Comment 29 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-12-15 18:33:40 UTC
(In reply to comment #28)
> (In reply to comment #27)
> > Any chance this is gonna get moved into portage anytime soon.
> > 
> 
> Taviso is away. We could use fvwm-9999 in the ebuild-live overlay until he gets
> back.
> 

Yes, but in these cases something should be done.

I thank taviso for his dedication and understand that real life is the most important thing (even more important than fvwm is :P ). But if you look at the changelog, you will see that 2.5.21 (which is the latest in portage) appears on the line 1324 of the changelog. That means that there are 1323 lines before that one listing newer updates (so much changes to justify an update in the ebuild, in my humble opinion).

I don't care if the portage maintainers want or don't want to use my somewhat improved ebuild, but an update is necesary, if you ask me.
Comment 30 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-12-15 18:36:08 UTC
And in addition, 2.24 should be marked stable as soon as it is doable. It is more stable than 2.5.18 ever was, and has lots of bugfixes.
Comment 31 Michael 2007-12-18 09:03:54 UTC
I second that. I respectfully ask for maintainers to move in 6think's ebuild into teh tree
Comment 32 Jesús Guerrero Botella (RETIRED) gentoo-dev 2007-12-18 09:28:45 UTC
Created attachment 138805 [details]
fvwm-2.5.24.ebuild

Update:

Added dev-libs/libxslt as a dep.
Updated to .24
Comment 33 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-01-26 15:49:45 UTC
Created attachment 141827 [details]
fvwm-2.5.24.ebuild

Default charset fix not needed anymore. One less patch.
Comment 34 Zer4tul 2008-01-29 12:07:43 UTC
(In reply to comment #33)
> Created an attachment (id=141827) [edit]
> fvwm-2.5.24.ebuild
> 
> Default charset fix not needed anymore. One less patch.
> 

it seems that the diff patch (fvwm-2.5.23-translucent-menus.diff) doesn't work. maybe the path is wrong? (/home/cvs/fvwm/fvwm/fvwm/) the patch should be done at /var/tmp/portage/x11-wm/fvwm-2.5.24/work/.
Comment 35 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-01-29 13:33:44 UTC
Created attachment 142111 [details]
fvwm-2.5.24.ebuild
Comment 36 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-01-29 13:34:47 UTC
Created attachment 142113 [details]
charset.patch

    # This IS NOT the previous trivial patch for locales.
    # This is a patch extracted from the commits to 2.5.25, on cvs,
    # which actually SOLVED the long standing issue with fonts and locales.
Comment 37 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-01-29 13:39:23 UTC
I took the patch that got into cvs and have put it into the ebuild. Now, 2.5.24 users can enjoy the fixed locales as well if using this new ebuild. 

(In reply to comment #34)
> (In reply to comment #33)
> > Created an attachment (id=141827) [edit]
> > fvwm-2.5.24.ebuild
> > 
> > Default charset fix not needed anymore. One less patch.
> > 
> 
> it seems that the diff patch (fvwm-2.5.23-translucent-menus.diff) doesn't work.
> maybe the path is wrong? (/home/cvs/fvwm/fvwm/fvwm/) the patch should be done
> at /var/tmp/portage/x11-wm/fvwm-2.5.24/work/.
> 

It works, I just tested on a clean brand-new directory. Maybe you just copied it with the mouse or something. Don't copypaste, download it with wget and rename the file, or use axel <url> -o <filename>.

I just tested it and it works against .24 without any flaw.

The three patches apply cleanly. I haven't tested the build because right now I have not time to do so. If someone can, that would be great.

Enjoy.
Comment 38 Zer4tul 2008-01-29 13:55:26 UTC
(In reply to comment #37)
> I took the patch that got into cvs and have put it into the ebuild. Now, 2.5.24
> users can enjoy the fixed locales as well if using this new ebuild. 
> 
> (In reply to comment #34)
> > (In reply to comment #33)
> > > Created an attachment (id=141827) [edit]
> > > fvwm-2.5.24.ebuild
> > > 
> > > Default charset fix not needed anymore. One less patch.
> > > 
> > 
> > it seems that the diff patch (fvwm-2.5.23-translucent-menus.diff) doesn't work.
> > maybe the path is wrong? (/home/cvs/fvwm/fvwm/fvwm/) the patch should be done
> > at /var/tmp/portage/x11-wm/fvwm-2.5.24/work/.
> > 
> 
> It works, I just tested on a clean brand-new directory. Maybe you just copied
> it with the mouse or something. Don't copypaste, download it with wget and
> rename the file, or use axel <url> -o <filename>.
> 
> I just tested it and it works against .24 without any flaw.
> 
> The three patches apply cleanly. I haven't tested the build because right now I
> have not time to do so. If someone can, that would be great.
> 
> Enjoy.
> 
I am used both wget <url> -O <filename> and copy paste. Neither of them works. patch complains the file to be patched cannot be found.

Thanks
Comment 39 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-01-29 14:40:50 UTC
I really don't know what to tell you. You should double check everything. I tested it again:

cd /var/portage/local/x11-wm; rm -rf fvwm; mkdir -p fvwm/files; cd fvwm;
wget http://bugs.gentoo.org/attachment.cgi?id=130296 -O files/fvwm-menu-xlock-xlockmore-compat.patch
wget http://bugs.gentoo.org/attachment.cgi?id=130298 -O files/README.translucency
wget http://bugs.gentoo.org/attachment.cgi?id=130307 -O   files/fvwm-2.5.23-translucent-menus.diff
wget http://bugs.gentoo.org/attachment.cgi?id=142113 -O files/charset.patch
wget http://bugs.gentoo.org/attachment.cgi?id=142111 -O   fvwm-2.5.24.ebuild
ebuild fvwm-2.5.24.ebuild manifest
ebuild fvwm-2.5.24.ebuild clean
ebuild fvwm-2.5.24.ebuild unpack

The final result when I unpack is this:

# ebuild fvwm-2.5.24.ebuild unpack
 * fvwm-2.5.24.tar.bz2 MD5 RMD160 SHA1 SHA256 size ;-) ...                                    [ ok ]
 * checking ebuild checksums ;-) ...                                                          [ ok ]
 * checking auxfile checksums ;-) ...                                                         [ ok ]
 * checking miscfile checksums ;-) ...                                                        [ ok ]
 * checking fvwm-2.5.24.tar.bz2 ;-) ...                                                       [ ok ]
>>> Unpacking source...
>>> Unpacking fvwm-2.5.24.tar.bz2 to /var/tmp/portage/x11-wm/fvwm-2.5.24/work
 * Applying fvwm-2.5.23-translucent-menus.diff ...                                            [ ok ]
 * Applying charset.patch ...                                                                 [ ok ]
 * Applying fvwm-menu-xlock-xlockmore-compat.patch ...                                        [ ok ]
>>> Source unpacked.

Comment 40 Zer4tul 2008-01-30 06:30:16 UTC
(In reply to comment #39)
> I really don't know what to tell you. You should double check everything. I
> tested it again:
> 
> cd /var/portage/local/x11-wm; rm -rf fvwm; mkdir -p fvwm/files; cd fvwm;
> wget http://bugs.gentoo.org/attachment.cgi?id=130296 -O
> files/fvwm-menu-xlock-xlockmore-compat.patch
> wget http://bugs.gentoo.org/attachment.cgi?id=130298 -O
> files/README.translucency
> wget http://bugs.gentoo.org/attachment.cgi?id=130307 -O  
> files/fvwm-2.5.23-translucent-menus.diff
> wget http://bugs.gentoo.org/attachment.cgi?id=142113 -O files/charset.patch
> wget http://bugs.gentoo.org/attachment.cgi?id=142111 -O   fvwm-2.5.24.ebuild
> ebuild fvwm-2.5.24.ebuild manifest
> ebuild fvwm-2.5.24.ebuild clean
> ebuild fvwm-2.5.24.ebuild unpack
> 
> The final result when I unpack is this:
> 
> # ebuild fvwm-2.5.24.ebuild unpack
>  * fvwm-2.5.24.tar.bz2 MD5 RMD160 SHA1 SHA256 size ;-) ...                     
>               [ ok ]
>  * checking ebuild checksums ;-) ...                                           
>               [ ok ]
>  * checking auxfile checksums ;-) ...                                          
>               [ ok ]
>  * checking miscfile checksums ;-) ...                                         
>               [ ok ]
>  * checking fvwm-2.5.24.tar.bz2 ;-) ...                                        
>               [ ok ]
> >>> Unpacking source...
> >>> Unpacking fvwm-2.5.24.tar.bz2 to /var/tmp/portage/x11-wm/fvwm-2.5.24/work
>  * Applying fvwm-2.5.23-translucent-menus.diff ...                             
>               [ ok ]
>  * Applying charset.patch ...                                                  
>               [ ok ]
>  * Applying fvwm-menu-xlock-xlockmore-compat.patch ...                         
>               [ ok ]
> >>> Source unpacked.
> 

it's ok now. it seems like that i've used a wrong url to get the patchs. sorry to trouble you. and lots of thanks.
Comment 41 Jesús Guerrero Botella (RETIRED) gentoo-dev 2008-02-27 03:03:10 UTC
Created attachment 144715 [details]
fvwm-2.5.25.ebuild

fvwm 2.5.25 is out.
===================

Charset patch no longer needed in any form.

Everyone should update to this release.

Check this for additional info about the release:
http://fvwm.lair.be/viewtopic.php?f=4&t=1994

The latest version in portage is 2.5.21, for detailed changes on what you are missing if you use the versions in portage, you can check this:
http://fvwm.org/news/#2.5.25
Comment 42 Dominique Michel 2008-03-09 20:30:10 UTC
At http://forums.gentoo.org/viewtopic-p-4944944.html#4944943:

QUOTE:FVWM dropped the fvwm2 naming convention of its binaries ages ago.

-- Thomas Adam
ENDQUOTE

That implies that /etc/X11/Sessions/fvwm2, file generated by the ebuild, is wrong. It use /usr/bin/fvwm2 instead of /usr/bin/fvwm. 

More, the desktop file in x11-themes/fvwm-crystal must be changed accordingly.

Comment 43 Gautam Iyer 2008-03-24 08:29:04 UTC
Any chance this is going to make it into the portage tree soon? Been a while since the last update!!

THanks,

GI
Comment 44 David Shakaryan (RETIRED) gentoo-dev 2008-04-24 09:35:00 UTC
(In reply to comment #43)
> Any chance this is going to make it into the portage tree soon? Been a while
> since the last update!!

My priority right now is fixing all desktop-wm and commonbox bugs. This being one of them, I'd like to get to it when I have some free time. (Hopefully within the next few days.)

Also, if anybody is interested in proxy-maintaining this package, just poke me via email or IRC. :)
Comment 45 David Shakaryan (RETIRED) gentoo-dev 2008-04-28 07:59:05 UTC
Version bump coming *very* soon. Next 2-3 days, I'd say... Just getting the ebuild up to par as it's extremely messy and outdated. :)
Comment 46 David Shakaryan (RETIRED) gentoo-dev 2008-05-04 08:45:12 UTC
I went ahead and committed an ebuild for 2.5.25.

While the ebuild is not yet perfect, I have improved and cleanup almost all of it, and rewrote some parts as well. It should be a lot nicer and easier to follow now. It seems to work fine here, so I'm hoping I didn't break anything.

Thanks to everybody for their patience and hard work, especially Jesús Guerrero.

This bug is finally resolved! :)