gmane.comp.autopackage.devel

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-25T20:36:57

Patch attached to #102: http://trac.autopackage.org/attachment/ticket/102/ticket-102.patch and committed as r2515. --------------------------------------------------------------------- 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

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-25T18:51:17

They are the same. I will commit a fix that uses the first path returned -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

Re: Autopackage 1.3.0 RC1

Jan Niklas Hasse — 2008-09-25T18:47:59

Is there a difference in the output of dumpverdefs for both? If there isn't, i would suggest using the first way, because that's the easiest one :) I read in the TODO file, that we should switch to something with dlopen anyway. I don't know if that's actually possible.

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-25T18:40:56

One was /lib/libc.so.6 and the other, IIRC was /lib/tls/i686/cmov/libc.so.6 They *are* different files (according to diff and ls) but I've no idea what the difference is It's easy to fix this one, but I'm not sure which fix to do.. * just take the first entry returned by _getLibraryPaths * take both and merge the result of dumpverdefs for both (all) of these libraries * figure out which one is the real one (the one that will be used by the program in the package) and use that one -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

Re: Autopackage 1.3.0 RC1

Jan Niklas Hasse — 2008-09-25T17:26:18

Hi Isak, Thanks for testing it. Unfortunately I'm very very busy for the next two weeks because of several exams, so I can't work on all those errors. Can you tell me which two paths are returned on your system? I never thought it was possible that there are two paths to libc.so.6. - Jan Niklas

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-24T16:17:39

Wee! Think I found it... http://trac.autopackage.org/browser/main/trunk/share/apkg-script-utils?rev=2503#L3409 I do get two paths from _getLibraryPaths, and dumpverdefs cannot handle that. Ticket filed as http://trac.autopackage.org/ticket/102 -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

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-24T15:51:34

Ok, I may have a guess here.. I just picked the built package in my svn checkout of "foobar" which may not be compatible with the 1.3 release (maybe it requires 1.4 or something?) I re-tried everything with another package I had on my harddisk and autopackage did not complain about not finding the package. What I got now was a glibc missing symbols error. I tried several different packages (including http://ftp.sunsite.dk/projects/autopackage/packages/mkapspec-0.5.x86.package which *should* work fine) and all of them gave me the same glibc error. Can anyone reproduce this? Get the above mkapspec package and execute it after doing export AUTOPACKAGE_RUNTIME_VERSION=1.3.0 -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

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-24T15:41:09

Tried on Ubuntu Hardy 8.04.1 and it failed: First, I got some errors after the autopackage-gtkfe installation: rm: cannot remove directory `/tmp/autopackage.49749541/payload/< at >autopackage.org/autopackage-gtk:1.3.0/share/locale/fr/LC_MESSAGES': No such file or directory rm: cannot remove directory `/tmp/autopackage.49749541/payload/< at >autopackage.org/autopackage-gtk:1.3.0/libexec/autopackage-gtk': No such file or directory rm: cannot remove directory `/tmp/autopackage.49749541/payload/< at >autopackage.org/autopackage-gtk:1.3.0/bin': No such file or director (Could this be the change we did regarding the removal of temp files?) Result was that "/tmp/autopackage.49749541/payload/< at >autopackage.org/autopackage-gtk:1.3.0/" was left behind.. Then it didn't install the actual package: (in bold red): Package ./Foobar Test Program 1.2.3.package could not be found Not sure about this one.. never seen this before. -Isak --------------------------------------------------------------------- To unsubscribe, e-mail: autopa

Re: Autopackage 1.3.0 RC1

Isak Savo — 2008-09-20T09:25:29

Great Work Jan Niklas! I'll give it a spin this weekend! Anyone trying this, please post results on this thread or swing by IRC. A simple "it worked fine on distro xyz" is great for us to know! -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

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

Re: Rename the package command

Jan Niklas Hasse — 2008-08-29T13:15:47

Older stubs are looking for the apkg-funclib file and then call the _install function inside it. As far as I know, there are no direct calls to the package command. If there are, well, the command will still be available. No, not yet. Should I create one for 1.3.1? Btw: I'm finished with the tickets for 1.3, can we release it this weekend? We should meet on IRC, because of creating the hybrids. --------------------------------------------------------------------- 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

Re: Rename the package command

Isak Savo — 2008-08-29T14:26:46

Ok, good. (BTW, there are a couple of sourced functions too.. the %XYZFOOO% entries in the stub, are they clear too?) But at some point, we plan on removing the 'package' link/wrapper script, right? Yeah do that. It's easier to track this issue later on and it's easier to point people to if they wanna know about the change. I'm gonna be a bit busy at least friday and saturday, but I'll try to be on when I can. -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

Re: Rename the package command

Isak Savo — 2008-08-29T06:41:23

I presume this is to solve the execute-package-directly bug, right? How about the other stubs? Aren't there calls to 'package' inside the other stubs? Or in the included code in existing packages. How will existing packages cope with renaming the 'package' command? We *don't* want to break old packages. I think "autopackage" is a better name. It is, after all, our "main executable" and it seems fair to name it after the project. It's a bit longer to write though... :-/ I'd say hold on to that patch for a while so that we can think this one through. Is there a ticket open for this issue? -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

Re: Rename the package command

Jan Niklas Hasse — 2008-08-28T21:03:45

I think it's very uncommon. I only heard of it by typing "package" without having autopackage installed. Ubuntu displays a message then in by which package this command is available. You're right, there's no user which is running into this problem afaik. But maybe the fix would be for reasons of precaution only. I'm also saying this, as the new stub.4.template is directly calling "package install " if autopackage 1.4 is installed. That's another reason, why I would change the name now, before 1.4. What do you think of 'apkg'? If that name is okay, I can commit a patch tomorrow. --------------------------------------------------------------------- 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

Re: Rename the package command

Isak Savo — 2008-08-28T20:44:24

sorry for the late reply On Sun, Aug 24, 2008 at 6:53 PM, Jan Niklas Hasse public.gmane.org> wrote: How common is this mailagent program? We've never heard of any issues AFAIK during the 5 or so years autopackage has been alive. Yeah, this is true. Might be good enough reason to rename it. Good idea. The purist in me agree with you. But the pragmatic guy on my shoulder says it may not be worth it :) Mostly because we're solving a problem which I'm not sure exists for any of our users... (please convince me otherwise) -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

Re: /usr/local news

=?UTF-8?Q?Rykel=E2=84=A2_(Aen=E2=84=A2)?= — 2008-08-27T01:45:20

Guys (and gals), I am not sure if this is going to be helpful, but next few weeks I will be interacting with the Team Ubuntu Singapore group and planning some agenda for Software Freedom Day. As autopackage advocate, I will definitely highlight the paramount importance of autopackage to the audience and see what feedback I get. Please let me know if there is anything else I might need to take note of, thanks!! Best Regards, Rykel™ The Team™ Asia http://tinyurl.com/TeamAsia +65 8400 2102 (Singapore) +6 013 4008749 (Malaysia) +84 93 2643369 (Vietnam) gmail.msn.yahoo.skype.twitter.delicious.ebay.gizmo5.meebo: rykel98 | aol: aenrykel | icq: 22768140 2008/8/23 Hongli Lai plan99.net>

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

Re: /usr/local news

Hongli Lai — 2008-08-23T07:54:39

It's sad to see that nothing has changed after all these years. :( But good luck guys, I really admire your dedication! From what I can see, it was and still is more of a political problem than a technical problem. The challenge lies in finding supporters, not actually writing code. We're in a rather strange situation right now: the people who are in charge don't care, while the people who complain that Linux software installation should be easier aren't in charge, and both groups have already decided that the other group consists of idiots. On top of that, the people who aren't in charge, but either don't care or oppose to the idea, are very vocal. I still read complaints about Linux software installation and cross-distro compatibility on places like Slashdot and OSNews. Would it be a good idea unite as many of these people as possible in an effort to convince distributions and the rest of the community that people care? A while ago I had contacted the person who's behind the LSB packaging

Re: /usr/local news

Isak Savo — 2008-08-22T23:19:58

I'm sorry to hear that, although I'm also not completely surprised... It's a hard current you're trying to swim against. This is indeed good news. If complaints arise again, I guess we can implement the whitelist code and immediately whitelist ubuntu 8.04. :-( I'd like to write some encouraging words here - that we're getting there and all that... but I kind of share the same thoughts as you. :-/ But hey - who knows... LSB has lately gotten a lot of focus so who knows what happens after the 4.0 release is out :) /me is trying to be optimistic -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

/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