I am currently working on getting the Adobe AIR SDK on Gentoo through portage and also creating a means of writing ebuilds for AIR applications. Gotchas are that upstream only prvides a tarball with a fixed name, so updated to it will break the ebuild because there is no way of distinguishing versions and that it is fetch-restricted. Reproducible: Always
Created attachment 189510 [details] Ebuild for Adobe Air SDK
Created attachment 189512 [details] files/airstart: wrapper script to start air applications
Created attachment 189514 [details] AdobeAirSDK license as referred to in the ebuild
Created attachment 189516 [details] files/airstart: Wrapper script to start AIR applications Fixed typo.
This is not a native 64 bit binary, so it will need emul-linux- stuff to run on amd64 (if it does, I'm not sure though)
@Serkan: Do you have any idea what I need in particular? It does work on amd64 (my arch), I'm not so sure which of the emul-linux-* packages the package depends on ... Any hints?
Note that bug 251475 also contains an ebuild for this.
as far as the download naming business goes, this can be fixed with EAPI , you can rename downloads i.e SRC_URI="http://airdownload.adobe.com/air/lin/download/latest/AdobeAIRSDK.tbz2 -> ${P}.tbz2" Though the fetch restriction will have to be turned off. see http://devmanual.gentoo.org/ebuild-writing/eapi/index.html for more infromation
Created attachment 202323 [details] adobe-air-sdk-bin-1.5.2 ebuild The latest Air SDK from Adobe is version 1.5.2, this ebuild is modified to suit. It also fixes the weird file permissions and broken symlinks within the SDK, and dispenses with the separate 'airstart' file, instead creating one on-the-fly.
Created attachment 202328 [details] adobe-air-sdk-bin-1.5.2 ebuild, updated A little update (added postinst usage instructions). I don't really know which, if any, emul-linux packages AIR needs on amd64. It works on both x86 and amd64 here, the again I have almost all possible emul-linux packages installed on amd64... Ldd is not really helping here.
isn't this technically a dupe of bug#251475 ....
Created attachment 211006 [details] a script to run air apps with no explicit extraction Copied from http://aur.archlinux.org/packages.php?ID=16940 This works better than the explicit step of extracting files in a specific location.
Created attachment 211009 [details] New Ebuild to extract files in a Temp Location and run the AIR App from there Run script copied from the Arch Linux Repository. Changed the Ebuild given to create the appropriate script file.
Created attachment 222575 [details] Cleaned up, versioned ebuild I've removed most of useless mangling, updated the ebuild for the newest version I was able to find and made it able to fetch the correct version of tarball. Please note that this ebuild is for amd64, and lacks x86 dependecy specifications (someone needs to find one which libraries are really needed).
Created attachment 222587 [details] ...and the cleaned up airstart script
Created attachment 222591 [details] Misc fixes
Created attachment 222593 [details] MIME database package for .air files
Created attachment 222595 [details] Associate airstart with .air files
Created attachment 222597 [details] Ebuild with .desktop & mime
I've commited the ebuild as dev-util/adobe-air-sdk-bin into Sunrise overlay. Please update the summary, add 'EBUILD InOverlay' to bug KEYWORDS and '[sunrise overlay]' to 'status whiteboard'.
(In reply to comment #20) > I've commited the ebuild as dev-util/adobe-air-sdk-bin into Sunrise overlay. > Please update the summary, add 'EBUILD InOverlay' to bug KEYWORDS and '[sunrise > overlay]' to 'status whiteboard'. > I've emerged it and when I try to start TweetDeck, it fails writing this: $ airstart TweetDeck_0_34.2.air The program 'adl' received an X Window System error. This probably reflects a bug in the program. The error was 'BadWindow (invalid Window parameter)'. (Details: serial 115 error_code 3 request_code 20 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) (adl:14620): Gdk-WARNING **: gdkdrawable-x11.c:952 drawable is not a pixmap or window
(In reply to comment #21) > $ airstart TweetDeck_0_34.2.air > The program 'adl' received an X Window System error. > This probably reflects a bug in the program. I was unable to reproduce the problem. However I used TweetDeck 0.34.3. Does the problem still exist for you? Does It occur in other air's?
Created attachment 246331 [details] new version 2.0.2 just change the version from the 1.5.3 to 2.0.2
(In reply to comment #23) > Created an attachment (id=246331) [details] > new version 2.0.2 > > just change the version from the 1.5.3 to 2.0.2 > Here is a problem, after i just change the version, it will report "rm -r opt/Adobe/AirSDK/runtimes/air/linux/Adobe AIR/Versions/1.0/Resources/nss3/None failed： No such file or directory" error and return. So i change the remove command in ebuild. But why it didn't report error when i emerge version 1.5.3, there is no a file named ”None“ also...
Created attachment 250327 [details] Will not attempt fetch archive from distfiles.gentoo.org
This is a very important package you know. Votes?
What is the status of ebuild is sunrise? Are there any devs willing to take care of it? Otherwise we can use some proxy maintainers for that
They are outdated in all overlays. I've made an ebuild off the runtime rpm, but if someone could figure out a way to run AIR applications...
Someone tried those bin packages? I dont know how many people complained, but I did stating the Gentoo community has lots of development power, and in a few day they released the bin.
@comment 28: could you provide this ebuild? @comment 29: They seem to have removed the tbz2 version. On amd64 I could not install the bin-version, it complains about not having a rpm- or deb-based distro.
Created attachment 256190 [details] Adobe Air SDK version bump to latest version 2.5 Adobe Air SDK version bump to latest version 2.5
@comment 31: works on amd64. Thanks. Any chance to get that to sunrise or main portage tree?
(In reply to comment #31) > Created an attachment (id=256190) [details] > Adobe Air SDK version bump to latest version 2.5 > > Adobe Air SDK version bump to latest version 2.5 > Works fine on amd64.
On hardened it require chpax -m /opt/Adobe/AirSDK/bin/adl
version 2.6 is out, can install it after simply rename the ebuild file, but always got crash. Application crashed with an unhandled SIGSEGV Crashlog has been dumped in /tmp/airCrashLogs/0506_1807_gZl3vH
In light of the events, should we deprecate this bug? http://blogs.adobe.com/flashplayer/2011/06/adobe-air-and-linux-increasing-distribution-on-devices.html
I installed dev-util/adobe-air-sdk-bin-1.5.3 from the sunrise overlay, but when I tried to start Botanicula (http://amanita-design.net/games/botanicula.html) I get this error: wonko@weird ~ $ airstart ~/apps/games/Amanita/Botanicula/Botanicula.air invalid application descriptor: descriptor version does not match runtime version Then I found this bug and installed dev-libs/adobe-air-sdk-bin-2.5. had a little trouble, it was not obvious to me I had to create a files directory and put some of the attachements named airstart, airstart.desktop and adobe-air-sdk-bin.xml into it. Anyway, now I get this error: wonko@weird ~ $ airstart ~/apps/games/Amanita/Botanicula/Botanicula.air invalid application descriptor: Unknown namespace: http://ns.adobe.com/air/application/2.6 The game is working if I start it like this, with AdobeAIRSDK.tbz2 2.6 from http://helpx.adobe.com/air/kb/archived-air-sdk-version.html installed manually: dir=~/apps/games/Amanita/Botanicula ~/apps/air-sdk/bin/adl "$dir/META-INF/AIR/application.xml" "$dir/" But it would be nice to have a Gentoo package for this.
Created attachment 347398 [details] airstart with sed-statement to change namespace to 2.6 Uploading a new airstart-script that sets the application namespace to 2.6 if there's originally a 3.x namespace set. AIR applications nowadays usually use the 3.x namespace, so by using this sed statement the application will at least try to start as a 2.6 application. No guarantees that it will work, of course.
Just as a note: I tried to install dev-util/adobe-air-sdk-bin-2.6 from the "gamerlay" overlay (http://gpo.zugaina.org/Overlays/gamerlay/dev-util/adobe-air-sdk-bin) and it failed since "app-emulation/emul-linux-x86-gtklibs" (needed as dependency) is no longer in tree. I assume this matters as well for the ebuilds found here.
Should we close that issue with resolution "WONTFIX"? The last AIR SDK for linux is four year old and there is no further (public) development. Quote: https://helpx.adobe.com/air/kb/install-air-2-64-bit.html Note: Beginning June 14 2011, Adobe AIR is no longer supported for desktop Linux distributions. Users can install and run AIR 2.6 and earlier applications but can't install or update to AIR 2.7. The last version to support desktop Linux distributions is AIR 2.6. AIR 2.6 is available from the AIR Archive.
It's not destined for the tree, certainly, though preferable resolutions might be OBSOLETE or UPSTREAM. If overlays still need existing version, they need to change the dependency to x11-libs/gtk+[abi_x86_32] (from memory, apologies if wrongly spelt)
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
