headers
Mike Hearn | 1 Aug 2004 13:25

Re: Thoughts on 0.7

On Sat, 2004-07-31 at 15:39 +0100, Mike Hearn wrote:
> - Distro compatibility fixes, eg some distros don't have binutils
>   installed by default and we use nm in the install scripts. Oops.
>   Writing a simple program to check libc for the right versions isn't
>   hard, it's first-grade C really once you find the ELF docs. We also
>   need to include libgcc_s.so in the core code, it's only small so this
>   isn't a problem IMHO.

Add to that: tput does not appear to work correctly on Fedora Core 2

On FC1: ncurses 5.3.20030517
On FC2: ncurses 5.4.20040208

So we get nasty visual artifacts with the progress bar in ttyfe :(

Will the breakage crap ever end? Unfortunately I thought shell scripting
was a reasonably stable platform when I started, how naive I was!

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe <at> sunsite.dk
For additional commands, e-mail: autopackage-dev-help <at> sunsite.dk
Permalink | Reply | 0 comments |
headers
Mike Hearn | 1 Aug 2004 16:50

Re: Thoughts on sealed installers

On Sat, 2004-07-31 at 09:53 -0700, Curtis L. Knight wrote:
> So a few items:
>   Are we in a 100% code review now - submit to list for critique and/or 
> inclusion

Not 100% but big changes or changes to core code should go to the list
yes.

>   Do we add a directory (web page) to ftp to place patches that are post 1.0

No, the list is fine.

> I am offering pull this item out back out of the code and maintain the 
> patch as necessary per better definition from this thread. 

Nope, keep it in.

> Barring that 
> I would want to change the directory to be within the 
> <source-root>/autopackage/packages. Which would you like - a] to patch 
> and fix per the directory update or b] backout and maintain the patch 
> for the entire enhancement. I kind of like the maintenance of the 
> enhancement in a complete patch.

Feel free to fix it now it's in.

On the other points you raised : the difference between half and full
seal is not how many dependencies are included, it's whether autopackage
support code is installed as per normal or simply used temporarily
during the install. In a "full install" there is no package command
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juanjo Alvarez | 2 Aug 2004 00:13

User experience with autopackage

Hi people.

First of all I've to issue the obligated "excuse my engRish".

That said :) yesterday I was playing a little with autopackage for the first 
time, with a lot of help from Curtis on #autopackage (thanks a lot Curtis!) 
that told me to comment my experience with the software here.

The package I was trying to wrap is a Python program. It has one main script 
to be installed in $prefix/bin and a bunch of modules that installs under 
$prefix/lib/animail (I don't like to install 
under /usr/lib/pythonXX/site-packages so when the user distributions updates 
the default python to a new version the program don't stops working for 
them). The manual installation uses a simple Makefile program (make install) 
that created the directories y populates them with the files, appending 
$(DESTDIR)$(PREFIX) to the install path (DESTDIR is neccesary for the Debian 
package building) and PREFIX set by default to /usr. It doesn't have a 
configure.

The .apspec file I wrote for it just uses prepareBuild, unprepareBuild, 
require  <at> python.org/python 2.0 and some copyFiles calls and I call 
makeinstaller with -c so it doesn't try to call ./configure; the strange 
thing here is that makeinstaller doesn't work if the PREFIX in my Makefile is 
set to /usr:

[snip]
Installing to /home/juanjux/tmp/apkg-build-root.21899 ... done
/usr/bin/makeinstaller: line 
474:pushd: /home/juanjux/tmp/apkg-build-root.21899/usr/local: No such file or 
directory
(Continue reading)

Permalink | Reply | 6 comments |
headers
Hongli Lai | 2 Aug 2004 00:22
Picon

Re: User experience with autopackage

Juanjo Alvarez wrote:
> the strange 
> thing here is that makeinstaller doesn't work if the PREFIX in my Makefile is 
> set to /usr:

prepareBuild runs 'make install DESTDIR=$build_root'
So your Makefile must support DESTDIR.

> [snip]-----------------
> configure:20337: checking if we can compile an X-Qt-KDE application
> configure:20378: apg++ -o conftest -O2 -Wall -O2 -march=i586 -mcpu=i686 -pipe 
> -I/usr/X11R6/include -I/home/juanjux/kde3.3-be
> ta1/./include -I/home/juanjux/kde3.3-beta1/./include   -I/usr/X11R6/include -s  
> conftest.cc -L/home/juanjux/kde3.3-beta1/./l
> ib -L/usr/X11R6/lib -L/home/juanjux/kde3.3-beta1/./lib    -L/usr/X11R6/lib  
> -lkdecore -lqt-mt  -lXext -lX11 -Wl,-rpath /home
> /juanjux/kde3.3-beta1/./lib -ldl >&5
> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
> conftest.cc: In function `int main()':
> conftest.cc:56: warning: `__comp_ctor' is deprecated (declared 
> at /home/juanjux/kde3.3-beta1/./include/kapplication.h:198)
> g++: /home/juanjux/kde3.3-beta1/./lib: linker input file unused because 
> linking not done
> g++: /home/juanjux/kde3.3-beta1/.o: No such file or directory
> [snip]---------------------------------

This is probably a bug in apgcc. I'll take a look at it later.

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Juanjo Alvarez | 2 Aug 2004 01:26

Re: User experience with autopackage

On Mon, Aug 02, 2004 at 12:22:11AM +0200, Hongli Lai wrote:
> Juanjo Alvarez wrote:
> >the strange 
> >thing here is that makeinstaller doesn't work if the PREFIX in my Makefile 
> >is set to /usr:
> 
> prepareBuild runs 'make install DESTDIR=$build_root'
> So your Makefile must support DESTDIR.
I've:

DESTDIR = /usr

And all the paths are $(DESTDIR)-appended. Manual make install works but
trying to makeinstaller -c with DESTDIR=/usr in the Makefile gives:

--------------------
[snip]
[this is from the make install]
cp src/*.py src/*.pyo /home/juanjux/tmp/apkg-build-root.28132/usr/lib/animail
cp animail /home/juanjux/tmp/apkg-build-root.28132/usr/bin
chmod +x /home/juanjux/tmp/apkg-build-root.28132/usr/bin/animail
cp -R docs/*    /home/juanjux/tmp/apkg-build-root.28132/usr/share/doc/animail
cp docs/animail.2.gz /home/juanjux/tmp/apkg-build-root.28132/usr/share/man/man2
[end make install]

Installing to /home/juanjux/tmp/apkg-build-root.28132 ... done
/usr/bin/makeinstaller: line 474: pushd: /home/juanjux/tmp/apkg-build-root.28132/usr/local: No
such file or directory
--------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Hongli Lai | 2 Aug 2004 10:53
Picon

Re: User experience with autopackage

Juanjo Alvarez wrote:
> It only works if I put DESTDIR to /usr/local in the Makefiles. I've also
> tried:
> 
> ifndef DESTDIR
>     DESTDIR =/usr
> endif
> 
> But it still doesn't work. What I'm missing?

Try setting PREFIX to /usr/local

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...
Permalink | Reply | 2 comments |
headers
Mike Hearn | 5 Aug 2004 12:40

On python programs

Hey guys,

I have email access from work again, yay, so while I won't be doing any 
hacking I can at least stand at the sidelines and egg you all on.

I saw there was a thread about Python programs lately. Before we can 
properly autopackage python apps we need to find a way to make them 
relocatable: a Perl style FindBin hack is acceptable in the short term 
but longer term the interpreter itself needs to expose this information. 
The Python code base is not scary, does somebody want to write such a 
patch (I'm assuming it doesn't already expose this information). We 
could then provide a simple drop in file a la prefix.c which uses the 
new API if the host runtime supports it and falls back to PATH searching 
etc if not.

Any volunteers? The project needs you to get working, right now it's 
really just Curtis hacking on the code as I'm out of action and Hongli 
is working on gaming stuff. So come on, sit down and write code you guys! :)

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...
Permalink | Reply | 0 comments |
headers
Josh Bath | 6 Aug 2004 05:15
Picon
Favicon

SUSE 9.1 :(

Hey guys, there seems to be a problem with SUSE 9.1's libsigc++.

OK when I try to install Inkscape (root-install), this happens...

http://img.photobucket.com/albums/v64/super_science_monkey/AP1.jpg
http://img.photobucket.com/albums/v64/super_science_monkey/AP2.jpg

But according to Yast, libsigc++ is installed

http://img.photobucket.com/albums/v64/super_science_monkey/AP3.jpg

So then I try a user-install and everything works fine and Autopackage 
install libsigc++

http://img.photobucket.com/albums/v64/super_science_monkey/AP4.jpg

OK hope that helps. :)

_________________________________________________________________
Take charge with a pop-up guard built on patented Microsoft® SmartScreen 
Technology.

http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
  Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bryce Harrington | 6 Aug 2004 06:58

Re: SUSE 9.1 :(

Are you installing the nightly build or the 0.39 release?
The 0.39 release should install fine with autopackage.  

I don't know the status of the nightly built autopackage, but I was able
to install CVS Inkscape from source on SuSE 9.1 last weekend.  My notes
are available here:

    http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape

Bryce

On Thu, 5 Aug 2004, Josh Bath wrote:
> Hey guys, there seems to be a problem with SUSE 9.1's libsigc++.
> 
> OK when I try to install Inkscape (root-install), this happens...
> 
> http://img.photobucket.com/albums/v64/super_science_monkey/AP1.jpg
> http://img.photobucket.com/albums/v64/super_science_monkey/AP2.jpg
> 
> But according to Yast, libsigc++ is installed
> 
> http://img.photobucket.com/albums/v64/super_science_monkey/AP3.jpg
> 
> So then I try a user-install and everything works fine and Autopackage 
> install libsigc++
> 
> http://img.photobucket.com/albums/v64/super_science_monkey/AP4.jpg
> 
> 
> OK hope that helps. :)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Hearn | 6 Aug 2004 11:14

Re: SUSE 9.1 :(

Bryce Harrington wrote:
> I don't know the status of the nightly built autopackage, but I was able
> to install CVS Inkscape from source on SuSE 9.1 last weekend.  My notes
> are available here:
> 
>     http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape

They are currently one and the same, I haven't packaged all the 
dependencies of the new CVS HEAD yet (and I can only work on it at 
weekends). It's about 50% done, I've packaged GTKmm 2.4, Glibmm 2.4, 
libsigc++ 2 but not libgc and I haven't updated or uploaded anything yet.

I'll see if I can finish it off this weekend.

On the problem Josh was seeing, the xterm pops up because I (doh) left a 
  breakpoint in there. I forget what causes it, I'll see if I can figure 
it out this weekend - sorry for the inconvenience Josh! Now you know why 
we're not 1.0 yet! :)

0.7 is looking like it'll be mostly plain old bugfixing and distro 
compatibility work.

thanks -mike

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe@...
For additional commands, e-mail: autopackage-dev-help@...
Permalink | Reply | 0 comments |

Gmane