Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 73725 - Catalyst fails without an error messege while running livecd/empty in livecd_stage2_target.py
Summary: Catalyst fails without an error messege while running livecd/empty in livecd_...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: Catalyst (show other bugs)
Hardware: x86 Linux
: High minor (vote)
Assignee: Gentoo Catalyst Developers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-07 15:05 UTC by Saurabh Upadhyay
Modified: 2005-05-06 08:28 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
livecd-stage2 patch (livecd_stage2_target.py.diff,1003 bytes, patch)
2004-12-17 20:23 UTC, John Davis (zhen) (RETIRED)
Details | Diff
Updated patch. (livecd-stage2.patch,1.09 KB, patch)
2005-01-03 11:35 UTC, Sven Rubben
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Saurabh Upadhyay 2004-12-07 15:05:40 UTC
Catalyst fails saying
!!! catalyst: could not complete build

just after displaying,
Emptying directory /usr/X11R6/lib/X11/doc

problem in livecd/empty ??

Reproducible: Always
Steps to Reproduce:
1. Do normal steps for creating livecd-stage1 and livecd-stage2
2. I think it occurs with new xorg version which has a simlink in place of /usr/X11R6/lib/X11/doc

Actual Results:  
Emptying directory /usr/X11R6/include
Emptying directory /usr/X11R6/lib/X11/config
Emptying directory /usr/X11R6/lib/X11/etc
Emptying directory /usr/X11R6/lib/X11/doc
!!! catalyst: could not complete build

Expected Results:  
It should have skipped Emptying /usr/X11R6/lib/X11/doc if it cannot or it should
have checked if it already empty or exists at all.

~ # ls -l
/var/tmp/catalyst/tmp/default/livecd-stage2-i586-0.01/usr/X11R6/lib/X11/doc
lrwxrwxrwx  1 root root 33 Dec  7 00:16
/var/tmp/catalyst/tmp/default/livecd-stage2-i586-0.01/usr/X11R6/lib/X11/doc ->
//usr/share/doc/xorg-x11-6.8.0-r3/

which is a "bad" link to /usr/share/doc/xorg-x11-6.8.0-r3/ of chrooted
livecd-stage2 environment. And I guess /usr/share/doc is already emptyed by
previous commands. So livecd/empty in livecd_stage2_target.py fails when
Emptying /usr/X11R6/lib/X11/doc, without any error messege (there is another bug
for not displaying any error messege #66592)
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2004-12-15 18:30:03 UTC
zhen: This is in the python and I'm still trying to learn my way around python.  Can you take a look at this one?  It should be as simple as ensuring that the directory to be emptied really is a directory and not a file/socket/whatever and exit with an error appropriately or possibly just spit out a warning and continue on without failing.
Comment 2 John Davis (zhen) (RETIRED) gentoo-dev 2004-12-17 20:23:49 UTC
Created attachment 46253 [details, diff]
livecd-stage2 patch

this patch is against the latest CVS version of catalyst. Apply it to
/usr/lib/catalyst/modules/livecd_stage2_target.py and report back whether or
not it fixes the problem, thanks!
Comment 3 Sven Rubben 2005-01-03 11:34:17 UTC
The patch doesn't solve the problem completely.

The function os.path.isdir() follows symbolic links, so if 'myemp' contains a symlink to a directory it will return true even though we shouldn't delete and recreate it. The delete will fail silently if the link is outside the chroot (I think :-) ).
So an extra check is needed with os.path.islink() to check for symbolic links. This solved the problem for me.
Comment 4 Sven Rubben 2005-01-03 11:35:55 UTC
Created attachment 47507 [details, diff]
Updated patch.

Update of the proposed patch with the addition of the os.path.islink()
function.
Comment 5 John Davis (zhen) (RETIRED) gentoo-dev 2005-01-03 16:37:44 UTC
I would rather follow the link and empty the directory than just ignore it.

I am CC'ing our xorg developer on this bug as the symlink behavior seems honky. If the package is installed in the chroot, it *should not* be linking to something outside of the chroot. Linking to //usr/blah just seems wrong. Spyderous, what do you think?
Comment 6 Donnie Berkholz (RETIRED) gentoo-dev 2005-01-03 18:58:12 UTC
This is the command in 6.8.0-r4 and newer:
    dosym ../../../share/doc/${PF} /usr/X11R6/$(get_libdir)/X11/doc

Older versions wrongly used an absolute symlink rather than a relative one.

Note that it doesn't link to something outside the chroot, as is suggested, unless you aren't in the chroot. It's just an absolute link to /, which ends up in different places depending on your current root.
Comment 7 Sven Rubben 2005-01-03 23:40:17 UTC
Hmm, I noticed that all links in /var/tmp/catalyst/tmp/default/livecd-stage1-x86-2005.0/usr/X11R6/lib/X11 where to someplace inside the chroot. However, the doc link was to my 'real' doc directory:

<sven@srubben:/var/tmp/catalyst/tmp/default/livecd-stage1-x86-2005.0/usr/X11R6/lib/X11>
% ls -l
total 111
lrwxrwxrwx   1 root root    27 Jan  3 00:05 Cards -> ../../../share/hwdata/Cards
-r--r--r--   1 root root 12991 Jan  2 21:57 Options
-r--r--r--   1 root root 36378 Jan  2 21:57 XErrorDB
-r--r--r--   1 root root  8298 Jan  2 21:57 XKeysymDB
lrwxrwxrwx   1 root root    32 Jan  2 21:57 app-defaults -> ../../../../etc/X11/app-defaults/
drwxr-xr-x   2 root root  3184 Jan  2 21:57 config/
lrwxrwxrwx   1 root root    33 Jan  2 21:57 doc -> //usr/share/doc/xorg-x11-6.8.0-r3/
drwxr-xr-x   2 root root   176 Jan  2 21:57 etc/
drwxr-xr-x   2 root root   296 Jan  2 21:57 fonts/
lrwxrwxrwx   1 root root    22 Jan  2 21:57 fs -> ../../../../etc/X11/fs/
drwxr-xr-x   2 root root   104 Jan  2 21:57 getconfig/
lrwxrwxrwx   1 root root    28 Jan  2 21:57 lbxproxy -> ../../../../etc/X11/lbxproxy/
drwxr-xr-x  55 root root  1736 Jan  2 21:57 locale/
lrwxrwxrwx   1 root root    29 Jan  2 21:57 proxymngr -> ../../../../etc/X11/proxymngr/
-r--r--r--   1 root root 17371 Jan  2 21:57 rgb.txt
lrwxrwxrwx   1 root root    26 Jan  2 21:57 rstart -> ../../../../etc/X11/rstart/
lrwxrwxrwx   1 root root    23 Jan  2 21:57 twm -> ../../../../etc/X11/twm/
drwxr-xr-x   2 root root   128 Jan  2 21:57 x11perfcomp/
lrwxrwxrwx   1 root root    23 Jan  2 21:57 xdm -> ../../../../etc/X11/xdm/
drwxr-xr-x   3 root root    72 Jan  2 21:57 xedit/
lrwxrwxrwx   1 root root    25 Jan  2 21:57 xinit -> ../../../../etc/X11/xinit/
drwxr-xr-x  10 root root   576 Jan  2 21:57 xkb/
-r--r--r--   1 root root  8305 Jan  2 21:57 xman.help
lrwxrwxrwx   1 root root    27 Jan  2 21:57 xserver -> ../../../../etc/X11/xserver/
lrwxrwxrwx   1 root root    23 Jan  2 21:57 xsm -> ../../../../etc/X11/xsm/



That was the reason I chose to ignore symlinks and not follow them.
Note that I have 6.8.0-r3 installed and not -r4, this could explain something I guess?
Comment 8 John Davis (zhen) (RETIRED) gentoo-dev 2005-01-09 17:09:45 UTC
give -r4 a run and see if it fixes the bug
Comment 9 Sven Rubben 2005-01-16 08:19:47 UTC
Sorry for the late reply, but I had some other problems (see #75733) :-)

-r4 works as expected with the original patch.
Comment 10 Eric Edgar (RETIRED) gentoo-dev 2005-05-06 08:28:39 UTC
As this bug is assigned to an old version of catalyst I am not sure its still relevant.  Please reopen if this is still a problem.