gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Help with building a XPI


From: Rob Savoye
Subject: Re: [Gnash-dev] Help with building a XPI
Date: Tue, 14 Apr 2009 09:04:01 -0600
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Sylvain Beucler wrote:

> - the versionning is "trunk$(date +%Y%m%d)-y" but Debian's are
>   0.8.x-y. It would make sense to use compatible versions, and allow a
>   release to have higher priority than an earlier snapshot

  Yeah, I just noticed that problem. There was a problem I vaguely
having to deal with how the package is named, guess it's time to clear
that up and do it right.

> - the suite is 'unstable' while it's a Lenny (stable) package. This
>   blocked the upgrade for me because I give 'unstable' a lower
>   priority in /etc/apt/preferences (hence I can hand-pick unstable
>   packages while remaining stable for the rest). So for a stable
>   repository it makes sense to use the 'stable' suite.

  I wouldn't consider snapshots to be stable, that'd be more for releases.

> - apparently the files are not split exactly the same, since when
>   upgrading, I got:

  They should be pretty much the same.

> dpkg : erreur de traitement de 
> /var/cache/apt/archives/gnash_trunk20090313_i386.deb (--unpack) :
>  tentative de remplacement de « /usr/share/pixmaps/gnash.xpm », qui 
> appartient aussi au paquet gnash-common
> dpkg-deb: sous-processus paste tué par le signal (Relais brisé (pipe))
> 
>   (i.e. gnash.xpm is in gnash while it was in gnash-common) This isn't
>   very important as the error disappears after relaunching apt-get .

  It should be in both.

> $ gtk-gnash
> gtk-gnash: error while loading shared libraries: libgnashnet.so.0: cannot 
> open shared object file: No such file or directory
> 
>   Apparently the file isn't present. /usr/lib/gnash/ files also lack
>   the version-less symlinks

  I thought I fixed that, arg....

> I was also asking about XPI though.  IMHO distro repos are fine, but
> are suboptimal if it's possible to provide statically-linked,
> one-click-install binaries.

  I'd like to see this work too. :-) I guess I'll take a break from RTMP
and MIPS hacking and make another attempt to fix xpi package building.
Where I could use help is making sure the XPCOM support actually works,
as the plugin needs that to find the executables. I'd actually prefer to
not statically link the gnash executable, but as the users profile
directory is always different, I haven't figured out a good way to
handle that.

        - rob -




reply via email to

[Prev in Thread] Current Thread [Next in Thread]