Hi!
Is boost-libs building for anyone on -current?
I've tried on 6.99.47 with both clang and gcc (in both cases starting
a bulk build without any existing binary packages, independently for
clang and gcc), and it failed building with many errors, some of them
are:
./boost/serialization/throw_exc
On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
> [...]
> > For the next release, core/releng should decide per current implementation:
> > - how the default userland MACHINE_ARCH should be deteremined
>
> What do you mean by default? For evbarm/cats/shark/etc. the MACHINE_ARCH is
>
On Sun, Jul 20, 2014 at 09:38:55AM +0100, Iain Hibbert wrote:
> one problem is that pcc is defining __GNUC__ by default, so although it
> may be possible with an ANSI C or C99 compiler, the sources might assume
> that GCC language features are available and they are not complete.
Compilers that
On Sat, Jul 19, 2014 at 06:11:42PM +0100, Iain Hibbert wrote:
> Nope, because the uhso driver does not do any locking directly.. there is
> USB locking and TTY locking which must interact and I am not sure what
> work has been done to make drivers MPSAFE in general.
The tty code isn't (and is
On Sun, Jul 20, 2014 at 11:18:58PM +0200, Thomas Klausner wrote:
> On Sun, Jul 20, 2014 at 08:30:07PM +0200, Joerg Sonnenberger wrote:
> > On Sun, Jul 20, 2014 at 07:11:16PM +0200, Thomas Klausner wrote:
> > > After upgrading kernel + userland from 6.99.44 (from around June 20)
> > > to 6.99.47 (fr
On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
> > - different MACHINE_ARCH should be used for armv4/v6/v7 or not
>
> Absolutely. You can't run an earmv7 on earmv6 or before. You default
> to just earm but you lose efficiency and performance. An earmv7hf
> userland is much faster
skrll@ wrote:
> On 07/21/14 06:49, Izumi Tsutsui wrote:
> > matt@ wrote:
> >
> >>> For the next release, core/releng should decide per current
> >>> implementation:
> >>> - how the default userland MACHINE_ARCH should be deteremined
> >> What do you mean by default?
> > "What (and how) MACHINE_AR
On Sun, 20 Jul 2014, Matt Thomas wrote:
- how sysctl hw.machine_arch should be handled
Right now it return the MACHINE_ARCH the executable was built
for via an ELF note.
I'd expect sysctl hw.something to report information about the
hardware that's in use, or perhaps the hardware that the k
On Thu, Jul 17, 2014 at 10:29:02AM +0200, Martin Husemann wrote:
> Does ATF work for anyone on -current on some arm platform?
Should be fixed, sorry for the regression.
Joerg
On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote:
> There is no upgrade path from i386 to amd64 in sysinst.
> (we only had a.out to ELF)
How much of an upgrade path do you need? Remove /dev, install sets as
usual, rerun MAKEDEV should be enough...
Joerg
On Mon, Jul 21, 2014 at 09:44:35AM +0200, Manuel Bouyer wrote:
> We probably don't have the ressources for providing binaries
> for each {,e}arm{,hf} variants.
We should only provide earm variants, and then there are not many relevant
combinations.
However, the question of a decent upgrade path f
On 07/21/14 10:25, Izumi Tsutsui wrote:
skrll@ wrote:
On 07/21/14 06:49, Izumi Tsutsui wrote:
matt@ wrote:
For the next release, core/releng should decide per current implementation:
- how the default userland MACHINE_ARCH should be deteremined
What do you mean by default?
"What (and how)
skrll@ wrote:
> On 07/21/14 10:25, Izumi Tsutsui wrote:
> > skrll@ wrote:
> >
> >> On 07/21/14 06:49, Izumi Tsutsui wrote:
> >>> matt@ wrote:
> >>>
> > For the next release, core/releng should decide per current
> > implementation:
> > - how the default userland MACHINE_ARCH should be
joerg@ wrote:
> On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote:
> > There is no upgrade path from i386 to amd64 in sysinst.
> > (we only had a.out to ELF)
>
> How much of an upgrade path do you need? Remove /dev, install sets as
> usual, rerun MAKEDEV should be enough...
For examp
I think these directories and their contents should be added to the
obsolete lists:
/usr/lib/i386/lua/5.1
/usr/lib/lua/5.1
/usr/share/lua/5.1
Thomas
Hi Thomas,
On Mon, Jul 21, 2014 at 10:30 AM, Thomas Klausner wrote:
> I think these directories and their contents should be added to the
> obsolete lists:
>
> /usr/lib/i386/lua/5.1
> /usr/lib/lua/5.1
> /usr/share/lua/5.1
>
> Thomas
Yes, you are right. I'll add them. Thanks.
Regards,
--
Louri
On Mon, Jul 21, 2014 at 10:51:07AM +0200, Joerg Sonnenberger wrote:
> On Sun, Jul 20, 2014 at 11:18:58PM +0200, Thomas Klausner wrote:
> > On Sun, Jul 20, 2014 at 08:30:07PM +0200, Joerg Sonnenberger wrote:
> > > On Sun, Jul 20, 2014 at 07:11:16PM +0200, Thomas Klausner wrote:
> > > > After upgradi
skrll@ wrote:
> > http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
>
> >>> We probably don't have the ressources for providing binaries
> >>> for each {,e}arm{,hf} variants.
> "Probably"?
>
> Anyway, I don't think anyone is asking for all variants.
Well, I asked to releng/co
On Mon, Jul 21, 2014 at 10:57:46PM +0900, Izumi Tsutsui wrote:
> joerg@ wrote:
>
> > On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote:
> > > There is no upgrade path from i386 to amd64 in sysinst.
> > > (we only had a.out to ELF)
> >
> > How much of an upgrade path do you need? Remov
joerg@ wrote:
> On Mon, Jul 21, 2014 at 10:57:46PM +0900, Izumi Tsutsui wrote:
> > joerg@ wrote:
> >
> > > On Mon, Jul 21, 2014 at 06:25:07PM +0900, Izumi Tsutsui wrote:
> > > > There is no upgrade path from i386 to amd64 in sysinst.
> > > > (we only had a.out to ELF)
> > >
> > > How much of an
skrll@ wrote:
> On 07/21/14 15:32, Izumi Tsutsui wrote:
> > skrll@ wrote:
> >
> >>> http://mail-index.netbsd.org/current-users/2014/07/21/msg025327.html
> > We probably don't have the ressources for providing binaries
> > for each {,e}arm{,hf} variants.
> >> "Probably"?
> >>
> >> Anyway, I
On Jul 21, 2014, at 2:35 AM, Alan Barrett wrote:
> On Sun, 20 Jul 2014, Matt Thomas wrote:
>>> - how sysctl hw.machine_arch should be handled
>>
>> Right now it return the MACHINE_ARCH the executable was built for via an ELF
>> note.
>
> I'd expect sysctl hw.something to report information ab
It looks most your messages are caught by filter on mail.NetBSD.org host.
Could you check you yahoo mailer settings?
skrll@ wrote:
> On 07/21/14 17:25, Izumi Tsutsui wrote:
> > skrll@ wrote:
> >
> >> On 07/21/14 15:32, Izumi Tsutsui wrote:
> >>> skrll@ wrote:
> >>>
> > http://mail-index.netbs
On Sun, Jul 13, 2014 at 07:28:39PM +0100, David Mackay wrote:
> Today I've attempted to try out the new i915drmkms support on NetBSD
> 6.99.47-CURRENT. I've built the DRMKMS kernel conf and installed its
> modules, and attempted to boot.
>
> Unfortunately, despite having all relevant debug options
Izumi Tsutsui wrote:
>skrll@ wrote:
>> I'd guess
>>
>> MACHINE=hpcarmMACHINE_ARCH=earmv4
>>
>> Maybe the port-masters/users can test?
I can test hpcarm on an iPAQ.
>Unfortunately all these ports are orphaned.
There were updates to hpcarm recently to get it to work on WZERO3
hardware,
On Tue, Jul 22, 2014 at 01:15:29AM +0900, Izumi Tsutsui wrote:
> Well, if you only read the quoted sentence and
> you are claiming about i386 to amd64 migration,
> please implement it in sysinst as you like.
>
> The problem discussed here is arm to earm (or its variant).
Yes, the problem is real
rjs@ wrote:
> Izumi Tsutsui wrote:
> >skrll@ wrote:
> >> I'd guess
> >>
> >> MACHINE=hpcarmMACHINE_ARCH=earmv4
> >>
> >> Maybe the port-masters/users can test?
>
> I can test hpcarm on an iPAQ.
Ok, good to hear.
> >Unfortunately all these ports are orphaned.
>
> There were updates to
On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui wrote:
> rjs@ wrote:
>
>> Izumi Tsutsui wrote:
>>> skrll@ wrote:
I'd guess
MACHINE=hpcarmMACHINE_ARCH=earmv4
Maybe the port-masters/users can test?
>>
>> I can test hpcarm on an iPAQ.
>
> Ok, good to hear.
>
>>> U
matt@ wrote:
> On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui wrote:
>
> > rjs@ wrote:
> >
> >> Izumi Tsutsui wrote:
> >>> skrll@ wrote:
> I'd guess
>
> MACHINE=hpcarmMACHINE_ARCH=earmv4
>
> Maybe the port-masters/users can test?
> >>
> >> I can test hpcarm on a
On Jul 21, 11:12am, Lourival Vieira Neto wrote:
} On Mon, Jul 21, 2014 at 10:30 AM, Thomas Klausner wrote:
} > I think these directories and their contents should be added to the
} > obsolete lists:
} >
} > /usr/lib/i386/lua/5.1
} > /usr/lib/lua/5.1
} > /usr/share/lua/5.1
}
} Yes, you are right.
On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
> [...]
>
> Absolutely. You can't run an earmv7 on earmv6 or before. You default to
> just earm but you lose efficiency and performance. An earmv7hf userland is
> much faster on an armv7 cpu than a earm{,hf} userland.
I tested e
On Jul 21, 2014, at 11:23 AM, Izumi Tsutsui wrote:
> matt@ wrote:
>
>> On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui wrote:
>>
>>> rjs@ wrote:
>>>
Izumi Tsutsui wrote:
> skrll@ wrote:
>> I'd guess
>>
>> MACHINE=hpcarmMACHINE_ARCH=earmv4
>>
>> Maybe the po
On Jul 21, 2014, at 12:50 PM, Manuel Bouyer wrote:
> On Sun, Jul 20, 2014 at 08:45:40PM -0700, Matt Thomas wrote:
>> [...]
>>
>> Absolutely. You can't run an earmv7 on earmv6 or before. You default to
>> just earm but you lose efficiency and performance. An earmv7hf userland is
>> much fas
On Mon, Jul 21, 2014 at 01:22:07PM -0700, Matt Thomas wrote:
> Try string processing, armv6+ have much faster support for the str* routines.
> Also, I've been working on faster memcpy taking advantage of the hardware
> fixed of unaligned accesses.
OK, so a pkgsrc build could show some improvement.
Izumi Tsutsui wrote:
>rjs@ wrote:
>
>> Izumi Tsutsui wrote:
>> >skrll@ wrote:
>> >> I'd guess
>> >>
>> >> MACHINE=hpcarmMACHINE_ARCH=earmv4
>> >>
>> >> Maybe the port-masters/users can test?
>>
>> I can test hpcarm on an iPAQ.
>
>Ok, good to hear.
The entry in build.sh for EABI hpcarm
Hi John and Thomas,
On Mon, Jul 21, 2014 at 4:00 PM, John Nemeth wrote:
> On Jul 21, 11:12am, Lourival Vieira Neto wrote:
> } On Mon, Jul 21, 2014 at 10:30 AM, Thomas Klausner wrote:
> } > I think these directories and their contents should be added to the
> } > obsolete lists:
> } >
> } > /usr/
Date: Fri, 18 Jul 2014 16:04:48 +0200
From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?=
DRM error in i915_driver_load: failed to map registers
Can you send me the dmesg output with a GENERIC kernel, particularly
about agp, and the output of `pcictl pci0 dump -b 0 -d 2 -f 0'? I
have a suspicion ab
Updating src tree:
P src/external/bsd/bind/dist/lib/lwres/include/lwres/lwres.h
P src/lib/librumphijack/hijack.c
P src/share/man/man9/vnodeops.9
P src/sys/arch/evbarm/beagle/beagle_machdep.c
P src/sys/dev/pci/if_vioif.c
P src/sys/dev/pci/ld_virtio.c
P src/sys/dev/pci/viomb.c
P src/sys/dev/pci/virt
On Mon, Jul 21, 2014 at 09:28:13AM +0200, Thomas Klausner wrote:
> Is boost-libs building for anyone on -current?
For others in this situation: After updating to a -current with
joerg's fix for libunwind, I had to rebuild boost-headers before
boost-libs started building again. Then it built fine.
39 matches
Mail list logo
