Re: 09/09: lint: Append "/info/refs" to git-reference-url.

[Maxim Cournoyer]

Hello,

guix-comm...@gnu.org writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit c9af27d4ca733b20f09019f1465d3e5fdc1ec724
> Author: Felix Lechner 
> AuthorDate: Mon Mar 20 21:25:41 2023 -0700
>
> lint: Append "/info/refs" to git-reference-url.
> 
> For the atftp package added in the preceeding commit, lint produced this
> warning:

After this fix, I'm now seeing warnings from Github, e.g.:

--8<---cut here---start->8---
gnu/packages/rails.scm:675:2: ruby-activejob@7.0.4.3: scheduled Software 
Heritage archival
gnu/packages/rails.scm:282:2: ruby-activemodel@7.0.4.3: URI 
https://github.com/rails/rails/info/refs not reachable: 403 ("Forbidden")
gnu/packages/rails.scm:282:2: ruby-activemodel@7.0.4.3: scheduled Software 
Heritage archival
gnu/packages/rails.scm:309:2: ruby-activerecord@7.0.4.3: URI 
https://github.com/rails/rails/info/refs not reachable: 403 ("Forbidden")
gnu/packages/rails.scm:309:2: ruby-activerecord@7.0.4.3: Software Heritage rate 
limit reached; try again later
gnu/packages/rails.scm:714:2: ruby-activestorage@7.0.4.3: URI 
https://github.com/rails/rails/info/refs not reachable: 403 ("Forbidden")
gnu/packages/rails.scm:52:2: ruby-activesupport@7.0.4.3: URI 
https://github.com/rails/rails/info/refs not reachable: 403 ("Forbidden")
gnu/packages/rails.scm:837:2: ruby-ammeter@1.1.5: source not archived on 
Software Heritage and missing from the Disarchive database
gnu/packages/ruby.scm:6134:12: ruby-arr-pm@0.0.12: source not archived on 
Software Heritage and missing from the Disarchive database
gnu/packages/ruby.scm:9336:12: ruby-aruba@2.1.0: URI 
https://github.com/cucumber/aruba/info/refs not reachable: 403 ("Forbidden")
gnu/packages/rails.scm:235:12: ruby-autoprefixer-rails@10.4.13.0: URI 
https://github.com/ai/autoprefixer-rails/info/refs not reachable: 403 
("Forbidden")
gnu/packages/ruby.scm:3995:12: ruby-bake@0.18.2: URI 
https://github.com/ioquatix/bake/info/refs not reachable: 403 ("Forbidden")
--8<---cut here---end--->8---

I've reverted it for now.

-- 
Thanks,
Maxim

Re: Automatically mapping services from System to Home

[Bruno Victal]

Hi Ludo’,

On 2023-03-28 17:18, Ludovic Courtès wrote:
> One idea I toyed with is automatic translation of service types from
> System to Home.  The service itself would look like this:
> 
> --8<---cut here---start->8---
> (define-module (gnu home services syncthing)
>   #:use-module (gnu home services)
>   #:use-module (gnu services syncthing)
>   #:export (home-syncthing-service-type)
>   #:re-export (syncthing-configuration
>syncthing-configuration?))
> 
> (define home-syncthing-service-type
>   (system-service-type->home-service-type syncthing-service-type))
> --8<---cut here---end--->8---
> 
> The code to do that is attached below.  The key here is that we’d define
> mappings, like:
> 
>   (define-service-type-mapping
> shepherd-root-service-type => home-shepherd-service-type)
> 
> The rest of the service type graph would be automatically constructed
> from this.
> 
> I feel like it would be worth pursuing this path so that there’s as
> little duplication as possible between Home and System.
> 
> OTOH, it doesn’t take care of things like #:user in
> ‘make-forkexec-constructor’ calls and the like.
> 

I've been thinking that shepherd services should, in general, come with a
preamble in their configuration record-types. (perhaps à la SRFI-136 
parent-style records?)

Below is a non-exhaustive list of “things” that should almost always be 
configurable,
unless it's reasonable to omit it:

--8<---cut here---start->8---
;; These fields were listed based on “experience” in reworking,
;; repurposing and adding new (system) services within Guix.


(define-configuration example-configuration
  ;; Allow the package to be overridden.
  (package
file-like
"Lorem ipsum …")

  ;; Note that they're not strings. This allows for tailoring
  ;; the user-account used by the service (e.g. adding extra groups
  ;; for the daemon to have access to other directories, etc.
  (user
user-account
"Lorem ipsum …")

  ;; ^ Ditto.
  (group
   user-group
   "Lorem ipsum …")

  (shepherd-requirement   ; or shepherd-requirements, the former already has 
some presence in Guix
  ; but could be phased-out in favor of the plural form
list-of-symbols
"Lorem ipsum …")

  ;; Uncommonly seen among services
  ;; but mpd-service-type is an example where this is important.
  (environment-variables
list-of-env-vars
"Lorem ipsum …")

--8<---cut here---end--->8---


Tossing another idea in the air, with 
define-configuration could perhaps be enriched with additional parameters to 
hint that certain fields should be treated differently depending
on “context”? Naturally the service code will have to be adjusted
to use these hints, but overall it should result in a much cleaner
way to guide serializations and service-extension pruning.


It could be something of the sort:

--8<---cut here---start->8---
(define-configuration example-configuration
  …

  (user
user-account
"Lorem ipsum …"
   (attributes 'system-service)
  …)

;; or
(define-configuration example-configuration
  …

  (user
user-account
"Lorem ipsum …"
system-only
  …)


;; or
(define-configuration example-configuration
  …

  (user
user-account
"Lorem ipsum …"
(system #t)
(home #f)
  …)
--8<---cut here---end--->8---


Cheers,
Bruno

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Hello Maxim!

Am Wed, Mar 29, 2023 at 08:32:08AM -0400 schrieb Maxim Cournoyer:
> I'll
> gladly volunteer to do the tricky merge after staging is merged into
> master (and removed).

Great, thanks! It should be quite feasible when paying attention to this
special case, but I only did a merge once and do not feel confident about it.

Concerning kcodecs, attached is a patch that disables the test (but keeps
the class in that is supposed to work around the fixed Qt bug; so it is
quite possible that this class is wrong currently). However I did compile
a KDE program with it and launched it successfully, so I would be in favour
of applying the patch to staging (and thus later merge it to core-updates).
What do you think?

Apart from this, all of my profile is built (and available through CI),
so I would be happy with the merge.

Andreas

>From f8694bf4f32ea8f817fbc32abe28de52472b61f4 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Andreas Enge 
Date: Wed, 29 Mar 2023 14:50:49 +0200
Subject: [PATCH] gnu: kcodecs: Disable obsolete test.

* gnu/packages/patches/kcodecs-5.98-drop-test.patch: New file.
* gnu/packages/kde-frameworks.scm (kcodecs): Add patch.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
 gnu/local.mk  |  1 +
 gnu/packages/kde-frameworks.scm   |  3 ++-
 .../patches/kcodecs-5.98-drop-test.patch  | 20 +++
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kcodecs-5.98-drop-test.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 65662f8667..45c786f136 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1397,6 +1397,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/lightdm-vncserver-check.patch   \
   %D%/packages/patches/lightdm-vnc-color-depth.patch   \
   %D%/packages/patches/localed-xorg-keyboard.patch \
+  %D%/packages/patches/kcodecs-5.98-drop-test.patch\
   %D%/packages/patches/kcontacts-incorrect-country-name.patch  \
   %D%/packages/patches/kde-cli-tools-delay-mime-db.patch   \
   %D%/packages/patches/kdiagram-Fix-missing-link-libraries.patch \
diff --git a/gnu/packages/kde-frameworks.scm b/gnu/packages/kde-frameworks.scm
index 10b8ac0134..65c4ccb4f4 100644
--- a/gnu/packages/kde-frameworks.scm
+++ b/gnu/packages/kde-frameworks.scm
@@ -532,7 +532,8 @@ (define-public kcodecs
 name "-" version ".tar.xz"))
   (sha256
(base32
-"0n10r7s9r25xp7vlym41qi421kld00niig73yark7yghj0r41jcz"
+"0n10r7s9r25xp7vlym41qi421kld00niig73yark7yghj0r41jcz"))
+  (patches (search-patches "kcodecs-5.98-drop-test.patch"
 (build-system cmake-build-system)
 (native-inputs
  (list extra-cmake-modules gperf qttools-5))
diff --git a/gnu/packages/patches/kcodecs-5.98-drop-test.patch 
b/gnu/packages/patches/kcodecs-5.98-drop-test.patch
new file mode 100644
index 00..fbb9bf42bc
--- /dev/null
+++ b/gnu/packages/patches/kcodecs-5.98-drop-test.patch
@@ -0,0 +1,20 @@
+diff -u -r kcodecs-5.98.0.alt/autotests/CMakeLists.txt 
kcodecs-5.98.0/autotests/CMakeLists.txt
+--- kcodecs-5.98.0.alt/autotests/CMakeLists.txt2023-03-29 
12:40:12.904883966 +0200
 kcodecs-5.98.0/autotests/CMakeLists.txt2023-03-29 12:40:28.952883548 
+0200
+@@ -25,16 +25,6 @@
+ LINK_LIBRARIES KF5::Codecs Qt${QT_MAJOR_VERSION}::Test ${_qt5_compat_libs}
+ )
+ 
+-ecm_add_test(
+-${CMAKE_SOURCE_DIR}/src/kusasciitextcodec.cpp
+-kusasciitextcodectest.cpp
+-TEST_NAME kusasciitextcodectest
+-LINK_LIBRARIES Qt${QT_MAJOR_VERSION}::Test ${_qt5_compat_libs}
+-)
+-target_include_directories(kusasciitextcodectest
+-PRIVATE "${CMAKE_SOURCE_DIR}/src"
+-)
+-
+ # Benchmark, compiled, but not run automatically with ctest
+ add_executable(base64benchmark base64benchmark.cpp)
+ target_link_libraries(base64benchmark KF5::Codecs Qt${QT_MAJOR_VERSION}::Test)
-- 
2.39.2

guix system container -r: write to profile?

[Ricardo Wurmus]

Hi Guix,

“guix system container” produces a launcher script.  I would really like
to have a nicer name for it, so I use “-r” to link it to a well-known
location.  But I can only do this once as the link name will be in use
the second time I run this.

I’d much rather like to have a proper profile with roll backs.  Would it
be a good idea to either extend “--root” to manage a symlink forest
(instead of just creating a single link) or to extend “guix system
container” to add its generated launcher script to a profile’s bin
directory?

-- 
Ricardo

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Maxim Cournoyer]

Hi Andreas!

Andreas Enge  writes:

> Hello,
>
> Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
>> I've updated the following dependencies in a group (to try to make
>> things a bit more efficient) on the staging branch; the motivation
>> originally stemmed from the latest Jami now requiring FFmpeg 6.
>
> that sounds good if it means we will get rid of the branch for good soon :-)
> Otherwise I think it would have been better to work on merging staging and
> core-updates and then use a feature branch.

Yeah, I was thinking about removing the staging branch afterward, to
encourage the new teams workflow.

> However I am a bit afraid of repercussions on core-updates (originally I
> had planned to first merge back staging into master, but somehow we ended
> up working on core-updates first...). I have no idea what is the ordering
> between packages in master, staging and core-updates - it may well be
> possible that some packages are newer in staging, others in core-updates.
> Or that they are the same in both, but with different patches.
> For instance, I also updated qt to 5.15.8 on core-updates, but differently,
> using a global version variable for making sure to update everything at
> once. I think this is preferable. In any case, merging this will be a bit
> difficult to sort out without mixing bits from the two parts.
> So it would be nice if you could carefully merge master into core-updates
> after the staging merge.

Apologies for not noticing about the Qt update on core-updates; the
change was motivated by the open reports on our bug-guix tracker.  I'll
gladly volunteer to do the tricky merge after staging is merged into
master (and removed).  The reason I opted to keep the version
per-package instead of in a %qt5-version global variable was initially
for tooling; 'guix refresh --update' doesn't work otherwise; but then I
noticed that it doesn't work anyway with the 'qt-urls' scheme (it
doesn't find a newer release), so I guess I'll keep your approach here.

> A typo in the title confused me, but it is gstreamer@1.22.1 instead of
> @2.22, which is hopefully less of a change ;-)

Eh :-).  Yes, it's 1.22.1.

> Concerning ffmpeg, we now have 5 different versions of it; @2, @3 and @5
> have almost no dependents, @4 and @6 have many. It would be nice to sort
> this out later and hopefully drop most of them.

Agreed; the 5 to 6 transition is advertised as very uneventful (outside
of Mozilla stuff), with only a few deprecated bits that may cause
problems, such as:

1. 
https://github.com/FFmpeg/FFmpeg/commit/dd846bc4a9163f875cc2c4e99325c1a7b4ab8e7d
2. 
https://github.com/FFmpeg/FFmpeg/commit/8f72bb866e47bcb57586608086c77cf0a2e2f21a

Which easily fixed with a simple substitution, so hopefully we can get
rid of ffmpeg@5 soon.

-- 
Thanks,
Maxim

Re: Hello GUIX

[pukkamustard]

Hi Shivam,

Welcome to Guix! I think that Sneakernet-esque distribution of
substitutes is very interesting and something that was also talked about
at the Guix Days before FOSDEM 23 (Guix with no internet and air-gapped
machines).

Some comments on the proposal:

- You might want to refer to the document "SQLite for ERIS block
  storage" (https://eris.codeberg.page/eer/sqlite.xml).

- I think the user experience as described in the proposal could be
  improved/might not quite work as expected:

  - Reading from a disk maybe should happen automagically if it can be
detected (and is enabled in some configuration). This might also
require some integration with udisks. The complexity of this should
not be underestimated.

  - Writing packages to a USB stick seems to be closer to a `guix
publish` or `guix deploy`. Maybe you can read up on those commands
and think of a nice way to publish or deploy a set of packages to a
USB stick. This is also relevant for publishing to other p2p
networks (IPFS, GNUnet, etc.).

- Maybe the Narinfos also need to packed onto the USB drive? How would
  an air-gapped computer otherwise know which substitute to get? Also
  have a look at the nar-herder tool
  (https://git.cbaines.net/guix/nar-herder) by Christopher Baines (in
  CC).

-pukkamustard

Shivam Madlani  writes:

> Hey everyone!
> I am Shivam Madlani, an undergraduate at DAIICT, India. I want to participate 
> in GSoC'23 for The GNU
> organization. The project "Decentralized substitute distribution" in GUIX 
> amused me and I want to
> apply for the same. I have been in touch with the project mentor 
> -pukkamustard for over a month
> now and started learning more about the project. I'm very excited to work on 
> this project as it lies in
> my interests.
>
> I've drafted a proposal on this project and I aim to add a transport 
> protocol-Sneakernet. This will allow
> the substitutes to be air-gappable. My approach is to use SQLite to store the 
> ERIS encoded substitute
> in the external drive using a custom schema. This is just a brief overview of 
> the project and more
> details are included in the attached proposal.
>
> I would love to hear your thoughts and reviews on my proposal and hopefully 
> improve it by filling in
> any missing key points.
>
> Thank you,
> Shivam
>
> [4. application/pdf; GSoC'23 GUIX proposal.pdf]...

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:53:22AM +0200 schrieb Andreas Enge:
> The file was removed in commit
> commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a
> Author: Volker Krause 
> Date:   Sun Feb 19 20:15:29 2023 +0100
> Remove QTextCodec leftovers
> This is all unused internal API now.
> of kcodecs, together with lots of other changes (wc shows 944 lines).

> It is not part of the latest kcodecs release 5.104.0, made after the commit.

Sorry, this is not what I mean:
The *commit* is not part of the latest release,
so the *file* is still present in the latest release.
It is thus not enough to simply update kcodecs (and I do not know to which
extent this would even be feasible inside KDE, or whether we would need to
update everything at once; probably the latter).

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values 
> are not the same
>Actual   (failConverterState.invalidChars): 1
>Expected (0)  : 0
>Loc: 
> [/tmp/guix-build-kcodecs-5.98.0.drv-0/kcodecs-5.98.0/autotests/kusasciitextcodectest.cpp(56)]
> 86% tests passed, 1 tests failed out of 7

Looking at the file, it is a workaround for this Qt bug:
   https://bugreports.qt.io/browse/QTBUG-83081
which was fixed in 5.17.0.

The file was removed in commit
commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a
Author: Volker Krause 
Date:   Sun Feb 19 20:15:29 2023 +0100
Remove QTextCodec leftovers
This is all unused internal API now.
of kcodecs, together with lots of other changes (wc shows 944 lines).

It is not part of the latest kcodecs release 5.104.0, made after the commit.

I do not know whether it would be safe to just disable the test for the
time being.

Andreas

Re: [GSoC 23] distributed substitutes, cost of storage

[pukkamustard]

Vijaya Anand  writes:

> Sorry for the late reply.
> So in the case we are running swarm nodes that serves the network and hence 
> help fund the substitute server, we can also use these
> to also upload eris encoded substitute blocks onto the network am I right? 
> The total cost will thus be cost to run the swarm nodes +
> storage cost of substitute blocks in the network + cost to run substitute 
> servers - money earned by running swarm nodes. But when
> we don't run swarm nodes which run to serve the network, the total cost is 
> not really affect right as the cost to run swarm nodes will
> be lessened and no money will be earned. 
> So in the context of fallback mechanism the user client can send request to 
> the substitute server for the missing block and the
> substitute server will serve the eris encoded data block back to the user 
> (using HTTP). The responsibility of uploading these missing
> blocks back to the network is of the third party nodes (which are running to 
> serve the desired content to the network). But how do we
> send the message to the node to report the missing block on the network? Can 
> it be done by the user itself?

Some remarks:

- Maybe we don't need to do too much of an economic cost estimation, the
  current p2p networks (blocks over HTTP and IPFS) as well as ones that
  will quite possibly work soonish (GNUnet) do not incur any additional
  monetary storage cost. I think we should focus on resource usage
  (memory, disk, network) of users, servers and caching peers instead.

- One fallback strategy we absolutely need is to use get a substitute
  using the existing mechanism (substitute is a single nar file that is
  retrieved over HTTP without ERIS or any other p2p stuff).

- I like the principle "Think globally, act locally". Maybe users
  downloading substitutes who want to improve access to substitutes over
  p2p should only try to do so withing the scope of what they can do
  locally. I.e. by making the blocks available on the p2p network from
  the local machine. For IPFS and GNUnet this works very well and
  elimintates necessity of more RPC endpoints.

> "i can dream about a future where there's a social network that is based on 
> digital signatures and encryption, and my Guix client
> authorizes compiled binaries based on some weighted transitive closure of 
> signatures of my trusted peers"Interesting! In the case
> of accessing Guix substitutes from p2p network, we ensure authorization by 
> Guix team by making sure the urn of the substitute is the
> urn mentioned in the narinfo (which we get from a trusted source like the 
> substitute server). So in the case of accessing some random
> compiled binary from the network, we just need to verify the authority of the 
> document providing the urn of the content?

This is a very nice vision, that I share! However, maybe we should keep
it out of scope from the GSoC project and rely on the existing signature
mechanism for authenticity.

A web-of-trust like system for substitute system would be an excellent
and very interesting follow-up project.

-pukkamustard

> On Mon, 27 Mar 2023 at 2:49 AM Attila Lendvai  wrote:
>
>  > Also I didn't really think about the point about having to pay for
>  > the p2p services at some point of time.
>
>  a quick note here: i forgot to mention that e.g. the Swarm Foundation has 
> programs for supporting opensource projects. so,
>  chances are high that the storage needs for Guix would be paid for by the 
> foundation.
>
>  > In this case we will have to pay for the storage of substitutes both
>  > on the p2p storage backend as well as for storage in the substitute
>  > server am I right?
>
>  well, the substitute servers are currently already operated (and paid for) 
> by the Guix team. i don't think that p2p storage solutions
>  have reached a point of maturity that we could rely on them alone. there 
> should definitely be some time where both
>  infrastructures are running in parallel. somewhere down the road a choice 
> could be made to stop running the current substitute
>  servers, but we are far away from that.
>
>  also, running swarm nodes that serve the network can earn money. so, the 
> cost of running enough swarm nodes to pay for the
>  storage needs of Guix on the swarm network should be in the same ballpark of 
> the costs of running the current substitute servers.
>  the storage price will be market based (this part is just being rolled out 
> on the live network), so it's reasonable to expect that
>  people will fire up nodes if the storage price go well above the VPS costs.
>
>  and not all p2p storage networks are made equal. e.g. IPFS is only a 
> registry of who is serving what. if you want to keep your data
>  alive on IPFS, then you need to run some nodes and make sure that they are 
> serving the content that you care about... and bear
>  the costs of running these nodes. i.e. the DoS attack surface of IPFS is 
> much smaller. (IPFS stores only the 

Re: [GSoC 23] distributed substitutes, cost of storage

[pukkamustard]

Andreas Enge  writes:

> Hello,
>
> Am Wed, Mar 29, 2023 at 01:49:23AM +0530 schrieb Vijaya Anand:
>> In the case of accessing Guix substitutes from p2p
>> network, we ensure authorization by Guix team by making sure the urn of the
>> substitute is the urn mentioned in the narinfo
>
> no, currently substitutes are authenticated by a digital signature with one
> of the substitute servers (the user has control over which signing keys are
> accepted, see /etc/guix/acl). It happens after the download.
>

Slight ellaboration:

Currently the official Guix substitute servers provide a signed Narinfo
that contains the SHA256 sum of the substitute. The SHA256 sum of a
downloaded substitute is checked to match what is in the signed
Narinfo.

With the ERIS patches (https://issues.guix.gnu.org/52555) the signed
Narinfo also contains the ERIS URN. When getting a substitute this
signed ERIS URN is used. Decoding content from an ERIS URN guarantees
integrity, thus we also have authenticity.

Nevertheless, we still compute the SHA256 sum and check it. This is not
really necessary for ensuring authenticity but, imho, good practice for
now to be really sure we only use authenticated substitutes. Especially
when developing transparent fallback mechanisms that might go back to
just downloading the entire substitute from HTTP.

-pukkamustard

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values 
> are not the same

We are not the only ones:
   https://bugs.gentoo.org/885615
for version 5.99, but there is no patch.

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> It'd be useful if people tested it by reconfiguring their systems with
> it or updating their profiles, and report any issues

Supposedly the Qt update breaks kcodecs, which in turn breaks most of KDE.
This issue is also present on core-updates, so sorting it out would be
really helpful!

Apart from that all packages in my profile build.

Andreas

FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values are 
not the same
   Actual   (failConverterState.invalidChars): 1
   Expected (0)  : 0
   Loc: 
[/tmp/guix-build-kcodecs-5.98.0.drv-0/kcodecs-5.98.0/autotests/kusasciitextcodectest.cpp(56)]
86% tests passed, 1 tests failed out of 7

Total Test time (real) =   2.58 sec

The following tests FAILED:
  7 - kusasciitextcodectest (Failed)
Errors while running CTest
make: *** [Makefile:139: test] Error 8

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test" "-j" "4") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 2.6 seconds
command "make" "test" "-j" "4" failed with status 2
builder for `/gnu/store/hj533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv' 
failed with exit code 1
build of /gnu/store/hj533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv failed
View build log at 
'/var/log/guix/drvs/hj/533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv.gz'.

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Hello,

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> I've updated the following dependencies in a group (to try to make
> things a bit more efficient) on the staging branch; the motivation
> originally stemmed from the latest Jami now requiring FFmpeg 6.

that sounds good if it means we will get rid of the branch for good soon :-)
Otherwise I think it would have been better to work on merging staging and
core-updates and then use a feature branch.

However I am a bit afraid of repercussions on core-updates (originally I
had planned to first merge back staging into master, but somehow we ended
up working on core-updates first...). I have no idea what is the ordering
between packages in master, staging and core-updates - it may well be
possible that some packages are newer in staging, others in core-updates.
Or that they are the same in both, but with different patches.
For instance, I also updated qt to 5.15.8 on core-updates, but differently,
using a global version variable for making sure to update everything at
once. I think this is preferable. In any case, merging this will be a bit
difficult to sort out without mixing bits from the two parts.
So it would be nice if you could carefully merge master into core-updates
after the staging merge.

A typo in the title confused me, but it is gstreamer@1.22.1 instead of
@2.22, which is hopefully less of a change ;-)

Concerning ffmpeg, we now have 5 different versions of it; @2, @3 and @5
have almost no dependents, @4 and @6 have many. It would be nice to sort
this out later and hopefully drop most of them.

Andreas

Re: [GSoC 23] distributed substitutes, cost of storage

[Andreas Enge]

Hello,

Am Wed, Mar 29, 2023 at 01:49:23AM +0530 schrieb Vijaya Anand:
> In the case of accessing Guix substitutes from p2p
> network, we ensure authorization by Guix team by making sure the urn of the
> substitute is the urn mentioned in the narinfo

no, currently substitutes are authenticated by a digital signature with one
of the substitute servers (the user has control over which signing keys are
accepted, see /etc/guix/acl). It happens after the download.

And see
   
https://guix.gnu.org/en/manual/devel/en/guix.html#Substitute-Server-Authorization
 .

Andreas