unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / Atom feed
* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
@ 2020-09-02  5:16 Vitaliy Shatrov
  2020-09-02 17:24 ` Mark H Weaver
  2020-09-03 16:11 ` zimoun
  0 siblings, 2 replies; 13+ messages in thread
From: Vitaliy Shatrov @ 2020-09-02  5:16 UTC (permalink / raw)
  To: 43166

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Hello again dear Guixen.
I use emacs-w3m as a browser on  a single board computer.  I want to read, for example, issue #43159.

I can read it on https://debbugs.gnu.org/43159.  It's formatted properly, and the patch is readable too.

But the https://issues.guix.gnu.org/43159
is barely readable, and the patch is unreadable at all.  Even quoted text appear as:
> line > another line > more lines..

I think the issues.guix.gnu.org  should automatically append a link to the debbugs.gnu.org, for all issues.  It can be named like <a>No-JS version here</a>, or so.

The Links browser also can't show issues.guix.gnu.org properly for now.

Thanks.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 876 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-02  5:16 bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m Vitaliy Shatrov
@ 2020-09-02 17:24 ` Mark H Weaver
  2020-09-02 18:18   ` Mark H Weaver
  2020-09-03 16:11 ` zimoun
  1 sibling, 1 reply; 13+ messages in thread
From: Mark H Weaver @ 2020-09-02 17:24 UTC (permalink / raw)
  To: Vitaliy Shatrov, 43166

Vitaliy Shatrov <guix.vits@disroot.org> writes:

> Hello again dear Guixen.
> I use emacs-w3m as a browser on  a single board computer.  I want to read, for example, issue #43159.
>
> I can read it on https://debbugs.gnu.org/43159.  It's formatted properly, and the patch is readable too.
>
> But the https://issues.guix.gnu.org/43159
> is barely readable, and the patch is unreadable at all.  Even quoted text appear as:
>> line > another line > more lines..

I see similar problems with both 'lynx' and 'dillo' when remote CSS is
disabled.  As you point out, https://debbugs.gnu.org/ works much better
for simpler web browsers.

> I think the issues.guix.gnu.org should automatically append a link to
> the debbugs.gnu.org, for all issues.  It can be named like <a>No-JS
> version here</a>, or so.

I haven't looked carefully, but the issue seems to be related to CSS,
not Javascript.

      Thanks,
        Mark




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-02 17:24 ` Mark H Weaver
@ 2020-09-02 18:18   ` Mark H Weaver
  0 siblings, 0 replies; 13+ messages in thread
From: Mark H Weaver @ 2020-09-02 18:18 UTC (permalink / raw)
  To: Vitaliy Shatrov, 43166

Earlier, I wrote:
> I see similar problems with both 'lynx' and 'dillo' when remote CSS is
> disabled.

To be clear, Lynx doesn't have CSS support, so it's unable to properly
render 'issues.guix.gnu.org'.  Dillo can render it unless remote CSS is
disabled.

      Mark




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-02  5:16 bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m Vitaliy Shatrov
  2020-09-02 17:24 ` Mark H Weaver
@ 2020-09-03 16:11 ` zimoun
  2020-09-05 14:17   ` Vitaliy Shatrov
  1 sibling, 1 reply; 13+ messages in thread
From: zimoun @ 2020-09-03 16:11 UTC (permalink / raw)
  To: Vitaliy Shatrov; +Cc: 43166

Dear,

If you use Emacs, you should try the package emacs-debbugs.
Then: C-u M-x debbugs-gnu guix,guix-patches n y and last M-x
debbugs-gnu-bugs 43159

It does not solve the CSS and/or Javascript issue but it clearly eases
the readings of bug reports with Emacs.

All the best,
simon




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-03 16:11 ` zimoun
@ 2020-09-05 14:17   ` Vitaliy Shatrov
  2020-09-14 13:03     ` Maxim Cournoyer
  0 siblings, 1 reply; 13+ messages in thread
From: Vitaliy Shatrov @ 2020-09-05 14:17 UTC (permalink / raw)
  To: zimoun; +Cc: 43166

Really i was a fool.
Thanks for suggesting a tool.
No more dances with web-faces.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-05 14:17   ` Vitaliy Shatrov
@ 2020-09-14 13:03     ` Maxim Cournoyer
  2020-09-14 20:55       ` Mark H Weaver
  0 siblings, 1 reply; 13+ messages in thread
From: Maxim Cournoyer @ 2020-09-14 13:03 UTC (permalink / raw)
  To: Vitaliy Shatrov; +Cc: 43166-done

Hi Vitaliy,

Vitaliy Shatrov <guix.vits@disroot.org> writes:

Closing since a dedicated tool for use in Emacs (emacs-debbugs) exists,
which works around the shortcomings of the Emacs web browsers (Probably
CSS related, as Mark pointed out).

Thanks,

Maxim




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-14 13:03     ` Maxim Cournoyer
@ 2020-09-14 20:55       ` Mark H Weaver
  2020-09-14 21:17         ` zimoun
  0 siblings, 1 reply; 13+ messages in thread
From: Mark H Weaver @ 2020-09-14 20:55 UTC (permalink / raw)
  To: Maxim Cournoyer, Vitaliy Shatrov; +Cc: 43166

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Vitaliy Shatrov <guix.vits@disroot.org> writes:
>
> Closing since a dedicated tool for use in Emacs (emacs-debbugs) exists,
> which works around the shortcomings of the Emacs web browsers (Probably
> CSS related, as Mark pointed out).

For what it's worth: not everyone uses Emacs, and it would be good to
support users who choose to use simpler software.  I guess that it would
be quite easy to modify the software behind 'issues.guix.gnu.org' to
generate HTML that works well with simpler web browsers, so I'd prefer
to keep this bug open.  What do you think?

      Mark




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-14 20:55       ` Mark H Weaver
@ 2020-09-14 21:17         ` zimoun
  2020-09-14 21:53           ` Ricardo Wurmus
  0 siblings, 1 reply; 13+ messages in thread
From: zimoun @ 2020-09-14 21:17 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: Maxim Cournoyer, Vitaliy Shatrov, 43166

Dear Mark,

On Mon, 14 Sep 2020 at 22:58, Mark H Weaver <mhw@netris.org> wrote:

> For what it's worth: not everyone uses Emacs, and it would be good to
> support users who choose to use simpler software.  I guess that it would
> be quite easy to modify the software behind 'issues.guix.gnu.org' to
> generate HTML that works well with simpler web browsers, so I'd prefer
> to keep this bug open.  What do you think?

I am not sure to understand.  Something that generates HTML that works
well with simpler web browsers is <https://debbugs.gnu.org>, isn't it?
From what I understand, the aim (and "raison d'étre) of
<issues.guix.gnu.org> is to generate what is considered as "modern
webapp".

Therefore, what is the concrete request?

 - read the Debbugs with a simple web browser?  Then the answer is
<debbugs.gnu.org>.
 - add a button in <issues.gnu.org> saying "simple html there" and
redirecting to <debbugs.gnu.org>?  If yes, the source code to tweak is
there <https://git.elephly.net/gitweb.cgi?p=software/mumi.git> and I
agree it would be quite easy; I will give a try if no one beats me.
:-)

All the best,
simon




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-14 21:17         ` zimoun
@ 2020-09-14 21:53           ` Ricardo Wurmus
  2020-09-15  1:06             ` Ricardo Wurmus
  2020-09-15 10:13             ` Mark H Weaver
  0 siblings, 2 replies; 13+ messages in thread
From: Ricardo Wurmus @ 2020-09-14 21:53 UTC (permalink / raw)
  To: zimoun; +Cc: maxim.cournoyer, guix.vits, 43166


zimoun <zimon.toutoune@gmail.com> writes:

> Dear Mark,
>
> On Mon, 14 Sep 2020 at 22:58, Mark H Weaver <mhw@netris.org> wrote:
>
>> For what it's worth: not everyone uses Emacs, and it would be good to
>> support users who choose to use simpler software.  I guess that it would
>> be quite easy to modify the software behind 'issues.guix.gnu.org' to
>> generate HTML that works well with simpler web browsers, so I'd prefer
>> to keep this bug open.  What do you think?
>
> I am not sure to understand.  Something that generates HTML that works
> well with simpler web browsers is <https://debbugs.gnu.org>, isn't it?
> From what I understand, the aim (and "raison d'étre) of
> <issues.guix.gnu.org> is to generate what is considered as "modern
> webapp".
>
> Therefore, what is the concrete request?
>
>  - read the Debbugs with a simple web browser?  Then the answer is
> <debbugs.gnu.org>.
>  - add a button in <issues.gnu.org> saying "simple html there" and
> redirecting to <debbugs.gnu.org>?  If yes, the source code to tweak is
> there <https://git.elephly.net/gitweb.cgi?p=software/mumi.git> and I
> agree it would be quite easy; I will give a try if no one beats me.
> :-)

As the primary author of mumi (the software behind issues.guix.gnu.org)
I agree with Mark and think this is worth fixing.  I don’t want people
to have to use debbugs.gnu.org with its different features when we could
just make issues.guix.gnu.org do the right thing on simpler browsers.

issues.guix.gnu.org is supposed to offer a “superior” experience to
debbugs.gnu.org — it is supposed to be sufficient to replace it, not to
be merely an alternative view; while a primarily goal is indeed to make
it look “pretty” (i.e. some font and spacing improvements and very
subjective style changes that lean on what many users of Github and
Gitlab may be familiar with), it also provides features that
debbugs.gnu.org does not, such as listing “forgotten” issues, to search
without a somewhat complicated form, or the ability to comment from a
browser.

There is no good reason why this should not be usable by people who use
a simpler browser (I’m one of these people on some days).  If it turns
out to be tricky to implement or to cause a degraded experience for
those who use popular browsers we can still close this, but I think we
should at least try.

-- 
Ricardo




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-14 21:53           ` Ricardo Wurmus
@ 2020-09-15  1:06             ` Ricardo Wurmus
  2020-09-15  9:51               ` Jan Nieuwenhuizen
  2020-09-15 10:13             ` Mark H Weaver
  1 sibling, 1 reply; 13+ messages in thread
From: Ricardo Wurmus @ 2020-09-15  1:06 UTC (permalink / raw)
  To: zimoun; +Cc: maxim.cournoyer, guix.vits, 43166

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

The attached patch seems to fix the worst problems.

I’m marking up each line in a message with a “span” tag and a “line”
class; then I use CSS to visually separate the lines.  Simple browsers
that don’t support this CSS rely on “span” to be an inline tag; likewise
they rely on “div” to be a block tag, no matter what the CSS might say.

So the attached patch changes the tag from “span” to “div”, so simple
browsers will render each line on their own instead of joining them.
This seems to have no negative impact on the rendering in other
browsers.  It also shouldn’t be a problem going forward, as popular
powerful browsers allow me to style these “div” tags without
limitations.

What do you think?

-- 
Ricardo



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: p.patch --]
[-- Type: text/x-patch, Size: 5709 bytes --]

diff --git a/assets/css/screen.css b/assets/css/screen.css
index 684bc01..5d8513d 100644
--- a/assets/css/screen.css
+++ b/assets/css/screen.css
@@ -353,28 +353,28 @@ details {
     display: none;
 }
 
-.message span.line {
+.message div.line {
     white-space: pre-wrap;
     font-family: monospace;
     display: block;
 }
 
 /* diff styles */
-.message .diff span.line.diff.file {
+.message .diff div.line.diff.file {
     color: #005cc5;
 }
-.message .diff span.line.diff.separator {
+.message .diff div.line.diff.separator {
     color: #005cc5;
 }
-.message .diff span.line.diff.addition {
+.message .diff div.line.diff.addition {
     color: #22863a;
     background-color: #f0fff4;
 }
-.message .diff span.line.diff.deletion {
+.message .diff div.line.diff.deletion {
     color: #b31d28;
     background-color: #ffeef0;
 }
-.message .diff span.line.diff.range {
+.message .diff div.line.diff.range {
     color: #6f42c1;
     font-weight: bold;
 }
@@ -394,7 +394,7 @@ details {
 }
 
 /* quote styles */
-.message .quote span.line {
+.message .quote div.line {
     color: #3868cc;
 }
 
diff --git a/mumi/web/view/utils.scm b/mumi/web/view/utils.scm
index 3c95644..4a4ecb0 100644
--- a/mumi/web/view/utils.scm
+++ b/mumi/web/view/utils.scm
@@ -68,7 +68,7 @@ with the next context."
        (if (string-prefix? "--8<---------------cut here" line)
            (values blocks #f)
            (values (cons (add-block-line! block
-                                          `(span (@ (class "line")) ,line))
+                                          `(div (@ (class "line")) ,line))
                          other-blocks)
                    context)))
       ((eq? context 'diff)
@@ -79,17 +79,17 @@ with the next context."
            (let ((formatted-line
                   (cond
                    ((string= "---" line)
-                    `(span (@ (class "line diff separator")) ,line))
+                    `(div (@ (class "line diff separator")) ,line))
                    ((string-prefix? "+" line)
-                    `(span (@ (class "line diff addition")) ,line))
+                    `(div (@ (class "line diff addition")) ,line))
                    ((and (string-prefix? "-" line)
                          (not (string= "--" line))
                          (not (string= "-- " line)))
-                    `(span (@ (class "line diff deletion")) ,line))
+                    `(div (@ (class "line diff deletion")) ,line))
                    ((string-prefix? "@@" line)
-                    `(span (@ (class "line diff range")) ,line))
+                    `(div (@ (class "line diff range")) ,line))
                    (else
-                    `(span (@ (class "line")) ,line)))))
+                    `(div (@ (class "line")) ,line)))))
              (values (cons (add-block-line! block formatted-line)
                            other-blocks)
                      context))))
@@ -97,7 +97,7 @@ with the next context."
        (if (string-prefix? ">" line)
            ;; Add line to current block
            (values (cons (add-block-line! block
-                                          `(span (@ (class "line")) ,line))
+                                          `(div (@ (class "line")) ,line))
                          other-blocks)
                    context)
            ;; Retry
@@ -124,28 +124,28 @@ with the next context."
                           ((uri-string . rest)
                            (or (and=> (string->uri uri-string)
                                       (lambda (uri)
-                                        `(span (@ (class "line"))
-                                               ,(string-trim-right pre #\<)
-                                               (a (@ (href ,uri-string))
-                                                  ,uri-string)
-                                               ,(string-join rest " "))))
-                               `(span (@ (class "line")) ,line)))))))
+                                        `(div (@ (class "line"))
+                                              ,(string-trim-right pre #\<)
+                                              (a (@ (href ,uri-string))
+                                                 ,uri-string)
+                                              ,(string-join rest " "))))
+                               `(div (@ (class "line")) ,line)))))))
                ((or (string-prefix? "Signed-off-by" line)
                     (string-prefix? "Co-authored-by" line))
-                `(span (@ (class "line commit attribution")) ,line))
+                `(div (@ (class "line commit attribution")) ,line))
                ((or (string-prefix? "From: " line)
                     (string-prefix? "Date: " line)
                     (string-prefix? "Subject: " line))
-                `(span (@ (class "line commit header")) ,line))
+                `(div (@ (class "line commit header")) ,line))
                ((or (string-prefix? "* " line)
                     (string-prefix? " * " line))
-                `(span (@ (class "line commit changelog")) ,line))
+                `(div (@ (class "line commit changelog")) ,line))
                ((string-prefix? "diff --git" line)
-                `(span (@ (class "line diff file")) ,line))
+                `(div (@ (class "line diff file")) ,line))
                ((string-prefix? "--8<---------------cut here" line)
                 "")
                (else
-                `(span (@ (class "line")) ,line)))))
+                `(div (@ (class "line")) ,line)))))
          (if (eq? new-context context)
              (values (cons (add-block-line! block formatted-line)
                            other-blocks)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-15  1:06             ` Ricardo Wurmus
@ 2020-09-15  9:51               ` Jan Nieuwenhuizen
  0 siblings, 0 replies; 13+ messages in thread
From: Jan Nieuwenhuizen @ 2020-09-15  9:51 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: maxim.cournoyer, guix.vits, 43166

Ricardo Wurmus writes:

> The attached patch seems to fix the worst problems.

Ohh...thank you!!!  This makes issues at least readable in EWW.

It's a bit annoying to change issues URLs into bugs.gnu.org urls and
this also made me reluctant to share issues URLs -- altough I greatly
appreciate all the work you have been doing here: in heavyweight modern
mouse-shoving-browsers --that I personally try to avoid-- it really
looks beautiful.

> What do you think?

It seems that EWW ignores ’monospace’...

-.message span.line {
+.message div.line {
     white-space: pre-wrap;
     font-family: monospace;
     display: block;
 }

... here, or otherwise "eats" spaces; so diffs/patches are still a bit
annoying to read.  Ideas?

Greetings,
Janneke

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-14 21:53           ` Ricardo Wurmus
  2020-09-15  1:06             ` Ricardo Wurmus
@ 2020-09-15 10:13             ` Mark H Weaver
  2020-09-15 10:28               ` Mark H Weaver
  1 sibling, 1 reply; 13+ messages in thread
From: Mark H Weaver @ 2020-09-15 10:13 UTC (permalink / raw)
  To: Ricardo Wurmus, zimoun; +Cc: maxim.cournoyer, guix.vits, 43166

Ricardo Wurmus <rekado@elephly.net> writes:

>> On Mon, 14 Sep 2020 at 22:58, Mark H Weaver <mhw@netris.org> wrote:
>>
>>> For what it's worth: not everyone uses Emacs, and it would be good to
>>> support users who choose to use simpler software.  I guess that it would
>>> be quite easy to modify the software behind 'issues.guix.gnu.org' to
>>> generate HTML that works well with simpler web browsers, so I'd prefer
>>> to keep this bug open.  What do you think?
[...]
> As the primary author of mumi (the software behind issues.guix.gnu.org)
> I agree with Mark and think this is worth fixing.  [...]

Thank you, Ricardo.

> There is no good reason why this should not be usable by people who use
> a simpler browser (I’m one of these people on some days).  If it turns
> out to be tricky to implement or to cause a degraded experience for
> those who use popular browsers we can still close this, but I think we
> should at least try.

Fair enough.

Thanks also for your proposed patch to change some spans to divs.  It's
a significant improvement, but there remains a very serious problem:
multiple spaces are being collapsed into a single space, and leading
spaces are lost entirely.  This destroys the indentation of all inline
code and patches.  The two solutions I know are (1) to generate 'pre'
elements, or (2) to convert leading spaces and runs of two or more
spaces into runs of 'nbsp' entities.

(I'm deliberately avoiding HTML syntax in this email, for fear that some
email clients may try to render it).

My suggestion would be to generate 'pre' elements.  It would avoid runs
of 'nbsp' entites making the raw html larger and harder to read.  It
would also ensure that a fixed width font is used.

My first thought was to simply modify your patch to change the 'span's
with class "line" into 'pre's instead of 'div's.  If 'pre' comes with
default styling that you don't like, perhaps it could be overridden by
additional code in screen.css.  I guess this approach would likely work
well enough in practice.

However, I've noticed that in Dillo with CSS disabled, generating a
'pre' for each line makes the line spacing larger than would be ideal.
It seems that some vertical padding or margins are added around each
'pre'.  It's likely that many browsers do this in their default styling
for 'pre'.  With this in mind, it would perhaps be better to wrap a
single 'pre' around each message.  Then you could either (1) leave the
lines as 'span's and add a raw CR-LF after each line (which would make
the HTML source code more readable) or (2) change the 'span's to 'div's
as in your proposed patch.

Another issue, which affects Dillo, is that ASCII apostrophes (') are
being converted to 'apos' entities, which are not valid HTML 4.  Dillo
renders these as the raw source, namely "&" followed by "apos" and ";",
which corrupts English text.  I suggest removing the third entry in
%escape-chars in (mumi web sxml).  Is there a reason to keep it?

What do you think?

   Thanks again,
       Mark




^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.
  2020-09-15 10:13             ` Mark H Weaver
@ 2020-09-15 10:28               ` Mark H Weaver
  0 siblings, 0 replies; 13+ messages in thread
From: Mark H Weaver @ 2020-09-15 10:28 UTC (permalink / raw)
  To: Ricardo Wurmus, zimoun; +Cc: maxim.cournoyer, guix.vits, 43166

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]

Earlier, I wrote:
> However, I've noticed that in Dillo with CSS disabled, generating a
> 'pre' for each line makes the line spacing larger than would be ideal.
> It seems that some vertical padding or margins are added around each
> 'pre'.  It's likely that many browsers do this in their default styling
> for 'pre'.  With this in mind, it would perhaps be better to wrap a
> single 'pre' around each message.  Then you could either (1) leave the
> lines as 'span's and add a raw CR-LF after each line (which would make
> the HTML source code more readable) or (2) change the 'span's to 'div's
> as in your proposed patch.

Actually, I just found by experimentation that option (2) above doesn't
work well in either Lynx or Dillo.  Option (1) works well in the simple
browsers I've tried so far, which are Lynx, Dillo, Netsurf, and Eww.

       Mark



[-- Attachment #2: Example HTML for Option 1 --]
[-- Type: text/html, Size: 175 bytes --]

[-- Attachment #3: Example HTML for Option 2 --]
[-- Type: text/html, Size: 163 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-09-15 10:30 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-02  5:16 bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m Vitaliy Shatrov
2020-09-02 17:24 ` Mark H Weaver
2020-09-02 18:18   ` Mark H Weaver
2020-09-03 16:11 ` zimoun
2020-09-05 14:17   ` Vitaliy Shatrov
2020-09-14 13:03     ` Maxim Cournoyer
2020-09-14 20:55       ` Mark H Weaver
2020-09-14 21:17         ` zimoun
2020-09-14 21:53           ` Ricardo Wurmus
2020-09-15  1:06             ` Ricardo Wurmus
2020-09-15  9:51               ` Jan Nieuwenhuizen
2020-09-15 10:13             ` Mark H Weaver
2020-09-15 10:28               ` Mark H Weaver

unofficial mirror of bug-guix@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guix-bugs/0 guix-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guix-bugs guix-bugs/ https://yhetil.org/guix-bugs \
		bug-guix@gnu.org
	public-inbox-index guix-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.bugs
	nntp://news.gmane.io/gmane.comp.gnu.guix.bugs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git