On Tue, Oct 27, 2020 at 09:42:41AM +0100, Manuel Bouyer wrote:
> Hello,
> in tests from 2020-10-25:
> http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/
> anita fails with
> Could not locate a CD medium in any drive with the distribution sets
> (for both amd64 and i386)
>
> martin, could you
On Sun, Oct 11, 2020 at 11:19:16PM +0200, Thomas Klausner wrote:
> I don't know enough about the internals of the hg and sqlite3, but I
> also saw a broken zip archive and had a good copy for comparison. In
> that case, a block of 256 bytes was zero instead of the real data.
Do you know the file
On Mon, Oct 12, 2020 at 03:06:56AM +, Thomas Mueller wrote:
[..]
> -r--r--r-- 1 root wheel 216493 Jul 23 2019 bootia32.efi
> -r--r--r-- 1 root wheel 204662 Jul 23 2019 bootx64.efi
[..]
> If I want to boot NetBSD-i386, could I use /usr/mdec/bootia32.efi,
> /usr/mdec/bootx64.efi, or
On Sun, Oct 04, 2020 at 01:52:43PM +0200, Martin Husemann wrote:
> On Sun, Oct 04, 2020 at 02:51:16PM +0300, Andreas Gustafsson wrote:
> > All,
> >
> > At least i386 and amd64 are currently in a state where installation
> > using sysinst completes successfully, but
On Sun, Oct 04, 2020 at 02:51:16PM +0300, Andreas Gustafsson wrote:
> All,
>
> At least i386 and amd64 are currently in a state where installation
> using sysinst completes successfully, but the installed system fails
> to boot. The problem appears to have started yesterday during a
> period of
On Thu, Oct 01, 2020 at 02:06:55PM +0200, Thomas Klausner wrote:
> Actually, that is the size of mame stripped, so yes, I need this bigger :)
The unstripped code size should not be bigger, symbols are a separate
(non loadable) section.
> Should we bump it in general?
Don't think so (but also
On Thu, Oct 01, 2020 at 02:03:30PM +0200, Martin Husemann wrote:
> On Thu, Oct 01, 2020 at 01:56:15PM +0200, Thomas Klausner wrote:
> > Program Headers:
> > Type Offset VirtAddr PhysAddr
> > FileSizMemSiz
On Thu, Oct 01, 2020 at 01:56:15PM +0200, Thomas Klausner wrote:
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSizMemSiz Flags Align
[..]
> LOAD 0x 0x0040
On Thu, Oct 01, 2020 at 01:27:38PM +0200, Thomas Klausner wrote:
> but that was not sufficient.
>
> > du -sh /usr/pkg/bin/mame
> 269M/usr/pkg/bin/mame
that is .. big.
Can you show readelf -l output for the binary?
Martin
On Mon, Sep 21, 2020 at 09:32:08AM +0100, Patrick Welche wrote:
> Since gcc9, essentially every ctype using piece of software fails with
>
>error: array subscript has type 'char' [-Werror=char-subscripts]
>
> which prompts a style question: cast every argument of every call to
> a ctype
On Thu, Sep 17, 2020 at 02:11:13PM +0100, Patrick Welche wrote:
> #2 0x7f7ff160c63d in pthread_create (thread=0x2f9d,
> thread@entry=0x7f7fd588, attr=attr@entry=0x0,
> startfunc=startfunc@entry=0x7f7fed764930 ,
> arg=arg@entry=0x7f7ff7e9f230) at
On Wed, Sep 16, 2020 at 11:05:49AM +0200, Thomas Klausner wrote:
> The one with 192.168.0.x configured is wm0. (I only have an lo0 except for
> that.)
Strange, your kernel is newer or same age as your userland?
Martin
On Wed, Sep 16, 2020 at 10:52:46AM +0200, Thomas Klausner wrote:
> Hi!
>
> I ran arp today and saw new errors:
>
> arp: ioctl(SIOCGNBRINFO): Inappropriate ioctl for device
> ? (192.168.0.x) at
> arp: ioctl(SIOCGNBRINFO): Inappropriate ioctl for device
> ? (192.168.0.x) at
> arp:
On Thu, Sep 10, 2020 at 04:06:12PM +0100, Patrick Welche wrote:
> I just upgraded to ancient boxen to -current/amd64. One has its 256 bits,
> the other has none?! I have tried playing spot the difference but
> haven't spotted anything:
Both machines do not have a proper hardware random number
On Mon, Sep 07, 2020 at 11:40:58PM +0200, Riccardo Mottola wrote:
> > It mentions a workaround, but what does it mean to:
> > dd if=/dev/urandom of=/dev/random bs=32 count=1
> > sysctl -w kern.entropy.consolidate=1
>
>
> I tried this "quick fix" and then was able to leave the laptop several
On Fri, Aug 28, 2020 at 12:04:04PM +0100, David Brownlee wrote:
> ure0: discarding oversize frame (len=1757)
> ure0: discarding oversize frame (len=8136)
Try newer -current, ure had a very recent change in that area.
Martin
Carefull when updating, -current is broken in several ways (does not compile
for 32bit architectures, make is broken, maybe more).
Should be fixed soon...
Martin
On Thu, Jul 30, 2020 at 10:55:05AM -0400, MLH wrote:
> > > Jul 29 12:04:59 tiamat /netbsd: [ 96208.8263223] uhub3: autoconfiguration
> > > error: device problem, disabling port 2
I see that every now and then on some machines/host controllers. It is
not exactly reproducable (for me) though.
On Sun, Jul 19, 2020 at 01:42:30PM +0100, Chavdar Ivanov wrote:
> Any ideas? Perhaps I've missed something new in the BUILDING file?
> there is nothing particular in these two lines of the bsd.nls.mk:
make(1) is broken right now.
Martin
On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
> Replacing malloc is just as invalid from a strict standard compliance
> perspective, so *shrug*
Why is that?
We have e.g. shells/standalone-tcsh that does it. Is it broken now?
Martin
On Thu, Jul 09, 2020 at 06:03:23PM -0700, Greg A. Woods wrote:
> The system is running my version of 9.99.64, so it's not quite current,
> and thus I wanted to ask if anyone knows if this particular crash is
> known of before I send-pr.
>
> I think this is the first time I've had a core dump over
On Mon, Jul 06, 2020 at 05:07:51PM +0100, Mike Pumford wrote:
> A quick look around suggests that some of the very high end gaming ones
> don't. Also assuming users will actually be able to find a cable to actually
> hook up the motherboard COM port is optimistic. You would probably have to
> get
On Mon, Jul 06, 2020 at 07:55:29AM -0700, Brian Buhrow wrote:
> hello. In my case, there are times when I want a serial console, for
> set up or troubleshooting, but cannot use the built-in display for various
> reasons. So, I think it would be useful in more situations than might
> first
On Mon, Jul 06, 2020 at 12:34:32PM +0300, Andreas Gustafsson wrote:
> Why would acting as a device be needed?
To emulate a serial console on an USB OTG port.
Martin
On Mon, Jul 06, 2020 at 09:52:31AM +0100, Mike Pumford wrote:
> Like it or not its probably going to be a long term requirement to have
> console USB support. If not for the serial output its becoming more and more
> necessary just to get a console keyboard for DDB.
USB keyboards as console in
On Sun, Jun 21, 2020 at 12:00:41PM +0300, Andreas Gustafsson wrote:
> Martin pointed me to this error some 63 lines from the end of the log:
>
> --- dependall-tests ---
> nbmake[7]: nbmake[7]: don't know how to make t_cabsl.cc. Stop
>
> I think the reason I didn't find it myself is that I
On Fri, Jun 19, 2020 at 08:56:32PM +0900, Rin Okuyama wrote:
> I will make these tests (and similar ones in kernel/t_trapsignal) skipped on
> QEMU, if there's no objection.
No objections from me.
Could you file a qemu bug for this, please?
Thanks!
Martin
On Sat, Jun 13, 2020 at 09:44:35PM -0700, Greywolf wrote:
> raidctl -a /dev/wd0c raid1
>
> raidctl -F component0 raid1
I would have expected that to work. What is the raidctl status output
after the -a ?
Martin
On Fri, Jun 12, 2020 at 06:21:29PM +0100, Sad Clouds wrote:
> I'm testing very recent -current on RPi4.
Threaded programs are broken for aarch64 since ~1 week (most of the
pthread tests fail, programs get stuck in jemalloc cleanup on thread exit).
It is not clear what goes wrong exactly (or: why
On Mon, Jun 08, 2020 at 04:42:42PM -0700, Greg A. Woods wrote:
> What magic am I missing, or is this a bug?
A bug, probably related to not using MBR on xen devices (but most other x86
code expecting disklabel inside MBR). It worked (last I tested) in the
default partition editor, not sure what
On Thu, May 28, 2020 at 01:48:49PM -0700, Greg A. Woods wrote:
> So, I thought I'd try to find out where these symbols might have come
> from, but I came up completely empty with no matches:
>
> $ cd /usr/src
> $ find . -type f -print0 | xargs -0 fgrep rumpns_lockebug_
> $
>
>
On Mon, May 18, 2020 at 09:41:17PM +, Andrew Doran wrote:
> 64 megs, I'm surprised it makes to the login prompt.
Why suprised?
I run several production XEN DomUs with 128 MB ram, and some of my
regular test machines only have 64 MB.
Martin
On Fri, May 15, 2020 at 06:27:41AM -0500, Robert Nestor wrote:
> Yes, and it appears to be different from what Chavdar has on his slightly
> earlier system.
> seed 0 ??? estimate, collect, v
Bingo!
You do not have a hardware random number generator, and your setup did not
On Fri, May 15, 2020 at 09:15:20AM +0100, Chavdar Ivanov wrote:
> Sure, here it is.
Heh, sorry- I meant Robert.
> rdrand 512 rng estimate, collect, v
I wanted to know if a line with "rng" is in his output (just a wild guess).
Martin
Can you show output (as root) of rndctl -l please?
Martin
On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote:
> I.e. the final repo DAG should contain all submitted commits, and all
> that history should be visible to those who look for it (just as is the
> case with merges from github "pull requests").
This is the case in our setup. In the
On Sun, May 10, 2020 at 07:52:42PM -, Michael van Elst wrote:
> And I'd like to talk to Martin, since 100% of the task is done if
> we just add the missing dependency without the option.
Lets start with just the dependency and see if everything fits in the
next build run. We can add the
On Fri, May 08, 2020 at 08:54:32AM -0400, Greg Troxel wrote:
> Why do you need to know? It will almost certainly be less than a day.
> Is that going to cause you do try netbsd, or not try netbsd?
As others have said, it highly depends on your hard disk and amount of
ram installed. Our build
On Wed, Apr 22, 2020 at 01:45:25PM +0100, Robert Swindells wrote:
> Do we need to do anything special to fix it in our checked out trees, or
> will just a 'cvs update' do it ?
I think a cvs up should do.
Martin
On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote:
> Seems fixed now. Thank you!
No quite sure what happened, but every file affected by the re-adding
that was from a vendor branch and unchanged on the wifi branch got
its default branch set to trunk (instead of the vendor branch).
spz
On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote:
> I don't understand why commits to phil-wifi affected to -HEAD...
ARGH - I hate cvs.
Will fix...
Martin
On Mon, Apr 20, 2020 at 12:39:01PM -0500, John D. Baker wrote:
> #0 dhcp_handledhcp (ifp=0xedc1a2a0, bootp=0xefffd362, bootp_len=311,
> from=0xefffd320)
> at /x/netbsd-9/src/external/bsd/dhcpcd/dist/src/dhcp.c:2891
> 2891 if (state->xid != ntohl(bootp->xid)) {
> (gdb) bt
> #0
On Sun, Apr 19, 2020 at 08:53:09AM -0500, John D. Baker wrote:
> Although "/etc/master.passwd" is updated to add the "_dhcpcd" user, the
> insecure "/etc/passwd" is not regenerated to reflect this addition.
How did you update?
postinstall(8) does no automatic updates for uid/gid, but prompts you
On Fri, Mar 27, 2020 at 08:36:39AM +0100, Thomas Klausner wrote:
> So my question is: if "postinstall fix" removes these devices on an
> upgrade, why does init still create them?
This is mostly for install media where we want to avoid to create the ptyfs
mount (and don't fear the security issues
On Thu, Mar 12, 2020 at 06:40:13PM +0100, Riccardo Mottola wrote:
> Hi!
>
> I completed now build and full userland including X, installed.
>
> I launch X11. A cursor appears, evberything else is black.
> Computer resets.
> Fun.
Give us some details ;-)
I updated a machine today and it does
On Wed, Mar 11, 2020 at 09:32:38AM +0100, Riccardo Mottola wrote:
> ${EXTRA_OBJ} vers.o swapnetbsd.o
> /usr/src/obj/tooldir.NetBSD-9.99.34-amd64/bin/x86_64--netbsd-ld:
> ioconf.o:(.rodata+0x120): undefined reference to `stripattach'
>
>
> any clues?
strip(4) has been removed, are you sure you
On Tue, Mar 03, 2020 at 12:57:28PM +, Robert Swindells wrote:
> I don't have an answer to the hang but had been meaning to submit a
> patch for review that might help with tracking it down.
Please commit it!
Martin
On Tue, Mar 03, 2020 at 01:29:39PM +0200, Andreas Gustafsson wrote:
> Would it be too much to ask that imports of entire new subsystems like
> this be at least build tested with "build.sh release"?
The lossage in this case seems to depend on -j values and whether you do
incremental builds, so not
On Sat, Feb 22, 2020 at 05:03:42PM +, Roy Marples wrote:
> Wups!
> I missed an instruction step to ensure the label of the FFS partiton is boot.
> gpt label -i 1 -l boot wd0
> Replace 1 with the partition index and wd0 with the device.
You can also set this directly in sysinst when creating
On Tue, Feb 04, 2020 at 07:40:50AM -0500, MLH wrote:
> Thanks. I have tried that. Always says the device is in use, even
> though nothing associaated with it is mounted, etc.
Are they part of a RAID set? That would qualify as "in use".
Martin
On Fri, Jan 24, 2020 at 08:00:51PM +0100, Adam wrote:
> > I upgraded it to 1.1.1d, and synced the map files.
> >
> > christos
>
> Perfect!
> I updates NodeJS packages.
This caused build fallout on all 64 bit architectures but sparc64,
maybe pkgsrc should enable the EC_GFp_nistp*_methods too?
On Tue, Jan 21, 2020 at 01:12:58PM -0800, Rob Newberry wrote:
> And the code in efi_block_probe will only identify partitions if:
>
> - it's GPT (mine isn't)
>
> - it's MBR (mine is) and it's a NETBSD partition type (mine isn't)
OK, have to admit the code confuses me. I'm not
On Mon, Jan 20, 2020 at 03:41:33PM -0800, Rob Newberry wrote:
> Below are patches -- one to "dosfs.c" to fix the overflow problem,
> one to "efiblock.c" to add the "deal with no disklabel" feature. I
> don't know the proper way to propose or advocate for these, but I'm
> sharing them here in the
On Thu, Jan 16, 2020 at 12:03:27AM -0800, David Hopper wrote:
> For a few days now I'm unable to compile -current modules on Alpha
> either natively or cross-compiled due to the following error:
>
> --- dependall-compat_crypto_50 ---
> /raid/src/sys/opencrypto/ocryptodev.h: In function
On Mon, Jan 06, 2020 at 11:25:01AM +, Patrick Welche wrote:
> yet neither src/sys/sys/queue.h nor
> xsrc/external/mit/libdrm/dist/util_double_list.h
> appear to have changed in ages?!
It was sys/sched.h and I just fixed it.
Martin
On Sun, Jan 05, 2020 at 05:34:51AM -0800, Paul Goyette wrote:
> I see that we have an XZ_ARGS variable which we can force to define
> with ``-V XZ_ARGS=-T6'' and that appears that it will add the "-T6"
> argument when invoking xz to build sets.
... which won't help as the tools xz version is not
On Sun, Dec 29, 2019 at 08:42:36PM +, David Brownlee wrote:
> What is the current wisdom on printing from Firefox?
>
> It appears that from firefox-60 the ability to generale ps was
> removed, so the lpd backend was also removed.
It still works fine for me in firefox 70, but I compile with
On Wed, Dec 18, 2019 at 09:41:45AM +0100, Manuel Bouyer wrote:
> kernel diagnostic assertion "pg->offset >= nextoff" failed: file
> "/home/source/ab/HEAD/src/sys/miscfs/genfs/genfs_io.c", line 972
We see that on various architectures. Andrew, any news on that?
Martin
On Tue, Dec 17, 2019 at 11:33:09AM +, Arthur Barlow wrote:
> I recently built the latest Current for amd64, (9.99.25), and I included
> the xsrc code with the build. I use ./build.sh -O ../obj -T ../tools -x
> distribution and then ./build.sh -O ../obj -T ../tools -x install=/ after
>
On Mon, Dec 16, 2019 at 12:50:39PM +, Emmanuel Dreyfus wrote:
> I thought about it, but requiring the user to enter an UUID to boot
> seems harsh.
Yes, but as a fallback it is good (and sometimes you have "serial console"
and working copy & paste - though with modern server management this
On Mon, Dec 16, 2019 at 08:52:29AM +, Emmanuel Dreyfus wrote:
> The attached patch fixes the bug by avoid using NAME= when there
> is no label. Once applied, rebuild src/sts/arch/i386/stand and
> install updated bootstrap.
This makes my old installation boot again!
Please commit + request
On Fri, Dec 13, 2019 at 03:26:07AM +0100, Emmanuel Dreyfus wrote:
> I still cannot reproduce it. I installed a VM from
> http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/images/NetBSD-9.0_RC1-a
> md64-uefi-install.img.gz
>
> It does not suggests creating an EFI partition.
Did you boot it
On Fri, Dec 13, 2019 at 07:23:20AM +0100, Adam wrote:
> That was a clean build, but, yes, with MKUPDATE=yes.
Sorry, but I still do not get it. A clean build did not work, but then
cleaning and rebuilding did work?
The auto build cluster does clean builds and uses .tar.xz for some
architectures,
On Thu, Dec 12, 2019 at 09:24:09PM +, Chavdar Ivanov wrote:
> Today's -current has a proble installing in gpt mode - it claims not
> to be able to determine the geometry of the disk and does not give an
> option to format it in gpt mode at all.
I think I fixed the "no gpt mode" an hour ago or
On Thu, Dec 12, 2019 at 03:11:38PM +0100, Adam wrote:
> I have to set USE_XZ_SETS=no, remove "distrib" from objdir, re-build,
> then re-building again with USE_XZ_SETS=yes works fine.
Not sure I understood correctly, but doing update builds (build.sh -u)
when switching build options sounds like a
On Thu, Dec 12, 2019 at 03:10:41PM +0100, Matthias Petermann wrote:
> The installation process with sysinst runs fine. Anyway, after reboot there
> seems to be no boot loader installed.
It would be interesting to see more details at this stage:
- how does it fail exactly
- what does "gpt show
On Thu, Dec 12, 2019 at 09:10:57AM +0100, Emmanuel Dreyfus wrote:
> Martin Husemann wrote:
>
> > Emmanuel, could you please have a look?
>
> I do not reproduce that one. Can you share the exact commands to build
> the testbed?
This one had been created manually and wo
On Thu, Dec 12, 2019 at 07:54:08AM +0100, Martin Husemann wrote:
> On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> > in efi with gpt; it performs the installation lege artis, but then the
> > boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
On Wed, Dec 11, 2019 at 10:30:44PM +, Chavdar Ivanov wrote:
> in efi with gpt; it performs the installation lege artis, but then the
> boot fails - the efi file tries and fails to find netbsd, nebsd.gz,
> onetbsd etc...
That sounds like a regression in bootx64.efi, checking
Martin
On Wed, Dec 11, 2019 at 01:34:27PM -0500, Ron Georgia wrote:
> Thanks for responding Martin. Actually I did both. Selecting GPT did set
> things up but it does not boot.
OK, it worked for me when I tried last (but that is a bit ago).
Does the UEFI offer the installed drive as a bootable target?
On Wed, Dec 11, 2019 at 01:28:31PM -0500, Ron Georgia wrote:
> I installed NetBSD 9.0_RC1 as a guest on VirtualBox 5.2.34 r133883 with
> GhostBSD as a host. I enabled EFI and booted from the iso image. I did
> follow the "instructions" on creating a gpt partition for efi
I guess you followed the
On Sat, Dec 07, 2019 at 02:56:25PM +, Taylor R Campbell wrote:
> OOPS -- rmind removed pserialize_init from rump_init, so the mutex
> never got initialized. Fixed in rump.c 1.337!
ACK, test failures down to normal level.
Martin
Here is gdb output from the rump_server core:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 rumpuser_mutex_spin_p (mtx=0x0)
at /work/src/lib/librumpuser/rumpuser_pth.c:166
166 /work/src/lib/librumpuser/rumpuser_pth.c: No such file or directory.
[Current thread is 1
Here is a simple recipe to reproduce the massive test lossage in -current:
cd /usr/tests/dev/raidframe && atf-run
In the output you will find:
tp-start: 1575709106.330783, t_raid, 7
tc-start: 1575709106.330864, old_numrows_config
tc-so:Executing command [ rump_server -lrumpvfs -lrumpdev
On Thu, Dec 05, 2019 at 11:06:48PM +, Sevan Janiyan wrote:
> Nevermind, pciverbose option has been enabled in the amd64 & i386
> GENERIC kernel configs instead.
Why?
Martin
On Wed, Dec 04, 2019 at 10:20:28PM +, Sevan Janiyan wrote:
> Hello,
> I've set the boot loader to load the pciverbose module by default via
> boot.cfg, this will result in a slightly different dmesg output (more
> info about devices)
... in new installations. This change will not affect
Not seen this locally, but that would be the switch to bsd/libarchive tar.
Maybe it does not unlink files before extraction and replaces them in-space?
I do the same kind of updates, but usually on a very quiet system.
The crashes you see are from other running processes? Joerg would likely
say:
On Mon, Nov 04, 2019 at 08:52:31PM +0200, Yorick Hardy wrote:
> This might be more pango fallout:
>
> https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/
>
> "Using Harfbuzz for font loading means that we will lose support
> for bitmap and type1 fonts. We think this is an
On Sun, Nov 03, 2019 at 01:33:42PM -0600, Robert Nestor wrote:
> My system has multiple disks which allow me to install various versions of
> NetBSD. The disks are large and the system supports EFI, so for some time
> I?ve been doing installations with GPT wedges and using either BIOS or EFI
>
On Thu, Oct 31, 2019 at 09:00:53AM +0100, Anders Magnusson wrote:
> Here are the results, using gcc as the compiler:
>
> bison:
> nbi386:/home/ragge/pcc/cc/ccom >size cgram.o
> text data bss dec hex filename
> 25637 0 0 25637 6425 cgram.o
>
> yacc:
>
On Thu, Oct 24, 2019 at 10:17:17PM +0300, Valery Ushakov wrote:
> On Thu, Oct 24, 2019 at 05:26:41 +0200, Martin Husemann wrote:
>
> > Deal with this properly in sysinst would mean:
> >
> > 1) run a script like:
> > rm -f /tmp/list
> > for s in *.${suffix}
On Thu, Oct 24, 2019 at 06:56:57AM +0700, Robert Elz wrote:
> Date:Wed, 23 Oct 2019 23:30:47 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191023213047.ga73...@bec.de>
>
> | (1) Abuse of symlinks to shuffle the tree somewhere else. IMO whoever
> | wants to do
On Wed, Oct 23, 2019 at 11:47:39AM +0200, K. Schreiner wrote:
> with current source cvs upped an hour or so ago:
Are you sure? Doing a clean build?
The previous auto build failed the same way you noted, but the current
run seems to have worked (so I guess it has been fixed in between).
Martin
On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
> Date:Mon, 21 Oct 2019 21:20:25 +0200
> From:Joerg Sonnenberger
> Message-ID: <20191021192025.ga33...@bec.de>
>
> | That said, I don't really see a point in
> | allowing one form of arbitrary file
On Mon, Oct 21, 2019 at 11:54:44AM +0200, J. Hannken-Illjes wrote:
> Somewhere between Netbsd-8 and NetBSD-9 "tar" changed its behaviour
> when it has to extract a directory and the path exists as a symlink.
I still believe it should be fixed, but Jörg disagrees. You need to use -P
now. See PR
On Mon, Sep 30, 2019 at 11:40:26AM -0500, John D. Baker wrote:
> As I build everything with MKDEBUG=yes MKDEBUG_LIB=yes. recent updates
> to the netbsd-9 branch cause build breakage. E.g., on i386 and sparc:
>>
> == 1 missing files in DESTDIR
> Files in flist but missing from
On Mon, Sep 30, 2019 at 06:33:04AM -0700, Paul Goyette wrote:
> If not already done, this should probably be added to src/UPDATING
This is a very generic advice that applies to all updates, and that
file is mostly for documenting special update build issues, so I am not
sure it is worth an entry
On Mon, Sep 23, 2019 at 03:30:42PM +0100, Patrick Welche wrote:
> This morning, I updated the kernels of 2 -current/amd64 boxen to today's HEAD.
>
> One no longer goes multiuser. ls, /rescue/ls, /rescue/mount, /rescue/ps
> all claim "Bad syscall". cat is OK. Guessed libutil, but popping in new
>
On Fri, Sep 20, 2019 at 11:24:53AM +0100, Patrick Welche wrote:
> > I'll do a MKUPDATE=no build...
>
> It seems that MKUPDATE=yes and MKDEBUG=yes don't do what one might
> hope for...
It works fine if you started with a MKDEBUG=yes build, but it will not
properly create debug info for things
On Thu, Sep 19, 2019 at 04:27:44PM +0100, Patrick Welche wrote:
> I'm pretty sure gdb used to pick up symbols automatically, but now I see
> on a fresh -current/amd64 box (with a nod to PR/38185):
>
> $ gdb `which calendar`
> GNU gdb (GDB) 8.3
> ...
> Reading symbols from /usr/bin/calendar...
>
On Thu, Sep 19, 2019 at 12:25:11PM +1000, Paul Ripke wrote:
> Looks like the following patch is needed? A quick grep shows a bunch
> more instances - but I'm not sure how common this arrangement is
> outside of arm.
>
> diff --git a/sys/stand/efiboot/bootarm/Makefile
>
On Mon, Sep 16, 2019 at 02:46:53PM +0300, Andreas Gustafsson wrote:
> On i386, MKZFS is not defined even though mk.conf(5) says it is.
> Which one is wrong, the code or the manpage?
The man page is wrong, MKZFS does not make sense on anything with a 32bit
kernel.
Martin
On Mon, Aug 26, 2019 at 03:13:29AM +, NetBSD Test Fixture wrote:
> This is an automatically generated notice of new failures of the
> NetBSD test suite.
>
> The newly failing test cases are:
>
> net/if_ipsec/t_ipsec_pfil:ipsecif_pfil_esp_null
>
On Sat, Aug 24, 2019 at 07:56:16AM +0700, Robert Elz wrote:
> | Besides, only disklabel provides storage for this data,
>
> Huh? What is being discussed here? I assumed it was the makefs
> parameters that get used (and yes, two of those do get inserted in
> the a bsd disklabel, though I
On Fri, Aug 23, 2019 at 07:30:33PM +0100, Robert Swindells wrote:
> >But is it really needed?
>
> Someone using a disk with 4k blocks might want to set the fragment size
> to that and the block size to a multiple.
If we *have* to set that manually, something is wrong.
Besides, only disklabel
On Fri, Aug 23, 2019 at 06:13:30PM +, John Klos wrote:
> How are people supposed to set the block and fragment sizes in the NetBSD
> installer? If it's still possible, it certainly isn't easy to find.
Is it usefull anywhere?
I removed it, thinking noone would care. If there is use for it,
On Mon, Aug 19, 2019 at 03:06:37PM +0200, Martin Husemann wrote:
> Something bad happened to rump network tests, they are all broken
> in -current, failing with cryptic messages like:
>
> $target$reqs != $target$rels (llentrypl5 != llentrypl2)
>
> Anyone have an idea wha
Something bad happened to rump network tests, they are all broken
in -current, failing with cryptic messages like:
$target$reqs != $target$rels (llentrypl5 != llentrypl2)
Anyone have an idea what caused this? Can someone make the message ... better?
Martin
On Thu, Aug 15, 2019 at 04:52:09PM +0100, Arthur Barlow wrote:
> I have some uncertainty about the application of the "-u" flag in
> build.sh. The docs say it prevents "make clean." But without it will
> rebuild everything, including tools. I've used the flag before
> without problems, but
On Mon, Aug 05, 2019 at 10:46:13AM +, ng0 wrote:
> Hi,
>
> I have a problem with a regression in my Google Summer of Code project
> which seems to only affect NetBSD in my last testing. The code can be
> found at https://git.gnunet.org/libmicrohttpd.git/log/?h=dev/ng0/gsoc2019
> or git cloned
201 - 300 of 656 matches
Mail list logo