zero-install-devel — Discussion about the Zero Install system (bugs, patches, suggestions)

[Zero-install-devel] Problems with environment variables in several programs

[Thomas L. <ta...@gm...>]

Some shells have begun silently removing environment variables they
don't like. In particular, they seem to dislike names starting with
"0" or containing hyphens. e.g.

$ python
Python 2.7.16 (default, Apr  6 2019, 01:42:57)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['XXX'] = 'OK'
>>> os.environ['0XXX'] = 'MISSING'
>>> os.system('env | grep XXX')
XXX=OK
0
>>> import subprocess
>>> for line in subprocess.check_output(['env']).split('\n'):
...     if 'XXX' in line: print line
...
XXX=OK
0XXX=MISSING

To fix this, I've made a couple of new releases:

0install 2.3.6 (the old Python branch) fixes this, and also has some
other updates:

- Update for changed GnuPG output format.

- Require Python < 3.7. Python 3.7 turned "async" into a keyword, but
we use it everywhere.

- Bugfix: fetcher.download_impls can return None. Reported by Bastian Eicher.

(luckily, the OCaml version switched to using safe characters back in
2014 for other reasons)

Also, 0compile 1.6 has been released
(http://0install.net/0compile.html) with some similar changes, as well
as a minor change to print a better message when using "0compile
publish" without an argument, which is now the preferred way to do
things.

0release has also been updated on master. The problem was causing the
unit-tests to fail, but it probably doesn't affect normal use.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

[Zero-install-devel] repo.roscidus.com new maintainer

[Thomas L. <ta...@gm...>]

Hi,

Just to let you all know that Bastian Eicher has volunteered to be an
admin for http://repo.roscidus.com. This should help clear the backlog
of PRs there (https://github.com/0install/repo.roscidus.com/pulls)!

Bastian has also provided some new hosting for the archive. It was
previously being hosted on an FSF server via the Sugar project (since
2009 - thanks!), but that creates a bit of overhead as we have to find
a sponsor from Sugar whenever we add a new admin. We also thought
about hosting it on GitHub pages, but we're using some Apache
mod_rewrite trickery to make the feed URIs look nicer and GitHub pages
doesn't support that.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] Zero Install documentation web-site

[Thomas L. <ta...@gm...>]

On Sat, 25 Aug 2018 at 11:10, Bastian Eicher <ba...@ei...> wrote:
>
> Hi all,
>
> I finally got around to working on the idea of a shared documentation
> web-site based on http://0install.net/ and http://0install.de/.
>
> I forked https://github.com/0install/web-site to
> https://github.com/0install/docs and removed all non-documentation content
> (landing page, feeds, etc.). Then I moved and renamed files and directories
> to match the menu structure. Next I replaced the XSLT-based build system
> with the MkDocs (https://www.mkdocs.org/) static site generator.

A quick update on this: the new docs are now available at
https://docs.0install.net/

I'm slowly making my way through it (we have a lot of docs!) but so
far it looks very good!


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

[Zero-install-devel] Note about the 0install Debian package

[Thomas L. <ta...@gm...>]

I got a notice recently saying that my 0install package had been
removed from Debian/testing, and after searching around a bit I found
this:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934872

The Debian OCaml team had removed both the obus and lwt_glib packages
which we use, as well as several of their dependencies. This is to
ease the future transition from OCaml 4.05 to 4.08 apparently
(although both removed packages work fine on 4.08). The maintainer
says "I expect it will take a few months before obus is in testing
again.".

I have now got the 0install package building again, by vendoring the
five missing libraries (camlp4, lwt_camlp4, type_conv, obus and
lwt_glib). It took a bit longer than expected because various hacks
are needed for the MIPS architecture (which I don't much care about,
but it prevents packages from migrating from unstable to testing).

The package will have to be updated again once the OCaml 4.08
transition actually happens, but it should be much easier then because
either the packages we need will be back, or at least we can vendor
modern versions that use dune. For a dune package, simply dropping the
package's source code inside 0install's source directory is enough to
make 0install use it.

The removal of the dependencies also happened just before the Ubuntu
Debian-import freeze, and I thought we'd be stuck with a broken
package in Ubuntu, but the package seems to have updated by itself to
the fixed version despite the freeze.

In the longer term, we should try to make it easier to import packages
from opam into Debian. It's amazing the amount of volunteer time
Debian consumes in the process of taking tested and working packages
from upstream and breaking them :-(


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

[Zero-install-devel] 0install 2.14.1

[Thomas L. <ta...@gm...>]

0install 2.14.1 is now available (source and generic binaries):

  https://0install.net/install-source.html
  https://0install.net/install-linux.html#generic


Changes since 2.14:

- Fix check for HTTP Location header. This should be case insensitive.
On systems where libcurl supports HTTP/2, we always get the header in
lowercase. Reported by Nick Sabalausky.

Build clean-ups:

- Suppress yojson deprecation warning.

- Update to support OCaml 4.08.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

[Zero-install-devel] 0compile 1.5

[Thomas L. <ta...@gm...>]

0compile 1.5 has been released:

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

Changes since 1.4

- Only display selected dependencies in autocompile output. We tried
to display everything in impl.requires, which is all the <requires> of
the <implementation>. This misses dependencies of commands and tries
to include unused dependencies (e.g. optional dependencies or those
only needed on a different architecture). Reported by Tim Cuthbertson.

- Don't create empty .git directory when copying sources (Tim Cuthbertson).

- Fix dup-src with 0compile.properties. This was intended to avoid
copying sub-directories that are being used as build directories.
However, if the source code has a 0compile.properties at its top
level, it also skipped copying everything.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

[Zero-install-devel] 0install 2.14

[Thomas L. <ta...@gm...>]

0install 2.14 is now available (source and generic binaries):

  https://0install.net/install-source.html
  https://0install.net/install-linux.html#generic


Changes since 2.13:


New features

- Support `version` attribute on package-implementations. Sometimes
different versions of a distribution package need to be handled
differently. For example, selecting python-gobject version 2..!3 may
require us to select Python 2..!3 too. See
https://github.com/0install/repo.roscidus.com/pull/112 for an example
(note that the final syntax is different though - see
https://0install.net/interface-spec.html#package-implementation).


Bug fixes

- Warn about duplicate package-implementations. If two
<package-implementation> elements generate implementations with the
same ID then log a warning. The Python version of 0install used to do
this, but the OCaml version was missing the check. Reported in
https://github.com/0install/repo.roscidus.com/pull/112 by pmiess.

- Fix host Python test on macOS. On Debian (Python 3.5.3), __path__ is
a string, but on macOS (Python 3.6.5) it's a list. Error was: warning:
Failed to get details from Python: Bad JSON: ...


Code clean-ups

- Convert build system to Dune. Advantages include:
  - Reduces build time for a clean build from 35s to 12s (for make
all), and from 40s to 19s (with tests) on my laptop.
  - Reduces time for incremental builds. Doing "make" when nothing has
changed went from 5s to 0s. Changing base64.ml and rebuilding, the
time reduces from 20s to 4s.
  - The project is around 300 lines shorter with the new system.
  - If you want to make changes to a library that 0install uses, you
can just clone it as a subdirectory. Dune will automatically do fast
incremental builds across both projects.
  - The dune files should be easier to read than the myocamlbuild.ml file.

- Work around a type checker bug in OCaml 4.07
(https://github.com/ocaml/ocaml/issues/7824).

- Move 0install commands under new cli directory.

- Move all test data under tests/data. It was a bit spread out before,
with test data inherited from the Python in tests and other data in
ocaml/tests. Renamed a couple of files that differed only in case to
avoid confusion (and failing tests, on OS X).

- Don't run the unit-tests again when testing 0compile. This gets
called even when ounit isn't installed, which is now an error.

- Update to opam 2. The main opam repository has updated to a new
format, so opam 1 no longer works.

- Move Env to Support.Env. Allows removing varname from Common. Also,
tidied the code slightly.

- Move string utilities to XString.

- Move Safe_exception out of Common. Also, add an mli file and make
the payload type abstract. Some places that previously only displayed
the message now include the context if present (often it isn't, so
this makes no difference). This allows other things that use
exceptions to be moved out of Common.

- Move stdout out of system. Only the CLI code needs access to stdout.

- Remove set_mtime work-around. This was fixed in OCaml 4.03.

- Remove support for OpenSSL hash functions. Just use ocaml-sha everywhere.

- Use a map instead of a hashtable in Env. Makes it easier and more
reliable to temporarily add an item to it, makes it clearer when it
cannot be mutated, and ensures variables are always set in the same
order. Also, it now gives the location of the <command> element on
error.

- Replace Success/Problem with Ok/Error. These are built-in with OCaml >= 4.03.

- Use Format in more places.

- Tidy up tree.ml. Add an mli file and use Format for output.

- Rename fmt functions to pp. `pp` is the convention that other OCaml
programs use.

- Clean up command-building code.

- Use Filename.get_temp_dir_name in unit-tests. We no longer need to
support OCaml 3.12.

- Enable Travis tests for OCaml 4.07.

- Remove some old OCaml 4.02 support. We now require >= 4.03 anyway,
and it was causing a warning on OCaml 4.07.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] PyGObject on Windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Bastian,
	Here is another source.
This location https://www.lfd.uci.edu/~gohlke/pythonlibs/#pygtk
Has pygobject 2.28.6 for amd64

The msys2 mingw packages are here http://repo.msys2.org/mingw/x86_64/
And that includes gobject2 2.28.7 as well as gobject 3.20.4

Here is the tree you would need to use gobject2 2.28.7 x86_64
mingw-w64-x86_64-python2-gobject2
	mingw-w64-x86_64-glib2
		mingw-w64-x86_64-gcc-libs
			already packaged
		mingw-w64-x86_64-gettext
			already packaged
		mingw-w64-x86_64-pcre
			mingw-w64-x86_64-gcc-libs
				already packaged
			mingw-w64-x86_64-bzip2
				already packaged
			mingw-w64-x86_64-wineditline
			mingw-w64-x86_64-zlib
				already packaged
		mingw-w64-x86_64-libffi
				 already packaged
		mingw-w64-x86_64-zlib
				 already packaged
		mingw-w64-x86_64-python3
			mingw-w64-x86_64-gcc-libs
				 already packaged
			mingw-w64-x86_64-expat
				 already packaged
			mingw-w64-x86_64-bzip2
				 already packaged
			mingw-w64-x86_64-libffi
				 already packaged
			mingw-w64-x86_64-mpdecimal
				mingw-w64-x86_64-gcc-libs
					already packaged
			mingw-w64-x86_64-ncurses
				 already packaged
			mingw-w64-x86_64-openssl
				mingw-w64-x86_64-ca-certificates
					mingw-w64-x86_64-p11-kit
						mingw-w64-x86_64-libtasn1
							mingw-w64-x86_64-gcc-libs
								already packaged
						mingw-w64-x86_64-libffi
							already packaged
						mingw-w64-x86_64-gettext
							already packaged
				mingw-w64-x86_64-gcc-libs
					already packaged
				mingw-w64-x86_64-zlib
					already packaged
			mingw-w64-x86_64-tcl
				mingw-w64-x86_64-gcc-libs
					already packaged
				mingw-w64-x86_64-zlib
					already packaged
			mingw-w64-x86_64-tk
				mingw-w64-x86_64-tcl>=8.6.9
			mingw-w64-x86_64-zlib
				 already packaged
			mingw-w64-x86_64-xz
				mingw-w64-x86_64-gcc-libs
					already packaged
				mingw-w64-x86_64-gettext
					already packaged
			mingw-w64-x86_64-sqlite3
				mingw-w64-x86_64-gcc-libs
					already packaged
				mingw-w64-x86_64-ncurses
					already packaged
				mingw-w64-x86_64-readline
					mingw-w64-x86_64-gcc-libs
						already packaged
					mingw-w64-x86_64-termcap
						mingw-w64-x86_64-gcc-libs
							already packaged
	mingw-w64-x86_64-libffi
				 already packaged
	mingw-w64-x86_64-gobject-introspection-runtime
		mingw-w64-x86_64-glib2
			...
	mingw-w64-x86_64-pygobject2-devel=2.28.7

We only need to add 12 packages to the ones I have up @ https://gitlab.com/pmiess/0install-feeds/tree/master/public/mingw64
Of course the existing packages may need a version bump and could be incorrect as I haven't used them very much.
FYI the GCC and Perl packages are not quite right.

Phil


-----Original Message-----
From: Bastian Eicher [mailto:ba...@ei...] 
Sent: Thursday, December 20, 2018 6:13 AM
To: 'The Zero Install system' <zer...@li...>
Subject: [Zero-install-devel] PyGObject on Windows

I've been looking for prebuild Windows binaries for the
http://repo.roscidus.com/python/python-gobject feed.

The ones currently listed in the feed are from
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/. There are only
PyGObject 2 builds for x86 Python 2.x here. There haven't been any updates
since 2011.

The official PyGObject documentation at
https://pygobject.readthedocs.io/en/latest/getting_started.html#windows-gett
ing-started simply suggests to use MSYS2's package manager to acquire python
and python-gobject.

PyGObject for Windows (https://sourceforge.net/projects/pygobjectwin32/)
provides PyGObject 3 builds for Python 2.7 - 3.4 in both x86 and AMD64
variants. The last update is from May 2017.

"gobject" needs to be imported differently when using PyGObject 2 (import
gobject) or PyGObject 3 (from gi.repository import GObject as gobject). This
code in Zero Install takes care of that:
https://github.com/0install/0install/blob/b2.3/zeroinstall/support/tasks.py#
L48
If I'm reading it correctly, the code assumes it will always use PyGObject 2
on Python 2.x and PyGObject 3 on Python 3 or later.
0compile has a fixed assumption of using python-gobject2
(https://github.com/0install/0compile/blob/master/0compile#L11) since its
feed requires Python < 3.

However, the PyGObject for Windows builds I mentioned above are all
PyGObject 3, even for Python 2.7. Can/should we change the code to
detect/support and use PyGObject 3 on Python 2.x?

[Zero-install-devel] PyGObject on Windows

[Bastian E. <ba...@ei...>]

I've been looking for prebuild Windows binaries for the
http://repo.roscidus.com/python/python-gobject feed.

The ones currently listed in the feed are from
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/. There are only
PyGObject 2 builds for x86 Python 2.x here. There haven't been any updates
since 2011.

The official PyGObject documentation at
https://pygobject.readthedocs.io/en/latest/getting_started.html#windows-gett
ing-started simply suggests to use MSYS2's package manager to acquire python
and python-gobject.

PyGObject for Windows (https://sourceforge.net/projects/pygobjectwin32/)
provides PyGObject 3 builds for Python 2.7 - 3.4 in both x86 and AMD64
variants. The last update is from May 2017.

"gobject" needs to be imported differently when using PyGObject 2 (import
gobject) or PyGObject 3 (from gi.repository import GObject as gobject). This
code in Zero Install takes care of that:
https://github.com/0install/0install/blob/b2.3/zeroinstall/support/tasks.py#
L48
If I'm reading it correctly, the code assumes it will always use PyGObject 2
on Python 2.x and PyGObject 3 on Python 3 or later.
0compile has a fixed assumption of using python-gobject2
(https://github.com/0install/0compile/blob/master/0compile#L11) since its
feed requires Python < 3.

However, the PyGObject for Windows builds I mentioned above are all
PyGObject 3, even for Python 2.7. Can/should we change the code to
detect/support and use PyGObject 3 on Python 2.x?

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Bastian E. <ba...@ei...>]

I gave running "0compile http://0install.net/tests/GNU-Hello.xml" on Windows
another try.

@Thomas You were right: On the second run the call to
_download_with_external_fetcher wasn't needed anymore and the bug was
thereby avoided.

However, it now fails with "sh: No such file or directory" (see below for
full output). Anybody got ideas how to debug this further?

================= http://0install.net/tests/GNU-Hello.xml ==================

Selecting versions for GNU Hello...
Selection done.

Plan:

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)
  - make: Use existing binary 3.81 (Windows-i486)
    - make dependencies: Use existing binary 3.81 (Windows-i486)

No dependencies need compiling... compile GNU Hello itself...
TMPDIR=d:\temp\0compile-hupfoc
BUILDDIR=d:\temp\0compile-2nwlcs\build
DISTDIR=d:\temp\0compile-2nwlcs\gnu-hello-windows-x86_64
SRCDIR=F:\0install\sha256new_KVK6PC63Z7MKNSJ7GYF3Z7AJ5DSRSRKGQQXI4FEN63FG2AI
7CEVA
BINARYFEED=d:\temp\0compile-2nwlcs\gnu-hello-windows-x86_64\0install\feed.xm
l
cd d:\temp\0compile-2nwlcs\build
PATH=F:\0install\sha256new_MO6M47HEJ4I6YOFT63O4L53QXP74K5SP5PQ6R63FXH4LFGY5Q
M3A\bin;F:\0install\sha256new_CCWSRVUMZLIYN2ZTLIBLH3D7DNMATOHTSYQG7MCRTANIZ7
PGA7YA\pywin32_system32;F:\0install\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6GK
JC455VK6HYMVT5IBOMJDXA\.;F:\0install\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6G
KJC455VK6HYMVT5IBOMJDXA\Windows\system32;F:\0install\sha256new_P3LD6BDLOWLCK
SEHYQJABS454FN6GKJC455VK6HYMVT5IBOMJDXA\DLLs;F:\0install\sha256new_V36BMVEDE
IGK2IR5KESEYLQUQZ3SKXWUIEDJTBWO252O56RGUOVA\bin;F:\0install\sha256new_25VZHE
CYKPTOHKWZVR6Q6ZFW2F362QKJYXGELIWY5VKTY7QQWOKQ\.;...
PATH=F:\0install\sha256new_MO6M47HEJ4I6YOFT63O4L53QXP74K5SP5PQ6R63FXH4LFGY5Q
M3A\bin;F:\0install\sha256new_CCWSRVUMZLIYN2ZTLIBLH3D7DNMATOHTSYQG7MCRTANIZ7
PGA7YA\pywin32_system32;F:\0install\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6GK
JC455VK6HYMVT5IBOMJDXA\.;F:\0install\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6G
KJC455VK6HYMVT5IBOMJDXA\Windows\system32;F:\0install\sha256new_P3LD6BDLOWLCK
SEHYQJABS454FN6GKJC455VK6HYMVT5IBOMJDXA\DLLs;F:\0install\sha256new_V36BMVEDE
IGK2IR5KESEYLQUQZ3SKXWUIEDJTBWO252O56RGUOVA\bin;F:\0install\sha256new_25VZHE
CYKPTOHKWZVR6Q6ZFW2F362QKJYXGELIWY5VKTY7QQWOKQ\.;...
Executing: "$SRCDIR/configure" --prefix="$DISTDIR" && make install []
+
F:\0install\sha256new_KVK6PC63Z7MKNSJ7GYF3Z7AJ5DSRSRKGQQXI4FEN63FG2AI7CEVA/c
onfigure --prefix=d:\temp\0compile-2nwlcs\gnu-hello-windows-x86_64
F:\0install\sha1new=624fe11b4b9f88c1087ed915e2c66b07edaf62dd\win-bash.exe:
sh: No such file or directory
Command
'['C:\\Users\\Bastian\\AppData\\Local\\0install.net\\injector\\executables\\
0COMPILE_BASH\\0COMPILE_BASH.exe', '-eux', '-c', u'"$SRCDIR/configure"
--prefix="$DISTDIR" && make install']': Build failed with exit code 1
Command failed with exit status 1

Build failed: leaving build directory d:\temp\0compile-2nwlcs for
inspection...

Command
'['F:\\0install\\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6GKJC455VK6HYMVT5IBOMJ
DXA\\python.exe',
'F:\\0install\\sha256new_DRI2B34BA24I5WP4NJCHZ6F2RU6ZDGRULN4WEUZNLYX6RW6BAN2
A\\0compile', 'build']' returned non-zero exit status 1

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Thomas L. <ta...@gm...>]

On Tue, 11 Dec 2018 at 18:12, Bastian Eicher <ba...@ei...> wrote:
>
> 0compile internally calls "0install fetch" on Windows, to delegate downloading and extracting archives back to the C# implementation, which handles stuff like NTFS ACLs.
>
>  The regular archive extraction code in Zero Install for Windows automatically guesses the MIME type of an archive based on its file ending if it is not specified (like the Linux version does). However, this "guessing code" is not executed on "0install fetch". I've fixed that and will publish a new release of Zero Install for Windows soon.
>
> Running "0compile autocompile http://0install.net/tests/GNU-Hello.xml" on my machine with a pre-release build containing this fix I get the following stack trace:
>
> Traceback (most recent call last):
>   File "(...0install...)\zeroinstall\injector\selections.py", line 443, in download
>     tasks.check(fetch_impls)
>   File "(...0install...)\zeroinstall\support\tasks.py", line 161, in check
>     for b in blockers:
> TypeError: 'NoneType' object is not iterable
>
> @Thomas: Any ideas what could be going wrong here?

Selections.download_missing does:

  fetch_impls = config.fetcher.download_impls(needed_impls, stores)
  yield fetch_impls
  tasks.check(fetch_impls)

It expects download_impls to return a blocker, but Fetcher.download_impls does:

  if self.external_fetcher:
    self._download_with_external_fetcher(implementations)
    return None

It's trying to check None to see if it failed, and crashes. Assuming
_download_with_external_fetcher succeeded, it will probably work if
you try again!

Wrapping that call to check in an "if" should fix it.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] can't run feedlint on windows

[Thomas L. <ta...@gm...>]

On Tue, 11 Dec 2018 at 18:20, Bastian Eicher <ba...@ei...> wrote:
>
> I've published a Zero Install for Windows update (2.16.0) that changes the
> solver behavior to prefer newer versions over 64-bitness (like the OCaml and
> Python implementations).
>
> @Thomas: Thanks for modifying the Zero Install feed. As you said, that
> should at least prevent incorrect selections for people running older
> versions of Zero Install for Windows.
>
> I'll look into adding a 64-bit Windows version of python-gobject to the feed
> some time this week.

That's great - thanks!

-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] can't run feedlint on windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Bastian,
	With the new version feelint 0.9 runs as expected when the old versions are not restricted. 
Thanks for the fix.
Phil

-----Original Message-----
From: Bastian Eicher [mailto:ba...@ei...] 
Sent: Tuesday, December 11, 2018 1:20 PM
To: 'The Zero Install system' <zer...@li...>
Subject: Re: [Zero-install-devel] can't run feedlint on windows

I've published a Zero Install for Windows update (2.16.0) that changes the solver behavior to prefer newer versions over 64-bitness (like the OCaml and Python implementations).

@Thomas: Thanks for modifying the Zero Install feed. As you said, that should at least prevent incorrect selections for people running older versions of Zero Install for Windows.

I'll look into adding a 64-bit Windows version of python-gobject to the feed some time this week.

-----Original Message-----
From: Thomas Leonard <ta...@gm...>
Sent: Samstag, 8. Dezember 2018 17:54
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] can't run feedlint on windows

On Fri, 7 Dec 2018 at 12:02, Bastian Eicher <ba...@ei...> wrote:
>
> @Thomas: Could you add a dependency on python-gobject to FeedLint?
>
> Some tools with dependencies on Zero Install, like 0template and 
> 0repo,
work fine on Windows without gobject. Therefore, I think it would be better to add the os="POSIX" restriction for the python-object dependency in the Zero Install feed back in.

That's really just luck, though. I suspect if you hit the right code path it may need gobject. I've instead added gobject dependencies to the older versions of 0install so at least it should get it when it needs it now.

One possible quick workaround for the slow solver issue might be to add a 64-bit Windows version of python-gobject...

Re: [Zero-install-devel] can't run feedlint on windows

[Bastian E. <ba...@ei...>]

I've published a Zero Install for Windows update (2.16.0) that changes the
solver behavior to prefer newer versions over 64-bitness (like the OCaml and
Python implementations).

@Thomas: Thanks for modifying the Zero Install feed. As you said, that
should at least prevent incorrect selections for people running older
versions of Zero Install for Windows.

I'll look into adding a 64-bit Windows version of python-gobject to the feed
some time this week.

-----Original Message-----
From: Thomas Leonard <ta...@gm...> 
Sent: Samstag, 8. Dezember 2018 17:54
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] can't run feedlint on windows

On Fri, 7 Dec 2018 at 12:02, Bastian Eicher <ba...@ei...> wrote:
>
> @Thomas: Could you add a dependency on python-gobject to FeedLint?
>
> Some tools with dependencies on Zero Install, like 0template and 0repo,
work fine on Windows without gobject. Therefore, I think it would be better
to add the os="POSIX" restriction for the python-object dependency in the
Zero Install feed back in.

That's really just luck, though. I suspect if you hit the right code path it
may need gobject. I've instead added gobject dependencies to the older
versions of 0install so at least it should get it when it needs it now.

One possible quick workaround for the slow solver issue might be to add a
64-bit Windows version of python-gobject...

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Bastian E. <ba...@ei...>]

0compile internally calls "0install fetch" on Windows, to delegate
downloading and extracting archives back to the C# implementation, which
handles stuff like NTFS ACLs.

 

The regular archive extraction code in Zero Install for Windows
automatically guesses the MIME type of an archive based on its file ending
if it is not specified (like the Linux version does). However, this
"guessing code" is not executed on "0install fetch". I've fixed that and
will publish a new release of Zero Install for Windows soon.

 

Running "0compile autocompile http://0install.net/tests/GNU-Hello.xml" on my
machine with a pre-release build containing this fix I get the following
stack trace:

 

Traceback (most recent call last):

  File "(...0compile...)\0compile", line 78, in <module>

    matches[0](args[1:])

  File "(...0compile...)\autocompile.py", line 586, in do_autocompile

    compiler.build()

  File "(...0compile...)\autocompile.py", line 363, in build

    tasks.wait_for_blocker(self.recursive_build(self.iface_uri))

  File "(...0install...)\zeroinstall\support\tasks.py", line 501, in
wait_for_blocker

    check(blocker)

  File "(...0install...)\zeroinstall\support\tasks.py", line 175, in check

    support.raise_with_traceback(ex[0], ex[1])

  File "(...0install...)\zeroinstall\support\__init__.py", line 105, in
raise_with_traceback

    exec("raise ex, None, tb", {'ex': ex, 'tb': tb})    # Python 2

  File "(...0install...)\zeroinstall\support\tasks.py", line 374, in _resume

    new_blockers = next(self.iterator)

  File "(...0compile...)\autocompile.py", line 321, in recursive_build

    tasks.check(build)

  File "(...0install...)\zeroinstall\support\tasks.py", line 175, in check

    support.raise_with_traceback(ex[0], ex[1])

  File "(...0install...)\zeroinstall\support\__init__.py", line 105, in
raise_with_traceback

    exec("raise ex, None, tb", {'ex': ex, 'tb': tb})    # Python 2

  File "(...0install...)\zeroinstall\support\tasks.py", line 374, in _resume

    new_blockers = next(self.iterator)

  File "(...0compile...)\autocompile.py", line 178, in compile_and_register

    tasks.check(download_missing)

  File "(...0install...)\zeroinstall\support\tasks.py", line 175, in check

    support.raise_with_traceback(ex[0], ex[1])

  File "(...0install...)\zeroinstall\support\__init__.py", line 105, in
raise_with_traceback

    exec("raise ex, None, tb", {'ex': ex, 'tb': tb})    # Python 2

  File "(...0install...)\zeroinstall\support\tasks.py", line 374, in _resume

    new_blockers = next(self.iterator)

  File "(...0install...)\zeroinstall\injector\selections.py", line 443, in
download

    tasks.check(fetch_impls)

  File "(...0install...)\zeroinstall\support\tasks.py", line 161, in check

    for b in blockers:

TypeError: 'NoneType' object is not iterable

 

@Thomas: Any ideas what could be going wrong here?

 

From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> 
Sent: Montag, 10. Dezember 2018 15:36
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on
windows

 

Zero install team,

                this now give a different error 

H:\>0compile autocompile http://0install.net/tests/GNU-Hello.xml

================= http://0install.net/tests/GNU-Hello.xml ==================

 

Selecting versions for GNU Hello...

Selection done.

 

Plan:

 

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)

  - make: Use existing binary 3.81 (Windows-i486)

    - make dependencies: Use existing binary 3.81 (Windows-i486)

 

No dependencies need compiling... compile GNU Hello itself...

The archive MIME type '' is not supported.

Download with external fetcher failed

 

I think it needs a type="application/x-compressed-tar" attribute on the
archive element.

 

Phil

 

From: Bastian Eicher [mailto:ba...@ei...] 
Sent: Friday, December 07, 2018 7:04 AM
To: 'The Zero Install system' <zer...@li...
<mailto:zer...@li...> >
Subject: Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on
windows

 

Zero Install for Windows does not support the old "sha1" digest format
anymore. It only supports "sha1new", "sha256" and "sha256new".

 

@Thomas: Could you update http://0install.net/tests/GNU-Hello.xml
<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-
2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHF
QFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21Ko
ANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=>  to use sha1new
hashes?

 

From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th... <mailto:phi...@th...> > 
Sent: Dienstag, 4. Dezember 2018 23:04
To: The Zero Install system <zer...@li...
<mailto:zer...@li...> >
Subject: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on
windows

 

Zero install team,

        When I run the example 0Compile on windows I get the following.

 

>0compile autocompile http://0install.net/tests/GNU-Hello.xml
<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-
2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHF
QFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21Ko
ANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=> 

================= http://0install.net/tests/GNU-Hello.xml
<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-
2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHF
QFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21Ko
ANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=>  ==================

 

Selecting versions for GNU Hello...

Selection done.

 

Plan:

 

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)

  - make: Use existing binary 3.81 (Windows-i486)

    - make dependencies: Use existing binary 3.81 (Windows-i486)

 

No dependencies need compiling... compile GNU Hello itself...

No manifest digest for implementation
'sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7' found.

Download with external fetcher failed

 

So the feed needs to have the sha1 manifest added.

 

 

Philip Miess

 

 

 

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Thomas L. <ta...@gm...>]

On Mon, 10 Dec 2018 at 14:37, Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> wrote:
>
> Zero install team,
>
>                 this now give a different error
>
> H:\>0compile autocompile http://0install.net/tests/GNU-Hello.xml
> - GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)
>   - make: Use existing binary 3.81 (Windows-i486)
>     - make dependencies: Use existing binary 3.81 (Windows-i486)
>
> No dependencies need compiling... compile GNU Hello itself...
> The archive MIME type '' is not supported.
> Download with external fetcher failed
>
> I think it needs a type="application/x-compressed-tar" attribute on the archive element.

The spec says you shouldn't need a MIME type if the extension is .tar.gz:

  http://0install.net/interface-spec.html#retrieval-methods

Does the Windows fetcher require the attribute?


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Zero install team,
                this now give a different error
H:\>0compile autocompile http://0install.net/tests/GNU-Hello.xml
================= http://0install.net/tests/GNU-Hello.xml ==================

Selecting versions for GNU Hello...
Selection done.

Plan:

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)
  - make: Use existing binary 3.81 (Windows-i486)
    - make dependencies: Use existing binary 3.81 (Windows-i486)

No dependencies need compiling... compile GNU Hello itself...
The archive MIME type '' is not supported.
Download with external fetcher failed

I think it needs a type="application/x-compressed-tar" attribute on the archive element.

Phil

From: Bastian Eicher [mailto:ba...@ei...]
Sent: Friday, December 07, 2018 7:04 AM
To: 'The Zero Install system' <zer...@li...>
Subject: Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

Zero Install for Windows does not support the old "sha1" digest format anymore. It only supports "sha1new", "sha256" and "sha256new".

@Thomas: Could you update http://0install.net/tests/GNU-Hello.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21KoANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=> to use sha1new hashes?

From: Miess, Philip (TR Tech, Content & Ops) <phi...@th...<mailto:phi...@th...>>
Sent: Dienstag, 4. Dezember 2018 23:04
To: The Zero Install system <zer...@li...<mailto:zer...@li...>>
Subject: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

Zero install team,
        When I run the example 0Compile on windows I get the following.

>0compile autocompile http://0install.net/tests/GNU-Hello.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21KoANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=>
================= http://0install.net/tests/GNU-Hello.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_tests_GNU-2DHello.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=dNkBJsyd5b5eaEQdTS44GtarzNejpYzyT21KoANOP_0&s=_ehEWYzrbqNVzthRVazXX5DF_c1UxE9F-wVA432Xrcw&e=> ==================

Selecting versions for GNU Hello...
Selection done.

Plan:

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)
  - make: Use existing binary 3.81 (Windows-i486)
    - make dependencies: Use existing binary 3.81 (Windows-i486)

No dependencies need compiling... compile GNU Hello itself...
No manifest digest for implementation 'sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7' found.
Download with external fetcher failed

So the feed needs to have the sha1 manifest added.


Philip Miess

Re: [Zero-install-devel] can’t run feedlint on windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

-----Original Message-----
From: Thomas Leonard [mailto:ta...@gm...] 
Sent: Saturday, December 08, 2018 11:50 AM
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] can’t run feedlint on windows

On Tue, 4 Dec 2018 at 20:46, Miess, Philip (TR Tech, Content & Ops) <phi...@th...> wrote:
>
> Zero install team,
>         If I run feedlint on windows I get the following error
>
> 0install run http://0install.net/2007/interfaces/FeedLint.xml http://0install.net/2007/interfaces/FeedLint.xml
> Traceback (most recent call last):
>   File "C:\ProgramData\0install.net\implementations\sha256new_TGEZYDFL3HZBTFMTM4LVDL4SOLYTORIYAAIIVQXUHYMLYOUL44YQ\feedlint", line 11, in <module>
>     from zeroinstall import SafeException
>   File "C:\ProgramData\0install.net\implementations\sha256new_FOGTP26G26DZHEXXPPFXLEBO2Q6TUHGRTSVJ5ZCOAUGKVSZROIVQ\zeroinstall\__init__.py", line 25, in <module>
>     import gobject
> ImportError: No module named gobject
>
> Probably needs GTK also.

(see https://github.com/0install/0install-feeds/issues/1)

-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/ 
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Zero install team,
	Now 0install selects FeedLint version 0.1 - 0.5 before 0.9 
If I mark 0.9 as preferred in the UI it still selects 0.5
If I mark 0.1-0.5 as insecure then it will use 0.9 and work correctly

Phil

Re: [Zero-install-devel] can't run feedlint on windows

[Thomas L. <ta...@gm...>]

On Fri, 7 Dec 2018 at 12:02, Bastian Eicher <ba...@ei...> wrote:
>
> @Thomas: Could you add a dependency on python-gobject to FeedLint?
>
> Some tools with dependencies on Zero Install, like 0template and 0repo, work fine on Windows without gobject. Therefore, I think it would be better to add the os="POSIX" restriction for the python-object dependency in the Zero Install feed back in.

That's really just luck, though. I suspect if you hit the right code
path it may need gobject. I've instead added gobject dependencies to
the older versions of 0install so at least it should get it when it
needs it now.

One possible quick workaround for the slow solver issue might be to
add a 64-bit Windows version of python-gobject...


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] can’t run feedlint on windows

[Thomas L. <ta...@gm...>]

On Tue, 4 Dec 2018 at 20:46, Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> wrote:
>
> Zeroinstall team,
>         If I run feedlint on windows I get the following error
>
> 0install run http://0install.net/2007/interfaces/FeedLint.xml http://0install.net/2007/interfaces/FeedLint.xml
> Traceback (most recent call last):
>   File "C:\ProgramData\0install.net\implementations\sha256new_TGEZYDFL3HZBTFMTM4LVDL4SOLYTORIYAAIIVQXUHYMLYOUL44YQ\feedlint", line 11, in <module>
>     from zeroinstall import SafeException
>   File "C:\ProgramData\0install.net\implementations\sha256new_FOGTP26G26DZHEXXPPFXLEBO2Q6TUHGRTSVJ5ZCOAUGKVSZROIVQ\zeroinstall\__init__.py", line 25, in <module>
>     import gobject
> ImportError: No module named gobject
>
> Probably needs GTK also.

(see https://github.com/0install/0install-feeds/issues/1)


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC

Re: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Bastian E. <ba...@ei...>]

Zero Install for Windows does not support the old "sha1" digest format
anymore. It only supports "sha1new", "sha256" and "sha256new".

 

@Thomas: Could you update http://0install.net/tests/GNU-Hello.xml to use
sha1new hashes?

 

From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> 
Sent: Dienstag, 4. Dezember 2018 23:04
To: The Zero Install system <zer...@li...>
Subject: [Zero-install-devel] 0Compile Gnu Hello example doesn't work on
windows

 

Zero install team,

        When I run the example 0Compile on windows I get the following.

 

>0compile autocompile http://0install.net/tests/GNU-Hello.xml

================= http://0install.net/tests/GNU-Hello.xml ==================

 

Selecting versions for GNU Hello...

Selection done.

 

Plan:

 

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)

  - make: Use existing binary 3.81 (Windows-i486)

    - make dependencies: Use existing binary 3.81 (Windows-i486)

 

No dependencies need compiling... compile GNU Hello itself...

No manifest digest for implementation
'sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7' found.

Download with external fetcher failed

 

So the feed needs to have the sha1 manifest added.

 

 

Philip Miess

 

 

 

Re: [Zero-install-devel] can't run feedlint on windows

[Bastian E. <ba...@ei...>]

@Thomas: Could you add a dependency on python-gobject to FeedLint?

 

Some tools with dependencies on Zero Install, like 0template and 0repo, work
fine on Windows without gobject. Therefore, I think it would be better to
add the os="POSIX" restriction for the python-object dependency in the Zero
Install feed back in.

 

From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> 
Sent: Dienstag, 4. Dezember 2018 21:46
To: The Zero Install system <zer...@li...>
Subject: [Zero-install-devel] can't run feedlint on windows

 

Zeroinstall team,

        If I run feedlint on windows I get the following error

 

0install run http://0install.net/2007/interfaces/FeedLint.xml
http://0install.net/2007/interfaces/FeedLint.xml

Traceback (most recent call last):

  File
"C:\ProgramData\0install.net\implementations\sha256new_TGEZYDFL3HZBTFMTM4LVD
L4SOLYTORIYAAIIVQXUHYMLYOUL44YQ\feedlint", line 11, in <module>

    from zeroinstall import SafeException

  File
"C:\ProgramData\0install.net\implementations\sha256new_FOGTP26G26DZHEXXPPFXL
EBO2Q6TUHGRTSVJ5ZCOAUGKVSZROIVQ\zeroinstall\__init__.py", line 25, in
<module>

    import gobject

ImportError: No module named gobject

 

Probably needs GTK also.

 

Philip Miess

 

 

 

[Zero-install-devel] 0Compile Gnu Hello example doesn't work on windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Zero install team,
        When I run the example 0Compile on windows I get the following.

>0compile autocompile http://0install.net/tests/GNU-Hello.xml
================= http://0install.net/tests/GNU-Hello.xml ==================

Selecting versions for GNU Hello...
Selection done.

Plan:

- GNU Hello: Compile 1.3 (sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7)
  - make: Use existing binary 3.81 (Windows-i486)
    - make dependencies: Use existing binary 3.81 (Windows-i486)

No dependencies need compiling... compile GNU Hello itself...
No manifest digest for implementation 'sha1=2aae32fd27d194167eac7eb611d7ce0983f83dd7' found.
Download with external fetcher failed

So the feed needs to have the sha1 manifest added.


Philip Miess

[Zero-install-devel] can’t run feedlint on windows

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Zeroinstall team,
        If I run feedlint on windows I get the following error

0install run http://0install.net/2007/interfaces/FeedLint.xml http://0install.net/2007/interfaces/FeedLint.xml
Traceback (most recent call last):
  File "C:\ProgramData\0install.net\implementations\sha256new_TGEZYDFL3HZBTFMTM4LVDL4SOLYTORIYAAIIVQXUHYMLYOUL44YQ\feedlint", line 11, in <module>
    from zeroinstall import SafeException
  File "C:\ProgramData\0install.net\implementations\sha256new_FOGTP26G26DZHEXXPPFXLEBO2Q6TUHGRTSVJ5ZCOAUGKVSZROIVQ\zeroinstall\__init__.py", line 25, in <module>
    import gobject
ImportError: No module named gobject

Probably needs GTK also.

Philip Miess

Re: [Zero-install-devel] can't run 0compile on windows .

[Miess, P. (TR T. C. & Ops) <phi...@th...>]

Thomas,
	It works for me as well. 
Thanks for the change.

Phil