Emerge waiting for ttmkfdir.o.lock to be removed.

[woodm]

Ok, I'm posting this with lynx, so I dont' know if it's going to work correctly...

I'm trying to emerge afterstep, and one of the required ebuilds is: ttmkfdir.
However, the ttmkfdir emerge is not working. It keeps repeating: "Waiting for ttmkfdir.o.lock to be removed". It just repeats that forever. I've let it run for half an hour so far, I can't imagine that I need to wait longer; should I?
I've tried deleting the package from /usr/portage/distfiles, I've tried rsyncing, rebooting, deleting the ttmkfdir files from /var/tmp/portage/___, and even deleting files from /var/cache/edb/dep/___, but nothing seems to work.
I did a search for ttmkfdir.o.lock, but found nothing.

I really don't know what to do at this point. You guys are always extremely helpfull, and I did search the archives of this forum as best I could.
Any suggestions? I think I just need to get rid of that lock and I will be fine.
_________________
There are thousands of types of people in this world:
The type that seperates people into two groups,
and the thousands of other types.

[px]

how did you research the file?

I think a .lock file is in /var/lock or in /var/run...
_________________
Nous autres, mordus d'informatique, préférons par-dessus tout passer notre temps à bidouiller nos ordinateurs, plutôt que les utiliser pour faire quelque chose de productif. [Dave Barry]

[woodm]

[pjp]

Does the same error occur if you do an emerge ttmkfdir?

By the way, I'm going to move this to Desktop Environments after your next post (letting you know since you have to deal with lynx).
_________________
Quis separabit? Quo animo?

[woodm]

[pjp]

Moved to P&P as "requested".
_________________
Quis separabit? Quo animo?

[Twist]

I know this is old but will post here in hopes that anybody doing a search (which is the Right Thing(tm) ) with this problem in the future can get the solution.

This is a bug/issue with libtool. When you see an endless line of

"Waiting for somefile.o.lock to be removed"

The usual explanation is that libtool is confused because your build directory is not on the same file system as that of libtool (usually for libtool, /usr).

With Gentoo, the most likely explanation is that you have set PORTAGE_TMPDIR to duh, a tmp location that is not on the same partition as /usr. Short solution: reset PORTAGE_TMPDIR for this package only, i.e.:

export PORTAGE_TMPDIR=/var/tmp

emerge whatever it is you are working on and set PORTAGE_TMPDIR back to it's original location. This behavior should be fixed in libtool eventually, but that's a different discussion.

Extended info:

If you are building something manually, many configure scripts allow you to override the lock check via "./configure --disable-libtool-lock". Keep in mind the original purpose of the lock is to prevent error between concurrent builds on multi-user systems - if you are in that circumstance potentially, use at your own peril.

[woodm]

I would have thought that my post would have died a long time ago. I never did fix the bug. I just ended up reinstallling stuff. I think I got that error around the time I was trying to upgrade my system to the new version of GCC. There were so many potential problems there. I think I would have mentioned that though. Hmmm. Maybe not.

Regardless, thanks for the update. Hopefully I won't have need for your explanation!
_________________
There are thousands of types of people in this world:
The type that seperates people into two groups,
and the thousands of other types.

[golemB]

I'm so glad to hear that others have run into my problems with ttmkfdir - but sad to say that the solution doesn't work for me.

Due to the painful disk requirements of gentoo with X, I have been scrounging space wherever I can - which translates into separate partitions for /usr/portage, /var/tmp, /usr/src, and /. I tried setting PORTAGE_TMPDIR from /var/tmp to /tmp (since my libtool lives in /usr/bin) -- but no luck. Do I also have to change my PORTDIR to live on the same partition?

[Mick_bravo]

Yeh it works for me. I was affraid I had to install it again.

I used RC4. It exported the directory to /tmp and now he doesn't complain.
_________________
You only need one tree to make a thousand matches, You only need one match to burn a thousand trees.

[golemB]

Mick_bravo, what exactly did you have to install again? Do you mean your entire system? Or do you mean that you also had to change your PORTDIR before emerging ttmkfdir? It seems to me that doing so could be dangerous (making it difficult for Portage to figure out what the dependencies are?) - though I don't know enough yet about Portage.

(I set PORTAGE_TMPDIR to /tmp and tried just emerge -uv ttmkfdir, with no success - same repeating message about the lock.)

[CerberusX]

I just bumped in to this lockfile problem, it seems that libtool is the culprit. re-emerge libtool and then retry your original file and it should work. This solved my lockfile problem.

[golemB]

thanks!

[blackbrow]

For anyone else, who is having troubles with both of the above solutions, I had to create a /usr/porttmp directory since /var and /tmp were both on different partitions.

I then used Twist's solution successfully.

[2501]

[mathew]

The emerge libtool didn't work for me and I suspect my /usr partition doesn't have enough space for emerge -e world, which is what I was trying to do as part of following the upgrade to 1.4. To work around this, I created a symbolic link for just the ttmkfdir package:

[mope]

I've tried everything in this thread but still can't get it to go.

I tried to do a manual compile, but there is no .configure in my work directory. Am I doing something wrong?

I do:

ebuild ttmkfdir*.ebuild fetch unpack

then when I go into the work directory, I can't ./configure anything.

[pennedinil]

if anyone's still having problems, search for 'quote.o.lock' n all closed bugs.

I was able to fix this problem for acl & attr. May be helpful to someone else.

[step]

looks like this problem is back
in x11-misc/ttmkfdir-3.0.9-r2

[pennedinil]

this ".lock" thing is a real emerge killer!!!

It also break xfsprogs. I can't do emerge -epv system anymore.

PLEASE PLEASE PLEASE someone fix this.

[alzz]

I had the same problem when I emerged x11-base/xorg-x11.
And I have solved it by making another portage temp directory just as people said. I did

[memic]

[pixelcatcher]

re emerging libtool made it work like a charm... thanks!
_________________
www.pixelcatcher.de

[TreeFree]

Howdy,

Thanks alot to all the posters on this thread.

I encountered this lock-waiting condition doing an emerge of apache that required apr-util-0.9.6-r2. I kept getting hung up on apr_buckets_file.o.lock to removed, and indeed the problem for me was that my portage tmp was on a seperate partition and symlinked in.

Updating libtool with emerge did not solve my problem.

I had to use the solution that Alzz and Step used in making a temp space for portage on the root partition (I guess it needs to be the same one as libtool?) Anyways, this worked like a charm and I was able to get apache to compile and install .

Thanks!