A user on the forum has reported that "testForLib -v 7z.so" doesn't work. See: http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44
It's strange, because 7z.so seems to be missing in the list that ldconfig -p returns. Does someone know why?
On Wed, Jan 7, 2009 at 7:35 PM, Jan Niklas Hasse <jhasse@...> wrote: > A user on the forum has reported that "testForLib -v 7z.so" doesn't work. > See: http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44 > > It's strange, because 7z.so seems to be missing in the list that ldconfig -p > returns. Does someone know why? > Could be because it is named wrongly. Libraries should be called libWHATEVER.so, not just WHATEVER.so. Try renaming it and test again (don't forget to run ldconfig) I posted a reply http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44&p=159#p159 -Isak --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@... For additional commands, e-mail: autopackage-dev-help@...
Well, /usr/lib/p7zip/ doesn’t look like default path to be included in ldconfig search paths.
That means whatever installed this library must add the path to ldconfig,
Install (of 7z lib) should create /etc/ld.so.conf.d/7z.conf containing that path and run # ldconfig
If ldconfig -p doesn’t list the .so, then linker will not find it, which meant library is as good as non-existing (except for apps that know exactly where it is).
So testForLib seems to work as it should.
(unless ldconfig -p does list it)
From: Jan Niklas Hasse
[mailto:jhasse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, January 07, 2009
11:36 AM
To: autopackage-dev-OfajU3CKLf1/SzgSGea1oA@public.gmane.org
Subject: 7z.so isn't found by
testForLib
A user on the forum has reported that "testForLib -v 7z.so"
doesn't work. See: http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44
It's strange, because 7z.so seems to be missing in the list that ldconfig -p
returns. Does someone know why?
On Tue, Dec 23, 2008 at 5:23 PM, Jan Niklas Hasse <jhasse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
1.2.6 seems to work fine, I think you can release it, Isak.
Btw: I've uploaded a first build of 1.4.0, can you redirect it, too?
On Wed, Jan 7, 2009 at 8:31 PM, Jan Niklas Hasse <jhasse@...> wrote: > On Tue, Dec 23, 2008 at 5:23 PM, Jan Niklas Hasse <jhasse@...> wrote: >> >> 1.2.6 seems to work fine, I think you can release it, Isak. >> >> Btw: I've uploaded a first build of 1.4.0, can you redirect it, too? > > Two weeks passed, can we release 1.2.6? I want to have 1.4.0 ready as fast > as possible. > oh, sorry. Thanks for reminding :) I've update the redirection now, please try it and see if it works. (just download a package) Meanwhile, I'll try to pursue dotsrc to give you cvs access so that you can do this without having to wait for me in the future :) -Isak --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@... For additional commands, e-mail: autopackage-dev-help@...
Looks fine for me.
GTK package wasn’t even rebuilt (right?), so should be as good as 1.2.5, and support code looks good.
From: Jan Niklas Hasse
[mailto:jhasse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
Sent: Wednesday, January 07, 2009
12:32 PM
To: autopackage-dev-OfajU3CKLf1/SzgSGea1oA@public.gmane.org
Subject: Re: New bug fix release
On Tue, Dec 23, 2008 at 5:23 PM, Jan Niklas Hasse <jhasse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
1.2.6 seems to work fine, I think you can release it, Isak.
Btw: I've uploaded a first build of 1.4.0, can you redirect it, too?
Two weeks passed, can we release 1.2.6? I want to have 1.4.0 ready as fast as
possible.
Hi All
This email is a compilation of my postings to the web forum, as I don't have the privilege of creating bug tickets. For those who want to read the originals, the thread is located here: http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44#p152. As you can see, Jan-Nik has already provided plenty of support.
Firstly, I'd like to note that I think Autopackage is a great idea. I'm
sick of including RPM/Deb/TGZ packages with my releases and Autopackage
is a sensible solution.
I wanted to modify the default Qt skeleton file, because it doesn't
work with Qt4. I had to search for ages before finding confirmation
that I should put local skeletons into
"./autopackage/skeletons/$ROOTNAME". You really must include this
crucial information somewhere within the "Autopackage Packagers Guide"
document.
I've modified the Qt skeleton to also work with Qt4. I'll attach it to
a new thread with the other skeletons I've created in the next few days, once I've also created some related to my Quamachi application.
I've just tested an Autopackage I created for my Q7Z application on the
following Linux distributions: Arch; Kubuntu; Fedora; Zenwalk. The only
minor issue was that neither the 'su' nor the 'sudo' passwords worked
while installing in Zenwalk. Everything else went well and I'm pleased
that I can finally enforce some dependencies for Slackware users.
Further implementing and testing revealed a new issue relating to the retrieval of dependencies. My Quamachi package will depend on a Hamachi package. In my Hamachi
skeleton file within the Quamachi package, I've included the following
line:
Hi All
I've noticed a few problems with v1.4.0, which I thought you'd like to know about before it receives the 'stable' stamp.
This version seems to forget all about dependency checking and retrieval, by going straight from extracting to installing. When created with v1.2.5, my Q7Z and Quamachi packages were successfully checking for several required libraries. I haven't made any changes to the skeleton files, so I'm guessing this is caused by a new bug.
When creating my packages, I receive the following non-fatal warnings:
On Mon, Jan 12, 2009 at 6:53 AM, Chris Giles <chris.g.27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hi All
I've noticed a few problems with v1.4.0, which I thought you'd like to know about before it receives the 'stable' stamp.
This version seems to forget all about dependency checking and retrieval, by going straight from extracting to installing. When created with v1.2.5, my Q7Z and Quamachi packages were successfully checking for several required libraries. I haven't made any changes to the skeleton files, so I'm guessing this is caused by a new bug.
When creating my packages, I receive the following non-fatal warnings:apkg-bashlib: line 595: echo: write error: Broken pipe
cp: cannot stat `/usr/libexec/autopackage/autopackage-curl': No such file or directory
The Qt front-end is still lagging behind the Gtk front-end in terms of layout and features. It's also unable to install the Development Environment package as 'root' or 'user', due to several errors. Here are the first few:`--> sudo package install Autopackage\ Development\ Environment\ 1.4.0.package
/usr/share/autopackage/apkg-io: line 309: 31436 Segmentation fault autopackage-frontend-qt "$ <at> "
.-(/media/Exchange/Temp/Programming/AutoPackage)-----------------------------------------------------------------------------------------------------------------(chris <at> localhost)-
`--> tar: bin/apgcc: Cannot change ownership to uid 1000, gid 1000: No such file or directory
tar: bin/apgcc: Cannot change mode to rwxr-xr-x: No such file or directory
tar: bin/make-icons: Cannot open: No such file or directory
I worked as a software engineer for a few years and I'm happy to become a featherweight contributor.
Since I now work as a secondary school teacher and private tutor, my time is limited during the school terms.
On Mon, Jan 12, 2009 at 11:06 AM, Jan Niklas Hasse <jhasse-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Mon, Jan 12, 2009 at 6:53 AM, Chris Giles <chris.g.27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:This version seems to forget all about dependency checking and retrieval, by going straight from extracting to installing. When created with v1.2.5, my Q7Z and Quamachi packages were successfully checking for several required libraries. I haven't made any changes to the skeleton files, so I'm guessing this is caused by a new bug.
Hm ... There was a bug in testForLib but I believed it fixed. I will try to reproduce the issue.
RSS Feed3 | |
|---|---|
13 | |
24 | |
16 | |
33 | |
47 | |
4 | |
41 | |
10 | |
38 | |
42 | |
32 | |
8 | |
10 | |
11 | |
14 | |
105 | |
102 | |
33 | |
24 | |
32 | |
46 | |
13 | |
66 | |
23 | |
57 | |
44 | |
18 | |
31 | |
76 | |
70 | |
101 | |
55 | |
49 | |
140 | |
119 | |
104 | |
112 | |
54 | |
63 | |
61 | |
49 | |
232 | |
232 | |
303 | |
268 | |
193 | |
172 | |
327 | |
83 | |
232 | |
280 | |
290 | |
202 | |
332 | |
288 | |
140 | |
215 | |
174 | |
50 | |
94 | |
98 | |
192 | |
96 | |
130 | |
112 | |
70 | |
11 | |
7 | |
9 | |
7 | |
9 | |
41 | |
121 | |
55 | |
70 | |
7 |
