Re: Trusted Firmware-A (ARMv8)
The system must be installed first. Some components on the board are probably supported (Ethernet, GPU) by open source software. -- Best regards, Kevin Vigouroux
* TODO Guix json dump all python packages in channel (CLI)
looking at this: https://github.com/NixOS/nixos-search/blob/main/flake-info/src/commands/nixpkgs_info.rs#L14 i thought... Wouldn't it be cool if you could do ``` guix dump -L my-guix-channel/ --json --filter=py ``` I know it's possible by writing Guix API code. And I know it's possible to slap a srfi-37 on it and ship it. I'm just being lazy and posting to guix-devel instead of taking the time to implement it. * DONE
Re: Trusted Firmware-A (ARMv8)
On 2022-10-24, Joshua Branson wrote: > Kevin Vigouroux via "Development of GNU Guix and the GNU System > distribution." writes: > >> I would like to install Guix (System) on the Banana Pi M5 [0]. The >> board is “open source” but not the firmware released by Amlogic [1]. >> >> The platform (Amlogic Meson S905X3) is currently not supported by the open >> source project Trusted Firmware-A [2][3]. >> >> I am a user not an expert and I don’t know what to do. >> > > This kind of question might get a better answer in help-g...@gnu.org. > :) > > Well, if you are trying to preserve your computing freedom, you might > need to ask how well will the board operate without the closed firmware. > > Will wifi work? Probably not, but you can purchase usb wifi dongles. > > Will graphics work... I've no idea. It is a signed boot firmware, so the board will not work at all without it. I have managed to get other S905* boards to boot, but it requires using the vendor-provided signing tools, which include some non-free blobs. There were attempts to replace that functionality, but as far as I know they are no longer active: https://github.com/afaerber/meson-tools https://github.com/angerman/meson64-tools That particular SoC has not yet been ported to upstream trusted-firmware-a (a.k.a. arm-trusted-firmware)... not sure how difficult that would be. So I don't hold my breath for something fully freedom-respecting from that family of boards... even though you can probably build more of the boot firmware from source than many systems people use regularly as they don't build any part of their boot firmware... a messy world. live well, vagrant signature.asc Description: PGP signature
Re: Trusted Firmware-A (ARMv8)
Kevin Vigouroux via "Development of GNU Guix and the GNU System distribution." writes: > I would like to install Guix (System) on the Banana Pi M5 [0]. The > board is “open source” but not the firmware released by Amlogic [1]. > > The platform (Amlogic Meson S905X3) is currently not supported by the open > source project Trusted Firmware-A [2][3]. > > I am a user not an expert and I don’t know what to do. > This kind of question might get a better answer in help-g...@gnu.org. :) Well, if you are trying to preserve your computing freedom, you might need to ask how well will the board operate without the closed firmware. Will wifi work? Probably not, but you can purchase usb wifi dongles. Will graphics work... I've no idea. Best of luck! Joshua > -- > [0]: https://wiki.banana-pi.org/Banana_Pi_BPI-M5 > [1]: > https://u-boot.readthedocs.io/en/latest/board/amlogic/pre-generated-fip.html > [2]: https://trustedfirmware-a.readthedocs.io/en/latest/plat/index.html > [3]: https://linux-meson.com/hardware.html
Re: Get all closed tickets with kolam
Hi jgart, > If so, is that endpoint currently deployed and accessible via mumi's > graphql API? Yes, the currently deployed mumi GraphQL endpoint is functioning normally. Sorry about the complete lack of documentation about how to use the GraphQL endpoint. Here is some working code with a bunch of GraphQL queries. I hope it helps. If it doesn't, do not hesitate to ping me. I will write better documentation "at some point". ;-) --8<---cut here---start->8--- (use-modules (ice-9 pretty-print) (kolam http)) (define %graphql-endpoint "https://issues.guix.gnu.org/graphql;) ;; Shown below are different GraphQL queries. Comment out all except ;; one. ;; Find the number, title and date of all closed issues. (define %graphql-document '(document (query (#(issues #:search "is:closed") number title date ;; Find the number, title, status and date of all issues submitted by ;; "arun". (define %graphql-document '(document (query (#(issues #:search "is:open submitter:arun") number title open date ;; Find the title and submitter of issue 34948. (define %graphql-document '(document (query (#(issue #:number 34948) title (submitter name address) ;; Find issues Arun Isaac participated in, the title of those issues ;; and who closed those issues. (define %graphql-document '(document (query (#(person #:email "Arun Isaac ") name (participated_in_issues title (closer name address)) ;; Run the GraphQL query, and print the results. (pretty-print (graphql-http-get %graphql-endpoint %graphql-document)) --8<---cut here---end--->8--- > Is there currently a way to get all closed tickets on mumi? Yes, there is. See the first example query in the code above. In fact, in the #:search field of `#(issues #:search "is:closed")`, you can put in any search query that you can put in at the https://issues.guix.gnu.org web interface. The GraphQL endpoint and the web interface share the same search code. Currently, mumi provides three different GraphQL object types---issue, person and email. Please see https://git.elephly.net/gitweb.cgi?p=software/mumi.git;a=blob;f=mumi/web/graphql.scm;h=56110a088c044e44ff10262a596c1f8823f2ded4;hb=HEAD for a complete list of fields provided by each object. Also, only GraphQL query operations are supported at the moment. Mutation and subscription operations are not. > I'm asking this on the guix-devel mailing list because I find others > might find this info useful. Good thinking! :-) Cheers, Arun
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Hi Simon, Quoting zimoun (2022-10-24 09:34:09) > On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR > wrote: > > >> guix package --export-manifest > /tmp/my-pkgs.scm > >> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ... > > > > I'm not using manifest (anymore). I used to, but for the time being, I'm > > using > > `divenv` + `guix shell` and I'm quite happy with that setup. > > Note that the first command above creates the manifest for you. > Usually, it works well enough. :-) I guess the "problem" is that I'm a "pipe person". I just don't like having to create a temp’ file. But I agree that your solution is more elegant. > Well, ’direnv’ + ’guix shell’ but you have a manifest, no? I mean how > does ’guix shell’ know what to provide inside this new shell? I used to have a `manifest.scm` file. I even used to (silly me!) commit it into the repository along side the project's code. I recently realized that it was easier to only have a git-ignored `.envrc` file containing: ``` use guix-shell python python-wrapper python-jedi poetry […] ``` The other project's dependencies are (still) managed by Poetry, so the list passed to Guix shell is quite short. Not that `guix-shell` is a custom function, for Direnv `guix` function still uses `guix environment`. But this would also work: ``` use guix --ad-hoc python python-wrapper python-jedi poetry […] ``` For some projects that are not dev project, I sometimes use a `manifest.scm`. I guess it also depends on the Moon phase. In those rare cases, my `.envrc` contains the following: ``` use guix-shell -m manifest.scm ``` Which can be abbreviated to `use guix-shell`, because it auto-magically loads the `manifest.scm` or `guix.scm` file present inside the folder. Regarding the `guix.scm` file, I recently decided to also move them out of the code repository of the (personal) projects I needed to package for Guix, because they don't actually belong with the code. They now live in a dedicated repository that I added to my Guix channels. > For what it is worth, I have used similar workflow but I have been bored > to run “guix pull”, do some stuff unrelated to ’project’, then later be > back on ’project’ and then have failures. Instead, my workflow is > splited into 2 ways depending on my phase of the Moon. Either, I create > a profile inside the project directory. Either, I use channels.scm + > manifest.scm and often run via ’guixify’ script (see below); e.g., > > guixify foo # run foo using the Guix environment > guixify # enter in the environment Thanks for sharing! I used to have the same kind of setup, but… > Maybe, ’direnv’ would do a better job. I wrote a `profile` function for Direnv that was doing the job of loading the environment. ``` use profile the-profile-for-my-project ``` I also had a `guix-all-profile` command that would executing the same command on all my profiles. Basically looping over them to `--upgrade` or `--delete-generations`. But I found it easier to use Guix shell. > The good point is that channels.scm and manifest.scm are included in the Git > tree of the project. And they can be re-used with ’guix pack -f docker -m > manifest.scm’ to generate Docker pack that I can share with colleagues. My colleagues use Debian. We agreed that I would not pollute the repo with my Guix files if they would not commit their Debian support files. Regards, -- Tanguy
Re: Pinning package inputs using inferiors?
Hi, On sam., 22 oct. 2022 at 22:58, Felix Lechner via "Development of GNU Guix and the GNU System distribution." wrote: > While I am relatively new to functional package management, I find it > inconsistent that inputs in Guix are provided by variables. What do you mean by « variables »? > I believe the inputs should be provided by functions that deliver the > most suitable version of a package. For most packages, that is the > most recent version unless pinned. What do you mean by « inputs »? Currently, the “new” style refers to symbol as inputs which points to other package definitions. A package definition somehow defines a function to build a package. At this level, it is hard to have a precise meaning of « suitable version of a package», IMHO. At the CLI level, packages are referred by their name field and the most recent version is used by default; unless a specific version as ’@1.2.3’ is appended to the name. > A package definition would be the list of available versions rather > than just one version. What do you build? Do you build the matrix of all the combinations? The hard task of a package manager is to provide a set of packages at their appropriated versions that works well all together. Aside some specific cases where the compatibility across version is guarantee, I miss how a mutli-version definition could work in practise. Package transformation is somehow a way to implement package definition for several versions. It allows to rewrite the function definition (package) but in the same time to keep under control the combinations. Cheers, simon
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Hi Tanguy, On dim., 23 oct. 2022 at 17:40, Tanguy LE CARROUR wrote: >> guix package --export-manifest > /tmp/my-pkgs.scm >> guix refresh -m /tmp/my-pkgs.scm 2>&1 | ... > > I'm not using manifest (anymore). I used to, but for the time being, I'm using > `divenv` + `guix shell` and I'm quite happy with that setup. Note that the first command above creates the manifest for you. Usually, it works well enough. :-) Well, ’direnv’ + ’guix shell’ but you have a manifest, no? I mean how does ’guix shell’ know what to provide inside this new shell? For what it is worth, I have used similar workflow but I have been bored to run “guix pull”, do some stuff unrelated to ’project’, then later be back on ’project’ and then have failures. Instead, my workflow is splited into 2 ways depending on my phase of the Moon. Either, I create a profile inside the project directory. Either, I use channels.scm + manifest.scm and often run via ’guixify’ script (see below); e.g., guixify foo # run foo using the Guix environment guixify # enter in the environment Maybe, ’direnv’ would do a better job. The good point is that channels.scm and manifest.scm are included in the Git tree of the project. And they can be re-used with ’guix pack -f docker -m manifest.scm’ to generate Docker pack that I can share with colleagues. --8<---cut here---start->8--- #!/bin/sh guix time-machine -C channels.scm \ -- shell --pure \ -m manifest.scm \ -- $@ --8<---cut here---end--->8--- Cheers, simon
Re: Notes from discussion on Quality Assurance from the 10 Years of Guix event
Hi Tanguy,
On dim., 23 oct. 2022 at 17:48, Tanguy LE CARROUR wrote:
> ```console
> $ guix package -I | awk '{print $1}' | tr '\n' ' ' | xargs guix refresh 2>&1 \
> | ag -v '(already|failed|no updater|warning|redirection)'
> ```
This pipe is equivalent to,
guix package --export-manifest > /tmp/my-installed-packages.scm
guix refresh -m /tmp/my-installed-packages.scm 2>&1 \
| ag -v '(already|failed|no updater|warning|redirection)'
which is, IMHO, more Guixy. ;-)
Cheers,
simon
Trusted Firmware-A (ARMv8)
I would like to install Guix (System) on the Banana Pi M5 [0]. The board is “open source” but not the firmware released by Amlogic [1]. The platform (Amlogic Meson S905X3) is currently not supported by the open source project Trusted Firmware-A [2][3]. I am a user not an expert and I don’t know what to do. -- [0]: https://wiki.banana-pi.org/Banana_Pi_BPI-M5 [1]: https://u-boot.readthedocs.io/en/latest/board/amlogic/pre-generated-fip.html [2]: https://trustedfirmware-a.readthedocs.io/en/latest/plat/index.html [3]: https://linux-meson.com/hardware.html -- Best regards, Kevin Vigouroux
Re: How long does it take to run the full rustc bootstrap chain?
Hi, Félix Baylac Jacqué writes: > Hey Guix, > > I'd be curious to know how long it takes to run the full rustc bootstrap > chain on the Guix build farm. I'm sadly not sure how to approach this > problem. > > Is there a way to extract this information from Cuirass or the Guix data > service? > > Félix It used to be 16 hours on a Ryzen 3900x machine, then it got halved to 8 hours with the work to bootstrap from 1.39, and recently we're bootstrapping from 1.54, so it must have been greatly reduced again. Looking at (gnu packages rust), the mrustc-based bootstrap starts with 1.54.0. This one is expensive, probably around 1 h 30 or more on a Ryzen 3900x CPU (24 logical CPUs). The intermediate builds are typically around 15-20 minutes on that machines, with the last one taking a bit more (30 minutes), so the current bootstrap on such a machine should take about: 1.54.0: 1h30m 1.55.0 - 1.60.0: 6 X 20 min = 1h20m 1.60.0: final build with tests and extra tools: 30 min The total should be around 3 h 20 on a fast modern x86_64 machine. I suppose the time for berlin to build it takes about this. HTH! -- Thanks, Maxim
Re: GNU Mes 0.24.1 released
On Wed, Oct 19, 2022 at 09:41:20PM +0200, Janneke Nieuwenhuizen wrote: > Ludovic Courtès writes: > > Hey! > > > Janneke Nieuwenhuizen skribis: > > > > This is exciting news! Looking forward to having full-source > > bootstrapped AArch64… and it looks like there’s already activity on a > > ‘wip-’ branch. > > Yes, it is! The ARM bootstrap story is still a bit flakey, as > stage0-posix does not support ARM. So, ARM would need > %bootstrap-mescc-tools and %bootstrap-mes binary seeds...meh. > > However, aarch64-linux now bootstraps from 526 bytes all the way until > gcc-core-mesboot 2,95.3. Very nice! > > We're still stuck at building a full gcc+glibc combo; > glibc-mesboot-2.2.5 builds, but possibly not correctly; as the full > gcc-mesboot0 (2.95.3) build fails at configure time: gcc-core-mesboot0 + > glibc-mesboot0 > >?: 0 [execle "./gencheck" # "./gencheck"] > ERROR: In procedure execle: Exec format error > > Not sure what to do here. We could somehow try to debug/bisect this. > We could try to use a newer glibc; glibc-2.2.5 happened during the > OABI/EABI switch and is heavily patched. Or, we could try to remove > glibc-2.2.5/gcc-2.95.3 altogether and aim for a direct tcc => gcc-4.6.4. > We need to go that way anyway for RISCV. I noticed that when offloading from my x86_64 box to my aarch64 machine target gets (%current-system) from the originating system, not from the system doing the building. I'm testing moving the '(let ((triplet ...' code down from the top of the definition to inside the arguments. I didn't see a difference with 'guix build -d' for x86_64 from x86_64, but the derivation did change with the planned offload to an aarch64 machine. I looked into gcc-2.95 more than I wanted to last week with GHC-4.08, would it help if we specified we wanted armv4 or armv4t or strongswan instead of "generic"? -- 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
Installer for 1.4.0
Hello, The installer has been hardened during the past months when it comes to error reporting: - Guile exceptions are caught, displayed and possibly uploaded to dump.guix.gnu.org if the user agrees to do so. - Failing system commands can be run again. I think that it would be nice to go a bit further as people tend to use the stable Guix installer image and given our current release rate, the future 1.4.0 could last for long. It would be awesome if we could tackle the following issues before the release: - Guile and library segfaults could be reported as proposed here: https://issues.guix.gnu.org/58733. - There is a nasty finalizer bug that has probably bitten a lot of users here: https://issues.guix.gnu.org/58732. - The backtrace page is not displayed correctly if an exception occurs withing the final PTY: https://issues.guix.gnu.org/58734. This one is maybe not as important but it would be great to have it fixed so that every part of the installer is well covered by the dump mechanism. - Displaying upfront that the WiFi, video card or any other hardware won't be supported by the installer/linux-libre in the spirit of: https://issues.guix.gnu.org/58549 would be great. For instance, I tested recently the installer on a laptop with an unsupported WiFi card. The WiFi page is skipped altogether by the installer which forces the user to plug an ethernet cable without explaining why. I think we could be a bit more didactic. Any volunteers? Thanks, Mathieu
