Re: updating Jami to "Together", Qt update?

[aviva]

On 11/18/20 2:17 PM, Pierre Neidhardt wrote:
> There must always be a first user ;)


that is not cute.

Re: GNU Guix 1.2.0rc2 available for testing!

[zimoun]

Hi Ludo,

On Wed, 18 Nov 2020 at 19:53, Ludovic Courtès  wrote:

> If everything goes well, let’s release on Monday 23rd.

Birthday release? :-)


> You can also check the ‘NEWS’ file and the draft blog post at
> 
> to make sure your favorite feature is mentioned and/or to discuss the
> highlights in the blog post.

Attached the first rough draft blog post for GuixHPC blog; I forgot my
password to push to the INRIA forge… and too late to wait the reset. :-)


All the best,
simon
--
>From 2823439d49d83e35ae30df51dcd38d6fb86cd5b7 Mon Sep 17 00:00:00 2001
From: Simon Tournier 
Date: Thu, 19 Nov 2020 03:10:55 +0100
Subject: [PATCH] Add draft notes for 1.2.0.

* drafts/hpc-reproducible-research-in-guix-1.2.0.md: New file.
---
 ...hpc-reproducible-research-in-guix-1.2.0.md | 132 ++
 1 file changed, 132 insertions(+)
 create mode 100644 drafts/hpc-reproducible-research-in-guix-1.2.0.md

diff --git a/drafts/hpc-reproducible-research-in-guix-1.2.0.md b/drafts/hpc-reproducible-research-in-guix-1.2.0.md
new file mode 100644
index 000..e3c997a
--- /dev/null
+++ b/drafts/hpc-reproducible-research-in-guix-1.2.0.md
@@ -0,0 +1,132 @@
+title: DRAFT HPC & reproducible research in Guix 1.2.0
+date: 2020-11-19 02:00:00
+author: Simon Tournier
+slug: hpc-reproducible-research-in-guix-1.2.0
+tags: packages, releases
+---
+
+Version 1.2.0 of Guix was [announced
+yesterday](https://guix.gnu.org/blog/2020/gnu-guix-1.2.0-released/).  As
+the announcement points out, some 200 people contributed more than
+10,000 commits since the previous release.  This post focuses on
+important changes for HPC users, admins, and scientists made since
+version 1.1.0 was released in April 2020.
+
+# Reproducible science workflows
+
+We’re giving users more flexibility on the command line, with the
+addition of three [*package transformation
+options*](https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html):
+`--with-debug-info` ([always debug in good
+conditions](https://guix.gnu.org/manual/devel/en/html_node/Rebuilding-Debug-Info.html)!),
+`--with-c-toolchain`, and `--without-tests`.  Consider this example:
+
+```
+guix build octave-cli \
+  --with-c-toolchain=fftw=gcc-toolchain@10 \
+  --with-c-toolchain=fftwf=gcc-toolchain@10
+```
+
+The command above builds a variant of the fftw and fftwf packages using
+version 10 of gcc-toolchain instead of the default tool chain, and then builds
+a variant of the GNU Octave command-line interface using them. GNU Octave
+itself is also built with gcc-toolchain@10.
+
+This other example builds the Hardware Locality (hwloc) library and its
+dependents up to intel-mpi-benchmarks with the Clang C compiler:
+
+```
+guix build --with-c-toolchain=hwloc=clang-toolchain \
+   intel-mpi-benchmarks
+```
+
+On the side of long-term archival of all the software Guix packages refer to,
+Guix now serves the file [`sources.json`](http://guix.gnu.org/sources.json)
+that is ingested by [Software Heritage](https://softwareheritage.org) via the
+[nixguix
+loader](https://docs.softwareheritage.org/devel/_modules/swh/loader/package/nixguix.html).
+In addition to the “archival” check of `guix lint` which sends a “save”
+request to Software Heritage for the specified packages.  More packages are
+continuously archived.
+
+The new option `--path` of [`guix
+graph`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-graph.html),
+shows the shortest path between two nodes.  The example below shows the
+shortest path between the packages gmsh and cunit:
+
+```
+guix graph --path gmsh cunit
+gmsh@4.6.0
+metis@5.1.0
+openblas@0.3.9
+cunit@2.1-3
+
+```
+
+Moreover, the command [`guix
+repl`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-repl.html)
+can now be passed a script which ease [package exploratinon in
+Guile](https://hpc.guix.info/blog/2020/01/reproducible-computations-with-guix/)
+especially when dealing with the new Scheme `(guix transformation)` module for
+package transformations.  And the section [“Programming
+Interface”](https://guix.gnu.org/manual/devel/en/html_node/Programming-Interface.html)
+of the *reference manual* has been greatly expounded.
+
+The [`guix
+pack`](https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-pack.html#Invoking-guix-pack)
+command creates “application bundles” that can be used to deploy software on
+machines that do not run Guix (yet!), such as HPC clusters. Since its
+[inception in
+2017](https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/), it has
+seen a number of improvements.  The relocatable packs can be now [faster by
+the addition of the Fakechroot
+engine](https://hpc.guix.info/blog/2020/05/faster-relocatable-packs-with-fakechroot/).
+
+
+# Packages
+
+Here are highlights among the 2,179 packages added and 4,487 packages
+upgraded since the previous release:
+
+ - 

Re: updating Jami to "Together", Qt update?

[Jan Wielkiewicz]

Dnia 2020-11-18, o godz. 20:17:54
Ryan Prior  napisał(a):

> On November 18, 2020, Pierre Neidhardt  wrote:
> > aviva  writes:
> >
> > > nobody i know uses it.  without a community of users, it has no
> > purpose
> >
> > There must always be a first user ;)
> 
> I use Jami regularly with a few adventurous friends who like peer-to-
> peer things. We often have to fall back to another video system like
> Jitsi to finish our calls, but keep returning for more punishment
> because we believe in the dream.
> 
> I have been specifically burned before by the Jami package in Guix. It
> hasn't played well with other Jami software; I started having better
> luck when I switched to using the Debian package. But if you get the
> Together release working well I'm absolutely down to give it another
> shot!

Remember you can always let me know if something doesn't work with my
package on this mailing list. I've never had luck with Jami to be honest
and bringing the package to the point where it is now was about 7
months of building it on my core 2 duo system, finding bugs, missing
dependencies, irreproducible bugs, etc. Stupid "DNDEBUG" flag pushed me
into another months of trying to figure out why audio calls were
crashing.

Did you try Jami from Guix before or after my updates? I mostly started
maintaining this package because it was 1. broken 2. building it from
source on a different distro gave strange effects.

Generally speaking I witnessed Jami (then Ring) going from absolutely
broken, unusable software to the point I can use it to chat with
friends, send files, etc. The last year of development fixed many
disgusting bugs.

Also remember that buggy routers and the unholy invention called NAT has
a big part of making Jami and generally p2p applications less usable.


Jan Wielkiewicz

Re: updating Jami to "Together", Qt update?

[Ryan Prior]

On November 18, 2020, Pierre Neidhardt  wrote:
> aviva  writes:
>
> > nobody i know uses it.  without a community of users, it has no
> purpose
>
> There must always be a first user ;)

I use Jami regularly with a few adventurous friends who like peer-to-
peer things. We often have to fall back to another video system like
Jitsi to finish our calls, but keep returning for more punishment
because we believe in the dream.

I have been specifically burned before by the Jami package in Guix. It
hasn't played well with other Jami software; I started having better
luck when I switched to using the Debian package. But if you get the
Together release working well I'm absolutely down to give it another
shot!

Re: updating Jami to "Together", Qt update?

[aviva]

On 11/18/20 1:11 PM, Jan Wielkiewicz wrote:
>> I wish I could find a reason to use it
>>
>>
> Works without a server, full p2p, can run in LAN without the Internet
> access, allows sending files p2p, allows audio/video calls,
> multi-platform, etc.


nobody i know uses it.  without a community of users, it has no purpose

GNU Guix 1.2.0rc2 available for testing!

[Ludovic Courtès]

Hello Guix!

Here’s the second and hopefully last release candidate for 1.2.0:

  source:
https://alpha.gnu.org/gnu/guix/guix-1.2.0rc2.tar.gz

  binary tarball (to install on a “foreign distro”):
https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc2.aarch64-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc2.armhf-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc2.i686-linux.tar.xz
https://alpha.gnu.org/gnu/guix/guix-binary-1.2.0rc2.x86_64-linux.tar.xz

  system installation:

https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc2.i686-linux.iso.xz

https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc2.x86_64-linux.iso.xz

  virtual machine image:
https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.2.0rc2.x86_64-linux.xz

SHA256 hashes:

  6d4cc24c6849e6d72b0ad8c0f7e32f668ff42e7fb226e828e201f837de0bbeb9  
guix-1.2.0rc2.tar.gz
  d6df60b839112cbbb6d8d1f87f644cc2752611fd6ce443bf361de4bd8c70df1e  
guix-binary-1.2.0rc2.aarch64-linux.tar.xz
  2528cf338fcf3e346225b0caa4bc1186964e01a86c0e7edcb44daea6384c791d  
guix-binary-1.2.0rc2.armhf-linux.tar.xz
  eb735373f526329d09452ed6a88c88b7cf432533677fe56b40a96a0d822b86b8  
guix-binary-1.2.0rc2.i686-linux.tar.xz
  f58248b6ea89ef1685826dd1e6ac2198771836cddf7449fd38d6242e03127bc9  
guix-binary-1.2.0rc2.x86_64-linux.tar.xz
  1a9aa981c271fc951ae8a4793599f6e52a1689f12b2923c26556c94e35230f3e  
guix-system-install-1.2.0rc2.i686-linux.iso.xz
  c90c5608f9926b6c6cacbf343757c2dcdb558062c3ddc92cb18c6c8df9874199  
guix-system-install-1.2.0rc2.x86_64-linux.iso.xz
  bd9048fe5d22c0ca318e8734cb18ec895d35d6da88ee6b909189e02895a65211  
guix-system-vm-image-1.2.0rc2.x86_64-linux.xz

All these files have an associated ‘.sig’, an OpenPGP signature that you
can verify as explained at
.

You can help by:

  1. Testing the binary tarball on the distro of your choice.  You can
 download .  Uncomment the
 ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
 should pick up 1.2.0rc2 automatically.

  2. Testing the graphical installer of Guix System.

  3. Testing the VM image.

In any case, please report success, failure, and annoyances in this thread.

If everything goes well, let’s release on Monday 23rd.

You can also check the ‘NEWS’ file and the draft blog post at

to make sure your favorite feature is mentioned and/or to discuss the
highlights in the blog post.

Thanks in advance!

Ludo’.


signature.asc
Description: PGP signature

Re: updating Jami to "Together", Qt update?

[Jan Wielkiewicz]

Dnia 2020-11-17, o godz. 21:06:44
aviva  napisał(a):

> On 11/17/20 8:45 PM, Jan Wielkiewicz wrote:
> > Hello everyone,
> >
> > I managed to compile the latest release of Jami and I'll be sending
> > patches soon.
> > Is anyone planning to update Qt to 5.15.1? It would be nice if Jami
> > used this version to stay close to upstream.
> > I can update it if no one plans that.
> >
> >
> > Jan Wielkiewicz
> >
> 
> 
> I wish I could find a reason to use it
> 
> 

Works without a server, full p2p, can run in LAN without the Internet
access, allows sending files p2p, allows audio/video calls,
multi-platform, etc.

Re: updating Jami to "Together", Qt update?

[Jan Wielkiewicz]

Dnia 2020-11-18, o godz. 09:10:52
Pierre Neidhardt  napisał(a):

> Hi Jan!
> 
> Jan Wielkiewicz  writes:
> 
> > I managed to compile the latest release of Jami and I'll be sending
> > patches soon.
> 
> Congrats and thanks again for your continuous effort!

Thanks.

> > Is anyone planning to update Qt to 5.15.1?
> 
> Not that I know of, Qt support is always welcome!

Well, I wouldn't call it a support because I have no idea about Qt
development/packaging nor I know how to fully test it, but I can bump
the version numbers and hope it compiles. I succesfully updated 3 Qt
packages Jami depends on in my private repo and it worked.


Jan Wielkiewicz

Re: Updating to latest Bioconductor release

[zimoun]

On Wed, 18 Nov 2020 at 17:33, Roel Janssen  wrote:

> Okay.  Then I'll look into it.  I currently have only these left as
> changed in my tree:
> - r-atacseqqc: Needs r-rhdf5lib.
> - r-cytoml: Needs r-rhdf5lib.
> - r-scater: Needs r-rhdf5lib.
> - r-scuttle (new package for r-scran): Needs r-rhdf5lib.
> - r-scran: Needs r-scuttle.

Now it rings a bell and I think you missed this email (and I forgot to
point you, sorry):

# NOT DONE
r-rhdf5lib: consider removing this native input: hdf5-source
r-rhdf5lib: consider removing this propagated input: hdf5

https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00047.html


> So it seems we are almost there.

Cool!


> I pushed the rest to the wip-r branch.

I will give a look on Friday.  Because of lockdown, today and
tomorrow, I have to be at the office and do some boring stuff with
physical access (plug/unplug, reboot, etc.)

Thanks,
simon

Re: Updating to latest Bioconductor release

[Roel Janssen]

On Wed, 2020-11-18 at 17:23 +0100, zimoun wrote:
> Hi Roel,
> 
> On Wed, 18 Nov 2020 at 17:13, Roel Janssen  wrote:
> 
> > I pushed updates and fixes for various packages. Now I'm at r-
> > rhdf5lib.
> 
> Cool!
> 
> 
> > In 38881c9368595c5a894abe3695d98aabb1ef0029 you updated it to
> > 1.12.0,
> > but it seems that building has changed quite a bit.  I wonder how
> > it
> > could've built for you?
> 
> I have not.  The idea proposed by Ricardo was to update everything
> and
> let Cuirass build.  BTW, I do not have enough power at hand to
> rebuild
> all the BioConductor packages.
> 

Okay.  Then I'll look into it.  I currently have only these left as
changed in my tree:
- r-atacseqqc: Needs r-rhdf5lib.
- r-cytoml: Needs r-rhdf5lib.
- r-scater: Needs r-rhdf5lib.
- r-scuttle (new package for r-scran): Needs r-rhdf5lib.
- r-scran: Needs r-scuttle.

So it seems we are almost there.

I pushed the rest to the wip-r branch.

Kind regards,
Roel Janssen

Re: Updating to latest Bioconductor release

[zimoun]

Hi Roel,

On Wed, 18 Nov 2020 at 17:13, Roel Janssen  wrote:

> I pushed updates and fixes for various packages. Now I'm at r-
> rhdf5lib.

Cool!


> In 38881c9368595c5a894abe3695d98aabb1ef0029 you updated it to 1.12.0,
> but it seems that building has changed quite a bit.  I wonder how it
> could've built for you?

I have not.  The idea proposed by Ricardo was to update everything and
let Cuirass build.  BTW, I do not have enough power at hand to rebuild
all the BioConductor packages.

Thank you for working on it.

All the best,
simon

Re: Updating to latest Bioconductor release

[Roel Janssen]

Hi Simon,

On Wed, 2020-11-18 at 12:50 +0100, zimoun wrote:
> Hi Roel,
> 
> On Wed, 18 Nov 2020 at 10:31, Roel Janssen  wrote:
> 
> > I fixed the build issue with r-delayedarray and a couple of others
> > on
> > my local machine.  I also updated the bioconductor version variable
> > to
> > 3.12.  Can I push these changes to the "wip-r" branch, along with
> > updates of the many packages involved?
> 
> Please go ahead.  Then Berlin will rebuild all since it tracks the
> branch wip-r.

I pushed updates and fixes for various packages. Now I'm at r-
rhdf5lib. 

In 38881c9368595c5a894abe3695d98aabb1ef0029 you updated it to 1.12.0,
but it seems that building has changed quite a bit.  I wonder how it
could've built for you?

Kind regards,
Roel Janssen

Re: Releasing guix binary in Docker format too?

[zimoun]

Hi,

Thank you for your feedback.

On Wed, 18 Nov 2020 at 14:53, Ryan Prior  wrote:

>>  Multiple isolated environments on a single host
>>  Preserve volume data when containers are created
>>  Only recreate containers that have changed
>>  Variables and moving a composition between environments

[...]

> For example, a common thing I do with docker-compose is to provide a compose 
> file with a service I'm working on that brings up the service with all its 
> dependencies (eg databases,  proxies, etc.) in a dev configuration, with the 
> source code from the repository mapped into the container and live-reload 
> enabled. That creates a "two-step" dev environment for the service: you clone 
> the repo then run "docker-compose up."

Do you have configuration files of minimal examples?  Just to
understand what you mean using concrete examples.


> Hashicorp has been working on Waypoint[1], a free software tool to extend 
> that concept even further by adding deployment and release capabilities. Now 
> you clone a repo and you have one tool to build, deploy and release the 
> software contained therein.
>
> I'm interested to use Guix for similar purposes, but there are a few primary 
> obstacles in the way:
> 1) I don't have enough experience yet defining systems using Guix similar to 
> what I'd define using docker-compose, and I haven't found documentation or 
> examples yet that makes it seem within reach
> 2) The machines I'm deploying to run Kubernetes, not Guix System, so if I do 
> use Guix to build a bundle for deployment its utility ends when I export to a 
> Docker container image.

Thanks for pointing this out.

> 3) I collaborate with developers who use macOS and Windows and so can't 
> easily install and use Guix.

I speak for myself, the idea is to build Docker images using Guix for this case.

Otherwise, I do not know if it is worth but someone pointed this [1]
for Windows.

1: 


All the best,
simon

Re: Releasing guix binary in Docker format too?

[Ryan Prior]

On November 18, 2020, Bengt Richter  wrote:
> E.g., (quoted from [1]), does the following mean that the guix daemon
> potentially could run "projects"
> instead of guixbuilder* to create "Multiple isolated environments on a
> single host" ?
> The features of Compose that make it effective are:
>
>  Multiple isolated environments on a single host
>  Preserve volume data when containers are created
>  Only recreate containers that have changed
>  Variables and moving a composition between environments

I love docker-compose and have used it every day. There are a bunch of
workflows I use compose for that I haven't figured out how to replace
with Guix yet, and I'm not in a huge hurry, but it would be great to see
features that are designed to appeal to Compose users.

For example, a common thing I do with docker-compose is to provide a
compose file with a service I'm working on that brings up the service
with all its dependencies (eg databases,  proxies, etc.) in a dev
configuration, with the source code from the repository mapped into the
container and live-reload enabled. That creates a "two-step" dev
environment for the service: you clone the repo then run "docker-compose
up."

Hashicorp has been working on Waypoint[1], a free software tool to
extend that concept even further by adding deployment and release
capabilities. Now you clone a repo and you have one tool to build,
deploy and release the software contained therein.

I'm interested to use Guix for similar purposes, but there are a few
primary obstacles in the way:
1) I don't have enough experience yet defining systems using Guix
similar to what I'd define using docker-compose, and I haven't found
documentation or examples yet that makes it seem within reach
2) The machines I'm deploying to run Kubernetes, not Guix System, so if
I do use Guix to build a bundle for deployment its utility ends when I
export to a Docker container image.
3) I collaborate with developers who use macOS and Windows and so can't
easily install and use Guix.

[1] https://www.waypointproject.io/

Re: Releasing guix binary in Docker format too?

[Bengt Richter]

Hi,

On +2020-11-17 17:38:09 +0100, Danny Milosavljevic wrote:
> Hi,
> 
> On Sun, 15 Nov 2020 19:30:44 +0100
> zimoun  wrote:
> 
> > $ docker exec guix guix pack hello
> > user with UID 0 not found
> 
> Docker needs to generate a /etc/passwd with uid 0 and the guix build user 
> accounts, and a /etc/group with the guixbuild group; and whatever other users 
> the things that are composed together using docker compose[1] require.  How 
> does this work in Docker-land ?
>
How much would change if the guix daemon were implemented a little differently?
E.g., (quoted from [1]), does the following mean that the guix daemon 
potentially could run "projects"
instead of guixbuilder* to create "Multiple isolated environments on a single 
host" ?

Is it suggestive to anyone else?

--8<---cut here---start->8---
The features of Compose that make it effective are:

Multiple isolated environments on a single host
Preserve volume data when containers are created
Only recreate containers that have changed
Variables and moving a composition between environments

Multiple isolated environments on a single host

Compose uses a project name to isolate environments from each other. You can 
make use of this project name in several different contexts:

on a dev host, to create multiple copies of a single environment, such as 
when you want to run a stable copy for each feature branch of a project
on a CI server, to keep builds from interfering with each other, you can 
set the project name to a unique build number
on a shared host or dev host, to prevent different projects, which may use 
the same service names, from interfering with each other

The default project name is the basename of the project directory. You can set 
a custom project name by using the -p command line option or the 
COMPOSE_PROJECT_NAME environment variable.
--8<---cut here---end--->8---
[...]
> 
> The question is: since Docker supports composition[1], how do they handle 
> this standard case ?  How can we get Docker to generate /etc/services, 
> /etc/passwd and /etc/group for the composed docker image ?
>
I guess this question would morph if guixbuilder*  became "projects",
where "you can set the project name to a unique build number".
[...]
> 
> [1] https://docs.docker.com/compose/
-- 
Regards,
Bengt Richter

Re: Updating to latest Bioconductor release

[zimoun]

Hi Roel,

On Wed, 18 Nov 2020 at 10:31, Roel Janssen  wrote:

> I fixed the build issue with r-delayedarray and a couple of others on
> my local machine.  I also updated the bioconductor version variable to
> 3.12.  Can I push these changes to the "wip-r" branch, along with
> updates of the many packages involved?

Please go ahead.  Then Berlin will rebuild all since it tracks the
branch wip-r.

All the best,
simon

Re: [PATCH] Automatically set `geiser-guile-load-path' from .dir-locals

[Miguel Ángel Arruga Vivas]

Hello Maxim,

Maxim Cournoyer  writes:

> Hello Miguel,
>
> Miguel Ángel Arruga Vivas  writes:
>
>> Hi!
>>
>> Christopher Lemmer Webber  writes:
>> [...]
>>> It sounds like you're already putting together the work to do it.  If
>>> you don't mind doing it that would save me a lot of time right
>>> now... I'm quite swamped!  I'd be very grateful!
>>
>> No problem, I just didn't want to end up with two reports for the same
>> issue.  It's already open as .
>
> Woo!  That was quick!

Well, I wouldn't call it quick, as I wanted to pin-point at least the
issue, but it took me a long time to even trim the reproducer.
Christopher mail really was a heads up to at least report the bug to
Emacs people.

> I've tested the repro script and could reproduce for the first time (the
> steps must be followed scrupulously otherwise just changing buffer can
> cause the bad behavior to disappear)!

Thank you for the confirmation.

> Thank you for the efficiency with which you handled the issue, it's much
> appreciated.

You're welcome.  Nonetheless, I wish I already had a solution... :-(

Happy hacking!
Miguel

Re: Updating to latest Bioconductor release

[Roel Janssen]

On Tue, 2020-11-17 at 23:58 +0100, zimoun wrote:
> Hi Roel,
> 
> Just to let you know:
> 
>   
> 
> I think the failure is coming from IO on the Berlin machine.
> 
> Are you building this branch too?

I fixed the build issue with r-delayedarray and a couple of others on
my local machine.  I also updated the bioconductor version variable to
3.12.  Can I push these changes to the "wip-r" branch, along with
updates of the many packages involved?

I still have about 30 packages to fix the build for before we can
consider merging to master.

Kind regards,
Roel Janssen

Re: Why unrelated package trigger rebuild?

[zimoun]

Hi,

For the interested reader, a quick cross-reference.


On Fri, 09 Oct 2020 at 03:35, zimoun  wrote:

> From the Data Service:
>
> 
>
> the commit 39222080911eaf3d7f74effe4467c1a04464aef3 which is about the
> addition of the package ’dkgpg’ modifies the hash of the package
> ’ghc-haddock’ from:
>
>   /gnu/store/s7s3ksfhkdbb6k6si8bjnxy8vvywv322-ghc-haddock-2.22.0
>
> to:
>
>   /gnu/store/j5llszq1cf12qn79bvhc042wc06ibfix-ghc-haddock-2.22.0
>
> Well, I miss why the addition of one package changes the hash of another
> unrelated one?  Is it expected?

The correct answer is because the Data Service deals with “state”
message of the mailing list guix-commits.  Where “state” means bunch of
commits pushed in a row.  Therefore, somehow it is expected.  However,
is it the behaviour we want is another question? :-)


Explanations are here:

   

and chat on IRC starting here:




All the best,
simon

Re: updating Jami to "Together", Qt update?

[Pierre Neidhardt]

Hi Jan!

Jan Wielkiewicz  writes:

> I managed to compile the latest release of Jami and I'll be sending
> patches soon.

Congrats and thanks again for your continuous effort!

> Is anyone planning to update Qt to 5.15.1?

Not that I know of, Qt support is always welcome!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature