Zero Install

On 24 April 2010 11:00, Thomas Leonard <talex5@...> wrote:
> I've added a 'devel' section on http://repo.roscidus.com/
>
> Currently it just contains pkg-config (as people occasionally submit
> bug reports about ROX-Filer failing to build because they don't have
> it). It provides tar.bz2's for Linux x86 and x86_64 (automatically
> converted by apt-repo + pkg2zero from Debian/stable), and
> <package-implementation>s for various distributions, copied from
> Aleksey's Sugar package. I was wondering whether to <import> the Sugar
> feed instead, but in the end I thought it was simpler to just copy the
> lines.
>
> If we add gcc and make too then we should have a decent base build system.

Make is there too now:

  http://repo.roscidus.com/devel/make

I've updated the GNU-Hello example to use it:

  http://0install.net/0compile.html

However, it turned out that 0compile didn't handle
package-implementation dependencies.

For now, I've left the <package-implementation> commented out, so
0compile always uses the Zero Install "make" even if your distribution
already has it. I've fixed 0compile and 0launch in Git to work better:
they now ignore package implementations in selections (i.e. don't try
to download them or set environment variables for them).

We probably need an option to ignore <package-implementation> tags
anyway, because using them makes builds less reproducible. Normally,
you can ask 0compile to recompile in the same environment used to
compile the program originally, but this isn't possible with
distribution-provided dependencies.

I've left pkg-config as it was, because the only thing using it so far
is the Git version of ROX-Filer, and probably I'll have made a new
release of 0compile before that gets released, but I didn't want to
break the GNU-Hello example.


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Thomas Leonard wrote:

>> I've added a 'devel' section on http://repo.roscidus.com/
>>
>> Currently it just contains pkg-config [...]
>> If we add gcc and make too then we should have a decent base build  
>> system.
>
> Make is there too now:
>
>   http://repo.roscidus.com/devel/make

Q:
Shouldn't these feeds also have a source implementation ?

I know that sometimes the installation is a bit tricky,
but at least provide a link to the source code tarball ?

http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.gz
http://ftp.debian.org/debian/pool/main/m/make-dfsg/make- 
dfsg_3.81.orig.tar.gz

Or maybe that would rather be to the debian dsc files...

http://ftp.debian.org/debian/pool/main/m/make-dfsg/make-dfsg_3.81-5.dsc
http://ftp.debian.org/debian/pool/main/m/make-dfsg/make- 
dfsg_3.81-5.diff.gz


Wondering if it wouldn't be better to bootstrap the
base build system from source, rather than use debian ?

Or perhaps *use* debian as the build system, and just
install the pkg-config, make and gcc packages* in it...

* plus m4, autoconf, libtool, automake, gettext perhaps ?
(as those are the ones most often needed to "autogen")

--anders

On 25 April 2010 17:10, Anders F Björklund <afb@...> wrote:
> Thomas Leonard wrote:
>
>>> I've added a 'devel' section on http://repo.roscidus.com/
>>>
>>> Currently it just contains pkg-config [...]
>>> If we add gcc and make too then we should have a decent base build
>>> system.
>>
>> Make is there too now:
>>
>>   http://repo.roscidus.com/devel/make
>
> Q:
> Shouldn't these feeds also have a source implementation ?

Ideally, yes, although of course you couldn't use the source to
generate the actual binary, since that comes from Debian.

> I know that sometimes the installation is a bit tricky,
> but at least provide a link to the source code tarball ?

Good idea. I've added a Homepage link to both of them.

> Wondering if it wouldn't be better to bootstrap the
> base build system from source, rather than use debian ?

The nice thing about using Debian here is that we can update to a
recent version of everything by running a single script (which does an
'apt-get update' to find out about new versions). Also, we can get
binaries for many architectures easily, even though it's currently
only set to build x86 and x86_64.


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Thomas Leonard wrote:

>> Q:
>> Shouldn't these feeds also have a source implementation ?
>
> Ideally, yes, although of course you couldn't use the source to
> generate the actual binary, since that comes from Debian.

A link to the .dsc then perhaps ? Or convert it to something
that can be archived next to the binary implementations...

e.g. do a `dpkg-source -x foo.dsc` (apt-get source foo) and
tar the result up, like it does with dpkg on the deb package:

make-src-3.81-5.tar.bz2
(cd make-dfsg-3.81 && dpkg-buildpackage -b -uc)

Maybe it wouldn't work with 0launch directly (i.e. "Compile")
but it would at least provide a way to get at the source code ?

>> I know that sometimes the installation is a bit tricky,
>> but at least provide a link to the source code tarball ?
>
> Good idea. I've added a Homepage link to both of them.

Maybe more markup would be needed, for repackaged feeds ?
("based on a package from debian" or "converted from" etc)

Also wondered a bit about the release date vs. package...
i.e. thought it would be 2008-06-03 rather than 2010-04-25

>> Wondering if it wouldn't be better to bootstrap the
>> base build system from source, rather than use debian ?
>
> The nice thing about using Debian here is that we can update to a
> recent version of everything by running a single script (which does an
> 'apt-get update' to find out about new versions). Also, we can get
> binaries for many architectures easily, even though it's currently
> only set to build x86 and x86_64.

Yeah, I hadn't looked at "apt-repo" but thought the feed
would be self-contained (in terms of source for binary).

But I would probably have used either/or (of deb or tbz),
rather than mixing and matching with the conversion...

--anders

Anders F Björklund wrote:
> Thomas Leonard wrote:
> 
>> That's excellent! Tested on Ubuntu 9.10 and it worked fine (although
>> it does ask if you want it to check for updates automatically, which
>> is a bit confusing since Zero Install would do that anyway).
> 
> I'm not sure if you can turn that feature off through configuration,
> or if you would need to recompile in order to disable the updates ?
> Though other than confusing Zero Install it shouldn't hurt, either.
> 
> If it can be disabled, then one could add a small "patch" file on
> top of the regular distribution in order to disable, perhaps...
> Or just avoid using the "Check for Updates" menu item meanwhile. :-)
> 
...
> 
> --anders
> 
...

Hi Anders

Debian and Ubuntu disables the self upgrade feature (greyed out in
preferences), so it surely can be done.
I think the --disable-updater option to 'configure' is the way to do
that, but I haven't found exact documentation.
Relevant pointers may include:
https://developer.mozilla.org/en/Configuring_Build_Options
https://wiki.mozilla.org/Linux/Compiler_Options

The latter indicates that --disable-updater is used in debs but not in rpms.

Cheers, Jonas

Jonas Bardino wrote:

>> I'm not sure if you can turn that feature off through configuration,
>> or if you would need to recompile in order to disable the updates ?
>> Though other than confusing Zero Install it shouldn't hurt, either.
>
> Debian and Ubuntu disables the self upgrade feature (greyed out in
> preferences), so it surely can be done.
> I think the --disable-updater option to 'configure' is the way to do
> that, but I haven't found exact documentation.

Well, the question was whether one could disable it *without*
recompiling since the feed is using the official binaries...

> Relevant pointers may include:
> https://developer.mozilla.org/en/Configuring_Build_Options
> https://wiki.mozilla.org/Linux/Compiler_Options
>
> The latter indicates that --disable-updater is used in debs but not  
> in rpms.

Thanks for the rpm pointer, it seems the configuration is:
pref("app.update.auto", false);
pref("app.update.enabled", false);
pref("app.update.autoInstallEnabled", false);

Presumably something similar can be done for OpenOffice.org,
eventually by _deleting_ the onlineupdate addon or something.
(Office/Addons/Addons-onlineupdate.xcu in the OOo "registry")
Possibly also the same in */Jobs/, for the automatic check ?

Something like that, those patches should be doable as recipes ?
Maybe not the delete, but that can be done in the shell wrapper.

--anders

On 21 April 2010 21:29, Anders F Björklund <afb@...> wrote:
[...]
> Another slight hack/workaround is that OOo extracts the RPMS to the
> cache directory, so the manifest doesn't verify and the size of the
> cache is reported wrong (i.e. it says 2012 bytes, rather than 465M!)

Hmm. Not so good, then. It certainly shouldn't be unpacking to the
implementation cache (the fact you had to do "chmod +w ." is a clue
;-) and won't work at all on a shared setup.

Can we just unpack it once and have the user download the RPMs
individually? Do the official OpenOffice RPMs contain any non-Free
stuff (e.g. the non-icedtea version of Java)? If not, the RPMs could
go on repo.roscidus.com. Otherwise, perhaps oo.org allow you to
download them individually?

> PS. Yet another thing that might be useful eventually would be a way
> to link to next major version, while still providing minor versions.
> You wouldn't want it to jump from say 1.0 to 2.0 but rather to 1.1,
> but maybe it could provide a "hint" that a new feed is available ?
> Currently I've done them separately, like seamonkey and seamonkey2
> or firefox and firefox3, but there is no good place for that link.

Interesting idea. I've thought we need a way to mark a feed as
deprecated for a while, but maybe we need something more general?


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Thomas Leonard wrote:

> On 21 April 2010 21:29, Anders F Björklund  
> <afb@...> wrote:
> [...]
>> Another slight hack/workaround is that OOo extracts the RPMS to the
>> cache directory, so the manifest doesn't verify and the size of the
>> cache is reported wrong (i.e. it says 2012 bytes, rather than 465M!)
>
> Hmm. Not so good, then. It certainly shouldn't be unpacking to the
> implementation cache (the fact you had to do "chmod +w ." is a clue
> ;-) and won't work at all on a shared setup.

Yeah, maybe I should have stated more clearly that it was a
gross hack / experiment rather than something ready-to-go. :-)

It should probably use another (temporary) location, since
the extraction doesn't take that long (just I/O basically) ?

> Can we just unpack it once and have the user download the RPMs
> individually? Do the official OpenOffice RPMs contain any non-Free
> stuff (e.g. the non-icedtea version of Java)? If not, the RPMs could
> go on repo.roscidus.com. Otherwise, perhaps oo.org allow you to
> download them individually?


Well, I tried to use the "without JRE" tarballs but it seems
that for x86_64 those are broken (both tarballs are identical)

The OOo feed could most certainly use the download directly,
just that I didn't know how to write a custom archive phase ?

--anders

On 23 April 2010 11:01, Anders F Björklund <afb@...> wrote:
>  Thomas Leonard wrote:
>
>> On 21 April 2010 21:29, Anders F Björklund
>> <afb@...> wrote:
>> [...]
>>> Another slight hack/workaround is that OOo extracts the RPMS to the
>>> cache directory, so the manifest doesn't verify and the size of the
>>> cache is reported wrong (i.e. it says 2012 bytes, rather than 465M!)
[...]
>> Can we just unpack it once and have the user download the RPMs
>> individually? Do the official OpenOffice RPMs contain any non-Free
>> stuff (e.g. the non-icedtea version of Java)? If not, the RPMs could
>> go on repo.roscidus.com. Otherwise, perhaps oo.org allow you to
>> download them individually?

> The OOo feed could most certainly use the download directly,
> just that I didn't know how to write a custom archive phase ?

Currently, you can't. There's no particular reason why we can't
extract archives recursively, but I'm not sure it's very useful.

For example, if you use Zero Install to run OpenOffice Base (the
database), it should only download the RPMs needed to run that (e.g.
"base" and "core"). If you then run Writer, it should download the
"writer" RPM but use the cached copy of "core".

Perhaps we could host the extracted RPMs on sf.net? (Even under
0install.net if you want. I've added you to the project members list
in any case.)


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Thomas Leonard wrote:

>> The OOo feed could most certainly use the download directly,
>> just that I didn't know how to write a custom archive phase ?
>
> Currently, you can't. There's no particular reason why we can't
> extract archives recursively, but I'm not sure it's very useful.

It even uses gzip on gzip, which is something of a waste of
resources (especially since it doesn't compress very well)
i.e. if you use a .tar.xz, instead of rpm or dep + tar.gz,
the resulting download is 127M rather than the current 147M)

The main "advantage" of doing one archive is that you can
bundle an installer application with it, so that people
used to setup.exe won't feel lost or have to learn to use
a package manager. Similarly, have the installer/application
update itself (with another bundled application) instead of
just using the package managers update feature to do that.
I'm sure that these package archives come from the equivalent
of 0export - but using rpm or dpkg instead of Zero Install...
(PBI is a similar project for BSD Ports, see http://pbidir.com)
All so that application installation can be as "good" as it
is on Windows, and so it all can continue to be done manually.

Then again, running the installer/update application can't
possibly be worse than having to use the terminal to do it:
http://download.openoffice.org/common/instructions.html#linux
http://support.mozilla.com/en-US/kb/Installing+Firefox+on+Linux

> For example, if you use Zero Install to run OpenOffice Base (the
> database), it should only download the RPMs needed to run that (e.g.
> "base" and "core"). If you then run Writer, it should download the
> "writer" RPM but use the cached copy of "core".
>
> Perhaps we could host the extracted RPMs on sf.net? (Even under
> 0install.net if you want. I've added you to the project members list
> in any case.)

Perhaps, but if I wanted that - I *could* have just installed
the RPMs or DEBs from the current distro instead of using the
vendor packages, that they don't bother making any repo for ?
i.e. use yum or apt and an install, rather than rpm or dpkg.

Otherwise I would have to sort out all the dependencies and
set up PATHs for linking and runtime and all the other stuff
that the "soffice" launcher script is expecting to be there.
(there are 59 packages that make up the OOo installation...)


It's probably the *right* thing to do, but it's more work than
just extracting and wrapping the current "everything" tarball ?
And of course one needs to do this one time _for each language_,
there's 33 locales for OpenOffice.org and like 65 for Mozilla*.

But I'll try to fix my feeds to not abuse the cache directory,
maybe it can extract to something like /var/tmp/$USER instead ?
The RPMS are still the "source", having to extract (or install)
the packages before running them is more like a "side effect".

--anders


* http://download.openoffice.org/other.html
   http://www.mozilla.com/en-US/firefox/all.html

> I should probably do a Distribution implementation
> for it, so that either "distribution" would work ?

Here goes...
There's also the previous code for Slackware packages.

--anders

On 24 April 2010 14:07, Anders F Björklund <afb@...> wrote:
>> I should probably do a Distribution implementation
>> for it, so that either "distribution" would work ?
>
> Here goes...
> There's also the previous code for Slackware packages.

Applied - thanks!


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

Thomas Leonard wrote:

>> I switched from old os.system to subprocess.check_call, and also
>> added some code to use "dmg2img" so that it'd work on Linux too...
>> i.e. using http://packages.ubuntu.com/search?keywords=dmg2img
>> Please try this out, and consider for adding to 0launch 0.46 ?
>
> OK, I applied the MacOS X bit (using "hdiutil"). I didn't apply the
> Linux support, since it would only work as root (I assume). Instead, I
> changed it to skip the unittest if hdiutil isn't present.

The dmg2img conversion works as the user, but the actual mount
does require root permission. Just that it enables one to add
Mac archives without needing Mac OS X which might be a feature ?

Perhaps FUSE could be used ? If *that* is installed, <sigh>.

> I also rebased and squashed the patches a bit, to give you more
> practice with Git ;-)

It seems to hate me, even though I have nothing against it. :-)
I decided to just throw the old changes out, and start over...
Seems to happen a lot with git, which is a bit against a VCS ?

So I still prefer bzr, even if it doesn't do rebasing/cherrypicks.

--anders

On 22/04/2010 07:22 a.m., Anders F Björklund wrote:
> It seems like version 2.12 of gtk is *not*
> enough, but that you need a later version:
> 
[...]
> With those changes, 0.46 runs in Debian stable.
> The deb doesn't work however, too new format...

I made those changes but I thought the unrecognized tags were ignored.
There is a branch for GTK compatibility in my repo [*] that uses Glade
instead of GTKBuilder so it should work with even older distros (maybe
RedHat), it's 0.42.1 but I will merge master if it's useful to you (or
someone else).

[*]
http://repo.or.cz/w/zeroinstall/zeroinstall-rsl.git/shortlog/refs/heads/glade

On Thu, Apr 22, 2010 at 7:22 AM, Anders F Björklund
<afb@...> wrote:
> It seems like version 2.12 of gtk is *not*
> enough, but that you need a later version:
[...]
> With those changes, 0.46 runs in Debian stable.
> The deb doesn't work however, too new format...

The suggested changes are attached, please test them.

Rene Lopez wrote:

>> It seems like version 2.12 of gtk is *not*
>> enough, but that you need a later version:
>>
> [...]
>> With those changes, 0.46 runs in Debian stable.
>> The deb doesn't work however, too new format...
>
> I made those changes but I thought the unrecognized tags were ignored.
> There is a branch for GTK compatibility in my repo [*] that uses Glade
> instead of GTKBuilder so it should work with even older distros (maybe
> RedHat), it's 0.42.1 but I will merge master if it's useful to you (or
> someone else).

Yes, those changes seemed like a good idea for translators but maybe
they would also require bumping GTK requirements from 2.12 to 2.16 ?
That would also exclude Debian 5, like GTKBuilder excluded Redhat 5.

I did have the 0.39 before, just thought that I'd update to 0.46.
Which worked OK, just that I hadn't tried the graphic interface...
But it seemed like a "small enough" change to consider reverting ?

--anders

Rene Lopez wrote:

>> With those changes, 0.46 runs in Debian stable.
>> The deb doesn't work however, too new format...
>
> The suggested changes are attached, please test them.<

I made the packages for debian lenny available at:
http://afb.users.sourceforge.net/zero-install/

I included it in my testing Live CD "distribution"*,
the APT configuration sources.list lines would be:
deb http://afb.users.sourceforge.net/zero-install/debian lenny main
deb-src http://afb.users.sourceforge.net/zero-install/debian lenny main

One unexpected side-effect was that some other feeds
stopped working, since "python-glade2" was no longer
being installed (as a requirement of 0launch itself)
and thus missing from the system. Added it separately.

--anders


* http://afb.users.sourceforge.net/debian/
   updated to Debian GNU/Linux 5.0.4 "lenny"

On 23/04/2010 02:02 a.m., Anders F Björklund wrote:
> One unexpected side-effect was that some other feeds
> stopped working, since "python-glade2" was no longer
> being installed (as a requirement of 0launch itself)
> and thus missing from the system. Added it separately.

Like 0publish-gui? I didn't noticed it as I have python-glade2 installed.

Rene Lopez wrote:

>> One unexpected side-effect was that some other feeds
>> stopped working, since "python-glade2" was no longer
>> being installed (as a requirement of 0launch itself)
>> and thus missing from the system. Added it separately.
>
> Like 0publish-gui? I didn't noticed it as I have python-glade2  
> installed.

Yes, I think that was it. Didn't have too many default feeds:

0alias 0compile http://0install.net/2006/interfaces/0compile.xml
0alias 0publish http://0install.net/2006/interfaces/0publish
echo Y | 0launch -d -c http://rox.sourceforge.net/2005/interfaces/ROX- 
Lib
0alias 0publish-gui http://0install.net/2007/interfaces/0publish-gui.xml

Those three were set up in /usr/local/bin, while the rest of
zeroinstall-injector went in /usr/bin (as usual with debs).

--anders