bug#55618: Allow patching from mummi issues

bug#55618: Allow patching from mummi issues

[Nicolas Graves via Bug reports for GNU Guix]

Hi !

I was tring to fix a local build using an online patch on mummi, this
way :

(define-public my-emacs-list-utils
  (package
    (inherit emacs-list-utils)
    (name "my-emacs-list-utils")
    (version "0.4.6")
    (source
     (origin
       (method git-fetch)
       (uri (git-reference
             (url "https://github.com/rolandwalker/list-utils")
             (commit (string-append "v" version))))
       (file-name (git-file-name name version))
       (sha256
        (base32 "07hbz2md52ccy95gv4d5n6szrfmpfqf3w4kwqdg2cf54c7kgf7hw"))
       (patches
        (list
         (origin
            (method url-fetch)
            (uri "https://issues.guix.gnu.org/issue/55498/attachment/0")
            (sha256
             (base32
              "1ysjb23g21m0jhkn63hq56snjd6skd9pl58c365g519q03hq5s87")))))))))

As it is a quick and convenient way to apply someone's work while the
patch is not upstream, I expected it to work, but it failed with the
following error during download:

Starting download of /gnu/store/v91i1m61skr42136vnxhzm4gzyidp11y-0
From https://issues.guix.gnu.org/issue/55498/attachment/0...
Bad media-type header component: text

I don't now if the fix should come from mummi's or guix's side, but I
found it a relevant way to quickly test an existing patch for one's
needs.

Thanks if you can enable this type of patches, or get alternatives if
there are. Also thanks for all the work on guix, it's amazing.

Nicolas Graves

bug#55618: Allow patching from mummi issues

[Maxime Devos]

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

Nicolas Graves via Bug reports for GNU Guix schreef op wo 25-05-2022 om
00:14 [+0200]:
> Starting download of /gnu/store/v91i1m61skr42136vnxhzm4gzyidp11y-0
> From https://issues.guix.gnu.org/issue/55498/attachment/0...
> Bad media-type header component: text

That page sets

 Content-Type text;charset=utf-8

which apperently Guile's HTTP parser doesn't like.
Maybe it can be changed to text/patch (*) or text/diff (*) (or
text/plain) instead?

(*) x- prefixes are deprecated

Or is text;charset=utf-8 actually valid?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#55618: Allow patching from mummi issues

[Daniel Meißner via Bug reports for GNU Guix]

Hi,

Maxime Devos writes:

> Or is text;charset=utf-8 actually valid?

There is a clear answer from RFC 2045, Section 5.1 [1]:

> Note also that a subtype specification is MANDATORY -- it may not be
> omitted from a Content-Type header field.

1: https://datatracker.ietf.org/doc/html/rfc2045#section-5.1

Best

-- 
Daniel

bug#55618: Allow patching from mummi issues

[Liliana Marie Prikler]

Am Mittwoch, dem 25.05.2022 um 13:06 +0200 schrieb Maxime Devos:
> is text;charset=utf-8 actually valid?
Not as far as I'm aware.  The first part should be a proper MIME type,
which ought to be registered by the IANA [1].

> That page sets
> 
>  Content-Type text;charset=utf-8
> 
> which apperently Guile's HTTP parser doesn't like.
> Maybe it can be changed to text/patch (*) or text/diff (*) (or
> text/plain) instead?
> 
> (*) x- prefixes are deprecated
As fate would have it, neither text/patch nor text/diff are registered
over at the IANA [1].  As far as I'm aware, both (Linux/GNU)
applications and browsers should understand the x- notation.

Cheers


[1] https://www.iana.org/assignments/media-types/media-types.xhtml

bug#55618: Allow patching from mummi issues

[Maxime Devos]

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

Liliana Marie Prikler schreef op wo 25-05-2022 om 14:16 [+0200]:
> Am Mittwoch, dem 25.05.2022 um 13:06 +0200 schrieb Maxime Devos:
> > is text;charset=utf-8 actually valid?
> Not as far as I'm aware.  The first part should be a proper MIME type,
> which ought to be registered by the IANA [1].
> 
> > That page sets
> > 
> >  Content-Type text;charset=utf-8
> > 
> > which apperently Guile's HTTP parser doesn't like.
> > Maybe it can be changed to text/patch (*) or text/diff (*) (or
> > text/plain) instead?
> > 
> > (*) x- prefixes are deprecated
> As fate would have it, neither text/patch nor text/diff are registered
> over at the IANA [1].  As far as I'm aware, both (Linux/GNU)
> applications and browsers should understand the x- notation.

Neither is text/x-patch nor text/diff.  I am not aware of any browser
that supports text/x-patch or text/x-diff (or text/patch for that
matter).  If there are any applications that understand text/x-patch
but not text/patch, it should be easy to patch them to support the more
standard-ish text/patch (or text/diff).

(Registering them would be even better, but AFAICT no-one is interested
in writing a formal spec to submit.)

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]