Ludovic Courtès writes:
>> I think it would be great if "guix pack -f docker" could avoid building
>> all these identical layers again and again. Perhaps it would be
>> possible to have a single derivation for each layer? This way we
>> wouldn't have to recreate the same layer archives every
Hi Guix,
in the next few months (from June to the end of October 2024) I won't
have much time for computers. Unfortunately, this means that my
projects will stall unless some of you continue them.
There are only three important projects, and one unimportant project:
* maintenance of R, as well
Hi Guix,
a few months ago "guix pack -f docker" was modified to produce layers.
This is great! Unfortunately, "guix pack" itself still produces one big
tarball containing all these layers. There is no sharing of previously
built layers, because they are all hidden inside the pack.
I think it
Jean-Pierre De Jesus Diaz writes:
> I haven't contributed it yet because it has been a bit hard adapting axoloti-*
> packages to use a modern toolchain because I'm also intending to remove
> the old toolchains in `gnu/packages/embedded.scm' eventually and
> instead use the ones in
Richard Sent writes:
> On a related note I recently discovered that issues.guix.gnu.org does
> have a patch-set endpoint that optionally takes a revision e.g.
> issues.guix.gnu.org/issue/70XXX/patch-set/3.
It's not advertised because it was not well tested at the time. I'm
using this script to
Richard Sent writes:
> On a related note I recently discovered that issues.guix.gnu.org does
> have a patch-set endpoint that optionally takes a revision e.g.
> issues.guix.gnu.org/issue/70XXX/patch-set/3.
It's not advertised because it was not well tested at the time. I'm
using this script to
kiasoc5 writes:
>>> Also, there appears to be a couple of FIXUP commits that were pushed.
>> Yeah, it's very annoying that I missed these two FIXUP commits :-/
>>
>
> Seeing that these are the only 2 FIXUP commits on the master branch
> history so far, would it make sense to force push and edit
Christopher Baines writes:
> Ricardo Wurmus writes:
>
>>> These changes from r-updates have effectively jumped the queue past
>>> those on the core-updates and gnome-team branches, and since there was
>>> never a "Request for merging" issue opene
Hi,
> guix-comm...@gnu.org writes:
>
>> rekado pushed a change to branch master
>> in repository guix.
>>
>> from 2bea3f2562 gnu: kubo: Unbundle go-cidutil, go-log and go-ipfs-util.
>> new 79c2b32337 gnu: r-with-tests: Update to 4.4.0.
>
> ...
>
>> new 5ad635ec49 gnu: r-job: Update
Ludovic Courtès writes:
> At this point I think defaulting
> to /var and /etc would do more good than harm.
Are those the only defaults that should change? These are the only ones
we are actively using, but perhaps it would be confusing to have
--prefix still point to /usr/local whereas
Hi Guix,
for the past weeks the "master" branch has been in pretty poor state
according to ci.guix.gnu.org. It keeps hovering at around 56% progress,
which is a far cry from the 80+% we used to have in the old days.
A lot of packages are in fact broken. Many more are marked as broken
due to a
Nicolas Graves via "Development of GNU Guix and the GNU System distribution."
writes:
> Is there an interface to rewrite / update a field from a series of
> packages easily?
We have "update-package-inputs" in (guix upstream), which defines a
local procedure "update-field". Perhaps you can use
Adam writes:
> As I see, first guix pull running too long for a lot of people.
Note that this is not due to download speeds but often due to
compilation. When updating Guix you are not just fetching new data, but
a new version of Guix itself (which happens to come with a library
encoding
> TL;DR :
> - patch series in big progress, not done yet because I don't really
> know where to stop and massive rebuilds.
Please take a look at the python-team branch, which contains changes to
the build system.
--
Ricardo
Hi Juli,
> I am happy to announce that this grant application was approved! [2]
Congratulations!
> Materially, it would allow Shepherd dæmons running on
> different machines to securely communicate and interact with each
> other, going so far as to control one machine's dæmons from another
>
Hi Simon,
> So I propose to add the plumbing command ’derivation’. Any objection?
I think it's useful to have. To avoid proliferation of sub-commands, do
you think we could put this under "inspect", a generic sub-command for
all sorts of as yet to be invented introspection tools?
--
Ricardo
[resending as a wide reply, sorry]
Felix Lechner writes:
> Hi Ricardo,
>
> On Sat, Apr 06 2024, Ricardo Wurmus wrote:
>
>> Any ideas what might be going on here?
>
> Could it be "ModuleNotFoundError: No module named 'jupyter_server'"?
I don't think so.
Hi Guix,
on the python-team branch I'm slowly fixing build errors, but I can't
figure out what's wrong with python-notebook:
https://ci.guix.gnu.org/build/3872654/details
Nothing big changed that would explain the build failure. It looks like
the notebook server doesn't start and all the
[mu4e must have changed the key bindings for replies, so here is my mail
again, this time as a wide reply.]
Giovanni Biscuolo writes:
> So AFAIU using a fixed "autoreconf -fi" should mitigate the risks of
> tampered .m4 macros (and other possibly tampered build configuration
> script)?
>
> IMHO
Tomas Volf <~@wolfsden.cz> writes:
> On 2024-03-29 13:39:59 -0700, Felix Lechner via Development of GNU Guix and
> the GNU System distribution. wrote:
>> > Is there a way we can blacklist known bad versions?
>>
>> Having said all that, I am not sure Guix is affected.
>>
>> On my systems, the
raingl...@riseup.net writes:
> On 2024-03-21 22:44, Edouard Klein wrote:
>> Dear Guixers,
>>
>> I'm a huge fan of guix --container, and I created a system to use those
>> by default for network services. But the VPS these services run on has
>> only 2GB of RAM, and I just realized that a
Hi David,
> after seeing that ROCm packages [1] are available in the Guix-HPC
> channel, I decided to try and package PyTorch 2.2.1 with ROCm 6.0.2.
Excellent initiative!
> For this, I first unbundled the (many) remaining dependencies of the
> python-pytorch package and updated it to 2.2.1,
Luis Felipe writes:
> https://gitlab.com/nonguix/nonguix/-/issues/317
>
> That page also mentions the reasoning behind the derivative logo.
>
> I don't see any issue if Nonguix uses such a logo (specially variant
> D2), but what do you think about it? They don't want to upset the GNU
> Guix
Hartmut Goebel writes:
> In both cases I need some tooling to fetch the current bug-fix version
> of the series in question. This can not be done using "guix refresh"
> only AFAIU, as this would use the next release-series if this is
> already released while our packages are not yet updated.
Gábor Boskovits writes:
> Continue rewrite build daemon in Guile Scheme
> Ludovic Courtès (civodul)
Since this is an ongoing NLnet project I think we should not offer it as
a GSoC project this time.
--
Ricardo
Hi Hartmut,
> I'm currently updating Tryton to version 7.0 and am wondering whether it's
> better to contribute the change to Guix or to set up a
> channel for Tryton.
>
> WDYT? I'm eager to learn about your thoughts.
>
> Here is why I'm wondering:
>
> * Tryton consists of a client, a server
Attila Lendvai writes:
>> WDYT? I'm eager to learn about your thoughts.
>
> the patch inflow to the guix repo is currently overwhelming the
> available capacity for review and pushing.
With an email like the one sent by Hartmut we can better arrange for
shepherding this large submission.
Antoine Eiche writes:
> Ricardo Wurmus writes:
>
>> We have "guix pack" as part of Guix. It builds Docker or squashfs
>> images as well as various other formats. What does nix2container offer
>> beyond what we have?
>
> I acutally don't kn
Antoine Eiche writes:
> In case you would like to try nix2container with Guix, in theory, you
> would need to add the support of another input reference graph format
> [6] and a write simple Guix derivations [7] calling the nix2container
> binary.
We have "guix pack" as part of Guix. It
Hartmut Goebel writes:
> Using a custom function "extend":
>
> (native-inputs
> (extend %standard-trytond-native-inputs
> trytond-account-invoice
> trytond-purchase
> trytond-sale))
We have a macro called MODIFY-INPUTS, which you could use, but
Janneke Nieuwenhuizen writes:
> I'm wondering though what the net gain of minification is
> with current bandwiths. On the few sites that I use javascript on I just
> ship the preferred readable code.
JavaScript libraries can weigh several megabytes unminified. With
minification applied to
Hi Ludo,
thanks for getting the discussion started. This problem has been
weighing on me for the past months and I don't see a good way forward.
Ludovic Courtès writes:
> For the record, glibc maintainer Carlos O’Donell brought up our use case
> a while back on the glibc mailing list but it
Hi Guix,
I have a little i686-linux laptop to which I deployed the Sugar desktop.
The only user account on that laptop (other than root) has no Guix
profile.
I switched to that user account and ran “guix package -d”. Here is what
happened:
--8<---cut
Hi,
I noticed that Cuirass bundles minified JavaScript. I’ve started a new
branch that replaces the minified JavaScript with readable source code
and minifies the files as part of the build.
I also tried to remove the need for jQuery, at least in our own
JavaScript code. (Datatables.js still
Efraim Flashner writes:
> As far as tracking back from git-annex to ghc to see that it's not
> supported on aarch64, I'm not sure how you would find that information.
You can try this in guix repl:
--8<---cut here---start->8---
(import (srfi srfi-1)
"jgart" writes:
> Hi Guixers,
>
> `guix refresh --update` removes Tex Dependencies that are needed. This makes
> it more tedious to update packages :(
“guix refresh” considers the importers’ output to be authoritative. Can
the Python importer be improved to discover the need for TeX things?
Hi Josselin,
>>> b4/lei is a nice example (we already have yhetil.org as a back-end,
>>> but maybe a more blessed one would be better) of a tool that lets you
>>> completely automate applying a patchset to a branch.
>>>
>>> patchwork is a nice tool to gather up and track patchsets, with status
Hi Felix,
> I also packaged and deployed on GNU Guix
>
> (A) the fifteen-year old Debbugs version deployed at gnu.org [2][3][4]
> (B) the modern Debbugs version deployed at debian.org [5][6][7]
> (C) and a custom version of Mumi for my own bug fixes [8][9]
>
> Together with the official
> for an average unix user a service is a process that is running in the
> backgroud, doing stuff mostly without any user interaction. you can
> try to argue this away, but i'm afraid that this is the state of
> things.
I don’t think it’s a good idea to aim to satisfy some presumed “average
Hi Maxim,
> I'm not in the Python team, but I thought I'd give some feedback on
> recent Python packages added.
>
> guix-comm...@gnu.org writes:
>
>> gnu: Add python-docspec.
>>
>> * gnu/packages/python-xyz.scm (python-docspec): New variable.
>>
>> Change-Id:
Justin Veilleux writes:
> Hi everyone. I was thinking about the propagated-inputs field in package
> definitions. As I understand it, it is useful as a way to replace RPATHs
> in packages that aren't compiled or don't support them.
>
> I was reading the documentation on
>
Felix Lechner via "Development of GNU Guix and the GNU System distribution."
writes:
> In Debian, test prerequisites are annotated awkwardly with in
> the build prerequisites. (I think Guix calls them native-inputs.) You
> can see some of Debian's funny notations here [1] and here. [2]
Sharlatan Hellseher writes:
> It might be addressed to rust/python teams.
> https://github.com/pydantic/pydantic-core
>
> During update of some packages from (gnu packages astronomy) I've faced with
> requirement for the fresh version of pydantic which
> depends on pydantic-core built with
Nguyễn Gia Phong writes:
> [[PGP Signed Part:Undecided]]
> [1. text/plain]
> On 2023-12-26 at 15:56+01:00, Ricardo Wurmus wrote:
>> On 2023-12-26 at 14:53+01:00, Sergey Trofimov wrote:
>> > - adding it to guix increases maintenance burden: new versions
>> > c
Attila Lendvai writes:
> if you demand that e.g. all services accepted into guix have a
> configuration entry for every possible config field, and that the
> documentation of these fields are duplicated into the guix
> codebase... then whatever is included into guix will have a 100%
>
Sergey Trofimov writes:
> - adding it to guix increases maintenance burden: new versions could
> add or remove config options
This is why there should be automated tests. There are too few of them.
> - it requires documentation/translation, another hidden cost
We should only accept
Attila Lendvai writes:
> is that a bug in (gnu packages embedded)? shall i look into fixing it?
>
> or am i the one who has invalid expectations?
FWIW I have successfully been using
make-arm-none-eabi-nano-toolchain-4.9 with the Axoloti DSP board (via
the axoloti-patcher package). The 2018
Hi Simon,
> Well, more than 7 weeks later… Hum, does it mean that the Guix project
> is not interested in formalizing some RFC?
>
> WDYT about the proposal?
I just got back from travels and finally caught up with important email.
I read the proposal and it looks good to me. Thank you for
Ricardo Wurmus writes:
> I would like to compute a derivation for a profile specified by a
> manifest. I do not (yet) want to actually build that derivation.
“guix build -d -m manifest.scm” also doesn’t quite do what I want. It
returns the derivations for all the listed pa
Hi Guix,
I would like to compute a derivation for a profile specified by a
manifest. I do not (yet) want to actually build that derivation.
This seems like a simple thing to do, but I haven’t been able to
accomplish this. Here is one of the things I’ve tried in “guix repl”:
jbra...@dismail.de writes:
> I would like to pay $5 a month to have an xmpp account
> coolawesomeusern...@guix.gnu.org
>
> Are there other interested parties? It might be a possible way to generate
> $$ to continue developing guix.
I’d rather not commercialize stuff like this, especially
Attila Lendvai writes:
> i myself also had headaches multiple times when i fixed something that
> needed to touch several different packages, and they would only work
> when applied in one transaction:
>
> how many debbugs issues? multiple issues and record the dependencies?
> little gain for
Felix Lechner via "Development of GNU Guix and the GNU System distribution."
writes:
> While executing meta-command:
> error: label: unbound variable
>
>> ,reload
>
> While this gives
>
> While executing meta-command:
> unknown file name for module #
>
> Also, what is a meta-command, please?
Attila Lendvai writes:
>> I guess "required" here means that in some cases Guix's policy is to
>> prefer small commits over buildable commits (with the previous
>> definition). I at least don't see any technical reasons why it would be
>> required. The question then becomes whether that policy
Ludovic Courtès writes:
> That said, I wonder if this would really be more convenient than SSH’ing
> into the target machine and running the commands right there. Perhaps
> I’m missing something about the use case?
The use case is to have a development host where packages are built and
then
Hi Guix,
to me the biggest downside of using “guix time-machine” is that it has
to do a lot of boring work before the interesting work begins. The
boring work includes building Guix derivations for the given channels,
most of which have long been collected as garbage on ci.guix.gnu.org.
It
Luis Felipe writes:
> El 26/10/23 a las 14:03, Luis Felipe escribió:
>> El 25/10/23 a las 21:17, Julien Lepiller escribió:
>>> The print service I usually use has a lot of options for flyers,
>>> {10,15,20,30}*{10,15,20,30}, 12*12, 21*29.7 and 30*40 cm. I think
>>> 15*20 would be best.
>>>
>>>
Hi Felix,
> On Wed, Nov 01 2023, Ricardo Wurmus wrote:
>
>> What do you think about changing “guix package” and/or “guix copy” to
>> better support deployment of remote profiles?
>
> As someone who uses 'guix deploy' all the time. I believe remote
> administration i
Hi Guix,
I build software locally and deploy the result to a remote system with
“guix copy”. This works pretty well but has a few rough edges:
1. “guix build -m manifest.scm” does not generate a profile. It only
builds the list of packages. To build a profile from a manifest file we
need to
Hi,
In (cuirass base) there is this definition:
--8<---cut here---start->8---
(define (exception-reporter . results)
"Return an exception handler that reports the exception on the error port
and returns the values RESULTS."
(lambda (key . args)
Simon Tournier writes:
> +concerns are actively resolved with proposals that work for everyone. A
> +contributor (which may or may not have commit access) wishing to
Should be “who” instead of “which”.
> +understand its finer details, you are encouraged to read
>
Maxim Cournoyer writes:
> All in all, I guess my position is unchanged: despite the potential for
> surprises, automating and enforcing these configs provide benefits that
> outweigh the cons, in my experience/opinion.
I concur.
In light of efforts to reduce cognitive overhead, I think it is
Hi,
> 2018-01-17 · website: say what Guix is at the very top
> https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00232.html
Hey, that’s me! Naturally, I do agree that we need clearer product
differentiation and your drafts are pretty and clear as always.
On the other hand I’ve always
Emmanuel Beffara writes:
> De Nicolas Goaziou le 09/10/2023 à 16:03:
>> Emmanuel Beffara writes:
>> > I do want to contribute to a solution, because right now texlive is
>> > practically unusable in Guix.
>>
>> FWIW, I use modular TeX Live regularly, so "unusable" is probably a bit
>>
"jgart" writes:
>> These are the 7 packages:
>
> I didn't get that output from `./pre-inst-env guix refresh -l
> sbcl-enhanced-eval-when`
>
> I get the following:
>
> [jgart@fedora guix]$ guix refresh -l sbcl-enhanced-eval-when
> Building the following 1 package would ensure 7 dependent
"jgart" writes:
> make -j6 && ./pre-inst-env guix refresh -l sbcl-enhanced-eval-when
>
> I don't see 7 dependent packages that would be rebuilt... Just three.
>
> Building the following 1 package would ensure 7 dependent packages are
> rebuilt: cl-definitions-systems@2.0.1
These are the 7
"jgart" writes:
> I've experienced this same issue with quite a number of Python
> packages that I've tried to import though...
Yes, this indicates a defect in the importer.
--
Ricardo
"jgart" writes:
> guix refresh -u does some weird stuff. See the git diff below.
>
> Why did it remove the native inputs?
Because Faker doesn’t list them in a way that the importer can add them.
The quality of the importer determines the quality of the updater. The
updater only does what the
Adam Faiz writes:
>> The last message in that issue discussion is mine:
>
>>FWIW M-x guix-installed-packages (and all the other stuff) works for me
>
>> Is it *actually* broken? If it is and you can provide information on
> how to trigger the broken behavior we might be a step closer to
Adam Faiz writes:
> 4. Emacs-Guix, currently broken (https://issues.guix.gnu.org/55013)
The last message in that issue discussion is mine:
FWIW M-x guix-installed-packages (and all the other stuff) works for me
Is it *actually* broken? If it is and you can provide information on
how to
Christopher Baines writes:
> PackagingCon [1] is happening in Berlin on the 26th to the 28th of
> October […]
> Is anyone else planning to attend these events, or otherwise interested
> in meeting up in Germany around these dates?
I don’t seem to have anything planned around the time of
Nathan Dehnel writes:
> I feel there should be a "guix manual" command that opens the latest
> version of your local copy in a new tab of whatever your XDG web
> browser is
Across the wider GNU system the command for accessing manuals is “info”
followed by the name of the manual, e.g. “info
Csepp writes:
> Ricardo Wurmus writes:
>
>> Nathan Dehnel writes:
>>
>>> heard about guile-studio, but it doesn't appear to have a dark mode,
>>> and I imagine trying to add one would require a bunch of emacs-style
>>> screwing around with it
Ricardo Wurmus writes:
> Nathan Dehnel writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
&g
Ricardo Wurmus writes:
> Nathan Dehnel writes:
>
>> heard about guile-studio, but it doesn't appear to have a dark mode,
>> and I imagine trying to add one would require a bunch of emacs-style
>> screwing around with it.
>
> M-x modus-themes-toggle RET
>
&g
Nathan Dehnel writes:
> heard about guile-studio, but it doesn't appear to have a dark mode,
> and I imagine trying to add one would require a bunch of emacs-style
> screwing around with it.
M-x modus-themes-toggle RET
i.e. hold Alt, press x, then type “modus-themes-toggle” and hit the
Hi,
> I was recently inspired from Nix's oci-container feature and wrote a thin
> wrapper around the docker CLI to enable the management of
> docker containers through Shepherd [0]. This enables handling of non packaged
> services through guix system reconfigure and herd
> start/stop/status .
MSavoritias writes:
> On 9/20/23 11:45, Nguyễn Gia Phong via Development of GNU Guix and the
> GNU System distribution. wrote:
>> On 2023-09-20 at 10:21+02:00, Csepp wrote:
>>> It's better if we have at least one *well documented* developer setup,
>>> than if we have a bunch of (sometimes
Simon Tournier writes:
>> Of course the Swineherd is also available as a Guix package called
>> “swineherd”.
>
> Hum, I did (or adding guile):
>
> guix time-machine -q -- shell swineherd
>
> Then I do not know what to do. What are the basic steps for testing it?
There are no executables.
Fannys writes:
>> But again, even if this is a great option for you, it might be a really bad
>> option for some other people. Everybody does not have the time to spend
>> learning emacs, or other specific tool. It's ok if the workflow suggests that
>> but it's not great if we have no other
MSavoritias writes:
> Simon Tournier writes:
>
>> Hi,
>>
>> On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote:
>>
>>> Do you know if there are any plans to write a scheme bug/patching
>>> system? Because looking a bit into it, it doesn't seem like its that
>>> actively developed so maybe we
> Can you share any ways you're currently using this?
We had been using this at work as part of a much bigger training
platform to launch customizable (but still reproducible) interactive
environments for workshops and courses.
An example is pre-configured RStudio installations with shared
Hi there,
you know the Shepherd: it is an elegant service manager looking after a
herd of daemons. Since it can be extended with Guile, I decided to do
just that to add an extra skill to the Shepherd, turning it into the
Swineherd.
The Swineherd is a manager of Guix System containers. It is
Giovanni Biscuolo writes:
> AFAIU mumi does not (still?) have ad authentication/authorization,
> right?
>
> If so how do you plan to deal with users posting SPAM or similar
> unappropriate content?
It only sends email on behalf of commenters, so we’re using the same
email mechanism to deal
Simon Tournier writes:
> On Fri, 08 Sep 2023 at 17:27, Ricardo Wurmus wrote:
>
>> Now, this is no longer a problem for me because I’ve been writing so
>> many commit messages over the years (and because I no longer try to
>> adhere to some poorly specified format
Liliana Marie Prikler writes:
>> Must we force a single workflow on everyone, even if our track record
>> in reviewing and merging doesn’t clearly show that our way is
>> superior?
> Again, define superior.
No, I won’t. I think it’s obvious that our review process isn’t working
*well*. So
Liliana Marie Prikler writes:
> Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
>> I have the same positive view on our faux ChangeLogs commit messages,
>> though I also would like to have them generated. The benefit is
>> still there: I still get to
Liliana Marie Prikler writes:
>> On Github, Pull Request branches are like our WIP branches. They are
>> how we arrive at acceptable changes. Picky people like me would then
>> go back and write new atomic commits for the effective diff, but in
>> my role as a reviewer I usually rebase,
Giovanni Biscuolo writes:
> […] actually Debbugs or Mumi web
> interfaces are read-only: you cannot open a bug report or comment it,
> you have to send an email; this is a _feature_, not a bug since we don't
> need a _complex_ web based authentication+authorization system for bug
>
"jgart" writes:
> What is the cadence for merging the python-team branch into master?
>
> Should you do it, me, or someone else?
Another thing that needs fixing is sphinx. The upgrade of
python-pygments and python-sphinx did not go over too well.
--
Ricardo
Liliana Marie Prikler writes:
> To be completely honest, mumi recalling everything at 0 precision is my
> biggest pet peeve at the moment
Can you please make a test case for this and add it to the mumi tests?
We have tests for the search feature there.
--
Ricardo
Maxim Cournoyer writes:
> I used to think the same about ChangeLogs style commit messages, but I
> have to admit that it forces some discipline on me by having me review
> my changes in details and write out what I did. It'll sometimes expose
> something that'd be better kept in a separate
Liliana Marie Prikler writes:
>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is
Josselin Poiret writes:
> Regarding the “mom argument”, I would disagree and say that this is
> completely related: interruptions are more costly, you're more likely to
> have less attention span, and overall you probably don't want to commit
> to 20 steps just to send a contribution.
That’s
Giovanni,
> You are obviously free not to contribute your patches upstream but the
> fact that you decided not to because it's "too hard" (my executive
> summary about your complaints about Change Log content rules) to write
> commit messages suitable for contribution it _not_ a Guix
Maxim Cournoyer writes:
> Hi,
>
> Ricardo Wurmus writes:
>
>> "Danny Milosavljevic" writes:
>>
>>> I agree that automating the technical steps of contributing to Guix
>>> would be nice.
>>
>> We could provide a VM. Guix
Maxim Cournoyer writes:
>> I’ll say that many of my gripes with (the GNU instance of) Debbugs are
>> due to the fact that we can’t customize it to better suit our needs — it
>> is a shared resource with a complicated maintenance story. So all
>> changes went into Mumi as crude workarounds. I
"Danny Milosavljevic" writes:
> I agree that automating the technical steps of contributing to Guix
> would be nice.
We could provide a VM. Guix can create systems well enough to make this
feasible, I think.
> This definitely should be automated. Why not generate a UUID locally and send
> a
Vagrant Cascadian writes:
> The only thing clunky about this particular aspect of the workflow
> described is the fact that the guix community (maintainers?) have
> decided on a one patch per mail policy with a cover letter, rather than
> submitting the patches as attachments in the initial
Csepp writes:
> I'll try to pick up the Sourcehut
> packaging, now that I know there is a chance it would be accepted.
Excellent. Thank you!
I started work on the issue tracker a while ago, but only had enough
time for the first two packages which are in gnu/packages/sourcehut.scm.
--
1 - 100 of 3744 matches
Mail list logo
