headers
Bernhard Sammer | 16 Nov 2004 09:40
Picon

unit-tests for 0install failing

When following the description on your home page to install from source, then
the error below occurs:

$ python tests/0test.py 
Logging to logfile 'log'
gpg: error reading key: secret key not available
Please create a key for "Zero Install <0install <at> foo.com>"
eg: gpg --gen-key

Why does one need to create a secret key?

-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
Permalink | Reply | 3 comments |
headers
Thomas Leonard | 16 Nov 2004 13:42
Picon
Favicon

Re: unit-tests for 0install failing

On Tue, Nov 16, 2004 at 08:40:02AM +0000, Bernhard Sammer wrote:
> When following the description on your home page to install from source, then
> the error below occurs:
> 
> $ python tests/0test.py 
> Logging to logfile 'log'
> gpg: error reading key: secret key not available
> Please create a key for "Zero Install <0install <at> foo.com>"
> eg: gpg --gen-key
> 
> Why does one need to create a secret key?

The tests create a test site, archive and sign it with 0build, and then
serve it to a test copy of zero install which accesses sites via a dummy
http_proxy (listening on 127.0.0.1).

Testing requires signing the test site's archives, and having zero-install
verify the signatures (requiring a secret key). One option here is to ship
a secret key for the test site with the package, but it's not too
difficult to generate one manually.

--

-- 
Dr Thomas Leonard		http://rox.sourceforge.net
tal at ecs.soton.ac.uk	        tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernhard Sammer | 17 Nov 2004 10:05
Picon

Re: unit-tests for 0install failing

Thomas Leonard <tal00r <at> ecs.soton.ac.uk> writes:

> 
> On Tue, Nov 16, 2004 at 08:40:02AM +0000, Bernhard Sammer wrote:
> > When following the description on your home page to install from source, then
> > the error below occurs:
> > 
> > $ python tests/0test.py 
> > Logging to logfile 'log'
> > gpg: error reading key: secret key not available
> > Please create a key for "Zero Install <0install <at> foo.com>"
> > eg: gpg --gen-key
> > 
> > Why does one need to create a secret key?
> 
> The tests create a test site, archive and sign it with 0build, and then
> serve it to a test copy of zero install which accesses sites via a dummy
> http_proxy (listening on 127.0.0.1).
> 
> Testing requires signing the test site's archives, and having zero-install
> verify the signatures (requiring a secret key). One option here is to ship
> a secret key for the test site with the package, but it's not too
> difficult to generate one manually.
> 
Thank you, this was not clear. An explanation of this test (i.e. a link to the
developer/packaging documentation) would be appreciated at the install site
http://0install.net/install.html, because the (first) unit-tests for lazyfs
needs no additional work, you can run it after installation without any
additional steps.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Leonard | 17 Nov 2004 11:38
Picon
Favicon

Re: Re: unit-tests for 0install failing

On Wed, Nov 17, 2004 at 09:05:33AM +0000, Bernhard Sammer wrote:
> Thomas Leonard <tal00r <at> ecs.soton.ac.uk> writes:
> 
> > 
> > On Tue, Nov 16, 2004 at 08:40:02AM +0000, Bernhard Sammer wrote:
> > > When following the description on your home page to install from source, then
> > > the error below occurs:
> > > 
> > > $ python tests/0test.py 
> > > Logging to logfile 'log'
> > > gpg: error reading key: secret key not available
> > > Please create a key for "Zero Install <0install <at> foo.com>"
> > > eg: gpg --gen-key
> > > 
> > > Why does one need to create a secret key?
> > 
> > The tests create a test site, archive and sign it with 0build, and then
> > serve it to a test copy of zero install which accesses sites via a dummy
> > http_proxy (listening on 127.0.0.1).
> > 
> > Testing requires signing the test site's archives, and having zero-install
> > verify the signatures (requiring a secret key). One option here is to ship
> > a secret key for the test site with the package, but it's not too
> > difficult to generate one manually.
> > 
> Thank you, this was not clear. An explanation of this test (i.e. a link to the
> developer/packaging documentation) would be appreciated at the install site
> http://0install.net/install.html,

I already added one...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Leonard | 24 Nov 2004 16:00
Picon
Favicon

Re: just a question..

On Tue, Aug 17, 2004 at 05:06:55PM +0200, Joachim Kupke wrote:
[...]
> A friend decided that would be a good idea, so he kept 0refreshing the
> www-i1.informatik.rwth-aachen.de site (which is no longer actively
> maintained, BTW). When I decided to move the acrobat.com directory to
> ita.ethz.ch (at the same time that I was told about a security
> vulnerability in Acrobat 5.0.8), I installed a symlink at the old site.
> Worked almost everywhere, but not on the one machine that had accessed
> /uri/0install/ita.ethz.ch before. There, things broke because nobody had
> 0refreshed ita.ethz.ch. The only way to work around this would have been
> to use a wrapper script instead of a symlink that, in turn, would call
> 0run or 0refresh appropriately.

Solving this in the most general case is quite difficult. A good solution
might be that reading or following a symlink whose target is missing will
call the zero-install daemon to do something about it.

zero-install can then check whether the symlink points to a site under
/uri/0install, and refresh it if so.

> Solution: Have a magic directory (or symlink) that when accessed
> immediately triggers a 0refresh. As in:
> 
>   $ ls -lA /uri/0install/ita.ethz.ch
>   lrwxr-xr-x  1 root root    1 2004-08-17 16:30 .0inst-mostrecent -> .
>   drwxr-xr-x  1 root root 4096 2004-08-13 11:14 acrobat.com
>   drwxr-xr-x  1 root root 4096 2003-07-29 12:43 hrz.tu-chemnitz.de_fri
>   drwxr-xr-x  1 root root 4096 2003-11-19 17:49 untroubled.org
> 
> Accessing /uri/0install/ita.ethz.ch/.0inst-mostrecent/acrobat.com would
(Continue reading)

Permalink | Reply | 11 comments |
headers
Joachim Kupke | 24 Nov 2004 17:56
Picon

Re: just a question..

Thomas Leonard:

(from your sig)
> Dr Thomas Leonard		http://rox.sourceforge.net
  ^^
Ah, that's what caused the recent silence on the list. My
congratulations.

[referring to zero install sites as of different points of time]
> Solving this in the most general case is quite difficult. A good solution
> might be that reading or following a symlink whose target is missing will
> call the zero-install daemon to do something about it.
> 
> zero-install can then check whether the symlink points to a site under
> /uri/0install, and refresh it if so.

This might be a practical solution occasionally, but it smells like a
kludge. What about an AppRun script that cd's into a directory at a
different site rather than following a symlink there? Neither can its
author be blamed for properly using existing zero install packages, nor
could s/he ever expect the script to break if s/he hadn't even known
about the former version of the site his/her script accesses.

It's all about ensuring that any two zero install users see the same
contents at the same address whenever that is what they desire. You have
decided to make aggressive use of caching, which is alright, and we
wouldn't want to access live NFS directories or the like. But then, we
need a compromise towards more liveness.

But I don't think there should be anything special about the source of
(Continue reading)

Permalink | Reply | 10 comments |
headers
Thomas Leonard | 25 Nov 2004 16:19
Picon
Favicon

Re: just a question..

On Wed, Nov 24, 2004 at 05:56:29PM +0100, Joachim Kupke wrote:
> Thomas Leonard:
> (from your sig)
> > Dr Thomas Leonard		http://rox.sourceforge.net
>   ^^
> Ah, that's what caused the recent silence on the list. My
> congratulations.

Yep, and getting a job, new internet connection, etc... might still be
quiet for a bit...

> [referring to zero install sites as of different points of time]
> > Solving this in the most general case is quite difficult. A good solution
> > might be that reading or following a symlink whose target is missing will
> > call the zero-install daemon to do something about it.
> > 
> > zero-install can then check whether the symlink points to a site under
> > /uri/0install, and refresh it if so.
> 
> This might be a practical solution occasionally, but it smells like a
> kludge. What about an AppRun script that cd's into a directory at a
> different site rather than following a symlink there?

Scripts aren't so much of a problem, as they can use 0refresh.

> > Which option do you think is best?
> > 
> > - Symlink target must exist. Refresh if not. Symlink source must be under
> >   /uri/0install.
> >   	/uri/0install/site1/prog -> /uri/0install/site2/foo/1.0/prog
(Continue reading)

Permalink | Reply | 9 comments |
headers
Joachim Kupke | 26 Nov 2004 13:07
Picon

Re: just a question..

Thomas Leonard:

> > > zero-install can then check whether the symlink points to a site under
> > > /uri/0install, and refresh it if so.
> > 
> > This might be a practical solution occasionally, but it smells like a
> > kludge. What about an AppRun script that cd's into a directory at a
> > different site rather than following a symlink there?
> 
> Scripts aren't so much of a problem, as they can use 0refresh.

Yes, this has been your constant suggestion in the past: Scripts (or
maybe even binaries) should use 0refresh; hence, ld-linux.so should be
modified to do the same before loading libraries, etc. Ultimately, perl,
for example, would be modified in order to 0refresh zero install
site-packages.

Besides, in my example, a number of scripts were involved. All of them
would have had to be modified. Plus, this still doesn't solve the
problem that a site maintainer might either remove or update files (and
not just publish new ones) and thus (unknowingly) cause
incompatibilities between third-party pieces of software:

Site A has libraries foo-1.2 and bar-2.3, and site B's someapp relies on
foo-1.2. Now, site C's anotherapp wants bar-2.4-or-later; thus,
anotherapp will call 0refresh (or 0run or whatever), and suddenly site A
has foo-1.5 and bar-2.4. Unfortunately, someapp relied on foo, but only
versions <= 1.3.

The only way around this (and it happens quite often if you look at some
(Continue reading)

Permalink | Reply | 8 comments |
headers
Thomas Leonard | 26 Nov 2004 14:55
Picon
Favicon

Re: just a question..

On Fri, Nov 26, 2004 at 01:07:14PM +0100, Joachim Kupke wrote:
> Thomas Leonard:
[...]

> Site A has libraries foo-1.2 and bar-2.3, and site B's someapp relies on
> foo-1.2. Now, site C's anotherapp wants bar-2.4-or-later; thus,
> anotherapp will call 0refresh (or 0run or whatever), and suddenly site A
> has foo-1.5 and bar-2.4. Unfortunately, someapp relied on foo, but only
> versions <= 1.3.
> 
> The only way around this (and it happens quite often if you look at some
> Debian package headers) is to keep site A's contents as of different
> points of time in different directories.

Well, we already do this by convention (ROX-Lib/ROX-Lib-1.9.14, etc). I
think you are suggesting we enforce this more (eg, so a site author can't
remove an old version from your cache by upgrading his site).

I was actually talking about getting the kernel to do a 0refresh when you
access something that's too old, but this is a different case.

[...]
> In addition, may I say this: I used to spend some time on what I called
> lazynfsd, an NFS server that, rather than serving files from its own
> file system, imitates lazyfs' behavior by talking to a helper
> application and serving its cached files, etc. Bottom line: After
> launching lazynfsd, you can mount 127.0.0.1:/blah /uri/0install and
> achieve pretty much the same effect as though you had actually mounted
> lazyfs there.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joachim Kupke | 26 Nov 2004 16:43
Picon

Re: just a question..

Thomas Leonard:

> > The only way around this (and it happens quite often if you look at some
> > Debian package headers) is to keep site A's contents as of different
> > points of time in different directories.
> 
> Well, we already do this by convention (ROX-Lib/ROX-Lib-1.9.14, etc). I
> think you are suggesting we enforce this more (eg, so a site author can't
> remove an old version from your cache by upgrading his site).
> 
> I was actually talking about getting the kernel to do a 0refresh when you
> access something that's too old, but this is a different case.

I don't think it's too different. How do you know you access anything
too old? Obviously, negative dcache entries can't do the trick: You
would continuously refresh about everything. Hence, you should be able
to tell by a path name whether it would make sense to refresh a site
before accessing a file. That is why it would be clever to make a time
stamp (or maybe version name alias) a mandatory path name component
since path names are zero install's means of resolving dependencies.

Think of it this way: When you apt-get install somepackage, and
somepackage depends on anotherpackage, the zero install counterpart is
to have /uri/0install/somesite/package access
/uri/0install/anothersite/package. We agree we are now discussing the
case where somepackage depends on anotherpackage (>= version). This is
where the zero install solution currently is to use 0run/0refresh. We
seem to agree that there should be a better method. All I'm saying is
that when looking for a better method, take the case into account where
the (Debian-style) dependency is on anotherpackage (<= version). These
(Continue reading)

Permalink | Reply | 6 comments |

Gmane