`guix-repl' function rather than
manually running shell commands.
A caveat of my script: it sets the `load-path` variable, which is useful
at times but greatly increases the foot-shoot-ability.
Kind regards,
pinoaffe
[0]
https://git.pixie.town/pinoaffe/emacs-config/src/branch/master/lisp/gu
provide a configurable CLI wrapper
> subcommand around all language ecosystem developer tools. In other words
> it's the same Guixy thesis applied to developer tooling. I think this
> could take the Guix developer experience to the next level.
Kind regards,
pinoaffe
indieterminacy writes:
> Sorry if this comes off as facetious (because this is an interesting
> proposal) but hasnt Make cornered a lot of these usecases well enough?
It has covered some of these usecases to a certain degree, but in my
opinion there's a lot of room for improvement.
As an exam
solved? (or is
this just a case of user-error?)
Kind regards,
pinoaffe
could make it easier/faster to write
package definitions.
Kind regards,
pinoaffe
Andreas Enge writes:
> Am Mon, Sep 04, 2023 at 08:44:18AM -0400 schrieb brian via Development of GNU
> Guix and the GNU System distribution.:
>> Regarding the GNU changelog commits, I really dislike them. They're
>> redundant busy-work as far as I'm concerned. And while I'd like to say
>> they'
Hi,
so you want an extended version of
https://libreplanet.org/wiki/Group:Guix/Wishlist, or am I
misunderstanding?
sider said criterion?
pinoaffe
On 2020-03-27 09:42, Ricardo Wurmus wrote:
It really should list all patches submitted to guix-patc...@gnu.org and
all bugs sent to bug-g...@gnu.org.
For example patch 40182 : doesn't show up when looking for "icestorm" or
"pinoaffe",
but does show up when I enter
On 2020-04-27 08:38, Jan Synacek wrote:
While we're at it, let me also give my opinion about supporting PAGER.
If it means that if PAGER is set, use it, otherwise don't page, then
that's perfectly valid and, in my opinion, how PAGER support is
supposed to work. If it means that *unless* something
o it may not
be idiomatic or good code.
I've attached the reusable stuff in guix-profiles.el, and my personal
config in init-profiles.el.
Any thoughts?
Blessings,
pinoaffe
guix-profiles.el
Description: application/emacs-lisp
init-profiles.el
Description: application/emacs-lisp
o it may not
be idiomatic or good code.
I've attached the reusable stuff in guix-profiles.el, and my personal
config in init-profiles.el.
Any thoughts?
Blessings,
pinoaffe
guix-profiles.el
Description: application/emacs-lisp
init-profiles.el
Description: application/emacs-lisp
o it may not
be idiomatic or good code.
I've attached the reusable stuff in guix-profiles.el, and my personal
config in init-profiles.el.
Any thoughts?
Blessings,
pinoaffe
guix-profiles.el
Description: application/emacs-lisp
init-profiles.el
Description: application/emacs-lisp
o it may not
be idiomatic or good code.
I've attached the reusable stuff in guix-profiles.el, and my personal
config in init-profiles.el.
Any thoughts?
Blessings,
pinoaffe
guix-profiles.el
Description: application/emacs-lisp
init-profiles.el
Description: application/emacs-lisp
Hi everybody, sorry for the repeated messages, something went wrong with
mu4e
On Thu, Dec 17, 2020 at 4:59 AM pinoaffe wrote:
> Hi guix!
>
> I wrote some elisp that
> * maintains a list of available guix profiles
> * maintains a list of active guix profiles
> * allows the user
o it may not
be idiomatic or good code.
I've attached the reusable stuff in guix-profiles.el, and my personal
config in init-profiles.el.
Any thoughts?
Blessings,
pinoaffe
guix-profiles.el
Description: application/emacs-lisp
init-profiles.el
Description: application/emacs-lisp
ith Emacs-Guix, from my
> understanding. :-)
It might very well be, but I couldn't find a way to do what I wanted to
do with emacs-guix
Blessing,
pinoaffe
ng to a (set of) profile(s). When implemented correctly, this
could also be applied through per-project profiles when combined with a
project manager such as projectile.
Blessings,
pinoaffe
raingloom writes:
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html
>
> Should support more architectures than Hurd ;)
>
> Anyways, just throwing this out there, as I - and I imagine every
> other contributor - have some more pressing projects.
>
> It probably wouldn't be able to run most packag
Hi Leo,
great that you're improving the emacs-on-guix experience!
I'm not sure whether this is related,
but a while ago, after an update of emacs,
I had an issue where emacs would not start in graphical mode
(it segfaulted) until I ran `fc-cache -rv`.
Kind regards,
pinoaffe
other distro as
far as I can tell),
I went on to try to and add support for faber to guix.
My work in progress can be found at
https://gitlab.com/pinoaffe/guix_fork/tree/fpga,
along with the sole package I've been able to find that makes use of the
build system
and with nextpnr, which dep
changes (hinted in the mockups) with the same goal of product
> differentiation could be:
>
> 5. Guix Features section in the manual: Improve it.
>+ Separate in sections to make it easier to browse
>+ List forgotten functional features (if any)
> + List non-functional features
>+ Compare with similar products
> 6. Guix System Features section in the manual: Add it.
> 7. Guix System Configurations page: A collection of configurations, ideally
> of real systems currently used in production environments.
Those changes would be very valuable!
Thanks a lot for all the work
Kind regards,
pinoaffe
Hello!
Luis Felipe writes:
> El 12/10/23 a las 20:30, pinoaffe escribió:
>> I think it's important to clarify what Guix is (and I really like your
>> mockups/some of the concrete proposed changes), but I don't quite agree
>> with the idea behind your proposal.
Lars-Dominik Braun writes:
>> I have heard folks in the Guix maintenance sphere claim that we
>> never rewrite git history in Guix, as a matter of policy. I believe we
>> should revisit that policy (is it actually written anywhere?) with an
>> eye towards possible exceptions, and develop a mecha
Again this has nothing to do with rights granted by states. This is
> about including people and making them feel safe and respected.
I fully agree with you here, rights such as the right to free speech and
copyleft don't mean that any action that falls within those rights
should be free of consequences, especially when such an action excludes
others, disrespects them or makes them feel unsafe.
>> [...]
kind regards,
pinoaffe
Giovanni Biscuolo writes:
> [...]
> pinoaffe writes:
>> - should examine possible workarounds going forward,
>> - should move towards something like UUIDs and petnames in the long run.
>>
>> (see https://spritelyproject.org/news/petname-systems.html).
>
> I
that should make you rejoice in the fact that
protecting trans people's rights also protects cis people's rights.
This should not at all be surprising, as trans rights are human rights.
Kind regards,
pinoaffe
hes?
> but thankfully the sendgmail approach seems to work without that by
> using a gmail dev api setup.
nice to hear that things are working!
Kind regards,
pinoaffe
Simon Tournier writes:
> For instance, magit-forge does not work with Codeberg although their
> documentation says so. Well, neither Ludo or I have succeeded in
> configuring it, although we asked advice on Mastodon [1,2].
magit-forge has practically no support for forgejo yet, it only knows
h
Hi,
Simon Tournier writes:
> Bah news from upstream:
> https://github.com/magit/forge/pull/770#issuecomment-2812213785
yup, kinda expected that tbh, and fair, since forge has a lot of
callback related technical debt and since tarsius is quite hesitant to
merge PRs
> Feel free to share the se
ly distributed as patch files in the guix repository.
Kind regards, pinoaffe
Ludovic Courtès writes:
This looks like a great idea to me!
In light of guix potentially moving to codeberg, i've began adding
forgejo support to magit/forge, see
https://github.com/magit/ghub/pull/171 and
https://github.com/magit/forge/pull/770
It's still a WIP, so testers (and patches) welco
very limited spare time for research, so if there is one specific
> place I can bookmark and find all the info, that would be great.
If you ask me, there should definitely be an info manual section on
codeberg and how to interact with it
Kind regards, pinoaffe
to vote on GCDNNN"
I would go for something along the lines of "As the Deliberation Period
is at an end, it's time to see/look whether consensus has been reached"
Alternatively, naming this process something like a (consensus) poll or
a show of hands might help prevent the associations with majority-based
decision making
And instead of "X people voted" you could say something like "X people
responded (to the poll)"
Kind regards,
pinoaffe
Greg Hogan writes:
> On Tue, May 13, 2025 at 9:32 AM pinoaffe wrote:
>> If someone prefers that a GCD be withdrawn but would find its acceptance
>> acceptable, they should probably "vote" accept, even if their preference
>> is quite strong
> This preference is
ent does
not seem like a significant change, and in any case I don't think that
regular releases can be brought about by a GCD
kind regards,
pinoaffe
of years ago, I wrote a few string distance algorithms
cuz I was interested in them (see
https://codeberg.org/pinoaffe/guile-words/src/words/distances.scm), but
I have no idea if (part of) that would be useful in the stdlib, and in
what form
Heck, I feel like there's even a lower barrier to
;all think about
adding a build phase to convert Org documentation files into Texinfo
files, so they can be uniformly accessed?
Kind regards,
pinoaffe
Maxim Cournoyer writes:
> What do other think? I would tend to also think going through a GCD to
> be overkill to change these conventions. Is a consensus possible
> regarding letting go of the GNU ChangeLog style for our commit
> messages?
I think it's good to have *some* sort of agreed-upon con
Cayetano Santos writes:
>>lun. 07 juil. 2025 at 09:01, pinoaffe wrote:
>> I recently found out that ox-texinfo exists - what do y'all think about
>> adding a build phase to convert Org documentation files into Texinfo
>> files, so they can be uniformly accessed?
>
in the same boat.
>
> I'm on board with this, we're all for free software and need to have
> the backs of other free software projects.
It almost seems like you're saying that we need to have the back of the
xlibre project - if so: I strongly disagree. They should be treated as
pariahs in the community. We should support others *against* xlibre
folks, against their attacks, against their discrimination.
Kind regards,
pinoaffe
41 matches
Mail list logo
