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)
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.
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!
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.
Created attachment 47507 [details, diff] Updated patch. Update of the proposed patch with the addition of the os.path.islink() function.
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?
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.
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?
give -r4 a run and see if it fixes the bug
Sorry for the late reply, but I had some other problems (see #75733) :-) -r4 works as expected with the original patch.
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.
