MBR)
so ${TOOL_GPT} on the update build may fail.
The similar issue (against the secondary GPT headers) occured
if IMAGE size is changed:
https://gnats.netbsd.org/56132
Maybe we should note it (remove work.mbr on updating builds)
in doc/UPDATING?
---
Izumi Tsutsui
nment[/ptn_0_offset]
[..]
>If
> the first partition is not defined then the alignment and offset
> for disks larger than 128GB is set to 2048 (1MB).
---
Izumi Tsutsui
ned if these mono support could be reverted,
but no positive comments.
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057
Maybe we should prepare gitlab merge request, but I'm not sure
if non-member can do it..
---
Izumi Tsutsui
I wrote:
> mrg@ wrote:
>
> > i've updated most of xsrc to their latest versions.
> > fontconfig and Mesa are remaining. i've tested the
> > new code on amd64 and arm64, and built several ports
> > to confirm they still build. the biggest change is
> > the new xorg-server.
>
> On 1.21.x, I'm
Thanks for your work.
mrg@ wrote:
> i've updated most of xsrc to their latest versions.
> fontconfig and Mesa are remaining. i've tested the
> new code on amd64 and arm64, and built several ports
> to confirm they still build. the biggest change is
> the new xorg-server.
On 1.21.x, I'm afraid
ometimes it fails to load on blocksize=65536 fs.
(but I'm nots sure 64KB blocksize is valied on FFS because
newfs(8) man page just says 4KB-32KB for it)
---
Izumi Tsutsui
snap_md_post" and
"smp_rpi" etc.
- src/distrib/utils/embedded/mkimage calls makefs(8), fdisk(8),
disklabel(8), and other tools to create board specific images
persrc/distrib/utils/embedded/conf/${h}.conf settings
---
Izumi Tsutsui
org/netbsd-bugs/2021/07/12/msg072460.html
---
Izumi Tsutsui
mp;5
echo $ECHO_N "checking for target miscellaneous support... $ECHO_C" >&6; }
case "${target}" in
-i[3456789]86-* | x86_64-*) misc_hosts="x86" ;;
+i[3456789]86-*) misc_hosts="x86" ;;
*) misc_hosts=no ;;
esac
{ echo "$as_me:$LINENO: result: ${misc_hosts}" >&5
echo "${ECHO_T}${misc_hosts}" >&6; }
-if test "x${misc_hosts}" = no; then
+if test "x${misc_hosts}" = xno; then
misc_hosts=
fi
---
Izumi Tsutsui
| PROT_WRITE
-| PROT_EXEC),
+#ifdef PROT_MPROTECT
+| PROT_MPROTECT(PROT_EXEC)
+#else
+| PROT_EXEC
+#endif /* PROT_MPROTECT */
+),
(MAP_SHARED
#ifdef MAP_ANON
| MAP_ANON
---
Izumi Tsutsui
t generate keysym 'SunStop' directly, or through a macro:
No such file or directory
[/display0.0]: cannot generate keysym 'SunAltGraph' directly, or through a
macro: No such file or directory
tmesh>
---
Not sure what happens though.
Note sun3 emulation works fine even on NetBSD/i386 9.2 + pkgsrc-2021Q2
so this seems sun4c emulation specific.
---
Izumi Tsutsui
l_image_clean etc. in all Makefiles
under src/distrib?
Anyway, we have workarounds but still need review by Makefile gurus:
https://mail-index.netbsd.org/netbsd-bugs/2021/04/29/msg071345.html
https://mail-index.netbsd.org/netbsd-bugs/2021/05/01/msg071360.html
---
Izumi Tsutsui
ith the changes? config(5), autoconf(9), config(9), etc.
(though I'm not sure if they reflected reality even before merge)
Thanks,
---
Izumi Tsutsui
> I just committed usr.bin/make/var.c r1.270 which seems to fix
> everything.
Confirmed. Thanks for a quick response.
---
Izumi Tsutsui
ps://twitter.com/labdrunker/status/963418617722281985
It's still worth to consider and design about Ethernet-over-SCSI layer.
---
Izumi Tsutsui
https://gnats.netbsd.org/53390
---
Izumi Tsutsui
days.
(note options(4) says we also had /dev/io in 1.1 and prior.)
For amd64 (and powerpc), they seem used only for kernel
(like ) and provided by amd64/cpufunc.S etc.
Maybe they are not expected to work for userland binaries.
(though x86_64 still has x86_64_iopl(2) in libarch)
---
Izumi Tsutsui
> Izumi Tsutsui wrote:
> >> Do we know what combination of things is causing X to be killed ?
> >
> >I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating
> >4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images).
>
> How is your X
> Do we know what combination of things is causing X to be killed ?
I can reproduce it by Xorg server + Firefox 62 + makefs(8) creating
4GB FFS image on NetBSD/i386 8.0 (i.e. on building live images).
IIRC no such problem on 7.x days.
(though Firefox was also smaller in those days)
---
Iz
:21:39 mirage /netbsd: UVM: pid 1100.1 (Xorg), uid 0 killed: out of
swap
It seems easily reproducible by running firefox and makefs(8)
to create learge iso/ffs images.
---
Izumi Tsutsui
istrib/atari/floppies/install/list so that other poor ports
can share them.
---
Izumi Tsutsui
loc())
gmalloc.c in emacs may also be affected.
---
Izumi Tsutsui
defs.h
http://nxr.netbsd.org/xref/src/tools/compat/compat_defs.h?r=1.103#580
Not sure if we should have __RCSID() in sources to be committed/merged
into upstream (i.e. sources in external dirs), though.
---
Izumi Tsutsui
completely misinterpreted something?)
It looks the documentation was not updated after changes of default dirs
defined in src/etc/Makefile:
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/Makefile#rev1.398
---
Izumi Tsutsui
approvals from persons
who will work on such dumb items you don't like.
Otherwise release users will get useless binaries
like mips ports in 6.0 release.
---
Izumi Tsutsui
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
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:
http://mail-index.netbsd.org/current-users
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
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
wrote proper commit logs.
(PR numbers, reports on public mailing lists etc.)
You have never answered other core member's question
about mips64 breakage either, put no comments to recent fixes.
It looks far from proper behavior as a core member..
---
Izumi Tsutsui
.
No idea about correctness, but for NetBSD 7.0 we needs some choice.
---
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.
Does anyone (core? releng?) has a particular plan about
the default MACHINE_ARCH for each arm ports?
---
Izumi Tsutsui
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
/msg006179.html
I would like to state at this time that I am not directly responsible for
any unexpected whatevers due to this change.
So adding xhci into GENERIC looks a bit stupid and
it should be reverted.
---
Izumi Tsutsui
--- dhcp6.c 21 Jun 2013 19:33:08 - 1.1.1.1
+++ dhcp6.c 22 Jun 2013 02:28:35 -
@@ -638,7 +638,8 @@ dhcp6_makemessage(struct interface *ifp)
o-len = encode_rfc1035(hostname, p + 1);
if (o-len == 0)
37 matches
Mail list logo
