Release: Camelbox 2008.120.0145Z
spicyjack
I'm pleased to announce a new release of Camelbox, 2008.120.0145Z
(April 28th, 2008). Changes for this release include:
- fixed logic for saving downloaded files when "Keep downloaded
archive files" checkbox is checked
- packaged Asciio application (http://search.cpan.org/perldoc?
App::Asciio)
- changed the HTTP downloader .dll library used to download archive
files; fixes problems with downloading archive files from machines on
the same subnet as the client
You can download the new installer here:
http://camelbox.googlecode.com/files/camelbox_2008.120.0145Z.exe
Upgrade Recommendation: Upgrading is only recommended if you want to
pick up the new features. Uninstalling the previous release is highly
recommended prior to installing the new one.
For support with this software, please send e-mail to the Camelbox
mailing list, located at came...@googlegroups.com.
Thanks,
Brian
spicy jack
> I got a Windows XP running in a virtual box so I could give a try to camelbox.
> The install looked very professional. The install time is ok for a development
> environment but a tad long if one was to install a single application.
A binary created with PAR::Packer would not take as long to install,
this is true. You may not need to perform a full install to get
Asciio going, probably installing Perl, Core GTK, and the Asciio
packages would be enough. Try a fresh Camelbox install using the
install option labeled "Perl with Core GTK Binaries" (it's in the
dropdown box above all of the packages).
> Thank you for bundling AsciiO. I noticed a few things:
>
> There is no output window. Normally debug output is displayed on the terminal
> that started AsciiO. The output helps a lot during development.
I switched 'perl.exe' with 'wperl.exe' in your batch file.
'wperl.exe' suppresses the text window that pops up with Perl in
Windows. Switch it back in your batch file if you want. Were you to
create Windows shortcuts for end-users, you would probably want create
a shortcut to the 'wperl.exe' binary and specify the asciio script as
it's argument, and that way the end user is not bothered by the (most
likely) unused text window.
> If I put the bat file on my desktop, the application doesn't start. a black
> window flashes an that's all.
Probably a path missing somewhere in your batch file. Absolute paths
are good things to have if you move the batch file out of your %PATH%.
> Anything special needed to help you maintain AsciiO on Camelbox? How do the
> end users update AsciiO when I make a new release (new release comming soon)?
I can't think of anything at the moment that would help with
maintaining this. How about less dependencies? ;)
An upgrade would basically involve downloading the source and then
running 'dmake; dmake install'.
Is there any reason why I can't have CPAN do all of the dirty work of
downloading and installing the application? When I do a modules regex
search inside the CPAN shell, App::Asciio does not show up.
> Would it be possible to know what went wrong with PAR?
PAR::Packer did not capture all of the dependencies correctly, so when
I run the executable file, I get errors in the console window. I
didn't spend that much time on it, creating a separate package that
ran on top of Camelbox was the quicker way to satisfy your (multiple)
requests.
> Finally, I wonder if there is redundancy between Strawberry and Camelbox?
Yes, there is redundancy, but I'm not inclined to change anything
right this second. However, I do want to see if I can adapt my
installer to drop my Gtk2-Perl packages on top of a Strawberry Perl
install.
Thanks,
Brian
spicy jack
> > > Anything special needed to help you maintain AsciiO on Camelbox?
>
> > maintaining this. How about less dependencies? ;)
> school. Shouldn't we all be? Nothing make me laugh more than module
> boasting "uses no non-core modules". well _that_ module would be one non-core
> module!!!
Maybe come up with a Bundle:: module that contains all of your
dependencies, so I don't have to keep hitting <Enter> in order to get
the CPAN shell to install the next set of dependent modules.
In any case, the modules I list here:
http://code.google.com/p/camelbox/wiki/BuildExternalApps
require a 'force install' in the CPAN shell under Windows because
their tests are failing for whatever reason. I didn't spend a lot of
time trying to figure out why said tests were failing however.
> Also the bat file stopped working. the problem is that there is nothing to
> work with just a very brief flashing window. works fine when I run the script
> directely.
Edit the .bat file and put a 'pause' command after every call to
perl.exe. Maybe you'll catch the error message that way.
> > > Would it be possible to know what went wrong with PAR?
> > PAR::Packer did not capture all of the dependencies correctly, so when
> > I run the executable file, I get errors in the console window.
> This happends quite often. The trick is to add the dependencies by hand. With
> AsciiO running in windows, I will try to find all those dependencies and
> generating an exe. What was the PAR command you used?
This is as far as I got:
C:\camelbox\bin>pp --gui --icon C:/camelbox/bin/wperl.exe -l libCairoPerl.dll -l
libgthread-2.0-0.dll -o C:\temp\asciio.exe -l C:\camelbox\site\lib\auto\Cairo\C
airo.dll -l C:\camelbox\site\lib\auto\Glib\Glib.dll -l C:\camelbox\site\lib\auto
\Gtk2\Gtk2.dll -M Win32::Console -M Tie::Hash::NamedCapture -M Gtk2 asciio
Thanks,
Brian
spicy jack
<adamkenn...@gmail.com> wrote:
> Strawberry has some existing functionality for installing binary
> packages, via both PPM and PAR packages.
>
> ppi also has support for hosting scripted installs at URIs via the p5i
> file format.
>
> But part of the mandate for Vanilla/Strawberry is to avoid inventing
> anything new and just take advantage of existing methodologies.
>
> The ideal case is that we could get GTK packaged as PAR packages of
> something similar.
>
> We're also temporarily (until we find a better way) using a "Vanilla
> PAR" style package, which has additional support for installing into the
> c directories, but that is only available at distro build time, not
> post-install.
>
> Given that camelbox has done the work to build the binary package, one
> option might be to add support for camelbox packages to Perl::Dist...
>
> I don't really understand much about how camelbox works, I've looked in
> the repository but I don't really see much of anything in the way of
> code/etc, so I'm not sure at this point how exactly it works. Until I
> work that out, there's not much more I can add.
Take a look at it from the other direction, i.e. if you're going to
use a Windows installer of some kind to do all of the work, which
installers for Windows provide what functionality? That's sort of the
way I approached packages for Camelbox. If I wanted to install
everything via the NSIS (Nullsoft) installer, I'm limited to whatever
archive formats are supported in the installer.
The other thing I'm always looking at is archive file size, I want to
get the smallest sizes possible, so people on dialup or slow links are
not left out.
Fortunately, the NSIS installer (http://nsis.sf.net) has a lot of
plugins, and I found one that does tar + [LZMA|bzip|gzip], so I get my
choice of compression. Also, I just realized the other day that you
can use the same installer to add more packages if you did not perform
a Full Install in the first place; you just run the installer and
select packages you want (or a Full Install even), and it will
download/re-download and unpack the archive files that you requested.
Unfortunately, since the packages are basically tarballs, I have to
either package metadata inside the package archive as a file, or
figure out some other way of doing it. I do like how Debian/Ubuntu
does it (package files are separate from metadata files, see
/var/lib/dpkg/info on a Debian/Ubuntu system to understand what I'm
talking about), but I don't know the magick behind it.
So to get around to answering your question, Camelbox packages are
simply tarballs compressed with LZMA, and the NSIS installer takes
care of downloading and unarchiving the files contained in the
.tar.lzma'ed packages. The NSIS installer for Windows is pretty
flexible, if you haven't taken a look at what it can do, you can check
out my installer files to see how I'm using it:
http://code.google.com/p/camelbox/source/browse/trunk/installer/
Specifically, camelbox_builder.nsi, camelbox_packages.nsh and
camelbox_functions.nsh in that directory.
The filelists that I feed to tar for creating the package archives are
located here:
http://code.google.com/p/camelbox/source/browse/trunk/build/filelists
Any of the files without numbers in front can be used with the -T
switch to tar to build a package archive of the same name as the
filelist file.
My next big task is to automate generating the 'camelbox_packages.nsh'
file, once I do that, it would be trivial to generate the Gtk2-Perl
add-on installer for Strawberry Perl.
As far as manipulating the .tar.lzma packages, once Camelbox is
installed, UnxUtils provides a copy of GNU tar, and I've included a
copy of lzma.exe from the 7-Zip SDK, so the basics are there for
writing package manipulation tools in Perl (which would call the
external binaries as needed), or even in POSIX sh sematics, as there's
a copy of sh.exe included with UnxUtils.
By the way list moderators, if this thread is getting too far off of
gtk-perl (it's certainly getting long), please let us know so we can
move this thread to a more appropriate list.
Thanks,
Brian
spicy jack
> Hi, I recommended to peopl who wanted to use AsciiO to install CamelBox. A few
> came back to me complaining they couldn't install because their companies use
> proxies, thus blocking downloads.
>
> Could you add the possibility to configure a proxy or is there another easy
> way to do the install?
From the NSIS docs for the NSISdl plugin:
NSISdl supports only basic configurations of proxies. It doesn't support
proxies which require authentication, automatic configuration script, etc.
NSISdl reads the proxy configuration from Internet Explorer's registry key
under HKLM\Software\Microsoft\Windows\CurrentVersion\Internet
Settings. It reads and parses ProxyEnable and ProxyServer.
I was using a different download plugin that had "better support for
proxies", but I stopped using it because I had a lot of problems
downloading from machines on the same physical network (from my own
private mirror).
That being said, there's nothing to say that you can't create your own
local archive of files; there's a dialog page in the installer where
you can choose which server to download the packaged files from; were
you to have a local archive, you could just point that dialog at it
and things should Just Work. I'm working on scripting this so that I
can upload a list of files that you can feed to something like curl or
wget, and create your own local mirrors for a specific release that
way.
> It would be really cool if you and Adam could agree on a way of working so
> people wouldn't have to install two installations of perl. Both of you seemed
> happy with yourselves and not really wanting to do anything to change the
> status quo. It is understandable but I believe both distribution suffer from
> that. I though I'd wait a bit to see if anyone makes a move before I start
> haunting you again ;)
I'm in the middle of writing some backend stuff that will make this
easier to do. Building Camelbox (and by extension, any addons I would
make for Strawberry) manually the way it is right now takes a lot of
time. There's definitely a lot of room for improvement.
> If both of you are going to YAPC::EU, maybe a face to face discussion could
> help. There is room at the post YAPC hackathon too. I'm quite sure that you
> could get help from the community.
As I live in San Diego (California), I would have a better chance of
making the NA version than the EU version, but I'm not planning to
attend any conferences this year. Maybe next year...
Thanks,
Brian