> --skipping because DONTDO is enabled.Package =net-misc/
> cfengine-2.1.22-r1 not installed.
Whoops, need a linefeed there.
--- package.c-0713 Fri Jul 13 12:14:02 2007
+++ package.c Fri Jul 13 12:18:08 2007
@@ -246,7 +246,7 @@
Verbose("InstallPackage(): using '%s'\n", instcmd);
if (DONTDO)
{
- Verbose("--skipping because DONTDO is enabled.");
+ Verbose("--skipping because DONTDO is enabled.\n");
result = 1;
}
else
> Match status for =net-misc/cfengine-2.1.22-r1 is 0
> cfengine:YYYYYYYYY: Package manager will be invoked as /usr/bin/emerge
> BuildCommandLine(): Adding package 'hup_cfservd' to the list.
> BuildCommandLine(): Adding package '=net-misc/cfengine-2.1.22-r1'
> to the list.
> Resolved command is '/usr/bin/emerge hup_cfservd =net-misc/
> cfengine-2.1.22-r1'
> InstallPackage(): using '/usr/bin/emerge hup_cfservd =net-misc/
> cfengine-2.1.22-r1'
> --skipping because DONTDO is enabled.Package =mail-mta/
> postfix-2.2.10 not installed.
> Match status for =mail-mta/postfix-2.2.10 is 0
I have to admit that I'm very confused as to why we aren't seeing the
following log message for each package. I think there is something
odd here.
PortageCheckPackage(): Requested (snip)
Also, clue me in on the = signs. Are these part of the package name?
> cfengine:YYYYYYYYY: Package manager will be invoked as /usr/bin/emerge
> BuildCommandLine(): Adding package 'bounce_smtp' to the list.
> BuildCommandLine(): Adding package '=mail-mta/postfix-2.2.10' to
> the list.
> Resolved command is '/usr/bin/emerge bounce_smtp =mail-mta/
> postfix-2.2.10'
> InstallPackage(): using '/usr/bin/emerge bounce_smtp =mail-mta/
> postfix-2.2.10'
> --skipping because DONTDO is enabled.
I'm interested in why bounce_smtp was parsed before postfix, but the
configuration files you includes aren't complete enough for me to
figure that out... any clues on your part?
(note that none of my patches affect the parsing, I'm just curious)
> BuildCommandLine(): Adding package 'x??r12' to the list.
> Resolved command is '/usr/bin/emerge x??r12'
> InstallPackage(): using '/usr/bin/emerge x??r12'
> *** glibc detected *** double free or corruption (fasttop):
> 0x8014c968 ***
> --skipping because DONTDO is enabled.Aborted
>
> * The obvious problem I see is that it somehow parsed in garbage
> text, tried to do something with it, which caused the glibc output
> and `Aborted' on stderr. In vi, the same garbage string shows up
> as [EMAIL PROTECTED] On different runs, it comes up with different non-
> ASCII characters, even just changing things like excluding other
> actions, without changing any configs. I've also been rearranging
> the package order for the last half-hour to try and find some
> pattern for which package causes this, but it neither seems to be
> related to the number of packages added to the list, the current
> package line just added, or the next package to add. But, given a
> certain config and command line, it always happens in the same place.
If you can find the most minimal configuration which shows this, I'd
appreciate it. Keep in mind we might be hitting the end of a 4096-
byte buffer, so also check for position or such.
> * The package `hup_' and `bounce_' "packages" that were parsed are
> really elsedefine=() classes.
I never touched the parsing code. I'll double-check to confirm that
I'm not adding them to the workload, but I think it's more likely a
parsing order thing. Can you provide the entire configuration
including cf.smtp and where it is included?
I'm also note sure why install was called so often. Try this patch
as well:
--- do.c-0713 Fri Jul 13 12:28:34 2007
+++ do.c Fri Jul 13 12:33:04 2007
@@ -2769,8 +2769,9 @@
Verbose("Match status for %s is %u\n", ptr->name, match );
/* Process any queued actions (install/remove). */
- if ((pending_pkgs) && ((ptr->action != prev_action) || (ptr-
>pkgmgr != prev_pkgmgr)))
+ if ((pending_pkgs != NULL) && ((ptr->action != prev_action) ||
(ptr->pkgmgr != prev_pkgmgr)))
{
+ Verbose("New action of %s didn't match previous action %s for
package %s\n", pkgactions[ptr->action], pkgactions[prev_action], ptr-
>name );
ProcessPendingPackages(prev_pkgmgr, prev_action, &pending_pkgs);
DeleteItemList( pending_pkgs );
}
(note that I haven't tested this last patch as I'm tied up at work
right now, this was "off the top of my head" but should work...)
--
Jo Rhett
senior geek
Silicon Valley Colocation
Support Phone: 408-400-0550
_______________________________________________
Bug-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/bug-cfengine
