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

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

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

> OK, I've updated the published 0compile feed to give the direct
dependency.
Thanks. Seems to be working fine now.

> However, I think it's a bad idea in general to prefer older versions just
> because their dependencies are easier to install.
> Newer versions tend to have more dependencies than older versions, so this
> could easily lead to getting stuck on old versions of software if they add
> a 32-bit-only dependency at some point.
I agree. I'll try to get this behavior changed in the C# version soon.

> For reference, the order used by the OCaml version is here:
> [...]
> score_machine (which prefers 64-bit binaries) is one of the last things it
> considers.
>
> Once the solver has the 0compile implementations ordered by preference, it
> will work down the list. e.g. if it decides that 0compile 1.4 is better
than
> 1.3 (which it will by default), then it will only install 1.3 if there is
no
> way to get 1.4.
I actually modeled this part of the C# solver very closely upon the existing
Python/OCaml code. Here you can see that the ordering logic is basically the
same:
https://github.com/0install/0install-dotnet/blob/master/src/Services/Solvers
/SelectionCandidateComparer.cs

However, rather than treating AMD64 as a superset of x86 and then forbidding
the mixing of AMD64 and x86 in a single selection, the C# implementation
simply treats AMD64 and x86 as incompatible and solves for them separately.
This is what I'll probably need to change.

> Is there some complexity threshold where it decides the cost of spawning a
> subprocess is worth it to get the faster solver, and switches over?
Yes. Once the backtracking solver has tried a certain number of
implementation candidates for a single interface it gives up.
This number is currently 32 (chosen somewhat arbitrarily).

There is an additional "cost" to switching over to the OCaml solver, since
it currently does not support HTTPS on Windows. So if it attempts to use any
HTTPS-served feed that the C# solver did not already cache, it will fail.

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

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

On Fri, 30 Nov 2018 at 21:25, Bastian Eicher <ba...@ei...> wrote:
>
> Hi guys,
>
> the C# solver always tries to find a 64-bit solution first when running on a
> 64-bit system and only considers 32-bit solutions if that fails.
> http://repo.roscidus.com/python/python-gobject only has an i486 build for
> Windows. Therefore it cannot be part of a valid 64-bit selection.
> http://0install.net/2007/interfaces/ZeroInstall.xml still lists some
> versions without a dependency on python-gobject, e.g. 1.14.
> Therefore the solver will prefer to use this old version of Zero Install
> rather than falling back to i486 for the entire selection and thus end up
> still providing a solution leading to "No module named gobject".

OK, I've updated the published 0compile feed to give the direct dependency.

However, I think it's a bad idea in general to prefer older versions
just because their dependencies are easier to install.
Newer versions tend to have more dependencies than older versions, so
this could easily lead to getting stuck on old versions of software if
they add a 32-bit-only dependency at some point.

For reference, the order used by the OCaml version is here:

https://github.com/0install/0install/blob/dca085e7211332fa19016a69240e331e79dcde00/ocaml/zeroinstall/impl_provider.ml#L169

score_machine (which prefers 64-bit binaries) is one of the last
things it considers.

Once the solver has the 0compile implementations ordered by
preference, it will work down the list. e.g. if it decides that
0compile 1.4 is better than 1.3 (which it will by default), then it
will only install 1.3 if there is no way to get 1.4.

> Since the C# solver uses simple backtracking rather than a SAT solver, it
> takes quite some time to find this solution.

Is there some complexity threshold where it decides the cost of
spawning a subprocess is worth it to get the faster solver, and
switches over?

> The following works on Windows and only takes a few moments:
> > 0install run --cpu=i486 http://0install.net/2006/interfaces/0compile.xml
>
> @Thomas: If you could add the python-gobject dependency to the remaining
> implementations in the ZeroInstall feed I believe it would prevent this
> issue.
> However, the solver would probably still take a long time until it realizes
> it has to down 32-bit lane.
> In order to speed up the process I suppose we should also add the
> python-gobject dependency directly to the 0compile feed.

Done.

> Further down the road, I have some optimizations for the C# solver planned,
> as time permits.


-- 
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 0compile on windows .

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

Hi guys,

the C# solver always tries to find a 64-bit solution first when running on a
64-bit system and only considers 32-bit solutions if that fails.
http://repo.roscidus.com/python/python-gobject only has an i486 build for
Windows. Therefore it cannot be part of a valid 64-bit selection.
http://0install.net/2007/interfaces/ZeroInstall.xml still lists some
versions without a dependency on python-gobject, e.g. 1.14.
Therefore the solver will prefer to use this old version of Zero Install
rather than falling back to i486 for the entire selection and thus end up
still providing a solution leading to "No module named gobject".
Since the C# solver uses simple backtracking rather than a SAT solver, it
takes quite some time to find this solution.

The following works on Windows and only takes a few moments:
> 0install run --cpu=i486 http://0install.net/2006/interfaces/0compile.xml

@Thomas: If you could add the python-gobject dependency to the remaining
implementations in the ZeroInstall feed I believe it would prevent this
issue.
However, the solver would probably still take a long time until it realizes
it has to down 32-bit lane.
In order to speed up the process I suppose we should also add the
python-gobject dependency directly to the 0compile feed.

Further down the road, I have some optimizations for the C# solver planned,
as time permits.

Regards
Bastian


-----Original Message-----
From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> 
Sent: Freitag, 30. November 2018 19:55
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] can't run 0compile on windows .

Thomas 
	It is falling back to the ocaml solver according the the -vv logging
Specifying the version selects quite a bit faster

ptime 0install select http://0install.net/2006/interfaces/0compile.xml
--os=Windows --version-for http://0install.net/2006/interfaces/0compile.xml
1.4

ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jb...@pc...>

=== 0install select http://0install.net/2006/interfaces/0compile.xml
--os=Windows --version-for http://0install.net/2006/interfaces/0compile.xml
1.4 ===
- URI: http://0install.net/2006/interfaces/0compile.xml
  Version: 1.4
  Path:
C:\ProgramData\0install.net\implementations\sha256new_DRI2B34BA24I5WP4NJCHZ6
F2RU6ZDGRULN4WEUZNLYX6RW6BAN2A
  - URI: http://0install.net/2006/interfaces/0publish
    Version: 0.25
    Path:
C:\ProgramData\0install.net\implementations\sha256new_AK4BBYGWE3AIITVH3POX2B
MQLK4BLDE2ZUOAFAGC5NBRHSZ2MKMA
    - URI: http:// repo.roscidus.com/security/gnupg
      Version: 1.4.22
      Path:
C:\ProgramData\0install.net\implementations\sha256new_25VZHECYKPTOHKWZVR6Q6Z
FW2F362QKJYXGELIWY5VKTY7QQWOKQ
    - URI: http://0install.net/2007/interfaces/ZeroInstall.xml
      Version: 2.3.5
      Path:
C:\ProgramData\0install.net\implementations\sha256new_WJTXRQOJFWFYBVFWITHSXE
PGWXBX5YTSQXVT5DUT7RMUTIH6ETYQ
      - URI: http://repo.roscidus.com/python/python-gobject
        Version: 2.28.3
        Path:
C:\ProgramData\0install.net\implementations\sha256new_GTWVISPUFHUCTTJGWC5PW2
NYRWGSVES4HBRZ5O3H4K22S4UT5X4Q
        - URI: http://repo.roscidus.com/lib/glib
          Version: 2.24.10
          Path:
C:\ProgramData\0install.net\implementations\sha256new_V36BMVEDEIGK2IR5KESEYL
QUQZ3SKXWUIEDJTBWO252O56RGUOVA
      - URI: http://0install.net/2012/interfaces/0install-runenv-cli.xml
        Version: 2.0.2
        Path:
C:\ProgramData\0install.net\implementations\sha256new_XMEYQHKYT7CNDYAWDQHGDI
DJK2QORBV5KRFQX6BQ7RNXTANR6PGQ
      - URI: http://repo.roscidus.com/python/python
        Version: 2.7.15
        Path:
C:\ProgramData\0install.net\implementations\sha256new_P3LD6BDLOWLCKSEHYQJABS
454FN6GKJC455VK6HYMVT5IBOMJDXA
        - URI: http://repo.roscidus.com/python/python-win32
          Version: 220
          Path:
C:\ProgramData\0install.net\implementations\sha256new_CCWSRVUMZLIYN2ZTLIBLH3
D7DNMATOHTSYQG7MCRTANIZ7PGA7YA
  - URI: http://repo.roscidus.com/utils/bash
    Version: 0.6
    Path:
C:\ProgramData\0install.net\implementations\sha1new=624fe11b4b9f88c1087ed915
e2c66b07edaf62dd

Execution time: 44.652 s

It takes 137 seconds without the version

Even with the version though it still fails the same way 

0install run http://0install.net/2006/interfaces/0compile.xml --version-for
http://0install.net/2006/interfaces/0compile.xml 1.4 Traceback (most recent
call last):
  File
"C:\ProgramData\0install.net\implementations\sha256new_JVBP6RCR3JVWBOBYLB7HO
YFDV2FXGMUPDW4GCMZY7U2KHVUFFWYA\0compile", line 11, in <module>
    import gobject; gobject.threads_init()
ImportError: No module named gobject

Phil

_______________________________________________
Zero-install-devel mailing list
Zer...@li...
https://lists.sourceforge.net/lists/listinfo/zero-install-devel

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

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

Thomas 
	It is falling back to the ocaml solver according the the -vv logging 
Specifying the version selects quite a bit faster

ptime 0install select http://0install.net/2006/interfaces/0compile.xml --os=Windows --version-for http://0install.net/2006/interfaces/0compile.xml 1.4

ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
Copyright(C) 2002, Jem Berkes <jb...@pc...>

=== 0install select http://0install.net/2006/interfaces/0compile.xml --os=Windows --version-for http://0install.net/2006/interfaces/0compile.xml 1.4 ===
- URI: http://0install.net/2006/interfaces/0compile.xml
  Version: 1.4
  Path: C:\ProgramData\0install.net\implementations\sha256new_DRI2B34BA24I5WP4NJCHZ6F2RU6ZDGRULN4WEUZNLYX6RW6BAN2A
  - URI: http://0install.net/2006/interfaces/0publish
    Version: 0.25
    Path: C:\ProgramData\0install.net\implementations\sha256new_AK4BBYGWE3AIITVH3POX2BMQLK4BLDE2ZUOAFAGC5NBRHSZ2MKMA
    - URI: http:// repo.roscidus.com/security/gnupg
      Version: 1.4.22
      Path: C:\ProgramData\0install.net\implementations\sha256new_25VZHECYKPTOHKWZVR6Q6ZFW2F362QKJYXGELIWY5VKTY7QQWOKQ
    - URI: http://0install.net/2007/interfaces/ZeroInstall.xml
      Version: 2.3.5
      Path: C:\ProgramData\0install.net\implementations\sha256new_WJTXRQOJFWFYBVFWITHSXEPGWXBX5YTSQXVT5DUT7RMUTIH6ETYQ
      - URI: http://repo.roscidus.com/python/python-gobject
        Version: 2.28.3
        Path: C:\ProgramData\0install.net\implementations\sha256new_GTWVISPUFHUCTTJGWC5PW2NYRWGSVES4HBRZ5O3H4K22S4UT5X4Q
        - URI: http://repo.roscidus.com/lib/glib
          Version: 2.24.10
          Path: C:\ProgramData\0install.net\implementations\sha256new_V36BMVEDEIGK2IR5KESEYLQUQZ3SKXWUIEDJTBWO252O56RGUOVA
      - URI: http://0install.net/2012/interfaces/0install-runenv-cli.xml
        Version: 2.0.2
        Path: C:\ProgramData\0install.net\implementations\sha256new_XMEYQHKYT7CNDYAWDQHGDIDJK2QORBV5KRFQX6BQ7RNXTANR6PGQ
      - URI: http://repo.roscidus.com/python/python
        Version: 2.7.15
        Path: C:\ProgramData\0install.net\implementations\sha256new_P3LD6BDLOWLCKSEHYQJABS454FN6GKJC455VK6HYMVT5IBOMJDXA
        - URI: http://repo.roscidus.com/python/python-win32
          Version: 220
          Path: C:\ProgramData\0install.net\implementations\sha256new_CCWSRVUMZLIYN2ZTLIBLH3D7DNMATOHTSYQG7MCRTANIZ7PGA7YA
  - URI: http://repo.roscidus.com/utils/bash
    Version: 0.6
    Path: C:\ProgramData\0install.net\implementations\sha1new=624fe11b4b9f88c1087ed915e2c66b07edaf62dd

Execution time: 44.652 s

It takes 137 seconds without the version

Even with the version though it still fails the same way 

0install run http://0install.net/2006/interfaces/0compile.xml --version-for http://0install.net/2006/interfaces/0compile.xml 1.4
Traceback (most recent call last):
  File "C:\ProgramData\0install.net\implementations\sha256new_JVBP6RCR3JVWBOBYLB7HOYFDV2FXGMUPDW4GCMZY7U2KHVUFFWYA\0compile", line 11, in <module>
    import gobject; gobject.threads_init()
ImportError: No module named gobject

Phil

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

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

On Fri, 30 Nov 2018 at 16:55, Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> wrote:
>
> Bastian,
>
> This doesn’t seem to have worked. And its lowed things down quite a bit.
>
> Now when I run
>
> 0install select -r http://0install.net/2006/interfaces/0compile.xml
>
>
>
> After a couple minutes I get the following
>
> - URI: http://0install.net/2006/interfaces/0compile.xml
>
>   Version: 1.0
>
>   (not cached)
>
>   - URI: http://0install.net/2007/interfaces/ZeroInstall.xml
>
>     Version: 1.14
>
>     (not cached)
>
>     - URI: http://0install.net/2012/interfaces/0install-runenv-cli.xml
>
>       Version: 2.0.2
>
>       Path: C:\ProgramData\0install.net\implementations\sha256new_XMEYQHKYT7CNDYAWDQHGDIDJK2QORBV5KRFQX6BQ7RNXTANR6PGQ
>
>     - URI: http://repo.roscidus.com/security/gnupg
>
>       Version: 1.4.22
>
>       Path: C:\ProgramData\0install.net\implementations\sha256new_25VZHECYKPTOHKWZVR6Q6ZFW2F362QKJYXGELIWY5VKTY7QQWOKQ
>
>   - URI: http://0install.net/2006/interfaces/0publish
>
>     Version: 0.25
>
>     Path: C:\ProgramData\0install.net\implementations\sha256new_AK4BBYGWE3AIITVH3POX2BMQLK4BLDE2ZUOAFAGC5NBRHSZ2MKMA
>
>   - URI: http://repo.roscidus.com/python/python
>
>     Version: 2.7.15
>
>     Path: C:\ProgramData\0install.net\implementations\sha256new_HBTOKP5QXXPXN2KSRSNA6DCZBXFCWCLW2GPKUV3XDLGXCZNCFREA
>
>     - URI: http://repo.roscidus.com/python/python-gobject
>
>       No selected version
>
>     - URI: http://repo.roscidus.com/python/python-win32
>
>       Version: 220
>
>       Path: C:\ProgramData\0install.net\implementations\sha256new_WQPHLXUMHKIIAD372XTVT5S6UGX67HCUEU2T7IPUZCM7G44MMP2Q

Is this using the OCaml solver, or some C# code? On Linux but with
--os=Windows, I get:

# time 0install select
http://0install.net/2006/interfaces/0compile.xml --os=Windows
- URI: http://0install.net/2006/interfaces/0compile.xml
  Version: 1.4
  Path: (not cached)

  - URI: http://repo.roscidus.com/python/python
    Version: 2.7.15
    Path: (not cached)

    - URI: http://repo.roscidus.com/python/python-win32
      Version: 220
      Path: (not cached)

    - URI: http://repo.roscidus.com/python/python-gobject
      Version: 2.28.3
      Path: (not cached)

      - URI: http://repo.roscidus.com/lib/glib
        Version: 2.24.10
        Path: (not cached)

  - URI: http://0install.net/2006/interfaces/0publish
    Version: 0.25
    Path: (not cached)

    - URI: http://0install.net/2007/interfaces/ZeroInstall.xml
      Version: 2.3.5
      Path: (not cached)

      - URI: http://repo.roscidus.com/security/gnupg
        Version: 1.4.22
        Path: (not cached)

      - URI: http://0install.net/2012/interfaces/0install-runenv-cli.xml
        Version: 2.0.2
        Path: (not cached)

  - URI: http://repo.roscidus.com/utils/bash
    Version: 0.6
    Path: (not cached)

real    0m0.036s
user    0m0.027s
sys    0m0.009s

You could try forcing it to use the same version as I got, with:

0install select http://0install.net/2006/interfaces/0compile.xml
--os=Windows --version-for
http://0install.net/2006/interfaces/0compile.xml 1.4

That might tell you why it picked version 1.0 instead.


-- 
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 0compile on windows .

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

Bastian,
This doesn't seem to have worked. And its lowed things down quite a bit.
Now when I run
0install select -r http://0install.net/2006/interfaces/0compile.xml

After a couple minutes I get the following
- URI: http://0install.net/2006/interfaces/0compile.xml
  Version: 1.0
  (not cached)
  - URI: http://0install.net/2007/interfaces/ZeroInstall.xml
    Version: 1.14
    (not cached)
    - URI: http://0install.net/2012/interfaces/0install-runenv-cli.xml
      Version: 2.0.2
      Path: C:\ProgramData\0install.net\implementations\sha256new_XMEYQHKYT7CNDYAWDQHGDIDJK2QORBV5KRFQX6BQ7RNXTANR6PGQ
    - URI: http://repo.roscidus.com/security/gnupg
      Version: 1.4.22
      Path: C:\ProgramData\0install.net\implementations\sha256new_25VZHECYKPTOHKWZVR6Q6ZFW2F362QKJYXGELIWY5VKTY7QQWOKQ
  - URI: http://0install.net/2006/interfaces/0publish
    Version: 0.25
    Path: C:\ProgramData\0install.net\implementations\sha256new_AK4BBYGWE3AIITVH3POX2BMQLK4BLDE2ZUOAFAGC5NBRHSZ2MKMA
  - URI: http://repo.roscidus.com/python/python
    Version: 2.7.15
    Path: C:\ProgramData\0install.net\implementations\sha256new_HBTOKP5QXXPXN2KSRSNA6DCZBXFCWCLW2GPKUV3XDLGXCZNCFREA
    - URI: http://repo.roscidus.com/python/python-gobject
      No selected version
    - URI: http://repo.roscidus.com/python/python-win32
      Version: 220
      Path: C:\ProgramData\0install.net\implementations\sha256new_WQPHLXUMHKIIAD372XTVT5S6UGX67HCUEU2T7IPUZCM7G44MMP2Q

0install run http://0install.net/2006/interfaces/0compile.xml
After a couple minutes I get the following
Downloading http://0install.net/2006/interfaces/0compile.xml...
[====================] Complete
Downloading http://0install.net/2006/interfaces/0publish...
[====================] Complete
Downloading http://0install.net/2007/interfaces/ZeroInstall.xml...
[====================] Complete
Downloading http://repo.roscidus.com/utils/bash...
[====================] Complete
Downloading http://repo.roscidus.com/python/python...
[====================] Complete
Downloading http://repo.roscidus.com/python/python/upstream.xml...
[====================] Complete
Downloading http://repo.roscidus.com/security/gnupg...
[====================] Complete
Downloading http://repo.roscidus.com/python/python-gobject...
[====================] Complete
Downloading http://0install.net/2012/interfaces/0install-runenv-cli.xml...
[====================] Complete
Downloading http://repo.roscidus.com/python/python-win32...
[====================] Complete
Traceback (most recent call last):
  File "C:\ProgramData\0install.net\implementations\sha256new_JVBP6RCR3JVWBOBYLB7HOYFDV2FXGMUPDW4GCMZY7U2KHVUFFWYA\0compile", line 11, in <module>
    import gobject; gobject.threads_init()
ImportError: No module named gobject

My local copy of the feed with the change I suggest still works

Phil

From: Bastian Eicher [mailto:ba...@ei...]
Sent: Friday, November 23, 2018 5:07 PM
To: 'The Zero Install system' <zer...@li...>
Subject: Re: [Zero-install-devel] can't run 0compile on windows .

Hi Philip,

thanks for reporting this. I've prepared a change to the python-gobject feed that should fix this: https://github.com/0install/repo.roscidus.com/pull/103<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0install_repo.roscidus.com_pull_103&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=8O76TB7jX0ePsbbpWCtnsCbCoOVbgF4d38HNm-ysNb4&s=sqRU37nBIWTuVozar5hmcBEubj6Hyhoyp6kX3d_YwV0&e=>

Regards
Bastian

From: Miess, Philip (TR Tech, Content & Ops) <phi...@th...<mailto:phi...@th...>>
Sent: Montag, 19. November 2018 22:51
To: The Zero Install system <zer...@li...<mailto:zer...@li...>>
Subject: [Zero-install-devel] can't run 0compile on windows .

0install team
        FYI when I run 0compile on windows I get an error

C:\zeroinstall>0install run http://0install.net/2006/interfaces/0compile.xml<https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_2006_interfaces_0compile.xml&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=8O76TB7jX0ePsbbpWCtnsCbCoOVbgF4d38HNm-ysNb4&s=wLC4h_LtIvgPttzjy6SEzCQkT00OXtr31ImlGEvl-GM&e=>
Traceback (most recent call last):
  File "C:\ProgramData\0install.net\implementations\sha256new_DRI2B34BA24I5WP4NJCHZ6F2RU6ZDGRULN4WEUZNLYX6RW6BAN2A\0compile", line 11, in <module>
    import gobject; gobject.threads_init()
ImportError: No module named gobject

If I add the following dependency it works.

      <requires interface="http://repo.roscidus.com/lib/gtk<https://urldefense.proofpoint.com/v2/url?u=http-3A__repo.roscidus.com_lib_gtk&d=DwMFAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=8O76TB7jX0ePsbbpWCtnsCbCoOVbgF4d38HNm-ysNb4&s=h-JaiMWMFXkX_rva49ZuUBHjwwkhs3IlOGGrXLdbSFM&e=>">
        <environment insert="bin" name="PATH"/>
      </requires>

This is what we did for diffuse when it needed GTK for python-gtk.



Philip Miess
Sr. Software Test Engineer
Phone: (585) 327-6195
phi...@th...<mailto:phi...@th...>
50 Broad Street
Rochester, NY 14694

Re: [Zero-install-devel] Statically linked build of 0install

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

On Mon, 19 Nov 2018 at 16:57, Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> wrote:
>
> FYI I have a couple FTP archives that I set up this year
>
> https://pmiess.gitlab.io/0install-feeds/netcdf.xml
> FTP site is the first of three alternatives
> Used by gnuwin32 gri
>
> And
> https://pmiess.gitlab.io/0install-feeds/pthreads-win32.xml
> Only ftp archive so the change will break this feed.
> There are some linked http mirrors on the homepage I could set up to fix it.
> Used by gnuwin32 chess
>
> So I would need to modify 1 feed to handle this change, and should modify one more to remove the ftp archive if it's not allowed.
>
> Personally I'd prefer to keep ftp, that way if an archive is only available via ftp I don't have to mirror the archive (and source to comply with GPL), but if it becomes necessary I think I can do so on GitLab, since I only publish open source packages.

I guess implementing a simple passive get using ftp should be fairly
easy. There's a single-threaded library at
http://opam.ocaml.org/packages/ftp/ which could be a starting point.


-- 
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 0compile on windows .

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

Hi Philip,

 

thanks for reporting this. I've prepared a change to the python-gobject feed
that should fix this: https://github.com/0install/repo.roscidus.com/pull/103

 

Regards

Bastian

 

From: Miess, Philip (TR Tech, Content & Ops)
<phi...@th...> 
Sent: Montag, 19. November 2018 22:51
To: The Zero Install system <zer...@li...>
Subject: [Zero-install-devel] can't run 0compile on windows .

 

0install team

        FYI when I run 0compile on windows I get an error

 

C:\zeroinstall>0install run http://0install.net/2006/interfaces/0compile.xml

Traceback (most recent call last):

  File
"C:\ProgramData\0install.net\implementations\sha256new_DRI2B34BA24I5WP4NJCHZ
6F2RU6ZDGRULN4WEUZNLYX6RW6BAN2A\0compile", line 11, in <module>

    import gobject; gobject.threads_init()

ImportError: No module named gobject

 

If I add the following dependency it works.

 

      <requires interface="http://repo.roscidus.com/lib/gtk">

        <environment insert="bin" name="PATH"/>

      </requires>

 

This is what we did for diffuse when it needed GTK for python-gtk.

 

 

 

Philip Miess
Sr. Software Test Engineer

Phone: (585) 327-6195

 <mailto:phi...@th...> phi...@th...

50 Broad Street

Rochester, NY 14694

 

 

 

[Zero-install-devel] can’t run 0compile on windows .

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

0install team
        FYI when I run 0compile on windows I get an error

C:\zeroinstall>0install run http://0install.net/2006/interfaces/0compile.xml
Traceback (most recent call last):
  File "C:\ProgramData\0install.net\implementations\sha256new_DRI2B34BA24I5WP4NJCHZ6F2RU6ZDGRULN4WEUZNLYX6RW6BAN2A\0compile", line 11, in <module>
    import gobject; gobject.threads_init()
ImportError: No module named gobject

If I add the following dependency it works.

      <requires interface="http://repo.roscidus.com/lib/gtk">
        <environment insert="bin" name="PATH"/>
      </requires>

This is what we did for diffuse when it needed GTK for python-gtk.



Philip Miess
Sr. Software Test Engineer

Phone: (585) 327-6195
phi...@th...<mailto:phi...@th...>
50 Broad Street
Rochester, NY 14694

Re: [Zero-install-devel] Statically linked build of 0install

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

FYI I have a couple FTP archives that I set up this year

https://pmiess.gitlab.io/0install-feeds/netcdf.xml
FTP site is the first of three alternatives
Used by gnuwin32 gri

And 
https://pmiess.gitlab.io/0install-feeds/pthreads-win32.xml
Only ftp archive so the change will break this feed.
There are some linked http mirrors on the homepage I could set up to fix it.
Used by gnuwin32 chess

So I would need to modify 1 feed to handle this change, and should modify one more to remove the ftp archive if it's not allowed.

Personally I'd prefer to keep ftp, that way if an archive is only available via ftp I don't have to mirror the archive (and source to comply with GPL), but if it becomes necessary I think I can do so on GitLab, since I only publish open source packages.

Phil




-----Original Message-----
From: Thomas Leonard [mailto:ta...@gm...] 
Sent: Saturday, November 17, 2018 10:40 AM
To: The Zero Install system <zer...@li...>
Subject: Re: [Zero-install-devel] Statically linked build of 0install

In Tue, 30 Oct 2018 at 21:14, Thomas Leonard <ta...@gm...> wrote:
>
> On Sun, 28 Oct 2018 at 13:28, Bastian Eicher <ba...@ei...> wrote:
> >
> > Hi all,
> >
> > I've recently been experimenting with running 0install in Docker 
> > containers based on various Linux distributions. Since I wanted to 
> > use the latest version I downloaded the pre-built binaries listed here:
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__0install.net_too
> > ls_0install.xml&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwK
> > gY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83
> > jNJ6t2g1k7svk3tgyXo62kSh8U&s=DZZhOiCUEkSuprtBC2kaPUMEr7cx5wW0inM3Wum
> > 4NE4&e=
> >
> > On Debian Stable and Ubuntu 18.04 I simply had to run "apt-get 
> > install libcurl3", download and extract the 0install archive and was good to go.
> > However, on Debian Testing and Ubuntu 18.10 libcurl3 has been 
> > replaced with libcurl4. After installing this 0install fails to launch with:
> > "/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found"
> > Installing a libcurl3 package intended for an older distro also 
> > isn't a good option, since libcurl3 and libcurl4 both attempt to 
> > install the same file and therefore cannot co-exist on the same 
> > system. Forcibly downgrading libcurl also breaks the curl command on the system.
> > Running the binaries on Alpine is of course even trickier, since 
> > that distro does not use glibc.
> >
> > This got me thinking: Would it be practical to create completely 
> > statically linked builds of 0install? A quick Google search turned 
> > up a blog article titled "Creating Static Linux Binaries in OCaml"
> > (https://urldefense.proofpoint.com/v2/url?u=http-3A__rgrinberg.com_p
> > osts_static-2Dbinaries-2Dtutorial_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=fqc0y-j4tovnPxKpKyw3wqQcdh8XIczb6SlDw800gLA&e= ). Since I have no experience with OCaml yet, I'm not sure if this is applicable to 0install.
> > @Thomas: Could you perhaps take a quick look?
>
> Static linking libcurl itself probably isn't difficult (or we could 
> replace it with cohttp if we dropped FTP support; I guess no-one is 
> using FTP now anyway).

I checked the mirror for public feeds referencing FTP sites.
These FTP sites are still running and being used as the main download URL by their projects:

https://urldefense.proofpoint.com/v2/url?u=ftp-3A__xmlsoft.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=u3POzq-pj8Mtg_vyUiG635PXfT9JuDkz5CZkGilSnfg&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.alsa-2Dproject.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=IWcGdTU2mfzrKxS9txHapnwxYWgiz6hgy08B1lWOzGg&e= 

These FTP sites are used in some feeds, but there is an HTTP alternative:

https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.gnu.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=h97a_kbvNhv8ebhS5LlDbhSLue5eSK3KoG0hbo0dv1M&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.gmplib.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=uSbyxttOgklmRL8DtxJLJbod1erlEQM9LU31wXs-uWo&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.lyx.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=ZcOZlBudPxnHGRmvUiib8czTirar2Ud9sfSMeDDveUQ&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.gnome.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=VVEiTDzMsfWEVAyjrlcgBApXltIQIiqcefQuj8R4Z3I&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.vim.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=l1cUUtzj9qpfkugtudg-8pGY-Q-CMPtLF_Ldt8BVx68&e=
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.osuosl.org&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=kKibKMzzvLo-InqId-dUtPjvSdLNE2AWt_N-LTM4W44&e= 

We should probably start logging warnings about FTP sites. We could also drop support in the 0install client, and just copy the archives to the mirror service to avoid breaking anything.
Or just drop it anyway - no feed using FTP has been updated since Jan 2017.


-- 
talex5 (GitHub/Twitter)        https://urldefense.proofpoint.com/v2/url?u=http-3A__roscidus.com_blog_&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=BYnlU56oJNQ-MG_0emZjSZ-pgLygfHNWefRftp5poRs&e= 
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC


_______________________________________________
Zero-install-devel mailing list
Zer...@li...
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_zero-2Dinstall-2Ddevel&d=DwICAg&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=pRAqyHFQFv0HoEiWgk-8HFVA7XY6phT8Klx-jbb5O0E&m=7wEk3sGEPw1AT4P83jNJ6t2g1k7svk3tgyXo62kSh8U&s=Pc08KZhhc_H8bApp4InS-WBDV9RJVwfOl29-Mohm-Rs&e= 

Re: [Zero-install-devel] Statically linked build of 0install

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

In Tue, 30 Oct 2018 at 21:14, Thomas Leonard <ta...@gm...> wrote:
>
> On Sun, 28 Oct 2018 at 13:28, Bastian Eicher <ba...@ei...> wrote:
> >
> > Hi all,
> >
> > I've recently been experimenting with running 0install in Docker containers
> > based on various Linux distributions. Since I wanted to use the latest
> > version I downloaded the pre-built binaries listed here:
> > http://0install.net/tools/0install.xml
> >
> > On Debian Stable and Ubuntu 18.04 I simply had to run "apt-get install
> > libcurl3", download and extract the 0install archive and was good to go.
> > However, on Debian Testing and Ubuntu 18.10 libcurl3 has been replaced with
> > libcurl4. After installing this 0install fails to launch with:
> > "/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found"
> > Installing a libcurl3 package intended for an older distro also isn't a good
> > option, since libcurl3 and libcurl4 both attempt to install the same file
> > and therefore cannot co-exist on the same system. Forcibly downgrading
> > libcurl also breaks the curl command on the system.
> > Running the binaries on Alpine is of course even trickier, since that distro
> > does not use glibc.
> >
> > This got me thinking: Would it be practical to create completely statically
> > linked builds of 0install? A quick Google search turned up a blog article
> > titled "Creating Static Linux Binaries in OCaml"
> > (http://rgrinberg.com/posts/static-binaries-tutorial/). Since I have no
> > experience with OCaml yet, I'm not sure if this is applicable to 0install.
> > @Thomas: Could you perhaps take a quick look?
>
> Static linking libcurl itself probably isn't difficult (or we could
> replace it with cohttp if we dropped FTP support; I guess no-one is
> using FTP now anyway).

I checked the mirror for public feeds referencing FTP sites.
These FTP sites are still running and being used as the main download
URL by their projects:

ftp://xmlsoft.org
ftp://ftp.alsa-project.org

These FTP sites are used in some feeds, but there is an HTTP alternative:

ftp://ftp.gnu.org
ftp://ftp.gmplib.org
ftp://ftp.lyx.org
ftp://ftp.gnome.org
ftp://ftp.vim.org
ftp://ftp.osuosl.org

We should probably start logging warnings about FTP sites. We could
also drop support in the 0install client, and just copy the archives
to the mirror service to avoid breaking anything.
Or just drop it anyway - no feed using FTP has been updated since Jan 2017.


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

Re: [Zero-install-devel] dune

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

On Sun, 11 Nov 2018 at 21:35, <s4...@go...> wrote:

> "Dune is a build system designed for OCaml/Reason projects only. It
> focuses on providing the user with a consistent experience and takes
> care of most of the low-level details of OCaml compilation. All you have
> to do is provide a description of your project and dune will do the
> rest."

0install does not currently use Dune. However, I am working on moving
to it. It's a bit complicated because we currently support:

- local dev builds,
- opam builds,
- 0compile builds,
- various Linux distributions, and
- Windows builds,

all of which need some special cases. We also have C stubs (some
Windows only), and conditional compilation (obus, lablgtk), and
binaries build with GTK still need to work on systems without it.

If anyone wants to see the current state, it's here:

  https://github.com/talex5/0install/tree/dune

I'm currently trying to get the Windows build working, which is a bit
slow as I don't have a Windows machine and waiting for AppVeyor to
install things each time is quite tedious.


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

[Zero-install-devel] dune

[<s4...@go...>]

"Dune is a build system designed for OCaml/Reason projects only. It 
focuses on providing the user with a consistent experience and takes 
care of most of the low-level details of OCaml compilation. All you have 
to do is provide a description of your project and dune will do the 
rest."


this is the usual bullshit ppl are given these days.

all that dune will in fact do is break, freeze and crash of course.


why 0install uses this crap pgming language that no one has ever heard 
of ?

its a complete mess and unworkable structure.

Re: [Zero-install-devel] Statically linked build of 0install

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

> If we had a reliable way to find the distribution's CA certificates, we
could
> even replace openssl with ocaml-tls and avoid all these C problems
entirely.
Getting rid of C dependencies sounds great to me. :)
Go's crypto/x509 package seems to use a list of hard-coded paths to search
for
CA certificates:
https://golang.org/src/crypto/x509/root_unix.go
https://golang.org/src/crypto/x509/root_linux.go
Maybe this could be the way to go?

> Another option is to drop support for older Linux versions and just build
> against libcurl4 now.
Deciding between libcurl3 and libcurl4 seems difficult at this point in
time,
since most "mature" distros (e.g., Debian Stable, latest Ubuntu LTS) have
only
libcurl3 while many "popular" distros (e.g., latest Ubuntu) have only
libcurl4.

Re: [Zero-install-devel] Statically linked build of 0install

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

On Sun, 28 Oct 2018 at 13:28, Bastian Eicher <ba...@ei...> wrote:
>
> Hi all,
>
> I've recently been experimenting with running 0install in Docker containers
> based on various Linux distributions. Since I wanted to use the latest
> version I downloaded the pre-built binaries listed here:
> http://0install.net/tools/0install.xml
>
> On Debian Stable and Ubuntu 18.04 I simply had to run "apt-get install
> libcurl3", download and extract the 0install archive and was good to go.
> However, on Debian Testing and Ubuntu 18.10 libcurl3 has been replaced with
> libcurl4. After installing this 0install fails to launch with:
> "/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found"
> Installing a libcurl3 package intended for an older distro also isn't a good
> option, since libcurl3 and libcurl4 both attempt to install the same file
> and therefore cannot co-exist on the same system. Forcibly downgrading
> libcurl also breaks the curl command on the system.
> Running the binaries on Alpine is of course even trickier, since that distro
> does not use glibc.
>
> This got me thinking: Would it be practical to create completely statically
> linked builds of 0install? A quick Google search turned up a blog article
> titled "Creating Static Linux Binaries in OCaml"
> (http://rgrinberg.com/posts/static-binaries-tutorial/). Since I have no
> experience with OCaml yet, I'm not sure if this is applicable to 0install.
> @Thomas: Could you perhaps take a quick look?

Static linking libcurl itself probably isn't difficult (or we could
replace it with cohttp if we dropped FTP support; I guess no-one is
using FTP now anyway).

But curl depends on openssl, which I think has even more API problems.
And I guess that depends on the files in ca-certificates, which I seem
to recall each distribution puts in a slightly different location. So
it's quite likely that a static binary using openssl wouldn't work
properly on other distributions.

Technically, assuming the C stuff is set up, building a static binary
should just be a case of passing -static as a linker option, e.g. edit
ocaml/Makefile to use

OCAMLBUILD=ocamlbuild -lflag -ccopt -lflag -static ...

However, it appears that Alpine doesn't provide a static version of
libssl, so the link fails when using the Alpine Docker image, as
suggested in the blog post.

If we had a reliable way to find the distribution's CA certificates,
we could even replace openssl with ocaml-tls and avoid all these C
problems entirely.

Another option is to drop support for older Linux versions and just
build against libcurl4 now.


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

[Zero-install-devel] Statically linked build of 0install

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

Hi all,

I've recently been experimenting with running 0install in Docker containers
based on various Linux distributions. Since I wanted to use the latest
version I downloaded the pre-built binaries listed here:
http://0install.net/tools/0install.xml

On Debian Stable and Ubuntu 18.04 I simply had to run "apt-get install
libcurl3", download and extract the 0install archive and was good to go.
However, on Debian Testing and Ubuntu 18.10 libcurl3 has been replaced with
libcurl4. After installing this 0install fails to launch with:
"/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found"
Installing a libcurl3 package intended for an older distro also isn't a good
option, since libcurl3 and libcurl4 both attempt to install the same file
and therefore cannot co-exist on the same system. Forcibly downgrading
libcurl also breaks the curl command on the system.
Running the binaries on Alpine is of course even trickier, since that distro
does not use glibc.

This got me thinking: Would it be practical to create completely statically
linked builds of 0install? A quick Google search turned up a blog article
titled "Creating Static Linux Binaries in OCaml"
(http://rgrinberg.com/posts/static-binaries-tutorial/). Since I have no
experience with OCaml yet, I'm not sure if this is applicable to 0install.
@Thomas: Could you perhaps take a quick look?

It is somewhat common for Linux users to build applications from source if
they want a version newer than the one provided by their package manager.
However, I feel that a tool such as 0install, aiming at simplifying
acquiring software, should itself be as easy as possible to acquire. I
believe the interest in Linux binaries with zero runtime dependencies is
also demonstrated by popular statically linked Go binaries such as docker,
kubectl and terraform.

Regards
Bastian

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

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

> The non-folding menu is indeed a bit ugly. Maybe somebody can help out
there
> with a little JavaScript voodoo?
The menu now collapses and auto-scrolls to the current page.

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

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

> We could fix these issues by using GitHub Pages hosting instead of
> ReadTheDocs. The same setup used for https://github.com/0install/web-site
> should work here: Keep the sources on the "master" branch and put the
> generated HTML on "gh-pages".
Done. A Travis CI job now automatically builds and deploys the docs here:
https://0install.github.io/docs/

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

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

> The current site does indeed seem bad on mobile. Do people want to read it
on their phones?

I can't speak for anybody else but I have in fact done so on occasion. :D

> readthedocs seems a bit slow. Testing a refresh on one page at random:
> [...]
> It seems to add some tracking scripts and some adverts too :-/

We could fix these issues by using GitHub Pages hosting instead of
ReadTheDocs. The same setup used for https://github.com/0install/web-site
should work here: Keep the sources on the "master" branch and put the
generated HTML on "gh-pages".
The actual build process with MkDocs is a single command and should be
fairly easy to run on AppVeyor or Travis CI.

> I don't mind moving to markdown if people prefer that to HTML. It does
indeed give nicer previews on GitHub. On the other hand, I don't feel we
suffer from a lack of documentation at the moment.

The documentation for Zero Install on Linux is pretty good indeed,
especially your detailed tutorials!
My main motivation for this is to have a place I can easily merge in the
much sparser Windows docs over time. If I find the time, I'd also like to
add some tutorials on using the various language runtimes available on
http://repo.roscidus.com/.

> In general, some things seem a little better (editing, separately
scrolling navigation, mobile) and some a little worse (speed, tracking, ads,
losing the search feature, non-folding menu, lack of control over ordering).

MkDocs has a built-in search feature which I hadn't enabled yet. I've turned
it on for https://0install.readthedocs.io/ now.

MkDocs also allows page ordering to be controlled manually
(https://www.mkdocs.org/user-guide/configuration/#documentation-layout).
However, I kind of prefer being able to just add new files and directories
without having to list them in a central file.

The non-folding menu is indeed a bit ugly. Maybe somebody can help out there
with a little JavaScript voodoo?

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

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

The current site does indeed seem bad on mobile. Do people want to
read it on their phones?

readthedocs seems a bit slow. Testing a refresh on one page at random:

Current site:
7 requests
47.94 KB / 27.70 KB transferred
Finish: 804 ms
DOMContentLoaded: 188 ms
load: 910 ms

New site:
22 requests
462.38 KB / 220.31 KB transferred
Finish: 3.25 s
DOMContentLoaded: 1.22 s
load: 3.25 s

It seems to add some tracking scripts and some adverts too :-/

I don't mind moving to markdown if people prefer that to HTML. It does
indeed give nicer previews on GitHub. On the other hand, I don't feel
we suffer from a lack of documentation at the moment.

In general, some things seem a little better (editing, separately
scrolling navigation, mobile) and some a little worse (speed,
tracking, ads, losing the search feature, non-folding menu, lack of
control over ordering).

In 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. I believe
> this provides a number of advantages:
>
> MkDocs uses Markdown files as its input. Markdown is wildly popular for
> documentation these days, dead simple to write and has native support in
> many tools (e.g. GitHub's web interface). Speaking of GitHub, MkDocs
> generates automatic "Edit this page on GitHub" links.
>
> MkDocs comes with responsive themes, making the generated doc pages easier
> to read on mobile devices. I added some custom CSS to better match look of
> http://0install.net/. It also applies language-specific syntax highlighting
> to Markdown code blocks, which makes the XML and Python samples in the docs
> look nicer.
>
> MkDocs automatically derives the menu structure from the file and directory
> structure. This makes adding new pages very easy. It also detects and
> reports dead links between pages during build.
>
> I converted the HTML content of the existing web-site into Markdown using
> Turndown (https://github.com/domchristie/turndown). Then I went through all
> the pages manually improving the generated Markdown, adding code blocks,
> etc..
>
> Finally, I set up free automatic building and hosting using ReadTheDocs at
> https://0install.readthedocs.io/. This service also supports custom domains
> using CNAMEs, including automatically issuing TLS certificates. So we could
> serve this from https://docs.0install.net/ for example.
>
> Next, I will start integrating documentation for Zero Install for Windows
> from http://0install.de/ into this web-site.
>
> What do you guys think? Is this a viable approach? Any areas you think need
> improvement?
>
> Regards
> Bastian
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Zero-install-devel mailing list
> Zer...@li...
> https://lists.sourceforge.net/lists/listinfo/zero-install-devel



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

Re: [Zero-install-devel] To get your own programs added, please announce them here on the ML

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

On Wed, 29 Aug 2018 at 17:41, <s4...@go...> wrote:
> http://roscidus.com/0mirror/
> says:
> >  To get your own programs added, please announce them and your GPG key on the mailing list.
>
> OK so here I want to announce that.
>
> What is the next step?

You need to publish the programs (using 0install) on your web-site first.

Once you have that working, you can post the URLs and your GPG key on this list.


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

Re: [Zero-install-devel] docs -- why-not section

[<s4...@go...>]

> If you compare 0inst with AUR it is clear to see why AUR is more
> popular: it works better and is less trouble!
> 
> It does not keep an app programmer to use the same advanced ways in use
> with 0inst, just, it does not enforce it. Which is why you find some
> absolute paths in AUR apps.



correction:

It does not keep an app programmer from using the same advanced ways...

Re: [Zero-install-devel] docs -- why-not section

[<s4...@go...>]

ciryat:
> Care should be taken to not reword why-not section into something
> subjective.
I'm not sure whether the docs are objective at this very moment.


If you compare 0inst with AUR it is clear to see why AUR is more
popular: it works better and is less trouble!

It does not keep an app programmer to use the same advanced ways in use
with 0inst, just, it does not enforce it. Which is why you find some
absolute paths in AUR apps.

But overall, AUR is simpler and less trouble and adds less complexities.

Its quite impressive how the guix makers proved their point by actually
packaging a whole distro with it, i.e. GuixSD.


Is is poss to repackage GuixSD using 0install ? That would be cool...
it might actually be poss. ...

Re: [Zero-install-devel] Zero-install-devel Digest, Vol 140, Issue 2

[<s4...@go...>]

s4...@go...:>> IMO zeroinstall universal package manager is very useful
but it not
>> adopted well and it is a different approach than mainline package
>> managers which is easiest seen in maintenance when looking at Arch or
>> Void package managers + AUR.
>
> AUR does _NOT_ make demands (on the grounds of security and
"installability")
> on the app like 0install does. That puts 0i at a disadvantage.

I corrected it:  AUR does  __not__ make demands

Re: [Zero-install-devel] Zero-install-devel Digest, Vol 140, Issue 2

[<s4...@go...>]

0install adoption may improve when future users know what to expect
from 0i.


ciryat:
> Care should be taken to not reword why-not section into something
> subjective. An operating system distribution is made up by its package
> manager, see f.e. gentoo's portage, Arch's pacman, Void's xbps, and
> people are sensitive.

best example being guix and GuixSD.



> De facto zeroinstall is a niche package manager that some reject due to
> containerization. This is a valid contra, that of course also has its
> pros, like encapsulation and the dependencies in different versions.

some just don't feel they get anything out of it other than extra work
and being confused by another tool doing everything different than the
regular tool.


> IMO zeroinstall universal package manager is very useful but it not
> adopted well and it is a different approach than mainline package
> managers which is easiest seen in maintenance when looking at Arch or
> Void package managers + AUR.

AUR does make demands (on the grounds of security and "installability")
on the app like 0install does. That puts 0i at a disadvantage.


> While with standard package managers one maintains all software to be
> compatible at the stable edge and if one is not, then it is updated to
> become compatible again, maybe breaking other software depending on the
> tool just updated. Thus these are updated to become compatible again.
> You get the point, this is a neverending story if and only if there are
> new modifications to existing software. If not then there was indeed an
> ending when all got compatible to each other.
> 
> ZeroInstall opted out of this maintenance game by ensuring one program
> gets what it needs for the functionality it provides.

guix does that even better.

The docs should make a comparison between
0install, guix and nix of NixOS.


> This is very good.
> As is the bundling of the template and release XML with the source
> repository.

but often time the GUI tools to handle the release XML breaks or
crashes.  :-(


> Yet people do not use it because it simply is no viable up to date,
> complete alternative yet. 

in other words: it breaks! it does not work often times!


> If one wanted to use 0install instead of pip
> and npm one first had to package way to many packages, not to speak
> about maintaining them. 

not only that but also modify the source a great deal! not necess. with AUR!


> Only automated generation and periodic update of
> all packages in existence will give zero-install the edge.

that is practically impossible.


> Then we'd have distributed package hosting by each developer or
> maintainer. In the most ideal case that would be only one maintainer
> which most often is the developer. In contrast to the current situation
> where every distro needs its maintainer for every package.

and every app has several package-maintainers for the various distros'
packg-managers since the programmer cannot keep 30 OSes on his disk.



> This goal of distributed single source principle distribution can be
> compared to how devs converted from SVN to Git or mercurial. Or maybe
> from piecemeal deployment to deploying a docker image. I see 0install as
> inbetween those and as a very noble goal to pursue.

But guix is even more consequentuial in addressing and resolving the
deployment crisis that is explained in the lines above.

> I use it for as much of my code works whenever it makes sense, i.e. it
> needs be distributed other than using Git clone, i.e. if there are
> dependencies that git submodules can not sensibly handle.

I found that manually deploying from git + manually deploying its deps is
quicker than bothering with 0install or such.

0install introduces extra complexity and thus extra workload.




>>     4. why to not use 0install (s4...@go...)

>> see my fork    ;-)
>>
>>
>>   https://km-200.github.io/docs

>> however, this does not make sense! People specifically use 0install
>> to get rid of github and github-pages due to the agressive censorship
>> on github and such places.