Thomas Leonard | 6 Sep 13:41 2009
Picon

0launch 0.42

A new release of Zero Install (0.42) is now available:

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

(source only at the moment; a Debian package has been uploaded to
unstable and the RPMs are building)

New features

- Connect to a key-server to look up trust hints. By default, this is
  a service hosted on Google AppEngine, at http://keylookup.appspot.com/
  Before, we used a built-in database, which couldn't be updated easily.
  The new system also allows us to use a much larger source of information;
  in particular the server can tell you if a package is signed by a
  member of the Debian project. Hopefully, this can be expanded in future
  to include packagers from Fedora, Ubuntu, etc.

- Allow multiple versions of each distribution package (Anders F
  Bjorklund). On RPM-based systems, 32-bit and 64-bit versions of a
  package may have the same package name, so store a list of (version,
  arch) pairs for each name.

Changes

- Always run the built-in copy of the GUI. Originally, the GUI was a
  separate program that 0launch downloaded when needed. Later, a copy of
  the GUI was bundled to improve the experience for first-time use, but
  updates were downloaded. In recent years, the only purpose of this has
  been to add new GPG keys to the hints database. Having the GUI as a
  separate program added unnecessary complexity, made it harder to
(Continue reading)

Rene Lopez | 11 Sep 03:41 2009
Picon

Re: 0launch 0.42

On Sun, Sep 6, 2009 at 6:41 AM, Thomas Leonard <talex5 <at> gmail.com> wrote:
> (source only at the moment; a Debian package has been uploaded to
> unstable and the RPMs are building)

deb states that it still requires python-glade2

> - Replaced Glade with GtkBuilder (Rene Lopez). Fixed UI resources
>  stating that some top level widgets were visible. Fixed the error
>  when selecting a preferred stability it will be switched to the one
>  above the selected one. This means that we now depend on GTK >= 2.12,
>  but that libglade is no longer needed.

I found serveral bugs introduced by this:

The ui files are in reality dependant to 2.16 (not to 2.12) because
they use the attribute property of labels. I don't know exacly how
this may fail but I think the only problem will be that labels with
bold letters and/or italics will be showed as normal text.

There are also warnings about using the deprecated gtk.tooltips and
they are not really used just instatiated so I removed them and also
removed a variable named COMPILE as I didn't see it used anywhere.
Patch attached

zero-install.ui has an error because cellrenderedtext1 is defined in
two times even if it is in different top level widgets and the
configuration states that objects can have the same name if in
different top level widgets, I'm not sure why this happens but the
attached patch appears to fix it.
(Continue reading)

Thomas Leonard | 11 Sep 10:11 2009
Picon

Re: 0launch 0.42

2009/9/11 Rene Lopez <rsl <at> members.fsf.org>:
> On Sun, Sep 6, 2009 at 6:41 AM, Thomas Leonard <talex5 <at> gmail.com> wrote:
>> (source only at the moment; a Debian package has been uploaded to
>> unstable and the RPMs are building)
>
> deb states that it still requires python-glade2

Oops. Will fix in next release.

>> - Replaced Glade with GtkBuilder (Rene Lopez). Fixed UI resources
>>  stating that some top level widgets were visible. Fixed the error
>>  when selecting a preferred stability it will be switched to the one
>>  above the selected one. This means that we now depend on GTK >= 2.12,
>>  but that libglade is no longer needed.
>
> I found serveral bugs introduced by this:
>
> The ui files are in reality dependant to 2.16 (not to 2.12) because
> they use the attribute property of labels. I don't know exacly how
> this may fail but I think the only problem will be that labels with
> bold letters and/or italics will be showed as normal text.

Sounds OK. I think some people have already tested with 2.12 and it worked?

> There are also warnings about using the deprecated gtk.tooltips and
> they are not really used just instatiated so I removed them and also
> removed a variable named COMPILE as I didn't see it used anywhere.
> Patch attached

Applied (I think I found another unused tooltips too).
(Continue reading)

Rene Lopez | 11 Sep 10:26 2009
Picon

Re: 0launch 0.42

On Fri, Sep 11, 2009 at 3:11 AM, Thomas Leonard <talex5 <at> gmail.com> wrote:
>> zero-install.ui has an error because cellrenderedtext1 is defined in
[...]
>> attached patch appears to fix it.
>
> Applied. How did you find the error?

Well, last time I tested it in my system (Debian unstable) it run ok
but I tried today (just updated to current unstable) to test the new
Floyopuyo feed and it reported that error. It did work if I tried to
run an already available program but failed with the new so it might
be present since I submitted the changes for gtkbuilder or it maybe
that the new gtk breaks z-i, not sure.

Reading my previous post the last part is very messy, even I have
trouble understanding it so here I go again.
In zero-install.ui two different windows (top level widgets) can have
a widget with the same name (as stated in the project preferences in
glade) but for some reason now gtk complains that the gtkbuilder file
defines two widgets, that are in different windows, using the same
name. This may be a bug in the new gtk lib in debian?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Thomas Leonard | 11 Sep 11:09 2009
Picon

Re: 0launch 0.42

2009/9/11 Rene Lopez <rsl <at> members.fsf.org>:
> On Fri, Sep 11, 2009 at 3:11 AM, Thomas Leonard <talex5 <at> gmail.com> wrote:
>>> zero-install.ui has an error because cellrenderedtext1 is defined in
> [...]
>>> attached patch appears to fix it.
>>
>> Applied. How did you find the error?
>
> Well, last time I tested it in my system (Debian unstable) it run ok
> but I tried today (just updated to current unstable) to test the new
> Floyopuyo feed and it reported that error.

OK, that's more serious! I've made a new release with your patch and
uploaded a new version to the Debian archive.

(wow... the new sf.net release system is *so* much better. I'm
averaging about 30 seconds per release now, compared to several hours
before!)

--

-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Anders F Björklund | 15 Sep 12:01 2009
Picon
Picon

Re: 0launch 0.42 (multi-arch)

Thomas Leonard wrote:

> - Allow multiple versions of each distribution package (Anders F
>   Bjorklund). On RPM-based systems, 32-bit and 64-bit versions of a
>   package may have the same package name, so store a list of (version,
>   arch) pairs for each name.

This still fails on Debian-based systems. For instance, the latest
implementation of the SeaMonkey feed only provides 32-bit binaries.
To run it, you need the C++ legacy runtime library (libstdc++.so.5)
Normally, this is provided by native the "libstdc++5" .deb package.

But when running the 32-bit app, you need /usr/lib32/libstdc++.so.5
and not /usr/lib64/libstdc++.so.5 (on a 64-bit installation that is)
This is instead being provided by the "ia32-libs" .deb package, but
it is reported as having a "x86_64" arch and thus as "Incompatible"...

On Redhat-based systems, /usr/lib32/libstdc++.so.5 would be provided
by "compat-libstdc++-33.i386" and /usr/lib64/libstdc++.so.5 would be
provided by "compat-libstdc++-33.x86_64" - same name, two .rpm arch.
(package names are listed as "%{name}-%{version}-%{release}.%{arch}")

But I don't think it can be fixed until dpkg grows some features*,
unless adding a .deb package directly to the feed or something ?
* http://www.debian.org/News/2009/20090730 ("Multi-arch support")
* https://wiki.ubuntu.com/MultiarchSpec (ia32-libs source = 550M!)

And you can't really build the library from source either, since
0compile doesn't support cross-compilation as far as I am aware ?
In this case you _could_ of course rebuild the whole application
(Continue reading)

Thomas Leonard | 26 Sep 18:10 2009
Picon

Re: 0launch 0.42 (multi-arch)

2009/9/15 Anders F Björklund <afb <at> users.sourceforge.net>:
> Thomas Leonard wrote:
>
>> - Allow multiple versions of each distribution package (Anders F
>>   Bjorklund). On RPM-based systems, 32-bit and 64-bit versions of a
>>   package may have the same package name, so store a list of (version,
>>   arch) pairs for each name.
>
> This still fails on Debian-based systems. For instance, the latest
> implementation of the SeaMonkey feed only provides 32-bit binaries.
> To run it, you need the C++ legacy runtime library (libstdc++.so.5)
> Normally, this is provided by native the "libstdc++5" .deb package.
>
> But when running the 32-bit app, you need /usr/lib32/libstdc++.so.5
> and not /usr/lib64/libstdc++.so.5 (on a 64-bit installation that is)
> This is instead being provided by the "ia32-libs" .deb package, but
> it is reported as having a "x86_64" arch and thus as "Incompatible"...

Perhaps we should check for /lib32 before assuming we can run 32-bit
binaries on a 64-bit system? Or prompt the user to install it if we
select a 32-bit binary?

> And you can't really build the library from source either, since
> 0compile doesn't support cross-compilation as far as I am aware ?

Not at the moment. The main issue is we'd need to separate the
dependencies somehow; if the source depends on "make" and
"libgtk-dev", then I want to select a version of make for the host,
and a version of libgtk-dev for the target.

(Continue reading)

Anders F Björklund | 26 Sep 18:27 2009
Picon
Picon

Re: 0launch 0.42 (multi-arch)

Thomas Leonard wrote:

>> But when running the 32-bit app, you need /usr/lib32/libstdc++.so.5
>> and not /usr/lib64/libstdc++.so.5 (on a 64-bit installation that is)
>> This is instead being provided by the "ia32-libs" .deb package, but
>> it is reported as having a "x86_64" arch and thus as  
>> "Incompatible"...
>
> Perhaps we should check for /lib32 before assuming we can run 32-bit
> binaries on a 64-bit system? Or prompt the user to install it if we
> select a 32-bit binary?

Sortof, just that that "lib32" doesn't exist on all systems.

On Debian systems, you have:
/usr/lib32
/usr/lib64 -> lib
/usr/lib

On Redhat systems, you have:
/usr/lib
/usr/lib32 -> lib
/usr/lib64

And on other systems, like Darwin, *both* architectures are
present in /usr/lib so there are no lib32 or lib64 at all...

/usr/lib/libstdc++.6.dylib: symbolic link to `libstdc++.6.0.4.dylib'

/usr/lib/libstdc++.6.0.4.dylib: Mach-O universal binary with 4  
(Continue reading)


Gmane