FS#11085 - The sawfish package lacks of some .la files

Attached to Project: Arch Linux
Opened by Plato Wu (netawater) - Friday, 01 August 2008, 08:47 GMT
Last edited by Jürgen Hötzel (juergen) - Thursday, 09 April 2009, 20:48 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Aaron Griffin (phrakture)
Jürgen Hötzel (juergen)
Ronald van Haren (pressh)
Architecture All
Severity Medium
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
It lacks of /usr/lib/librep/rep/i686-pc-linux-gnu/sawfish/client.la for client.so, and other .la files are also lost.

$ sawfish-client
*** File error: No such file or directory, sawfish/client

Additional info:
* package version(s)
sawfish-1.3.3

Steps to reproduce:
It always report that error message when run sawfish-client.

How to fix it:
I have rebuild this package with a patch file to fix library installed
path in accordance with makepkg's requirement.
http://aur.archlinux.org/packages.php?ID=18806
Please check it.
This task depends upon

Closed by  Jürgen Hötzel (juergen)
Thursday, 09 April 2009, 20:48 GMT
Reason for closing:  Upstream
Comment by Greg (dolby) - Friday, 01 August 2008, 12:14 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (High → Medium)
  • Task assigned to Aaron Griffin (phrakture)
Please make a bugreport upstream
Comment by Aaron Griffin (phrakture) - Friday, 01 August 2008, 14:30 GMT
I don't think this is an upstream issue. I think it's a build issue. I will look into it
Comment by Gavin Bisesi (Daenyth) - Friday, 01 August 2008, 19:07 GMT
The PKGBUILD already has options=(!libtool); perhaps the latest makepkg isn't honoring it?
Comment by Aaron Griffin (phrakture) - Friday, 01 August 2008, 19:44 GMT
Well the AUR entry was deleted, but the patch looked like something that could be done via an configure param or something. If I recall, it was doing something like:

repinstallpath=$startdir/pkg/usr

If that fixes things, then there's probably way to do that in the PKGBUILD. This should still be reported upstream though, as it's a goofed issue in their buildscript (that variable isn't based off the installdir)
Comment by Greg (dolby) - Friday, 01 August 2008, 19:59 GMT
Yeah, thats i meant when i said report upstream before :-)
Comment by Plato Wu (netawater) - Monday, 04 August 2008, 05:51 GMT
My opinion is the developer of sawfish do not think the rep's install path which is get by checking module script ought to be effected by its install path, so I think it should be handled by PKGBUILD for it merely is archlinux's requirement.

PS: Why need to delete the AUR entry now?
Comment by Aaron Griffin (phrakture) - Tuesday, 05 August 2008, 18:33 GMT
I didn't delete it, I don't know who did
Comment by Aaron Griffin (phrakture) - Thursday, 20 November 2008, 20:46 GMT
Tag, Jürgen, you're it 8)
Comment by Jürgen Hötzel (juergen) - Wednesday, 26 November 2008, 22:12 GMT
@Aaron: Thanks for the early Christmas gift ;)
@netawater: AUR link is broken: Can you attach the file please?
Comment by Plato Wu (netawater) - Friday, 05 December 2008, 02:54 GMT
I re-upload it: http://aur.archlinux.org/packages.php?ID=22008.
I'm glad somebody handle it in the last. I hope my contribution can do a little help.
Comment by Plato Wu (netawater) - Saturday, 06 December 2008, 14:06 GMT
I'm very sad someone has deleted my package again.
so I do not know what is to say and hope you can check the BUG & AUR flow.
Comment by Gavin Bisesi (Daenyth) - Saturday, 06 December 2008, 14:58 GMT
It's against the AUR rules to upload a copy of a package from the repos.
Comment by Plato Wu (netawater) - Tuesday, 09 December 2008, 01:34 GMT
So how do I share my patch file?
Comment by Jürgen Hötzel (juergen) - Tuesday, 09 December 2008, 06:44 GMT
Please make a file attachment in this bug report.
Comment by Jürgen Hötzel (juergen) - Tuesday, 09 December 2008, 19:17 GMT
New release 1.3.4-1 includes libtool archives again -> fixes this issue.

I keep this bug open. We need to look into the libtool issue.
Comment by Jürgen Hötzel (juergen) - Tuesday, 09 December 2008, 19:21 GMT
bringing Ronald on board...

@Ronald you checked in:

upgpkg: librep 0.17.1-2
it should work correctly now, we need the libtool files

what was the issue with librep. sawfish depends on it...
Comment by Plato Wu (netawater) - Wednesday, 10 December 2008, 13:11 GMT
Please check it, thanks.
(application/octet-stream)    package.tar.gz (0.7 KiB)
Comment by Ronald van Haren (pressh) - Wednesday, 10 December 2008, 13:28 GMT
@Jürgen: I believe the libtool files were required by maxima but it seems to work fine now without the .la files (at least basic testing). I also can't find any related bug reports so if you need to remove the .la files I think it should be fine as librep is only used by sawfish and maxima and some rep-gtk thing.
Comment by Jürgen Hötzel (juergen) - Wednesday, 10 December 2008, 13:49 GMT
Hi Ronald,

Looks like maxima is currently build with clisp:
[juergen@bitzer ~]$ maxima
Break 1 [4]> (lisp-implementation-type)
"CLISP"
Break 1 [4]> (lisp-implementation-version)
"2.45 (2008-05-15) (built on localhost.localdomain [127.0.0.1])"

and it doesn't even offically support librep:

http://apps.sourceforge.net/mediawiki/maxima/index.php?title=Maxima_FAQ#What_Lisp_implementations_will_Maxima_work_with.3F


Comment by Ronald van Haren (pressh) - Thursday, 11 December 2008, 17:49 GMT
Thanks Jürgen. I removed librep from the dependencies of maxima for the next release (5.17.0) which I'm currently preparing. So one thing less you need to take into account.
Comment by Ronald van Haren (pressh) - Wednesday, 11 March 2009, 21:54 GMT
Jürgen, we are at sawfish 1.3.5 now for some time already, is this fixed?
Comment by Jürgen Hötzel (juergen) - Thursday, 12 March 2009, 13:05 GMT
1.3.5-1 is functional but i would like to keep this bug open until libtool-slayed all "rep" packages.
Comment by Jürgen Hötzel (juergen) - Thursday, 09 April 2009, 17:06 GMT
We can't libtool-slay librep. Upstream uses following code with
".la" hardcoded into the filename generation do find libs:

./lispcmds.c:1403: try = rep_concat2(rep_STR(dir), ".la");
./lispcmds.c:1407: (rep_concat3 ("lib", rep_STR(file), ".la"),
./unix_dl.c:241: if (len >= 3 && strcmp (tem + len - 3, ".la") == 0)

I don't know why they don't use libltdl (part of libtool) to do platform-independend loading of shared libs. I will try to convince upstream.
Meanwhile we will keep ".la" files (they don't hurt because they are located in libreps private path).

Loading...