Re: AP v1.4.2: Dependency Building: Still Broken
Chris Giles
Just make sure that the remote dependency resolution feature is tested before each release and you'll keep me happy. I'm sorry to write that it still appears to be broken in v1.4.2.
I just created Hamachi and Quamachi packages using v1.4.2. When I tried to install Quamachi, Autopackage is still unable to install the (remote) Hamachi package. The error message this time was simply: FAIL: Unable to prepare package ...
I had set the debug level to '3' beforehand, but no log file was created. Can you please actually take the time to test that this remote dependency resolution feature is fixed before releasing v1.4.3? If preferred, you're welcome to email me the beta code tarballs and I'll test it here.
I want to stop releasing Deb/RPM/TGZ packages with my application and force everyone to use AP, but it seems to be too unstable right now. I'm hoping we can get this ongoing problem fixed and then leave all related code the hell alone for all eternity.
I'm very very sorry. I really didn't test it (since I'm not using dependency resolution for my own packages and was in a hurry). I will have a close look and test it this time. But this might take a while, as I'm currently also forced to do some stuff for school (will be the last time in my whole life though, yeah!).
I noticed that Ticket #115 was recently closed, but the original fix for this bug wasn't fully successful and Jan wanted more time for testing. Has this happened yet?
I haven't done anything about the broken dependency building yet. The problem was a very full time schedule as my grandfather was in hospital and my mother currently is. The same reason I had to cancel the trip to the LinuxTag a month ago. But things are getting better, after this weekend I will definitely have more time to hack on autopackage again.
I got need some help though ;) Can you send me two example packages which one is a dependency of each other? I'm also quite unsure how dependencies retrieval works. Can someone point me out to a good point in the docs which explains it?
Has there been any progress in fixing this problem yet? I'm sorry that I didn't send you the files that you requested, probably because I got sidetracked with other issues. Do you still need me to send them to you now, or are you able to fix this problem without assistance?
Jan Niklas Hasse
On Sun, Jul 11, 2010 at 10:21 AM, Chris Giles <chris...@gmail.com> wrote:
> Has there been any progress in fixing this problem yet?
No sorry, I haven't looked into it again.
I'm sorry that I
> didn't send you the files that you requested, probably because I got
> sidetracked with other issues. Do you still need me to send them to you
> now, or are you able to fix this problem without assistance?
They would help me :)
Chris Giles
I've attached the source archives that you'll need. After building them, the 'Hamachi' AP file goes on a remote host, while the user downloads the 'Quamachi' AP file.
When the user installs 'Quamachi', AP is supposed to download the 'Hamachi' AP file and install it first. The problem is that this process fails when using AP v1.4.2.
Within these source archives, you'll need to modify the 'URL' and 'Repository' variables in the AP specification files. For example, you might like to put the 'Hamachi' AP file in the 'Downloads' section of AP's rather deserted Google Code webpage :-).
Let me know if you need any further information about this matter. I look forward to getting this bug fixed, as it's the only AP feature I use that seems to be broken right now.
Jan Niklas Hasse
On Thu, Jul 15, 2010 at 1:08 PM, Chris Giles <chris...@gmail.com> wrote:
> Hi Jan
>
> I've attached the source archives that you'll need. After building them,
> the 'Hamachi' AP file goes on a remote host, while the user downloads the
> 'Quamachi' AP file.
Okay, thanks :)
> Within these source archives, you'll need to modify the 'URL' and
> 'Repository' variables in the AP specification files. For example, you
> might like to put the 'Hamachi' AP file in the 'Downloads' section of AP's
> rather deserted Google Code webpage :-).
Ah okay, I will do that.
> Let me know if you need any further information about this matter. I look
> forward to getting this bug fixed, as it's the only AP feature I use that
> seems to be broken right now.
I'm working on it at the moment :)
Jan Niklas Hasse
I got so far that it installs the dependency now. But the output looks
strange to me:
# Preparing package: Quamachi - Hamachi GUI
# Checking for cURL library ... passed
# Checking for Python language runtime ... passed
# Checking for Qt toolkit ... passed
# Checking for PyQt bindings ... passed
# Checking for LogMeIn Hamachi ... passed
## Preparing package: LogMeIn Hamachi - VPN System
## Checking for GNU Make ... passed
## Checking for GNU GCC ... passed
## Checking for GNU Bash ... passed
# Checking for GNU Bash ... passed
# Checking for GNU Make ... passed
100%[==================================================] 68Kb/s ETA
00:00
## Checking for GNU Make ... passed
## Checking for GNU GCC ... passed
## Checking for GNU Bash ... passed
## Installing package: LogMeIn Hamachi - VPN System (package 1 of 1)
## 100%[==================================================] Extracting
## Preparing executables...
## Updating package database...
The following package was successfully installed:
* LogMeIn Hamachi - VPN System
This installation used 0 bytes of disk space.
Remove this package by running package remove hamachi from the command line.
Why does it show 0 bytes of disk space and why are there two # before
some lines?
Could you send me the output of a correct installation of Quamachi and Hamachi?
-
Jan
Chris Giles
I got so far that it installs the dependency now. But the output looks
strange to me:
...
Why does it show 0 bytes of disk space and why are there two # before
some lines?
The "0 bytes" is due to the way that I chose to package the application. I've instructed AP to run 'make' and "make install" during the installation, rather than simply to copy the pre-built files across. I'm guessing that the extra '#' occurs when AP calls AP to install a package.
Could you send me the output of a correct installation of Quamachi and Hamachi?
There's probably no need, since that output looks to be normal. If the dependency is now being retrieved and installed, you might not have to make any further changes. You're welcome to send me a pre-release of AP and I'll retest this issue here, prior to the next official release.