Re: GitLab to plans to delete dormant projects

On 06-08-2022 15:08, Olivier Dion via Development of GNU Guix and the GNU System distribution. wrote: Hi, Following this article, GitLab is planning to start deleting project that were idle for > 12 months. Many packages origin in Guix use an url to a GitLab

v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

Here's a v2. I've changed the structure to something close to what Julien proposed, it looks a lot better now to me! The (^) should probably be tested before the final version. I don't think the list of 'guiding principles' is worded well, probably needs more work. [something I wrote

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

Currently writing a v2 with a structure like Julien proposed. Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 05-08-2022 05:23, Philip McGrath wrote: On Sun, Jul 24, 2022, at 11:17 PM, Maxime Devos wrote: * Patches must not be used to remove non-free files, because a patch by construction contains the non-free file itself so the patch would be non-free, which would not be acceptable to Guix

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 05-08-2022 05:38, Philip McGrath wrote: On Sun, Jul 24, 2022, at 11:17 PM, Maxime Devos wrote: * In principle, you can apply a patch from a phase. However, this causes the result of "guix build --source" to not correspond to the actual source code anymore (i.e., it d

Re: Strategy for Zig packages

FWIW I was commenting on the impossibility of dynamically linking Zig libraries that uses comptime. It doesn't make a difference, AFAICT my explanation on why it can work holds equally for static as for shared libraries. On 03-08-2022 05:35, mcsi...@disroot.org wrote: Compile-time execution

Re: Strategy for Zig packages

On 02-08-2022 07:21, mcsi...@disroot.org wrote: Zig source files could be handled in the same manner as C headers however, and be used as native inputs, so downstream can still update a library for all dependees at once. Going for native-inputs and not non-native sounds incorrect when

Re: Strategy for Zig packages

On 02-08-2022 07:21, mcsi...@disroot.org wrote: On Mon Aug 1, 2022 at 10:43 PM +0200, Mája Tomášek wrote: More realistic (imo) is that zig should be encouraged to build dynamically linked packages, not static ones, and allow the ability (with their future package manager) for the distribution

Re: Strategy for Zig packages

On 01-08-2022 22:43, Mája Tomášek wrote: But I understand it wouldn't be popular, locking an independent language into the guix ecosystem. They could consider multiple package managers and distros (e.g.: Guix support, Debian support, vcpkg support, ...) according to what users of Zig are

Re: developing javascript with guix

TL;DR: I disagree with many of the claims, I agree that some documentation using specific examples is useful, I disagree that this isn't what we are already doing in the Guix manual, I agree that we don't have per-language landing pages yet and that they could be a convenient starting point, I

Re: developing javascript with guix

On 28-07-2022 01:15, Ryan Prior wrote: Is there really a use case for shipping the source code of a JavaScript library without the interpreter? Yes -- see "guix build --source" (it's not JavaScript-specific). If you meant the _compiled_ JavaScript library (result of "guix build node-...")

Re: developing javascript with guix

On 28-07-2022 01:15, Ryan Prior wrote: Why isn't node a dependency for node-mersenne though? It is. node-mersenne uses node-build-system, which has node (or node-lts, dunno) in its implicit inputs. Did you mean: 'Why isn't node propagated?' For the same reasons as why any plugins don't

Re: developing javascript with guix

On 28-07-2022 01:15, Ryan Prior wrote: At a minimum, can we make `guix shell` warn on stderr if you create a shell with one or more libraries but no interpreter? I suppose, but this isn't `guix shell` specific really, it hold for all users of profiles (including "guix environment", "guix

Re: developing javascript with guix

On 28-07-2022 00:25, jgart wrote: How are users supposed to know to run node and node-mersenne?: They know that, because that was the premise of what they were trying to do: You wrote: "how does a js developer use `guix shell` to load a js line like node-rimraf in a repl currently`: In

Re: developing javascript with guix

On 27-07-2022 02:25, jgart wrote: Should we make a guide for developing with js and guix? For example, how does a js developer use `guix shell` to load a js lib like node-rimraf in a repl currently? This one is not in Guix, so I'll replace it by node-mersenne. There's currently no doc for

Re: Strategy for Zig packages

On 26-07-2022 20:48, Liliana Marie Prikler wrote: 4. Convince Zig maintainers to perhaps maybe not join the ranks of Rust et al. and produce reusable shared libraries? I'd like to clarify that Rust supports shared libraries (*) just fine, it's Cargo that insists on source code. Looking at

Re: nix installed with guix on a foreign distro

On 26-07-2022 08:00, jgart wrote: Hi Guixers, How can we make it easier to install nix with guix on a foreign distro? Guix System has a nix-service-type but there is no such thing on Debian. wdyt This sounds like a question for Nix or Debian people to me, as AFAICT it doesn't concern

Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

On 25-07-2022 07:21, Julien Lepiller wrote: I don't like the wording at all. You're mixing too many things together. Feel free to try to separate the things, but going previous discussions, many tings are important, and they appear all to be inseparable. I think it would be better to first

A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

Context: it's currently a mess:, and at times contradictory * There is policy involving those three, as can be seen from the shepherd mess. * This policy is partially secret, as can be seen by some people treating some things as policy even if it's not in the manual. * Some versions of

Re: xpip install -U 'xonsh[full]'

On 25-07-2022 00:29, jgart wrote: When installing xonsh I get the following after starting: ``` You are currently using the readline backend. For interactive tab-completion, on-the-fly syntax highlighting, and more, install prompt_toolkit by running: xpip install -U 'xonsh[full]' ```

Re: python-pytest in references graph

On 24-07-2022 22:25, Roel Janssen wrote: I'm trying to understand the output of: $ guix graph --type=references python-rdflib | dot -Tsvg -o rdflib.svg Particularly, I'm looking at why python-pytest has an input arrow from python-rdflib, while it's "only" a native-input? I thought the

Re: Guix-devel Digest, Vol 109, Issue 56

On 22-07-2022 19:12, kiasoc5 wrote: We could have packages recommend other packages to make this discovery easier for users, like Arch's opt-depends. This sounds like my previous proposal to me: Alternatively, packages could have an additional set of inputs (development-inputs?) for this

Re: Is Guix suitable for large monorepos?

On 22-07-2022 08:58, Liliana Marie Prikler wrote: 13:43 "... if you are scrupulous about running tests ..." Are you really going to run all the tests from hex0 to node whenever you flip a bit? Chances are no. Also, with some exceptions (e.g. emacs packages and texlive), tests are run by

Re: Is Guix suitable for large monorepos?

On 22-07-2022 08:58, Liliana Marie Prikler wrote: 15:10 "An engineering organization is not a bottom-up kind of thing" (X) Doubt. 15:18 "In a well functioning engineering team, priorities and decisions and effort allocation flow top-down" (X) Doubt. 15:24 "Some sort of top-down organization is

Re: Building, packaging and updating Guix with confidence

On 21-07-2022 18:10, Josselin Poiret wrote: b...@bokr.com writes: Naively: Why does "the" guix daemon per se need root access at all? The main thing is that all files in the store end up being written by the guix daemon user. So if we want the files to be easily substitutable, they'd need

Re: [WIP Patch] Adding an FHS container to guix shell

On 20-07-2022 23:22, John Kehayias wrote: I was thinking mostly of binaries, though I've also encountered code that wanted to read the ldcache (e.g. parsing ldconfig -p directly), for some reason. Do you have an example in the wild? Greetings, Maxime. OpenPGP_0x49E3EE22191725EE.asc

Re: Could Guix System eventually run on top of HyperbolaBSD ? slightly off topic

On 20-07-2022 18:03, Raghav Gururajan wrote: [2] IIUC, HyperbolaBSD (OS) consist of a custom-made kernel and a custom-made userspace, both of which the components are either derived from OpenBSD System or written from scratch. So two things can be explored, *separately*. (A) Guix System with

Re: native-inputs: Go for completeness or minimalism?

On 20-07-2022 10:33, Hartmut Goebel wrote: Hi, shall native-inputs be as complete as possible or as minimal as possible? Background: I just stepped over a couple of packages where upstream requires a lot of code-quality checkers which are not actually run when running the tests. (More

Re: “Building a Secure Software Supply Chain with GNU Guix”

Ludovic Courtès schreef op ma 18-07-2022 om 10:45 [+0200]: > The model here is that users trust authorized committers.  When you > think about it, there’s no way around it, because at the end of the > day, you’re installing software that an authorized committer added to > the channel. FWIW,

Re: “Building a Secure Software Supply Chain with GNU Guix”

Arun Isaac schreef op di 19-07-2022 om 12:51 [+0530]: > > Hi Ludo, > > >    https://doi.org/10.22152/programming-journal.org/2023/7/1 > > This is an excellent read! Are there plans to release this git > authentication system as a separate tool so that other non-Guix > projects may use it

Re: Non-free data in Poppler test suite

Ludovic Courtès schreef op vr 01-07-2022 om 14:57 [+0200]: > Nitpick: it’s not that “the FSDG applies to Guix” but rather the Guix > project chooses to follow the FSDG (info "(guix) Software Freedom"). OOps, I searched for 'FSDG' but not for 'free software distribution guidelines' ... Greetings,

Re: Rust reprodubility -- .rmeta and shadow-rs

> https://issues.guix.gnu.org/50015 I don't think that shadow-rs changes Cargo.toml, so I think that one is a separate issue ... > https://issues.guix.gnu.org/55928 Maybe related, though .rmeta isn't mentioned there so maybe not. Seems debugging information related, so maybe the report at (and

Re: Shall updaters fall back to other updaters?

Hartmut Goebel schreef op do 30-06-2022 om 10:58 [+0200]: > Hi, > > while working on refreshing to a specific version (see > https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00222.html) I > discovered that the updaters fall back to another updater. Is this intended? > > Concrete

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

Small clarification to old discussion: Hello, Ludovic Courtès writes: > Hi! > > Maxime Devos skribis: > >> 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 pac

Re: Non-free data in Poppler test suite

Marius Bakke schreef op di 28-06-2022 om 23:19 [+0200]: > I discovered a potential freedom issue with the Poppler test suite. > Specifically it includes a file with the CC BY-NC-ND (non-commercial) > license: Given that it what (some tests) are based on, this might count as functional data and

Re: Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

Maxime Devos schreef op di 28-06-2022 om 22:13 [+0200]: > Blake Shaw schreef op wo 29-06-2022 om 01:34 [+0700]: > > Which brings up another thing I've been considering working on > thats > > been discussed in the Guix community: the need for click-to-edit > > wiki, writte

Re: Wiki && Re: [feature request] merge sxml->html from (haunt html) into guile?

Blake Shaw schreef op wo 29-06-2022 om 01:34 [+0700]: > Which brings up another thing I've been considering working on thats > been discussed in the Guix community: the need for click-to-edit > wiki, written in Guile. [...] I don't think ‘written in Guile’ has been discussed? Also, I don't see

Re: Dealing with upstream issues

zimoun schreef op di 28-06-2022 om 19:36 [+0200]: > Hi, > > On Tue, 28 Jun 2022 at 18:47, Maxime Devos wrote: > > > It is -- where's the bug report upstream or a fix? > > Upstream [1] does not have a bug tracker, or I am missing it.  See > bug#56285 for tracking

Re: Dealing with upstream issues

zimoun schreef op di 28-06-2022 om 18:25 [+0200]: > My workflow dealing with old bugs is: pick one and read the report (and > the complete thread, if any), then, > >  1. the report provides enough information for reproducing; I try to >     reproduce myself and report more info, and then I try to

Re: Dealing with upstream issues

zimoun schreef op di 28-06-2022 om 18:21 [+0200]: > And… as I wrote [1]: > >     I agree; we cannot fix the world. ;-) In the case of patch#55541, the >     issues of cross-compilation can be reported directly to upstream and >     another Debbugs number could be open. > > 1:

Re: Dealing with upstream issues

en fixed, though--it could be that only > the servers > are more reliable and this code path is thus not currently being > entered. These kind of things are still bugs -- occassionally we see these kind of bug reports pop up, so likely the underlying issue is still there and error handl

Re: Dealing with upstream issues

zimoun schreef op di 28-06-2022 om 13:01 [+0200]: >  Do you think that patch#55541 should be > delayed while submitter has not open an upstream issue? Yes, as mentioned in . Greetings, Maxime. signature.asc Description: This is a digitally signed message

Re: Dealing with upstream issues

zimoun schreef op di 28-06-2022 om 13:01 [+0200]: > Well, from my understanding, the question is: should a perfectly working > and fine submission be delayed because unrelated-to-Guix issues are in > upstream code? This is not the question. The dispute is about: Maxime Dev

Re: guix refresh to a specific version?

Hartmut Goebel schreef op wo 15-06-2022 om 13:34 [+0200]: > Hi, > > I wonder whether this is a way to refresh to a specific version, like > one can import a specific version: > > works: > > guix import pypi trytond@6.2.0 FWIW, this works for the 'crate' importer. Greetings, Maxime.

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 17:23 [+0200]: > Old unsolved bugs are still open.  The cross-compilation of one package is > an issue for sure, but: > >  1. it is not an issue for inclusion in Guix >  2. it has to be solved by people interested by cross-compilation Unfortunately, systematic

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 17:23 [+0200]: > Old unsolved bugs are still open Sometimes they aren't: * https://issues.guix.gnu.org/45828 * https://issues.guix.gnu.org/26705 * https://issues.guix.gnu.org/25719 (exception handling hasn't been cleaned up before closing) *

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 17:23 [+0200]: > You are mixing unrelated topics, IMHO. > > We have policies, not standard. > > «A policy is a set of ideas or plans that is used as a basis for making > decisions, especially in politics, economics, or business.» > > «A standard is a level of

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 17:06 [+0200]: > Do you mean > > --8<---cut here---start->8--- > > +(define-public harec > > +  (let ((commit "bbabe09bddf74bd699f8ad2224fdd6e2eefbd35e") > > (revision "0")) > Despite what (guix style) may tell you, revision

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 14:53 [+0200]: > Maybe I misunderstand the point.  To me, the aim of the package > submission is the inclusion in Guix.  AFAIK, the Guix project is not > applying any standard audit on the upstream code before inclusion. > > Therefore, if the upstream code is

Re: Dealing with upstream issues

zimoun schreef op ma 27-06-2022 om 14:32 [+0200]: > Hi Maxime, > > On Mon, 27 Jun 2022 at 12:37, Maxime Devos wrote: > > > Also, some of those rules are incorrect -- "guix style" occasionally > > makes things wrong and patch submitters had to be told to n

Re: Dealing with upstream issues

Maxime Devos schreef op ma 27-06-2022 om 12:30 [+0200]: > We can ask to do send the notice upstream, if it's in the rules (I > consider this to be part of the unwritten rules). [...] > I also consider them to not be rules as in ‘if they are followed, it > WILL be accepted’ but more gui

Re: Dealing with upstream issues

Ludovic Courtès schreef op ma 27-06-2022 om 12:10 [+0200]: > Regarding the review process, I think we should strive for a predictable > process—not requesting work from the submitter beyond what they can > expect.  Submitters can be expected to follow the written rules¹ and > perhaps a few more

Re: reader macros for hidden packages

jgart schreef op zo 26-06-2022 om 09:43 [-0500]: > > Or a new 'define-public-hidden': > > > > (define-public-hidden python-httplib2 > >    (package > > (name "...") > > ...)) > > I like this idea. You'd implement that as a macro that inserts > hidden-package for the user of

Rust reprodubility -- .rmeta and shadow-rs

Hi, There was some mail about irreproducibility in Rust, but I couldn't find it anymore. Anyway, I found a potential cause: rust-shadow-rs embeds timestamps (even though it nominally respects SOURCE_DATE_EPOCH???) and the ordering of definitions it generates is based on a hash map (and hence,

Re: reader macros for hidden packages

jgart schreef op za 25-06-2022 om 22:27 [-0500]: > Out of curiosity, is it possible to make reader macros like this with guile? > > ``` > @hidden > (define-public python-httplib2 >   (package >     (name "python-httplib2") > [...] > The above would make the package hidden by using

Re: Experimental nar-herder support for serving fixed output files by hash

Christopher Baines schreef op vr 24-06-2022 om 09:10 [+0100]: > [...] > In terms of next steps, there's some things to do with improving the > implementation, but it would be good to hear if this is actually > worthwile? I wouldn't know about the Guix part, but supporting streaming reading

Re: Time namespace for build sandbox (was Re: Set FORCE_SOURCE_DATE=1 by default)

Zhu Zihao schreef op wo 22-06-2022 om 23:16 [+0800]: > > Can we make some experiments on the Linux time namespace for build > sandbox? > > This can mock the real system with our desired value, maybe a good > solution for the reproduciblity on Linux machine. > > Ref:

Re: Teams: first draft list

Josselin Poiret schreef op wo 22-06-2022 om 14:30 [+0200]: > Hello, > > zimoun writes: > > Then maybe, we could hook Mumi and add regexps based on commit messages > > for notifying a specific team.  Well, it is a rough approximation with > > many false-positive but hey the aim is to deal with

Re: how to write services

indieterminacy schreef op za 18-06-2022 om 13:53 [+0200]: > Additionally, based upon a decent demonstration on LMDB, I realised that > my annotation system makes it more feasible to adapt documents into LDIF > database-like-files (is that the correct terminology Maxime?) - > potentially turning

Re: FSDG-compatibility of APSL-2.0

Felix Lechner schreef op vr 17-06-2022 om 13:11 [-0700]: > > If you are already in California, [...], but if you don't and > > simply > > Apple needs to appeal to international > > law enforcement or your country in particular, whichever is easier. > > I generally think of license violations as

Re: PARI/GP and parallelism

zimoun schreef op vr 17-06-2022 om 16:36 [+0200]: > Well, I do not know if the parallel computation of PARI/GP are > reproducible.  But the building of PARI/GP is not; because some > documentation… > > --8<---cut here---start->8--- > $ diff -r --no-dereference

Re: FSDG-compatibility of APSL-2.0

(zimoun pointed out that I didn't actually send this mail, apparently it never left ‘drafts’. Anyway, just sending this e-mail for completeness; unless someone comes with a new insight or something the discussion appears to be done for now.) Philip McGrath schreef op do 16-06-2022 om 02:21

Re: FSDG-compatibility of APSL-2.0

Doesn't seem to reach some kind of consensus, or maybe there's actually some consensus for considering APSL-2.0 acceptable (albeit suboptimal) for Guix but I'm to biased to see it :p, so I suppose continue with status quo (i.e.: allow APSL-2.0)? Greetings, Maxime. signature.asc Description:

Re: FSDG-compatibility of APSL-2.0

Liliana Marie Prikler schreef op vr 17-06-2022 om 12:00 [+0200]: > Am Freitag, dem 17.06.2022 um 11:39 +0200 schrieb Maxime Devos: > > The clause is also rather extra-territorial: what if $local_country > > reforms copyright to make all sofware free, if we accepted ‘go to > &

Re: FSDG-compatibility of APSL-2.0

zimoun schreef op vr 17-06-2022 om 11:06 [+0200]: > [...] How do we resolve the disagreements? By talking on guix-devel. signature.asc Description: This is a digitally signed message part

Re: FSDG-compatibility of APSL-2.0

TBC, did you see my previous mail about cherry-picking and power assymetry. > FWIW, I think that adopting a different (more stringent) license > policy hits two issues: > > 1. Where do you draw the line? Based on which concrete principles > to decide for this or for that? I would like to

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op do 16-06-2022 om 06:20 [+0700]: > But, perhaps it's just getting late and the matters are now & the > details are slipping my mind, but im starting to realize im unsure of > many examples of file-like objects that aren't a file? The email > where you responded re: packages

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > On the contrary, lets say I'm writing an intro book on CT. If I'm > demonstrating something trivial, say the initial object, I'm not > going to refer to it as "an initial-like object" for the sake of > generality. Neither does Guix? If

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > AFAIK no relation to GNU. > > I thought recalled hearing it used in relation to GNU/Linux. A quick > search > brings up this stackexchange discussion[1], which quotes the book > "Linux > Philosophy" with the following: > > #+begin_example

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 21:40 [+]: > > Something I dislike about the ‘file AND file-like objects’ > > construction > > is that it suggests that files and file-like objects are separate > > and > > are handled separately, whereas files (as in, 'local-file' or > > 'computed-file')

Re: how to write services (was: Re: Teams)

Blake Shaw schreef op wo 15-06-2022 om 17:01 [+]: > Thats very good advice and will be a useful guide in refactoring the > parts of the system services documentation. I think in general, we > need to find a nice middle ground between the extremely general and > the immediately sensible, as I

Re: On commit access, patch review, and remaining healthy

Giovanni Biscuolo schreef op ma 13-06-2022 om 11:34 [+0200]: > Maxime I have a question for you please: do you really think that in > the NixOS community Going by the Java example, yes, at least for some of the NixOS community. I've also seen this interpretation of reproducibility in Clojure

Re: On commit access, patch review, and remaining healthy

Giovanni Biscuolo schreef op zo 12-06-2022 om 11:42 [+0200]: > > or have packages with bundled dependencies (e.g. vendored jars). > > bundling binaries it's (is it?) for sure against the definition of a > reproducible build, but what about bundling (source) dependencies? > > AFAIU not to bundle

Re: U.S. Midwest based build farm

jbra...@dismail.de schreef op za 11-06-2022 om 16:06 [+]: > What's good and/or bad about this idea? A positive point: extra resources, could be useful for reproducibility testing, ...? A negative point: extra points through with malware can be introduced (->compromises). Can be solved by

Re: On commit access, patch review, and remaining healthy

Giovanni Biscuolo schreef op vr 10-06-2022 om 14:27 [+0200]: > > - Our synopses and descriptions are not casually copy-pasted from > the > >    project website. We try to rewrite and improve on them if > necessary. > > AFAIK similar requirements are "enforced" by all other distributions They

Re: Repology and outdated packages

Maxime Devos schreef op di 07-06-2022 om 23:32 [+0200]: > In my experience with antioxidant, not-up-to-date Rust toolchains do > not prevent upgrading packages -- in the process of resolving build > failures, I updated some crates.  This never resulted in a ‘you need > an > new

Re: Repology and outdated packages

kias...@disroot.org schreef op di 07-06-2022 om 18:39 [+]: > So without demanding more maintainer time, for now I just convince myself > that: > - key toolchains such as Rust and Go are not always up to date, thus blocking > the > upgrade of several packages In my experience with

Re: Repology and outdated packages

kias...@disroot.org schreef op di 07-06-2022 om 18:39 [+]: > - we package their dependencies separately (eg Rust crates, Go modules), > these are a significant portion of Guix that cannot be constantly updated > easily > - the Guix 1.4 release is coming soon so more time may be spent

Re: Move switch-symlinks to (guix build utils)

Arun Isaac schreef op ma 06-06-2022 om 16:57 [+0530]: > Could we implement symlink/remove-old without catch and throw? Something > like: > > --8<---cut here---start->8--- > (define (symlink/remove-old target link) >   "Make a symbolic link named LINK pointing

Re: Teams

Tobias Geerinckx-Rice schreef op za 04-06-2022 om 14:50 [+]: > I think we should also have (natural) language 'teams' who can be pinged > when, e.g., a news item lands, through a single guix-translators@ meta-alias, > and who can co-ordinate before releases. > > I'll take -nl.  Maxime? Ok

Re: Teams

Ricardo Wurmus schreef op za 04-06-2022 om 14:07 [+0200]: > As a first step I’d suggest collecting teams, setting up the email > aliases, and updating the website to show the existing teams.  Here’s > a draft of three teams: > > [...] You can add me to the Rust team and to a new Minetest team.

Re: Move switch-symlinks to (guix build utils)

b...@bokr.com schreef op za 04-06-2022 om 01:55 [+0200]: > I am not expert on kernel link internals, but if > you need/prefer atomic change to a specific link, > does my log [1] below suggest a way? > [...] Only the replacing of an old by a new symlink needs to be atomic, and this is already the

Re: Move switch-symlinks to (guix build utils)

Ludovic Courtès schreef op vr 03-06-2022 om 18:38 [+0200]: > That’s EACCES? It's EEXIST. > > If we move it to (guix build utils), I'd prefer the bug to be addressed > > first. > > Yes, better be cautious before “setting it in stone”.  Do you have a fix > in mind? Maybe replace (symlink

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: >   * cons: probably not everything of Cargo.toml is implemented yet Another downside: in Cargo-land, the leaf package declares what ‘features’ (= configure flags for enabling things) it requires from dependencies. This works because Ca

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: (b) To get a good grasp on what builds/what not, it would be useful     to build the channel at ci.guix.gnu.org or such.  More concretely,     the CI would grab all cargo-build-system rust apps from (gnu packages ...),     feed them

Re: Move switch-symlinks to (guix build utils)

Arun Isaac schreef op do 02-06-2022 om 20:36 [+0530]: > Hi Maxime, > > > To avoid a world-rebuild, you could for now make a module (guix build > > symlinks) or such?  An alternative is (gnu build activation), but then > > some (guix ...) modules would depend on (gnu ...). > > I don't really mind

Re: A corner case of broken reproducibility

Ludovic Courtès schreef op do 02-06-2022 om 16:13 [+0200]: > I’m not sure what the conclusion of those bug reports were, but (gnu > build accounts) doesn’t reuse UIDs: you can see that in > ‘user+group-databases’, which reads the initial /etc/{passwd,group}, and > passes them to ‘allocate-passwd’

Re: Merging the purge-python2-packages branch

zimoun schreef op do 02-06-2022 om 09:25 [+0200]: > On Wed, 01 Jun 2022 at 22:30, Maxime Devos wrote: > > > > (from [0]) > > > Sunsetting Python 2 > > > [...] > > > We did not want to hurt the people using Python 2. So, in 2008, we > > &

Re: A corner case of broken reproducibility

raingloom schreef op wo 01-06-2022 om 22:41 [+0200]: > Could we instead check for existing homes and set uids in > /etc/passwd based on that instead? That's practically O(1), but is a > bit more involved. For this to work, the home directory may not be changed. As Ludo wrote (albeit about user

Re: Merging the purge-python2-packages branch

zimoun schreef op wo 01-06-2022 om 21:51 [+0200]: > Any user of Guix, scientist or not, can be surprised that their > perfectly working packages are suddenly removed without a period of > grace.  Yes, these packages could have been removed before today since > they are EOL since 2 years.  It does

Re: A corner case of broken reproducibility

Ludovic Courtès schreef op wo 01-06-2022 om 18:38 [+0200]: > There’s a talk by Lennart Poettering where he explains that, contrary to > what one might think, “chown -R $HOME” turns out to be fast enough that > systemd-homed can do that unconditionally (off the of my head). Interesting. Taking

Re: A corner case of broken reproducibility

Ludovic Courtès schreef op wo 01-06-2022 om 18:38 [+0200]: > Things that seem missing here to me: > >    * a mechanism for remembering that an uid is still in use even > though > the user has been removed (previously mentioned solutions: keep > the > uid in /etc/passwd even though it is

Re: Move switch-symlinks to (guix build utils)

Arun Isaac schreef op wo 01-06-2022 om 13:04 [+0530]: > Hi Guix, > > The switch-symlinks function from (guix utils) is often required in > activation-service G-expressions. But, only (guix build utils) and not > (guix utils) is available to such G-expressions. See, for example, the >

Re: antioxidant-build-system can be tested as a channel, + > GTK app 'castor' builds

kias...@disroot.org schreef op di 31-05-2022 om 17:45 [+]: > Hi Maxime, > > > > > Non-goals: > > > > * Produce exactly the same binaries with exactly the same dependencies as > > with > > Cargo. If you want to reproduce a binary produced with Cargo, use Cargo. > > > > If I compile

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Maxime Devos schreef op di 31-05-2022 om 11:27 [+0200]: > (d) Implement support for "cdylib" such that things like librsvg can > be built. Some basic support now implemented in 7040ce32840ba74f948fe9d243e1eb393daec4fc, though probably more remains to be done for librsvg.

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Ludovic Courtès schreef op ma 30-05-2022 om 17:26 [+0200]: [...] To make sure share a common understanding, could you post a summary of:   1. the goals;   2. the status;   3. pros and cons over the status quo and other options (if any!);   4. the next steps. > [...] (notabug.org is down, so I've

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

Gábor Boskovits schreef op di 31-05-2022 om 06:54 [+0200]: > I was thinking about a bit of a different structure that can also be > automated. My original idea was to use the already existing tree > structure of the derivations, and split it based on depth. I think > that gives a bit more

Re: Finding a “good” OpenPGP key server

Ludovic Courtès schreef op ma 30-05-2022 om 17:34 [+0200]: > > (package > >    (name "gnurl") > >    [...] > >    (properties > > ;; Keys that are considered ‘trustworthy’ for signing releases > > ;; of gnurl. > > `((permitted-pgp-signing-keys "CABB A99E ..." "DEAD BEEF ...") > >    

Re: A corner case of broken reproducibility

Ludovic Courtès schreef op ma 30-05-2022 om 17:58 [+0200]: > Perhaps it should forcefully “chown -R” home directories at boot time, > so they have the right UID?  This has been discussed a few times, I haven't seen the "chown -R" suggestion yet in the context of homes (only for system accounts,

Re: antioxidant-build-system can be tested as a channel, + GTK app 'castor' builds

Ludovic Courtès schreef op ma 30-05-2022 om 17:26 [+0200]: > (Unfortunately notabug.org is down since a few days ago.) For now, the fallback location https://github.com/emixa-d/antioxidant-fallback/ can be used. (rest of the response later) signature.asc Description: This is a digitally signed

<    1   2   3   4   5   >