Re: Excessively energy-consuming software considered malware?
My point to here is not to argue a "libertarian" viewpoint (I'm not one), but to argue that there or other consideration to mining crypto and that it is outside the realm of the free software movement from which Guix's package inclusion policy is derived. You or I might not like or agree with the over viewpoints but that should be fine with in the context of free software and operating systems. This is also foundational to liberalism and having a functional government in the first place. Who is going to pay and provide all of this I personal think it would be wonderful if governments focused on providing those things and mechanism such as the harbinger tax could be great and removing control of the monetary supply from the state would greatly reduce its ability to fund military expenditures. For reference David graeber's Debt: The First 5000 Years is an interesting narrative of how money's evolution was impart driven by the waging of mass war. On 2/24/22 10:23, Hartmut Goebel wrote: CW: politics below Am 20.02.22 um 21:39 schrieb Martin Becze: But undermining the governments ability to raise tax and therefor to wage war or not expending energy to prevent government theft is the ‘controversial morality’ that I am sure can be agreed to death and which probably doesn't belong on this list. Undermining the governments ability to raise tax also means undermining the ability to build schools, kindergartens, public libraries, public transport, streets, etc. Who is going to pay and provide all of this, If there is no democratically controlled(*) government? You might argument that this will then be paid be wealthy people - but the country will depend solely on their will and want. And these wealthy people are not controlled at all. And these people might wage war, too. We already had such a system in the medieval time. It:s called feudalism. So nothing is won by undermining the government. (*) Democratic control still needs a lot of improvement. Esp. in the USA where „the winner takes it all“ results in a two-party system, which does not represent the people. But this is another issue. OpenPGP_0xB97E95F9DED5755D.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Excessively energy-consuming software considered malware?
What is subjective about the numbers about energy consumption? The numbers are not subjective. As stated later it is the opinion on whether it is useful or not that is subjective. 1 Bitcoin transaction is said to be equivalent to 735121 Visa transactions This is a bad comparison since it compares two things that are different. A bitcoin tx is just an secp256k1 over some input and output opcodes. So forming at tx is not energy intensive. Processing a tx involves verifying the signature and running the opcodes. So this is also not energy intensive. What is energy intensive is PoW. PoW is used to achieve consensus on the ordering of tx's and *protects* the ledger for being reordered. Visa also ultimately relies on protection by law's and enforcement of those laws by governments within who's jurisdiction it operates. Bitcoin doesn't have any reliance on protection from the state, so it must provide its own protection and it does this through PoW. A better comparison would be comparing bitcoin mining to the US military expenditures. I would agree that military expenditures are too high and war is very bad for the environment. The ability of governments to wage massive wars rest on their ability to 1) collect taxes and 2) manipulating the supply of money. While it is a long shot, cryptos such as bitcoin could be used to prevent or at least make it hard for governments to seize crypto assets from the citizens, which could ultimate hinder them from raising the capital needed to wage mass war. In this context seems to me to be an great use of excess energy. BTW you can already mine bitcoin and monero with current packages. Guix refuses to have anything to do with non-free software, banning it from its repositories. That seems a bit authoritarian to me. Some people would say that's rather arbitrary of Guix. There's still plenty of software that is being kept non-free, so I guess that ‘software should be free’ counts as ‘controversial morality’? Yes I agree, but it is quite clear what to expect from a GNU project. I agree with its stance on free software and that is why I use it. Free software doesn't conflict with open source implementation of cryptocurrencies. I don't think it is fair to start add rules that ban software built with a particular political or ideological view point. It would be better to fork and create a new distro founded on your political and ideological principles. That way all newcomers could choose if participate and agree with the principles, instead of trying to force a participial ideological stance onto existing users that disagree with them. I suppose that technically, ‘don't mess up the planet’ is ‘controversial morality’ Once again agree we agree not to mess up the planet. But undermining the governments ability to raise tax and therefor to wage war or not expending energy to prevent government theft is the ‘controversial morality’ that I am sure can be agreed to death and which probably doesn't belong on this list. 2/20/22 17:52, Maxime Devos wrote: Martin Becze schreef op zo 20-02-2022 om 12:13 [+0100]: I don't consider mining to be wastefully and this is a extremely subjective opinion. What is subjective about the numbers about energy consumption? Quoting myself: ‘At least for bitcoin, mining is known to consume an absurd(*) amount of energy (the footprint of a whole country, and 1 Bitcoin transaction is said to be equivalent to 735121 Visa transactions)[1].’ [1]: See, e.g., https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html / https://www.nytimesn7cgmftshazwhfgzm37qxb44r64ytbb2dj3x62d2lljsciiyd.onion/2021/03/09/business/dealbook/bitcoin-climate-change.html (*) the word ‘absurd’ might count as subjective here Where exactly you draw the line between wasteful and not wasteful is rather subjective, but the numbers theirselves seem rather objective to me and wherever the line lies exactly, these numbers seem to be well over it. It should be a users choose whether or not they want to mine. A corner stone of free software is "(0) The freedom to run the program as you wish, for whatever purpose." By limiting what is accessible to the user based an arbitrary, authoritarian and controversial morality goes against the nature of free software. Guix refuses to have anything to do with non-free software, banning it from its repositories. That seems a bit authoritarian to me. Some people would say that's rather arbitrary of Guix. There's still plenty of software that is being kept non-free, so I guess that ‘software should be free’ counts as ‘controversial morality’? Along the same lines, Guix disabling telemetry and removing Google Analytics from documentation could count as patronising to upstream. I suppose that technically, ‘don't mess up the planet’ is ‘controversial morality’ given the existence of various lobbies etc., but I don'
Re: Excessively energy-consuming software considered malware?
I don't consider mining to be wastefully and this is a extremely subjective opinion. It should be a users choose whether or not they want to mine. A corner stone of free software is "(0) The freedom to run the program as you wish, for whatever purpose." By limiting what is accessible to the user based an arbitrary, authoritarian and controversial morality goes against the nature of free software. Martin On 2/20/22 11:48, Tobias Platen wrote: Yes, bitcoin could be considered malware. There is GNU Taler which is more efficent. Unfortunately Taler has not started yet, there is no working exchange at the moment. Tobias
Re: sorting Rust crates [was Re: rav1e AV1 encoder]
The problem should be fixed now. You can try it out about cloning `git clone https://gitlab.com/mjbecze/guix-package-sorter && cd guix-package-sorter` then do `./pre-install-env guix sort ` to sort the given file. Let me know if it works! On 4/12/20 10:22 AM, Martin Becze wrote: I apologize I didn't see this message until now. I will look into this today. On 4/2/20 5:31 PM, Leo Famulari wrote: On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote: sort2.scm will sort a files exported packages alphanumerically. I'm working on packaging rav1e for Guix again and so I'm using sort2.scm on the big 'gnu/packages/crates-io.scm' module. One problem I noticed with sort2.scm is that inherited packages need to be after the package they inherit from, but this means they will not be alphanumerically sorted. For example, sort2.scm will put rust-bytes-0.3 before rust-bytes-0.4, but then the build fails, because the former inherits from the latter but can no longer find it.
Re: sorting Rust crates [was Re: rav1e AV1 encoder]
I apologize I didn't see this message until now. I will look into this today. On 4/2/20 5:31 PM, Leo Famulari wrote: On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote: sort2.scm will sort a files exported packages alphanumerically. I'm working on packaging rav1e for Guix again and so I'm using sort2.scm on the big 'gnu/packages/crates-io.scm' module. One problem I noticed with sort2.scm is that inherited packages need to be after the package they inherit from, but this means they will not be alphanumerically sorted. For example, sort2.scm will put rust-bytes-0.3 before rust-bytes-0.4, but then the build fails, because the former inherits from the latter but can no longer find it.
Re: missing dependency for ungoogled-chromium
I submitted a patch awhile ago on this (https://issues.guix.gnu.org/issue/36632) but I couldn't figure out how to do it without propagating the input. On 3/25/20 4:46 AM, Marco van Hulten wrote: Hello— In a relatively clean profile, Chromium (ungoogled-chromium@80.0.3987.132-0.7e68f18) was crashing. By trial-and-error, I found out that the crash does not occur when font-liberation is installed. Therefore, I propose to add font-liberation as a dependency to ungoogled-chromium. —Marco
Re: rav1e AV1 encoder
On 2/27/20 12:26 PM, Leo Famulari wrote: I'm wondering if I can just push the crates as a single commit, after inserting them alphabetically and fixing any cosmetic issues, and also handling the semver-compatible package updates. I know that we don't usually do this when adding packages to an existing module. We do add packages en masse when creating a new module. The reason I'm asking to make an exception to our policy of one package or update per commit are that it will be a ton of work (several full days at least) to add software that is already working fine on the wip-rav1e branch. I don't see what value this additional labor will give to Guix users, including developers. At least, I don't think the value of individual commits will outweigh the value of my labor in this case. What do you all think? Yeah I have also wondered this. I think it would make things a lot easier if we could do single commits.
Re: rav1e AV1 encoder
However, it does not successfully handle inherited packages, doing things like removing rust-aho-corasick-0.7 even though rust-aho-corasick-0.6 inherits from it. Handling inheritance could be tricky, I have fully thought that part though. Additionally, the commit diffs it creates are a little suspicious, for example see below, which seems malformed. Can confirm its off. I might be able to look at it today. thanks!
Re: rav1e AV1 encoder
You need to remove the "(use-modules ..." from rav1e-sorted.scm, it should only have package definitions into. Ill also find away to handle that more elegantly On 2/21/20 11:56 AM, Leo Famulari wrote: On Fri, Feb 21, 2020 at 11:46:58AM -0500, Martin Becze wrote: hmm do you mind sending me rav1e-sorted.scm? Thanks for the report! Attached! If you want to build it, make sure to adjust the module path on the first line to match the "-sorted" filename. Also note that I changed the variable names of the first two packages, cargo-c and rav1e, from what the importer named them. But I tried changing them back and it didn't seem to help.
Re: rav1e AV1 encoder
hmm do you mind sending me rav1e-sorted.scm? Thanks for the report! On 2/21/20 11:41 AM, Leo Famulari wrote: On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote: 2) Sort the packages, `guile -s ./sort2.scm mypackage.scm > mypackage.scm` (you will probably also want to sort crates-io.scm, i think some packages may be out-of-order now) I sorted rav1e.scm and crates-io.scm, no problem... 3) merge mypackages.scm and crates-io.scm `guile -s ./merge.scm ./mypackage.scm ./crates-io.scm` It crashes like this: -- ~/work/guix/pre-inst-env guile -s ~/tmp/merge.scm gnu/packages/rav1e-sorted.scm gnu/packages/crates-io-sorted.scm Backtrace: 6 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 5 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 4 (_ #(#(#))) In ice-9/boot-9.scm: 2312:4 3 (save-module-excursion _) 3832:12 2 (_) In /home/leo/tmp/merge.scm: 101:10 1 (merge-iter # …) In unknown file: 0 (string
Re: rav1e AV1 encoder
hmm do you mind sending me rav1e-sorted.scm? Thanks for the report! On 2/21/20 11:41 AM, Leo Famulari wrote: On Fri, Feb 21, 2020 at 04:15:43AM -0500, Martin Becze wrote: 2) Sort the packages, `guile -s ./sort2.scm mypackage.scm > mypackage.scm` (you will probably also want to sort crates-io.scm, i think some packages may be out-of-order now) I sorted rav1e.scm and crates-io.scm, no problem... 3) merge mypackages.scm and crates-io.scm `guile -s ./merge.scm ./mypackage.scm ./crates-io.scm` It crashes like this: -- ~/work/guix/pre-inst-env guile -s ~/tmp/merge.scm gnu/packages/rav1e-sorted.scm gnu/packages/crates-io-sorted.scm Backtrace: 6 (apply-smob/1 #) In ice-9/boot-9.scm: 705:2 5 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 4 (_ #(#(#))) In ice-9/boot-9.scm: 2312:4 3 (save-module-excursion _) 3832:12 2 (_) In /home/leo/tmp/merge.scm: 101:10 1 (merge-iter # …) In unknown file: 0 (string
Re: rav1e AV1 encoder
On 2/20/20 5:43 PM, Leo Famulari wrote:
Should they be added to (gnu packages crates-io)?
yep!
And if so, should it
be done as a single commit? Or one-by-one?
One-by-one unfortunately
It's 258 new packages, and
figuring out the order they should be added in seems... too hard.
They should be alphanumeric
The c-bindgen and cargo-c packages could go in (gnu packages rust-apps).
What about updating them later? Will `guix refresh` handle it?
guix refresh should handle them. But currently it should do thing
recursively so keep that in mind.
I have a small tool I have been working will make the new packages
easier to commit its very much WIP but if I would appreciate any
feedback. Attached is sort2.scm and merge.scm
sort2.scm will sort a files exported packages alphanumerically.
merge.scm will merge exported packages of two files into a single file
creating a git commit for every new or updated package.
Here is my work flow,
1) Import the package using `guix import crate -r mypackage > mypackage.scm`
2) Sort the packages, `guile -s ./sort2.scm mypackage.scm >
mypackage.scm` (you will probably also want to sort crates-io.scm, i
think some packages may be out-of-order now)
3) merge mypackages.scm and crates-io.scm `guile -s ./merge.scm
./mypackage.scm ./crates-io.scm`
4) check that the git log looks correct and that everything still runs! :D
-Martin
(use-modules (guix utils))
(use-modules (guix build utils))
(use-modules (ice-9 binary-ports))
(use-modules (ice-9 match))
(use-modules (srfi srfi-1))
(use-modules (srfi srfi-9))
(use-modules (srfi srfi-71))
(define-record-type
(make-iter-pos port name str version eof?)
iter-pos?
(portiter-pos-port)
(nameiter-pos-name)
(str iter-pos-str)
(version iter-pos-version)
(eof?iter-pos-eof?))
(define-values (a-filename b-filename)
(match (command-line)
((self a-file b-file) (values a-file b-file
(define (peek-operation port proc)
(let ((org-pos (ftell port)))
(call-with-values
proc
(lambda vals
(seek port org-pos SEEK_SET)
(apply values vals)
(define (peek-rest port)
(peek-operation port (λ ∅ (get-bytevector-all port
(define a-port (open-input-file a-filename))
(define out-port (open-io-file b-filename))
(define b-port (open-bytevector-input-port
(peek-rest out-port)))
(define (git-commit msg)
(sync)
(invoke "git" "commit" "-a" "-m" msg))
(define (git-commit-new-package a)
(define name (iter-pos-name a))
(git-commit
(string-append "gnu: Add " name "\n\n* gnu/packages/" b-filename
" (" name "): New varible.")))
(define (git-commit-update-package a)
(let ((name (iter-pos-name a))
(version (iter-pos-version a)))
(git-commit
(string-append "gnu: " name ": Upgrade to " version "\n\n* gnu/packages/" b-filename
" (" name "): Upgrade to " version
(define (file-iter port)
(λ ∅
(let* ((start (ftell port))
(sexp (read port))
(end (ftell port))
(str (begin
(seek port start SEEK_SET)
(get-bytevector-n port (- end start
(name version
(match sexp
(('define-public name
(or
('package ('name _) ('version version) . _)
('let _ ('package ('name _) ('version version) . _
(values (symbol->string name) version))
(_ (values #f #f
(eof? (eof-object? sexp)))
(make-iter-pos port name str version eof?
(define* (insert-before a b out #:optional replace)
(let ((a-str (iter-pos-str a))
(b-str (iter-pos-str b))
(b-rest (peek-rest
(iter-pos-port b
(put-bytevector out-port a-str)
(peek-operation
out-port (λ ∅
(unless replace
(put-bytevector out-port b-str))
;; read the rest of port-b
(put-bytevector out-port b-rest)
(define (merge-iter a-iter b-iter out-port)
(let lp ((a (a-iter))
(b (b-iter)))
(unless (iter-pos-eof? a)
(let ((a-name (iter-pos-name a))
(b-name (iter-pos-name b))
(a-str (iter-pos-str a))
(b-str (iter-pos-str b)))
(cond
((not b-name)
(begin
(put-bytevector out-port (iter-pos-str b))
(lp a (b-iter
((string? a-name b-name)
(lp a (b-iter)))
(#t
(begin ;; else the names are equal
;; make sure the action are idenpotent
(unless (equal? b-str a-str)
(insert-before a b out-port #t)
(git-commit-update-package a))
(lp (a-iter) (b-iter)
(merge-iter
(file-iter a-port) (file-iter b-port) out-port)
(use-modules (ice-9 pretty-print))
(use-modules (ice-9 binary-ports))
(use-modules (ice-9 match))
(define filename (match (command-line)
((self file) file)))
(define* (package-list port #:optional (init '()))
(let ((start (ftell port))
(sexp (read port))
(end (ftell port)))
(if (eof-object? sexp)
init
(package-list port (cons (list start end sexp) init)
(define out-port (current-output-port))
(define port (open-file filename "r"))
(define packages (package-list port))
(define
Re: Rust packaging coordination
I'm trying to finishup the recursive importer. After that is in I might work on Alacritty, but if anyone wants to work on it in the meantime feel free! On 2020-01-27 15:09, John Soo wrote: > Hi rust packagers, > > We have: ripgrep, tokei, cbindgen. > > I cc'd nicolo because they mentioned wanting exa. I have a patch for > it but there are tests failing. If they wanted to give packaging a > try, that would also be welcome. > > I would also like to see alacritty updated to 0.4 in master. Alacritty > 0.3.3 has been working for a few months for me. > > I also have: racer, rustfmt, fd and pijul. > > What should we do next? > > Thanks, > > John
Re: (not) testing Rust packages?!
On 1/25/20 11:46 AM, John Soo wrote: Hi Hartmut and Martin, I think it makes sense to run tests now. Part of the reason is that bringing tests for a given library can bring in a massive amount of dependencies. I think that we are getting close to having complete dependencies for most rust packages we have and most are declared in the package definition. Yeah really good point there (and good work on getting all those pkgs in!) Furthermore since most rust libraries we have are not executables, we could still skip the build and run the tests I think. Aren’t the two phases completely separate for cargo? Yes, will can skip the build and just test in the (cargo-build-system) but `cargo test` will cause most everything to build anyways i believe. I like the idea of having tests, too. Plus I’d like to see the cargo build system come closer to the standard package definition. agreed!
Re: (not) testing Rust packages?!
Part of the reason is that bringing tests for a given library can bring in a massive amount of dependencies. So testing only the top level package seemed like the way to go. Maybe we could add testing when encountering problematic rust packages that break often? On 1/25/20 8:38 AM, Hartmut Goebel wrote: Hi, I discovered that most packages in crates-io.scm are not build. I understand that this is done since they do not produce any useful output. But as an side-effect, the packages are not tested either - which might leave issues undiscovered. Is this intended? My experience when packaging KDE libraries showed that is does make sense to actually test the libraries to detect issues early. And there are quite some possible issue in libraries, e.g. ladoing dynamic libs from /usr/lib, searching executables in PATH or even worth in a hard-coded path.
Re: Importers as independent packages?
Thank you Ludo, I added guile-semver to guix in the attached patch set, and I tested it by running ./pre-inst-env guix environment guix, which installed the guile-semver. and Makefile.am may have to check whether guile-semver is available.) I didn't see anything in the Makefile.am that looks to check for guile modules. Let me know if anything needs fixing! =Martin >From e4b022ce72582691dadae1b9f31ad6243914a5db Mon Sep 17 00:00:00 2001 From: Martin Becze Date: Sat, 18 Jan 2020 05:05:03 -0500 Subject: [PATCH v7 1/3] guix: import: (recursive-import) Allow for version numbers * guix/import/utils.scm (package->definition) [arguments] added optional `append-version?` * guix/import/utils.scm (recursive-import) [arguments] added key `version` and moved `repo` to be a key * tests/import-utils.scm * guix/import/cran.scm (cran->guix-package) [argument]: change `repo` to a key * guix/import/cran.scm (cran-recursive-import) [argument]: change `repo` to a key * guix/scripts/import/cran.scm: change `repo` to a key * guix/import/elpa.scm (elpa->guix-pakcage) [argumnets]: change `repo` to a key * guix/import/elpa.scm (elpa-recursive-import) [argumnets]: change `repo` to a key * guix/scripts/import/elpa.scm: change `repo` to a key * guix/import/gem.scm (gem->guix-package) [arguments]: change `repo` to a key * guix/import/gem.scm (recursive-import) [arguments]: change `repo` to a key * guix/import/opam.scm (opam-recurive-import) [arguments]: change `repo` to a key * guix/import/pypi.scm (pypi-recursive-import) [arguments]: change `repo` to a key * guix/import/stackage.scm (stackage-recursive-import) [arguments]: change `repo` to a key --- guix/import/cran.scm | 8 +++-- guix/import/elpa.scm | 6 ++-- guix/import/gem.scm | 6 ++-- guix/import/opam.scm | 5 ++-- guix/import/pypi.scm | 5 ++-- guix/import/stackage.scm | 5 ++-- guix/import/utils.scm| 57 +++- guix/scripts/import/cran.scm | 5 ++-- guix/scripts/import/elpa.scm | 4 ++- tests/import-utils.scm | 8 +++-- 10 files changed, 69 insertions(+), 40 deletions(-) diff --git a/guix/import/cran.scm b/guix/import/cran.scm index bcb37ed250..9e05dfcba8 100644 --- a/guix/import/cran.scm +++ b/guix/import/cran.scm @@ -2,6 +2,7 @@ ;;; Copyright © 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus ;;; Copyright © 2015, 2016, 2017, 2019, 2020 Ludovic Courtès ;;; Copyright © 2017 Mathieu Othacehe +;;; Copyright © 2020 Martin Becze ;;; ;;; This file is part of GNU Guix. ;;; @@ -506,7 +507,7 @@ from the alist META, which was derived from the R package's DESCRIPTION file." (define cran->guix-package (memoize - (lambda* (package-name #:optional (repo 'cran)) + (lambda* (package-name #:key (repo 'cran) #:allow-other-keys) "Fetch the metadata for PACKAGE-NAME from REPO and return the `package' s-expression corresponding to that package, or #f on failure." (let ((description (fetch-description repo package-name))) @@ -521,8 +522,9 @@ s-expression corresponding to that package, or #f on failure." (cran->guix-package package-name 'cran)) (else (values #f '() -(define* (cran-recursive-import package-name #:optional (repo 'cran)) - (recursive-import package-name repo +(define* (cran-recursive-import package-name #:key (repo 'cran)) + (recursive-import package-name +#:repo repo #:repo->guix-package cran->guix-package #:guix-name cran-guix-name)) diff --git a/guix/import/elpa.scm b/guix/import/elpa.scm index 2d4487dba0..9140bcdc34 100644 --- a/guix/import/elpa.scm +++ b/guix/import/elpa.scm @@ -2,6 +2,7 @@ ;;; Copyright © 2015 Federico Beffa ;;; Copyright © 2015, 2016, 2017, 2018, 2020 Ludovic Courtès ;;; Copyright © 2018 Oleg Pykhalov +;;; Copyright © 2020 Martin Becze ;;; ;;; This file is part of GNU Guix. ;;; @@ -245,7 +246,7 @@ type ''." (license ,license)) dependencies-names))) -(define* (elpa->guix-package name #:optional (repo 'gnu)) +(define* (elpa->guix-package name #:key (repo 'gnu) #:allow-other-keys) "Fetch the package NAME from REPO and produce a Guix package S-expression." (match (fetch-elpa-package name repo) (#f #f) @@ -301,7 +302,8 @@ type ''." (define elpa-guix-name (cut guix-name "emacs-" <>)) (define* (elpa-recursive-import package-name #:optional (repo 'gnu)) - (recursive-import package-name repo + (recursive-import package-name +#:repo repo #:repo->guix-package elpa->guix-package #:guix-name elpa-guix-name)) diff --git a/guix/import/gem.scm b/guix/import/gem.scm index 0bf9ff2552..e744d9e69d 100644 --- a/guix/import/gem.scm +++ b/guix/import/gem.scm @@ -2,6 +2,7 @@ ;;; Copyright © 2015 David Thompson ;;; Copyrigh
Re: how to test service changes
Thanks Nicolo, after adding my user to the kvm group that works! On 1/22/20 2:50 AM, Nicolò Balzarotti wrote: Hi Martin, I think you can use ~./pre-inst-env guix system vm config.scm~ and test the service there. But maybe somebody else has better advices. Thanks, Nicolò Martin Becze writes: Hi Guix, I was in the processes of updating geoclue but I ran into a problem. I don't know how to test the updated package on my system. geoclue is installed by (geoclue-service) in my config.scm. How would I go about making `guix system reconfigure ./config.scm` use my updated package? Or is there another way to replace the current geoclue with the newer one? Thanks! -Martin
Re: Documenting Yubikey setup
> Did you write something for the cookbook? The only thing that I know to put in the cookbook is the below snippet. I think it should be expanded a bit. But I haven't had a chance to futher explore using Yubikey. I still have some problems using it with icecat that I need to figure out. On 1/14/20 11:21 PM, Chris Marusich wrote: Hi Martin, Martin Becze writes: For a user to access a Yubikey an udev rule needs to be added. This can be done by using the udev rules found in libu2f-host package. To use the rules the following should be added to your config.scm (use-modules (gnu packages security-token)) ... (define %modified-desktop-services (modify-services %minimal-desktop-services (udev-service-type config => (udev-configuration (inherit config) (rules (cons libu2f-host (udev-configuration-rules config))) Reference https://guix.gnu.org/manual/en/html_node/Base-Services.html --- Of course there is more to say about yubikey but this is all I needed for now. Did you write something for the cookbook? I've also set up a YubiKey using Guix - I actually packaged some of the things like libu2f-host - and would be happy to review / add to whatever you've written.
how to test service changes
Hi Guix, I was in the processes of updating geoclue but I ran into a problem. I don't know how to test the updated package on my system. geoclue is installed by (geoclue-service) in my config.scm. How would I go about making `guix system reconfigure ./config.scm` use my updated package? Or is there another way to replace the current geoclue with the newer one? Thanks! -Martin
Re: Rust packaging coordination
I have packaged alacritty (im using it as a test app for the recursive crate importer). I'll wait until you get tokei in! On 1/16/20 3:14 AM, John Soo wrote: Hello guix and rust packagers, I’m curious if anyone else is working on packaging rust apps. I have been working on a patch set for tokei and it’s getting close to done. I would not like it if I had to rebase all 50 patches and I wouldn’t want anyone else to have to rebase theirs. So if you are working on any rust packages, maybe we should coordinate to make it less painful to merge. Thanks! John
Re: Importers as independent packages?
On 2019-12-17 04:37, Martin Becze wrote: > Hello Guix, > I have been working on a recursive importer that uses semantic > versioning over on #38408. It relies on guile-semver. I'm not exactly > sure how to add guile-semver as a dependency to guix. But I'm also not > sure that I should. Importers will probably not be used by the majority > of end users so would it make sense to put the importers in their own > package? This would also nicely solve recursive-import-semver's problem > of being dependent on guile-semver. > > Also in the future it would be nice if the crate import could read from > a Cargo.toml directly (this will make importing things like alacritty > much easier since it is not crates.io), which would probably mean have > yet another dependency (guile-toml). What do you think about this Guix? > > Thanks, > -Martin Becze So I should say that I meant one package for all importers. Not one package per-importer, since they share several common files.
Importers as independent packages?
Hello Guix, I have been working on a recursive importer that uses semantic versioning over on #38408. It relies on guile-semver. I'm not exactly sure how to add guile-semver as a dependency to guix. But I'm also not sure that I should. Importers will probably not be used by the majority of end users so would it make sense to put the importers in their own package? This would also nicely solve recursive-import-semver's problem of being dependent on guile-semver. Also in the future it would be nice if the crate import could read from a Cargo.toml directly (this will make importing things like alacritty much easier since it is not crates.io), which would probably mean have yet another dependency (guile-toml). What do you think about this Guix? Thanks, -Martin Becze
Re: Overhauling the cargo-build-system
On 2019-12-09 04:45, Chris Marusich wrote:
> input in order to actually build the program. In this model, I guess
> every "*-src" package would have no inputs and just one output. I guess
> any package that produces an artifact, for example the "ripgrep"
> package, would list a bunch of "*-src" packages as inputs: one for every
> crate in the transitive closure of dependencies and dev-dependencies of
> the ripgrep crate. That might solve the problem of cyclic dependencies,
> and it might reduce (but not eliminate) the amount of excessive building
> performed by cargo-build-system. However, it would make some package
> definitions large, it would introduce duplication of inputs across
> packages that need the same "*-src" inputs, and it would create a lot of
> "*-src" packages. On the plus side, tools like "guix graph" would work
> as-is; currently, "guix graph" has not been taught to understand
> #:cargo-inputs and #:cargo-development-inputs for cargo-build-system
> packages.
I don't understand why just adding a (skip-build?) to the source rust
packages, dropping their cargo-dev-deps AND leaving the cargo-inputs for
all the rest of the dependencies wouldn't accomplish the same thing. The
thing I object to is having to specify the transient packages at the top
level, since that would be unusable for actually rust development. Is
there any problem with the following example for rust source packages?
(define-public rust-home
(package
(name "rust-home")
(version "0.5.1")
(source
(origin
(method url-fetch)
(uri (crate-uri "home" version))
(file-name
(string-append name "-" version ".crate"))
(sha256
(base32
"1a4wcnadw2sarmisb5bz7gs4qwnijalvbf5gf7kg0wdxyxa3jxd3"
(build-system cargo-build-system)
(arguments
`(#:skip-build?
#t
#:cargo-inputs
(("rust-scopeguard" ,rust-scopeguard)
("rust-winapi" ,rust-winapi
(home-page "https://github.com/brson/home;)
(synopsis
"Shared definitions of home directories")
(description
"Shared definitions of home directories")
(license (list license:expat license:asl2.0
(define-public rust-winapi
(package
(name "rust-winapi")
(version "0.3.8")
(source
(origin
(method url-fetch)
(uri (crate-uri "winapi" version))
(file-name
(string-append name "-" version ".crate"))
(sha256
(base32
"1ii9j9lzrhwri0902652awifzx9fpayimbp6hfhhc296xcg0k4w0"
(build-system cargo-build-system)
(arguments
`(#:skip-build?
#t
#:cargo-inputs
(("rust-winapi-i686-pc-windows-gnu"
,rust-winapi-i686-pc-windows-gnu)
("rust-winapi-x86-64-pc-windows-gnu"
,rust-winapi-x86-64-pc-windows-gnu
(home-page
"https://github.com/retep998/winapi-rs;)
(synopsis
"Raw FFI bindings for all of Windows API.")
(description
"Raw FFI bindings for all of Windows API.")
(license #f)))
Also see patch 38465
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38465) for a complete
example. I would like too know if there is an problem with this patch
to, before I start packaging the other rust programs this way.
Thanks,
-Martin
Re: [PATCH] WIP patches for the rust importer
On 2019-12-04 02:40, Ivan Petkov wrote: > Hi Martin, > >> On Dec 2, 2019, at 3:10 PM, Martin Becze wrote: >> >> When you say source import of the transitive dependencies, do you >> mean >> that all the rust libs should just be source only or do you mean the >> top >> level package should have to declare all the transitive >> dependencies? > > All rust libs should be source only imports, but each package > definition > should only declare dependencies on the crates it consumes directly > and > guix should figure out the rest (in other words, I’d expect there to > be a > one-to-one mapping between a Cargo.toml and a package definition). > > For example, if crate foo depends on crate bar which depends on crate > baz, I’d expect the definitions to look like: > > (define-public rust-foo > (package > (name “rust-foo") > (source-input `((“bar” ,bar) > > (define-public rust-bar > (package > (name “rust-bar") > (source-input `((“baz” ,baz) > > (define-public rust-baz > (package > (name “rust-baz"))) > > But while building foo (assuming it is some kind of application), guix > would ensure that bar and baz are available in the build environment. > > IMO this direction would be the most maintainable in the long term. > > —Ivan Yes agree and that is what (recusive-import-semver) for produces rust. -Martin
Re: [PATCH] WIP patches for the rust importer
On 2019-12-02 04:01, Ivan Petkov wrote: > Hi Martin! > >> On Dec 1, 2019, at 7:17 PM, Martin Becze wrote: >> >> oh to be more clear. Even with "#:skip-build? #t" on all the rust >> libs, >> things fail if I omit one optional dependency from somewhere. I'm >> just >> testing on hello-cli but hello-cli inculdes clap which has alot of >> optional deps. In ./guix/build-systems/cargo.scm on line 186 it says >> >> >> "Cargo requires all transitive crate dependencies' sources to be >> available >> in its index, even if they are optional (this is so it can generate >> deterministic Cargo.lock files regardless of the target platform or >> enabled >> features). Thus we need all transitive crate dependencies for any >> cargo >> dev-dependencies, but this is only needed when building/testing a >> crate >> directly >> (i.e. we will never need transitive dev-dependencies for any >> dependency >> crates)." >> >> I haven't really dug into the cargo build-system yet but my guess is >> that the problem lies there. Asooo i totally could have missed >> something simple.. idk > > Yes, this is the primary limitation of packaging rust crates into guix > without manually needing to edit the Cargo.toml definition. > > My opinion is that the easiest (to maintain) method for incorporating > rust packages into guix is to bite the bullet and perform a (source) > import of all transitive dependencies that a package might need. > Manually keeping up with tweaking the Cargo.toml file for every single > potential package, across every single published version will make > you go mad :) > > Then the challenge would be how to automate the incremental importing > from crates.io [1] (for example, some crates require a specific x.y.z > version of > a dependency, some are willing to work with x.y.*, some have ranges, > etc.) > and making sure that all packaged crates point to the appropriate > dependencies > as they get updated in guix. > > —Ivan > > Links: > -- > [1] http://crates.io Hi Ivan, > My opinion is that the easiest (to maintain) method for incorporating > rust packages into guix is to bite the bullet and perform a (source) > import of all transitive dependencies that a package might need. When you say source import of the transitive dependencies, do you mean that all the rust libs should just be source only or do you mean the top level package should have to declare all the transitive dependencies? If former I agree but if it is the latter then I would consider rust packaging to be broken. > Then the challenge would be how to automate the incremental importing > from crates.io [1] (for example, some crates require a specific x.y.z > version of > a dependency, some are willing to work with x.y.*, some have ranges, > etc.) Yes that is what this patch (https://issues.guix.gnu.org/issue/38408) does. It uses semantic versioning to select the correct package form crate.io or if available from the alread packaged rust packages. -Martin
Re: [PATCH] WIP patches for the rust importer
On 2019-12-01 08:59, Efraim Flashner wrote: > On Fri, Nov 29, 2019 at 07:59:35AM -0800, Martin Becze wrote: >> On 2019-11-28 12:22, Efraim Flashner wrote: >> > On Wed, Nov 27, 2019 at 04:36:20PM -0800, mjbe...@riseup.net wrote: >> >> >> >> > I'd love to see what you have so far if you want to share >> >> >> >> Okie Dokie, I posted it and cc'd ya. >> >> >> >> Also I took a look at your patches. >> >> 0001-import-crate-Don-t-include-optional-dependencies.patch should work >> >> just fine with my patch. But >> >> 0003-import-crate-Honor-versioned-dependencies-when-impor.patch will not >> >> work. >> >> >> >> I took a different route here with the naming. If you are interested take >> >> a look take a look at my second patch. (recusive-import-semver) only will >> >> add the version number to the name if the crate being imported is not the >> >> latest version. I thought this was more inline with the canonical names, >> >> but if always adding version number the export symbol is desirable it will >> >> simplify things. >> >> >> > >> > I'll take a look at it in a minute. I figured with the versioned >> > requirements we would always want to be specific in version numbers for >> > crate dependents so I figured it made sense. Also, if we did want to >> > provide an unversioned '-latest' version we could declare an extra >> > variable '(define-public rust-libc rust-libc-0.2)' and now rust-libc >> > points to rust-libc-0.2. >> > >> >> Also I added a function (find-packages-by-name*/direct) to packages.scm >> >> which will return the export symbol of a package that already exists. I >> >> use this in case there are some non-canocal export name already added. >> >> >> >> I added the no-optional-dep logic to the recusive-semver patch >> (https://issues.guix.gnu.org/issue/38408), but it seems to break >> packages. I'm testing on the recursive importer on "hello-cli". Attach >> is the patch to add the logic and the before and after output for "guix >> import crate -r hello-cli". Removing all the optional deps breaks clap >> here for some reason which I haven't figured out. > > Looking at the two attached files I want to bring attention to the size > of them: > after.scm [text/plain, base64, utf-8, 5.7K] > before.scm [text/plain, base64, utf-8, 226K] > > One way to fix this (in addition to your "default to the don't build" > argument) is to keep rust-clap in it's broken state and define a > different rust-clap for when we actually want it and to have that use > enough inputs to actually build. I do now actually realize that only > really works if we keep all the crates hidden, which I don't think we > want. So I guess that has us sending bug reports upstream that some of > the optional dependencies aren't actually optional. > > In any case, I think it'd be better to skip the optional dependencies > and then add them back in as needed to actually build the crates we > want. oh to be more clear. Even with "#:skip-build? #t" on all the rust libs, things fail if I omit one optional dependency from somewhere. I'm just testing on hello-cli but hello-cli inculdes clap which has alot of optional deps. In ./guix/build-systems/cargo.scm on line 186 it says "Cargo requires all transitive crate dependencies' sources to be available in its index, even if they are optional (this is so it can generate deterministic Cargo.lock files regardless of the target platform or enabled features). Thus we need all transitive crate dependencies for any cargo dev-dependencies, but this is only needed when building/testing a crate directly (i.e. we will never need transitive dev-dependencies for any dependency crates)." I haven't really dug into the cargo build-system yet but my guess is that the problem lies there. Asooo i totally could have missed something simple.. idk
Re: [PATCH] WIP patches for the rust importer
On 2019-12-01 08:54, Efraim Flashner wrote: > Also, we don't want Guix to think 1.2.3 can only be upgraded to 1.2.3.4 > and not to 1.2.4. I'm kinda lost on this one. Why would guix think 1.2.3 can only be upgraded to 1.2.3.4?
Re: Documenting Yubikey setup
On 2019-11-29 20:15, Pierre Neidhardt wrote: > To clarify, you can send your article to this mailing list with an > obvious title (e.g. [BLOG] ...) to get feedback before publishing. thanks Pierre! Maybe this should go into the cookbook though? I think ideally it would be a wiki entry. Its one of those things that is easy from hindsight but not easy to google. --- For a user to access a Yubikey an udev rule needs to be added. This can be done by using the udev rules found in libu2f-host package. To use the rules the following should be added to your config.scm (use-modules (gnu packages security-token)) ... (define %modified-desktop-services (modify-services %minimal-desktop-services (udev-service-type config => (udev-configuration (inherit config) (rules (cons libu2f-host (udev-configuration-rules config))) Reference https://guix.gnu.org/manual/en/html_node/Base-Services.html --- Of course there is more to say about yubikey but this is all I needed for now.
Documenting Yubikey setup
Hello Guix, It took me a bit of time to figure out how to setup my Yubikey. Where would be a good place to document how to do this? Thanks, -Martin Becze
Re: [PATCH] WIP patches for the rust importer
On 2019-11-28 12:22, Efraim Flashner wrote: > I'll take a look at it in a minute. I figured with the versioned > requirements we would always want to be specific in version numbers for > crate dependents so I figured it made sense. Also, if we did want to > provide an unversioned '-latest' version we could declare an extra > variable '(define-public rust-libc rust-libc-0.2)' and now rust-libc > points to rust-libc-0.2. one thing to keep in mind is that (recursive-import-semver) is suppose to be generic so what ever naming logic we apply here for rust libs should be universal.
Re: Overhauling the cargo-build-system
> What I would have liked is to somehow replace the #:cargo-inputs > argument (which is build-system-specific and thus “opaque”) with regular > ‘native-inputs’ or ‘inputs’ field. That would be lovely! I always wondered why "#:cargo-inputs" existed.
Re: Overhauling the cargo-build-system
> It is quite frustrating to have to specify transitive dependencies at > the top level. I’m not sure what else is to be done, though. How about having something like "propagated-input" for rust source dependencies? The top level package could use the source deps as development-inputs so the source files wouldn't end up polluting the environment. Would that make sense?
Re: Overhauling the cargo-build-system
Sorry for digging up and old issue, but i just saw commit 86e443c71d4d19e6f80cad9ca15b9c3a301c738c > It makes for a very large package definition, but we wouldn't have to ensure thousands of other rust libraries built so we The whole point of package management is that you can use module building blocks. By having to specify the sub-dependencies in a top level definition kinda breaks the whole modular thing. In commit 86e443c71d4d19e6f80cad9ca15b9c3a301c738c all the inputs got removed for all the libraries. So if I'm trying to use guix as package manager for a rust project and I want to use one of the rust libraries in crates-io.scm, how am i suppose to do this? I can't just include it as an input to my project because now I have to look up all of it dependencies as well? > > PROPOSAL: > > Change all the rust packages we have now to be source-only. Rename them > > from rust-foo to rust-foo-src or rust-src-foo. Is there no way we can do this and keep the have a dependancy graph? On 2019-10-11 14:13, Efraim Flashner wrote: > On Fri, Oct 11, 2019 at 12:33:18AM +0200, Ludovic Courtès wrote: >> Hello! >> >> Efraim Flashner skribis: >> >> > I'd like to challenge the assumption that packages are both libraries >> > and source. A 'library' in rust compiles into one of three types: a >> > static library (libfoo.a), a shared library (libfoo.so), or a >> > 'rust-library' (libfoo.rlib). >> >> Why don’t we create .so files, then? They have NEEDED and RUNPATH, so >> that could work like for C, no? >> > > It is possible to force a library to produce .so files, but then we'd > have to force all the other packages to link against them, and then at > that point we're basically rewriting 'cargo build'. For some packages, > like icecat, that does seem to be what they do. > >> > Let me repeat that. We have 192 rust packages that no one needs or >> > wants, except in source form. >> >> Ouch! So the rlib file is never actually used?! >> > > As I understand it, it gets treated as a build artifact. It'll be > compiled as libfoo_X.rlib and then, if some other program comes > around as asks for "foo with feature baz" it'll be reused. At some point > it gets compiled directly into the final binary, so it's really more of > an intermediary stage. > >> You said “it is not possible to link an rlib to another rlib”, but >> that’s not necessarily a problem, it’s like .a libraries, no? >> > > if libfoo depends on libbar, then pre-building libbar_X.rlib doesn't > allow us to call "rustc --crate-name foo src/lib.rs --crate-type lib > --extern (string-append bar=(assoc-ref %build-inputs bar) > /lib/libbar.rlib)" (note the --crate-type lib in there), it'll just not > work and want to recompile libbar for just the few functions it uses > from it. The only difference I've seen is if our foo is also a "binary > crate", ie produces a binary, then it'll sometimes accept rlibs for its > own rlib lib output. > > Going back to forcing it to produce .so files, if we changed the > crate-type to dylib then we'd get libfoo.so. The two parts of the > problem is now we need to change all the other libraries and programs > that depend on foo to take our libfoo.so and not expect an rlib, and > that if foo has 3 options then we have to decide how to build libfoo so > it's useful for everything (obviously all 3) but without dragging in > everything (easiest with none of the 3), or to have some combination, > which becomes a nightmare very quickly. > > That sentence was way too long. > >> > PROPOSAL: >> > Change all the rust packages we have now to be source-only. Rename them >> > from rust-foo to rust-foo-src or rust-src-foo. >> >> In the current scheme, can you actually do, say: >> >> guix environment --ad-hoc rust rust-foo rust-bar >> >> and then (pseudo syntax): >> >> rustc mystuff.rust -lfoo -lbar >> >> ? > > Ignoring that we don't actually install the libraries here's a copy of > a check phase I wrote trying to use installed libraries. I think in the > end it did consume the rlibs as requested, but it never did link to > them, it just absorbed them into the final binary. > > (replace 'check > (lambda* (#:key inputs #:allow-other-keys) > (let ((ndarray(assoc-ref inputs "ndarray")) > (rand (assoc-ref inputs "rand")) > (rayon (assoc-ref inputs "rayon")) > (serde (assoc-ref inputs "serde")) > (serde-json (assoc-ref inputs "serde-json")) > (structopt (assoc-ref inputs "structopt"))) > (invoke "rustc" "--edition=2018" "--crate-name" "qtlreaper" > "src/lib.rs" > "-C" "opt-level=3" > "--test" "-C" "metadata=test" "-C" "extra-filename=-test" > "--out-dir" "target/release/deps" > "--extern" (string-append "ndarray=" ndarray > "/lib/libndarray.rlib") > "--extern" (string-append "rand=" rand "/lib/librand.rlib") > "--extern" (string-append "rayon=" rayon
Re: dependancies for importers
On 9/5/19 2:14 PM, Efraim Flashner wrote: > On Wed, Sep 04, 2019 at 04:20:46AM -0700, Martin Becze wrote: >> Hello, >> I'm wokring on the crate importer. It currently doesn't support >> versioning of dependancies and just always uses the latest version of a >> given crate. Of course this would break main rust packages, so i'm >> trying to add version support. To do this I need to be able it find a >> dependancy in a specified semantic version range and to do this I'm >> attempting to use a guile module >> (https://ngyro.com/software/guile-semver/). Is it possible to package >> this module then use it in an importer? Or should I just put the modules >> code directly in the `guix/import` ? >> > Although not actually answering your question, what about modifying the > crate importer to allow for getting a specific version? For example > 'guix import crate addr2line/0.9' or '/0.9.0'. I think it works with the > pypi importer, but I haven't inspected the code to see if that's on > purpose or a happy accident. > yes I already did this. But it doesn't work to well if it can't also get the correct version for the dependencies. signature.asc Description: OpenPGP digital signature
dependancies for importers
Hello, I'm wokring on the crate importer. It currently doesn't support versioning of dependancies and just always uses the latest version of a given crate. Of course this would break main rust packages, so i'm trying to add version support. To do this I need to be able it find a dependancy in a specified semantic version range and to do this I'm attempting to use a guile module (https://ngyro.com/software/guile-semver/). Is it possible to package this module then use it in an importer? Or should I just put the modules code directly in the `guix/import` ? Thanks, -Martin Becze
