Bugs upgrading attr, pam, ghostscript, libtinfo, libjpeg, libsdl, libv4l, xfig, slitaz-base-files

SliTaz Forum » Community Groups » Devel

Bugs upgrading attr, pam, ghostscript, libtinfo, libjpeg, libsdl, libv4l, xfig, slitaz-base-files

(6 posts) (2 voices)

Started 8 years ago by llev
Latest reply from Aleksej
This topic is not a support question

Tags:

No tags yet.

llev

offline
Member

attr: segmentation fault during "Installation...", but installation continues nevertheless.

pam: segmentation fault during "Installation...", installation stops.

ghostscript: the "ln -s" in post_install fails because the link already exists

After libtinfo installation bash segfaults! (Not sure how to reproduce.)

libv4l: installation fails and leaves LD_PRELOAD containing "/usr/lib/libv4l/v4l1compat.so",
then basically all commands give the message "ERROR: ld.so: object '/usr/lib/libv4l/v4l1compat.so' from LD_PRELOAD cannot be preloaded: ignored." Could not reproduce, maybe it was caused by the upgrade of a previous package in the list (namely libtool, libtorrent-rasterbar, libunique, libusb or libusb-compat)?

libjpeg: Installation... Fail, but no error message shown; could not reproduce.

libsdl: Post-install... Fail, but no error message shown (is there a debug flag in tazpkg?).

xfig: Installation... Fail: cp: cannot overwrite directory `/usr/lib/X11/app-defaults' with non-directory

slitaz-base-files overwrites /usr/bin/sudo (the true sudo in my case).

Posted 8 years ago #
Aleksej

offline
Coder-hobbyist

Hi llev,

Problems with "ln -fs", v4l and sudo are simple to fix. I'll fix the receipts later tonight or tomorrow's night. Having not enough free time with my work.

Also, I planning to release beta version of the new TazPkg, again later night or tomorrow... It is interesting if you'll repeat your actions with new version of tazpkg. All that segfaults may gone (or lasts). I'll write here links later.

Posted 8 years ago #
Aleksej

offline
Coder-hobbyist
Hi llev,

Simple bugs are fixed. Please, wait for a new packages on cook.slitaz.org, and then on the mirrors.

xfig: Installation... Fail: cp: cannot overwrite directory '/usr/lib/X11/app-defaults' with non-directory

This bug appeared in the installation process. Installation is a simple command (abridged):
```
cp -af fs/* /
```
Problematic package "xfig" (and I found another one yesterday, "fontconfig-infinality") contains "symlinked" directory while there is "real" directory on the file system. Or vice versa. In other words, "cp" can't follow symlinks.

Following Busybox's cp help:
```
Usage: cp [OPTIONS] SOURCE... DEST

Copy SOURCE(s) to DEST

	-a	Same as -dpR
	-R,-r	Recurse
	-d,-P	Preserve symlinks (default if -R)
	-L	Follow all symlinks
	-H	Follow symlinks on command line
	-p	Preserve file attributes if possible
	-f	Overwrite
	-i	Prompt before overwrite
	-l,-s	Create (sym)links
```
So, seems we need to add "-L" option. But… I can't cope this problem with the "cp -aLf" or "cp -LpR" or with something meaningful else. I need help!

Simple test suite:
```
cd /tmp
mkdir 1 2/a 3
ln -s ../3 1/a
```
Now we have:
- /tmp/1/a — "symlinked" directory (to be overwritten);
- /tmp/2/a — "real" directory (it should overwrite directory above).
Light, action:
```
cp -af 2/a 1
cp: target '1/a' is not a directory

cp -rLpf 2/a 1
cp: target '1/a' is not a directory
```
That's it :(
Posted 8 years ago #
llev

offline
Member
I don't have a Slitaz installation right now, so can you tell me: without xfig, is there an /etc/X11/app-defaults/ directory? If not, maybe add this to genpkg_rules() of xfig:
```
cp -a $install/* $fs
    sed -i 's/^Fig\*Font:.*/Fig*Font:\t\t\tfixed/' $fs/etc/X11/app-defaults/Fig
++    rm $fs/usr/lib/X11/app-defaults
++    mkdir $fs/usr/lib/X11/app-defaults
++    mv $fs/etc/X11/app-defaults/Fig $fs/usr/lib/X11/app-defaults
++    rmdir $fs/etc/X11/app-defaults
```
(This is the idea, I don't know how package generation works exactly, so you'd have to adapt.)

About the cp problem:
1) if you do a cp, you will have a duplicate: is this what you want?
2) if you overwrite 1/a with a copy of 2/a, other software looking in the 1/a link to find files in 3 will fail. So maybe we just want to copy contents of 2/a to the 1/a link? This contents will end up in 3. Not sure how to do this correctly to copy dot-files also: if we type 'cp -a 2/a/* 2/a/.* 1/a', is the command 'cp' smart enough not to try to recursively copy 2/a/.. ? (In bash there is option "dotglob" to match dot-files with *, but this is nonstandard I think.)
Posted 8 years ago #
llev

offline
Member

P.-S.: The -L option means "follow symlinks /in the SOURCE args/", I think.

Also, the problem here is that cp tries to overwrite the real directory /usr/lib/X11/app-defaults/ with a symlink to /etc/X11/app-defaults/. So in the test suite that would be "cp -a 1/a 2/", and "cp -aL 1/a 2/" works as expected: contents of 3/ is copied into 2/a/.

But still: do we want a duplicate? ;)

Posted 8 years ago #
Aleksej

offline
Coder-hobbyist

Hi llev,

I haven't enough time, want to "fly" to work.
Take a look here to list of xfig files: http://cook.slitaz.org/cooker.cgi?files=xfig
Continue experiments night. Until that I can use only my Android smartphone to read SliTaz forum and other sources.
See you!

Posted 8 years ago #

RSS feed for this topic

Reply

You must log in to post.