----- Original Message -----
> On 20/03/13 08:07, Nathan Scott wrote:
> > Something's gone wrong - the non-secure-sockets builds should be
> > very much how things were before the introduction of NSS code,
> > and we've never had this warning before. If you can track it down
> > that would be awesome, else I'll take a look later today.
>
> Found this one ... error in looping logic left fd non-zero, even if
> no pmcd socket establised. Tested patch on its way.
Fabulous, thanks!!!
> > I am planning a 3.7.1 asap (today even, ideally) to roll up those
> > 3.7.0 fixes from working with the Aconex operations folks - I'll
> > roll these couple in too. Also, I was adding code yesterday that
> > needed to treat the postinst scripts similarly to the way you had
> > tackled preinst before - if you could double check that stuff for
> > me it'd be much appreciated (in dev branch now).
> >
>
> Only thing I can see is that in debian/cleantmpdirs
>
> target="$_new_tmp_dir/$_subdir/$f"
>
> without any tests ... I think any of the following conditions would
> warrant a warning (maybe even if $_verbose is not set)
> - $_new_tmp_dir does not exist or is not a directory
> - $_new_tmp_dir/$_subdir does not exist or is not a directory
> - $_new_tmp_dir/$_subdir/$f already exists
I think all of these are handled. This is the postinst, so if we
reach this point the install has succeeded and we are guaranteed
by the packaging that the tmpdirs exist (they are installed now,
during the builds). The final case above remains - that is handled
by the -n option in the mv(1) invocation which is "do not overwrite
an existing file"
nathans@smash:~$ echo 1 > a
nathans@smash:~$ echo 2 > b
nathans@smash:~$ mv -fun a b
nathans@smash:~$ cat b
2
> If $_new_tmp_dir and/or $_new_tmp_dir/$_subdir might not exist, then
> they'd need to be created with ownership and permissions that would
> match the pcp packages that deliver these (I'm thinking the core PCP
> piece is being upgraded, but what if one of these dirs is in an
> optional PCP package ... should not happen in this case, so I think
> the warning message is required ... and may be even an exit 1 as
> this is pretty broken if it happens.
As above, I think that we have avoided this issue via commit aeb162cf6
from ddiss ... for those packages/platforms that did the move, there's
this:
$ rpm -ql pcp | grep tmp
/var/lib/pcp/tmp
/var/lib/pcp/tmp/mmv
/var/lib/pcp/tmp/pmdabash
/var/lib/pcp/tmp/pmie
/var/lib/pcp/tmp/pmlogger
... and for those that didn't, there's a short-circuit guard in the
script (from earlier today) that bails out early if the new/old dirs
are the same.
cheers.
--
Nathan
|