Not to be a pita, but when I run ./configure, I get this: This is on a 16.2 core install, 32 bit.
Google says (I think) that I am not sure, as this is not something I do a lot.
Anyway, if you know how to fix that, great! and if not, just tell me to f*** off __{{emoticon}}__

Uhm, you might want to do that even if you do know...

this is not something I do a lot.

Me too. Me either? I'm a greenhorn at compiling/packaging.
At a glance (I'll recheck and post a followup) it looks like my github upload was incomplete. Hopefully we'll discover your build just failed due to missing files.

Yah, files were missing from my github repository.

Upside-down from what you seemed to expect, I'm thankful you noticed & called attention to the problematic situation.
Do -- please do -- keep a critical eye & hold my feet to the fire as you inspect/build/test.

701files // 72 dirs
Ok, I've added the missing files to the github repository




FWIW, I inherited, and ignorantly copypasted, a .gitignore file present in the upstream code.
This, from 4yrs ago
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/fluxbox/fluxbox/blob/master/.gitignore"
linktext was:"https://github.com/fluxbox/fluxbox/blob ... .gitignore"
====================================

(prior to addition of the m4 automake templates so, yeah, it would have rightly ignored those paths)
still exists in the upstream codebase, and was present among my local files.

Great!
Well, it still does not finish without errors, but I am thinking this is because I am on antix core, and I am simply missing whatever it is that provides desktop-menu.
I will try later today, on a full install.

Anyway, here is the error, just because.

In response to your latest report, I"ate my own dogfood" by downloading/extracting/building from the current github zipfile.
Still (again) 64-bit antiX 16 here (dunno how/why 32 vs 64bit might behave differently though) and it it successfully compiled. dpkg-query -S /usr/local/bin/desktop-menu
^---v
desktop-session-antix: /usr/local/bin/desktop-menu

Your assessment seems correct. According to this:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/BitJam/Build-iso/search?utf8=%E2%9C%93&q=desktop-session-antix&type="
linktext was:"https://github.com/BitJam/Build-iso/sea ... ntix&type="
====================================

the"desktop-session-antix" package is preinstalled to only"base" and"full" editions.

If you installed just that one missing package to your"core" edition, breakage (idunno about build failure) might still occur.
As mentioned in the INSTALL file & my early posts in this topic, handling this"test build" is awkward, because antiX fluxbox
implementation involves bits-n-pieces provided by multiple, separate .deb packages (e.g."desktop-defaults-fluxbox-antix").

Hmm, I had anticipated that even if eventually this ships pre-installed, those packages should remain separate.
(Avoids needing to rebuild the package containing executables when preinstalled themes are swapped in/out)

I can't make a decision"how to accommodate core edition?" on my own.
As is, this fluxbox package would rightfully need to declare"desktop-defaults-fluxbox-antix" as a dependency.
(and could"squeak by", listing"fluxbox-themes-antix" as a Recommends, but I'm not keen on that prospect)
That package (d-d-f-a) is only 300Kb or so; hopefully its pre-installation in"core" edition wouldn't be objectionable
or a mechanism is already in place

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/BitJam/Build-iso/blob/53d86d50b050a2d30c3ae83e97b347b036bf02fd/Template/COMMON/delete-files.list"
linktext was:"https://github.com/BitJam/Build-iso/blo ... files.list"
====================================

to nix its content during the automated build process, when generating the"core edition" iso.

Again, thanks for testing and helping to flesh out these prospective"gotchas" and"whatifs".

ps:
Today, in response to the earlier build failure you described
(dangit, presence of second arg should be moot. The gcc v4.9+ compiler should just ignore, or raise notice, but not fail)
I tested:
-- edit"configure.ac" and remove the second argument
-- edit its counterpart (at bottom of"ax_cxx_compile_stdcxx_11.m4")
and confirmed the build is successful for me, with or without presence of the second argument.

oh... I was missing the desktop-session-antix
I already had the desktop-defaults-fluxbox-antix installed

Anyway, it did finish, and created a .deb for me, and fluxbox does start, so that is good.
None of the"cool" things work, like the menu stuff, or themes, but hey! it does work.
(still on the core install)
I will see if I can try it on the antix full install, out in the garage.

skidoo - I don't understand why desktop-session-antix is/should be needed for your fluxbox version?
On core user can install fluxbox from Debian without needing to install desktop-session-antix. Of course user would need to set up .xinitrc or whatever.

Just to bring some happy news, I moved the .deb from the core install, to the full install, and it installed and works perfectly (as far as I can see)

why desktop-session-antix is/should be needed

short answer:"without it, applications submenu does not get populated"


long answer (advice/corrections/suggestions welcome):

* debian packaging displaces the menu_generator provided by upstream fluxbox. I agreed (the output of menu_generator is pointless/counterproductive) so did not alter that packaging detail.

* antiX proprietary"update-menu" populates the applications submenu for each wm.

* When fluxbox is pre-installed in antiX, on first-run (or as each user account is created), a symlink"~/.fluxbox/applications-menu" is created from an /etc/skel/ file which is provided by desktop-session-antix. Successful operation of the update-menu script apparently relies on presence of this symlink.

Awkward. Technically,"bone stock menu, default menu (devoid of antiX enhancements) as provided by the newly-installed wm package" is the result to be expected. In the test scenario however, testing a menu devoid of"applications submenu" content (and other antiX-specific content) would be pointless. Test build (as well as final, or so I had expected) ships a"default" menu containing the antiX-proprietary"Update Menu" entry which depends on the antix"menu-update" utility.

I didn't anticipate the prospect of a betatester attempting to use this"test build" in core edition ~~ we just wound up here.
The instructions I had provided for prospective testers assumed / presumed the 'necessary bits' would already be in place.

As noted within earlier posts in this topic, typically some of the antiX fluxbox configfiles are pre-installed by other debfiles.
Installing this"fluxbox v1.3.8-ski" debfile to an existing antiX system necessitates some preparatory steps:

Code: Select all

 . . . {snip} . . .

    1) FOR TESTING (and in case you wish to rollback):
           sudo cp -R /usr/share/fluxbox  /usr/share/fluxbox_bak

    2) cp -R ~/.fluxbox  ~/.fluxbox_bak

    3) By design, your existing"startup" file will be preserved.
       FOR TESTING, we want to ensure fluxbox uses"fresh, new version config files, so
           rm ~/.fluxbox/init && rm ~/.fluxbox/keys && rm ~/.fluxbox/menu
           rm ~/.fluxbox/overlay && rm ~/.fluxbox/windowmenu

. . . {snip} . . .

[/color]

To accommodate"antiX core edition" users -- and the debian community at large -- a future release could revert to shipping
a non-antiX-proprietary default menu. However, as soon as it becomes possible to do so (don't hold yer breath),
pushing the other enhancements to upstream 1.4.0 and using that, instead, might be a more appealing course.


Here's where the debian packaging"deals with" the menu.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antix-skidoo/fluxbox/blob/master/debian/fluxbox.menu-method"
linktext was:"https://github.com/antix-skidoo/fluxbox ... enu-method"
====================================

"menu-method" is apparently a mandatory building block in the packaging.
Any advice? I didn't put much effort into revising their prior decision to mangle fluxbox's native menu generator.

nitpicking, sorry, but its out of curiosity:

antiX proprietary"update-menu" populates the applications submenu for each wm.

i have the contents of both refracta and antix uncompressed to folders, and /usr/bin/update-menu is a binary executable in both, ranging from 135k in refracta 8.3 to 127k in what is surely antix 17 but either that of 16. what (if anything) does antix change/replace/do differently in this executable from the refracta(debian) one? because whatever refracta has, its going to be stock debian stuff. not everything in refracta is stock debian, but update-menu is unless they got it from here.

not everything in refracta is stock debian, but update-menu is unless they got it from here.

Within my attempt to explain"why depends", I suppose in that quoted bit I should have conveyed air quotes by prefacing (aka"update-menu").
'Twas an inexact shorthand instead of typing out"the [..] menu updating mechanism".
I expected anticapitalista would recognize that I was referring to /usr/local/bin/desktop-menu

curiousity:

/usr/local/bin/desktop-menu is invoked via a dpkg post-install hook and... follow the white rabbit.

Just to post something this month.
I have been using this fluxbox version on 3 different machines since I found it, and I have been really happy with it. 
I can not say I have found any problems with it so far, except the core version missing some things it needs to work as intended. 

"core version" means"antiX core"?

thanks for the feedback. It's been in use continually here on several machines across a span of months.
A while ago, I installed it to antix17b2 and briefly tested. Seemed same (fine). Lemme know if you find any hiccups.

edited to add note-to-self:

As reversedog pointed out, fluxbox v1.3.5 supports placement of a"RootMenu" button in the toolbar.
The button glyph is currently hardcoded to show a right-pointing triangle.
Changing it to an upward-pointing triangle, and using stock button instead of a custom button
would eliminate the chore of creating labeltext localizations for the button.

github.com/fluxbox/fluxbox/blob/master/src/ToolFactory.cc#L153
xref: github.com/fluxbox/fluxbox/blob/master/src/FbTk/FbDrawable.cc

yes, I mean antix core. But, now that I think about it, it was the netinstall...