this bug is actually #21438. summary: in /etc/init.d/bootmisc the line
( find /var/lock -type f -print0 | xargs -0 rm -f -- 1>&2 )
xargs: environment is too large for exec
baselayout-126.96.36.199-r1 is now marked stable and this is still not fixed,
somewhere in the comments for #21438 there is a fix.
Steps to Reproduce:
Yes. On the stable tree baselayout 188.8.131.52-r1 still produces the xargs error. That line in /etc/init.d/bootmisc can be replaced with the alternative solution supplied elsewhere on bugzilla. A suggestion was made to patch fileutils also but I leave the choice in your capable hands.
pfeifer, can you have a look at this bug? It has 3 duplicates and I think it can be fixed with a one line patch to /etc/init.d/bootmisc
It is already fixed in CVS - Pieter, haven't you read the previous bugs
and the one or two others that you needed fixed that I fixed last night?
I just am getting all the serious bugs squisched, and will get a new
version out in the next day or so. Sorry for it taking so long to get
the new version out, but my time has not been my own lately.
This *is* already fixed in CVS, please be pacient, I will get new version
out tonight, latest tomorrow.
thnxs Martin, I really appreciate your work.
We all appreciate it. Thanks!
*** Bug 24993 has been marked as a duplicate of this bug. ***
*** Bug 26939 has been marked as a duplicate of this bug. ***
it's not fixed in "x86" 184.108.40.206-r1 but it's fixed in "~x86" 220.127.116.11
*** Bug 26972 has been marked as a duplicate of this bug. ***
*** Bug 27091 has been marked as a duplicate of this bug. ***
Well it's now about six weeks since it was said there will be a new stable version for baselayout where this gets fixed. It still is not. Are there other issues hindering the maintainer from making a new release?
Baselayout 18.104.22.168 on ~x86 works nicely for me. You could use that one.
Or I could copy /etc/init.d/bootmisc from cvs and use that. But that is not the point.
Okay. Let me be more objective rather than trying to help you which wasn't at all well received.
(1) Why hasn't there been a new stable release of baselayout?
Usually, this is because (1) the package is not ready for stable or (2) not enough time has past or (3) the developer is very busy (as is probably the case with most devs including this one).
(2) What issues are preventing moving to stable?
Search for baselayout on bugzilla and read results. Users are very quick to express their anger and be critical of new baselayout releases in particular when problems occur so it is not surprising and quite justified if it is taking due time in shifting over to stable.
thank you for your collection of explanations.
After all it appears, Bug #23569 et.al. is simply boring. Nobody cares about it.
We can be happy that we have permission to write comments.
Hi guys, sorry for the delay. For the last few weeks I just had many issues
with internet, mail, etc, and work (real one :/) has been keeping me more away
than I wanted. .10 have this fixed, and except for a few small issues could
be marked stable - I just plainly did not have the time to sit down, fix the
few issues with .10, and maybe have a .11 out for a short while, and then
marking stable, although I guess I should just mark .10 stable. I will really
try to get to it this weekend.
I have an alternative version to this fix which keeps, usage of xargs, and may
be useful for other places where environment bloat occurs.
( find /var/lock ! -name .keep -a -type f -print0 | env -i PATH=/bin:/usr/bin
xargs -tr0 rm -f -- 1>&2 )
Note, I avoid removeal of the .keep, as per suggestion in forum thread, when I
looked into this one, also it uses trace option to list the locks deleted.
*** Bug 26170 has been marked as a duplicate of this bug. ***
This is now really fixed with the release sys-apps/baselayout-22.214.171.124-r1 for stable.
*** Bug 43280 has been marked as a duplicate of this bug. ***