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
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,
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?
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
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
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 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:
(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 -
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 about
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: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
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.
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,
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
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 armv3
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 should
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 versions
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 afraid no
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.
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 which are
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:
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
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_ARCH should releng
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
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 deteremined
What do you mean
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 example,
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:
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, what is
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 and
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 hpcarm recently to get
On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp 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.
Unfortunately
On Jul 21, 2014, at 11:23 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
matt@ wrote:
On Jul 21, 2014, at 10:56 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:
rjs@ wrote:
Izumi Tsutsui wrote:
skrll@ wrote:
I'd guess
MACHINE=hpcarmMACHINE_ARCH=earmv4
Maybe the
On Jul 21, 2014, at 12:50 PM, Manuel Bouyer bou...@antioche.eu.org 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
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 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 tsut...@ceres.dti.ne.jp wrote:
| On behalf of the release engineering
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 tsut...@ceres.dti.ne.jp wrote:
| On behalf
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 release?
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
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
In article 140719232527.m0121...@mirage.ceres.dti.ne.jp,
Izumi Tsutsui tsut...@ceres.dti.ne.jp 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
christos@ wrote:
In article 140719232527.m0121...@mirage.ceres.dti.ne.jp,
Izumi Tsutsui tsut...@ceres.dti.ne.jp 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
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,
44 matches
Mail list logo
