bug#21032: package.el acts pecularly

bug#21032: package.el acts pecularly

[Vaidheeswaran C]

(custom-set-variables
  '(package-archives
   (quote
    (("gnu" . "http://elpa.gnu.org/packages/")
     ("ung" . "http://elpa.gnu.org/")))))


Do M-x list-packages, the messages buffer reports the following.

| Error contacting: http://elpa.gnu.org/archive-contents
| error in process filter: peculiar error: 404 [2 times]

I think package.el should offer to remove (or blacklist)
"misconfigured" archives or "disappeared" archives.  At the minimum,
it shouldn't throw 404-s in user's face.

bug#21032: package.el acts pecularly

[Artur Malabarba]

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

> I think package.el should offer to remove (or blacklist)
> "misconfigured" archives or "disappeared" archives.  At the minimum,
> it shouldn't throw 404-s in user's face.

Can we differentiate them from an archive that is temporarily down?

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

bug#21032: package.el acts pecularly

[Vaidheeswaran C]

On Saturday 11 July 2015 03:51 PM, Artur Malabarba wrote:
>> I think package.el should offer to remove (or blacklist)
>> > "misconfigured" archives or "disappeared" archives.  At the minimum,
>> > it shouldn't throw 404-s in user's face.
> Can we differentiate them from an archive that is temporarily down?
> 

We can definitely improve upon how the error gets reported.

    Error contacting: http://blah.blah.blah:/archive-contents
    error in process filter: peculiar error: 404 [2 times]

To the user, the first error gives sufficient hint for futher action.
I wonder what the second error says which the first error already
doesn't say.  Or may be there is indeed two errors and not one error
as I surmise.

ps: I wonder what contacting a file means :-P.

bug#21032: package.el acts pecularly

[Artur Malabarba]

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

> We can definitely improve upon how the error gets reported.

Certainly. Patches welcome. :-)

>     Error contacting: http://blah.blah.blah:/archive-contents
>     error in process filter: peculiar error: 404 [2 times]
>
> To the user, the first error gives sufficient hint for futher action.
> I wonder what the second error says which the first error already
> doesn't say.

The second error is saying that the page was not found. I imagine other
things that can happen are request time-out and certificate issues.

The 404 error is so well known that I'm not too worried about confusing the
user. I'd rather not hide this possibility-useful information in fear that
someone might be freaked out by it.

But improving its presentation is certainly possible.

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

bug#21032: package.el acts pecularly

[Stefan Monnier]

> The 404 error is so well known that I'm not too worried about confusing the
> user.

No, 404 is not well-known enough.  I for one have no idea which kind of
error this is (other than "the host itself was OK since got a reply, but
the file part of the URL lead to some kind of problem", and I wouldn't
assume every user to know that much).


        Stefan

bug#21032: package.el acts pecularly

[Vaidheeswaran C]

On Sunday 12 July 2015 04:28 AM, Artur Malabarba wrote:


>>     Error contacting: http://blah.blah.blah:/archive-contents
>>     error in process filter: peculiar error: 404 [2 times]

> The second error is saying that the page was not found.

Removing the second error and rewording the first error is good enough
for me.  Actually speaking, there is no "second" error.  There is only
one error.

The peculiar error is coming from `edebug-report-error'.  I really
think that user doesn't care much about the "innermost" errors.  So,
catching such errors and re-throwing it is a good idea.  Even if one
(as a developer) wants to see the "inner" errors, the *Messages*
should reflect the "innerness" of the fact by (say) parenthesizing it.


> I imagine other things that can happen are request time-out and
> certificate issues.

(The following pertains to url-http and may not concern package.el)

One way to handle the 404 (or for that matter any error) is to replace
it with it's string counterpart in `url-http-codes'.  If the error
code takes a "parameter", we can also convert entries like this:

    (404 not-found "Not found")

to

    (404 not-found "%s Not found")

etc.

bug#21032: package.el acts pecularly

[Artur Malabarba]

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

On Jul 12, 2015 3:28 AM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:
>
> > The 404 error is so well known that I'm not too worried about confusing
the
> > user.
>
> No, 404 is not well-known enough.  I for one have no idea which kind of
> error this is (other than "the host itself was OK since got a reply, but
> the file part of the URL lead to some kind of problem", and I wouldn't
> assume every user to know that much).

Actually, I think in that instance it was the server part that led to the
problem. However, I _think_ package.el (or url.el) doesn't have the
information to say that. That is, we would get the same error whether it's
an issue in the server part or the file part, wouldn't we?

Anyway, like I said, I'm fine with improving the error message. I just
meant I prefer the message to still say 404 somewhere (or whatever the
error code was).

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

bug#21032: package.el acts pecularly

[Artur Malabarba]

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

On Jul 12, 2015 6:37 AM, "Vaidheeswaran C" <
vaidheeswaran.chinnaraju@gmail.com> wrote:
>
> On Sunday 12 July 2015 04:28 AM, Artur Malabarba wrote:
>
>
> >>     Error contacting: http://blah.blah.blah:/archive-contents
> >>     error in process filter: peculiar error: 404 [2 times]
>
> > The second error is saying that the page was not found.
>
> Removing the second error and rewording the first error is good enough
> for me.  Actually speaking, there is no "second" error.  There is only
> one error.

Yes, it would be nice to improve the error message.

> The peculiar error is coming from `edebug-report-error'.  I really
> think that user doesn't care much about the "innermost" errors.  So,
> catching such errors and re-throwing it is a good idea.  Even if one
> (as a developer) wants to see the "inner" errors, the *Messages*
> should reflect the "innerness" of the fact by (say) parenthesizing it.

Sounds great. :-)

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

bug#21032: package.el acts pecularly

[Stefan Monnier]

> Actually, I think in that instance it was the server part that led to the
> problem.

Really?  I thought a 404 came from the remote server, which implies that
we managed to contact the server (i.e. the DNS name points to a live
machine).


        Stefan

bug#21032: package.el acts pecularly

[Artur Malabarba]

You're right. I misread the original message. I thought the user had
configured an invalid server, but I see now they just specified an
invalid file in the (valid) server.

2015-07-12 16:03 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> Actually, I think in that instance it was the server part that led to the
>> problem.
>
> Really?  I thought a 404 came from the remote server, which implies that
> we managed to contact the server (i.e. the DNS name points to a live
> machine).
>
>
>         Stefan

bug#21032: package.el acts pecularly

[Lars Ingebrigtsen]

Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com> writes:

> (custom-set-variables
>   '(package-archives
>    (quote
>     (("gnu" . "http://elpa.gnu.org/packages/")
>      ("ung" . "http://elpa.gnu.org/")))))
>
> Do M-x list-packages, the messages buffer reports the following.
>
> | Error contacting: http://elpa.gnu.org/archive-contents
> | error in process filter: peculiar error: 404 [2 times]
>
> I think package.el should offer to remove (or blacklist)
> "misconfigured" archives or "disappeared" archives.  At the minimum,
> it shouldn't throw 404-s in user's face.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

It looks like this has been fixed somewhat since this bug was reported.
It now reports:

Error retrieving: http://elpa.gnu.org/archive-contents (error http 404)

Which seems like a reasonable error message.

I don't think it would be appropriate to remove or block the URLs -- the
failure may be temporary, and it should be up to the user to remove the
archives themselves, so I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no