On Thu, 12 Apr 2018, Chase via cdesktopenv-devel wrote:
Hi Chase, you know you can get free email accounts from all over the
place right? :)
Comments inline...
Hi all,
I was advised to share a project of mine with this mailing list, as
people may find it helpful and have things to add. I am normally
opposed to having my private email be available to the public, but I
will make an exception in this case. I have been working on a CDE
package for Debian as of recent, and would like to share some of my
progress. Good news is, the package builds and with some proper
tweaking works without any major issues. The bad news is, is that
Debian's standards for packages immediately disqualifies the package
due to a number of issues. Luckily that number is small, but there
are some sizable issues. The issues are as follows:
- Non standard directory creation - this includes the directories C,
ja, and infolib on root and the existence of /usr/dt. The
contents of C and ja seem to be the exact same, so perhaps their
functionality can be merged and moved elsewhere, infolib doesn't
seem to have much of anything in it, and I don't really see the
purpose of it's existence. /usr/dt is the biggest problem facing
a CDE package. The short term simple solution would be to find a
different place to store it in a standard directory, but the goal
would be to specify a directory via the build mechanism, however
CDE ignores DESTDIR, so this could be difficult.
I'm a little confused by this, could you give more information?
CDE is hardcoded all over the place using the following directories:
/usr/dt/ - where CDE lives (binaries, libs, datafiles, etc)
/etc/dt/ - system level overrides for data stored in /usr/dt/
/var/dt/ - where CDE stored it's runtime dynamic info.
The C/ and ja/ are language specific directories for the C (ASCII) and
ja (Japanese) locales. They should not be located in root (/) if I
understand you completely... Could you elaborate on those?
It is known that a lot of these are hardcoded all over CDE and this is
a big task to undertake - though it is one we'd like to address
eventually, perhaps through some build options or some such. I seem
to recall an initial attempt was already done a year or 2 ago to make
a dent in it, but the task is certainly not done yet.
Is the lack of DESTDIR support a problem for packaging itself or a
problem in actual deployment of CDE on a given platform?
If there was a CDE package available, where would the above 3
directories typically go on a user's system?
- Missing source code (supposedly) - Lintian, when checking for
errors in the built package, finds binaries for dtbuilder and
instant, and says that they are missing source code due to them
being in binary format, but both of them have code. I suspect
that for dtbuilder, this is an issue relating to a case mismatch
in the makefile, it builds "dtbuilder" but cleans "Dtbuilder",
and thus when I run clean, it will not clean. As for instant, I
still have to look into it a bit further as it makes and cleans
just fine.
I fixed the problem with dtbuilder - the Imakefile had a typo such
that a "make clean" did not remove the dtbuilder binary itself. I
committed a fix to the cde-fixups-1 branch (more on that below).
The "Dtbuilder" file you mention is actually the Dtbuilder application
resource file which specifies much of dtbuilder's runtime behavior.
It is properly deleted on a make clean.
As for instant, I have no idea. If you could describe what you are
seeing that's wrong, I'm willing to investigate.
- Binaries defining rpath - dsdm, dtdspmsg, dtsrclean, dtsrcreate,
dtsrdbrec, dtsrdelete, dtsrhan, dtsrindex, dtsrkdump, dtsrload,
huffcode, imake and nsgmls all define rpath to /usr/lib, debian
explains why this is a problems here:
https://wiki.debian.org/RpathIssue
I've read this document, and I can't see it as a real problem for CDE,
however I can see thier point of view. Unfortunately their only real
suggestion is to use a new version of libtool - this is part of the
autoconf build system and CDE does not use that (maybe someday it
will).
Instead, CDE uses Imake. config/cf/lnxLib.rules uses -rpath during
linking. We could perhaps put that behind a configuration option
that, when enabled, disables the use of rpath when building
libraries. It's doable.
Any input from the BSD maintainers?
- Package has unnecessary activation of ldconfig trigger, this might be an
issue with CDE or a bug in lintian, I still need to look into it more.
That will need more investigation. One of the downsides to removing
rpath support is that you need some way of telling the linker where
libraries can be found.
Usually this would be done via ldconfig. I can not see any place in
CDE (is would be the installer stuff under admin/ in the src tree)
that calls ldconfig (for linux).
OpenBSD and FreeBSD platforms do call ldconfig in their
configShlibs.src files. This is not done for linux as we depend on
rpath to do the Right Thing™. How will the package installer inform
the system of the location of /usr/dt/lib/ if there is no rpath used?
- libssl - Package makes use of libssl, I need to find out to what degree, and
if it is actually a dependency like the wiki says, I will ignore it for now as
trying to get the correct dependency on my system is for some reason a
challenge. If libssl is truly needed for the project, the license must include
a linking exception clause as displayed here:
https://en.wikipedia.org/wiki/OpenSSL#Licensing
There is nothing in CDE that I'm aware of that uses openssl. It may
be that a system library we use does make use of openssl, but we can't
be held "responsible" for that.
I have no objection to adding this "exception clause" if it turns out
some part of CDE *really* is making use of openssl. Personally, this
linking exception just sounds like petty political BS to me, but hey,
lawyers gotta law.
But if we *have* to, we can. I just want to see where we specifically
call into/link with openssl first. Any hints welcome :)
Some issues that are not blocking a release but are frowned upon by
Debian: - Being a git release, since 2.2.4 isn't going to be seeing
any of the issues above patched, and also a few people tested 2.2.4
without libxp and it fails to build, whereas the new build works. I
decided to use the git release, however this is frowned upon due to
one of Debian's goals is being stable.
By "git release" I assume you mean the master branch?
We have been working on addressing some of these issues, particularly
coverity issues and compiler warnings. 2.2.4 is rather old, and we
would like to make a new release "soon".
We currently have two branches (aside from releases):
master - this is where current development happens. Up until
recently, this is also where we were commiting compiler warning and
coverity fixes as well. But, I broke dtfile, and Peter broke dthelp,
so we decided we would create another branch where we would do our
"current" work in order to keep master as stable as possible:
cde-fixups-1 - this is where the "most bleeding edge" stuff is going
on - compiler warnings, coverity issues, and bug fixes.
The plan is that periodically, we (once we are sure we didn't break
anything major) will merge this branch to master. Then we will delete
the cde-fixups-1 branch and start a new cde-fixups-2 branch and
continue on from there.
The coverity and compiler fixes are likely to take years to complete
at our current pace, but we do not want to destabilize master due to
mistakes.
For inital packaging, I would go with the latest and greatest in
cde-fixups-1 for now, until we merge it with master. At that point,
we might make a new official release. But until that release, there
is no reason why whatever work is need for packaging can't go on using
the latest stuff, even if they are not "official packages"...
- Setting rpcbind to insecure, maybe be fixable with some tweaks in libtirpc.
I am already working on that and it appears to be working great. I
had intended to commit that to cde-fixups-1 today, but other duties
prevented that. I will shoot for tomorrow.
- CVEs, although I know that with the first one mentioned, it was patched by
ibm and some other unix companies, does anyone have connections with them and
would be willing to ask them for the patch? They may even have one for the
second CVE as well.
Unfortunately I don't know anyone in those companies (especially
someone who would actually know) who would give me the time of day :)
Some of the CVE's are very vaguely described and trying to locate and
fix those problems on the information provided is mostly a waste of
time.
The main issues being worked on are compiler and coverity warnings, which means
that these issues are being put on hold until further notice unless me or
someone else decides to pick them up, so please le me know if you are
interested.
Well, not really... As explained above we are looking at some of the
issues you brought up.
The coverity, and in some cases, compiler warnings, often do point out
real problems that when fixed, improve CDE's stability (maybe
addressing one of those CVE's you mentioned). At least the serious
Coverity issues need to be triaged - it is not wasted work.
Actually, I'd love to have more people willing to work on that stuff,
but as we are a "volunteer operation", we get what we get when we get it.
I will look at the rpath issue (letting you disable it during a
build).
The hardcoded /usr/dt, etc is a much bigger issue that will take
significantly more time. But that should not slow down the
construction of a decent debian/ubuntu/whatever packaging framework
for CDE.
And the TIRPC issue should be hopefully solved in a couple days (in
cde-fixups-1).
Thanks!
--
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
