On Mon, 20 Jan 2020 16:51:34 -0500 Calum McConnell wrote:

[...]
> > > Sorry about taking so long to get back to you: I have been really
> > > busy
> > > recently.
> > 
> > No problem, I got ill immediately afterwards!  :-/
> 
> That sucks, hope you're doing better!

Yeah, definitely. Thanks for asking.   :-)

[...]
> > Did you fix the installation status of firefox-esr?
> > What's the output of the command
> > 
> >   $ dpkg -l | grep firefox
> > 
> > on your system, now?
> 
> I put it below: I did some re-wrapping of lines, because I couldnt
> quickly figure out how to make evolution stop wrapping the selection.
> 
> $ dpkg -l | grep firefox
> ii  firefox-esr                                   
> 68.4.1esr-1                          amd64        
> Mozilla Firefox web browser - Extended Support Release (ESR)

It looks fine, now.

[...]
> > OK, I think I shared enough of my headache!   ;-)
> 
> Thanks for the explaination: it's all making sence now.

You're welcome!
I am glad I clarified.

[...]
> > Maybe apt-listbugs could drop the DISPLAY enviroment variable before
> > invoking querybts or any browser.
[...]
> > Let me think about it some more (and feel free to express your
> > thoughts!).
> 
> That definatly would work for me.

I prepared this modification and pushed it to the public git repository.
It will be part of the next package upload to Debian unstable.

[...]
> Of cource, the way you described it, it sounds like this could just as
> easily be thought of as a bug in xdg-open/sensible-browser: they ought
> to check if the profile for firefox is accsessible in additon to seeing
> whether DISPLAY is set before trying to launch firefox, or else catch
> the errors that stem from launching firefox without a profile.

This could perhaps be considered as asking too much, taking into
account the simplicity of xdg-open and sensible-browser!

Anyway, if you feel like preparing (and thoroughly testing) a patch for
xdg-open and/or for sensible-browser, maybe you can propose it to the
respective upstream developers and see what happens...

> 
> Any idea on what was up with the pulse audio errors?

I am not sure, since I don't use pulseaudio and I am not familiar with
it.
Above all, I do not fully understand why it tried to
access /root/.config/pulse//daemon.conf: I thought it should have been
started as your regular user, not as root!

> Or are they
> probably just collateral damage from firefox's Halt and Catch Fire?

Probably.
Maybe you have some sort of setup that starts pulseaudio on demand...
And firefox attempted to connect to the audio facility (since it is
well able to produce audio to be sent to a sound server, or directly to
the ALSA infrastructure).
Frankly speaking, I do not know.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgpLUr8ikaohl.pgp
Description: PGP signature

Reply via email to