On 04/23/2018 05:43 PM, Chase via cdesktopenv-devel wrote:
Not quite sure why my license file turned into a binary, take this one
instead.
[...]
This is a long email.
On April 23, 2018 4:38 PM, Chase via cdesktopenv-devel
<cdesktopenv-devel@lists.sourceforge.net> wrote:
Hi all,
I actually sent out this email about a week ago, but accidentally sent
it to only one person, I do have some small additions to my progress
though. I have some patches attached to this email, mostly spelling
fixes and code cleanup.
I want to provide a small update on some progress I've made on the
package, but first I want to say thank you to Jon for fixing dtbuilder
and the rpcbind situation, great work!
I have an update on the instant situation, instant makes, but only
cleans when run inside the folder, when clean is run at the cde top
folder, it doesn't clean, thus triggering the error.
Can you open a ticket for this? It will require investigation....
Next, a problem I forgot to mention, many of the files are missing
copyright headers, I will attach a text file with all the files,
because this email is long enough as it stands.
I looked at that file - there's alot to go through there.
The next issue is a reevaluation of the dependencies on debian
systems. The wiki states that git is needed to download and build the
software, but you can download a snapshot of the most current
repository or any older repositories without git. Build essentials is
stated to also be needed, but debian and debian based systems already
provides this at install.
Ok, well Are you saying the wiki is wrong on this? If you have a
sourceforge ID, I can give to access to fix the wiki. Send it to me in
a private email.
I do know that at least the ubuntu's need it, so maybe this is just
debian specific.
On debian, software is depended on in three
ways, it can be depended, which means that the package will flat out
not work unless this software is installed, recommended, which means
the package may suffer breakages without it, but still functions, and
suggests, which means the package will not suffer any problems if the
dependency is not met and is merely an enhancer. The qualifiers should
be specified in the wiki or to me directly so I can build the package
properly, because putting these in the wrong categories can cause
problems. Putting xfonts in depends, for example, makes lintian throw
an error, because it is extremely rare for a program to cease
functionality altogether simply due to a missing font, so it either
goes into recommends or suggests depending on if functionality is
missing without it, so I am putting it into recommended unless someone
can let me know if CDE still works without it, or on the flipside, is
written in a way in which CDE will not function at all without them.
I am not sure what "xfonts" is exactly. CDE absolutely requires fonts
in order to work. The ones listed, are the ones needed. Very little
will work without fonts.
I
would test these dependencies myself, but I have been busy building
the package and writing documentation, I am going to ask the package
sponsors to join this mailing list and maybe they will be able to
provide insight into the situation. libssl seems to be completely
pointless, and can be removed from the dependency list, I did a quick
grep through the code and there is no code relating to libssl. Tcl
also seems to be minimally used, only appearing in
/programs/dtdocbook/tcl/*, this is by no means a priority, but if
someone could write tcl out of those files in that folder that would
eliminate one more needless dependency. Ksh and it's related programs
should also be a bit more shell independent if at all possible as to
eliminate to dependency on ksh, but again, that isn't the biggest
issue as of now. I haven't looked much into the other dependencies,
but I am sure some of them could be put into recommended, suggested,
or removed entirely.
Ok...
As for the /usr/dt situation, I understand that backwards
compatibility is an important issue when it comes to scripts, but on
the flip side, many unix platforms simply use older versions of CDE as
it is, so those who want a current offering probably won't be affected
and those who want to maintain backwards compatibility are still using
CDE 1.0. As for /usr/dt being the standard, I looked around, and not
from POSIX, SUS, IEEE, ISO or FHS could I find a single reference to
/usr/dt being the standard directory for CDE, the closest thing I
could find to a CDE standard was ISO 1295 for motif, but it has since
been withdrawn.
It was the "defacto" standard they chose. Everything in /usr/dt. I
agree, being able to place this stuff more "naturally" into the system
(/usr/bin, /usr/lib) is desirable. But it's going to take work.
One avenue of approach might be to modify the installation scripts and
datafiles (in databases/) to handle some of these problems. Perhaps,
including the DESTDIR problem. Essentially a script generates the .db
files from .src and .udb files. Then another script reads that data and
copies files to their destination, ensuring proper permissions and the
like. I'll bet the bulk of the work *might* be doable in that module alone.
Others will have to be handled directly where code or scripts DEPEND on
a hardcoded /usr/dt. Patches welcome :)
It may have been the standard back in the 1990s,
however it is not today, and should be made to (ironically) comply
with modern day standards. I have two desktops installed on my system,
lxde and lxqt, both of them put data from usr into their respective
subcategories, /usr/share, /usr/bin, /usr/lib, and none of them define
something like /usr/lxde/* and put all the files there, so a quick fix
would be replacing all the hardcoded dt stuff with it's proper place
in usr, but unfortunately, /usr/dt can not remain if a debian package
is still desired, I could ask my sponsors if they would be willing to
override the issue, but an override usually comes with the presumption
that the issue will be fixed soon or that attempting to fix the
problem would break functionality so badly it would be
counterproductive. The latter statement does not seem to be true, and
thus it would only be putting off a fix. Also, as for /etc/dt and
/var/dt, these are fine and debian doesn't throw any errors, however,
/var/dt could be broken up even further into the provided
subdirectories, but /var/dt is valid as of now. As for symlinking, I
think that it would be the equivalent of putting a painting on a hole
in the wall. The DESTDIR problem is more of an inconvenience more than
anything, this is the bug that referenced it:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689098
I don't think anybody disagrees with you here.
As for infolib, C and ja, debuild creates a fake root in the package's
files in order to test the package, maybe this is some sort of glitch
regarding build location? The errors being given to me say that when
the package is installed, these directories are being installed on root.
I can't speak for fakeroot, but I do know that installation in a
"normal" system is not installing those in root.
I've been busy as of late getting some install scripts to work, I
tried some from a package made by a sparkylinux maintainer, however
those scripts throw more errors than they are worth, so I will be
looking at implementing the ones provided by CDE. Debian is now
throwing errors about the recursive chown, (chmod -R a+rwx /var/dt for
a post install script) Debian gives these suggestions in order to
replace recursive chown:
- If your package uses a static uid, please perform the chown at
package build time instead of installation time.
- Use a non-recursive call instead, ensuring that you do not change
ownership of files that are in user-controlled directories.
- Use runuser(1) to perform any initialization work as the
user you were previously chowning to.
Yes, those are generally bad - in this case it's probably a "reset" in
case people were mucking around in there - the whole 777 perms on
/var/dt is not so good either. Remove it, see what happens.
[...]
From the attached license file:
Notes:
A number of these files could very well be cruft, in that case they should be
deleted instead of relicensed. (why are the same icons found in three different
locations? can these be consolidated?)
programs/types/dt-toolbox literally only says "this file is obsolete", consider
deleting?
Yes - there is definitely cruft there. Feel free to delete it (in a
patch of course).
/programs/dtinfo/dtinfogen/infolib/etc/dataflow.doc appears to be a proprietary
word doc, if it isn't it should be renamed as to not confuse people and file
managers which try to open .doc files in libreoffice.
It's a: FrameMaker document (4.0 K)
Yep, that should be deleted too, unless someone with Framemaker wants to
convert it to a pdf or something we can keep.
programs/dtdocbook/sgmls/sgml-mode.el has an incorrect address for the FSF,
they moved offices sometime after the publishing of the gplv1, their new
address from the lgpl should be posted.
Patch welcome.
Also, I went back to the initial posting of the source, and unless the file was added
at the exact same time the code was released, the open group and all corporate
>contributors of CDE have been violating the GPL for a solid 20+ years, and the
unixes/openvms that still use older versions of CDE are using license-violating
>software.
What does this mean? The .el file?
Some READMEs on my file manager (PCmanFM) are getting confused as C source
code, not sure if this is a bug with PCmanFM or formatting in the readme.
Maybe they have some C code in them? Example?
I omitted all of the dot files mentioned because if I didn't this would be much
to long of an email, if you want to see the full list for yourself, on a linux
system, run licensecheck -r *
All of the "dot" files should be generated at build time... At least I'm
not aware of anything hidden in dot files within the source code itself.
--
Jon Trulson
"But when I'm in command, every mission's a suicide mission."
- Zapp Brannigan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
