Hi Ricardo,
Ricardo Wurmus writes:
> Hi Josselin,
>> They both can co-exist with debbugs, and for now the patchwork instance
>> of QA is not usable for status tracking (because it is not meant to be
>> used as such for now). One can already use both of them, but using both
>> supercedes debbugs
Timothy Sample writes:
> I’ve written a special remote in Guile. If anyone wants to do so, the
> following file might help. It implements the basic protocol.
>
> https://git.ngyro.com/git-annex-remote-clouda/tree/git-annex-remote-clouda/remote.scm
Looks like a great reference. Thanks for shari
Simon Tournier writes:
> As we see, since ’origin’ is unreachable, it fetches directly from the
> web. Well, on machine-B running:
>
> git annex sync && git annex get -A
>
> allows to first update the keys and then to fetch all the new content
> from ’origin’. It eases the maintenance of back
Hi Maxim,
Maxim Cournoyer writes:
> Another easy option is to retrieve the Message-ID of any message in the
> series (via the source HTML of the mail archives, or directly from the
> mail headers if you have the mail locally), and then use B4, Linux
> style [0]. Example: suppose I wanted to appl
>Since it is computing, we could ask about the bootstrap of such
>generated data. I think it is a slippery slope because it is totally
>not affordable to re-train for many cases: (1) we would not have the
>hardware resources from a practical point of view,, (2) it is almost
>impossible to tac
>I do not know what you have in mind with “working satisfiable
>configurations” or with “a variant of the solver”. To my knowledge,
>this implies some SAT solver. Well, before going this direction, I
>would suggest to read some output of the Mancoosi project [8].
>Especially this part [9]. F
considered than I could have
anticipated at the start of a project. That said I liked your earlier stated
plan of starting simple. Handling latest releases seems a reasonable minimal
viable product.
Cheers,
Kyle
On April 3, 2023 8:41:53 PM EDT, Spencer Skylar Chan
wrote:
>Hi Kyle,
&g
My view as a statistician and Guix user is that trained machine learning models
should at best be provided as substitutes. They are opaque binary artifacts of
purely digital compilation processes and should not be treated exceptionally to
any other build artifact.
It would seem to me most consi
Skylar Chan
wrote:
>Hi Kyle,
>
>On 3/24/23 14:59, Kyle wrote:
>> I am a bit worried about your proposed project is too focused on replacing
>> python with guile. I think the project would benefit more from making python
>> users more comfortable productively using Gu
As a statistician who always wants to get the most information for the least
effort, I am particularly interested in being able to reprioritize workflow
jobs interactively within the equivalent portions of the topological sort. I
thought perhaps this would be possible with GWL if it could talk t
Dear Spencer,
I am a bit worried about your proposed project is too focused on replacing
python with guile. I think the project would benefit more from making python
users more comfortable productively using Guix tools in concert with the tools
they are already comfortable with.
I'm wondering
Simon Tournier writes:
> Hi,
>
>
> On Sun, 26 Feb 2023 at 16:52, Kyle wrote:
>
>> One idea might be to write a conda importer which looks at the
>> versions of software in the resulting environment and tries to make
>> feasible package variants of make a manif
sider and maybe translate into more interesting
technical goals you think would help the python community (and other
communities) become more engaged.
Cheers,
Kyle
On February 26, 2023 2:38:36 AM EST, Pjotr Prins
wrote:
>To follow up on Gábor: we excited to announce that the GNU project
On Fri, Feb 17, 2023 at 10:29 AM, Max Brieiev
wrote:
I want to run Guix on Apple M1 as a Qemu virtual machine.
I think I may be one of the few (only?) guix users that has a
setup like this. IIRC getting grub setup with qemu was the one
trickier parts of this. Feel free to ping me direct
right suggestion in my case.
On February 10, 2023 4:30:49 AM EST, Andreas Enge wrote:
>Hello Kyle,
>
>Am Fri, Feb 10, 2023 at 03:10:02AM +0000 schrieb Kyle Andrews:
>> configure: error: chosen localstatedir '/usr/local/var' does not match that
>> of the existing
ured because I wanted to extend Guix with a new feature and that I
could piece together a story in my head about how the code should look, my
query should be sent to this list rather than to help-guix.
Thanks in advance for any helpful suggestions towards getting this backend
added to Guix!
Cheers,
Kyle
Kyle Meyer writes:
> Sarah Morgensen writes:
>
>> On Tuesday, January 5th, 2021 at 5:01 AM, Kyle Meyer wrote:
>>
>>> add the appropriate "From:" header to the body of each patch. `git am`
>>> will take the in-body header over the actual header.
&g
zimoun writes:
> [...]
> Well, using the plain Git repo, it is easy to:
>
> 1. get messages from a list starting at a date;
> using ’git clone --mirror --shallow-since=’
>
> 2. get all the new messages;
> (using ’git pull)
>[...]
> IIUC, ’lei’ avoid this manual dance with the Git repo an
new ones for a specific list?
Rather than pass --all, you can call `lei up OUTPUT', where OUTPUT is a
particular saved search generated by `lei q', so you could have a saved
search that's specific for a list or set of lists:
$ lei ls-external | grep guix
/home/kyle/inboxes/g
zimoun writes:
> On Tue, 03 May 2022 at 17:42, Thiago Jung Bauermann
> wrote:
[...]
>> Just an aside about public-inbox: Starting with version 0.7 it ships
>> with a ‘lei’ tool that can be used to query a local or remote
>> public-inbox repo, and export the matching messages to a maildir.
>
> Th
Leo Famulari writes:
> On Mon, Jan 17, 2022 at 05:26:08PM -0500, Kyle Meyer wrote:
>> Fwiw I don't think Git automatically resolved that conflict:
>>
>> $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^
>> $ git merge 276f40fdc3
Leo Famulari writes:
> --
> $ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm |
> grep "define-public epiphany" -A11
> (define-public epiphany
> (package
> (name "epiphany")
> (version "41.2")
> (source (origin
> (method url-fetch)
>
Ricardo Wurmus writes:
> > test-name: file-needed/recursive
> > location:
> > /tmp/guix-build-guix-1.3.0-14.2a621f1.drv-0/source/tests/gremlin.scm:70
> > source:
> …
> > + (and (zero? (close-pipe pipe))
> > + (lset= string=?
> > + (pk 'truth ground-truth)
> > +
I think this is the related issue: https://issues.guix.gnu.org/52943
Lars-Dominik Braun writes:
> Hi Maxim,
>
>> I've grown to like our apparent lack of structure; we interact globally
>> on any topic of interest and the discussions all happen in a shared
>> space, which makes it easy to stay informed with everything that's going
>> on (do we really need more maili
zimoun writes:
> On Fri, 22 Oct 2021 at 21:43, Kyle Meyer wrote:
[...]
>> https://yhetil.org/guix-patches/?q=dfn:docker&x=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 g
Thiago Jung Bauermann writes:
> Em quinta-feira, 21 de outubro de 2021, às 10:38:44 -03, Artem Chernyak
> escreveu:
[...]
>> One thing that could help this, is to include a little more info in
>> the subject line for patches. Right now we include the broad area
>> (e.g. "gnu: ..."). But we could
Sarah Morgensen writes:
> On Tuesday, January 5th, 2021 at 5:01 AM, Kyle Meyer wrote:
>
>> add the appropriate "From:" header to the body of each patch. `git am`
>> will take the in-body header over the actual header.
>
> I wonder if there is a way to aut
Kyle Meyer writes:
> As an example, the patch you feed to git-send-email would look something
> like this:
>
> --8<---cut here---start->8---
> From ad2469ec86357b1a46dd63dcd17d5831969d5270 Mon Sep 17 00:00:00 2001
> From: Ryan Prior
&g
Ryan Prior via Guix-patches via writes:
>> By the way, your patches show that they are authored by "Ryan Prior
>> via Guix-patches via guix-patc...@gnu.org". Is that the correct email
>> address?
>
> No, the correct email address is rpr...@protonmail.com
>
> There's maybe 15 commits in Guix that h
Kyle Meyer writes:
> For public-inbox URLs, there is one character that needs to be escaped:
> "/" with "%2F" (see <https://yhetil.org/guix-devel/_/text/help/>).
Correcting myself: I shouldn't take that help page as a complete
description of what needs to be
zimoun writes:
> On Thu, 17 Sep 2020 at 12:00, Ricardo Wurmus wrote:
>> This is an interesting idea! I don’t know if it’ll work as a plain URL,
>> because not all characters of a message id might be usable in a URL (you
>> may need to URL-encode it and can’t just paste it in the URL bar of your
Gábor Boskovits writes:
> Konrad Hinsen ezt írta (időpont: 2019. dec.
> 17., Ke 7:52):
[...]
>> How about a more drastic measure: deprecate "guix environment" and
>> introduce a new subcommand with the desired new behaviour?
>>
> That is also the other option I was thinking about. Do you have an
Timothy Sample writes:
> Kyle Meyer writes:
[...]
>> Perhaps I'm just missing something, but to spell out my concern a
>> little
>> more: I have /gnu/store/A/git-annex and /gnu/store/X/bash-minimal. I
>> set up a repo with 'git annex init', and
>
ing the script in the Installation
> section and only asking users to look in the subsections for details?
Looks good. I think it would certainly help hasty readers like me.
Thanks.
--
Kyle
Hi Ricardo,
Ricardo Wurmus writes:
[...]
>> % ./pre-inst-env guix build -K --check git-annex
>> Utility/Exception.hs:29:1: error:
>> Bad interface file:
>> /gnu/store/qb3knv1h536sdjqc4nfkm3j1l8n7q87a-ghc-exceptions-0.10.0/lib/ghc-8.4.3/exceptions-0.10.0/Control/Monad/Catch.dyn_hi
>>
Hello,
I'm seeing the failure below when trying to build git-annex. Can anyone
else reproduce this failure? Any ideas how to resolve it?
--8<---cut here---start->8---
% git describe
v0.16.0-400-g4f36d98f7b
% ./pre-inst-env guix build -K --check git-annex
Uti
Brett Gilio writes:
> Kyle Meyer writes:
>
>> Ricardo Wurmus writes:
[...]
>>> That’s because it’s trying to colorize the diff of thousands of lines of
>>> .po and .texi changes.
>>
>> With the default settings and no cached visibility for the rep
ink the delayed painting is worth noting
because users may not realize that their custom visibility settings are
making things slower.
--
Kyle
7;m happy to send
a patch to guix-patches, but I imagine it is easier for someone with
push access to correct it.
--
Kyle
Timothy Sample writes:
[...]
>> I'm wondering whether the shebang patching in .git/hooks/pre-commit will
>> cause a problem. Using the patched shellPath_portable, 'git annex init'
>> generates a hook like this:
>>
>> % cat .git/hooks/pre-commit
>> #!/gnu/store/rbrandv7anzjxqkr40d7fkanzs
Hello,
Thanks for packaging git-annex, Tim! I'm excited to see it in Guix.
I'm wondering whether the shebang patching in .git/hooks/pre-commit will
cause a problem. Using the patched shellPath_portable, 'git annex init'
generates a hook like this:
% cat .git/hooks/pre-commit
#!/gnu/sto
Alex Kost writes:
> OK, so if the others agree with "along with" policy, would you like to
> update your patch for it?
Sure, sent to guix-patches (#27845).
--
Kyle
macs
packages, whereas no --pure flag would match adding the environment's to
the current profile's.
But in the discussion so far, I've been assuming that currently there's
not a direct way for guix-emacs-autoload-packages to detect if --pure
was given. If that's not true, I'd be happy with the behavior you
propose.
--
Kyle
>
> Now I'm also not sure if "along with" or "instead" is better. I don't
> have a preference, so I agree with any choice :-)
... I'd say "along with" is better.
As I said in my previous post, it's quite easy for me to get the
behavior I want, so I'd prefer to go with your gut feeling about the
expected behavior.
--
Kyle
Alex Kost writes:
> Kyle Meyer (2017-07-22 21:39 -0400) wrote:
>
>> I noticed that Emacs packages from the user's profile leak into guix
>> environment calls.
>
> As for me, this is a natural behaviour. If you want to be safe from any
> external packages, site se
Hello,
I noticed that Emacs packages from the user's profile leak into guix
environment calls.
For example, when I run
$ guix environment --pure --ad-hoc emacs -- emacs -q
load-path contains the Emacs packages from my main profile.
I expected it to use GUIX_ENVIRONMENT instead (something l
I think it’s a good idea to build R without OpenBLAS on all
> architectures for now.
Thank you, Ricardo. I'm sorry I wasn't able make any progress on
figuring out what the underlying issue was there.
--
Kyle
/python.scm
+++ b/gnu/packages/python.scm
@@ -14,6 +14,7 @@
;;; Copyright © 2015 Ben Woodcroft
;;; Copyright © 2015 Erik Edrosa
;;; Copyright © 2015 Efraim Flashner
+;;; Copyright © 2015 Kyle Meyer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -6006,3 +6007,38 @@ automatically detect a wide
Leo Famulari writes:
> On Thu, Dec 03, 2015 at 01:24:09AM -0500, Kyle Meyer wrote:
>> * gnu/packages/python.scm (python-docopt, python2-docopt): New
>> variables.
>
> Have you tested the software provided by this patch to make sure it
> works? I'm not sure how
* gnu/packages/python.scm (python-docopt, python2-docopt): New
variables.
---
gnu/packages/python.scm | 26 ++
1 file changed, 26 insertions(+)
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 45222e9..5b31ae8 100644
--- a/gnu/packages/python.scm
+++
/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2014, 2015 Mark H Weaver
;;; Copyright © 2014 Eric Bavier
;;; Copyright © 2015 Efraim Flashner
+;;; Copyright © 2015 Kyle Meyer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -925,3 +926,32 @@ any
kefile forms the path as
"${DESTDIR}${PREFIX}", so the end result should be the same. I'm not
sure why I decided setting DESTDIR would be better.
Sending an updated patch. Thanks for the comments.
--
Kyle
/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2014, 2015 Mark H Weaver
;;; Copyright © 2014 Eric Bavier
;;; Copyright © 2015 Efraim Flashner
+;;; Copyright © 2015 Kyle Meyer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -925,3 +926,32 @@ any
Ricardo Wurmus writes:
> Kyle Meyer writes:
>
>> In any case, I don't see these prompts as much of an issue because I'd
>> prefer to just use Guix for all R packages. Why not manage bioconductor
>> packages with Guix as well?
>
> I’m working on it alre
iced any issues (but my use of R is fairly limited, so that may not
be worth much).
In any case, I don't see these prompts as much of an issue because I'd
prefer to just use Guix for all R packages. Why not manage bioconductor
packages with Guix as well?
--
Kyle
u/packages/statistics.scm (r-lattice): New variable.
Isn't lattice already included with the main R build as a recommended
package?
--
Kyle
57 matches
Mail list logo
