gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging
Hi, 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. It'd be useful if people tested it by reconfiguring their systems with it or updating their profiles, and report any issues, as I'd like to merge this branch into master in about a week time, if there are no blockers. -- Thanks, Maxim
Re: bug#62244: [PATCH] etc: Add gnome team.
Hello,
Liliana Marie Prikler writes:
> * etc/teams.scm.in (gnome): New team.
> ("Liliana Marie Prikler"): Add to gnome.
> ---
> Hi folks,
>
> to get effort for GNOME 44 rolling while also recognizing the burden this
> puts on folks, I've decided to add a gnome team to our teams.scm.
>
> To those in Debbugs CC – you know who you are ;) – I've added you to CC,
> because you've contributed changes to the mentioned scope since 2022.
> If you'd like to be added to the team from the first commit, please
> reply; otherwise feel free to add yourself at your convenience.
LGTM. Count me in too!
--
Thanks,
Maxim
Re: [GSoC 23] distributed substitutes, cost of storage
Hi, 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? "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? "i value consensual relationships, and that implies that the other party is well informed. and clogging someone's network bandwidth is not an expected behavior from installing a linux distribution." I agree with this point and also since there are already specialised nodes doing the work of uploading blocks onto the network I guess for now it is better to assign the task to them itself. Also I will give a read about how network's charge for uploading data onto them. As you had mentioned before if the payment is associated with a block id, then maybe we could have any random client upload data onto the network (if of course we are able to ship in with Guix itself, the configuration to upload data onto the said network). Vijaya Anand 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 metadata in the DHT (i.e. where is what), while Swarm stores there > the data itself -- they are different architectures with different features) > > (i need to learn more about GNUnet) > > > > So ideally we will want to eliminate the usage of these substitute > > servers and shift totally to p2p services and in this case we will > > have to shift the responsibility of re-uploading the blocks to the > > clients itself. > > > yep, that's my way of thinking, too. > > note that 'client' here has two meanings: > > 1) some part of the codebase > > 2) a program that is running on the computers of the Guix users > > i was using it in the
Re: Automatically mapping services from System to Home
> Thoughts? my gut reaction is that whatever the automatic mapping does should be captured/reified into the code that defines a service... factoring out the common parts, and adding on top of that whatever is necessary in the two different contexts. but then i'm not sure i fully understand the differences between these two contexts, and i don't have a proposal.diff either, so... BTW, what are the differences? - a possible call to setuid/setgid, and their values in the config if the service is not to be started as root? - the default values of the config file and log file(s)? possibly some service-specific values in the config whose default value depend on the user/group under which the service is running? maybe the user/group should be a mandatory value under the hood, and the service code should dispatch on their values and the current effective user/group id, and act accordingly? what am i missing? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The moral law is one of the basic laws of the universe. It is likewise called the principle of Karma, the result of cause and effect, or action and reaction. There is nothing vindictive about this principle. It works impersonally like any law of nature. As the fruit is contained in the seed, so the consequences are inherent in the act. This principle guides the destinies of both people and nations. Knowledge of this principle gives human beings the power to control our own destiny.” — Thor Kiimaletho
Re: [RFC] Cosmetic changes to define-configuration usage
On 3/24/23 6:33 AM, Bruno Victal wrote: I'd like to propose for field specifications in define-configuration to be separated with a blank line between them. Reason for this is that it makes it much easier on the eyes to read, rather than being presented with a dense hunk of text to sift through. I tend to always insert these blank lines when making changes in these parts to aid reading, even if they weren't originally present and were not planned to be committed. I'd be happy if I could simply keep the line separations and avoid the tedious insert-erase ritual. I think I'm not alone in this opinion, consider the following snippets: It's funny how sometimes this works out. I was just hacking on a service's configuration and had the same thought. I had spaced everything out so that it wasn't as overwhelming, and with a sigh grouped it all back together because that's how all existing services work. I would definitely appreciate this change in the style standard. -- Katherine
Automatically mapping services from System to Home
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. Thoughts? Ludo’. diff --git a/gnu/home/services.scm b/gnu/home/services.scm index b7ea6f08dd..b32e7395b1 100644 --- a/gnu/home/services.scm +++ b/gnu/home/services.scm @@ -1,6 +1,7 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2021 Andrew Tropin ;;; Copyright © 2021 Xinglu Chen +;;; Copyright © 2022 Ludovic Courtès ;;; ;;; This file is part of GNU Guix. ;;; @@ -31,8 +32,10 @@ (define-module (gnu home services) #:use-module (guix diagnostics) #:use-module (guix i18n) #:use-module (guix modules) + #:use-module (guix memoization) #:use-module (srfi srfi-1) #:use-module (ice-9 match) + #:use-module (ice-9 vlist) #:export (home-service-type home-profile-service-type @@ -46,6 +49,9 @@ (define-module (gnu home services) fold-home-service-types home-provenance +define-service-type-mapping +system-service-type->home-service-type + %initialize-gettext) #:re-export (service @@ -396,6 +402,77 @@ (define home-activation-service-type reconfiguration or generation switching. This service can be extended with one gexp, but many times, and all gexps must be idempotent."))) + +;;; +;;; Service type graph rewriting. +;;; + +(define (service-type-mapping proc) + (define (rewrite extension) +(match (proc (service-extension-target extension)) + (#f #f) + (target + (service-extension target + (service-extension-compute extension) + + (define replace +(mlambdaq (type) + (service-type + (inherit type) + (location (service-type-location type)) + (extensions (filter-map rewrite (service-type-extensions type)) + + replace) + +;; (define (service-type-extensions-rewriting replacements) +;; (define replace +;; (let ((replacements (alist->vhash replacements hashq))) +;; (lambda (type) +;; (match (vhash-assq type replacements) +;; (#f type) +;; ((_ . replacement) replacement) + +;; (service-type-mapping replace)) + +(define system-service-type->home-service-type + (let () +(define (replace type) + (define replacement +(hashq-ref %system/home-service-type-mapping type + *unspecified*)) + + (if (eq? replacement *unspecified*) + type + replacement)) + +(service-type-mapping replace))) + +(define %system/home-service-type-mapping + (make-hash-table)) + +(define-syntax define-service-type-mapping + (syntax-rules (=>) +((_ system-type => home-type) + (hashq-set! %system/home-service-type-mapping + system-type home-type + +(define-syntax define-service-type-mappings + (syntax-rules (=>) +((_ (system-type => home-type) ...) + (begin + (define-service-type-mapping system-type => home-type) + ... + +(define-service-type-mappings + (system-service-type => home-service-type) + (activation-service-type => home-activation-service-type)) + +;; (define system->home-service-type +;; (service-type-extensions-rewriting +;;`((,system-service-type . ,home-service-type) +;; (,activation-service-type . ,home-activation-service-type) +;; (,shepherd-root-service-type . ,home-shepherd-service-type + ;;; ;;; On-change. diff --git a/gnu/home/services/shepherd.scm b/gnu/home/services/shepherd.scm index 7a9cc064bb..21b73d8cdf 100644 --- a/gnu/home/services/shepherd.scm +++ b/gnu/home/services/shepherd.scm @@ -131,4 +131,5 @@ (define-public home-shepherd-service-type (default-value (home-shepherd-configuration)) (description "Configure and install userland Shepherd."))) - +(define-service-type-mapping + shepherd-root-service-type => home-shepherd-service-type) diff --git a/gnu/services/syncthing.scm b/gnu/services/syncthing.scm index
Re: bug#62246: [PATCH] doc: Add a reference to a page explaining consensus decision making.
Hi, Ludovic Courtès writes: > Hi Maxim, > > Maxim Cournoyer skribis: > >> This is to make explicit something which until now had always been implicit. >> >> * doc/contributing.texi (Commit Access): Mention that committers are expected >> to employ consensus decision making. > > [...] > >> -contributor is willing to take to help the project. >> +contributor is willing to take to help the project. It is expected from >> +all contributors, and even more so from committers, to collaborate in a >> +consensus decision making fashion. To learn what consensus decision > > The first sentence was hard to parse at first. Perhaps a slight > improvement: “… from committers, to help build consensus and make > decisions based on consensus.” > > Otherwise LGTM; thanks for working on it! I've applied your suggestion to my local branch, thanks. I'm CC'ing guix-devel and guix-maintainers to make sure everybody is informed of this proposed change. It's still time to voice any concern you may have with this suggested change. I'll leave it open for a few more days. -- Thanks, Maxim
Re: Call for members to join the Xfce, LXQt and Localization teams
宋文武 writes: > Zhu Zihao writes: > >> count me in :) > > Good, all three? Thank you! As we talked in #guixcn, join you to the xfce and localization team, thanks!
How to manage package replacements?
Hey, I was looking at python-pillow as there's some duplication showing up in various places, including guix lint. → guix lint python-pillow guix lint: warning: ambiguous package specification `python-pillow' This is probably connected with package replacements, maybe the original package definition should be marked as hidden? Anyway, I think the bigger point here is I'm not sure what's meant to be done when adding replacements for a package, and I don't know how to find out what's meant to be done? Does anyone know what needs to be done in any/every case when replacing a package? Thanks, Chris signature.asc Description: PGP signature
Re: Call for members to join the Xfce, LXQt and Localization teams
Zhu Zihao writes: > count me in :) Good, all three? Thank you!
Re: Call for members to join the Xfce, LXQt and Localization teams
count me in :) 宋文武 writes: > Hello, I recently joined/created teams for xfce, lxqt, and localization, > in which I am the only member so far, so I'd like to call for more > members. > > I think Team members mostly do (in the scope and area of expertise by team): > - Review patches from guix-patches. > - Handle issues or usages support from guix-help and bug-guix. > > And the goals of said 3 teams are: > - xfce: Maintain the Xfce desktop environment in Guix, timely > updates/releases. > > - lxqt: Maintain the LXQt desktop environment in Guix, timely > updates/releases. > > - localization: Help your friends which doesn't use English as the main > system language to use the Guix System, by setup the required fonts > and input methods etc. Also maintain the required packages. > > If this interests you, please reply or send a patch for > 'etc/teams.scm.in', thank you! > > I have CCed a list of people which I think might be interested (by looked > at git shortlog or asked on IRC) :) -- Retrieve my PGP public key: gpg --recv-keys B3EBC086AB0EBC0F45E0B4D433DB374BCEE4D9DC Zihao signature.asc Description: PGP signature
Call for members to join the Xfce, LXQt and Localization teams
Hello, I recently joined/created teams for xfce, lxqt, and localization, in which I am the only member so far, so I'd like to call for more members. I think Team members mostly do (in the scope and area of expertise by team): - Review patches from guix-patches. - Handle issues or usages support from guix-help and bug-guix. And the goals of said 3 teams are: - xfce: Maintain the Xfce desktop environment in Guix, timely updates/releases. - lxqt: Maintain the LXQt desktop environment in Guix, timely updates/releases. - localization: Help your friends which doesn't use English as the main system language to use the Guix System, by setup the required fonts and input methods etc. Also maintain the required packages. If this interests you, please reply or send a patch for 'etc/teams.scm.in', thank you! I have CCed a list of people which I think might be interested (by looked at git shortlog or asked on IRC) :)
