Re: Problems: Stability: 1.4.0

Chris Giles <[email protected]> Wed, 4 Feb 2009 21:30:06 +1100
Newsgroups gmane.comp.autopackage.devel
Message-ID <[email protected]>
>
> 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.
>
> I just tried and it worked fine with one of my own packages. Just to ensure
> that we're using the same build here's the MD5 sum of the autopackage
> tarball I used:
>
> 7f1818be3cc9f94efbae271fefba5dc8  autopackage.tar.bz2
>

I just retested this issue and figured out its cause.  Dependency checking
and retrieving works fine with AP v1.4.0 when my spec file has the following
line:

   - AutopackageTarget: 1.2.6

However, dependencies aren't even tested if my spec file has either of the
following lines:

   - AutopackageTarget: 1.4
   - AutopackageTarget: 1.4.0

I'm guessing that this problem should be relatively easy to fix.

 When creating my packages, I receive the following non-fatal warnings:
>> apkg-bashlib: line 595: echo: write error: Broken pipe
>>
>
> Don't know what causes this, happens quite often for me, too.


This problem seems to have magically disappeared today, but I wonder if
anyone knows the cause and resolution.  Just in case it resurfaces, perhaps
we should create a bug ticket with a low priority.

cp: cannot stat `/usr/libexec/autopackage/autopackage-curl': No such file or
>> directory
>>
>
> Strange, this shouldn't happen. Are you sure that you installed the
> Autopackage Development Environment 1.4.0 and not 1.2.5?


Yeah, AP v1.4.0 was installed since the problem doesn't exist with v1.2.6.
Do we know why this file is missing?

Unfortunately the maintainer of the Qt front-end is no longer active AFAIK.
> I also can't help it, don't know anything about Qt3. I think we have no
> choice other than to drop the Qt front-end.
>

Since both of my Linux applications are written in Python-Qt4, perhaps I'm
the logical guy to takeover the development of the AP-Qt front-end.  I hate
programming in C++, but I'll take a look at the AP-Qt code when I get some
free time.  My first two goals would be to: upgrade the code from Qt3 to
Qt4, if necessary; port the recent AP-GTK changes across to AP-Qt.