* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
[not found] ` <handler.s.C.146397087814700.transcript@debbugs.gnu.org>
@ 2016-05-23 15:40 ` Glenn Morris
2016-05-23 16:32 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Glenn Morris @ 2016-05-23 15:40 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Emacs developers
GNU bug tracker automated control server wrote:
> Processing commands for control@debbugs.gnu.org:
>
>> unblock 19759 by 23050
Again, this is not necessary. Closed bugs are not included in the list
at the top of http://debbugs.gnu.org/19759
Explicitly unblocking closed bugs is harmful, because if the bug needs
to be reopened for some reason, it won't reappear in the blocking list.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 15:40 ` Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch Glenn Morris
@ 2016-05-23 16:32 ` Eli Zaretskii
2016-05-23 16:44 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-23 16:32 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
> From: Glenn Morris <rgm@gnu.org>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Mon, 23 May 2016 11:40:48 -0400
>
> GNU bug tracker automated control server wrote:
>
> > Processing commands for control@debbugs.gnu.org:
> >
> >> unblock 19759 by 23050
>
> Again, this is not necessary.
I remembered you said that, but the facts are otherwise, sorry.
> Closed bugs are not included in the list at the top of
> http://debbugs.gnu.org/19759
They are for me. I do need glasses, but I still see very well, I
assure you.
> Explicitly unblocking closed bugs is harmful, because if the bug needs
> to be reopened for some reason, it won't reappear in the blocking list.
Sorry, I have no other way to display the list of blockers as it
really is. Maybe it's a debbugs bug, I don't know. But the problem
is real, and I did the only thing I know about that helps.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 16:32 ` Eli Zaretskii
@ 2016-05-23 16:44 ` Paul Eggert
2016-05-23 17:00 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-23 16:44 UTC (permalink / raw
To: Eli Zaretskii, Glenn Morris; +Cc: emacs-devel
On 05/23/2016 09:32 AM, Eli Zaretskii wrote:
>> >Closed bugs are not included in the list at the top of
>> >http://debbugs.gnu.org/19759
> They are for me.
What I've noticed, is that http://debbugs.gnu.org/19759 is often cached
(whether in my browser or somewhere else, I haven't checked), and when I
close a blocking bug the closed bug is still listed on that web page as
a blocker, until I refresh the cache. This is independent of whether the
bug is still listed as a blocker.
Glenn is right: it shouldn't be necessary to remove the bug as a
blocking bug. If there is something other than caching that is causing
this problem it'd be nice to know what it is.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 16:44 ` Paul Eggert
@ 2016-05-23 17:00 ` Eli Zaretskii
2016-05-23 17:32 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-23 17:00 UTC (permalink / raw
To: Paul Eggert; +Cc: rgm, emacs-devel
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 09:44:44 -0700
>
> On 05/23/2016 09:32 AM, Eli Zaretskii wrote:
> >> >Closed bugs are not included in the list at the top of
> >> >http://debbugs.gnu.org/19759
> > They are for me.
>
> What I've noticed, is that http://debbugs.gnu.org/19759 is often cached
> (whether in my browser or somewhere else, I haven't checked), and when I
> close a blocking bug the closed bug is still listed on that web page as
> a blocker, until I refresh the cache. This is independent of whether the
> bug is still listed as a blocker.
IME, the bug is still listed as blocking long after it was closed, no
matter how many times I refresh the browser page. But when I send the
control message to the tracker that unblocks it, the next refresh of
the browser updates the display by removing that bug.
So if some cache is involved in this, it reacts differently to closing
a bug and to removing it from the blockers list.
> Glenn is right: it shouldn't be necessary to remove the bug as a
> blocking bug. If there is something other than caching that is causing
> this problem it'd be nice to know what it is.
Hey, I tried, okay? I didn't do it because I deliberately ignored
Glenn's requests. I even told him in the past (off list) that what he
asks for didn't work for me. I just don't want to let software
problems prevent me from doing my job. If there's a bug there
somewhere that causes the phenomenon I described above, I'm all for
fixing it, and will be the first to avoid sending control messages
when it is fixed -- it's not like I enjoy writing those messages.
TIA
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 17:00 ` Eli Zaretskii
@ 2016-05-23 17:32 ` Paul Eggert
2016-05-23 17:41 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-23 17:32 UTC (permalink / raw
To: Eli Zaretskii; +Cc: rgm, emacs-devel
On 05/23/2016 10:00 AM, Eli Zaretskii wrote:
> IME, the bug is still listed as blocking long after it was closed, no
> matter how many times I refresh the browser page. But when I send the
> control message to the tracker that unblocks it, the next refresh of
> the browser updates the display by removing that bug.
Weird, that's not my experience: if I close a blocking bug, wait for a
bit (to make sure my bug-close email has hit the debbugs server), and
hard-refresh <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, the
blocking bug is no longer listed as a blocker.
I hard-refresh by using Firefox. I hold down the shift key, and press on
the cycle icon at the right of the main URL.
Perhaps the next time you close a blocking bug B, you might try looking
at B's page first and waiting until it's marked "done", and then try
refreshing Bug#19759. If you still see B listed as blocking in
Bug#19759, you might try using Firefox in the way that I described. This
might help us get to the bottom of the problem here.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 17:32 ` Paul Eggert
@ 2016-05-23 17:41 ` Eli Zaretskii
2016-05-23 18:28 ` John Wiegley
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-23 17:41 UTC (permalink / raw
To: Paul Eggert; +Cc: rgm, emacs-devel
> Cc: rgm@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 23 May 2016 10:32:08 -0700
>
> On 05/23/2016 10:00 AM, Eli Zaretskii wrote:
> > IME, the bug is still listed as blocking long after it was closed, no
> > matter how many times I refresh the browser page. But when I send the
> > control message to the tracker that unblocks it, the next refresh of
> > the browser updates the display by removing that bug.
>
> Weird, that's not my experience: if I close a blocking bug, wait for a
> bit (to make sure my bug-close email has hit the debbugs server), and
> hard-refresh <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, the
> blocking bug is no longer listed as a blocker.
>
> I hard-refresh by using Firefox. I hold down the shift key, and press on
> the cycle icon at the right of the main URL.
My point is that no such hard-refresh (about whose existence I didn't
even know) is needed when I send the control command to the tracker to
remove a big from the blocking list.
> Perhaps the next time you close a blocking bug B, you might try looking
> at B's page first and waiting until it's marked "done", and then try
> refreshing Bug#19759.
That's what I did. The bug was "done", but refereshing the 19759 page
didn't remove it. When I sent the control message, it was removed on
the next refresh a few minutes later.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 17:41 ` Eli Zaretskii
@ 2016-05-23 18:28 ` John Wiegley
2016-05-23 18:39 ` John Mastro
2016-05-24 15:38 ` Glenn Morris
0 siblings, 2 replies; 33+ messages in thread
From: John Wiegley @ 2016-05-23 18:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: rgm, Paul Eggert, emacs-devel
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>> Perhaps the next time you close a blocking bug B, you might try looking at
>> B's page first and waiting until it's marked "done", and then try
>> refreshing Bug#19759.
> That's what I did. The bug was "done", but refereshing the 19759 page didn't
> remove it. When I sent the control message, it was removed on the next
> refresh a few minutes later.
Clearly we need something that doesn't require jumping through hoops, such as
a hard refresh (which I don't even know how to do outside of Firefox). If that
means unblocking bugs for now, then debbugs needs some improvement.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 18:28 ` John Wiegley
@ 2016-05-23 18:39 ` John Mastro
2016-05-23 18:48 ` Eli Zaretskii
2016-05-24 15:38 ` Glenn Morris
1 sibling, 1 reply; 33+ messages in thread
From: John Mastro @ 2016-05-23 18:39 UTC (permalink / raw
To: emacs-devel; +Cc: rgm, Eli Zaretskii, Paul Eggert
John Wiegley <jwiegley@gmail.com> wrote:
> Clearly we need something that doesn't require jumping through hoops, such as
> a hard refresh (which I don't even know how to do outside of Firefox). If that
> means unblocking bugs for now, then debbugs needs some improvement.
FWIW, I believe [C-f5] will work for all the major browsers on both
GNU/Linux and Windows. (I think it's Command-Shift-r on OS X but I'm not
as sure.)
John
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 18:39 ` John Mastro
@ 2016-05-23 18:48 ` Eli Zaretskii
2016-05-24 3:50 ` John Wiegley
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-23 18:48 UTC (permalink / raw
To: John Mastro; +Cc: rgm, eggert, emacs-devel
> From: John Mastro <john.b.mastro@gmail.com>
> Date: Mon, 23 May 2016 11:39:48 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Paul Eggert <eggert@cs.ucla.edu>, rgm@gnu.org
>
> John Wiegley <jwiegley@gmail.com> wrote:
> > Clearly we need something that doesn't require jumping through hoops, such as
> > a hard refresh (which I don't even know how to do outside of Firefox). If that
> > means unblocking bugs for now, then debbugs needs some improvement.
>
> FWIW, I believe [C-f5] will work for all the major browsers on both
> GNU/Linux and Windows. (I think it's Command-Shift-r on OS X but I'm not
> as sure.)
FWIW, I believe that no such gesture should be needed to begin with, a
simple refresh should do.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 18:48 ` Eli Zaretskii
@ 2016-05-24 3:50 ` John Wiegley
0 siblings, 0 replies; 33+ messages in thread
From: John Wiegley @ 2016-05-24 3:50 UTC (permalink / raw
To: Eli Zaretskii; +Cc: John Mastro, eggert, emacs-devel, rgm
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> FWIW, I believe that no such gesture should be needed to begin with, a
> simple refresh should do.
I also agree; it's confusing to have to remember that special need for this
one project.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-23 18:28 ` John Wiegley
2016-05-23 18:39 ` John Mastro
@ 2016-05-24 15:38 ` Glenn Morris
2016-05-24 15:41 ` Kaushal Modi
1 sibling, 1 reply; 33+ messages in thread
From: Glenn Morris @ 2016-05-24 15:38 UTC (permalink / raw
To: emacs-devel
Please try to use standard ctrl-f5 or equivalent rather than unnecessary
unblock commands.
https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
There won't be any changes to debbugs.gnu.org.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 15:38 ` Glenn Morris
@ 2016-05-24 15:41 ` Kaushal Modi
2016-05-24 15:59 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Kaushal Modi @ 2016-05-24 15:41 UTC (permalink / raw
To: Glenn Morris, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Tue, May 24, 2016 at 11:38 AM Glenn Morris <rgm@gnu.org> wrote:
>
> Please try to use standard ctrl-f5 or equivalent rather than unnecessary
> unblock commands.
>
> https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
>
> There won't be any changes to debbugs.gnu.org.
>
I agree, Ctrl-F5 has been my natural reflex when the browsers fetch stale
stuff from their cache. I've been using that on Chrome/Firefox for ever. As
you said, this has nothing to do with debbugs but with browser
technologies.
--
--
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 1055 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 15:41 ` Kaushal Modi
@ 2016-05-24 15:59 ` Eli Zaretskii
2016-05-24 16:47 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-24 15:59 UTC (permalink / raw
To: Kaushal Modi; +Cc: rgm, emacs-devel
> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 24 May 2016 15:41:40 +0000
>
> Please try to use standard ctrl-f5 or equivalent rather than unnecessary
> unblock commands.
>
> https://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache
>
> There won't be any changes to debbugs.gnu.org.
>
> I agree, Ctrl-F5 has been my natural reflex when the browsers fetch stale stuff from their cache. I've been
> using that on Chrome/Firefox for ever. As you said, this has nothing to do with debbugs but with browser
> technologies.
As I've explained numerous times earlier, I have hard time believing
this is a browser issue, because just clicking on the "refresh" icon
immediately refreshes the list of blocking bugs after I send an
unblock command to debbugs.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 15:59 ` Eli Zaretskii
@ 2016-05-24 16:47 ` Paul Eggert
2016-05-24 17:25 ` Eli Zaretskii
2016-05-25 18:23 ` Paul Eggert
0 siblings, 2 replies; 33+ messages in thread
From: Paul Eggert @ 2016-05-24 16:47 UTC (permalink / raw
To: Eli Zaretskii, Kaushal Modi; +Cc: rgm, emacs-devel
On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
> I have hard time believing this is a browser issue
I don't. There are different kinds of refreshes, and it's possible that
a partial refresh won't give you a new page at the same time that a full
refresh would.
Anyway, this question should be resolvable easily the next time you fix
a blocking bug, by trying out Firefox on the bug in question.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 16:47 ` Paul Eggert
@ 2016-05-24 17:25 ` Eli Zaretskii
2016-05-25 1:22 ` Chad Brown
2016-05-26 17:00 ` Glenn Morris
2016-05-25 18:23 ` Paul Eggert
1 sibling, 2 replies; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-24 17:25 UTC (permalink / raw
To: Paul Eggert; +Cc: rgm, emacs-devel, kaushal.modi
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 24 May 2016 09:47:35 -0700
> Cc: rgm@gnu.org, emacs-devel@gnu.org
>
> On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
> > I have hard time believing this is a browser issue
>
> I don't. There are different kinds of refreshes, and it's possible that
> a partial refresh won't give you a new page at the same time that a full
> refresh would.
That makes no sense at all. It's the same browser and the same Web
page. How can the browser know to refresh it in one case, but not in
the other?
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 17:25 ` Eli Zaretskii
@ 2016-05-25 1:22 ` Chad Brown
2016-05-25 2:46 ` Eli Zaretskii
2016-05-26 17:00 ` Glenn Morris
1 sibling, 1 reply; 33+ messages in thread
From: Chad Brown @ 2016-05-25 1:22 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1798 bytes --]
> On 24 May 2016, at 10:25, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Tue, 24 May 2016 09:47:35 -0700
>> Cc: rgm@gnu.org, emacs-devel@gnu.org
>>
>> On 05/24/2016 08:59 AM, Eli Zaretskii wrote:
>>> I have hard time believing this is a browser issue
>>
>> I don't. There are different kinds of refreshes, and it's possible that
>> a partial refresh won't give you a new page at the same time that a full
>> refresh would.
>
> That makes no sense at all. It's the same browser and the same Web
> page. How can the browser know to refresh it in one case, but not in
> the other?
Because the refresh button doesn’t ask the web server for a new copy of the page; it instead asks the local cache to check and see if it thinks a new copy of the web page is needed. There are many circumstances where the local cache controller can ask the web server and get back what is effectively the wrong answer. C-F5 is a standard command that tells the web browser to have the local cache get a new copy of the page, without asking the web server if it can use the cached copy instead. In practice, this sort of thing happens in certain corners often enough that many people have developed the habit of always using the reload-dammit command when they’re sure they want a fresh page (see Kaushal Modi’s message, for example).
Debbugs could be changed to always give out a new copy of the page, with the concomitant increase in load you might expect from always bypassing the cache. It could presumably be changed to never give out the wrong answer, but (if this is what is happening in this case — it’s hard to tell without someone trying) that depends on specific effort being put into debbugs.
I hope that helps.
~Chad
[-- Attachment #2: Type: text/html, Size: 5080 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 1:22 ` Chad Brown
@ 2016-05-25 2:46 ` Eli Zaretskii
2016-05-25 5:13 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-25 2:46 UTC (permalink / raw
To: Chad Brown; +Cc: emacs-devel
> From: Chad Brown <yandros@gmail.com>
> Date: Tue, 24 May 2016 18:22:33 -0700
> Cc: emacs-devel <emacs-devel@gnu.org>
>
> That makes no sense at all. It's the same browser and the same Web
> page. How can the browser know to refresh it in one case, but not in
> the other?
>
> Because the refresh button doesn’t ask the web server for a new copy of the page; it instead asks the local
> cache to check and see if it thinks a new copy of the web page is needed. There are many circumstances
> where the local cache controller can ask the web server and get back what is effectively the wrong answer.
So you are saying that this always brings the cached copy when a bug
is closed, and always brings the correct copy when a bug is deleted
from the blocking list? That makes no sense to me: the browser and
the cache don't understand the semantics of each operation at all, so
I don't see how they could do different stuff in each case.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 2:46 ` Eli Zaretskii
@ 2016-05-25 5:13 ` Paul Eggert
0 siblings, 0 replies; 33+ messages in thread
From: Paul Eggert @ 2016-05-25 5:13 UTC (permalink / raw
To: Eli Zaretskii, Chad Brown; +Cc: emacs-devel
Eli Zaretskii wrote:
> That makes no sense to me: the browser and
> the cache don't understand the semantics of each operation at all
They don't need to. They can rely on non-semantic metadata that the origin web
server provides, e.g., an entity tag. However, if the origin web server is
misbehaving when a blocking bug is fixed, or if the browser or intermediate
cache is misbehaving in that particular case, one could see the symptoms you're
observing.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 16:47 ` Paul Eggert
2016-05-24 17:25 ` Eli Zaretskii
@ 2016-05-25 18:23 ` Paul Eggert
2016-05-25 18:51 ` Clément Pit--Claudel
1 sibling, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-25 18:23 UTC (permalink / raw
To: Eli Zaretskii, Kaushal Modi; +Cc: rgm, emacs-devel
On 05/24/2016 09:47 AM, Paul Eggert wrote:
> this question should be resolvable easily the next time you fix a
> blocking bug, by trying out Firefox on the bug in question.
I just now tested this with Firefox and it worked as I expected. I
closed Bug#23612 (a blocking bug) and then visited this web page:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759
Firefox showed the bug as still blocking. I refreshed the web page by
left-clicking with the mouse on the refresh icon just to the right of
the URL in the menu bar. Firefox still showed the bug as blocking. I
then did a shift-left-click on the same icon (a full refresh). Firefox
updated the web page properly.
So, a full-refresh appears to be enough to work around the problem, at
least for me (Firefox, Fedora 23 x86-64).
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 18:23 ` Paul Eggert
@ 2016-05-25 18:51 ` Clément Pit--Claudel
2016-05-25 18:56 ` Clément Pit--Claudel
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Clément Pit--Claudel @ 2016-05-25 18:51 UTC (permalink / raw
To: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 1400 bytes --]
On 2016-05-25 14:23, Paul Eggert wrote:
> On 05/24/2016 09:47 AM, Paul Eggert wrote:
>> this question should be resolvable easily the next time you fix a blocking bug, by trying out Firefox on the bug in question.
>
> I just now tested this with Firefox and it worked as I expected. I closed Bug#23612 (a blocking bug) and then visited this web page:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759
>
> Firefox showed the bug as still blocking. I refreshed the web page by left-clicking with the mouse on the refresh icon just to the right of the URL in the menu bar. Firefox still showed the bug as blocking. I then did a shift-left-click on the same icon (a full refresh). Firefox updated the web page properly.
>
> So, a full-refresh appears to be enough to work around the problem, at least for me (Firefox, Fedora 23 x86-64).
Doesn't this indicate a bug in debbugs?
Presumably when you did the simple refresh Firefox queried the server to know if a more up-to-date version of the page was available (using the X-Modified-Since header); it should have received a positive answer, but instead received a negative one (that would be the bug).
Doing a hard refresh forces Firefox to bypass its cache; but ideally, debbugs should respond correctly to Firefox' queries and indicate that the page was in fact modified.
Or am I misunderstanding something?
Clément.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 18:51 ` Clément Pit--Claudel
@ 2016-05-25 18:56 ` Clément Pit--Claudel
2016-05-25 19:33 ` Dmitry Gutov
2016-05-25 21:51 ` Paul Eggert
2 siblings, 0 replies; 33+ messages in thread
From: Clément Pit--Claudel @ 2016-05-25 18:56 UTC (permalink / raw
To: emacs-devel
[-- Attachment #1.1: Type: text/plain, Size: 135 bytes --]
On 2016-05-25 14:51, Clément Pit--Claudel wrote:
> using the X-Modified-Since header
This should have been 'If-Modified-Since'
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 18:51 ` Clément Pit--Claudel
2016-05-25 18:56 ` Clément Pit--Claudel
@ 2016-05-25 19:33 ` Dmitry Gutov
2016-05-25 21:51 ` Paul Eggert
2 siblings, 0 replies; 33+ messages in thread
From: Dmitry Gutov @ 2016-05-25 19:33 UTC (permalink / raw
To: Clément Pit--Claudel, emacs-devel
On 05/25/2016 09:51 PM, Clément Pit--Claudel wrote:
>> So, a full-refresh appears to be enough to work around the problem, at least for me (Firefox, Fedora 23 x86-64).
>
> Doesn't this indicate a bug in debbugs?
It does, but it's unlikely that anybody's going to work on fixing it
(our debbugs is a heavily customized fork, so we can't rely on the
upstream in this either).
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 18:51 ` Clément Pit--Claudel
2016-05-25 18:56 ` Clément Pit--Claudel
2016-05-25 19:33 ` Dmitry Gutov
@ 2016-05-25 21:51 ` Paul Eggert
2016-05-26 2:44 ` Eli Zaretskii
2 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-25 21:51 UTC (permalink / raw
To: Clément Pit--Claudel, emacs-devel
On 05/25/2016 11:51 AM, Clément Pit--Claudel wrote:
> Presumably when you did the simple refresh Firefox queried the server
> to know if a more up-to-date version of the page was available (using
> the X-Modified-Since header); it should have received a positive
> answer, but instead received a negative one (that would be the bug).
Yes, in this case the request headers include "Cache-Control: max-age=0"
and "If-Modified-Since: |Tue, 24 May 2016 17:50:01 GMT". Firefox is
using If-Modified-Since because the HTTP response from debbugs.gnu.org
for <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759> contains a
header line "Last-Modified: Tue, 24 May 2016 17:50:01 GMT". This
Last-Modified time is the|time that Glenn added Bug#23612 as a blocker
for Bug#|19759|. However, that's the wrong time value: the Last-Modified
time should be at least Wed, 25 May 2016 17:45:21 GMT, which is when I
fixed the blocking bug #23611, as this fix caused a change to the
contents of <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>.
> Doing a hard refresh forces Firefox to bypass its cache; but ideally,
> debbugs should respond correctly to Firefox' queries and indicate that
> the page was in fact modified.
Yes, the bug is clearly on the debbugs side here. That being said, the
workaround is to use a shift-reload, which causes Firefox to specify
"cache-control: no"in its request, which in turn causes debbugs to
recalculate the page.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-25 21:51 ` Paul Eggert
@ 2016-05-26 2:44 ` Eli Zaretskii
2016-05-26 5:08 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-26 2:44 UTC (permalink / raw
To: Paul Eggert; +Cc: clement.pit, emacs-devel
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 25 May 2016 14:51:32 -0700
>
> > Doing a hard refresh forces Firefox to bypass its cache; but ideally,
> > debbugs should respond correctly to Firefox' queries and indicate that
> > the page was in fact modified.
>
> Yes, the bug is clearly on the debbugs side here. That being said, the
> workaround is to use a shift-reload, which causes Firefox to specify
> "cache-control: no"in its request, which in turn causes debbugs to
> recalculate the page.
The bug seems to be that the removal of a closed bug from the blockers
list takes several hours, which is much more than one can be
reasonably expect to wait. For example, one bug was closed yesterday
6.5 hours before I got to refreshing the list, and then just clicking
the refresh icon showed the updated list. By contrast, explicitly
removing a bug from the list by a debbugs command results in an
instant update that doesn't need any workarounds.
That said, all this thread is a tempest in a teapot, because adding a
bug to the list (if it becomes open again) takes just a few moments.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 2:44 ` Eli Zaretskii
@ 2016-05-26 5:08 ` Paul Eggert
2016-05-26 15:09 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-26 5:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: clement.pit, emacs-devel
Eli Zaretskii wrote:
> The bug seems to be that the removal of a closed bug from the blockers
> list takes several hours
That's not been my experience. There is never a several-hour wait. If I close
the blocking bug B via email, and wait a minute or two and verify that it's
closed by visiting its bug page and forcing a refresh, and then visit
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, what I observe is that
Bug#19759 still lists B as blocking (due to the debbugs bug). If I refresh the
Bug#19759 page in the routine way it will continue to list B as blocking. If I
do a full refresh (by shift-left-mouse-click) then the Bug#19759 page will no
longer list B as blocking; this is always immediate, assuming B has been closed
already.
> adding a
> bug to the list (if it becomes open again) takes just a few moments.
Sure, but it's easy to forget to add B as a blocker, and indeed the person
reopening B may not even know that B was a blocker and should become a blocker
again. In contrast, simply closing B in the first place will mean that reopening
B later will do the right thing without further thought.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 5:08 ` Paul Eggert
@ 2016-05-26 15:09 ` Eli Zaretskii
2016-05-26 15:27 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-26 15:09 UTC (permalink / raw
To: Paul Eggert; +Cc: clement.pit, emacs-devel
> Cc: clement.pit@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 25 May 2016 22:08:30 -0700
>
> Eli Zaretskii wrote:
> > The bug seems to be that the removal of a closed bug from the blockers
> > list takes several hours
>
> That's not been my experience. There is never a several-hour wait. If I close
> the blocking bug B via email, and wait a minute or two and verify that it's
> closed by visiting its bug page and forcing a refresh, and then visit
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19759>, what I observe is that
> Bug#19759 still lists B as blocking (due to the debbugs bug). If I refresh the
> Bug#19759 page in the routine way it will continue to list B as blocking. If I
> do a full refresh (by shift-left-mouse-click) then the Bug#19759 page will no
> longer list B as blocking; this is always immediate, assuming B has been closed
> already.
I was talking about a simple refresh, not forced refresh.
And it looks like a problem is more complex than I thought: on one
machine I tried this even 24 hours was not enough to refresh the page.
> > adding a
> > bug to the list (if it becomes open again) takes just a few moments.
>
> Sure, but it's easy to forget to add B as a blocker, and indeed the person
> reopening B may not even know that B was a blocker and should become a blocker
> again. In contrast, simply closing B in the first place will mean that reopening
> B later will do the right thing without further thought.
You can rely on me: I won't forget.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 15:09 ` Eli Zaretskii
@ 2016-05-26 15:27 ` Paul Eggert
2016-05-26 15:48 ` Eli Zaretskii
0 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-26 15:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: clement.pit, emacs-devel
On 05/26/2016 08:09 AM, Eli Zaretskii wrote:
> And it looks like a problem is more complex than I thought: on one
> machine I tried this even 24 hours was not enough to refresh the page.
The number of hours is not that relevant. If nobody does a full refresh,
and nobody edits Bug#19759 more directly, that web page can stay wrong
for weeks. That's how debbugs works.
In contrast, full-refresh fixes the problem right away, without having
to make otherwise-superfluous-and-arguably-misleading edits to Bug#19759.
> You can rely on me: I won't forget.
I'm not worried about you! I'm worried about the rest of us -- the mere
mortals.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 15:27 ` Paul Eggert
@ 2016-05-26 15:48 ` Eli Zaretskii
2016-05-26 16:01 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2016-05-26 15:48 UTC (permalink / raw
To: Paul Eggert; +Cc: clement.pit, emacs-devel
> Cc: clement.pit@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 26 May 2016 08:27:40 -0700
>
> On 05/26/2016 08:09 AM, Eli Zaretskii wrote:
>
> > And it looks like a problem is more complex than I thought: on one
> > machine I tried this even 24 hours was not enough to refresh the page.
>
> The number of hours is not that relevant. If nobody does a full refresh,
> and nobody edits Bug#19759 more directly, that web page can stay wrong
> for weeks. That's how debbugs works.
>
> In contrast, full-refresh fixes the problem right away, without having
> to make otherwise-superfluous-and-arguably-misleading edits to Bug#19759.
So you are saying that to see the page refreshed I need to wait for
someone to force debbugs to refresh it? Beautiful!
> > You can rely on me: I won't forget.
>
> I'm not worried about you! I'm worried about the rest of us -- the mere
> mortals.
You can all rely on me.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 15:48 ` Eli Zaretskii
@ 2016-05-26 16:01 ` Paul Eggert
2016-05-26 16:43 ` John Wiegley
0 siblings, 1 reply; 33+ messages in thread
From: Paul Eggert @ 2016-05-26 16:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: clement.pit, emacs-devel
On 05/26/2016 08:48 AM, Eli Zaretskii wrote:
> So you are saying that to see the page refreshed I need to wait for
> someone to force debbugs to refresh it?
Not at all. You don't need to wait. You can easily force debbugs to
refresh it yourself, by doing a shift-reload from Firefox. Shift-reload
doesn't make any changes to the debbugs database; it merely fixes the
web page. And (at least for me) it's easier than fiddling with the list
of which blocks block what.
I suppose you're using some sort of Emacs UI to alter the blocking bugs
list? If so, perhaps someone could add a button to that UI that says
"Recalculate the debbugs web page for Bug#N", where pressing the button
would do the equivalent of a shift-reload from Firefox.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 16:01 ` Paul Eggert
@ 2016-05-26 16:43 ` John Wiegley
2016-05-26 16:51 ` Paul Eggert
0 siblings, 1 reply; 33+ messages in thread
From: John Wiegley @ 2016-05-26 16:43 UTC (permalink / raw
To: Paul Eggert; +Cc: Eli Zaretskii, clement.pit, emacs-devel
>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:
> Not at all. You don't need to wait. You can easily force debbugs to refresh
> it yourself, by doing a shift-reload from Firefox. Shift-reload doesn't make
> any changes to the debbugs database; it merely fixes the web page. And (at
> least for me) it's easier than fiddling with the list of which blocks block
> what.
> I suppose you're using some sort of Emacs UI to alter the blocking bugs
> list? If so, perhaps someone could add a button to that UI that says
> "Recalculate the debbugs web page for Bug#N", where pressing the button
> would do the equivalent of a shift-reload from Firefox.
Paul, is it acknowledged that this behavior is wrong and a bug, and should be
fixed? Adding a button to the UI should not be necessary.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 16:43 ` John Wiegley
@ 2016-05-26 16:51 ` Paul Eggert
0 siblings, 0 replies; 33+ messages in thread
From: Paul Eggert @ 2016-05-26 16:51 UTC (permalink / raw
To: Eli Zaretskii, clement.pit, emacs-devel
On 05/26/2016 09:43 AM, John Wiegley wrote:
> Paul, is it acknowledged that this behavior is wrong and a bug, and should be
> fixed?
Sure, but what we're hearing from our debbugs expert is "good luck with
that". Apparently debbugs is not going to be fixed. Perhaps we should
change our bug-reporting mechanism to something else, but in the
meantime we need to deal with this relatively-minor gotcha.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-24 17:25 ` Eli Zaretskii
2016-05-25 1:22 ` Chad Brown
@ 2016-05-26 17:00 ` Glenn Morris
2016-05-26 18:09 ` Glenn Morris
1 sibling, 1 reply; 33+ messages in thread
From: Glenn Morris @ 2016-05-26 17:00 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Paul Eggert, emacs-devel, kaushal.modi
The issue (I imagine) is that closing bug #456 which blocks bug #123
does not *directly* affect the status of bug#123. (In contrast, removing
#456 from #123's list of blockers does.) If someone wants to change
this, try looking at blockedby and last_modified in debbug's Status.pm
(but I have no idea how/if any of that propagates to the http modified
headers of CGI output). Obviously this is a debbugs bug, like many
things are, but a trivial one with an easy workaround, so I don't intend
to work on it. (No-one else has ever sent me a debbugs patch for
anything, but if they sent one for this I would apply it, if safe.)
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch
2016-05-26 17:00 ` Glenn Morris
@ 2016-05-26 18:09 ` Glenn Morris
0 siblings, 0 replies; 33+ messages in thread
From: Glenn Morris @ 2016-05-26 18:09 UTC (permalink / raw
To: emacs-devel
Technical comments welcome at http://debbugs.gnu.org/23624
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2016-05-26 18:09 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <83oa7x5wpc.fsf@gnu.org>
[not found] ` <handler.s.C.146397087814700.transcript@debbugs.gnu.org>
2016-05-23 15:40 ` Processed: Re: bug#19717: 24.4.50; printing.el still uses ps-eval-switch Glenn Morris
2016-05-23 16:32 ` Eli Zaretskii
2016-05-23 16:44 ` Paul Eggert
2016-05-23 17:00 ` Eli Zaretskii
2016-05-23 17:32 ` Paul Eggert
2016-05-23 17:41 ` Eli Zaretskii
2016-05-23 18:28 ` John Wiegley
2016-05-23 18:39 ` John Mastro
2016-05-23 18:48 ` Eli Zaretskii
2016-05-24 3:50 ` John Wiegley
2016-05-24 15:38 ` Glenn Morris
2016-05-24 15:41 ` Kaushal Modi
2016-05-24 15:59 ` Eli Zaretskii
2016-05-24 16:47 ` Paul Eggert
2016-05-24 17:25 ` Eli Zaretskii
2016-05-25 1:22 ` Chad Brown
2016-05-25 2:46 ` Eli Zaretskii
2016-05-25 5:13 ` Paul Eggert
2016-05-26 17:00 ` Glenn Morris
2016-05-26 18:09 ` Glenn Morris
2016-05-25 18:23 ` Paul Eggert
2016-05-25 18:51 ` Clément Pit--Claudel
2016-05-25 18:56 ` Clément Pit--Claudel
2016-05-25 19:33 ` Dmitry Gutov
2016-05-25 21:51 ` Paul Eggert
2016-05-26 2:44 ` Eli Zaretskii
2016-05-26 5:08 ` Paul Eggert
2016-05-26 15:09 ` Eli Zaretskii
2016-05-26 15:27 ` Paul Eggert
2016-05-26 15:48 ` Eli Zaretskii
2016-05-26 16:01 ` Paul Eggert
2016-05-26 16:43 ` John Wiegley
2016-05-26 16:51 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.