Hi John,
> I would suggest we revert commit
> d084fb4b04a1cebb59959633660013fff495cd0d and/or use the previous version
> 6.1.3 until we can have docker compose with v2 support. As it is, this
> makes docker-compose unusable on Guix without some manual downgrade.
>
> Arun, what do you think?
Sorry, I am really constrained for time and not working on this
actively. But, I am happy to review patches if any.
Hi Chris and Maxim,
>> I think this is kind of expected. If NGinx hits the proxy_read_timeout
>> it'll return a 504 to the client and close the connection to Mumi I
>> think. I think what you're seeing here is Mumi trying to respond to a
>> request from NGinx that NGinx has closed.
Thanks for
Hi Maxim,
I have made a number of changes to mumi and reconfigured berlin with the
latest mumi. Here is a quick summary of the main changes to mumi.
- We now log the complete URI and the response code for every request to
mumi.
- We now handle HEAD requests correctly. This should eliminate
Hi Maxim,
Thanks for monitoring mumi. I'm not sure why these mumi crashes are
happening. I can think of two leads to start working on.
1. I see many lines such as those below that warn of garbage collection
issues with "repeated allocations of large blocks". I am not sure, but
this sounds like
>> Notice how the search term "database" is highlighted in the search
>> results. This is relatively easy to do with Xapian, and indeed I do
>> plan to implement this at some point.
>
> OK: can we consider this bug report (wishlist) as the "official" one for
> that feature? :-)
Sure!
> Can I
Hi Gio,
Sorry for my late reply. I have been travelling the last week and am
just catching up on all my email.
> When searching for "subject:" it would be useful to have a speficic
> message number and subject along with (or in place of) the bug title.
This is actually difficult to do because
Hi Gio,
Thanks for this feature request! It's always gratifying to know that
someone is using mumi, especially its more advanced features! :-)
> IMO is useful to be able to search for "subject:foo", it's a different
> search than searching for foo in the body
It looks like we implement this
`mumi send-email' only works with patch files. For example, `mumi
send-email foo.patch bar.patch'. It would be nice if it could also
handle refs like `mumi send-email HEAD~5'.
Here's one way to achieve this.
1. When passed a ref, `mumi send-email' must run `git format-patch'
internally to
The mumi GraphQL endpoint errors out with an "Internal Server Error"
when queried for an issue that does not exist. It should error out with
a meaningful error response.
> It's string-contains without ?, apparently.
Ah, yes. That one always trips me up.
> The change is now installed; thanks for the review!
Thank you! :-)
Hi Maxim,
Thank you for the updated patch! :-) It LGTM. Please push.
> OK! I opted for simplicity and double-quoted all the names.
Fair enough. Though a check is only one condition away! ;-)
(if (string-contains? (person-name member) ",")
(string-append "\"" (person-name member) "\"")
Hi Maxim,
When a patch relates to no teams, I get the empty header output
"X-Debbugs-Cc: ". For such patches, it would be nicer to not add any
header instead of adding an empty header.
> +(define (team->members team)
> + "Return the list of members in TEAM."
> + (sort (team-members team)
> +
> Now, I don't think the GNU Debbugs instance is kept up-to-date with
> Debbugs upstream, having its own set of changes, so I think the patch
> here should still be applied in the meantime.
I agree. And, even otherwise, it is nice for X-Debbugs-Cc to mirror the
Cc header and use a
> Pushed as 42fbe62d52a82d1003c3d7039d3c4a46806c5cee
Thank you, Pierre! :-)
> I'm inclined to keep it in %network-configuration-files just to be
> safe.
I agree. I don't really understand the implications of removing
/etc/hosts from %network-configuration-files. I would err on the side of
caution and leave it there for now.
@Pierre: Could you make a patch of the fix
Hi Bruno,
> /etc/hosts is created by hosts-service-type, so if you remove that service
> it shouldn't be present anymore.
That makes sense.
There's one more question, though. Now that we are handling /etc/hosts
using hosts-service-type, should /etc/hosts still be in
Hi Bruno and Ludo,
This bug seems related to your commit
802ea1f3a43e5fb8d0b8bd2882954d8a6e49cde6 . Could you weigh in?
https://issues.guix.gnu.org/61627
Thanks!
Arun
Hi Ricardo,
I have an additional small improvement. guile-email transparently
handles MIME encoded words. We need not check for them. Patch follows.
Regards,
Arun
Arun Isaac (1):
debbugs: Do not check for MIME encoded words in subject.
mumi/debbugs.scm | 13 +++--
1 file changed, 7
/debbugs.scm
index 16bff8e..7e95ddf 100644
--- a/mumi/debbugs.scm
+++ b/mumi/debbugs.scm
@@ -1,5 +1,6 @@
;;; mumi -- Mediocre, uh, mail interface
;;; Copyright © 2020 Ricardo Wurmus
+;;; Copyright © 2023 Arun Isaac
;;;
;;; This program is free software: you can redistribute
Hi Ricardo,
Thanks for the bug report!
It's very strange, but I'm not able to reproduce this. I tried the
following. bug_49114.mbox is downloaded from
https://debbugs.gnu.org/cgi/bugreport.cgi?mbox=yes;bug=49114
--8<---cut here---start->8---
(use-modules
Closing since python-seaborn now builds successfully on the latest
master.
I have also sent a new patch updating python-seaborn to
0.12.0. https://issues.guix.gnu.org/58466
Hi Maxime,
> X-Debbugs-CC: Arun Isaac
>
> ^ author of the commit adding the rust-zstd-sys
>
> I noticed that the package 'rust-zstd-sys' bundles a copy of zstd. This
> is against policy for the reasons documented in the manual. This
> packag
> I fixed it in 67a6828b2bb821274757f686f7c685b664339a96 using the same
> trick as earlier.
Works now, thank you!
Hi zimoun,
> Well, it appears to me easier if bug#57306 remains closed since ’guix
> time-machine’ is fixed; as it was the subject.
I think you mean that bug #56441 should remain closed. Bug #56441 was
about guix time-machine. Bug #57306 is the current bug about guix pull.
Regards,
Arun
Hi zimoun,
> I do not think it is related to guix-daemon and I think it is expected;
> indeed it could be considered as a bug. The command-line,
>
> guix pull --commit=xyz -p /tmp/test
>
> writes /tmp/test/manifest using the current Guix (say manifest 4) and
> not using Guix at commit xyz
Thanks, Josselin! I have asked at #56441 whether it may be reopened.
>> Commit 4ff12d1de7cd617b791996ee7ca1240660b4c20e introduced that bug,
>> which was fixed in c9fbd40785a99e13a59d8e530830ce85220a9871:
The failing commit 6f75565b4ec3b8a7247699c327a3b3196c787f76 is not in
that range, if that's what you are saying.
When I guix pull to 6f75565b4ec3b8a7247699c327a3b3196c787f76, activate
the profile and run guix describe, it fails with an "unsupported
manifest format" error.
--8<---cut here---start->8---
$ guix pull --commit=6f75565b4ec3b8a7247699c327a3b3196c787f76 -p
Hi Maxim,
> I'm curious as to how SSH clients typically trigger 'pinentry' to
> prompt; perhaps Guile-SSH is lacking some feature here.
Exactly my point! :-)
> I hope someone in the know can tip in! In the meantime, you've already
> found a workaround (the use of an SSH agent).
Yup.
Hi Maxim,
I normally use neither OpenSSH's ssh-agent nor gpg-agent's ssh-agent
feature. But, when I do, it works. I didn't run into any pinentry issues
like you described. But, that's only because a passphrase entry is not
required at the time of `guix build'. Passphrase entry is required only
Hi Maxim,
> I suspect this is due to changes in OpenSSH *client* that now refuse
> older RSA keys for security reasons.
This doesn't seem to be. Here's why: I have another machine that I ssh
to using an unencrypted RSA key. I am able to connect to the Guix daemon
on that machine without any
Hi Ludo,
While I'm pretty sure it won't help this issue, I just released the long
overdue guile-xapian 0.2.0 and updated the Guix package as well. See
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e614cf2907105d1d41653c2316b96d29d807baa8
Regards,
Arun
Hi Ludo,
> --8<---cut here---start->8---
> 2022-06-02 15:04:45 GET /issue/54065/raw/12
> 2022-06-02 15:04:45 GET /issue/43096/raw/2
> 2022-06-02 15:04:45 GET /issue/45676/raw/10
> 2022-06-02 15:09:09 GET In procedure delete-Database: Wrong type argument in
>
I have an SSH key encrypted with a passphrase. When I try connecting to
a remote guix daemon with that encrypted SSH key, it fails with the
following error message.
--8<---cut here---start->8---
$ GUIX_DAEMON_SOCKET=ssh://foo guix build -v3 hello
guix build:
Hi Bonface,
It looks like this problem is due to matplotlib 3.5.x and is known
upstream. See
https://github.com/mwaskom/seaborn/issues/2663 . We might have to wait
for an upstream release or cherry pick commits.
Regards,
Arun
signature.asc
Description: PGP signature
Hi,
Tobias communicated off-list that it is ok to close this issue. I am
closing it now.
Thanks,
Arun
signature.asc
Description: PGP signature
Hi,
I just pushed a patch upgrading wesnoth to 1.16.0, and I confirm that it
builds successfully. Can we close this issue?
Regards,
Arun
signature.asc
Description: PGP signature
Hi,
Thanks for the patch! Unfortunately, this is a duplicate of
https://issues.guix.gnu.org/50744 . Sorry about that! I'm closing this
bug now.
Thanks,
Arun
signature.asc
Description: PGP signature
Hi Maxim,
> I thought the default user agent was already that of Firefox for Windows
> (!), purportedly to make it less unique (thus making fingerprinting of
> browsers/users more difficult).
Sorry, I'm replying rather late. I just disabled the "User-Agent
Switcher" addon in my Icecat, and
Hi,
I believe commits b459c39adb725822916a8e21ee250fb408d2e2f8 and
e17f063627f826b4dd0dda77ede48fc7a535414b address this issue. So, closing
this issue.
Thanks,
Arun
signature.asc
Description: PGP signature
Hi,
Version 10.0.1 (the latest version) of linkchecker supports python 3,
and I updated the package a month or so ago. Closing this bug report
now.
Cheers,
Arun
signature.asc
Description: PGP signature
Hi all,
For many services, extending the activation-service-type with a gexp
that can chown the necessary files is a good enough solution. This is
how I work around the problem of unstable uids/gids in my guix system
containers.
Regards,
Arun
signature.asc
Description: PGP signature
>> [Adding Arun Isaac to CC. Their commit d8796851 is the first one to
>> drop -pkg.el, but without explanation.]
>
> Commit d8796851 was an attempt to not install too many unnecessary files
> and be closer to how MELPA packaged emacs packages. See
> https://lists.gnu.org
> [Adding Arun Isaac to CC. Their commit d8796851 is the first one to
> drop -pkg.el, but without explanation.]
Commit d8796851 was an attempt to not install too many unnecessary files
and be closer to how MELPA packaged emacs packages. See
https://lists.gnu.org/archive/html/guix-devel/2
Hi,
> @Arun, does this sound familiar to you?
Thanks for the bug report! It was indeed a regression in guile-email. I
have fixed it, and added a test. See
https://git.systemreboot.net/guile-email/commit/?id=ca0520a33c9042a68691d85c6849f88412ca8357
Cheers!
signature.asc
Description: PGP
Hi,
I don't know much about the state of ibus in Guix. When last I checked a
few years ago, I couldn't get it to work for Tamil. So, I tried uim and
it worked. Perhaps, just as an immediate workaround until this bug is
addressed, maybe you could try uim?
My uim setup is as follows. You probably
Hi,
Thanks for your patch. I pushed to master with the following minor
changes.
- added copyright header for you
- made minor style change in code
- modified the commit message
Cheers!
signature.asc
Description: PGP signature
>> I have fixed this bug in the latest guile-email master, and added
>> tests to prevent regression. See
>> https://git.systemreboot.net/guile-email/commit/?id=37e245539bc9e27db35731e7b517cdde397834e2
>> and
>>
> For some reason “Jorge P. de Morais Neto ” is
> not split up into name and address parts but remains a single string.
I have fixed this bug in the latest guile-email master, and added
tests to prevent regression. See
Hi,
This is likely a bug in guile-email. It shouldn't have returned the
unparsed From address. It was likely triggered by "Jorge P. de Morais
Neto " being an invalid address. The period
character is not allowed in the name and should have been quoted like
"\"Jorge P. de Morais Neto\" ". I will
Hi,
Many sites---jitsi among many others---don't work properly when they see
an Icecat user agent. Instead, when the user agent is set to a Firefox
user agent, these sites work as expected. Users can do this manually by
installing user agent switching extensions such as uaswitcher, but it
would
> It kept spitting the error during the check phase, but I was
> time-machined some months into the past. Maybe with current Guix version
> the issue does not occur. I will check it out this or the next week.
Sure, check it out and let me know.
> Thank you for your work on this issue.
My
Hi,
I pushed to master, my commit replacing proj.4 with proj. This fixes the
segfault issue. I also updated the package. If the issue with the check
phase still persists, please open a separate issue.
Cheers!
© 2019 Jan (janneke) Nieuwenhuizen
+;;; Copyright © 2020 Arun Isaac
;;;
;;; This file is part of GNU Guix.
;;;
@@ -393,7 +394,17 @@ thus potentially malicious code."
(when (guix-channel? channel)
;; Apply the relevant subset of PATCHES directly in CHE
The new guile-git based patch follows. Thanks!
Arun Isaac (1):
Use nearest tag as the version string in documentation.
guix/channels.scm | 13 -
guix/self.scm | 10 ++
2 files changed, 18 insertions(+), 5 deletions(-)
--
2.26.2
> I would rather not call out to ‘git-version-gen’ and instead use (git
> describe) or similar.
Sure, I'll do that. Then, perhaps we should even rewrite git-version-gen
using (git describe). It would be nice to have that in guile too. WDYT?
> However, unless I’m mistaken, the output of
© 2019 Jan (janneke) Nieuwenhuizen
+;;; Copyright © 2020 Arun Isaac
;;;
;;; This file is part of GNU Guix.
;;;
@@ -40,6 +41,7 @@
#:use-module (guix sets)
#:use-module (guix store)
#:use-module (guix i18n)
+ #:use-module (guix build utils)
#:use-module ((guix utils
. See use of dot-git? in latest-channel-instance of
(guix channels). To remedy this, I am generating .version before discarding
the git repo.
WDYT?
Arun Isaac (1):
self: Use nearest tag as the version string in documentation.
guix/channels.scm | 15 ++-
guix/self.scm | 11
> The “0.0-git” string comes from (guix self). As noted there, we can’t
> really afford to change the version string at each commit, or we’d have
> to rebuild the manual at each commit.
>
> We could perhaps choose a more meaningful version string, though, maybe
> by looking at the closest tag or
In the info manual, the Guix version is rendered as 0.0-git. For
example, in "(guix) The Store", see "The ability to connect to remote
build daemons is considered experimental as of 0.0-git". I am running
the Guix standalone system. Any idea what's going wrong?
Thanks,
Arun
signature.asc
Hi,
> Have you been able to figure out why some of the items differ in the
> two lists?
The two lists are the same if `guix build' is invoked with the
`--no-grafts' flag. I don't understand grafts very well and am not sure
how that can be fixed. Any ideas?
See different output below with and
> Have you been able to figure out why some of the items differ in the two
> lists?
Hi! Are you asking me? I haven't worked on this in a very long
time. But I'll give it another shot now and get back to you.
signature.asc
Description: PGP signature
In the check-description-style function in guix/lint.scm, the string
"sentences in description should be followed ..." should be pluralized
using ngettext, not ~p as it is now. ~p only adds an 's' if the
corresponding argument is greater than 1. Needless to say, there are
many languages that
> No, I cannot reproduce any more, it looks like this is fixed, thanks !
Thanks! I'm closing this issue now.
signature.asc
Description: PGP signature
Hi,
This problem seems to have been addressed after Ricardo's recent update
of our mumi issue tracker instance.
https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00205.html
Are you still able to reproduce it?
Regards,
Arun
signature.asc
Description: PGP signature
>> arm-none-eabi-toolchain is conflicting with avr-toolchain since both are
>> setting the CROSS_* environment variables. See the output of `avr-gcc -E -v
>> -` below.
>>
>> This should probably be considered a bug. But I have no idea how to fix
>> this. :-( What do you think?
>
> I agree. The
> * gnu/packages/avr.scm (avr-gcc-4.9): Use CROSS_C*_INCLUDE_PATH (like
> cross-base does).
> (avr-gcc-5)[source]: Apply patch "gcc-cross-environment-variables.patch".
Hi,
I verified that this patch works[1]. Could you please push to master?
Thanks! :-)
signature.asc
Description: PGP
> I can replicate what you did and it works.
Nice! :-)
> May it be conflicting with other packages?
arm-none-eabi-toolchain is conflicting with avr-toolchain since both are
setting the CROSS_* environment variables. See the output of `avr-gcc -E
-v -` below.
--8<---cut
> ```
> QMK Firmware 0.7.163
> Making helix/rev2 with keymap default
> [ERRORS]
> In file included from drivers/avr/pro_micro.h:28:0,
> from keyboards/helix/rev2/matrix.c:33:
>
Hi,
I tried the last patch at bug 24416 [1] and it does fix the issue. Can
you confirm?
Regards,
Arun.
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24416#17
signature.asc
Description: PGP signature
> First, your patch does not apply. Because it should be line 21 and not
> 18 for the addition of your Copyright.
Sorry, I should have rebased with master.
> But as we have talked before, there is an issue about the upstream
> test suite of the package (point 1. of [1]). So I am
--container --ad-hoc r r-rgdal -- Rscript -e
'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1];
ogrInfo(dsn=dsn, layer="cities")'
Thank you for your patience! Cheers! :-)
From 7b2430788c2d168bd2a8a848e488a0e03140057b Mon Sep 17 00:00:00 2001
From: Arun
> You mean:
>
> guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!
Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.
> So
> For other packages than r-rgdal depending on proj.4:
> - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
> - not ok: libspatialite and libosmium
Indeed, all packages don't yet support proj. We'll have to keep proj.4
around until their upstreams adds support for proj.
>> > 2. a regression of r-rgdal introduced by your commit
>> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>>
>> Replacing proj.4 with proj in the r-rgdal package seems to fix this
>> regression. Can you confirm?
>
> Maybe, but it is not what the user expects. Upstream explicitly
> mentions proj.4,
> There is 2 issues in this bug report:
>
> 1. the `check' phase is failing but the build ends with "success".
I haven't investigated why this is happening.
> 2. a regression of r-rgdal introduced by your commit
> f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
Replacing proj.4 with proj in the
> My best guess is that this has something to do with a circular
> reference between guile modules, but I am not certain on how to easily
> debug (and fix) this.
I updated the guile-email package two days ago. I hope that is not what
introduced this problem, and I don't see how it could have.
> It seems that version 3.0.0 is out for two months. I will try to
> update this first, then have a look at reproducibility. Wdyt?
I have a patch updating postgis as well as many other packages in
geo.scm. Please see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38149
signature.asc
I felt pretty sure about this patch. So, I pushed it to
master. Meanwhile, I also updated ansible to the latest 2.8.5. I am
closing this bug report now. Please feel free to open a new bug report
in case there are any further problems.
Thanks!
signature.asc
Description: PGP signature
> so it's possible to "manually" remove the unneeded mingetty and
> console-fonts services from containers
>
> how could it be automated? should it be automated? (IMHO yes)
I too believe it should be automated. But, I'll leave the others on this
thread to come to a decision.
signature.asc
>> You should do something along the lines of the following:
>>
>> (remove (lambda (service)
>> (let ((type (service-type-name (service-kind service
>> (or (eq? type 'mingetty)
>> (eq? type 'console-fonts
>> %base-services)
>
> thank you for
> please any hint on how to "manually" remove those two failing services?
You should do something along the lines of the following:
(remove (lambda (service)
(let ((type (service-type-name (service-kind service
(or (eq? type 'mingetty)
(eq? type
> The current ansible package is still brokenin the same way.
FWIW, I fixed our ansible package in
https://issues.guix.info/issue/33777 . This is not a general solution,
but at least our ansible package works at the moment.
signature.asc
Description: PGP signature
> This looks fine to me. Thanks!
Pushed, thanks!
signature.asc
Description: PGP signature
I've attached a patch addressing this issue. May I push it?
From 57fa15ef15d1fdb0896ce139e1e02c459b285743 Mon Sep 17 00:00:00 2001
From: Arun Isaac
Date: Sun, 20 Jan 2019 22:18:32 +0530
Subject: [PATCH] import: github: Check if git URIs are GitHub URIs.
This fixes a regression introduced
I'm closing this issue since it is not relevant anymore. Gajim is now
version 1.0.3, as opposed to 0.16.5 when this issue was reported. At
least as far as I can tell, this locale issue does not seem to exist
anymore.
> Commit de30205ba0f63eb987097a9f47b6e4fd38cd9044 added a pcscd service
> (hooray!). However, its activation procedure doesn't always work. The
> system test passes, and the activation procedure works the first time
> you boot, but if you reboot, it will fail because the symlink it creates
>
Hi Diego,
Thank you for your report. I just patched our emacs-exwm to include the
upstream fix.
Regards,
Arun.
At (info "(Guix)Top"), the first line says "This document describes GNU
Guix version , a functional ...". The version number is
missing. However, the manual at the URL
https://www.gnu.org/software/guix/manual/guix.html has the version
0.13.0 correctly mentioned.
signature.asc
Description: PGP
Ricardo Wurmus writes:
> Alex Kost <alez...@gmail.com> writes:
>
>> Arun Isaac (2017-06-27 11:44 +0530) wrote:
>>
>>> Ok, fixed! :-)
>>>
>>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2482c02f3b23b2490a6647e0717cf8a4ccf3f6a8
>
> I'm not sure what you mean by a "fix". This is an Emacs issue, and it
> was there since... I don't know, always.
Oh, my bad. I thought it was something related to guix-devel-mode or the
.dir-locals.el
> Moreover, I don't think it's a bug; it's just how Emacs finds a
> beginning of the
Ok, fixed! :-)
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2482c02f3b23b2490a6647e0717cf8a4ccf3f6a8
However, I think this is a hack, and the better solution would be to
actually fix the underlying indentation issue. But, I am too lazy to
find out how. :-P
I'm not entirely sure this is the right place to report this
bug. If I should report this bug elsewhere, please direct me.
When I indent the `emacs-which-key' package definition in
gnu/packages/emacs.scm using `indent-region', the description gets
indented wrongly. The "(or as many as space
Pushed! :-)
Made a few minor modifications to the commit message...
> Sorry I haven’t closely followed this discussion. Arun: Could you merge
> it if that looks good to you? I trust your judgment, comrades. :-)
The patches are fine by me. Alex Kost is reviewing this patch. So, I
think he should push. Thanks!
Alex Kost writes:
> Sure, I didn't mean I was ignored, I just wanted to say that I got the
> same thought about those arguments as Maxim.
No hard feelings! :-) debbugs can be a pain to read. I thought you
missed that message from me.
> As I said, I think this duplication can be avoided simply
> this might have to do with the fact that until recently most Elisp
> projects were organized as a single file of thousands of lines of code
> ;).
Exactly! :-)
> I've also factorized out the default args of the include and exclude
> option of the emacs-build-system install phase. Please see
> As far as I understand it, it was done for purpose: some packages
> include "uninteresting" (for tests, maintenance, etc.) *.el files in
> subdirs, that's why they are excluded by default. So probably a better
> solution would be to fix 'ert-runner' package (as it is done in commit
>
> I cannot currently make guarantees on when I'll be able to wrap my head
> around the entire problem, so if you come to conclusions for next steps
> on the basis of your testing, we should go with those.
>
> Else I will revisit this issue when I have time (which might be a
> while).
I don't
1 - 100 of 119 matches
Mail list logo
