Re: powerpc64[le]-linux port progress
dftxbs3e writes: Hi! > On 2/22/20 1:34 PM, Jan Nieuwenhuizen wrote: >> Have you tried building static gawk standalone and check it for that >> bash? You could do something like >> >>grep -ao '/gnu/store/e*-bash' $(./pre-inst-env guix build -e '(@@ (gnu >> packages make-bootstrap) %static-binaries)') >> >> On my x86_64-linux system, I get >> >>/gnu/store/-bash > Yes! I used the strings utility. I get two references to bash-static in > the store with 'e'. Ah, "good". > Speaking of which, do you know if it's possible > to be spawned into an environment where %static-binaries's gawk package > (and only that one) sources are extracted, patched and configured? So > that I can investigate the inclusion of bash-static comfortably. You can either do something like ./pre-inst-env guix build -e '(@@ (gnu packages bootstrap) %static-binaries)' --keep-failed --no-offload and edit the #:builder to return #f, or copy %static-binaries into a %static-gawk where you strip out other stuff. >> For the new Scheme-only bootstrap, I solved a similar problem for >> %bootstrap-mes by replacing the /gnu/store/eee* store-references with >> actual bootstrap file names; see `%bootstrap-mes-rewired' in >> core-updates >> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm?h=core-updates#n251 >> > I hear, however that smells like a hack to me, I'd like to avoid > resorting to such unless absolutely necessary. I'm not entirely sure which is better; but we chose this in order not having to touch the bootstrap binary for mes. Also, I don't know "where you are"; when trying to get "it to work", cutting corners initially works for me :-) > How come it's not > possible to find where that bash-static reference is being inserted? Computers are hard? It's probably easy to find when you see it... Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Migrating packages to Guile 3.0
Hello Guix! I’ve pushed a ‘wip-guile3.0-packages’ branch, which renames “guile-next” to “guile”, renames “guile3.0-” packages to just “guile-”, and changes a few more occurrences of ‘guile-2.2’ to ‘guile-3.0’ in package inputs. It should start building here: https://ci.guix.gnu.org/jobset/wip-guile3.0-packages We’re talking about the subset of packages known to support Guile 3.0, which includes all the dependencies (and dependents, hopefully) of Guix, plus a bunch of other packages. Initially I thought about applying the patch to ‘master’. However, it’s not that simple: we’d also need to have all the modules for Shepherd compiled for Guile 3.0, same for mcron, and same everywhere we use ‘with-extensions’ (for ‘guix pack’, (gnu system vm), etc.). Thus, I’m inclined to do the big switch in ‘core-updates’, where we could directly change ‘default-guile’, and thus everything would switch to Guile 3.0 at once. (In the meantime, the branch above allows us to test the packaging bits.) Thoughts? Thing is, it’d be great to have Guile 3.0.1, which could happen anytime now but just needs synchronization. Ludo’.
Thoughts on making Guix even better
Hello Raghav! > Lets assume we have 5 packages in profile. Package 1, 3 and 5 has > non-critical > updates. Package 4 has non-critical update but it breaks. Package 2 > has > critical update (CVE). We can either upgrade all packages except > package 4 (or) > we can upgrade only package 2. > > Lets assume we have 5 services/packages in system. Package/Service 1, > 3 and 5 > has non-critical updates. Package/Service 4 has non-critical update > but it > breaks. Package/Service 2 has critical update (CVE). Now, when we > reconfigure > the system, all packages/services will upgrade, package/service 4 > will break > the system. We can of course do '--roll-back' and take the system to > previous > working state. But that will leave the system with critical > vulnerability. > Therefore, we cannot reconfigure package/service 2 or any other parts > of the > system, until the package/service 4 is fixed. This window/gap puts > guix system > at great risk and instability. This is not as much a guix package vs. guix system issue as it is an issue of explicit manifests against implicit ones. If you use guix package with manifests and without inferiors, you will have the same problem. Likewise, you can use inferiors in your config.scm to mitigate some of those issues. At least it works for the kernel, but it should in theory also work for packages. The problem with inferiors as a solution to this problem is, that it doesn't address the issues of services. You'd have to use the current service structure with an inferior-package, which is not always what you want, specifically when the introduction of a new field to that service causes an issue. In addition to that, finding all package references and patching them to not include some breaking package (say e.g. the newest mesa version, which depending on your graphics card may or may not cause issues) can be very tedious depending on what is referenced where. Perhaps a lookup-inferior-services procedure might help here. Overall, there are also some "not so fun" things when dealing with inferior packages. For one (car (lookup-inferior-packages ...)) is quite a mouthful, especially when you know you'll always want the first result or there is only one to begin with. I'd welcome a procedure to turn an inferior into a procedure that always returns the first match. IIRC inferior packages are also not always accepted as packages, but I'd welcome being proven wrong about that. You can also modularize guix system by wrapping each and every service in a module which you either re-export from guix proper or -- in case of some failure -- implement on your own. That's a lot of work however. TL;DR: You can "modularize" transactions with 'guix system' in the same way you modularize 'guix package -m' (the "-m" means "not modular" ;P). Regards, Leo PS: What you're envisioning is probably a front-end, that obscures the very existence of a config.scm by managing one that is just as verbose as guix-generated manifests are. However, this is not really a solution as it fails to address the need for a (human-readable) initial configuration. The interface would also be a pain to deal with as each service comes with its own configuration record allowing arbitrary lisp expressions that one would have to write on the command line.
Re: Qt build problems after bump to 5.12.7
Submitted qtbase-patched in bug #39758.
GNU Guix ported to powerp64-linux-gnu
Hello! Finally it succeeded. Thanks to everyone who has answered my countless questions on the mailing list and IRC! GNU Hello - /gnu/store/98wc63drnc5iwkcclls91iz181mmiv7c-hello-2.10 (natively built with: ./pre-inst-env guix build hello) I used Gentoo (https://wiki.gentoo.org/wiki/Handbook:PPC64) as a base PowerPC 64-bit big endian system. (precisely IBM POWER9) source: https://gitlab.com/lle-bout/guix - commit f47e761a10675b05b07107035d5024618267a3ad (current master at time of writing) bootstrap binaries: https://gitlab.com/lle-bout/guix-bootstrap - commit b017c0459bc65a53203eb056998be8abd7778e4a (current master at time of writing) - currently it's unclear from which revision the bootstrap binaries come from, a rebuild of all the binaries from the latest ported guix's revision is pending. How to build bootstrap binaries: On a system where GNU Guix already works: ./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-tarballs Next steps are getting things to work on powerpc64le-linux-gnu (shouldnt be too hard now) then rebase everything onto core-updates! Leo signature.asc Description: OpenPGP digital signature
Re: Thoughts on making Guix even better
On Feb 22, 2020, at 9:49 PM, Raghav Gururajan wrote: > > The guix system transactions are NON-MODULAR. That is, you cannot selectively > reconfigure certain parts of the system. For example, you either reconfigure > the system as a whole (or) you do not reconfigure the system at all. This is something that also made it a bit difficult to get started writing services: you can’t work on a service in isolation and enable it on your current system by itself, which would be nice. I ended up building an operating-system container with just that service running, which works, but increases the time taken for each code-test cycle.
