The successor of fvwm is released and in active development. at that time, the fvwm2 configurations are compatible with fvwm2, with no changes at all or with a few very minor changes. Reproducible: Always I have a working ebuild for fvwm3-1.0.1 and fvwm3-9999, but before I finalize and put it here, it would be best if we can decide how we integrate fvwm3 into portage. Also, we can wait until fvwm3-1.0.2 is out (maybe that week), because it will contain some important fixes for the compatibility with the existing fvwm2 configurations. If we keep fvwm3 in x11-wm/fvwm, this will result into fvwm-1.0.x being fvwm3 and more recent than fvwm-2.6.{5,8,9}. In that case, the dependencies of x11-themes/fvwm-crystal should be modified to depend on fvwm-1.* or >=fvwm-2.6.9 for its last and coming versions (I will try to keep the compatibility with fvwm.2.6.9 as long it is possible to do it without too much work. How long it will be the case is out of my control because it depend on fvwm3 development.). If we make a new package x11-wm/fvwm3, we will have to add virtual/fvwm and make x11-themes/{fvwm-crystal, fvwm-icons, fvwm_sound} to depend on it. Also, x11-themes/fvwm-themes* should work at that time with fvwm3, but as it was no development on them from years, They will certainly break with the future development of fvwm3. Anyway, I fell than from years, they are more interesting to keep into the tree for the numerous fvwm configuration examples they contains, than to get a good and stable fvwm based working environment. I also fell than these examples are good to have in the tree, that because if fvwm is not hard, it is complex and, especially with modules like FvwmScript, they are very helpful in order to get started with the hacking of fvwm configuration. Also, it is a possibility to have both fvwm2 and fvwm3 installed, but this imply to install one of them with PREFIX="Usr/local", which break the FHS/Gentoo policy paths. Which imply this is not a valid option. I don't see how we can slot them because, at the exception of the main executable which was renamed to fvwm3, this will result into a lot of files collisions with at least the other exec in $PREFIX/bin, the man pages and the locales. So, what do we do with fvwm3?
Oops: the fvwm2 configurations are compatible with fvwm3, with no changes at all or with a few very minor changes.
If we look how the few other distributions which have a package for fvwm3 integrate it, they made a new fvwm3 package: https://repology.org/project/fvwm3/versions. If wee look for fvwm, only one have fvwm3 and it integrate it like fvwm-3-1.0.1: https://repology.org/project/fvwm/versions Maybe the simplest in portage would be to name the package as fvwm-3.1.0.x. That way, in other packages, a depend like >=fvwm-2.6.x would work with both fvwm2 and fvwm3.
Created attachment 678322 [details] ebuild for fvwm3 It is a combined ebuild for fvwm-3.9999 and fvwm-3.1.0.1 When fvwm-3.1.0.2 will be released, it would be possible to simplify it a bit. With fvwm-3.1.0.1 and USE=htmldoc, the html doc is installed into /usr/share/doc/fvwm3, but I prefer to wait until fvwm3-1.0.2 is released than to fix it.
Created attachment 678325 [details] updated metadata with the go USE flag
Created attachment 678328 [details] oops, make repoman happy
Created attachment 678331 [details] ebuild for fvwm3 libstroke is not supported anymore by fvwm3. Added KEYWORDS for non live versions. Various fixes to make "repoman full" out of business.
Created attachment 678334 [details] fixed metadata Removed stroke use flag. Fixed tab/space inconsistency.
Created attachment 678691 [details] fix shebangs and simplify This fix the python shebangs and make the ebuild ready for 3.1.0.2 Thomas Adam confirmed me than 3.1.0.2 will be out very soon. Anyway, 3.1.0.2 address several critical bugs and compatibility issues with the fvvwm2 configurations, the live version is very stable when 3.1.0.1 is not.
Created attachment 678694 [details] fix dependencies remove non needed dependency
Created attachment 678697 [details] fix depends remove non needed depend
I got the following error when trying the ebuild: Traceback (most recent call last): File "/usr/lib/portage/python3.7/doins.py", line 594, in <module> sys.exit(main(sys.argv[1:])) File "/usr/lib/portage/python3.7/doins.py", line 585, in main os.path.dirname(source)): File "/usr/lib/portage/python3.7/doins.py", line 434, in _doins return install_runner.install_file(source, os.path.dirname(dest)) File "/usr/lib/portage/python3.7/doins.py", line 370, in install_file return self._ins_runner.run(source, dest_dir) File "/usr/lib/portage/python3.7/doins.py", line 179, in run sstat = os.stat(source) FileNotFoundError: [Errno 2] No such file or directory: b'dev-docs/NEW-COMMANDS.md' * ERROR: x11-wm/fvwm-3.1.0.2::localrepo failed (install phase): * dodoc failed * * If you need support, post the output of `emerge --info '=x11-wm/fvwm-3.1.0.2::localrepo'`, * the complete build log and the output of `emerge -pqv '=x11-wm/fvwm-3.1.0.2::localrepo'`. * The complete build log is located at '/var/tmp/portage/x11-wm/fvwm-3.1.0.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/x11-wm/fvwm-3.1.0.2/temp/environment'. * Working directory: '/var/tmp/portage/x11-wm/fvwm-3.1.0.2/work/fvwm3-1.0.2' * S: '/var/tmp/portage/x11-wm/fvwm-3.1.0.2/work/fvwm3-1.0.2' * QA Notice: command not found: * * /var/tmp/portage/x11-wm/fvwm-3.1.0.2/temp/environment: line 3730: python_single-r1_pkg_setup: command not found Removing dev-docs/NEW-COMMANDS.md from DOCS solved this. $ emerge fvwm -vp [ebuild R ] x11-wm/fvwm-3.1.0.2::localrepo USE="png readline truetype -bidi -debug -doc -go -htmldoc -lock -netpbm -nls -perl -rplay -svg -tk -vanilla" PYTHON_SINGLE_TARGET="python3_7 (-python3_6) -python3_8 -python3_9" 0 KiB
The attached ebuilds work great over here. Could those be released by any chance soon? That would be great. Thanks.
Created attachment 713712 [details] fix installation of dev-docs files
Created attachment 713796 [details] fix maintainer
For now Go is optional, is there any way to make it optional in the ebuild too? The "go" use flag is useless because of the inherited "go-module" eclass. [ebuild N ] dev-lang/go-bootstrap-1.13.6::gentoo USE="(-big-endian)" 114,185 KiB [ebuild N ] dev-lang/go-1.16.5:0/1.16.5::gentoo CPU_FLAGS_X86="sse2" 20,432 KiB [ebuild U *] x11-wm/fvwm-3.9999::GEN2 [2.6.9::gentoo] USE="nls png svg truetype -bidi -debug -doc -go% -htmldoc% -lock -netpbm -perl -readline -rplay -tk -vanilla (-stroke%) (-xinerama%)" PYTHON_SINGLE_TARGET="python3_9%* -python3_8%" 0 KiB Also, dev-libs/libbson is not a dependency any more.
Created attachment 744777 [details] build.log
Using the attached ebuild building fvwm3 fails, build.log attached.
@needle Check GOFLAGS: > go: parsing $GOFLAGS: unknown flag -w"
Hi Dominique, if you're interested in maintaining this, could you: - email me a 'git am'-able patch (git format-patch should do this, or git send-email), or - email the proxy-maint mailing list, or - make a github PR. Thanks!
@sebaro. Thanks for the hint. I have been pointed to this fvwm3 commit, causes the issue: https://github.com/fvwmorg/fvwm3/commit/9bac03e442bcebd47db55946de840096fb04ce75 I try to write a patch for this. (In reply to sebaro from comment #18) > @needle > Check GOFLAGS: > > go: parsing $GOFLAGS: unknown flag -w"
Patching the GOFLAGS in the Makefile.am is OK. Howerver it makes no difference if GOFLAGS is set to -s or left empty. The build breaks saying either "invalid value" for leaving empty or "unknown flag" if flags are set. This can not be solved this way. Someone with GO experienced would need to take a loo at this. (In reply to needle from comment #20) > @sebaro. > > Thanks for the hint. I have been pointed to this fvwm3 commit, causes the > issue: > > https://github.com/fvwmorg/fvwm3/commit/ > 9bac03e442bcebd47db55946de840096fb04ce75 > > I try to write a patch for this. > > (In reply to sebaro from comment #18) > > @needle > > Check GOFLAGS: > > > go: parsing $GOFLAGS: unknown flag -w"
(In reply to needle from comment #21) > Patching the GOFLAGS in the Makefile.am is OK. Howerver it makes no > difference if GOFLAGS is set to -s or left empty. The build breaks saying > either "invalid value" for leaving empty or "unknown flag" if flags are set. > This can not be solved this way. Someone with GO experienced would need to > take a loo at this. I agree with you. I get the same error now, and if I go in $S and run "make", it compile without issue: make[3]: Entering directory '/var/tmp/portage/x11-wm/fvwm3-9999/work/fvwm3-9999/bin/FvwmPrompt' go build -mod=mod -ldflags="-s -w" -mod=vendor -o FvwmPrompt -v make[3]: Leaving directory '/var/tmp/portage/x11-wm/fvwm3-9999/work/fvwm3-9999/bin/FvwmPrompt' That imply it should be an issue with go in portage and into the ebuild.
Created attachment 762823 [details] remove libsson depend; add GO conditional Can you please test the GO conditional and report how it work for you.
Created attachment 762824 [details] build log I can see 2 issues/warnings with go: - In src_unpack: * Tidying go.mod/go.sum go: go.mod file not found in current directory or any parent directory; see 'go help modules' I don't know if this can be ignored or if it should be fixed and how. - In src_compile: Making all in FvwmPrompt make[3]: Entering directory '/var/tmp/portage/x11-wm/fvwm-3.9999/work/fvwm-3.9999/bin/FvwmPrompt' go build -mod=mod -ldflags="-s -w" -mod=vendor -o FvwmPrompt -v go: parsing $GOFLAGS: unknown flag -w" make[3]: *** [Makefile:529: build] Error 1 I googled and try different things like setting the EGO_BUILD_FLAGS or GOFLAGS variables, but I found nothing that work and have no more clue. Even to use make instead of emake was not working.
Another issue I get with go in that ebuild is when I try, instead of maintaining a long list into EGO_SUM, to put the following: EGO_SUM=( "https://github.com/fvwmorg/fvwm3/blob/master/bin/FvwmPrompt/go.mod" ) which result into: ebuild fvwm-3.9999.ebuild digest ... !!! Couldn't download 'https:%2F%2Fgithub.com%2Ffvwmorg%2Ffvwm3%2Fblob%2Fmaster%2Fbin%2F!fvwm!prompt%2Fgo.mod%2F@v%2F.zip'. Aborting. !!! Fetch failed for https:%2F%2Fgithub.com%2Ffvwmorg%2Ffvwm3%2Fblob%2Fmaster%2Fbin%2F!fvwm!prompt%2Fgo.mod%2F@v%2F.zip, can't update Manifest
Same issue if I try with the permalink: !!! Couldn't download 'https:%2F%2Fgithub.com%2Ffvwmorg%2Ffvwm3%2Fblob%2F42d9198c81d689b9c26a45ee1c5518df1b1d1f70%2Fbin%2F!fvwm!prompt%2Fgo.mod%2F@v%2F.zip'. Aborting
(In reply to Dominique Michel from comment #26) > Same issue if I try with the permalink: > > !!! Couldn't download > 'https:%2F%2Fgithub. > com%2Ffvwmorg%2Ffvwm3%2Fblob%2F42d9198c81d689b9c26a45ee1c5518df1b1d1f70%2Fbin > %2F!fvwm!prompt%2Fgo.mod%2F@v%2F.zip'. Aborting [14:31:58] <@sam_> dominique_michel: as for the issue at the end of the bug, you have to put the contents of go.sum into that variable, _not_ the link to it [14:32:08] <@sam_> i do: cat /tmp/go.sum | cut -d" " -f1,2 | awk '{print "\t\"" $0 "\""}' [14:32:12] <@sam_> then i put the output into EGO_SUM
(In reply to Dominique Michel from comment #24) > Making all in FvwmPrompt > make[3]: Entering directory > '/var/tmp/portage/x11-wm/fvwm-3.9999/work/fvwm-3.9999/bin/FvwmPrompt' > go build -mod=mod -ldflags="-s -w" -mod=vendor -o FvwmPrompt -v > go: parsing $GOFLAGS: unknown flag -w" > make[3]: *** [Makefile:529: build] Error 1 According to Thomas Adam on IRC #fvwm: - ... it'll be due to the golang version you're using. When I tell him I don't get that issue when running just "make", but only with portage, he answered: - Sounds like a Gentoo/Portage issue to me. Try asking them. I don't get that issue with the last released version: fvwm3-1.0.4. I am testing it and a patch for the live ebuild that fix that issue by removing these ldflags. But as the real issue seam to be in portage, that will be more a workaround than the real fix.
Created attachment 762993 [details] ebuild for the last released version That version compile fine with portage and go version go1.17.6 linux/amd64
Created attachment 762994 [details, diff] fix for the go ldflags portage issue That patch works fine here with the live ebuild and go version go1.17.6 linux/amd64
Created attachment 762995 [details, diff] use the build system to generate the html doc fvwm documentation is so extensive than I really prefer to use the html version.
Created attachment 762996 [details] live ebuild with fix for the go ldflags issue Next step is a little bit more cleanup and, hopefully, a PR or an email with a portage patch.
Created attachment 763485 [details, diff] Translucent Menus Patch
It works with some changes: * dev-libs/libbson is not needed any more, was replaced with internal cJSON * both doc and htmldoc flags require dev-ruby/asciidoctor * attached translucent menus patch from fvwm2
The ebuild 3.9999 works including the needed 2 patches: fvwm-3.9999-goflags.patch fvwm-3.9999-htmldoc.patch work now over here. Thanks for looking into this and fixing.
OK, everything on the PR looks good to go now; Someone that actually has a fvwm2 configuration to migrate (or already uses fvwm3) should take a look and validate that functionality is working. The x11-wm/fvwm3 package has a weak blocker on x11-wm/fvwm to prevent collisions. I went with `x11-wm/fvwm3` to match upstream's naming convention. This will require some additional work by an actual fvwm3 user who can test (add '|| x11-wm/fvwm3' to deps). The most likely culprits are: x11-themes/fvwm-crystal x11-themes/fvwm_icons x11-themes/fvwm_sounds x11-themes/fvwm-themes-extra x11-themes/fvwm-themes I note that the majority of these packages are on EAPI 7, with one on 6 so they could probably use some love anyway - I've got a few other projects on at the moment and can't get to it right now, and an actual fvwm user is probably going to notice any issues - at the moment I'd only be able to go with 'it compiles and launches'.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=441413d3e25f69a370edd41ce25aad07f6803b86 commit 441413d3e25f69a370edd41ce25aad07f6803b86 Author: Matt Jolly <Matt.Jolly@footclan.ninja> AuthorDate: 2022-05-20 13:02:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-06-02 05:23:07 +0000 x11-wm/fvwm3: new package, add 1.0.4, 9999 Closes: https://bugs.gentoo.org/760012 Signed-off-by: Matt Jolly <Matt.Jolly@footclan.ninja> Closes: https://github.com/gentoo/gentoo/pull/25609 Signed-off-by: Sam James <sam@gentoo.org> x11-wm/fvwm3/Manifest | 3 + x11-wm/fvwm3/files/README.translucency | 94 ++++ x11-wm/fvwm3/files/fvwm3-1.0.4-htmldoc.patch | 70 +++ .../files/fvwm3-1.0.4-translucent-menus.patch | 487 ++++++++++++++++++++ x11-wm/fvwm3/files/fvwm3-9999-goflags.patch | 11 + x11-wm/fvwm3/files/fvwm3-9999-htmldoc.patch | 43 ++ .../fvwm3/files/fvwm3-9999-translucent-menus.patch | 489 +++++++++++++++++++++ x11-wm/fvwm3/fvwm3-1.0.4.ebuild | 200 +++++++++ x11-wm/fvwm3/fvwm3-9999.ebuild | 200 +++++++++ x11-wm/fvwm3/metadata.xml | 27 ++ 10 files changed, 1624 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e0676d323821ce5660feec809a9f8018a2ab58c3 commit e0676d323821ce5660feec809a9f8018a2ab58c3 Author: Matt Jolly <Matt.Jolly@footclan.ninja> AuthorDate: 2022-05-20 13:02:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-06-04 02:19:19 +0000 x11-wm/fvwm3: new package, add 1.0.4, 9999 Closes: https://bugs.gentoo.org/760012 Signed-off-by: Matt Jolly <Matt.Jolly@footclan.ninja> Signed-off-by: Sam James <sam@gentoo.org> x11-wm/fvwm3/Manifest | 3 + x11-wm/fvwm3/files/README.translucency | 94 ++++ x11-wm/fvwm3/files/fvwm3-1.0.4-htmldoc.patch | 70 +++ .../files/fvwm3-1.0.4-translucent-menus.patch | 487 ++++++++++++++++++++ x11-wm/fvwm3/files/fvwm3-9999-goflags.patch | 11 + x11-wm/fvwm3/files/fvwm3-9999-htmldoc.patch | 43 ++ .../fvwm3/files/fvwm3-9999-translucent-menus.patch | 489 +++++++++++++++++++++ x11-wm/fvwm3/fvwm3-1.0.4.ebuild | 204 +++++++++ x11-wm/fvwm3/fvwm3-9999.ebuild | 204 +++++++++ x11-wm/fvwm3/metadata.xml | 27 ++ 10 files changed, 1632 insertions(+)
