Re: FSDG issues of SCUMMVM-based games
On Tue, Jun 20, 2023 at 06:30:26AM +0200, Liliana Marie Prikler wrote: > Am Sonntag, dem 18.06.2023 um 21:07 +0200 schrieb Denis 'GNUtoo' > Carikli: > > [...] > > > Didn't you say that a hello world for scummvm exists? > > I don't know. There is a template for AGI games but the license is > > strange too, and it also requires some software to build it, and I've > > no idea if it's compatible with QT AGI, and I've also no idea if QT > > AGI works, doesn't have nonfree dependencies, etc. > > > > So that makes things way more complicated because here it probably > > requires a lot of work to confirm that it's possible or not possible > > to develop programs that run inside ScummVM with free software. > I see we're hitting a recurring pattern of not knowing things. This is > not aided by my personal disinterest for ScummVM, but I have to weigh > that disinterest against the potential interest of thousands of users > who are likely to only discover this argument to have taken place after > we've reached a conclusion. > > Note, that this discussion started IIRC a year ago and we have > practically known about actually existing FSDG violations since then. > My approach here is quite simple and pragmatic: Remove the games which > obviously violate the FSDG (that is all the games currently depending > on ScummVM as far as I know), but keep ScummVM for now to allow folks > to experiment. If in some one to five years we still find no practical > way of using ScummVM with only free software, that might be a reason to > remove it then. > > WDYT? This sounds like a sensible resolution to me. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Ideas for ocaml-team
Hi, Do you plan on including coq.scm in the upgrade plan, as it also depends on dune? If so, would coq-packages also be upgraded, or should that be done after the ocaml-team branch has been merged with master? Anyway, I am new to Guix, but will try to help if I can (time- and competence-wise) ! :) -- ds-ac Le Fri, Jun 16, 2023 at 04:32:48AM +, pukkamustard a écrit > > Hello Guix, > > I think it's time to start an `ocaml-team` (or `ocaml-updates`) branch > to collect some bigger updates and changes to the OCaml packages in > Guix. > > Some things that I can think of: > > * Update OCaml from 4.14.0 to 4.14.1 > > * Update OPAM from 2.1.3 to 2.1.5 > - Requires a major update of ocaml-dose3 from 5.0.1 to 7.0.0 > > * Update Dune from 3.6.1 to 3.8.1 > > * Update Jane Street packages from 0.15.0 to 0.16.0 > > * Remove most ocaml4.07-* and ocaml4.09 packages > - We only want to keep the compiler around for bootstrapping purposes. > - Update unison 2.51.2 to 2.53.3: This makes it buildable with OCaml > 4.14 or even 5.0. (see > https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00253.html). > > * Split packages from (gnu packages ocaml) into multiple modules. Maybe > in following modules: > > - (gnu packages ocaml): For the compiler and core dev packages (opam, > dune, merlin) > - (gnu packages ocaml-boot): For the 4.07 and 4.09 compilers > - (gnu packages ocaml-xyz): Everything else > > Thoughts? Any other things? How do we get started with such a branch? > > Cheers, > pukkamustard > signature.asc Description: PGP signature
Re: Guix / Nix Benchmarks
On Mon, Jun 19, 2023 at 02:55:21PM -0400, kiasoc5 wrote: > On 6/19/23 08:54, Nicolas Graves via Development of GNU Guix and the GNU > System distribution. wrote: > > > > One of the criticism that can be read online about Guix (compared to > > Nix) is its speed. I have never tried Nix and probably won't in a near > > future, but I was wondering if some work has been made to compare them > > on basic tasks (package installation, removal...) (the reason why I ask > > is to be able to give an honest answer to someone hesitating between > > both). > > > > At least package installation is faster with Nix. One reason is that Hydra > (their "substitute server") has faster download speeds compared to > CI/Bordeaux, likely due to multiple geographical locations/mirrors. I believe on the Nix side that includes a ~$9000/month bill for AWS. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Ideas for ocaml-team
Hi everyone, DABY-SEESARAM Arnaud writes: > Do you plan on including coq.scm in the upgrade plan, as it also depends > on dune? If so, would coq-packages also be upgraded, or should that be > done after the ocaml-team branch has been merged with master? > > Anyway, I am new to Guix, but will try to help if I can (time- and > competence-wise) ! :) I can also give a hand regarding Coq and libraries, since I have a vested interest in having everything up-to-date :) Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: Guix / Nix Benchmarks
On 2023-06-20 12:45, W. T. Meyer wrote: > Hi, > > Nicolas Graves via "Development of GNU Guix and the GNU System distribution." > writes: > >> One of the criticism that can be read online about Guix (compared to >> Nix) is its speed. > > I am using guix as well as nix, and depending on the operation you're > performing there's not much of a noticeable difference (I usually tend > to build packages from source, so for most of the build process it > doesn't really matter what, as in guix or nix, calls the corresponding > build-system; as that's not too relevant during the build process in > terms of time relevance). > > However, the download speed from the official substitute servers is > noticeable slower; but that's to be expected considering the resources^1 > NixOS is allocating towards their binary/build caching efforts. > >> I have never tried Nix and probably won't in a near >> future, but I was wondering if some work has been made to compare them >> on basic tasks (package installation, removal...) (the reason why I ask >> is to be able to give an honest answer to someone hesitating between >> both). > > I'd personally advise against over-priotizing raw performance of package > management tasks as a feasible metric to choose a package manager by; as > having a "good enough" (which is highly subjective) performance should > be enough. In this context it'd be probably more helpful to have a look > at nix vs. guix cli tooling and nix as a language vs. guile basing your > decision upon that. I fully agree with this statement, over-priotizing raw performance was not my point, and I won't change myself. I agree with the fact that having a fair comparison would first require comparing tooling, although I also think that keeping an eye on performance is not a waste either. Then the "best" actual comparison might be the one done by Andrew Tropin a few years ago, right here : https://gist.github.com/abcdw/e54807b0a25e61fe2cf1bf8991410f83 Maybe we could get in touch with some nix folks to try to update, enrich and maintain this kind of comparison up-to-date? (I've seen that some nice reviewing has been done on NixOS by linux "influencers" during the last week, and would like to also see Guix benefit from that. Although both are not in competition, a fair and shared comparison might help Guix grow in the space of Linux distributions.) > > Regards, > > Wilko Meyer > > [1]: > https://discourse.nixos.org/t/the-nixos-foundations-call-to-action-s3-costs-require-community-support/28672 -- Best regards, Nicolas Graves
Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hello, please consider I am (was?) a /great/ fan of rebase, but I have to admit that "the golden rule" [1] of rebasing makes sense: «never rebase on a public branch.» Leo Famulari writes: > On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote: >> I'm not sure how that'd work, since Git only allows a single PGP >> signature per commit, as far as I can tell. When you rewrite the >> history (by using rebase, say), the existing signatures of the rewritten >> (rebased) commits are replaced with new ones generated from your key. > > Is it so bad to re-sign commits on feature branches that we should lose > the easy-to-read history of rebased branches? IMHO this is not a problem, at all. > To me, it's much easier to understand and review a branch that has been > updated by rebasing rather than merging. I think that counts for a lot. > Do many people feel the same way? Me! ...if you mean "it's much easier to understand the history" I agree, but all in all this is "just" a "view" problem that should be solved (if not already solved) by a proper git log "filter" conversely, when rebasing the review process might be (sometimes very) problematic, this is an excerpt from «Why you should stop using Git rebase» https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1 --8<---cut here---start->8--- Why do we use Git at all? Because it is our most important tool for tracking down the source of bugs in our code. Git is our safety net. By rebasing, we give this less priority, in favour of the desire to achieve a linear history. A while back, I had to bisect through several hundred commits to track down a bug in our system. The faulty commit was located in the middle of a long chain of commits that didn’t compile, due to a faulty rebase a colleague had performed. This unneccessary and totally avoidable error resulted in me spending nearly a day extra in tracking down the commit. [...] Git merge. It’s a simple, one-step process, where all conflicts are resolved in a single commit. The resulting merge commit clearly marks the integration point between our branches, and our history depicts what actually happened, and when it happened. The importance of keeping your history true should not be underestimated. By rebasing, you are lying to yourself and to your team. You pretend that the commits were written today, when they were in fact written yesterday, based on another commit. You’ve taken the commits out of their original context, disguising what actually happened. Can you be sure that the code builds? Can you be sure that the commit messages still make sense? You may believe that you are cleaning up and clarifying your history, but the result may very well be the opposite. --8<---cut here---end--->8--- Also, when I read the below mentioned article I have many doubts that rebase should ever be used in Guix public feature branches: «Rebase Considered Harmful» https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md --8<---cut here---start->8--- 2.1 A rebase is just a merge with historical references omitted [...] So, another way of thinking about rebase is that it is a kind of merge that intentionally forgets some details in order to not overwhelm the weak history display mechanisms available in Git. Wouldn't it be better, less error-prone, and easier on users to enhance the history display mechanisms in Git so that rebasing for a clean, linear history became unnecessary? [...] 2.2 Rebase does not actually provide better feature-branch diffs [...] The argument from rebase advocates is that with merge it is difficult to see only the changes associated with the feature branch without the commingled mainline changes. In other words, diff(C2,C7) shows changes from both the feature branch and from the mainline, whereas in the rebase case diff(C6,C5') shows only the feature branch changes. But that argument is comparing apples to oranges, since the two diffs do not have the same baseline. The correct way to see only the feature branch changes in the merge case is not diff(C2,C7) but rather diff(C6,C7). [...] (n.d.r. see graphs on original page for clearness) --8<---cut here---end--->8--- (IMHO the whole article deserves to be read) [...] WDYT? Happy hacking! Gio' [1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing P.S.: and yes, maybe Fossil is better designed than Git, but I'm not proposing switching to it, not at all :-) -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hi Maxim, Maxim Cournoyer writes: > As discussed previously in this thread, a good policy would be to > suggest avoid *both* rebases and merges during a feature branch > development. This way we avoid both problems, I read the whole thread and AFAIU the (only?) problem with the "merging master to feature branch" workflow is the one pointed out by Andreas [1]: --8<---cut here---start->8--- Well, we used to repeatedly merge the master branch to core-updates, which if I remember well makes the master commits end up first in "git log". So the core-updates specific commits gradually disappear below thousands of master commits. So this is a problem. --8<---cut here---end--->8--- So, if I don't get wrong, the only problem is with "git log" not clearly showing the commit that are specific to the feature branch: are we sure is there no option that can help feature branch reviewers focus on the specific commits? Is not "git log --no-merges master..branchname" supposed to do what we need? Or "git log --first-parent "? (not tested) > and if the branch is short lived, it should be bearable that is isn't > synced with master for its short lifetime. What lifetime is short lived in Guix context? 5 days, 3 weeks? Anyway, I'm not sure that the branches designed on Guix (i.e. those listed on https://qa.guix.gnu.org/) will be short lived, I guess some could be long lived (months instead of weeks) WDYT? Ciao, Gio' [1] id:ZIcZ9tUidrWOfgyN@jurong -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Using (recursive #t) in (origin git-reference)
Hi, Is there a trick to fetching Git submodules with (recursive? #t)? It does not seem to work with the package definition below. The code uses Ekaitz's proposed Zig build system. [1] Thank you! Kind regards Felix [1] https://issues.guix.gnu.org/60889 * * * gnu: Add river. * gnu/packages/zig.scm (river): New variable. 1 file changed, 45 insertions(+), 2 deletions(-) gnu/packages/zig-xyz.scm | 47 +-- modified gnu/packages/zig-xyz.scm @@ -21,10 +22,52 @@ (define-module (gnu packages zig-xyz) #:use-module (guix git-download) #:use-module ((guix licenses) #:prefix license:) #:use-module (guix build-system gnu) + #:use-module (guix build-system zig) #:use-module (guix gexp) #:use-module (gnu packages) - #:use-module (gnu packages zig) - #:use-module (gnu packages python)) + #:use-module (gnu packages freedesktop) + #:use-module (gnu packages man) + #:use-module (gnu packages pkg-config) + #:use-module (gnu packages python) + #:use-module (gnu packages wm) + #:use-module (gnu packages xdisorg) + #:use-module (gnu packages xorg) + #:use-module (gnu packages zig)) + +(define-public river + (package +(name "river") +(version "0.2.4") +(source (origin + (method git-fetch) + (uri (git-reference +(url "https://github.com/riverwm/river";) +(commit (string-append "v" version)) +(recursive? #t))) + (file-name (git-file-name name version)) + (sha256 + (base32 +"1kh5yh2a47vr2q9paivmm3d57rcbb3f2p6d4f4r4k6f7jf62391n" +(build-system zig-build-system) +(arguments + (list + #:zig-build-flags #~(list "-Dxwayland") ;experimental xwayland support + #:zig-release-type "safe")) +(native-inputs (list +libevdev +libxkbcommon +pkg-config +pixman +scdoc +wayland +wayland-protocols +wlroots)) +(home-page "https://github.com/riverwm/river";) +(synopsis "Dynamic tiling Wayland compositor") +(description "River is a dynamic tiling Wayland compositor with flexible +runtime configuration. It can run nested in an X11/Wayland session or also +directly from a tty using KMS/DRM.") +(license license:gpl3))) (define-public zig-zls (package
Re: Using (recursive #t) in (origin git-reference)
Felix Lechner via "Development of GNU Guix and the GNU System distribution." writes: > Is there a trick to fetching Git submodules with (recursive? #t)? It > does not seem to work with the package definition below. > > The code uses Ekaitz's proposed Zig build system. [1] Thank you! Not sure whether or not you've already done this, but when you're doing ``(recursive? #t)'' the hash will be for the source code with submodules checked out, so you need to fetch them all in your ``git clone'' before doing ``guix hash -rx .''. (If you've already tried building it without the RECURSIVE?, then this issue will go unnoticed, as the derivation paths for these two objects: (origin (method git-fetch) (uri (git-reference (url "…") (commit (string-append "v" version …) (origin (method git-fetch) (uri (git-reference (url "…") (commit (string-append "v" version)) (recursive? #t))) …) are *exactly the same*, as the output path is the hash, followed by a dash, followed by whatever's given in FILE-NAME. Thus, they are treated as exactly the same object, making rebuilding pointless in Guix's eyes, because you've already got that "same" output in your store from the first build without RECURSIVE?. This is also, funnily enough, why it's not a great idea to first copy another origin's hash, then try to build, in the hopes of getting the actual hash from the "expected hash: …" message; if you haven't changed the FILE-NAME, or haven't included one, the output path will be exactly the same as the original package's, meaning that one will be used as the source if you happen to have it in your store! [IIUC, of course.]) That being said, you may know all this and have already taken it into account, in which case I'm not sure what's going on here :) -- (
Re: Using (recursive #t) in (origin git-reference)
Hi unmatched-paren! On Tue, Jun 20, 2023 at 11:52 AM ( wrote: > > (If you've already tried building it without the RECURSIVE?, then this > issue will go unnoticed, as the derivation paths [...] > are *exactly the same* Okay, that nipped me in the hiney. Now it works! Thanks for explaining! You are an invaluable as well as instant resource for this list. Kind regards Felix
Re: Using (recursive #t) in (origin git-reference)
On Tue, Jun 20, 2023 at 12:33 PM, Felix Lechner via \"Development of GNU Guix and the GNU System distribution.\" wrote: > Hi unmatched-paren! > > On Tue, Jun 20, 2023 at 11:52 AM ( wrote: >> >> (If you've already tried building it without the RECURSIVE?, then this >> issue will go unnoticed, as the derivation paths [...] >> are *exactly the same* > > Okay, that nipped me in the hiney. Now it works! > > Thanks for explaining! You are an invaluable as well as instant > resource for this list. > Yes, thanks for the quick response (! This happens enough I feel like it should be explicitly mentioned as a potential "gotcha" in the manual, even if one can gleam it from understanding package definitions and hashes, if it isn't already. Or maybe a little "tips" section on packaging (or in the cookbook) with something like this and related ones like idiosyncrasies/conventions in certain language ecosystems. We all accumulate a lot of institutional knowledge as we do and pass it along, but better to have it properly referenced. John
Re: Using (recursive #t) in (origin git-reference)
John Kehayias writes: > This happens enough I feel like it should be explicitly mentioned as a > potential > "gotcha" in the manual, even if one can gleam it from understanding package > definitions and hashes, if it isn't already. Or maybe a little "tips" section > on > packaging (or in the cookbook) with something like this and related ones like > idiosyncrasies/conventions in certain language ecosystems. We all accumulate a > lot of institutional knowledge as we do and pass it along, but better to have > it > properly referenced. Sounds like an idea. I definitely think it should go in the manual, though, as it'll be far more visible there. (I, personally, have never read the cookbook in all that much detail...) -- (
Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]
Hi Giovanni, Giovanni Biscuolo writes: > Hi Maxim, > > Maxim Cournoyer writes: > >> As discussed previously in this thread, a good policy would be to >> suggest avoid *both* rebases and merges during a feature branch >> development. This way we avoid both problems, > > I read the whole thread and AFAIU the (only?) problem with the "merging > master to feature branch" workflow is the one pointed out by Andreas [1]: > > > Well, we used to repeatedly merge the master branch to core-updates, > which if I remember well makes the master commits end up first in "git > log". So the core-updates specific commits gradually disappear below > thousands of master commits. So this is a problem. > > So, if I don't get wrong, the only problem is with "git log" not clearly > showing the commit that are specific to the feature branch: are we sure > is there no option that can help feature branch reviewers focus on the > specific commits? > > Is not "git log --no-merges master..branchname" supposed to do what we > need? Or "git log --first-parent "? (not tested) I'm not a 'git log' expert myself, but intuitively like you, I'd expect the --no-merges one to be useful to hide merge commits! The doc seems to confirm that: --no-merges Do not print commits with more than one parent. This is exactly the same as --max-parents=1. Thanks for finding that option. >> and if the branch is short lived, it should be bearable that is isn't >> synced with master for its short lifetime. > > What lifetime is short lived in Guix context? 5 days, 3 weeks? I'd say anything shorter than a month is (relatively) short lived, yes. > Anyway, I'm not sure that the branches designed on Guix (i.e. those > listed on https://qa.guix.gnu.org/) will be short lived, I guess some > could be long lived (months instead of weeks) I'm not sure too, but the idea is that when a branch is merged it should be deleted to communicate that, and that branches should be short lived (feature branches). Perhaps we'll find out that we still need more longer term integration branches that require synchronization; we'll see! -- Thanks, Maxim
distributed substitutes: file slicing
I have a question / suggestion about the distributed substitutes project: would downloads be split into uniformly sized chunks or could the sizes vary? Specifically, in an extreme case where an update introduced a single extra byte at the beginning of a file, would that result in completely new chunks? An alternative I've been thinking about is this: find the store references in a file and split it along these references, optionally apply further chunking to the non-reference blobs. It's probably best to do this at the NAR level?? Storing reference offsets is already something that we should be doing to speed other operations up, so this could tie in nicely with that.
Re: FSDG issues of SCUMMVM-based games
On Tue, 20 Jun 2023 06:30:26 +0200 Liliana Marie Prikler wrote: > Note, that this discussion started IIRC a year ago and we have > practically known about actually existing FSDG violations since then. > My approach here is quite simple and pragmatic: Remove the games which > obviously violate the FSDG (that is all the games currently depending > on ScummVM as far as I know), but keep ScummVM for now to allow folks > to experiment. If in some one to five years we still find no > practical way of using ScummVM with only free software, that might be > a reason to remove it then. > > WDYT? That looks perfectly fine to me. It leaves some time to people to try to fix ScummVM itself in a better way (like by packaging games built from source like Draci Historiae, removing the checksums, making a hello world, etc), and at the end ScummVM would get removed if it's not fixed. Denis. pgp1puW4qmk7v.pgp Description: OpenPGP digital signature
