Hello, new fvwm version has been released. Announcement: https://github.com/fvwmorg/fvwm/releases/tag/2.6.7 Please update the ebuild. Thank you. Reproducible: Always
Thank you for the bump request, but please wait at least 48h next time. https://wiki.gentoo.org/wiki/Bugzilla/Guide#Zero-day_bump_requests
Mmm, there are quite a few changes that need to be considered. - gtk1 and gnome stuff are both gone, two flags need to be removed. - same goes for png, since png support seems to be mandatory. - the new config offers optional support for a few things; stalonetray, xterm and pyxdg comes to mind, but there might be others - docs have moved around, the ebuild needs to take that into account. I can provide an initial ebuild if there's none in progress. Stay tuned :P
Created attachment 452670 [details] Preliminary fvwm-2.6.7.ebuild This one rips gtk and gnome stuff, it also removed png flag because png is now mandatory. It also changes the dodocs because of a lot of old files went the way of the dodo. Things to note: - the new default config can use xterm and stalonetray if they are present, should we add that as RDEPEND? Maybe an ewarn informing about this?... I really don't care much about that... - there's an option to copy the default config to your, home right in the menu when you first use it - I should also add a dependency to python-xdg, but since I haven't been able to make the xdg menu work still, I haven't included that yet, pointers are welcome if someone knows something about python-xdg
The xdg menu... You need python to get it working. That's not a big deal in Gentoo, except for the fact that fvwm-desktop-menu only works with python2, and you need to modify the bang in the first line of that script to get it working. Just change python by python2 and it will work. I reported upstream, let's see if that solution is acceptable for them.
In addition to all that's been said above, the xdg menu also needs USE=perl (so perllib is built) to be able to use its configuration dialog. Why I was at this, I also discovered that FvwmConsole doesn't work with USE=-perl, so I will also rip that flag from the ebuild. FvwmCommand is a central tool for Fvwm administration, configuration and debugging. If someone else wants to intentionally break their fvwm installation, they probably don't need an ebuild to do so.
Created attachment 452678 [details] perl goes inconditionally, otherwise FvwmConsole and default config break Supporting utterly broken installs goes beyond what I call customizability.
*** Bug 580166 has been marked as a duplicate of this bug. ***
*** Bug 585792 has been marked as a duplicate of this bug. ***
(In reply to Jesús Guerrero Botella from comment #3) > - the new default config can use xterm and stalonetray if they are present, > should we add that as RDEPEND? Maybe an ewarn informing about this?... I > really don't care much about that... > - there's an option to copy the default config to your, home right in the > menu when you first use it I think it is not a big deal for most fvwm users. But anyway, it can be good to install that file somewhere, as example in "${DOCS}/example". That default config is a very good example of an effective and concise fvwm configuration, and it need very few modifications for a fvwm newcomer to get started.
(In reply to Dominique Michel from comment #9) > (In reply to Jesús Guerrero Botella from comment #3) > > > - the new default config can use xterm and stalonetray if they are present, > > should we add that as RDEPEND? Maybe an ewarn informing about this?... I > > really don't care much about that... > > - there's an option to copy the default config to your, home right in the > > menu when you first use it > > > I think it is not a big deal for most fvwm users. But anyway, it can be good > to install that file somewhere, as example in "${DOCS}/example". That > default config is a very good example of an effective and concise fvwm > configuration, and it need very few modifications for a fvwm newcomer to get > started. Oh maybe I misunderstood. If the option is in fvwm, I guess it is for copying fvwm's default config into $HOME/.fvwm/.config. In that case, I think an ewarn would be right and sufficient.
(In reply to Dominique Michel from comment #10) > (In reply to Dominique Michel from comment #9) > > (In reply to Jesús Guerrero Botella from comment #3) > > > > > - the new default config can use xterm and stalonetray if they are present, > > > should we add that as RDEPEND? Maybe an ewarn informing about this?... I > > > really don't care much about that... > > > - there's an option to copy the default config to your, home right in the > > > menu when you first use it > > > > > > I think it is not a big deal for most fvwm users. But anyway, it can be good > > to install that file somewhere, as example in "${DOCS}/example". That > > default config is a very good example of an effective and concise fvwm > > configuration, and it need very few modifications for a fvwm newcomer to get > > started. > > Oh maybe I misunderstood. If the option is in fvwm, I guess it is for > copying fvwm's default config into $HOME/.fvwm/.config. In that case, I > think an ewarn would be right and sufficient. I am checking that. The ebuild needs to remove the gtk2-perl part and associated files in ${S}, as it is not in portage anymore. I can be the proxy maintainer of that package.
Thanks for volunteering, I guess you will need to open a bug report for that: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Pacho Ramos from comment #12) > Thanks for volunteering, I guess you will need to open a bug report for that: > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Thanks! I will do that.
(In reply to Dominique Michel from comment #10) > (In reply to Dominique Michel from comment #9) > > (In reply to Jesús Guerrero Botella from comment #3) > > > > > - the new default config can use xterm and stalonetray if they are present, > > > should we add that as RDEPEND? Maybe an ewarn informing about this?... I > > > really don't care much about that... > > > - there's an option to copy the default config to your, home right in the > > > menu when you first use it > > > > > > I think it is not a big deal for most fvwm users. But anyway, it can be good > > to install that file somewhere, as example in "${DOCS}/example". That > > default config is a very good example of an effective and concise fvwm > > configuration, and it need very few modifications for a fvwm newcomer to get > > started. > > Oh maybe I misunderstood. If the option is in fvwm, I guess it is for > copying fvwm's default config into $HOME/.fvwm/.config. In that case, I > think an ewarn would be right and sufficient. I checked that. From the menu, you can copy the config fvwm file in $FVWM_USERDIR, and it is the same than the file in ${S}/default-config, but it is a few more files: # ls -a default-config . .stalonetrayrc FvwmScript-ConfirmQuit Makefile Makefile.in images .. FvwmScript-ConfirmCopyConfig FvwmScript-DateTime Makefile.am config The question is, do we install these files? I have no preference. Also, it is another issue with fvwm: it doesn't install any session file in /usr/share/xsessions. We can install one with portage: make_session_desktop fvwm /usr/bin/fvwm That way, it will be visible by graphical logging managers, and by the nested sessions menu of fvwm-crystal.
The config files are already installed into /usr/share/fvwm/default-config/, which imply it is no need to install them twice.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9445bcf71684247be699b2d5db15104be71434b1 commit 9445bcf71684247be699b2d5db15104be71434b1 Author: Tim Harder <radhermit@gentoo.org> AuthorDate: 2018-09-23 07:18:19 +0000 Commit: Tim Harder <radhermit@gentoo.org> CommitDate: 2018-09-28 17:31:02 +0000 x11-wm/fvwm: version bump to 2.6.8 Closes: https://bugs.gentoo.org/533258 Closes: https://bugs.gentoo.org/599144 x11-wm/fvwm/Manifest | 1 + x11-wm/fvwm/fvwm-2.6.8.ebuild | 152 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 153 insertions(+)
