On Tue, Feb 21, 2017 at 10:29:43PM -0800, Steve Kargl wrote:
> On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > > Well, I found the guilty commit. r313934 breaks loading
> > > either i915kms.ko or drm2.ko on a
On Wed, Feb 22, 2017 at 08:08:02AM +0200, Konstantin Belousov wrote:
> On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> > Well, I found the guilty commit. r313934 breaks loading
> > either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> > details below.
> >
> > I'll also not
On Tue, Feb 21, 2017 at 09:32:42PM -0800, Steve Kargl wrote:
> Well, I found the guilty commit. r313934 breaks loading
> either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
> details below.
>
> I'll also note that starting at r313902 or so, after
> loading i915kms.ko console output on v
On Tue, Feb 21, 2017 at 09:37:41PM -0800, Steve Kargl wrote:
> On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote:
> > On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote:
> > > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
> > > >
> > > > Well, the good new
On Wed, Feb 22, 2017 at 07:29:08AM +0200, Konstantin Belousov wrote:
> On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote:
> > On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
> > >
> > > Well, the good news seems to be that r313254 and older are 'ok'.
> > > So, something betw
Well, I found the guilty commit. r313934 breaks loading
either i915kms.ko or drm2.ko on a Dell Latitude D530 laptop.
details below.
I'll also note that starting at r313902 or so, after
loading i915kms.ko console output on vt is slooow.
A simply 'time ls /usr/bin' reports 6.27 real, 4.00 user
On Tue, Feb 21, 2017 at 10:55:11AM -0800, Steve Kargl wrote:
> On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
> >
> > Well, the good news seems to be that r313254 and older are 'ok'.
> > So, something between r313943 and r313254 is triggering a the
> > problem. I'm still bisecting,
On Tue, 21 Feb 2017 at 10:44 pm, Vladimir Zakharov
wrote:
> Hello
>
> After recent upgrade portsnap doesn't work anymore:
>
> # portsnap fetch update
> Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
> Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
> Fetching s
On 21 Feb 2017, at 18:26, Dimitry Andric wrote:
>
> On 21 Feb 2017, at 13:48, Hartmut Brandt wrote:
>>
>> it looks like the typeinfo for __int128_t and __uint128_t is missing from
>> our dynamically linked libcxxrt.
...
> * We also need to add the typeinfo for __u?int128_t * and __u?int128_t
>
On Mon, Feb 20, 2017 at 09:26:58PM -0800, Steve Kargl wrote:
>
> Well, the good news seems to be that r313254 and older are 'ok'.
> So, something between r313943 and r313254 is triggering a the
> problem. I'm still bisecting, but it might take a day or two.
>
I've been able to narrow the range
On 21 Feb 2017, at 13:48, Hartmut Brandt wrote:
>
> it looks like the typeinfo for __int128_t and __uint128_t is missing from our
> dynamically linked libcxxrt. I added it like:
>
> Index: lib/libcxxrt/Version.map
> ===
> --- lib/l
On Tue, Feb 21, 2017 at 03:45:36PM +0100, Mateusz Guzik wrote:
> ...
> > stable/11 -- I had been waiting for it to finish the reboot for
> > around 5 minutes, watching: "Syncing disks, vnodes remaining ..."
> > when the thought of noting the amount of elapsed time between reports
> > of the number
Hello
After recent upgrade portsnap doesn't work anymore:
# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Tue Feb 21 16:05:39 MSK 2017 to Tu
On Tue, Feb 21, 2017 at 06:39:08AM -0800, David Wolfskill wrote:
> This morning's daily "head" update & smoke-test was from:
>
> FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263
> r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017
> r...@g1-252.catwhisker.org:/common/
This morning's daily "head" update & smoke-test was from:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #263
r313988M/313991:1200021: Mon Feb 20 06:31:32 PST 2017
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64
to
FreeBSD g1-252.catwhisker.org 12.0-CU
Hi,
it looks like the typeinfo for __int128_t and __uint128_t is missing from
our dynamically linked libcxxrt. I added it like:
Index: lib/libcxxrt/Version.map
===
--- lib/libcxxrt/Version.map(revision 313007)
+++ lib/libcxxrt
[Back to the powerpc64 context.]
On 2017-Feb-20, at 11:10 AM, Mateusz Guzik wrote:
> On Sat, Feb 18, 2017 at 04:18:05AM -0800, Mark Millard wrote:
>> [Note: I experiment with clang based powerpc64 builds,
>> reporting problems that I find. Justin is familiar
>> with this, as is Nathan.]
>>
>> I
On Tue, 21 Feb 2017 09:00-, Filippo Moretti wrote:
> While trying to compile akonadi I get the following error:
> ===> Installing for qtchooser-39===> Checking if qtchooser already
> installed===> Registering installation for qtchooser-39 as
> automaticInstalling qtchooser-39...pkg-static:
While trying to compile akonadi I get the following error:
===> Installing for qtchooser-39===> Checking if qtchooser already
installed===> Registering installation for qtchooser-39 as automaticInstalling
qtchooser-39...pkg-static: qtchooser-39 conflicts with qt4-dbus-4.8.7 (installs
Hello
Found that after 313938 (Capsicum-ize lam) it's doesn't work.
portsnap auto
Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
Fetching snapshot tag from your-org.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Thu Feb 16 11:34:22 EET 2017 to Tue Fe
20 matches
Mail list logo
