Regarding php-gacl, that project is dead. We have embedded the project into OpenEMR’s codebase/database along with some fixes/customizations.
Regarding adodb, that would be tough since each version change would require intensive testing; Kevin likely has more to add here.
Regarding phpmyadmin, that is basically to make it easier for diy types. I’ve been a heavy proponent for including that in the past, but it may finally be time to let that one go (because it’s too tough to keep up with security updates on the phpmyadmin stuff).
Is there an advantage to using a symlink rather than just setting apache to point to it (like is done in the fixed not yet released openemr package)?
The php5-adodb is not the library for database access. It is a subset of code that is compiled as c for optimization. The PHP files are still needed in order to work.
Kevin and Brady - Thanks for the responses. Will make note that the GACL
and adodb stuff need to be left alone.
There’s a nice phpMyAdmin package that installs and configures correctly
that we should probably just point people too if using Linux (phpmyadmin)
or installing it in Windows from the site.
Probably no clear benefit to symlink things should just point to it and not
muddle up the file system.
The problem with putting anything in /var/www/html is that the Debian
Policy says that’s not allowed (it’ll spit out errors when you run lintian
which will prevent it from being accepted to Debian repos - the whole point
of doing this little exercise).
Ok, phpmyadmin will come out, others stay in and keep plugging away at
apache, etc.
Interesting phpmyadmin is using a Apache configuration method similar to
the way you were first doing it (not as a site) … which on second thought
might be a better option. I am pretty much going to replicate it since
it’s so clean.
The php5-adodb is not the library for database access. It is a subset of
code that is compiled as c for optimization. The PHP files are still needed
in order to work.
That Debian package installs this extension, which does not sufficiently
handle the adodb dependency OpenEMR needs. ADOdb download | SourceForge.net
My Out events are still orange after patching. Are there any other steps you took to revert back to the selected color in Administration > Other > Calendar > Categories? I tried to clear smarty cache and clear local browser cache with no change.
It seems like the real elephant in the room here is the /var/www (or /var/www/html) paths. It would be useful to know how strict this requirement is and whether it can be overrided; considering it is a lintian Error rather than a Warning guessing not much leniency, but you never know. If it does need to move, then makes sense to see what phpmyadmin does (I am guessing phpmyadmin does not separate it’s writable config files from the read-only, so perhaps it would only involve migrating it during an upgrade; migrate it in preinst maintainer script and then the rest happens automatically).
Once that is out of the way, then seems like just need to clean up the codebase some more to deal with the left over random lintian stuff. In the maintainer scripts, I am also confident that the direct modification of the php.ini file will need to go (phpmyadmin does a cool thing where it overrides php settings in the apache site config file, if needed).
Brady - Sorry work/family have gotten in the way of keeping up with
emails. As you suspect there is no bending on the lintian Error’s.
Warnings I think most will let slide … but only if we are willing to look
into fixing them. I agree with most of the error messages anyway. I have
a package that has most of the Error’s taken care of … but your nicely
written upgrade scripts/etc need to be re-worked at some point - lintian
complains about the templates, debconf stuff and something about debhelper
tags that we are missing.
I am first focused on just cleaning up the structure and getting ride of
the extra license files that needed to be merged to make it happy.
It seems like the real elephant in the room here is the /var/www (or
/var/www/html) paths. It would be useful to know how strict this
requirement is and whether it can be overrided; considering it is a lintian
Error rather than a Warning guessing not much leniency, but you never know.
If it does need to move, then makes sense to see what phpmyadmin does (I am
guessing phpmyadmin does not separate it’s writable config files from the
read-only, so perhaps it would only involve migrating it during an upgrade;
migrate it in preinst maintainer script and then the rest happens
automatically).
Once that is out of the way, then seems like just need to clean up the
codebase some more to deal with the left over random lintian stuff. In the
maintainer scripts, I am also confident that the direct modification of the
php.ini file will need to go (phpmyadmin does a cool thing where it
overrides php settings in the apache site config file, if needed).
Hello everyone! Regarding the bug about the ‘OUT’ event splitting the previous event, changing it’s duration from 0 minutes to 15 minutes fixes this problem. I’ll send the patch in when I have time.
