Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Installation and Upgrades / Install failure - "Failed to determine codename for release"
« on: July 28, 2011, 06:24:24 am »
Hi people
Tried to install Zentyal Server i386 2.0.4 after downloading cd ISO from Zentyal download site.
Made a cd from ISO after verifying ISO mdchecksum - ISO burned/verified with no detectable errors.
Verified CD from initial installer screen - no detected errors
After partitioning hard drive, receive the following error - "Failed to determine codename for release"
on the package installation phase
After searching the internet - both Zentyal forum, and Ubuntu forums finally found only one instance of this being reported here - http://ubuntuforums.org/showthread.php?t=1643938
It would appear this is a scripting error in the /var/lib/dpkg/cdrom-detect.postinstall file which is causing the script to exit prematurely before updating the debconf database.
Since I am not on a usable opensource OS (i.e. Linux) I am not able to find/fix the problem as listed in the above thread. Any suggestions as to how to open the iso, edit and correct the problem file, save the corrected file, and re-make the ISO would be appreciated.
Tried to install Zentyal Server i386 2.0.4 after downloading cd ISO from Zentyal download site.
Made a cd from ISO after verifying ISO mdchecksum - ISO burned/verified with no detectable errors.
Verified CD from initial installer screen - no detected errors
After partitioning hard drive, receive the following error - "Failed to determine codename for release"
on the package installation phase
After searching the internet - both Zentyal forum, and Ubuntu forums finally found only one instance of this being reported here - http://ubuntuforums.org/showthread.php?t=1643938
It would appear this is a scripting error in the /var/lib/dpkg/cdrom-detect.postinstall file which is causing the script to exit prematurely before updating the debconf database.
Since I am not on a usable opensource OS (i.e. Linux) I am not able to find/fix the problem as listed in the above thread. Any suggestions as to how to open the iso, edit and correct the problem file, save the corrected file, and re-make the ISO would be appreciated.
2
News and Announcements / Re: Planning to drop ebox-egroupware support, volunteers for maintaining it?
« on: August 20, 2010, 01:03:29 am »
I too am not surprised that eBox is dropping eGroupware, due to it's complexities in setting it up properly through eBox. I have been trying for several days to get this properly working, and have met with little success.
Having reviewed what others have stated in previous entries, I have to echo their sentiments; though I don't have an adequate solution/recommendation for a suitable replacement; we are still evaluating several other options/solutions but have not found any of them truly suitable, mainly due to little quirks here and there.
What I believe eBox developers really need to do is request input from the community at large -- maintainers and users alike.
Put together a survey letter and ask system integrators, current customers, potential customers, and users of the product
1) what they would like to see in all-in-one management package,
2) what they would like to see in a all-in-one user desktop package solution,
3) what they are currently using to accomplish their job today,
4) what are the future plans for further applications that each one will require,
5) does the customer/future prospect already have a groupware solution in place, that eBox needs to be integrated with?
6) If they have their own groupware solution in place, will they need outside assistance to develop integrated package front-ends, or just ide's/API's/modules that interface with said package that their in-house staff can take and make work, easily?
If the survey is crafted right, what may be derived from it is snap shot of the current market requirements and future trends that eBox may need to go. Does the customer want a solution that integrated all that eBox has to-date, but add to that, the requirements for modules that interface with third party groupware/CRM/ERP/ticketing systems as well.
While the development cycle may be increased, once the requirements have been determined, I believe in the end run you will have a much better product to offer the community, commercial and otherwise.
For now, IMHO, drop the groupware package, and concentrate on the remainder to get 2.0 out the door soonest; then develop the rest.
One other item that sorely needs addressing - Adequate, accurate, and up-to-date documentation. While it would be nice to have it when the product is released, if it followed with-in a few days that would be tolerable.
IMHO, complicated, all-in-one products that are released, without adequate, updated documentation, is just as worthless as software that has not been adequately tested/written/documented. A good example of how not to do this, is the 1.5/1.5-1 release that points only to the 1.4 documentation, even though the 1.5 series is clearly heavily modified, screen snapshots dont' match what product screens show, and customer is left to try to figure things out on their own -- you lose customers/prospects that way.
Having reviewed what others have stated in previous entries, I have to echo their sentiments; though I don't have an adequate solution/recommendation for a suitable replacement; we are still evaluating several other options/solutions but have not found any of them truly suitable, mainly due to little quirks here and there.
What I believe eBox developers really need to do is request input from the community at large -- maintainers and users alike.
Put together a survey letter and ask system integrators, current customers, potential customers, and users of the product
1) what they would like to see in all-in-one management package,
2) what they would like to see in a all-in-one user desktop package solution,
3) what they are currently using to accomplish their job today,
4) what are the future plans for further applications that each one will require,
5) does the customer/future prospect already have a groupware solution in place, that eBox needs to be integrated with?
6) If they have their own groupware solution in place, will they need outside assistance to develop integrated package front-ends, or just ide's/API's/modules that interface with said package that their in-house staff can take and make work, easily?
If the survey is crafted right, what may be derived from it is snap shot of the current market requirements and future trends that eBox may need to go. Does the customer want a solution that integrated all that eBox has to-date, but add to that, the requirements for modules that interface with third party groupware/CRM/ERP/ticketing systems as well.
While the development cycle may be increased, once the requirements have been determined, I believe in the end run you will have a much better product to offer the community, commercial and otherwise.
For now, IMHO, drop the groupware package, and concentrate on the remainder to get 2.0 out the door soonest; then develop the rest.
One other item that sorely needs addressing - Adequate, accurate, and up-to-date documentation. While it would be nice to have it when the product is released, if it followed with-in a few days that would be tolerable.
IMHO, complicated, all-in-one products that are released, without adequate, updated documentation, is just as worthless as software that has not been adequately tested/written/documented. A good example of how not to do this, is the 1.5/1.5-1 release that points only to the 1.4 documentation, even though the 1.5 series is clearly heavily modified, screen snapshots dont' match what product screens show, and customer is left to try to figure things out on their own -- you lose customers/prospects that way.
Pages: [1]