Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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
Created an attachment (id=130293) [edit] Ebuild
Created an attachment (id=130295) [edit] charset fix patch
Created an attachment (id=130296) [edit] xlockmore patch
Created an attachment (id=130297) [edit] translucent menus patch
Created an attachment (id=130298) [edit] fixed typo in the readme file name
*** Bug 190791 has been marked as a duplicate of this bug. ***
Created an attachment (id=130306) [edit] revised the ebuild I submitted the wrong ebuild the first time
Created an attachment (id=130307) [edit] fvwm-2.5.23-translucent-menus.diff
(From update of attachment 130298 [edit]) fixed typo in filename
(From update of attachment 130296 [edit]) xlock compatibility patch
(From update of attachment 130295 [edit]) charset fix patch
(In reply to comment #7) > Created an attachment (id=130306) [edit] Your ebuild is missing a conditional dependency on librsvg for USE="svg"
Created an attachment (id=130418) [edit] fvwm-2.5.23.ebuild fixed dep on libsrvg when USE="svg"
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.
(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.
(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.
(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.
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.
Created an attachment (id=130495) [edit] fvwm-2.5.23.ebuild simplified use flags, fixed a couple of deps and added the vanilla use
(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.
(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
Created an attachment (id=130808) [edit] fvwm-2.5.23.ebuild fixed ! use vanilla
(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.
Any chance to get this bumped in portage (with or without my "fixes")?
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!!
The most recent development version is now 2.5.24.
Any chance this is gonna get moved into portage anytime soon.
(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.
(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.
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.
I second that. I respectfully ask for maintainers to move in 6think's ebuild into teh tree
Created an attachment (id=138805) [edit] fvwm-2.5.24.ebuild Update: Added dev-libs/libxslt as a dep. Updated to .24
Created an attachment (id=141827) [edit] fvwm-2.5.24.ebuild Default charset fix not needed anymore. One less patch.
(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/.
Created an attachment (id=142111) [edit] fvwm-2.5.24.ebuild
Created an attachment (id=142113) [edit] 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.
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.
(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
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.
(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.
Created an attachment (id=144715) [edit] 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
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.
Any chance this is going to make it into the portage tree soon? Been a while since the last update!! THanks, GI
(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. :)
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. :)
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! :)
