On Fri, 2019-11-01 at 01:49 -0400, David H. Gutteridge wrote:
> On Tue, 2019-10-29 at 19:52 -0400, David H. Gutteridge wrote:
> > On Tue, 2019-10-29 at 10:38 +, Chavdar Ivanov wrote:
> > > I've tested xfce4 - a few days old build from -current pkgsrc -
> > > now
> > > on
> > > real hardware wit
I don't remove xfwm4.xml, just set use_compositing setting to no. Then
I am able to start xfce4 without a problem many times. EVen if I
delete that file - out of xfce4 - then startxfce4, it starts first
time; on exit use_compositing is set to true, subsequent startxfce4
starts, but without xfwm4 (a
On Tue, 2019-10-29 at 19:52 -0400, David H. Gutteridge wrote:
> On Tue, 2019-10-29 at 10:38 +, Chavdar Ivanov wrote:
> > I've tested xfce4 - a few days old build from -current pkgsrc - now
> > on
> > real hardware with functional dri2. I get the same as with the
> > VirtualBox client - I have t
On Tue, 2019-10-29 at 10:38 +, Chavdar Ivanov wrote:
> I've tested xfce4 - a few days old build from -current pkgsrc - now on
> real hardware with functional dri2. I get the same as with the
> VirtualBox client - I have to disable compositing to get xfwm4
> working. At the same time glmark2 ret
I've tested xfce4 - a few days old build from -current pkgsrc - now on
real hardware with functional dri2. I get the same as with the
VirtualBox client - I have to disable compositing to get xfwm4
working. At the same time glmark2 returns the usual or close to
results.
The other thing is - firefox
"David H. Gutteridge" wrote:
>On Wed, 2019-10-16 at 12:10 +0100, Chavdar Ivanov wrote:
> On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge > wrote:
>
> > FWIW, aside from Firefox (where I also see this issue), I've found
> > since the recent Mesa upgrade, Xfce4's window manager consistently
>
On Sun, Oct 27, 2019 at 02:47:43PM -0400, David H. Gutteridge wrote:
> On Sun, 2019-10-27 at 02:24 +, m...@netbsd.org wrote:
> > On Sun, Oct 27, 2019 at 01:30:48AM +0100, Chavdar Ivanov wrote:
> > > In my case its also swrast_dri, VirtualBox host. I haven't recently
> > > tried xfce4 on a real
On Sun, 2019-10-27 at 14:14 +, Chavdar Ivanov wrote:
> I do not have MesaLib installed on this v/b guest at all.
>
> I bisected xfwm4.xml to try to find out which setting was causing the
> problem. I didn't bother to read it first, as the result was obvious:
> ..
> ~ diff -u .config/xfce4/xfco
On Sun, 2019-10-27 at 02:24 +, m...@netbsd.org wrote:
> On Sun, Oct 27, 2019 at 01:30:48AM +0100, Chavdar Ivanov wrote:
> > In my case its also swrast_dri, VirtualBox host. I haven't recently
> > tried xfce4 on a real hardware with intel, I might di that later.
>
> I could finally reproduce a
Chavdar Ivanov wrote:
>On Sun, 27 Oct 2019 at 16:25, Robert Swindells wrote:
>>
>> Chavdar Ivanov wrote:
>> >I do not have MesaLib installed on this v/b guest at all.
>>
>> Are you running modular or native xorg ?
>
>Native.
Ok, so either you have MesaLib from xsrc installed or you have delet
Native.
On Sun, 27 Oct 2019 at 16:25, Robert Swindells wrote:
>
>
> Chavdar Ivanov wrote:
> >I do not have MesaLib installed on this v/b guest at all.
>
> Are you running modular or native xorg ?
--
Chavdar Ivanov wrote:
>I do not have MesaLib installed on this v/b guest at all.
Are you running modular or native xorg ?
I do not have MesaLib installed on this v/b guest at all.
I bisected xfwm4.xml to try to find out which setting was causing the
problem. I didn't bother to read it first, as the result was obvious:
..
~ diff -u .config/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml.HIDE
.config/xfce4/xfconf/xfce-perch
On Sun, Oct 27, 2019 at 01:30:48AM +0100, Chavdar Ivanov wrote:
> In my case its also swrast_dri, VirtualBox host. I haven't recently
> tried xfce4 on a real hardware with intel, I might di that later.
I could finally reproduce a crash.
And it went away when I pkg_delete'd MesaLib. I wonder if our
In my case its also swrast_dri, VirtualBox host. I haven't recently
tried xfce4 on a real hardware with intel, I might di that later.
On Sat, 26 Oct 2019 at 19:25, David H. Gutteridge wrote:
>
> On Sat, 2019-10-26 at 00:40 +, m...@netbsd.org wrote:
> > Can someone who has this issue explain i
On Sat, 2019-10-26 at 00:40 +, m...@netbsd.org wrote:
> Can someone who has this issue explain it shortly?
>
> - Which GPU?
> - What part of updating (kernel, userland) did it?
> - Does a clean build of everything fix it?
>
> the i915 driver has broken userland compatibility. mrg/riastradh fi
Can someone who has this issue explain it shortly?
- Which GPU?
- What part of updating (kernel, userland) did it?
- Does a clean build of everything fix it?
the i915 driver has broken userland compatibility. mrg/riastradh fixed it,
but I won't be surprised if there's more we haven't spotted with
On Wed, 2019-10-16 at 12:10 +0100, Chavdar Ivanov wrote:
> On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge > wrote:
>
> > FWIW, aside from Firefox (where I also see this issue), I've found
> > since the recent Mesa upgrade, Xfce4's window manager consistently
> > crashes during startup. These's
I wrote:
>>>From the stack trace that Paul Goyette provided it looks to me like
>>>a Firefox bug is triggering one in Mesa.
>>
>>I have now got a debug system and firefox build with debug-info, a
>>firefox build with debug wouldn't display an URL.
>>
>>I commented out the locking code to see what
I wrote:
>>From the stack trace that Paul Goyette provided it looks to me like
>>a Firefox bug is triggering one in Mesa.
>
>I have now got a debug system and firefox build with debug-info, a
>firefox build with debug wouldn't display an URL.
>
>I commented out the locking code to see what happen
I also have xfwm4 crash, but only if there is .config/xfce4 directory.
So far if I remove it, xfce4 works fine. Otherwise the trace appeared
similar to the above.
On Wed, 16 Oct 2019 at 11:03, David H. Gutteridge wrote:
>
> On Tue, 15 Oct 2019, at 12:00:42 +0100, Robert Swindells wrote:
> > I wro
On Tue, 15 Oct 2019, at 12:00:42 +0100, Robert Swindells wrote:
> I wrote:
> >From the stack trace that Paul Goyette provided it looks to me like
> >a Firefox bug is triggering one in Mesa.
>
> I have now got a debug system and firefox build with debug-info, a
> firefox build with debug wouldn't d
On Fri, Oct 11, 2019 at 12:38 Chavdar Ivanov wrote:
> On Fri, 11 Oct 2019 at 20:21, nia wrote:
> >
> > On Fri, Oct 11, 2019 at 11:05:57AM -0700, bch wrote:
> > > I quit running Firefox on my (-current) laptop months ago because the
> build
> > > process (rust, esp) was so brutal. Have there been
On Fri, Oct 11, 2019 at 10:43 Chavdar Ivanov wrote:
> I wouldn't bother chasing this. My firefox 69.0.2 runs perfectly well
> under 9.99.15, so I'd rebuild. You would need rust 1.38 though, my
> build failed with 1.37.
>
I quit running Firefox on my (-current) laptop months ago because the build
I wrote:
>From the stack trace that Paul Goyette provided it looks to me like
>a Firefox bug is triggering one in Mesa.
I have now got a debug system and firefox build with debug-info, a
firefox build with debug wouldn't display an URL.
I commented out the locking code to see what happened:
In
On Sat, Oct 12, 2019 at 11:16:45AM +, m...@netbsd.org wrote:
> On Sat, Oct 12, 2019 at 10:49:58AM +0100, Robert Swindells wrote:
> >
> > m...@netbsd.org wrote:
> > >On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
> > >> On Fri, 11 Oct 2019 11:05:57 -0700
> > >> bch wrote:
> > >>
m...@netbsd.org wrote:
>On Sat, Oct 12, 2019 at 10:49:58AM +0100, Robert Swindells wrote:
>>
>> m...@netbsd.org wrote:
>> >
>> >Firefox works great. The discussion here isn't about firefox being
>> >broken on netbsd, it's being broken across an update. That usually
>> >happens due to some kind o
I just did a quick comparison on a 9.99.16 amd64 VirtualBox guest
between firefox 69.0.2 and the latest versions of epiphany and midori.
All of them seem to work reasonably well, but firefox is the most
usable, in terms of reaction to clicks, updates and overall behaviour.
I tried Google maps with
On Sat, Oct 12, 2019 at 10:49:58AM +0100, Robert Swindells wrote:
>
> m...@netbsd.org wrote:
> >On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
> >> On Fri, 11 Oct 2019 11:05:57 -0700
> >> bch wrote:
> >>
> >> > I quit running Firefox on my (-current) laptop months ago because the
>
On Sat, 12 Oct 2019 at 10:50, Robert Swindells wrote:
> m...@netbsd.org wrote:
> >Firefox works great. The discussion here isn't about firefox being
> >broken on netbsd, it's being broken across an update. That usually
> >happens due to some kind of binary incompatibility being introduced.
>
> I'm
m...@netbsd.org wrote:
>On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
>> On Fri, 11 Oct 2019 11:05:57 -0700
>> bch wrote:
>>
>> > I quit running Firefox on my (-current) laptop months ago because the
>> > build process (rust, esp) was so brutal. Have there been any
>> > community
On Sat, 12 Oct 2019 08:58:46 +
m...@netbsd.org wrote:
> On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
> > On Fri, 11 Oct 2019 11:05:57 -0700
> > bch wrote:
> >
> > > I quit running Firefox on my (-current) laptop months ago because
> > > the build process (rust, esp) was so bru
On Sat, Oct 12, 2019 at 08:41:49AM +0100, Sad Clouds wrote:
> On Fri, 11 Oct 2019 11:05:57 -0700
> bch wrote:
>
> > I quit running Firefox on my (-current) laptop months ago because the
> > build process (rust, esp) was so brutal. Have there been any
> > community efforts to organize the build ar
from Sad Clouds:
> What's the alternative, I've not used NetBSD for desktop tasks for a
> while now, but I wish recent Opera browser was available for NetBSD. I
> suppose you could run it with Linux emulation, but not sure how well it
> works on NetBSD. Last time I tried, which was years ago, ther
On Fri, 11 Oct 2019 11:05:57 -0700
bch wrote:
> I quit running Firefox on my (-current) laptop months ago because the
> build process (rust, esp) was so brutal. Have there been any
> community efforts to organize the build artifacts from bleeding-edge
> environments to avoid repeating (and failin
On Fri, 11 Oct 2019 at 20:21, nia wrote:
>
> On Fri, Oct 11, 2019 at 11:05:57AM -0700, bch wrote:
> > I quit running Firefox on my (-current) laptop months ago because the build
> > process (rust, esp) was so brutal. Have there been any community efforts to
> > organize the build artifacts from bl
On Fri, Oct 11, 2019 at 11:05:57AM -0700, bch wrote:
> I quit running Firefox on my (-current) laptop months ago because the build
> process (rust, esp) was so brutal. Have there been any community efforts to
> organize the build artifacts from bleeding-edge environments to avoid
> repeating (and f
Good question.
My "build server" is an old(-ish, maybe 6 years old) HP Elite 8570
laptop with damaged screen and non-functional FireGL graphics card,
which resets the moment it is touched (I disable radeon in the boot
configuration); on top of that, the CPU heatsink is also probably off,
so it reg
I wouldn't bother chasing this. My firefox 69.0.2 runs perfectly well
under 9.99.15, so I'd rebuild. You would need rust 1.38 though, my
build failed with 1.37.
There were some rather substantial changes in the last few versions.
On Fri, 11 Oct 2019 at 17:40, Sad Clouds wrote:
>
> On Fri, 11 Oct
On Fri, 11 Oct 2019 08:27:31 -0700 (PDT)
Paul Goyette wrote:
> Core was generated by `firefox'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x7af20d009a7b in _atomic_cas_ptr (new=,
> #old=0x0,
> ptr=0x7af20d3cb730)
> at /build/netbsd-local/src_ro/lib/libpthre
I recently upgraded my system from 9.99.4 to 9.99.15, and I've noticed
that firefox is repeatedly dumping core. I haven't found the specific
trigger yet, but...
* The host system is a NetBSD amd64
* firefox 69.0.1 (and all of its dependencies) was build from pkgsrc,
while the host was still ru
41 matches
Mail list logo
