Created attachment 373416 [details] cde-2.2.1.ebuild The Common Desktop Environment, the classic UNIX desktop, the Industrial Standard of GUI. Now is free! The first free release =cde-base/cde-2.2.1 Successfully built on my amd64 host according upstream scenario: https://sourceforge.net/p/cdesktopenv/wiki/LinuxBuild/ Yet NOT done (in ebuild): 1. Check locales: de_DE.ISO-8859-1 es_ES.ISO-8859-1 fr_FR.ISO-8859-1 it_IT.ISO-8859-1 2. Check status (and options) of rpcbind service: Modify rpcbind to run in insecure mode (-i) 3. Install script was succeed with current stable gawk, although some people find failures: https://sourceforge.net/p/cdesktopenv/wiki/Slackware/ 4. The only question to deps parse is identity of fonts packages: xfonts-100dpi (for nicer looking fonts) xfonts-100dpi-transcode or xfonts-100dpi-transcoded
Created attachment 373418 [details] cde-9999.ebuild Slightly different ebuild for live version.
Created attachment 373976 [details] cde-2.2.1.ebuild Fixed version of ebuild, performing all necessary checks. Note: upstream's install script tries to install directly in system tree, that is incompatible with portage (default src_install() works fine). Live version for now is broken, so not updated yet.
Given that there are still known issues within CDE's codebase, including potentially unresolved security issues, this is probably not ready to go into Portage right now, but it's still pretty neat. Keep this updated as upstream fixes things and it can probably go in at some point. My only curiosity is, does it need its own category? Wouldn't it fit better under the existing x11-wm instead?
(In reply to Sergey S. Starikoff from comment #2) > Created attachment 373976 [details] > cde-2.2.1.ebuild > > Fixed version of ebuild, performing all necessary checks. > Note: upstream's install script tries to install directly in system tree, > that is incompatible with portage (default src_install() works fine). > > Live version for now is broken, so not updated yet. cde-2.2.1 postinstall fails for me: >>> Installing (1 of 1) x11-wm/cde-2.2.1 Unable to find /usr/dt/config/dtterm.ti ./configRun: line 1070: return: can only `return' from a function or sourced script * ERROR: x11-wm/cde-2.2.1::local failed (postinst phase): * linux postinstall check failed * * Call stack: * ebuild.sh, line 93: Called pkg_postinst * environment, line 181: Called die * The specific snippet of code: * ./configRun -e || die "linux postinstall check failed"; * Also, the /usr/dt/config directory (which contains Xsession) is not merged into the live filesystem. This might be an artifact of the above error. I moved this over manually and can get the greeter to half-work over a tunneled ssh (to an Xming instance on Windows), but no login prompt appears.
(In reply to Joshua Kinard from comment #3) > My only curiosity is, does it need its own category? Wouldn't it fit better > under the existing x11-wm instead? The CDE is NOT WM. It worths its own category neither less than XFce, LDXE and other Razor-qt's. (In reply to Joshua Kinard from comment #4) > (In reply to Sergey S. Starikoff from comment #2) > > Created attachment 373976 [details] > > cde-2.2.1.ebuild > > > > Fixed version of ebuild, performing all necessary checks. > > Note: upstream's install script tries to install directly in system tree, > > that is incompatible with portage (default src_install() works fine). > > > > Live version for now is broken, so not updated yet. > > cde-2.2.1 postinstall fails for me: > > >>> Installing (1 of 1) x11-wm/cde-2.2.1 > Unable to find /usr/dt/config/dtterm.ti > ./configRun: line 1070: return: can only `return' from a function or sourced > script > * ERROR: x11-wm/cde-2.2.1::local failed (postinst phase): > * linux postinstall check failed > * > * Call stack: > * ebuild.sh, line 93: Called pkg_postinst > * environment, line 181: Called die > * The specific snippet of code: > * ./configRun -e || die "linux postinstall check failed"; > * > > Also, the /usr/dt/config directory (which contains Xsession) is not merged > into the live filesystem. This might be an artifact of the above error. I > moved this over manually and can get the greeter to half-work over a > tunneled ssh (to an Xming instance on Windows), but no login prompt appears. Due to some unresolved usability issues I've don't merged the CDE in my filesystem tree yet. For this issue I expect this script is unsufficently compatible with portage's standards (note, that install script for me failes). Maybe, together with its own category the CDE will need also its own eclass. I think it will be right to continue discuss issues opf installation scripts in the upstream's tracker: https://sourceforge.net/p/cdesktopenv/tickets/33/ And the list of mentioned issues: 1. I've put into dependency list the media-fonts/font-bitstream-100dpi. But test run of dtterm showed this is unsufficient. Mabe you knows more about fonts? 2. The locale requirements also look like very strange: I don't need neither German, nor French locales. But I need the Russian one. And for now the preferrable is not ISO, but UTF8 one. 3. Install article in wiki mentions inetd. But in Gentoo it's virtual (commonly for xinetd?). Mabe it is a reason of your merge issue?
Created attachment 384338 [details] cde-2.2.4.ebuild New version was release at the end of July. Build is OK, at least or me.
Created attachment 384652 [details] cde-9999.ebuild Probably fixed version of live ebuild. But for now it fails to install. For details see bug #522690
Created attachment 384666 [details] cde-9999.ebuild Fixed ebuild for git build.
Comment on attachment 384338 [details] cde-2.2.4.ebuild 2015-05-10 was released new version of The CDE: 2.2.3. It builds with ebuild from 2.2.2, so renaming file. Development still incomplete, for example 2.2.3 seems to have just initial support of UTF8 locales. QA Notices at install phase are reported in upstream tracker: https://sourceforge.net/p/cdesktopenv/tickets/45/ https://sourceforge.net/p/cdesktopenv/tickets/46/
Tried the 2.2.3 ebuild, and ran into an issue where 'ksh', as a dependency, tries to build, but that fails due to not finding the 'nmake' command. Bug #555670 was opened for this, so I am adding that as a dependency. 'nmake' appears to refer to AT&T's version, but that doesn't seem to be carried in the 'ast-base' package stored on floppym's devspace.
Why on earth would an X11 window manager depend on app-shells/ksh? That makes no sense.
(In reply to Mike Gilbert from comment #11) > Why on earth would an X11 window manager depend on app-shells/ksh? Probably because The CDE is NOT a window manager, but the DESKTOP ENVIRONMENT? You should not be confused with the fact, that just for now it's build system doesn't provide modular build. And I see nothing strange in that some component(s?) of over twenty year old DE depends on Korn shell. More interesting for future is the question about zsh compatibility (could zsh satisfy dependencies on ksh?). Project's page shows many commits not included in latest release. So I recommend to use for tests the live ebuild.
(In reply to Joshua Kinard from comment #10) > Tried the 2.2.3 ebuild, and ran into an issue where 'ksh', as a dependency, > tries to build, but that fails due to not finding the 'nmake' command. Bug > #555670 was opened for this, so I am adding that as a dependency. 'nmake' > appears to refer to AT&T's version, but that doesn't seem to be carried in > the 'ast-base' package stored on floppym's devspace. It seems the build failures with both the in-tree app-shells/ksh and the dead app-shells/pdksh are tied to gcc-4.9.x and up to 5.x. I was able to build pdksh with gcc-4.8.5 without a problem, then switch back to the 5.x compiler chain and build the rest of CDE's dependencies. Currently building CDE itself, but I don't know when I'll get to test it if it succeeds.
Created attachment 418052 [details] /usr/dt/bin/Xsession copied out of CDebian ISO I got CDE-2.2.3 to compile, but it appears the 2.2.3 release is missing the /usr/dt/bin/Xsession file entirely, which makes starting CDE rather impossible. I even looked around in the upstream git tree and cannot where this file is supposed to originate from. I managed to find an ISO of CDebian here: http://www.securitronlinux.com/bejiitaswrath/a-look-at-the-cde-unix-desktop-running-on-debian/ And extracted the Xsession from there. Still doesn't work, but it's progress. Running dtlogin directly authenticates the user, but something crashes and dtlogin just reloads. Running "startx /usr/dt/bin/Xsession" is loading Xorg up and apparently running the Xsession, but nothing loads up. Just a black background with the characteristic "X" mouse cursor. Giving up for now and will return back to this in a few weeks, but for now, I've attached the Xsession from CDebian so that others can find something to work with.
(In reply to Joshua Kinard from comment #14) > Running dtlogin directly authenticates the user, but something > crashes and dtlogin just reloads. Possibly stupid suggestion: What about enabling core-dumps with writing properly named cores into dedicated directory as it's described for now in https://wiki.gentoo.org/wiki/Project_Talk:Quality_Assurance/Backtraces It will provide you at least, without analyzing core itself, info about _what_ binary crashes and on what signal. P.S. What about confirmation of this bug? ☺
(In reply to Sergey S. Starikoff from comment #15) > (In reply to Joshua Kinard from comment #14) > > Running dtlogin directly authenticates the user, but something > > crashes and dtlogin just reloads. > > Possibly stupid suggestion: > What about enabling core-dumps with writing properly named cores into > dedicated directory as it's described for now in > https://wiki.gentoo.org/wiki/Project_Talk:Quality_Assurance/Backtraces > It will provide you at least, without analyzing core itself, info about > _what_ binary crashes and on what signal. > > P.S. What about confirmation of this bug? ☺ I'm not even certain something is crashing. Could be another error condition causing the desktop to not load and thus X is re-invoking dtlogin. Investigating X11 errors is not one of my strong points, so I haven't invested the time to deep dive into it. And I haven't "confirmed" the bug because it's in maintainer-wanted status. I'm playing with the ebuild mainly out of curiosity, but I lack the time and knowledge to take over the bug, add CDE to the tree, and maintain it at the present time. In its present state, CDE is not suitable for addition to Gentoo, because it has some awkward build requirements, such as the hardcoded language locales and forces a reduction in system security by running rpcbind in insecure mode. On top of that, the requirement on pdksh, which was removed from the Gentoo tree when the real ksh was open-sourced is a further blocker (if someone could test to see if the real ksh can replace pdksh, that'd be an improvement). I periodically check-in on the upstream SourceForge site to see how they're doing on addressing these issues, but I suspect it's going to take a long time to really bring the CDE codebase around to current standards. It'll get these in time, but for now, this bug is effectively a tracking bug on CDE's upstream status.
Comment on attachment 384338 [details] cde-2.2.4.ebuild 2016-06-19 was released The CDE 2.2.4. Ebuild the same with 2.2.3.
Could anybody explain upstream developer the idea of QA Notice about pre-stripped binaries and way to fix it? Upstream bug https://sourceforge.net/p/cdesktopenv/tickets/58/
(In reply to Sergey S. Starikoff from comment #18) > Could anybody explain upstream developer the idea of QA Notice about > pre-stripped binaries and way to fix it? > Upstream bug https://sourceforge.net/p/cdesktopenv/tickets/58/ I haven't logged into SourceForge in forever, so I can't comment on the issue directly right now, but basically, the QA notice means that the CDE build process is stripping binaries itself, instead of letting the ebuild system handle that. In the event someone wanted to actually try to backtrace some code, they'd have to figure out how to disable the stripping done by CDE's build system, instead of simply turning off stripping via USE flags or such. So mostly, it's just a notice that debugging this package will be a *lot* harder than normal because something in the CDE code is doing the stripping. If we're lucky, it's a toggle-able setting somewhere, but can't rule out that it may also be hardcoded, too.
Created attachment 552168 [details] cde-9999.ebuild Clean obsolete dependency on x11-libs/libXp (see bug #649076, upstream comment «libxp-dev (not available on latest linuxes, skip)»).
Ebuild contains some not fixed yet issues: * The ebuild is installing to one or more unexpected paths: * * /appconfig * /app-defaults * /C * /infolib * /ja * /misc * /usr/dt * * Please fix the ebuild to use correct FHS/Gentoo policy paths. Is it right to fix them in ebuild, or it points on some upstream misses in build system?
Just in case anyone is interested, I have my own version of the ebuild, currenty 2.3.1-autotools available here: https://github.com/nephros/gentoo/tree/cde-devel/cde-base
^ nice work! I have kitchen-sink ebuild using old build system here https://github.com/gyakovlev/gentoo-overlay/tree/master/x11-wm/cde note, above overlay is not for public consumption, just copy ebuild to yours if you need.
