context, you can only tell if the open failed with the
subsequent getfsent()/setfsent(); that branch should probably just be
removed entirely, and the initial getfsent() might be worth
error-checking for potential error or premature EOF.
Thanks,
Kyle Evans
On 3/11/25 21:58, Kyle Evans wrote:
On 3/11/25 19:21, Jamie Landeg-Jones wrote:
Kyle Evans wrote:
On 9/29/23 15:37, Kyle Evans wrote:
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine
for me -
I'v
On 3/11/25 19:21, Jamie Landeg-Jones wrote:
Kyle Evans wrote:
On 9/29/23 15:37, Kyle Evans wrote:
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
F
On 1/12/25 11:25, bob prohaska wrote:
From: bob prohaska
To: freebsd-ker...@freebsd.org
Subject: Re: [Bug 273566] stray characters contaminate serial console
On Sun, Jan 12, 2025 at 05:02:15AM +, bugzilla-nore...@freebsd.org wrote:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273566
to run ports under head that
were built under stable/14)?
Perhaps
Peace,
david
Thanks,
Kyle Evans
On 10/1/24 11:29, Rodney W. Grimes wrote:
On 9/30/24 19:36, Jamie Landeg-Jones wrote:
Kyle Evans wrote:
It might be that the better long-term approach is to teach updatedb.sh
how to drop privileges and push that out of the periodic script to avoid
surprises like this from the different
On 9/30/24 19:36, Jamie Landeg-Jones wrote:
Kyle Evans wrote:
It might be that the better long-term approach is to teach updatedb.sh
how to drop privileges and push that out of the periodic script to avoid
surprises like this from the different execution environments. This
/feels/ like the
ents. This
/feels/ like the kind of thing we could take an opinionated stance on,
maybe providing an escape hatch of some sort if someone really wants to
complain that they can't document all filenames on the system.
Thanks,
Kyle Evans
On 7/31/24 14:31, Gleb Smirnoff wrote:
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote:
K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf
K> > > Author: Alfonso Siciliano
K> > > Date: Sat May 25 02:42:46 2024 +0200
K> > >
K> > >
On 7/30/24 16:16, Cy Schubert wrote:
In message , Gleb Smirnoff writes:
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote:
T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote:
T> T> This is an automated email to inform you that the July 2024 stabilizati
on week
T> T> sta
ushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
__BSD_VISIBLE") and audited a bit for similar issues in the other ssp
headers, but didn't see any off-hand. With that change:
100% tests passed, 0 tests failed out of 267
Thanks,
Kyle Evans
it- thanks. I suspect it just needs an extra helping of
`__BSD_VISIBLE` sprinkled in.
Thanks,
Kyle Evans
e,
O. Hartmann
See so@'s answer from a couple days ago:
https://lists.freebsd.org/archives/freebsd-security/2024-March/000248.html
TL;DR no
Thanks,
Kyle Evans
ickly
repurpose some PID for a non-u2f thing, much less in a way that we care
about.
Thanks,
Kyle Evans
BSD_version shims or something.
Thanks,
Kyle Evans
[0]
https://github.com/ventoy/Ventoy/tree/master/Unix/ventoy_unix_src/FreeBSD/geom_ventoy_src
On 10/12/23 00:08, Mark Millard wrote:
Kyle Evans wrote on
Date: Thu, 12 Oct 2023 02:54:13 UTC :
The branch main has been updated by kevans:
URL:
https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250
commit 989c5f6da99081b1f2b76ec09e91078e531e1250
Author: Kyle
On 9/29/23 15:37, Kyle Evans wrote:
On 9/29/23 13:25, Jamie Landeg-Jones wrote:
Jamie Landeg-Jones wrote:
Brilliant! Thanks for the quick response and fix. It works fine for me -
I've not managed to break it again :-)
Famous last words
"grep -v" now produces dupli
rintline() with the vflag
because we already terminated in the first printline().
It also removes the offending code that made me overlook that scenario.
Thanks,
Kyle Evans
On 9/27/23 22:34, Greg 'groggy' Lehey wrote:
On Wednesday, 27 September 2023 at 22:30:43 -0500, Kyle Evans wrote:
On 9/27/23 21:40, Jamie Landeg-Jones wrote:
When using color=always and a regex of '.' (for example), output lines
are duplicated.
$ grep --version
grep (BSD
line and output the leading context again + terminate
again.
Thanks,
Kyle Evans
On 8/29/23 14:15, Felix Palmen wrote:
* Kyle Evans [20230829 14:07]:
On 8/29/23 14:02, Shawn Webb wrote:
Back in 2019, I had a similar issue: I needed access to be able to
read/write to the system extended attribute namespace from within a
jailed context. I wrote a rather simple patch that
fully that's useful to someone.
Thanks,
FWIW (which likely isn't much), I like this approach much better; it
makes more sense to me that it's a feature controlled by the creator of
the jail and not one allowed just by using a compat ABI within a jail.
Thanks,
Kyle Evans
ror code 1
This error indicates that for some reason we're trying to build during
the install phase; either tree was updated since last build, messed up
timestamps on build artifacts, messed up clock, etc. Whatever the case
may be, make(1) sees the build output of this as out-of-date.
Thanks,
Kyle Evans
On Sat, Apr 8, 2023 at 5:24 AM Mateusz Guzik wrote:
>
> On 4/8/23, Kyle Evans wrote:
> > On Fri, Apr 7, 2023 at 4:54 PM Mateusz Guzik wrote:
> >>
> >> On 4/7/23, Mark Millard wrote:
> >> > On Apr 7, 2023, at 14:26, Mateusz Guzik wrote:
>
5c8de23c22bde/arm64/aarch64/kernel.txz
> >
> > (No artifact build was exactly at either of your commits.)
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> >
> >
>
> I have arm64 + zfs at $job and just verified the above lets it boot
> again, so I committed already.
>
This was a known issue that we were working on fixing properly over in
https://reviews.freebsd.org/D39448... this really could have waited
just a little bit longer. This problem was already brought up in
response to the commit in question days ago.
Thanks,
Kyle Evans
s... d_write/d_read need the uio accounting updated to reflect how
much data was written/read, it doesn't want to assume you were able to
do everything in a single call.
Thanks,
Kyle Evans
nel.old/kernel
>
> Looks wrong to me. (I've never explicitly assigned to kern.bootfile .)
>
The usual suspect here is that you did an `installkernel` -- if it
replaces kern.bootfile, it moves the old kern.bootfile to
/boot/kernel.old and updates the sysctl to reflect the new location so
that it still accurately reflects the booted kernel.
Thanks,
Kyle Evans
On Tue, Aug 23, 2022 at 2:44 PM Peter Jeremy wrote:
>
> On 2022-Aug-23 15:19:34 +0200, Ronald Klop wrote:
> >Van: Kyle Evans
> >> I was not aware that beadm touches loader.conf, but I find that
> >> slightly horrifying. I won't personally make bectl do that
On Mon, Aug 22, 2022 at 5:10 AM Ronald Klop wrote:
>
>
>
> Van: Peter Jeremy
> Datum: maandag, 22 augustus 2022 10:45
> Aan: "Patrick M. Hausen"
> CC: Ryan Moeller , freebsd-current@freebsd.org
> Onderwerp: Re: Beadm can't create snapshot
>
> On 2022-Aug-17 18:07:20 +0200, "Patrick M. Hausen" w
On Thu, Jul 7, 2022 at 10:01 AM Steve Kargl
wrote:
>
> On Thu, Jul 07, 2022 at 10:37:40AM -0600, Warner Losh wrote:
> > On Thu, Jul 7, 2022 at 10:37 AM Steve Kargl <
> > s...@troutmask.apl.washington.edu> wrote:
> >
> > > Thanks, but
> > >
> > > root[216] git cherry-pick -n 37f604b49d4a
> > > fata
ent eligible for
GSoC is able to propose ideas (regardless of whether we've pitched the
ideas on our wiki or not).
Thanks,
Kyle Evans
>
> On Sat, Apr 16, 2022 at 7:26 PM Julian H. Stacey wrote:
>>
>> > okay...
>> > all seems very time consuming operations!!
&g
On Wed, Feb 2, 2022 at 10:50 AM Kyle Evans wrote:
>
> On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen
> wrote:
> >
> >
> >
> > On 31.01.2022 22.20, Mark Millard wrote:
> > > Mike Karels wrote on
> > > Date: Mon, 31 Jan 2022 12:27:41 -
On Wed, Feb 2, 2022 at 3:41 AM Jesper Schmitz Mouridsen
wrote:
>
>
>
> On 31.01.2022 22.20, Mark Millard wrote:
> > Mike Karels wrote on
> > Date: Mon, 31 Jan 2022 12:27:41 -0600 :
> >
> >> A bisect
> >> would be rather laborious, building a modified SD card each time,
> >> even if just testing
Where did this ecpubkey.pem come from?
On Tue, Dec 7, 2021, 15:28 Larry Rosenman wrote:
>
> --
> >>> Installing everything completed on Tue Dec 7 15:23:33 CST 2021
> --
>
On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney wrote:
>
> Hello,
>
> It seems like the recent changes to make --no-allow-shlib-undefined
> broke pructl.
>
> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but
> pructl does not use atexit_b, and yet gets the following error:
> : && /usr/b
On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote:
>
> On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote:
>
> >
> >
> > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin
> > wrote:
> >
> >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote:
> >> > On Sun, Oct 10, 2021 at 02:52
n Fri, Apr 16, 2021 at 11:36 AM Rainer Hurling wrote:
>
> While viewing sys/sys/param.h I noticed that the comment of the
> definition of __FreeBSD_version is probably out of date.
>
> Since the switch to Git, doesn't it have to be 'main' instead of 'master'?
>
This isn't based on a branch name,
On Wed, Mar 31, 2021 at 7:25 AM Ronald Klop wrote:
>
>
> Van: Jochen Neumeister
> Datum: woensdag, 31 maart 2021 13:26
> Aan: Christoph Moench-Tegeder ,
> freebsd-current@freebsd.org
> Onderwerp: Re: Blacklisted certificates
> >
> >
> > Am 31.03.21 um 13:02 schrieb Christoph Moench-Tegeder:
> >
y pointed out to me attempts to use KASSERT
> without having it defined.
>
> So: Is DIAGNOSTIC intended to necessarily imply that KASSERT is
> available for use?
>
This is fixed in ff92a03616c5, thanks for the report!
Kyle Evans
___
fre
On Mon, Mar 8, 2021 at 10:51 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Tue, 09 Mar 2021 00:57:32 +0900 (JST)
>
> > But still one question remains. Why have the value of
> > kern.timecounter.hardware and kern.timecounter.tc.ACPI-fast.counter
>
On Sat, Mar 6, 2021 at 4:02 AM Yasuhiro Kimura wrote:
>
> From: Yasuhiro Kimura
> Subject: Re: Waiting for bufdaemon
> Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST)
>
> >> My belief is that this commit helps more users than it hurts. Namely,
> >> the VMWare and KVM users, which are majority, use f
On Tue, Feb 16, 2021 at 7:29 PM Kyle Evans wrote:
>
> On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
> wrote:
> >
> > I historically on occasion have done something like:
> >
> > # grep -rI ... /
> >
> > in order to find all instance
On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current
wrote:
>
> I historically on occasion have done something like:
>
> # grep -rI ... /
>
> in order to find all instances of a text, including
> in build trees and such. I now find that I need to
> do something more like (using a more
fined symbol: hid_is_mouse
> >>> referenced by ukbd.c:958 (/usr/src/sys/dev/usb/input/ukbd.c:958)
> >>> ukbd.o:(ukbd_probe)
> ...
Hi,
ukbd recently grew a dependency on the newly split uhid module. See
the 20210107 UPDATING entry for resolution.
On Tue, Dec 8, 2020 at 9:48 AM Mark Johnston wrote:
>
> On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote:
> > On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote:
> > > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> > > this, wh
On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston wrote:
>
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> > I just got this panic:
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 9; apic id = 09
> > instruction pointer = 0x20:0x80bc6e22
> > stack
, we would never attempt to mmap() on ZFS.
Tossing arichardson@ into CC as the committer
Tossing mmacy@ and freqlabs@ into CC as ZFS folks
Looking through sys/contrib/openzfs, there's special handling for mmap
on linux because it bypasses the page cache and relies on caching in
ARC. AFA
kdb_enter+0x37: movq $0,0x1fa9446(%rip)
> > > db>
> >
> > This looks like SMEP catching an issue, but it is not clear why.
>
> Probably fixed by r367783? The bug would have partially overwritten the
> stack frame, resulting in a jump to a user address
On Sun, Nov 15, 2020 at 2:05 PM Stefan Esser wrote:
>
> Am 15.11.20 um 20:41 schrieb Kyle Evans:
> > This is a separate (valid) problem, but not directly related to
> > Scott's work here. sysctlbyname now goes directly to the kernel with
> > no chance for the user
> Thanks,
> Guy Yur
>
This is a separate (valid) problem, but not directly related to
Scott's work here. sysctlbyname now goes directly to the kernel with
no chance for the user.* sysctls to intercept. That should
independently be fixed to maintain the illusion that they're
On Mon, Oct 5, 2020 at 9:54 AM Kyle Evans wrote:
>
> On Sun, Oct 4, 2020 at 11:55 PM Hartmann, O. wrote:
> >
> > For a couple of weeks now cross-compiling 12-STBALE on CURRENT fails
> > due to an compiler error in bin/cp/utils.c, see details below.
> >
> > A
hat shouldn't be the case on stable/12. It's clearly trying to
rebuild it into the src tree in the same way, though:
[/pool/sources/12-STABLE/src/bin/cp/utils.o] Error code 1
This is interesting, but I'm afraid I don't know the nanobsd
On Thu, Sep 17, 2020 at 4:15 PM Christian Weisgerber wrote:
>
> Kyle Evans:
>
> > > FWIW, I just committed a Got port (devel/got).
> >
> > This is probably better for a separate thread, but any idea if there
> > are plans to eventually support local filesystem
This is probably better for a separate thread, but any idea if there
are plans to eventually support local filesystem cloning in got?
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
update i've done to this system
> since the import of openzfs code, and iocage was operating without
> issues previously. i am wondering does iocage need to be rebuild
> against newer sources or did something else change recently?
>
Hi,
You'll need a ports tree
On Sat, Sep 12, 2020 at 7:55 AM Mark Murray wrote:
>
> On 12 Sep 2020, at 12:18, Eric McCorkle wrote:
> >
> > I recently updated my other laptop, and now I'm getting a problem
> > loading zfs.ko at boot, relating to the lockstat_enabled symbol not
> > being defined (this happens during kernel boo
On Thu, Jul 30, 2020 at 2:48 PM David Wolfskill wrote:
>
> On Thu, Jul 30, 2020 at 06:46:40AM -0500, Kyle Evans wrote:
> > On Thu, Jul 30, 2020 at 6:24 AM David Wolfskill
> > wrote:
> > ...
> > > ld-elf.so.1: /common/S4/obj/usr/src/amd64.amd64/tmp/legacy/usr/s
ildenv. installworld injects .WAIT between lib and
libexec + other subdirs, which is supposed to prevent stuff like this
(new binary got installed linked against new libc before new libc).
Running in a buildenv set SYSROOT and stripped out the .WAITs, leaving
me with an annoyance where I had to in
On Fri, Jul 24, 2020 at 3:24 PM Kyle Evans wrote:
>
> Hello!
>
> Just a little bit ago, I committed an update[0] to the valgrind-devel
> port that updates it to Paul Floyd's branch, where he has rebased us
> forward to 3.17.0 and largely fixed valgrind operation on b
to pass on
FreeBSD, the status of which is summarized here:
- https://github.com/paulfloyd/freebsd_valgrind/wiki/Regtest-status
Some outstanding issues:
- https://github.com/paulfloyd/freebsd_valgrind/issues
Please go forth and test it!
Thanks,
Kyle Evans
[0] https://svnweb.freebsd.org/changeset/po
s; I did note
that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/
but I'm told a compat sysctl is on the TODO list to ease the
transition.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd
tive comments like this to make sure a fairly
common need is represented. The (light-hearted?) self-deprecation near
the end of this makes me a bit uneasy- I certainly hope you didn't
feel like it was mandatory to acknowledge that he's a developer and
you're a hobbyist, because there'
of modules mounting
> of filesystems.
>
I seem to recall that you use or experiment with pkgbase -- double
check that pkg hasn't left *.pkgnew in your /etc/rc.d. These will
cause double processing.
Thanks,
Kyle Evans
___
freebsd-current@fre
"alias" hardlink, you get a panic.
>
> E.G:
>
> # ifconfig tun create name tun1
> # ifcondif tun create
>
> [... snip ...]
Whoops, good catch. =-( Will fix ASAP.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mail
it
or at least transcribe the initial part of the panic message?
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
odd
setup that I can never remember. For legacy setups, the bootpool
can/should be merged into your root pool if it's feasible.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Sun, Mar 29, 2020 at 10:16 PM Rebecca Cran wrote:
>
>
> > On Mar 29, 2020, at 9:11 PM, Nathan Whitehorn
> > wrote:
> >
> > The problem then is that we have treated loader as a
> > continuously-updatable part of the OS, like the kernel, and the update
> > system and development process assumes
nightmare -- which I suspect would just mean that
we have some tool that users use to update the ESP rather than
instructing them to examine/replace files manually.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd
On Thu, Mar 19, 2020 at 12:11 PM Graham Perrin wrote:
>
> Is this maybe related to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244847 or should I
> make a separate bug report?
>
Please throw a tentative "Me too" on that PR; I'm investigating it,
then we'll see if they're related or requir
On Fri, Feb 21, 2020 at 3:27 AM Pavel Timofeev wrote:
>
> пт, 10 янв. 2020 г. в 22:05, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev wrote:
> > >
> > > пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> > > >
> > > > On
a,
Can you scroll up and grab a bit more context? This excerpt is still
in the process of cascading errors, so there's not much telling what
caused it.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
y to lag when I am not using them for a
> while. I've adjusted time and started ntpd. In the past that would not fix
> the time lag permanently.
>
> I'll do a fresh buildworld and see whether that completes.
>
I mentioned this elsewhere, but
(Resend because I suck at e-mail; sorry Marek)
On Tue, Jan 28, 2020 at 5:42 PM Marek Zarychta
wrote:
>
> W dniu 28.01.2020 o 22:28, Kyle Evans pisze:
> > On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
> >>
> >> Marek Zarychta zarychtam at plan-b.pwste.edu.pl
On Tue, Jan 28, 2020 at 3:28 PM Kyle Evans wrote:
>
> On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
> >
> > Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> > Tue Jan 28 19:33:45 UTC 2020 :
> >
> > > W dniu 28.01.2020 o 19:11, Dimitry Andr
On Tue, Jan 28, 2020 at 2:15 PM Mark Millard wrote:
>
> Marek Zarychta zarychtam at plan-b.pwste.edu.pl wrote on
> Tue Jan 28 19:33:45 UTC 2020 :
>
> > W dniu 28.01.2020 o 19:11, Dimitry Andric pisze:
> > > On 28 Jan 2020, at 12:36, Nick Hibma wrote:
> > >>
> > >> Could anyone explain to me what
On Fri, Jan 10, 2020 at 12:59 PM Pavel Timofeev wrote:
>
> пт, 10 янв. 2020 г. в 17:48, Kyle Evans :
> >
> > On Fri, Jan 10, 2020 at 12:31 AM Pavel Timofeev wrote:
> > >
> > > чт, 9 янв. 2020 г. в 16:52, Pavel Timofeev :
> > > >
> > >
e a little bit of effort
examining why it's unused. =-)
The inetd build should be clear after r356602, but you'll need to
build WITHOUT_GOOGLETEST=yes for now with the gcc ports. There are
some fundamental issues with mips-gcc{6,9} trying to emit
__floatunsidf references, but that'
st reference: flua is built as
bootstrap on older versions, so it will get built with bootstrap or
buildworld targets and MAKEOBJDIRPREFIX of sysent target must match
what bootstrap/world was built with. I'll MFC flua itself within the
next couple of days to make the p
so the KASSERT did not use sc either.
>
>
Whoops, sorry about that! Fixed in r355031.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lling to build a kernel as described and put up for you to
download, as well, if you'd accept that.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
us&dt=2019-10-02%2001%3A20%3A14
>
Just to follow up with this for list' sake; this was fixed by r352952.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
those that manu's recently tagged for
inclusion into a package to backup-and-restore manually around the
upgrade for the time being, but the PR will be resolved in due time.
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://li
t;XXX A drm-current-kmod 2 /usr/local 3 drm-current-kmod 4 "
> >
> > suggestions welcome...
>
> (CCing Kyle)
>
> This behavior change is probably caused by r351799.
>
> I personally think the code before Kyle’s change and after it was buggy. It’s
> no
On Fri, Aug 30, 2019 at 2:26 PM Kyle Evans wrote:
>
> On Fri, Aug 30, 2019 at 2:11 PM John Baldwin wrote:
> >
> > On 8/30/19 10:42 AM, Kyle Evans wrote:
> > > On Fri, Aug 16, 2019 at 7:38 PM John Baldwin wrote:
> > >>
> > >> On 8/16/19 3:05 A
On Fri, Aug 30, 2019 at 2:11 PM John Baldwin wrote:
>
> On 8/30/19 10:42 AM, Kyle Evans wrote:
> > On Fri, Aug 16, 2019 at 7:38 PM John Baldwin wrote:
> >>
> >> On 8/16/19 3:05 AM, Gary Jennejohn wrote:
> >>> I tried to build a kernel today and it fai
this with !empty(LOCAL_MODULES) &&
EXISTS(${LOCAL_MODULES_DIR}) or maybe just the latter condition to
prevent accidental foot-shooting... I was testing a problem with doing
this stuff in a poudriere build for swills@ and set LOCAL_MODULES=""
only to get an error because LOCAL_MODULES_D
/src/share/mk/bsd.nls.mk /
us
> r/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk
> /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk
> /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk
> /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk
&g
On Wed, Aug 14, 2019 at 1:04 PM Ian Lepore wrote:
>
> On Wed, 2019-08-14 at 19:55 +0200, Niclas Zeising wrote:
> > On 2019-08-14 19:23, Emmanuel Vadot wrote:
> > > On Wed, 14 Aug 2019 10:13:48 -0700
> > > John Baldwin wrote:
> > >
> > > > On 8/14/19 9:22 AM, Ian Lepore wrote:
> > > > > This all s
On Tue, May 14, 2019 at 10:34 AM Kyle Evans wrote:
>
> On Tue, May 14, 2019 at 10:10 AM Mark Johnston wrote:
> >
> > Hi,
> >
> > I hit the following panic last night on a non-INVARIANTS kernel at
> > r347549. The workload involves running a number of bhyve VM
On Tue, May 14, 2019 at 10:10 AM Mark Johnston wrote:
>
> Hi,
>
> I hit the following panic last night on a non-INVARIANTS kernel at
> r347549. The workload involves running a number of bhyve VMs with
> frequent restarts, during which a tap interface is destroyed and
> recreated. I'm a bit short
On Thu, May 9, 2019 at 8:27 AM Michael Butler
wrote:
>
> On 2019-05-09 09:07, Kyle Evans wrote:
> > On Thu, May 9, 2019 at 7:24 AM Michael Butler
> > wrote:
> >>
> >> Seems there's a lock or tuntap issue after recent changes. Restarting
> >> open
eebsd.org/~kevans/etherdetach.diff
Thanks,
Kyle Evans
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Thu, May 2, 2019 at 11:42 AM Kyle Evans wrote:
>
> On Thu, May 2, 2019 at 11:40 AM Larry Rosenman wrote:
> >
> > On 05/02/2019 11:34 am, Larry Rosenman wrote:
> > > On 05/02/2019 11:10 am, Larry Rosenman wrote:
> > >> On 05/02/2019 10:58 am, Warner Losh
>> >
> >>>> >>> > BIOS or UEFI booting?
> >>>> >>>
> >>>> >>> UEFI boot.
> >>>> >>>
> >>>> >>
> >>>> >> So no change to \efi\boot\bootx64.efi (or whatever you a
On Thu, Apr 25, 2019 at 3:33 PM Michael Butler
wrote:
>
> Seems that the lib32 piece (on amd64) is now broken; as follows:
>
*sigh*
Strike two of three for me today, it seems. Should be fixed in
r346705... sorry about that, thanks for the report!
___
f
On Mon, Feb 25, 2019 at 8:18 PM Rebecca Cran wrote:
>
> I've been working on some EFI changes, and in the process found that
> i386 booting is broken. On real hardware - my MinnowBoard Turbot - the
> loader hangs when calling ExitBootServices, while in a VM I get a panic
> saying "exec returned".
On Mon, Feb 18, 2019 at 9:20 PM Graham Perrin wrote:
>
> On 19/02/2019 03:05, Kyle Evans wrote:
> > I'd be interested in seeing what happens when you apply this diff:
> > https://people.freebsd.org/~kevans/bectl-perf.diff
>
>
> Thanks, I'll let you know.
>
On Mon, Feb 18, 2019 at 8:34 PM Graham Perrin wrote:
>
> Preparing to update the OS, I created a new boot environment. Creation
> took a long time, subsequent bectl commands are extraordinarily slow.
>
> Whilst composing this e-mail I'm awaiting completion of a simple list.
>
> Any ideas?
>
> zpoo
likely can't be required in directly, you'll need to run it
through config.load(). I intend to write up a wiki page or something
for converting common Forth-isms to either portable loader.conf(5)
directives or Lua-specific equivalents, depending on the feasibility
of the former.
Tha
On Fri, Jan 18, 2019 at 8:04 AM Olivier Cochard-Labbé
wrote:
>
> On Fri, Jan 18, 2019 at 2:10 PM Lev Serebryakov wrote:
>
> > On 18.01.2019 5:31, Rebecca Cran wrote:
> >
> >
> > > I was wondering if people will expect /boot.config to still be read and
> > so code should be added to loader to cont
1 - 100 of 179 matches
Mail list logo
