Re: weird OpenBLAS time-machine

zimoun schreef op do 03-02-2022 om 03:19 [+0100]: > The issue is because concurrency.  If two time-machines are run > concurrently, they both update ~/.cache/guix/checkouts/ and the end > result is hard to predict. > > Well, I probably ran inside one terminal “guix time-machine > --commit= --

Re: weird OpenBLAS time-machine

> zimoun schreef op do 03-02-2022 om 11:42 [+0100]: > [...] > > > FWIW it's a known issue but I can't find it on issues.guix.gnu.org. > > The (unimplemented) fix is to use worktrees, or don't checkout and use > > the libgit2 / (guix git) equivalent of > > "git show 46fc72b2bfee2a30a3c3f3320e7d84b4

Re: Return back original implementation for text-config serialization

Andrew Tropin schreef op wo 26-01-2022 om 11:36 [+0300]: > In addition to the problems I mentioned above: > > 1. Mixed usage of two configuration languages (nginx-conf and lisp). > 2. Having a string, which should be properly escaped (luckily for > this > example it's not a problem). Mixing two c

Re: cross compiling using qemu-user-static

7:2: emacs@27.2: build system > `glib-or-gtk' does not support cross builds Is your guix up to date? Cross-compilation for 'glib-or-gtk' has been implemented in: commit 881a5d26b2fdf9ccb222b26b2a533cd09ffc62c8 Author: Maxime Devos Date: Tue Aug 24 11:06:53 2021 +0200

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]: > guix pack --target=armhf-linux-gnu openssh emacs libhandy FWIW the triple is arm-linux-gnueabihf. Greetings, Maxime. signature.asc Description: This is a digitally signed message part

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]: > So I think one could copy qemu-user-static for the target architecture > into the build directory and execute native versions of the software. > > [1] http://www.openpandora.org/ From a technical point of view, that's mostly native compil

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 17:39 [+0100]: > I was unaware that Guix already has that feature. > But on my Talos II, I am using Guix on top of Debian, > and I don't have Shepherd running. Debian has two packages for setting up binfmt: qemu-user-static and qemu-user-binfmt. Perhaps e

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 17:20 [+0100]: > On Sat, 2022-02-05 at 17:09 +0100, Maxime Devos wrote: > > Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]: > > > Some time ago I was able to cross compile emacs to run on the > > > OpenPandora[1] u

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 17:20 [+0100]: > On Sat, 2022-02-05 at 17:09 +0100, Maxime Devos wrote: > > Tobias Platen schreef op za 05-02-2022 om 16:14 [+0100]: > > > Some time ago I was able to cross compile emacs to run on the > > > OpenPandora[1] u

Re: cross compiling using qemu-user-static

Tobias Platen schreef op za 05-02-2022 om 18:23 [+0100]: > > What does "type -p guix" return? $HOME/.guix-profile/bin/guix or > > /usr/{local/,}bin/guix or something else? > /usr/local/bin/guix Looks like an old version. I see two possibilities here: * Set up .bash_profile and .profile like do

Re: emacs tramp in remote guix

Antonio Carlos Padoan Junior schreef op za 12-02-2022 om 19:04 [+0100]: > Josselin Poiret writes: > > > > > I personally use > > > >   (require 'tramp) > >   (connection-local-set-profile-variables > >    'guix-system > >    '((tramp-remote-path . (tramp-own-remote-path > >   (connection-lo

Re: better error messages through assertions

Ricardo Wurmus schreef op ma 14-02-2022 om 23:32 [+0100]: > I think we should add simple type checks, something like this: > [...] > > What do you think?  There are many different ways of implementing this > (a new variant of DEFINE that also accepts a type declaration, an assert > like above, a f

Re: Assisting reviewing & committing with tags?

Bengt Richter schreef op di 15-02-2022 om 13:23 [+0100]: > Hi guix, > > It sounds like a good idea, but ISTM we don't need yet another markup syntax > if emacs org mode already defines a useful standard that can be adopted. > > The advantage to org mode style [0] -- in commit commentary as well a

Excessively energy-consuming software considered malware?

[CC'ing some people in Guix I know to be interested in cryptocurrency] Hi, Guix packages some cryptocurrency(*) software (bitcoin, monero, some people have been working on packaging ethereum). So far, it only appeared that clients are being packaged. More recently, a ‘miner’ for monero has been

Faster "guix pull" by incremental compilation and non-circular modules?

Ekaitz Zarraga schreef op zo 20-02-2022 om 11:34 [+]: > Making a Guix pull is unpredictable too... An idea for making "guix pull" faster: 1. Make package imports non-circular, breaking up package modules in parts when necessary. 2. Instead of building all of Guix as a single derivat

Re: Excessively energy-consuming software considered malware?

Taylan Kammer schreef op zo 20-02-2022 om 13:20 [+0100]: > If we're going to exclude software on grounds of it being used in harmful > ways, I can already see people arguing that one should exclude software > such as aircrack-ng for aiding in breaching into networks, or anonymity > software like To

Re: Excessively energy-consuming software considered malware?

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

Semantics of circular imports

Philip McGrath schreef op zo 20-02-2022 om 11:47 [-0500]: > I was just (or maybe am still?) dealing with some issues caused by cyclic > imports of package modules while updating Racket to 8.4: see in particular > , as well as #66, #112, and #113 in the > same t

Re: [minor patch] Amend CoC

Liliana Marie Prikler schreef op zo 20-02-2022 om 19:05 [+0100]: > > Note: The upstream Contributor Covenant wouldn't want to include it > > because the author seems to have a peculiar world-view where they > > don't acknowledge that humans actually have a sex. I hope the Guix > > maintainers are

Re: Excessively energy-consuming software considered malware?

Attila Lendvai schreef op ma 21-02-2022 om 09:29 [+]: > let me add, though, that a more apples-to-apples comparison here would be to > compare Bitcoin to the FED, and PoW to the costs of enforcing the PetroDollar > system on the entire world. Here PetroDollar = US dollar and FED=US Federal Gov

Re: (Re-) Designing extractong-downaloder

Hartmut Goebel schreef op wo 23-02-2022 om 09:57 [+0100]: > TL;DR: What do you think about the idea of an „extracting dowloader“? > > I'm about pick up work on „extracting downloader“ and the rebar build > system (for erlang), see for a first > try, In the afo

Re: (Re-) Designing extractong-downaloder

Maxime Devos schreef op wo 23-02-2022 om 13:30 [+0100]: > A benefit of delegating the actual downloading to url-fetch, is that > (guix scripts perform-download) would be used, so connections could > be cached. Nevermind, this benefit is probably undone by the extra unpacking. I still

Re: setting open files limit for daemon processes

Attila Lendvai schreef op vr 25-02-2022 om 07:55 [+]: > "The per-process limit is inherited by each process from its parent", > and Shepherd is the init process. when it spawns a daemon, it inherits > its open files limit. > > i have successfully set the limit for the daemon user using: > >

Re: Everytime I install a package a symlink to ld.so.cache is created in $GUIX_PROFILE/etc, why?

vapnik spaknik schreef op vr 25-02-2022 om 15:16 [+]: > I've noticed that whenever I install a new package guix symlinks > the ld.so.cache file in that package to the etc subdir of my > guix profile directory (on a foreign distro). I was a bit suspicious > when I first noticed this, but then I

Re: Excessively energy-consuming software considered malware?

Bengt Richter schreef op vr 25-02-2022 om 13:41 [+0100]: > On +2022-02-24 19:27:37 -0500, Christine Lemmer-Webber wrote: > > I am all for these conversations; they are good to have as a society, to > > examine our social foundations in earnest dialogue. But I think they've > > approached a point o

Re: setting open files limit for daemon processes

Attila Lendvai schreef op vr 25-02-2022 om 21:28 [+]: > is there a way to instruct `guix system vm ...` _not_ to rebuild all the > dependants, and only replace the Shepherd that is running as the init process? This can be done by customising the 'shepherd' field of 'shepherd- configuration', i

Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

tumashu schreef op zo 27-02-2022 om 18:52 [+0800]: >    I want to include CAJA_EXTENSION_DIRS setup in ~/.guix- > profile/etc/profile file, > and the below code seem to do not work in glib-or-gtk-build-system The native-search-path will only have effect once there's actually a caja extension in ~/

Re: Re: native-search-paths search-path-specification do not work in glib-or-gtk-build-system

tumashu schreef op ma 28-02-2022 om 08:22 [+0800]: > by the way, if my system-config enable mate-1.24 desktop type.  when I > install a different version mate in > my home, for example 1.26,  which one will be use when I enter my deskop by > slim? I don't know. I'm currently on a foreign syste

Re: Faster "guix pull" by incremental compilation and non-circular modules?

Ludovic Courtès schreef op ma 28-02-2022 om 14:17 [+0100]: > Hi, > > Maxime Devos skribis: > > >   2. Instead of building all of Guix as a single derivation, > >  create a DAG of derivations. More concretely: > > > >  First read the *.scm fil

Re: workflow while hacking on Shepherd

Attila Lendvai schreef op di 01-03-2022 om 07:59 [+]: > 1) the code that will be run as the init process in a Guix System > > 2) the code that the Guix codebase is compiled against AFAICT, these two use the same shepherd -- i.e., the shepherd from the 'shepherd-configuration' record. To see

gnu: shepherd: patch, snippet or phase

(as implied per zimoun's previous mail (‘FWIW, it would be unfair for the patch to have the discussion here’), moved to guix-devel) Leo Famulari schreef op za 05-03-2022 om 16:13 [-0500]: > On Thu, Mar 03, 2022 at 07:25:22AM +0100, Maxime Devos wrote: > > Leo Famulari schreef op wo

Re: ‘gnu: Add go-github-com-niemeyer-pretty.’

> + (define-public go-github-com-niemeyer-pretty > + (package > +(name "go-github-com-niemeyer-pretty") > +(version "0.0.0-20200227124842-a10e7caefd8e") > +(source > + (origin > +(method git-fetch) > +(uri (git-reference < + (url "https://github.com/n

(rust) Do we always need to package minor versions separately?

Hi guix, Many rust crates are available in multiple versions in Guix (say, rust-wayland-scanner-0.29). The reason is that ((guix)Rust Crates): In the rust ecosystem it is common for multiple incompatible versions of a package to be used at any given time, so all package definitions should hav

Re: Different package version in same environment was: Re: [bug#54261] Acknowledgement ([PATCH]: Update GTK to 4.6.1.)

Zhu Zihao schreef op zo 13-03-2022 om 00:06 [+0800]: > Can you show me the link of the libcairo conflict example you said? > > I don't know what cause the segfaults in your example. C linker will > embed the full path of the library into the RUNPATH, unless > LD_LIBRARY_PATH is set, C library will

Re: Improve the output of `guix refresh -l`

Zhu Zihao schreef op do 17-03-2022 om 18:22 [+0800]: > for example, run `guix refresh -l pango`, The terminal prints: > > ``` > Building the following 2945 packages would ensure 7521 dependent > packages are rebuilt: .. > ``` > > The package list is too long to read, flood my terminal with pa

Re: Building a software toolchain that works

David Arroyo schreef op ma 14-03-2022 om 17:40 [-0400]: > 1. Obtain the source and unpack it into a writable working directory, >    skipping downstream patches and snippets. Why skip downstream patches and snippets? Often, these are necessry to make the source actually compileable (e.g. if it us

Re: Interest in "guix lint" Meetup?

zimoun schreef op vr 18-03-2022 om 10:13 [+0100]: > maybe Jami could be an > option.  IIRC, a service is around IIUC, the service is not required to hold a meeting, even among more than two parties. IIUC, one can simply create a ‘rendezvous point’, share the identifier and tell everyone to connec

Re: Fetching sources using Guix (re: Building a software toolchain that works)

Ryan Prior schreef op za 19-03-2022 om 00:08 [+]: > Would it be feasible or desirable to create a set of "reason" > symbols, similar to our "licenses," and attach a reason (or unknown?) > to each snippet and patch? Then we can expose meaningful data to the > end-user about patches & snippets th

Packaging go-github-com-hashicorp-vault-sdk -- ‘no Go files found’

(I sent this one previously to help-guix two days ago, and again one day ago, but it seems that it did not end up in so I'm resending to guix-devel this time) Hi, I'm trying to package go-github-com-hashicorp-vault-sdk. I ran "gu

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

zimoun schreef op wo 23-03-2022 om 12:28 [+0100]: > > This happens whenever I upgrade the system.  This makes the system > > rather frustrating to use.  I don’t know if booting into an older > > system > > generation would result in the same problem, but my guess is that > > it > > would because bo

Re: The Shepherd on Fibers

pelzflorian (Florian Pelz) schreef op za 26-03-2022 om 12:06 [+0100]: > * Lastly I grafted > > (define-public shepherd >   (package >     (name "shepherd") >     (replacement new-shepherd) >     … Grafting is not necessary. See (guix)Shepherd Services: ;; Use own Shepherd package.

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: > Fibers is used in a single-threaded fashion, which is the main > constraint for shepherd since it forks. That also means that fibers > cannot be preempted, so it’s fully cooperative scheduling. When hz!=0, guile-fibers uses with-interru

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: > [...] > Thoughts? To help translators, I would use positional arguments in + (l10n "Accepted connection on ~a from ~:[~a~;~*local process~].") Greetings, Maxime. signature.asc Description: This is a digitally signed message part

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: > Thoughts? What if 'exec-command' in 'fork+exec-command' fails? Is it still the case that the exception bubbles up, eventually causing the socket file to be deleted? Greetings, Maxime. signature.asc Description: This is a digitally si

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: Thoughts? From service.scm: > + (define (sleep* n) > +;; In general we want to use (@ (fibers) sleep) to yield to the > scheduler. > +;; However, this code might be non-suspendable--e.g., if the user calls > +;; the 'start'

Re: Packaging rust-analyzer is not necessary.

Paul Alesius schreef op vr 25-03-2022 om 09:05 [+0100]: > I've tried to produce a patch for the latest version, and it has > probably hundreds of dependencies that need to be updated. Even if you didn't succeed at updating _all_ dependencies, if you have patches for some of them, please send them.

Re: The Shepherd on Fibers

pelzflorian (Florian Pelz) schreef op za 26-03-2022 om 17:52 [+0100]: > Oh yes, I had not tried that.  Thank you Maxime.  Still with unchanged > original shepherd package, I get exactly the same > shepherd-avahi-daemon.go.drv.gz build failure iff I set (shepherd > new-shepherd).  Therefore I ask ho

A lexical use-modules?

Hi, [ CC'ing guix-devel@ because this functionality could be useful in Guix package definitions ] Currently, use-modules cannot be meaningfully used inside procedures, unless '(current-module)' is always the module in which the procedure is defined. I wondered if some kind of 'lexical use-module

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 23-03-2022 om 23:36 [+0100]: > Thoughts? To avoid accidentally using threads, perhaps Shepherd could do (set! call-with-new-thread (lambda () (error "multi-threading is not supported in Shepherd"))) ? Greetings, Maxime. signature.asc Description: This is a

Re: Semantics of circular imports

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]: > Oh, wow. I definitely had not realized that, *even inside a > declarative > module*, a reference to a variable with no statically visible > definition > would semantically be a dynamic lookup in a mutable environment at > runtime (rathe

Re: Semantics of circular imports

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]: > The use of "top-level" to refer to definitions within a module is > somewhat confusing to me. I usually understand "top-level" to refer > to > the kind of interactive REPL environment for which R6RS leaves the > semantics unspecified. R

Re: Semantics of circular imports

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]: > (Also, what is a "compilation unit" in Guile? Is it ever something > other than a single module corresponding to a single file > (potentially using `include` to incorporate other files at expand > time?) (the following explanation ignor

Re: Semantics of circular imports

Philip McGrath schreef op zo 27-03-2022 om 10:12 [-0400]: > In the context of Racket or R6RS modules, where the semantics are > essentially those of `letrec*`, I'm used to distinguishing "unbound" > variables from "undefined" variables, two types of errors, though > informally "defined" is often u

Re: Hardened toolchain

zimoun schreef op ma 21-03-2022 om 14:34 [+0100]: > > * gcc can be compiled with `--enable-default-ssp --enable-default- > > pie` > > to enforce ssp and pic > > You wrote [1]: > > --8<---cut here---start->8--- > (define-public gcc >   (package >     (inherit gc

Re: using srfi-189 in (gnu services configuration)

Attila Lendvai schreef op ma 28-03-2022 om 14:35 [+]: > this is a follow up to: using an SRFI that is not available in Guile > > https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00249.html > > let me summarize the discussion, and with that my argument why i'd > like to use srfi-189 in

Re: Improving importers best investment for growing gnu/packages/

Brendan Tildesley schreef op di 29-03-2022 om 10:50 [+1100]: > For example grepping build files it can be determined if pkg-config is used > and add it to inputs. an index of .pc files can automatically detect and add > the inputs a package is most likely looking for Not sure what the cargo equiva

Re: The Shepherd on Fibers

Philip McGrath schreef op ma 28-03-2022 om 20:14 [-0400]: > Maybe it would be enough for this case for Fibers to provide variants of > `dynamic-wind` and/or `call-with-continuation-barrier` that cooperate > with the Fibers implementation. I don't know if that would be possible > of not—in additi

Re: The Shepherd on Fibers

Zhu Zihao schreef op di 29-03-2022 om 18:13 [+0800]: > IMO the problem is not fork, you can't do anything useful to create > subprocess without fork on *NIX systems. > > fork is allowed to execute in multi-thread environment. It just don't > care about other threads, it's safe and recommended if y

Re: The Shepherd on Fibers

Ludovic Courtès schreef op di 29-03-2022 om 14:50 [+0200]: > Which socket file? The socket created by 'open-server-socket', used by 'herd stop' and the like. Greetings, Maxime. signature.asc Description: This is a digitally signed message part

Re: The Shepherd on Fibers

Ludovic Courtès schreef op di 29-03-2022 om 14:50 [+0200]: > Maxime Devos skribis: > > > What if 'exec-command' in 'fork+exec-command' fails?  Is it still the > > case that the exception bubbles up, eventually causing the socket file > > to be delete

Re: A lexical use-modules?

Maxime Devos schreef op za 26-03-2022 om 20:21 [+0100]: > (define-syntax use-module/lexical >   ;; todo: integrate into (use-modules ...)? >   (lambda (s) >     (syntax-case s () >   ((_ foo) >    (let* ((module-name (syntax->datum #'foo)) >  

Re: The Shepherd on Fibers

Ludovic Courtès schreef op di 29-03-2022 om 14:48 [+0200]: > Maxime Devos skribis: > > > To help translators, I would use positional arguments in > > > > + (l10n "Accepted connection on ~a from ~:[~a~;~*local process~].") > > Hmm so how would you

Re: lxc and subuid

Antonio Carlos Padoan Junior schreef op wo 30-03-2022 om 08:51 [+0200]: > Hello, > > I'm trying to figure out how to set a unprivileged container using lxc > in guix. I do not know either how to allocate subuid/gid space in guix, subuid/gid are _not_ unprivileged. They are an userspace feature b

Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Hi guix, Quite some packages in Guix use the Autotools system. In this system, a 'configure.ac' and 'Makefile.am' script / makefile is written, from which 'autoconf' & 'automake' generate a very long bash script and a Makefile.in. Depending on the maintainer of the upstream package, this 'config

Re: lxc and subuid

Antonio Carlos Padoan Junior schreef op wo 30-03-2022 om 15:13 [+0200]: > Thanks Maxime, > > > Maxime Devos writes: > > > Antonio Carlos Padoan Junior schreef op wo 30-03-2022 om 08:51 [+0200]: > > > Hello, > > > > > > I'm trying to fig

Re: The Shepherd on Fibers

Ludovic Courtès schreef op wo 30-03-2022 om 17:14 [+0200]: > > (format #t "Accepted connection on ~0@*~a from ~1@*~a." "foo" > > "bar")) > > Hmm that doesn’t seem to work: > > --8<---cut here---start->8--- > scheme@(guile-user)> ,use(ice-9 format) > scheme

Re: Deprecating legacy build phase style when cross-compiling vs. native

Josselin Poiret schreef op wo 30-03-2022 om 17:17 [+0200]: > Following a report on IRC [1] that nss-certs wouldn't cross-build, I > found out that the old syntax of using %output instead of the shinier > $output was still supported only when native-compiling, and not when > cross-compiling, at leas

Re: Deprecating legacy build phase style when cross-compiling vs. native

Josselin Poiret schreef op wo 30-03-2022 om 17:17 [+0200]: > This means that packages that were not updated to fit the new style > should all fail to cross-compile.  This simple bug could be resolved by > adding %output to gnu-cross-build, however as was argued on IRC this is > now undocumented beh

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Liliana Marie Prikler schreef op wo 30-03-2022 om 20:55 [+0200]: > Note that many autotools-based packages already require the addition of > autoconf and friends due to being pulled from git.  That being said, > it's somewhat hard to argue for completely dropping them, because > a. simply matching

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Liliana Marie Prikler schreef op do 31-03-2022 om 06:22 [+0200]: > > It should be possible to look for ‘# Generated by GNU Autoconf’ and > > ‘# Makefile.in generated by automake’ lines in some 'find- > > generated-autotools-fies’or something. > I don't think that will work correctly.  Case in point

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Zhu Zihao schreef op wo 30-03-2022 om 22:31 [+0800]: > It is also burden for > packager to pick the build-time dependencies like libtool, > autoconf-archive, gnulib etc. if we force all autotools baseed > packages use autoreconf Reading 12037 lines of 'configure' and 7896 lines of 'Makefile.in' se

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Zhu Zihao schreef op wo 30-03-2022 om 22:31 [+0800]: > For software developer, they prefer to bundle a generated configure > script because it will be a bootstrap problem sometimes. Sometimes that's convenient for upstream, but how is this relevant to downstream (Guix)? Downstream does not have t

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Zhu Zihao schreef op wo 30-03-2022 om 22:31 [+0800]: > A simple examples,the m4 macro GUILE_PKG defined in guile.m4 helps > autotools to check guile installation. If there's no generated > configure > script. Software user should have guile.m4 to generate configure > script. > A macro that detects

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Zhu Zihao schreef op wo 30-03-2022 om 22:31 [+0800]: > Because you can't track all files that generated by Autotools. You can. Just look for files named 'configure', 'Makefile.in', 'Makefile.in.in', and to reduce false positives, look inside the files for the "Generated by ..." string. Also look

Removing #:skip-build? from the crate importer?

Hi guix, Often, when new rust package definitions are submitted at guix- patches@, I see #:skip-build? #false. Apparently it's added by default in (guix import cargo), with some exceptions. However, ‘(guix)Rust Crates’ states: Care should be taken to ensure the correct version of dependencie

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Liliana Marie Prikler schreef op do 31-03-2022 om 20:24 [+0200]: > > What would not work correctly here? > grep "[Gg]enerated" pre-inst-env I suggest: 1. check that the file name is "configure" or "Makefile.in" 2. and search for "[Gg]enerated by (automake|GNU Autoconf)" 3. If (1) and (2) ma

Re: Removing #:skip-build? from the crate importer?

Liliana Marie Prikler schreef op do 31-03-2022 om 21:07 [+0200]: > Hi Maxime, > > similar discussions have been had in the past, but thanks for raising > them again.  As far as I'm aware, the "consensus" – if it can be called > such – is that due to Rust packages often being a giant nothing burger

Compiling rust things without cargo (super WIP POC)

Hartmut Goebel schreef op do 31-03-2022 om 21:47 [+0200]: since rust does not support anything like static or dynamic libraries, building (intermediate) crates is useless like a hole in my head. Any output on any intermediate crate will just be thrown away. In my experiments, it looks like the r

Re: New review checklist

Liliana Marie Prikler schreef op vr 01-04-2022 om 06:14 [+0200]: > It won't be added to Guix. Here's why it won't. > You appear to believe that > [...] > [ ] hard-coding the commit field is a good idea Does the following count: (define-public foo (package (name "foo") (version "1.0.0")

Re: Autotools-generated 'configure' & 'Makefile.in' considered binaries?

Ludovic Courtès schreef op vr 01-04-2022 om 10:58 [+0200]: > As a first milestone, maybe we could start running ‘autoreconf’ more > often, for packages higher in the graph.  We could change the > ‘bootstrap’ build phase to do that unless it’s explicitly turned off. > It may turn out to be a Sisyphe

Re: Compiling rust things without cargo (super WIP POC)

Ludovic Courtès schreef op vr 01-04-2022 om 11:10 [+0200]: > Overall, I’m afraid Rust packaging is getting out of hands and we’re all > looking elsewhere.  For example, that Rust packages live in their own > separate world means there’s no tooling available, leading to poor QA, a > proliferation of

Re: Compiling rust things without cargo (super WIP POC)

Ludovic Courtès schreef op vr 01-04-2022 om 11:10 [+0200]: > I guess the whole question is whether that technique can be made to work > for the vast majority of Rust packages.  I’d suggest working in that > direction: writing a build system as a first step, using it in all the > Rust packages, and

Re: Deprecating legacy build phase style when cross-compiling vs. native

Daniel Meißner schreef op vr 01-04-2022 om 12:26 [+0200]: > I am also wondering: How are multiple outputs handled with gexps and > #$output? #~(do-stuff #$output:lib #$output:static #$output:bin #$output:doc ...) Greetings, Maxime. signature.asc Description: This is a digitally signed message p

Re: New review checklist

Liliana Marie Prikler schreef op vr 01-04-2022 om 19:03 [+0200]: > Hi Maxime, > > [...] > > > > -- would the commit need to be let-bound here? > This discussion has already been had elsewhere, but to reiterate, my > reasoning is that if you can't trust upstream tags to remain valid, you > need an

Re: Reviewing the diff when updating a package?

Thiago Jung Bauermann schreef op vr 01-04-2022 om 22:59 [-0300]: > Hello Maxime, > > Maxime Devos writes: > > > Patch is not yet ready (I'm looking at the source code diff for > > anything ‘suspicious’), just reserving a bug number and avoiding double > > wor

Re: Getting the name of file-like objects

Justin Veilleux schreef op vr 01-04-2022 om 16:29 [-0400]: > (define (unzip f) >   (computed-file (string-append (name f) "-unzipped") > #~(begin > (system* (string-append #$unzip "/bin/unzip") (unrelated) you can do #+(file-append unzip "/bin/unzip") here. The 'file-append' is not ve

Re: Compiling rust things without cargo (super WIP POC)

Maxime Devos schreef op do 31-03-2022 om 22:06 [+0200]: > As a next step, maybe I could try writing a Guix package definition > for libhello > and hello-oxygen, gradually making things more complicated (macros, > transitive > dependencies, some non-toy Rust dependencies, a Gu

Re: Removing #:skip-build? from the crate importer?

Hartmut Goebel schreef op za 02-04-2022 om 11:45 [+0200]: > [checksum things] > (Maybe the road to go would be to make cargo less strict here. But > this requires understanding rust code and cargo.) FWIW, in an

Re: lxc and subuid

Ludovic Courtès schreef op vr 01-04-2022 om 10:12 [+0200]: > Or we could unconditionally add 65536 subuids for each non-system user > account; that’s what other distros seem to be doing. > > I think we could take advantage of it for ‘guix system container’: it > could run in an unprivileged user n

Building hexyl (a rust app) without cargo, with antioxidant-build-system

Hi, antioxidant-build-system can now be used for some ‘real’ software -- it compiles 'hexyl'. To test, download (commit: d09fd93750ac6d77e0c85623286b45cf5c3b055b) and run "guix build -L . -f guix.scm" and then $ cat guix.scm | /gnu/store/[

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

Brendan Tildesley schreef op ma 04-04-2022 om 15:10 [+1000]: >  I would have called it cargone. >   >  Do you believe sidestepping cargo all together like this is a good > long term strategy?  In particular that importing packages will still > be easy.  The package definitions look almost the same

Re: Excessively energy-consuming software considered malware?

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+]: > > 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 >

Re: Excessively energy-consuming software considered malware?

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+]: > > 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 >

Re: Excessively energy-consuming software considered malware?

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+]: > if you want to dig deeper, then a book titled 'The Machinery of Freedom' > discusses the various alternative forms of financing in more detail > (http://daviddfriedman.com/#mybooks). > I get a: 403 Forbidden openresty for that UR

Re: Excessively energy-consuming software considered malware?

Attila Lendvai schreef op ma 04-04-2022 om 08:00 [+]: > the vast majority of the taxes are not taken from the wealthy, > but from the masses. the well-connected easily pays for the > marginal cost of the tax consultants, lawyers, judges, offshore > entities, and whatnot... and ultimately buy/co

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

Maxime Devos schreef op za 02-04-2022 om 17:18 [+0200]: >   * makes a few assumptions on the source layout (can be fixed >     by using more info from Cargo.toml) This has now been partially resolved. It now looks in Cargo.toml to determine where Rusts's equivalent of 'configur

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

raingloom schreef op wo 06-04-2022 om 00:28 [+0200]: > I'm also a bit worried with the trend of Guix trying to duplicate > functionality already present in language package managers and config > file formats. It creates a two-sources-of-truth situation. For service configurations, there is only on

Re: Building hexyl (a rust app) without cargo, with antioxidant-build-system

Hartmut Goebel schreef op wo 06-04-2022 om 17:49 [+0200]: > [...] > >     * Package definitions can request non-default features to be built > >   anyway. > > > >   A difference from cargo-build-system: features are set in the > >   package of the rust crate, not the package using the

Re: Guix wiki

Attila Lendvai schreef op ma 11-04-2022 om 06:49 [+]: > if someone wants to use guix as a platform for reproducible builds > of go projects (independent of guix revisions), then a package > definitions is needed that refers to specific versions of its > dependencies. > > currently it's not pos

Re: Guix wiki

Attila Lendvai schreef op ma 11-04-2022 om 06:49 [+]: > these names are pretty much independent from each other > (modulo some conventions), and this is an issue for the importers. > more specifically the go importer, that currently needs scheme variable > names to refer to the identified depen

<    1   2   3   4   5   >