http://permalink.gmane.org/gmane.comp.autopackage.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.autopackage.devel/6896 On Mon, Dec 1, 2008 at 6:30 PM, Eugene Zolenko <EugeneZolenko-XYgkjQFSZqy1Z/+hSey0Gg< at >public.gmane.org> wrote: Ok, I will look into applying fixes to those tickets for the stable branch. -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 Isak Savo 2008-12-02T18:18:22 http://permalink.gmane.org/gmane.comp.autopackage.devel/6895 On Mon, Dec 1, 2008 at 9:42 PM, Eugene Zolenko <EugeneZolenko-XYgkjQFSZqy1Z/+hSey0Gg< at >public.gmane.org> wrote: Yes, it looks like it could be added without breaking anything. -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 Isak Savo 2008-12-02T18:14:29 http://permalink.gmane.org/gmane.comp.autopackage.devel/6894 If this is going to be an official release, can we also add fix for #93? ________________________________ From: Jan Niklas Hasse [mailto:jhasse-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org] Sent: Monday, December 01, 2008 12:07 PM To: autopackage-dev-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org Subject: Re: New bug fix release Hi there, Since an official release would be cool, what do you both think about making an official release out of Eugene's? < at >Eugene Am I right that you're UnFleshed One on trac? What do you think about joining the team? I think it would be a very good idea, since we could need some help and you are one of the few people left using Autopackage and also committing patches. Eugene Zolenko 2008-12-01T20:42:01 http://permalink.gmane.org/gmane.comp.autopackage.devel/6893 Yep, that's me. I wont mind joining the team, even if for bragging rights :-), although don't expect a lot of active development from me (especially in between our own linux releases, which are few and far apart). ________________________________ From: Jan Niklas Hasse [mailto:jhasse-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org] Sent: Monday, December 01, 2008 12:07 PM To: autopackage-dev-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org Subject: Re: New bug fix release Hi there, Since an official release would be cool, what do you both think about making an official release out of Eugene's? < at >Eugene Am I right that you're UnFleshed One on trac? What do you think about joining the team? I think it would be a very good idea, since we could need some help and you are one of the few people left using Autopackage and also committing patches. Eugene Zolenko 2008-12-01T19:31:45 http://permalink.gmane.org/gmane.comp.autopackage.devel/6892 Hi there, Since an official release would be cool, what do you both think about making an official release out of Eugene's? < at >Eugene Am I right that you're UnFleshed One on trac? What do you think about joining the team? I think it would be a very good idea, since we could need some help and you are one of the few people left using Autopackage and also committing patches. Jan Niklas Hasse 2008-12-01T19:07:10 http://permalink.gmane.org/gmane.comp.autopackage.devel/6891 I thought 2 different 1.2.5 versions would be more confusing :). Although that was essentially what I was thinking about -- patching support code I'm sealing and making sure it wouldn't conflict with later official releases. Official release would be perfect. I just didn't want to ask for that :). Yes, 109 is mainly what I care about, since it breaks installing my packages over previous version. (And 105 is nice to have, as it simplifies things for me internally). That is, unless testing here finds something else I can't fix externally. >_< --------------------------------------------------------------------- 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 Eugene Zolenko 2008-12-01T17:30:44 http://permalink.gmane.org/gmane.comp.autopackage.devel/6890 On Sat, Nov 29, 2008 at 3:39 AM, Eugene Zolenko <EugeneZolenko-XYgkjQFSZqy1Z/+hSey0Gg< at >public.gmane.org> wrote: No, please don't make your own version. This can become very confusing Can't you just take the patches you need and still call it 1.2.5-eugene (or something)? Is it just those tickets? Maybe we can put those patches into the 1.2 branch and make an official release? Yeah 1.3 is the unstable branch so you shouldn't switch to it for untill it's called 1.4 -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 Isak Savo 2008-11-29T08:55:20 http://permalink.gmane.org/gmane.comp.autopackage.devel/6889 Hi, Do you guys mind if I hijack one minor version and make my own 1.2.6 release, which would be sealed into my installs? :-) I'll take 1.2.5 and add fixes for ticket 109 and maybe 93 and 105. I don't want to move to 1.3.0 yet, even if it is released before we do (no time to test -- we are releasing soon). Then if you decide to release another 1.2 it should be 1.2.7, so as to avoid confusion. What do you think? Eugene Zolenko 2008-11-29T02:39:57 http://permalink.gmane.org/gmane.comp.autopackage.devel/6888 Okay, I might think about it for >=1.5. Jan Niklas Hasse 2008-11-19T14:44:43 http://permalink.gmane.org/gmane.comp.autopackage.devel/6887 I'm a strong believer in "if it ain't broken, don't fix it" so without pretty good reasons I don't see why. (I think this current issue is fixable) That said, if you or someone else does all the work and migrates with no loss in functionality, then I'm not gonna be a pain in the ass and object :) -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 Isak Savo 2008-11-18T20:40:09 http://permalink.gmane.org/gmane.comp.autopackage.devel/6886 Yep It could also be a breaking change in autotools. Ubuntu is often quick Ah thx. I tried my best with update-alternatives but the old version of automake didn't seem to fix it. I will just set up a new VM with 8.04. Btw: What do you think of switching to SCons as the build system? I'm already using it for my C++ projects and it's really clean and easy. Jan Niklas Hasse 2008-11-18T19:23:52 http://permalink.gmane.org/gmane.comp.autopackage.devel/6885 Was this a clean checkout? Does running 'make maintainer-clean' (or other types of clean) and/or re-running autogen.sh solve it? It could also be a breaking change in autotools. Ubuntu is often quick to upgrade to the latest and greatest and they are not often fully compatible (they are, however, parallell installable, so you can install older auto* tools and change which should be the default using the update-alternatives program) -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 Isak Savo 2008-11-18T18:05:25 http://permalink.gmane.org/gmane.comp.autopackage.devel/6884 I just tried to build autopackage in a Virtual Machine with Ubuntu 8.10 x86 and got the following error when trying to build the gtk manager: checking for GTK2... yes configure: error: conditional "am__fastdepCXX" was never defined. Usually this means the macro was only invoked conditionally. make: *** Keine Regel, um »clean« zu erstellen. Schluss. make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden. Schluss. cp: Aufruf von stat für „autopackage-manager-gtk" nicht möglich: No such file or directory WARNING: Manager was not built. Make sure that you remembered to run ./autogen.sh in manager/ Does someone know how to fix this? I already searched the internet a bit but couldn't find a solution. Jan Niklas Hasse 2008-11-18T13:41:25 http://permalink.gmane.org/gmane.comp.autopackage.devel/6883 Right now there's not much need. The purpose of apbuild is to support older systems, and since 64bit distros are a relatively new thing, apbuild doesn't really do much good. That said. History has taught us that compatibility gets broken once in a while so in the future apbuild may be needed for 64bit systems aswell. True. The bogus dependency stripper could surely benefit 64bit binaries too. Aswell as the other niceties added by apbuild. I tend to (wrongly) think of apbuild as the tool-to-fix-glibc-errors :) Agree. -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 Isak Savo 2008-11-12T20:26:18 http://permalink.gmane.org/gmane.comp.autopackage.devel/6882 Ah, i see. I'm not sure, but the GLIBC symbols isn't everything apbuild does, so there is a reason to run apgcc on 64 bit, is there actually? If yes, we should think then how apgcc is triggering this particular linker error and then disable the feature for x86_64. --------------------------------------------------------------------- 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 Jan Niklas Hasse 2008-11-12T19:50:42 http://permalink.gmane.org/gmane.comp.autopackage.devel/6881 I get those missing GLIBC_2.0 symbols, as mentioned earlier in the thread. Isak replied saying I should not use apgcc to compile 64-bit programs. -Justin --------------------------------------------------------------------- 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 Justin Karneges 2008-11-12T19:36:47 http://permalink.gmane.org/gmane.comp.autopackage.devel/6880 I added the latter and will commit it later this evening, thx. Thanks for reporting this. I will try my best to fix it. Could be related to http://trac.autopackage.org/ticket/104 Why shouldn't apgcc be able to compile for x86_64 machines? --------------------------------------------------------------------- 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 Jan Niklas Hasse 2008-11-12T18:04:29 http://permalink.gmane.org/gmane.comp.autopackage.devel/6879 I suppose this should really be: have apgcc abort if the target arch is x86_64. The host arch should not affect it, so that cross-compiling stays possible. -Justin --------------------------------------------------------------------- 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 Justin Karneges 2008-11-12T17:47:32 http://permalink.gmane.org/gmane.comp.autopackage.devel/6878 That was it! The installer now works. So I guess it was all fine and I misunderstood how it worked. I might suggest that you make this more idiot-proof. Specifically: - have apgcc abort if being invoked on x86_64 - have makepackage refuse to package an x86_64 executable if it doesn't target AP 1.4 Btw, I got this output at the end of makepackage: /home/jkarneges/.local/share/autopackage/apkg-funclib: line 2149: /tmp/autopackage.865614527/reporting: No such file or directory rm: cannot remove directory `/tmp/autopackage.865614527/payload/< at >barracuda.com/imclient:3.3.2/share/barracuda/gfx/.svn/prop-base': No such file or directory Maybe a race in some cleanup code? Permissions look fine. Anyway, this didn't seem to affect creation of the installer. Thanks, -Justin --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/SzgSGea1oA< at >public.gmane.org For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/ Justin Karneges 2008-11-12T17:26:14 http://permalink.gmane.org/gmane.comp.autopackage.devel/6877 Strange, this should have been fixed a long time ago. Can you send me your package? Make sure you've set AutopackageTarget to 1.4, otherwise 64 bit support won't work. --------------------------------------------------------------------- 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 Jan Niklas Hasse 2008-11-12T14:42:19 http://permalink.gmane.org/gmane.comp.autopackage.devel/6876 As you guess, these are bogus warnings. They are true (your *aren't* using apbuild, and there *are* symbols from glibc2.3 in the binaries) but it shouldn't pose a problem for 64bit systems. I'm gonna leave this one to Jan Niklas, cause he's the 64bit champion around here :) My guess is that you've hit a bug in our (not-yet-completed) 64bit handling code. -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 Isak Savo 2008-11-12T07:53:33 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.autopackage.devel