On Fri, Aug 08, 2014 at 02:53:22PM -0700, Jeff Rizzo wrote:
> All the code and build mechanisms for the KMS drivers are imported
> and in-place; hopefully during the beta period existing bugs will
> get fixed.
I'm glad to hear that - my question was caused by impression, that
needed amount of
On 8/8/14 10:29 AM, Piotr Meyer wrote:
On Fri, Aug 08, 2014 at 07:49:56AM -0700, Jeff Rizzo wrote:
[...]
Lots of good progress has been made - expect the branch to be
created within the next 2 or 3 days.
Is there chance for dealing with latest Ivy Bridge KMS regressions
before branching?
Also
On Fri, Aug 08, 2014 at 07:49:56AM -0700, Jeff Rizzo wrote:
[...]
> Lots of good progress has been made - expect the branch to be
> created within the next 2 or 3 days.
Is there chance for dealing with latest Ivy Bridge KMS regressions
before branching?
Also, if I have understood correctly, Rias
On 7/25/14 11:07 PM, Jeff Rizzo wrote:
On 7/13/14, 12:11 PM, Jeff Rizzo wrote:
On behalf of the release engineering team, I am happy to announce
that the release process for NetBSD 7.0 is now underway.
We will be creating the netbsd-7 CVS branch on or about July 26th,
just under two weeks fro
On 7/13/14, 12:11 PM, Jeff Rizzo wrote:
On behalf of the release engineering team, I am happy to announce that
the release process for NetBSD 7.0 is now underway.
We will be creating the netbsd-7 CVS branch on or about July 26th,
just under two weeks from today. The creation of this branch wi
On 7/25/14, 12:28 AM, Alan Barrett wrote:
I don't care which of the two you keep, but I think it's ugly to have
two aliases that mean the same thing.
After thinking about it some more, I've adopted your original
suggestion. Here's what I want to commit, probably tomorrow.
Index: build.sh
Would it be a problem for you if the alias names were changed?
--apb (Alan Barrett)
Not at all- I'll just regenerate my scripts. I was concerned that the
aliases would be removed period because technically they're redundant. The
aliases however, make generating my scripts easier.
On Thu, 24 Jul 2014, William D. Jones wrote:
I happen to use the aliases to simplify generation of a build.sh wrapper
using m4 (although if necessary I could run etcmanage on my cross compiling
machine). See: https://gist.github.com/cr1901/07b8e6810caedc31fe7c
Would it be a problem for you if t
On Thu, 24 Jul 2014, Jeff Rizzo wrote:
(Please keep me on the cc: when replying, otherwise we get 24-hour
lags such as this waiting for me to check list mail again)
OK.
... I'd keep the new ALIAS=evbearm* and remove the old ALIAS=evbarm*
lines, not provide both.
This ^^^ is actually why I
Accidentally forgot to Cc: the mailing list... whoops!
-Original Message-
From: William D. Jones
Sent: Thursday, July 24, 2014 10:55 PM
To: Jeff Rizzo
Subject: Re: ARM ABI changes/combinations (was Re: Preparation for creating
netbsd-7 branch)
That said, if people don't care
(Please keep me on the cc: when replying, otherwise we get 24-hour lags
such as this waiting for me to check list mail again)
On 7/23/14, 12:10 PM, Alan Barrett wrote:
On Wed, 23 Jul 2014, Jeff Rizzo wrote:
Attached is the proposed diff to build.sh with the changes, including
hpcarm -> MACHINE
Hi all,
To give a user's perspective, I'd like to comment on a couple of
items in the thread so far.
Christos Zoulas wrote:
>Yes, I've been trying to follow that thread. Can you please summarize
>the problem and propose a solution? Is it a backwards compatibility
>issue? Or do we need to worry ab
Any chance of importing the latest version of /usr/bin/tmux before the
branch? We have 1.5, there is a 1.9a.
It is available in pkgsrc, but they are not compatible with each other.
That means that if you are running the base system version, there is no
point in installing the pkgsrc version, becau
On Wed, 23 Jul 2014, Jeff Rizzo wrote:
Attached is the proposed diff to build.sh with the changes, including
hpcarm -> MACHINE_ARCH=earmv4 .
This patch introduces many cases in which the same
MACHINE/MACHINE_ARCH pair is listed under more than one ALIAS. I
don't see the point of that.
Alia
On 7/22/14, 2:28 PM, Jeff Rizzo wrote:
So, what I am proposing:
- acorn26, acorn32, epoc32 remain MACHINE_ARCH=arm
- cats, netwinder, shark switch to MACHINE_ARCH=earmv4 (rename oabi
equiv to ocats, onetwinder, oshark)
- hpcarm, iyonix, zaurus switch to MACHINE_ARCH=earm(which is
equivale
On Tue, 22 Jul 2014, Robert Swindells wrote:
I would prefer hpcarm to switch to MACHINE_ARCH=earmv4
Currently, build.sh would reject that as invalid. It knows the
following MACHINE/MACHINE_ARCH settings for hpcarm:
MACHINE=hpcarm MACHINE_ARCH=armDEFAULT
MACHINE=hpcarm
On 7/22/14, 2:45 PM, Robert Swindells wrote:
I would prefer hpcarm to switch to MACHINE_ARCH=earmv4
Robert Swindells
noted. (may have been a transcription error on my part)
+j
Jeff Rizzo wrote:
>On 7/22/14, 2:45 PM, Robert Swindells wrote:
>> I would prefer hpcarm to switch to MACHINE_ARCH=earmv4
>>
>> Robert Swindells
>noted. (may have been a transcription error on my part)
No, you didn't make an error transcribing it.
The current definitions in build.sh are:
MACH
Jeff Rizzo wrote:
>On 7/21/14, 4:28 AM, Nick Hudson wrote:
>>
>>
>> IMO, non-earm ABI builds should be dropped in favour of earm and a
>> subset of evbarm earm variants should be made available.
>>
>
>This seems reasonable, and I am also going to suggest that the defaults
>change on those ports
On 7/21/14, 4:28 AM, Nick Hudson wrote:
IMO, non-earm ABI builds should be dropped in favour of earm and a
subset of evbarm earm variants should be made available.
This seems reasonable, and I am also going to suggest that the defaults
change on those ports which are switching to EABI.
On Tue, Jul 22, 2014 at 04:44:00PM +, David Holland wrote:
> On Mon, Jul 21, 2014 at 05:57:52PM +0200, Joerg Sonnenberger wrote:
> > > Preparing and testing such upgrade mechanism would be a bit boring work
> > > (there are few developers who care releases and sysinst itself)
> > > so I'm af
On Mon, Jul 21, 2014 at 05:57:52PM +0200, Joerg Sonnenberger wrote:
> > Preparing and testing such upgrade mechanism would be a bit boring work
> > (there are few developers who care releases and sysinst itself)
> > so I'm afraid no one will take it...
>
> For the ones in base, compat version
On Mon, Jul 21, 2014 at 09:50:41PM +0200, Manuel Bouyer wrote:
> [...]
>
> I tested earmhf vs earmv7hf on the beaglebone black. with glxgears,
> the performance improvement is less than 1%.
>
> Do you have other tests that show a large gain with earmv7hf vs earmhf ?
> For 1% I don't think we shou
matt@ wrote:
> > What about acorn26 and acorn32?
>
> Are you willing to step up and fix any apcs32 bugs in gcc?
>
> I have no idea if acorn26 still runs (I've made a significant
> effort to ensure it does). It would greatly simplify
> the ARM world if it would just die. :)
>
> acorn32 uses an
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
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.
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 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 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
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, 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
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 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
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,
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
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
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
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
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
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
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
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)
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 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
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, 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
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
>
christos@ wrote:
> Please correct me if I am wrong:
> - The default userland is selected by installing the toolchain that
> produces that kind of userland. The binaries are "branded" via an
> Elf note that are of this kind of machine arch.
> - I am not sure if migration works, but presumably a
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_ARCH should releng (binary builders) specify
for each arm port on NetBSD 7.0 re
On Jul 20, 2014, at 3:25 AM, Izumi Tsutsui wrote:
> christos@ wrote:
>
>> On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
>> -- Subject: Re: Preparation for creating netbsd-7 branch
>>
>> | christos@ wrote:
>> |
&
Hello,
On Sun, 20 Jul 2014 19:25:53 +0900
Izumi Tsutsui wrote:
> christos@ wrote:
>
> > On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> > -- Subject: Re: Preparation for creating netbsd-7 branch
> >
> > | christos@ wrote:
> > |
&g
In article <140720192553.m0104...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>
>The main problem is lack of design description with random changes.
>http://mail-index.netbsd.org/port-arm/2013/10/26/msg002069.html
>http://mail-index.netbsd.org/port-arm/2013/10/27/msg002075.html
>Without specifi
christos@ wrote:
> On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
> -- Subject: Re: Preparation for creating netbsd-7 branch
>
> | christos@ wrote:
> |
> | > In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
> | > Izumi Tsutsui
On Jul 20, 3:50am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: Preparation for creating netbsd-7 branch
| christos@ wrote:
|
| > In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
| > Izumi Tsutsui wrote:
| > >> On behalf of the release enginee
christos@ wrote:
> In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
> Izumi Tsutsui wrote:
> >> On behalf of the release engineering team, I am happy to announce that
> >> the release process for NetBSD 7.0 is now underway.
> >
> >Does anyone (core? releng?) has a particular plan abou
In article <140719232527.m0121...@mirage.ceres.dti.ne.jp>,
Izumi Tsutsui wrote:
>> On behalf of the release engineering team, I am happy to announce that
>> the release process for NetBSD 7.0 is now underway.
>
>Does anyone (core? releng?) has a particular plan about
>the default MACHINE_ARCH fo
> On behalf of the release engineering team, I am happy to announce that
> the release process for NetBSD 7.0 is now underway.
Does anyone (core? releng?) has a particular plan about
the default MACHINE_ARCH for each arm ports?
---
Izumi Tsutsui
On behalf of the release engineering team, I am happy to announce that
the release process for NetBSD 7.0 is now underway.
We will be creating the netbsd-7 CVS branch on or about July 26th, just
under two weeks from today. The creation of this branch will mark the
start of the Beta period, wh
58 matches
Mail list logo