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

Re: [Zero-install-devel] Script command to download archive and calculate SHA etc.?

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

Hi Mateusz,

the version of 0publish bundled with the Zero Install Publishing Tools (Feed Editor) has an option that does exactly that:

0install run --command=0publish http://0install.de/feeds/ZeroInstall_Tools.xml --add-missing path\to\feed.xml

Regards
Bastian

-----Original Message-----
From: Mateusz Czaplinski <cza...@gm...> 
Sent: Mittwoch, 1. Januar 2020 22:15
To: The Zero Install system <zer...@li...>
Subject: [Zero-install-devel] Script command to download archive and calculate SHA etc.?

Hi,

Is there a command I could use in my script, other than 0template, that would take a nearly-complete feed.xml, and just download the .zip/.tar.gz/... archive I specified, and then calculate the missing SHA, size, and other derived data, and insert them back into the .xml file?

I'm writing a script to bulk-generate feeds for Vim plugins I use. I am currently passing them through 0template as a workaround, but 0template fetched a surprising amount of dependencies, and generally I'm using it in a very hackish way. I have kinda suspicion there might be just some simple option in 0publish instead, that would do what I'm trying to describe? There are quite many commands and options in 0install, and I'm still having hard time wrapping my head around them and finding what I need - thus I'm not sure if it's not there, or did I simply miss it? 

Thanks & Best Regards,
/Mateusz Czapliński.

[Zero-install-devel] Script command to download archive and calculate SHA etc.?

[Mateusz C. <cza...@gm...>]

Hi,

Is there a command I could use in my script, other than 0template, that
would take a nearly-complete feed.xml, and just download the
.zip/.tar.gz/... archive I specified, and then calculate the missing SHA,
size, and other derived data, and insert them back into the .xml file?

I'm writing a script to bulk-generate feeds for Vim plugins I use. I am
currently passing them through 0template as a workaround, but 0template
fetched a surprising amount of dependencies, and generally I'm using it in
a very hackish way. I have kinda suspicion there might be just some simple
option in 0publish instead, that would do what I'm trying to describe?
There are quite many commands and options in 0install, and I'm still having
hard time wrapping my head around them and finding what I need - thus I'm
not sure if it's not there, or did I simply miss it?

Thanks & Best Regards,
/Mateusz Czapliński.

Re: [Zero-install-devel] Feed for a Vim plugin?

[Mateusz C. <cza...@gm...>]

Thanks! The VIMPATH approach sounds interesting.

A few further questions I'd love if you could help me understand answers to:

  1. Is there a way to find out from command-line which version of a
particular "implementation" of a specific "interface" is currently
installed?
  2. For Vim, I'd like to be able to have it available on Windows in an
"Open with" context menu *for all file types*, while not being the "default
handler" for any file types. Do 0install desktop integrations allow for
such a variation?

Thanks again!
/Mateusz Czapliński.

On Sun, Dec 29, 2019 at 9:41 PM Bastian Eicher <ba...@ei...> wrote:

> You could add the following inside the <implementation> in go-explorer.xml
> :
>
>     <environment name="VIMPATH" insert=""/>
>
>     <command name="run">
>
>       <runner interface="http://repo.roscidus.com/powershell/powershell">
>
>         <arg>-Command</arg>
>
>         <arg>echo $VIMPATH</arg>
>
>       </runner>
>
>     </command>
>
> Executing 0install run
> https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
> would then print the location the archive was extracted to.
>
>
>
> Alternatively you could create a local-only feed my-vim.xml like this:
>
> <interface xmlns="
> http://zero-install.sourceforge.net/2004/injector/interface">
>
>   <implementation version="1" id="dummy" local-path="C:\Path\To\Vim"
> main="vim.exe">
>
>     <requires interface="
> https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
> ">
>
>       <environment name="VIMPATH" insert=""/>
>
>     </requires>
>
>   </implementation>
>
> </interface>
>
> Executing 0install run my-vim.xml would launch C:\Path\To\Vim\vim.exe
> with the environment variable VIMPATH set to the location the plugin was
> extracted to.
>
>
>
> *From:* Mateusz Czaplinski <cza...@gm...>
> *Sent:* Sonntag, 29. Dezember 2019 13:51
> *To:* The Zero Install system <zer...@li...>
> *Subject:* Re: [Zero-install-devel] Feed for a Vim plugin?
>
>
>
>
>
>
>
> On Sat, Dec 28, 2019 at 8:41 PM Thomas Leonard <ta...@gm...> wrote:
>
> On Fri, 27 Dec 2019 at 00:30, Mateusz Czaplinski <cza...@gm...>
> wrote:
> >
> > Hi!
> >
> > I'd like to create a feed for a Vim editor plugin. I would like to
> > then be able to install/download it with 0install, and somehow
> > retrieve the local path where it was unpacked, so that I could
> > reference this path from my .vimrc file. (How) can I do it with
> > 0install?
>
> One way to do this is to create a feed for your custom vim [...]
> The XML source of this page may give some inspiration:
>
>   http://gfxmonk.net/dist/0install/vim-custom.xml
>
>
>
> I looked into this file, but I don't yet understand some aspects of it.
> Specifically:
>
> - there seems to be some "vim-custom-<ID>.tgz" file referenced; not sure
> what's (supposed to be) in it...? I must say I'd prefer if I didn't have to
> host some special vim tweaks in a custom-tailored tarball, I'd love if I
> could just use a vanilla vim tarball...
>
> - in my .vimrc, how can I get the list of plugins available, and how to
> find their paths? is it somehow done with the VIMPATH env var refrenced in
> a few places of the feed?
>
>
>
> > Any ideas how I could make it download successfully, and how I can
> > then get the local path where it was unpacked, ideally from a script?
>
> You could solve this with `--command=` to tell it you're not planning
> to run the plugin directly, but the above approach might be better.
>
>
>
> Thanks! That seemed to work indeed! Still, could you advise how I can then
> find out the directory in the 0install caches where some particular feed
> got downloaded and unpacked? I tried `0install store list-implementations
> <my-name>` - it seems to show the hash, but not sure how I can know in what
> absolute directory it is located...
>
>
>
> Thanks & Best Regards,
>
> /Mateusz Czapliński.
> _______________________________________________
> Zero-install-devel mailing list
> Zer...@li...
> https://lists.sourceforge.net/lists/listinfo/zero-install-devel
>

Re: [Zero-install-devel] Feed for a Vim plugin?

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

You could add the following inside the <implementation> in go-explorer.xml:

    <environment name="VIMPATH" insert=""/>

    <command name="run">

      <runner interface="http://repo.roscidus.com/powershell/powershell">

        <arg>-Command</arg>

        <arg>echo $VIMPATH</arg>

      </runner>

    </command>

Executing 0install run https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml would then print the location the archive was extracted to.

 

Alternatively you could create a local-only feed my-vim.xml like this:

<interface xmlns="http://zero-install.sourceforge.net/2004/injector/interface">

  <implementation version="1" id="dummy" local-path="C:\Path\To\Vim" main="vim.exe">

    <requires interface="https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml">

      <environment name="VIMPATH" insert=""/>

    </requires>

  </implementation>

</interface>

Executing 0install run my-vim.xml would launch C:\Path\To\Vim\vim.exe with the environment variable VIMPATH set to the location the plugin was extracted to.

 

From: Mateusz Czaplinski <cza...@gm...> 
Sent: Sonntag, 29. Dezember 2019 13:51
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] Feed for a Vim plugin?

 

 

 

On Sat, Dec 28, 2019 at 8:41 PM Thomas Leonard <ta...@gm... <mailto:ta...@gm...> > wrote:

On Fri, 27 Dec 2019 at 00:30, Mateusz Czaplinski <cza...@gm... <mailto:cza...@gm...> > wrote:
>
> Hi!
>
> I'd like to create a feed for a Vim editor plugin. I would like to
> then be able to install/download it with 0install, and somehow
> retrieve the local path where it was unpacked, so that I could
> reference this path from my .vimrc file. (How) can I do it with
> 0install?

One way to do this is to create a feed for your custom vim [...]
The XML source of this page may give some inspiration:

  http://gfxmonk.net/dist/0install/vim-custom.xml

 

I looked into this file, but I don't yet understand some aspects of it. Specifically:

- there seems to be some "vim-custom-<ID>.tgz" file referenced; not sure what's (supposed to be) in it...? I must say I'd prefer if I didn't have to host some special vim tweaks in a custom-tailored tarball, I'd love if I could just use a vanilla vim tarball... 

- in my .vimrc, how can I get the list of plugins available, and how to find their paths? is it somehow done with the VIMPATH env var refrenced in a few places of the feed?

 

> Any ideas how I could make it download successfully, and how I can
> then get the local path where it was unpacked, ideally from a script?

You could solve this with `--command=` to tell it you're not planning
to run the plugin directly, but the above approach might be better.

 

Thanks! That seemed to work indeed! Still, could you advise how I can then find out the directory in the 0install caches where some particular feed got downloaded and unpacked? I tried `0install store list-implementations <my-name>` - it seems to show the hash, but not sure how I can know in what absolute directory it is located...

 

Thanks & Best Regards,

/Mateusz Czapliński.

Re: [Zero-install-devel] Feed for a Vim plugin?

[Mateusz C. <cza...@gm...>]

On Sat, Dec 28, 2019 at 8:41 PM Thomas Leonard <ta...@gm...> wrote:

> On Fri, 27 Dec 2019 at 00:30, Mateusz Czaplinski <cza...@gm...>
> wrote:
> >
> > Hi!
> >
> > I'd like to create a feed for a Vim editor plugin. I would like to
> > then be able to install/download it with 0install, and somehow
> > retrieve the local path where it was unpacked, so that I could
> > reference this path from my .vimrc file. (How) can I do it with
> > 0install?
>
> One way to do this is to create a feed for your custom vim [...]
> The XML source of this page may give some inspiration:
>
>   http://gfxmonk.net/dist/0install/vim-custom.xml


I looked into this file, but I don't yet understand some aspects of it.
Specifically:
- there seems to be some "vim-custom-<ID>.tgz" file referenced; not sure
what's (supposed to be) in it...? I must say I'd prefer if I didn't have to
host some special vim tweaks in a custom-tailored tarball, I'd love if I
could just use a vanilla vim tarball...
- in my .vimrc, how can I get the list of plugins available, and how to
find their paths? is it somehow done with the VIMPATH env var refrenced in
a few places of the feed?


> > Any ideas how I could make it download successfully, and how I can
> > then get the local path where it was unpacked, ideally from a script?
>
> You could solve this with `--command=` to tell it you're not planning
> to run the plugin directly, but the above approach might be better.
>

Thanks! That seemed to work indeed! Still, could you advise how I can then
find out the directory in the 0install caches where some particular feed
got downloaded and unpacked? I tried `0install store list-implementations
<my-name>` - it seems to show the hash, but not sure how I can know in what
absolute directory it is located...

Thanks & Best Regards,
/Mateusz Czapliński.

Re: [Zero-install-devel] Feed for a Vim plugin?

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

On Fri, 27 Dec 2019 at 00:30, Mateusz Czaplinski <cza...@gm...> wrote:
>
> Hi!
>
> I'd like to create a feed for a Vim editor plugin. I would like to
> then be able to install/download it with 0install, and somehow
> retrieve the local path where it was unpacked, so that I could
> reference this path from my .vimrc file. (How) can I do it with
> 0install?

One way to do this is to create a feed for your custom vim and have it
depend on the main Vim and on every plugin you want. Then you would do

  0install add vim https://.../my-vim.xml

to get it (or use a local XML file, if you don't want to share your
configuration).

The XML source of this page may give some inspiration:

  http://gfxmonk.net/dist/0install/vim-custom.xml

> I created a test feed that you can see at:
> https://github.com/akavel/0catalog/blob/master/feeds/go-explorer.xml,
> but when I try to install it, I'm getting the following error:
>
>   C:\prog\0catalog>0install download
> https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
>   Running external solver...
>   [                    ]
>   Can't find all required implementations:
>           - https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
> -> (problem)
>               Rejected candidates:
>                 sha1new=b5362a57d7d57a88403340365a7e7e2efabd83cc
> (0.0.20160424): No run command
>
> Any ideas how I could make it download successfully, and how I can
> then get the local path where it was unpacked, ideally from a script?

You could solve this with `--command=` to tell it you're not planning
to run the plugin directly, but the above approach might be better.


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

[Zero-install-devel] Feed for a Vim plugin?

[Mateusz C. <cza...@gm...>]

Hi!

I'd like to create a feed for a Vim editor plugin. I would like to
then be able to install/download it with 0install, and somehow
retrieve the local path where it was unpacked, so that I could
reference this path from my .vimrc file. (How) can I do it with
0install?

I created a test feed that you can see at:
https://github.com/akavel/0catalog/blob/master/feeds/go-explorer.xml,
but when I try to install it, I'm getting the following error:

  C:\prog\0catalog>0install download
https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
  Running external solver...
  [                    ]
  Can't find all required implementations:
          - https://raw.githubusercontent.com/akavel/0catalog/master/feeds/go-explorer.xml
-> (problem)
              Rejected candidates:
                sha1new=b5362a57d7d57a88403340365a7e7e2efabd83cc
(0.0.20160424): No run command

Any ideas how I could make it download successfully, and how I can
then get the local path where it was unpacked, ideally from a script?

Thanks & Best Regards,
/Mateusz Czapliński.

[Zero-install-devel] 0install 2.15

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

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

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


Changes since 2.14.1:

New features

- Add cohttp backend. This adds cohttp as an alternative to using
libcurl for downloads. As cohttp doesn't support FTP, it also adds a
very minimal FTP client implementation. The generic binaries are now
built using this and openssl (statically linked), which should avoid
the symbol version problems with libcurl. Distribution packages should
probably continue to use libcurl for now.

- The "0install --version" output now shows which HTTP backend is
used, and also whether D-Bus support has been compiled in.

Bug fixes

- Don't show stacktraces for expected errors unless `-v` is used. We
previously did this by only enabling stacktraces when `-v` was given.
However, newer versions of OCaml enable stacktraces by default.

- Fix detection of obus library. We looked for `obus.network-manager`,
but that got renamed to `obus.network_manager` when obus converted to
dune.

- Improve speed of apt-cache queries. If we wanted the apt-cache
results for a package but we didn't have them because a check was in
progress, then we started another apt-cache process. Now, we just wait
for the first one to finish. We also now only run one apt-cache query
at a time. These changes reduce the time to run "0install select -rc
0release" from 30s to 8s on my laptop.

- Don't abort if we can't save new app selections. Just log a warning.
Otherwise, you can't run an application at all if e.g. the filesystem
is read-only, or we are running inside a sandbox (e.g. when an opam
build recursively calls the opam binary).

Other changes:

- Use new keylookup.0install.net address for key information lookups.

Tests

- Build and test static binaries in CI.

- Test on OCaml 4.08 and 4.09. Drop support for 4.03 and 4.04, now
that Debian 10 is out.

Code cleanups / build fixes

- Replace Unmodified exception with return value.

- Make transitive OCaml library dependencies explicit.

- Fix select for dune 2.0 (Rudi Grinberg). In dune 2.0, one may not
use with_dbus and without_dbus as module names as they don't really
exist. They're just alternative sources for dbus.ml. The new naming
convention reflect that these are true modules and removes the
unnecessar `modules` field.

- Fix compiler warnings on OCaml 4.08. Error was: Error (alert
deprecated): module Stdlib.Pervasives

- Use "dune exec" in sample_client.py. After switching to dune, we no
longer get a symlink in the source directory.

- Replace Not_found with new OCaml 4.05 _opt functions.

- Add some missing dependencies to 0install.opam, for people building
from source.


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

Re: [Zero-install-devel] Generic binaries depending on libcurl3

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

On Mon, 9 Dec 2019 at 12:06, Thomas Leonard <ta...@gm...> wrote:
>
> On Sat, 23 Nov 2019 at 14:03, Thomas Leonard <ta...@gm...> wrote:
> >
> > On Sun, 17 Nov 2019 at 18:37, Bastian Eicher <ba...@ei...> wrote:
> > >
> > > The generic Linux binaries for 0install
> > > (https://0install.net/injector.html#linux-generic) depend on libcurl3.
> > > However, this library is no longer available in Debian starting with Buster
> > > or Ubuntu starting with 18.10.
> > >
> > > Installing the suggested replacement library libcurl4 results in:
> > > 0install: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3'
> > > not found (required by 0install)
> > >
> > > Maybe we should look back into possibilities for statically linking
> > > 0install's dependencies?
> >
> > This Dockerfile seems to work now (using the latest Alpine edge,
> > building from a 0install Git clone):
> [...]
>
> I tried a few more things with this. The situation is:
>
> - If we statically link everything on Alpine then we can't use GTK,
> because the statically-linked libmusl doesn't support dynamic linking.
> - If we dynamically link libmusl then we get a dependency on libmusl
> and it doesn't work anywhere except Alpine.
> - If we build on Debian then we only get a dependency on glibc, but it
> has lots of symbols that aren't on Alpine, etc.
>
> I also tried using cohttp/ocaml-tls as an alternative to libcurl
> (https://github.com/0install/0install/pull/122). That avoids the above
> problems, but it seems that ocaml-tls doesn't work with all web-sites.
> For example, the set of ciphers supported by GitLab doesn't seem to
> intersect with the set supported by ocaml-tls, so you just get a
> handshake failure.
>
> We could use cohttp with openssl, but I seem to recall that openssl is
> no better at binary compatibility than libcurl.

I've now merged support for using cohttp with openssl
(https://github.com/0install/0install/pull/122). This means you can
static link openssl to get a fairly portable binary. To try it out:

git clone https://github.com/0install/0install.git
cd 0install
make static/dist.tgz

You'll need to have Docker installed to build this way. You can also
run `make static-test` to test the archive on Debian 10 and Fedora 30
(also using Docker).

It would be good to test the resulting binary on more sites. In
particular, cohttp doesn't support FTP, so I hacked up a client myself
quickly. It works on ftp.vim.org, but that's the only one I tested. If
you're still using FTP, I'd recommend testing your site yourself.

If no-one reports any problems, I'll make a new release in a couple of days.


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

Re: [Zero-install-devel] Generic binaries depending on libcurl3

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

On Sat, 23 Nov 2019 at 14:03, Thomas Leonard <ta...@gm...> wrote:
>
> On Sun, 17 Nov 2019 at 18:37, Bastian Eicher <ba...@ei...> wrote:
> >
> > The generic Linux binaries for 0install
> > (https://0install.net/injector.html#linux-generic) depend on libcurl3.
> > However, this library is no longer available in Debian starting with Buster
> > or Ubuntu starting with 18.10.
> >
> > Installing the suggested replacement library libcurl4 results in:
> > 0install: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3'
> > not found (required by 0install)
> >
> > Maybe we should look back into possibilities for statically linking
> > 0install's dependencies?
>
> This Dockerfile seems to work now (using the latest Alpine edge,
> building from a 0install Git clone):
[...]

I tried a few more things with this. The situation is:

- If we statically link everything on Alpine then we can't use GTK,
because the statically-linked libmusl doesn't support dynamic linking.
- If we dynamically link libmusl then we get a dependency on libmusl
and it doesn't work anywhere except Alpine.
- If we build on Debian then we only get a dependency on glibc, but it
has lots of symbols that aren't on Alpine, etc.

I also tried using cohttp/ocaml-tls as an alternative to libcurl
(https://github.com/0install/0install/pull/122). That avoids the above
problems, but it seems that ocaml-tls doesn't work with all web-sites.
For example, the set of ciphers supported by GitLab doesn't seem to
intersect with the set supported by ocaml-tls, so you just get a
handshake failure.

We could use cohttp with openssl, but I seem to recall that openssl is
no better at binary compatibility than libcurl.


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

Re: [Zero-install-devel] GPG for OmniaWrite

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

On Sat, 7 Dec 2019 at 13:36, OmniaWrite <In...@om...> wrote:
>
> The GPG for my app is: 6B9A F865 9622 6571 FB36 3EC5 F792 19AA B7B1 370C

Added - thanks!


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

[Zero-install-devel] GPG for OmniaWrite

[OmniaWrite <In...@om...>]

The GPG for my app is: 6B9A F865 9622 6571 FB36 3EC5 F792 19AA B7B1 370C

Re: [Zero-install-devel] GPG authorization

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

On Thu, 5 Dec 2019 at 21:35, Torsten Dittmann <in...@om...> wrote:
>
> Hello!
>
> I want to use 0install (Which is awesome btw!) for my Project that is going in open beta in a few days.
>
> My app is a next-generation plain text editor engineered for creative writing. It is perfect for writing novels, lyrics, poems, essays, drafts and screenplays and available for Windows/Linux/Mac/Android and iOS.
>
> For that reason, I would like to have my GPG key authorized.

Great -  just post your GPG fingerprint here on this list.


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

[Zero-install-devel] GPG authorization

[Torsten D. <in...@om...>]

<!doctype html>
<html>
 <head> 
  <meta charset="UTF-8"> 
 </head>
 <body>
  <div>
   Hello!
  </div>
  <div>
   <br>
  </div>
  <div>
   I want to use 0install (Which is awesome btw!) for my Project that is going in open beta in a few days. 
  </div>
  <div>
   <br>
  </div>
  <div>
   My app is a next-generation plain text editor engineered for creative writing. It is perfect for writing novels, lyrics, poems, essays, drafts and screenplays and available for Windows/Linux/Mac/Android and iOS.
  </div>
  <div>
   <br>
  </div>
  <div>
   For that reason, I would like to have my GPG key authorized.
  </div>
  <div>
   <br>
  </div>
  <div class="io-ox-signature">
   <p class="default-style">---</p>
   <p class="default-style"><strong>Torsten Dittmann</strong></p>
   <p class="default-style">Entwickler @ OmniaWrite</p>
   <p class="default-style"><br></p>
   <p class="default-style"><a href="mailto:in...@om...">in...@om...</a></p>
   <p class="default-style">https://OmniaWrite.com</p>
  </div> 
 </body>
</html>

Re: [Zero-install-devel] Feature proposal: Build Docker images with 0install

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

On Thu, 21 Nov 2019 at 14:17, Bastian Eicher <ba...@ei...> wrote:
>
> I would like to propose a small addition to 0install that I believe would
> work great with Docker multi-stage builds
> (https://docs.docker.com/develop/develop-images/multistage-build/).
>
> A new command-line options for the "0install run" command, called something
> like --print-script:
> Everything runs as usual (select, download, etc.) right up until the point
> where the target application would be executed. Now instead an equivalent
> shell script is printed to stdout.
> Basically this would mean encoding and printing the output get_exec_args
> (https://github.com/0install/0install/blob/master/ocaml/zeroinstall/exec.ml#
> L109) like this:
> #!/bin/sh
> VAR1=/root/.cache/0install.net/implementations/sha256_ABC123
> /root/.cache/0install.net/implementations/sha256_DEF456/myapp
>
> With this feature it would now be possible to use 0install to download an
> app and its dependencies in Docker but then use that app without having to
> include 0install in the final image:
>
> FROM some-image-with-0install as builder
> RUN 0install run --print-shell http://example.com/feed.xml > /app
> RUN chmod +x /app
> FROM debian
> COPY --from=builder /root/.cache/0install.net /root/.cache/0install.net
> COPY --from=builder /app /app
> ENTRYPOINT ["./app"]

This won't quite work, because if the program runs another program, it
needs to go via `0install runenv`.

> Another usecase for this would be sandbox tools. For example:
> The new Windows Sandbox feature in Windows 10 automatically creates
> light-weight throw-away VMs for testing untrusted software. Zero Install
> could resolve and download dependencies outside of the sandbox and then
> mount the implementation cache directory and a (Windows) shell script into
> the sandbox VM.


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

Re: [Zero-install-devel] Generic binaries depending on libcurl3

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

On Sun, 17 Nov 2019 at 18:37, Bastian Eicher <ba...@ei...> wrote:
>
> The generic Linux binaries for 0install
> (https://0install.net/injector.html#linux-generic) depend on libcurl3.
> However, this library is no longer available in Debian starting with Buster
> or Ubuntu starting with 18.10.
>
> Installing the suggested replacement library libcurl4 results in:
> 0install: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3'
> not found (required by 0install)
>
> Maybe we should look back into possibilities for statically linking
> 0install's dependencies?

This Dockerfile seems to work now (using the latest Alpine edge,
building from a 0install Git clone):

FROM ocurrent/opam:alpine-3.10-ocaml-4.08 AS build
RUN opam depext -i cppo yojson xmlm ounit lwt_react ocurl obus lablgtk
lwt_glib sha dune
RUN sudo sudo sed -i -e 's/v[[:digit:]]\..*\//edge\//g' /etc/apk/repositories
RUN sudo apk add --no-cache curl-static openssl-libs-static
zlib-static nghttp2-static
COPY 0install.opam /src/
WORKDIR /src
RUN opam install --deps-only .
COPY --chown=opam:opam . /src/
RUN sudo chown opam /src
RUN echo "(lang dune 1.11)" > dune-workspace
RUN echo "(env (_ (flags -cclib -static -cclib -lssl -cclib -lcrypto
-cclib -lz -cclib -lnghttp2)))" >> dune-workspace
RUN opam exec -- make all
RUN strip /src/dist/files/0install
#RUN opam exec -- make test

FROM alpine:3.10
RUN apk add --no-cache unzip gnupg ca-certificates
COPY --from=build /src/dist/files/0install /usr/bin/0install

You don't get the GTK plugin though, because it uses dynamic linking to load it.


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

[Zero-install-devel] Feature proposal: Build Docker images with 0install

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

I would like to propose a small addition to 0install that I believe would
work great with Docker multi-stage builds
(https://docs.docker.com/develop/develop-images/multistage-build/).

A new command-line options for the "0install run" command, called something
like --print-script:
Everything runs as usual (select, download, etc.) right up until the point
where the target application would be executed. Now instead an equivalent
shell script is printed to stdout.
Basically this would mean encoding and printing the output get_exec_args
(https://github.com/0install/0install/blob/master/ocaml/zeroinstall/exec.ml#
L109) like this:
#!/bin/sh
VAR1=/root/.cache/0install.net/implementations/sha256_ABC123
/root/.cache/0install.net/implementations/sha256_DEF456/myapp

With this feature it would now be possible to use 0install to download an
app and its dependencies in Docker but then use that app without having to
include 0install in the final image:

FROM some-image-with-0install as builder
RUN 0install run --print-shell http://example.com/feed.xml > /app
RUN chmod +x /app
FROM debian
COPY --from=builder /root/.cache/0install.net /root/.cache/0install.net
COPY --from=builder /app /app
ENTRYPOINT ["./app"]

Another usecase for this would be sandbox tools. For example:
The new Windows Sandbox feature in Windows 10 automatically creates
light-weight throw-away VMs for testing untrusted software. Zero Install
could resolve and download dependencies outside of the sandbox and then
mount the implementation cache directory and a (Windows) shell script into
the sandbox VM.

Re: [Zero-install-devel] Proposal: apps.0install.net

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

On Sun, 17 Nov 2019 at 14:52, Bastian Eicher <ba...@ei...> wrote:
>
> >> Hi all,
> >>
> >> I would like to propose a new feed repository named apps.0install.net
> >> which would unify the contents from repo.roscidus.com and
> 0install.de/feeds.
> >>
> >> By creating a new repository with a new domain we could:
> >> - Switch to HTTPS URLs. Not strictly necessary due to 0install's GPG
> >> signature checks but makes feed URLs look more trustworthy, especially
> >> when viewed in a browser.
> >> - Use URLs ending in .xml. This would allow use to use GitHub Pages
> >> for hosting rather than requiring hosting with .htaccess support.
> >> - Fit in nicely with the naming of docs.0install.net. Using a
> >> 0install.net subdomain could also help make the feed URLs somewhat easier
> to memorize.
> >>
> >> We could leave all the old feeds in place but replace their content
> >> with forwarding/redirects like this: <feed
> >> src="https://apps.0install.net/category/feed.xml"/>
> >
> >That might cause problems if a program ends up depending on the same
> library by two different paths.
> >Might be better to use <replaced-by>.
>
> The disadvantage of <replaced-by> is that users that have added a feed using
> "0install add" most likely will never notice this change and would then stop
> getting automatic updates.
>
> Perhaps we could use <replaced-by> for anything that is "library-like" and
> <feed> for anything that is "app-like"?

I guess we could use <replaced-by> in all cases, and do the <feed>
thing too for applications.


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

[Zero-install-devel] Generic binaries depending on libcurl3

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

The generic Linux binaries for 0install
(https://0install.net/injector.html#linux-generic) depend on libcurl3.
However, this library is no longer available in Debian starting with Buster
or Ubuntu starting with 18.10.

Installing the suggested replacement library libcurl4 results in:
0install: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3'
not found (required by 0install)

Maybe we should look back into possibilities for statically linking
0install's dependencies?

Re: [Zero-install-devel] Proposal: apps.0install.net

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

>> Hi all,
>>
>> I would like to propose a new feed repository named apps.0install.net 
>> which would unify the contents from repo.roscidus.com and
0install.de/feeds.
>>
>> By creating a new repository with a new domain we could:
>> - Switch to HTTPS URLs. Not strictly necessary due to 0install's GPG 
>> signature checks but makes feed URLs look more trustworthy, especially 
>> when viewed in a browser.
>> - Use URLs ending in .xml. This would allow use to use GitHub Pages 
>> for hosting rather than requiring hosting with .htaccess support.
>> - Fit in nicely with the naming of docs.0install.net. Using a 
>> 0install.net subdomain could also help make the feed URLs somewhat easier
to memorize.
>>
>> We could leave all the old feeds in place but replace their content 
>> with forwarding/redirects like this: <feed 
>> src="https://apps.0install.net/category/feed.xml"/>
>
>That might cause problems if a program ends up depending on the same
library by two different paths.
>Might be better to use <replaced-by>.

The disadvantage of <replaced-by> is that users that have added a feed using
"0install add" most likely will never notice this change and would then stop
getting automatic updates.

Perhaps we could use <replaced-by> for anything that is "library-like" and
<feed> for anything that is "app-like"?

Re: [Zero-install-devel] Proposal: apps.0install.net

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

On Sun, 10 Nov 2019 at 13:10, Bastian Eicher <ba...@ei...> wrote:
>
> Hi all,
>
> I would like to propose a new feed repository named apps.0install.net which
> would unify the contents from repo.roscidus.com and 0install.de/feeds.
>
> By creating a new repository with a new domain we could:
> - Switch to HTTPS URLs. Not strictly necessary due to 0install's GPG
> signature checks but makes feed URLs look more trustworthy, especially when
> viewed in a browser.
> - Use URLs ending in .xml. This would allow use to use GitHub Pages for
> hosting rather than requiring hosting with .htaccess support.
> - Fit in nicely with the naming of docs.0install.net. Using a 0install.net
> subdomain could also help make the feed URLs somewhat easier to memorize.
>
> We could leave all the old feeds in place but replace their content with
> forwarding/redirects like this: <feed
> src="https://apps.0install.net/category/feed.xml"/>

That might cause problems if a program ends up depending on the same
library by two different paths.
Might be better to use <replaced-by>.

> What do you think? Is this a sensible approach?

Sounds good to me. repo.roscidus.com was only supposed to be a
temporary name anyway:

https://sourceforge.net/p/zero-install/mailman/message/23890186/

> Is apps.0install.net a good name for this, or perhaps hub.0install.net or repo.0install.net?

Any of these is fine with me!


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

[Zero-install-devel] Proposal: apps.0install.net

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

Hi all,

I would like to propose a new feed repository named apps.0install.net which
would unify the contents from repo.roscidus.com and 0install.de/feeds.

By creating a new repository with a new domain we could:
- Switch to HTTPS URLs. Not strictly necessary due to 0install's GPG
signature checks but makes feed URLs look more trustworthy, especially when
viewed in a browser.
- Use URLs ending in .xml. This would allow use to use GitHub Pages for
hosting rather than requiring hosting with .htaccess support.
- Fit in nicely with the naming of docs.0install.net. Using a 0install.net
subdomain could also help make the feed URLs somewhat easier to memorize.

We could leave all the old feeds in place but replace their content with
forwarding/redirects like this: <feed
src="https://apps.0install.net/category/feed.xml"/>

What do you think? Is this a sensible approach? Is apps.0install.net a good
name for this, or perhaps hub.0install.net or repo.0install.net?

Regards
Bastian

Re: [Zero-install-devel] 0install website concept

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

On Sat, 19 Oct 2019 at 17:46, Bastian Eicher <ba...@ei...> wrote:
>
> Hello all,
>
> I've been playing around with some ideas for a Bootstrap-based redesign of
> 0install.net. You can see a sample of this here:
> https://0install.de/concept/
>
> Happy to hear your feedback, impressions, suggestions, etc..

I like this general direction. The old site was a bit of a mess, with
lots of old links that just redirected to the docs site. This looks
much cleaner!

The Debian and Arch download instructions should be brought back
though - those platforms are both still fairly up-to-date. Also, the
Generic download instructions appear to be Debian-specific. And there
should probably be an "Other" tab, after Linux, Windows and macOS,
linking to the source code.

And maybe put the GitHub link back in somewhere?


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

[Zero-install-devel] 0install website concept

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

Hello all,

I've been playing around with some ideas for a Bootstrap-based redesign of
0install.net. You can see a sample of this here:
https://0install.de/concept/

Happy to hear your feedback, impressions, suggestions, etc..

Regards
Bastian

[Zero-install-devel] 0release 0.16

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

0release 0.16 released:

  https://docs.0install.net/tools/0release/

0release automates the process of creating new software releases. It
handles details such as setting the version number and release date,
tagging the release in your version control system and updating your
feed.

Changes since 0.15:

New features

- Now works on Windows (Bastian Eicher).

- Add <release:update-version>. This is an easier way to update version
  numbers, and is more portable as you don't need "sed". Just pass the file to
  update and a regular expression matching the version assignment. The first
  match group will be replaced with the version. Example:

  <release:update-version path='main.py'>^version =
'(.*)'$</release:update-version>

  Note: this also sets a "-post" version after the commit, which wasn't
  previously possible.

Updates

- Remove support for releasing without 0repo and create a 0repo-compatible
  configuration by default. This is much simpler.

- Rename environment variables for newer shells. Newer shells silently remove
  variables with names beginning with '0'.

Improved messages

- Better error when feed has wrong prefix.

- Print a warning if not releasing from the master branch.

- Suggest providing a "test" command, not the old self-test attribute.

Unit-tests

- Remove example hooks from .git directories in unit-tests. Recent versions of
  Git warn about these files.

- Add Travis tests.


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