Re: Should commits rather be buildable or small

[dan]

Hi John,

On 3/25/2024 9:15 AM, John Kehayias wrote:

dan: Do you know if just a version/hash bump is at least buildable? Or
are the changes necessary for the packages to build/function at all?
Or I guess if the non-version changes are applicable to the current
version first?


I'll give it a try tomorrow.  I think if packages are updated in certain 
sequence, it should be at least buildable.  I'll give update or send a 
new patch series if I have any progress on this.


--
dan

Re: Should commits rather be buildable or small

[dan]

Hi John,

On 3/5/2024 5:38 AM, John Kehayias wrote:

In this case all the vulkan packages share a version through a variable name. I 
would assume packages wouldn't like mixed versions, but maybe some would work 
(I haven't tried). I'll be taking this series on mesa-updates with related 
changes, so the plan is that when it hits master there are no/few broken 
packages and full substitute coverage. So perhaps this makes this more of a 
style and convention question.

Some options:

1. Essentially squash to one commit where all of vulkan is updated in one commit. The 
main upside is that nothing should break (within vulkan, dependents to be fixed as 
needed) and it shows as "one" change; the main downside is that the proposed 
changes are not just trivial version bumps. Harder to then disentangle as needed.

2. Make each commit updating a package, but don't use the variable 
%vulkan-sdk-version, updating each package with a version as it is done. Then 
do a commit where all the versions are replaced by the variable. This seems 
like unnecessary work to me and while it stops the obvious breaking (source 
hashes don't match once variable is updated but package hasn't yet) versions 
are still mixed which is likely a problem.

3. Go with the series as proposed: this means after the first commit for sure 
all other vulkan packages and dependents don't build, as the source hashes 
won't match until the commit that updates that package. Along with version 
mixing, this perhaps doesn't give you a helpful git bisect either?

None are perfect. What do people think?

My instinct is to go with the series as proposed (after review) accepting that 
there will be for sure builds failing if time traveling to the middle of the 
series. I don't think we can really avoid that anyway, as sometimes we only see 
an issue after a commit and it is fixed some time later. We could have a note 
in the first commit that this requires the next n commits to update vulkan 
packages. That might help if someone is on an intermediate commit and can see 
quickly in git log this note.

Or perhaps we can note something is part of a dependent series when we make 
commits so this is easier for someone to tell in general?


I think to make each commit able to build, it's feasible to remove this 
%vulkan-sdk-version variable. However, this doesn't fundamentally solve 
the problem: when updating several packages in a patch series, some 
packages might be broken since their dependencies are updated.


Another question is how should we treat vulkan packages. Some distros 
package them on a per package basis (I see in Arch Linux, vulkan-headers 
and vulkan-icd-loaders have version 1.3.276 while other packages like 
spirv-headers has 1.3.275). I had to admit that I'm not that familiar 
with vulkan packages, but I feel it's safer to keep their version 
matched since each vulkan-sdk release makes sure every vulkan packages 
are compatible with others. Thus, I prefer updating them in batch.


I think maybe it's a good option that we mark these commits are a series.

--
dan

Re: Branch (and team?) for mesa updates

[dan]

Hi John,

Aug 26, 2023 08:51:49 John Kehayias :



Though at least (gnu packages gl) looks pretty
reasonable to start for maybe a graphics team? Maybe with vulkan?

I'm still not sure but I should probably propose something concrete
with at least myself for gl since those patches generally will go to
the mesa-updates branch for convenient building.

Anyone else want in?


I use vulkan and sdl2 for my day to day development, and I once submitted 
a patch series updating various vulkan packages.  I'm interested in 
maintaining these vulkan packages and I like the idea of having a 
graphics team.  Meanwhile, I'm not so sure if the team should be 
responsible for sdl2, but I would like to discuss the possibility first.

Re: Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

Hi John,

On 11/16/2022 11:00 AM, John Kehayias wrote:

At the very least Mesa will need the DirectX headers. That may be it?


According to the document of mesa[1], I believe it's doing more than 
just including headers:

The D3D12 driver is a Gallium driver that emits API calls for Microsoft’s D3D12 
API instead of targeting a specific GPU architecture.
Anyway, I could take the effort into investigating if it's gonna work on 
WSL if we add d3d12 support to the gallium3d driver, but I'm afraid I 
don't have the ability to test if it breaks anything on other platform / 
for other use cases.


[1]: https://docs.mesa3d.org/drivers/d3d12.html
--
dan

Re: help wanted: upgrade llvm to 15

[dan]

Hi Maxim,

On 11/16/2022 5:03 AM, Maxim Cournoyer wrote:

For other reasons (qt-creator), I've packaged llvm/clang 15, see
https://issues.guix.gnu.org/59237.


I'm aware of the patch series.  Really appreciate it!

--
dan

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:


1. when logged in, there is a warning says:
 > warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'


The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].


This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.


2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).


I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?


[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87

[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

--
dan


OpenPGP_0xB17E7CFADED8D81E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:


1. when logged in, there is a warning says:
 > warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'


The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].


This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.


2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).


I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?


[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87

[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

--
dan


OpenPGP_0xB17E7CFADED8D81E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Should wsl-boot-program create XDG_RUNTIME_DIR?

[dan]

Hello guix,

Even since the WSL image was pushed to master branch, I've been spending 
time experimenting with it.  It almost runs smoothly, unless two points:


1. when logged in, there is a warning says:
> warning: XDG_RUNTIME_DIR doesn't exists, on-first-login script won't 
execute anything.  You can check if xdg runtime directory exists, 
XDG_RUNTIME_DIR variable is set to appropriate value and manually 
execute the script by running '$HOME/.guix-home/on-first-login'


The value of $XDG_RUNTIME_DIR is /run/user/$UID, and the /run/user 
directory is empty.  I believe the /run directory is created on WSL's 
side, and there is a step remounting it[1].


This also makes home shepherd services unusable.  Although I could 
manually create the directory, perhaps it's better if we could just do 
the work within `wsl-boot-program', a wrapper for the login shell to 
work properly on WSL.


2. WSLg is usable, but the mesa in guix repo doesn't build with d3d12 
gallium driver[2]. So when opening up a GUI software in guix on WSL, in 
renders through llvmpipe (using CPU not GPU).


I'm not sure if building mesa with d3d12 driver enabled by default is a 
good idea, or maybe we could create a new package?


[1] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/images/wsl2.scm#n87

[2] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gl.scm#n332

--
dan


OpenPGP_0xB17E7CFADED8D81E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

help wanted: upgrade llvm to 15

[dan]

hello guix,

i'm totally new to guix and free software development, so bear me if i'm 
doing something wrong.


the 0.10 version of zig just got released[1], with the new self-hosted 
compiler.  during the period of development, i've also submitted a pull 
request[2] for zig, so that we don't need an extra patch file[3] to 
build it on guix.


however, the new zig compiler depends on llvm-15 to build, which is 
unfortunately, not available in guix at the moment.  i personally would 
like to do the work, but lacking the knowledge of both guix and llvm 
makes it almost like an impossible task for me.  so it would be really 
helpful if anyone could help with the packaging of llvm-15.


initially asked on #guix irc channel, csepp suggested me asking on 
guix-devel, hoping to get more attention and help.


[1] https://ziglang.org/download/0.10.0/release-notes.html
[2] https://github.com/ziglang/zig/pull/13145
[3] 
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/zig-use-system-paths.patch


--
dan


OpenPGP_0xB17E7CFADED8D81E.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Alternate logo (origami gnu)

[Dan Frumin]

On 17-06-19 11:36, Ludovic Courtès wrote:

Hi,

Daniel Fitzpatrick  skribis:


I made an origami gnu based off some origami instructions I found online.
Possibly suitable as an alternate logo.  Looks vaguely similar to the Clear
Linux penguin, but not as polished or polygonal.

I'm not an artist and this only took a couple of hours.  Please tweak and
use under whatever license you prefer.  Or don't use.  It was done purely
for fun in inkscape.

https://paste.debian.net/hidden/47b14e9a/


Fun!

Now you’ll have to come up with folding instructions so we can make it
for real.  :-)



I've managed to find folding instructions for this online: 
https://issuu.com/dafeba/docs/gnu
(warning, the page seem to require arbitrary JavaScript), and it's relatively 
easy to make it! :-)

Now we just need to get instructions licensed under a free license. :-)

Best,
Dan


Thanks for sharing,
Ludo’.

Re: Fennel and Luarocks

[Dan Frumin]

Hi Marlin!

I am not really familiar with the Lua ecosystem, but wouldn't it be desirable to use Guix to manage Lua package, the way it's done for e.g. Haskell 
right now?


I don't fully understand how luarocks works, but is it possible to have an 
"importer" for luarocks packages, similar to e.g. the hackage importer?

Best,
-Dan

On 18-06-19 03:35, Marlin wrote:

I'm trying to port over fennel and luarocks to guix.
Fennel is a lisp language which compiles to lua, and luarocks is a
Pypi-like package manager for lua libraries
I believe a luarocks build system would be needed.
The packges are luarocks.scm and fennel.scm, located at my personal channel.
https://framagit.org/marlin1113/marlin-guix-packages

Re: GNU Guix 1.0.1 released

[Dan Frumin]

Hi Ludovic,

Congratulations on the release.

Perhaps someone can update the website <http://guix.gnu.org> or 
<http://guix.info>
which still has a DOWNLOAD 1.0.0 button.

On a related note, how come there are two versions of the official Guix website?
- http://gnu.org/s/guix (this one seems to be the most recent/updated one)
- http://guix.info or http://guix.gnu.org (this one seems to lag behind)

Is it possible to unify them somehow, perhaps? It would be less confusing for 
people searching
for Guix on Google or DuckDuckGo.

Best,
-Dan

On 19-05-19 23:43, Ludovic Courtès wrote:

We are pleased to announce the release of GNU Guix 1.0.1.

This is a bug-fix release primarily addressing one major issue in the
graphical installer of the standalone Guix system, as well as less
critical issues.

Read more about today’s announcement at:

   https://gnu.org/software/guix/blog/2019/gnu-guix-1.0.1-released

• About

   GNU Guix is a transactional package manager and an advanced
   distribution of the GNU system that respects user freedom.  Guix can
   be used on top of any system running the kernel Linux, or it can be
   used as a standalone operating system distribution for i686, x86_64,
   ARMv7, and AArch64 machines.

   In addition to standard package management features, Guix supports
   transactional upgrades and roll-backs, unprivileged package
   management, per-user profiles, and garbage collection.  When used as a
   standalone GNU/Linux distribution, Guix offers a declarative,
   stateless approach to operating system configuration management.  Guix
   is highly customizable and hackable through Guile programming
   interfaces and extensions to the Scheme language.

   https://www.gnu.org/software/guix/

• Download

   Here are the compressed sources and a GPG detached signature[*]:
 https://ftp.gnu.org/gnu/guix/guix-1.0.1.tar.gz
 https://ftp.gnu.org/gnu/guix/guix-1.0.1.tar.gz.sig

   Here are the bootable USB installation images and their signatures[*]:
 https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.i686-linux.iso.xz
 
https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.i686-linux.iso.xz.sig
 https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linux.iso.xz
 
https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.1.x86_64-linux.iso.xz.sig

   Here is the QCOW2 virtual machine (VM) image and its signature:
 https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz
 https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.0.1.x86_64-linux.xz.sig

   Here are the binary tarballs and their signatures[*]:
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.i686-linux.tar.xz
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.i686-linux.tar.xz.sig
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.x86_64-linux.tar.xz
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.x86_64-linux.tar.xz.sig
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.armhf-linux.tar.xz
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.armhf-linux.tar.xz.sig
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.aarch64-linux.tar.xz
 https://ftp.gnu.org/gnu/guix/guix-binary-1.0.1.aarch64-linux.tar.xz.sig

   Use a mirror for higher download bandwidth:
 https://www.gnu.org/order/ftp.html
   
   Here are the SHA1 checksums:


   f6e32b17e034124edeec11d841e687ba0ee59242  guix-1.0.1.tar.gz
   d710c927c1eae466c4f8a11796e196bd61fe07aa  
guix-binary-1.0.1.aarch64-linux.tar.xz
   457b8a13660a764c326096cd3a7107c6e036e406  
guix-binary-1.0.1.armhf-linux.tar.xz
   314f093ea71702cebdc1a98c3ca8319cd49efbfc  guix-binary-1.0.1.i686-linux.tar.xz
   8288422fde6a6d4ee257355c21ab9447ae9736cf  
guix-binary-1.0.1.x86_64-linux.tar.xz
   78b48b00c7f5e073a66c976085f0489db2449b0b  
guix-system-install-1.0.1.i686-linux.iso.xz
   41c6ed4e48930fa0ef7954745b5c7a4d85dfd0a8  
guix-system-install-1.0.1.x86_64-linux.iso.xz
   bce4a096717ac7a749cccd8d161d71dfd6c6e579  
guix-system-vm-image-1.0.1.x86_64-linux.xz
   
   [*] Use a .sig file to verify that the corresponding file (without the

   .sig suffix) is intact.  First, be sure to download both the .sig file
   and the corresponding tarball.  Then, run a command like this:
   
 gpg --verify guix-1.0.1.tar.gz.sig
   
   If that command fails because you don't have the required public key,

   then run this command to import it:
   
 gpg --keyserver pool.sks-keyservers.net \

 --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
   
   and rerun the 'gpg --verify' command.


   To install the standalone Guix system, please see “System
   Installation” in the manual.  To install Guix on a running system, see
   “Installation” in the manual.

• Changes since version 1.0.0 (excerpt from the NEWS file)

   ** Package management
   *** The ‘https_proxy’ environment variable is now honored
   ** Distribution
   *** ‘guix system docker-image’ now produces images with an entry point
   *** New ‘--network’ option

Re: Libre games that might be worth packaging :)

[Dan Frumin]

On 18-03-19 08:25, Pierre Neidhardt wrote:

Ricardo Wurmus  writes:


We have this.  It’s called “btanks”.


Shouldn't we name this "battle-tanks"?



I think this one is packaged: see the `crawl' and `crawl-tiles' packages.


Shouldn't we name this "dungeon-crawl-stone-soup"?



Possibly, but the official packages from crawl.develz.org are called `crawl' 
and `crawl-tiles'.
Maybe it is good to add the abbreviation "DCSS" somewhere in the description 
tho?





Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the
classic Tron arcade game. Highly configurable and very fun to play.


This we have already. :)


It's named "armagetronad".  Shouldn't we name this
"armagetron-advanced"?

Cheers!

Re: Libre games that might be worth packaging :)

[Dan Frumin]

Hi!

On 17-03-19 17:51, swedebugia wrote:> Hi!
>
> I just went through Julie Marchants excellent list of libre games: 
https://onpon4.github.io/articles/libre-games.html
>
> There are so many! :)
>
> Currently we are missing these (according to https://guix.mdc-berlin.de/):
>
>>  <>>
> Dungeon Crawl Stone Soup - A very fun and well-made dungeon crawl game with a nice 
interface. Find the "Orb of Zot" and then exit the dungeon (without
> getting yourself killed, of course) to win!
>
I think this one is packaged: see the `crawl' and `crawl-tiles' packages.


Best, Dan

Re: Eliminate environment variable hints?

[Dan Frumin]

Hi,

I just wanted to add that I use an interactive shell with a different syntax 
(fish),
so I cannot just source a bsh script from my shell rc (AFAIK). To that extent having Guix print the exact variables I should be setting is actually 
quite useful.


Best,
Dan

On 04-03-19 22:56, Ludovic Courtès wrote:

Hello,

Ricardo Wurmus  skribis:


when installing a package into a profile Guix very helpfully tells you
that you may need to set certain environment variables.  It doesn’t tell
you that these environment variables can also be set by source’ing the
generated etc/profile file.

I have seen the bashrc and bash_profile files of many users and they are
usually full of conflicting environment variable definitions.  In these
files I often also see these Guix recommendations.

I think Guix should suggest sourcing the generated etc/profile file
instead of listing explicit environment variable definitions.  It would
be less noisy and less confusing, in my opinion.

What do you think?


When (re)sourcing etc/profile, you might clutter some variables.  For
instance, if you do that several times, you can end up with:

   
PATH=$HOME/.guix-profile/bin:$HOME/.guix-profile/bin:$HOME/.guix-profile/bin:…

Conversely, the hint upon installation disappears if the entry is
already present in the variable.

That’s a fine point but I occasionally rely on this as a user.

That said, I understand your concern.  What about changing the message
to:

   You might need to run:

  . …/etc/profile

   Alternately, you can define the following environment variables:

  …

Too verbose?  Confusing?

Thanks,
Ludo’.

Re: Ensuring we don't break user systems

[Dan Partelly]

It all boils down to what you desire GuixSD to become. If you want it to be a 
hacker playground, than any model is good. If you want it to be a reliable OS 
used in production some day, then, frankly, you need live up to the reliability 
promise you have on the distro www page, even if this means a certain degree of 
inconvenience to the developers and they will have to adapt their habits to the 
new model.  And it aint gonna be funny, but needs to be done.

I also believe that an iterative process is better than devising from a to z a 
deployment model , wait for complete tool development, then go through a 
painful transition period. Why ?

- devising a complete model and tools will take years. In this time the promise 
of reliability will not be fulfilled, and an already low user base will become 
lower as a consequence.  I have to reiterate, in the wild adoption of software 
has almost nothing to do with technical excellence but almost everything with 
social factors. People couldn't care less about whats great about GuixSd if it 
breaks easily. 

- you will lower the amount of bikeshedding. A full a to z change will require 
a lot of agreeing on new models, operations change , infrastructure work and 
some of the decision will be unpopular with some developers who will try to 
fight it. Iterations will help IMO to minimize this.

-you will lower the amount of factors you need to juggle simultaneously to 
ensure a smooth transition with iteration. This in effect will lower the 
negative effects the transition has on your own developers. 


- you will have something today,as opposed in a couple of years. Users are 
appreciative of  increases in reliability and they might stay interested if 
they see work is actively done.  Last thing users (leaving aside sticking with 
something on philosophical grounds )  want is to  fight the OS and solve 
breakages. In fact having to solve OS breakages (when you use the OS not 
develop it) builds negative reactions in most humans. Once a breakage is 
encountered at OS level (which in guixsd includes guix) inevitably the next 
question is “Why should I use this ? It wastes my time”. And the negative 
reaction is usually strong, as in - it eclipses other positive of the OS.

-stability and reliability  in themselves  much more important than features 
such as device mapper / lvm / root on exotic filesystems ,  whatever. 

- leaving aside social factors, even technically , inflicting a development  
branch on anyone but the developers / testers is *the wrong thing to do(TM)*. 

Those , of course, are just my thoughts based on the empirical observations I 
made in time.  

> On Jul 31, 2018, at 00:16, Nils Gillmann  wrote:
> 
> We have grown over the last years, but developing reasonable deployment
> models which fit our group takes time.

Re: Ensuring we don't break user systems

[Dan Partelly]

However, you do not need any tool support to switch a “stable” branch as a 
first step , ensuring you inimize the OS user exposure to both serious Guix 
bugs and potential Guile bugs. 

> On Jul 30, 2018, at 02:41, Ludovic Courtès  wrote:
> 
> Hello!
> 
> Julien Lepiller  skribis:
> 
>> I'd like to propose the following policy:
>> 
>> We wouldcreate a new branch, stable, that would be used by guix pull. We 
>> would continue to push to master or other branches.
>> 
>> Once hydra finds it can build at least as many packages in master than 
>> stable, it would make master the new stable, hopefully once a day or so.
> 
> I’m all for it.  We “just” need support for this in Cuirass and/or some
> other tool…
> 
> Ludo’.
> 

Re: Ensuring we don't break user systems

[Dan Partelly]

It also has the effect that guix is pulled from a reasonably tested branch and 
it is proven that it compiles. Given how central the package manager is to the 
GuixSD, this is something which IMO should have been done from long ago. IT 
saves users time, 
and show the developers care , if nothing else. But yeah, this proposal is IMO 
sound both technically and socially.

> system or profile will always succeed and use substitutes, but it
> doesn't give any guarantee on adding a package to the system or a user
> profile.
> 
>> 
>> 
>> 
>>> On Jul 29, 2018, at 12:40, Julien Lepiller 
>>> wrote:
>>> 
>>> Hi guix!
>>> 
>>> I recently had an idea about how we should organize ourworkflow for
>>> post 1.0. The goal is to ensure that users can always update their
>>> system.
>>> 
>>> Currently, we push updatesto master and they may not build on other
>>> architectures or break dependant packages. This is bad because a
>>> security update might get blocked because an unrelated package now
>>> fails to build.
>>> 
>>> I'd like to propose the following policy:
>>> 
>>> We wouldcreate a new branch, stable, that would be used by guix
>>> pull. We would continue to push to master or other branches.
>>> 
>>> Once hydra finds it can build at least as many packages in master
>>> than stable, it would make master the new stable, hopefully once a
>>> day or so.
>>> 
>>> Security updates would be provided to users by a seéarate channel,
>>> to ensure important updates are delivered immediately to users.
>>> 
>>> Another possibility is to use a patch management system like gerrit
>>> with a similar policy.
>>> 
>>> WDYT?
>>> 
> 
> 

Re: Ensuring we don't break user systems

[Dan Partelly]

No I did not shown or proofed this affirmation. I believe it is sensible.  It 
is a undeniable reality of software development  that bugs are introduced 
during development. Having the update to the package manager (which in GuixSD 
is very central to the distro itself) 
result in a broken system "even if you can roll back” is a very bad thing. It 
is my opinion that the current model is both technically bad (exposing users to 
broken software , security bugs and so on) and socially bad ( having the 
package manager crap on itself due to bugs introduced in the development cycle 
may prompt a lot of people to look in to an alternative and creates bad 
publicity. It also results in end users wasting time, and time is the most 
precious comodity we have. I do not want the OS I use to waste my time. I want 
to install the software I need and work with and go on with my life and work  
). Ironically, the problem is easily solved . DO not expose people to your 
devel branch where they will get first contact wiith guix bugs and guile bugs. 
The situation with GuixSD is somehow complicated by the fact that the package 
metadata is compiled as code, but yeah, a stable branch which is proven to be 
compilable and preferably regression tested is the first step IMO towards a 
better future with GuixSD. Treat is as a product which offers a rock solid 
platform for the users.

And yes, in between 0.14 / 0.15 GuixSD was broken by guix pull a  lot. That is 
a fact, unfortunately. 
> Dan Partelly  writes:
> 
>> I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. 
>> Thanks for reaffirming  the idea In all honesty the current model is very 
>> badly broken, and you should not wait for 1.0. I had no other Linux distro 
>> break up faster than GuixSD. A stable branch is not enough by itself,  (but 
>> is the mort important part) you need to ensure that all substitutes are 
>> built correctly, and atomically update all substitutes following a 
>> successful build of all packages.
>> 
>> You should not inflict  current model on your users , not  even for an 0.1
> 
> While this might apply to some software. I don't believe, and I don't
> think you've shown that this reasoning is appropriate or useful to apply
> to Guix.
> 
> Saying that something doesn't work for you is fine, and can be helpful,
> but such a unevidenced extreme view is unhelpful.

Re: Ensuring we don't break user systems

[Dan Partelly]

Even more important than this, is that the users do not end up with a broken 
package manager  following a guix pull. Which is what happened pretty often in 
my experiences with GuixSD. Yes, yes, you can “roll-back”. The bottom line is , 
the system should not break in the first place. GuixSD should not inflict its 
development branch of the package manager on the world, and the stable branch 
should be regression tested

> On Jul 29, 2018, at 12:45, Pierre Neidhardt  wrote:
> 
> I like this a lot!
> 
> Security aside, I also think it's very important for 1.0 that casual users
> (i.e. non-devs) can `guix pull' without rebuilding half their packages 
> because hydra
> hadn't had the time to rebuild everything from the latest commit.
> 
> -- 
> Pierre Neidhardt

Re: Ensuring we don't break user systems

[Dan Partelly]

I pointed this out 4-5 weeks ago when trying GuixSD, on this very list. Thanks 
for reaffirming  the idea In all honesty the current model is very badly 
broken, and you should not wait for 1.0. I had no other Linux distro break up 
faster than GuixSD. A stable branch is not enough by itself,  (but is the mort 
important part) you need to ensure that all substitutes are built correctly, 
and atomically update all substitutes following a successful build of all 
packages. 

 You should not inflict  current model on your users , not  even for an 0.1



> On Jul 29, 2018, at 12:40, Julien Lepiller  wrote:
> 
> Hi guix!
> 
> I recently had an idea about how we should organize ourworkflow for post 1.0. 
> The goal is to ensure that users can always update their system.
> 
> Currently, we push updatesto master and they may not build on other 
> architectures or break dependant packages. This is bad because a security 
> update might get blocked because an unrelated package now fails to build.
> 
> I'd like to propose the following policy:
> 
> We wouldcreate a new branch, stable, that would be used by guix pull. We 
> would continue to push to master or other branches.
> 
> Once hydra finds it can build at least as many packages in master than 
> stable, it would make master the new stable, hopefully once a day or so.
> 
> Security updates would be provided to users by a seéarate channel, to ensure 
> important updates are delivered immediately to users.
> 
> Another possibility is to use a patch management system like gerrit with a 
> similar policy.
> 
> WDYT?
> 

Re: Improving the README and new user experience

[Dan Partelly]

> I'm not quite sure yet how to improve the experience to new users.  I'd
> need to install it several times, with other people and for different
> scenarios before I can be a better judge.


Hi guys, 

Look, I started to watch more things on GuixSD , such as “Composing system 
services in guixSD or how we came….”  by Ludovic Courtes . I believe you guys 
should put in Guix manual some explication of concepts and some of the examples 
Ludovic does there,
that video helped a lot with GuixSD in general. 

Re: Improving the README and new user experience

[Dan Partelly]

It is my oppinion that first you should very clearly define what you want from 
GuixSD 

a) is GuixSD to be a system which sees wide adoption , or is a system by 
developers for developers.
b) What kind of users ? Industrial use or amateurs at home ?
c) Server space, desktop space or both ?
d) if server space, actively think at security  and to the stability of the OS. 
Identify potential security risks of  running the custom kernel you have. 
Document it. Be open about it . Think at the implications of running a 
conservative garbage collector in several system demons. Uptime should be 
measured in year(s). See if it is a problem or not.Measure it .  Document it.
e) GuixSD is decent OS  and  follows NIX on the path of innovation . It would 
be a pitty to remain a niche used by a very small group of ppl . Do not focus 
just on the fact that the system is transactional, atomic and so on. Make it 
rock stable.


> I'm not quite sure yet how to improve the experience to new users.

1. Once you know this there is a lot you can do. Scheme is a good configuration 
language, but if you lack info on all the basics administration tasks and the 
semantics of the DSL the user is screwed. Documenting it is a must, for all 
common adminsitrative tasks
2. Make sure you use sound development practices, do not inflict the users upon 
the bleeding edge of your repository. I cannot stress enough how important this 
is, regardless of what you shoose to be the market of your product.
3. Treat it as a product, not as a hacking playground. I know it is not funny, 
but my guess is that it will help with adoption
4. Once you reach 1.0 , stop. Reflect on the bugs you have, and what 
documentation you lack. Make bug solving a priority for several point releases 
over new features. Or do both if you have sufficient manpower.
e) AIX Smitty is a great rpogram for configuring the system. It generates 
scripts, which the admin can execute and bring the OS in the desired state. You 
can generate Scheme from a similar system configuration tool, indicate the user 
it should review it, then
execute system recofniguration with guix command. 

> On Jun 20, 2018, at 10:20, Pierre Neidhardt  > wrote:
> 
> I'm not quite sure yet how to improve the experience to new users.  I'd
> need to install it several times, with other people and for different
> scenarios before I can be a better judge.

Re: Improving the README and new user experience

[Dan Partelly]

HI,

When somebody installs an OS , the last thing he wants is to have the OS craps 
on him in the next 10 minutes. And I can safely generalize this. People want to 
install the OS and then get on with their lives, do their work or whatever 
else. This is paramount for an OS. Be reliable and get out of the way. GuixSD 
unfortunately falls short here , but some aspects are easy to mitigate. This 
assumes that you want people to use your OS, and it’s not written by developers 
for developers only. Adoption of software is modulated by social factors much 
more then technical excellence. If somebody wants his tools

> I would like to help new users understand more about GuixSD before they run 
> it (and inevitably into errors) 

First thing, you must ensure that users do not run in the errors. If the users 
go inevitably into errors, then you have an issue with the design of the system 
and you have to rethink it. The simplest best way to mitigate this aspect is 
two fold:
- make a FAQ page as the first thing of the manual. Make sure it 
contains a glossary of specific terms such as  store, system profile, user 
profile, derivation, substitutes, explain structure, and some usual commands. 
Make sure it has a disclaimer the system is in beta, and may break, outlining 
the simplest way to recover. 
   - make sure you follow sane development practices and relase 
engineering. Take this very seriously. By no means have giux pull work by 
pulling from the bleeding edge of a  repository. In my opinion this is 
irresponsible. You just exposed your users to every bug imaginable in a 
development cycle. Guix is inevitably rolling, and to get last packages  you 
have to update it, but do this from intermediary branches such as 0.14.1 … 
0.14.n, branches which where regression  tested before beeing inflicted upon 
the user. 

> Users come from other Distros where tough package manager errors mostly mean: 
> you are screwed, reinstall. Because if you loose the central command to 
> manipulate the system - how can you possibly recover? Imagine apt being 
> corrupt or gone missing. 

This is not true. In classical distros, the central command to recover is not 
the package manager per se. It’s an editor in the first place, and only 
secondary the package manager. You are not screwed if the package manager craps 
on you, you have a lot of options to recover. You do not have to reinstall. 
Guix is much more central to GuixSD then pacman to arch for example, because 
well, it also wants to manage t system configuration for you, not just install 
some packages. 

> wen we need to educate them that this is something completely different where 
> it is actually hard to break (besides when running guix pull and not 
> understanding how to set paths manually) 

What you want is not easy recovery. This is important , but secondary to the 
fact that they **system should not break** in the first place.  guix pull is a 
very problematic command. Users do not want to do a command which supposedly 
gives them access to new packages and then have to recover. Again, user want to 
get the software, and get on with their lives. This means that you must have 
guix pull work flawlessly (industrial strength ) by the time you reach 1.0 I 
cannot stress enough how important this is for the adoption of your OS.

> I would like to tell new users NOT to change the config.scm at first install 
> if they are not confident schemers. (besides the username and timezone 
> perhaps). 

I dont think it’s OK. People want to configure the system. With how much 
fragmentation exist in Linux world it is unlikely you will be able to offer a 
good inital configuration which satisfy ppl coming from othe Linuxes. For 
example the default bare bones loaded a DNS caching demon for me. Why would I 
want that ? The config system should as user friendly as possible, and 
***DOCUMENTED**.  FAQ are in order:

 - how to I modify the base packages set
 - how do I add my own package set
 - how do I alter a package build options
 -what can be inherited and what not, and what inheriting gains me
 - how do I set timezone , locale
 - how do I create a network interface. use DHCP, fixed address. How do I 
create abridge network interface 
 - boot and initrd handling. Add new drenel driver to kmod Options for init 
demon 
 - filesystem handling. software raid handling. encryption of filesystems. 
-  time management. UCT times. NTP options
- conr options. cron administration.

You could offer a sample config which does all those examples. 


>  Also the editors included in the image are crap because they lack two 
> important features: 1) keeping track of the damn paranteses and 2) comment 
> and uncomment region. 

Yes. nano is crap. vi has paren matching, but doest keep tack of them . Editing 
lispy code with tracking of parens is not a pleasure. 

Also document every bug and quirk of this system.

 

> On Jun 20, 2018, at 07:46, swedebugia  wrote:
> 
> Hi
> 
> I woul

Re: Videos

[Dan Partelly]

Thank you both , guys, 

> On Jun 19, 2018, at 23:11, Tobias Geerinckx-Rice  wrote:
> 
> Dan,
> 
> Dan Partelly wrote:
>> Whats the story with the PDF files mentioned below ? Are they flawed , 
>> damaged or not confirming to standard ? None of my pdf readers can open 
>> them. Not even Firefox or Adobe Reader. Im trying to read more on Guix.
> 
> None of the above. You likely saved the target of the ‘foo.pdf’ link, which 
> is an HTML file:
> 
> $ curl -LO  
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/talks/bio-it-world-2018/talk.2018-05-16.pdf
> $ file talk.2018-05-16.pdf
> talk.2018-05-16.pdf: HTML document, ASCII text, with very long  lines
> 
> Saving this as ‘foo.pdf’ will still be an HTML file.
> 
> The ‘plain’ link on the right serves the raw PDF file:
> 
> $ curl -LO  
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/plain/talks/bio-it-world-2018/talk.2018-05-1-6.pdf
> $ file talk.2018-05-16.pdf  talk.2018-05-16.pdf: PDF document, version 1.5
> 
> Kind regards,
> 
> T G-R

Re: Videos

[Dan Partelly]

Hi guys,

Whats the story with the PDF files mentioned below ? Are they flawed , damaged 
or not confirming to standard ? None of my pdf readers can open them. Not even 
Firefox or Adobe Reader. Im trying to read more on Guix.

Dan

> 
> using to present Guix to various audiences:
> 
>https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/talks
> 
> We don’t have to use them as they are, but they could provide some
> inspiration to find ways to explain the essence of functional package
> management.  We don’t need to start with this abstract topic.  Maybe
> it’s better to show features first.
> 
> What are your thoughts on this?
> 
> --
> Ricardo
> 
> 

Re: Suboptimal experience

[Dan Partelly]

> 
> Thank you for your advice :) I think you're right: we are still beta, so
> errors are to be expected from time to time. We should fix them before we
> go 1.0. That said, the system is robust enough that you can always recover
> from said errors.
> 

Good. Now, give current state of affairs combined with my lack of experience 
with the system I wont install it for work anywhere as some fo you guys do, but 
I will install it on an old laptop and I will try to build my Linux recovery 
images with it. This will give me time to learn it and Ill take it from here. 
The truth is that despite the negatives of the first encounter  the system has 
some characteristics that are too good to pass. And you where right when you 
told me that is very easy to extend and “make it your own”. 

Which is the right mailing list for asking question regarding packaging 
software, hooking into build system and so on (ofc, packaging discussion in the 
limit of your core values ) ?

With thanks

Re: Suboptimal experience

[Dan Partelly]

Well, retried again a git pull today. It broke with no backtrace (an exception 
while printing backtrace)
ERROR: In procedure private-lookup: No variable bound to define-module* in 
module (guile)

cannot build derivation for /gnu/store/sha…guix-32eb44240-modules.drv: 1 
dependencies could not be built
cannot build derivation for /gnu/store/sha…guix-32eb44240.drv: 1 dependencies 
could not be built

I do not know whats going on, but one two things are sure:

1. If is true that any packager can break the build of guix by commiting a bad 
package definition, then the whole packaging system design is **FLAWED** in my 
opinion. A system which is so brittle has no place in an industrial 
environment, at least until such issues are permanently resolved.  Yes, Mark 
was nice enough to say you can build it from source and it works better, but to 
be honest, when I work with an OS I just want tools which do work and make my 
life easier, not 
spit error after error for days. If I need to build a repository, it must be 
because i want to modify something or customize some software, not because the 
OS itself burps .

2. A package manager which fails time and again to build itself doesn't present 
itself as very trustworthy. It may be very well be, but adoption of software is 
governed by social factors more than technical excellence. GuixSD for now is 
very nice and cool, but its a hacking playground, not an industrial strength OS 
which you deliver without worry. 

So please excuse me if I give a bit of unsolicited advice, please fix all those 
before going 1.0.  It does not gives a good impression on the OS. I believe its 
important for your future marketing and your goals to further free software in 
this world. 






> On Jun 18, 2018, at 14:11, swedebugia  wrote:
> 
> Hi
> 
> On June 17, 2018 9:51:51 PM GMT+02:00, Dan Partelly  
> wrote:
>> HI Mark
> 
> [...]
> 
>> For any “guix system …. “ the message was:
>> 
>> guix: system: command not found . 
> 
> I experienced this as well today after guix pull from 0.14 to commit 
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=b4eae997fe5b928f179c34d281e9f2c3eccd3670
>  if I remember correctly. 
> 
> I just understood from the previous reply that running guix pull again will 
> solve the problem. I will try later and report back the result. 
> 
> -- 
> Cheers Swedebugia

Re: Suboptimal experience

[Dan Partelly]

Ive seen that in manual Julien, but I did not tried it, because the manual 
says: :When using Guix on top of GNU/Linux distribution other than GuixSD—a 
so-called foreign distro—a few additional steps are needed to get everything in 
place. Here are some of them.”   
Note the “… other than GuixSD” formulation.  I use it on GuixSD. Should i 
understand that he manual is flawed and the step is necessary on GuixSD as well 
?

> On Jun 17, 2018, at 23:09, Julien Lepiller  wrote:
> 
> Le Sun, 17 Jun 2018 22:55:03 +0300,
> Dan Partelly  a écrit :
> 
>> guile: warning: failed to install locale.
> 
> This is a "normal" message. You need to install glibc-locales in your
> profile and set an environment variable. Also, that's only a
> warning ;).
> 
> It's documented here:
> http://www.gnu.org/software/guix/manual/html_node/Application-Setup.html#Locales-1

Re: Suboptimal experience

[Dan Partelly]

Thanks a lot Julien. 

Well a second pull did not worked, it compiled sucessfully , but now any 
command results in :

guile: warning: failed to install locale.

Ill try to compile from git, I want to lear enough to solve those annoyance , 
so I can work a bit with guix sd see first hand what it has to offer

Thanks !


> On Jun 17, 2018, at 18:40, Julien Lepiller  wrote:
> 
> I hope I could help you. Don't hesitate to ask more questions or come
> back if running guix pull once more didn't work :)

Re: Suboptimal experience

[Dan Partelly]

HI Mark

> A major change was recently made to 'guix pull', and there's apparently
> a bug.  I'm sincerely sorry that this was your first impression of Guix.

Well, is not all bad, there is a lot to like as well it seems, but I need to 
experience it first hand as well :P The concept might be very well the future, 
it reminded me of Plan9 Venti file system and Joe Armstrong’s  “The web of 
names hashes and UUIDs”. The concept of guix is powerful , maybe a solution to 
so many problems,  but when wielding powerful things, some care must be taken. 
Such as not making an util update itself from the bleeding edge of a 
development repository. 

>  At the end of #4 above, you
> wrote "Guix reported:" but I see nothing anything after that.  Did you
> forget to include the error message?

Yes I forgot. For any “guix system …. “ the message was:

guix: system: command not found . 

It basically could not execute any system command. I dont know yet the 
architecture of guix componenets . I promise Ill read but it will take time to 
go through all the docs. I assume guix is a dumb client, and all the work is 
done by the demon. But is the daemon
loading “plugins” to execute the various tasks ? Or is monolithic ?  Im trying 
to see how can this happen. Client / server / server plugins are all part of 
the same system , si it sould make sense to intall them all as a single 
transaction, i.e an all or nothing to minimize the chance of something like 
this happening. 

> We are not able to eliminate the possibility that bad bugs will
> sometimes be introduced into Guix.  However, what we can ensure is that
> it's almost always possible to *roll* *back* to a working version.

I agree. This is the nature of software development. But what one can do is to 
have as many safeguards as possible in place to *minimize* such chanches. Some 
ideeas would be:

- do not ever pull a core system utility update from bleeding edge by 
*default*
-  introduce regresión testing 
- solve it socially by introducing rules for development 
- have an “unstable” branch for bleeding edge from where who wants 
bleeding edge can pull at their own peril,

> A bug introduced into package definitions can also result in a
> temporarily unusable system.  Keeping the package definitions separate
> would not eliminate that possibility

Well, if you keep them separately , you break one, two, 10 packages, and you 
can mark them broken and thats it. If you argue that any package which does 
something important in the OS if bugged I agree. But it’s not about 
*eliminating* the chances for it is impossible. It is about “minimizing” the 
chance . The distinction is important IMO. Keeping package definitions 
separately reduces this risk imo.

> n your case, it might have been useful to know that 'guix pull' only
> changes ~/.config/guix.  If 'guix pull' gets you into a bad state, you
> can always delete that directory as a last resort.


Yes very useful. May I suggest put a resume of basic functionality  the manual 
as the first page ? The implementation and filesystem paths in guix are very 
alien for the first several hours of working with. An heads up in manual would 
be very usefull
to newcomers IMO. Its not that people do not read manuals (OK most people do 
not). But usally when you evaluate a new thing there is an exploratory direct 
phase , which is very important for the first impressions. This over, some will 
go and read on the subject and lear it, but IMO it has to go smooth to maintain 
the interest in the object.

> Going forward, recent versions of 'guix pull' include the ability to
> list the "generations" of guix that have been compiled by 'guix pull',
> and to roll back to an earlier generation, or to an arbitrary commit
> from the git repo.

Well, I found those commands almost instantly, but I used them in conjunction 
with system commands. Which was broken as I mentioned. It may have worked in 
conjuction with papckages for the root store, but until you finish reading the 
manual and get the concepts it is important to be have a bump free exploratory 
ride. 

> So, once you know your way around Guix, it is almost always possible to
> recover by rolling back to older versions until the issue is resolved.

Yes, i take your word for it, I almost no flight time on guix so …

> Also, I should mention that it's possible to run Guix without ever using
> 'guix pull'.  I haven't run 'guix pull' in years.  Instead, I compile
> guix from a git checkout, and updating guix involves 'git pull’ and

Thanks.








> On Jun 17, 2018, at 20:31, Mark H Weaver  wrote:
> 
> Hi Dan,
> 
> Dan Partelly  writes:
> 
>> First thanks for the development effort you guys do. Now the issues:
>> 
>> 1. I managed to

Suboptimal experience

[Dan Partelly]

Hello,


First thanks for the development effort you guys do. Now the issues:

1. I managed to install 0.14 to a Virtual box VM. I used bare-bones 
configuration.
2. I tried to get familiar with guix / guixSD a bit, I never used it before 
3. Within minutes I managed to break the system completely , due to my 
misguided idea to execute a guix pull to upgrade the packages to the latest 
available. This command is a liability, while it should 100% safe given how  
central is to the OS.
4. This resulted into an unusable system , the command “system” for guix did 
not functioned at all after whatever git pull did .  Guix reported: 
5. attempting to fix the issue by pulling from git branch 0.14 where not 
successful.


Now some  points:

1. Why does exist a tight coupling between guix proper and package definitions  
? It is OK to recompile the package manager to get new functionality, not OK to 
recompile the package manager proper to get definitions for latest software.
It exposes the user to all kind of issues, from mundane to unmangeable / 
unusable systems .
2. Why failing to rebuild guix results into an unmanageable system ? If the OS 
prides itself with atomicity and safety, then IMO any warning in the build 
process of this core tool (for any final build artifact ). If the build process 
results in N 
   artifacts, then care should be taken that those are atomically inserted in 
the new system so no broken state can exist
3. compilation time of guix at guix pull time is horrendous. I dont know the 
system good enough, so I can be mistaken, but probably the bulk of is  is 
because of package definitions . If this is true, then you have an  issue. You 
are at about 7k packages,
   it will increase linear with n ,  you'll grow old near a computer running 
this package manager by the time you'll reach 30k + .
4. again, if 3 is true, this can be mitigate by releasing a guix package which 
is updated automatically in binary form, but it’s a hack IMO. Cutting the 
dependency of package manager from package descriptions is the only sane way to 
solve this issue IMO
5. How secure is guix SD ? I see that you use a kernel with no provisions of 
loading microcode into CPUs. Given the recent rainbow of speculative execution 
bugs, this is a big issue if kernel mitigations are not enough and updated CPU 
microcode 
is required ? How secure is Guix SD and do you plan to do anything about it 
? Or do you recommend to use it only in secure physical environments which are 
air-gapped , give that known bugs might be active ?
6. How do you plan to handle the future with a kernel which does not allow 
firmware uploads to devices. As of today, for example, virtually no current 
generation GPU for PCs on the market works in  parameters without firmware. 
That means that 
you cannot use Guix SD on server for any computing loads with current 
gen hardware, and on desktop you are limited to old hardware.  What is the 
project stance on this ? Is it doomed from start to work only on legacy 
hardware which in 5 to 10
years will be virtually extinct ? Yes, today you can still use it this way, 
since you have firmware free legacy GPUs available yet, but what about the 
future ?  How about in 5 years,  Will it run only on second hand machines using 
antiquated hardware
7. while I realize that Im inexperienced with guix, I consider that the type of 
issues I encountered should not be part of a software product in beta stage. It 
may be acceptable for the first one year in the life cycle of the product, but 
not on a beta system with what, like  8 -9 years under the belt .   Besides 
giving a very bad first impression, it wastes human time, and people time is 
the most precious resource. 
8. if I am mistaken on any point, please correct me. 
9. 

With thanks