0launch 0.47

0launch 0.47 is now released:

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

NEW FEATURES

- Added PortsDistribution (for FreeBSD) (Anders F Bjorklund).

- Added support for Apple disk image (.dmg) archives (Anders F Bjorklund).

- Support svg feed icons #2983195 (Aleksey Lim).

CHANGES

- Highlight the selected version in bold in the GUI, rather than
moving it to the top of the list. This avoids the versions jumping
around in a confusing way as you change the settings. Closes #2982862
(reported by Aleksey Lim).

- Allow passing command line arguments the unittest.main. This allows
you to say which test cases you want to run. Closes #2982815 (Aleksey
Lim). You can also say, for example, "./testdistro.py --help" to see
what options are available.

BUG FIXES

- Selections.download_missing now ignores package implementations.
There's no way to put a distribution package back to a given version,
so just ignore them instead of giving an error. The error was: File
"../zeroinstall/zerostore/__init__.py", line 246, in lookup_any:

Re: Install native packages

On Fri, Apr 30, 2010 at 07:57:31PM +0100, Thomas Leonard wrote:
> On 31 March 2010 08:54, Aleksey Lim <alsroot <at> member.fsf.org> wrote:
> > On Sun, Mar 28, 2010 at 11:19:24AM +0100, Thomas Leonard wrote:
> [...]
> >> Now we need:
> >>
> >> - Support for getting available versions from PackageKit on
> >> distributions that use it. Currently, only apt-get is implemented, so
> >> it only works on Debian-type systems. The Sugar branch would be a good
> >> start here.
> >>
> >> - Support for installing new versions using PackageKit (probably also
> >> based on the work in the Sugar branch).
> >
> > I'm planing to rebase sugar branch soon
> 
> Did you get a chance to do the rebase yet? I'm hoping to get some
> PackageKit support added this weekend, but I don't want to duplicate
> any work if you've already done it...

Sorry, I'm distracted with other stuff right now.

I attached PK patch but it is what I was thinking about i.e. using
distro.py for checking only already installed packages and use PK to
search new packages during downloading phase (in fallback cases)
and install them. I also didn't test newly rebased code.

I'm still not sure that asking native packaging tools before resolving
to search for not installed packages is good practice even if it works
fine right now (in some cases? in some distros?) since such tools are

Windows implementation

I wanted to go give you all a quick overview of the current state of the
Windows implementation:

The code for parsing Feed XML files (Model) is feature complete. Currently
adding more Unit tests.
The code for generating manifest files and managing implementation caches
(Store) is in active development.
The interface code for running the Python solver script and parsing the
returned XML data (Solver) is working, but needs improvement.

Regarding the Python solver interface:

I run "python 0launch --console --get-selections --select-only URI" and
redirect stdout and stderr. If something went wrong, I am able to determine
that by looking at stderr once the process terminates. If everything went as
planned, I can parse stdout as XML.

However, if 0launch does something interactive (such as displaying a GPG
fingerprint and asking the user to confirm) things get messy. For some
reason, if both stdout and stderr are redirected, these interactive messages
are no longer printed to stderr as the usually would be. Instead, they are
simply missing. I get the same behavior when running 0launch from the
command line and redirecting both output streams there.

Maybe the best solution would be to create a modified / stripped down
version of the Python script specifically for use as a Solver backend. It
would:
- provide the same output as "0launch  --get-selections" does on stdout,
- use no ncurses-like writing to the terminal,
- contain only code for downloading and validating feeds, omitting all the

Re: Build tools on repo

On 25 April 2010 16:32, Thomas Leonard <talex5 <at> gmail.com> wrote:
[...]
> 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).

I've now released 0compile 0.19.1, which depends on 0launch >= 0.47,
to fix this issue.

You can use

  <implementation ... compile:min-version="0.19.1">

to make sure your program is compiled with a new enough version, if
you want to depend on pkg-config.

--

-- 
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

------------------------------------------------------------------------------

Re: Windows implementation

On 1 May 2010 13:11, Bastian Eicher <bastian <at> eicher.net> wrote:
> I wanted to go give you all a quick overview of the current state of the
> Windows implementation:
[...]
> Maybe the best solution would be to create a modified / stripped down
> version of the Python script specifically for use as a Solver backend.

Yes, and you should find it easy to do (just copy cli.py and delete
things until it does what you want, really). You'll probably want to
create your own subclass of Handler that does more sensible things. By
default, cli.py uses the ConsoleHandler subclass if stdout is an
interactive terminal. Have a look in handler.py.

> One last question regarding "--get-selections": What does the XML contain
> for selected package implementations instead of normal implementations?

e.g.

<selection id="package:deb:rox-filer:2.5-1" interface="..."
main="/usr/bin/rox" package="rox-filer" stability="testing"
version="2.5-1"/>

--

-- 
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

------------------------------------------------------------------------------

Re: New Feeds for Linux

On 25 April 2010 15:51, Anders F Björklund <afb <at> users.sourceforge.net> wrote:
> Thomas Leonard wrote:
[...]
>> 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...)

Good point. If pkg2zero can't sort out the relationships (which it
will only do for .so files) then it might be a lot of work to make
separate packages.

> It's probably the *right* thing to do, but it's more work than
> just extracting and wrapping the current "everything" tarball ?

That's probably the best option, then.

> 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.

Can we script it?

Re: New Feeds for Linux

Thomas Leonard wrote:

>> 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...)
>
> Good point. If pkg2zero can't sort out the relationships (which it
> will only do for .so files) then it might be a lot of work to make
> separate packages.
>
>> It's probably the *right* thing to do, but it's more work than
>> just extracting and wrapping the current "everything" tarball ?
>
> That's probably the best option, then.

Yup, or make the regular tools understand the packaging.
(e.g. so that the tarball-with-rpms can be extracted ?)

I'm sure it is used elsewhere, although I can think of
anything other than the infamous Sun Java JRE/JDK RPMS...

>> 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.
>
> Can we script it?

I think scripting is the only possible way, but made it en_US
only to start with. It said language wasn't being used anyway ?

Re: New Feeds for Linux

On 3 May 2010 19:24, Anders F Björklund <afb <at> users.sourceforge.net> wrote:
> Thomas Leonard wrote:
>
>>> 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...)
>>
>> Good point. If pkg2zero can't sort out the relationships (which it
>> will only do for .so files) then it might be a lot of work to make
>> separate packages.
>>
>>> It's probably the *right* thing to do, but it's more work than
>>> just extracting and wrapping the current "everything" tarball ?
>>
>> That's probably the best option, then.
>
> Yup, or make the regular tools understand the packaging.
> (e.g. so that the tarball-with-rpms can be extracted ?)
>
> I'm sure it is used elsewhere, although I can think of
> anything other than the infamous Sun Java JRE/JDK RPMS...

Maybe it was just a Sun thing then?

>>> 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.
>>
>> Can we script it?
>

Re: New Feeds for Linux

Thomas Leonard wrote:

>> I'm sure it is used elsewhere, although I can think of
>> anything other than the infamous Sun Java JRE/JDK RPMS...
>
> Maybe it was just a Sun thing then?

I think they were called "superdebs" or "yumpacks" elsewhere.

Most people just use apt or yum and a repository, though...

>> I think scripting is the only possible way, but made it en_US
>> only to start with. It said language wasn't being used anyway ?
>> Or would Zero Install know which feed implementation to choose,
>> based on the current locale ? Thought that feature was missing.
>
> It is, but if someone could just add a couple of lines to solver.py's
> compare method it would be fixed, e.g.
>
> 		r = cmp(rate_language(a), rate_language(b))
> 		if r: return r
>
> where rate_language(x) somehow generates a score based on x.langs and
> the desired language. e.g. something like:
>
> def rate_language(impl):
>   return int(self.lang in impl.langs.split(' '))

You could start with just a compare ? Some of the preferences
are a bit tricky, for example pt_BR and pt_PT and some others

Re: New Feeds for Linux

Thomas Leonard wrote:

> I don't know enough about what non-English speakers want to know
> exactly what's needed (though I have been running with
> "LANG=es_ES.utf8" for a couple of weeks, which has turned up a number
> of encoding bugs in various error paths).

I made an example feed for Firefox, by including the
Swedish and Spanish translations and implementations.

It doesn't really "work", in that each language looks
identical in the list and in that the last provided
translation appears in the Zero Install interface
(and all of them in the HTML rendering of the XML)

But something like the provided would be "needed"...
BTW: I had to use the GUI to sign it, the CLI failed.

--anders

------------------------------------------------------------------------------

_______________________________________________
Zero-install-devel mailing list
Zero-install-devel <at> lists.sourceforge.net