Re: Go importer - help with git-fetch
Hi :) Thanks for the quick responses. On 2019-08-06 15:04, Jakob L. Kreuze wrote: Ricardo Wurmus writes: ... Yes -- my apologies, I probably should have clarified in the earlier email thread. 'git-fetch' from (guix git-download) needs to be run in the store monad, but 'git-fetch' from (guix build git) doesn't. You can get rid of 'with-store' and 'run-with-store'. Done! (see attached) I got the git-fetch and hashing to work. :D Next challenge: silence git-fetch. Do any of you know how to do that? I imagine it entails sending its text output to some dummy port. -- Cheers Swedebugia >From f01dff653c365fb15acdac165a3ad0cf2f809930 Mon Sep 17 00:00:00 2001 From: swedebugia Date: Tue, 6 Aug 2019 22:20:10 +0200 Subject: [PATCH] guix: import: Add golang importer utilizing the Go-search API. * guix/import/github.scm (fetch-readme, fetch-license) (fetch-latest-commit, headers, http-url?): Add support for /commits, /license, and /readme Github APIv3 endpoints. (export): Export fetch-readme, fetch-license & fetch-latest-commit. (github-user-slash-repository): Use http-url? for better error reporting. * guix/import/go.scm: New file. * guix/import/utils.scm (guix-hash-directory): New procedure. (export): Export it. --- guix/import/github.scm | 66 ++-- guix/import/go.scm | 232 + guix/import/utils.scm | 5 + 3 files changed, 293 insertions(+), 10 deletions(-) create mode 100644 guix/import/go.scm diff --git a/guix/import/github.scm b/guix/import/github.scm index fa23fa4c0..b889da69a 100644 --- a/guix/import/github.scm +++ b/guix/import/github.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2017, 2018, 2019 Ludovic Courtès ;;; Copyright © 2018 Eric Bavier ;;; Copyright © 2019 Arun Isaac +;;; Copyright © 2019 swedebugia ;;; ;;; This file is part of GNU Guix. ;;; @@ -33,7 +34,11 @@ #:use-module (guix upstream) #:use-module (guix http-client) #:use-module (web uri) - #:export (%github-updater)) + #:export (%github-updater +fetch-latest-commit +fetch-license +latest-released-version +fetch-readme)) (define (find-extension url) "Return the extension of the archive e.g. '.tar.gz' given a URL, or @@ -115,19 +120,66 @@ URL of the form 'https://github.com/arq5x/bedtools2/archive/v2.24.0.tar.gz'" ((_ owner project . rest) (string-append (basename project ".git") +(define (http-url? url) + ;; We only support Github urls beginning with http. + (string-prefix? "http" url)) + (define (github-user-slash-repository url) "Return a string e.g. arq5x/bedtools2 of the owner and the name of the repository separated by a forward slash, from a string URL of the form 'https://github.com/arq5x/bedtools2/archive/v2.24.0.tar.gz'" - (match (string-split (uri-path (string->uri url)) #\/) -((_ owner project . rest) - (string-append owner "/" (basename project ".git") + (if (http-url? url) + (match (string-split (uri-path (string->uri url)) #\/) + ((_ owner project . rest) + (string-append owner "/" (basename project ".git" + (error "Not a valid url."))) (define %github-token ;; Token to be passed to Github.com to avoid the 60-request per hour ;; limit, or #f. (make-parameter (getenv "GUIX_GITHUB_TOKEN"))) +(define headers +;; Ask for version 3 of the API as suggested at +;; <https://developer.github.com/v3/>. +`((Accept . "application/vnd.github.v3+json") + (user-agent . "GNU Guile"))) + +(define (fetch-readme url) + "Return a file with the README if any from a github repository url." + (let ((readme-url + (string-append "https://api.github.com/repos/"; +(github-user-slash-repository url) +"/readme"))) +"Get json, extract and fetch the raw url." +(let ((data (json-fetch readme-url #:headers headers))) + (http-fetch (assoc-ref data "download_url") + +(define (fetch-license url) + "Return the license json if any from a github repository url. This contains +the SPDX id among other things." + (let ((license-url + (string-append "https://api.github.com/repos/"; +(github-user-slash-repository url) +"/license"))) +(json-fetch license-url #:headers headers))) + +(define (fetch-latest-commit url) + "Get the latest commit-id." + (let ((commit-url + (string-append "https://api.github.com/repos/"; +(github-user-slash-repository url) +"/commits"))) +;; This might be able to implement using only match +(assoc-
Re: Go importer - help with git-fetch
On 2019-08-06 12:26, Pierre Neidhardt wrote: Just to be sure: did you write the go imported from scratch? Because a work-in-progress has been available for a while, you may want to base your work on it. Oh. Yeah, I did based on Go-Search and with inspiration from Jakob Kreuze. I just found the WIP golang.scm among the patches, see #35627. It relies on unstable github tarballs for sha256 hashes which in my view is not a viable approach. Also it was lacking an easy road to recursive import which is really what we want IMHO. My patch is quite concise in comparison and also extract licenses and readme's from github. It also has a complete list of the dependencies and can be easily extended with recourse-ability. Only the hashing is missing now, besides the calling script in guix/scripts/import and documentation. Anyone know how to calculate the hash based on a checkout? -- Cheers Swedebugia
Go importer - help with git-fetch
Hi :) I'm stuck trying to write a git-fetch -> hash procedure for the go importer. This is what I am trying to do in pseudocode: (base32-nix-hash (sha256 (git-fetch url commit temp-path))) I got this far by using (guix build git): (display (let* ((name "github.com/gogo/protobuf") (url (go-name->url name)) (commit "28a6bbf47e48e0b2220b2a244750b660c83d4942")) (with-store store (run-with-store store (let ((path "test")) (git-fetch url commit path)) But I'm pretty new to this derivation 2nd order code stuff and I don't understand the errors. It gives me: Initialized empty Git repository in /home/egil/src/guix/test2/.git/ remote: Enumerating objects: 924, done. remote: Counting objects: 100% (924/924), done. remote: Compressing objects: 100% (745/745), done. remote: Total 924 (delta 476), reused 330 (delta 132), pack-reused 0 Receiving objects: 100% (924/924), 1.45 MiB | 944.00 KiB/s, done. Resolving deltas: 100% (476/476), done. From https://github.com/gogo/protobuf * branch28a6bbf47e48e0b2220b2a244750b660c83d4942 -> FETCH_HEAD Note: checking out 'FETCH_HEAD'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at 28a6bbf [merge] Fix merge of non-nullable slices (#569) Backtrace: 8 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 7 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 6 (_ #(#(#))) In ice-9/boot-9.scm: 2312:4 5 (save-module-excursion _) 3831:12 4 (_) In guix/import/go.scm: 262:11 3 (_) In guix/store.scm: 623:10 2 (call-with-store #) 1803:24 1 (run-with-store # _ # _ …) In unknown file: 0 (_ #) ERROR: Wrong type to apply: #t What does this error mean? I looked into derivations.scm and found out about a port-sha256 from gcrypt - is that usable here to compute the hash? How do I get it to download to a temporary path? -- Cheers Swedebugia >From b7e99f057039e01a327c2f620b7202f7bc762d6c Mon Sep 17 00:00:00 2001 From: swedebugia Date: Thu, 1 Aug 2019 18:54:11 +0200 Subject: [PATCH] guix: import: Add golang importer via the Go-search API. * guix/import/github.scm (fetch-readme, fetch-license) (fetch-latest-commit, headers, http-url?): Add support for /commits, /license, and /readme Github APIv3 endpoints. (export): Export fetch-readme, fetch-license & fetch-latest-commit. (github-user-slash-repository): Use http-url? for better error reporting. * guix/import/go.scm: New file. --- guix/import/github.scm | 66 +-- guix/import/go.scm | 255 + 2 files changed, 311 insertions(+), 10 deletions(-) create mode 100644 guix/import/go.scm diff --git a/guix/import/github.scm b/guix/import/github.scm index fa23fa4c0..b889da69a 100644 --- a/guix/import/github.scm +++ b/guix/import/github.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2017, 2018, 2019 Ludovic Courtès ;;; Copyright © 2018 Eric Bavier ;;; Copyright © 2019 Arun Isaac +;;; Copyright © 2019 swedebugia ;;; ;;; This file is part of GNU Guix. ;;; @@ -33,7 +34,11 @@ #:use-module (guix upstream) #:use-module (guix http-client) #:use-module (web uri) - #:export (%github-updater)) + #:export (%github-updater +fetch-latest-commit +fetch-license +latest-released-version +fetch-readme)) (define (find-extension url) "Return the extension of the archive e.g. '.tar.gz' given a URL, or @@ -115,19 +120,66 @@ URL of the form 'https://github.com/arq5x/bedtools2/archive/v2.24.0.tar.gz'" ((_ owner project . rest) (string-append (basename project ".git") +(define (http-url? url) + ;; We only support Github urls beginning with http. + (string-prefix? "http" url)) + (define (github-user-slash-repository url) "Return a string e.g. arq5x/bedtools2 of the owner and the name of the repository separated by a forward slash, from a string URL of the form 'https://github.com/arq5x/bedtools2/archive/v2.24.0.tar.gz'" - (match (string-split (uri-path (string->uri url)) #\/) -((_ owner project . rest) - (string-append owner "/" (basename project ".git") + (if (http-url? url) + (match (string-split (uri-path (string->uri url)) #\/) + ((_ owner project . rest) + (string-append owner "/" (basename project ".git" + (error "Not a valid url."))) (define %github-token ;; Token to be pas
Re: A P2P alternative to email based development flow
On 2019-07-18 15:32, swedebugia wrote: Hi I have recently started using SSB[1] and it seems to me like a really promising protocol. Here is an idea for replacing a email-based workflow with a ssb-based one: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains There is already a vibrant active gossip P2P social media platform[2] working on this protocol. It is uncensurable and encrypts all private conversations. Here is a golang implementation FWIW: https://github.com/cryptoscope/ssb -- Cheers Swedebugia
A P2P alternative to email based development flow
Hi I have recently started using SSB[1] and it seems to me like a really promising protocol. Here is an idea for replacing a email-based workflow with a ssb-based one: https://people.kernel.org/monsieuricon/patches-carved-into-developer-sigchains There is already a vibrant active gossip P2P social media platform[2] working on this protocol. It is uncensurable and encrypts all private conversations. -- Cheers Swedebugia [1] https://ssbc.github.io/scuttlebutt-protocol-guide/ (its current implementation is mainly in node but the protocol seems solid and a c implementation (sbotc, sbotd) does exist. [2] https://www.scuttlebutt.nz/
Re: Installing custom kernel on Intel NUC using USB and no network(newbie question)
Hi Will I never played with guix archive so I will just comment on what I advise you to do. On 2019-07-13 18:41, Will Schenk wrote: I'm playing around with guixsd and am really impressed with the work so far! I've been unpacking the installer and configuration trying to understand how it works. so if there's a more straightforward way to do this that would be great also, but I have some questions on how guix itself works. I'm trying to install guix on a IntelNUC where I don't have access to a wired connection. This requires me to use the iwlwifi-firmware. I never used guix with wifi. Is there a free iwl driver in linux-libre? If not I advise you to buy a free software compatible wifi-stick. See h-node.org. I have a docker container on my OSX machine that installs guix on a debian image, and from there I add another channel to guix that has the standard linux kernel. From there I build an installation iso that I copy to USB key, boot the nuc off of, and am able to install the system over WiFi and everything is great. This sounds overly complicated if all you want to do is try guix system on the NUC. My plan was to then change my /etc/config.scm file to include the packages that I built in the docker container to provision the system with a different kernel. What I can't figure out is how to copy the package over in a way that guix system reconfigure can see them just using a USB stick. Building a custom kernel is not something I would recommend beginners of Guix System. I have only seen a few do it and they had many months of experience. ... Question 3: It seems crazy to me that I'm downloading everything over and over. At the office (where I was playing with this) we have fiber, but right here we have a terrible network connection so downloading multiple times is painful. Is there a way to setup a local mirror of the builds (I'm waiting for ipfs backing for this obvious.) It seems you have access to fast wired internet. I advise you to take the NUC somewhere and plug it in and wait for it to download everything. Guix is somewhat (maybe 25% compared to parabola and 35% compared to Debian) more bandwidth hungry than your average distribution from my experience. Anyway, what I really dont understand is the guix archive behavior and why that didn't work, and how to reference the packages once they've been imported into either my profile and especially the config.scm. Guix archive is not used a lot to my knowledge. I would avoid it as a beginner. Running guix publish to move packages is much more user friendly. Thanks, and I'm very excited to be playing with guix! Cool! Hope you find a solution that works for you. -- Cheers Swedebugia
Re: Can we increase the print width/column in daemon backtraces
On 2019-07-15 14:47, Ricardo Wurmus wrote: Hi Pierre, Quite often when packaging and iterating, the daemon produces backtraces on errors, which could be very useful to understand what's wrong, but unfortunately the output is truncated to some 80-ish column. Set the COLUMNS environment variable to some large value. This should be added to the manual I think. -- Cheers Swedebugia
Re: Apply Guix patches from debbugs
On 2019-07-15 12:54, Pierre Neidhardt wrote: Hi, Question for Emacs users: how do you apply patches directly from the debbugs interface? From the summary view, I can press M-m (debbugs-gnu-apply-patch). It asks me for a directory, I point to guix, and then I get the error --8<---cut here---start->8--- cd: No such directory found via CDPATH environment variable --8<---cut here---end--->8--- which after some investigation turns out to be because the command expects a "lisp" folder (this is made for Emacs development indeed). There must be some other way then. I remember doing it in the past, so my memory must be failing me... You can ignore that error. The patches apply fine (silently). -- Cheers Swedebugia
Re: Help needed fixing linux-libre-5.2 on aarch64
On 2019-07-14 14:24, Pierre Langlois wrote: And if I remove it then the error goes away! The build hasn't finished yet for me, but it's gone past the offending xor-neon.c file so we /should/ be good. I'm not really sure why though, do you know why this phase was required at the time? I haven't tested that linux-libre still builds on x86 with this phase removed yet, trying it now. OK, I've now built kernels with the attached patch on the kernel-updates branch for x86_64 and aarch64! I've also tested with --system=armhf-linux on the softiron and --system=i868-linux on my x86 desktop, it all looks good! Nice work! -- Cheers Swedebugia
Re: guix import crate wraps #:cargo-inputs twice
Hi arne On 2019-06-30 23:20, Arne Babenhauserheide wrote: Hi Ivan, When using guix import crate flamer, it generates a pattern like Thanks for the report, I’ve fixed this in 022288ba53bd44c9311c6cffef5e8224a2e74598! Thank you! I’ve been working at getting a current Firefox packaged, but got stuck now. If you’re interested I could send you all the rust how did you get stuck? package definitions I created for that — maybe you’ll spot the mistake right-away. Unfortunately guix does not seem to handle duplicates well and chokes with this unrelated it seems error when I add your packages to my list without duplicates: See bug #36456
Re: Rust = bust?
On 2019-06-30 21:35, swedebugia wrote: I logged into my substitute server to find out more, but: athena.tobias.gr ~ λ guix describe Generation 109 Jun 30 2019 21:11:58 (current) guix a3d1a34 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a3d1a3487a34820d2a0b3d5e6206e4df1c77c15c athena.tobias.gr ~ λ guix build rust@1.30.1 […] /gnu/store/p20fkgdlqqw4dlfqg8jximqg6qpcz7a1-rust-1.30.1 Looks like I already built the entire rust chain successfully. (?) You're welcome to give my substitute server at https://guix.name> a try (more info at that URL). I'd be interested in both success and failure. :-) Nice, what a gift! Authorized your key and ran: $ ./pre-inst-env guix build -K grin -c 1 -n --substitute-urls="https://ci.guix.gnu.org https://guix.tobias.gr"; substitute: updating substitutes from 'https://guix.tobias.gr'... 100.0% The following derivations would be built: /gnu/store/9d9r8c70yz329gl01ywgvf4gql9ir31f-grin-1.1.0.drv /gnu/store/hgpjq9f5z6rpmidsij7nrp20ad38vg98-rust-1.35.0.drv /gnu/store/1lmw4151bbz6b0scd2gvxsgh0ad25vwb-rust-1.34.1.drv /gnu/store/cssgpdzm63zd8vdxr9pkhmplr5c0wglr-rust-1.33.0.drv /gnu/store/ivkmn1gisdz3xys6gdmncr1vfpwp1a0v-rust-1.32.0.drv /gnu/store/11b81ijyi1wnp41wgyqjwgxvg28hk4hg-rust-1.31.1.drv /gnu/store/1yis5vsvqpf0gaynnfqpnin45yp3cw4l-rust-1.30.1.drv 147.4 MB would be downloaded: /gnu/store/0bqbl8jpirdi4g84hylcxj6i500mr93b-rustc-1.32.0-src.tar.xz /gnu/store/k8i6bf0c5dzm34dnfx7qq7wq5hgccfnz-rustc-1.31.1-src.tar.xz /gnu/store/3hfni09gy7d7n0gnc12s7zfa0lr7c0ff-rustc-1.33.0-src.tar.xz /gnu/store/zamc7lhcsjn0hkfs93796xgpbmkccfam-rustc-1.34.1-src.tar.xz Hm. Then I did a git pull && make and got The following derivation would be built: /gnu/store/f19xi2dy52ajyylikzvm1ks2mhkdj0j4-grin-1.1.0.drv The following files would be downloaded: /gnu/store/s89kb99c07wvyxjcq3rc6aap8rkcfwqx-rust-1.35.0-cargo /gnu/store/2dc71v5jlbd6rpz7qx04iyzwl7kcqrjm-rust-1.35.0 Hooray! Thanks a lot. -- Cheers Swedebugia
Re: Rust = bust?
On 2019-06-30 21:32, Tobias Geerinckx-Rice wrote: Swedebugia, swedebugia wrote: http://ci.guix.gnu.org/search?query=rust-1.30 -> http://ci.guix.gnu.org/build/1303680/details "dependency failed" What does that mean? What is going on? That a package (well, derivation) upon which rust@1.30.1 depends failed to build. I'm almost certain that Cuirass doesn't currently track dependency information the way it eventually should, which would mean there's no way to find out *which* dependency failed. The only way to find out would be build rust@1.30.1 yourself and see what fails before you get to it. If you do get to it, you managed to build something that ci.guix didn't and you should feel proud. I logged into my substitute server to find out more, but: athena.tobias.gr ~ λ guix describe Generation 109 Jun 30 2019 21:11:58 (current) guix a3d1a34 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a3d1a3487a34820d2a0b3d5e6206e4df1c77c15c athena.tobias.gr ~ λ guix build rust@1.30.1 […] /gnu/store/p20fkgdlqqw4dlfqg8jximqg6qpcz7a1-rust-1.30.1 Looks like I already built the entire rust chain successfully. (?) You're welcome to give my substitute server at https://guix.name> a try (more info at that URL). I'd be interested in both success and failure. :-) Nice, what a gift! Also could somebody tell me how to shut off the tests if I choose to build them myself? Edit the package definition to add ‘#:tests? #f’ to the arguments field. This will change the derivation and all that depend on it (so you won't get substitutes for anything that depends on your untested rust fork). Yeah, thats the downside. -- Cheers Swedebugia
Re: Rust = bust?
Hi On 2019-06-30 21:27, Ivan Petkov wrote: Hi swedebugia, Rust 1.30 was recently broken I believe when gdb was upgraded. I’ve pushed out a fix, Nice. so rust 1.30 and anything else should build successfully. Unfortunately there are no substitutes for this currently (the CI keeps showing jobs in progress and failing after a day, maybe the build nodes are all busy building the staging updates?) As I detailed above the problem now seems to be below 1.30 as I detailed in my email. Rust-1.24 seems to be the bottleneck (since 11 may) if I understood it correctly. -- Cheers Swedebugia
Re: Rust = bust?
On 2019-06-30 21:12, swedebugia wrote: Hi I'm eager to begin building grin which relies on rust 1.34+ but I get this from a guix checkout compiled yesterday: The following derivations would be built: /gnu/store/9d9r8c70yz329gl01ywgvf4gql9ir31f-grin-1.1.0.drv /gnu/store/hgpjq9f5z6rpmidsij7nrp20ad38vg98-rust-1.35.0.drv /gnu/store/1lmw4151bbz6b0scd2gvxsgh0ad25vwb-rust-1.34.1.drv /gnu/store/cssgpdzm63zd8vdxr9pkhmplr5c0wglr-rust-1.33.0.drv /gnu/store/ivkmn1gisdz3xys6gdmncr1vfpwp1a0v-rust-1.32.0.drv /gnu/store/11b81ijyi1wnp41wgyqjwgxvg28hk4hg-rust-1.31.1.drv /gnu/store/1yis5vsvqpf0gaynnfqpnin45yp3cw4l-rust-1.30.1.drv This has not changed for days/a week. When investigation on the CI I find that rust above 1.30 have not build on master for x86-64 since april. http://ci.guix.gnu.org/search?query=rust-1.30 -> http://ci.guix.gnu.org/build/1303680/details "dependency failed" What does that mean? What is going on? Also could somebody tell me how to shut off the tests if I choose to build them myself? Investigating further I found this: http://ci.guix.gnu.org/build/1303679/details Build marked failed 11 may but the log says: "Rust is ready to roll." and "@ build-succeeded /gnu/store/2za0a3v7p8dbmnf64cb5agjs09cmns15-rust-1.24.1.drv -" ERROR in our CI? This "failed" build of course causes the rest of the toolchain to fail with "dependency failed" but that seems to be incorrect. (rust-0.23 http://ci.guix.gnu.org/search?query=rust-1.23 succeded 11 may and was correctly marked as such :) ) Anyone capable of helping out? -- Cheers Swedebugia
Rust = bust?
Hi I'm eager to begin building grin which relies on rust 1.34+ but I get this from a guix checkout compiled yesterday: The following derivations would be built: /gnu/store/9d9r8c70yz329gl01ywgvf4gql9ir31f-grin-1.1.0.drv /gnu/store/hgpjq9f5z6rpmidsij7nrp20ad38vg98-rust-1.35.0.drv /gnu/store/1lmw4151bbz6b0scd2gvxsgh0ad25vwb-rust-1.34.1.drv /gnu/store/cssgpdzm63zd8vdxr9pkhmplr5c0wglr-rust-1.33.0.drv /gnu/store/ivkmn1gisdz3xys6gdmncr1vfpwp1a0v-rust-1.32.0.drv /gnu/store/11b81ijyi1wnp41wgyqjwgxvg28hk4hg-rust-1.31.1.drv /gnu/store/1yis5vsvqpf0gaynnfqpnin45yp3cw4l-rust-1.30.1.drv This has not changed for days/a week. When investigation on the CI I find that rust above 1.30 have not build on master for x86-64 since april. http://ci.guix.gnu.org/search?query=rust-1.30 -> http://ci.guix.gnu.org/build/1303680/details "dependency failed" What does that mean? What is going on? Also could somebody tell me how to shut off the tests if I choose to build them myself? -- Cheers Swedebugia
Re: Guix beyond 1.0: let’s have a roadmap!
On 2019-06-28 18:54, zna...@disroot.org wrote: ** TODO make a wiki online for newcomers ** TODO make some other methods for chatting (for those who use free vpn, tor) Telegram seems to work well. Only the client is free though. -- Cheers Swedebugia
Re: Guix beyond 1.0: let’s have a roadmap!
On 2019-06-27 21:02, Alex Griffin wrote: On Thu, Jun 27, 2019, at 4:31 PM, Ludovic Courtès wrote: What do *you* want Guix to address in the future? * Guix System ** TODO add firewall-service to provide a configurable stateful firewall suitable for most desktops and servers +1 *** TODO add service-extensions to existing services so that firewall-service can be added to %base-services without unnecessary breakage ** TODO use guile-bash to automatically update environment variables when the current profile changes ** TODO support more partitioning and bootloader configurations (full disk encryption without entering password twice, LVM support, os-prober, etc.) *** TODO support secured boot from Heads/PureBoot (https://docs.puri.sm/PureBoot.html) ** TODO easier loading of out-of-tree kernel modules ** TODO run-time configuration system for services, similar to OpenWrt's UCI * Command Line Interface ** TODO refresh able to take a contributor name and find out-of-date packages that they have contributed to ** TODO improved search: support AND terms instead of OR, configurable recfmt template ** TODO package --show should allow multiple arguments and not require an equal sign +1 * Other ** TODO evaluate shepherd service definitions placed somewhere in ~/.guix-profile before evaluating ~/.config/shepherd/init.scm ** TODO support automatic GPG/signify signature verification of origin objects ** TODO better Node.js packaging and tooling This seem to have gotten stuck. But I heard something about a guile-semver and also we need to handle circular dependencies better in guix to make it easier to discover and mitigate them. Compared to the whole expat/JS community Guix is still a very small project. The bootstrap problems will probably take years to complete with the current pace/manpower/interest. Maybe we should propose The GNU Project to create and seek funding for a "fix JS (bootstrap)" campaign? Compilers will need to be written according to Julien (like rustc). *** TODO package important Icecat and Ungoogled-Chromium extensions. This is a pain point because IceCat steers users away from Firefox Add-ons and Ungoogled-Chromium completely disallows installing from Chrome Web Store. Actually currently our Chrome does not support add-ons at all. See bug #35709 -- Cheers Swedebugia
Filecoin source is now available
Hi "Filecoin is a decentralized storage network that turns the world’s unused storage into an algorithmic market, creating a permanent, decentralized future for the web. Miners earn the native protocol token (also called “filecoin”) by providing data storage and/or retrieval. Clients pay miners to store or distribute data and to retrieve it. Check out How Filecoin Works for more." It is dual licensed MIT&Apache2 It is build using rust and go so it might be a challenge to package. It is packaged in very few other distros yet to my knowledge (found https://aur.archlinux.org/packages/go-filecoin/ and that is outdated). https://github.com/filecoin-project/go-filecoin -- Cheers Swedebugia
Re: Cuirass Ghzminutes enhancement idea
Hi On 2019-06-21 18:01, Andreas Enge wrote: On Fri, Jun 21, 2019 at 05:43:54PM +0200, swedebugia wrote: Maybe we could have an additional time measurement: Ghzminutes. E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes. 180 GHzmin? Yes, thanks for correcting me! At 1 Ghz it would have taken 180 minutes. :) -- Cheers Swedebugia
Cuirass Ghzminutes enhancement idea
Hi I would like to estimate how long building the rust toolchain would take on my 2-c 2.2 Ghz laptop. I asked on irc and had an idea of improvement: swedebugia: you can check the build duration for past builds on ci.guix.gnu.org most of the build nodes are pretty old and weak, though probably still faster than a 2-core celeron. (we’re currently finalising the order for a replacement of all but two build nodes) rekado_, wow new fast nodes :) * bzp har avslutat (Quit: Lost terminal) Maybe we could have an additional time measurement: Ghzminutes. E.g. if the build took 60 minutes on a 3 Ghz machine it took 20 Ghzminutes. The build node would have to communicate the total Ghz used for the build. E.g. if 2-core 3 Ghz= 2*3 Ghz= 6 Ghz. Any thoughts about this? -- Cheers Swedebugia
Grin on Guix
Hi people Grin is a cryptocurrency with a strong focus on fungibility and privacy. They launched their mainnet this january. It is written in rust and I would like to try and package it. If anyone have already worked on this please let me know. https://github.com/mimblewimble/grin/blob/master/doc/build.md#requirements -- Cheers Swedebugia
Re: Help with match
On 2019-05-10 15:53, Timothy Sample wrote: > My guess is that you don’t mean to have that “dependencies” symbol > in the input. > > I was just about to send this, but there’s another issue! The > “synopsis-line” form has five elements, but the pattern “(_ val)” will > only match a two-element list. Should the “An async HTTP client” part > should be a string? > > Hope that helps and good luck with the importer! Thanks a lot for looking at this. 🙂 After writing this email I realized I need to change the peg-patterns to 1) output a string for multiple output 2) match the structure metadata-ref procedure in opam.scm so I dont have to fiddle with the matcher. The parsing of asd-files has proven to be a big challenge because of the diversity of the files (tabs, spaces, different prefix, etc.) -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Help with match
Hi
I am almost finished with the quicklisp importer but I'm stuck with not
being able to match what I want with the pattern matcher.
I (still) don't understand the documentation for this matcher and I
can't get it to do what I want it seems :/
--
Cheers Swedebugia
scheme@(guile-user) [8]> (let ((l '(asd-record (license-line (text-until-dq
MIT)) (synopsis-line (text-until-dq An async HTTP client)) dependencies
(dependencies (text alexandria)) (dependencies (text babel)) (dependencies
(text fast-io)) (dependencies (text cl-async)) (dependencies (text blackbird))
(dependencies (text quri)) (dependencies (text fast-http)) (dependencies (text
fast-io)) (dependencies (text cl-async-ssl)) (dependencies (text cl-cookie))
(dependencies (text file)
(match l ;; <- the input object
(('asd-record (who (_ val)) ...) ;; <- the pattern
who))) ;; <- the expression evaluated upon matching
:170:23: Throw to key `match-error' with args `("match" "no
matching pattern" (asd-record (license-line (text-until-dq MIT)) (synopsis-line
(text-until-dq An async HTTP client)) dependencies (dependencies (text
alexandria)) (dependencies (text babel)) (dependencies (text fast-io))
(dependencies (text cl-async)) (dependencies (text blackbird)) (dependencies
(text quri)) (dependencies (text fast-http)) (dependencies (text fast-io))
(dependencies (text cl-async-ssl)) (dependencies (text cl-cookie))
(dependencies (text file'.
Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [9]> (let ((l '(asd-record (license-line (text-until-dq
MIT)
(match l ;; <- the input object
(('asd-record (who (_ val)) ...) ;; <- the pattern
who))) ;; <- the expression evaluated upon matching
$5 = (license-line)
signature.asc
Description: OpenPGP digital signature
Re: GNOME Core Applications
Hi Dexter On 2019-05-05 15:27, Dexter Morgan wrote: > Hi, > > I was going over list of GNOME Core Applications > at https://en.wikipedia.org/wiki/GNOME_Core_Applications. I am not able > to find half of them in my Guix System as a part of GNOME Desktop. > Aren't these core applications usually bundled with GNOME Desktop? Quite > confused. :( Guix is a work in progress. Did you search for the packages using "guix search"? Would you like to try packaging one of them? See http://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/ If not I suggest you post to help-guix in the future as this mailing list is for developing related questions. Psst: packaging is not as hard as it looks, there are lots of helpful people here to give you hints and a hand if you get stuck. -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: Missing Secure and Private Communication Applications in Guix (REVISED)
On 2019-05-01 15:21, Dexter Morgan wrote:
_*REVISED POST*_
Hello!
I was just browsing FSF's High Priority Projects
(https://directory.fsf.org/wiki/Collection:High_Priority_Projects) and
PRISM (https://directory.fsf.org/wiki/Collection:PRISM).
I found out that some applications listed there for secure and private
communications were not imported into Guix yet. The applications are:
[1] CyrptoCat (https://directory.fsf.org/wiki/Cryptocat)
This has no releases and requires NPM libraries.
[2] Ekiga (https://directory.fsf.org/wiki/Ekiga) *
This is buggy. Last release 5 years ago.
[3] Empathy (https://directory.fsf.org/wiki/Empathy) *
"Empathy is looking for a new maintainer, see Attic/Unmaintained."
We have pidgin, pidgin-otr, Jami and Tox. Tox offers both Voice and
Video calls it seems. Jami offers both Voice and Audio and video
conference calls.
[4] Jitsi (https://directory.fsf.org/wiki/Jitsi) **
No release since oct 2018, requires java and ant.
Supports Gtalk/Hangouts which will have to be evaluated for
freedom/privacy issues.
[5] Linphone (https://directory.fsf.org/wiki/Linphone)
Last release was a year ago. SIP VOIP communicator. We have Jami and Tox.
[6] Ricochet (https://directory.fsf.org/wiki/Ricochet)
Last release 7 Nov 2016
[7] Wire (https://directory.fsf.org/wiki/Wire) **
Written in JS,
"dependencies": {
"@wireapp/certificate-check": "0.1.6",
"@wireapp/commons": "1.6.6",
"auto-launch": "5.0.5",
"axios": "0.18.0",
"electron-window-state": "5.0.3",
"file-url": "3.0.0",
"fs-extra": "7.0.1",
"image-type": "4.1.0",
"lodash": "4.17.11",
"logdown": "3.2.8",
"minimist": "1.2.0",
"moment": "2.24.0",
"open-graph": "0.2.4",
"prop-types": "15.7.2",
"raygun": "0.10.1",
"react": "16.8.6",
"react-dom": "16.8.6",
"react-redux": "7.0.3",
"redux": "4.0.1",
"redux-logger": "3.0.6",
"redux-thunk": "2.3.0",
"uuid": "3.3.2"
* Part of GNOME, but not in Guix yet.
** Very useful for non-techsavvy users.
Thank you!
*HAPPY TO SEE THE COUNT REDUCED :)*
This is not that likely if you don't package one of these yourself.
I found something during my review:
I found guile bindings for tox!
https://github.com/urras/guile-toxcore (no release yet though and they
use an old tox API it seems)
Happy packaging.
--
Cheers
Swedebugia
Guix <-> Wikidata
Hi I went ahead and pushed a proposal to WD creating a property linking to our scheme variables. https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#Guix_Variable_Name WDYT? I suggest we patch our package record to include a field for QID. WDYT? -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: Alternative VPN Clients
On 2019-04-28 11:17, Dexter Morgan wrote: > How can I use it with GNOME NetworkManager ? I think thats not supported yet. > > *Sent:* Thursday, April 25, 2019 at 2:37 PM > *From:* "Leo Famulari" > *To:* "Dexter Morgan" > *Cc:* guix-devel@gnu.org > *Subject:* Re: Alternative VPN Clients > On Wed, Apr 24, 2019 at 06:01:49AM +0200, Dexter Morgan wrote: >> My friend introduced me to GNU/Linux and installed GuixSD on my > laptop. I am >> just getting started on Bash. I find that there is absence of VPN > clients as an >> alternative to OpenVPN. Can some one please package the following > alternative >> VPN clients: > > Just FYI, we have a WireGuard package that works well. You may find it > superior to traditional VPN systems. This seems to require support from the VPN provider and will not work with traditional (open)VPN-providers e.g. Riseup. -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: Quicklisp importer bug in tarball->extract->parse
Hi
Thanks a lot for taking the time to look at this.
On 2019-04-11 16:31, Pierre Neidhardt wrote:
> Hi!
>
> I've had time to look at it a little.
>
> If you want to debug, you can, for instance, put a breakpoint in
> guess-requirements-from-source,
How exactly do you do this?
I looked in the guile manual and found the module (system vm trap-state)
and tried calling add-trap-at-procedure-call! like this:
(add-trap-at-procedure-call!
(system* "tar" "xf" tarball "-C" dir "--wildcards" (string-append "*"
file-name)
But it failed with:
;;; (file-name "1am.asd")
Backtrace:
13 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2 12 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 11 (_ #(#(#)))
In ice-9/boot-9.scm:
2312:4 10 (save-module-excursion _)
3831:12 9 (_)
In guix/import/quicklisp.scm:
404:3 8 (_)
In guix/utils.scm:
618:8 7 (call-with-temporary-output-file _)
632:8 6 (call-with-temporary-directory _)
In guix/import/quicklisp.scm:
374:32 5 (_ "/tmp/guix-directory.Z4chBm")
In srfi/srfi-1.scm:
592:17 4 (map1 ("1am.asd"))
In guix/import/quicklisp.scm:
380:41 3 (_ _)
In system/vm/trap-state.scm:
213:15 2 (add-trap-at-procedure-call! 0 _)
In system/vm/traps.scm:
137:45 1 (trap-at-procedure-call 0 # #:our-frame? _)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("Not a VM program" 0) #f)
ERROR: In procedure scm-error:
Not a VM program 0
> There is nothing wrong with find-files: the "dir" directory is empty.
> This is because the extraction failed:
> check the exit-code of system* before proceeding, you'll see what
> happens ;)
>
> --8<---cut here---start->8---
> (system* "tar" "xf" tarball "-C" dir file-name)
> --8<---cut here---end--->8---
>
> The above will error out if "file-name" is not found. For 1am:
>
> Queried file-name:
>
> "1am.asd"
>
> Tarball actual file:
>
> "1am-20141106-git/1am.asd"
>
> I don't think we can predict the root folder, and more generally
> projects have different trees.
> So I suggest we extract the whole tarball and proceed from there. So
> your code should work by just removing "file-name":
>
> --8<---cut here---start->8---
> (system* "tar" "xf" tarball "-C" dir)
> --8<---cut here---end--->8---
>
> Makes sense?
Yes. I implemented Ricardos wildcard-suggestion:
(system* "tar" "xf" tarball "-C" dir "--wildcards" (string-append "*"
file-name))
>
> Unrelated comment: If I'm not mistaken, you are fetching the meta-file
> and the index-file on every query. I suggest you keep those in memories
> as soon as possible (memoize them), this will allow you to iterate much
> faster when developing.
I already tried by adding:
(memoize
(let* ( ;;(name "circular-streams")
(name "1am")
(source-url (ql-extract 'url name))
(asd (ql-extract 'system-files name)))
(peek 'asd asd)
(call-with-temporary-output-file
(lambda (temp port)
(begin (url-fetch source-url temp)
(guess-requirements-from-source source-url asd temp)
)
and
(let* ( ;;(name "circular-streams")
(name "1am")
(source-url (memoize (ql-extract 'url name)))
(asd (memoize (ql-extract 'system-files name
(peek 'asd asd)
(call-with-temporary-output-file
(lambda (temp port)
(begin (url-fetch source-url temp)
(guess-requirements-from-source source-url asd temp)
But it still fetches the index-file 2 times regardless where I put it.
Any ideas?
> It seems that you are on the right track, great job!
Thanks for the encouragement!
--
Cheers Swedebugia
signature.asc
Description: OpenPGP digital signature
Re: Software Heritage & Guix
On 2019-03-30 19:03, zna...@tutanota.com wrote: > I've translated into Russian here > https://www.opennet.ru/tips/info/3100.shtml > It is interesting occupation to study and translate something when I > have free time. Nice. I like translating too :) -- Thanks Ludo, I liked the article. Maybe this could be spread in more places like slashdot, reddit, wikinews etc. to reach a wider audience. Is it ok if I request for an interview in Wikinews with you Ludo? https://en.wikinews.org/wiki/Wikinews:Request_an_interview -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Quicklisp importer bug in tarball->extract->parse
Hi I continued working on it and have run into a bug with extracting and parsing files in the tarball (like the pypi importer does) This is really putting my lisp skills to the test I feel like i'm in over my head here. 😛 The idea is to - first extract information from quicklisp - done - then extract the tarball - done - then find the 'name'.asd-file in the extracted directory - fails - then parse with PEG - todo - then print the result - todo Does anyone have a clue what is wrong or how to debug (find-files)? Here is the code: https://gitlab.com/swedebugia/guix/tree/quicklisp Here is the output: Starting download of /tmp/guix-file.Q7fTrf From https://beta.quicklisp.org/dist/quicklisp.txt... quicklisp.txt 408B 202KiB/s 00:00 [##] 100.0% Starting download of /tmp/guix-file.N8gfUL From http://beta.quicklisp.org/dist/quicklisp/2019-03-07/releases.txt... releases.txt 423KiB 1.1MiB/s 00:00 [##] 100.0% Starting download of /tmp/guix-file.B6vRet From https://beta.quicklisp.org/dist/quicklisp.txt... quicklisp.txt 408B 223KiB/s 00:00 [##] 100.0% Starting download of /tmp/guix-file.QA07gb From http://beta.quicklisp.org/dist/quicklisp/2019-03-07/releases.txt... releases.txt 423KiB 768KiB/s 00:01 [##] 100.0% ;;; (asd "1am.asd") Starting download of /tmp/guix-file.4QyAk4 From http://beta.quicklisp.org/archive/1am/2014-11-06/1am-20141106-git.tgz... …06-git.tgz 3KiB4.2MiB/s 00:00 [##] 100.0% ;;; (dirname "1am-20141106-git") ;;; (system-files "1am.asd") ;;; (dir "/tmp/guix-directory.DnfwBX") ;;; (file-name "1am.asd") ;;; (find-files ()) warning: Failed to extract requirements files -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
On 2019-03-29 16:16, Andreas Enge wrote: > On Fri, Mar 29, 2019 at 03:02:00PM +0100, Tobias Geerinckx-Rice wrote: >> I still think this change should be reverted > > I also think so. Agreed, I remember having proposed and gotten a 1 name change through the patch-review-process and that worked fine and that I had to deprecate the old name properly to get it accepted. Pierre would you be willing to prepare some patches to include the long names/project names in the descriptions instead and send them to the patches-list? > > The wording in the naming guidelines is intentionally a bit vague; > the intention was definitely to take in general the tarball name, or maybe > if this does not fit the domain name or something "similarly canonical". > The tarball name does not always work, for instance in cases where it is > "v0.15.zip". So we cannot have a strict rule, but the idea was to take the > "canonical short name". When writing the section, I did not expect this > part to lead to controversies; the real question was how to handle special > characters (lowercase, replace underscores with dashes), and what to do > for (at the time) python packages. > > I am happy to make the wording clearer. But I am not sure whether replacing > "project name" by "package name" makes a difference. What is a "package"? > But if you think it is better, why not. > > We could also add "short" in front of "projet"/"package name", and maybe > add that this usually corresponds to something like the base name of the > tarball, the git repository name or the domain where the project is hosted. > > What do you think? 👍 -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
On 2019-03-27 16:00, Ricardo Wurmus wrote: > > Pierre wrote: >> Finally, as I mentioned above with the completion systems that we have, >> we've got nothing to lose in having long names. Reading the arguments of Ricardo I changed my mind and support keeping the variable names short. > > swedebugia wrote: >> Good useability is important and cryptic acronyms are not something to >> expose to the user if possible to avoid IMO. > >> Maybe this is where we need to discuss what our target audience is? >> Nerds only? […] > > This is a false dichotomy, in my opinion. Good usability is not at odds > with using short package names. I also think that the length of package > names is not going to be a deciding factor for somebody who is not a > “nerd”, so let’s not go down this tangent please. There are different > interfaces to package managers, and we’re currently not offering fully > functional interfaces that would be more suitable for people without a > “techie” background. If you want to make Guix more accessible *that’s* > a screw to turn, not the length of package names. Thanks for sharing this. I regret having written this as a dichotomy. I'm actually very happy with guix overall and the guix-web frontend is awesome. :) I'm sorry if I added tension to this discussion. I will try expressing myself less confrontationally going forward. > > Completion should not be used as an excuse to use long package names. > For one, not everyone is using Bash, so not everyone benefits from our > Bash completions. (Some shells can reuse Bash completions but this does > not invalidate the point.) I agree. > > The package name is just an identifier for command line interaction > purposes. There is no reason why it should be descriptive – after all, > that’s what the package description is used for. Users can easily find > the package they are interested in by using the search feature. That > will give them the short name by which they can refer to the package. > Having that short name be long serves little purpose. I agree. Would you agree that we try to strike a compromise with short package variable names, synopsis' and longer descriptions? Should we state this clearly in the documentation for packagers? I guess a GUI-search would work like guix-web and search all three for hits and displaying the results. -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: Libre games that might be worth packaging :)
On 2019-03-18 14:55, Ricardo Wurmus wrote: > > Pierre Neidhardt writes: > >> Ricardo Wurmus writes: >> >>> We have this. It’s called “btanks”. >> >> Shouldn't we name this "battle-tanks"? >> >> >>> I think this one is packaged: see the `crawl' and `crawl-tiles' packages. >> >> Shouldn't we name this "dungeon-crawl-stone-soup"? >> >> >>>> Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the >>>> classic Tron arcade game. Highly configurable and very fun to play. >>> >>> This we have already. :) >> >> It's named "armagetronad". Shouldn't we name this >> "armagetron-advanced"? > > Instead of renaming the packages (whose names follow our packaging > guidelines) how about adding the full name of the games to the > description? 👍 This would have helped me find the packages when I compiled the list :) -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: 05/15: gnu: wesnoth: Rename package to the-battle-for-wesnoth.
Pierre Neidhardt skrev: (27 mars 2019 12:46:26 CET) >Ludovic Courtès writes: > >> Apologies if I missed a previous discussion on this topic, but… I’m >> skeptical about the renames. I assume that the original names were >> those commonly used in distributions, which in itself may be a good >> reason to keep them. > >Names may vary a lot across distributions. Especially when it comes to >games, since they tend to have more exotic titles. > >If the majority of distributions decides on a poor name, we don't have >to repeat the same mistake ;) > >> Those names are also used upstream in some cases: the tarball for >> wesnoth is called “westnoth*.tar.gz”, for example, and the GitHub >> project of L’Abbaye des morts is “abbayedesmorts” (no ‘l’). Like our >> naming guidelines say (info "(guix) Package Naming"), we should try >to >> stick to the upstream name. >> >> Thoughts? > >I think it's important to ask "why should we name a package this way." >What's the rationale behind a package name? > >We are facing the users, not package maintainers. Users are not >supposed to know about: > >- domain names >- tarball names >- github names > >Those are details, in my understanding, reserved to developers and >packagers. >More often than not, those shortened names are used because of >technical >limitations (e.g. character length). We don't have to forward those >limitations on ourselves. > >I think it makes sense that we expose to the users names that speaks to >them, i.e. the "official project full name". > >Finally, as I mentioned above with the completion systems that we have, >we've got nothing to lose in having long names. > >My two cents :) > >-- >Pierre Neidhardt >https://ambrevar.xyz/ I agree with Pierre. 😃 Good useability is important and cryptic acronyms are not something to expose to the user if possible to avoid IMO. Maybe this is where we need to discuss what our target audience is? Nerds only? Random Joe who is new to GNU systems but dead tired of the proprietary systems he was taught in school who heard og Guix through a good friend who helps him getting started? Tangent to this is the focus on an installer. Why bother with an installer if we only target nerds and educated computer professionals? Anyone else who have opinions on the matter of acronyms in names where they can be avoided? -- Sent from my k-9 mail for Android.
Re: Libre games that might be worth packaging :)
Pierre Neidhardt skrev: (18 mars 2019 16:32:26 CET) >Ricardo Wurmus writes: > >> Pierre Neidhardt writes: >>> It's named "armagetronad". Shouldn't we name this >>> "armagetron-advanced"? >> >> Instead of renaming the packages (whose names follow our packaging >> guidelines) how about adding the full name of the games to the >> description? > >That would not help interfaces like Emacs-Guix and >Helm-System-Packages. >I think names are more important than having obsolete packages :) > >-- >Pierre Neidhardt >https://ambrevar.xyz/ I agree. What about adding a pretty name to show the user that matches the marketing name of the software? Arch seems to have this and it is used in the gui tools like pamac but not on the command line. We could solve this by adding a new optional field to the package record (pretty-name "Armagetron Advanced") For the packages that lack this field I would in the gui display them like this: (name "aircrack-ng") -> Aircrack-ng -- Sent from my k-9 mail for Android.
Re: Libre games that might be worth packaging :)
On 2019-03-17 17:51, swedebugia wrote: Hi! I just went through Julie Marchants excellent list of libre games: https://onpon4.github.io/articles/libre-games.html There are so many! :) Currently we are missing these (according to https://guix.mdc-berlin.de/): A7Xpg - An arcade game centered around avoiding enemies while collecting as many gold pieces as possible. Centered around a "booster" which repels enemies and makes you go faster. Adanaxis - A first-person 4-D space shooter game. Literally "adds an axis" to typical 3-D space shooters for a very unique experience. Alex the Allegator 4 - A fun, lighthearted, short platformer. Armagetron Advanced - A 3-D variant of the Light Cycles sub-game of the classic Tron arcade game. Highly configurable and very fun to play. This we have already. :) B.A.L.L.Z. - Highly engaging action puzzle game centered around a character that moves automatically. You start with only one action (jumping) and gain two more actions later in the game. Battle Tanks - An engaging multiplayer overhead shooter game. Features deathmatch and cooperative modes. Includes a nice selection of tanks and weapons. When your current tank is destroyed, your character ejects from it as an infantry unit and can search for and board a new one, or continue fighting on foot. Criticalmass - A simple space shooter game similar in style to games like Galaxian with great production value and balance. The game awards you with more/better weapons for playing at higher difficulty levels. Dink Smallwood (GNU FreeDink) - A funny Zelda-style RPG. Dopewars - A simple game where you buy drugs for cheap and then sell them to make a profit, avoiding (or fighting) cops along the way. You have one month to make as much money as you possibly can. Dungeon Crawl Stone Soup - A very fun and well-made dungeon crawl game with a nice interface. Find the "Orb of Zot" and then exit the dungeon (without getting yourself killed, of course) to win! Endgame: Singularity - A very fun real-time strategy game from the perspective of the Singularity, an advanced A.I. that seeks to eventually surpass reality itself. Help the Singularity achieve the highest possible state before the humans uncover its presence and destroy it. Flare: Empyrean Campaign - A very fun, engaging, well-balanced, and detailed isometric action fantasy RPG about someone who has been exiled from their homeland and their quest to regain entry. Funguloids - A simple arcade game where you control some sort of blob thing in space, collecting mushrooms while avoiding asteroids. The thing you control moves at a constant speed which increases as you collect mushrooms and move through levels, so it gets harder and harder until you finally mess up. Great production value and very fun to play. Gunroar - An abstract naval-themed bullet hell game. Hex-a-Hop - A fun puzzle game where you have to find the right path to clear the board of tiles. Inside a Star-filled Sky - Progress as deep as you can into an endless abstract world. Your actions in the current level affect the state of your character in the next level. You can enter into yourself and enemies, regressing back a level, to change their properties if you find yourself in a pinch. Very unique and challenging. Jump 'n Bump - A classic multiplayer deathmatch game where you stomp on your friends' heads. Features fully customizable graphics, allowing you to create any kind of map you can imagine if you are so inclined. Krank - A puzzle game incorporating elements from Pool/Billiards. You have to use a large ball to bump smaller balls into their proper place. Includes a lot of variety and gets quite challenging later on. Konquest - A fun turn-based strategy game which is a twist on the Risk board game. Send ships from planets you control to conquer others. Crush all other empires and conquer the whole galaxy to win! Liquid War - A unique real-time strategy game: you tell your liquid what direction to move in, and nothing else. Liquid attacks enemy liquid when it goes in its direction. Your goal is simply to end up with more liquid than all of your opponents when the timer runs out. For such a simple concept, it is surprisingly engaging. Meritous - A fun action-adventure dungeon crawler game. Micropolis - The libre version of Sim City Classic. This is not a clone, but actually directly based on the Unix port of Sim City. Mindustry - A pixel-styled "sandbox tower defense" game centered around building networks to collect materials and then using those materials to build defense systems. Fantastic production value and highly engaging, with online multiplayer support. Mirror Magic - A fun puzzle game where you have to use mirrors to manipulate a beam. Mu-cade - A unique abstract shooter game taking place on a ring. Knock your enemies off the ring while preventing them from knoc
Libre games that might be worth packaging :)
tformer with a retro style. Noiz2sa - A fun and challenging abstract bullet hell game with nice graphics. OpenClonk - A fun game combining elements of parkour with elements of RTS games. Features multiple game modes and has great production value. Overgod - A fun twist on the classic Asteroids, featuring several different ships, multiplayer support, powerups, and "asteroids" that shoot back. Phlipple - A simple, but engaging puzzle game centered around folding 3-D objects together. Ri-li - A simple game centered around helping a train collect all cars on the board without allowing it to run into itself. Effectively, a variant of Snake where you are only allowed to move along set paths. rRootage - An abstract bullet hell game. Your weapon is a continuous beam that fires straight forward, and all enemies are boss-like. Rocks'n'Diamonds - A highly sophisticated game combining elements of Boulder Dash, Emerald Mine, Supaplex, and Sokoban as well as several original elements, creating an engine that is capable of highly varied gameplay. If that wasn't enough, the production value is great, too. Sleep Is Death - A unique 2-player-only RPG, limited only by the players' imagination. Slingshot - A fun 2-player turn-based strategy game centered around aiming shots so that the gravity of nearby planets flings them toward the enemy ship. SolarWolf - A simple, but very fun game based on the Atari 2600 game SolarFox, but with much better production value. Centered around collecting cubes as quickly as possible while avoiding gunfire. Spout - A simple abstract game where you use a spray to propel as high as you can through the level, without touching obstacles. Spraying the obstacles erodes them, clearing the path. Titanion - An abstract shooter game in a style similar to the bonus stages of Galaga, with great visuals and an emphasis on fast action. Torus Trooper - A highly fast-paced abstract shooter where you travel down a tube as fast as you can, destroying enemies to regain your timer and avoiding getting shot yourself (which causes you to lose time). TUMIKI Fighters - A fun abstract side-scrolling shooter where you can pick up enemy "toys" to use as both extra weapons and shields. Which Way Is Up? - A simple puzzle-platformer centered around rotating the stage to make it to the exit. Word War vi - A simple, fun abstract shooter inspired by the famous rivalry between Emacs and vi. see also the authors own games under "games". -- Cheers Swedebugia
Re: Go build system updates and future work?
Pierre Neidhardt skrev: (15 mars 2019 07:54:49 CET) >What about adding and extra key #:test-directories that takes a list of >directories where we would "cd && go test"? > >-- >Pierre Neidhardt >https://ambrevar.xyz/ +1 -- Sent from my k-9 mail for Android.
Re: Request for commit access
Alex Vong skrev: (14 mars 2019 20:24:52 CET) >Hello all, > >Laura Lazzati writes: > >> Hi Paul :) >> >>> I am looking forward to viewing the videos after I have cloned the >>> repository as a member. Initially, I am not planning to make any >>> changes, just to make an estimate of the total speaking time. >> I more or less added what it took to me, but when you record even a >> draft because of the format, that would be the "real timing". I guess >> I told you but the only parts in which I did not record the audios >was >> in the cli session videos. Now that I have a headset and the >> environmental noice is reduced quite a lot, I could try to add my >> voice to them, WDYT Guix? But for the slide videos, my voice and the >> transcript are enough for a reference :) >> >Just in case people don't know about it, there's a wonderful piece of >free software called audacity, which can be used for audio processing. > >While I haven't tried it before, I believe it can be used for noise >reduction. (I myself mostly use audacity for fade in, fade out, >loudness >normalization, changing tempo, adding silence and overlaying tracks.) > >Hope it help :) > >> Regards :) >> Laura > >Cheers, >Alex I have used the noise correction in audacity. It is brilliant and very easy to use 😃 -- Sent from my k-9 mail for Android.
Re: Regarding freedom issues
Ricardo Wurmus skrev: (12 mars 2019 13:32:26 CET) > >swedebugia writes: >> The idea is to add to guix a way to inform the user that the package >> they just searched for is not included in guix because of freedom >> issues. >> >> The idea is that when we refuse a package to be included we add it >> with a short reason to this list. >> >> Something like this >> (issues >> (package odoo >> (reason "trapping users by withholding update scripts, see >gnu.org/link.to.article" >> (alternatives '(dolibarr tryton smbledger ledger hledger gnucash))) > >I don’t think it’s a good idea to clutter Guix with packages that we >won’t add. There’s already a lot in Guix to provide free software >packages; I don’t think we should add “negative packages”. > >That’s out of scope for Guix and could be handled by some other GNU >resource instead. > >-- >Ricardo Ok. I understand. -- Sent from my k-9 mail for Android.
Regarding freedom issues
Hi. I had the idea of integrating guix more with GNU when it comes to packages with freedom issues. The idea is to add to guix a way to inform the user that the package they just searched for is not included in guix because of freedom issues. The idea is that when we refuse a package to be included we add it with a short reason to this list. Something like this (issues (package odoo (reason "trapping users by withholding update scripts, see gnu.org/link.to.article" (alternatives '(dolibarr tryton smbledger ledger hledger gnucash))) This makes it clear to the user that they can scratch the itch and fix the problems by contacting upstream, fork or whatever or choose a better alternative. What do you think? -- Sent from my k-9 mail for Android.
Help needed with newmoon
Hi
My pet project for today was working on getting newmoon to build. I
failed :/
I got the definition from ng0 and have improved a few things and updated
it to the newest version.
I investigated the 3 errors below:
1. sqlite3 needs to be compiled with SQLITE_ENABLE_FTS3 (this results in
a lot of builds, patch attached)
2. our libvpx does not provide vpx_mem/vpx_mem.h even though it is in
the source of libvpx it is not installed it seems.
3. the pulseaudio-error I do not understand: : fatal error:
when writing output to : Broken pipe ??
Here are the errors with context:
0:19.11 checking for vpx >= 1.5.0... yes
0:19.11 checking MOZ_LIBVPX_CFLAGS...
0:19.11 checking MOZ_LIBVPX_LIBS...
-L/gnu/store/7s6z2ybw86k7r97cwzrix9hngs729lrk-libvpx-1.8.0/lib -lvpx -lm
0:19.17 checking for vpx/vpx_decoder.h... yes
0:19.38 checking for vpx_codec_dec_init_ver in -lvpx... yes
0:19.42 checking for vpx_mem/vpx_mem.h... no
0:19.44 checking for libpulse... yes
0:19.45 checking MOZ_PULSEAUDIO_CFLAGS... -D_REENTRANT
0:19.45 checking MOZ_PULSEAUDIO_LIBS...
-L/gnu/store/hd3x89yknm4k6k4gw16jy5xk7idq1sxf-pulseaudio-12.2/lib -lpulse
0:19.47 : fatal error: when writing output to : Broken pipe
0:19.47 compilation terminated.
0:19.48 /tmp/guix-build-newmoon-28.4.0.drv-0/source/old-configure: line
14935: test: : integer expression expected
0:19.50 checking for wget... no
0:19.52 checking for sqlite3 >= 3.26.0... yes
0:19.52 checking SQLITE_CFLAGS...
0:19.52 checking SQLITE_LIBS...
-L/gnu/store/kg104rhqzvmnpqxk91ayvwxzsrncr0f4-sqlite-3.26.0/lib -lsqlite3
0:19.67 checking for SQLITE_SECURE_DELETE support in system SQLite... yes
0:19.78 checking for SQLITE_THREADSAFE support in system SQLite... yes
0:19.90 checking for SQLITE_ENABLE_FTS3 support in system SQLite... no
0:19.90 configure: error: System SQLite library is not compiled with
SQLITE_ENABLE_FTS3.
0:19.93 DEBUG:
0:19.94 DEBUG: configure:15039: checking for wget
0:19.94 DEBUG: configure:15362: checking for sqlite3 >= 3.26.0
0:19.94 DEBUG: configure:15369: checking SQLITE_CFLAGS
0:19.94 DEBUG: configure:15374: checking SQLITE_LIBS
0:19.94 DEBUG: configure:15405: checking for SQLITE_SECURE_DELETE
support in system SQLite
0:19.94 DEBUG: configure:15428:
/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin/gcc -std=gnu99
-o conftest -fno-strict-aliasing -fno-math-errno -msse2 -mfpmath=sse
-pthread -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
conftest.c -ldl
-L/gnu/store/kg104rhqzvmnpqxk91ayvwxzsrncr0f4-sqlite-3.26.0/lib
-lsqlite3 1>&5
0:19.94 DEBUG: configure:15451: checking for SQLITE_THREADSAFE support
in system SQLite
0:19.94 DEBUG: configure:15474:
/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin/gcc -std=gnu99
-o conftest -fno-strict-aliasing -fno-math-errno -msse2 -mfpmath=sse
-pthread -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
conftest.c -ldl
-L/gnu/store/kg104rhqzvmnpqxk91ayvwxzsrncr0f4-sqlite-3.26.0/lib
-lsqlite3 1>&5
0:19.94 DEBUG: configure:15497: checking for SQLITE_ENABLE_FTS3 support
in system SQLite
0:19.94 DEBUG: configure:15520:
/gnu/store/n2p1zs14y89lwkg9da68y12pc10c6sw9-gcc-5.5.0/bin/gcc -std=gnu99
-o conftest -fno-strict-aliasing -fno-math-errno -msse2 -mfpmath=sse
-pthread -lpthread -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id
conftest.c -ldl
-L/gnu/store/kg104rhqzvmnpqxk91ayvwxzsrncr0f4-sqlite-3.26.0/lib
-lsqlite3 1>&5
0:19.94 DEBUG: configure: failed program was:
0:19.94 DEBUG: #line 15511 "configure"
0:19.94 DEBUG: #include "confdefs.h"
0:19.94 DEBUG:
0:19.94 DEBUG: #include "sqlite3.h"
0:19.94 DEBUG:
0:19.94 DEBUG: int main(int argc, char **argv){
0:19.94 DEBUG: return
!sqlite3_compileoption_used("SQLITE_ENABLE_FTS3");
0:19.94 DEBUG: }
0:19.94 DEBUG: configure: error: System SQLite library is not compiled
with SQLITE_ENABLE_FTS3.
0:19.94 ERROR: old-configure failed
0:19.98 *** Fix above errors and then restart with\
0:19.98
"/gnu/store/7j3941iannrngdvgbclyxid12vds5w9i-make-4.2.1/bin/make -f
client.mk build"
0:19.98 make[1]: *** [client.mk:378: configure] Error 1
make: *** [GNUmakefile:9: build] Error 2
--
Cheers Swedebugia
From 89c0629198b10264c07de88f2f678af5292d4fbf Mon Sep 17 00:00:00 2001
From: swedebugia
Date: Sat, 23 Feb 2019 05:34:45 +0100
Subject: [PATCH 1/2] WIP gnu: Add New Moon.
---
gnu/packages/web-browsers.scm | 400 +-
1 file changed, 395 insertions(+), 5 deletions(-)
diff --git a/gnu/packages/web-browsers.scm b/gnu/packages/web-browsers.scm
index a19a0dc7c..105fe2839 100644
--- a/gnu/packages/web-browsers.scm
+++ b/gnu/packages/web-browsers.scm
@@ -4,10 +4,12 @@
;;; Copyright © 2015, 2016 Efraim Flashner
;;; Copyright © 2016 Kei Kebreau
;;; Copyright © 2017 Eric Bavier
+;;; Copyright © 2017, 2018 Nils Gillmann
;;; Copyright © 2018, 2019 Tobias Geerinckx-Ri
Re: Guix on the ASUS C201PA
Thanks a lot for sharing this 😃 -- Sent from my k-9 mail for Android.
Re: ci.guix.info 504 gateway timeout (was Re: guix package builds, subsitutes and --no-build)
On 2019-02-21 16:14, Giovanni Biscuolo wrote: snip > > in my case (I'm on Debian with systemd) I have to add an "Environment=" > parameter in /etc/systemd/system/guix-daemon.service, reload the systemd > file and restart the service If this is not explained in the manual could you send a patch to include this? -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Investigating a missing substitute on berlin
Hi Today I tried installing musescore 3.0.2 on a very recent guix. It resorted to building. "building /gnu/store/54ljg7cfj5cnszfyzbzxarcgvmd13g6w-musescore-3.0.2.drv" I tried going to berlin to check why it was not built there and available but failed to find it. Is there any recommended way of doing this? -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
The value of adopting GNU Guix for Linux package management
https://github.com/malcook/sce/blob/master/MakingTheCase.org Is now cc-by-sa Originalmeddelande Från: Malcolm Cook Skickat: 24 februari 2019 01:07:28 CET Till: malcook/sce Kopia: swedebugia , Author Ämne: Re: [malcook/sce] License missing (#2) add CC license -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/malcook/sce/issues/2#issuecomment-466715810 -- Sent from my k-9 mail for Android.
Re: OSM tile server with Guix
On 2019-02-23 13:32, Gábor Boskovits wrote: > Hello, > > swedebugia ezt írta (időpont: 2019. febr. 23., > Szo, 12:03): snip >> * carto (uses npm and node) https://www.npmjs.com/package/carto (7 >> dependencies - at least 1 with a lot of dependencies (yargs)) > > My usecases usually can be solved using hand-authored styles, but would be > nice to have. (Carto usually created something very bloated for me) Ok. > >> * openstreetmap-carto (contain carto-css styles and a lua-script useful >> for tag-transformation when loading pbf-files into a postgis database >> with osm2pgsql and get-shapefiles.py a script to download low-zoom >> country boundaries) https://github.com/gravitystorm/openstreetmap-carto/ >> >> This last one should perhaps be included in our osm2pgsql-package >> because it is hard to imagine someone using one but not the other. > > I sometimes use osm2pgsql without any need for rendering, so when using > the database not for rendering, but as a database, these functions are > not needed. > I would keep these separate. Wdyt? Ok, I will add packaging openstreetmap-carto to my list. Renderd comes with mod_tile. signature.asc Description: OpenPGP digital signature
OSM tile server with Guix
Hi I read up on how to setup a tile server with the least hassle. It is quite a bit involved according to this guide: https://switch2osm.org/manually-building-a-tile-server-18-04-lts/ I imagine this could be more fully automated with guix if we find a way to run the pgsql-commands from guile and write the necessary services. We have most of the bits and pieces already but I spotted a few that were missing while reading and thought I would share them here: * mod_tile (apache plugin) https://github.com/openstreetmap/mod_tile * carto (uses npm and node) https://www.npmjs.com/package/carto (7 dependencies - at least 1 with a lot of dependencies (yargs)) * openstreetmap-carto (contain carto-css styles and a lua-script useful for tag-transformation when loading pbf-files into a postgis database with osm2pgsql and get-shapefiles.py a script to download low-zoom country boundaries) https://github.com/gravitystorm/openstreetmap-carto/ This last one should perhaps be included in our osm2pgsql-package because it is hard to imagine someone using one but not the other. It seems we need a renderd-service also. Thoughts? -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: Renewing certificates with certbot
On 2019-02-22 14:49, Julien Lepiller wrote: > Hi, > > I use certificates from let's encrypt for my website and mail servers, > and found that there was an issue with certificates generated by the > certbot service in Guix: the generated private keys are world-readable > (in a directory that cannot be accessed by anyone but root, so it's OK I > guess). OpenSMTPD is not happy with that though, so I have to chmod the > files every time. I came up with a variant of the deploy-hook that's > presented in the manual, and I'd like to update the example with it. > Here it is: > > ;; Find running nginx and reload its configuration (for certificates) > (define %my-deploy-hook > (program-file > "my-deploy-hook" > #~(let* ((pid (call-with-input-file "/var/run/nginx/pid" read)) > (cert-dir (getenv "RENEWED_LINEAGE")) > (privkey (string-append cert-dir "/privkey.pem"))) > ;; certbot private keys are world-readable by default, and smtpd > complains > ;; about that, refusing to start otherwise > (chmod privkey #o600) > (kill pid SIGHUP > > What do you think? > LGTM. -- Cheers Swedebugia signature.asc Description: OpenPGP digital signature
Re: wrapping up the Newmoon Browser package
Hi > Can you find evidence that > Pale Moon has made such a commitment for their add-ons repository? I did not find any such statements. I did find non-free addons though. E.g. FireShot listed here: https://addons.palemoon.org/extensions/tools-and-utilities/ It took some time to find a non-free one, so I guess they are rare like 1% of the total or less. -- Cheers Swedebugia
Re: upgrading on GuixSD before 0.16 to 0.16 fails
n...@n0.is skrev: (21 februari 2019 18:09:53 CET) >Hi, > >I'm currently trying to upgrade out (gnunet) server to a new >version of GuixSD. Upgrading it was put off for a while due to research >reasons. > >This installation is from November '18, and I'm getting stuck on a >backtrace when I'm trying to pull from the commit 0.16 tags or >anything after it. > >Here's the backtrace. If it helps I can attach the config. > >root@firefly ~/gnunet-maintenance/gnunet# guix system build config.scm >guile: warning: failed to install locale >hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' >package and >defining `GUIX_LOCPATH', along these lines: > > guix package -i glibc-utf8-locales > export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" > >See the "Application Setup" section in the manual, for more info. > > >Backtrace: > 14 (primitive-load "/root/.config/guix/current/bin/guix") >In guix/ui.scm: > 1603:12 13 (run-guix-command _ . _) >In ice-9/boot-9.scm: > 829:9 12 (catch _ _ # ?) > 829:9 11 (catch _ _ # ?) >In guix/scripts/system.scm: > 1268:8 10 (_) >In guix/status.scm: >615:4 9 (call-with-status-report _ _) >In guix/scripts/system.scm: > 1138:6 8 (process-action _ _ _) >In guix/store.scm: > 1659:24 7 (run-with-store _ _ #:guile-for-build _ #:system _ # _) >In guix/scripts/system.scm: > 1151:13 6 (_ _) > 869:18 5 (perform-action build #< kernel: # ?) >In gnu/system.scm: > 840:19 4 (operating-system-derivation _ #:container? _) >In gnu/services.scm: >743:6 3 (instantiate-missing-services _) >In guix/combinators.scm: > 45:26 2 (fold2 # ?) > 45:26 1 (fold2 # ?) >In gnu/services.scm: > 723:31 0 (_ _ (#< type: # ?) ?) > >gnu/services.scm:723:31: In procedure struct_vtable: Wrong type >argument in position 1 (expecting struct): shepherd-root-service-type We need your config to be certain but I am guessing you are bitten by the ABI changes: service->service-type. Though this usually gives a more helpful error. -- Sent from my k-9 mail for Android.
Re: New topic: packaging
"Björn Höfling" skrev: (13 februari 2019 10:13:22 CET) >On Mon, 11 Feb 2019 11:38:21 -0300 >Laura Lazzati wrote: > >> Hi Guix again! >> >> Another topic is about showing how to package. >> >> Gábor suggested maybe using my experience about creating a new R >> package. >> >> My idea is to show how to look for a package that is not packaged, >> package it and the workflow for testing it with git am and send it to >> the patches list. WDTY? > >Aggreed on R: There is the importer to show, and R-packages are usually >easy to go. > >We have the rough idea of steps to take in the manual. Point people to >the right chapter here. > >Then it would involve the whole things: > >* git clone ... >* go into guix directory >* Enter the environment: > guix environment guix > --> Explain what happens here and what's so cool about it. >* ./bootstrap >* ./configure --localstatedir=/var >* make >* Then the import begins: >* ./pre-inst-env guix import ... >* [hack file, using emacs, maybe ./pre-inst guix edit new-package] >* ./pre-iinst-env guix build new-package >* Check: > ./pre-inst-env guix lint new-package >* Finally: > Commit, take care of the correct commit messsages >* git format-patch and maybe git send-email > >This is a lot for even a simple R package but I don't see how/where we >could leave out steps without confusing people. > >Björn Hi. Am I late to the party? Here is my two cents. I suggest splitting this in multiple videos. Split after make is finished. I agree it is hard to cover less than this if we want to nudge people into contributing new packages and guide them the whole way. If you decide to go with ./pre-inst guix edit new-package then I suggest we fool proof it by prepending EDITOR=emacs Given this I suggest the video starting after make also include setting up emacs. This might even warrant its own short video. So we end up with 3! Generally I think shorter videos to the point are preferred over long ones bundling multiple things. Maybe we should cut it also after successful build and test and make the comitting a separate video. That gives us 4 in total 😃 -- Sent from my k-9 mail for Android.
Re: It's time to build "guix deploy"
Giovanni Biscuolo skrev: (14 februari 2019 15:17:34 CET) >Hi swedebugia! > >swedebugia writes: > >[...] > >> I understand most parts of it ;) >> It is a real beauty and a testiment to the power of Guix and Guile. > >[...] > >>> IMHO your remote host configuration technique deserves a dedicated >>> blog >>> article... but I've already asked too much :-) >> >> Good idea! > >given you understand most part of it, why don't you try to write an >exegesis of that code yourself ;-) I could certainly try to do that but Ricardo said himself "its not great..." so I don't know if it is a good idea. Anyway it draws on quite a lot of modules so I would have to look at them too to get the whole picture. Which parts would you like explained? Hi -- Sent from my k-9 mail for Android.
Re: New topic: asking for help
Alex Vong skrev: (16 februari 2019 19:58:39 CET) >Laura Lazzati writes: > > >>> We might also propose the mumi as the primary issue tracking >>> interface, and mention debbugs in >>> case more advanced stuff is needed. No strong opinion here. I agree. Although an important missing piece in both debbugs and mumi is the ability to report a bug directly on the webpage. They are both essentially just listings of bugs. >> Already mentioned my idea about debbugs. Don't know what mumi is :/ >> >I don't know what's mumi either. But I think there's a (relatively new) >web frontend for debbugs: https://issues.guix.info/ Mumi is the debbugs frontend code serving that adress. It is written by Ricardo but very little advertised it seems. The code is linked in the bottom of the page. Ricardo maybe you could submit mumi to the list if guile programs on gnu.org to help people find it? And perhaps add the name mumi to issues.guix.info -- Sent from my k-9 mail for Android.
Re: It's time to build "guix deploy"
Hi :) ons 2019-02-13 klockan 20:04 +0100 skrev Giovanni Biscuolo : Ricardo Wurmus writes: Thompson, David writes: Other thoughts? Just for reference: to update Berlin build nodes I use this script: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/install-berlin.scm It’s not great, but it’s been helpful. thanks for sharing! (even if I can still barely understand what your script does) I understand most parts of it ;) It is a real beauty and a testiment to the power of Guix and Guile. actually mainenance.git is full of treasures :-) Berlin consists of a head node and many almost identical servers. AFAIU remote servers could be completely different each other for your script to do its job, or am I missing something? Besides the host-ips being hardcoded and the (berlin-build-machine-os) procedure from (sysadmin build-machines) and the keys from (sysadmin people) it seems pretty generic. Ricardo, is (define (reconfigure-remote id guix-directory) dead code that could be commented out/removed? To update one or more servers I run the script on the head node, which generates operating system configuration variants for each of the requested servers, builds the systems (offloading to all of the connected build nodes), copies the system closures to the target systems, and then runs “reconfigure” on the targets. explained this way seems easy :-O Since the operating system configuration record cannot be serialized, is there any plan or wip on this kind of serialization? the build nodes need to have a copy of the code that’s used to generate the operating system configuration. Not great. (They only need it to run “reconfigure”; they wouldn’t need that if “reconfigure” could operate remotely.) "just" having a "guix system reconfigure --host " would be a *huge* feature Agreed, but we would need to supply both keys and generic-config to this command as well. Anyway, I thought I’d share this with y’all. IMHO your remote host configuration technique deserves a dedicated blog article... but I've already asked too much :-) Good idea!
Re: Policy to remove obsolete packages
On 2019-02-06 23:32, Ricardo Wurmus wrote: This is a tangent. This thread is about removing obsolete packages. Let’s not discuss moving packages each to their own module here. This has been discussed elsewhere and it’s a can of worms (which is fine if you’re a bird, but not so good if you want to close the can again). If you’re interested in playing with this you can do this in a local branch and see how it behaves and what drawbacks it has. But I don’t think it’s a good use of our time discussing it (again). Thanks for the heads up. I missed the conversation. Its not really that important to me anyway. -- Cheers Swedebugia
Re: Policy to remove obsolete packages
n...@n0.is skrev: (5 februari 2019 22:31:53 CET) >Bjrn Hfling transcribed 846 bytes: >> On Mon, 04 Feb 2019 23:52:47 +0100 >> Ludovic Courtès wrote: >> >> >> > (Note that, IIUC, in openSuSE a package can be broken and yet >remain >> > installable by users, because the last binary that was produced is >> > still around.) >> >> We have guix pull --commit=..., inferiors, channels and time-travel, >so >> there are plenty opportunities to keep old states :-) > >There are many ways to keep it, but they are really sometimes just >jumping through too many hoops. >Or depending on what your idea of keeping old packages is. it should be >easy, but >it involves a good amount[1] of work to build a much older version >with the otherwise almost-only recent,updating,master. >To the point where you have to do the logical thing and look into >which versions upstream or guix build around that time as dependencies >and simply "freeze" all the dependencies in your package. > >1: amount depending on what you are building > >There are other ways to handle obsolete packages, but I think they >don't map to how guix works: > >a year or 2 back i experimented with a complete resructure of Guix, >and packages got split up differently (one module per package mostly) >leading to different kinds of problems and fixes. >a separate repository with the prefix -wip holds all the unstable, >obsolete, unfinished, etc packagesi (remotely comparable to how >ports trees are handled, but not quiet like it[1]). That's the gist >of it. just have a repository instead of dropping it from a tree. >Once it's fixed up in the "wip" repository, move it back into the >main repository. >I can elaborate more on this if you want me to once I'm no longer sick. > >> Björn >> Interesting! I like the idea of keeping it simple and now we tried the lumped modules approach. I don't like it so much to be honest. It comes with obvious drawbacks when the package per file grow and subcategorization have to be done. But is it efficient in guile to load hundreds of modules where all pull in more or less the same dependencies? If yes I think your idea is worthwhile Nils. We might have 3 repos: wip, core, extra But switching to one module per package might involve a lot of work. Can we automate it somehow? If yes we will probably end up with a couple thousand modules that import more modules than necessary. E.g. it would be no breakage if the split script simply includes all use-module-lines of the parent in the new child modules. Could we use an AI to help find unneded use-modules afterwards? Maybe just a half intelligent one that tries removing them one by one and sees if the derivation is computed correctly and report back a pairs of modules . use-modules-lines that are superfluous. -- Sent from my k-9 mail for Android.
Questions related to packaging go-bitmask-vpn
Hi Today I took a stab at packaging the new go-bitmask-vpn The go-files are not in the pkg-root and the go-build-system therefore fails with: "starting phase `build' can't load package: package 0xacab.org/leap/bitmask-vpn: no Go files in /tmp/guix-build-go-bitmask-vpn-0.19.1.drv-0/src/0xacab.org/leap/bitmask-vpn Building '0xacab.org/leap/bitmask-vpn' failed." The tree looks like this: . ├── cmd │ ├── bitmask-connect │ │ └── main.go │ ├── bitmask-helper │ │ └── main.go │ └── bitmask-vpn │ ├── catalog.go │ └── main.go ├── go.mod ├── go.sum ├── icon │ ├── blocked_darwin.go │ ├── blocked_unix.go │ ├── blocked_win.go │ ├── ico │ │ ├── black │ │ │ ├── vpn_blocked.ico │ │ │ ├── vpn_off.ico │ │ │ ├── vpn_on.ico │ │ │ ├── vpn_wait_0.ico │ │ │ ├── vpn_wait_1.ico │ │ │ ├── vpn_wait_2.ico │ │ │ └── vpn_wait_3.ico │ │ └── white │ │ ├── vpn_blocked.ico │ │ ├── vpn_off.ico │ │ ├── vpn_on.ico │ │ ├── vpn_wait_0.ico │ │ ├── vpn_wait_1.ico │ │ ├── vpn_wait_2.ico │ │ └── vpn_wait_3.ico │ ├── Makefile │ ├── make_icon.bat │ ├── off_darwin.go │ ├── off_unix.go │ ├── off_win.go │ ├── on_darwin.go │ ├── on_unix.go │ ├── on_win.go │ ├── png │ │ ├── black │ │ │ ├── vpn_blocked.png │ │ │ ├── vpn_off.png │ │ │ ├── vpn_on.png │ │ │ ├── vpn_wait_0.png │ │ │ ├── vpn_wait_1.png │ │ │ ├── vpn_wait_2.png │ │ │ └── vpn_wait_3.png │ │ └── white │ │ ├── vpn_blocked.png │ │ ├── vpn_off.png │ │ ├── vpn_on.png │ │ ├── vpn_wait_0.png │ │ ├── vpn_wait_1.png │ │ ├── vpn_wait_2.png │ │ └── vpn_wait_3.png │ ├── wait_0_darwin.go │ ├── wait_0_unix.go │ ├── wait_0_win.go │ ├── wait_1_darwin.go │ ├── wait_1_unix.go │ ├── wait_1_win.go │ ├── wait_2_darwin.go │ ├── wait_2_unix.go │ ├── wait_2_win.go │ ├── wait_3_darwin.go │ ├── wait_3_unix.go │ └── wait_3_win.go ├── LICENSE ├── locales │ ├── bn │ │ └── messages.gotext.json │ ├── en-GB │ │ └── messages.gotext.json │ ├── en-US │ │ └── messages.gotext.json │ ├── es │ │ └── messages.gotext.json │ ├── es-ES │ │ └── messages.gotext.json │ ├── fr │ │ └── messages.gotext.json │ ├── lt │ │ └── messages.gotext.json │ ├── nl │ │ └── messages.gotext.json │ ├── pt-BR │ │ └── messages.gotext.json │ └── ru │ └── messages.gotext.json ├── Makefile ├── pkg │ ├── bitmask │ │ ├── autostart.go │ │ ├── bitmaskd.go │ │ ├── bitmask.go │ │ └── standalone.go │ ├── bitmaskd │ │ ├── events.go │ │ ├── main.go │ │ └── vpn.go │ ├── config │ │ ├── config.go │ │ ├── darwin.go │ │ ├── logger.go │ │ ├── unix.go │ │ └── windows.go │ ├── helper │ │ ├── args.go │ │ ├── darwin.go │ │ ├── helper.go │ │ ├── linux.go │ │ └── windows.go │ ├── standalone │ │ ├── bonafide.go │ │ ├── bonafide_integration_test.go │ │ ├── bonafide_test.go │ │ ├── launcher.go │ │ ├── launcher_linux.go │ │ ├── main.go │ │ ├── status.go │ │ ├── testdata │ │ │ ├── cert │ │ │ └── eip-service.json │ │ └── vpn.go │ └── systray │ ├── config.go │ ├── notificator.go │ ├── pid.go │ ├── pid_test.go │ ├── run.go │ ├── signal_unix.go │ ├── signal_windows.go │ └── systray.go ├── README.md ├── riseupvpn.svg └── tools └── transifex ├── main.go ├── Makefile └── messages.json Is there an example of how to get it to find files in sub-directories? Or should I package it as 5 different packages in one? -- Cheers Swedebugia ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2016, 2017, 2018 Efraim Flashner ;;; Copyright © 2016 Matthew Jordan ;;; Copyright © 2016 Andy Wingo ;;; Copyright © 2016 Ludovic Courtès ;;; Copyright © 2016, 2017 Petter ;;; Copyright © 2016, 2017 Leo Famulari ;;; Copyright © 2017 Sergei Trofimovich ;;; Copyright © 2017 Alex Vong ;;; Copyright © 2018 Tobias Geerinckx-Rice ;;; Copyright © 2018 Christopher Baines ;;; Copyright © 2018 Tomáš Äech ;;; Copyright © 2018 Pierre-Antoine Rouby ;;; Copyright © 2018 Pierre Neidhardt ;;; Copyright @ 2018 Katherine Cox-Buday ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a
Re: [bug#28004] [PATCH] gnu: Add ungoogled-chromium.
Marius Bakke skrev: (2 februari 2019 20:20:23 CET)
>Thanks to Marks beautiful "computed-origin-method", Ungoogled-Chromium
>is finally ready for inclusion in Guix.
>
>Features:
>* Chromium 72.
>* No unsolicited network traffic.
>* Free software only.
>* No DRM.
>* Not an April Fools joke.
>
>It's currently using my trivial "fork" of Ungoogled-Chromium[0], which
>will be upstreamed once the upstream reorganization[1] is done.
>
>Comments appreciated!
>
>[0]:
>https://github.com/mbakke/ungoogled-chromium/commit/f9b9074c322a67b04baf0982797cd7b7e09614b5
>[1]: https://github.com/Eloston/ungoogled-chromium/issues/651
>
>* gnu/packages/aux-files/chromium/master-preferences.json,
>gnu/packages/chromium.scm: New files.
>* gnu/local.mk (GNU_SYSTEM_MODULES): Adjust accordingly.
>---
> gnu/local.mk | 1 +
> .../chromium/master-preferences.json | 26 +
> gnu/packages/chromium.scm | 741 ++
> 3 files changed, 768 insertions(+)
>create mode 100644
>gnu/packages/aux-files/chromium/master-preferences.json
> create mode 100644 gnu/packages/chromium.scm
>
>diff --git a/gnu/local.mk b/gnu/local.mk
>index 82db1488d6..b5e937cdd7 100644
>--- a/gnu/local.mk
>+++ b/gnu/local.mk
>@@ -100,6 +100,7 @@ GNU_SYSTEM_MODULES = \
> %D%/packages/check.scm \
> %D%/packages/chemistry.scm \
> %D%/packages/chez.scm \
>+ %D%/packages/chromium.scm \
> %D%/packages/ci.scm \
> %D%/packages/cinnamon.scm \
> %D%/packages/clojure.scm\
>diff --git a/gnu/packages/aux-files/chromium/master-preferences.json
>b/gnu/packages/aux-files/chromium/master-preferences.json
>new file mode 100644
>index 00..0caa7cc4cd
>--- /dev/null
>+++ b/gnu/packages/aux-files/chromium/master-preferences.json
>@@ -0,0 +1,26 @@
>+{
>+ "distribution": {
>+ "import_bookmarks": false,
>+ "make_chrome_default": false,
>+ "make_chrome_default_for_user": false,
>+ "verbose_logging": true,
>+ "skip_first_run_ui": true,
>+ "suppress_first_run_default_browser_prompt": true
>+ },
>+ "browser": {
>+ "has_seen_welcome_page" : true,
>+ "check_default_browser" : false
>+ },
>+ "dns_prefetching": {
>+"enabled": false
>+ },
>+ "alternate_error_pages": {
>+"enabled": false
>+ },
>+ "hardware": {
>+"audio_capture_enabled": false
>+ },
>+ "default_apps": "noinstall",
>+ "hide_web_store_icon": true,
>+ "homepage": "https://www.gnu.org/software/guix";
>+}
>diff --git a/gnu/packages/chromium.scm b/gnu/packages/chromium.scm
>new file mode 100644
>index 00..eb404246d3
>--- /dev/null
>+++ b/gnu/packages/chromium.scm
>@@ -0,0 +1,741 @@
>+;;; GNU Guix --- Functional package management for GNU
>+;;; Copyright © 2019 Marius Bakke
>+;;;
>+;;; GNU Guix is free software; you can redistribute it and/or modify
>it
>+;;; under the terms of the GNU General Public License as published by
>+;;; the Free Software Foundation; either version 3 of the License, or
>(at
>+;;; your option) any later version.
>+;;;
>+;;; GNU Guix is distributed in the hope that it will be useful, but
>+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
>+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>+;;; GNU General Public License for more details.
>+;;;
>+;;; You should have received a copy of the GNU General Public License
>+;;; along with GNU Guix. If not, see
Re: Proposal: hide unavoidable compilations by default
Ricardo Wurmus skrev: (1 februari 2019 00:21:00 CET) > >swedebugia writes: > >> I tested installing extremetuxracer today. >> >> I got this: >> >> substitute: updating substitutes from 'https://ci.guix.info'... >100.0% >> The following derivations would be built: >>/gnu/store/jyg5na6m93s2m40ma96l4809f5cnbd2a-profile.drv >>/gnu/store/zcyshai941cb88326rggrcv2sqxbl5dl-gtk-im-modules.drv >> >/gnu/store/z2lay5k0hm9xsr0ds34iyicw9r12cpvi-ca-certificate-bundle.drv >>/gnu/store/n4dff9vfgzrmkcvyh3nhypd64p0bbvw1-xdg-mime-database.drv >> >/gnu/store/j5pbmdjqsb9dv3chjfkk0b8i0h7kr4sw-xdg-desktop-database.drv >>/gnu/store/hs46q0lhmm7xhjgygdg175v4c6jmvjvc-fonts-dir.drv >>/gnu/store/hdifcszmlf1gwd2q0zg4n7zkabzm1bx0-glib-schemas.drv >>/gnu/store/4idc38h10bcz1ln97pakaxkr3gdn9j2p-gtk-icon-themes.drv >>/gnu/store/0fs4jqxrnwlgwq3dnyzpd00ww68l2k0c-info-dir.drv >> >/gnu/store/9xydhzf9810vljhyzcackgg34hvqmj7v-extremetuxracer-0.7.5.drv >>/gnu/store/apsn4m9fnv7927dnlj9wya39035l4i69-manual-database.drv >> 44.7 MB would be downloaded: >>/gnu/store/ia3zw1nb1vppscl9lpj3v5d8r3p4zv9q-etr-0.7.5.tar.xz >>/gnu/store/yyn8g8am7y9xl4dhrzb6klrmaqwjl2mk-sfml-2.5.1 > >I thought it would say “The following profile hooks would be built” for >all of the profile hooks that are to be built, i.e. most of the listed >derivations except for extremetuxracer. > >-- >Ricardo Correct. This was a slightly old guix. I still think we should hide them. -- Sent from my k-9 mail for Android.
Re: Guix Days starting in two days!
On 2019-01-31 15:45, Thompson, David wrote: On Tue, Jan 29, 2019 at 4:58 AM Ludovic Courtès wrote: snip Since I'll be on another continent, I'm looking forward to seeing the talks/blog posts that come out of FOSDEM. +1 I wish I could join you all! Since I'm busy with personal stuff in Sweden, I wish you all a wonderful time hacking and talking and perhaps bring back a new idea or two. -- Cheers Swedebugia
Proposal: hide unavoidable compilations by default
Hi I tested installing extremetuxracer today. I got this: substitute: updating substitutes from 'https://ci.guix.info'... 100.0% The following derivations would be built: /gnu/store/jyg5na6m93s2m40ma96l4809f5cnbd2a-profile.drv /gnu/store/zcyshai941cb88326rggrcv2sqxbl5dl-gtk-im-modules.drv /gnu/store/z2lay5k0hm9xsr0ds34iyicw9r12cpvi-ca-certificate-bundle.drv /gnu/store/n4dff9vfgzrmkcvyh3nhypd64p0bbvw1-xdg-mime-database.drv /gnu/store/j5pbmdjqsb9dv3chjfkk0b8i0h7kr4sw-xdg-desktop-database.drv /gnu/store/hs46q0lhmm7xhjgygdg175v4c6jmvjvc-fonts-dir.drv /gnu/store/hdifcszmlf1gwd2q0zg4n7zkabzm1bx0-glib-schemas.drv /gnu/store/4idc38h10bcz1ln97pakaxkr3gdn9j2p-gtk-icon-themes.drv /gnu/store/0fs4jqxrnwlgwq3dnyzpd00ww68l2k0c-info-dir.drv /gnu/store/9xydhzf9810vljhyzcackgg34hvqmj7v-extremetuxracer-0.7.5.drv /gnu/store/apsn4m9fnv7927dnlj9wya39035l4i69-manual-database.drv 44.7 MB would be downloaded: /gnu/store/ia3zw1nb1vppscl9lpj3v5d8r3p4zv9q-etr-0.7.5.tar.xz /gnu/store/yyn8g8am7y9xl4dhrzb6klrmaqwjl2mk-sfml-2.5.1 Many of the things to be built are unavoidable internals of guix that are not relevant to the user. I suggest we hide them unless given a flag like --show-all-drv This is after hiding them: substitute: updating substitutes from 'https://ci.guix.info'... 100.0% The following derivations would be built: /gnu/store/9xydhzf9810vljhyzcackgg34hvqmj7v-extremetuxracer-0.7.5.drv 44.7 MB would be downloaded: /gnu/store/ia3zw1nb1vppscl9lpj3v5d8r3p4zv9q-etr-0.7.5.tar.xz /gnu/store/yyn8g8am7y9xl4dhrzb6klrmaqwjl2mk-sfml-2.5.1 -- Cheers Swedebugia
Re: GuixDays: Perfect Setup: Speaker wanted
On 2019-01-27 12:50, Ricardo Wurmus wrote: swedebugia writes: Also we should mention that the error which appears after applying patches from emails can be ignored - the patches apply succesfully anyways. What error are you referring to? "cd: No such directory found via CDPATH environment variable" My env looks like this: LANG=sv_SE.utf8 GDM_LANG=sv_SE.utf8 HISTIGNORE=&:ls:l:ll:[bf]g:exit:..:history:dirs:cd:vlc HISTCONTROL=eraseups:ignoreups DISPLAY=:0 OLDPWD=/home/sdb/src EDITOR=emacs -nw GTK_OVERLAY_SCROLLING=0 COLORTERM=truecolor GIT_SSL_CAINFO=/home/sdb/.guix-profile/etc/ssl/certs/ca-certificates.crt DESKTOP_AUTOSTART_ID=10b9a9895f1abe6b415487106236179350005930007 MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins XDG_VTNR=7 SSH_AUTH_SOCK=/run/user/1000/keyring/ssh GUILE_LOAD_COMPILED_PATH=/home/sdb/src/guix:/home/sdb/.guix-profile/lib/guile/2.2/site-ccache XDG_SESSION_ID=c2 XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/sdb USER=sdb DESKTOP_SESSION=mate MV=-v GUIX_LOCPATH=/home/sdb/.guix-profile/lib/locale PWD=/home/sdb/src/guix HOME=/home/sdb XDG_SESSION_TYPE=x11 MATE_DESKTOP_SESSION_ID=this-is-deprecated XDG_SESSION_DESKTOP=mate QT_SCALE_FACTOR=1 GTK_MODULES=canberra-gtk-module MAIL=/var/spool/mail/sdb GIT_EXEC_PATH=/home/sdb/.guix-profile/libexec/git-core TERM=xterm-256color SHELL=/bin/bash VTE_VERSION=5403 XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0 XDG_CURRENT_DESKTOP=MATE XDG_SEAT=seat0 SHLVL=1 GDMSESSION=mate SSL_CERT_DIR=/home/sdb/.guix-profile/etc/ssl/certs LOGNAME=sdb DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus XDG_RUNTIME_DIR=/run/user/1000 XAUTHORITY=/home/sdb/.Xauthority GUILE_LOAD_PATH=/home/sdb/src/guix:/home/sdb/.guix-profile/share/guile/site/2.2 XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0 QT_AUTO_SCREEN_SCALE_FACTOR=0 PATH=/home/sdb/.guix-profile/bin:/home/sdb/scripts:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl INFOPATH=/home/sdb/.guix-profile/share/info:/usr/local/share/info SESSION_MANAGER=local/parabola:@/tmp/.ICE-unix/593,unix/parabola:/tmp/.ICE-unix/593 _=/usr/bin/env -- Cheers Swedebugia
Re: GuixDays: Perfect Setup: Speaker wanted
Ricardo Wurmus skrev: (28 januari 2019 13:03:42 CET) > >swedebugia writes: > >> Actually what is even nicer is emacs-debbugs and its ability to apply >> patches from emails. The UI is somewhat lacking and I think we should >> fork it so that it defaults to guix bugs and packages. > >FWIW you don’t need emacs-debbugs to apply patches from emails, nor do >you need emacs-debbugs at all if you don’t want to use it. > >At https://issues.guix.info you can download any message by clicking on >the “Download” link in the upper right corner. You can download >individual parts of multipart messages. You can then apply any >downloaded patches with “git am”. > >-- >Ricardo I will return with the error message. I liked that it makes it easier to apply and review patches. I know that it can be done manually but that's cumbersome in my view. -- Sent from my k-9 mail for Android.
Re: Changes in the spending committee for the FSF Fund
Andreas Enge skrev: (27 januari 2019 16:43:34 CET) >Hello, > >On Fri, Jan 25, 2019 at 11:57:21PM +0100, Ludovic Courtès wrote: >> There’s a ledger for the Guix Europe non-profit¹, which is a separate >> entity, but most of the transactions on the funds held at the FSF >have >> been made via Guix Europe. > >And the decisions of the Solidary Administrative Council are also made >public: >https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/minutes > >From the beginning, it has been our aim to be as open as possible about >our activities. > >Andreas Thanks. This looks very good. 😃 -- Sent from my k-9 mail for Android.
Re: GuixDays: Perfect Setup: Speaker wanted
On 2019-01-26 21:13, Maxim Cournoyer wrote:
swedebugia writes:
[...]
Actually what is even nicer is emacs-debbugs and its ability to apply
patches from emails. The UI is somewhat lacking and I think we should
fork it so that it defaults to guix bugs and packages.
There's no need to fork emacs-debbugs for that; it's already
configurable:
(setq debbugs-gnu-default-packages '("guix"))
Thanks for sharing that! I did not look into it deeply and had not
realized this was possible.
I think this should be included in HACKING where emacs-debbugs is mentioned:
"* Using emacs-debbugs
Bug reports and patches are tracked using debbugs. If you are on emacs, you
can use emacs-debbugs.
List all open bug reports on guix-patches with
C-u M-x debbugs-gnu guix-patches n y"
Also we should mention that the error which appears after applying
patches from emails can be ignored - the patches apply succesfully anyways.
If you want to apply only one of several patches from a single email you
have to select manually and run M-x magit-apply (if I remember correctly)
--
Cheers
Swedebugia
Re: GuixDays: Perfect Setup: Speaker wanted
Pierre Neidhardt skrev: (25 januari 2019 23:22:47 CET) >"The Perfect Setup" sounds a bit exclusive in my opinion, there is a >whole world of >possibilities out there... :) Agreed. A recommended setup sounds better. > >That said, if it's only about Emacs+Geiser+Magit, I'd be happy to make >a demo >and share my config :) Nice 😃 I also tried this setup but found that magit does unexpected things to the repo sometimes. Maybe it is just my git skills that are lacking. Actually what is even nicer is emacs-debbugs and its ability to apply patches from emails. The UI is somewhat lacking and I think we should fork it so that it defaults to guix bugs and packages. Hi -- Sent from my p≡p for Android.
Re: Listing all packages with --search now impossible
Ricardo Wurmus skrev: (25 januari 2019 23:05:51 CET) > >Hi swedebugia, > > writes: > >> Yesterday when I played around with guix I noticed that the default >> behavior of >> $ guix package --search >> guix package: error: invalid argument: Missing required argument >after >> `--search' >> >> has changed recently from showing all packages to now showing none. >> >> also: >> >> $ guix package --search * >> guix package: error: invalid argument: Missing required argument >after >> `--search' >> >> This is a bug. "*" should match everything. > >This is not a bug. > >The argument must be separated from the option with an “=”. The second >problem is that “*” is not a regular expression but a shell glob >pattern. You need to provide a regular expression. This works: > >guix package --search=.* > >-- >Ricardo Thanks! We should document the regex syntax and an example I think. -- Sent from my p≡p for Android.
Re: Changes in the spending committee for the FSF Fund
"Ludovic Courtès" skrev: (25 januari 2019 23:57:21 CET) >Hi, > >Gábor Boskovits skribis: > >> swedebugia ezt írta (időpont: 2019. jan. 24., >> Cs, 23:04): >>> >>> On 2018-09-08 17:11, Christopher Lemmer Webber wrote: >>> > Ludovic Courtès writes: >>> > >>> >> Thanks Mark for your time on the spending committee, and welcome >Tobias! >>> > >>> > Yes, thank you both! >>> >>> Thanks to you all for doing this work. >>> >>> It would be nice I think to have transparency towards the community. >>> Given the very large donations I think this is important. >>> >>> Are the decisions of the committee public and published somewhere? >>> >>> Is there a public account balance also somewhere and a list of prior >>> spendings so we can get an overview? >>> >> >> I believe this information is available in the maintenance >repository. > >There’s a ledger for the Guix Europe non-profit¹, which is a separate >entity, but most of the transactions on the funds held at the FSF have >been made via Guix Europe. Another use of the FSF fund has been the >Outreachy internship (that predates the recent donation by Handshake >and >the change on the spending committee.) I think it’s now time to add a >new ledger to write this down. Tobias, Ricardo? > >Thanks, >Ludo’. > >PS: guix-fina...@gnu.org is an alias for the spending committee >members. > >¹ >https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/guix-europe/accounting/accounting.ledger OK. Thanks. -- Sent from my p≡p for Android.
Listing all packages with --search now impossible
Hi Yesterday when I played around with guix I noticed that the default behavior of $ guix package --search guix package: error: invalid argument: Missing required argument after `--search' has changed recently from showing all packages to now showing none. also: $ guix package --search * guix package: error: invalid argument: Missing required argument after `--search' This is a bug. "*" should match everything. Is this intentional? This means that now users have to know guile to list all packages with all the fields. :/ -- Cheers Swedebugia
Re: Removing greenisland?
Ricardo Wurmus skrev: (25 januari 2019 14:24:11 CET) >Hi Guix, > >the greenisland package cannot be built. The upstream repository has >been archived and its replacement has also been archived. The work is >supposedly merged back into QtWayland. > >Since no package depends on greenisland I suggest removing it. > >-- >Ricardo Sounds resonable to me. -- Sent from my p≡p for Android.
Re: Changes in the spending committee for the FSF Fund
On 2018-09-08 17:11, Christopher Lemmer Webber wrote: Ludovic Courtès writes: Thanks Mark for your time on the spending committee, and welcome Tobias! Yes, thank you both! Thanks to you all for doing this work. It would be nice I think to have transparency towards the community. Given the very large donations I think this is important. Are the decisions of the committee public and published somewhere? Is there a public account balance also somewhere and a list of prior spendings so we can get an overview? -- Cheers Swedebugia
Overview of build machines
Hi I just found a thread from september about adding more arm build machines. How did it go? Is there a list of all our build machines and locations somewhere? -- Cheers Swedebugia
Re: Closing issues from commits
On 2018-08-20 11:52, Ludovic Courtès wrote: Hello Marius, Marius Bakke skribis: Marius Bakke writes: Hello, It would be convenient (for me, at least) to have a server-side git hook that can close debbugs issues. It would grep the commit message for '^Fixes: <https://bugs\\.gnu\\.org/(\d+)>' and automatically send an email to cont...@debbugs.gnu.org with the message 'close $1 $commit_id'. Is this something that we want and can deploy? Derp. I realized I can do this with a post-push hook. I'll make it next time I need it and submit it here :-) Would be nice! A server-side hook would also be welcome in any case. It turns out that Mailutils in Git has bindings for Guile 2.2, which we can use to send email, so writing such a hook wouldn’t be too hard. :-) We could have a tiny program that regularly pulls from Git, browses the latest commits, and sends email as appropriate. Would be a fun hack. (A script like this would be easier than having a server-side hook on Savannah, especially if we need to store credentials for the SMTP server.) Did anyone take a stab at this yet? -- Cheers Swedebugia
Re: Matrix & Nheko Packaging
On 2018-10-09 09:18, Pierre Neidhardt wrote: I found out that there is an Emacs package for Matrix: https://github.com/jgkamat/matrix-client-el/ The authors claim it's not mature enough. I'll try it out and if it's usable I'll package it for Guix :) How did it go? -- Cheers Swedebugia
Re: Help with sxml simple parser for the quicklisp importer
On 2019-01-23 19:58, Pierre Neidhardt wrote: I'm not sure you need to extract Quickdocs data at all. What Quickdocs does is all automated I believe, so you could probably do the same it's already doing: extract the metadata from the project themselves. Most of the data is contained in the .asd files. I think looking at Quickdocs code could be most informative, especially considering it's written in Common Lisp ;) You are right. And Ricardo. Quickdocs seems like a dirty hack. The information we want is in the tgz that we download so I just found out that we can do the same as with the pypi importer and extract it from there :) The .asd files seem uniformly formatted. -- Cheers Swedebugia
Re: Help with sxml simple parser for the quicklisp importer
On 2019-01-23 16:58, Ricardo Wurmus wrote: swedebugia writes: The second “link” tag opens but is never closed. This may be valid HTML, but it is not valid XML, which is what xml->sxml expects. Thanks for the quick answer! I will try to remove this line before handling over to the parser. I would recommend looking for a better source of package information. Parsing HTML is not fun and is often brittle. I understand. Hm. Will try asking the author. Got a little further. Added this: (define (sanitize-html html) "Correct an offending invalid line from the html source" (let* ((html1 (regexp-substitute #f (string-match "main.css\">" html) 'pre "main.css\" />" 'post)) (result (regexp-substitute #f (string-match "utf-8\">" html1) 'pre "utf-8\" />" 'post))) result)) Which results in a new error: Starting download of /tmp/guix-file.uAoKMD From http://quickdocs.org/1am/... 1am/ 7KiB 2.0MiB/s 00:00 [##] 100.0% Backtrace: 13 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 12 (call-with-prompt _ _ #(k proc)>) In ice-9/eval.scm: 619:8 11 (_ #(#(#))) In ice-9/boot-9.scm: 2312:4 10 (save-module-excursion _) 3831:12 9 (_) In guix/import/quicklisp.scm: 239:9 8 (_) In guix/utils.scm: 618:8 7 (call-with-temporary-output-file #guix/import/quicklisp.scm:236:3 (temp port)>) In sxml/simple.scm: 143:4 6 (xml->sxml _ #:namespaces _ #:declare-namespaces? _ #:trim-whitespace? _ #:entities _ #:default-entity-handler _ # _) 143:4 5 (loop # () #f _) 143:4 4 (loop # () #f _) 143:4 3 (loop # () #f _) 143:4 2 (loop # () #f _) 143:4 1 (loop # () #f _) 143:4 0 (loop # () #f _) sxml/simple.scm:143:4: In procedure loop: Throw to key `parser-error' with args `(# "[wf-entdeclared] broken for " copy)'. Any ideas? -- Cheers Swedebugia ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2018 Julien Lepiller ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. (define-module (guix import quicklisp) ; #:use-module (ice-9 ftw) #:use-module (ice-9 match) #:use-module (ice-9 peg) #:use-module (ice-9 regex) #:use-module ((ice-9 rdelim) #:select (read-line)) #:use-module (ice-9 textual-ports) #:use-module (sxml simple) #:use-module (sxml xpath) #:use-module (srfi srfi-1) #:use-module (srfi srfi-2) #:use-module (web uri) ; #:use-module (guix http-client) #:use-module ((guix build download) #:prefix build:) #:use-module (guix base32) ; #:use-module (guix ui) #:use-module ((guix utils) #:select (call-with-temporary-output-file)) ; #:use-module (guix import utils) ; #:use-module ((guix licenses) #:prefix license:) #:export (test)) ;; Define a PEG parser for the quicklisp format (define-peg-pattern SP none (or " " "\n")) (define-peg-pattern NL none "\n") (define-peg-pattern COLON none ":") (define-peg-pattern RELEASE none "release/") (define-peg-pattern HASH none "#") (define-peg-pattern IGNORE none (peg "(! SP .)*")) (define-peg-pattern IGNORE-UNTIL-NL none (peg "(! NL .)*")) (define-peg-pattern text all (+ (or (range #\a #\z) "-"))) (define-peg-pattern text-until-sp all (peg "(! SP .)*")) (define-peg-pattern text-until-colon all (peg "(! COLON .)*")) (define-peg-pattern text-until-nl all (peg "(! NL .)*")) ;; Meta and distinfo files use COLON as separator: (define-peg-pattern test all text-until-colon) (define-peg-pattern record all (and text COLON (* SP) text-until-nl)) (define-peg-pattern records body (* (and record (* SP ;; Release index has no colons between the values: (define-peg-pattern record-index all (and text-until-sp (* SP) text-until-nl)) ;; Field no. 2 is tarball url (define-peg-pattern field-2 all (and text-until-sp SP text-until-sp IGNORE-UNTIL-NL)) (define-peg-pattern 2s body (* (and (or header-hash field-2) (* SP ;; Field no. 6 is version (define-peg-pattern version all (and text-until-sp SP IGNORE SP IGNORE SP IGNORE SP IGNORE SP text-until-sp IGNORE-UNTIL-
Re: Help with sxml simple parser for the quicklisp importer
On 2019-01-23 15:22, Ricardo Wurmus wrote: Hi, (define (get-homepage name) "Get the latest meta release file. From the links in this we extract all other information we need." (call-with-temporary-output-file (lambda (temp port) (and (url-fetch (homepage name) temp) (xml->sxml (get-string-all port)) Aside: you don’t need to use “get-string-all”; “xml->sxml” can read directly from a port. But it errors out with: sxml/simple.scm:143:4: In procedure loop: Throw to key `parser-error' with args `(# "[GIMatch] broken for " (END . head) " while expecting " END link)'. I fetched the document. Here’s the part that it barfs on: --8<---cut here---start->8--- 1am | Quickdocs … --8<---cut here---end--->8--- The second “link” tag opens but is never closed. This may be valid HTML, but it is not valid XML, which is what xml->sxml expects. Thanks for the quick answer! I will try to remove this line before handling over to the parser. -- Cheers Swedebugia
Re: ‘nss-certs’ missing in the installation image
Hi On 2019-01-23 12:22, Pierre Neidhardt wrote: I’m not sure it belongs in “System Installation”. After all, it’s already under “System Configuration” and in several OS config examples. Here the issue is not with system configuration, but with the live install image. In this sense, I'd say it belongs next to the network setup instructions. Leaving it to System Configuration is too late. Conversely, the OS config examples don't address the same issue. I agree we should at least note this in the installer. I stumbled on this the last time I installed from USB. I could not get my config.scm because it was on a https-only server: $ wget http://gitlab.com/swedebugia/guix-config/raw/master/config.scm URL transformed to HTTPS due to an HSTS policy --2019-01-23 14:58:06-- https://gitlab.com/swedebugia/guix-config/raw/master/config.scm Läste in CA-certifikatet ”/etc/ssl/certs/ca-certificates.crt” Slår upp gitlab.com (gitlab.com)... 35.231.145.151 Ansluter till gitlab.com (gitlab.com)|35.231.145.151|:443... ansluten. HTTP-begäran skickad, väntar på svar... 200 OK Längd: 4569 (4,5K) [text/plain] Sparar till: "config.scm" config.scm 100%[>] 4,46K --.-KB/som 0s 2019-01-23 14:58:07 (28,9 MB/s) - "config.scm" sparades [4569/4569] -- Cheers Swedebugia
Help with sxml simple parser for the quicklisp importer
Hi I am trying to extract information from the quickdocs website to fill into the description. I got this code: ;; Guess the homepage of the package (define (homepage name) (string-append "http://quickdocs.org/"; name "/")) (define (get-homepage name) "Get the latest meta release file. From the links in this we extract all other information we need." (call-with-temporary-output-file (lambda (temp port) (and (url-fetch (homepage name) temp) (xml->sxml (get-string-all port)) (display (get-homepage "1am")) But it errors out with: sxml/simple.scm:143:4: In procedure loop: Throw to key `parser-error' with args `(# "[GIMatch] broken for " (END . head) " while expecting " END link)'. The document has no link problems in the html according to https://validator.w3.org/nu/?doc=http%3A%2F%2Fquickdocs.org%2F1am%2F Any ideas how to make it parse? -- Cheers Swedebugia ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2018 Julien Lepiller ;;; ;;; This file is part of GNU Guix. ;;; ;;; GNU Guix is free software; you can redistribute it and/or modify it ;;; under the terms of the GNU General Public License as published by ;;; the Free Software Foundation; either version 3 of the License, or (at ;;; your option) any later version. ;;; ;;; GNU Guix is distributed in the hope that it will be useful, but ;;; WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with GNU Guix. If not, see <http://www.gnu.org/licenses/>. (define-module (guix import quicklisp) ; #:use-module (ice-9 ftw) #:use-module (ice-9 match) #:use-module (ice-9 peg) ; #:use-module (ice-9 receive) #:use-module ((ice-9 rdelim) #:select (read-line)) #:use-module (ice-9 textual-ports) #:use-module (sxml simple) #:use-module (sxml xpath) #:use-module (srfi srfi-1) #:use-module (srfi srfi-2) #:use-module (web uri) ; #:use-module (guix http-client) #:use-module ((guix build download) #:prefix build:) ; #:use-module (guix git) ; #:use-module (guix ui) #:use-module ((guix utils) #:select (call-with-temporary-output-file)) ; #:use-module (guix import utils) ; #:use-module ((guix licenses) #:prefix license:) #:export (test)) ;; Define a PEG parser for the quicklisp format (define-peg-pattern SP none (or " " "\n")) (define-peg-pattern NL none "\n") (define-peg-pattern COLON none ":") (define-peg-pattern RELEASE none "release/") (define-peg-pattern HASH none "#") (define-peg-pattern IGNORE none (peg "(! SP .)*")) (define-peg-pattern IGNORE-UNTIL-NL none (peg "(! NL .)*")) (define-peg-pattern text all (+ (or (range #\a #\z) "-"))) (define-peg-pattern text-until-sp all (peg "(! SP .)*")) (define-peg-pattern text-until-colon all (peg "(! COLON .)*")) (define-peg-pattern text-until-nl all (peg "(! NL .)*")) ;; Meta and distinfo files use COLON as separator: (define-peg-pattern test all text-until-colon) (define-peg-pattern record all (and text COLON (* SP) text-until-nl)) (define-peg-pattern records body (* (and record (* SP ;; Release index has no colons between the values: (define-peg-pattern record-index all (and text-until-sp (* SP) text-until-nl)) ;; Field no. 2 is tarball url (define-peg-pattern field-2 all (and text-until-sp SP text-until-sp IGNORE-UNTIL-NL)) (define-peg-pattern 2s body (* (and (or header-hash field-2) (* SP ;; Field no. 6 is version (define-peg-pattern version all (and text-until-sp SP IGNORE SP IGNORE SP IGNORE SP IGNORE SP text-until-sp IGNORE-UNTIL-NL)) (define-peg-pattern versions body (* (and (or header-hash version) (* SP ;; Field no. 7-N is system files which we need. (define-peg-pattern system-files all (and text-until-sp SP IGNORE SP IGNORE SP IGNORE SP IGNORE SP IGNORE SP text-until-nl)) (define-peg-pattern system-files-list body (* (and (or header-hash system-files) (* SP ;; Release hashfile has no colons between the values: ;; Names contain numbers, get everything exept space. (define-peg-pattern record-hash all (and ;; This matches the prefix "release/" RELEASE text-until-sp (* SP) text-until-nl)) (define-peg-pattern header-hash all (and (and HASH (* SP)) text-until-sp (* SP) text-until-nl)) (define-peg-pattern records-hash body (* (and (or header-hash record-hash) (* SP ;; Systems.txt with dependencies ;; This parsing results in a lot of duplicates, but we ignore that because our ;; match just picks the first and returns happy and the overhead is neglible. ;; Field no. 3 is system-name (define-peg-pattern field-3 all (and text-until-sp SP IGNORE SP text-un
Re: ‘sudo’ leaves PATH unchanged… so what?
Danny Milosavljevic skrev: (18 januari 2019 21:29:28 CET) >On Fri, 18 Jan 2019 19:03:18 + >Caleb Ristvedt wrote: > >> To be clear, it's not so much a real problem as an eyesore. 'sudo >guix >> package ...' and 'sudo guix pull' will operate on root's profile(s) >as >> expected, but that also means 'sudo guix system reconfigure' will >look at >> root's profile when deciding whether to say that it's out of date, >even >> though the guix actually used for reconfiguring may not be out of >date. It >> pretty much only ever comes up when reconfiguring, but for those like >> myself who are worried by messages like that it can be confusing to >try to >> resolve. > >There's an environment variable "SUDO_USER" which still contains the >name >of the original user. > >We could check SUDO_USER instead of USER if USER=root, otherwise check >USER. +1 great idea. Maybe we could have an explicit --root switch too? Then we could state in the manual that guix always runs with your user profile guix unless you give it --root. We could the clearly state why you might not want it to use a root profile of guix on a typical single user system. -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
Re: Shell installer script (feedback)
On 2019-01-17 18:10, zimoun wrote:
Dear,
The script is nice because it just works! :-)
As a newcomer, I find it lacks an optional installation of default
packages in the default profiles.
I have in mind: nss-certs, recutils, emacs (or info), glibc-locales.
Then, "Run 'info guix' to read the manual." does not work.
Because the command info is not installed by default on all the distributions.
And the Guix manual does not seem installed by default. Am I doing wrong?
I used the installer here on parabola and I found this (with 'locate'):
the manual was found both in the store in a profile (not my current) and
in /usr/local/share/info/
After adjusting my infopath to this it worked like a charm:
export
INFOPATH="/home/sdb/.guix-profile/share/info:/usr/local/share/info${INFOPATH:+:}$INFOPATH"
--
Cheers Swedebugia
Re: Communication and Design at Guix
On 2019-01-17 12:10, Ricardo Wurmus wrote: L p R n d n writes: Guix is ... ... a package and system manager. (A seen previously, system manager is too wide) ... a package manager and machine administrator. ... a package and machine administrator. ... a package and environment manager. WDYT? If anyone has an idea, don't be shy :) “administrator” is generally understood to be a person (as in “system administrator”). “environment manager” is just as vague as “system manager”, in my opinion — “everything is the environment!”. It only makes sense to people who are already familiar with the term “environment” in a computing context. That’s the advantage the word “package manager” has — it’s already a well-established term, for better or worse. I'd like to keep the "package manager" part as it'll probably ring a bell to any linux user and helps understand the not so familiar part (system/environment dealing). Right, that’s what I meant. We are underselling Guix, though, if we keep referring to it as a “package manager”, because people’s familiarity with other package managers may make them think in smaller terms. FWIW, I’m with Ludo here with regards to “Guix” as the “single brand”. I disagree with this part that George wrote: "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's first expectation is for "Guix system" to refer to the whole of Guix, which we want to call "Guix" (referred to as "Guix Brand" below). In my experience “… system” is not generally used to describe a tool’s full set of features. I think “Guix System” is just the right term for everything that Guix generates or operates on with the “guix system” set of commands. “GuixOS” is, in my opinion, a pretty terrible name (I’m also not a fan of all the other “…OS” names out there) and it needlessly keeps the confusion between “Guix, the tool” and “Guix, the system” alive. Interesting. So if we go with "Guix System" would the following sentences be meaningful? "Is your operating system running Guix?" (ambiguous) "Which operating system do you use? Guix System." "Are you on Guix System?" "Which version of Guix System are you using?" (we should really have something like lsb_release -a output this term) "How did you install your Guix System?" "Can I dual-boot Guix System and Parabola GNU/Linux?" "A: My Guix System runs Linux. B: Oh, I use the Hurd on mine!" "I love the R.M. Stallman picture that is on my Guix System during boot!" :D (https://wallup.net/wallpapers/richard-stallman/) "My Guix System performs really well" "Since I switched my operating system to Guix System I have not looked back" "I love my Guix System!" "Guix helps me get things done instead of losing myself in the details of dependencies and stuff when coding" "Guix makes it easy for me to sandbox my browser so I can surf without worrying too much" "Guix System boots a little slower than XX but it is worth the wait!" "I really like the roll-back provided by Guix System when I end up in a broken state" (geek version) "I really like the roll-back provided by Guix System when my pc won't boot and just goes black so I can't use the mouse or log in." (non-geek version) "I recommend Guix System because it makes it easy to copy your friends OS setup so that you can get to all the fun parts quickly without worrying about installing this or that - everything is there out-of-the-box!". If not please comment. -- Cheers Swedebugia
Re: Idea: guix printer configuration generation
On 2019-01-17 13:08, Gábor Boskovits wrote: Hello, swedebugia ezt írta (időpont: 2019. jan. 17., Cs, 8:22): "Gábor Boskovits" skrev: (16 januari 2019 16:00:30 CET) Hello, ezt írta (időpont: 2019. jan. 16., Sze, 15:35): Hi I would rather not have to learn the CUPS web interface just to configure my printer. Do we have a way to do this yet from config.scm? I think we should abstract away everything CUPS. Maybe we could make a guix printer importer? The idea is to extract information about the printer via Guile and print what the user need to add to the config.scm. Something like this: $ guix printer "Found 1 USB printer: HP DeskJet 4330 (cups-configuration (printer (name "HP DeskJet 4330" (connection "usb://34234556" (settings (paper "a4" (source "default" ..." When the user adds this to their config.scm and reconfigures the printer JUST WORKS. Thoughts? -- Cheers Swedebugia I've found the CUPS config stuff somewhat problematic. The config file is generated from another config file, and some other things, that trigger regenerating the config. Sometimes even the printer ink level is regenerating cups configs, which is really annoying. Modifying files in /etc is not a very nice way to handle that indeed. The problem is known upstream, and seems to be won't fix. If we could get around that in any sane way, I would be very happy. Thanks for the link. This morning I read parts of the source code for the filters. I was not impressed. As this program is essentially the work of one person and not a well oiled community that can be reasoned with it really begs to be forked/replaced. In my view it should be split into a few well working interacting programs instead of this one big C program that tries to do everything from backend to converting to-from postscript, (rasterization), filtering, web admin system & printer sharing over the web. I would be very happy with a tool set like this: * frontend gui program to orchestrate the whole thing and help the user understand what is going on (display progress, errors, cancel job). * guile-wrapper for ghostscript that helps converting pdf documents (if any program wants to print output pdf or ps please) + guile-wrapper to apply filters for a given printer configuration. * backend to communicate with the printer (exposes API) (this could be a patched cups-minimal package). Configuration is done in 1 file that is written by the user or guix when reconfiguring. So to print I could either use the wrapper directly from the command line or use the frontend gui. A cli frontend could easily be created that informs the user about the current state of the printer, the queue and maybe history of printed jobs. If anybody wants to share the printer then this will be another server-frontend component developed apart from but interacting via APIs with the other parts. -- Cheers Swedebugia
Re: Idea: guix printer configuration generation
"Gábor Boskovits" skrev: (16 januari 2019 16:00:30 CET) >Hello, > > ezt írta (időpont: 2019. jan. 16., Sze, 15:35): >> >> Hi >> >> I would rather not have to learn the CUPS web interface just to >> configure my printer. Do we have a way to do this yet from >config.scm? I >> think we should abstract away everything CUPS. >> >> Maybe we could make a guix printer importer? >> >> The idea is to extract information about the printer via Guile and >print >> what the user need to add to the config.scm. >> >> Something like this: >> $ guix printer >> >> "Found 1 USB printer: HP DeskJet 4330 >> (cups-configuration >> (printer >>(name "HP DeskJet 4330" >>(connection "usb://34234556" >>(settings >> (paper "a4" >> (source "default" >> ..." >> >> When the user adds this to their config.scm and reconfigures the >printer >> JUST WORKS. >> >> Thoughts? >> >> -- >> Cheers >> Swedebugia >> > >I've found the CUPS config stuff somewhat problematic. >The config file is generated from another config file, and some other >things, that trigger >regenerating the config. Sometimes even the printer ink level is >regenerating cups configs, >which is really annoying. Modifying files in /etc is not a very nice >way to handle that indeed. >The problem is known upstream, and seems to be won't fix. If we could >get around that in any sane way, >I would be very happy. > >Best regards, >g_bor I did not understand what you meant. Does the cups server regenerate you printer config automatically? I'm surprised nobody forked the CUPS project long ago. Maybe this should be a high priority for GNU? -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
Re: Communication and Design at Guix
On 2019-01-16 16:31, George Clemmer wrote: > Hi Lprndn, > > I am glad to see your interest in these issues. > > Ludovic Courtès writes: > >> Hi, >> >> L p R n d n skribis: >> >>> Ludovic Courtès writes: >> >> [...] >> >>>> A very concrete task that could be of interest to you is the “name >>>> change” (a bit of a strong word) that we’d like to implement by 1.0. >>>> I’ll try to summarize. Currently we have “Guix” and “GuixSD”, and that >>>> confuses things: people visit the web site, they see a “GuixSD” logo and >>>> get confused because they were just looking for a package manager, not a >>>> whole distro, or they think “GuixSD” is a storage device ;-), things >>>> like that. >>>> >>>> The idea is to bring everything under the “Guix” name. Most of the >>>> time, writing “Guix” is good enough—after all, one can run ‘guix system’ >>>> on a foreign distro, too. When we really need to make the distinction, >>>> for instance in the manual, we would write “Guix System” to designate >>>> what we currently call “GuixSD”. >>> >>> Hum. It might just be as easy as getting rid of the GuixSD logo and >>> wording for the most part. Then we can find a *preferred* way to >>> designate GuixSD (a Guix system (probably), Guix distro, Guix os).Here, >>> it's more about making GuixSD "disappear" but we could also just rebrand >>> GuixSD with some kind of "subtitle": "Guix, the system", derive a logo >>> from the Guix's one. It depends a lot from what we want to put under >>> the spotlight. >> >> The idea is more to have a single “brand”: Guix. > > Yes a single brand is the way to go. But, piecemeal changes to the web > site are unlikely to get us there unless we work from a unified "Guix > Brand" product description. E.g., earlier I proposed ... > > "'Guix' is a software environment manager that creates user environments > that are completely and independently specified by users. Guix users are > never stuck needing software that a Sysadmin can't, won't, or hasn't > installed. A Guix user can run multiple, differing environments > simultaneously and can replicate any environment on any Guix run-time > platform. Guix provides system-wide environment management when > appropriate to the run-time platform. Creation, modification, and > upgrade are atomic and roll-back is instantaneous, so Guix users and > sysadmins are never stuck with a broken user environment or system. > Guix implements a functional specification of package, user, and system > configurations using the Scheme language. Guix complies with the FSF > Four Essential Freedoms and Free System Distribution Guidelines and > provides easy and immediate access to the exact source being run. By > default, Guix uses pre-built package substitutes from the Guix build > farm and mirrors but users may build any package, or a complete system, > from package developer sources."[1] > >> Then “Guix System” would be a component of Guix, so to speak, similar >> to GNOME and its applications. > > "Guix System" is a "bad" name for "GuixSD." Why? Because a new user's > first expectation is for "Guix system" to refer to the whole of Guix, > which we want to call "Guix" (referred to as "Guix Brand" below). > > But if we call GuixSD the "Guix System", we create a counter-intuitive > thing to explain. E.g., we will be saying, "Our GNU/Linux System > Distribution, 'Guix System' is just one of multiple ways to use 'Guix > Brand', which includes the Guix package manager, for which we also use > the 'Guix Brand' label. > > Another "bad" thing about calling it "Guix system" is that when a user > searches "guix system" they hit the 'guix system' "Guix Brand" package > manager' command that, BTW, also generates "Guix VMs". > > It will simplify our work if we present GuixSD as simply one of several > Guix download/deployment options. E.g., earlier I suggested ... > > "Guix is available on multiple run-time platforms including bare metal > (GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix > Binary).[1]" > > With this approach, we only need a distinctive label for GuixSD that > doesn't puzzle users to produce reliable search hits on the relevant > parts of our message and documentation. E.g., GuixOS. > > HTH - George > > [1] https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00444.html +1 Nice work George. GuixOS gives us the advantage of OS already being known as a complete useful separate thing to boot and install (e.g. NixOS, ReactOS, Chrome OS, iOS, etc.) Guix is now an octopus with many arms :) -- Cheers Swedebugia
Re: Stating the size of ecosystems in descriptions
On 2019-01-16 19:55, Ricardo Wurmus wrote: > Pierre Neidhardt writes: > >> Ricardo Wurmus writes: >>> I’d prefer not to add a feature like this. >> >> Why not? > > Lots of reasons. > > One reason is that pypi isn’t the only source of Python packages. Nor > is CRAN the only source of R packages. There are also package sources > that we fetch from other locations because of problems with whatever has > been published on the more popular repositories (e.g. most of the > rubygems). > > I also think it’s not the job of a package manager to tell you how much > software there is in this world and how much of it can be accessed via > the package manager. What good are those numbers? What useful > information do they provide? I don’t think it’s good to clutter the > list of commands (and the documentation) with features of very limited > usefulness. > > I don’t like the ways it would work: neither do I want to store and > regularly update lists of remote packages nor do I want to have my > package manager call out to remote web servers. What about packages > that are not available because they are not free software? > > (Finally, I don’t like the use of the word “ecosystem” in the realm of > software.) OK. Thanks for stating this Ricardo. Pierre, I'm fine with removing the sentence with the number altogether. -- Cheers Swedebugia
Re: Stating the size of ecosystems in descriptions
On 2019-01-16 14:52, Gabriel Hondet wrote: > Hello everyone, > > On Wed 16 Jan 2019 at 13:53 Pierre Neidhardt wrote: > >> Whichever number we provide will go out of date at some point. >> It's extra maintenance, and if we only put a rough number (e.g. 100k+) then >> it's >> not really meaningful in my opinion. > > While I agree with this statement, I also think that Swedebugia's idea of > comparing the number of Guix-ported packages of an ecosystem with the > total number of packages in this ecosystem is interesting. > > Couldn't something like > > #+begin_src sh > guix ecosystem pypi > #+end_src > > which would retrieve the number of packages on pypi, compute the number > of pypi packages defined for Guix and output some statistics be done? +1 This is way better than including it in the definitions, however we would probably have to parse the websites to get the numbers we need. -- Cheers Swedebugia
Idea: guile-cups-notifier (Was: Re: Improving GUI printing in GuixSD: (python-)system-config-printer, worth adding?)
On 2019-01-16 14:43, swedebu...@riseup.net wrote: > Hi > > Today I investigated a bit about this program. > > system-config-printer is a Red hat offspin that is essentially a quick > python hack to be able to say "we have a desktop gui for printer > configuration". > > Is it a useful program you think? Having used it on arch and debian I > found it somewhat buggy, ugly, unintuitive. > > It does not seem to interact with the system bus in order to send > printer errors to the notification area. (I could be wrong about this) > > One thing it does is give you easy access to the queue and to view print > related errors. Although cups errors are usually quite bad if you ask me > and I found I cannot really rely on it for restarting jobs etc. > > CUPS seems to me like in the same category as TeX, it is old, scolded, > overly complicated, error prone and we use and rely on it ONLY because > we lack a well working GNU replacement. > > -- > > system-config-printer depends on pycups and perhaps some polkit > pk-helper. > > Unfortunately I found no build documentation in the repository and it > has not seen a release for a year. > https://github.com/zdohnal/system-config-printer So if system-config-printer is an ugly python hack based on pycups, can we do better in guile? (pycups is 95,9% written in C) https://github.com/molefrog/cupsidity Is an alternative to pycups written in C++ and contains only the basics of the CUPS API. Keeping it simple we could make sure to ONLY add what Guix does not provide: print queue management. The idea is to make guile-cups bindings and a guile-cups-notifier that interacts with CUPS via guile-ffi and does only a few things (and do them well!): * has a daemon running that reads the queue from cups * prints messages to the user via dbus E.g. if the user sends something to the printer it pops up a message "Printing: "document name" - click to cancel." (cancelling a document is a nice feature and needed if the printer is far away) E.g. if an error occurs during printing it pops up a message displaying the error. E.g. "Printing of "document name" failed: No paper found" If printing succeed it prints: "Printing of "document name" finished." Thoughts? -- Cheers Swedebugia
Improving GUI printing in GuixSD: (python-)system-config-printer, worth adding?
Hi Today I investigated a bit about this program. system-config-printer is a Red hat offspin that is essentially a quick python hack to be able to say "we have a desktop gui for printer configuration". Is it a useful program you think? Having used it on arch and debian I found it somewhat buggy, ugly, unintuitive. It does not seem to interact with the system bus in order to send printer errors to the notification area. (I could be wrong about this) One thing it does is give you easy access to the queue and to view print related errors. Although cups errors are usually quite bad if you ask me and I found I cannot really rely on it for restarting jobs etc. CUPS seems to me like in the same category as TeX, it is old, scolded, overly complicated, error prone and we use and rely on it ONLY because we lack a well working GNU replacement. -- system-config-printer depends on pycups and perhaps some polkit pk-helper. Unfortunately I found no build documentation in the repository and it has not seen a release for a year. https://github.com/zdohnal/system-config-printer -- Cheers Swedebugia
Idea: guix printer configuration generation
Hi I would rather not have to learn the CUPS web interface just to configure my printer. Do we have a way to do this yet from config.scm? I think we should abstract away everything CUPS. Maybe we could make a guix printer importer? The idea is to extract information about the printer via Guile and print what the user need to add to the config.scm. Something like this: $ guix printer "Found 1 USB printer: HP DeskJet 4330 (cups-configuration (printer (name "HP DeskJet 4330" (connection "usb://34234556" (settings (paper "a4" (source "default" ..." When the user adds this to their config.scm and reconfigures the printer JUST WORKS. Thoughts? -- Cheers Swedebugia
Mozilla-importer and mozilla-build-system
Hi We currently have neither langpacks, dictionaries nor add-ons for Icecat packaged. This forces the users to install them iperatively through Icecat which for the case of dictionaries entails getting an error when following the "add dictionaries" menu-link in Icecat to an old mozilla-page. Installing via the new mozilla dictionary UI page here does work though (swedish): https://addons.mozilla.org/en-US/firefox/addon/g%C3%B6rans-hemmasnickrade-ordli/ Clicking install downloads and loads this file: https://addons.mozilla.org/firefox/downloads/file/1163981/swedish_dictionary-1.18.1webext.xpi The langpacks are provided by upstream here: ftp://ftp.gnu.org/gnu/gnuzilla/60.3.0/langpacks/ Add-ons installation support is buggy as has been reported here: https://lists.gnu.org/archive/html/bug-gnuzilla/2018-12/msg4.html We can do better than this! I beleive all these problems could be solved easily if we would package these in guix and make sure our Icecat looks for them in the right place. Perhaps a new mozilla-importer and mozilla-build-system is a worthwhile project? It should unpack and install the .xpi-files. There is an API available for the add-ons repository: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/AMO/Add-ons_manager_API An example output is this: https://services.addons.mozilla.org/en-US/firefox/api/1.5/addon/1865 If we package the langpacks and dictionaries from the upstream links I hope we can update them with "guix refresh". -- Cheers Swedebugia
Stating the size of ecosystems in descriptions (Was: Re: Gauche description)
On 2019-01-16 09:47, Pierre Neidhardt wrote: > Hi Gabriel! > > Thanks for contributing Gauche to Guix! > I've noticed something strange however: in the description, you mention > > --8<---cut here---start->8--- > There are currently 58 packages available. > --8<---cut here---end--->8--- > > Isn't it shortsighted? If another package is added upstream, then the > description won't match anymore. > > Why mentioning it at all? It was my idea during review. I think it is a good idea to give the user a hint about the number of available packages that exist in the ecosystems/package-managers we package. This is also valid for our python-pip-package etc. Currently this description does not mention anything about the number available (164,921 projects as of today). I agree that specifying the exact number might not be a good idea for the reason you stated. What about "More that 50 packages are currently available"? For pip this would be "More than 164.000 packages are currently available." -- This enables the user to quickly get a feel of how many of the total packages of python are currently in guix: fold-packages... prefix python: ~1400 out of 164.000 total ~ less than 1% of the python ecosystem is currently available in Guix thus you could help import more packages! -- Cheers Swedebugia
Re: Communication and Design at Guix
Ludovic Courtès writes:
> Hi!
>
> Ricardo Wurmus skribis:
>> It’s fine to deviate from the consistent style. We do that already for
>> the style sheet that’s used for our HTML documentation. Compare this:
>>
>> https://www.gnu.org/software/sharutils/manual/html_node/index.html
>>
>> with this:
>>
>> https://www.gnu.org/software/guix/manual/en/html_node/index.html
>>
>> It’s fine to change our style sheet, but let’s stay with Texinfo.
>
> Note that our manual uses https://gnu.org/software/gnulib/manual.css,
> which is the standard CSS produced by Gnulib’s gendocs.sh, and this CSS
> is used by many (most?) manuals at gnu.org, not just Guix.
>
> My suggestion was to improve this CSS, if L p R n d n is willing to make
> the extra social effort to get changes accepted. If that doesn’t work,
> we can depart from that.
Thanks for the clarification :)
I looked into the chicken docs and their html and css. They generate
their examples from source-code with this MIT chicken egg-script:
http://code.call-cc.org/svn/chicken-eggs/release/4/colorize/trunk/colorize.scm.
To use their approach with parens highlighting we would need to either
depend on chicken and this egg or port it to guile.
I ran it just for fun and got an error as expected. :p
It generates nice html like this:
;; irregex,
the regular expression library, is one of the
;; libraries included with CHICKEN.
(import (chicken irregex)
(chicken
io))
The CSS magic is this (public domain):
#content .highlight .paren1,#content .highlight .paren2,#content .highlight
.paren3,#content .highlight .paren4,#content .highlight .paren5,#content
.highlight .paren6 {
background-color:inherit;
}
#content .highlight .paren1:hover,#content .highlight .paren2:hover,#content
.highlight .paren3:hover,#content .highlight .paren4:hover,#content .highlight
.paren5:hover,#content .highlight .paren6:hover {
color:#FFF;
font-weight:700;
}
#content .highlight .paren1:hover {
background-color:#DB7859;
}
#content .highlight .paren2:hover {
background-color:#1B804C;
}
#content .highlight .paren3:hover {
background-color:#9F214E;
}
#content .highlight .paren4:hover {
background-color:#DBA059;
}
#content .highlight .paren5:hover {
background-color:#B64926;
}
#content .highlight .paren6:hover {
background-color:#64A422;
}
#content .highlight .comment {
color:#8C8281;
font-style:italic;
}
Re: NPM breakthrough with test packages and weird error
Julien Lepiller skrev: (12 januari 2019 23:26:10 CET) >Le Sat, 12 Jan 2019 11:08:03 -0800, >swedebu...@riseup.net a écrit : > >> On 2019-01-12 18:57, swedebu...@riseup.net wrote: >> > Hi >> > >> > I have good (and bad) news! >> > >> > Today I worked intensely on the node-build-system, importer and >made >> > some improvements as I ran into multiple errors using the importer >> > and building the packages. >> > >> > I tried first importing tape (test package, quite popular) and >> > succeded with a few adjustments. >> > >> > Then I tried tap, its a hairy mess unfortunately and pulls in del, >> > typescript, grunt, nyc, and others >> > >> > I write this message mostly because I now receive a really weird >> > error from guix. >> > >> > sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K node-grunt >> > guix build: error: build failed: invalid hash >> > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' >> > sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K >> > node-tap-mocha-reporter >> > guix build: error: build failed: invalid hash >> > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' >> > >> > The error is the same across multiple packages. Builds "succeede" >as >> > usual if they are already in the store or unrelated to grunt and >> > nyc. >> > >> > After investigating with strace I found this in the end: >> > >> > [pid 8371] read(13, "download", 8) = 8 >> > [pid 8371] write(13, >> > "\10\0\0\0\0\0\0\0\27\0\0\0\0\0\0\0minimatch-3.0.4."..., 944) = 944 >> > [pid 8371] read(13, "ptxc\0\0\0\0", 8) = 8 >> > [pid 8371] read(13, "K\0\0\0\0\0\0\0", 8) = 8 >> > [pid 8371] read(13, "invalid hash `72bd690b3fbd3be123"..., 75) = >75 >> > [pid 8371] read(13, "\0\0\0\0\0", 5) = 5 >> > [pid 8371] read(13, "\1", 1) = 1 >> > [pid 8371] read(13, "\0\0\0\0\0\0\0", 7) = 7 >> > [pid 8371] close(13) = 0 >> > [pid 8371] write(2, "guix build: error: build failed:"..., 109guix >> > build: error: build failed: invalid hash >> > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' >> > ) = 109 >> > [pid 8371] exit_group(1) = ? >> > [pid 8376] <... read resumed> ) = ? >> > [pid 8375] <... read resumed> ) = ? >> > [pid 8376] +++ exited with 1 +++ >> > [pid 8375] +++ exited with 1 +++ >> > [pid 8374] <... futex resumed>)= ? >> > [pid 8374] +++ exited with 1 +++ >> > +++ exited with 1 +++ >> > >> > How did I get a corrupted store? No idea. How to delete single >> > items? >> > >> > I found this email from 宋文武 from 2016 >> > >> > "> How do I get rid of these ca. 30 outdated store items? >> > I think call gc for each one will work, eg: >> > >> > for i in /gnu/store/*teensy*; do guix gc -d $i; done" >> > >> > I adapted it to *minimatch* and deleted them all and checked the >> > store manually for any minimatch left and... it still did not work. >> > >> > Hm. >> > >> > Removed the hash for minimatch from the node.scm. Tried again. No >> > luck. >> > >> > Time to repair the store? Update the daemon via reconfigure? >> > >> > I run vanilla 0.16. >> >> Pushed my changes here for anybody interested in taking a look >> https://gitlab.com/swedebugia/guix/commits/npm2 >> >> (All my work build on the previous work of Jelle and Julien. Big >> thanks to you!) >> >> Resume of its status: >> * recursive import works now. >> * cyclic dependencies are not detected by the importer >> * you have to import an earlier version by hand if a cycle is >> encountered. >> >> I imported 400+ packages in one day and most of them work out of the >> box :) >> > >Nice! > >For the hash issue, I just had a similar one because I somehow removed >the hash in an origin record like so: > >(sha256 (base32 "")) > >The error is weird, but maybe the importer did something wrong? Thanks for the information. I switched to my guix on parabola and cloned first yours and them my repo. Then I imported minimatch again to make sure the hash is right and it worked! Status: I now got these working 95 % built with guix: * tap * grunt * coffee-script * @babel/core and /cli In total these have 300 dependencies that now work. I got stuck with tape because one of the dependencies need typescript to build and typescript depends on gulp. Gulp is a nightmare (304 dep with multiple circles if versions are not considered). If I disable building on this one dependency tape would probably work. -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
Adding versioning to our recursive importer
Hi I would like some help from someone who understands the recursive importer. The reason is that in our npm-importer we have to support different versions of the same packages to avoid circular dependencies (which happen e.g. when importing gulp when not considering versions). Doing this manually is... not viable. (see the svgz attached) For every dependency I expect the procedure below to handle a list dependency pairs of name+version instead of just name. Our very nice recursive importer looks like this: (define* (recursive-import package-name repo #:key repo->guix-package guix-name #:allow-other-keys) "Generate a stream of package expressions for PACKAGE-NAME and all its dependencies." (receive (package . dependencies) (repo->guix-package package-name repo) (if (not package) stream-null ;; Generate a lazy stream of package expressions for all unknown ;; dependencies in the graph. (let* ((make-state (lambda (queue done) (cons queue done))) (next (match-lambda (((next . rest) . done) next))) (imported (match-lambda ((queue . done) done))) (done? (match-lambda ((queue . done) (zero? (length queue) (unknown? (lambda* (dependency #:optional (done '())) (and (not (member dependency done)) (null? (find-packages-by-name (guix-name dependency)) (update (lambda (state new-queue) (match state (((head . tail) . done) (make-state (lset-difference equal? (lset-union equal? new-queue tail) done) (cons head done))) (stream-cons package (stream-unfold ;; map: produce a stream element (lambda (state) (repo->guix-package (next state) repo)) ;; predicate (negate done?) ;; generator: update the queue (lambda (state) (receive (package . dependencies) (repo->guix-package (next state) repo) (if package (update state (filter (cut unknown? <> (cons (next state) (imported state))) (car dependencies))) ;; TODO: Try the other archives before giving up (update state (imported state) ;; initial state (make-state (filter unknown? (car dependencies)) (list package-name Any ideas? -- Cheers Swedebugia
Re: NPM breakthrough with test packages and weird error
On 2019-01-12 18:57, swedebu...@riseup.net wrote: > Hi > > I have good (and bad) news! > > Today I worked intensely on the node-build-system, importer and made > some improvements as I ran into multiple errors using the importer and > building the packages. > > I tried first importing tape (test package, quite popular) and succeded > with a few adjustments. > > Then I tried tap, its a hairy mess unfortunately and pulls in del, > typescript, grunt, nyc, and others > > I write this message mostly because I now receive a really weird error > from guix. > > sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K node-grunt > guix build: error: build failed: invalid hash > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' > sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K > node-tap-mocha-reporter > guix build: error: build failed: invalid hash > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' > > The error is the same across multiple packages. Builds "succeede" as > usual if they are already in the store or unrelated to grunt and nyc. > > After investigating with strace I found this in the end: > > [pid 8371] read(13, "download", 8) = 8 > [pid 8371] write(13, > "\10\0\0\0\0\0\0\0\27\0\0\0\0\0\0\0minimatch-3.0.4."..., 944) = 944 > [pid 8371] read(13, "ptxc\0\0\0\0", 8) = 8 > [pid 8371] read(13, "K\0\0\0\0\0\0\0", 8) = 8 > [pid 8371] read(13, "invalid hash `72bd690b3fbd3be123"..., 75) = 75 > [pid 8371] read(13, "\0\0\0\0\0", 5) = 5 > [pid 8371] read(13, "\1", 1) = 1 > [pid 8371] read(13, "\0\0\0\0\0\0\0", 7) = 7 > [pid 8371] close(13) = 0 > [pid 8371] write(2, "guix build: error: build failed:"..., 109guix > build: error: build failed: invalid hash > `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' > ) = 109 > [pid 8371] exit_group(1) = ? > [pid 8376] <... read resumed> ) = ? > [pid 8375] <... read resumed> ) = ? > [pid 8376] +++ exited with 1 +++ > [pid 8375] +++ exited with 1 +++ > [pid 8374] <... futex resumed>)= ? > [pid 8374] +++ exited with 1 +++ > +++ exited with 1 +++ > > How did I get a corrupted store? No idea. How to delete single items? > > I found this email from 宋文武 from 2016 > > "> How do I get rid of these ca. 30 outdated store items? > I think call gc for each one will work, eg: > > for i in /gnu/store/*teensy*; do guix gc -d $i; done" > > I adapted it to *minimatch* and deleted them all and checked the store > manually for any minimatch left and... it still did not work. > > Hm. > > Removed the hash for minimatch from the node.scm. Tried again. No luck. > > Time to repair the store? Update the daemon via reconfigure? > > I run vanilla 0.16. Pushed my changes here for anybody interested in taking a look https://gitlab.com/swedebugia/guix/commits/npm2 (All my work build on the previous work of Jelle and Julien. Big thanks to you!) Resume of its status: * recursive import works now. * cyclic dependencies are not detected by the importer * you have to import an earlier version by hand if a cycle is encountered. I imported 400+ packages in one day and most of them work out of the box :) -- Cheers Swedebugia
NPM breakthrough with test packages and weird error
Hi I have good (and bad) news! Today I worked intensely on the node-build-system, importer and made some improvements as I ran into multiple errors using the importer and building the packages. I tried first importing tape (test package, quite popular) and succeded with a few adjustments. Then I tried tap, its a hairy mess unfortunately and pulls in del, typescript, grunt, nyc, and others I write this message mostly because I now receive a really weird error from guix. sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K node-grunt guix build: error: build failed: invalid hash `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' sdb@antelope ~/src/guix$ ./pre-inst-env guix build -K node-tap-mocha-reporter guix build: error: build failed: invalid hash `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' The error is the same across multiple packages. Builds "succeede" as usual if they are already in the store or unrelated to grunt and nyc. After investigating with strace I found this in the end: [pid 8371] read(13, "download", 8) = 8 [pid 8371] write(13, "\10\0\0\0\0\0\0\0\27\0\0\0\0\0\0\0minimatch-3.0.4."..., 944) = 944 [pid 8371] read(13, "ptxc\0\0\0\0", 8) = 8 [pid 8371] read(13, "K\0\0\0\0\0\0\0", 8) = 8 [pid 8371] read(13, "invalid hash `72bd690b3fbd3be123"..., 75) = 75 [pid 8371] read(13, "\0\0\0\0\0", 5) = 5 [pid 8371] read(13, "\1", 1) = 1 [pid 8371] read(13, "\0\0\0\0\0\0\0", 7) = 7 [pid 8371] close(13) = 0 [pid 8371] write(2, "guix build: error: build failed:"..., 109guix build: error: build failed: invalid hash `72bd690b3fbd3be123e66c0c1932d856b294931d134cd07d4d4cd6aa1e07' ) = 109 [pid 8371] exit_group(1) = ? [pid 8376] <... read resumed> ) = ? [pid 8375] <... read resumed> ) = ? [pid 8376] +++ exited with 1 +++ [pid 8375] +++ exited with 1 +++ [pid 8374] <... futex resumed>)= ? [pid 8374] +++ exited with 1 +++ +++ exited with 1 +++ How did I get a corrupted store? No idea. How to delete single items? I found this email from 宋文武 from 2016 "> How do I get rid of these ca. 30 outdated store items? I think call gc for each one will work, eg: for i in /gnu/store/*teensy*; do guix gc -d $i; done" I adapted it to *minimatch* and deleted them all and checked the store manually for any minimatch left and... it still did not work. Hm. Removed the hash for minimatch from the node.scm. Tried again. No luck. Time to repair the store? Update the daemon via reconfigure? I run vanilla 0.16. -- Cheers Swedebugia
Re: GRUB fallback mechanism [was Re: Brain storming cool Guix features]
Leo Famulari skrev: (11 januari 2019 23:32:12 CET) >On Mon, Jan 07, 2019 at 05:48:39PM +0100, L p R n d n wrote: >> - Currently, I think the only way for a GuixSD installation to break >is >> if something goes wrong with the bootloader. Might be nice to have >a >> tool (in the install image I suppose) to recover the bootloader. >> Maybe 'guix system init' can deal with that king of cases for now, >I >> don't know, but a dedicated command might be able to use the >original >> store, restore previous generations etc. > >Apparently GRUB has a feature that records a "fallback" system to boot >if booting fails. > >Maybe when reconfiguring, Guix could set the current system as the >fallback so that it would always boot. > >If we did that, we'd want to warn the user somehow... not sure how to >achieve that. > >Discussion of this feature at NixOS: > >https://github.com/NixOS/nixpkgs/issues/26332 I don't think automatic fallback is a good idea because it unnecessarily complicates a now well working simple part of the OS. KISS is a nice principle. -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
Re: Packaging Jami (ex GNU Ring)
Pierre Neidhardt skrev: (10 januari 2019 14:19:34 CET) > >swedebugia writes: >> I put it in messaging.scm. Is that suitable? > >Maybe not. From qaul.net: > >> qaul.net implements a redundant, open communication principle, in >which >> wireless-enabled computers and mobile devices can directly form a >spontaneous >> network. Text messaging, file sharing and voice calls are possible >independent >> of internet and cellular networks. > >From https://github.com/qaul/qaul.net: >(WiFi) Mesh network communication app > >Maybe it would fit better in networking.scm? Thanks, I had put it there first 😝 -- Sent from my p≡p for Android. pEpkey.asc Description: application/pgp-keys
