Re: nnn-service-type for guix home
On Mon, 25 Oct 2021 02:05:31 +0300 Oleg Pykhalov wrote:
> Hi,
>
> jgart writes:
>
> > Does it make sense to add nnn's configuration to the bash-service-type
> > or to create a new service altogether?
> >
> > nnn is configured by setting environment variables:
> >
> > https://github.com/jarun/nnn/wiki/Usage#configuration
>
> For environment variables I think the best way is extending
> 'home-environment-variables-service-type' [1]. This approach could
> configure nnn for not only for Bash, but e.g. Zsh.
>
> [1]
> https://guix.gnu.org/en/manual/devel/en/html_node/Essential-Home-Services.html
Ah, thanks.
So, something like this?
(simple-service 'nnn-service-type
home-environment-variables-service-type
`(("NNN_BMS" . "d:$HOME/Documents;D:$HOME/Docs archive/")
("NNN_SSHFS" . ,(string-append sshfs "-o reconnect,idmap=user")) ;
reference sshfs from store somehow
("NO_COLOR" . 1)
...))
Re: nnn-service-type for guix home
Hi, jgart writes: > Does it make sense to add nnn's configuration to the bash-service-type > or to create a new service altogether? > > nnn is configured by setting environment variables: > > https://github.com/jarun/nnn/wiki/Usage#configuration For environment variables I think the best way is extending 'home-environment-variables-service-type' [1]. This approach could configure nnn for not only for Bash, but e.g. Zsh. [1] https://guix.gnu.org/en/manual/devel/en/html_node/Essential-Home-Services.html signature.asc Description: PGP signature
nnn-service-type for guix home
Hi Guixers, Does it make sense to add nnn's configuration to the bash-service-type or to create a new service altogether? nnn is configured by setting environment variables: https://github.com/jarun/nnn/wiki/Usage#configuration I had originally proposed an nnn config for guix-home-manager: https://framagit.org/tyreunom/guix-home-manager/-/issues/15
Re: public-inbox/elfeed -> Maildir bridge (was: Incentives for review)
Hi Kyle,
Lei and B4 look like very cool tools, thanks for the reference!
Jonathan McHugh
indieterminacy@libre.brussels
October 23, 2021 6:19 PM, "Kyle Meyer" wrote:
> zimoun writes:
>
>> On Fri, 22 Oct 2021 at 21:43, Kyle Meyer wrote:
>
> [...]
>
>>> https://yhetil.org/guix-patches/?q=dfn:docker=A
>>
>> Oh, that’s really cool!
>>
>> Do you know a bridge from Elfeed to Message-mode?
>>
>> I mean, using the feed you are referring, Alice gets:
>>
>> --8<---cut here---start->8---
>> Title: [bug#50227] [PATCH] build-system/go: Trim store references using the
>> native compiler option.
>> Author: Marius Bakke
>> Date: Fri, 27 Aug 2021 18:45:37 CEST
>> Feed: dfn:docker - search results
>> Link: https://yhetil.org/guix-patches/20210827164423.17109-1-mar...@gnu.org
>>
>> * guix/build/go-build-system.scm (build): Add '-trimpath' to the 'go install'
>> invocation.
>> […]
>> --8<---cut here---end--->8---
>>
>> This is really nice for filtering and only reading what is of interest
>> (for Alice).
>>
>> However, it is not handy for commenting. It could be cool to have a way
>> to turn what I showed (above) into a reply message. Does a bridge exist
>> somewhere?
>
> Good question. It does :)
>
> With the link in the Elfeed buffer, we can grab the mbox for a message
> or entire thread from a public-inbox instance. So, for those that use a
> Maildir locally, the steps are to
>
> 1) download the message (or thread)
> 2) convert the mbox into Maildir messages
> 3) visit the message in your regular mail client
> 4) proceed as usual
>
> piem can take care of 1 and 2 (as well as 3, with some user
> configuration) via its piem-inject-thread-into-maildir command:
>
> https://docs.kyleam.com/piem/Injecting-messages-into-a-Maildir-directory.html
>
> This command isn't specific to Elfeed buffers. It just needs to be in a
> buffer where piem knows how to grab the public-inbox link:
>
> https://docs.kyleam.com/piem/Enabling-integration-libraries.html
>
> The other supported modes that are interesting in this context are EWW
> and Gnus.
>
> Elfeed -> Notmuch
> =
>
> zimoun, I know you're a Notmuch user, so here's how you could configure
> things so that calling piem-inject-thread-into-maildir from the Elfeed
> buffer above throws you into a Notmuch show buffer for the message.
>
> * add a guix-patches entry to piem-inboxes
>
> (add-to-list 'piem-inboxes
> '("guix-patches" :url "https://yhetil.org/guix-patches;))
>
> * point piem to your Maildir
>
> (setq piem-maildir-directory "/path/to/maildir/")
>
> Alternatively, messages for different projects can be sent to
> different Maildir directories using the :maildir keyword in the
> piem-inboxes entry. (This feature was added by Xinglu Chen :>)
>
> * enable Elfeed integration
>
> (piem-elfeed-mode 1)
>
> * tell piem to visit the message in Notmuch after injecting
>
> (add-hook 'piem-after-mail-injection-functions
> (lambda (mid)
> (require 'notmuch-lib)
> (message "Running notmuch new")
> (call-process notmuch-command nil nil nil "new")
> (notmuch-show (concat "id:" mid
>
> You actually asked about ending up in a (Notmuch) message mode buffer
> rather than a Notmuch show buffer. Perhaps tossing a
> notmuch-show-reply in there after notmuch-show will work as expected,
> though I haven't tested it.
>
> lei
> ===
>
> This email is already too long, but I should briefly mention that Eric
> Wong (public-inbox's creator) has been working on a local command-client
> client for public-inbox called lei (local email interface).
>
> To continue with the original dfn example, you could do something like
> this with lei to dump those results to a Maildir and then view those in
> mutt:
>
> $ lei q -o /tmp/mdir --mua mutt \
> -I https://yhetil.org/guix-patches dfn:docker d:4.months.ago..
> # later: update with new results and visit in mutt
> $ lei up --mua mutt /tmp/mdir
>
> Anyway, that's just a small piece of what lei can do, and IMO it's
> really impressive and exciting. It will be a part of the next
> public-inbox release, v1.7. (How this all ends up integrating with piem
> is very much up in the air.)
>
> For a high-level picture that includes public-inbox, lei, and b4:
> Konstantin Ryabitsev, b4's creator, recently talked at the Linux
> Plumbers Conference:
>
> https://linuxplumbersconf.org/event/11/contributions/983/attachments/759/1421/Doing
> more with lore
> and b4.pdf
>
> The lei part starts on page 24. I believe there's a video out there,
> but I haven't watched it and don't have a link on hand.
Re: --with-source version not honored?
I was able to write a short manifest that avoided the overwriting of the
original "foobarpy" package in my case, and instead cleanly replace it with
a newer version specified using "with-source".
By setting, for example, GUIX_FOOBAR_VERSION=1.23 and
GUIX_TEST_PACKAGE=my-package - I can now create an environment which builds
the version of foobarpy I want from an https link generated from
GUIX_FOOBAR_VERSION, and then create a modified version of "my-package"
with foobarpy replaced, rather than overwritten.
This is much better than my original hack, but it's still not recursive so
whilst it does rebuild my-package with the new version of foobarpy as a
propagated input, it isn't rebuilding the whole dependency tree - other
inputs to my-package could also depend on foobarpy, and should be rebuilt
too - so what I've done is more of a graft, buthappens to be good enough
for my specific use case (the foobarpy is not used anywhere else in my
case).
Anyway thought I'd share this here as a template for simple non-recursive
cases. I suspect it's not a massive effort to make it recursive, when I
have a moment I'll have a think about that too. Any thoughts on how to
improve are welcome!
(use-modules (guix transformations) ;; options->transformation
(guix packages) ;; package/inherit
(srfi srfi-1) ;; fold
(srfi srfi-98)) ;; get-environment-variable
(define (generate-foobar-link version)
(string-append "https://packages.foobar.com/;
(substring version 0 3) "/foobar"
version "_linux64.tar.gz"))
(define transform
;; The package transformation procedure.
(let* ((foobar-version (get-environment-variable "GUIX_FOOBAR_VERSION"))
(foobar-link (string-append
"foobarpy@" foobar-version
"=" (generate-foobar-link foobar-version
(format #t "~%Setting Foobar Version: ~a~%" foobar-version)
(options->transformation
`((with-source . ,foobar-link)
(define my-foobar-package (transform (specification->package "foobarpy")))
(define-public my-package-with-my-foobar
(let* ((test-package-string (get-environment-variable
"GUIX_TEST_PACKAGE"))
(test-package (specification->package test-package-string)))
(package/inherit test-package
(propagated-inputs
`(("foobarpy" ,my-foobar-package)
,@(fold alist-delete (package-propagated-inputs test-package)
'("foobarpy")))
(packages->manifest (list my-package-with-my-foobar))
On Sat, 23 Oct 2021 at 11:04, Phil wrote:
> Hi,
>
> Ludovic Courtès writes:
>
> > For historical reasons, ‘--with-source’ only applies to leaf packages,
> > unlike most (all?) other transformation inputs. Concretely, this works:
>
> Yes I think this is what I'm hitting. I want to reference a package
> using --with-source, but then immediately build an environment which
> feeds this source as an input into a 2nd package - forcing it to
> rebuild.
>
> My hack works but for propagated dependencies in python - but it's not a
> proper solution, and is brittle. I was going to try to improve
> it by writing a Guile script to avoid the overwriting - I can post any
> solution I find if I get something working.
>
> Currently I can only do 2 things at the command line it seems:
>
> 1. I can try package X without writing a package but only in isolation
> or as a leaf.
>
> 2. I can replace package X as a dependency of package Y, if I write a
> package
> for it.
>
> Being able to combine 1 and 2 at the command line - would be very
> useful.
>
> Cheers,
> Phil.
>
Re: Incentives for review
On Thu, Oct 21, 2021 at 10:51:07AM -0700, Vagrant Cascadian wrote: > On 2021-10-19, Ludovic Courtès wrote: > > zimoun skribis: > > > >> On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès > >> wrote: > > >> One question is “encouragement” for reviewing, somehow. Asking for new > >> package additions to go via guix-patches is a call making kind of > >> equality between contributors. As someone without commit access, I can > >> tell you that it is often demotivating to send a trivial addition, wait > >> forever, ping people (aside I know who I have to ping :-)). Usually, it > >> means people are busy elsewhere, so I try to help to reduce the workload > >> by reviewing stuff or by doing bug triage. However, in the same time, I > >> see committers push their own trivial additions. It appears to me > >> “unfair”. > > > > I understand and sympathize (I also see us slipping off-topic :-)). > > > >> Why are committer’s trivial additions more “urgent” than mine? > > > > Yeah, I see what you mean. > > > > I would like to see us committers do more review work. But I also view > > things from a different angle: everyone contributes in their own way, > > and each contribution is a gift. We can insist on community > > expectations (reviewing other people’s work), but we should also welcome > > contributions as they come. > > I must admit, I don't review patches unless they're in an area of > expertise (e.g. u-boot, arm-trusted-firmware, reproducible builds > tooling, etc.); I just don't have sufficient skill with guile to review > arbitrary packages in a meaningful way, other than the most trivial of > packages... > > Before I was granted commit access, I *really* appreciated getting > review... but was also frustrated by how long it took to get a > contribution in; having limited time available for guix, spending that > energy checking if something I'd already "finished" was actually merged > was a bit demotivating. > > I have added a small number of trivial packages without review; maybe I > shouldn't have... but it was also a bit of a sigh of relief once I could > push directly to no have to get caught up in the waiting game; I had > more time to actually contribute other improvements to guix. > > > > There’s a balance to be found between no formal commitment on behalf of > > committers, and a strict and codified commitment similar to what is > > required for participation in the distros list¹. > > So yeah, it is a quite balancing act! > > > Would a workflow of pushing to a "wip-pending" branch in guix.git that > then gets merged and/or cherry-picked into master/staging/core-updates > help at all? > > A cursory review could commit to "wip-pending", with the > plan/hope/expectation that it would get some other review and/or a > timeout before it gets merged. > > I guess it would be hard to avoid having to constantly rebase with the > latest updates... "wip-pending" might just add more work to an already > needs-more-resources process... > > > live well, > vagrant There is cbaines' guix-patches service (and other things), where you can add the git remote https://git.guix-patches.cbaines.net/git/guix-patches and then cherry-pick commits from there to the necessary branch. I haven't used it much though. -- Efraim Flashner רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
Leo Famulari writes: > On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote: >> * Disable substitutes for relevent packages. Technically correct as >> license incompatibility is only triggered on transmission of binary, >> though maybe missing something about the spirit of the GPL. > > Maybe, but did anyone with standing ever take action regarding these > licensing incompatibilities? > > Perhaps, looking at these issues too closely is also missing something > about the spirit of the GPL. It just needs one person. Also see this weeks newsletter from Cory Doctorov on the lawsuit against Vizio. It might soon only take one user. Best get licensing problems fixed sooner than later. GPLv2-only is a problem quickly getting closer. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: Public guix offload server
>> $ export GUIX_DAEMON_SOCKET=ssh://char...@sandbox.guix.gnu.org:22 >> $ guix build foo > > …requires an SSH access by ’charlie’ to sandbox.guix.gnu.org, And they > think this access is risky. We could provide SSH access but no shell access. We could use some restricted shell in the spirit of git-shell. All we need is port forwarding through SSH, not shell access. signature.asc Description: PGP signature
