Hi,
over the last couple of months I have seen at least two non-C
(rust and python) implementations of syslog() equivalent
functionality causing applications written in those languages to
become brittle.
The reason, I hear you ask?
In C, the return type of syslog() is void, so it can't return an
> dependall ===> lib/../external/mpl/bind/lib/libdns
> create libdns/gssapictx.d
> /u/NetBSD/src.ks/external/mpl/bind/lib/libdns/../../dist/lib/dns/gssapictx.c:24:10:
> fatal error: gssapi/gssapi.h: No such file or directory
>24 | #include
> | ^
> compilat
> Summary: it seems that libdeflate explicitly uses some gcc-intrinsic
> functions on gcc 11+, and it is expected that the assembler can handle
> the result. So this doesn't depend on a compiler option and it looks
> like we cannot disable it either.
This seems vaguely similar to the build failur
Hi,
with NetBSD 5.1, the install kernel needs to be booted with a
kernel module loaded (the miniroot kernel module).
This means that any installation attempts following this old
avenue will FAIL from this point forward:
* dropping to the boot prompt
* switch to serial console
* resuming boot
> On Thu, Jul 25, 2013 at 02:24:29PM +0200, Havard Eidnes wrote:
>> Now, there are probably several ways to go around mending this.
>> Some of them are:
>>
>> 1) provide a way to display the contents of boot.cfg (but need to
>>prevent showing the "conten
> On Thu, Jul 25, 2013 at 02:24:29PM +0200, Havard Eidnes wrote:
>> Now, there are probably several ways to go around mending this.
>> Some of them are:
>>
>> 1) provide a way to display the contents of boot.cfg (but need to
>>prevent showing the "conten
>> How does the attached look? It should implement the suggested idea.
>
> That looks like a pretty simple change.
Yah, it was easier than I expected.
>> diff -u -r1.58 boot2.c
> ...
>> +#ifndef SMALL
>> +if (bootconf.nummenu > 0)
>> +bootdefault();
>> +#endif
>
>
>> > How about change "boot" to use whatever boot.cfg says is the default
>> > boot option, and "boot ...anything..." to be the override-the-menu
>> > command?
>>
>> How does the attached look? It should implement the suggested idea.
>
> The changes you propose sound like a good idea, however, I'm
Hi,
The changes implementing the two features I described in this
thread:
1) new "menu" command
2) default "boot" to use the default choice from boot.cfg, if
defined
have now been committed to NetBSD-current.
Best regards,
- Håvard
> With sources up-to-date, I'm seeing:
>
> # build librumphijack/librumphijack.so.0.0
...
> librumphijack.a(hijack.o):(.eh_frame+0x1c): warning: relocation emitted
> against readonly section
Me too, for all mips ports, apparently. I've not seen this error
message before, and would like hint
Hi,
I recently had occasion to boot up NetBSD 6.1 and -current on a
Supermicro X9DRW board equipped witn a Xeon E5 processor. The
board uses the Intel C602 chipset.
There are many "not configured" PCI devices. Notable is perhaps
vendor 0x8086 product 0x1d6b (SAS mass storage, revision 0x06)
> For reference I include the dmesg outputs which I could capture
> since the network device *is* supported.
Bah, forgot the -current dmesg. Here it is.
- Håvard
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013
The N
> I tried to configure a port channel (agr0).
> When I configure the port channel only with bnx0 or only with bnx1
> everything works. If I use bnx0 and bnx1, the Cisco switch sets one of
> the two links to suspended mode.
If I'm not terribly mistaken, the problem is that both physical
interfaces
> On Thu, Jul 30, 2015 at 10:25:36PM +0200, Havard Eidnes wrote:
>> > I tried to configure a port channel (agr0).
>> > When I configure the port channel only with bnx0 or only with bnx1
>> > everything works. If I use bnx0 and bnx1, the Cisco switch sets one of
>&g
> And while I'm on a roll I might as well promote -P as well. I think
> that unless you know what you are doing, -d and -P is probably
> switches you always want to apply when you do cvs update.
I agree -- that's why my ~/.cvsrc contains:
update -d -P
diff -u
rdiff -u
Regards,
- Håvard
Hi,
I have a couple of ODROID C1 boxes. One of them appear to have
intermittent networking problems, in particular with receiving
packets.
droid# uname -a
NetBSD droid.urc.uninett.no 7.99.58 NetBSD 7.99.58 (ODROID-C1) #0: Thu Jan 12
10:12:54 CET 2017
h...@mt.urc.uninett.no:/u/build/HEAD/obj/e
Hi,
on a couple of arm boxes I have I've been observing the
development of the entropy estimate, what "rndctl -s" calls "bits
currently stored in pool" over time.
I've also tried to read some of the code to understand the
behaviour.
If I understand correctly, randomness sources come in two basic
>> Meanwhile the hardware random generator sits there unused.
>
> Does it sit there completely unused, or did it get used a little at
> boot time?
It generated some bits at boot time, but apparently not early
enough, because on each reboot the kernel log looks like this:
...
total memory = 1024 M
> The failure doesn't give much of a clue about what's happened.
> The last lines in the build.log are:
>
> running: /pkg_comp/work/pkg/lang/rust/work/rust-bootstrap/bin/cargo build
> --manifest-path
> /pkg_comp/work/pkg/lang/rust/work/rustc-1.42.0-src/src/bootstrap/Cargo.toml
> --frozen
>Co
>> (gdb) print *cv
>> $1 = {cv_shared = 0x6c652e73, cv_closure = 0x761713184050}
>> (gdb) print *cv->shared
>> There is no member named shared.
>> (gdb) print *cv->cv_shared
>> Cannot access memory at address 0x6c652e73
>> (gdb) print *cv->cv_shared->ci_ops
>> Cannot access memory at address 0x6c65
> On Wed, Mar 31, 2021 at 12:12:31AM +, Taylor R Campbell wrote:
>> This is false. If the VM host provided a viornd(4) device then NetBSD
>> would automatically collect, and count, entropy from the host, with no
>> manual intervention.
>
> I would love to see instructions how to do this - I ha
> Is that file encrypted?
As I understand it, no.
> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that. Regardless of
> how unproven that method might be.
Do note, the existing randomness sources are still bein
>> Do note, the existing randomness sources are still being sampled and
>> mixed into the pool, so even if the starting state from the saved
>> entropy may be known (by violating the security of the storage),
>> it's still not possible to predict the complete stream of randomness
>> data once the s
>> My question is, how can we tell what random sources a system actually
>> has, i.e. is there some flag that cpuctl identify shows when a system
>> has RDRAND/RDSEED?
>
> What about architectures that have nothing like RDRAND/RDSEED? Are
> they, effectively, totally unsupported now?
Nope, not en
>> > No amount of uptime and activity was increasing the entropy in my
>> > system before I patched it.
>>
>> As I understand it, entropy was being contributed. What wasn't
>> happening was the random driver code recognizing and acknowledging that
>> entropy, because it had no way to tell how much
> I suspect what is commonly the problem here is related to the fact
> that cvs has such a phase at the beginning where it is scanning
> through the file system, which can take quite a while. Some NAT
> devices along the path sometimes have timeouts on existing connections
> that if no traffic is h
Hi,
on and off I've been toying with the pkgsrc-wip v8 package, which
is the Google JavaScript engine. They have a largih test suite,
and "of course" a number of tests fail on NetBSD/i386 7.0_BETA
which I'm currently developing on.
Lately I've been able to look a little closer into what causes
t
>> > It's not at all clear to me where maildrop directory is. And it is >
>> > also not clear to me why this is broken, since I took great pains to >
>> > avoid modifying the postfix {master,main}.cf files during etcupdate.
>>
>> I hit that last week - I think it is a change postfix...
>>
>> $ ls
> Ooopppsss!
>
>
>
>
> Seems like I forgot the -p option when untarring the distribution
> sets!
Been there, done that, wasn't too pleasant... :)
Regards,
- Håvard
Hi,
for some odd reason that I've not yet found, the file
/usr/include/gcc-4.5/mm_malloc.h is being included by one of the
configure tests for the net/libcmis package, and configure is
failing with this error:
/usr/include/gcc-4.5/mm_malloc.h:34:64: error: declaration of 'int
posix_memalign(void
Hi,
I updated my netbsd-7 amd64 testing machine yesterday at around
11:17 local time (to a local mirror which may lag 4 hours behind
anoncvs), and this time I got a panic, transcribed via paper:
panic: kernel diagnostic assertion "(obj == NULL) ||
mutex_owned(obj->vmobjlock)"
...uvm_page.c line
> I encountered this as well, on amd64 (I also run i386 and sparc and they
> were fine).
>
> Since the machine I saw this on is my file server, I reverted to my
> previous kernel (7.0_BETA from 22 September).
My previous kernel was of October 9 vintage, and I reverted to
it. I briefly looked over
>> I encountered this as well, on amd64 (I also run i386 and sparc and they
>> were fine).
>>
>> Since the machine I saw this on is my file server, I reverted to my
>> previous kernel (7.0_BETA from 22 September).
>
> My previous kernel was of October 9 vintage, and I reverted to
> it. I briefly l
>> panic: kernel diagnostic assertion "(obj == NULL) ||
>> mutex_owned(obj->vmobjlock)"
>> ...uvm_page.c line 1226
>
> http://mail-index.netbsd.org/current-users/2014/10/20/msg025989.html ?
in which Stephen Borrill said:
> Apologies for the noise, I think this was down to running an
> update bu
> Another datapoint maybe. I've manage to rebuild a few 7.0_BETAs
> without scratching the old obj files and all arch i386 has
> survived those upgrades. The only system that has crashed for
> me was arch amd64. Was that what you where running on your
> machine too?
Yep, testing with NetBSD/amd64.
>> Another datapoint maybe. I've manage to rebuild a few 7.0_BETAs
>> without scratching the old obj files and all arch i386 has
>> survived those upgrades. The only system that has crashed for
>> me was arch amd64. Was that what you where running on your
>> machine too?
>
> Yep, testing with NetB
Hi,
I'm running netbsd-7 code on my new Lenovo T430 laptop. I'm
using code from November 27 at the moment, with the DRM/KMS
kernel, and there are a few glitches:
1) Sometimes the rendering of images e.g. in a web browser
(firefox) is mangled / "interlaced" (not sure how to best
describe it
Hi,
I've recently had occasion to try to install NetBSD on a new
Lenovo RD350 1U server. I've tried the following versions and
boot device combinations:
7.0_BETA from USB flash disk
7.0_BETA from a USB CD-ROM
7.99.10 from a USB CD-ROM
6.1.3 from a USB CD-ROM
I've also hooked up a Dell USB keybo
Hi,
I've recently been installing NetBSD on a new Lenovo RD350
server. I first tried booting from USB disk and from a USB
CD-ROM drive, and both the install kernels loaded just fine.
However, the boot medium was not probed by the 7.0_BETA amd64
kernel.
The kernel on NetBSD 6.1.3 CD-ROM install m
>> I've recently been installing NetBSD on a new Lenovo RD350
>> server. I first tried booting from USB disk and from a USB
>> CD-ROM drive, and both the install kernels loaded just fine.
>> However, the boot medium was not probed by the 7.0_BETA amd64
>> kernel. [...]
>>
>> Anyone else seeing som
>> This is PR kern/48494 :(
I tried a -current kernel, no improvement.
I also tried the change which was suggested in the PR (and then
reverted), and that also made no difference.
Regards,
- Håvard
> A kernel compiled with "options USB_DEBUG" doesn't provide any
> more information that I can see [...]
With additionally usbdebug and uhubdebug set to 10 resulted in
the attached boot messages. cd0 is still not probed.
Regards,
- Håvard
Apr 28 23:39:11 tos-res su: he to root on /dev/pts/2
Pa
>> I've recently been installing NetBSD on a new Lenovo RD350
>> server. I first tried booting from USB disk and from a USB
>> CD-ROM drive, and both the install kernels loaded just fine.
>> However, the boot medium was not probed by the 7.0_BETA amd64
>> kernel. [...]
>>
>> Anyone else seeing som
Hi,
one machine I'm testing NetBSD on feels sort of sluggish, which
is strange because it's got lots of RAM (128GB) and a pair of
Xeon(R) CPU E5-2650 CPUs, for a total of 16 physical cores and 32
with hyperthreading.
It looks like one of the CPUs is using most of its time doing
interrupt processi
> Try booting with the CD drive disabled (via userconf)
with "disable cd*", basically no change:
stest: {5} vmstat -i
interrupt total rate
TLB shootdown 1693 28
cpu0 timer 5716 95
msix2 vec 0 1465 24
msix6 vec 0 2438 40
ioapic0 pin 21
Hi,
lately I have been dusting off and testing a Cobalt RAQ2 I bought
a while ago. Fan's been replaced (the old one spun only
intermittently and made noises...) It has a
viaide0: VIA Technologies VT82C586 (Apollo VP) ATA33 controller
and an internal 40-pin connector for a normal 3.5" PATA driv
>> All of these applications depends on the "MROUTING" kernel option,
>> it seems, which is mostly default-off, except for a few (tending
>> on the more obscure side) kernel configs. I wonder if anyone
>> knows the history there.
>
> I'm not really sure why MROUTING is default off [...]
Isn't MROU
Hi,
I'm running NetBSD-current on one of my 1G Mac Mini G4 systems,
doing pkgsrc bulk building.
This go-around I've managed to build llvm, and next up is rust. This
is proving to be difficult -- my system will consistently wedge it's
user-land (still responding to ping, no response on the consol
Well,
following up on my own posting of yesterday evening.
There's good and not so good news: the good news is that my G4
Mac Mini running -current finally managed to build rust-1.62.1
from pkgsrc-current (using llvm from pkgsrc, not the internal
one). The bad news is that I don't have a definit
>> I tried going into libexec/ld.elf_so and running "make
>> install" but that didn't work or even come close.
>
> It would be something like:
>
> cd src/libexec/ld.elf_so
> ${TOOLDIR}/bin/nbmake-${arch} dependall
> ${TOOLDIR}/bin/nbmake-${arch} install
and if the tool nbmake was
>> As always before such an operation, "do the kernel first".
>
> How do you do the kernel first without building the userland to
> build the updated tools?
The "do the kernel first" is sort of a "general warning".
Whether it is strictly needed depends on what version user-land
and what version so
Hi,
a user contacted me about having a freshly installed version of
NetBSD-current for amd64 built with clang, and a failure to run
the provided "bootstrap kit" for rust, with the following error:
/usr/lib/libgcc_s.so.1: version GCC_3.3 required by
/tmp/pkgsrc/wip/rust/work/rust-bootstrap/bin/ca
>> It might be better to use corresponding older tools to build older
>> kernels. Modern gcc switched to -fno-common by default, so if you
>> want to compile an older kernel that has multiple variable definitions
>> you will need to arrange for -fcommon option to be used.
>
> Is there any way to
>> Indeed, this (without -O) works. The key is the HOST_CFLAGS
>> variable; I was thinking of just CFLAGS at first.
>
> I have had some luck with compiling old systems with -V
> HOST_CFLAGS=-fcommon.
>
> That only goes so far into the past, however. I thought the
> next step would be to try bui
>> Unfortunately the additional shared library changes require
>> another round of package rebuilds from scratch. Everyone
>> building packages against netbsd-10: please start a new round
>> from scratch.
>
> Does that mean the pkgsrc-2023Q2 binary packages for 10_BETA 2
> that have been published
Hi,
I have recently had a bear of a time getting the new rust which
landed in pkgsrc-wip the other day to build natively on several
of the targets we support for NetBSD.
The problem is that the "bootstrap" program (a rust executable)
lands on its nose with a SIGSEGV, and dumps core (without leavi
Hi,
following up on my own message, I finally had the presence of
mind to look at what gdb on armv7 would tell me, if anything,
because that build failed as well.
And... it tells quite a bit more than the other two:
armv7: {2} gdb
/usr/pkgsrc/wip/rust/work/rustc-1.73.0-src/build/bootstrap/debug
> Program terminated with signal SIGSEGV, Segmentation fault.
...
> #0 0x60d0fe74 in _cpuset_isset () from /usr/lib/libc.so.12
> #1 0x03d2bf8c in std::sys::unix::thread::available_parallelism ()
...
> At least it gives a bit of clue about where to go looking for the
> null pointer de-reference,
>>for i in 0..u64::MAX {
>>match libc::_cpuset_isset(i, set) {
>> [...]
>> but ... under which conditions would it seg-fault inside that
>> function?
>
> What's does the Rust impl. of _cpuset_isset() look like? Does it
> take ints by any c
Hi,
I recently had reason to install NetBSD on a new (to me) server.
This server had previously ran Linux/Debian with a software RAID
setup over two drives.
The dmesg of the server is visible at
https://dmesgd.nycbug.org/index.cgi?do=view&id=7403
I wanted to continue to use software RAID with
> Yes. I had a similar problem. The build would fill up the
> /tmp/ directory and die from exhausted resources. I had /tmp/
> created with tmpfs and had a constraint of 64M. The answer for
> me was to create /tmp in /etc/fstab with tmpfs and no size
> constraint. Then Rust would build, but it s
Hi,
I just updated one of my source trees to netbsd-7, and did a
fresh rebuild (empty obj and dest, host oldish 7.1_STABLE), but
got:
compile libc/compat___msgctl13.o
In file included from /usr/src/lib/libc/compat/sys/compat___msgctl13.c:48:0:
/usr/src/sys/compat/sys/msg.h: In function '__na
>> I just updated one of my source trees to netbsd-7, and did a
>> fresh rebuild (empty obj and dest, host oldish 7.1_STABLE), but
>> got:
>
> For what value of "just"? You need something from today around noon UTC
> or newer.
My update was done 13:06 UTC+1, but via a cvs mirror, so possibly
a few
Hi,
this afternoon I attempted to upgrade NetBSD from 7.1_STABLE to
8.0_BETA on an amd64-running machine in our lab. It has an aac
controller, probed like so:
aac0 at pci6 dev 0 function 0: IBM ServeRAID 8k
aac0: interrupting at ioapic0 pin 17
aac0: Enabling 64-bit address support
aac0: Enable 6
Hi,
the OpenSSH in NetBSD has for quite a while had the "high-
performance networking" patches applied.
However, despite this, we are observing rather low performance
when copying files over a distance, e.g. we have a pair of hosts
running netbsd-7 code, placed some 14-15ms apart, where scp'ing a
Hi,
>
> # Improves TCP performance significantly with ssh.
> net.inet.tcp.recvbuf_auto=1
> net.inet.tcp.sendbuf_auto=1
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.recvbuf_max=16777216
Thanks for the suggestions, and I've done some initial
adjustments with beneficial results. I was a bit
Hi,
I decided it might be a good idea to run the self-tests in llvm
5.0.1 on powerpc. However, after the test and utilities are
built, it appears to spin while doing the first test. The run
log shows:
[100%] Built target LLVMHello_exports
[100%] Built target LLVMHello
Scanning dependencies of t
And ... as follow-up I thought I'd check whether "make test" in
lang/llvm (5.0.1nb1) works on NetBSD/amd64 8.0_BETA. And while the
selftest setup seems to work fine on this platform, there are quite a
bit of unexpected failures:
Expected Passes: 20309
Expected Failures : 130
Unsupporte
>> And ... as follow-up I thought I'd check whether "make test" in
>> lang/llvm (5.0.1nb1) works on NetBSD/amd64 8.0_BETA. And while the
>> selftest setup seems to work fine on this platform, there are quite a
>> bit of unexpected failures:
>>
>> Expected Passes: 20309
>> Expected Failures
> On 01.04.2018 16:53, Havard Eidnes wrote:
>> And some of the internal functions in libexecinfo are apparently
>> static, so not present in the symbol table for display in the
>> debugger, making debugging all that much harder.
>>
>> Sigh!
>>
>>
>> Hm, I am suspecting that nobody has actually tested whether
>> backtrace() really works on NetBSD/powerpc... I'll write a
>> simple test of that in C tomorrow.
>
> Yes, this looks more like dysfunctional backtrace(3).
>
> We have got an ATF test for this:
>
> tests/lib/libexecinfo/t_backtrace
>> I don't see an ATF machine for powerpc, there shall be one available.
>>
>> http://releng.netbsd.org/test-results.html
>
> Mm, OK, doing the tests on netbsd-8 on this MacMini G4 should be
> fairly straight-forward.
Not so. The machine wedged partway through the tests, it's in
the office and I'
>>> I don't see an ATF machine for powerpc, there shall be one available.
>>>
>>> http://releng.netbsd.org/test-results.html
>>
>> Mm, OK, doing the tests on netbsd-8 on this MacMini G4 should be
>> fairly straight-forward.
>
> Not so. The machine wedged partway through the tests, it's in
> the of
Hi,
I am (for work) managing a multi-node anycast DNS resolver
cluster using BIND, with NetBSD/amd64 10.0 as the platform, and
use exabgp to announce the service address of this cluster once a
simple sanity check of the local DNS recursor succeeds. This
mostly works quite well.
A few months ago I
> hello. In your stack traces, I see libgcc_s.so.1. Is
> there a comparable library clang should be using instead of a
> library which, on the face of it, looks very gcc specific? If
> there is, can you use that with different results?
That goes back to "how do I actually use this feature
Just to follow up one more time on this specific point:
> hello. In your stack traces, I see libgcc_s.so.1.
Yes, I see that as well. I posted the clang command line used to
build that tiny "does executables work" program, and there is no
mention of libgcc_s anywhere, so I'm not sure what I
> So, "This does not work with clang / LLVM" apparently"; looks
> like I'll have to put my hope to gcc. Or am I doing something
> wrong? Anyone want to make a prediction about how that'll turn
> out with the in-tree gcc 10.5.0?
Re-trying with in-tree gcc but with the -fsanitize=thread
argument a
Hi,
> Given the target, this means gcc 10.5.0 ("nb3") is the default
> compiler. I think I'm able to read the gcc man page, which
> points towards -fsanitize=thread, and that it cannot be combined
> with either of the "address" or "leak" sanitizers, and googling a
> bit brings me to
My first att
> On Fri, Feb 14, 2025 at 11:59:33AM +0100, Havard Eidnes wrote:
>> Now, backing off that for a bit, and returning to the original
>> question, the "90" suffix used with statvfs*() appears to me to
>> indicate that this rename was done in the era leading up to the
&
Hi,
I'm building -current from a few days ago, but my build does not
want to complete successfully, but instead fails during the set
list verification with:
checkflist ===> distrib/sets
execute checkflist
== 3 missing files in DESTDIR
Files in flist but missing from DESTDIR.
>> Is this just me?
>
> MKDEBUGLIB is working for me on amd64 with sources updated less
> than two hours ago...
Thanks for the quick response, even though the answer to the
above looks like "yes"..
Back to a more thorough retry.
- Håvard
>>> Is this just me?
>>
>> MKDEBUGLIB is working for me on amd64 with sources updated less
>> than two hours ago...
>
> Thanks for the quick response, even though the answer to the
> above looks like "yes"..
>
> Back to a more thorough retry.
Hmm. I re-updated src and xsrc, and started with an em
> It looks like you are building for i386 - my build was amd64
Hm, not so. I was also building for amd64.
What I ended up doing was (locally):
Index: distrib/sets/lists/debug/mi
===
RCS file: /cvsroot/src/distrib/sets/lists/debug/m
>> Hmm. I re-updated src and xsrc, and started with an empty OBJDIR
>> and DESTDIR, but still I get the error(s):
>>
>> == 3 missing files in DESTDIR
>> Files in flist but missing from DESTDIR.
>> File wasn't installed ?
>> --
>> ./usr/libdata
> On Mon, Apr 07, 2025 at 02:37:18PM +0200, Havard Eidnes wrote:
>> Then the bug is probably in the logic which translates from build
>> flags ("MKDEBUGLIB" / "MKDEBUG") to the attributes to decide
>> which entries from the set lists to include. I'
> On Fri, Feb 14, 2025 at 09:22:54AM +0100, Thomas Klausner wrote:
>> Perhaps we need to add code like FreeBSD has (to rust libc):
>> https://github.com/rust-lang/libc/blob/2258bf0fb96767bcffbe3ed09b29a31ee54b549b/src/unix/bsd/freebsdlike/freebsd/mod.rs#L5340
>
> Your rust binary calls __getvfsstat
>> [...]
>> So currently my best hunch about the problem is that there was a bug
>> in versioning getmntinfo, or that rust calls the wrong version of
>> getmntinfo, and gets the new statvfs struct where all the char fields
>> are moved around by 16 bytes, but parses it using the old struct
>> defin
Hi,
I'm currently in the process of cross-building rust 1.85 for the
various targets we try to maintain. This is mostly proceeding
well, but our "mipsel" target is failing to build, with:
clippy_utils.c33fa2c5294c0ca2-cgu.08:(.text._RNvMs7_NtCsgLiP1snAFCU_12clippy_utils6constsNtB5_13C
88 matches
Mail list logo
