OK.. I'm getting out of ideias.
Now I've got the same error with a different file..
# chroot (...)
# emerge portage
[...]
Traceback (most recent call last):
File "/usr/bin/emerge", line 3200, in ?
mydepgraph.merge(mydepgraph.altlist())
File "/usr/bin/emerge", line 1912, in merge
retval=portage.doebuild
(y,"merge",myroot,self.pkgsettings,edebug)
File "/usr/lib/portage/pym/portage.py", line 2724, in doebuild
return merge(mysettings["CATEGORY"],mysettings["PF"],mysettings["D"],mysettings["BUILDDIR"]+"/build-info",myroot,mysettings,myebuild=mysettings["EBUILD"])
File "/usr/lib/portage/pym/portage.py", line 2896, in merge
return mylink.merge(pkgloc,infloc,myroot,myebuild)
File "/usr/lib/portage/pym/portage.py", line 6893, in merge
return
self.treewalk(mergeroot,myroot,inforoot,myebuild,cleanup=cleanup)
File "/usr/lib/portage/pym/portage.py", line 6502, in treewalk
if self.mergeme(srcroot,destroot,outfile,secondhand,"",cfgfiledict,mymtime):
File "/usr/lib/portage/pym/portage.py", line 6758, in mergeme
if self.mergeme(srcroot,destroot,outfile,secondhand,offset+x+"/",cfgfiledict,thismtime):
File "/usr/lib/portage/pym/portage.py", line 6791, in mergeme
os.utime(mydest,(thismtime,thismtime))
OSError: [Errno 38] Function not implemented: '/etc/make.globals'
On 12/29/05, Brian Harring <ferringb@gentoo.org> wrote:
On Thu, Dec 29, 2005 at 10:35:12AM +0000, Joăo Brázio wrote:
> On 12/29/05, Brian Harring <[1]ferringb@
gentoo.org> wrote:
> > On Thu, Dec 29, 2005 at 10:24:06AM +0000, Jo?o Br?zio wrote:
> > > Wel.. I've already tryed to chroot() into the grp-x86-20051228 and
> > > issued:
> > > # emerge portage
> > > Calculating dependencies
> > >
> > > !!! Problem in sys-apps/portage dependencies.
> > > !!! [Errno 38] Function not implemented:
> > > '/var/cache/edb/dep//usr/portage/sys-apps/.update.23778.portaege-2.0.53
> > > ' exceptions
> > utime or rename offhand...
> Excuse me but what do you mean with "offhand" ?
That name for a file is only created with a flat_list cache backend,
specifically when it's doing an update to an existing entry (kind of a
duh there considering the name, I know).
The algo is roughly
f=open(tmp_update_entry)
write to it
close it
utime it (reset mtime)
rename(tmp_update_entry, update_entry)
Hence the 'offhand'. Don't know if it's rename or utime that's not
defined- just know that those are the only two syscalls that could
sanely trigger that (failed update will trigger an unlink, but I'd be
amazed if that call was missing).
~harring
--
Cumprimentos,
Joăo Brázio.