> On Dec 31, 2024, at 5:05 PM, Julio Merino wrote:
>
> On Tue, Dec 31, 2024 at 03:27:49PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Dec 31 20:27:49 UTC 2024
>>
>> Modified Files:
>> src/etc/pam.d: Makefile
>>
>> Log Mes
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue Dec 31 20:27:49 UTC 2024
>
> Modified Files:
> src/etc/pam.d: Makefile
>
> Log Message:
> Use a suffix rule. I would have just commented out the skey entry instead,
> since it is rarely used and we alre
On Tue, Dec 31, 2024 at 03:27:49PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Dec 31 20:27:49 UTC 2024
>
> Modified Files:
> src/etc/pam.d: Makefile
>
> Log Message:
> Use a suffix rule.
Thanks for this. I suppose this fixes the problem t
>> Module Name:src
>> Committed By: he
>> Date: Sun Jul 21 14:56:16 UTC 2024
>>
>> Modified Files:
>> src/etc: security
>>
>> Log Message:
>> etc/security: emit proper error message when there are dup groups.
>>
>> ...instead of erroring with "[: $grpname: unexpected oper
Date:Mon, 22 Jul 2024 00:07:34 +
From:Taylor R Campbell
Message-ID: <20240722000735.3069360...@jupiter.mumble.net>
| Nice, is there a PR for this? Should we pull it up to 10 or 9?
There are lots more sh quoting issues in /etc/security - normally they're
not a
> Module Name:src
> Committed By: he
> Date: Sun Jul 21 14:56:16 UTC 2024
>
> Modified Files:
> src/etc: security
>
> Log Message:
> etc/security: emit proper error message when there are dup groups.
>
> ...instead of erroring with "[: $grpname: unexpected operator".
Nic
On Sun, Jun 11, 2023 at 11:23:23AM +0300, Kimmo Suominen wrote:
> My thinking here is that it makes it simpler to keep the script in
> sync between branches. (I have not checked, but I guess the sysctl
> does not depend on kernel configuration then.)
In this special case I think this would not be
On Sat, 10 Jun 2023 at 20:08, Martin Husemann wrote:
> I don't like this commit, it mixes:
>
> - several text improvements (good!)
> - one unrelated cosmetic change (rely on all rc.d scripts being installed
>with x bit, so drop the "sh" from the manual invocation)
Calling the rc.d script di
On Sat, Jun 10, 2023 at 04:02:39AM +, Kimmo Suominen wrote:
> Module Name: src
> Committed By: kim
> Date: Sat Jun 10 04:02:39 UTC 2023
>
> Modified Files:
> src/etc/rc.d: sshd
>
> Log Message:
> Add some backwards compat. Adjust grammar.
>
>
> To generate a diff of this com
In article <20221128024658.71caaf...@cvs.netbsd.org>,
Jan Schaumann wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: jschauma
>Date: Mon Nov 28 02:46:58 UTC 2022
>
>Modified Files:
> src/etc: protocols
>
>Log Message:
>regen from IANA 2022-09-28
>
>
>To generate a diff of t
On 22-08-24 20:39, Robert Elz wrote:
| Date:Wed, 24 Aug 2022 20:37:54 +1000
| From:Luke Mewburn
| Message-ID:
|
| | I think it would be more consistent with existing convention
| | (in both NetBSD and on other systems) to add /etc/raid.d
|
| I ce
Date:Wed, 24 Aug 2022 20:37:54 +1000
From:Luke Mewburn
Message-ID:
| I think it would be more consistent with existing convention
| (in both NetBSD and on other systems) to add /etc/raid.d
I certainly won't be doing that, I detest the ".d" convention
as a genera
On 22-07-21 07:49, Robert Elz wrote:
| Module Name:src
| Committed By: kre
| Date: Thu Jul 21 07:49:36 UTC 2022
|
| Modified Files:
| src/etc/rc.d: raidframe
|
| Log Message:
| Make this better ... Allow config file for raidN to be found
| in
Hi Alex,
Alexander Nasonov wrote:
> Simon Burge wrote:
> > Why don't we just mount all the ZFS filesystems in mountcritlocal?
>
> Future versions may require loading of encryption keys over kerberos
> or a special pam module to decrypt /home/$USER.
How is this different to the existing "zfs moun
Greg Troxel writes:
[snip]
>
> I am opposed to deciding that all zfs filesystems should be treated as
> critical (in a world where we have not abolished the notion).
>
> We could have a discussion about why we even have the concept of
> critical filesystems, but if so that should not be
Brad Spencer writes:
> What is referred to here is a specific ZFS idea and should not be
> confused with any sort of global notion. Specifically, ZFS, by default
> and in common use, does not use anything like a /etc/fstab or
> /etc/vfstab to specify where the filesets get mounted. It also doe
I apologize for failing to understand "zfs legacy mount" and incorrectly
associating it with how I usually encounter the word legacy.
I now understand that you meant to separate:
zfs's preferred path of having mountpoints stored as volume
properties, which is a different way of specifying wh
Greg Troxel writes:
[snip]
> [I don't really know what you mean by legacy (other than non-zfs, but
> you didn't say that, so perhaps you mean something different).]
[snip]
I am only going to speak to the use of "legacy" in this conversation.
What is referred to here is a specific ZFS idea and
Simon Burge wrote:
> Why don't we just mount all the ZFS filesystems in mountcritlocal?
Future versions may require loading of encryption keys over kerberos
or a special pam module to decrypt /home/$USER.
Alex
Simon Burge writes:
> I'm running with a complete ZFS-only setup with no legacy mounts. This
> is my basic ZFS layout (leaving out a few mounts that don't add any more
> value to this discussion):
>
> NAME MOUNTPOINT
> pool0 /pool0
>
[ Oops, resending to include the source-changes-d list. ]
[ Sorry for the double-up for the original recipients. ]
Hi Alexander, folks,
Sorry for chiming in a bit late on this.
I'm running with a complete ZFS-only setup with no legacy mounts. This
is my basic ZFS layout (leaving out a few moun
Taylor R Campbell wrote:
> > Date: Sat, 5 Feb 2022 21:21:53 +
> > From: Alexander Nasonov
> >
> > Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> > legacy mountpoints a try to see how much complexity they add.
>
> I use legacy mountpoints for / and /var, but it's a littl
> Date: Sat, 5 Feb 2022 21:21:53 +
> From: Alexander Nasonov
>
> Since I plan to migrate my ZFS setup to a smaller cgd disk, I gave
> legacy mountpoints a try to see how much complexity they add.
I use legacy mountpoints for / and /var, but it's a little kludgey,
and from what I recall a leg
Alexander Nasonov writes:
> Brad Spencer wrote:
>> Alexander Nasonov writes:
>> > Are there any downside of mixing legacy and non-legacy mountpoints?
>> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>>
>> That should work fine as long as /var was arranged to be mounted
Brad Spencer wrote:
> Alexander Nasonov writes:
> > Are there any downside of mixing legacy and non-legacy mountpoints?
> > E.g. if my /var is legacy but /var/crash is a normal ZFS mountpoint?
>
> That should work fine as long as /var was arranged to be mounted first.
> The other way around may a
Alexander Nasonov writes:
> J. Hannken-Illjes wrote:
>> What is wrong with ZFS legacy mounts?
>>
>> $ zpool create -m legacy tank
>> $ zfs create tank/a
>> $ mount -t zfs tank/a /mnt
>
> Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
> look into it because, well, "legacy"..
J. Hannken-Illjes wrote:
> What is wrong with ZFS legacy mounts?
>
> $ zpool create -m legacy tank
> $ zfs create tank/a
> $ mount -t zfs tank/a /mnt
Hmm, I heard about ZFS legacy (quite a while ago!) but I didn't
look into it because, well, "legacy"...
Are there any downside of mixing lega
On Fri, Feb 04, 2022 at 10:19:03PM +, Alexander Nasonov wrote:
> These two "styles of mounting" are
>
> /sbin/mount /filesystem - looks up fs parameters in /etc/fstab
> /sbin/zfs mount dataset - looks up fs parameters in zpools
There are several things that could be done here. I would guess s
> On 4. Feb 2022, at 23:19, Alexander Nasonov wrote:
>
> Martin Husemann wrote:
>> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
>>> variable, it will mix two very different styles of mounting and
>>> compilate the code.
>
> s/compilate/complicate/
>
>> "different styles of
Martin Husemann wrote:
> On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> > variable, it will mix two very different styles of mounting and
> > compilate the code.
s/compilate/complicate/
> "different styles of mounting" sounds like a non-starter to me, maybe
> that should be
On Thu, Feb 03, 2022 at 11:10:43PM +, Alexander Nasonov wrote:
> variable, it will mix two very different styles of mounting and
> compilate the code.
"different styles of mounting" sounds like a non-starter to me, maybe
that should be fixed first?
Martin
Hi Robert,
Robert Elz wrote:
> A couple of comments about your mount_critical_filesystems_zfs()
> function in rc.subr
Thank you for reviewing my code!
> It starts:
>
> eval _fslist=\$critical_filesystems_zfs
>
> I'm not sure what you're attempting to accomplish there.
I copied this line
Alexander Nasonov wrote:
> Module Name: src
> Committed By: alnsn
> Date: Thu Feb 3 20:52:44 UTC 2022
>
> Modified Files:
> src/etc: rc.subr
>
> Log Message:
> Add mount_critical_filesystems_zfs
>
> The new function is similar to mount_critical_filesystems
> but it walks through
A couple of comments about your mount_critical_filesystems_zfs()
function in rc.subr
It starts:
eval _fslist=\$critical_filesystems_zfs
I'm not sure what you're attempting to accomplish there. The eval
command sees
fslist=$critical_filesystems_zfs
(the \ having quoted the '$' pr
In article <20220105014628.9f952f...@cvs.netbsd.org>,
Robert Elz wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kre
>Date: Wed Jan 5 01:46:28 UTC 2022
>
>Modified Files:
> src/etc: Makefile
>
>Log Message:
>Install the missing sh syntax element in the MKDEBUGKERNEL = no
On Tue, Nov 30, 2021 at 10:11:36AM +, Stephen Borrill wrote:
> In our products, we have a standard rc.conf and then a series of build
> scripts that configure and enable/disable services as required. We can
> switch between npf and ipfilter with a one-line change in a settings file,
> for examp
On 30/11/2021 09:43, Martin Husemann wrote:
On Tue, Nov 30, 2021 at 09:10:35AM +, Stephen Borrill wrote:
In rc.conf, npf=YES is sufficient, but you are advocating the setting needs
to be duplicated if put into rc.conf.d.
I think the confusion starts with the idea of enabling NPF by just
pu
On Tue, Nov 30, 2021 at 09:10:35AM +, Stephen Borrill wrote:
> In rc.conf, npf=YES is sufficient, but you are advocating the setting needs
> to be duplicated if put into rc.conf.d.
I think the confusion starts with the idea of enabling NPF by just
putting the NPF=yes into scripts in /etc/rc.co
On 26/11/2021 17:52, Robert Elz wrote:
Date:Fri, 26 Nov 2021 13:11:36 +
From:"Stephen Borrill"
Message-ID: <20211126131136.63fabf...@cvs.netbsd.org>
| Load rc configuration based on rcvar, not name, so that correct settings
| in /etc/rc.conf.d are loade
Date:Fri, 26 Nov 2021 13:11:36 +
From:"Stephen Borrill"
Message-ID: <20211126131136.63fabf...@cvs.netbsd.org>
| Load rc configuration based on rcvar, not name, so that correct settings
| in /etc/rc.conf.d are loaded.
This looks wrong to me (and a pullup reque
Date:Mon, 2 Aug 2021 20:02:28 +0900
From:Rin Okuyama
Message-ID: <21dae7de-f153-2e53-4e66-cc61c8241...@gmail.com>
quoting Michael van Elst:
| > If you insist on a separate barrier, one name would be USERDEVICEPATHS
| > or short UDEV.
UDEV (or UDEVS) sounds good
On 2021/08/02 19:15, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with MKZ
On Mon, Aug 02, 2021 at 11:27:22AM +0200, Michael van Elst wrote:
> On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> > Hi,
> >
> > this commit causes:
> >
> > rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
> >
> > for systems with MKZFS=no.
> >
> > Install
On Mon, Aug 02, 2021 at 11:54:27AM +0900, Rin Okuyama wrote:
> Hi,
>
> this commit causes:
>
> rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
>
> for systems with MKZFS=no.
>
> Install /etc/rc.d/zfs for everyone? This should be harmless; the script
> properly checks e
On Mon, Aug 02, 2021 at 12:44:01PM +0700, Robert Elz wrote:
> Date:Mon, 2 Aug 2021 11:54:27 +0900
> From:Rin Okuyama
> Message-ID:
>
> | Install /etc/rc.d/zfs for everyone?
>
> Add a new dummy rc.d script (like LOGIN or DISKS)
> have devpubd come before that, and
Date:Mon, 2 Aug 2021 11:54:27 +0900
From:Rin Okuyama
Message-ID:
| Install /etc/rc.d/zfs for everyone?
Add a new dummy rc.d script (like LOGIN or DISKS)
have devpubd come before that, and everything
which should come later require it.
That's cleaner. We should
Hi,
this commit causes:
rcorder: file `/etc/rc.d/devpubd' is before unknown provision `zfs'
for systems with MKZFS=no.
Install /etc/rc.d/zfs for everyone? This should be harmless; the script
properly checks existence of /sbin/zfs, i.e., MKZFS=yes.
Alternatively, autogen /etc/rc.d/devp
On 30/09/2020 08:55, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Wed Sep 30 07:55:31 UTC 2020
Modified Files:
src/etc/mtree: NetBSD.dist.tests
Log Message:
add missing new if_vether subdir.
Thanks!
Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Mon Apr 9 15:02:39 UTC 2018
Modified Files:
src/etc/rc.d: sshd
Log Message:
Simplify so we don't have to hard-code the key filenames in two places.
There are some leftovers in the script after the si
Sorry about commit msg. should have said...
install rc.d/smtoff and provide defaults/rc.conf
setting for it
Attempting to work from my phone while waiting
for car to be serviced
On 14/01/2019 12:27, m...@netbsd.org wrote:
> [...]
> This does give the ability to configure wifi with a GUI w/o root or
> something akin to polkit, via some pkgsrc packages (There's wpa_gui, for
> example, it's a QT5 thing. I imagine writing other things is not much
> harder)
Yes, that's also wh
On Mon, Jan 14, 2019 at 01:08:27AM +, David Holland wrote:
> On Mon, Jan 14, 2019 at 09:42:54AM +1100, matthew green wrote:
> > it would be OK if this was _read-only_ access to network
> > configuration, but one should never be allowed to change the
> > it unless root.
>
> In the long run,
Date:Mon, 14 Jan 2019 11:59:51 +1100
From:matthew green
Message-ID: <10889.1547427...@splode.eterna.com.au>
| i don't agree with this.
|
| if we were going to make things easy for naive users
I didn't say "easy" for naive users, I said "most useful". That mig
matthew green writes:
> (i wouldn't pick 'wheel' as this group -- i would invent a
> new group either called 'net' or 'wpa', with no underscore
> since they're designed to be assigned, unlike the groups
> for specific programs security models.)
Are you saying that you are ok with the following:
> On Jan 13, 2019, at 5:08 PM, David Holland
> wrote:
>
> Is there a way we could, for example, leverage the current hacks for
> chowning console devices to grant access to wpa_supplicant?
Some of this could be achieved with ttyaction(5), certainly.
-- thorpej
On Mon, Jan 14, 2019 at 09:42:54AM +1100, matthew green wrote:
> it would be OK if this was _read-only_ access to network
> configuration, but one should never be allowed to change the
> it unless root.
In the long run, it's quite helpful for laptops to be able to adjust
the network configurati
> | i don't want to allow [...]
>
> People, once again, a big meaningless discussion on what the
> default configuration should be.We should work out what will
> be most useful to most naive users, and make that be the default,
> regardless of what any of us want.
i don't agree with this.
In my previous message, I forgot to also note that if
modifying (if required) wpa_supplicant to create the
socket with the ownership & permissions set in the
rc.conf file is too hard (would create issues with importing
new versions easily) then the same can be accomplished
by putting the socket in
Date:Mon, 14 Jan 2019 09:42:54 +1100
From:matthew green
Message-ID: <11338.1547419...@splode.eterna.com.au>
| > I suppose the real question is do we want to allow group access to
| > [...]
| i don't want to allow [...]
People, once again, a big meaningless di
Roy Marples writes:
> On 13/01/2019 10:20, matthew green wrote:
> > shouldn't one need to be root to modify network configuration?
> > i shouldn't be able to tell wpa_supplicant to do something as
> > non-root, in a default install.
>
> In a default install the only member of wheel is root and wpa
Jason Thorpe writes:
>> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote:
>>
>> Even if you have to be root, these changes are still hugely useful.
>> "sudo wpa_cli" is not that hard, even if it seems like it should not be
>> necessary.
>
> ...but made slightly more annoying seeing as how sudo is
> On Jan 13, 2019, at 5:21 AM, Greg Troxel wrote:
>
> Even if you have to be root, these changes are still hugely useful.
> "sudo wpa_cli" is not that hard, even if it seems like it should not be
> necessary.
...but made slightly more annoying seeing as how sudo is not part of the base
OS.
Roy Marples writes:
> On 13/01/2019 10:20, matthew green wrote:
>> shouldn't one need to be root to modify network configuration?
>> i shouldn't be able to tell wpa_supplicant to do something as
>> non-root, in a default install.
>
> In a default install the only member of wheel is root and
> wpa
On 13/01/2019 10:20, matthew green wrote:
shouldn't one need to be root to modify network configuration?
i shouldn't be able to tell wpa_supplicant to do something as
non-root, in a default install.
In a default install the only member of wheel is root and wpa_supplicant
is not started.
I su
shouldn't one need to be root to modify network configuration?
i shouldn't be able to tell wpa_supplicant to do something as
non-root, in a default install.
.mrg.
Not really, it just sets the group explicitly rather than implicitly. Without
it the socket group is derived from the directory it's created in, which is
group wheel to start with.
Now it could be argued that creating the socket in the first place allows
members of the wheel group to configure
This lets any user in wheel group choose to connect to the network.
Isn't that more privileges than we normally give?
On Sat, Jan 12, 2019 at 04:51:55PM +, Roy Marples wrote:
> +ctrl_interface_group=wheel
On Tue, 06 Nov 2018 14:36:06 +0100, "Herbert J. Skuhra" wrote:
>
> On Mon, 05 Nov 2018 22:37:31 +0100, Nick Hudson wrote:
> >
> > On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> > >> "Herbert J. Skuhra" writes:
> > >>
> > >>> On
On Mon, 05 Nov 2018 22:37:31 +0100, Nick Hudson wrote:
>
> On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> >> "Herbert J. Skuhra" writes:
> >>
> >>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>
> Module Nam
On Tue, Nov 06, 2018 at 12:58:54AM +, m...@netbsd.org wrote:
> On Mon, Nov 05, 2018 at 09:45:38PM +0100, Herbert J. Skuhra wrote:
> > With etc/etc.evbarm/Makefile.inc r1.97 the command completes. I only
> > have to fix the build of groff (PR #53314) by removing/commenting out
> > the following
On Mon, Nov 05, 2018 at 09:37:31PM +, Nick Hudson wrote:
> On 05/11/2018 20:45, Herbert J. Skuhra wrote:
> > On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> > > "Herbert J. Skuhra" writes:
> > >
> > > > On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> > > > >
> > > >
Greg Troxel writes:
> "Herbert J. Skuhra" writes:
>
>> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>>>
>>> Module Name:src
>>> Committed By: skrll
>>> Date: Sun Nov 4 21:41:12 UTC 2018
>>>
>>> Modified Files:
>>> src/etc/etc.evbarm: Makefile.inc
On Mon, Nov 05, 2018 at 09:45:38PM +0100, Herbert J. Skuhra wrote:
> With etc/etc.evbarm/Makefile.inc r1.97 the command completes. I only
> have to fix the build of groff (PR #53314) by removing/commenting out
> the following lines in obj/tools/groff/build/src/include/config.h:
>
> #define NEED_DE
On 05/11/2018 20:45, Herbert J. Skuhra wrote:
On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
"Herbert J. Skuhra" writes:
On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
Module Name:src
Committed By: skrll
Date: Sun Nov 4 21:41:12 UTC 2018
Modified Fi
On Mon, Nov 05, 2018 at 09:11:02AM -0500, Greg Troxel wrote:
> "Herbert J. Skuhra" writes:
>
> > On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
> >>
> >> Module Name: src
> >> Committed By: skrll
> >> Date: Sun Nov 4 21:41:12 UTC 2018
> >>
> >> Modified Files:
"Herbert J. Skuhra" writes:
> On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>>
>> Module Name: src
>> Committed By:skrll
>> Date:Sun Nov 4 21:41:12 UTC 2018
>>
>> Modified Files:
>> src/etc/etc.evbarm: Makefile.inc
>>
>> Log Message:
>> Only add GENERIC
On Sun, 04 Nov 2018 22:41:12 +0100, "Nick Hudson" wrote:
>
> Module Name: src
> Committed By: skrll
> Date: Sun Nov 4 21:41:12 UTC 2018
>
> Modified Files:
> src/etc/etc.evbarm: Makefile.inc
>
> Log Message:
> Only add GENERIC to earmv6 and earmv7 builds
This change obviously br
Date:Sun, 30 Sep 2018 21:40:18 +0200
From:Joerg Sonnenberger
Message-ID: <20180930194018.ga11...@britannica.bec.de>
| Just for the future, a better way would be to use :Uno or similar.
Yes, I thought there was a method like that, but make "programmming"
is not my t
On Sat, Sep 29, 2018 at 01:12:22AM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Sat Sep 29 01:12:22 UTC 2018
>
> Modified Files:
> src/etc: Makefile
>
> Log Message:
> Only test USE_XZ_SETS if it is defined. This is probably not the
> correct fix, so so
On Sat, Sep 29, 2018 at 01:12:22AM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Sat Sep 29 01:12:22 UTC 2018
>
> Modified Files:
> src/etc: Makefile
>
> Log Message:
> Only test USE_XZ_SETS if it is defined. This is probably not the
> correct fix, so so
On Thu, Jul 26, 2018 at 08:23:19AM +0200, Maxime Villard wrote:
> Le 24/07/2018 à 21:45, Thomas Klausner a écrit :
> > On Tue, Jul 24, 2018 at 07:10:38PM +0200, Maxime Villard wrote:
> > > > Is this something that we should let postinstall fix?
> > > > Or what is the upgrade strategy for the users
Le 24/07/2018 à 21:45, Thomas Klausner a écrit :
On Tue, Jul 24, 2018 at 07:10:38PM +0200, Maxime Villard wrote:
Is this something that we should let postinstall fix?
Or what is the upgrade strategy for the users not reading source-changes?
Now that I stumbled across it while browsing mail-ind
On Tue, Jul 24, 2018 at 07:10:38PM +0200, Maxime Villard wrote:
> > Is this something that we should let postinstall fix?
> > Or what is the upgrade strategy for the users not reading source-changes?
>
> Now that I stumbled across it while browsing mail-index.netbsd.org:
> doesn't postinstall use M
Is this something that we should let postinstall fix?
Or what is the upgrade strategy for the users not reading source-changes?
If you send your answer to me on a mailing list I'm not subscribed to,
without even CC'ing me, I'm just never going to see your mail.
Now that I stumbled across it whi
> Module Name:src
> Committed By: christos
> Date: Sat Apr 7 00:41:16 UTC 2018
>
> Modified Files:
> src/etc/rc.d: sshd
>
> Log Message:
> support xmss keys
I advise against generating XMSS host keys by default.
The XMSS signature scheme is stateful, so managing XMSS ke
PR bin/52905 (typo in the pr number in the log message).
On Sat, Jan 06, 2018 at 23:44:06 +, Michael van Elst wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Sat Jan 6 23:44:06 UTC 2018
>
> Modified Files:
> src/etc: security
>
> Log Message:
> Use sysctl to retrie
On Wed, Dec 06, 2017 at 08:25:08AM +0700, Robert Elz wrote:
> It isn't the precedence of the operators that is at issue, but
> deciding what is an operator -
oh right, I'm pretty sure I knew about that at one point and blocked
it out for the sake of my sanity :-)
--
David A. Holland
dholl...@n
Date:Tue, 5 Dec 2017 16:00:25 +
From:David Holland
Message-ID: <20171205160025.ga22...@netbsd.org>
| Test -o isn't well specified? Or is the issue the precedence of ! vs. -o?
-o is a "to be deprecated one day" option, but that is not really the
problem (our tes
On Mon, Dec 04, 2017 at 02:50:33PM +, Robert Elz wrote:
> Modified Files:
> src/etc/rc.d: sshd
>
> Log Message:
> Do away with (not well specified, even if it happens to work) absurd
> 15 arg test ([ ]) expression, and replace it with several well defined
> 2 arg tests, combined wi
In message <20171025074135.8b844f...@cvs.netbsd.org>
on Wed, 25 Oct 2017 07:41:35 +,
"Takahiro Kambe" wrote:
> Module Name: src
> Committed By: taca
> Date: Wed Oct 25 07:41:35 UTC 2017
>
> Modified Files:
> src/etc/namedb: root.cache
>
> Log Message:
> /tmp/t
On Sat, 21 Oct 2017, Robert Elz wrote:
Log Message:
Create directory for new bwfm firmware to be installed into.
Thank you!
On Jul 8, 12:47pm, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k
| > | The PR says:
| > | > This information should be fixed to reflect reality, or
etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
| > |
| &g
> | The PR says:
> | > This information should be fixed to reflect reality, or
> etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
> |
> | What makes you choose the latter?
>
> That every arch except alpha uses ttya and ttyb for zstty?
In which file? zs(4) man page?
---
The PR says:
> This information should be fixed to reflect reality, or
> etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
What makes you choose the latter?
---
Izumi Tsutsui
On Jul 8, 11:41am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k
| The PR says:
| > This information should be fixed to reflect reality, or
etc/etc.next68k/MAKEDEV.conf should build tty[ab] as done on e.g. sparc.
|
| What makes you choose
On Jul 8, 11:31am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote:
-- Subject: Re: CVS commit: src/etc/etc.next68k
| IMO man page should be updated to mention "ttyZ[01]",
| as MI src/etc/MAKEDEV.tmpl does.
|
| tty[ab] were derived from sun3 and sparc, which followed SunOS ones.
|
| O
> Module Name: src
> Committed By: christos
> Date: Fri Jul 7 23:48:34 UTC 2017
>
> Modified Files:
> src/etc/etc.next68k: MAKEDEV.conf
>
> Log Message:
> PR/52377: Miod Vallat: Provide links to ttya and ttyb as mentioned in zs(4)
IMO man page should be updated to mention "ttyZ[0
In article <20170116093926.99ca3f...@cvs.netbsd.org>,
Hauke Fath wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: hauke
>Date: Mon Jan 16 09:39:26 UTC 2017
>
>Modified Files:
> src/etc: protocols
>
>Log Message:
>Add carp as an alias for vrrp - after all, we do not ship vrr
joerg@ wrote:
> Is the change of opty to ipty intentional?
Yes.
---
Izumi Tsutsui
On Fri, Jan 29, 2016 at 06:03:16PM +, Izumi Tsutsui wrote:
> Module Name: src
> Committed By: tsutsui
> Date: Fri Jan 29 18:03:16 UTC 2016
>
> Modified Files:
> src/etc/etc.atari: MAKEDEV.conf
>
> Log Message:
> Drop almost unnecessary devices for floppy to shrink sysinst.fs.
>
1 - 100 of 263 matches
Mail list logo
