On Sat, May 20, 2023 at 11:38:14AM -0700, Rick Macklem wrote:
> Hi,
>
> So I did an MFC that broke the stable/13 build (it's reverted now).
> I didn't realize that changes inside _KERNEL in mount.h would do
> this, but now I know.
>
> Since it is only an issue for stable/1
Hi,
So I did an MFC that broke the stable/13 build (it's reverted now).
I didn't realize that changes inside _KERNEL in mount.h would do
this, but now I know.
Since it is only an issue for stable/13 (and not main), I'd like to do a
minimal fix on the MFC and not mess with adding #includes
lassified as "out of swap space"? Would either
>>> one show the swap space as (nearly?) all used in, say, top?
>>> Or might one of them still end up looking like a misnomer
>>> from just a top (or whatever) display?
>>
>> Hmm, those cases should lik
} else
>>
>> Care to comment on the distinctions and why there are two
>> contexts classified as "out of swap space"? Would either
>> one show the swap space as (nearly?) all used in, say, top?
>> Or might one of them still end up looking like a misnomer
>
On Thu, Jun 3, 2021 at 8:29 PM Alan Somers wrote:
> On Thu, Jun 3, 2021 at 8:13 PM Rick Macklem wrote:
>
> > Hi,
> >
> > I am trying to MFC a commit to stable/12.
> > The cherry-pick works, but the resultant code
> > is not correct and won't build.
On Thu, Jun 3, 2021 at 8:13 PM Rick Macklem wrote:
> Hi,
>
> I am trying to MFC a commit to stable/12.
> The cherry-pick works, but the resultant code
> is not correct and won't build.
> --> I broke the build yesterday and manually
>reverted the breakage.
>
>
Hi,
I am trying to MFC a commit to stable/12.
The cherry-pick works, but the resultant code
is not correct and won't build.
--> I broke the build yesterday and manually
reverted the breakage.
So, how do I do this?
Do I have to manually edit the file after the
cherry-pick and then
not in 12-STABLE or 11-STABLE, despite
having a MFC tag. This means people with newer Cannon Lake-based laptops
like the 2018 Spectre x360 (or a ThinkPad with an equivalent PCH) are
forced to use CURRENT.
Could someone please MFC these patches?
-Neel
===
https://www
Is the following from head/sys/arm/conf/ALLWINNER (and whatever it takes to
support it) ever likely to be MFC'd to stable/11 ?
> Revision 305505 - (view) (download) (annotate) - [select for diffs]
> Modified Tue Sep 6 21:36:20 2016 UTC (2 months ago) by jmcneill
> File length: 2979 byte(s)
>
Is the following from head/sys/arm/conf/ALLWINNER (and whatever it takes to
support it) ever likely to be MFC'd to stable/11 ?
> Revision 305505 - (view) (download) (annotate) - [select for diffs]
> Modified Tue Sep 6 21:36:20 2016 UTC (2 months ago) by jmcneill
> File length: 2979 byte(s)
>
driver, and replaces it with sys/crypto/sha512.h
>
> Does this kind of change mean it cannot be MFCd to stable/10? Or is it
> ok to MFC it?
>
> --
> Allan Jude
>
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.fre
up being asked to bump __FreeBSD_version because it
removes sys/crypto/sha2.h which was apparently used by a 3rd party
driver, and replaces it with sys/crypto/sha512.h
Does this kind of change mean it cannot be MFCd to stable/10? Or is it
ok to MFC it?
--
Allan Jude
signature.asc
Description
Hi,
There has been little comment w.r.t. the NFSv4.1
server code I dropped into head a month ago.
It changes the internal interfaces between the
NFS related kernel modules, but I do not believe
that these would be considered KPIs.
I`d like to MFC it to stable10 for 10.1.
Does anyone have
Oliver Pinter oliver.p...@gmail.com writes:
Can you merge back the r261913 commit to stable/10 or is this a POLA
violation?
It needs to be accompanied by r264964, and you should ask jmg@ about
merging r262945 and r263218 as well.
DES
--
Dag-Erling Smørgrav - d...@des.no
Hi Des!
Can you merge back the r261913 commit to stable/10 or is this a POLA violation?
Thanks,
Oliver
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
from Adrian Chadd:
hi all,
I'd like a developer or two to organise the MFC of anything that's in
net80211 on -HEAD back to -10 before 10.0-REL.
There's a few critical fixes that need to go in but I just don't have
the time to do it myself. :(
Thanks!
There are a couple things I
hi all,
I'd like a developer or two to organise the MFC of anything that's in
net80211 on -HEAD back to -10 before 10.0-REL.
There's a few critical fixes that need to go in but I just don't have
the time to do it myself. :(
Thanks!
-adrian
On Thu, Nov 28, 2013 at 06:54:56PM -0800, Adrian Chadd wrote:
I'd like a developer or two to organise the MFC of anything that's in
net80211 on -HEAD back to -10 before 10.0-REL.
There's a few critical fixes that need to go in but I just don't have
the time to do it myself. :(
Depending
On 28 November 2013 19:04, Glen Barber g...@freebsd.org wrote:
On Thu, Nov 28, 2013 at 06:54:56PM -0800, Adrian Chadd wrote:
I'd like a developer or two to organise the MFC of anything that's in
net80211 on -HEAD back to -10 before 10.0-REL.
There's a few critical fixes that need to go
On Thursday, October 04, 2012 6:06:56 pm Rick Macklem wrote:
John Baldwin wrote:
On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter or is there a trick to avoid this?
Thanks in advance for any help, rick
ps: I seem to MFC
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter or is there a trick to avoid
Sean Bruno wrote:
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter
On 4 October 2012 14:35, Rick Macklem rmack...@uoguelph.ca wrote:
Sean Bruno wrote:
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo
On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does this matter or is there a trick
John Baldwin wrote:
On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote:
Hi,
Hopefully someone familiar with svn can help. When I try to MFC
a kernel change to stable/8, it works, but I end up with tons of
mergeinfo. (It looks like every directory under sys.)
Does
On Fri, 24 Jun 2011 15:03:50 +0300 Andriy Gapon a...@freebsd.org wrote:
on 24/06/2011 14:44 Johan Hendriks said the following:
Hello all i have a question regarding MFC
At the svn page from head most revisions comments contain a line
like MFC after:x weeks or x days. or x months
Hello all i have a question regarding MFC
At the svn page from head most revisions comments contain a line like
MFC after:x weeks or x days. or x months.
Is this done automaticly, or is this still done by the auther.
I came to this question, because of the following.
http
on 24/06/2011 14:44 Johan Hendriks said the following:
Hello all i have a question regarding MFC
At the svn page from head most revisions comments contain a line like
MFC after:x weeks or x days. or x months.
Is this done automaticly, or is this still done by the auther.
It's done
jhell jh...@dataix.net writes:
Because SVN in both our patches for tab completion missed filecomplete.h
and filecomplete.c [...] the previous patches from des@
myself will break world builds.
Speak for yourself. Both files are present in the patch I posted, and I
tested it (make toolchain,
2010/6/21 Dag-Erling Smørgrav d...@des.no:
jhell jh...@dataix.net writes:
Because SVN in both our patches for tab completion missed filecomplete.h
and filecomplete.c [...] the previous patches from des@
myself will break world builds.
Speak for yourself. Both files are present in the patch
On 06/21/2010 09:12, Dag-Erling Smørgrav wrote:
jhell jh...@dataix.net writes:
Sorry but he only mention of filecomplete in your patch is in this
section. That is exactly the same in the patch I had originally
generated using SVN.
Umm, the copy I have on my disk has those files. Just to be
-Brandon
Oh, I see. The diff doesn't include the change(s) to histedit.h
I would be very interested in a diff for FreeBSD 8.1
Sam Fourman Jr.
http://www.fourmannetworks.com/
___
freebsd-current@freebsd.org mailing list
On 06/16/2010 02:20, Sam Fourman Jr. wrote:
-Brandon
Oh, I see. The diff doesn't include the change(s) to histedit.h
I would be very interested in a diff for FreeBSD 8.1
Sam Fourman Jr.
http://www.fourmannetworks.com/
Just got home, So Ill be working on getting this put together over
On 06/16/2010 07:53, jhell wrote:
On 06/16/2010 07:29, jhell wrote:
Just got home, So Ill be working on getting this put together over the
next few minutes and replying to this thread with a go or no go
depending on the outcome and posting the patch.
Here it is:
cd /usr/src
patch
I should probably also mention that it does not have username
completion the the following form ~userna[TAB][TAB]
But does complete ~/[TAB][TAB] from your own home directory. And if you
spell out the username as ~username/[TAB][TAB] that will also work.
So do not be surprised.
--
jhell
I discovered a few moments ago that filename completion had been
committed to HEAD[1]!!!
This is a (seemingly) small, yet VERY useful addition, and, of course
I'm so grateful to Guy Yur and Jilles for getting this into the tree
:)
I would like to make an official request that this feature be
On 06/15/2010 22:00, jhell wrote:
On 06/15/2010 21:14, Brandon Gooch wrote:
I discovered a few moments ago that filename completion had been
committed to HEAD[1]!!!
This is a (seemingly) small, yet VERY useful addition, and, of course
I'm so grateful to Guy Yur and Jilles for getting this
On Tue, Jun 15, 2010 at 9:08 PM, jhell jh...@dataix.net wrote:
On 06/15/2010 22:00, jhell wrote:
On 06/15/2010 21:14, Brandon Gooch wrote:
I discovered a few moments ago that filename completion had been
committed to HEAD[1]!!!
This is a (seemingly) small, yet VERY useful addition, and, of
On Tue, Jun 15, 2010 at 9:17 PM, Brandon Gooch
jamesbrandongo...@gmail.com wrote:
On Tue, Jun 15, 2010 at 9:08 PM, jhell jh...@dataix.net wrote:
On 06/15/2010 22:00, jhell wrote:
On 06/15/2010 21:14, Brandon Gooch wrote:
I discovered a few moments ago that filename completion had been
Hi,
I just tried to compile 5.0-RC2 from using a recently cvsupped copy using the
RELENG_5_0 tag and found that src/sys/geom/geom_slice.c does not compile.
It seems that the version of geom_slice.h which was tagged as RELENG_5_0 is out of
sync with the .c file. Getting the HEAD revision of
In message [EMAIL PROTECTED], Thorsten Greiner w
rites:
Hi,
I just tried to compile 5.0-RC2 from using a recently cvsupped
copy using the RELENG_5_0 tag and found that src/sys/geom/geom_slice.c
does not compile.
It seems that the version of geom_slice.h which was tagged as
RELENG_5_0 is out of
On Mon, Aug 12, 2002 at 08:56:32PM -0500, Craig Boston wrote:
CC: -current since that's what I'm using, but keeping -stable as this
was just MFC'd.
On Mon, 2002-08-12 at 19:13, Bryan Liesner wrote:
I would like to try the uvisor/ucom stuff just comitted, but don't have
a clue how
CC: -current since that's what I'm using, but keeping -stable as this
was just MFC'd.
On Mon, 2002-08-12 at 19:13, Bryan Liesner wrote:
I would like to try the uvisor/ucom stuff just comitted, but don't have
a clue how to use it... Can you point me in the right direction?
Has anyone
with cyrillic letters in
filenames on smbfs.
So, when will be MFC src/contrib/smbfs?
--
Vitaly Markitantov mailto: [EMAIL PROTECTED]
icq: 117438950 phone: (062)332-23-90
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
This is differences between our lib_baudrate and official variant, fixed
at summer 2001. I constantly ask our ncurses maintainer (Peter) to commit
this since summer 2001, but nothing happens, so I plan to do it in anycase
even taking this file out of vendor branch since the bug must be fixed
Hi
Is there a possibility that Estonian locale be MFC'd from current ?
TIA
Lauri
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
This argument is just rehashing something that came up in June. Man
you people have short memories!
I comitted a fix to -current two months ago. It's still in my -stable
tree... if Jordan gives the O.K., I will MFC it to -stable
freebsd-current in the body of the message
this was already submitted as a PR
(http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28143)
maybe time to call for an MFC ? [CC added]
--
Thierry Herbelot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body
On Sat, 25 Aug 2001, Mike Smith wrote:
It should be a tunable, not a compile-time option.
David Hill wrote:
Hello -
Could someone please document options HZ into LINT?. I found it whil
e
reading the dummynet(4) manpage.
It must remain a compile-time option for those of us
as a PR
(http://www.FreeBSD.org/cgi/query-pr.cgi?pr=28143)
maybe time to call for an MFC ? [CC added]
--
Thierry Herbelot
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I searched the archives, and found this question asked, but no responses.
I wonder when (if) Perl 5.6 will be MFC'd to 4.x.
Thanks,
_F
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, Mar 07, 2001 at 06:33:09PM -0500, Forrest Aldrich wrote:
I searched the archives, and found this question asked, but no responses.
I wonder when (if) Perl 5.6 will be MFC'd to 4.x.
^^
Uh, _*WHY*_ are you sending this to freebsd-current
I was thinking about that. Of course my skills limit me to the idea :-P
Well, maybe if it would load automatically on first open.. :) We need
some stub loader technology...
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
On Tue, 12 Sep 2000, The Hermit Hacker wrote:
I'm going from a fresh install of 4.1-RELEASE - 4.1-STABLE, or, at least,
trying to ... and I'm building the kernel as 'make buildkernel' ...
cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes
have done that and it appears to have fixed the problem ... wish I could
remember where I rad that 'buildkernel' was supposed to build anytying the
kernel requird :(
On Wed, 13 Sep 2000, Paul Herman wrote:
On Tue, 12 Sep 2000, The Hermit Hacker wrote:
I'm going from a fresh install of
personalities or styles. In this case, I'd say it was a job for the
CRC if we currently had one. :)
Does that make it a "CRC Check"? :)
(Good old redundant-terminology Cyclical-Reduncancy-Check Checks.)
mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
it out, I'll submit my own
:opinion on whether or not this is "immediate MFC" material.
The linux patch is the only patch under discussion here in regards
to the simultanious commit/MFC issue. The SMP work was committed
to current almost a month ago so MFC'ing it now is
Good greif that last one failed to go to stable@ or current@.. time to
fix mail.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
then give me a day or so to check it out, I'll submit my own
opinion on whether or not this is "immediate MFC" material.
That covers the operational side of the discussion, and on the
procedural side I unfortunately see a lot of arguing about "our
policy" for things
submit my own
opinion on whether or not this is "immediate MFC" material.
That covers the operational side of the discussion, and on the
procedural side I unfortunately see a lot of arguing about "our
policy" for things like this in spite of the fact that there has never
reall
61 matches
Mail list logo
