Gaim autopackage still being developed?

Re: Gaim autopackage still being developed?

I don't think it is.

On 2/2/07, Rykel <rykel@...> wrote:
> Hi,
>
> Does any of you know if the GAIM autopackage is still being developed?
>
> Because it is now version 2.0.0Beta6 and I have not been able to find a
> single autopackage for it since 2.0.0Beta1. Incidentally, it used to be that
> I could download version 2.0.0Beta1, but even that is no more. The latest I
> can find is 1.5.0something.package.
>
>
>
> --
> Best Regards,
>
> Rykel
> Gizmo.Skype.GTalk/Yahoo/MSN.eBay.GVideo: rykel98
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Re: GCompris NOT Working On Dapper

Le mercredi 31 janvier 2007 à 01:25 +0800, Rykel a écrit :
> Hi pals,
> 
> GCompris 8.2.2 does NOT work on Ubuntu Dapper 6.06.1. (it installs OK)
> Below are the error messages. If my memory serves me well, it used to
> work well on Ubuntu Edgy.
> 
> $ gcompris
> gcompris: /lib/libpopt.so.0: no version information available
> (required by /home/rykel/.local/lib/libgcompris-1.so.0)
> 
> ** (process:9587): WARNING **:
> config_file /home/rykel/.gcompris/gcompris.conf
> 
> ** (process:9587): WARNING **: Binary relocation enabled
> package_data_dir         = /home/rykel/.local/share/gcompris/boards
> package_locale_dir       = /home/rykel/.local/share/locale
> package_plugin_dir       = /home/rykel/.local/lib/gcompris 
> package_python_plugin_dir= /home/rykel/.local/share/gcompris/python
> ** Message: gc_locale_set ''
> 
> ** (gcompris:9587): WARNING **: Requested locale '' got 'en_US.UTF-8'
> open /dev/sequencer: No such file or directory 
> 
> (gcompris:9587): GdkPixbuf-CRITICAL **: gdk_pixbuf_new_from_file:
> assertion `filename != NULL' failed
> sys:1: GtkWarning: gtk_main_quit: assertion `main_loops != NULL'
> failed

Sorry for the late answer. The error means that GCompris can't find the
image to load. can you try to give us more feedback by giving us the
result of gcompris -D

--

-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Fwd: [Bug 7070] Mime type for Autopackage packages

Finally got a respond to this old bug report. Looks like fd.o don't
want the apkg mime type in the db by default.

Hadess' reasoning seems sound to me, so I won't be arguing this.

-Isak

---------- Forwarded message ----------
From: bugzilla-daemon@...
<bugzilla-daemon@...>
Date: Feb 5, 2007 4:28 PM
Subject: [Bug 7070] Mime type for Autopackage packages
To: isak.savo@...

http://bugs.freedesktop.org/show_bug.cgi?id=7070

hadess@... changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hadess@...
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

------- Comment #2 from hadess@...  2007-02-05 07:28 -------
Given that only autopackage can open autopackage files, it would be best for
the mime-type to stay with the application itself. It should also probably be a
sub-class of application/x-executable.

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Trying to package a Python script...

Hey all, I've spent a few hours trying to use autopackage to distribute 
a couple of small Python scripts that I've made. I've been able to get 
it to package up the scripts, images and docs, but when I go to do a 
test install, it fails when it's trying to 'prepare executables'. Any 
help here would be appreciated, and I'll leave my 'default.apspec' here 
for others to look at and tell me where I've gone wrong. :)

Oh, before I post the apspec, I'd better outline roughly what I'm trying 
to do here. I'm trying to put the scripts, images, and doc in a 'share' 
directory. I then want symlinks in the 'bin' directory to the hopefully 
executable scripts in the 'share' directory without their '.py' 
extensions. Hopefully that makes sense. :)

Thanks again!
-M.

Code:

# -*-shell-script-*-

[Meta]
RootName:  <at> mannequin.invigorated.org/pypetals:$SOFTWAREVERSION:1
DisplayName: PyPetals
ShortName: pypetals
Maintainer: Aaron Sebold <bugs>
Packager: Aaron Sebold <bugs>
Summary: pyPetals is a mind game that involves 5 dice and the player 
attempting to figure out an answer based on what is rolled.
URL: http://mannequin.invigorated.org/pypetals/
License: GNU General Public License, Version 2
SoftwareVersion: 3
AutopackageTarget: 1.2

# Only uncomment InterfaceVersion if your package exposes interfaces
# to other software, for instance if it includes DSOs or python/perl
# modules. See the developer guide for more info, or ask on
# autopackage-dev if you aren't sure about interface versioning.
#
# InterfaceVersion: 0.0

[Description]
pyPetals is a mind game that involves 5 dice and the player attempting 
to figure out an answer based on what is rolled.

[BuildPrepare]
# setup directories to copy files into
mkdir -p $build_root/bin $build_root/usr/share/pypetals 
$build_root/usr/share/pypetals/images $build_root/usr/share/pypetals/docs

cp pypetals.py pypetalstk.py $build_root/usr/share/pypetals
chmod +x $build_root/usr/share/pypetals/pypetals.py
chmod +x $build_root/usr/share/pypetals/pypetalstk.py
cp images/dice*.* $build_root/usr/share/pypetals/images
cp docs/* $build_root/usr/share/pypetals/docs

[BuildUnprepare]
unprepareBuild

[Globals]
# Anything put here will be run during makeinstall and at
# install/uninstall time. Define useful variables here:

# export MY_VAR=1

[Imports]
echo '*' | import

[Prepare]
# Dependency checking

require  <at> python.org/python 2.1

[Install]
# Put your installation script here. See the quickstart guide on
# the website for an API cheat-sheet
# installExe bin/*

copyFile pypetals.py "$PREFIX/usr/share/pypetals"
copyFile pypetalstk.py "$PREFIX/usr/share/pypetals"
linkFile pypetals.py "$PREFIX/bin/pypetals"
linkFile pypetalstk.py "$PREFIX/bin/pypetalstk"
copyFiles images/dice*.* "$PREFIX/usr/share/pypetals/images"
copyFiles docs/* "$PREFIX/usr/share/pypetals/docs"

[Uninstall]
# Usually just the following line is enough to uninstall everything
uninstallFromLog

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

"Autopackage struggling to gain acceptance"

Hi,

the article some of us got interviewed for is now available:
http://specialreports.linux.com/article.pl?sid=07/02/09/0854226&tid=138&tid=113

Cheers,
Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

Re: "Autopackage struggling to gain acceptance"

Re: "Autopackage struggling to gain acceptance"

> A good idea WILL withstand the test of time, competition and disbelief if
> the advocates continue to evangelize at any given opportunity, through
> whatever means necessary.

Spoken like a true salesman ;)

> Think about it... if we (each of us, EVERYONE of us) simply convert just ONE
> person per year to autopackage, in 13 years we would have 4000+ users. In 33
> years, we would have the WORLD. (of course, at that point of time, would
> people still install programs into their harddisk? beats me, hehe...)

Haha, the grain of rice philosophy, I like it :)

> There is a saying in my industry... when a winner makes a decision, the odds
> don't count, the challenges don't count, people's opinions don't count, the
> facts don't count, the current objections don't count, the circumstances
> don't count, the lack of money doesn't count... NOTHING counts except the
> winner's decision.

It must be a fascinating industry to work in when the facts don't count!

> Next, I like the comment... how about getting Google to release Google
> Earth, Linux Picasa etc. as autopackages?

I think Picasa packaging is handled by CodeWeavers not Google. We
discussed it at the time, but basically apps shipped by Google have:

a] No dependencies on anything outside of libc and X
b] Little or no desktop integration (menus, etc)
c] Root vs user is not really relevant as they always install as user

So the primary benefits offered by autopackage don't really apply, and
there's not much reason to move to anything else given that users
don't expect/demand it. Like, it's acceptable for an app on Linux to
have no menu entries or icons. If you tried that on Windows/Mac, it
wouldn't be accepted, but on Linux it is.

Actually I'm not sure about [b] for Picasa. CodeWeavers have this
tremendously complex set of Perl scripts that handle menus so they
might have reused that.

> I think it makes sense since Google products are NOT available in any
> repository anywhere. Naturally, whether we can get Google Linux guys to do
> it depends a lot on our dearest Mike Hearn...

Well, I am not really going to argue this, we could ship them with no
installers at all and I doubt anybody would care or notice.
Expectations for ISV software on Linux are really low. Also, Dan Kegel
is more involved with this stuff than me and he is a big fan of the
LSB. We argue about it frequently ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

autopackage 1.2.2 RC2 and apbuild 2.0.3 RC2

Hello all,

I pushed release candidates for autopackage support code and developer 
tools to the main server this past weekend. There is no target date for public 
release.

To test this release either:
  * Download from http://ftp.sunsite.dk/projects/autopackage/1.2.2/
or
  * Set 'AUTOPACKAGE_RUNTIME_VERSION=1.2.2' and force a new download/install

This is a bugfix release that covers:
  * Allow package script to accept arguments such as --prefix, --force, -g, -t
  * Update autosu to set LANG and LANGUAGE to 'C' as it parses looking 
for 'Password:' in English http://autopackage.org/forums/viewtopic.php?t=576
  * copyFiles shows only one progress bar for a multi-argument command
  * ldconfig is handled by session triggers like other system update commands
  * removeLinkerCacheEntry adds trigger for updating ldconfig
  * desktop-file-install output is written to debug log instead of to console
  * Apbuild/GCC.pm: Detect if ld supports --hash-style so that we can force 
both .gnu.hash and .hash to be generated on FC6
  * apgcc: If linker supports --hash-style, generate both .gnu.hash and .hash 
sections so that binary works with linkers with support for either type
  * Ubuntu Edgy could not find package script when support code was installed 
into $HOME and ~/.local/bin was not in $PATH so graphical installs were no go.

Changes since last release candidate:
  * Rolled back a gtk-frontend logview patch which caused problems with 
copyFiles progress bars.
  * Core scripts and stub code updated to "$HOME" from using '~' which was not 
expanding properly and causing LZMA errors when expanding packages with '-x'.

Regards,
Curtis

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...

apg++ and libraries

Hi,

when using g++-3.2 or g++-3.4 I can build a autopackage of Lincity NG,
with apg++ makeinstaller fails.

[...]
C++ ./build/i386-pc-none/optimize/src/lincity-ng/HelpWindow.o 
C++ ./build/i386-pc-none/optimize/src/lincity-ng/prefix.o 
LinkApplication lincity-ng 
ar: TextureManagerGL.o: No such file or directory
[...]
Prepare failed. Please refer to above messages to see why.
[...]

Is there a problem with libraries? Do I need a special APar?
Or is it something else?

Source and autopackage config are on
http://prdownload.berlios.de/lincity-ng/lincity-ng-1.1.0rc2.tar.bz2
and http://svn.berlios.de/viewcvs/lincity-ng/trunk/contrib/autopackage/
Whole output from makeinstaller:
http://uafr.freeshell.org/tmp/lincity-typescript.txt.bz2
I'm using Autopackage Development Environment 1.2.1.

Any ideas how to can make it work?

Tschüß,
Wolfgang
--

-- 
Wolfgang Becker  ***  eMail uafr@...  ***  http://uafr.freeshell.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...