gmane.comp.autopackage.devel

Autopackage 1.3.0 RC1

Jan Niklas Hasse — 2008-09-19T14:50:51

Hi there, first step toward 1.4, which should introduce 64 bit support. It's now possible to create and install so called "Hybrid" packages, which contain both 32 bit and 64 bit binaries. See my second blog post for more information: http://jan-nik.blogspot.com/2008/08/gtkmencoders-trac-page-and-hybrid.html This is my first attempt to do a release, so there might be some major bugs. To test this release run export AUTOPACKAGE_RUNTIME_VERSION=1.3.0 and then install a new package by executing it. # # # # # # Release Page: http://trac.autopackage.org/milestone/1.3 List of fixed bugs: http://trac.autopackage.org/query?status=closed&milestone=1.3

Rename the package command

Jan Niklas Hasse — 2008-08-24T16:53:19

I just found out that there's a package called "mailagent" in Debian which also contains a binary file called 'package'. This means users who have mailagent and autopackage installed can't use both at the same time. So I suggest switching to a new name for the terminal frontend, like 'apkg' or 'autopackage'. Another reason would be that 'package' doesn't really do what it once was named for (http://autopackage.org/faq.html#2_5 ) and certainly never will be, as PackageKit already implemented something like this. For the 1.4 release I think there should still be a 'package' command which forwards all calls to the new command after telling the user that 'package' is deprecated. What do you think? --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

/usr/local news

Damjan Jovanovic — 2008-08-22T13:59:15

Hi I am hereby declaring that my attempts to convert a few commonly used open source libraries to support /usr/local have failed :-(. The pkg-config project took months to reply to my mail and patch. They apparently didn't even understand what I was saying about /usr/local, and months later eventually committed another patch based on mine, which simply changes the way the paths are configured and still doesn't support /usr/local. I mailed them and told them that's not the point of my patch and tried to explain, but nobody responded to that mail. In brighter news, in Ubuntu 8.04, libc does support /usr/local. Looks like /usr/local is supported by libc by default now, /etc/ld.so.conf.d/libc.conf contains these 2 lines: # libc default configuration /usr/local/lib Seeing as libc was the only major library in Ubuntu that didn't support /usr/local, it looks like we can now whitelist Ubuntu 8.04 as a distribution on which installing to /usr/local does work properly. But it simply isn't going to work this way,

coreutils, -c or --bytes=?

Jan Niklas Hasse — 2008-08-02T14:50:47

A user on the forum reported problems using autopackage on PuppyLinux. I found out that tail command is missing the --bytes= option so I proposed to him to replace it with -c. http://watteimdocht.de/autopackage/forum/viewtopic.php?f=4&t=13 I found out that the --bytes= option was introduced in this revision: http://trac.autopackage.org/changeset/1450 Mike, do you still know why you changed it? --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

Debug mode

Hylke Donker — 2008-07-18T11:56:54

Hi, I am trying to use cmake in combination with autopackage, but I haven't had much luck getting it to work so far. So I tried turning debugmode on using: export DEBUGLEVEL=3 But when I run makepackage after that I get the error: apkg-bashlib: line 56: err: Command not found I guess this is a bug in autopackage? Because no log-files were created. Hylke

GCC 4.2 & apgcc

Gabriele Greco — 2008-07-18T07:48:25

It seems apgcc doesn't work correctly with gcc 4.2.1, at least for c++. It used to work perfectly to produce binaries with low requirements as glibc and libstdc++, now if I try to use a binary compiled in ubuntu 8.04 and provide the libstdc++.so.6 distributed with autopackage I get the following error: gabry< at >nevada:~/projects/spectator/bin$ ldd garm ./garm: /amd/mars/root/home/gabry/spectator/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./garm) linux-gate.so.1 => (0xb7f97000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7f6d000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7f4d000) libstdc++.so.6 => /amd/mars/root/home/gabry/spectator/bin/../lib/libstdc++.so.6 (0xb7e64000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e3f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e34000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ce5000) /lib/ld-linux.so.2 (0xb7f98000) So I think we'll need at least to recompile the libstdc++ of gcc 4.2.x wi

Autopackage branched for 1.3

Isak Savo — 2008-07-13T15:02:48

I've branched all the modules in SVN for the work on the next major release of Autopackage. Future development goes into trunk (as usual), while all 1.2 development should be committed to the apkg-1-2 branch (such as bugfixes, backported features etc.) If you want to keep using the bleeding edge autopackage, just stay with trunk. If you want to use svn, but stay on the 1.2 version, you can use either the 'svn switch'[1] command (good if you're low on bandwidth and don't mind doing it manually for all modules) or you can checkout a new copy using the checkout-from-svn script[2] and passing the --branch=apkg-1-2 argument to it. The major driver for 1.3 will be Jan-Niklas' work on 64 bit support. -Isak [1] svnbook seems to be down, but http://www.google.com/search?q=svn+switch should give some hints [2] http://www.autopackage.org/source.html --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For

First Autopackage 1.3 patch

Jan Niklas Hasse — 2008-07-12T17:23:33

Hi everyone, In the last few days I started creating a first patch for autopackage 1.3. Here it is: http://trac.autopackage.org/attachment/ticket/10/x86_64-1.3.diff It adds 64 bit support (based on my last patch) and moves nearly all scripts out of the .package file. So a 1.3 package doesn't need to be executed in order to install it. When a package file is installed all scripts are then created using the templates. The disadvantage is, that the backend.template and the installer.x.template now need to be inside the support code tarball, too. Feedback and further questions appreciated :) - Jan-Nik --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

test, ignore

Isak Savo — 2008-06-07T18:37:27

The list seems to have issues.. let's see if this message gets through --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

Mailing list was down

Isak Savo — 2008-06-09T18:20:04

The list has been down due to hardware problems with the ISP. This affected the web (www.autopackage.org) and mailing list, but the other services worked fine (trac, planet, IRC, forums, and as far as I know support code downloads). The website is back now, and if this message gets through, so is the mailing list. -Isak --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

Packing a C# project.

Neil Munro — 2008-06-04T16:15:46

In an attempt to learn how to autopackage something, I figure I will work on my own project, which is a C# one, but this is going to be a long slow process, since I only have a vague understanding of how autopackage works, and I will need to get my head around several new concepts, so all help is appreciated. So first thing that needs to occur is binary re-locatability, my understanding of this is that autopackage can find any and all files used and created by the application regardless of where on the file system a distribution stores these. Now my problem is integrating this code into my project, I do not know where I should place the files/code and simply adding the files results in a 'two entry points' error in the C# compiler. I have the binreloc C# project file I believe. I just don't know how to integrate it. So if someone could explain to me step by step what to do it would be a massive help. Thanks Neil Munro

Autopackage creation

Hylke Donker — 2008-06-04T15:23:16

--------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

apkg-mimetype.xsl not installed by development package

Leslie Newell — 2008-06-02T15:46:44

If I install the autopackage development package and try to build a package with mime types I get this error: Converting XDG MIME type definitions to KDE 3.x equivalents ... warning: failed to load external entity "/usr/share/autopackage/apkg-mimetype.xsl" If I download and install Autopackage from source then I no longer get this error. Les --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

Blogs and planet autopackage

Isak Savo — 2008-06-01T09:26:20

I think planet autopackage (http://planet.autopackage.org) could use some fresh feeds and was wondering if there are people on the list here that sometimes blogs about something autopackage related. I'm looking for (example): * People who contribute to autopackage code * People who use autopackage for their own programs * People who use autopackage for complex game updater platforms (yeah starez, that's you guys ;-) * People who has nothing to do with autopackage but once in a while post ideas, opinions, or somehow otherwise related information about autopackage * Combination of any of the above Give me a feed URL, a name and (if possible/desired) a hackergotchi[1] image and I'll make sure it gets syndicated on p.a.o. The only requirement is that you post in english, and at least once in a while write about autopackage (or related technology). -Isak [1] http://en.wikipedia.org/wiki/Hackergotchi --------------------------------------------------------------------- To unsubscribe, e-mail: autopackag

testForLib not always detecting libraries in local install

Leslie Newell — 2008-06-01T09:02:14

Hi, I have a package that installs some shared libraries. It is possible that the user may already have those libs on their system so I use testForLib in the skeleton to test for the individual libraries. I do the following on a distro that does not currently have Autopackge (Ubuntu 8): Install my libs.package from a terminal. This downloads the Autopackage core. When it asks for a password I say 'no password' so it installs in the home directory. I now double click on myapp.package which depends on these libs. The package uses the skeleton to find the libs but testForLib fails to find them. I now run package install myapp.package from a terminal and testForLibs works. This is repeatable. If I double click it fails, if I use a terminal it works. Here is the [Test] section from my skeleton. I know it is inefficient but I am not very experienced with shell scripts. [Test] liblist="bindadv bindaui bindbase bindcore bindgl bindhtml bindnet bindrichtext bindstc bindxml bindxrc lua luadebug luasock

Contributing guidelines

Isak Savo — 2008-06-01T08:48:07

Hi All. First of all, a big big thanks to everyone who has been reporting bugs, providing patches and otherwise made sure autopackage is moving forward. I'd like to just provide a few guidelines for contributions that would make it easier (and thus quicker) for me to review and apply patches. * Always use unified diffs (-u argument to diff/svn diff) * Please provide a ChangeLog entry if you think the patch is supposed to be committed as-is TIP: In emacs, just hit "c-x 4 a" and it'll do the magic for you, anjuta and vim has similar tricks * Try to work against svn, and diff with "svn diff". You are all mostly doing the above, but I'd like to give it in writing anyway. I'm also considering giving some of you svn commit access. Thanks, -Isak --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

Integity check failed

Leslie Newell — 2008-05-30T15:38:50

Hi, I am trying to package an application with autopackage using Autopackage compiled from a recent SVN snapshot on OpenSuse 10.2. Everything seems to go to plan and I end up with a .package. However when I run it, I get 'Integrity check failed. This package is damaged'. I then tried packaging the foobar test program and got exactly the same result. Does anyone have any ideas? Thanks, Les --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org

binreloc and gnome_program_init

Thomas Leonard — 2008-05-28T17:48:54

I didn't notice anything on the Autopackage site, but are there any recommendations about using gnome_program_init in a way that allows easy binary relocation? It looks like it's as simple as passing the package's directory to it, e.g. (from a real GNOME app) we have: gnome_program_init(PACKAGE, VERSION, LIBGNOMEUI_MODULE, argc, argv, GNOME_PARAM_GOPTION_CONTEXT, option_context, GNOME_PARAM_APP_DATADIR, PACKAGE_DATA_DIR, GNOME_PARAM_NONE); I replaced the #defined "PACKAGE_DATA_DIR" with some code to work out the correct path at runtime, and it worked perfectly.

Little redesign of package files for 1.3

Jan Niklas Hasse — 2008-05-28T11:21:33

Hi everyone! I thought about 64 bit support. As Isak said, it would need a new major version because of the new parameter "CpuArchitecture*s*" in the header. Furthermore I read this criticism of autopackage: http://kitenet.net/~joey/blog/entry/autopackage_designed_by_monkeys/ Although is definitely not very nice, he does has his points: Autopackage is indeed more like an installer then a "package" which can be easily read by other programs. But I also think it's easy to fix his criticisms: - no formal design documentation: -> add a page for this in the trac wiki - package must be executed to extract its content -> add skip_lines, meta_size, data_size and compression to the header and document how to use them in the wiki page - no path info in the payload -> advise developers to import everything in the right path into their payload. This should be automatically done by "make install $build_root" and "import *". Then there should be a function called "installEverything" which scans the data payload (like

Warp: RSS Package Manager

Neil Munro — 2008-05-27T21:25:30

Hey all, I was wondering what you guys thought of this. http://www.sourceforge.net/projects/warp It's my own project and while I know I have not put out a new release in a few months I have had exams so had to revise for them, but work has continued, and I have one new feature to implement before the new version comes out, I would like to point out the first package format I implemented was in fact autopackage support because my theory is when a new autopackage comes out Warp will automatically check remove the old version and install the new version. I figure it's easier for the user to have a program to automatically update their autopackages than searching for them manually. Warp aim's to bridge the gap between distributions not adding new features until a new release and users wanting new features in the interim. It's written in C# and uses bash calls occasionally to work on Nix systems. It's worth pointing out the code I have on my hard drive is much cleaner and better than what's on sourceforge at t

Autopackage 1.2.5 and APBuild 2.0.6 released

Isak Savo — 2008-05-27T18:50:37

The testing phase is over and RC1 was released as 1.2.5 without changes. Release Page: http://trac.autopackage.org/milestone/1.2.5 List of fixed bugs (19): http://trac.autopackage.org/query?status=closed&milestone=1.2.5 Release Highlights: * Breaking of GTK icon cache fixed. Tickets #31 and #39 * xauth issues on some systems fixed, especially on KDE4 where autosu would hang. Tickets #70 and #78 * Make '--prefix' work as argument to packages again. Ticket #65 * mkapspec can now read existing .apspec files. Ticket #18 * Allow packages to remove their own dependencies. Ticket #46 * Some minor 64bit fixes, such as ticket #33. * ...and many many more fixes... Thanks to everyone who has contributed to this release. Without your support, this release would probably never have happened! The Autopackage Developers --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additio