Re: [qmailtoaster] Re: Check data in vpopmail/dir_control table
Il 04/08/2012 16:26, xaf ha scritto: |--> Eric Shubert, le 04/08/2012 14:27, a dit : On 08/04/2012 02:42 AM, Alessio Cecchi wrote: Yes could be, currently the only certain thing is that domains in rcpthosts+morercpthosts are more that domain in dir_control table and so the dom_89 row is "corrupted". run /home/vpopmail/bin/vdominfo should add to dir_control missing domains dom_89 should be equal to (and so total rows -1) /home/vpopmail/bin/vdominfo |grep domain: | grep -v alias | wc -l if not, fix it manually Thanks, run /home/vpopmail/bin/vdominfo add the missing domains but not set the correct value in "cur_users" (set it to 0). With a query (SELECT * FROM dir_control WHERE cur_users='0';) I found this domains and manually corrected. with this commands I have found and correct the mismatched domains. One last question, in dir_control the dom_89 row report in "domains" filed "51" and "0" in all other fields. i do not think is correct. How can fix it? If someone explain me what the fileds means I can try to correct it manually. -- Alessio Cecchi is: @ ILS -> http://www.linux.it/~alessice/ on LinkedIn -> http://www.linkedin.com/in/alessice Assistenza Sistemi GNU/Linux -> http://www.cecchi.biz/ @ PLUG -> ex-Presidente, adesso senatore a vita, http://www.prato.linux.it - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vqadmin
On Monday 06 August 2012 12:07 PM, Eric Shubert wrote: On 08/05/2012 11:24 PM, Maxwell Smart wrote: Maybe a simple modification of the admin-toaster and e mail-toaster files is a better way to go so QMT is compliant and not required to be backward compatible. That is my intention. Stay tuned on the devel list for details. I'll take a look and ensure that there are no short tags in any of the scripts. PHP6 won't even allow short tags to be switched on. Bharath - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 8/6/2012 12:10 AM, Eric Shubert wrote: On 08/05/2012 02:52 PM, Philip Nix Guru wrote: On 08/05/2012 09:55 PM, Eric Shubert wrote: The subject software upgrades for QMT are now available. These long awaited upgrades are seriously overdue, as QMT has been using the same version of vpopmail since I built my first QMT over 6 years ago. I'm happy to say that this brings QMT up to date with all of the upstream software (TTBOMK - someone please notify if something newer is out there), and completes work on v1.4.x until such time as another upstream update becomes available. If I'm lucky, QMT v1.5.0 (CentOS 6.x compatibility) will be available before then. The recommended upgrade procedure is as follows: # yum update qmailtoaster-plus # qtp-newmodel If you're running the QTP version of dovecot: # yum update dovecot If you're running spamdyke (you should be if you're not): # qtp-install-spamdyke # service qmail restart If you choose to do things the hard way (manually), here are some notes off the top of my head. In addition to the 3 vpopmail related packages, the following packages should be rebuilt and reinstalled (qtp-newmodel will do this automatically): qmail-toaster courier-authlib-toaster courier-imap-toaster If you're running a dovecot version that you built yourself, you should rebuild and reinstall this as well after installing vpopmail. There are vpopmail database changes required by vpopmail-5.4.18+. You should run the qtp-convert script which will do them for you (qtp-newmodel does this as well). TTBOMK, all problems with vqadmin have been fixed. If you have a problem with it, let us know and we'll see if it can't be fixed. Likewise with vpopmail and quotas. There might be some database fixing that needs to be done to put things in sync for you, but we can cross those bridges as they come. As always, if you have any problems with this, please post here. Thanks to everyone who's helped along the way with this, especially our own Bharath, and Matt at inter7 (the present vpopmail maintainer). That's great usually I do compile all manually or even mod a bit the spec files but for once I just started the qtp-newmodel was for updating a "normal" not modified qmt Well I guess I ll have to do it manually :) . qtp-build-rpms v0.3.5 qtp-remove-pkgs v0.3.1 REMOVED control-panel-toaster from sandbox (not for real) Building daemontools-toaster-0.76-1.3.6 ... Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... qtp-build-rpms - binary rpm not found for daemontools-toaster-0.76-1.3.6 qtp-build-rpms - Script Error - aborting. Build failed, Exiting. Wrote: /root/src/rpm/RPMS/x86_64/daemontools-toaster-0.76-1.3.6.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + cd daemontools-0.76 + '[' -n /var/tmp/daemontools-toaster-0.76 -a /var/tmp/daemontools-toaster-0.76 '!=' / ']' + rm -rf /var/tmp/daemontools-toaster-0.76 + '[' -d /root/src/rpm/BUILD/daemontools-0.76 ']' + rm -rf /root/src/rpm/BUILD/daemontools-0.76 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + rm -rf daemontools-0.76 + exit 0 Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... Conclusion Then script is not handling .rpmmacros env variables that's a fault in my opinion Any idea why it put the rpm in /root/src/ instead of /usr/src/? That's appears to me to be the problem. What does # qtp-whatami show? It shouldn't be tough to fix this, even though your setup isn't apparently typical. Hey :) sure I know heheh, I am always using .rpmmacros to define where I want my rpms I am building rpms for different projects and I want mine in my homedir not in the usual /usr/src before I validate them for release. It is is a typical way to define by user where to store . But no worry I can disable it when using qtp-newmodel, just passing the infos for those who may get that error Thx for your great work
Re: [qmailtoaster] Re: vqadmin
Just change Eric Shubert wrote: On 08/05/2012 08:49 PM, Maxwell Smart wrote: FWIW, vqadmin still doesn't work. This is all I get when going to /admin-toaster Please post this to the users list. Have you done any customization to apache which might affect this? It's pretty much a stock Apache installation. I have upgraded to php5.3 though and that's when it stopped working. I upgraded today and can access vqadmin, qmlog-toaster and mrtg directly, but admin-toaster and e mail is not showing anything. I am guessing that's it php related, but haven't looked into the logs yet. - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 8/6/2012 4:30 AM, Philip wrote: On 8/6/2012 12:10 AM, Eric Shubert wrote: On 08/05/2012 02:52 PM, Philip Nix Guru wrote: On 08/05/2012 09:55 PM, Eric Shubert wrote: The subject software upgrades for QMT are now available. These long awaited upgrades are seriously overdue, as QMT has been using the same version of vpopmail since I built my first QMT over 6 years ago. I'm happy to say that this brings QMT up to date with all of the upstream software (TTBOMK - someone please notify if something newer is out there), and completes work on v1.4.x until such time as another upstream update becomes available. If I'm lucky, QMT v1.5.0 (CentOS 6.x compatibility) will be available before then. The recommended upgrade procedure is as follows: # yum update qmailtoaster-plus # qtp-newmodel If you're running the QTP version of dovecot: # yum update dovecot If you're running spamdyke (you should be if you're not): # qtp-install-spamdyke # service qmail restart If you choose to do things the hard way (manually), here are some notes off the top of my head. In addition to the 3 vpopmail related packages, the following packages should be rebuilt and reinstalled (qtp-newmodel will do this automatically): qmail-toaster courier-authlib-toaster courier-imap-toaster If you're running a dovecot version that you built yourself, you should rebuild and reinstall this as well after installing vpopmail. There are vpopmail database changes required by vpopmail-5.4.18+. You should run the qtp-convert script which will do them for you (qtp-newmodel does this as well). TTBOMK, all problems with vqadmin have been fixed. If you have a problem with it, let us know and we'll see if it can't be fixed. Likewise with vpopmail and quotas. There might be some database fixing that needs to be done to put things in sync for you, but we can cross those bridges as they come. As always, if you have any problems with this, please post here. Thanks to everyone who's helped along the way with this, especially our own Bharath, and Matt at inter7 (the present vpopmail maintainer). That's great usually I do compile all manually or even mod a bit the spec files but for once I just started the qtp-newmodel was for updating a "normal" not modified qmt Well I guess I ll have to do it manually :) . qtp-build-rpms v0.3.5 qtp-remove-pkgs v0.3.1 REMOVED control-panel-toaster from sandbox (not for real) Building daemontools-toaster-0.76-1.3.6 ... Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... qtp-build-rpms - binary rpm not found for daemontools-toaster-0.76-1.3.6 qtp-build-rpms - Script Error - aborting. Build failed, Exiting. Wrote: /root/src/rpm/RPMS/x86_64/daemontools-toaster-0.76-1.3.6.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + cd daemontools-0.76 + '[' -n /var/tmp/daemontools-toaster-0.76 -a /var/tmp/daemontools-toaster-0.76 '!=' / ']' + rm -rf /var/tmp/daemontools-toaster-0.76 + '[' -d /root/src/rpm/BUILD/daemontools-0.76 ']' + rm -rf /root/src/rpm/BUILD/daemontools-0.76 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + rm -rf daemontools-0.76 + exit 0 Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... Conclusion Then script is not handling .rpmmacros env variables that's a fault in my opinion Any idea why it put the rpm in /root/src/ instead of /usr/src/? That's appears to me to be the problem. What does # qtp-whatami show? It shouldn't be tough to fix this, even though your setup isn't apparently typical. Hey :) sure I know heheh, I am always using .rpmmacros to define where I want my rpms I am building rpms for different projects and I want mine in my homedir not in the usual /usr/src before I validate them for release. It is is a typical way to define by user where to store . But no worry I can disable it when using qtp-newmodel, just passing the infos for those who may get that error Thx for your great work Just an FYI -- that is the DEFAULT behavior of rpmbuild in RHEL/COS 6! The normal build location becomes /root/rpmbuild/* Dan -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail!
Re: [qmailtoaster] Re: vqadmin
On 8/6/2012 2:24 AM, Maxwell Smart wrote: Maxwell Smart wrote: You're right. I went back through some e mails and found a note from Dan about short tags in php.ini file. By default it's off in php5.3 install. It needs to be on according to Dan. I switched it on, restarted Apache and everything works as expected. Is there any security issue with having shot tags set to on? _*You mean someone actually READS these??? *_ OMG! I'll have to make sure I'm /RIGHT /more often! :-) FWIW: Short tags are not a real security issue unless you're in a mixed-scripting environment, in which case short tags can result in some odd (and sometimes extremely difficult to trace) problems -- especially with XML interoperability! The elimination of short tags in PHP5.3 is actually a change (ok, maybe a migration) in the language syntax However, according to some documentation, elimination of short tags may be REQUIRED in the next major revision (PHP6)... there does seem to be some push-back in the PHP community (regarding the deprecation of even allowing short tags - the community appears to strongly favor keeping at least the option available, so I wouldn't be surprised to see it re-enabled as an option...). However, as we (as a computing community) continue to move toward a platform-independent model, we're going to have to live better with other languages (like xml), and thus/as a coding style/, short tags need to be phased out as we maintain our PHP scripts (and templates). (It should be as easy as a global replace in php-only files!) Just my thoughts! Before you complain, remember how much you paid for them! Dan McAllister -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail!
Re: [qmailtoaster] Re: vqadmin
On 08/06/2012 06:47 AM, Dan McAllister wrote: On 8/6/2012 2:24 AM, Maxwell Smart wrote: Maxwell Smart wrote: You're right. I went back through some e mails and found a note from Dan about short tags in php.ini file. By default it's off in php5.3 install. It needs to be on according to Dan. I switched it on, restarted Apache and everything works as expected. Is there any security issue with having shot tags set to on? You mean someone actually READS these??? OMG! I'll have to make sure I'm RIGHT more often! :-) FWIW: Short tags are not a real security issue unless you're in a mixed-scripting environment, in which case short tags can result in some odd (and sometimes extremely difficult to trace) problems -- especially with XML interoperability! The elimination of short tags in PHP5.3 is actually a change (ok, maybe a migration) in the language syntax However, according to some documentation, elimination of short tags may be REQUIRED in the next major revision (PHP6)... there does seem to be some push-back in the PHP community (regarding the deprecation of even allowing short tags - the community appears to strongly favor keeping at least the option available, so I wouldn't be surprised to see it re-enabled as an option...). However, as we (as a computing community) continue to move toward a platform-independent model, we're going to have to live better with other languages (like xml), and thus as a coding style, short tags need to be phased out as we maintain our PHP scripts (and templates). (It should be as easy as a global replace in php-only files!) Just my thoughts! Before you complain, remember how much you paid for them! Dan McAllister -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail! Not just read saved for reference! Not complaining, just sharing. Alex mentioned to simply change the tags which I did and they still don't work with short tags off. I am sure it's something simple, but with the tag changed and short tags off it doesn't work, switch them on with no changes to the php code and it works. - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vqadmin
On 8/6/2012 10:26 AM, Maxwell Smart wrote: Alex mentioned to simply change the tags which I did and they still don't work with short tags off. I am sure it's something simple, but with the tag changed and short tags off it doesn't work, switch them on with no changes to the php code and it works. Short tags were intended to make "short and simple" php scripts less wordy and easier to read by non-programmers... Unfortunately, it meant that some ambiguities that were made possible by the use of short tags had to be handled in a "best guess" fashion. IMHO, for now, just leave the php code alone (for one, it calls other php sources that ALSO need to be fixed, and for another, the code that's there is "programatically sloppy" and needs to be fixed-up anyways). With my background in programming, I must admit that I strongly prefer the maintenance of code with as little change as possible... so my first instinct was to just enable short tags (making the entire PHP subsystem backward compatible) and forget about it. Upon further review, it's become clear to me that just allowing short tags will have to be a "band-aid" solution, and someone will have to look over the source material. Fortunately, there is no rush, as we'll be OK with the "band-aid" until RHEL/COS 7 (which should include PHP 6). More of my thoughts for free... I have a serious accounts receivable issue here! ;-) Enjoy! Dan McAllister -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 08/06/2012 06:07 AM, Dan McAllister wrote: On 8/6/2012 4:30 AM, Philip wrote: On 8/6/2012 12:10 AM, Eric Shubert wrote: On 08/05/2012 02:52 PM, Philip Nix Guru wrote: On 08/05/2012 09:55 PM, Eric Shubert wrote: The subject software upgrades for QMT are now available. These long awaited upgrades are seriously overdue, as QMT has been using the same version of vpopmail since I built my first QMT over 6 years ago. I'm happy to say that this brings QMT up to date with all of the upstream software (TTBOMK - someone please notify if something newer is out there), and completes work on v1.4.x until such time as another upstream update becomes available. If I'm lucky, QMT v1.5.0 (CentOS 6.x compatibility) will be available before then. The recommended upgrade procedure is as follows: # yum update qmailtoaster-plus # qtp-newmodel If you're running the QTP version of dovecot: # yum update dovecot If you're running spamdyke (you should be if you're not): # qtp-install-spamdyke # service qmail restart If you choose to do things the hard way (manually), here are some notes off the top of my head. In addition to the 3 vpopmail related packages, the following packages should be rebuilt and reinstalled (qtp-newmodel will do this automatically): qmail-toaster courier-authlib-toaster courier-imap-toaster If you're running a dovecot version that you built yourself, you should rebuild and reinstall this as well after installing vpopmail. There are vpopmail database changes required by vpopmail-5.4.18+. You should run the qtp-convert script which will do them for you (qtp-newmodel does this as well). TTBOMK, all problems with vqadmin have been fixed. If you have a problem with it, let us know and we'll see if it can't be fixed. Likewise with vpopmail and quotas. There might be some database fixing that needs to be done to put things in sync for you, but we can cross those bridges as they come. As always, if you have any problems with this, please post here. Thanks to everyone who's helped along the way with this, especially our own Bharath, and Matt at inter7 (the present vpopmail maintainer). That's great usually I do compile all manually or even mod a bit the spec files but for once I just started the qtp-newmodel was for updating a "normal" not modified qmt Well I guess I ll have to do it manually :) . qtp-build-rpms v0.3.5 qtp-remove-pkgs v0.3.1 REMOVED control-panel-toaster from sandbox (not for real) Building daemontools-toaster-0.76-1.3.6 ... Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... qtp-build-rpms - binary rpm not found for daemontools-toaster-0.76-1.3.6 qtp-build-rpms - Script Error - aborting. Build failed, Exiting. Wrote: /root/src/rpm/RPMS/x86_64/daemontools-toaster-0.76-1.3.6.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + cd daemontools-0.76 + '[' -n /var/tmp/daemontools-toaster-0.76 -a /var/tmp/daemontools-toaster-0.76 '!=' / ']' + rm -rf /var/tmp/daemontools-toaster-0.76 + '[' -d /root/src/rpm/BUILD/daemontools-0.76 ']' + rm -rf /root/src/rpm/BUILD/daemontools-0.76 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + rm -rf daemontools-0.76 + exit 0 Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... Conclusion Then script is not handling .rpmmacros env variables that's a fault in my opinion Any idea why it put the rpm in /root/src/ instead of /usr/src/? That's appears to me to be the problem. What does # qtp-whatami show? It shouldn't be tough to fix this, even though your setup isn't apparently typical. Hey :) sure I know heheh, I am always using .rpmmacros to define where I want my rpms I am building rpms for different projects and I want mine in my homedir not in the usual /usr/src before I validate them for release. It is is a typical way to define by user where to store . But no worry I can disable it when using qtp-newmodel, just passing the infos for those who may get that error Thx for your great work Just an FYI -- that is the DEFAULT behavior of rpmbuild in RHEL/COS 6! The normal build location becomes /root/rpmbuild/* Dan -- That did ring a bell after I sent the reply. Thanks for the confirmation, Dan. I need to modify qtp-whatami for this. Philip, you can change qtp-whatami to set BUILD_DIR to whatever your preference is. Since I have to change qtp-whatami anyhow for COS6, if you post the format of your .rpmmacros (hidden file in /root/ I'm presuming, yes?) I can have qtp-whatami check for this, and set the variable accordingly. Thanks. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: vqadmin
On 08/06/2012 07:36 AM, Dan McAllister wrote: On 8/6/2012 10:26 AM, Maxwell Smart wrote: Alex mentioned to simply change the tags which I did and they still don't work with short tags off. I am sure it's something simple, but with the tag changed and short tags off it doesn't work, switch them on with no changes to the php code and it works. Short tags were intended to make "short and simple" php scripts less wordy and easier to read by non-programmers... Unfortunately, it meant that some ambiguities that were made possible by the use of short tags had to be handled in a "best guess" fashion. IMHO, for now, just leave the php code alone (for one, it calls other php sources that ALSO need to be fixed, and for another, the code that's there is "programatically sloppy" and needs to be fixed-up anyways). With my background in programming, I must admit that I strongly prefer the maintenance of code with as little change as possible... so my first instinct was to just enable short tags (making the entire PHP subsystem backward compatible) and forget about it. Upon further review, it's become clear to me that just allowing short tags will have to be a "band-aid" solution, and someone will have to look over the source material. Fortunately, there is no rush, as we'll be OK with the "band-aid" until RHEL/COS 7 (which should include PHP 6). More of my thoughts for free... I have a serious accounts receivable issue here! ;-) Enjoy! Dan McAllister I agree with (most of) what Dan's said. We're doing to do it right, and fix the code. It's not that big of a deal. We could probably have had it pretty much done in the time we've researched and discussed it. Thank you. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 08/06/2012 06:29 PM, Eric Shubert wrote: On 08/06/2012 06:07 AM, Dan McAllister wrote: On 8/6/2012 4:30 AM, Philip wrote: On 8/6/2012 12:10 AM, Eric Shubert wrote: On 08/05/2012 02:52 PM, Philip Nix Guru wrote: On 08/05/2012 09:55 PM, Eric Shubert wrote: The subject software upgrades for QMT are now available. These long awaited upgrades are seriously overdue, as QMT has been using the same version of vpopmail since I built my first QMT over 6 years ago. I'm happy to say that this brings QMT up to date with all of the upstream software (TTBOMK - someone please notify if something newer is out there), and completes work on v1.4.x until such time as another upstream update becomes available. If I'm lucky, QMT v1.5.0 (CentOS 6.x compatibility) will be available before then. The recommended upgrade procedure is as follows: # yum update qmailtoaster-plus # qtp-newmodel If you're running the QTP version of dovecot: # yum update dovecot If you're running spamdyke (you should be if you're not): # qtp-install-spamdyke # service qmail restart If you choose to do things the hard way (manually), here are some notes off the top of my head. In addition to the 3 vpopmail related packages, the following packages should be rebuilt and reinstalled (qtp-newmodel will do this automatically): qmail-toaster courier-authlib-toaster courier-imap-toaster If you're running a dovecot version that you built yourself, you should rebuild and reinstall this as well after installing vpopmail. There are vpopmail database changes required by vpopmail-5.4.18+. You should run the qtp-convert script which will do them for you (qtp-newmodel does this as well). TTBOMK, all problems with vqadmin have been fixed. If you have a problem with it, let us know and we'll see if it can't be fixed. Likewise with vpopmail and quotas. There might be some database fixing that needs to be done to put things in sync for you, but we can cross those bridges as they come. As always, if you have any problems with this, please post here. Thanks to everyone who's helped along the way with this, especially our own Bharath, and Matt at inter7 (the present vpopmail maintainer). That's great usually I do compile all manually or even mod a bit the spec files but for once I just started the qtp-newmodel was for updating a "normal" not modified qmt Well I guess I ll have to do it manually :) . qtp-build-rpms v0.3.5 qtp-remove-pkgs v0.3.1 REMOVED control-panel-toaster from sandbox (not for real) Building daemontools-toaster-0.76-1.3.6 ... Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... qtp-build-rpms - binary rpm not found for daemontools-toaster-0.76-1.3.6 qtp-build-rpms - Script Error - aborting. Build failed, Exiting. Wrote: /root/src/rpm/RPMS/x86_64/daemontools-toaster-0.76-1.3.6.x86_64.rpm Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + cd daemontools-0.76 + '[' -n /var/tmp/daemontools-toaster-0.76 -a /var/tmp/daemontools-toaster-0.76 '!=' / ']' + rm -rf /var/tmp/daemontools-toaster-0.76 + '[' -d /root/src/rpm/BUILD/daemontools-0.76 ']' + rm -rf /root/src/rpm/BUILD/daemontools-0.76 + exit 0 Executing(--clean): /bin/sh -e /var/tmp/rpm-tmp.97447 + umask 022 + cd /root/src/rpm/BUILD + rm -rf daemontools-0.76 + exit 0 Installing daemontools-toaster-0.76-1.3.6 in the sandbox ... Conclusion Then script is not handling .rpmmacros env variables that's a fault in my opinion Any idea why it put the rpm in /root/src/ instead of /usr/src/? That's appears to me to be the problem. What does # qtp-whatami show? It shouldn't be tough to fix this, even though your setup isn't apparently typical. Hey :) sure I know heheh, I am always using .rpmmacros to define where I want my rpms I am building rpms for different projects and I want mine in my homedir not in the usual /usr/src before I validate them for release. It is is a typical way to define by user where to store . But no worry I can disable it when using qtp-newmodel, just passing the infos for those who may get that error Thx for your great work Just an FYI -- that is the DEFAULT behavior of rpmbuild in RHEL/COS 6! The normal build location becomes /root/rpmbuild/* Dan -- That did ring a bell after I sent the reply. Thanks for the confirmation, Dan. I need to modify qtp-whatami for this. Philip, you can change qtp-whatami to set BUILD_DIR to whatever your preference is. Since I have to change qtp-whatami anyhow for COS6, if you post the format of your .rpmmacros (hidden file in /root/ I'm presuming, yes?) I can have qtp-whatami check for this, and set the variable accordingly. Thanks. Hello Eric yes .rpmmacros is in the root of the user's dir # cat .rpmmacros %_topdir /root/src/rpm # ls /root/src/rpm/ BUILD RPMS SOURCES SPECS SRPMS
[qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 08/06/2012 10:21 AM, Philip Nix Guru wrote: yes .rpmmacros is in the root of the user's dir # cat .rpmmacros %_topdir /root/src/rpm # ls /root/src/rpm/ BUILD RPMS SOURCES SPECS SRPMS Thanks. I'll get this done with the next QTP release. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: vpopmail-5.4.33, qmailadmin-1.2.16, vqadmin-2.3.7 upgrades
On 8/6/2012 1:21 PM, Philip Nix Guru wrote: Hello Eric yes .rpmmacros is in the root of the user's dir # cat .rpmmacros %_topdir /root/src/rpm # ls /root/src/rpm/ BUILD RPMS SOURCES SPECS SRPMS Just my 2-cents worth... In RHEL/COS 6, the default build is ~/rpmbuild Dan McAllister -- IT4SOHO, LLC PO Box 507 St. Petersburg, FL 33731-0507 CALL TOLL FREE: 877-IT4SOHO We have support plans for QMail!