On 10/30/23 10:42 AM, Ludovic Courtès wrote:
Hello Guix!
It’s a bit of a non-event since we’ve been packaging and using snapshots
of Cuirass all along, but nevertheless, I’m totally thrilled to announce
that Cuirass 1.2.0 is out!
Congratulations! It might be my holiday project this year to
On 10/2/23 5:24 AM, Wilko Meyer wrote:
- Where solicitations to complete the survey are broadcast is very
important. E.g. if we only send it to guix-dev, this skews the
responses to questions like "where do you talk about Guix".
Definitely, I'm not entirely sure on how to solve this;
On 9/24/23 1:27 AM, Andy Tai wrote:
Hi, curious if core-updates still a thing?There seems a branch by
that name and the manual still says patches causing large number of
rebuilds should go to core-updates, at least for these not aiming at a
specific feature branch.
I have the same question.
Imran Iqbal writes:
> Personally I don't think its fair to ask Guix to move away from emails
> because folks are more familiar with using web browsers for everything.
Imran, you bring up good points. I wanted to state that I share this opinion:
Guix should not move away from emails.
I view
This is awesome, thanks Wilko!
I've been talking with my wife who is the field of psychology. As part
of her degree, and as part of her ongoing education, she's studied how
to design studies/surveys so that they're not biased and don't produce
contaminated data. She's not an expert at this,
On 9/20/23 4:12 PM, Ricardo Wurmus wrote:
To conclude, I'm not advocating for adding OCI-backed services to Guix
mainstream: in my opinion they should be bootstrapped and
built from source, but I believe the actual "backend" implementation for such
services could be useful to have in Guix.
On 9/13/23 3:06 AM, Ricardo Wurmus wrote:
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
On 9/8/23 2:37 PM, Ricardo Wurmus wrote:
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
On 9/8/23 5:28 AM, Ricardo Wurmus wrote:
Katherine, I’m very happy you brought this up and continue to respond in
this thread to clarify and steer the discussion into a fruitful
direction. I know I couldn’t do it. I thank you for this work, and I
hope that the project can come up with ways to
On 9/8/23 6:40 AM, Giovanni Biscuolo wrote:
Ricardo,
Ricardo Wurmus writes:
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
On 9/11/23 6:19 AM, Giovanni Biscuolo wrote:
If you want I can add a little bit of Italian attitide at discussing in
detail tiny variations of the same thing :-O... just joking, eh! ;-)
One of the reasons I love working with people from around the world is
the delight in discovering that
On 9/6/23 3:07 AM, Simon Tournier wrote:
As you said, we are all different, thus it means that any collaboration
cannot be full-frictionless. Because any social interaction implies
norms and standards. Norms and standards are by their definition
excluding.
For example, we communicate in
On 9/6/23 3:34 AM, Simon Tournier wrote:
Well, from my point of view, the next steps are:
+ Propose a survey (questions), open a new thread (or a bug report) for
iterating.
I'll open a bug report and start logging notes/suggestions against it.
In it, I'll include your points:
+
On 9/5/23 2:43 PM, Liliana Marie Prikler wrote:
Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:
Liliana Marie Prikler writes:
Uhm, we have snippets?
Well, those are exclusive to Emacs :) And without regard to /that/
issue, I do think that there's a problem if the commit format is so
.
OK, great! What are next steps, and how can I help?
On Tue, 05 Sep 2023 at 12:00, Katherine Cox-Buday
wrote:
1. A list of the issues
2. How we'll measure that they're issues
3. How we'll measure improvement against the issues
4. How we'll address the issues
So often in my long career I've
On 9/5/23 4:57 PM, Simon Tournier wrote:
Hi,
On Tue, 05 Sep 2023 at 11:01, Katherine Cox-Buday
wrote:
Well, somehow, I consider the commit message format similarly as coding
style. We can discuss which one is better than the other when at the
end it only reflects some artificial
Thank you for your thoughtful comments, Giovanni!
On 9/2/23 5:16 AM, Giovanni Biscuolo wrote:
1. We should use sourcehut or continue to improve mumi
Please forgive me if I insist, but the one and _only_ benefit of using
SourceHut is the web-UI /helper/ to prepare an email message to send,
On 9/3/23 1:36 AM, Ricardo Wurmus wrote:
Why are we trying to compete with Sourcehut? What's the end goal?
I can’t make myself even clearer about this, but I’ll repeat myself
again: we are not.
“Competition” is a foreign concept to me. Mumi exists only because I
found the Debbugs web
On 9/5/23 8:01 AM, Simon Tournier wrote:
Hi Katherine,
Thank you for your extensive analysis. I concur.
On Wed, 30 Aug 2023 at 10:11, Katherine Cox-Buday
wrote:
3. We should reify a way for Guix, the project, to measure, and track
progress,
against long-term goals. Particularly when
On 9/4/23 7:32 PM, Maxim Cournoyer wrote:
13. Run `guix style` (this is still in the manual although I have since
learned this is not actually advisable).
The intent is for it to be advisable -- when it's not, a bug should
be/have been reported against it to track its resolution.
On 9/5/23 10:01 AM, Simon Tournier wrote:
Well, somehow, I consider the commit message format similarly as coding
style. We can discuss which one is better than the other when at the
end it only reflects some artificial preferences and for the sake of any
project one needs to be arbitrarily
.
On 8/28/23 4:17 AM, Simon Tournier wrote:
> Hi Katherine,
>
> On Fri, 25 Aug 2023 at 19:02, Katherine Cox-Buday
wrote:
>
>> I think there's utility in distinguishing between familiarity and
>> eliminating toil. I think it was incorrect of me to suggest forming
>> ha
On 8/27/23 9:41 AM, wolf wrote:
Sure, golang compiles faster than C++ for example, but anecdotal data point: at
$DAYJOB we had to start persisting the compiler cache to make CI fast enough.
I've seen similar things done at companies. This is perhaps an
interesting avenue to pursue later: if
On 8/25/23 6:29 PM, John Kehayias wrote:
I've not been following in detail this discussion, but where do we currently
stand? Is the proposed Go 1.21 patch basically ready?
As far as I know, yes. I've been using it locally since I submitted the
patch, and things seem to be working as
On 8/24/23 12:53 PM, Simon Tournier wrote:
Hi,
At some point, I sympathize.
On Wed, 23 Aug 2023 at 10:25, Katherine Cox-Buday
wrote:
I don't use the email-based patch workflow day-to-day, so this is
another area where I spend a lot of time trying to make sure I'm doing
things correctly
On 8/24/23 12:33 AM, ( wrote:
* We could support a managed web-based workflow
The problem with this is that it would not be possible without changing
the git hosting entirely to something like Gitea. I'm personally a fan
of the email-based workflow; what, specifically, is it that bothers you
On 8/23/23 9:33 PM, Ahmed Khanzada via Development of GNU Guix and the
GNU System distribution. wrote:
My wife and I are currently trying, so I hope to be a busy parent soon too!
Good luck to you!
The debate comes down to: the people contributing the most code already
have a very familiar
On 8/24/23 6:10 PM, Ekaitz Zarraga wrote:
Lots of important use cases that
Guix could serve are ignored because the people who need them are not
represented in our community and/or they can't contribute and no one is
able/willing to write code for them.
On 8/23/23 6:18 PM, Csepp wrote:
* Contributing to Guix is not for you
I would be really sad if someone ever said this, but I guess it's a
possibility. Maybe someone like me just can't be a contributor to
Guix until
I have the bandwidth to manage all the details. I would
On 8/25/23 3:57 AM, Attila Lendvai wrote:
Otherwise I do not get your point: I keep untreated messages with the latest
patch version in my Guix inbox, and file away the others in a separate mbox.
So things are not flat, but have two levels: "to be treated" or "done".
my point is that in a PR
On 8/23/23 12:03 PM, Andreas Enge wrote:
Hello,
Am Wed, Aug 23, 2023 at 10:27:31AM -0700 schrieb Felix Lechner via Development
of GNU Guix and the GNU System distribution.:
I can't ever seem to get the GNU style commit messages correct.
Neither can I. The style apparently helps with
On 8/23/23 11:27 AM, Felix Lechner via Development of GNU Guix and the
GNU System distribution. wrote:
* Encourage upstream communities like "Guix 'R Us"
Every contributor should have their own channels for packages [1] and
for Guix. [2] Testing patches before they are submitted would vastly
Summary: for people who don't contribute to Guix a lot, each
contribution has
very high cognitive overhead. Can we work to reduce that?
Hey all,
Contributing to Guix is currently pretty difficult for me. I'm a Mom with a
full-time job, and anything outside of my job that requires a lot of
On 8/22/23 8:24 AM, Felix Lechner via Development of GNU Guix and the
GNU System distribution. wrote:
Hi Attila,
On Tue, Aug 22, 2023 at 6:14 AM Attila Lendvai wrote:
currently the go build system in guix does not reuse build artifacts
Can Golang reuse build artifacts?
I don't think it's
On 8/22/23 12:06 PM, david larsson wrote:
Im not a fan of Go, but I've wanted to package some Go packages. Ive
only managed to write 2 packages for my private channel so far, but they
were simple. If there is a guide or so somewhere explaining how to do
this, then maybe I could complete and
On 8/19/23 11:40 AM, Hilton Chain wrote:
Hello Guix,
With the commit [1] made hours ago, I have been granted commit access
to Guix repository.
Congratulations and welcome!
On 8/21/23 11:53 AM, Felix Lechner wrote:
Hi,
On Mon, Aug 21, 2023 at 9:11 AM Katherine Cox-Buday
wrote:
the immediate emphasis should be on making bringing
our Go ecosystem onto a supported version of Go
From my experience of packaging Gocryptfs in Debian and here, perhaps
some
Summary: these are good things to talk about. I think we should focus on
using the current approach to get our Go ecosystem into a supported
state before we talk about these things.
On 8/19/23 5:31 AM, Attila Lendvai wrote:
at one point i tried to compile some large projects written in golang
On 8/17/23 3:54 PM, Wilko Meyer wrote:
That being said, I'd actually be willing to put some time and effort
into Guixes Go ecosystem; even though I haven't been on Guix for that
long and would probably have to read through prior contributions to
golang.scm to get the gist on how the
On 8/16/23 11:25 AM, Felix Lechner via Development of GNU Guix and the
GNU System distribution. wrote:
Hi Katherine,
On Tue, Aug 15, 2023 at 12:59 PM Katherine Cox-Buday
wrote:
There's also no one on Guix's Go team. I've created a patch to add
myself[1]
Your courage and initiative
Hey all,
Our Go ecosystem is currently in need of a lot of love.
* The Go Team
There is currently no branch for Go updates. I know Leo had tried to get
one setup at one point[0] but ran into issues. I'm unclear if they were
ever resolved, but the branch isn't there, and we need one.
On 7/2/23 4:30 AM, Andreas Enge wrote:
So I would suggest to delete every branch right after merging, and then
branch off of master later when a new patch is going to be applied.
This will also create a cleaner history by avoiding a merge.
I disagree with this because it seems like Mesa moves
On 5/11/23 8:44 AM, Maxim Cournoyer wrote:
Hello,
I'd like to welcome Simon (aka zimoun) as a new committer. They have
made many contributions along the years, both in code and in community
management. I'm sure they'll make good use of their new
responsibility/privilege.
Congrats, Simon!
On 5/4/23 11:33 AM, Kaelyn wrote:
Regarding solutions, I would prefer to have libstdc++ in it's own package or
output rather than bundled into gcc-toolchain:out; it feels messy and against
the grain of isolating programs in containers if I have to make the gcc and g++
compilers available in
On 4/25/23 8:40 AM, Felix Lechner via Development of GNU Guix and the
GNU System distribution. wrote:
Hi Andreas,
On Tue, Apr 25, 2023 at 7:09 AM Andreas Enge wrote:
many thanks to
everyone who contributed to the branch, be it by commits, discussions or
by working on the infrastructure.
On 4/19/23 4:48 AM, Andreas Enge wrote:
just a quick update to share good news and to heap praise on people who are
not rewarded by seeing their name in a git commit.
Consider my praise added to the heap (and hopefully not GCed). As
always, I am deeply appreciative to all of our maintainers.
On 3/24/23 6:33 AM, Bruno Victal wrote:
I'd like to propose for field specifications in define-configuration to be
separated with a
blank line between them. Reason for this is that it makes it much easier on the
eyes
to read, rather than being presented with a dense hunk of text to sift
On 2/14/23 1:08 PM, Efraim Flashner wrote:
Also I don't think there's a lot of overlap between go and rust so we
can probably have both going at the same time.
Oh, yes, I didn't mean to imply that the two were related, or
conflicted. I just wanted to point it out in case it was of any help.
Efraim Flashner writes:
> As a project we haven't setup anything for starting the team-based
> branches and upgrades, and the Rust Team volunteers to go first.
Leo has attempted[1] to setup a branch for Go, but we're waiting to hear from
sysadmins on why there's a build error.
[1]
Efraim Flashner writes:
> On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
>> Hi Guix!
>>
>> As discussed at Guix Days before Fosdem, we haven't merged core-updates
>> in a very long time. I'd volunteer to lead this effort, but I don't
>> know what steps I should follow. Do we
Katherine Cox-Buday writes:
> Katherine Cox-Buday writes:
>
>> This is a patch series to add the gopls package.
>>
>> I haven't contributed to many projects which use the e-mail flow, so
>> hopefully I'm doing this correctly. Please feel free to make
>
Katherine Cox-Buday writes:
> This is a patch series to add the gopls package.
>
> I haven't contributed to many projects which use the e-mail flow, so
> hopefully I'm doing this correctly. Please feel free to make
> suggestions if not!
>
> Some of the diffs are a little
Robby Zambito writes:
> Hi,
>
> I remember seeing some details about certain compilers not being
> allowed in Guix due to having an inadequate bootstrapping process, but
> I can't seem to find it right now. I'm looking to write a package for
> the Cyclone Scheme[1] implementation. The compiler
Katherine Cox-Buday writes:
Sorry, I had a bug in my format one-liner which gave versions parenthesis. This
should be copy/pastable:
--8<---cut here---start->8---
scheme@(guix import go)> (for-each (lambda (p) (format #t "gui
Demis Balbach writes:
> Hello, I was wondering what the "correct" way would be to get grammars
> for the tree-sitter library available in Guix when using tree-sitter
> with Emacs 29+.
>
> There is https://github.com/emacs-tree-sitter/tree-sitter-langs, but I
> don't think it has been packaged in
phodina via writes:
> Hi Guix,
Hey Petr, thanks for having a go at packaging this! It would be awesome
to have Grafana in Guix!
I was able to troubleshoot this a little. I agree with the sentiment[1][2]
that the Guix importer should just use Go tooling; however, I don't
think it's at fault
Ludovic Courtès writes:
> Even from a purely practical perspective, it’s not convenient when
> ‘guix pack’ creates big images that you have to carry around and your
> colleague laughs at you because their Alpine image of “the same thing”
> (quotes!) is half the size. ;-)
I know this pain!
--
Ludovic Courtès writes:
> Hi,
>
> Josselin Poiret skribis:
>
>> I also don't see how Guix would gain anything from moving to Guile's
>> native exceptions. However, one thing that would be nice to have is a
>> description of all such "implementation choices" in Guix, perhaps in
>> the "Coding
John Kehayias writes:
>>> Efraim Flashner skribis:
>>>
>>> I've made some progress on LLVM and I think I have a working LLVM
>>> that can be used as an input for mesa.
This is awesome! Thank you Efraim!
> I don't think there were any errors in building mesa with older LLVM,
> but on current
Hilton Chain writes:
> Hi Guix,
>
> I'm trying to package wakatime-cli[1], while Guix uses Go 1.17 as the
> default, the package requires Go 1.19 at the current version
> (v1.60.4).
>
> Though it's possible to package the last version supports Go 1.17
> (v1.38.0), I wonder if we can adjust the
Leo Famulari writes:
> Now that our build farm is running smoothly, I propose we revive the
> practice of feature branches, when appropriate.
It was on my TODO list to bring this up on the mailing list! Thank you, Leo!
I also think this is a fantastic idea, and like John, I think mesa is
Maxim Cournoyer writes:
> This is a heads up to let you know that the
> %BASE-PACKAGES-DISK-UTILITIES public variable exported from (gnu
> system) may be removed in the near future.
>
> For the rationale and more details, see the proposed change [0].
>
> [0] https://issues.guix.gnu.org/59661#1
jgart writes:
> Could we support sorting inputs with guix style?
And for that matter, auto-add and auto-remove unusued imports. I'm so
bad at this kind of manual book-keeping.
But maybe that's more of a geiser/scheme-lsp feature request?
--
Katherine
Maxim Cournoyer writes:
> Apologies for causing grief!
No worries at all, Maxim! The good you do far outweighs any grief, and
even if that weren't the case, we're only human :)
> I'm taking yours and Ludovic's feedback into account for the future
> and will reach out to guix-devel with
Maxim Cournoyer writes:
>> Moving the field last is problematic as we’ve seen for any user that
>> uses ‘match’ on records—something that’s not recommended but still
>> used a lot.
Some feedback I hope is useful:
I'm one such newbie, and had to stumble my way into discovering why some
of my
jgart writes:
> Is Guix suitable for large monorepos?
I use Guix against a large mono-repo, and there are a few
difficulties.
I should mention that I am not using Guix in the typical fashion with
fixed commits (packages are pointed at HEAD and I don't use checksums).
For my purposes, it's
Michael Rohleder writes:
> This looks like https://issues.guix.gnu.org/55427
I tried to update emacs yesterday and ran into this issue, and a few
other issues with emacs packages as well. I was surprised that we merged
an update to emacs when some packages (well used ones at that) were
failing
zimoun writes:
> On Tue, 29 Mar 2022 at 12:15, Ludovic Courtès wrote:
>
>> Stack smashing protection (SSP) may incur measurable run-time
>> overhead though so enabling that one by default may be less
>> consensual.
>
> That’s true and it could be an issue for HPC practitioners. However,
>
Aurora writes:
> Katherine Cox-Buday writes:
>
>> Everyone has different threat models and needs. A lot of computers
>> have CPU speculative execution attack mitigation disabled because
>> those types of attacks will never affect those computers, and it
>> redu
raingloom writes:
> People shouldn't have to take extra steps and burn extra CPU cycles
> for security.
To be clear, I don't have a strong opinion on this, but I wanted to give an
alternative viewpoint: people shouldn't have to take extra steps and burn extra
CPU cycles for performance.
I agree with the gist of what you're saying, but I first need to establish that
Guix is actually not doing anything wrong before we can talk about how to make
things better.
> On Saturday, April 23rd, 2022 at 9:51 AM, jgart wrote:
>
> The Guix docs do not explicitly state that a uri like
>
Pier-Hugues Pellerin writes:
> We should probably also try to mimic how their bootstrap and have the
> following:
>
>- Bootstrap 1.17 with 1.4
>- Bootstrap 1.18 with 1.4
>- Have 1.19 bootstrap with 1.17.
>
> So maybe we should do something like this.
>
> - Add go-1.18 build from 1.4.
>>> Pier-Hugues Pellerin writes:
>> Ludovic Courtès writes:
>>> I am trying to update Go to 1.18, I do have a *working* patch that defines
>>> a package that inherits from 1.17 and that adjusts the inputs.
>>
>> Nice!
Yes, thank you! I just found out I need this and came to see if anyone had
I run Guix everywhere I can, and it's now the only way I develop software.
Having said that, I have thought about this issue a little bit, and here's my
opinion on why this happens.
Pjotr Prins writes:
> And they start out as the next new thing to solve all problems! If
> they would only
Maxim Cournoyer writes:
> I'd like to bring your attention to a change to the current Guix
> maintainers collective; in a nutshell, Ludovic and Marius are stepping
> down from maintainer-ship while Efraim is joining.
Thank you very much for your guidance, support, and hard work, Ludovic and
adriano writes:
> Il giorno dom, 12/12/2021 alle 21.50 -0600, Katherine Cox-Buday ha scritto:
>> - In geiser, run =,a thing-i-want-to-look-for= (this is supposedly an
>> apropos command that is supposed to search symbols for you). The command
>> returns nothing.
> abou
jgart writes:
> On Wed, 29 Dec 2021 00:27:04 +0100 raingloom wrote:
>> TLDR how much of the effort spent on this channel is really justified
>> compared to making the underserved use-cases easier in upstream Guix?
I also have my own personal "upstream staging" channel so that I can continue
Luis Felipe writes:
> Hi,
Hello! Thank you for adding some context around why things are laid out the way
they are.
I just wanted to respond again with gratitude for your work, and to plainly
state that I view this work as difficult, with no clear best practice.
Sincerely,
--
Katherine
Here is some analysis on various popular languages' documentation landing
pages. I did this on Sunday, but I held it back from my previous message
because it was already quite long, and I was worried this would be seen as
over-critical and maybe raise the ire of various language fans.
But I
Congratulations, everyone!
I love Guix, and I really appreciate all the work that everyone puts into it.
I'm updating now :)
Sincerely,
--
Katherine
Blake Shaw writes:
> Katherine Cox-Buday writes:
>
> Katherine, reading a big deeper into your user experience report, its really
> so so helpful to have this concrete sort of step-by-step user experience
> report.
Definitely! The first step to resolution is a common understa
Blake Shaw writes:
> I'd love to know where you found trouble so that I can take that into
> consideration when developing a design strategy for the makeover.
When reading this, please keep in mind that I have a lot of gratitude for the
various maintainers of this software and its respective
Ryan Prior writes:
> I've found the Guile IRC channel to be polite and encouraging, but also very
> self-satisfied, which makes it hard to feel heard as a Guile hacker who's
> struggling.
Consider reaching out to Andy Wingo (wingo in IRC in #guile). I hope I am not
laying this issue at his
Foo Chuan Wei writes:
> In lisp-xyz.scm, I see that the "cl-locale" package has the same problem
> with its tests.
>
> Does anyone here know the cause of the error above?
Without having time to look at the code, but with the hope that this points you
in the right direction:
It probably has
Hey Guix!
I'm slowly working on contributing rsyslog with a Guix service. I have just
arrived at trying to allow the user to specify where the Shepherd service sends
its log file, and I began thinking about log rotation.
In the manual, SS10.8.3, it says:
> (usually, services that produce log
zimoun writes:
> And obviously, it could be nice to have an automatic tool for formatting; >
> something similar as etc/indent-code.el for ordering packages. ;-)
And cleaning up unused imports too! Does such a thing exist for Guile in
general?
--
Katherine
zimoun writes:
>> I have often seen folks on various projects worried about the size of
>> various backlogs: bugs, issues, etc. I think it is human to want to
>> try and contain something that appears to be growing, unbounded.
>
> …about patches only. Bug is another story. :-)
Sorry, I meant
Ludovic Courtès writes:
>go (Sarah? Leo? Raghav?)
I have only used this a few times so far, but the quality seems to have gotten
a lot better. My impression, though, due to the nature of how we have to
generate packages so as to not be reliant on a centralized GOPROXY server
Ludovic Courtès writes:
> I think a major goal of the process would be to formalize a minimum
> and a maximum duration under which an RFC is under evaluation, and a
> mechanism to determine whether it’s accepted or withdrawn.
I think it's a good idea. The only contribution I can give is that I
Ricardo Wurmus writes:
> Katherine Cox-Buday writes:
>
>>> It’s not about urgency but rather about not contributing to the growth
>>> of our patch backlog, which is a real problem.
>>
>> I have often seen folks on various projects worried about the size of
&g
Ludovic Courtès writes:
>> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès
> But I also view things from a different angle: everyone contributes in their
> own way, and each contribution is a gift.
Maybe selfishly, but I really agree with this. I think this is just the nature
of
Sarah Morgensen writes:
>> As an aside, when I started writing the importer, I didn't know it was a
>> possibility to just use the Go toolchain to help us generate packages. I
>> thought "the Guix way" was to do it all in scheme. It's nice that it's in
>> scheme, but I would love to leverage the
Xinglu Chen writes:
> I disagree, I think it’s OK for things like (guix git), which are mainly
> used by developers, to not be documented in the manual.
I strongly disagree with this. As a long-time developer, I have used
documentation both as a user and as a developer many times.
Sarah Morgensen writes:
> Hi Katherine, Jack,
>
> Katherine Cox-Buday writes:
>
>> Jack Hill writes:
>>
>>> Hi Guix,
>>
>> Hey, Jack, a few thoughts.
>>
>>> While I was was working with the go importer today, it suggested I package
&g
Jack Hill writes:
> Hi Guix,
Hey, Jack, a few thoughts.
> While I was was working with the go importer today, it suggested I package
> go-github-com-russross-blackfriday-v2. Fair enough, except we already have a
> package for go-github-com-russross-blackfriday.
I was poking around a rust
Andrew Tropin writes:
> The core part of Guix Home project has been moved from rde
> repository[fn:1] to wip-guix-home branch of guix repository.
>
> I'm about a week on wip-guix-home branch completely and Guix Home works
> fine. There are no any major issues on rde-devel and guix-devel mailing
Ludovic Courtès writes:
> I agree. Like Konrad and you wrote, it’s good that we can all have our
> quick-and-dirty packages in personal channels, and it’s good that these
> are separate channels.
Definitely! I would also encourage Guix to adopt some of the tools that make
creating quick, but
Konrad Hinsen writes:
> What is so far insufficiently supported by computing technology is the
> necessary transition from "fast" to "robust".
This is really a large problem in the industry. Especially since in most
circles moving fast is considered the preferred way to do things. SaaS and
Ludovic Courtès writes:
> Hello Guix!
>
> I and others are often disappointed (or angry!) when looking at the
> weaknesses of the most popular software deployment tools. I felt that
> acutely after packaging PyTorch last month and felt the need to look
> more closely at what others are doing
Xinglu Chen writes:
> On Wed, Sep 15 2021, Andrew Tropin wrote:
>> Records even for the same services have slightly different fields and
>> because of macro nature can't be reused between Home and System
>> services. In more details I mentioned this problem here:
>>
1 - 100 of 156 matches
Mail list logo
